1. 25th Nov, 1999 LHCb Event Data Model Pavel Binko, LHCb / CERN 1 LHCb Software Week LHCb Event Data Model Pavel Binko LHCb / CERN

2. 25th Nov, 1999 LHCb Event Data Model Pavel Binko, LHCb / CERN 2 LHCb Software Week Outline  LHCbEvent Overview  LHCbEvent Objects Identification  Retrieving / Finding DataObjects  SmartDataLocator and SmartDataPtr  Navigation between DataObjects  SmartRef and SmartRefVector (both by Markus Frank)  Conclusions

3. 25th Nov, 1999 LHCb Event Data Model Pavel Binko, LHCb / CERN 3 LHCb Software Week 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. 25th Nov, 1999 LHCb Event Data Model Pavel Binko, LHCb / CERN 4 LHCb Software Week 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. 25th Nov, 1999 LHCb Event Data Model Pavel Binko, LHCb / CERN 5 LHCb Software Week “Single Objects” Logical path : “/Event” “/Event/MC” “/Event/Raw” “/Event/Rec” “/Event/Anal” Type : Event MCEvent RawEvent RecEvent AnalEvent

6. 25th Nov, 1999 LHCb Event Data Model Pavel Binko, LHCb / CERN 6 LHCb Software Week “Containers of Objects” 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

7. 25th Nov, 1999 LHCb Event Data Model Pavel Binko, LHCb / CERN 7 LHCb Software Week 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 ); SmartDataPtr checks 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 particles( eventDataService(), “/Event/MC/MCParticles” );

8. 25th Nov, 1999 LHCb Event Data Model Pavel Binko, LHCb / CERN 8 LHCb Software Week Navigation between DataObjects (1) SmartRef and SmartRefVector should 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. 25th Nov, 1999 LHCb Event Data Model Pavel Binko, LHCb / CERN 9 LHCb Software Week Navigation between DataObjects (2) Class definition class MCParticle : public ContainedObject {... private: /// Smart reference to origin vertex SmartRef m_originMCVertex; /// Vector of smart references to decay vertices SmartRefVector 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. 25th Nov, 1999 LHCb Event Data Model Pavel Binko, LHCb / CERN 10 LHCb Software Week 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. 25th Nov, 1999 LHCb Event Data Model Pavel Binko, LHCb / CERN 11 LHCb Software Week 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. 25th Nov, 1999 LHCb Event Data Model Pavel Binko, LHCb / CERN 12 LHCb Software Week 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. 25th Nov, 1999 LHCb Event Data Model Pavel Binko, LHCb / CERN 13 LHCb Software Week 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. 25th Nov, 1999 LHCb Event Data Model Pavel Binko, LHCb / CERN 14 LHCb Software Week 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