Transient detector data model (TDDM) describes the representation of detector data in the memory. Transient detector data representation has to be automatically (without implicitly asked for it) synchronized with contents of the corresponding transient event store. The synchronization is insured by the information in the Event object, by run number, event number, and time stamp. In addition the corresponding alignment has to be applied automatically.
The application code should be shielded from any kind of detector data persistency, and the hierarchy in the persistent store. Dependent on all possible applications, there will be different transient views of the detector data. These views will differ in the element hierarchy and level of details. To fullfil this requirement, there have to be many different logical identification strategies (different navigations) to be able to select the requested detector hierarchy.
Objects of the detector data model structure have to be identifiable. It means, that they have to inherit from the class IdObject, which contains the Identifier.
TDDM has to fullfil the SICB requirements first, then the needs of GEANT4, and other applications.
In the persistent store, there has to be a logical connection between event data and detector data. These logical links will exist between ObjectSets (containers with physical entities, e.g. vertex hits, tracks) and corresponding modules (e.g. tracking stations).
Detector data can be requested implicitly by algorithms or application manager, but the usual request will come from the Event Data Service (if it will be configured to send such requests). Using this procedure, logical links will be replaced by concrete links (C++ pointers).
The TDDM is the basic building unit, used by other LHCb components. It will depend on the identification package. The TDDM uses heavily the Standard Template Library (STL) and Class Library for High Energy Physics (CLHEP).