| Summary: | Particles traversing a geometry see "different geometries" depending on their direction of travel. | ||
|---|---|---|---|
| Product: | Geant4 | Reporter: | christopher.lester |
| Component: | geometry/solids | Assignee: | Vladimir.Grichine |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | major | CC: | John.Apostolakis |
| Priority: | P4 | ||
| Version: | 2.0 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
The problem is now under investigation. Thanks for the detailed report. This problem could not be reproduced in any test we built reproducing similar user geometry. We believe the problem is hidden in the user code therefore requiring further investigation on the user side. The report is closed and will be re-opened in case further analysis will determine a real failure in the G4 kernel. |
I have a geometry (symmetrical about z=0) which is of the form: air siliconWafer air baseboard air siliconWafer air Both silicon wafers are identical and are described by the same volume (called sct_doubleWafer - see later). This volume is postioned twice inside a mother volume called sct_barrelSensitive. For technical reasons, the shape of the mother volume (sct_barrelSensitive) is the disconnected union of the two spatially separated wafers. Indeed, for the moment, in this particular geometry, every mother volume is shaped as the boolean union of its daughter volumes. The problem is that particles traversing this geometry only see one of the silicon wafers if they come from negative to positive z, whereas they see (i.e. hit) both wafers if they come from positive to negative z. Here follows an example of a particle (an 18GeV pion) passing through a module from positiver to negative z: (The same happens with Geantinos, by the way) ********************************************************************************************************* * G4Track Information: Particle = pi+, Track ID = 1, Parent ID = 0 ********************************************************************************************************* Step# X(mm) Y(mm) Z(mm) KinE(MeV) dE(MeV) StepLeng TrackLeng NextVolume ProcName 0 1 0 100 1.8e+04 0 0 0 expHall initStep 1 1 0 0.575 1.8e+04 0.0169 99.4 99.4 sct_doubleWafer Transportation 2 1 1.6e-06 0.275 1.8e+04 0.0889 0.3 99.7 expHall Transportation HIT IN SCT_DoubleWaferSD *** HIT IN SCT_DoubleWaferSD *** HIT IN SCT_DoubleWaferSD *** HIT IN SCT_DoubleWaferSD 3 1 2.38e-06 0.2 1.8e+04 0 0.075 99.8 srt_barrelBaseboardPart3of5 Transportation 4 1 6.52e-06 -0.2 1.8e+04 3.62e-05 0.4 100 expHall Transportation 5 1 7.38e-06 -0.275 1.8e+04 0 0.075 100 sct_doubleWafer Transportation 6 1 1.09e-05 -0.575 1.8e+04 0.0777 0.3 101 expHall Transportation HIT IN SCT_DoubleWaferSD *** HIT IN SCT_DoubleWaferSD *** HIT IN SCT_DoubleWaferSD *** HIT IN SCT_DoubleWaferSD 7 1 1.45e-05 -0.869 1.8e+04 0.000108 0.294 101 expHall hIoni 8 1 0.00121 -43.1 1.8e+04 0.00704 42.3 143 expHall hIoni 9 1 0.00402 -114 1.8e+04 0.0156 70.5 214 expHall hIoni 10 1 0.00529 -147 1.8e+04 0.00564 33.3 247 expHall hIoni 11 1.01 0.0113 -322 1.8e+04 0.0333 175 422 expHall hIoni as you can see, we have hits in BOTH silicon wafers (sct_doubleWafer) as we would hope for. Each hit deposits approx 0.08 MeV. However, here you can a typical event when the particle is fired from the other direction: (Again, same for Geantinos) ********************************************************************************************************* * G4Track Information: Particle = pi+, Track ID = 1, Parent ID = 0 ********************************************************************************************************* Step# X(mm) Y(mm) Z(mm) KinE(MeV) dE(MeV) StepLeng TrackLeng NextVolume ProcName 0 1 0 -100 1.8e+04 0 0 0 expHall initStep 1 1 0 -0.575 1.8e+04 0.0169 99.4 99.4 sct_barrelModule Transportation 2 1 1.6e-06 -0.275 1.8e+04 1.28e-05 0.3 99.7 expHall Transportation 3 1 1.99e-06 -0.2 1.8e+04 0 0.075 99.8 srt_barrelBaseboardPart3of5 Transportation 4 1 3.99e-06 0.2 1.8e+04 6.34e-05 0.4 100 expHall Transportation 5 1 4.31e-06 0.275 1.8e+04 1.09e-05 0.075 100 sct_doubleWafer Transportation 6 1 5.62e-06 0.575 1.8e+04 0.111 0.3 101 expHall Transportation HIT IN SCT_DoubleWaferSD *** HIT IN SCT_DoubleWaferSD *** HIT IN SCT_DoubleWaferSD *** HIT IN SCT_DoubleWaferSD 7 1 -1.64e-05 1.15 1.8e+04 0.000897 0.575 101 expHall hIoni 8 1 -0.00337 86.5 1.8e+04 0.0162 85.3 186 expHall hIoni 9 1 -0.00385 98.6 1.8e+04 0.00302 12.1 199 expHall hIoni 10 1 -0.00584 175 1.8e+04 0.0115 76.7 275 expHall hIoni 11 1 -0.00621 200 1.8e+04 0.00509 24.7 300 beamDump Transportation 12 1.07 -0.176 279 1.77e+04 123 79.3 379 beamDump hIoni 13 1.07 -0.176 286 1.77e+04 11.5 6.42 386 beamDump hIoni You can see the problem: where one would expect to see hits in the first (negative Z) SCT_DoubleWafer, one actually gets only a very weak energy loss in the volume named "sct_barrelModule" (which is the name of the logical volume containing the whole module: wafers, baseboard, and other volumes not described here) and no hits at all. NB Since sct_barrelModule's shape is the union of its daughters, one would not expect to get any energy loss inside it directly - there is no "room spare" for that. [cf first example where things go to plan] The other (positive z) wafer works fine though - we do register a hit there - and this hit deposits an amount of energy similar to what one would expect from the particle going in the other direction. (Here .1 MeV was deposited, there 0.08 MeV). Out of ten events fired in the second direction, I did not see ANY hits in the first sct_doubleWafer - I only see hits in the second. With accompanying tarfile, and a working atlas-srt setup on linux, one ought to be able to do (in a sepatate build directory) a top level configure, a top level "gmake install", and then in the ModuleSim directory do a "gmake check" in the ModuleSim package to compile/run an executable which will reproduce the bug when the commands in ModuleSim/test/g4draw are executed - but I haven't checked for sure that this works. Good luck, Christopher [Ps My actual version of G4 is whatever is presently in atlas srt offline software. This is 4.2 - but I don't know which revision]