Archivi categoria: Ricerca

A caccia di muoni

Sono sempre stato affascinato dai progetti di grid computing e di citizen science. Non ho mai sperimentato SETI@home perché la ricerca di forme di vita extraterrestri non rientra nei miei interessi ma, in una fase piuttosto nerd della mia vita, avevo configurato un server per Folding@home, il progetto sullo studio delle proteine dell’Università di Stanford.
Qualche giorno fa ho ricevuto il mio primo numero di Asimmetrie, la rivista dell’Istituto Nazionale di Fisica Nucleare, numero interamente dedicato ai muoni. La rivista, splendidamente realizzata, viene recapitata gratuitamente a tutti coloro che ne fanno richiesta e, pur affrontando tematiche legate alla fisica delle particelle, risulta sufficientemente divulgativa da garantire una piacevole lettura.
Nell’ultima pagina ho trovato il riferimento ad un progetto veramente interessante promosso dal Wisconsin IceCube Particle Astrophysics Center della Wisconsin University denominato DECO (Distributed Electronic Cosmic-ray Observatory).

DECO
In breve si tratta di sfruttare il sensore della fotocamera di un dispositivo mobile per rilevare i muoni derivanti dai raggi cosmici.
Al di là di un interesse amatoriale per la fisica delle particelle, l’entusiasmo è scattato perché i raggi cosmici seguono un processo di branching e quindi rientrano nel mio ambito di studio.
È bastato requisire un vecchio cellulare Android di mia moglie ormai in disuso e istallare l’app del progetto per trasformare la mia soffitta il mio studio1 in un rilevatore di muoni.
Se qualcuno fosse interessato a vedere come me la sto cavando, il link al tracciato CSV è questo: https://deco-web.wipac.wisc.edu/?sensor_id=DECO-ffffffff-fc4b-30b0-4480-0c3100000000&output=csv.


  1. Sembra che, sebbene la soffita sia ad un solo piano di distanza, non sia raggiunta dal wi-fi di casa pertanto l’app non è in grado di trasmettere i dati al server. In attesa di portare la connessione tramite una power line, ho spostato il rilevatore nella libreria dello studio.

A che punto siamo?

E’ passato molto tempo dall’ultima volta che ho scritto su questo blog ma non sono stato inoperoso. Certo il progetto procede un po’ a rilento ma durante l’estate sono state fatte molte correzioni alla base dati e, ad oggi, dovrei essere in grado di integrare i dati con quelli provenienti da un’altra base dati online, operazione che dovrebbe colmare alcune lacune nelle genealogie studiate. Proprio in questi giorni sto valutando l’impatto di questa operazione di integrazione.

Qualche mese fa, il professore mi ha chiesto di dare una mano ad un suo tesista in fisica statistica che sta lavorando sulla cladistica tra famiglie. L’idea era quella di integrare gli alberi genealogici dei capostipiti dell’alta nobiltà con rami sterili e su questi dati condurre varie analisi di tipo statistico. La base dati del progetto Hochadelsdorf poteva quindi costituire un ottimo punto di partenza ma necessitava di alcune elaborazioni. Ho fatto quindi quello che forse avrei dovuto fare fin dall’inizio: trasformare la base dati in una base dati relazionale. Attualmente infatti il database di Hochadelsdorf è una enorme tabella in cui molti dati sono ridondanti. Ho quindi estratto la tabella dei soggetti univoci assegnando ad essi un codice numerico ed ho sostituito, nella tabella delle occorrenze, i nomi con i codici. Poi a ciascun soggetto ho assegnato il codice del padre e quello della madre. In questo modo ho facilitato il lavoro del tesista fornendogli i dati in un formato sicuramente più maneggevole. Magari in un prossimo post entrerò nel dettaglio delle istruzioni SQL adoperate per la trasformazione.

Arrampicandosi sull’albero genealogico

La fine del 2016 è stata un momento decisamente intenso: l’arrivo della piccola prima e il trasloco nella nuova abitazione poi, hanno messo me e mia moglie a dura (ma piacevole) prova. Il trasloco in particolare è stato frenetico e gli scatoloni continuano a dominare il panorama domestico. Nel riordinare alcuni oggetti fragili, diligentemente imballati, a (vana) difesa dalla maldestrìa dei traslocatori, in carta di giornale, mi è capitato tra le mani un articolo del quotidiano locale, a data 18 luglio 2016, dall’occhieggiante titolo “Così ci arrampichiamo sull’albero genealogico”. Sin dalle prime righe appariva evidente il tenore da articolo estivo, tipico di quando i giornali hanno meno contenuti e incaricano qualcuno dei cronisti (in questo caso la giornalista Ileana Reali) di scrivere un pezzo su un argomento di costume, ma sono comunque arrivato in fondo alla lettura. L’articolo spiegava in breve come tentare di ricostruire il proprio albero genealogico con i consueti mezzi: i parenti, internet, gli archivi.
In sostanza un onesto articolo sulla genealogia familiare. Quello che mi ha invece interessato e fatto riflettere è stata la figura a corredo dell’articolo, un disegno realizzato da una maestra, Roberta Bancale, che raffigura sulla sinistra un albero spoglio a cui una bambina appende tre cartellini, “babbo”, “mamma”, “io” e, sulla destra, lo stesso albero con foglie e fiori. Mi ha ricordato il modo di procedere nella realizzazione della base dati di Hochadelsdorf: i rami ci sono tutti e sono i codici Sosa presenti nella base dati (dovrò decidermi prima o poi a scrivere qualcosa sul sistema Sosa-Stradonitz); quello che, in parte, manca sono le foglie e i fiori ovvero i soggetti giusti al posto giusto. L’opera (apparentemente infinita) di completamento che sto portando avanti assomiglia alla bambina che appende i cartellini in attesa che l’albero fiorisca. In questo momento anche la mia ricerca sta affrontando un lungo e freddo inverno ma confido in una rigogliosa primavera, che porti finalmente qualche fiore al progetto, e in una estate ricca dei tanto attesi frutti.
Concludo con una citazione della storica francese Christiane Klapisch Zuber, riportata in testa al citato articolo.

“L’albero durante i secoli ha rappresentato quel grande corpo che è un lignaggio, una discendenza. Come l’albero, una famiglia nasce, si sviluppa, si ramifica, si secca. Le rappresentazioni della parentela hanno utilizzato fin da tempi molto antichi questa metafora che si è poi fissata in una immagine: l’albero genealogico”.

Un mese con Azure

Come già anticipato nel post precedente, ho spostato (o meglio copiato) la base dati del progetto su Azure ed ho cominciato ad usare i servizi cloud di Microsoft. Al termine del primo mese di utilizzo posso fare un primo bilancio di costi, qualità e usabilità della piattaforma.

Sono sempre stato un po’ scettico su Azure sia a causa di una prima non positiva esperienza quando il servizio era ancora agli esordi e quindi non esattamente intuitivo nell’utilizzo, sia per la paura di una tariffazione oscura ed incontrollabile.

A distanza di qualche anno da questa prima esperienza, Azure ha raggiunto una completezza e chiarezza di servizio, supportata da una interfaccia utente intuitiva e potente, tale che l’utilizzo risulta agevole fin dai primi approcci.

Le diffidenze verso la tariffazione sono state vinte grazie alla sottoscrizione DreamSpark ottenuta tramite l’email (da studente) dell’Università che consente l’utilizzo gratuito di diversi servizi. In realtà, con la sottoscrizione DreamSpark si fa ben poco, soprattutto a livello di database, ma è servita come chiave di ingresso nel mondo di Azure. Appena mi sono reso conto che il servizio poteva essermi utile, ho cercato di espandere le possibilità di utilizzo e mi sono ricordato che come sviluppatore Microsoft, tramite il programma Dev Essentials, potevo avere diritto, per un anno, ad un credito mensile pari a 25 euro. Restava da verificare cosa fosse possibile fare con 25 euro/mese.

azure_novembre

Il grafico, estratto dalla dashboard del mio account Azure, mostra il consumo di credito nel primo mese ed appare evidente che non ho esaurito il credito malgrado l’uso intensivo e gli errori di configurazione dati dall’inesperienza.

Come prima cosa ho creato un database SQLServer analogo a quello locale del progetto. Ho scelto una configurazione con un numero di DTU (che sono le unità di elaborazione dei database Azure) non troppo basso perché dovevo trasferire qualche milione di righe solo per creare la base dati e la sottoscrizione DreamSpark, con solo 5 DTU, era andata immediatamente in saturazione. Ho scelto la soluzione da 10 DTU che si è rivelata sufficiente alle operazioni necessarie al trasferimento dei dati ma anche all’elaborazione delle interrogazioni. Azure inoltre, in base all’utilizzo del database, suggerisce ed applica ottimizzazioni alle tabelle e alle query.

Ho usato il database per alcuni giorni notando che il consumo di credito era abbastanza irrisorio e che l’utile proiezione del grafico preannunciava che avrei terminato il mese con oltre metà del credito disponibile.

Ho deciso di creare quindi anche una macchina virtuale da usare collegato in Remote Desktop per accedere al database da dispositivi privi di software specifico. Le macchine virtuali generiche Windows 10 sono riservate ai sottoscrittori MSDN ma è sempre possibile creare una macchina con Visual Studio. Il sistema operativo, in questi casi, è una versione server di Windows, in particolare Windows Server 2012 R2. Qui ho commesso un errore: nel creare la macchina virtuale, il sistema suggerisce due configurazioni abbastanza carrozzate in termini di RAM e processore ma con tariffe alte. Confidando in un utilizzo saltuario, ho scelto una di queste senza notare il link “mostra tutte”. Nel grafico, questa scelta corrisponde alla drastica e rapida riduzione del credito. Dopo aver notato che, malgrado un uso veramente minimo, il credito calava vertiginosamente, ho distrutto e ricreato la macchina virtuale usando un diverso piano tariffario, riducendo la RAM a 1.75GB e usando un processore mono core. Il grafico del consumo, a quel punto, ha ripreso un andamento più rassicurante. La cosa positiva da notare è che molte delle operazioni di creazione di servizi (siano essi database o macchine virtuali) è intuitiva e veloce.

Una sola accortezza è necessaria nell’uso delle macchine virtuali di Azure: non basta spegnerle per ridurre quasi a zero il consumo, vanno deallocate. In pratica, oltre a spegnere la macchina occorre spegnerla anche dalla piattaforma e poi deallocarla premendo nuovamente sul pulsante arresta della propria area di gestione. In alternativa è possibile configurarsi uno script PowerShell da lanciare dalla propria dashboard. Come stima grossolana, un’ora di utilizzo di una macchina virtuale di queste dimensioni costa circa 0.20 euro.

Dal punto di vista della qualità del servizio c’è poco da dire, Azure funziona alla grande e fornisce quasi out of the box moltissimi servizi. Per il progetto che sto portando avanti, ho configurato un database replica di quello ufficiale e una macchina per lo sviluppo e l’interrogazione della base dati in pochissimo tempo e con una spesa abbordabile. Inoltre non devo preoccuparmi di configurazioni del sistema, di hardware (e relativi guasti) e, soprattutto, di backup.

In conclusione, grazie alla sottoscrizione Dev Essentials, godrò per un anno di un ambiente di lavoro potente, raggiungibile da ovunque e sicuro. Al termine della sottoscrizione, molto probabilmente, deciderò di stanziare un fondo per l’uso della piattaforma, magari limando ancora un poco le risorse per contenere ulteriormente le spese anche se sono convinto che la comodità di un sistema come quello che ho configurato su Azure non abbia prezzo.

Nella nuvola

L’arrivo di mia figlia ha rivoluzionato in positivo, tra le tante cose, anche i tempi e gli spazi della mia ricerca. L’ora quotidiana dedicata al progetto, in genere dalle 6 alle 7 dei giorni feriali, è adesso dedicata alla preparazione dei biberon, al cambio dei pannolini o, se va bene, al recupero di qualche momento prezioso di sonno.

Ho deciso quindi di cambiare l’approccio e questo mi ha permesso di sperimentare strumenti interessanti distribuiti sul cloud. L’esigenza è stata quella di avere i dati sempre disponibili in modo da poter lavorare in qualunque momento e da qualunque postazione. E’ stata quindi l’occasione per sperimentare i servizi di Microsoft Azure che da tempo mi incuriosivano ma verso i quali nutrivo sempre una certa diffidenza. L’account DreamSpark ottenuto tramite la email dell’Università non mi consentiva di fare molto a causa delle sue limitazioni. Per fortuna, il programma Dev Essentials fornisce agli sviluppatori un credito mensile di 25 euro, sufficiente a creare un database abbastanza grande da ospitare i dati del progetto. Ho così creato una copia della base dati su Azure in modo da averla sempre disponibile. Per il momento, storage e uso non intensivo di un database di circa 500MB mi costano circa 0.35 euro al giorno, abbondantemente dentro i limiti del credito concessomi.

L’interrogazione della base dati avviene attraverso i medesimi strumenti usati per la versione locale (ovvero SQLServer Management Studio) ma adesso ho il vantaggio di poter lavorare in mobilità che significa durante la pausa pranzo o nei tempi morti di altre attività. Per questo ho istallato anche una app sullo smartphone (SQL Server Metro) anche se l’utilizzo è limitato a qualche interrogazione di controllo dati.

In realtà lo strumento che avrei voluto usare in mobilità sarebbe dovuto essere il netbook convertibile Asus VivoTab ma mi sono scontrato con le grosse limitazioni del sistema operativo Windows RT. L’unica app (a pagamento!) disponibile per questo sistema che possa interfacciarsi con SQL Server non funziona con l’ultima versione di Azure SQL Server e l’ho scoperto a mie spese. Con questa versione di SQL Server non è possibile neanche utilizzare il management online, funzionante fino alla precedente versione. Proverò il servizio Azure RemoteApp sperando di rimanere nei limiti del credito, ammesso che funzioni. E’ un vero peccato perché con queste giornate di caldo, su una panchina durante la pausa pranzo, avrei lavorato veramente bene!

Comunque sia, aver decentralizzato i dati copiandoli nel cloud mi sta dando una maggiore libertà di gestione in termini di luogo e tempo di lavoro oltre a fornirmi una copia sicura di backup (oltre a quella su dispositivo rimovibile). Come spesso accade, soprattutto a me, una apparente (e in questo caso piacevole) limitazione è motivo per apprendere cose nuove, sperimentare, tentare con tenacia di superare i limiti del mezzo tecnologico. Una sfida nella sfida che rende tutto molto più avvincente.

Edit (09/11/2016):
Azure RemoteApp non è più supportato, l’unica alternativa valida è stata creare una macchina virtuale su Azure con istallato SQL Server Management Studio ed accedere a quella in Desktop Remoto.

Leo van de Pas (1942 – 2016)

Mercoledi 17 Agosto 2016 è morto Leo van de Pas, ideatore e curatore del sito genealogics.org una delle più vaste e attendibili banche dati di genealogie disponibile in rete. Un lavoro titanico, come ho avuto modo di sottolineare più volte, messo a disposizione degli studiosi, condotto con rigore scientifico ed in costante aggiornamento. Con la morte di van de Pas il sito rimane attivo anche se in “modalità manutenzione” ovvero non sarà soggetto ad aggiornamenti ma solo alla correzione di eventuali errori.

Il progetto Hochadelsdorf deve moltissimo a questa base dati che costituisce la fonte principale (anche se non l’unica) dei dati che stiamo elaborando. Per questo motivo, ritengo giusto rendere onore a questo studioso e al lavoro che ha fatto. Grazie Leo!

Delusioni

Quando sembrava che il lavoro di disambiguazione della base dati fosse concluso, un nuovo processo di analisi basato questa volta non sulle coppie ma sugli “orfani” (soggetti con genitori sconosciuti) ha messo in luce una serie consistente di buchi nelle genealogie. In pratica alcuni soggetti, e non pochi, hanno i genitori noti nella maggior parte delle occorrenze nel database ma non in tutte. Queste occorrenze nelle quali il soggetto risulta figlio di ignoti (anche se i genitori sono conosciuti) crea dunque una serie di interruzioni negli alberi e soprattutto una mancata corrispondenza tra soggetti. La causa sembrerebbe essere l’integrazione di alcuni alberi con dati provenienti da altre fonti ma quello che conta, adesso, è trovare un algoritmo in grado di rimettere a posto i genitori.

Progressi

Il lungo silenzio su queste pagine è dovuto all’enorme lavoro di disambiguazione effettuato sulla base dati di Hochadelsdorf. Per disambiguazione intendo l’individuazione di soggetti che, pur essendo la stessa persona, compaiono con nomi diversi nella base dati. Il fenomeno è dovuto alla provenienza dei soggetti da fonti diverse o più semplicemente a grafie diverse dello stesso nome. Risolutiva, in questa poderosa caccia all’intruso, è stata l’ideazione di un processo di analisi che si basa non sui singoli individui ma sulle coppie. Associando ciascun soggetto al suo o ai suoi coniuge/i è stato più agevole scovare i falsi doppi e ricondurli ad una grafia unica. Il lavoro manuale è stato considerevole ma l’estrazione automatica di questo tracciato di controllo ha fatto sì che potessimo procedere per approssimazioni successive fino alla completa (o almeno ragionevolmente tale) bonifica della base dati. L’intera operazione ha richiesto oltre un anno di lavoro anche se c’è da dire che, per me, non è certo un lavoro a tempo pieno e non è stato facile individuare di tempi adeguati per essere portato a termine. L’esito positivo dell’ultimo controllo effettuato mi ha fatto tirare un sospiro di sollievo anche se sono consapevole che ci sono ancora molte fasi da affrontare prima che la base dati sia veramente adatta allo scopo della ricerca che ci siamo posti.

Sul blogging accademico

Qualche settimana fa sono stato contattato dalla giornalista Alessia Smaniotto, responsabile della comunicazione per il progetto OpenEdition Italia (l’infrastruttura che sviluppa Hypotheses.org e che ospita questo blog), con lo scopo di raccogliere materiale per un breve articolo di presentazione dei blog italiani attualmente attivi su Hypotheses.org. Genealogy Cruncher è stato uno dei blog prescelti ed ho avuto occasione di riflettere sulla genesi, sulle finalità e sul ruolo, in un panorama più ampio, di quanto ho scritto fino ad ora e scriverò in seguito in questo pubblico spazio.

Il contatto è stato fortunoso perché i filtri antispam, per un eccesso di zelo, avevano pensato bene di mettere la mail della Smaniotto nella posta indesiderata e solo il caso ha voluto che io andassi a curiosare nel bidone della spazzatura, cosa che faccio di rado ma che può riservare, a volte, delle sorprese.

Così, dopo un breve scambio di email, ho risposto alle domande e le risposte non solo hanno contribuito alla stesura dell’articolo principale ma sono state pubblicate interamente in un altro articolo esclusivamente dedicato a questo blog.

I links a cui è possibile leggere i due articoli sono:

Cinque storie di blogger italiani su Hypotheses.org

Il blogging al servizio della ricerca sulle genealogie della nobiltà europea

Se comunico solo adesso in questa sede l’uscita dei due articoli è solamente perché, nell’ultimo periodo, il progetto Hochadelsdorf ha assorbito tutte le mie energie. La normalizzazione della base dati tesa ad uniformare i soggetti univoci presenti con due diversi nomi è stata una operazione lunga e complessa ma assolutamente necessaria. Prosegue al momento il lavoro sulla identificazione dei MRCAs (Most Recent Common Ancestors) che dovrebbe costituire una parte importante di un futuro articolo sull’argomento.

Close the semantic gap

According to Wikipedia, “Scientists include theoreticians who mainly develop new models to explain existing data and experimentalists who mainly test models by making measurements – though in practice the division between these activities is not clear-cut, and many scientists perform both.” The domain-specific language that many scientists use to define their models is mathematics, and since the early days of computing science, the holy grail has been to close the semantic gap between scientific models and executable code as much as possible. It is becoming increasingly clear that all scientists are practicing applied mathematics, and some scientists, such as theoretical physicists, are behaviorally indistinguishable from pure mathematicians. The more we can make programming look like mathematics, the more helpful we make it to scientists and engineers.

Erik Meijer, prefazione a D. Syme, A. Granicz, A. Cisternino “Expert F#”, Apress 2007

Calcolo dell’età

Può capitare, lavorando con le genealogie ma anche studiando fenomeni come le dinamiche di reclutamento, di dover calcolare l’età di un soggetto, di cui si conosca la data di nascita, sia rispetto alla data odierna, sia rispetto ad un’altra data di riferimento.

Qualche tempo fa, in un mio lavoro sull’età di inizio professione da parte di alcuni soggetti operanti nel mondo giudiziario, disponendo di un database MySQL, avevo applicato con successo la seguente interrogazione:

SELECT YEAR(DATE_FORMAT([dataInizio], '%Y­%m%d')) ­- YEAR(DATE_FORMAT([dataNascita], '%Y­%m%d')) ­- (DATE_FORMAT([dataInizio], '%m%d') <  DATE_FORMAT([dataNascita], '%m%d')) AS eta  FROM [tabella]

In pratica, per calcolare l’età di inizio professione, si è proceduto facendo la sottrazione tra l’anno di inizio professione e l’anno di nascita e si è sottratto 1 qualora giorno e mese di nascita fossero successive, rispetto all’anno solare, a giorno e mese di inizio professione. Questa formula può essere scritta

anno(data inizio) – anno(data nascita) – (giorno e mese inizio < giorno e mese nascita)

in considerazione del fatto che, in MySQL, il confronto produrrà un esito booleano che sarà interpretato come 0 (falso) o 1 (vero) andando a togliere tale valore dal risultato della sottrazione iniziale.

Sicuramente non è l’unico metodo e forse neanche il più immediato tuttavia non manca di eleganza.

Ho tentato di convertire le istruzioni nella sintassi di SQLServer, database che sto usando attualmente per il progetto Hochadelsdorf.

Al posto dell’istruzione DATE_FORMAT, ma solo a partire dalla versione 2012 di SQLServer, quella usata dal progetto, è possibile fare uso dell’istruzione FORMAT che accetta in ingresso un valore, un pattern di formattazione e una indicazione di cultura.

E’ possibile quindi riscrivere l’interrogazione con la seguente sintassi:

SELECT DATEPART(YEAR, [data_inizio]) - DATEPART(YEAR, [data_nascita]) - CASE WHEN FORMAT([data_inizio],'MMdd','it-IT') < FORMAT([data_nascita],'MMdd','it-IT') THEN 1 ELSE 0 END AS eta FROM [tabella]

ottenendo lo stesso risultato.

Al momento non so se questa interrogazione sarà necessaria nella mia ricerca ma ritengo utile condividerla, anche solo come promemoria per uso futuro.

Introduzione

“La scienza è una cosa meravigliosa per chi non deve guadagnarsi da vivere con essa” (Albert Einstein)

Questo è un blog accademico. O almeno avrebbe la pretesa di esserlo. Nasce dalla lettura di questa serie di post e alla fine di un percorso di Laurea che spero essere l’inizio di uno di ricerca. I contenuti quindi non dovrebbero mancare: parlerò di informatica umanistica, di estrazione ed elaborazione di conoscenza dai dati, di metodi della fisica applicati alle scienze umane. E parlerò prevalentemente di genealogie perché è il campo di applicazione a cui mi sto dedicando.

Ho riflettuto a lungo se scrivere in italiano o in inglese ed alla fine ho optato per la mia lingua madre senza tuttavia precludermi la possibilità di postare in inglese (to post, appunto) contenuti più tecnici o di interesse generale.

Due parole sulla citazione in apertura del post. Contrariamente alla comune interpretazione del “sarebbe bello se…”, posso dire che nel mio caso, almeno per adesso, la frase ha il significato letterale di “è bello poter…”. Fintanto che riesco ad affiancare la ricerca al mio lavoro in azienda come sviluppatore software posso dire di avere un fondo di ricerca autogestito. Certo non saranno cifre da sogno ma sufficienti a svolgere con serenità la propria ricerca. E poi, non si può mai dire…