Support surface-based VecGeom 2.x navigator #1422
Conversation
Several tests hang, to be investigated
sethrj
changed the title
| @@ -11,6 +11,7 @@ | |||
| #include <vector> | |||
| #include <VecGeom/base/Config.h> | |||
| #include <VecGeom/base/Cuda.h> | |||
| #include <VecGeom/base/Version.h> | |||
There was a problem hiding this comment.
I've verified that this header (and the VECGEOM_VERSION macro therein) are present in v1.2.4, which is the minimum vecgeom required by Celeritas.
| globalpoint, globaldir, in_state, out_state, exit_surf, step_limit); | ||
| long hitsurf_id = 0; | ||
| auto step = vgbrep::protonav::BVHSurfNavigator<Precision>::ComputeStepAndNextSurface( | ||
| globalpoint, globaldir, in_state, out_state, hitsurf_id, step_limit); |
There was a problem hiding this comment.
Something here is misbehaving compared to the volume version:
54: /Users/seth/Code/celeritas-temp/test/geocel/vg/Vecgeom.test.cc:164: Failure
54: Value of: next.boundary
54: Actual: true
54: Expected: false
for the calls
auto next = geo.find_next_step(from_cm(100));
EXPECT_SOFT_EQ(100, to_cm(next.distance));
EXPECT_FALSE(next.boundary);
So it's claiming to have a boundary for the next surface, even though it doesn't hit it within the step limit.
Test summary 268 files 404 suites 32s ⏱️ For more details on these failures, see this check. Results for commit b7a5aaa. ♻️ This comment has been updated with latest results. |
|
Without GPU on my laptop (clang 15 debug), on VecGeom ca34e35ea5fc822fcffd3c7c5d117e6bc671ce32 (reldeb), the following tests fail: The simplest failure is just that it seems to report aa boundary when not actually hitting a boundary: Full failure log: |
| 0.52499999999986, 13.023518051922, 6.95, 6.95, 13.023518051922, | ||
| 0.52499999999986, 2.15, 100, 5, 8, 100, 100, 100}; | ||
| 10.3027302206745, 13.023518051922, 6.95, 6.95, 13.023518051922, | ||
| 10.3027302206745, 2.15, 100, 5, 8, 100, 100, 100}; |
There was a problem hiding this comment.
It's great that you've recorded the updated safety values: these are now consistent with the ones returned by Geant4. I suppose we'll have to "edit" these when using the volume-based vecgeom.
| @@ -1034,7 +1120,8 @@ TEST_F(CmseTest, trace) | |||
| static real_type const expected_distances[] = {12.495, 287.505, 530, | |||
| 920}; | |||
| EXPECT_VEC_SOFT_EQ(expected_distances, result.distances); | |||
| static real_type const expected_hw_safety[] = {1, 1, 242, 460}; | |||
| static real_type const expected_hw_safety[] = {6.2475, 47.9499999999998, | |||
| 242, 460}; | |||
There was a problem hiding this comment.
Guess we'll have to change the label on this one 😄 since it now agrees between the two
Adapting Celeritas to use the latest surface-based model from VecGeom 2.x (see #1412).
The main change is to use VecGeom's
vgbrep::protonav::BVHSurfNavigator. Since there are interface differences between this one and the volume-basedBVHNavigator, the code-guardsVECGEOM_USE_SURF, in analogy to AdePT.Alternatively,
VECGEOM_VERSION >= 0x020000could be used instead, as the VecGeom 1.2.x series should always be used for volume-based navigation anyway.There are also distinct interfaces for ABBoxManager (template vs. non-template).
Note: in draft mode, as some tests currently fail. Under investigation.