Summary
Several geometry-path lookups in FairShip are hard-coded and rely on path/name conventions such as /target_vacuum_box_1. In muonShieldOptimization/exitHadronAbsorber.cxx, the kaon/pion splitting setup currently calls nav->cd("/target_vacuum_box_1") and then uses nav->GetCurrentNode() without checking whether navigation succeeded.
This is acceptable to defer from #1063 because the current pull request is focused on kaon/pion splitting behavior, while geometry-path hardening likely needs coordinated treatment across multiple call sites.
Rationale
If a geometry variant does not contain the expected path, the current code may continue with a stale navigator state or dereference a null current node, leading to incorrect sensitive-volume registration or a crash.
The broader issue is not limited to one file: geometry paths appear to be hard-coded in multiple places, so the fix should be approached consistently rather than patched only in one PR.
Affected areas
muonShieldOptimization/exitHadronAbsorber.cxx
exitHadronAbsorber::ConstructGeometry()- sensitive-volume registration for kaon/pion splitting
- Other FairShip geometry/navigation code that assumes hard-coded paths exist
Suggested follow-up work
- Audit geometry navigation calls that use hard-coded paths.
- Add defensive checks around
nav->cd(...) / nav->GetCurrentNode() before dereferencing nodes or volumes.
- Decide whether to standardize path validation helpers or a common utility pattern.
- Keep behavior unchanged when the expected geometry exists; otherwise log a clear warning and skip only the affected optional setup.
Acceptance criteria
- The code no longer dereferences
GetCurrentNode() after a failed nav->cd(...).
- Geometry variants missing an expected path fail gracefully with a warning instead of crashing or using stale navigator state.
- Similar geometry-path assumptions are identified and either fixed or tracked explicitly.
Backlinks
Summary
Several geometry-path lookups in FairShip are hard-coded and rely on path/name conventions such as
/target_vacuum_box_1. InmuonShieldOptimization/exitHadronAbsorber.cxx, the kaon/pion splitting setup currently callsnav->cd("/target_vacuum_box_1")and then usesnav->GetCurrentNode()without checking whether navigation succeeded.This is acceptable to defer from #1063 because the current pull request is focused on kaon/pion splitting behavior, while geometry-path hardening likely needs coordinated treatment across multiple call sites.
Rationale
If a geometry variant does not contain the expected path, the current code may continue with a stale navigator state or dereference a null current node, leading to incorrect sensitive-volume registration or a crash.
The broader issue is not limited to one file: geometry paths appear to be hard-coded in multiple places, so the fix should be approached consistently rather than patched only in one PR.
Affected areas
muonShieldOptimization/exitHadronAbsorber.cxxexitHadronAbsorber::ConstructGeometry()Suggested follow-up work
nav->cd(...)/nav->GetCurrentNode()before dereferencing nodes or volumes.Acceptance criteria
GetCurrentNode()after a failednav->cd(...).Backlinks