u-eff-gee
commented
5 years ago Solved before commit b61b82e6f8bf32a72edac78676974d432dd8cbf5 by subjecting the detectors and filter cases of the 2018/2019 geometries to the new construction conventions where all parts of the geometry are placed in the same world volume (IF they are not contained inside each other).
This problem was due to the filter cases and detectors having partially empty mother volumes. For example, the mother volume of a complete detector (front part plus dewar) was simply a large G4Tubs with an outer radius that was equal to the outer radius of the dewar. In the front part, the mother volume was much larger than the actual detector and could, in a close geometry, overlap with the front parts of other detectors. The same holds for the filter cases, whose mother volume was even more hollow and shadowed parts of the detector crystals.
The functionality was checked by ray tracing, as suggested by j-kleemann, and it yielded output like
G4WT0 > Step# X(mm) Y(mm) Z(mm) KinE(MeV) dE(MeV) StepLeng TrackLeng NextVolume ProcName
G4WT0 > 0 -4.82 7.45 0 7 0 0 0 Ni64_Target initStep
G4WT0 > 1 5.89 7.45 0 7 0 10.7 10.7 Vacuum Transportation
G4WT0 > 2 20.9 7.45 0 7 0 15 25.8 TargetTube Transportation
G4WT0 > 3 20.9 7.45 0 7 0 0 25.8 Pipe_Upstream Transportation
G4WT0 > 4 24.3 7.45 0 7 0 3.34 29.1 World Transportation
G4WT0 > 5 79.7 7.45 0 7 0 55.4 84.5 filter_LaBr1_0 Transportation
G4WT0 > 6 80.9 7.45 0 7 0 1.15 85.7 World Transportation
G4WT0 > 7 83.4 7.45 0 7 0 2.54 88.2 LaBr1_crystal_housing_face Transportation
G4WT0 > 8 83.9 7.45 0 7 0 0.5 88.7 LaBr1_vacuum Transportation
G4WT0 > 9 85.9 7.45 0 7 0 2 90.7 LaBr1_crystal Transportation
G4WT0 > 10 162 7.45 0 7 0 76.2 167 LaBr1_vacuum Transportation
G4WT0 > 11 165 7.45 0 7 0 3 170 World Transportation
G4WT0 > 12 350 7.45 0 7 0 185 355 LaBr1_pmt_housing_bottom Transportation
G4WT0 > 13 352 7.45 0 7 0 2 357 World Transportation
G4WT0 > 14 1.5e+03 7.45 0 7 0 1.15e+03 1.5e+03 OutOfWorld TransportationAll of the components are traversed in the correct order and at the correct point in space. For example, the lanthanum bromide detector case is hit at x=83.4, which is the desired distance from the target. Furthermore, the length of the crystal, which should be 3 inches, can be read off from the entry and exit points.
Note that this problem does not exist in pre-2018 geometries, since the detectors simply had a cylindrical shape, and the filter cases were placed directly in the world volume as it is now.
The large mother volumes of FilterCases and Detector can overwrite parts of other detectors nearby or for the FilterCases even parts of its very own detector.
Simulating for example a geantino going from the g3 target position straight up into a LaBr detector placed 55mm away from the target with a 2mm Cu and 1mm Pb filter gives in verbose tracking:
Note how the Pb and Cu filters don't appear at all and the Crystal_Housing_Lid1 is also not transversed.
Now by uncommenting the Filtercase new G4PVPlacement and doing the same over one gets:
Here the Pb and Cu filters appear and also the Crystal_Housing_Lid1 is entered at 55mm track length as expected.
The parts of the FilterCase (Ring, Bottom, Wall) are not transversed here simply because due to their geometry they are not hit by a particle hitting the detector face center (This puzzled me in the beginning but UG made me aware of this).
Note however that while the LaBr is placed in the code before the FilterCase, the Pb and Cu filters are placed after it. So apparantly the order in which objects are placed in the code does not matter, it is likely the case that the order in which a particle enters an object is relevant when all overlapping objects share the same mother volume.