SEAL: Common Core Libraries and Services for LHC Applications CHEP’03, March 24-28, 2003 La Jolla, California J. Generowicz/CERN, M. Marino/LBNL, P. Mato/CERN, L. Moneta/CERN, S. Roiser/CERN, L. Tuura/Northeastern U.

4 March 2003The SEAL Project P. Mato/CERN2 Contents  History: The blueprint RTAG  Project Aims  Current Work Areas: –Foundation Libraries –Math Libraries –Plugin Management –LCG Dictionary –Scripting services  Project Status  Summary

4 March 2003The SEAL Project P. Mato/CERN3 The Blueprint RTAG  The mandate of the RTAG was to define the architectural ‘blueprint’ for LCG applications: –Define the main architectural domains (‘collaborating frameworks’) of LHC experiments and identify their principal components. –Define the architectural relationships between these ‘frameworks’ and components, including Grid aspects, identify the main requirements for their inter-communication, and suggest possible first implementations. –Identify the high-level milestones for each domain and provide a first estimate of the effort needed. –Derive a set of requirements for the LCG  Any piece of software developed by any LCG common project must conform to a coherent overall architectural vision  The end goal is the integration of LCG and non-LCG software to build coherent applications  The blueprint will be established in terms of a set of requirements, suggested approaches and guidelines, and recommendations

4 March 2003The SEAL Project P. Mato/CERN4 Architecture requirements  Long lifetime: technology evolution  Languages: C++ today; allow multi-language and evolution  Distributed applications  TGV and airplane work  Modularity of components  Component communication via public interfaces  Interchangeability of implementations  Integration into coherent framework  Design for end-user’s convenience more than the developer’s  Re-use existing implementations  Software quality at least as good as any LHC experiment  Meet performance, quality requirements of trigger/DAQ software  Platforms  Trigger/DAQ environment

4 March 2003The SEAL Project P. Mato/CERN5 Architectural Elements  Interface model –Abstract interfaces, versioning, guidelines,…  Component model –Communication via public interfaces (no hidden channels) –Plug-ins (run-time loading) –Live-time management (reference counting) –Configuration  Design guidelines –Dependencies –Exception handling –Interface to external components Basic Framework Foundation Libraries Simulation Framework Reconstruction Framework Visualization Framework Applications... Optional Libraries Other Frameworks Software Structure

4 March 2003The SEAL Project P. Mato/CERN6 Architectural Elements (2)  Object Dictionary –The ability to query a class about its internal structure (Introspection) –Essential for data browsing, rapid prototyping, persistency, etc.  Object Whiteboard –Uniform access to application-defined objects (equivalent to the Gaudi transient stores)  Component Bus –Integration of components providing a wide variety of functionality GUI Python math shell PyGaudi Database EDG API GUI XML Gaudi Frame work PyROOT Root Classes PVSS JPE Java Classes

4 March 2003The SEAL Project P. Mato/CERN7 The Blueprint RTAG Recommendations  RTAG establishes a user/provider relationship between LCG software an ROOT –LGC software will not be based on ROOT, it will use ROOT where adequate  Start common project on core tools and services  SEAL Project  Start common project on physics interfaces  Start RTAG on analysis, including distributed aspects  Tool/technology recommendations –CLHEP, CINT, Python, Qt, AIDA, …  Develop a clear process for adopting third party software

4 March 2003The SEAL Project P. Mato/CERN8 SEAL Overview  SEAL aims to –Provide the software infrastructure, basic frameworks, libraries and tools that are common among the LHC experiments –Select, integrate, develop and support foundation and utility class libraries –Develop a coherent set of basic framework services to facilitate the integration of LCG and non - LCG software  Scope –Foundation Class Libraries »Basic types (STL, Boost, CLHEP, …), utility libraries, system isolation libraries, domain specific foundation libraries –Basic Framework Services »Component model, reflection, plugin management, incident (event) management, distributed computing, grid, scripting

4 March 2003The SEAL Project P. Mato/CERN9 Domain Coverage

4 March 2003The SEAL Project P. Mato/CERN10 Assumptions, constraints, risks  Do not re-invent wheel –Most of the core software to be delivered by SEAL exists - more or less - in experiments’ core software »We will re-use as much as possible existing software »Most of the work will be in re- packaging existing pieces of software  If wheel squeaks… –Develop / adapt / generalize in order to achieve the necessary level of coherency and conformance to the architectural vision already established  Adopt a Seal –In order to use SEAL, projects will need to replace their own software elements with SEAL functionally equivalent ones. This will certainly imply some period of instability for the experiment applications

4 March 2003The SEAL Project P. Mato/CERN11 Work Packages  Foundation and Utility Libraries  Math Libraries  Component Model and Plug-in Manager  LCG Object Dictionary  Basic Framework Services  Scripting Services  Grid Services  Education and Documentation

4 March 2003The SEAL Project P. Mato/CERN12 Foundation and Utility Libraries  Low level, fairly independent class libraries complementary to Boost and STL from existing code in classLib (CMS), Gaudi (ATLAS/LHCb), HepUtilities, etc.  Broad range of unrelated functionalities which makes sense to re-use across LCG projects  Developed or adapted as the need arises –Inventory of existing utility classes »  Current Status –Release provides few classes used by POOL

4 March 2003The SEAL Project P. Mato/CERN13 Math Libraries  The Math Libraries project (F. James et al.) is becoming a work package of the SEAL project. Started to define the work plan  Provides experiments with math and statistics libraries to be used in analysis, reconstruction, simulation.  Current activities –Evaluation of GSL (India). To be finished by 15 April 2003 –Implementation of Minuit in C++ –CLHEP participation and support –GSL support

4 March 2003The SEAL Project P. Mato/CERN14 Component Model and Plug-in Manager  In the LCG architecture a plug-in is a logical module that encapsulates the concrete implementation of a given service.  The plug-in manager is responsible for loading, activating, deactivating and unloading plug-ins at run-time  Current activities –Develop/adapt a basic set of mechanisms and base classes to manage creation of objects (factories), lifetime, multiplicity and scope, component communication and interface discovery –Ideas and code re-use from Iguana (CMS) and Gaudi (LHCb/ATLAS). Plug-In Cache Object Factory Object Factory Plug-in Database Plug-In Cache Module Object Factory Attached Unattached

4 March 2003The SEAL Project P. Mato/CERN15 LCG Object Dictionary  Areas of work –Reflection Packages (Reflection, ReflectionBuilder) –Dictionary generation from header files using gcc_xml technology (DictionaryGenerator) –Python-binding to Reflection –Gateway CINT -> LCG Dictionary –Generation of.h files and dictionary from higher level language (e.g. XML)  Concentrating in Reflection packages and dictionary generation from header files –Main goal: Full support of C++ without any class instrumentation –Parsing XML file from gccxml and producing “usable” dictionaries

4 March 2003The SEAL Project P. Mato/CERN16 LCG Object Dictionary: Usage ROOT I/O LCG Dictionary CINT Dict Streamer.h in out ROOTCINT CINT generated code Dict generating code.adl.xml ADL/GOD Other Clients: (python, GUI, etc.) LCG to CINTDict gateway (2) (1) Population Conversion Reflection GCC-XML

4 March 2003The SEAL Project P. Mato/CERN17  Uses gccxml (0.4.1) to parse header-files (extension to gcc- compiler), generates intermediate XML file with dictionary information  XML file parsed by a python script which generates dictionary building C++ code (for “selected classes”)  Compiled to shared library and loaded at run-time to create dictionary in memory.xml Dictionary generation from header files.h lcgdict.h gccxml.xml filter + exten gendict par ser _dict.cpp.so make selection file (python script) #include files

4 March 2003The SEAL Project P. Mato/CERN18 Framework Basic Services  Develop a set of basic services to be used by LCG applications for message reporting, exception handling, component configuration, “event” management, etc. –Starting with the most basic ones –Extended later with potentially common services identified in other projects  Framework level base classes and interfaces –Provide a number of base classes to facilitate the task of building applications  Develop object “whiteboard” –Access to application-defined objects (event data objects, for example) will be supported throughout the system. –Study interaction with persistency, visualization and other services

4 March 2003The SEAL Project P. Mato/CERN19 Scripting Services  The Blueprint RTAG proposes interoperability between ROOTCINT and Python –Possibility to access application-defined objects from both of these environments –Python bindings for ROOT (PyROOT)  Python bindings to standard services and utility libraries developed in SEAL  Current activities –Evaluate existing Python binding options: SWIG, Boost.Python, SIP, raw Python API, etc. –Started with PyROOT (C++) and PyGSL (C) as examples in the evaluation process. They are candidates to become “real” products

4 March 2003The SEAL Project P. Mato/CERN20 Project Status and Summary  The SEAL project started last November –To provide the software infrastructure, basic frameworks, libraries and tools that are common among the LCG projects and LHC experiments  First pre-release (v0.1) end of February –Various packages: SealKernel, Reflection, ReflectionBuilder, DictionaryGenerator –Used by POOL release v0.4  Second pre-release (v0.2) expected in 1 week –Evolution of the existing packages and additional ones: SealSystem, PyROOT, …  First complete release (v1.0) scheduled end of June –Sufficient functionality to be used by other LCG projects and LHC experiment’s Frameworks  For more information: