ATLAS Computing Model Alessandro De Salvo 19-02-2015 A. De Salvo – 19 febbraio 2015

Roadmap Il Computing Model di ATLAS che verrà descritto oggi si riferisce per la quasi totalità al Run2 Molto difficile ipotizzare quello che succederà nei run successivi, sia da un punto di vista tecnologico che di strategie Molte applicazioni e parametri, utili per i successivi sviluppi, verranno definiti in modo più accurato una volta che si avrà sufficiente esperienza con il sistema durante il Run2 Pur non ipotizzando grosse differenze tra Run2 e Run3 non si possono quindi fare previsioni su quello che accadrà dopo il Run2 In parte questo è anche vero per il Run2 stesso, all’interno del quale probabilmente ci saranno comunque delle piccole evoluzioni Al momento non sono definite altre roadmap al di fuori di quanto verrà applicato direttamente al Run2 2

Nuovo Computing Model di ATLAS nel Run2 Nuovo sistema di computing Rucio (Data Management) Prodsys-2 (Workload Management) FAX ed Event Service per ottimizzare l’utilizzo delle risorse Ottimizzazione della Produzione ed Analisi Run-1: 75% / 25% (slots occupancy ~ cputime usage) Run-2: 90% / 10% (stima grossolana) La maggior parte dell’analisi (Derivation) sarà spostata sulla (group) production L’analisi rimanente sarà più veloce e I/O intensive Riduzione del merging e produzione di file più grandi Code dinamiche in Panda, basate sui requirement dei job Direct I/O (xrootd e WebDAV/HTTPS) 3

Lifetime dei dati Modello di lifetime dei dati Ogni dataset avrà un lifetime settato in fase di creazione La lifetime può essere infinita (ad esempio per i dati RAW) e può essere estesa, ad esempio se il dataset è stato utilizzato di recente oppure se esiste una eccezione conosciuta Ogni dataset avrà una retention policy, ad esempio i RAW saranno memorizzati in doppia copia su tape e gli AOD almeno una copia su tape Durante la loro lifetime I dataset verranno contrassegnati come dati primari, e quindi non cancellabili I dataset con lifetime spirata verranno contrassegnati come secondari e potranno scomparire in ogni momento dai dischi e dai tape, ad eccezione dei Group disk e LocalGroup disks Utilizzo maggiore del tape, ma non dal punto di vista degli utenti finali, tranne casi particolari 4

Novità del Computing di ATLAS nel Run2 Utilizzo più efficiente delle risorse Maggiore flessibilità nel Computing Model (Clouds/Tiers) Eliminazione dei ruoli stretti T1/T2/T3 Global Panda queue Global Storage Pool (STABLE, UNSTABLE, VOLATILE) Diminuzione delle risorse utilizzate (multicore) Ottimizzazione del workflow delle analisi (Derivation Framework/Analysis Model) La maggior parte delle analisi: Processeranno una grande mole di dati Utilizzeranno meno tempo di CPU Un singolo job di analisi sui dataset derivati può utilizzare fino a 40MB/s (vs. 4 MB/s nel Run-1 con gli AOD) Utilizzo di risorse opportunistiche Grid, Cloud, HPC, Volunteer Computing 5

Risorse opportunistiche: HPC S. Campana – ATLAS Jamboree – Dec 2014 6

Risorse opportunistiche: Cloud S. Campana – ATLAS Jamboree – Dec 2014 7

Risorse opportunistiche: Volunteer Computing Boinc-based Low priority jobs with high CPU-I/O ratio Non-urgent Monte Carlo simulation Need virtualisation for ATLAS sw environment CERNVM image and CVMFS No grid credentials or access on volunteer hosts ARC middleware for data staging The resources should look like a regular Panda queue ARC Control Tower ATLAS @ HOME CERN ARC Control Tower Panda Server ARC CE Boinc server (vLHC@Home) Volunteer PC Boinc Client VM Shared Directory Grid Catalogs and Storage DB on demand BOINC PQ Shared NFS D. Cameron – Pre-GDB on Volunteer Computing – Nov 2014 Volunteers growth Continuous 2000-3000 running jobs almost 300k completed jobs 500k CPU hours 14M events 50% CPU efficiency Currently >10000 volunteers 300 new volunteers/week 8

Storage Federation Goal reached ! >96% data covered We deployed a Federate Storage Infrastructure (*): all data accessible from any location Analysis (and production) will be able to access remote (offsite) files Jobs can run at sites w/o data but with free CPUs. We call this “overflow”. S. Campana – ATLAS Jamboree – Dec 2014 9

Nuovi tipi di Reprocessing nel Run2 Derivation Framework Modello in super-streaming, con scopo finale la produzione per (gruppi di) analisi Potenzialmente può risolvere problemi nell’input di AOD Esegue operazioni intensive di CPU su eventi selezionati I lumi-block completi appaiono solo dopo il passaggio del Derivation Framework AODtoAOD Reprocessing Risolve problemi che necessitano solo di input di AOD Intrinsecamente correlato con il Derivation Framework RAWtoAOD - Fast Reprocessing Riprocessamento veloce dove vengono aggionate solo le Condition Data RAWtoAOD - Full Reprocessing Riprocessamento veloce dove vengono applicate le nuove calibrazioni e viene aggiornato il software 10

S. Campana – ATLAS Jamboree – Dec 2014 Derivation Framework S. Campana – ATLAS Jamboree – Dec 2014 11

Analysis Model per il Run2 S. Campana – ATLAS Jamboree – Dec 2014 Common analysis data format: xAOD replacement of AOD & group ntuple of any kind Readable both by Athena & ROOT Data reduction framework Athena to produce group derived data sample (DxAOD) Centrally via Prodsys Based on train model one input, N outputs from PB to TB S. Campana – ATLAS Jamboree – Dec 2014 12

Event facilities Event Service Event Index Event level processing, implementato a livello di ProdSys (e pilot) L’event service verrà inzialmente utilizzato su risorse tradizionali (grid/cloud) e successivamente anche su HPC e oltre Inizialmente sarà usato per la simulazione, per poi essere ampliato a tutto il resto, fino all’utilizzo di un Event Streaming Service Integrazione con G4Hive e Multi-Threading Event Index Semplificazione del TagDB di ATLAS, trasformandolo in un indice degli eventi (EventIndex), con puntatori allo storage che contiene gli eventi in vari formati (da RAW a NTUP) Basato su Hadoop Imminente sostituzione del TagDB con l’EventIndex 13

Performance del software Ricostruzione Raggiunto il fattore 3 di miglioramento rispetto al Run-1, previsto dal nuovo Computing Model! Dimensione degli AOD Raggiunta la dimensione prevista dal Computing Model 14

D. Charlton – ATLAS Italia – Feb 2015 Computing resources D. Charlton – ATLAS Italia – Feb 2015

Infrastruttura italiana ATLAS in Italia continuerà ad usare per il Run2 il Tier1 e i Tier2 allo stesso modo del Run1 Tier1 + 4 Tier2 (Tier2 di tipo ‘S’ – Stable) con risorse sempre più equalizzate Interfaccia primaria di tipo Grid Full mesh con accesso ai dati locali e tramite Federazioni di Storage Cambiamenti in fase di studio o di sviluppo Interfacce di tipo Cloud Prototipo di Tier-2 distribuito Progetto PRIN LHC-StoA, tra NA e RM Possibile estensione a più siti T2 Attualmente il target è quello della condivisione di servizi in HA multiregione, ma può anche essere esteso Attività promettente, limitata solo dall’esigua quantità di manpower che può essere dedicato a tale scopo

Conclusioni Il computing di ATLAS si è evoluto in modo sostanziale per il Run2 Ma è molto difficile immaginare cosa accadrà dopo Molti cambiamenti importanti DDM (Rucio) ProdSys 2 Data lifetime model Derivation framework e fast reprocessing … Grande lavoro fatto dagli sviluppatori per aumentare le performance Raggiunto un fattore 3 di velocità in più sulla ricostruzione Fast simulation in preparazione (2016)

Backup slides

Software & reprocessing in 2015/2016 P Laycock – ATLAS sw workshop 02/2015 19

Tabella dei parametri per il 2015-2017