Roadmap for event-by-event and run based flagging of RecHits and CaloTowers in CMSSW

Purpose

We expect ECAL and HCAL to learn more about their subdetectors during the next year, and the need coming up to pass more information from the hit reconstruction upstream. Usually, the information needed to flag a cell in a particular event is only available at the digi level. Thus it can be read at the building step of the RecHit, but given that the digi information is dropped later, it is not possible to use this at e.g. the building of a CaloTower, as currently, it is not possible to read that necessary information from the RecHit itself.

Based on several rounds of discussions, first within the HCAL DPG (Jeremy Mans, Radek Ofierzynski, Mayda Velasco), then with ECAL DPG (Paolo Meridiani, Giovanni Franzoni, Federico Ferri) and CMS coordinators for Reconstruction and Software (Andrea Rizzi, David Lange, Lucia Silvestris), the presented mode of operation was established.

Mechanics

Event-by-event flags (Jeremy Mans, Radek Ofierzynski)

The mechanics needed is to flag a CaloRecHit. Thus, an additional variable is needed which can be filled only during the RecHit reconstruction, i.e. before passing the RecHit collection to the EventSetup. Two options are considered:

1. (working name: "simple") redefine the current 32-bit float time into two variables: a signed 16-bit integer time (in units of 10ps), and an unsigned 16-bit integer flag. In this case, the total size stays at the same level both in memory, uncompressed collections and compressed collections (in fact tests show that it is smaller due to the sparse occupancy of the status flag)
2. (working name: "compat") keep the current definition of the CaloRecHit, but add a 32-bit status flag on top. This definition has been tested to be the most compatible with the CaloRecHit without a flag, i.e. CaloRecHits created without the flag variable were successfully read out using the "compat" implementation. In this case, the total size slightly increases in memory and uncompressed RecHit collections. In compressed RecHits, as long as the occupancy of the flag is small, the size is basically the same: tests show that using a test setup of setting the lowest bit based on a random number with a rate of 1/10/00, and the next-lowest bit at a rate of 1/250, the compressed size is comparable to the CaloTower without flag (differences in size at at the 0.5% level up or down due to ROOT compression features)

Currently, the question on which implementation to use is undecided. The "compat" option is favoured, as it allows for backwards compatibility and enough space for future definitions of additional flag bits, under the conditions that the occupancy of the flag will still be small and thus the compressed size of the RecHit collections will not increase significantly. If this condition cannot be fulfilled, the "small" option has to be taken.

Run based flags (Radek Ofierzynski, Jeff Temple, others)

The mechanism for run-based flags is already available. It consists of marking the cells using the ChannelStatus using the database. The ChannelStatus allows for up to 32 bits of information for one cell, with the granularity of currently one run. The current definition (see HcalDataValidationWorkflow for the bit definitions) includes bits for various problems found for a cell, including whether the channel was on or off, whether it is masked by the L1 trigger, whether it is considered dead, or hot.

Mode of Operation

Hcal RecHit Reconstruction (Efe Yazgan, Jeff Temple, Ted Laird, Jordan Damgov)

The current HcalSimpleReconstructor will be kept (mainly for compatibility reasons as well as for speed dependent applications - HLT, online DQM). An additional class is being written - HcalRecHitReconstructor that will have the same basic functionality, but will additionally call all the algorithms needed for marking of anomalous cells.

First of all, the CaloRecHit reconstruction will look at the ChannelStatus information from the database and will omit for the reconstruction all channels which are off or are considered dead. Next, using the energy and timing information from the digi and the database conditions (pedestals, qie, gains and response corrections), the CaloRecHit is reconstructed. Based on algorithms to identify anomalous cells, the cells in question are marked. No cells apart from the dead and off ones are deleted at this stage.

Currently, it is foreseen to use the following number of bits:

• for HBHE: 1 bit for capid rotation flag, 2 bits for timing check flag, 2 bits for energy based flag, 1 bit for cluster based flag, several bits (3-4 ?) for passing on sum of timeslices in front of the signal for HPD-anomalous cells
• for HF: 1 bit for capid rotation flag, 1 bit for timing check flag, 1 bit for energy based flag (long to short fiber ratio), 1 bit for cluster based flag
• up to four bits for ECAL and HCAL common information: yet to be determined

CaloTower Reconstruction (Anton Anastassov)

The CaloTower reconstruction has to collect all information from the constituting CaloRecHits and provide CaloTowers that sum up this information. For this purpose, it needs to read:

• the ChannelStatus flag for finiding information about the cells that constitute this CaloTower (e.g. if a channel is dead or off, it will not show up in the CaloRecHits, but the information that one of its constituents is considered dead must be available from the CaloTower itself)
• the CaloRecHit flag to summarize that information inside the CaloTower status flag (also see HcalDataValidationWorkflow)

Again, no CaloRecHits or outcoming CaloTowers are deleted at this stage. The information about problems in the CaloTower must be however included in the CaloTower status flag. It is up to the higher level object groups to decide whether to keep or to drop that particular CaloTower.

Timeline

• delivery of mechanism to flag RecHits: done (Jeremy Mans)
• first version of HcalRecHitReconstructor and algorithms to flag anomalous events: 6.11 ? (Jordan Damgov, Ted Laird, Jeff Temple, Efe Yazgan)
• first version of modified CaloTower reconstruction: 10.11 ? = deadline for CMSSW_3_0_0_pre3 (Anton Anastassov)

Q&A

• Do we include summary information from the ChannelStatus in the CaloRecHit flag ? After some discussion, it is proposed not to do this. First of all, dead channels will either not show up at all (be killed by the zero suppression) or be dropped at the RecHit reconstruction level (it does not make sense to treat these two cases differently). The CaloTower reconstruction will need to look into the ChannelStatus anyways to see which of its constituents are dead. Additional requests from the ChannelStatus do not cost additional processing time or memory.
• What is the foreseen occupancy of the status flag of the CaloRecHit ? To be determined soon...

-- RadekOfierzynski - 31 Oct 20Main.08