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. 

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 2003 The SEAL Project

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 2003 The SEAL Project

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 2003 The SEAL Project

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 Software Structure Basic Framework Foundation Libraries Simulation Framework Reconstruction Framework Visualization Framework Applications . . . Optional Libraries Other Frameworks 4 March 2003 The SEAL Project

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 XML Gaudi Frame work PyROOT Root Classes PVSS JPE Java 4 March 2003 The SEAL Project

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 2003 The SEAL Project

SEAL Overview SEAL aims to Scope 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 2003 The SEAL Project

Domain Coverage 4 March 2003 The SEAL Project

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 2003 The SEAL Project

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 2003 The SEAL Project

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 http://cern.ch/seal/components.html Current Status Release 0.1.1 provides few classes used by POOL 4 March 2003 The SEAL Project

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 2003 The SEAL Project

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 Plug-in Database Module Attached Unattached 4 March 2003 The SEAL Project

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 2003 The SEAL Project

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

Dictionary generation from header files .xml selection file lcgdict .xml .h gccxml par ser filter + exten gendict _dict.cpp .so make .h .h (python script) .h #include files 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 4 March 2003 The SEAL Project

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 2003 The SEAL Project

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 2003 The SEAL Project

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: http://cern.ch/seal 4 March 2003 The SEAL Project