seal: common core libraries and services for lhc applications chep’03, march 24-28, 2003 la jolla,...

SEAL: Common Core Libraries and Services for LHC Applications

CHEP’03, March 24-28, 2003La Jolla, CaliforniaJ. Generowicz/CERN, M. Marino/LBNL, P. Mato/CERN, L. Moneta/CERN, S. Roiser/CERN, L. Tuura/Northeastern U.

4 March 2003 The SEAL Project P. Mato/CERN 2

Contents

History: The blueprint RTAG Project Aims Current Work Areas:

– Foundation Libraries– Math Libraries– Plugin Management– LCG Dictionary– Scripting services

Project Status Summary


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


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


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

OtherFrameworks

Software Structure


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

mathmathshell

PyGaudi

DatabaseEDG APIGUI

XML

GaudiFramework

PyROOT

RootClasses

PVSS

JPE

JavaClasses


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


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


Domain Coverage

EventGeneration

Core Services

Dictionary

Whiteboard

Foundation and Utility Libraries

DetectorSimulation

Engine

Persistency

StoreMgr

Reconstruction

Algorithms

Geometry Event Model

GridServices

I nteractiveServices

Modeler

GUIAnalysis

EvtGen

Calibration

Scheduler

Fitter

PluginMgr

Monitor

NTuple

Scripting

FileCatalog

ROOT GEANT4 DataGrid Python Qt

Monitor

. . .MySQLFLUKA

EventGeneration

Core Services

Dictionary

Whiteboard


DetectorSimulation

Engine

Persistency

StoreMgr

Reconstruction

Algorithms

Geometry Event Model

GridServices

I nteractiveServices

Modeler

GUIAnalysis

EvtGen

Calibration

Scheduler

Fitter

PluginMgr

Monitor

NTuple

Scripting

FileCatalog

ROOT GEANT4 DataGrid Python Qt

Monitor

. . .MySQLFLUKA

4 March 2003 The SEAL ProjectP. 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


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



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

http://cern.ch/seal/components.html

http://cern.ch/seal/components.html


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


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-InCachePlug-In

Cache

ObjectFactoryObject

FactoryPlug-in

Database Plug-InCache

ModuleModule

ModuleModule

Module ObjectFactory

Attached

Unattached


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


LCG Object Dictionary: Usage

ROOT I/O

LCGDictionaryCINT

DictStreamer

.h

in

out

ROOTCINT

CINT generatedcode Dict generating

code

.adl.xml

ADL/GOD

OtherClients:

(python, GUI, etc.)

LCG

to C

INT

Dic

t gate

way

(2)

(1)

Population

Conversion

Reflection

GCC-XML


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

.h lcgdict.h.h

gccxml .xml filter+

exten

gendictparser

_dict.cpp .somake

selection file

(python script)

#include files


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


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


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

seal: common core libraries and services for lhc applications chep’03, march 24-28, 2003 la jolla,...

Documents