Hello,
I’m updating my codes from version 2.1.6 to version 2.2.10. The codes are for radio purity studies for the electronics of the IAXO-D0 detector.
I’ve started adapting a previous rml file for simulating Th232 radioactive emission from a volume to version 2.2.10 and I’ve encountered a problem in the results I’m obtaining.
The energy deposited in gas is zero for all events:
I don’t think it has to do with Sensitive/Active volumes since I was carefully after I read about problems regarding this.
What I have noticed is that, for all of the events I have checked, the particles generated never enter the hole inside the lead shielding which contains the detector. In this image, for example, you can see an event stopping just on the limiting region lead-vacuum:
My concern is that there might be some problem regarding not the restG4 rml file but the geometry ones.
I have uploaded the rml file to CERN and it can be found at:
/afs/cern.ch/user/c/ccogollo/public/RPE_IAXO_REST_v2.2.10/IAXO_AGET-REST/G4sims/restSims/AGET/Electronics_closer/Th232FromCapBottom_closer.rml
Hi Cristian, thanks for posting. Actually it would be easier if you attach the RML file directly in the forum.
It is unlikely that the problem is in the GDML definition. Could you send an attachment with the RML used with restG4 and restManager and the geometry for testing? You may prepare a zip with the necessary files and include them as attachment.
Hi Javier, thanks for the answer.
I’m attaching a zip file with the required files. (The directories structure inside the zip file follows the path structure defined for the rml files, the only part that needs to be adjusted is the home directory) Cogollos_Egasdep_Problem.zip (17.4 KB)
I think there is some bug that registers the kinetic energy of an ion into hits in all the active volumes. This looks as a problem that needs to be tracked/identified.
SubEvent ID : 6 Global timestamp : 5.722548193e+17 seconds
Track ID : 3 Parent ID : 0 Particle : Bi212[238.632] Time track length : 1.3e-308 us
Ekin : 0.00063 keV
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Hit 0 process : RadioactiveDecay volume : 0 X : -109.76 Y : 0.73934 Z : 32.24 mm Edep : 0.00062521 keV
Hit 1 process : RadioactiveDecay volume : 1 X : -109.76 Y : 0.73934 Z : 32.24 mm Edep : 0.00062521 keV
Hit 2 process : RadioactiveDecay volume : 2 X : -109.76 Y : 0.73934 Z : 32.24 mm Edep : 0.00062521 keV
Hit 3 process : RadioactiveDecay volume : 3 X : -109.76 Y : 0.73934 Z : 32.24 mm Edep : 0.00062521 keV
Hit 4 process : RadioactiveDecay volume : 4 X : -109.76 Y : 0.73934 Z : 32.24 mm Edep : 0.00062521 keV
Hit 5 process : RadioactiveDecay volume : 5 X : -109.76 Y : 0.73934 Z : 32.24 mm Edep : 0.00062521 keV
Hit 6 process : RadioactiveDecay volume : 6 X : -109.76 Y : 0.73934 Z : 32.24 mm Edep : 0.00062521 keV
Hit 7 process : RadioactiveDecay volume : 7 X : -109.76 Y : 0.73934 Z : 32.24 mm Edep : 0.00062521 keV
Hit 8 process : RadioactiveDecay volume : 8 X : -109.76 Y : 0.73934 Z : 32.24 mm Edep : 0.00062521 keV
Hit 9 process : RadioactiveDecay volume : 9 X : -109.76 Y : 0.73934 Z : 32.24 mm Edep : 0.00062521 keV
Probably, when an ion generates a deposit in an active volume this hit is produced at any activeVolume, and therefore the gas volume. Then, it creates a fake tiny energy deposit.
Although a small problem is that the energyRange filter is connected to the total energy deposited in all active volumes. I would remove (comment out) the active volumes temporary to force that only events leaving at least 100eV in the gas volume (sensitive volume) are registered.
I commented out the other active volumes, just to study the gas volume and it worked.
In my case the extra active volumes are not needed, it was just a piece of “fossil code”. But, won’t this be an issue, for example, when studying energy deposits on vetos and the detector gas for the same event?
I think the problem was easy to identify and solve, see Git issue. Now I added a commit with a fix to the development branch (v.2.2.11_dev). You may temporary change to this branch to verify the change.
Now, even if I have active volumes defined for storage I don’t get fake events in the sensitive volume. For 100,000 events launched I get 6 entries leaving keV energies.
