| Summary: | Problem with G4UnionSolid with a G4Trap and a G4Ellipsoid | ||
|---|---|---|---|
| Product: | Geant4 | Reporter: | Ioannis Sechopoulos <isechop> |
| Component: | geometry/solids | Assignee: | tatiana.nikitina |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | P1 | ||
| Version: | 9.2 | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: | zip file with the simulation files and some macros | ||
The problem is now fixed in the development version "geom-specific-V09-02-06". It was originated by incorrect assumptions in the usage of geometrical tolerances introduced to G4Ellipsoid::DistanceToIn(p,v,...) in one of the most recent changes applied to this class. |
Created attachment 48 [details] zip file with the simulation files and some macros I believe there is probably a bug in G4UnionSolid. I'm attaching a stripped down simulation (in the zip file) that includes only the union of an ellipsoid and a trapezoid, with pretty much arbitrary sizes and offset between them. After 5956 gammas, and several track stuck messages of the type: WARNING - G4Navigator::ComputeStep() Track stuck, not moving for 10 steps in volume -physiSkin- at point (32.39327662,-102.9916514,55.11405407) direction: (0.2513308773,-0.737997636,0.6262525684). Potential geometry or navigation problem ! Trying pushing it of 9e-10 mm ... the simulation gets stuck, repeating the same two steps over and over. The world is defined really large to guarantee that both solids are well within it and the two solids overlap substantially. If I only simulate either the trap or the ellipsoid and not use the G4UnionSolid, then everything works fine. This problem happens in version 9.2.p02 (the latest), I tested this simulation with 9.1p03, and it worked fine. I included test.in which is the macro I use to run the simulation (all it does is shoot one million x-rays) and the macro files I use with visualization commands.