Repository navigation
Restore atomic de-excitation; make Generator work multithreaded - #106
Merged
Merged
Conversation
The custom physics list registered G4RadioactiveDecayPhysics before the EM constructor. It then creates the atomic de-excitation module and initializes it while the physics list is built, before any material-cuts couple exists, so de-excitation stayed inactive in every volume: no fluorescence x-rays or Auger electrons, while printParameters reported them enabled. Register it after G4EmStandardPhysics_option4, as Geant4 requires. In multithreaded mode the master has no primary generator or stacking action, so app.generator raised "Primary generator action is not available". Their state is static, so return the bound classes instead. /gun/ and /gps/ commands issued before their messengers exist (before initialize() in MT) are now kept and applied right after initialization.
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configuration
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 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
1. No fluorescence or Auger electrons with the default physics list (bug in our code)
The
"custom"physics list registeredG4RadioactiveDecayPhysicsbeforeG4EmStandardPhysics_option4. Geant4 requires the opposite order: itsConstructProcesssays it "should be defined after EM constructor". When it runs first, it creates theG4UAtomicDeexcitationmodule and callsG4LossTableManager::ResetParameters()while the physics list is still being constructed. The production-cuts table is still empty at that point, so no material-cuts couple is marked active. The one-shot reset flag is then used up, so the module is not re-initialised at the first run.The result: no de-excitation in any volume, while
/process/em/printParametersstill reports fluorescence, Auger and ignore-cuts as enabled. The tell-tale is/process/em/verbose 1, which prints "UAtomDeexcitation is activated for 1 region:" with no region line under it. Because the de-excitation code never ran or drew random numbers,/process/em/fluo false, Bearden and ANSTO all gave bit-identical output.The fix moves decay and radioactive decay after the EM constructor.
Gold slab, 0.1 mm, 100 keV gamma beam, 2000 events,
photsecondaries:The released wheel also confirms the mechanism: QGSP_BIC_EMZ with
add_physics("G4RadioactiveDecayPhysics")appended after EM gives 1465 gammas and 24,502 electrons.With the bug, the whole K-shell binding energy was deposited locally, which inflates kV-photon dose in high-Z materials.
Reference lists are not affected by this bug. They show no K x-rays in gold because of normal Geant4 behaviour:
/process/em/deexcitationIgnoreCut trueor/run/setCut 0.01 mmrestores the x-rays.2.
app.generatorin multithreaded modeIn multithreaded mode only the workers have a primary generator and a stacking action, so
app.generatorraisedPrimary generator action is not available. Since all their state is static, thegeneratorandstackingproperties now return the bound classes instead of the master's (non-existent) instance./gun/and/gps/commands issued before their messengers exist (in multithreaded mode, beforeinitialize()) failed with code 100. They are now kept and applied, in order, right after initialization, and the master forwards them to the workers. A mistyped command of this kind is reported byinitialize()instead of immediately.PrimaryGeneratorAction::set_*now goes throughApplication::Command, so it raises on failure instead of ignoring it.Tests
tests/test_physics.py::test_gold_fluorescence[0, 2]: gold Kα photons fromphot(serial and 2 threads).tests/test_run.py: Generator gun and GPS withn_threads=2, before and afterinitialize(), and the deferred typo error.The developer guide sections that describe the multithreaded workaround (28, 32 and 74) exist only on the
developer-guide-updatesbranch (#105). Replacement text for them is handed over to that PR rather than edited here, to avoid conflicts.🤖 Generated with Claude Code