Compute Accelerator Forum - Detector Geometry

Virtual (Zoom)





To receive annuoncements and information about this forum please subscribe to


Detector geometry in Opticks

After the images load: use arrow keys to navigate, or enter page number and press return.  The html has the advantage of working links vs the large PDF.

  •  (23 MB)

  • John:

    • What is the difference between the two concepts: a “solid“ and a “structural volume“  

    • Simon: By structural I mean one with an instance transform. Opticks blurs the G4PVPlacement and G4VSolid distinction by merging together some volumes and solids to make compound solids to fit better with what the GPU wants.

    • Is there an assumption that the hierarchy is flat - i.e. one single “world” volume of water containing all others, and its daughters have no contents

    • Simon: No such assumption, but the refactorization ends up with a 2-level heirarchy

    • The Opticks instancer seems to create something like G4 Assemblies - the user gives a set of prepositioned logical volumes and their relative position/orientation. 

    • Simon: Opticks concatenates volumes and solids together to fit the simple geometry model that the GPU needs.

  • Andrei: how much can be automated from G4? 

    • A. It’s all automated, but each new geometry is likely to show new problems. There’s an automated converter from GDML, but need to check the accuracy.

  • Andi: From a reco POV… we use mesh geometries, that should be even easier. We follow particle by particle. Tried brute force ray tracing, but lose parallelism once the intersections are done (10^4 -> 10). Can we build pipelines that avoid the bottlenecks?

    • A. Here just using NVidia OptiX, which is a “black box” and somehow avoids this issue and extracts more performance.

  • Andi: how much batching is needed outside of OptiX?

    • A. A lot - you need to pass in big problems, largest we have tried is 400M (four hundred million) photons! Try to be x10 higher than the number of cores to allow latency hiding to work properly. However, one has to “surrender” to the OptiX model and give up some control, but for Juno it’s worth it.

  • Charles: how could you leverage this for a detector with charged particles and curved paths? Split tracks into curved v. straight?

    • A. Not clear at all - OptiX really only does straight lines!

VecGeom Detector Geometry on GPU

  •  Simon : why cannot you always flatten the hierarchy ? Just combines transforms ?

    • A: because of complexity - e.g. 30M touchables, can’t tesselation.

    • Simon: more thinking about flattening, tesselation obvious very difficult

    • A: can be done, though still may face complexity issues

  • Simon: is instancing (replication) used?

    • A: yes, it’s something to look at

    • John: instancing/flattening pushing in other directions. In Geant4, have replication.

  • Attila: How fragmented does the memory copied to the device become?

    • A: buffers generally keep things co-located, but can still be issues with different tracks in different volumens

  • Attila: How tightly coupled is Vecgeom to CUDA? How much would it be to port to another system

    • A: Tight at the moment, not just decoration but instrumentation of classes. Object model on device is CUDA-specific, e.g. virtual calls at top level. Have had a discussion about what would be needed in design/impl to aid portability. Want to call into library, not compiling headers every time.

  • Marilena: Are there plans to port solids using tesselation/internal vectorization?

    • A: Yes, the navigation improvements should assist with tesselation. Internal vectorization may need optimization depending on organization of hierarchy 

There are minutes attached to this event. Show them.