1. LCG Kickoff Workshop - Summary Jamie Shiers CERN-IT-DB Agenda, Slides & Video: http://documents.cern.ch/AGE/current/fullAgenda.php?ida=a02298

2. Overview Brief comments on the workshop itself Main focus on applications area Summary of RTAG reports More on RTAG on Persistency Framework CERN-IT-DB role in LCG status of recruitment (Many of these slides borrowed from W/S)

3. Workshop Well attended – plenaries in CERN main auditorium + “sequential” sessions Mainly high-level presentations Most likely to be repeated ~once/year More focussed “hands-on” workshops, possibly sponsored by PEB Some concerns raised: funding; recruitment; organising the real work, …

4. Funding & Timing The LCG Project has two facets management of the resources at CERN  CERN base budget and special pledges  materials and people coordination of the overall activities  important external resources – materials and personnel  regional centres; grid projects  experiment applications effort Phase I – is probably now 2002-2005 extension does not significantly change the integral of the budget  rather smaller prototype, delayed ramp-up  staff later than expected in arriving

5. Funding at CERN – preliminary planning Special funding staff status arrived – 3 contract – 8 in-process – 4-5 Recruitment under way FZK - 8 PPARC – up to 15 EPSRC – up to 5 Italy - ~5 Funded by EU-Datagrid – 7 will evolve as the requirements and priorities are defined mountain molehill

6. Project Resources CERN personnel and materials including those contributed by member and observer states openlab industrial contributions Experiment resources Regional Centres Grid Projects Five components identify establish commitment to the project

7. Permanent Executive Bodies Organised by the PEB Applications area Open weekly applications-wide meeting Monthly decision-making meetings with experiment architects and computing coordinators Hard decisions resolved by Architecture Committee Applications project manager Experiment architects Experiment Computing Coordinators

8. Summary of RTAGs Persistency Framework Software Process Mathlib

9. RTAG on LCG Software Process Management Fons Rademakers (ALICE/chair) Marco Cattaneo (LHCb) Gabriele Cosmo (IT) Simon George (ATLAS) Stephan Wynhoff (CMS)

10. Mandate Define a process for managing LCG software. Specific tasks to include Establish a structure for organising software, for managing versions and coherent subsets for distribution Identify external software packages to be supported Identify recommended tools for use within the project – to include configuration and release management Estimate resources (person-power) needed to run an LCG support activity Guidance – it is assumed that Procedures and tools will be specified Will be used within the project Can be packaged and supported for general use Will evolve with time

11. Assumptions (not in mandate) All LCG software projects will be components of one overall architecture An architect will be appointed to define this architecture. The architect will: Be technically on top of all issues Have a wide experience in the field and a good track record Be able to motivate the people, to explain the issues (like why and why not) Have the final say LCG software projects will define a common software development process that all LCG projects will adhere to: Not highly formalised, but assume that it will be based on one or more of the current best practice methodologies, e.g.: XP, RUP, USDP  Architecture-centric  Iterative and incremental approach to software development ("Release early, release often")  Use-case driven ("Let user feedback drive the development"). We propose tools and procedures to support such a process Which remain valid even if not all assumptions turn out to be true

12. General Recommendations All LCG projects must adopt the same set of tools, standards and procedures Which must be centrally installed, maintained and supported Adopt commonly used open-source or commercial software where available In preference to “Do It Yourself” All recommendations in this report are unanimously supported by the RTAG members

13. “Architecture-centric” Projects should be decomposed into small teams: 2 to 5 people Software should be decomposed into packages A package is an atomic unit With a well defined interface  Establish clear interfaces as soon as possible  Adopt coherent naming conventions  Language bindings: C/C++ mandatory, other languages (e.g. Java, Python, Perl, C#) optional Typically one developer is “owner” of a package with check-in permission Supporting tools: Design: no specific tool, but UML notation Code versioning: CVS (including access policy)  Checkin only by recognized developers, checkout by anybody Build tool: GNUmake Configuration management: CMT, SCRAM Tools for managing platform-dependencies, packaging, exporting: autoconf, CMT, SCRAM/DAR, rpm, GRID install and export tool

14. Other recommendations Release early, release often Let user feedback drive the development Testing and Quality Assurance Different architectures, coding conventions, tools, Q/A tests, …

15. External Software Central installation of third party software In one easy to find place  Not buried deep inside some release structure  Single distribution point with rpm/tar files Multiple versions made available  Let users (or integrators) choose the version they want via appropriate configuration tools  New versions installed on request No need for additional “private” installations by individual projects  Clearly define coherent set of versions used for each release Streamlined installation process  Uniform installation procedures for all external packages in same format as LCG software Build up local expertise on widely used external packages Provide first level support to users Interact with authors to report bugs etc. In particular case of HEP specific libraries:  Local expertise includes active participation in evolution of the software, representing needs of CERN users

16. Roles & Manpower Estimation 1 release manager Rotates between project managers with each major release 1-2 librarians, 1 once project stabilizes This is FTE, should always be more than 1 person 1-2 tool smiths, 1 once project stabilizes Task could be shared with librarian 1 QA support person 1-2 technical writers Some of these tasks scale with size and scope of the LCG project

17. MATHLIB Fred James / Chair Ivan Belyaev / ATLAS Peter Hristov / ALICE Andreas Pfeiffer / IT-API Teddy Todorov / CMS Mark Fischler / Fermilab Leif Lönnblad / Pythia Torre Wenaus / BNL

18. Conclusions Immediate: NAG C versus GSL? Longer term: support issues Non-zero, even for “free” libraries…

19. Persistency Framework One member from each experiment, one from IT/DB, one from ROOT team: Fons Rademakers (Alice) David Malon (ATLAS) Vincenzo Innocente (CMS) Pere Mato (LHCb) Dirk Duellman (IT/DB) Rene Brun (ROOT)

20. SC2 mandate to the RTAG Write the product specification for the Persistency Framework for Physics Applications at LHC Construct a component breakdown for the management of all types of LHC data Identify the responsibilities of Experiment Frameworks, existing products (such as ROOT) and as yet to be developed products Develop requirements/use cases to specify (at least) the metadata /navigation component(s) Estimate resources (manpower) needed to prototype missing components

21. Guidance from the SC2 The RTAG may decide to address all types of data, or may decide to postpone some topics for other RTAGS, once the components have been identified. The RTAG should develop a detailed description at least for the event data management. Issues of schema evolution, dictionary construction and storage, object and data models should be addressed.

22. Interim conclusions RTAG’s highest priority is to provide foundation for a near-term common project reasonably matched to current capabilities of ROOT, with a relational layer above it Optimistic about prospects to accomplish this— significant progress to date Additional work (further RTAGs) in other areas will almost certainly be necessary—we will make recommendations While the limited time available forced [them] to be a bit myopic, believe that LCG should not be too short-sighted—some amount of R&D should be part of the project effort profile

23. Short-term – Apps (PEB) Persistency  subject to RTAG report  Hybrid event store early implementation ~Sep/Oct general release mid 2003 object dictionary service  similar timescale conditions database  may need another RTAG  build on existing work, leveraging hybrid event store

24. IT-DB: Role in LCG 3 main activities: Database Infrastructure for lab  Oracle; Objectivity/DB phase-out being discussed Grid Data Management  Not just EDG WP2 – must deliver working solutions for LCG Physics Data Management Clearly all closely related G / PDM have several components that build on DBI

25. IT-DB-PDM More than LCG: also e.g. Objectivity/DB and replacement services for HARP, COMPASS, … Likely to be (part of) implementation team for DB-related components of new persistency framework CondDB, Object catalogue, Collection meta-data, Production meta-data, … Design of interfaces to components of PF Part of implementation team for some components On-going R&D into Oracle 9i and others

26. IT-DB manpower Currently at target for DBI & GDM 2 EDG fellows, 1 PPARC fellow Still 4-5 under target for PDM Without counting contribution to non-LCG Good candidates in this recruitment round Hope to be at target by summer Believe we have a clear role to play in LCG Technology transfer possibilities are highly motivating for potential candidates