hep-fcc / k4reccalorimeter

Key4hep Framework Components for the Calorimeter Reconstruction

k4RecCalorimeter - Key4hep Framework Components for Calorimeter Reconstruction

The components are available from the Key4hep stack on machines with CVMFS.

source /cvmfs/sw-nightlies.hsf.org/key4hep/setup.sh

Dependencies

• Gaudi
• ROOT
• EDM4HEP
• k4FWCore
• DD4hep
• k4geo
• ONNXRuntime

Building

After fetching the repository, do

source /cvmfs/sw.hsf.org/key4hep/setup.sh
mkdir build install
cd build
cmake -DCMAKE_INSTALL_PREFIX=install ..
make -j4
make install
cd ..
k4_local_repo  # will update all necessary environment variables

k4reccalorimeter's Issues

Readouts and calo cell position

LAr calo cell positions used to be derived in several step, relying on CreateVolumePositions and two different readouts (see e.g. runCaloSim.py). This feature should be recovered and/or refactored.

Sliding window clustering

There are two problems with the sliding window clustering at the moment:

• in rare occurrences (~%), one hits a segfault. This problem was already there in the fccedm version, stack trace attached to the issue
• the output cluster collection contains many clusters, but all of them have exactly the same information encoded

SlidingWindowStackTrace.txt

CreateCaloCells vs CreateCaloCellsNoise

do we need both
https://github.com/HEP-FCC/k4RecCalorimeter/blob/main/RecCalorimeter/src/components/CreateCaloCells.h
and
https://github.com/HEP-FCC/k4RecCalorimeter/blob/main/RecCalorimeter/src/components/CreateCaloCellsNoise.h
?

They seem to be essentially identical bar
(1) the latter misses cross-talk, added recently by Zhibo
(2) CreateCaloCellsNoise operates on a DataHandleedm4hep::CalorimeterHitCollection
while CreateCaloCells operates on a DataHandleedm4hep::SimCalorimeterHitCollection

If the latter is really needed, then should we add x-talk to it?
Otherwise, can this be put in the dustbin?

Tagging @BrieucF , @faltovaj

Add Test for CorrectCaloClusters Alg

ClusterCell collection lacking cellID encondings, or including cells from heterogeneous subsystems with different CellIDEncodings

The clustered cell collection (https://github.com/HEP-FCC/k4RecCalorimeter/blob/main/RecCalorimeter/src/components/CreateCaloClustersSlidingWindow.cpp#L45C8-L45C23) can potentially hold cells from heterogeneous subsystems which then have inconsistent CellIDEncodings. The issue and further details are extensively described and discussed in #83

In addition, even if only one system is used, the cell collection attached to the cluster does not have the CellIDEncoding. This is indeed potentially a problem (analysis scripts later in the chain may need this information to properly set-up the decoder).

Performance issue related to BitFieldCoder::get

As reported by Nicolas Morange:

All calls related to getting the position of a cell use a DDSegmentation::BitFieldCoder object. The problem is, the function used absolutely everywhere is this one: long64 get(long64 bitfield, const std::string& name) const which does a std::map::find(name) instead of retrieving the index only once and using long64 get(long64 bitfield, size_t idx) const As this behaviour is in many very basic classes in DD4Hep::DDSegmentation and in FCCDetectors::DetSegmentation, it is used in many hot loops, and so this std::map::find amounts to 15% of the total CPU spent in my jobs... A priori the fix is simple, i.e get the indices from the strings in the initialization of the algorithms/tools, and then use the correct function.

.