Message: Re: Problem with very small stepsize caused by transportation process? Not Logged In (login)
 Next-in-Thread Next-in-Thread
 Next-in-Forum Next-in-Forum

None Re: Problem with very small stepsize caused by transportation process? 

Forum: Fast Simulation, Transportation & Others
Re: Note Problem with very small stepsize caused by transportation process? (Henning Gast)
Re: None Re: Problem with very small stepsize caused by transportation process? (John Apostolakis)
Date: 12 Jan, 2007
From: Henning Gast <Henning Gast>

Dear John,

thank you for your detailed proposals. Please see my findings below:

John Apostolakis wrote:
> *** Discussion title: Fast Simulation, Transportation & Others
> Email replies to PublicHyperNews@slac.stanford.edu must include:
>   In-Reply-To: <"/fastsim/22/2"@geant4-hn.slac.stanford.edu>
>   Subject: ...change this to be about your reply.
> 

> From the values of the position, it is my guess that there is a boundary
> exactly at this z value:
>  Position - z (mm)   :             -285.232
> Can you confirm whether the point is at a boundary of one of the
> TrdLayer volumes at this point ? 

Yes indeed, I find that the problem seems to occur at the boundary 
between two TrdLayer volumes.

> If so, it would be very useful to create a custom sub-class of
> G4SteppingVerbose that prints out the copy number of the current
> TrdLayer (and potentially the parent volume's copy number as well.) This
> way we can check whether it is confused by bouncing between different
> copies at their interface.

That is exactly what happens:

#Step#      X         Y         Z        KineE    dEStep   StepLeng 
TrakLeng              Volume          Process
   514   31.1 cm  -35.7 cm  -23.2 cm    990 keV1.45e-07 eV  1e+03 fm 
2.94 cm               TrdLayer   Transportation
PreStepPoint:
  at 0: TrdLayer  replica 3 copy 3
  at 1: TrdLowerSuperLayer  replica 0 copy 0
  at 2: Tracker  replica 0 copy 0
  at 3: World  replica 0 copy 0
PostStepPoint:
  at 0: TrdLayer  replica 2 copy 2
  at 1: TrdLowerSuperLayer  replica 0 copy 0
  at 2: Tracker  replica 0 copy 0
  at 3: World  replica 0 copy 0

#Step#      X         Y         Z        KineE    dEStep   StepLeng 
TrakLeng              Volume          Process
   515   31.1 cm  -35.7 cm  -23.2 cm    990 keV1.47e-07 eV 1.01e+03 fm 
  2.94 cm               TrdLayer   Transportation
PreStepPoint:
  at 0: TrdLayer  replica 2 copy 2
  at 1: TrdLowerSuperLayer  replica 0 copy 0
  at 2: Tracker  replica 0 copy 0
  at 3: World  replica 0 copy 0
PostStepPoint:
  at 0: TrdLayer  replica 3 copy 3
  at 1: TrdLowerSuperLayer  replica 0 copy 0
  at 2: Tracker  replica 0 copy 0
  at 3: World  replica 0 copy 0

#Step#      X         Y         Z        KineE    dEStep   StepLeng 
TrakLeng              Volume          Process
   516   31.1 cm  -35.7 cm  -23.2 cm    990 keV1.45e-07 eV  1e+03 fm 
2.94 cm               TrdLayer   Transportation
PreStepPoint:
  at 0: TrdLayer  replica 3 copy 3
  at 1: TrdLowerSuperLayer  replica 0 copy 0
  at 2: Tracker  replica 0 copy 0
  at 3: World  replica 0 copy 0
PostStepPoint:
  at 0: TrdLayer  replica 2 copy 2
  at 1: TrdLowerSuperLayer  replica 0 copy 0
  at 2: Tracker  replica 0 copy 0
  at 3: World  replica 0 copy 0

#Step#      X         Y         Z        KineE    dEStep   StepLeng 
TrakLeng              Volume          Process
   517   31.1 cm  -35.7 cm  -23.2 cm    990 keV1.47e-07 eV 1.01e+03 fm 
  2.94 cm               TrdLayer   Transportation
PreStepPoint:
  at 0: TrdLayer  replica 2 copy 2
  at 1: TrdLowerSuperLayer  replica 0 copy 0
  at 2: Tracker  replica 0 copy 0
  at 3: World  replica 0 copy 0
PostStepPoint:
  at 0: TrdLayer  replica 3 copy 3
  at 1: TrdLowerSuperLayer  replica 0 copy 0
  at 2: Tracker  replica 0 copy 0
  at 3: World  replica 0 copy 0

... and so on ...


> After this, please try to call the Navigator's ComputeStep method
> yourself. If it returns zero, you are seeing the same problem.
> 
> I suggest to repeat
>     Locate( point, direction, ...
>     step= ComputeStep( point, direction, ...
>     point += step * direction; 
> a few more times (say 20 times in a loop) to confirm that the problem
> is with Navigation, not the field.
> 

I put the following code in my SteppingAction:

     G4cout << "LOOP:" << G4endl;
     for( G4int i=0 ; i<20 ; ++i ){

       G4cout << " physVol: " << navigator->LocateGlobalPointAndSetup( 
position, &direction )->GetName() << G4endl;
       G4double safety = 0.0;
       G4double step = navigator->ComputeStep( position, direction, 
1.0*km,safety);
       G4cout << "STEP: " << step/mm << " mm." << G4endl;
       position += step*direction;
       G4cout << " new pos: " << position << G4endl;

     }

The result is curious:

LOOP:
  physVol: TrdLayer
STEP: 3.7272604e-09 mm.
  new pos: (311.25547,-357.47662,-231.744)
  physVol: TrdLayer
STEP: 1e-09 mm.
  new pos: (311.25547,-357.47662,-231.744)
  physVol: TrdLayer
STEP: 1e-09 mm.
  new pos: (311.25547,-357.47662,-231.744)
  physVol: TrdLayer
STEP: 1e-09 mm.
  new pos: (311.25547,-357.47662,-231.744)
  physVol: TrdLayer
STEP: 1e-09 mm.
  new pos: (311.25547,-357.47662,-231.744)
  physVol: TrdLayer
STEP: 167.71476 mm.
  new pos: (149.96333,-397.5,-254.35406)
  physVol: TrdLayer
STEP: 0 mm.
  new pos: (149.96333,-397.5,-254.35406)
  physVol: TrdLayer
STEP: 0 mm.
  new pos: (149.96333,-397.5,-254.35406)
  physVol: TrdLayer
STEP: 0 mm.
  new pos: (149.96333,-397.5,-254.35406)
  physVol: TrdLayer
STEP: 0 mm.
  new pos: (149.96333,-397.5,-254.35406)
  physVol: TrdLayer
STEP: 0 mm.
  new pos: (149.96333,-397.5,-254.35406)
  physVol: TrdLayer
STEP: 0 mm.
  new pos: (149.96333,-397.5,-254.35406)
  physVol: TrdLayer
STEP: 0 mm.
  new pos: (149.96333,-397.5,-254.35406)
  physVol: TrdLayer
STEP: 0 mm.
  new pos: (149.96333,-397.5,-254.35406)
  physVol: TrdLayer
STEP: 0 mm.
  new pos: (149.96333,-397.5,-254.35406)
  physVol: TrdLayer
STEP: 9e-10 mm.
  new pos: (149.96333,-397.5,-254.35406)
  physVol: TrdLayer
STEP: 9e-10 mm.
  new pos: (149.96333,-397.5,-254.35406)
  physVol: TrdLayer
STEP: 9e-10 mm.
  new pos: (149.96333,-397.5,-254.35406)
  physVol: CFCtube
STEP: 10.476048 mm.
  new pos: (139.88846,-400,-255.76636)
  physVol: CFCtube
STEP: 0 mm.
  new pos: (139.88846,-400,-255.76636)



> The code for propagating in a magnetic field should take care for
> difficult cases, where it can be unclear what volume a track is actually
> crossing. In this case, though, it appears that it is the Navigator
> which is having difficulties.
> 
> I noted that you said that "" a particle should never really enter a
> "TrdLayer" volume explicitly because the daughter volume "TrdRadiator"
> in each "TrdModule" fills the upper part of the layer completely. ""

I have to change my statement regarding this point. As a matter of fact, 
the problem occurs most frequently (only??) in a part of TrdLayer that 
is not filled by further daughters. You see, the inner part of a 
TrdLayer is filled with TrdModules but there is some remaining gap at 
the fringe which is just filled with air.

> This seems to indicate that it is experiencing significant difficult at
> this level. What type of volume is a 'TrdModule'? A box, a tubs, or
> other ?? Also what is the TrdRadiator ?
>  

TrdLayer, TrdModule and TrdRadiator are all simple boxes. TrdLayer is a 
G4PVReplica slicing a TrdSuperLayer into eight divisions along z.

Cheers

Henning


Inline Depth:
 1 1
 All All
Outline Depth:
 1 1
 2 2
 All All
Add message: (add)

 Add Message Add Message
to: "Re: Problem with very small stepsize caused by transportation process?"

 Subscribe Subscribe

This site runs SLAC HyperNews version 1.11-slac-98, derived from the original HyperNews


[ Geant 4 Home | Geant 4 HyperNews | Search | Request New Forum | Feedback ]