| Summary: | Simulations using G4TessellatedSolid produce unknown inside/outside exceptions and zero steps | ||
|---|---|---|---|
| Product: | Geant4 | Reporter: | Arto Lehtolainen <arto.lehtolainen> |
| Component: | geometry/solids | Assignee: | PRTruscott |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | flei, Gabriele.Cosmo, PRTruscott |
| Priority: | P5 | ||
| Version: | 9.3 | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: |
G4TessellatedSolid.cc that includes the workaround to the possible bug in G4TriangularFacet.cc
output log file when running with G4 v9.3.p02 |
||
Hi, Arto, I've been looking at the problem and your work-arround ... thanks. What would help me in understanding the context is to try to run your example. Is it easy for you to tar-zip the essential files of your application or geometry? Sorry for the delayed reply, and best regards, Pete Thanks for the tar-gz file, Arto. I've run this with version 9.3 reference tag 0 and got the result you were explaining (problems with zero step lengths). Note that there was an updated bug-fix version of the tessellated solids system which went into 9.3.p02. I re-ran your source code and gdml ***with the tessellated solids which went into that later G4 release (9.3.p02) *** and the problem goes away (no reports of "<n>th dist 9e+99 5e-10" etc). Just to explain, your corrections to G4TessellatedSolid.cc were valid and a good engineering fix/work-around the problem which originates in G4TriangularFacet. The correction which went into Patch 02 repairs the source of the problem in G4TriangularFacet as well as some other issues. Unfortunately I do not have a version of the whole of 9.2.p02 on my laptop (just an earlier version with the tessellated solids correction) and I'm now in the process of rebuilding the whole of G4 9.2.p02 just to make sure this completely solves your problem. However, I'm pretty sure this will overcome the issues you see. I hope that this helps. Best regards, Pete Created attachment 92 [details]
output log file when running with G4 v9.3.p02
Hi, Arto, I've installed/built G4 v9.3.p02 and compiled it with your example. Using the GDML file aperture.gdml, the simulation seems to work ok, i.e. there are no zero steps. I've attached the output log file based on a simulation of 100 events (previously it's only taken 10 events to flag problems with the "unfixed" version of tessellated solids). When I try using aperture_test.gdml in your tar-gz file, I get lots of errors of the type: G4GDML: VALIDATION ERROR! Attribute 'vertex<blah blah>' is not declared for element <blah blah blah> .... However, I think you said you had some problems with (doubts about) this file? So the short message seems to be use version 9.3 patch 02. I hope that this resolves your problem. Thanks and regards, Pete resolved |
Created attachment 90 [details] G4TessellatedSolid.cc that includes the workaround to the possible bug in G4TriangularFacet.cc Simulations involving G4TessellatedSolids defined as triangular facets (at least) sometimes produce zero steps inside the solids and if the track is created inside a tessellated solids, it sometimes causes the G4Exception: "G4TessellatedSolid::Inside()", "UnknownInsideOutside-MaxTries", JustWarning, "Cannot determine whether point is inside or outside volume!" In both of these cases the track is treated as being outside the solid after the error, causing unphysical results. The problem seems to be in the navigation since the same thing happens with the standard grid test to check the geometry. VRML visualization of my geometry does not reveal any obvious errors in the locations where these issues happen. This problem also seems to happen more frequently with thin solids or solids with rough surfaces. The cause of these problems seems to be the method G4TriangularFacet::Intersect and possibly also G4TriangularFacet::Distance. For some reason those methods sometimes return zero distances and null vectors as surface normals, causing these errors in the calling methods. When I changed the methods Inside, SurfaceNormal, DistanceToIn and DistanceToOut in G4TessellatedSolid.cc to disregard any zero distances and null surface normals, both types of errors dissappeared. The simulation results with the modified code appear to be realistic from a first glance but this of course needs to be verified. I changed the method Inside to check also the intersecting facet's surface normal in addition to the return value of the method G4TriangularFacet::Intersect befure treating the facet as intersecting. In the methods SurfaceNormal, DistanceToIn and DistanceToOut I changed the check if (dist >= 0.0) to if (dist > 0). By my estimation these changes should be fine since the facet surface normals should never be null vectors and the distance methods default to zero anyway if the track happens to be exactly at the boundary. The modified G4TessellatedSolid.cc including my workaround is attached with this report. I'm using Geant4 version 4.9.3 p01 with Ubuntu 8.10 but I think this problem happens with other systems as well.