Celeritas is a new Monte Carlo transport code designed to accelerate scientific discovery in high energy physics by improving detector simulation throughput and energy efficiency using GPUs.
I think for the optical physics (#1351 ) we may need to reconsider volume IDs in ORANGE because they're derived from the SCALE implementation/behavior, where every object is defined as a distinct "media" entry. Right now, volume IDs are somewhat like the "physical"/"placed" volumes in Geant4/VecGeom: copying a shape/solid results in two distinct IDs. However, for optical physics (and indeed for mapping in general to sensitive detectors with the new conversion layer), we may need to assign multiple volume IDs to the same "logical"/"unplaced" volume.
Do we rename VolumeId to VolumeInstanceId?
Do we add a new UniqueVolumeId/ReusableVolumeId/...?
Do we change the name of LocalVolumeId based on whatever new names we come up with? (I'd say not...)
Can logical IDs be arbitrarily set? (I think so?) and if so then we can define a one-to-one mapping with geant4.
Then implementing:
The volume ID in ORANGE is still useful as a "placed" volume and we still will keep everything the same for indexing into the data.
We'll need to add another mapping of instance ID -> unique volume ID to ORANGE
We'll need to expose the physical volumes for Geant4/VecGeom for optical physics
I think for the optical physics (#1351 ) we may need to reconsider volume IDs in ORANGE because they're derived from the SCALE implementation/behavior, where every object is defined as a distinct "media" entry. Right now, volume IDs are somewhat like the "physical"/"placed" volumes in Geant4/VecGeom: copying a shape/solid results in two distinct IDs. However, for optical physics (and indeed for mapping in general to sensitive detectors with the new conversion layer), we may need to assign multiple volume IDs to the same "logical"/"unplaced" volume.
VolumeId
toVolumeInstanceId
?UniqueVolumeId
/ReusableVolumeId
/...?LocalVolumeId
based on whatever new names we come up with? (I'd say not...)Then implementing:
CC @elliottbiondo @mrguilima