|
| 1 | +Physics |
| 2 | +======= |
| 3 | + |
| 4 | +This chapter documents implementation details of GATE's physics handling for |
| 5 | +developers. It focuses on the Python-side orchestration around Geant4 physics |
| 6 | +objects, i.e. the code that turns user-facing settings into Geant4 regions, |
| 7 | +physics constructors, processes, and cuts. |
| 8 | + |
| 9 | +Step Limiter |
| 10 | +------------ |
| 11 | + |
| 12 | +The step limiter is implemented through Geant4 user limits. On the GATE side, |
| 13 | +the relevant code is split across three places: |
| 14 | + |
| 15 | +* ``opengate.managers.PhysicsManager`` exposes the user-facing API. |
| 16 | +* ``opengate.physics.Region`` stores per-region user limits and builds the |
| 17 | + corresponding Geant4 region objects. |
| 18 | +* ``opengate.physics.UserLimitsPhysics`` is a Geant4 physics constructor that |
| 19 | + adds the required Geant4 processes to the selected particles. |
| 20 | + |
| 21 | +User-facing entry points |
| 22 | +~~~~~~~~~~~~~~~~~~~~~~~~ |
| 23 | + |
| 24 | +Users set the maximum step size either through the physics manager: |
| 25 | + |
| 26 | +.. code-block:: python |
| 27 | +
|
| 28 | + sim.physics_manager.set_max_step_size(volume.name, 1 * gate.g4_units.mm) |
| 29 | +
|
| 30 | +or through the volume convenience method: |
| 31 | + |
| 32 | +.. code-block:: python |
| 33 | +
|
| 34 | + volume.set_max_step_size(1 * gate.g4_units.mm) |
| 35 | +
|
| 36 | +Internally, both paths associate the volume with a ``Region`` object and store |
| 37 | +the value in ``region.user_limits["max_step_size"]``. If no region exists yet |
| 38 | +for the volume, ``PhysicsManager.find_or_create_region()`` creates one. The |
| 39 | +world volume is associated with Geant4's ``DefaultRegionForTheWorld``; other |
| 40 | +volumes use a GATE-created region named ``<volume_name>_region`` by default. |
| 41 | + |
| 42 | +The particles to which user limits are applied are selected with: |
| 43 | + |
| 44 | +.. code-block:: python |
| 45 | +
|
| 46 | + sim.physics_manager.user_limits_particles = ["proton", "GenericIon"] |
| 47 | +
|
| 48 | +This setting is a list-like user input. A single string is accepted by the |
| 49 | +setter hook and converted to a one-element list. The special values are: |
| 50 | + |
| 51 | +* ``"all"``: apply user limits to all Geant4 particles known to the particle |
| 52 | + table. |
| 53 | +* ``"all_charged"``: add the step limiter to charged particles, following |
| 54 | + Geant4's ``G4StepLimiterPhysics`` behaviour. |
| 55 | + |
| 56 | +Particle names are intentionally not limited to the production-cut aliases |
| 57 | +(``gamma``, ``electron``, ``positron``, ``proton``). Any Geant4 particle name is |
| 58 | +accepted, after applying the small GATE-to-Geant4 alias translation implemented |
| 59 | +by ``translate_particle_name_gate_to_geant4()``. |
| 60 | + |
| 61 | +Region initialization |
| 62 | +~~~~~~~~~~~~~~~~~~~~~ |
| 63 | + |
| 64 | +During simulation initialization, every ``Region`` runs |
| 65 | +``Region.initialize_g4_user_limits()``. If none of the user-limit fields is set, |
| 66 | +no ``G4UserLimits`` object is created. Otherwise, GATE creates one and fills all |
| 67 | +limits: |
| 68 | + |
| 69 | +* ``max_step_size`` maps to ``G4UserLimits.SetMaxAllowedStep()``. |
| 70 | +* ``max_track_length`` maps to ``SetUserMaxTrackLength()``. |
| 71 | +* ``max_time`` maps to ``SetUserMaxTime()``. |
| 72 | +* ``min_ekine`` maps to ``SetUserMinEkine()``. |
| 73 | +* ``min_range`` maps to ``SetUserMinRange()``. |
| 74 | + |
| 75 | +Unset upper limits are replaced by ``FLOAT_MAX`` and unset lower limits by |
| 76 | +``0``. This lets one ``G4UserLimits`` object represent only the limits that the |
| 77 | +user actually requested. |
| 78 | + |
| 79 | +After that, ``Region.initialize_g4_region()`` creates or finds the Geant4 |
| 80 | +``G4Region``, attaches the ``G4UserLimits`` object to it, and adds the root |
| 81 | +logical volumes associated with the GATE region. This is the part that tells |
| 82 | +Geant4 where the user-limit values apply. |
| 83 | + |
| 84 | +Registering the Geant4 processes |
| 85 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 86 | + |
| 87 | +A ``G4UserLimits`` object alone is not sufficient. Geant4 also needs tracking |
| 88 | +processes attached to particles so that the limits are actually enforced. |
| 89 | + |
| 90 | +The physics engine checks all regions in |
| 91 | +``PhysicsEngine.initialize_user_limits_physics()``: |
| 92 | + |
| 93 | +.. code-block:: python |
| 94 | +
|
| 95 | + if region.need_step_limiter(): |
| 96 | + need_step_limiter = True |
| 97 | + if region.need_user_special_cut(): |
| 98 | + need_user_special_cut = True |
| 99 | +
|
| 100 | +If at least one region needs a maximum step size or another user special cut, |
| 101 | +GATE registers ``UserLimitsPhysics`` on the active Geant4 physics list. |
| 102 | + |
| 103 | +``UserLimitsPhysics.ConstructProcess()`` then iterates over the full Geant4 |
| 104 | +particle table and decides, particle by particle, whether to add: |
| 105 | + |
| 106 | +* ``G4StepLimiter("StepLimiter")`` for ``max_step_size``. |
| 107 | +* ``G4UserSpecialCuts("UserSpecialCut")`` for the other user limits. |
| 108 | + |
| 109 | +For explicit particle names and for ``"all"``, GATE adds both processes. For |
| 110 | +``"all_charged"``, GATE only adds ``G4StepLimiter`` to charged particles. This |
| 111 | +mirrors Geant4's default step-limiter constructor behaviour and avoids applying |
| 112 | +the other special cuts unless the user explicitly asked for the particle. |
| 113 | + |
| 114 | +The created Geant4 process objects are stored in |
| 115 | +``UserLimitsPhysics.g4_step_limiter_storage`` and |
| 116 | +``UserLimitsPhysics.g4_special_user_cuts_storage``. This storage is important: |
| 117 | +the objects are created from Python via pybind11, and keeping references avoids |
| 118 | +their garbage collection after ``ConstructProcess()`` returns. |
| 119 | + |
| 120 | +Validation and name translation |
| 121 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 122 | + |
| 123 | +Before processes are added, ``UserLimitsPhysics`` validates all explicitly named |
| 124 | +particles against ``G4ParticleTable``. Unknown particles are rejected with a |
| 125 | +fatal error. The special selectors ``"all"`` and ``"all_charged"`` are removed |
| 126 | +before validation. |
| 127 | + |
| 128 | +The translation helper ``translate_particle_name_gate_to_geant4()`` maps the |
| 129 | +historical GATE names used for production cuts to Geant4 names: |
| 130 | + |
| 131 | +* ``electron`` -> ``e-`` |
| 132 | +* ``positron`` -> ``e+`` |
| 133 | +* ``gamma`` -> ``gamma`` |
| 134 | +* ``proton`` -> ``proton`` |
| 135 | + |
| 136 | +Names not present in this alias table are passed through unchanged. This is what |
| 137 | +allows inputs such as ``"GenericIon"`` or other Geant4 particle names to work |
| 138 | +without extending the production-cut particle list. |
| 139 | + |
| 140 | +Important distinction from production cuts |
| 141 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 142 | + |
| 143 | +Production cuts and user limits have different particle-name scopes in GATE. |
| 144 | +Production cuts are still constrained to the particle aliases in |
| 145 | +``cut_particle_names`` because that mirrors Geant4 production-cut usage in GATE. |
| 146 | +User limits, including the step limiter, are more general: Geant4 can apply them |
| 147 | +to any particle with a process manager. |
| 148 | + |
| 149 | +This distinction is why ``sim.physics_manager.user_limits_particles = "all"`` |
| 150 | +means all Geant4 particles for user limits. Tests that need the historical |
| 151 | +GATE behaviour should explicitly request: |
| 152 | + |
| 153 | +.. code-block:: python |
| 154 | +
|
| 155 | + sim.physics_manager.user_limits_particles = [ |
| 156 | + "proton", |
| 157 | + "gamma", |
| 158 | + "electron", |
| 159 | + "positron", |
| 160 | + ] |
| 161 | +
|
0 commit comments