LHCb Event Data Model

1. LHCb Event Data Model Pavel Binko LHCb / CERN

2. Outline • LHCbEvent Overview • LHCbEvent Objects Identification • Retrieving / Finding DataObjects • SmartDataLocator and SmartDataPtr • Navigation between DataObjects • SmartRef and SmartRefVector (both by Markus Frank) • Conclusions

3. LHCbEvent: Overview • The LHCbEvent data model contains these directories • LHCbEvent / TopLevel • LHCbEvent / MonteCarlo • LHCbEvent / Raw • LHCbEvent / Reconstructed • LHCbEvent / Analysis • LHCbEvent / Utilities • Most of the LHCbEvent classes have to be identifiable • They have to inherit from the class DataObject • Most of the LHCbEvent objects are managed by the transient event store

4. LHCbEvent: Objects Identification • Objects in the transient event store are organised in a tree • There are two kinds of objects • “Single objects” of types e.g. Event, MCEvent, RawEvent, etc. • “Containers of objects” of types e.g. MCParticle, MCVertex, etc. (called MCParticleVector, MCVertexVector, etc.) • Retrieving / finding object is based on logical paths, which is human-readable string • Defined in the files LHCbEvent/TopLevel/EventModel.h and .cpp

5. Logical path : “/Event” “/Event/MC” “/Event/Raw” “/Event/Rec” “/Event/Anal” Type : Event MCEvent RawEvent RecEvent AnalEvent “Single Objects”

6. Logical path : “/Event/MC/MCParticles” “/Event/MC/MCVertices” “/Event/MC/MCTrackerHits” “/Event/MC/MCVertexHits” “/Event/MC/MCVertexPileupHits” “/Event/MC/MCMuonHits” “/Event/MC/MCRichRadiatorHits” “/Event/MC/MCRichPhotodetectorHits” “/Event/MC/MCECalFacePlaneHits” “/Event/MC/MCECalHits” “/Event/MC/MCHCalHits” “/Event/MC/MCPreshowerHits” “/Event/MC/MCRClusters” “/Event/MC/MCPhiClusters” “/Event/Raw/RawInnerTrackerMeas” “/Event/Raw/RawOuterTrackerMeas” “/Event/Anal/AxPartCandidates” Container Type : MCParticleVector MCVertiexVector MCTrackerHitVector MCVertexHitVector MCVertexPileupHitVector MCMuonHitVector MCRichRadiatorHitVector MCRichPhotodetectorHitVector MCECalFacePlaneHitVector MCECalHitVector MCHCalHitVector MCPreshowerHitVector MCRClusterVector MCPhiClusterVector RawInnerTrackerMeasVector RawOutertrackerMeasVector AxPartCandidateVector “Containers of Objects”

7. Retrieving / Finding DataObjects • SmartDataLocator only checks for the presence of the object in the transient event data store • Similar to function sc = findObject( path, pObject ); • SmartDataPtrchecks first the store, but loads it, if not present • Similar to function sc = retrieveObject( path, pObject ); • The advantage is, that users do not need to cast to the real type • As the functions e.g. retrieveObject(...) work with DataObject*& SmartDataPtr<MCParticleVector> particles( eventDataService(), “/Event/MC/MCParticles” );

8. Navigation between DataObjects (1) • SmartRef and SmartRefVectorshould be used while referencing objects in the transient data store. They provide • Safe data access and automatic loading of referenced data on demand • Example: Imagine situation when MC particles are already loaded, but MC vertices aren’t, and an algorithm de-references a variable pointing to the origin vertex • If smart reference is used, MC vertices will be loaded automatically and only after that the variable would be de-referenced • If plain C++ pointer is used instead, the program would crash

9. Navigation between DataObjects (2) • Class definition class MCParticle : public ContainedObject { . . . private:    /// Smart reference to origin vertex SmartRef<MCVertex> m_originMCVertex;    /// Vector of smart references to decay vertices SmartRefVector<MCVertex> m_decayMCVertices; } • Usage does not differ from C++ pointers MCVertex* vtx = (*particles)[n]->originMCVertex(); // MCVertices will MCParticle* part = vtx->motherMCParticle(); // be loaded • Smart references have to be initialised properly (in convertors)

10. Conclusions • LHCbEvent improved by • Addition of new classes • Transition to smart references and vectors of smart references • Formatted ASCII output • Data comparison with FORTRAN output showed an agreement • To do list • Extend functionality of containers by concrete functions and caching information already requested, which would also solve the partitions problem • Extend LHCb event data model in particular by classes from Reconstructed and Analysis event • Improve SICB converters by introducing agreed physics units

11. LHCb Containers • Currently two container types - ObjectVector and ObjectList • Containers are the elementary unit of identification • Have to inherit from class DataObject • It is assumed that algorithms do not identify individual hits or tracks, but always containers of hits, containers of tracks, etc. • Are based on STL containers - they implement the same interface • Provide containment of pointers to the physics object • Requirements on LHCb containers • Physics objects must not be contained in more than one container • Therefore all classes of objects, they are allowed to be contained in LHCb containers, have to inherit from the base class ContainedObject • Memory management of contained objects • Navigability in both directions • From the container to its object, and from the object to its container

12. Contained Objects • Class ContainedObject • Provides the back pointer from the contained objects to its parent container • Provides the exclusive ownership of a physics object by a container • Helps the containers to provide safe memory management • Containers together with the class ContainedObject provide extended data management • They manage the pointers they contain • In addition they manage the objects these pointers point to • No freely flying objects in the stores

13. Safety (1) • Inserting objects into a container • You can use STL-like functions push_back( myObject* pointer ) insert( iterator position ), etc. • All these functions check, if the inserted object is already contained in an other container • You give up the ownership of the inserted object • Never add automatic objects into the containers ! • Do always MCVertex* myVertex = 0; • To acquire back the ownership (e.g. to move an object out from one container into an other) • You have to use the function release( myObject* pObject ), which only removes the pObject from the container

14. Safety (2) • Removing objects from a container • You can use STL-like functions pop_back( ) erase( iterator position ) erase( iterator first, iterator last ), etc. • In all cases you remove the pointer contained in the container and destroy the object this pointer points to • Not recommended, but you can even use delete pObject; • The safety system will check, if the pObject is contained object • If yes, it will remove the pointer from that container • And in all cases it will delete the object • This operation might be quite slow, because the system has to iterate over the whole container to find the pObject