celeritas-project
Geant4 object model
I'm at the point in ORANGE where I can start converting (some) Geant4 solids to their equivalents. There's a fair bit of implementation complexity in interpreting the geant4 geometry model for some edge cases:
- version-specific accessors
- reflection factory
- boolean "displaced" solids
- expanding parameterised volumes
I'm hesitant to copy g4vg and modify for ORANGE. Ideally there would be an object model layer (a set of simple C++ classes with no functionality aside from storing and validating the geometry parameters and relationships) that:
- can fully represent a Geant4 geometry (up to the capabilities we want to support, e.g. no custom shapes)
- can be created from Geant4 directly
- can be used as input to a VecGeom or ORANGE geometry translator
- can be serialized to and from JSON to make testing and input easier
This wouldn't be a zero-effort task (most of the work would be a bit tedious), but I think it would be very useful for validation and testing. We might be able to auto-generate C++ code using a JSON Schema generator and build a simple schema that would effectively replace GDML. The schema and interface classes, along with the Geant4 reader, could be a completely independent project.
I've floated this idea a couple of times but maybe now that we've actually got the g4vg builder (which contains weirdness particular to Geant4 and weirdness particular to VecGeom, especially with reflection) it's time to think about it again.
@drbenmorgan your birds-eye opinion on this would be appreciated...
I guess one question is whether the existing GDML XSD schema would be sufficient (so there's a bidirectional line from GDML to/from Object model. It wouldn't hurt to also have a GDML JSON schema (and may be easier to bind), but I'm wondering if we should have a proof-of-concept with XML first.
That's a good point, I didn't think about that. Is this GDML schema the one that you mean? (Is it the latest version? 6 years old.) Do you know if GDML is supposed to be a superset of all HEP detector geometries, or simply an alternate representation of the ones Geant4 supports?
The reason I ask is that GDML has many features/abilities that aren't strictly necessary for a Geant4 model:
- Material and element and auxiliary definitions, as an obvious one
- Support for variables and constants that are evaluated during geometry construction (these, for example, aren't supported by the VecGeom custom GDML reader)
- Geant4 uses unique transforms for every solid model whereas GDML uses indirection to allow rotations and positions to be reused
- GDML flattens the volume hierarchy whereas an object model may use shared pointers or a YAML representation may use anchors
Support for variables and constants that are evaluated during geometry construction:
See related https://github.com/root-project/root/issues/13074, https://root-forum.cern.ch/t/tformula-error-while-importing-gdml-file-in-root6/30345/6,
