ePIC integration

[sethrj]

This is the primary tracking issue for integrating Celeritas with the simulation workflow for the ePIC collaboration. The primary Celeritas contact points are the "assignees" to the right.

Core capabilities

• EM physics

Specific requirements

• Tessellated geometry tracking (see Support tesselated surfaces #1400)

External collaborators

@wdconinc 😉

[wdconinc]

Tessellated volumes not required. Only outer hadronic calorimeter uses them and most benefits of celeritas will be in our electromagnetic calorimeters.

[wdconinc]

What's the next step here?

[sethrj]

@wdconinc There's no immediate action required here, but if you have a representative GDML you can send us (email, slack, upload here), it'll make it easier for us to characterize/test initial capabilities. One thing for example we can do is extract into a standalone test file the forward hadronic calorimeter, which you said is the largest computing time sink.

We're too oversubscribed at the moment to try any integration work ourselves, but perhaps we could talk at CHEP (assuming you'll be there) about the possibility of a student project looking at initial integration/performance studies? Then any issues that arise we will track here.

[wdconinc]

A current selection of live-update gdml files is at https://eic.github.io/epic/artifacts, with in particular (deep links may become invalid on months timescales):

• https://eic.github.io/epic//artifacts/gdml/epic_calorimeters.gdml: all calorimeters, including tessellated barrel hadronic calorimeter,
• https://eic.github.io/epic//artifacts/gdml/epic_bhcal.gdml: the barrel hadronic calorimeter with tessellated volumes,
• https://eic.github.io/epic//artifacts/gdml/epic_forward_detectors.gdml: the forward detectors, including the forward hadronic calorimeter (and exclusing the barrel hadronic calorimeter),
• https://eic.github.io/epic//artifacts/gdml/epic_imaging_only.gdml: the barrel electromagnetic calorimeter (without the barrel hadronic calorimeter).

Note that these are automatically produced as a byproduct of our geant4 simulations, not the input to it, and therefore they are in some cases a more expansive representation than when using the replicated or parametrized volumes in geant4 directory (since those are not supported in geant4).

[sethrj]

That's great, thanks so much for the links!