Problem 818

Summary: Overlap problem using G4Tubs ?
Product: Geant4 Reporter: zsh42
Component: geometry/solidsAssignee: davidw
Status: RESOLVED DUPLICATE    
Severity: normal CC: John.Apostolakis
Priority: P2    
Version: 7.0   
Hardware: PC   
OS: Linux   

Description zsh42 2005-12-03 06:55:30 CET
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;
}
Comment 1 Vladimir.Grichine 2005-12-07 01:54:59 CET
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.
Comment 2 Vladimir.Grichine 2005-12-07 01:54:59 CET
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.