Bug/Feature: Condense duplicated particle contributions in calorimeter

[murnanedaniel]

I have a minimalKineticEnergy cut in a truth handler, which disregards particle truth according to some rules. However, the contributions list in the calorimeters still has separate entries for each energy deposit, even when they are from the same particle. Is there any configuration where the contributions can be "collapsed", and duplicate particle contributions aggregated (e.g. energy summed, time averaged or weight-averaged)? The root files are huge when every separate contribution is preserved (20GB per 100 events in my case, and I can see that if I process afterwards to remove duplicates, this reduces by ~70-80%).

For more context:

• I am using a truth handler that is a little more tolerant of retaining details than those currently in main: https://github.com/murnanedaniel/DD4hep/blob/colliderml/DDG4/plugins/Geant4FullTruthParticleHandler.cpp. However, it still uses the identical approach to keep/discard the particle entry
• I am using the not-yet-merged (I believe) branch of Wouter that enables multithreading (https://github.com/wdconinc/DD4hep/tree/ddsim-mt).
• I run the simulation with the attached python file, which consumes a hepmc3 file: ddsim_run.py, and feed it this config: simulation_slurm_config.yaml

I'm not sure if the duplicate hits in the calorimeter are intended or not. But either way, it would be great to be able to switch a flag to condense them down.

[andresailer]

Can we get a reproducer that just uses ddsim and a ddsim steering file?

[murnanedaniel]

@andresailer

Here is a small reproducer:
0. Environment setup: source /cvmfs/sft.cern.ch/lcg/views/setupViews.sh LCG_107 x86_64-el9-gcc13-opt

1. The steering file: steering_file.py . Of course, the OpenDataDetector xml path will need to be updated
2. Run ddsim --steeringFile steering_file.py, to produce a single electron particle gun event
3. Take a look at the EDM4hep calorimeter deposits and contributions collections. Below are some dataframes that show a snapshot of the contents:

You can see that there are 10x the contributions than cells with hits. And the contributions are all from the electron. Is this expected behaviour? If so, it would be nice to make it configurable (if it's not already, of course).

[andresailer]

We can add an option to reduce the number of calo hit contributions. I am not sure what the best way is to reduce the calo hit contributions

• 0 and just store things in the SimCaloHit (I am not sure edm4hep would be OK if we have empty caloHitContributions). I would prefer this because it leaves the least room to misunderstand what happened

All other options can be easily confused with the existing choice for storing one contribution per geant4 step, I think

• 1 per cell
• One per particle per cell
• ...

[murnanedaniel]

What exactly is the proposal for storing things in SimCaloHit? To collapse all truth to each cell, with no particle ID associated with the contribution? Or to then have multiple simcalohits for each cell, which aggregates duplicate particles?

I can see that there could be confusion in the one-per-particle-per-cell approach, in that it reduces the truth record. But the particle truth handler also discards truth, and I suppose the user is expected to communicate this truth handling when they use/share the dataset.

[andresailer]

The proposal does not change the one SimCaloHit per cell.

[murnanedaniel]

Okay, then I don't understand the structure. Could you give an example of how it would look?

[andresailer]

It would look like this (using your image)

But then there are no calo hit contributions.

[murnanedaniel]

Okay, but in that case there would be no way to associate truth particle with calo hit/contribution, right?

My proposal is to maintain that ability to associate truth to calo hits. Just as the particle truth handler removes particle truth, I would propose to add a calo contribution truth handler (or something even more lightweight), which aggregates duplicate calo contribution entries. It would probably only need to take one flag: aggregation_strategy. This could be false (no aggregation, default), mean (aggregate any other quantities in the calo contribution by taking the mean) and maybe energy_weighted (take an energy-weighted mean of other quantities).

This would retain identical structure of calo hits and calo contributions. Calo contributions would be (potentially) much smaller. Calo hits would simply need the begin/end indices updated. I understand it adds an ambiguity, but it doesn't seem more ambiguous than the default truth particle handling of, e.g. Geant4TCUserParticleHandler.

[andresailer]

I see, apologies, I understand now that you are still interested in knowing which original particle is responsible for the (total) energy deposit.

The potential confusion with one per particle per cell is in the PDG(?), time, step position, stepLength fields of the contribution, but users will just need to be aware, or we need to write this into the metadata of the collections.

There is the HitCreationMode flag for sensitive detectors, which can be extended to allow more choices that then have to be implemented in the Geant42XYZOutputModules (or sensitive detectors).

[andresailer]

By the way:

Does murnanedaniel@930f4a9 fix #471 ?

[murnanedaniel]

I see, apologies, I understand now that you are still interested in knowing which original particle is responsible for the (total) energy deposit.

The potential confusion with one per particle per cell is in the PDG(?), time, step position, stepLength fields of the contribution, but users will just need to be aware, or we need to write this into the metadata of the collections.

There is the HitCreationMode flag for sensitive detectors, which can be extended to allow more choices that then have to be implemented in the Geant42XYZOutputModules (or sensitive detectors).

I agree that users should be made clearly aware that some truth is being remove if they turn such a flag on.

As to implementation, I think PDG, time, step position and step length can all equally be handled by the aggregation strategy (even PDG as an int can be "averaged", but of course the duplicate particle will have the same PDG across all contributions).

I'm happy to try to take a look at adding functionality to the Geant42XYZOutputModules, but I wouldn't consider myself an expert. If anyone else knows the workings, then I'm happy to help. If not, then I will attempt it myself.

Basically, we will be writing this functionality ourselves to make the large ColliderML dataset (and to save O(100)TB of duplicate contributions), so if it's useful to others, it makes sense to merge upstream.

[murnanedaniel]

By the way:

Does murnanedaniel@930f4a9 fix #471 ?

Yes, backscatter is handled as a new daughter particle in the Geant4FullTruthParticleHandler that I'm proposing in that branch. If that's a useful fix, it would be very nice to merge it upstream