| Summary: | Overlap problem using G4Tubs ? | ||
|---|---|---|---|
| Product: | Geant4 | Reporter: | zsh42 |
| Component: | geometry/solids | Assignee: | davidw |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | John.Apostolakis |
| Priority: | P2 | ||
| Version: | 7.0 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
We verified that the user geometry is correctly defined and that tracking is behaving correctly, as well as the response of the solid G4Tubs. Starting with 3 sections of the tube, the application gives core-dump when running with the overlaps-check (recursive_test) on. This problem reproduces a similar situation as reported in bug report #784 and is related to the algorithm used for detecting overlaps. As such, we mark it as duplicate of #784. We verified that the user geometry is correctly defined and that tracking is behaving correctly, as well as the response of the solid G4Tubs. Starting with 3 sections of the tube, the application gives core-dump when running with the overlaps-check (recursive_test) on. This problem reproduces a similar situation as reported in bug report #784 and is related to the algorithm used for detecting overlaps. As such, we mark it as duplicate of #784. |
I wanted to report a potential geometry bug associated with the G4Tubs class, but thought it best to run it by you first. I received no replies to my Hypernews post 470.3 under geometry (I completely understand that we're all busy!) and subsequent investigation has turned up some major problems. Currently, I am running GEANT4.7.0 on Fedora Core 2. In short, there seems to be a geometry, and subsequently a tracking and G4Navigator problem, with G4Tubs sections that interface on a common plane. The internal GEANT4 "cylinder_test" as well as DAVID and OLAP report overlap when there should be no problems at all. Tracking/G4Navigating is also severly hindered, issuing numerous "track stuck" and intersection point errors. Let me give an example: I would like to build a hollow cylinder (inner radius 6 meters, outer radius 8 meters, half-length in z 2 meters) out of 12, 30-degree G4Tubs sections (ie Sphi=0.*degree, Dphi = 30.*degree in the constructors...). When I create the physical volumes, I place them by placing the first one with 0-degree rotation, the second one with 30-degree rotation, the third with 60-degree rotation, and so forth to construct the complete cylinder. Despite appearances that all seems well, "cylinder_test", DAVID, and OLAP report that ALL 12 sections overlap with the sections immediately next to them. I have also tried building each section in place, ie, using Sphi=0.*degree, Dphi=30.*degree for arc 1, Sphi=30.*degree, Dphi=60.*degree for arc 2, and so on. These yields the same overlap problem. In a further study of the problem, I tried constructing the cylinder for a different number of "arcSections" (ie, for 3 arcSection, each sections spans 120-degrees...) with the following results: 2 arcs -> No overlaps 3 arcs -> No overlaps 4 arcs -> 4 interesecting volumes 5 arcs -> No overlaps 6 arcs -> No overlaps 7 arcs -> 5 intersecting volumes 8 arcs -> No overlaps 9 arcs -> 6 intersecting volumes 10 arcs -> 10 intersecting volumes 11 arcs -> 7 intersecting volumes 12 arcs -> 12 intersecting volumes What's more confusing is that examining the DAVID .log files shows that some arcSections OPPOSITE EACH OTHER (180 degree around the cylinder) overlap with each other! How this is possible, I do not know. Possibly an off by pi error in the G4Tubs source code, when it converts and checks the user-specified angles? I don't know the source code well enough. I have attached my detectorConstruction source code as a .txt file for your inspection. This is the source code that I used to generated the above errors and geometry problems. Its very simple...I certainly don't see how I am making the error! Hope someone is able to track this very confusing problem down. Any feedback or updates you have would be much appreciated! Thanks for all the hard work! ---------------------------------------- #include "G4Box.hh" #include "G4Tubs.hh" #include "G4Material.hh" #include "G4LogicalVolume.hh" #include "G4PVPlacement.hh" #include "G4VisAttributes.hh" #include "G4Colour.hh" #include "tubsTestConstruction.hh" tubsTestConstruction::tubsTestConstruction(G4int sections) : lab_S(0), lab_L(0), lab_P(0), arcSection_S(0), arcSection_L(0), arcSection_P(0), sections_(sections) {;} tubsTestConstruction::~tubsTestConstruction() {;} G4VPhysicalVolume* tubsTestConstruction::Construct() { G4double a,z,density; G4Material* Al = new G4Material("Aluminum", z=13., a=26.98*g/mole, density=1.782*mg/cm3); G4Material* Vacuum = new G4Material("Galactic", z=1., a=1.01*g/mole,density= universe_mean_density, kStateGas, 3.e-18*pascal, 2.73*kelvin); G4double lab_x = 20.0*m; G4double lab_y = 30.0*m; G4double lab_z = 20.0*m; lab_S = new G4Box("lab",lab_x,lab_y,lab_z); lab_L = new G4LogicalVolume(lab_S, Vacuum, "lab", 0, 0, 0); lab_P= new G4PVPlacement(0, G4ThreeVector(), lab_L, "lab", 0, false, 0); for(G4int i=0; i<sections_; i++){ arcSection_S = new G4Tubs("arcSection", 6.*m, 10.*m, 2.*m, 0.*degree, 360./sections_*degree); arcSection_L = new G4LogicalVolume(arcSection_S, Al, "arcSection", 0, 0, 0); char objectName[30]; std::sprintf(objectName,"arcSection[%d]",i); arcSection_P = new G4PVPlacement(new G4RotationMatrix(0., 0., 360./sections_*i*degree), G4ThreeVector(0.,0.,0.), arcSection_L, objectName, lab_L, false, 0); G4VisAttributes* labVisAtt = new G4VisAttributes(G4Colour()); labVisAtt -> SetVisibility(1); lab_L -> SetVisAttributes(labVisAtt); G4VisAttributes* aSVisAtt = new G4VisAttributes(G4Colour(1.0,0.0,0.0,1.0)); aSVisAtt -> SetForceWireframe(1); arcSection_L -> SetVisAttributes(aSVisAtt); } return lab_P; }