Possible bug with geometry

Hello friends

I have found some strange behavior with geometry. I will try to convey the bug with only 1 image, due to restrictions on new users.
My application fires photons through multiple layers of barriers. I find the correct behavior when simulating 2 barriers. E.g. 2 cm of lead followed by 3 cm of lead stops the photons, as shown here:
(Image retracted)
Zooming in you can see the 2 layers of lead:
(Image retracted)
The problem arises when I add a third layer, e.g. another 1 cm of lead in front:
(Image retracted)
While the barriers appear in the visualization, only one quadrant of the barriers is attenuating photons:
(Image retracted)


To clarify, this is a GPS beam with full 2*pi azimuthal coverage:
(Image retracted)
3/4 quadrants of the barrier do not seem to exist in the simulation; the photons that pass through them do not pass through barrier materials.
To further complicate issues, this bug does not occur when I increase the layer widths by a factor of 10 (10 cm, 20 cm and 30 cm):
(Image retracted)

I am happy to share the code, but I am not doing anything interesting. I have used G4Tubs for the barriers here, but the same bug occurs with G4Box. I have produced this apparent bug on Geant4 versions 10.05 and 10.05.p01.

Thanks in advance.
Jake

Have you checked for overlaps?

/geometry/test/run

Hi John, thanks for the response.

I ran that check for overlaps and it came back OK:

/geometry/test/run
Running geometry overlaps check…
Checking overlaps for volume Detector … OK!
Checking overlaps for volume Layer1 … OK!
Checking overlaps for volume Layer2 … OK!
Checking overlaps for volume Layer3 … OK!
Geometry overlaps check completed !

I have also tried with a 1 cm gap between layers and get the same behavior:

Mmm. Trying to understand the symptoms. You say, “3/4 quadrants of the barrier do not seem to exist in the simulation; the photons that pass through them do not pass through barrier materials.”
Could you try firing one photon at a time into the different quadrants with
/tracking/verbose 2
You can use GPS to set a direction, then
/run/beamOn 1
Let us have some output (in an attachment).

I assume when you say photons you mean gammas, not optical photons.

Thanks

John

That’s correct, they are 140.5 keV gammas.

Here is some output:
correct_behavior.txt (29.8 KB) wrong_behavior.txt (28.8 KB)

Please note the output includes print statements from this line in UserSteppingAction:

G4cout << step->GetPreStepPoint()->GetMaterial()->GetName() << G4endl;

Thanks,
Jake

Hi. So…

correct_behavior: gamma is absorbed in Layer1 and produces a photoelectron.
wrong_behavior: gamma goes straight OutOfWorld.

I note:
correct_behavior: the first step goes to (359,359,858) mm.
wrong_behavior: the first step goes to (-385,-385,1.06e+03) mm.

Your gammas are shooting as quite a large angle and in opposite quadrants.

Not sure what this is telling us. Sorry not to be more helpful. All I can suggest is that you keep on investigating and see if you can pin down what’s happening. Run several gammas (/run/beamOn 10), say. Are you sure you’re firing the same gammas from GPS?

Cheers

John

I see:
correct_behavior:
/gps/position 0 0 -2025 mm
/gps/pos/type Point
/gps/ang/type iso
/gps/ang/mintheta 170 deg
/gps/ene/mono 140.5 keV
/gps/particle gamma
#/run/beamOn 100
#/vis/ogl/printEPS
/gps/ang/maxtheta 170 deg
/gps/ang/minphi 225 deg
/gps/ang/maxphi 225 deg

wrong_behavior:
/gps/position 0 0 -2025 mm
/gps/pos/type Point
/gps/ang/type iso
/gps/ang/mintheta 170 deg
/gps/ene/mono 140.5 keV
/gps/particle gamma
#/run/beamOn 100
#/vis/ogl/printEPS
/gps/ang/maxtheta 170 deg
/gps/ang/minphi 45 deg
/gps/ang/maxphi 45 deg

Why are they different? Why minphi == maxphi? Make sure you are using the same and sensible parameters.

John

Hi John,

I set minphi = maxphi (and mintheta = maxtheta) so that I could consistently fire the gamma in the same direction.
Here is visualisation of the two situations. As you see with the eye, the phi = 45 deg gamma should be passing through the the barrier:

We have the correct behavior for 180 < phi < 270 (i.e. one quadrant), but the wrong behavior for all other phi.

Thanks for your persistence through this weird problem, it is much appreciated.
Jake

Hi Jake

OK. Weird.

Another thing to check is: are your volumes sharing a rotation matrix? Or material? And are these objects created on the heap (with new) so that they last the life of your app?

And please tell us: What version of Geant4? What operating system?

John

Hi John

The volumes do not share a rotation matrix. No rotation matrices are used.
For the materials I have been using e.g.

G4Material* lead = nist->FindOrBuildMaterial(“G4_Pb”);

The problem occurs regardless of whether the volumes are the same material or not.

The solid, logical and physical volumes are all created with “new”.

I have produced this using Geant4 versions 10.05 and 10.05.p01, both on CentOS Linux release 7.6.1810 (Core). I’m using VMs from http://geant4.in2p3.fr/spip.php?rubrique8&lang=en

Thanks,
Jake

Hi Jake

Looks like you have found a genuine bug. Will you please file a bug report. Could you attach a simple app that demonstrates the bug (in the form of a tar file or zip file)?

Hope we can get to the bottom of this.

John

Hi John,
Sorry for the delay. I am not allowed to upload a tar.gz file here. Where should I submit it?
Also, I discovered that if I remove the detector (the small box behind the layers), the problem goes away.

Thanks,
Jake

Hi Jake

I think you can upload a tar file in the Bug Report system (https://bugzilla-geant4.kek.jp/).

Hmmm, re detector. Strange. Try /vis/drawTree and send us the output. Maybe /vis/ASCIITree/verbose 2 first.

John

Thanks John.
The bug submission is here: https://bugzilla-geant4.kek.jp/show_bug.cgi?id=2205
The ASCII tree output: ASCIITree.txt (2.3 KB)

Jake