fix: surface Geant4 init failures and repair production-cut regions#83
fix: surface Geant4 init failures and repair production-cut regions#83olantwin wants to merge 4 commits into
Conversation
The geant4_crossing patterns Target and HadronAbsorber date from the v0.1.0 geometry and match no logical volume in the GeoModel geometry, whose volumes are named /SHiP/target/... and /SHiP/muon_shield/magn_absorb. Since the no-match check became fatal, every workflow using geant4_crossing dies during master initialisation; before that, the regions were silently empty and no production cuts were applied. Point the patterns at the current target complex and magnetised hadron absorber.
A throw from init_master left init_flag_ unset, so the next simulate call — phlex keeps feeding in-flight events after one throws — re-ran the initialisation. The first G4MTRunManager is a leaked singleton, so the retry died on Geant4's fatal Run0031 "G4RunManager constructed twice" abort, hiding the original error entirely (e.g. the production-cut region config error was never printed). Capture the exception in the call_once body, log it, and rethrow it on every simulate call: phlex drains in-flight events, reports the real error, and exits instead of aborting.
A production run prints nothing between master initialisation and the end of the job, so a healthy multi-hour simulation is indistinguishable from a stall. Log the completed-event count and average rate every progress_interval events (default 100, 0 disables).
The destructor cleaned the geometry stores on the geometry thread only after a fully successful master init. A failed init typically fails after detector construction has registered the volumes, so the stores stayed populated and their static destructors segfaulted at process exit on the main thread (the #68 pattern), turning a clean configuration-error exit into a crash. Key the cleanup on the run manager's existence instead: from that point the geometry thread owns the thread-local split-class data and the stores may hold volumes.
|
Warning Review limit reached
Next review available in: 17 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Physics Metrics Comparison1 configuration(s) have differences
Configurations with Differences
|
|
@THanae This might fix the issues you are seeing. |
Great, thanks! |
2 participants
Summary
fixed_target_mt.jsonnet(and every workflow usinggeant4_crossing) died ~30 s in with Geant4's fatalRun0031: G4RunManager constructed twiceabort — with the actual error hidden. Root cause chain:Target/HadronAbsorberdate from v0.1.0 and match no logical volume in the GeoModel geometry (/SHiP/target/...,/SHiP/muon_shield/magn_absorb). Before a0116a0 they silently produced empty regions (no cuts applied); since a0116a0 they throw duringrm->Initialize().init_flag_unset, so the next in-flightsimulate()call re-raninit_master, constructed a secondG4MTRunManagernext to the leaked first one, and died on the fatal G4 abort — masking the configuration error entirely.initialized_unset, so their static destructors segfaulted at process exit (the Segmentation violation at teardown when running with GeoModel geometry #68 pattern).Changes
geant4_crossingregions at/SHiP/targetand/SHiP/muon_shield/magn_absorb(the magnetised hadron absorber).simulate()call, so phlex reports the real error and exits instead of aborting.progress_intervalevents (default 100, 0 disables) — a healthy multi-hour run was previously indistinguishable from a stall.Verification
fixed_target_mt.jsonnet: no moreRun0031; init completes, 4 workers simulate at ~20 events/s with progress lines.fixed_target_st.jsonnet: runs to completion, exit 0, output file written, clean shutdown.Production-cut region 'DoesNotExist' matches no logical volumesin the log; no abort, no segfault.Note: touches
geant4_module.cppnear the physics-list validation thatfix/g4-fail-cleanlyalso modifies; whichever merges second may need a trivial rebase.