160 likes | 290 Views
Event Data Definition in LHCb. Gloria Corti Pere Mato Vila Stefan Roiser. Marco Cattaneo Markus Frank Silvia Miksch . Content. The problem Description of the data-model Example Benefits / Drawbacks Current Status / Prospects Migration to LCG software Conclusion. The Problem.
E N D
Event Data Definition in LHCb Gloria Corti Pere Mato Vila Stefan Roiser Marco Cattaneo Markus Frank Silvia Miksch
Content • The problem • Description of the data-model • Example • Benefits / Drawbacks • Current Status / Prospects • Migration to LCG software • Conclusion 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 Stefan Roiser
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) Stefan Roiser
Overall View of Gaudi Object Description 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 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 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> 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 • … Stefan Roiser
Example (cont’d) Stefan Roiser
1:12,5 1:8,2 1:4,3 1:4,3 .h-files + dictionary-files (67.694 loc) .h-files (23.373 loc) .h-files (23.373 loc) dictionary-files (44.591 loc) xml-source (5.427 loc) Ratio* *(LHCb Event-model taken from LHCb-project v11r9) Stefan Roiser
XML 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. “<”) Benefits & Drawbacks 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 Stefan Roiser
Reflection Model Item propertyList declaringClass superclasses Class Field Method PropertyList Array type fields returnType Modifiers argumentTypes methods 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 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 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 Stefan Roiser