Unexpected exception using /gps/confine

Geometry, Fields and Transportation
1

Dear all

I’m currently modifying the detector geometry in my simulation and encounter an unexpected exception using /gps/confine. In this new version I include a radioactive spot to which I will try to confine the event generation. This radioactive spot is defined in the DetectorConstruction class as a G4tubs with a height of 1nm and a 1mm radius centered on (0., 0., -1. mm).
In the macro I defined:
/gps/pos/centre 0. 0. -1. mm
/gps/pos/type Plane
/gps/pos/shape Circle
/gps/pos/radius 1. mm
/gps/pos/confine RadiationSpot
Which works as expected (for charged geantinos and 10 events). Keeping everything the same except for a bigger value of /gps/pos/radius, e.g. 1.1 mm, results in G4Exception: G4GPS001.
LoopCount = 100000
Either the source distribution >> confinement or any confining volume may not overlap with the source distribution or any confining volumes may not exist

This exception was unexpected for me, especially when looking at the output when using /gps/verbose 1 where there are several events which according to me fit the requirements to be excepted:
G4WT0 > Rotated and Translated position (0.8435785306149446,-0.5855505638464635,-1)
G4WT0 > Rotated and Translated position (0.04277877150439346,0.1528173779970043,-1) Should be excepted?
G4WT0 > Rotated and Translated position (0.4877390072176273,0.6246413596337022,-1) Should be excepted?
G4WT0 > Rotated and Translated position (0.5520109266627489,-0.9381969957858898,-1)
G4WT0 > Rotated and Translated position (-0.5594148641537221,0.5836322704609065,-1) Should be excepted?

Can anyone help me with this issue? It’s the first time that I use /gps/confine, don’t hesitate to let me know if I need to include additional information.

Thanks in advance!

1 Like
2

Given that this topic didn’t attract any attention I decided to give it a second try. I’m posting this follow-up message for anyone experiencing a similar problem in the future.

After some more debugging I learned that the code ran as expected whenever the first try hit the confined region. If not, meaning that the first proposed position of G4SingleParticleSource was outside of this region, all other guesses where not accepted even though they had the correct position.
Thereafter, I noticed that CheckOverlaps() returned a warning on the volume used for the confine command. To verify that this influenced my result I shifted both the volume and the position in the macro which now ran as expected. Thus I solved the overlap warning using a G4SubtractionSolid and shifted the volume back to its original position. Now also the problem with the /gps/confine/ command was solved!
As a cross-check I removed the subtraction solid, however, the code kept working.

As my preliminary conclusion, I would say that this problem might have been caused by a difference in the order in which the volumes are checked for a first try or subsequent tries of G4SingleParticleSource. If this is the case changing my code back to the original form, which now does work, probably influenced the order in which the volumes get checked.