ATLAS: il calcolo Alessandro De Salvo 5-9-2013 A. De Salvo – 5 settembre 2013.

Presentazione sul tema: "ATLAS: il calcolo Alessandro De Salvo 5-9-2013 A. De Salvo – 5 settembre 2013."— Transcript della presentazione:

1 ATLAS: il calcolo Alessandro De Salvo 5-9-2013 A. De Salvo – 5 settembre 2013

2 2013 ATLAS data Logical data: singola copia dei dati prodotti Physical data: insieme di tutte le copie prodotte e replicate nelle cloud ITALY NTUP ESD AOD HITS DESD 2.5 PB 2e3 1.5e3 1e3 0.5e3 0 2012-09 2013-09 PHYSICAL DISK PHYSICAL DATA ALL ATLAS 70e3 60e3 50e3 40e3 30e3 20e3 10e3 0 2012-092013-09 AOD NTUP HITS RAW ESD 40 PB 25e3 20e3 15e3 10e3 5e3 0 2012-092013-09 HITS DESD NTUP AOD ESD 80e3 90 PB 30e3 35e3 LOGICAL DATA PHYSICAL DISK ALL ATLAS AOD NTUP HITS RAW ESD 2013-092012-09 20e3 0 40e3 60e3 80e3 10e4 12e4 14e4 160 PB 2 2.5 PB

3 Efficienza trasferimento al primo tentativo: 93% 100% considerando i retries Dati disponibili in tempo “quasi reale”: media trasferimento AOD dal Tier0 a un Tier1: 2.7 h per il completamento dei dataset Export dal Tier0 ai Tier1 RAW: 1 copia primaria (disco) + 1 copia custodial (tape) ESD: 1 copia primaria e 1 copia secondaria (su disco in siti diversi) AOD: 2 copie primarie + 1 copia secondaria +copie secondarie ai Tier2 con il sistema dinamico di replica. Nel run2 il numero di repliche primarie degli AOD scenderà a 1 per i T1 e 1 per i T2. Gli AOD meno utilizzati verranno trasferiti su tape, dal quale potranno comunque essere usati in caso di necessità I T2D (MI, NA, RM) posseggono anche copie primarie di alcuni tipi di dati Significativa riduzione del numero di copie e di formati di dati replicati nella griglia rispetto agli anni passati Suddivisione per attività: Data Brokering: replica dinamica dei dati Data Consolidation: pre-placement (T1-T1) Data export 3

4 ATLAS: Utilizzo risorse Tier 1 in Italia Pledge 2013 4 INFN-T1 : 8.79% INFN-T1 ATLAS T1s Sep 2012Sep 2013 1e5

5 ATLAS: Utilizzo risorse Tier 2 in Italia Pledge 2012 Pledge 2013 4 siti T2  Frascati  Milano  Napoli  Roma 1 5 Site reliability/availability Sistema di replica dinamico dei dati PD2P, basato sulla popolarità del dati, già dal 2010. Ottimizzazione dell’uso del disco dei Tier2 permettendo la copia di dati interessanti. Napoli Milano Frascati Roma 4.5e4 3 PB 2012-09 2013-09

6 ATLAS: Utilizzo Tier 2 & Tier 3 in Italia Tier-3 Lecce Bologna Genova Roma 3 Cosenza Pavia Roma 2 Frascati Milano Napoli Roma 1 Milano Frascati Tier-3 Napoli Roma 1 CNAF 6 2012-09 2013-09 6e8 9e7

7 Frascati Roma1 Milano Napoli Utilizzo risorse in Italia: Accounting Tier 2 Aug12 Sep12 Aug12 Sep12 Aug12 Sep12 Aug12 Sep12 Problemi pubbliicazione 7

8 Utilizzo delle risorse per il 2013-2015  2013  Possibile riprocessamento dei dati e MC 2010-2012 per studi ulteriori  Produzione di ulteriore nuovo MC per l’analisi  Attività molto intensa di analisi utente e di gruppo  2014  Produzione di sample più grandi di MC per il run ad alta energia  Reprocessing completo finale dei dati e MC del 2010-2012, utilizzando l’evoluzione del modello dei dati preparato per la presa dati del 2015  Attività di preparazione del Run 2 (full dress reharsal)  2015  Processamento e riprocessamento dei nuovi dati ad alta energia  Produzione associata di MC per I nuovi dati  Incremento di attività utente e di gruppo 8

9 Preparazione al run del 2015  ATLAS ha piani ambiziosi per l’upgrade delle attività di Software e Computing  Software: ricostruzione, simulazione, analisi  Ottimizzazione delle performance degli algoritmi, utilizzando in modo più adeguato le CPU moderne  Riduzione dell’utilizzo di memoria  Parallelismo a livello di evento e di algoritmo  Riduzione della dimensione degli eventi  Computing distribuito  Nuovo sistema di Data Management (Rucio)  File based data management, subscriptions and rules,..  Upgrade del Production System (PanDA + JEDI + DEfT)  New TRF, log file merging, …  Merging at T2s, dynamic job definition based on scouts, …  Procedure operative e workflow  Ottimizzazione delle analisi di gruppo e utenti finali 9

10 Cambi nel workflow di analisi  Il formato AOD sembra non essere l’ “Analysis Object Data” per la maggior parte delle analisi  La produzione dei formati di dati di gruppo (D3PD/NTUP) è effettuata centralmente  La situazione corrente rallenta l’analisi, crea problemi nella Grid, riempiendo I dischi, e non scala al 2015 con il Run 2  E’ necessario cambiare il modello di analisi e il suo workflow per aumentare il thoughput  Aggiornamento del workflow  Aggiornamento del formato degli AOD per farlo diventare direttamente leggibile da ROOT  Introduzione di un reprocessing AOD2AOD per ottimizzare l’utilizzo delle risorse  Introduzione di un “Derivation framework” per la produzione di formati di gruppo specifici, tramite skimming/slimming/thinning degli AOD secondo un modello a treno, rimpiazzando il modello corrente per la produzione di DPD  Introduzione di un common analysis framework, che metta a disposizione dei tool di analisi più semplici e una integrazione migliore con la Grid 10

11 Nuovi protocolli di accesso ai dati  Sperimentazione dei nuovi protocolli di accesso  xrootd e HTTP supportano lo streaming su WAN  Sperimentazione dei protocolli di accesso remoti e comparazione con i protocolli di storage nativi a disposizione  I protocolli verranno adottati sulla base delle performance, dell’affidabilità e della semplificazione che manifesteranno  Valutazione successiva di un modello per la rottura del modello di località dei dati per i job  Impatto sull’infrastruttura (storage e network)  Migrazione finale all’infrastruttura di Storage Federato  Attualmente basato su sulla tecnologia xrootd (FAX)  L’utilizzo dello storage federato comporterà un cambio di paradigma, sia a livello centrale che a livello utente  Possibilità di accesso diretto ai file anche su siti che non hanno un file system Posix (es. GPFS al CNAF, …), quindi ad esempio tutti I siti DPM (LNF, NA, RM, …)  Utilizzo più massiccio della rete  Maggiore affidabilità di analisi e ottimizzazione dello spazio disco 11

12 Uso di risorse opportunistiche  Cloud commerciali a basso costo o gratuite  Utilizzo di VM allocate staticamente in una cloud è stato ampiamente dimostrato in produzione (includendo anche la farm HLT)  ATLAS si concentrerà ad ottimizzare la gestione dinamica delle risorse di calcolo attraverso delle interfacce di provisioning di VM (ad esempio OpenStack)  Il piano consiste nell’integrare la AutoPilot Factory 2 con OpenStack/EC2  Si lavorerà sull’ottimizzazione del workflow per l’utilizzo di risorse opportunistiche  Il nuovo “event server”, ossia il dispatcher di eventi per la parallelizzazione dei task, sarà molto utile in questo ambito  Possibilità di utilizzo di risorse di tipo HPC, ma alcuni problemi  Whole-node scheduling  Assenza di disco nei nodi  Nessuna connessione outbound 12

13 Partecipazione italiana alle attività di ATLAS  ATLAS Italia partecipa alle attività di computing di ATLAS in diverse aree di lavoro  Cloud support [all]  Database [D. Barberis]  Installazione del software (CVMFS e distribuzione) [A. De Salvo]  Monitoring [S. Tupputi]  Network infrastructure (LHCONE) [E. Capone, A. De Salvo]  Scrutiny Group [G. Carlino]  Storage [A. De Salvo, A. Doria, E. Vilucchi]  Federazioni di xrootd e HTTPD  DPM  VO management [A. De Salvo]  Altre attività (PRIN)  Cloud Computing  Hadoop (EventIndex)  Network Infrastructure (LHCONE)  Proof on Demand  La partecipazione alle rimanenti attività è largamente limitata dalla disponibilità di persone  Attività sulle GPU, inserite in un FIRB  Interesse della comunità per GPU e multiprocessing/ottimizzazione del codice, ma NON c’è manpower  2 FTE al CERN, pagati dall’INFN in-kind e riconosciuti come M&O-A 13

14 Responsabilità italiane nel calcolo di ATLAS  ATLAS database  Dario Barberis [coord]  https://twiki.cern.ch/twiki/bin/viewauth/AtlasComputing/AtlasDistributedComputing https://twiki.cern.ch/twiki/bin/viewauth/AtlasComputing/AtlasDistributedComputing  Coordinamento calcolo ATLAS IT  Alessandro De Salvo [coord]  https://web2.infn.it/atlas/index.php/organigramma https://web2.infn.it/atlas/index.php/organigramma  https://twiki.cern.ch/twiki/bin/viewauth/AtlasComputing/InternationalComputingBoard https://twiki.cern.ch/twiki/bin/viewauth/AtlasComputing/InternationalComputingBoard  Grid software release / CVMFS  Alessandro De Salvo [coord]  https://twiki.cern.ch/twiki/bin/viewauth/AtlasComputing/AtlasDistributedComputing https://twiki.cern.ch/twiki/bin/viewauth/AtlasComputing/AtlasDistributedComputing  SAM monitoring  Salvatore Tupputi [deputy coord]  https://twiki.cern.ch/twiki/bin/viewauth/AtlasComputing/AtlasDistributedComputing https://twiki.cern.ch/twiki/bin/viewauth/AtlasComputing/AtlasDistributedComputing  Scrutiny Group  Gianpaolo Carlino  https://twiki.cern.ch/twiki/bin/viewauth/AtlasComputing/InternationalComputingBoard https://twiki.cern.ch/twiki/bin/viewauth/AtlasComputing/InternationalComputingBoard  VO management  Alessandro De Salvo [coord]  https://twiki.cern.ch/twiki/bin/viewauth/AtlasComputing/AtlasDistributedComputing https://twiki.cern.ch/twiki/bin/viewauth/AtlasComputing/AtlasDistributedComputing 14

15 Risorse Disponibili 2013 - CPU CPUFrascatiMilanoNapoliRomaTotale HP0656331015910798985036440 To be pledged 34200 Le CPU totali a disposizione dei Tier2 comprendono anche risorse che non pledged: CPU per uso locale (cluster proof) o in griglia ma dedicate principalmente alle attività italiane (Tier3) finanziate con fondi vari –Proof on Demand, share per analisi e simulazione MC per il ruolo atlas/it le CPU obsolete (fino al 2013 e già rifinanziate) ancora in produzione ma in corso di spegnimento CPU non a completa disposizione dei siti –(es. scope a NA, SuperB a LNF) Queste CPU concorrono alla definizione della linea blu dell’accounting che in alcuni casi è significativamente maggiore della linea rossa Nel conto delle CPU pledged sono comprese le CPU gara CNAF 2013 ancora da installare CPU disponibili 2013 “pledged” 15

16 Risorse Disponibili 2013 – Disco DiscoFrascatiMilanoNapoliRomaTotale Totale disponibile 5461133118010583917 to be pledged 3517 Lo storage totale disponibile nei Tier2 comprende anche l’area locale in cui sono conservati i dati di tutti gli utenti italiani (LOCALGROUP), non solo gli utenti locali La dimensione di queste aree è di circa 100 TB per Tier2 In gran parte già occupata, gli utenti dovranno cancellare i dati vecchi non più necessari per fare spazio ai dati del 2013 l’utilizzo di queste aree è irrinunciabile per cui il loro volume va sottratto allo storage da dichiarare pledged Storage disponibile 2013 “pledged” 16

17 ATLAS: Risorse Obsolete nel 2014/2015 Le CPU obsolete sono le macchine con più di 3 anni di vita Lo storage obsoleto comprende le SAN con più di 5 anni di vita La sostituzione del materiale obsoleto, specie per i dischi, è fondamentale per il buon funzionamento dei centri e quindi dell’intero sistema di computing italiano di ATLAS CPU 2014 (HS06) CPU 2015 (HS06) Disco 2014 (TBn) Disco 2015 (TBn) Frascati118723040120 Milano49793735192176 Napoli53123415184180 Roma4707307292180 Tot1618512526468656 Risorse obsolete 2014/2015 17

18 Risorse Attività ATLAS 2014 Lo Scrutiny Group ha approvato ad aprile 2013 le seguenti risorse per ATLAS 18 Nuove richieste di ATLAS (09/2013), ancora non approvate dall’RRB

19 Richiesta Risorse 2014 - I Le risorse necessarie per il 2014 sono determinate dalla volontà di conservare il ruolo significativo nel computing di ATLAS acquisito negli ultimi anni conservando gli share di risorse pledged per le attività centrali: Tier1: 10% Tier2: 9% CPU e 7% Disco e di garantire la competitività agli utenti italiani mediante l’uso di risorse dedicate nei Tier2 e Tier3 Richieste aggiornate a settembre 2013 ATLAS Share IT ATLAS IT 2014 ATLAS IT disponibile Delta (da RRB) Attività 2014 CPU T1 (kHS06) 365 10%36.531.9 * +1.04.6 Disco T1 (PB) 3510%3.53.3 * +0.20.2 CPU T2 (kHS06) 4259%38.334.2+3.24.1 Disco T2 (PB) 527%3.73.5+0.20.2 * Pledge 2013 19

20 Richiesta Risorse 2014 - II Le risorse per le attività italiane sono già disponibili e non inclusi nel disponibile “pledged” 2013 e non sono necessarie ulteriori richieste Attività 2013 Attività Italiane Obs Richieste 2014 Tot CPU T2 (kHS06) 0016.24.120.3 Disco T2 (TB) 00468200668 Attività 2013 Attività Italiane Obs Richieste 2014 Tot CPU T2 (kHS06) 0010.90 Disco T2 (TB) 002840 + Recas - Napoli Totale 20 Richieste effettive

21 Risorse CPU Attività ATLAS 2015-2017 Richieste di ATLAS per il 2015-2017, aggiornate al 28/08/2013, non ancora referate 21 I valori in [] sono relativi alle richieste presentate in precedenza

22 Risorse Disco Attività ATLAS 2015-2017 Richieste di disco ATLAS per il 2015-2017, aggiornate al 28/08/2013, non ancora referate 22

23 Conclusioni  Il Computing di ATLAS ha dimostrato di essere robusto ed affidabile per il processamento dei dati, sia MC che analisi finale, tuttavia sono stai individuati dei punti dove è necessario migliorare  Durante il LS1 il Computing Model di ATLAS subirà un sostanziale cambiamento, apportando modifiche sia al codice di ricostruzione/analisi sia ai servizi infrastrutturali  L’Italia contribuisce in modo sostanziale alle attività centrali di calcolo e tramite i centri nazionali (T1 e T2)  ATLAS sta tentando di ridurre l’incremento del 2015, pur bilanciando in parte con il 2014  Le richieste sono diminuite in conseguenza delle nuove risorse provenienti dal progetto RECAS nelle sedi di BA, NA, CS e CT  RECAS può soddisfare anche l’incremento di richieste di ATLAS, a discapito del 2015  E’ comunque fondamentale fornire supporto ai Tier2 esistenti per quel che riguarda le dismissioni 23

24 Backup slides 24

25 Availability = time_site_is_available/total_time Reliability = time_site_is_available/ (total_time-time_site_is_sched_down) Availability / Reliability 2011-2013

26 Risorse Obsolete nel 2014 Le CPU obsolete sono le macchine comprate nel 2010 e installate fine 2010 inizi 2011 (non sono comprese le macchine installate successivamente). Le CPU hanno garanzia triennale Lo storage obsoleto comprende le SAN comprate nel 2008 e installate giugno 2009. Garanzia quinquennale Le dismissioni di Napoli sono finanziate da RECAS La sostituzione del materiale obsoleto, secie per i dischi, è fondamentale per il buon funzionamento dei centri e quindi dell’intero sistema di computing italiano di ATLAS CPU (HS06) Disco (TBn) Frascati11870 Milano4979192 Napoli5312184 Roma470792 Tot16185468 Tot – NA10873284 Risorse obsolete 2014 26

27 Utilizzo risorse in Italia: Federazione T2 Pledge 2012 Pledge 2013 27

28 Il sistema di replica dinamico dei dati PD2P, basato sulla popolarità del dati, già dal 2010 ha ottimizzato l’uso del disco dei Tier2 permettendo la copia di dati interessanti. Circa +90 TB al mese Nessun rischio saturazione, si possono cancellare i dati secondari Utilizzo del disco nei Tier 2 ATLAS Italia 04-2013 04-2012 3000 2500 2000 1500 1000 0 Terabytes 500 NTUP AOD ESD DAOD 28

29 Availability = time_site_is_available/total_time Reliability = time_site_is_available/ (total_time-time_site_is_sched_down) Availability / Reliability 2011-2012 29

30 Multiprocessing e concurrent framework  Le risorse Grid in WLCG sono limitate come agreement a 2GB/core  Il software di ricostruzione di ATLAS fatica a mantenere questo limite  Non è ancora possibile girare la ricostruzione a 64 bit tranne che in nodi speciali dove è disponibile più memoria  Tale situazione certamente peggiora con l’aumento dell’energia e del pileup  Le nuove tecnologie vanno in direzione di CPU many-core, perciò l’approccio corrente non è più sostenibile, nonché l’ultilizzo di eventuali risorse HPC praticamente impossibile  ATLAS prevede di rendere operativo AthenaMP durante LS1 e iniziare lo sviluppo di un nuovo framework concorrente con Full threading e parallelismo a livello di eventi e algoritmi  Collaborazione con IT/OpenLab, PH-SFT, LHCb e CMS  Questo nuovo approccio richiederà anche la migrazione del sistema di Computing distribuito, a partire dalle configurazioni delle code fino alle convenzioni di nomenclatura dei file  Necessaria una chiara strategia per i siti, in fase di sviluppo  Nonostante l’approccio di AthenaMP, per job di ricostruzione ad alto pile up si avrà comunque, secondo le proiezioni correnti, una RSS/core di circa 3GB, mentre per altri tipi di job sarà minore  Ogni sito che girerà la ricostruzione dovrà fornire delle code multicore 30

31 Utilizzo della farm HLT durante LS1  La farm HLT di ATLAS verrà usata come un “sito” Grid opportunistico durante LS1  ~14k core, corrispondenti ad un grande T2 (se non un T1)  Infrastruttura overlay di tipo Cloud basata su OpenStack  CERN IT (Agile), CMS (HLT Farm) e BNL già utilizzano OpenStack 31

32 ATLAS: as study case for GPU sw trigger ATLASThe ATLAS trigger system has to cope with the very demanding conditions of the LHC experiments in terms of rate, latency, and event size. LHC luminosityThe increase in LHC luminosity and in the number of overlapping events poses new challenges to the trigger system, and new solutions have to be developed for the fore coming upgrades (2018-2022) GPUs high level triggerGPUs are an appealing solution to be explored for such experiments, especially for the high level trigger where the time budget is not marginal and one can profit from the highly parallel GPU architecture ATLAS GPUsmuon identification and reconstructionWe intend to study the performance of some of the ATLAS high level trigger algorithms as implements on GPUs, in particular those concerning muon identification and reconstruction. Slide from G. Lamanna / A. Messina 32

33 Altre evoluzioni  Completa migrazione ed utilizzo dell’ATLAS Grid Information System in produzione  Definitivo abbandono dei servizi di IS di Grid in favore di AGIS  Abbandono anche del WMS, finora utilizzato ancora solo per le installazioni del software  Installation System migrato completamente ad AGIS + Panda  Sorgente primaria di informazioni per Panda e DDM  Migrazione ad SL6  Inizio ufficiale delle migrazioni ad SL6 a giugno 2013  Alcune delle release necessitano di una patch per funzionare con l’analisi a causa delle opzioni diverse di compilazione  Possibile soluzione generica trovata di recente, in fase di test  In ogni caso le release più utilizzate sono state già sistemate o comunque funzionanti nativamente  Migrazione ad IPv6  Test dei servizi con IPv6 necessario  SHA-2  Migrazione imminente, necessario un controllo dei servizi  Finalizzazione dell’integrazione di gLexec in Panda 33

34 PRIN: Cloud Computing  Utilizzo del Cloud Computing per servizi o elaborazione dati  Servizi di grid  Workload Management  Servizi interattivi on-demand  Virtualized WN con Panda  Cluster di analisi su Cloud  Data Preservation  Altri tipi di servizi in alta affidabilità  OpenStack + glusterfs + cloud-init  In collaborazione con il gruppo cloud INFN  Stessa infrastruttura di base di CERN Agile Infrastructure  Possibilità di unire più siti grid in una unica infrastruttura  Sperimentazione su Tier2 distribuito, tramite LHCONE  Stato  Facility iniziale, esportabile anche ad altri siti entro fine anno Roma 34

35 PRIN: EventIndex  Studiare la possibilità di semplificare il 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)  EventIndex è l'equivalente del catalogo di una biblioteca  Sostituzione del database in Oracle con storage strutturato (Hadoop)  Divisione delle tre categorie di dati nei Tag odierni:  Identificazione dell'evento e quantità immutabili (lumi block, trigger pattern)  Quantità dipendenti dalla ricostruzione (topologia, particelle, ecc.)  Puntatori ai files con gli eventi (GUID e offset interni)  Utilizzo della tecnologia più appropriata per ogni categoria di dati  Sviluppo (o adattamento) dei servizi esterni  Event counting, picking, skimming, consistency checks  Connessione a ProdSys e DDM per l'upload dei dati e la loro utilizzazione  Stato  Testbed attivo al CERN Genov a 35

36 PRIN: PoD per PBS, gLite-WMS, Panda  Dedicare alcune risorse di calcolo ad una farm da utilizzare per l'analisi con PROOF.  Sviluppare e perfezionare PoD, Proof on Demand, un insieme di tool pensati per interagire con un RMS locale o globale ed avviare i demoni di PROOF.  Test per provare i plugin di PoD per PBS e PanDA (gLite- WMS non più supportato da ATLAS), con i dati acceduti con protocollo XrootD e in futuro anche HTTP:  Test di performance di accesso al disco  Job che legge circa 40% dell’evento  Test di latenza di startup  Stato  Infrastruttura funzionante tramite PanDA  Test di performance e scalabilità in corso  Talk a CHEP 2013 LNF Milano Napoli 36

37 PRIN: LHCONE  Sviluppo di una nuova generazione di reti geografiche di comunicazione dati (overlay L2 network) denominata LHCONE (LHC Open Network Environment)  Configurazione dinamica degli apparati attivi (router o switch multilayer) che costituiscono la rete stessa  Realizzazione di servizi di Bandwidth on Demand (BOD)  Integrazione con il software di esperimento  Stato  Infrastruttura stabile già in produzione al T1 e nei T2  Ottimizzazione e studi su configurazioni dinamiche in corso  Sperimentazione su T2 distribuito in fase di allestimento  Inter-site VLAN (NA-RM)  Failover di servizi core in WAN, con collegamento a 10 Gbps (GARR-X) a bassa latenza Napoli 37

38 GPU: GAP Realtime (FIRB) “Realization of an innovative system for complex calculations and pattern recognition in real time by using commercial graphics processors (GPU). Application in High Energy Physics experiments to select rare events and in medical imaging for CT, PET and NMR.”  FIRB partito ad inizio del 2013  Per ciò che riguarda la comunità HEP, verrà studiato l’utilizzo di trigger hardware di basso livello con latenza ridotta e trigger software di alto livello  Si studieranno I casi di NA62 L0 e l’High Level Muon Trigger di ATLAS come “casi fisici”  Roma coinvolta nello studio del trigger di ATLAS 38

39 Trigger rate 2015 Luminosity expected to increase from 7×10 33 to 2×10 34 corresponding to about a factor 3 in rates Pile up will increase affecting the effective trigger rates Moving to √s=14 TeV cross sections will increase on average by a factor 2.5 Rates would increase by about one order of magnitude. To keep the increase within a factor ~2 (50kHz→100kHz L1 and 450Hz→1kHz EF) selections have to be improved/tightened minimizing the impact on physics. PS: The physics (Higgs, top...) remains the same. 39 Slide from C. Gatti / D. Orestano

40 Trigger menu 2012 vs 2015 Current menu scaled to 10 34 40 Slide from C. Gatti / D. Orestano

41 Trigger menu 2012 vs 2015 Menu at 2×10 34 and 14 TeV 41 Slide from C. Gatti / D. Orestano Increase single e/gamma threshold Increase single and di muon thresholds Increase single and di tau thresholds Increase Jet and MET thresholds

42 Milano: status report Miglioramenti sui tre indicatori principali della qualità del T2 Realiability, data management e produttività. Interventi per migliorare la reliabilty Completa riorganizzazione del file system GPFS con divisione degli storage in storage pools Disaccoppiamento completo di localgroupdisk su h/w dedicato (isolamento dei guasti) Upgrade a StoRM 1.11.2 (EMI-3) Nessun grave incidente hardware dal primo di maggio (contro una media di due al mese nel periodo gennaio 2013 – maggio 2013) Interventi per migliorare la velocità dei trasferimenti Upgrade dei gridftp servers con schede di rete a 10Gb/s Aggiornamento all’ultima versione di gridftp Interventi per migliorare la produttività A seguito della ritrovata stabilità dello storage abbiamo completato la riorganizzazione della sala macchine per l’installazione prompt di tutto il nuovo hardware. 42 Slide from C. Gatti / D. Orestano