VecGeom meeting
VecGeom developers meeting
Dial-in numbers: 73020 (CERN), +41227673020
Meeting ID: 662 8850 7117 - Passcode: 40061535
Brief summary / actions
– Andrei reported improvement of ’safety’ for surface modelling using approximation for far points.
– Severin identified multiple issues with memory ownership & cleaning; many Valgrind reports remain
– Action: Agreed to undertake spring cleaning and design review ‘Sprint’ to address ownership, interface refinement / clarification issues. Cleanup of CUDA interface must preceded this. Idea: use of smart pointers (Severin, Ben.) Potential dates: Week of 12-16 May 2025
– Action: Agreed to create MR now on merging Surface Modeller into master. Need to consolidate flags for choosing implementation of NavigationIndex, simplify configuration choice for Surface modeller and to document / explain any configuration choices it necessitates and other side effects, if any.
– Guilherme reported improvements in Sphere/Orb in solid modeller, most merged in master (some not?) . He will create MR(s) for v1-branch and, if needed, further fix(es) in master.
– Need to clarify completeness of tests for solid modeller and applicability for configurations generated for surface modeller (e.g. whether the extensive testing for the solids can be leveraged to create large scale ‘unit’/sub-module tests for surface modeller.)
Raw notes of discussions
Round table
Andrei
– Safety - improved by approximating for far points
– Add arb4 hyperbolic surfaces - carry lots of state and create divergence on GPUs. Tried triangulation, but this is not
Severin
– Tried running simple example with ValGrind
– Many memory leaks - fixed one large source of such errors Xerces
– Now “only” 200 memory leaks
– Clean up not done
– Specialised placed volume (base class) with no virtual destructor
– Ownership is unclear
– Need hackathon on cleaning the code, after the
– Propose using more smart pointers, to ease the memory management
– Need to improve: avoid need to look at 3 structures to find source etc
Ben
– Happy to help with this
Hackathon
– Design review
– Prior to stamping version 2.0
– Clean up of CUDA interfaces before hand
– Review interfaces
Seth
– Progress on integrating g4vg made Wednesday 15 Jan meetup
– Will provide to-do items for this Wednesday’s meeting
Guilherme L.
– Still working on integrating fix of VecGeom Surface model found interfacing with Celeritas
– Using unit tests in Celeritas to identify issues
– Creating implementation of Orb in VecGeom (was incomplete)
– Particular issue with Orb (full sphere) - flipping variable
– fixed issue found
– Do not understand convention - uncertain (John: where is this clarified? in the code? )
– Andrei: flipping can come from inner-surface, boolean logic.
– Andrei: suggest to compare with Tube
– Second change (proposed fix) for DistanceToIn
– How complete is ray tracing ?
– it checks distance To In (and what else Andrei)
– there is a second (ray tracer) CI test for all solids
– Can SolidTester be used to test the surface-based modeller?
– Andrei: it is not a great equivalence; the condition
Ben
– Forward porting config. Now ATLAS compiles / links with AdePT & Celeritas
– Q (Severin) - Has you update the ‘codimd’ page on how to run Athena with a “full setup”?
– ABC
– Q (Seth) Should it be a living document or historical
– Ben: agree to make it reverse historical to keep latest at top
– Severin: wish to use it also so that G4HepEM as CPU version for AdePT
Topic: merging the Surface Model
– Reasoning: it does not interfere with the existing Solid model
– Open issues: completion
– Proposal: use MR to move development of the surface-model to the master
– Branch version 2 to
– Are there switches to choose to use Surface Model ?
– The surface model requires a particular Touchable
– Ben: code will still after migration. Will need to use opt-in flag to use it ? Yes
– Code is approaching maturity and not interfering
– What needs to be done
– ‘Documentation’: clarify how to use it
– Existing flag to Use_Surface_Model - currently used for external clients (eg for AdePT.)
– Severin: ensure the coherence of flags for NavigationIndex (Guilherme supports) - NavStateTupple vs NavStateIndex
– Andrei: future can make NavStateTupple default, after checking that performance is maintained in Solid modeller. Check if any user code. Check whether NavStateIndex on GPU gives same performance (especially on flattened geometries)