I have a GDML geometry extracted from a STEP file which I’m trying to integrate in my simulation. I noticed that some of the elements are overlapping of a very small amount, e.g.:
Checking overlaps for volume P-LAYER-11_1_-5:0 (G4TessellatedSolid) ... OK!
Checking overlaps for volume P-_X2_4FA78FB98FDE63A5_X0_-6:0 (G4TessellatedSolid) ...
-------- WWWW ------- G4Exception-START -------- WWWW -------
*** G4Exception : GeomVol1002
issued by : G4PVPlacement::CheckOverlaps()
Overlap with volume already placed !
Overlap is detected for volume P-_X2_4FA78FB98FDE63A5_X0_-6:0 (G4TessellatedSolid) with P-LAYER-11_1_-5:0 (G4TessellatedSolid)
overlap at local point (-185.267,372.29,-1055.39) by 7.36402 um (max of 40 cases)
NOTE: Reached maximum fixed number -1- of overlaps reports for this volume !
*** This is just a warning message. ***
-------- WWWW -------- G4Exception-END --------- WWWW -------
I guess this is because of the limited precision combined with too tight dimensions in the original CAD drawing, which I cannot modify.
So my question is: what can I expect if I use this geometry as is? A small error in energy deposits is not an issue for me (I would expect an error roughly proportional to the overlap dimension and thus very small, and these are anyway all passive materials), but I’m concerned about crashes or macroscopic navigation errors like a particle completely missing a volume. Are these concerns valid or not? Is there anything else I should beware of?
Thanks.
yes. particles could leave one volume and be already inside another. Since they ascend hierarchically to the departed volume’s mother volume, particles miss “entering” the second volume.
So the particle in this case would travel the mother volume instead of the daughter one, since when exiting from the previous daughter and returning to the mother it is already inside the second daughter and thus it doesn’t see the boundary and thus doesn’t enter the daughter. Does it work like this?
I guess that at volume exit there’s no check about already being inside another volume at the same hierarchy level, this would solve my problem but it’s a complete waste of time in a properly defined geometry with no overlaps…
this is exactly my understanding. plus there could be issues with calculating the distance to the next geometric boundary, as it could now “see” the exit face of the volume it is currently (geometrically, but not logically) inside competing with a regular entrance face of a third volume…
jep, that check would probably be extremely expensive.
I have similar problems (CAD to GDML conversion), but so far I was thinking that the overlaps simply “shift” the boundary crossing depending on the direction of the step. (I.e. the boundary crossing would happen on the edge defined for the current volume.)
In our case every volumes’ mother is the world volumes, and there were some problems when calculating the number of geantinos hitting 6 identical volumes (the hit numbers were not consistent).
After some tests it turned out that many geantinos missed the boundary crossings:
I think I will give up. After a colleague removed all the overlaps in the CAD file I still get sub-nm overlaps from the G4 geometry test. I’d guess it’s because of single precision used by CAD/GDML file, and I see no way to fix this. Any suggestion is appreciated.
you could shrink the CAD in that sense that you subtract 10nm times the normal vector of each facet from each vertex of that facet (assuming that 10nm is much smaller than the distance between vertices.
There seem to be a number of misunderstandings. The initial guess that the errors in energy deposition will be proportional to the overlap volume (and the difference in density and Z of the materials) is the closest to what I would expect - so long as there are no ‘thin’ volumes in the hierarchy hiding inside these overlaps.
Whan the Navigator exists one volume, it will consider whether it has also exited the mother volume (and, if so, other ancestor volumes in turn.). Next it checks whether it is entering a different daughter of the \the last volume it exited. Finally it checks whether the point is inside each daughter volume. I know this code, as I have maintained it for the last 27 years.
The pathological cases are a) those with boundaries that are within ‘tolerance’ distance of each other and b) those in which the solids involved do not give consistent answers (this can happen if intersections are calculated using iterative methods, or there is a rare inconsistency between the Inside method and the answers of DistanceToIn / DistanceToOut. We have checks for such inconsistencies, and do not
expect them to occur except in circumstances which are rare or which were missed in testing.
If your geometry has many levels, with inconsistencies between the surfaces at each level there would be more cause for concern. Nevertheless I would try out your candidate geometry in practice after testing that there are no macroscopic scale overlaps. To do that run the new overlap checking with an overlap tolerance distance of 1.0mm , then 0.5mm, 0.25 mm and 0.1 mm. If your geometry has a clean bill of health or very few problems except for the last value(s), then you should have reasonable confidence that you can run simulations with reasonable reliability. Do expect to see the Navigator reporting some stuck particles, but I would expect that it recovers in the significant majority of cases.
Thank you very much John for sharing your deep insight. I will test my geometry as is now with sub-nm overlaps, and based on what you write I expect no sizeable effect (except error messages) sine I don’t have sub-nm volumes.
Thank you for this thorough explanation. Are there also checks whether the point is inside a daughter volume of the mother volume the particle just left – i.e. a sibling of the last exited volume? At least for my workflows, this seems to be the dominant case, when all CAD objects are direct daughters of the world volume.
The reports of the previously linked thread by @albgabor seem to contradict, and are consistend with my experience…
edit: just ran a few tests with cad exports and overlap: indeed the particle travels through both volumes and also finds the second volume as @japost described – even though it already travelled past its entry facet when leaving the first.
“I think I will give up. After a colleague removed all the overlaps in the CAD file I still get sub-nm overlaps from the G4 geometry test. I’d guess it’s because of single precision used by CAD/GDML file, and I see no way to fix this. Any suggestion is appreciated”
Did you try scaling the STEP file before the CAD/GDML conversion?
What are you using to preform the CAD/GDML conversion?
Is the single precision coming from the STEP file or the CAD/GDML conversion?
Are you able to share the STEP file?
Some times it is possible to recreate a STEP file as a small number of booleans of GDML Solids, for example see Revolved : Examples of Revolved sketches · KeithSloan/GDML Wiki · GitHub
Name dropping this originally was a step file that Frederico Carminati( Was involved with Geant4 from the start) was trying to convert that we recreated as a revolved sketch in FreeCAD.
A second example Home · KeithSloan/GDML Wiki · GitHub.
Here a couple of sections have been taken of the STEP file and the object recreated as booleans of GDML objects.
Not sure how it would workout but FreeCAD could be used to scale the imported file, scale 0.9999 or some such, then use the workbenches facilities to Tessellate the Object.
Thanks Keith for your tips. Actually I’m not an expert of CAD manipulation, I simply got the STEP file from one of our engineers and naively tried to make it work inside G4 using the GDML file derived from the STEP with MRADSIM. I’ll try to scale the file as you suggested.