Choose timezone
Your profile timezone:
VecGeom meeting
Description
VecGeom developers meeting
Dial-in numbers: 73020 (CERN), +41227673020
Meeting ID: 662 8850 7117 - Passcode: 40061535
VecGeom developers meeting
Zoom Meeting ID
66288507117
Description
VecGeom developers meeting
Host
Gabriele Cosmo
Alternative host
John Apostolakis
Useful links
Join via phone
Zoom URL
Summary
– Andrei reported on his work to bring the surface-based modeller into the master branch. He tested all Navigators with the build options for Navigation State ( ’table’/stack, index and ‘tuple’), identifying and fixing some issues (zero steps). His ray-tracing benchmarks revealed an overhead in the ‘tuple’ version of 1-10% and in the surface model of about 1%.
– Regarding whether it is ‘feature-complete’: the current versions works for geometries without overlaps. Sphere and tesselated solids are missing.
– In the current branch it does not replace the solid modeller - it remains available as a configuration
– Seth gave an update on G4VG. He, Ben & Seth completed the separation, to make it independent.
– He reported his investigation into an issue reported by Juan. It was due to the different treatment of a reflected hierarchy . A correction will be made.
– This led to a question: the choice of not including reflexions in the G4 Affine Transform means that a copy of logical (and physical) volumes must be created for each level of a hierarchy. Why does G4AffineTransform not allow reflexions ?
– Seth reported on tools he created to investigate the implementation of isotropic safety in the different modellers. His tool, embedded in Celeritas, displays a colormap for the value of safety in a 2-d slice of a setup (showed a setup with one solid. )
Informal ('raw') notes
From the Round-Table
Andrei:
– working to stabilise version of surface-model, to stabilise
– Testing all navigators with all options for NavigationState (in particular NavStateTuple - with different depths/sizes).
– Benchmarking with ray-tracing the tuple approach which shows decrease in performance
– in solid model see 1% - 5-10%
– in surface model it is 1%
– Solved problems doing zero steps
Question: feature complete ? ( missing sphere, tesselated )
– works for geometries which are non-overlapping
– does not interfere with (or replace ) the solid model
– option not to create solid model on GPU
– but remains possible to use the solid model on GPU
NavState options
– In surface model found memory issue with — problem with new on device, solved by putting into a buffer
– improved Cmake, clarifying Flags
– Seeking to make default the NavStateTuple (depth=4) - could not use NavStateIndex (fails for biggest models). For solids models it will remain.
Guilherme Lima
– Is it planned to introduce Surface Model use in Geant4 - ie for CPU ? Answer: NO
– Q/me: What would the motivation be? Robustness checking seems the likeliest.
Seth Q: Running on CPU you could use SIMD operations for planes, etc
Guilherme:
– Working on Tests which failed from Celeritas with (VecGeom) surface model
– Difficulties encountered with small distances returned to Celeritas
Seth:
– Update on G4VG - Ben & Seth completed the separation, to make it independent on
– Issue with mapping reflected volumes
Forcing reflections to create a separate hierarchy increases memory
– Reflection factory could be put aside
– Why does
– Reflected logical volumes get a “_refl” suffix
– Physics volumes do not have a suffice - prevents simple lookup.
Andrei: In AdePT there is a visitor which checks VecGeom against the Geant4 tree hierarchy
Seth:
- revisiting inaccuracies with polycone VECGEOM jira 522 + tool
- AdePT with V4VG working; will get it to work with ATLAS
There are minutes attached to this event.
Show them.
