Add Par04 style Parallel World Placements

[peter-mckeown]

BEGINRELEASENOTES
The PR adds several new (related) features:

1. An alternative means of placing hits in the detector readout via a sensitive detector action in order emulate the Par04 parallel world approach. Practically, this extends the library for use beyond CALICE-style calorimeters
2. The CaloDiT diffusion model, which operates on a Par04 style scoring mesh
3. Addition of support for placement in cylindrical barrel geometries (to allow simulation in the ALLEGRO ECAL)

Note: each of these features will be factored into separate PRs and linked from here

ENDRELEASENOTES

[tmadlener]

I suppose that given

Note: each of these features will be factored into separate PRs and linked from here

You will also remove the geometry (and other) files that do (or should) belong here in that process?

[peter-mckeown]

I suppose that given

Note: each of these features will be factored into separate PRs and linked from here

You will also remove the geometry (and other) files that do (or should) belong here in that process?

Yes, this branch needs a proper cleanup before it is ready.

However, there are some changes to the geometry that are necessary in order to make the trick with the sensitive detector action work. Namely:

• In the xml all layers have to be marked sensitive, to get the sensitive detector call back and enable placement into the sensitives.
• The factory has to assign volume IDs to all volumes placed in the calorimeter, as this is what is used in the sensitive detector call back to proceed for full sim.

So I guess the question is @tmadlener how should we handle this? Clearly, we don't want this in the upstream k4geo. We can (and will) of course document this clearly in the ReadMe instructions for users, but we might also want these kind of fast-sim friendly geometries hosted somewhere e.g. for testing purposes etc?

In general, I am also not a fan of having copies of the geometry. From discussion with Markus: we should be able to inject ‘FastSim’ sensitives for absorbers etc. via the plugin when the sensitive detectors are constructed (see: https://github.com/AIDASoft/DD4hep/blob/4dd1579cbd24b68c565fbcdaf3f7e3ef698aaad8/DDG4/plugins/Geant4DetectorSensitivesConstruction.cpp#L82) .
In any case, as we have immediate use cases of these features, I would be in favour of getting them added now, and trying to remove the need to modify the geometry later as these features should be orthogonal to adding Fast Sim sensitives to the absorbers

[tmadlener]

• In the xml all layers have to be marked sensitive, to get the sensitive detector call back and enable placement into the sensitives.
• The factory has to assign volume IDs to all volumes placed in the calorimeter, as this is what is used in the sensitive detector call back to proceed for full sim.

So I guess the question is @tmadlener how should we handle this? Clearly, we don't want this in the upstream k4geo. We can (and will) of course document this clearly in the ReadMe instructions for users, but we might also want these kind of fast-sim friendly geometries hosted somewhere e.g. for testing purposes etc?

I don't see a reason for this not to live in k4geo even given these constraints. There is precedent for several things in k4geo:

• E.g. having different shapes for a detector depending on a config parameter from xml: Add a switch to use a conical instead of a polyhedral cutout in the GenericCalEndcap constructor k4geo#341
• Having the same detector with slightly different versions of e.g. the magnetic fields
  • see, e.g. the ILD_(s|l)5_v0[2-6] family of models which are pretty much all the same detector

So while it will be somewhat hard to retrofit this into an existing geometry, I don't see a reason to not have what is essentially a copy of a geometry with slight modifications to what is and what isn't sensitive with a different version and some documentation. (This would probably also need some discussion with other people involved in k4geo, though).

How to solve this on a technical level is then probably a slightly different topic, but I think that separates quite nicely from the logistics of where the compact files (and some potentially updated detector constructors) would live in the end.