Problem 1077

The gap introduced of 10e-3*deg for Phi angle for an extent of ~40m detector
can easily reach the precision limits imposed by the geometrical tolerance. It is
therefore not surprising if the reply from the solid is not precise at the surface.
You should explicitly 'tune' the geometrical tolerance in this case.
Try adding the following in the beginning of your detector construction code:

  G4GeometryManager::GetInstance()->SetWorldMaximumExtent(WCLength);
  G4cout << "Computed tolerance = "
         << G4GeometryTolerance::GetInstance()->GetSurfaceTolerance()/mm
         << " mm" << G4endl;

and let us know if that fixes your problems, also for the issue you posted on
Hypernews...

Created attachment 50 [details]
Code to reproduce the stuck photons

We compilde the Geant4 clhep on centos with gcc 4.1.2. Now this error does not appears any longer. Also using the pre compiled versions of Genat4 and clhep und using gcc3.4 helps. Adjusting tolerance does not make any difference. This is also true for the issue I posted on hypernews
But there are still Photos that are stuck:


*********************************************************************************************************
* G4Track Information:   Particle = opticalphoton,   Track ID = 516161,   Parent ID = 515196
*********************************************************************************************************

Step#      X         Y         Z        KineE    dEStep   StepLeng  TrakLeng    Volume     Process
    0   13.3 m    28.8 cm  -13.1 cm   3.87 eV      0 eV      0 fm      0 fm           WC    initStep
    1   16.7 m    1.85 cm    -51 cm   3.87 eV      0 eV   3.45 m    3.45 m            WC  Transportation
    2     17 m  0.0546 fm  -53.6 cm   3.87 eV      0 eV   23.7 cm   3.69 m    WCBarrelCell  Transportation
    3     17 m  0.0546 fm  -53.6 cm   3.87 eV      0 eV      0 fm   3.69 m    WCBarrelCell  Transportation
    4     17 m  0.0546 fm  -53.6 cm   3.87 eV      0 eV      0 fm   3.69 m    WCBarrelCell  Transportation
    5     17 m  0.0546 fm  -53.6 cm   3.87 eV      0 eV      0 fm   3.69 m    WCBarrelCell  Transportation
    6     17 m  0.0546 fm  -53.6 cm   3.87 eV      0 eV      0 fm   3.69 m    WCBarrelCell  Transportation
    7     17 m  0.0546 fm  -53.6 cm   3.87 eV      0 eV      0 fm   3.69 m    WCBarrelCell  Transportation
    8     17 m  0.0546 fm  -53.6 cm   3.87 eV      0 eV      0 fm   3.69 m    WCBarrelCell  Transportation
    9     17 m  0.0546 fm  -53.6 cm   3.87 eV      0 eV      0 fm   3.69 m    WCBarrelCell  Transportation
   10     17 m  0.0546 fm  -53.6 cm   3.87 eV      0 eV      0 fm   3.69 m    WCBarrelCell  Transportation
   11     17 m  0.0546 fm  -53.6 cm   3.87 eV      0 eV      0 fm   3.69 m    WCBarrelCell  Transportation
WARNING - G4Navigator::ComputeStep()
          Track stuck, not moving for 10 steps
          in volume -WCBarrelCell- at point (16954.94997,5.464552422e-14,-536.2263466)
          direction: (0.9908703991,-0.0780949745,-0.1098955281).
          Potential geometry or navigation problem !
          Trying pushing it of 9e-10 mm ...
   12     17 m   -70.2 fm  -53.6 cm   3.87 eV      0 eV    900 fm   3.69 m    WCBarrelCell  Transportation
   13   17.1 m   -9.86 mm    -55 cm   3.87 eV      0 eV   12.6 cm   3.81 m    WCBarrelCell  Transportation
   14   18.1 m   -8.92 cm  -66.2 cm   3.87 eV      0 eV   1.02 m    4.83 m    OutOfWorld  Transportation


Now, there are cells inside the rings. The photons are stuck inside the cells. the y-component of the points, where the photos are stuck is < 1e-13cm. Thus in y-direction they are in the centre of the first cell in each ring. If start the replica with an offset, the photos still are stuck in the fist cells. I attached a version of N02 to reproduce this warnings. The number of stuck photos vary between 3 and a few hundred, because the region, where the photons are stuck is very narrow.

This problem seems to be not the same as the original one.
Sorry for mixing this two issues in one bugreport. 
This Problem does not appear for all values of WCBarrelRingNPhi. Changing 360.*deg to 2.*pi solves the problem for the most values, but not 150.

Indeed, the issue you're reporting now is something else.
The adjustment of the geometrical tolerance -is required- according to the extent of your setup and the precision you ask for, especially if introducing such unphysical gap.
The difference in behavior observed when switching from degrees to radians should not happen and is somewhat surprising. I tend to believe that this is most likely a problem in approximation induced by the mathematical system libraries (something we already observed in some cases, particularly on 64 bits systems). Although far from being a solution (this precision issue certainly deserves further investigation!), I would suggest you to stick using radians instead of degrees, since Geant4 internal units are expressed in radians and this would at least avoid an implicit conversion to happen...
Concerning the stuck tracks (rather rare, considering the density of photons generated in your setup), you should consider them harmless; we're aware of such navigation issues on composed replicas (i.e. replicas defined on more than one axis), happening for tracks traveling along surfaces of separation of composed replica components. The artifact is due to the replica navigation algorithm itself which does not take into account of the direction associated to a track. In almost all cases, the navigator itself manages to push successfully the track out of the loop (by issuing a warning though).