1 / 16

Advancements in Event Data Definition for LHCb: The Gaudi Object Description Model

The Gaudi Object Description (GOD) model has been crucial for defining event data in the LHCb experiment, addressing challenges like prolonged experiment lifetimes and evolving software paradigms. This model allows easy object definition and generation of multiple implementations from a single source. It utilizes XML for strong syntax while remaining flexible, ensuring coherency across a complex data structure involving various sub-detectors. With its successful application for over two years, GOD demonstrates reliability and adaptability in the face of changing requirements, paving the way for migration to LCG software.

oberon
Télécharger la présentation

Advancements in Event Data Definition for LHCb: The Gaudi Object Description Model

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. 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

  4. 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

  5. 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

  6. 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

  7. Example <class name=“MCParticle” id=“210” location=“MC/Particles” author=“Gloria Corti” desc=“The MC particle kinematics information”> <base name=“KeyedObject&lt;int&gt;”/> <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

  8. 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

  9. Example (cont’d) Stefan Roiser

  10. 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

  11. 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. “&lt;”) Benefits & Drawbacks Stefan Roiser

  12. 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

  13. Reflection Model Item propertyList declaringClass superclasses Class Field Method PropertyList Array type fields returnType Modifiers argumentTypes methods Stefan Roiser

  14. 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

  15. 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

  16. 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

More Related