Calo Event Model

This page has been built for the purpose of the LHCb Event Model review that took place in 2005.
It contains a brief description of the Calorimeter Event Model as it was defined at that time.
Although the reviewing procedure only leaded to slight modifications of the Calorimeter Event Model, some information provided on this page are now obsolete. In particular, due the whole repackaging of the persistent classes within the LHCb project, some links on this page might point onto an obsolete location (e.g. the Calorimeter EM classes formerly located in the Event/CaloEvent package are no dispatched within Event/MCEvent, Event/DigiEvent, Event/RecEvent or Event/PhysEvent packages ).
The general structure of the Calorimeter software as presented here is however still valid.
The conclusions of the review process can be found here.
More recent description of the calorimeter software can be found on the dedicated page.


The persistent classes of the Calo Event Model are defined using GOD and are located in the Event/CaloEvent package. Only persistent classes are described in this page. Additional information about the Calorimeter software structure can be found here.

Details about the reconstruction of calorimeter data can also be found in the following two notes : "Particles identification with LHCb Calorimeters" and "Photon and neutral pion reconstruction"

Offline reconstruction

The offline reconstruction of calorimeter data is based on the following data stream :

RawBuffer -> CaloDigits -> CaloClusters -> CaloHypo -> CaloParticle -> Protoparticle

Main classes


CaloDigits are the elementary objects for the reconstruction of calorimeter data. The energy deposit in each cell of each calorimeter subsystem is described with a CaloDigit. The main members of the CaloDigit data are the cell identifier (CaloCellID) and the energy deposit in the cell. This object was defined before the RawBuffer format exists and currently CaloDigits are created from the RawBuffer (see Calo/CaloDAQ package). In this scope, the Event Model Review is a good opportunity to discuss whether the CaloDigit class is still needed (or at least, needed to be a persistent data).


A CaloCluster is a collection of CaloClusterEntries (A CaloClusterEntry contains a reference to a CaloDigit in addition to its status within the cluster and the energy fraction to be assigned to the cluster). The main data members of CaloCluster are a vector of CaloClusterEntry and the CaloPosition (X,Y,E) of the cluster. TheCaloPosition of CaloClusters is independent of any hypothesis about the origin of the cluster.


CaloHypos are hypothesis-dependent calorimeter objects. A CaloCluster could match with several CaloHypos. The CaloHypothesis are listed here. The CaloHypo data contain the (hypothesis-dependent) CaloPosition and CaloMomentum. CaloMomentum essentially contains the Lorentz 4-momentum and the corresponding covariance matrix assuming the particle hypothesis originates from (0,0,0) vertex. As the momentum of the calorimeter particles is currently re-evaluated later, taking into account the position of the assumed production vertex, this data member could be removed. The calorimeters alone can only provides a 3D point (e.g. corresponding to the EM shower barycenter)


CaloParticle is the "final" class of the calorimeter reconstruction chain. Actually this class is only used to built ProtoParticles that could be built directly from CaloHypos. So, CaloParticle class is a good candidate to be removed from Calo Event Model.


Currently the following RelationWeighted objects are used for Calo reconstruction :

(1) TrStoredTrack <-> CaloCluster

Bidirectional relation table with the attribute("weight") equal to chi2 of 2D matching. This table is used to define "neutral" and "charged" clusters. Additionally, it is planned to use this information for global PID for photons.

(2) TrStoredTrack <-> CaloHypo

Bidirectional relation table with the attribute ("weight"). Currently we have 2 such tables:

  • a) The table where the weight is equal to chi2 of 3D-matching for electron hypothesis.
  • b) The table where the weight is equal to chi2 of "Bremstrahlung"-match. This information is an essential ingredient for e Calo-based PID

(3) TrStoredTrack --> float

Unidirectional table, which could be considered as "attaching" the additional attribute/information for the given track. Currently three "primary" tables are used :

  • a) TrStoredTrack ---> energy in Prs : this table used as a source of basic information for e Prs-based ID.
  • b) TrStoredTrack ---> energy in Ecal : this table used as a source of basic information for mu+/mu- Ecal-based ID.
  • c) TrStoredTrack ---> energy in Hcal : this table used as a source of basic information for mu+/mu- Hcal-based ID.

In addition there is a set of "secondary" tables, deriving from the "primary" ones :

  • d) TrStoredTrack ---> minimal value for chi2 of 3D-matching for electron hypothesis. The information is derived from table 2a.
  • e) TrStoredTrack ---> minimal value for chi2 of Bremstrahlung-matching for electron hypothesis. The information is derived from table 2b).

Another set of "secondary" tables, contains the result of the evaluation of different Delta Log-likelihoods in the same format:

  • f) TrStoredTrack ---> DLL(e/b) evaluated from using chi2 of 3D-matching. The information is derived from table 3d, using the comparison with PDF-distributions for signal(e) and background(h/mu) hypotheses.
  • g) TrStoredTrack ---> DLL(e/b) evaluated from chi2 of Bremstrahlung-matching. The information is derived from table 3e, using the comparison with PDF-distributions for signal(e) and background (h/mu) hypotheses.
  • h) TrStoredTrack ---> DLL(e/b) using energy in Preshower detector. The information is derived from table 3a, using the comparison with PDF-distributions for signal(e) and background(h/mu) hypothesis.
  • i) TrStoredTrack ---> DLL(mu/b) using energy in Ecal. The information is derived from table 3b, using the comparison with PDF-distributions for signal(mu+/mu-)and background hypothesis(e/h).
  • j) TrStoredTrack ---> DLL(mu/b) using energy in Hcal. The information is derived from table 3c, using the comparison with PDF-distributions for signal(mu+/mu-) and background hypothesis(e/h).

The "primary" Relation tables (1, 2a-b, 3a-c) are made persistent and stored on Brunel DST output while the "secondary" tables 3d-j , deriving from the primary ones, are not persistent. The information from tables 3f-j is directly propagated to ProtoParticle. Note that, in case of the ProtoParticles were stored on DST, there would be no need to store all these tables.

Additional MC-related classes

MC Relations and Linker

Two LinkerTable and two RelationWeighted objects are defined to associate offline-reconstructed Calorimeter data (CaloDigits and CaloClusters) with MC Particles when running MC simulated events. Currently (in the latest Brunel versions v27r*), the LinkerTable object for CaloDigit->MCParticles relations is stored on DST output (see MCDstContent) while the other Linker or Relation tables derive from it. Note that in the format used for DC04 production this was the RelationWeighted object CaloCluster -> MCParticle that was made persistent (see DSTContent).

MC-association for the calo data reconstructed with the HLT-dedicated Calorimeter Model also exists as discussed in the next section.

Online (HLT) reconstruction

A fast alternative software for the reconstruction of the calorimeter data has recently been implemented for HLT purpose. It consists in few simple algorithms and is based on the simplified data structure :

RawBuffer -> TrgCaloClusters -> TrgCaloparticle

More details about the HLT Calo reconstruction can be found here. The persistent classes of the TrgCalo Event Model are defined using GOD and are located in the Event/TrgEvent package.

Restructuring of both reconstruction models towards an unification (sharing the same event classes) is under discussion (see here).


The TrgCaloClusters are directly built from the RawBuffer. The associated CaloPosition contains hypothesis-dependent corrections unlike the offline CaloClusters. The MC-association for TrgCaloCluster, derived from the persistent CaloDigit->MCParticle Linker described above, exists in the two formats : Linker object and Relation table.


TrgCaloParticles . The 4-momentum computation assume the production vertex to be (0,0,0).

Answering the questions of reviewers

August 25 - Chris

Chris's questions : "I'm starting to begin the review of the Calo event model. Your web page is quite clear on some issues, but one thing it doesn't really discuss are what objects are made persistent ? Looking at the DstContent.opts file in Brunel there are quite a selection of CALO objects in the DST ! It would I think be useful if you could add a little each information to your web page, addressing 1) What objects are currently made persistent 2) Whether any of them could be created on-demand in DaVinci (I recall hearing a discussion on this in a talk some time ago) and 3) If any of them could be removed when the proto-particles are stored on the DST ?"
Answer :

  • CaloDigits are NO MORE persistent objects neither in Boole DIGI outputs(DigiContents) nor in Brunel DST outputs (DstContents,MCDstContents). CaloDigits are created on-demand from RawBufer both in Brunel and, when required, also in DaVinci (see commented line in DaVinciNeutrals.opts).

  • CaloClusters, CaloHypos and CaloParticles ARE DST-persistent objects. The corresponding containers in DstContents output are :

CaloClusters :

    • "/Event/Rec/Calo/EcalClusters#1"
    • "/Event/Rec/Calo/EcalSplitClusters#1"

CaloParticles :

    • "/Event/Rec/Calo/Particles#1"

The CaloParticles class could easily be removed when the ProtoParticle are stored on DST.

CaloHypos :

    • "/Event/Rec/Calo/Photons#1"
    • "/Event/Rec/Calo/Electrons#1"
    • "/Event/Rec/Calo/MergedPi0s#1"
    • "/Event/Rec/Calo/SplitPhotons#1"

Note that the full reconstruction stream :

RawBuffer -> CaloDigits -> CaloClusters -> CaloHypo -> CaloParticle -> Protoparticle

could be run (on demand) in DaVinci and in some sense calorimeter reco. doesn't need any calo-specific DST-persistent classes except RawBuffer. As calorimeter reconstruction is relatively fast this possibility has to be evaluated in term of CPU-penalty versus DST-size.

  • The RelationWeighted objects for Calo PID are also persistent objects. The corresponding DST containers are :
    • "/Event/Rec/Calo/PhotonMatch#1"
    • "/Event/Rec/Calo/ElectronMatch#1"
    • "/Event/Rec/Calo/BremMatch#1"
    • "/Event/Rec/Calo/HcalE#1"
    • "/Event/Rec/Calo/PrsE#1"
    • "/Event/Rec/Calo/EcalE#1"

As ProtoParticle class contains all the relevant informations for Calo-PID, these Relation objects could be removed from persistency stream when ProtoParticles is stored on DST.

  • MC-related classes described above (MCCaloDigits, MCCaloHits, MCCaloSensPlaneHit) are DIGI-persistent in the following containers of Boole output (DigiContents):

    • "/Event/MC/Prs#1"
    • "/Event/MC/Prs/Hits#1"
    • "/Event/MC/Spd#1"
    • "/Event/MC/Spd/Hits#1"
    • "/Event/MC/Ecal#1"
    • "/Event/MC/Ecal/Hits#1"
    • "/Event/MC/Hcal#1"
    • "/Event/MC/Hcal/Hits#1"

    • "/Event/MC/Prs/Digits#1"
    • "/Event/MC/Spd/Digits#1"
    • "/Event/MC/Ecal/Digits#1"
    • "/Event/MC/Hcal/Digits#1"

  • The MC-Linkers objects are DST-persistent in the following container of Brunel output (MCDSTContents):

    • "/Event/Link/Raw/Ecal/Digits

  • The HLT-related classes (TrgCaloCluters, TrgCaloParticles) have recently been "CLID'ed" but are not made persistent as HLT is usually run in DaVinci !

ChrisRJones - 05 Sep 2005

Some followup or new questions :-


Am I correct in saying that an average DaVinci user only requires the Calo information cached in the ProtoParticle during a normal job ?

Answer (Vanya 06/09): Currently in DaVinci CaloHypo objects are used explicitely for creation of Particles from the ProtoParticles for neutral particles, and for bremmstrahlung energy correction for electrons. For the second case, the explicit access to CaloHypo is trivial to eliminate (one needs to store in ProtoParticle not only chi2 for bremmstrahlung match, but also the energy of the best bremstrahlung photon). For the first case the elimination of CaloHypo is also possible, but one needs to(re)-reconstruct Calo. Here one can think about few scenarios. According to our computing model, one should clearly distinguish "stripping" jobs wich uses as input data "reduced" DTS, and the user analysis jobs on stripped DTS. Since stripping jobs runs over few ten of different channel, for them the CPU-penalty for RE-reconstruction of Calo is totally negligible, and one can skip ALL Calorimeter information form rDST tape. But for "stripped"DST tape, where the tape size is not an issue anymore one can store CaloHypo objects in the tape.

In which case, would it be a valid suggestion to say once the ProtoParticles are produced in Brunel and stored on the dst's, to then have no Calo data objects or relation tables at all stored on the dst files ? Seeing as the Calo is fast in the odd occasions users do require these objects to do specialist studies (Does this ever happen ?) then they could be created "on-demand" in their DaVinci job.

I which case, would it also be fair to suggest that most of the Calo objects become essentially "internal" objects to the Calo processing, and not of interest outside the calo code ? Transient only classes have potentially much more flexibility for future development, as you avoid problems with writting out and reading in different versions.

Would it be possible to then move some of these Calo Objects out of the CaloEvent package itself, in order to streamline this package to contain only the persistent/common data objects. (An example of where this is already done is in the RICH, where the Rich/RichEvent package contains only such objects. The reconstruction does use a selection of RichRecEvent objects during its processing, but these are not defined in the Rich Event Model package, but a separate library RichRecBase).

--- Answer (OD): It depends of your definition of a 'normal/specialist studies'. I think your statement is true for CaloDigits that is not really necessary at DaVinci level. However, I currently use CaloHypo and CaloCluster within 'normal' DaVinci job, e.g when I need MC association for photons or pi0's (a MC<->CaloDigit.or.Cluster relation table is obviously to be persistent). On real data, your statement is probably true.

CRJ: I think we need to distinguish between normal and specialist runs. Normal runs will represent by far the largest fraction of events and thus should be made minimal in terms of dst size. This is true both for MC and real data. It would be wrong to include data only needed for a small fraction of events for special studies. Particularly given how easy it is to add things to the dst (or digi/sim files) for private development productions. An example of this is the RICH where I add additional MC information to the sim files in Gauss. Currently I only do this in private productions, but I see no reason why for example we could have developer productions that include all information for all subdetectors for this sort of thing.

Anyway, most of the DaVinci jobs do not require neutrals at all (I think the tagging with electrons does not require anything else than ProtoParticle in basic configuration), and we could imagine to fully (or partially) rebuilt on-demand the calo stream when neutral particle are involved in the DaVinci study.

Removing most Calo-specific objects from DST has some advantages (DST size, backward compatibility) and the CPU penalty for a DaVinci Calo reconstruction has to be evaluated. We could also imagine an intermediate approach, in between 'removing all' and 'removing none' of the calo-specific classes. This has to be further discussed.

CRJ: Yes, there are lots of options. The structure of the CALO model and the speed of the reconstruction is very flexible in this regard. It should be easy to add/remove data from the dsts or reproduce on demand in DaVinci etc.

Status Flags

Many of your event model classes have "status" flags, but what are the meaning of these flags ? There is nothing in the doxygen to explain this. Maybe some documented enums could be used instead ? Are they simple internal flags for the reconstruction ?

Answer (OD): The CaloDigit status is a 32bits word that indicates what is the status of the digit inside a cluster (e.g. the status indicates wether the digit is the seed of the cluster, used for cluster energy calculation, shared between several clusters ...). You can find the bit definition of the status word there

CRJ: Thanks - I guess then it is really just a question of documentation. Looking at these status flags in the CaloObjects it was not possible to get to this page. Some sort of links should be set up so it is obvious how to get to these from the objects that use them.


Similar to the status flags - What are the "parameters" in the CaloPosition class ?

Answer (OD): The CaloPosition parameters contain the (E,x,y,z) value associated to Calo objects as Cluster or Hypo.

CRJ: Again, this is far from clear by just looking at the doxygen documentation...


I strongly agree with the idea to merge the online and offline models, as is currently being done by the tracking (and already the case in the RICH). Particularly if some of the Calo classes are no longer needed (CaloDigit/CaloParticle) since then the models seem even closer.

What is the status of this ? Is there a timescale for achieving it ?

Answer (OD): The status is quite modest : we just had few discussions with Vanya and Cristina. We expect to work on this issue, starting somewhere in october ...

CRJ: Thanks. I think this issue should be given high priority in this review


Do you see any major problem moving from the CLHEP vector/linear algebra classes to the ROOT ones ?

Answer (OD): I'm really not an expert for that question!
CRJ: I was't talking about general issues, but CALO specific ones - I.e. given how you use these classes in the event model or reconstruction code, do you expect any problems - eventually someone from the CALO group will have to look into the issues around this once the decision is made to move over... You can find some first doxygen for the new classes here Also, look at Juan's twiki page GeomNewMathLibs.

Answer (Vanya 06/09): As for CLHEP/ROOT I see no problems, with proper definition of "typedef" everything should be more or less transparent. And the code fragments, which has been coded through "typedef" are immune against this interchange


Which, if any, of your event classes are used for the visualisation of your event data in Panoramix ?

Answer (Vanya 06/09): _As for visuazation, the initial code (developed 2-3-4? Years ago) allow to visualise CaloDigits/CaloClusters and CaloHypos. But as I know nobody is using thie code.. I guess somebody should try to resurrect it..._

-- Main.odescham - 15 Jul 2005
Edit | Attach | Watch | Print version | History: r15 < r14 < r13 < r12 < r11 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r15 - 2007-05-24 - OlivierDeschampsSecondary
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LHCb All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback