Feature celeritas integration

[rahmans1]

BEGINRELEASENOTES

Integrate track offloading to celeritas (https://celeritas-project.github.io/celeritas)

ENDRELEASENOTES

[sethrj]

This indicates a "zero" magnetic field: is there a way to assert that DD4HEP doesn't have a mag field definition so that it's consistent?

[sethrj]

We definitely shouldn't have this. Where were these lines copied from? We should probably use something closer to https://gitlab.cern.ch/bmorgan/athena/-/blob/6072d57711365aa3a58c38ff1134e3f0c569c78b/Simulation/G4Utilities/G4UserActions/src/Celeritas.cxx

[rahmans1]

I think that's where I took it from. Am i looking in the wrong branch? https://gitlab.cern.ch/bmorgan/athena/-/blob/integrate-celeritas/Simulation/G4Utilities/G4UserActions/src/Celeritas.cxx?ref_type=heads&blame=1

[github-actions]

Test Results

   14 files     14 suites   6h 0m 53s ⏱️
  369 tests   369 ✅ 0 💤 0 ❌
2 538 runs  2 538 ✅ 0 💤 0 ❌

Results for commit 4dcf6a3.

♻️ This comment has been updated with latest results.

[andresailer]

Hi @rahmans1

Thank you for the interesting feature. Please format the original PR message with BEGIN/ENDRELEASENOTES.
At the very least this should also include an example / test of the celeritas feature.

[sethrj]

@rahmans1 I was totally unfamiliar with dd4hep's architecture when we started our conversation. Based on what little I now know, it might be possible/better for Celeritas to have an option to build a dd4hep plugin... @andresailer I apologize for the newbie question but if we do want to support custom physics and some sort of translation mechanism that replaces certain components (e.g. sensitive detectors) with GPU-optimized ones, should that live in dd4hep or should we include it in celeritas? Thanks!

[MarkusFrankATcernch]

@rahmans1 @sethrj
I have here a very fundamental notes to add to the discussion:

• Can this celeritas feature reasonably be tested with the default stack
  ie. the software stack which is provided by EP/SFT here at CERN and published as an LCG view like e.g. ROOT?
• I think this is not the case - please correct me if I am wrong. Consequently this code will hardly ever be tested
  and not even compiled during our normal release procedures.
• This would lead to the unfortunate situation that any interface change, even if otherwise transparent,
  either on the celeritas side or dd4hep side would lead to unusable releases.
  This is not a desirable situation at all.
• Given these disadvantages I believe it would be simpler to maintain this component outside of dd4hep.
  After all the manpower available here for the support of DD4hep is very limited. Is there any disadvantage
  in maintaining the celeritas component within the EIC code stack ? I believe not.

For these reasons I would opt for not committing these changes to the dd4hep core.
In the past we have incorporated such features if multiple clients (>2) request it and if this happens
of course the issue can be re-discussed.

I hope you understand this reasoning.

[sethrj]

Hi @MarkusFrankATcernch , thanks for your message. Celeritas, along with another software project AdePT, is being developed in concert with the Geant4 R&D to study particle tracking on GPU. Our goal is to be available to LHC experiment workflows; we've been collaborating with numerous experiments on how best to do this. DD4HEP is one refrain we've heard (especially from next-generation experiments) which is why we're pursuing this course of action.

I'm not as familiar with DD4HEP-based applications as I'd like to be, but it seems like downstream libraries and applications can define plugins that are loaded at runtime to add functionality. Is it possible to use the plugin architecture to add Geant4 interfaces (custom tracking managers, end-of-event actions, begin/end run actions)? If so we could develop the DD4HEP interface externally.

[MarkusFrankATcernch]

Hi @sethrj Thanks for the quick answer!

1. If Celeritas is in concert with the Geant4 R&D, then the Celeritas targets Celeritas::accel and Celeritas::corecel should be present on a LCG view. If not maybe you can arrange with the Geant4 guys to have them present....
   If this is the case I have no objections

2. The plugin architecture allows to implement DD4hep based Geant4 components (custom tracking managers, end-of-event actions, begin/end run actions) anywhere in the client software. The only requirement is that this code should reside in a library which is solely dynamically linked. Anybody can as he wants create his specialized components and load them into DDG4. This was a design criteria when building DDG4.
   From this side there should be no obstacles to develop DDG4 components externally.
   If you face here any technical problem, please ask. There is also in the examples:

• /examples/DDG4 and
• /examples/DDG4_MySensDet
  where user defined components are used.
  I had a quick look in the code: You implement components, but the factory instantiations are missing.
  But this is an implementation detail.