Feedback from LHC Experiments on

using CLHEP

Lorenzo Moneta

CLHEP workshop

28 January 2003

2

Introduction CLHEP is used from the LHC experiments

since quite some time– Generally satisfied with the library

SEAL will adopt CLHEP as part of the utility library– SEAL will collect experiment requirements – Could act as consultant/mediator for the LHC

experiments– participate in CLHEP discussions and

contribute to decisions

3

Re-packaging Experiments like the idea of splitting CLHEP

in various libraries with minimal dependency. – Possible candidate libraries are current packages

Would like to have a clear dependency hierarchy between packages: – Having a core CLHEP at lower level – A set of higher level packages depending on the

core Different packages evolution

– more frequent releases/versions for higher level packages ?

4

Consistency Scope of CLHEP should be better defined

– It should not be a common repository for all common HEP code

– Clear definitions for what should be inside Avoid duplications More coherent Interfaces

– Try to avoid duplications of methods (e.g. X() , px() ) – method names should not be misleading

Any Fortran inheritance should be removed– Access to Matrix indices starts from zero !

Use of namespaces to avoid pollution of global space

5

Documentation User Documentation needs to be improved

– Very inhomogeneous documentation Same packages are well documented (e.g. Zoom)

Document better CLHEP releases and evolution – Bug fixes, releases notes, etc: – Non backward compatible changes should be clear

announced– A release change log may not be sufficient for users

More frequent releases

6

Matrix Package Poor performance for matrices operations

– in particular for symmetric matrices Numerical instabilities obtained in matrix inversions

– Have an automatic renormalization procedure ? Should redesign for a common matrix interface

– hide behind different implementations (GSL, Boost)– replace implementation library according to needs

Establish a collaboration with MathLib project Small issues:

– Matrix dependency on Random – No constructor taking Hep3Vectors as arguments

7

Vector Package is widely used by experiments Interface is too bloated

– Many getter methods for same operation: get a component of a Lorentz Vector :

getX(), x() , px(), (0) , [1] Would like to be templated on the contained type

precision (float, double) Doubts on having public setter methods

setX( ), setTheta( ) Vector template on dimension ?

8

Vector and Geometry Prefer a much simpler interface

– A set of adaptor classes according to the needs (geometry or kinematics)

Some preference expressed also for an abstract vector interface– User could redefine objects with kinematical

properties as LorentzVectors. A new design of Vector/Geometry classes is

proposed by CMS – see Teddy Teodorov presentation

9

HepMC and HepPDT HepMC is used by the LHC experiments

– Often not the official CLHEP version– Used a version downloaded from Matt Dobson page– Not consistent evolution between the various versions

HepPDT– Would like it as a separate package to be used not

only in simulation programs useful in analysis jobs for getting true particle

information Would like a connection established with LCG

generator project for future evolution

10

Random Package Very much used by experiments

– Used often through Gean4 Establish connection with Mathlib LCG project

and GSL Comments received on

– Possibility to save and restore generator seeds to generic streams

– Problems switching random engine on Windows RandomObjects package is not used

11

Other Packages Units

– Used also a lot by experiments– Should always be used by CLHEP too

Why an M_PI is defined separately ? – Need to be as a separate package ?

Evaluator : – Used for describing geometry – no comments received

GenericFunctions– Not really used yet – Should use GSL by default

12

Other Issues Persistency of CLHEP classes

– CLHEP data classes (e.g. vectors and matrices) are used directly in the experiment event model

need to be persistified

– LCG will need to provide dictionary for those classes

Streams using CLHEP data classes for debugging purpose

13

Summary General satisfaction with CLHEP Would like improvements on the numerical part

(Linear Algebra) Try to profit more from existing mathematical

libraries becoming standards– GSL – Boost numerical libraries

Improve in documentation and infrastructure– Increase release frequency– More user interactions– Better support

14

Proposal from LCG LCG could help CLHEP providing the needed

infrastructure: – Web portal (Savannah) too the project– Use of tools for producing code documentation– bug tracking and reporting tools– Testing tools and quality assurance– CVS repository– Release management and build tools (librarian)

Help could be provided also in maintaining code– Support for the compiler (at lease for those supported

by LCG)

15

LCG Proposal LCG could provide also expertise in some areas:

– Math libraries (numerics)– Persistency

No intention to take full control of CLHEP– Author remains authors and will continue to

lead developments establish tagging policy schedule releases

Hope everybody will profit from a closer collaboration