Add an interface for invoking the PostStepDoIt action of Geant4 hadronic process#2302
Add an interface for invoking the PostStepDoIt action of Geant4 hadronic process#2302whokion wants to merge 8 commits intoceleritas-project:developfrom
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #2302 +/- ##
===========================================
- Coverage 87.24% 87.17% -0.07%
===========================================
Files 1357 1358 +1
Lines 43225 43267 +42
Branches 13667 13689 +22
===========================================
+ Hits 37711 37719 +8
- Misses 4478 4508 +30
- Partials 1036 1040 +4
🚀 New features to boost your workflow:
|
Test summary 5 930 files 9 549 suites 21m 39s ⏱️ Results for commit 0c8ecac. ♻️ This comment has been updated with latest results. |
There was a problem hiding this comment.
Thanks @whokion , I think it would help me understand the class's role if you could clarify:
- when this is constructed
- what class(es) own it
- whether it's thread-local (presumably so since processes in geant4 are?)
- whether this is meant for future use in geant4 applications or is just for internal use in Celeritas.
This wrapper should be created in the constructor of celeritas transporter (i.e., LocalTransporter).
I believe this wrapper is primarily used internally within Celeritas to return the kinematic changes of primary particle if needed (for example, for electrons) and the secondary particles produced by interactions handled by the associated Geant4 process for onloaded particles. Depending on the particle type, the resulting secondaries may either be passed back to Geant4 tracking or pushed directly back to the offloading buffer if they are EM particles. |
sethrj
left a comment
There was a problem hiding this comment.
Since this is an implementation detail of Celeritas, let's follow celeritas conventions. The class does only one thing, so call it operator() instead of PostStepDoIt.
I think these will probably be owned by aux state data, since we'll probably need additional buffers to send back the track data?
I tested this class with the local transport with a separate buffer (for fake onloaded tracks for now), but it can be instantiated anywhere once a physics list (with corresponding hadronic processes) is constructed. |
sethrj
left a comment
There was a problem hiding this comment.
I hope the next pull request includes a test? Thanks!
|
@sethrj Yes, that is the plan. For a realistic test, we should include (or enable) gamma- and electro-nuclear interactions in the list of processes to be offloaded. Later, we should also add low-energy neutron processes as a complete neutron-elastic interactor and the neutron-inelastic cross section are already available (only need to add the capture cross section below 20 MeV, which is also in my to-do list). That said, adding a unit test using a Geant4 physics list (with the EM extra) could still be worthwhile. |
| G4HadronicProcessType type) | ||
| : particle_(particle) | ||
| { | ||
| auto* proc_store = G4HadronicProcessStore::Instance(); |
There was a problem hiding this comment.
I'd CELER_ASSERT(proc_store) here.
| // Copyright Celeritas contributors: see top-level COPYRIGHT file for details | ||
| // SPDX-License-Identifier: (Apache-2.0 OR MIT) | ||
| //---------------------------------------------------------------------------// | ||
| //! \file celeritas/g4/HadronicInteractor.cc |
There was a problem hiding this comment.
One final thing (an I apologize for the confusion, I 'll add a readme later): the g4 directory is meant for components to be used from Geant4 apps (or other downstream code interacting with Geant4), not for internal celeritas adapters to Geant4 code. Could you move to celeritas/ext?
There was a problem hiding this comment.
No problem - did not catch that. Moved from g4 to ext. Thanks.
This MR adds an interface for invoking the PostStepDoIt action of Geant4 hadronic processes for a given particle definition and hadronic process type. It will be used to sample final states of hadronic processes that are not yet implemented on the GPU. Potential onloaded particles and associated EM extra processes include:
It can also be used for
Test cases will be added once the handling of onloaded particles is in place.