31 Gennaio 2005 P. Capiluppi - CSN1 - Roma CMS Computing Model Commento: Costruito ad uso e consumo per la definizione delle risorse: LHCC review di Gennaio 2005 Ora e’ un “planning document”!?

LHCC Review of Computing Resources for the LHC experiments David Stickland Jan 2005 Page 2 Baseline and “Average” In the Computing Model we discuss an initial baseline –Best understanding of what we expect to be possible –We will adjust to take account of any faster than expected developments in for example grid middleware functionality –Like all such battle plans, it may not survive unscathed the first engagement with the enemy… We calculate specifications for “Average” centers. –Tier-1 centers will certainly come in a range of actual capacities (available to CMS) Sharing with other experiments… Overall T1 capacity is not a strong function of N Tier1 –Tier-2 centers will also cover a range of perhaps times these average values And will probably be focused to some particular activities (Calibration, Heavy-Ion,..) that will also break this symmetry in reality

3 P. Capiluppi - CSN1 - Roma 31 Gennaio 2005 Definizioni nel Computing Model (CM) di CMS u I Tier-n sono “nominali” o meglio “average/canonical Tiers” u 7 Tier1 (incluso uno speciale al CERN) u 25 Tier2 (di cui uno speciale al CERN: ~2-3 canonical Tier2) u Il primo anno di riferimento e’ il 2008 (anche se e’ un po’ confuso nel Computing Model paper) u Le risorse devono essere implementate nell’anno di “riferimento -1” (valutazione dei costi) “We expect 2007 requirements to be covered by rampup needed for 2008” u Scenario assunto: 

4 P. Capiluppi - CSN1 - Roma 31 Gennaio 2005 CM - Event Data Format (summary) Event size 1.5 MByte Event rate 150 Hz Second RAW data copy at Tier1s RECO Objects 2+1 reproc/year AOD Primary basis of analyses Events “catalog” A total of ~9.5 PByte per year Event Format ContentPurposeEvent sizeEvents / yearData volume (MByte)(PByte) DAQ- RAW Detector data in FED format and the L1 trigger result. Primary record of physics event. Input to online HLT × 10 9 =10 7 seconds × 150Hz – RAWDetector data after on-line formatting, the L1 trigger result, the re-sult of the HLT se-lections (“HLT trigger bits”), potentially some of the higher-level quan-tities calculated during HLT processing. Input to Tier-0 reconstruction. Primary archive of events at CERN × 10 9 =1.5 × 10 9 DAQ events × 1.1 (dataset overlaps) × 2(copies) 5.0 RECOReconstructed objects (tracks, vertices, jets, electrons, muons, etc. including reconstructed hits/clusters) Output of Tier-0 recon-struction and subsequent re- reconstruction passes. Sup-ports re- fitting of tracks, etc × 10 9 =1.5 × 10 9 DAQ events × 1.1 (dataset overlaps) × [2 (copies of 1st pass) + 3 (reprocessings/year)] 2.1 AODReconstructed objects (tracks, vertices, jets, electrons, muons, etc.). Possible small quantities of very localized hit information. Physics analysis × 10 9 =1.5 × 10 9 DAQ events × 1.1 (dataset overlaps) × 4 (versions/year) × 8(copies perTier − 1) 2.6 TAGRun/even number, high- level physics objects, e.g. used to index events. Rapid identifi-cation of events for further study (event directory). 0.01––

LHCC Review of Computing Resources for the LHC experiments David Stickland Jan 2005 Page 5 Event Sizes and Rates Raw Data size is estimated to be 1.5MB for 2x10 33 first full physics run –Real initial event size more like 1.5MB Expect to be in the range from 1 to 2 MB Use 1.5 as central value –Hard to deduce when the event size will fall and how that will be compensated by increasing Luminosity Event Rate is estimated to be 150Hz for 2x10 33 first full physics run –Minimum rate for discovery physics and calibration: 105Hz (DAQ TDR) –Standard Model (jets, hadronic, top,…) +50Hz –LHCC study in 2002 showed that ATLAS/CMS have ~same rates for same thresholds and physics reach

6 P. Capiluppi - CSN1 - Roma 31 Gennaio 2005 CM - Data Model specifications (or location) u I RAW, RECO e AOD sono “divisi” in O(50) “Primary Datasets”  Definiti dalla “trigger matrix” (L1 Trigger + High Level Trigger)  Max 10% overlap u Seconda copia dei RAW data distribuita nei Tier1  Solo il CERN Tier0 ha il full RAW sample u I RECO (leggi DST) sono distribuiti tra i Tier1  Nessun Tier1 li ha tutti, ma ognuno ha lo share che corrisponde ai RAW data residenti  2+1 reprocessing per anno, 2 nei Tier1 e 1 al CERN (LHC downtime) è Incluso il reprocessing dei dati simulati u Gli AOD sono tutti in ogni Tier1  4 versioni per anno, residenti su disco u Gli AOD e i RECO possono essere distribuiti ad ogni Tier2  Meta’ degli AOD “correnti” e/o RECO di max 5 primary datasets u I “non-event” data (calibrazioni, allineamenti, etc.) sono presso i Tier1(2) che ne fanno l’analisi e al CERN Tier0/Tier1/Tier2/Online-farm

7 P. Capiluppi - CSN1 - Roma 31 Gennaio 2005 CM - Data Flow CNAF Bo, Ba, LNL, Pd, Pi, Rm1 MC data Reprocessed data

8 P. Capiluppi - CSN1 - Roma 31 Gennaio 2005 CM - Analysis Model (descrizione-1/2) u Verra’ definito nel C-TDR, ed e’ ancora in evoluzione  L’attivita’ del P-TDR ne dettera’ le caratteristiche iniziali è Perche’ evolvera’ nel tempo comunque…  Grid potra’ dare un “significant change” è Ma si parte in modo tradizionale è Tuttavia ci si aspetta che gli analisti abbiano un accesso ad una User Interface presso i Tier2 e/o i Tier3 è E solo per alcuni users i jobs verranno sottomessi direttamente ai Tier1 (o anche ai Tier2), la maggioranza ci accedera’ via Grid tools u I Dati sono navigabili in un “primary dataset”:  AOD  RECO  RAW (vertical streaming) è La navigazione e’ “protetta” Comunque non e’ sensato navigare dagli AOD ai RECO, ma solo dai RECO ai RAW Infatti chiedere agli AOD oggetti che sono solo nei RECO deve produrre eccezione Infatti chiedere agli AOD oggetti che sono solo nei RECO deve produrre eccezione u L’Event Data Model (framework) e’ in corso di ridefinizione:  Con idee anche di CDF/BaBar

9 P. Capiluppi - CSN1 - Roma 31 Gennaio 2005 CM - Analysis Model (descrizione-2/2) u RAW and RECO analysis  Significant amount of experts analysis è Studi di trigger e detector (incluse calibrazioni, allinementi, fondi) è Base per re-reconstruction (new-RECO) e per creare sub-samples (new- AOD, TAGs, Event directories, etc.) è Dominante all’inizio dell’esperimento (2007 e 2008?)  Principalmente ai Tier1 (ma anche qualche Tier2 specializzato) u RECO and AOD analysis  Significant physics analysis è 90% of all physics analysis can be carried out from AOD data samples è Less than 10% of analyses should have to refer to RECO  Principalmente ai Tier2 (ma anche ai Tier3?) u Event Directories & TAGs analysis  Fanno parte degli “users skims” (o Derived Physics Data) anche se sono prodotti “ufficialmente” quando si creano gli AOD  Sono nei Tier2 e Tier3

10 P. Capiluppi - CSN1 - Roma 31 Gennaio 2005 CM - Data and Tier0 activities u Online Streams (RAW) arrivano in un 20 day input buffer è Archiviati su nastro al Tier0 u Prima ricostruzione  RECO è Archiviati su nastro al Tier0 u RAW+ RECO distribuiti ai Tier1 è 1/NTier1 per ogni Tier1 u AOD distribuiti a tutti i Tier1 u Ri-ricostruzione al Tier0 (LHC downtime)  RECO e AOD distribuiti come sopra  Tempo impiegato ~4 mesi  I restanti 2 mesi per prima ricostruzione completa degli HI data è Possibilmente col contributo di “qualche” Tier2 CMS WAN at CERN = ~2x10 Gbps CMS Tier0 Resources

11 P. Capiluppi - CSN1 - Roma 31 Gennaio 2005 Tier0: dettagli risorse Total T0 Tapes: 3775 TB Raw= 2250 TB HIRaw= 350 TB Calib= 225 TB 1stReco= 375 TB 2ndReco= 375 TB HIReco= 50 TB 1stAOD= 75 TB 2ndAOD= 75 TB Total T0 CPU: 4588 kSI2K (EffSchCPU =85%) Raw1stReco= 3750 kSI2K Calib= 150 kSI2K Raw 2ndReco= included above

12 P. Capiluppi - CSN1 - Roma 31 Gennaio 2005 CM - Data and Tier1 activities u Riceve il suo share di RAW+RECO (custodial data) + tutti gli AOD dal Tier0 è Custodial data anche archiviati su nastro u Riceve i RAW+RECO+AOD di simulazione dai suoi Tier2 è Anche archiviati su nastro è Distribuisce gli AOD simulati a tutti i Tier1 u Manda i RECO+AOD concordati ai suoi Tier2 u Riprocessa la ri-ricostruzione concordata sui suoi RAW/RECO (real+simu)  Manda i new-AOD agli altri Tier1 e ai Tier2, e li riceve dagli altri Tier1 u Partecipa alle “calibrazioni” u Esegue le “large scale Physics Stream skims” dei ~ 10 “Physics Groups” che usano i dati residenti è Il risultato e’ mandato ai Tier2 di competenza per l’analisi è Full pass sui RECO (data+MC) in ~2 giorni  ogni gruppo ogni ~3 settimane u Supporta un “limitato” accesso (interattivo e batch) degli users CMS WAN at each Tier1 = ~10 Gbps CMS Tier1 Resources

13 P. Capiluppi - CSN1 - Roma 31 Gennaio 2005 Tier1: dettagli delle risorse Total T1 Disks: 1121 TB (EffDisk =70%) Raw data= 375 TB 1stReco (curr vers)= 63 TB 2ndReco (old vers)(10% disk)= 13 TB 2ndReco Sim (old vers) (10%)= 17 TB Simul Raw (10% disk)= 43 TB Simul Reco (10% disk)= 9 TB 1stAOD (data & sim)(curr vers)= 150 TB 2ndAOD (old vers) (10% disk)= 30 TB Calib data= 38 TB HIReco(10% disk)= 6 TB Analyses Group space= 43 TB Total T1 CPU: 2128 kSI2K [CPU scheduled + CPU analysis] (EffSchCPU =85%) (EffAnalCPU = 75%) Re Reco Data=510 kSI2K Re Reco Sim=510 kSI2K Calib= 25 kSI2K Analyses skims =672 kSI2K Two days per Group per Tier1 Data I/O Rate ≈ 800 MB/s Local (Sim+Data) Reco Full Sample size (Tapes) / TwoDay

14 P. Capiluppi - CSN1 - Roma 31 Gennaio 2005 CM - Data and Tier2 activities u Serve l’analisi per i “local Groups” è users, 1-3 Gruppi? è “Local” non necessariamente “geografico” è Fornisce il supporto storage per i “local Groups” e le sim private è Ogni user analizza ogni 2 giorni 1/10 degli AOD e 1/10 dei RECO residenti è Sviluppo software locale è Accesso al sistema degli users (User Interface) u Importa i dataset (RECO+AOD+ skims) dai Tier1 è Una volta ogni 3 settimane u Produce ed esporta i dati di simulazione (sim-RAW + RECO + AOD) è Non una responsabilita’ locale: eseguita centralmente via GRID u Puo’ analizzare e produrre le “calibrazioni” è Di interesse/responsabilita’ della comunita’ che accede al Tier2 u Puo’ partecipare alla ricostruzione ed analisi degli HI data CMS WAN at each Tier2 = ~1 Gbps CMS Tier2 Resources

15 P. Capiluppi - CSN1 - Roma 31 Gennaio 2005 CM - Computing Summary CMS Italia: Tier1 (2.9 M€) + 6 Tier2 (0.6x6=3.6 M€) = ~6.5 M€ Annual expenditures CMS Italia: ~1.9 M€/year CERN investment: Tier0 + un Tier1 + un Tier2 Costi valutati con “criteri CERN” e proiettati al 2007

16 P. Capiluppi - CSN1 - Roma 31 Gennaio 2005 CM - Open Issues u Software & Framework  Non incluso nel Computing Model, dovra’ essere nel C-TDR u Tools e servizi nei vari Tiers  Non incluso nel CM, dovra’ esserlo nel C-TDR (e LCG-TDR) u Sviluppo software (e middleware)  Non incluso nel CM, dovra’ esserlo nel C-TDR (e LCG-TDR) u Location and implementation of needed services  Non incluso nel CM, dovra’ esserlo nel C-TDR (e LCG-TDR) + MoUs u Level of services agreement nei Tiers  Non incluso nel CM, dovra’ esserlo nel C-TDR (e LCG-TDR) + MoUs u Personale  Non incluso nel CM, dovra’ esserlo nel C-TDR (e LCG-TDR) + MoUs u Ruolo e consistenza dei “Physics Groups”  Non c’e’ nel modello proposto, non in modo esplicito (C-TDR?) u Flusso dei dati “tra” Tier1 e “tra” Tier2  Non c’e’ nel modello proposto, dovra’ essere nel C-TDR u I “non event data” sono poco trattati … u La distribuzione dei dati potrebbe essere diversa all’inizio (2007/8) u Etc.

17 P. Capiluppi - CSN1 - Roma 31 Gennaio 2005 Commenti e prospettive u Attuali candidati Tier1 per CMS:  {CERN}, USA(FNAL), Italy (CNAF), France (Lyon), Germany (FZK), UK (RAL), Spain (PIC), Taipei, [Russia?]  Percentuale di contributo expected: è {CERN 8%}, USA 36%, Italy 20%, France 7%, Germany 6%, UK 5%, Spain 3%, Taipei 1%, [Russia? 14%] u Attuali candidati Tier2: è USA, ~7 Universities + LHC Physics Center a FNAL è INFN, 6 sezioni (±1) è In2p3, nessuno? è DDF, ? è UK, 3-4 sites? è Es, 2-3 sites? è Others? u Il CM proposto da sempre da CMS Italia non e’ dissimile da questo  Un po’ piu’ importanza ai Tier2/3 e a Grid: attraverso risorse umane localmente interessate e investimento hardware/infrastruttura/organizzazione u Test e verifica del CM: non solo attraverso il P-TDR!  Analisi distribuita (via LCG) per il P-TDR gia’ da ora  Service challenge di LCG entro 2005  Attivita’ di sviluppo software e commitments di lungo periodo

18 P. Capiluppi - CSN1 - Roma 31 Gennaio 2005 Tempi Febbraio, CMSProduzione DST ex-DC04 over Aprile, RRBApprovazione dei MoUs: LCG (fase 2) ed Esperimenti Giugno, CMSSottomissione del C-TDR (e LCG-TDR) a LHCC Giugno?, CMSPrototipo funzionante di analisi DST Autunno?, CSN1Discussione C-TDRs Ottobre, RRBAncora MoUs ? Dicembre, CMSSottomissione del P-TDR Nel frattempo bisogna implementare l’infrastruttura hardware e software per produzione ed analisi (anche attraverso work-around solutions)

19 P. Capiluppi - CSN1 - Roma 31 Gennaio 2005 Schedule

20 P. Capiluppi - CSN1 - Roma 31 Gennaio 2005 Back-up slides

21 P. Capiluppi - CSN1 - Roma 31 Gennaio 2005 Cost Evolution u This plan is for “2008” run (First major run)  Systems must be ramped up in 2006 and 2007  Established centers (CERN, FNAL, Lyon, RAL) could ramp latish  New centers have to ramp manpower as well, not leave to late  Some capacity required in 2007 u Subsequent years  Operations costs (Mostly Tape)  Upgrade/Maintenance è Replace 25% “Units” each year. 3-4 years maximum lifetime of most components è Moores law give steady upgrade During next year, last years data becomes (over the year) mostly staged in rather than on disk Luminosity upgrades need more CPU and more disk

22 P. Capiluppi - CSN1 - Roma 31 Gennaio 2005 Tier2: dettagli delle risorse Total T2 Disks: 218 TB (EffDisk =70%) 1stReco (curr vers) (~5 prim datasets)= 19 TB 1stReco Sim (curr vers) (~5 prim datasets)= 19 TB 1stAOD (data & sim)(curr vers)= 15 TB Analyses Group space= 40 TB Local priv simul data= 60 TB Total T2 CPU: 829 kSI2K [CPU scheduled + CPU analysis] (EffSchCPU =85%) (EffAnalCPU = 75%) Simul= 128 kSI2K Reco Sim= 71 kSI2K HI Reco= 38 kSI2K AOD Analyses= 217 kSI2K Reco Analyses= 217 kSI2K Each Group in Twenty days All local data in Twenty days

23 P. Capiluppi - CSN1 - Roma 31 Gennaio 2005 C-TDR WORKING GROUPS (DRAFT) 1.Physics input: Analysis, Data, Event Models uEvent / Data model, streams, data flow, processing, calibration, … 2.Computing Model: Key Features and Top-Level Architecture uAnalysis model, groups, users … uRole of LCG and Grid components 3.Core Applications Software and Environment uArchitecture of software, software principles and development process uDevelopment environment and tools uApplications framework, persistency, metadata... uToolkits : utilities, plug-ins, mathlibs, graphics, technology choices…... 4.Computing Services and System Operations uTier-0, Tier-1’s, Tier-2’s, local systems, networks u(Multiple) Grids – expectations (e.g. LCG), fallback solutions uData Management and Database Systems uDistributed (job) processing systems uFinal data challenge (“Computing Ready for Real Data”) 5.Project Management and Resources uSize and costs: CPU, disk, tape, network, services, people uProposed computing organisation, plans, milestones uHuman resources and communications uRisk management First order iteration done with “Computing Model” paper Conveners Italiani???? e contributors? Task force italiana!

LHCC Review of Computing Resources for the LHC experiments David Stickland Jan 2005 Page 24 Grids We expect, at least initially, to manage data location by CMS decisions and tools –CMS physicists (services) can determine where to run their jobs Minimize requirements on “Resource Brokers” –CMS with Tier centers manages local file catalogs –Minimize requirements for global file catalogs Except at dataset level “Local” users or “Limited set of users” submitting jobs on a given Tier-2 –Tier-2’s don’t have to publish globally what data they have, or be open to a wide range of CMS physicists –But Simulation production runs there using grid tools For Major Selection and processing (most) physicists use a GRID UI to submit jobs on T1 centers –Maybe from their Institute or Tier-2 –Some local users at Tier-1 using also local batch systems

LHCC Review of Computing Resources for the LHC experiments David Stickland Jan 2005 Page 25 Computing at CERN The Online Computing at CMS Cessy The CMS Tier-0 for primary reconstruction A CMS Tier-1 center –Making use of the Tier-1 archive, but requiring its own drives/stage pools Thus can be cheaper than an offsite Tier-1 CMS Tier-2 Capacity for CERN based analysis –Estimate need equivalent of 2-3 canonical CMS T2 centers at CERN The CMS CERN Tier-1 and Tier-2 centers can share some resources for economy and performance, and provide a very important analysis activity also at CERN –Have not studied this optimization yet

26 P. Capiluppi - CSN1 - Roma 31 Gennaio 2005 Tier3s u Pag 37 (Specifications, overview)  Tier-3 Centres are modest facilities at institutes for local use. Such computing is not generally available for any coordinated CMS use but is valuable for local physicists. We do not attempt at this time to describe the uses or responsibilities of Tier-3 computing. We nevertheless expect that significant, albeit difficult to predict, resources may be available via this route to CMS. u Pag 50 (Tier2 roles)  All Monte Carlo production is carried out at Tier-2 (And Tier-3)

27 P. Capiluppi - CSN1 - Roma 31 Gennaio 2005 Grids u Pag 3 (executive Summary)  …GRID Middleware and Infrastructure must make it possible…via GRID middleware…designs of GRID middleware…in local GRID implementations… u Pag 24 (RAW event rates)  …a figure that could be reasonably accommodated by the computing systems that are currently being planned in the context of the LHC Computing Grid (LCG). u Pag 32 (Analysis Model)  …significant changes if/as we become convinced that new methods of for example Grid-based analysis are ready for full scale deployment. u Pag 35 (Middleware and software)  …we do not describe the Grid middleware nor the applications software in detail in this document. … ”then a full page on Grid”.  Requirement 33: Multiple GRID implementations are assumed to be a fact of life. They must be supported in a way that renders the details largely invisible to CMS physicists.  Requirement 34: The GRID implementations should support the movement of jobs and their execution at sites hosting the data, … u Pag 36 (Specifications of CM, overview)  We expect this ensemble of resources to form the LHC Computing Grid. We use the term LCG to define the full computing available to the LHC (CMS) rather than to describe one specific middleware implementation and/or one specific deployed GRID.We expect to actually operate in a heterogeneous GRID environment but we require the details of local GRID implementations to be largely invisible to CMS physicists (these are described elsewhere, e.g.: LCG-2 Operations [9]; Grid-3 Operations [10]; EGEE [11]; NorduGrid [12]; Open Science Grid [13]. … “then a couple of sentences about Grid in CMS”. u Pag 45 (Tier1 reprocessing)  … we believe this would place unnecessarily high demands on the Grid infrastructure in the early days … u Pag 50 (Tier2 data processing)  …the ability to submit jobs locally directly or via Grid interfaces, and ability to submit (Grid) jobs to run at Tier-1 centres …