You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -105,21 +105,28 @@ Note: all three conditions may be combined (if one condition is True, the partic
105
105
106
106
### Hits-related actors (digitizer)
107
107
108
-
In legacy Gate, the digitizer module is a set of tools used to simulate the behaviour of the scanner detectors and signal processing chain. The tools consider a list of interactions occurring in the detector (e.g. in the crystal), named as "hits collections". Then, this collection of hits is processed and filtered by different modules to end up with a final digital value. To start a digitizer chain, we must start defining a `HitsCollectionActor`, explained in the next sections.
108
+
The digitizer module is a set of tools used to simulate the behaviour of the scanner detectors and signal processing chain. The tools consider a list of interactions occurring in the detector (e.g. in the crystal), named as "hits collections". This collection of hits is then processed and filtered by different modules to produce a final digital value. To initiate a digitizer chain, you begin by defining a `HitsCollectionActor`, as explained in the following sections.
109
+
110
+
Common features of all digitizer actors:
111
+
112
+
- Most digitizers have a root output (with the exception for `DigitizerProjectionActor`, which outputs an image). This output can be written to disk with `my_digitizer.root_output.write_to_disk = True`. Multiple digitizers can share the same root output file, with each storing data in a separate branch named after the actor.
113
+
114
+
-`authorize_repeated_volumes`: Set this to True if you want the digitizer to work with repeated volumes. This is useful, for example, when the digitizer is attached to a region with repeated crystal volumes (as in a PET system). However, if you are repeating some SPECT heads, you may not want the digitizer to record hits from both heads in the same file (in which case, set the flag to False).
115
+
109
116
110
117
#### DigitizerHitsCollectionActor
111
118
112
119
The `DigitizerHitsCollectionActor` is an actor that collects hits occurring in a given volume (or one of its daughters). Every time a step occurs in the volume a list of attributes is recorded. The list of attributes is defined by the user as follows:
113
120
114
121
```python
115
122
hc = sim.add_actor('DigitizerHitsCollectionActor', 'Hits')
In this example, the actor is attached (`mother` option) to several volumes (`crystal1` and `crystal2` ) but most of the time, one single volume is sufficient. This volume is important: every time an interaction (a step) is occurring in this volume, a hit will be created. The list of attributes is defined with the given array of attribute names. The names of the attributes are as close as possible to the Geant4 terminology. They can be of a few types: 3 (ThreeVector), D (double), S (string), I (int), U (unique volume ID, see DigitizerAdderActor section). The list of available attributes is defined in the file `core/opengate_core/opengate_lib/GateDigiAttributeList.cpp` and can be printed with:
129
+
In this example, the actor is attached (`attached_to` option) to several volumes (`crystal1` and `crystal2` ) but most of the time, one single volume is sufficient. This volume is important: every time an interaction (a step) is occurring in this volume, a hit will be created. The list of attributes is defined with the given array of attribute names. The names of the attributes are as close as possible to the Geant4 terminology. They can be of a few types: 3 (ThreeVector), D (double), S (string), I (int), U (unique volume ID, see `DigitizerAdderActor` section). The list of available attributes is defined in the file `core/opengate_core/opengate_lib/GateDigiAttributeList.cpp` and can be printed with:
123
130
124
131
```python
125
132
import opengate_core as gate_core
@@ -192,29 +199,29 @@ The two actors used to convert some `hits` to one `digi` are "DigitizerHitsAdder
192
199
This actor groups the hits per different volumes according to the option `group_volume` (by default, this is the deeper volume that contains the hit). All hits (in the same event) occurring in the same volume are gathered into one single digi according to one of the two available policies:
193
200
194
201
- EnergyWeightedCentroidPosition:
195
-
- the final energy ("TotalEnergyDeposit") is the sum of all deposited energy
196
-
- the position ("PostPosition") is the energy-weighted centroid position
197
-
- the time ("GlobalTime") is the time of the earliest hit
202
+
- the final energy (`TotalEnergyDeposit`") is the sum of all deposited energy
203
+
- the position (`PostPosition`) is the energy-weighted centroid position
204
+
- the time (`GlobalTime`) is the time of the earliest hit
198
205
199
206
- EnergyWinnerPosition
200
-
- the final energy ("TotalEnergyDeposit") is the energy of the hit with the largest deposited energy
201
-
- the position ("PostPosition") is the position of the hit with the largest deposited energy
202
-
- the time ("GlobalTime") is the time of the earliest hit
207
+
- the final energy (`TotalEnergyDeposit`) is the energy of the hit with the largest deposited energy
208
+
- the position (`PostPosition`) is the position of the hit with the largest deposited energy
209
+
- the time (`GlobalTime`) is the time of the earliest hit
Note that this actor is only triggered at the end of an event, so the `mother` volume to which it is attached has no effect. Examples are available in test 037.
220
+
Note that this actor is only triggered at the end of an event, so the `attached_to` volume to which it is attached has no effect. Examples are available in test 037.
214
221
215
222
#### DigitizerReadoutActor
216
223
217
-
This actor is the same as the previous one (DigitizerHitsAdderActor) with one additional option: the resulting positions of the digi are set in the center of the defined volumes (discretized). We keep two different actors (Adder and Readout) to be close to the previous legacy GATE versions. The additional option `discretize_volume` indicates the volume name in which the discrete position will be taken.
224
+
This actor is the same as the previous one (`DigitizerHitsAdderActor`) with one additional option: the resulting positions of the digi are set in the center of the defined volumes (discretized). We keep two different actors (Adder and Readout) to be close to the previous legacy GATE versions. The additional option `discretize_volume` indicates the volume name in which the discrete position will be taken.
218
225
219
226
```python
220
227
sc = sim.add_actor("HitsReadoutActor", "Singles")
@@ -239,7 +246,7 @@ For Linear: `blur_reference_value`, `blur_reference_value` and `blur_slope` EQU
239
246
240
247
```python
241
248
bc = sim.add_actor("DigitizerBlurringActor", "Singles_with_blur")
242
-
bc.output="output.root"
249
+
bc.output_filename="output.root"
243
250
bc.input_digi_collection ="Singles_readout"
244
251
bc.blur_attribute ="GlobalTime"
245
252
bc.blur_method ="Gaussian"
@@ -306,7 +313,7 @@ As parameters, Coincidence Sorter expects as input:
306
313
307
314
#### Policies
308
315
309
-
When more than two singles are found in coincidence, several type of behavior could be implemented. GATE allows to model 5 different policies to treat multiple coincidences that can be used. Mutliple coincidences or "multicoincidence" are composed of at least three singles detected in the same **time window** that could form coincidence. The list of policies along with their explanation are given in Table below. The 5 policies, same as in [Gate9.X](https://opengate.readthedocs.io/en/latest/digitizer_and_detector_modeling.html#id43), were selected for the implementation as the most used. If an option that you need is missing, please, don't hesitate to report it in [Issues](https://github.com/OpenGATE/opengate/issues).
316
+
When more than two singles are found in coincidence, several type of behavior could be implemented. GATE allows to model 5 different policies to treat multiple coincidences that can be used. Multiple coincidences or "multicoincidence" are composed of at least three singles detected in the same **time window** that could form coincidence. The list of policies along with their explanation are given in Table below. The 5 policies, same as in [Gate9.X](https://opengate.readthedocs.io/en/latest/digitizer_and_detector_modeling.html#id43), were selected for the implementation as the most used. If an option that you need is missing, please, don't hesitate to report it in [Issues](https://github.com/OpenGATE/opengate/issues).
310
317
311
318
312
319
**Available multiple policies and associated meaning**. When a multiple coincidence involving n *singles* is processed, it is first decomposed into a list of n·(n−1) pairs which are analyzed individually.
@@ -368,7 +375,7 @@ The Compton splitting actor generates N particles, each with a weight equal to t
0 commit comments