Event Data Definition in LHCb Marco Cattaneo Markus Frank Silvia Miksch Gloria Corti Pere Mato Vila Stefan Roiser

Content The problem Description of the data-model Example Benefits / Drawbacks Current Status / Prospects Migration to LCG software Conclusion Mar. 24th, 2003 Stefan Roiser

The Problem Long lifetime of experiment (> 10 years) Change of programming-paradigms Change of implementation-language Storing large amounts of data Uniform way of handling objects Many sub-detectors define bits of event-model Coherency is an important issue Avoid different look and feel Mar. 24th, 2003 Stefan Roiser

Gaudi Object Description (GOD) The Goals Definition of objects on a higher level Easy language for defining objects Ability to derive several implementations from this source Uniform layout of objects Easily extensible Gaudi Object Description (GOD) Mar. 24th, 2003 Stefan Roiser

Overall View of Gaudi Object Description LHCb rules internal model specific C++ mapping rules C++ Dictionary XSLT java C++ headers dictionary headers html docu java classes doxygen make .so docu dictionary library Mar. 24th, 2003 Stefan Roiser

Object Definition Languages ASCII-text simple to write but parsing difficult IDL interface-language, not flexible enough UML description-language also not flexible XML strong syntax (DTD, XML Schema) still flexible and easily extendable Mar. 24th, 2003 Stefan Roiser

Example <class name=“MCParticle” id=“210” location=“MC/Particles” author=“Gloria Corti” desc=“The MC particle kinematics information”> <base name=“KeyedObject<int>”/> <attribute name=“momentum” type=“HepLorentzVector” init=“0.0,0.0,0.0,0.0” desc=“4-momentum-vector”/> <relation name=“endVertices” type=“MCVertex” mulitplicity=“M” desc=“Vector of Pointers to decay vertices”/> <method name=“virtualMass” type=“double” const=“TRUE” desc=“Retrieve virtual mass”/> <code> return m_momentum.m(); </code> </method> </class> Mar. 24th, 2003 Stefan Roiser

C++ Code Generation Unknown types looked up in database and included Generation of setters/getters for attributes Depending on multiplicity handling of relations only setter/getter for 1-1 relation additional addTo/removeFrom/clear vector for 1-M relations Use of smart-pointers for relations Generation of class-id Documentation in doxygen-style Generation of serializers/deserializers Handling plurals … Mar. 24th, 2003 Stefan Roiser

Example (cont’d) Mar. 24th, 2003 Stefan Roiser

.h-files + dictionary-files Ratio* .h-files + dictionary-files (67.694 loc) 1:12,5 dictionary-files (44.591 loc) 1:8,2 .h-files (23.373 loc) 1:4,3 .h-files (23.373 loc) 1:4,3 xml-source (5.427 loc) *(LHCb Event-model taken from LHCb-project v11r9) Mar. 24th, 2003 Stefan Roiser

Benefits & Drawbacks XML XML Automatic Documentation Strong syntax (DTD) Still flexible for expansion (new elements/attributes) Use of default-values Simple (13 elements, ~4 attributes/element) Automatic Documentation Obeys coding-conventions Object-introspection Other backends possible No change of source-code XML verbose language escape sequences (eg. “<”) Mar. 24th, 2003 Stefan Roiser

Reflection Reflection is the ability to obtain information about an object at runtime and interact with it query it’s layout get/set values invoke functions Can be used in: Persistency Interactive environments Reflection-information of event-objects is generated from the same xml-source Development started in LHCb, now LCG/SEAL Mar. 24th, 2003 Stefan Roiser

Reflection Model Item Class Field Method PropertyList Array Modifiers declaringClass propertyList superclasses Class Field Method PropertyList Array type fields returnType Modifiers argumentTypes methods Mar. 24th, 2003 Stefan Roiser

Current Status and Prospects Gaudi Object Description proved to be usable and stable Used for 24 iterations of the LHCb-event-model (since Dec. 2001) Features seem to be sufficient for doing LHCb physics Adaptations maybe needed for future iterations of the event-model Review of LHCb-event-model scheduled for this autumn Mar. 24th, 2003 Stefan Roiser

Migration to LCG Software LCG/SEAL Dictionary-information-generation will be adapted to work with SEAL-Reflection Python binding to LCG-Reflection LCG/POOL Dictionary and meta-information about objects will be used for persistency No more need for generated serializers/deserializers Mar. 24th, 2003 Stefan Roiser

Conclusions Gaudi Object Description has been in production for more than a year Accepted by physicists Model proved to be useable XML as underlying language was a good choice Model is flexible enough for short-term adaptations Good input/output ratio Even more advantages on long-term Integration with LCG software We don’t expect major difficulties Mar. 24th, 2003 Stefan Roiser