1. ATLAS Computing Review, 17 March 2000 ATLAS Architecture, Data Model and Infrastructure David R. Quarrie Lawrence Berkeley National Laboratory DRQuarrie@LBL.GOV

2. ATLAS Computing Review, 17 March 2000 David R. Quarrie: ATLAS Architecture 2 Overview l Discuss current activities and approach n Set the context for next section l Provide answers to specific questions from panel n Based upon context established in first section

3. ATLAS Computing Review, 17 March 2000 David R. Quarrie: ATLAS Architecture 3 Architecture Task Force l Established June 1999 çKatsuya Amako (KEK) Laurent Chevalier (Saclay) Andrea Dell’Acqua (CERN) Fabiola Gianotti (CERN) Stephen Haywood (RAL) – Chair Norman McCubbin (RAL) Helge Meinhard (CERN) David Quarrie (LBNL/B A B AR ) RD Schaffer (CERN+LAL) Marjorie Shapiro (LBNL/CDF) Valerio Vercesi (INFN) Torsten Akesson (ATLAS management) l Broad involvement from experiment l Some non-ATLAS members

4. ATLAS Computing Review, 17 March 2000 David R. Quarrie: ATLAS Architecture 4 ATF - Mandate l “… specify the global architecture of ATLAS computing in a way that provides a unified execution framework for data access, reconstruction, simulation, analysis and event display.” l “… a database interface making ATLAS independent of database supplier.” l “Full attention should be given to implementations already carried out in previous and upcoming experiments…” l “A first version of the architecture document should be made available to the collaboration at the latest three months after the launch of the taskforce.” l “The taskforce will have a composition taken from a large base in the collaboration so as to ensure that the architecture will be one with a broad support.”

5. ATLAS Computing Review, 17 March 2000 David R. Quarrie: ATLAS Architecture 5 ATF - Approach l Understand application domains n Next slide l Gather feature lists and requirements from collaboration n Feature list of 245 features n More detailed requirements l Presentations n LHCb, B A B AR, CDF, D0,… l Architectural Design n Two approaches to identify components, responsibilities and relationships çPrior experience çUnified Software Development Process (USDP) based approach n Approaches complementary çNew insight çValidation of experience-based conclusions n Merging incomplete at termination of ATF

6. ATLAS Computing Review, 17 March 2000 David R. Quarrie: ATLAS Architecture 6 ATF – Application Domains l Reconstruction n Production n Reprocessing n Calibrations n Parameter tuning l Event Filtering n Online n Offline l Physics Analysis l Simulation n Generators n Detector Simulation l Online detector monitoring l Testbeams l Algorithm development in all areas

7. ATLAS Computing Review, 17 March 2000 David R. Quarrie: ATLAS Architecture 7 ATF - Core Abstractions l Modules/Algorithms n Computational code l Data Objects n Module Inputs and outputs n Transient objects capable of being converted l Converters n Convert data from one representation to another çTransient/Persistent çTransient/Graphical l Services n Components that provide a support service n E.g. Histogramming, Random Number Generators l Stores n Several, both transient & persistent

8. ATLAS Computing Review, 17 March 2000 David R. Quarrie: ATLAS Architecture 8 ATF - Components

9. ATLAS Computing Review, 17 March 2000 David R. Quarrie: ATLAS Architecture 9 ATF - Major Decisions l Object oriented paradigm n C++ implementation language n See Norman’s talk for Strategic Decisions l Separation of Transient and Persistent Data n Independence from persistent implementation n Converters provide interchange mechanism l Transient Event Store as scratchpad n Owner of intermediate results n Communication between Modules/Algorithms n Source of data that can be made persistent at end of processing

10. ATLAS Computing Review, 17 March 2000 David R. Quarrie: ATLAS Architecture 10 Architecture Team l Detailed Design and Implementation of Framework çKatsuya Amako (KEK) Simulation Coordinator Paolo Calafiura (LBNL) Gilbert Poulard (CERN) David Quarrie (LBNL) Chief Architect David Rousseau (Orsay) Reconstruction Coordinator RD Schaffer (Orsay) Database Co-coordinator Craig Tull (LBNL) l Full team established in February 2000 l Working model is to augment small core team n Reconstruction n Simulation n Database n Visualization n Etc. l First milestone is a prototype in May 2000

11. ATLAS Computing Review, 17 March 2000 David R. Quarrie: ATLAS Architecture 11 A-Team - Approach l Review recommendations of ATF l Understand requirements and timescales of potential user/developer communities l Based upon a review of the requirements and evaluation, propose to base May prototype on GAUDI from LHCb l Continue USDP work in parallel n Expect to gain new insight as well as validation of “fast-track” l Review prototype and further development strategy in June/July 2000 l Merge two development tracks in September 2000 l Longer term schedule discussed later

12. ATLAS Computing Review, 17 March 2000 David R. Quarrie: ATLAS Architecture 12 GAUDI l LHCb Architecture n John Harvey, Pere Mato et al. l Identifies many of the same components as the ATF n Both based on prior experience l Embodies a coherent vision l Clear distinction between abstractions and implementations n Experiment-specific implementations both possible and expected l Designed with support for multiple languages in mind l In third release iteration n Fourth is due in April n Possible to track actual evolution against predicted

13. ATLAS Computing Review, 17 March 2000 David R. Quarrie: ATLAS Architecture 13 GAUDI Evaluation l Comparison of their architecture against our feature list n 245 features n Compare against architecture, not their present implementation çYes (185) No (0) Irrelevant (47) Not understood (11) l Evaluation of their Software Process & Physical Design l Willingness to collaborate l Openness to new ideas n Changes to existing implementation n New services and capabilities l Past history l Bottom Line n GAUDI seems a reasonable basis for prototype n Good possibility of long-term collaboration çSubject to review in July 2000

14. ATLAS Computing Review, 17 March 2000 David R. Quarrie: ATLAS Architecture 14 May Prototype Functionality l Basic functionality n Read Physics TDR data n Chain multiple algorithms together n Integrate with ATLAS visualization n Integration of Isajet Event Generator n Persistent output limited to histograms & ntuples l Basic functionality based upon requirements from users/developers n Target existing PASO users first (Physics TDR data) çTestbeam users in July/August çFast Simulation users in September l Augment basic functionality to test extensibility n Use Event Filter requirements as an example çComplex sequencing of algorithms with branches and filtering n Enhance functionality of an existing service çProperties extended with bounds checking and hierarchical lists

15. ATLAS Computing Review, 17 March 2000 David R. Quarrie: ATLAS Architecture 15 Sequencing Service l Driven by Event Filter domains n Online as well as physics event selection for analysis l Introduce the concept of a Sequencing Service l Multiple concrete implementations n Existing functionality maintained as default çSimple linear sequence n B A B AR /CDF model of multiple paths with filtering çHypothesis-based processing l Each path corresponds to a physics signal n Succeeds if event meets filter criteria n On-demand Sequencing çReconstruction on-demand (c.f. CARF) çAssociate algorithm(s) with converters çDemonstrate capability via a proof-of-principle

16. ATLAS Computing Review, 17 March 2000 David R. Quarrie: ATLAS Architecture 16 Future Releases l September 2000 n Merged USDP/Prototype n Fast Simulation integration n Wrapped FORTRAN n Preliminary Event Data Model n Limited database integration n MC Generators l December 2000 n Targeted towards Trigger TDR n Geant3 full simulation data input n Prototype OO Reconstruction (with some wrapped FORTRAN) l June 2001 n Full Database integration n Geant4 Simulation integration n Physics Analysis Tool integration n History/Bookkeeping

17. ATLAS Computing Review, 17 March 2000 David R. Quarrie: ATLAS Architecture 17 Event Data Model (1) l Architectural n Separation of transient and persistent representations çNecessity of having separate classes and converters l Framework n Base classes çDataObject çProvide common capabilities n Foundation classes çCollections, linear algebra, etc. l STL, CLHEP, etc. n Smart Pointers çProvide associations in the context of automatic conversion çDeferred access to persistent information

18. ATLAS Computing Review, 17 March 2000 David R. Quarrie: ATLAS Architecture 18 Event Data Model (2) l Event related n Simulation (MC Truth, Hits, Digis/Raw) n Reconstruction (Raw, tracks, clusters, etc.) n Physics Analysis (Particle candidates, etc.) l Detector conditions n Geometry n Alignments n Calibrations n Ambient l Bookkeeping/History n Configuration information n E.g Record of adjustable parameters used in reconstruction l Metadata n What data exists, and where is it? n What data has been processed, reprocessed?

19. ATLAS Computing Review, 17 March 2000 David R. Quarrie: ATLAS Architecture 19 Event Data Model Status l Persistent and transient Geant3 simulation data underway n Target date for completion is July 2000 l Evaluating base classes & smart pointers now l Reconstruction entities are being defined n Not yet converted into C++ code n September 2000 preliminary milestone n December 2000 milestone for complete prototype l Detector description underway n Based on XML representation n Generic model exists, with preliminary conversion to Geant4 l Calibrations and alignments not yet embarked on n Baseline is to use time-interval repository provided by IT Division l Bookkeeping/History not yet embarked on n Look at FNAL RCP functionality n June 2001 milestone

20. ATLAS Computing Review, 17 March 2000 David R. Quarrie: ATLAS Architecture 20 Configuration Management l Code repository based on CVS l ATLAS SRT used for Configuration Management n Initially based on B A B AR SRT n Diverged because of different platform support n Significant ATLAS enhancements l Future options being assessed n Working group has been setup n Long term needs of Trigger/DAQ as well as Offline n Ensure get involvement from people using tools as well as developers

21. ATLAS Computing Review, 17 March 2000 David R. Quarrie: ATLAS Architecture 21 Software Releases l Three tier l Nightly Releases – every night n Rapid developer feedback l Version Releases – every two weeks n No physics QA n Basis for most development l Production Releases n Synchronized with major milestones çE.g. Trigger TDR Production n Undergo physics QA

22. ATLAS Computing Review, 17 March 2000 David R. Quarrie: ATLAS Architecture 22 What requirements, current and future, have you identified for your software architecture or ‘framework’? l We’ve identified the application domains n Earlier slide l Extensive compilation of user input from Collaboration n 245 element “feature list” n Ancillary Report to ATF Report n Further requirements being actively sought çAlso incorporating relevant requirements from other experiments l CDF/B A B AR /LHCb l Preliminary set of milestones and functionality based on this input n Including external milestones çE.g Trigger TDR

23. ATLAS Computing Review, 17 March 2000 David R. Quarrie: ATLAS Architecture 23 Distributed and Parallel Processing l Recognize need n Simulation production n Event Filter n Physics Analysis n Support for Regional Centres l Architecture is capable of supporting distributed and parallel processing n Service abstraction maps well onto GRID infrastructure l Build upon prior experience n Physics TDR Production n MONARC participation n B A B AR Online Prompt Reconstruction Farm n HENP Grand Challenge n PPDG Project l Current milestone for some distributed capability n April 2002

24. ATLAS Computing Review, 17 March 2000 David R. Quarrie: ATLAS Architecture 24 Security and Authentication l Tentatively based on a Security Service l Recognize that baseline persistency mechanism (Objectivity/DB) will offer some authentication services by Fall 2000 (based on SLAC/B A B AR work) n Baseline is AFS/Kerberos n Need to understand the implications of that l Obviously an area where we will need to devote more work

25. ATLAS Computing Review, 17 March 2000 David R. Quarrie: ATLAS Architecture 25 Language Evolution l Recognize that this will occur in lifetime of project l Need to support multiple languages n Not just a migration from one to another l Task force looking at Java issues now l LHCb have low level effort looking at Java version of GAUDI n GAUDI abstractions designed to be easily portable to Java l Java reconstruction algorithms? n Several issues need to be addressed çCapability çPerformance çScaling l Strategic Decision n Norman’s talk

26. ATLAS Computing Review, 17 March 2000 David R. Quarrie: ATLAS Architecture 26 Do you believe your requirements for framework, configuration management & data persistency are distinct and different? l Do not believe that our requirements preclude a common approach n We have demonstrated this n E.g. SRT, Objectivity/DB, Framework l Common Abstractions with potentially different implementations are more likely to be successful than common implementations l Data Persistency n ATLAS baseline is Objectivity/DB n Risk assessment çTransient/persistent separation çB A B AR demonstrates that this works l Kanga limited functionality microDST (ROOT) developed in 6 months l Run-time switching between both implementations n Change is a strategic decision çNorman’s talk

27. ATLAS Computing Review, 17 March 2000 David R. Quarrie: ATLAS Architecture 27 Data Model l Discussed earlier l Existing Combined Reconstruction Ntuple n Generated by existing FORTRAN-based ATRECON applications n Accessible from ROOT, JAS, PAW and LHC++ Components using Objy l May prototype n Histograms & ntuples l June 2001 n Integration with Physics Analysis Tools l Track ROOT/JAS/AIDA/Lizard developments

28. ATLAS Computing Review, 17 March 2000 David R. Quarrie: ATLAS Architecture 28 History/Bookkeeping l Discussed earlier l June 2001 n Milestone for deployment

29. ATLAS Computing Review, 17 March 2000 David R. Quarrie: ATLAS Architecture 29 Experiment Input, Validation & Testing l Strong emphasis on user input to requirements n USDP based on use-cases n Architecture Workshops çMarch & April 2000 l Validation n Design Reviews following each major release l Testing n MDC0, MDC1, MDC2 l Physics Workshops n Fabiola’s talk l Early goal is to incorporate Fast Simulation into Framework n Encourage active use across broad user community