Introduzione
A differenza della scienza basata sulle osservazioni (che sono uniche), quella basata sugli esperimenti ha in principio la possibilità della riproducibilità e dunque la non necessità di condividere nella comunità o nel tempo tutti i prodotti della ricerca.
Ed è per questo che non c’è una cultura associata alla condivisione nel tempo in HEP. In astrofisica per esempio i prodotti della ricerca diventano aperti e immagazzinati con degli standard (FIT per i dati ed esiste una libreria in diversi linguaggi sw capaci di manipolare tali dati).
In HEP
Maturata la consapevolezza, visto che gli esperimenti hanno un costo… e la riproducibilità rimane "solo” un principio, il grosso sforzo è stato fatto senza una programmazione e risorse dedicate. Gli esperimenti cercano all’interno del loro perimetro “spazio-temporale” i migliori meccanismi per la condivisione dei loro prodotti della ricerca.
Fuori da tale perimetri usufruire di un oggetto digitale aperto è complicato da una serie di barriere (tecnologiche, obsolescenze, assenza di standard o conoscenze tecnico scientifiche).
ALEPH
L’esperienza maturata dopo la fine dell’esperimento indica con chiarezza che varie azioni possono mitigare le difficoltà di accesso. Tali difficoltà si riscontrano anche tra chi ha fatto parte della collaborazione… nonostante la documentazione …
Nonostante questo molti articoli sono usciti a poche firme con i dati di Aleph sia su ricerca di nuove particelle sia su studi “standard” (QCD, tau physics, etc), sempre in parallelo a novità. Ancora oggi c’è una lista di argomenti di fisica che beneficerebbe da l’uso dei dati di Aleph (lettera di Blondel Janot a Tenchini, coordinata da Ganis). Ma non esistendo un supporto per l’accesso la cosa è rimasta sulla carta. Una volta “acceso” un supporto la cosa è risultata relativamente semplice.
Data Stewart
Il supporto “acceso” è stato un processo di data stewardship. Esso è consistito di
- verificare e validare che i dati fossero accessibili (leggibili analizzabili) via via che c’era un cambio di Architettura SW.
- Validare che dati e sw fossero utilizzabili all’interno dei nuovi paradigmi di calcolo (Condor, Eudat, GRID, Cloud, data analytics parquet, etc.)
- Costruire e usare emulatori, VM e containers per le architetture in cui il sw non gira (anche in maniera incastonata)
- Tradurre i dati in formati semplici che non richiedessero l’uso del sw di ALEPH.
- La CERNLIB é stata portata per 64 bit e compilatori ultimi. Ma ALEPH perderebbe la possibilità di validazione bit to bit (produzione MC) dovendo ricompilare tutto… e geant 3 deve subire delle semplici modifiche (bugs) ma aleph ha una serie di correzioni per compensare discrepanze forse anche dovuti ai bugs…
Ci sono ulteriori cose che andrebbero fatte
- partecipare allo sviluppo e adottare edm4hep (o qualunque standard che permetterebbe l’uso di un ambiente unico di analisi per qualunque esperimento)
- I nuovi generatori costringono all’uso del sw stack di ALEPH (mentre la lettura dati già esistenti una volta tradotti non lo richiederebbe, dati mini con calibrazioni allineamento ed altre conditions già applicate). Dunque servirebbe automatizzare il running dando come input gli eventi in stdhep o altro standard.
- Nuovi generatori QCD richiederebbero nuovi tuning…
- Mettere a posto o recuperare la documentazione.
- Ripristinare il data Bookkeeping system o meglio FAIRificare gli oggetti digitali e pubblicare con DOI gerarchizzato
- Mettere i dati su Open Data Portal
