Event Data Definition in LHCb Marco Cattaneo Gloria

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

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

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

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

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

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

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

C++ Code Generation • Unknown types looked up in database and included • Generation of setters/getters for attributes • Depending on multiplicity handling of relations n n • • • only setter/getter for 1 -1 relation additional add. To/remove. From/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. 24 th, 2003 Stefan Roiser 8

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

1: 1 2, 5 Ratio* 1: 8, 2 3 4, : 1 xml-source (5. 427 loc) . h-files +. h-files dictionary-files (67. 694 (23. 373 loc) (44. 591 loc) *(LHCb Event-model taken from LHCb-project v 11 r 9) Mar. 24 th, 2003 Stefan Roiser 10

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

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

Reflection Model declaring. Class Item property. List superclasses Class Field Method Property. List Array type fields return. Type Modifiers argument. Types methods Mar. 24 th, 2003 Stefan Roiser 13

Current Status and Prospects • Gaudi Object Description proved to be usable and stable n n 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 n Review of LHCb-event-model scheduled for this autumn Mar. 24 th, 2003 Stefan Roiser 14

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

Conclusions • Gaudi Object Description has been in production for more than a year n n n 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 n We don’t expect major difficulties Mar. 24 th, 2003 Stefan Roiser 16