1. 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. 

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. Domain Coverage
4 March 2003
The SEAL Project

10. 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

11. 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

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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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:
4 March 2003
The SEAL Project