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

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

3. Mar. 24th, 2003Stefan Roiser3 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

4. Mar. 24th, 2003Stefan Roiser4 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)

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

6. Mar. 24th, 2003Stefan Roiser6 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

7. Mar. 24th, 2003Stefan Roiser7 Example <method name=“virtualMass” type=“double” const=“TRUE” desc=“Retrieve virtual mass”/> return m_momentum.m();

8. Mar. 24th, 2003Stefan Roiser8 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 …

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

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

11. Mar. 24th, 2003Stefan Roiser11 Benefits & Drawbacks 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. “<”)

12. Mar. 24th, 2003Stefan Roiser12 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

13. Mar. 24th, 2003Stefan Roiser13 Reflection Model Class Item FieldMethodPropertyList Array Modifiers superclasses declaringClass methods argumentTypes returnType fields type propertyList

14. Mar. 24th, 2003Stefan Roiser14 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

15. Mar. 24th, 2003Stefan Roiser15 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

16. Mar. 24th, 2003Stefan Roiser16 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