As discussed with John, it seems that sometimes the first track in a run encounters a geometry problem. The G4Tracks enters a volume, and is not able to exit from it than a lot after the physical size of the volume.
To provide some more context of this problem report, I copy below some of the information from the original communications: Several communications have been exchanged, but the problem remains. Thanks again for your feedback, John Apostolakis ---------- Original problem information ---------- > Date: Mon, 27 Oct 2003 19:11:03 +0100 > From: Tommaso Boccali <Tommaso.Boccali@cern.ch> [ snip ] > > Reading > /afs/cern.ch/cms/Releases/COBRA/COBRA_7_4_1/src/Data/Generator > Data/HepPDT/particle_table > > > ************************************************************** > ******************************************* > * G4Track Information: Particle = mu-, Track ID = 1, > Parent ID = 0 > ************************************************************** > ******************************************* > > Step# X(mm) Y(mm) Z(mm) KinE(MeV) dE(MeV) StepLeng TrackLeng NextVolume ProcName > > 0 0.00476 0.0153 -86.6 3.72e+05 0 0 0 BVTB initStep > > // > // track has the first step in x=0, y=0, z=-9 cm (well, it is not really > // the vertex, but the impact on the beam pipe) > > 1 -28.4 5.87 -191 3.72e+05 0 108 108 BTUB Transportation > 2 -28.5 5.89 -191 3.72e+05 0.0911 0.389 108 BTUB MuIoni > 3 -28.5 5.9 -191 3.72e+05 0.0127 0.0796 109 BTUB MuIoni > 4 -28.9 5.97 -192 3.72e+05 0.31 1.41 110 BTUB MuIoni > 5 -29.2 6.03 -194 3.72e+05 0.228 1.1 111 BEAM Transportation > 6 -30.4 6.27 -198 3.72e+05 0.000782 4.48 116 PBXL Transportation > 7 -32.1 6.64 -204 3.72e+05 0.00141 6.72 122 PBXL MuIoni > 8 -36.2 7.48 -219 3.72e+05 0.00289 15.6 138 PBS1 Transportation > 9 -36.3 7.49 -220 3.72e+05 0.0555 0.186 138 PBS2 Transportation > 10 -36.4 7.51 -220 3.72e+05 0.0924 0.373 138 PBXL Transportation > 11 -40.3 8.31 -234 3.72e+05 0.00261 14.8 153 PX1B Transportation > 12 -41.3 8.52 -238 3.72e+05 0.00067 3.79 157 PXBC Transportation > 13 -44.7 9.22 -250 3.72e+05 4 13 170 PX1B Transportation > 14 -44.7 9.22 -250 3.72e+05 4.79e-08 0.00024 170 PXBP Transportation > 15 -45.3 9.34 -252 3.72e+05 0.592 2.16 172 PXBH Transportation > 16 -45.4 9.38 -253 3.72e+05 0.339 0.671 > 173 PXBD Transportation > 17 -45.6 9.42 -254 3.72e+05 0.227 0.725 > 174 PXBD MuIoni > > // > // here it is the first step in a sensitive detector, which > // fires the on demand creation of the NS > // > > Entering a new Step 0.227405 PXBD 0xc302db8 > POSITION GLOBAL Entry (-45.4385,9.37743,-253.092) Exit > (-45.6292,9.41664,-253.79) > Creating a TrackerSimHitNumberingScheme > Building the TrackerSimHitNumberingScheme map > TrackerSimHitNumberingScheme: numbering detectors with > SensitiveDetector=TkAccumulatingSensitiveDetector > TrackerSimHitNumberingScheme maps deleted from memory. > Before Sort: 20188 detectors recognized. > Created TrackerSimHitNumberingScheme; results in 20188 > detectors numbered. > TouchableTo History: got 20188 sensitive detectors from > TrackerSimHitNumberingScheme. > TouchableToHistory: mapped 20188 detectors to G4. > TrackerSimHitNumberingScheme maps deleted from memory. > OLD (d,t) = (-1,0), new = (11179,1) return 0 > Created PSimHit: mu- 11179 1 0.000227405 > (0.134465,-1.96416,0.015) > (0.135016,-2.03402,-0.00445895) > > // > // ok, first hit created, we go to the next step > // > > 18 -45.9 9.46 -255 3.72e+05 0.306 0.884 174 PXBD MuIoni > > Entering a new Step 0.305539 PXBD 0xc302db8 > POSITION GLOBAL Entry (-45.6292,9.41664,-253.79) Exit > (-45.8617,9.46446,-254.642) > OLD (d,t) = (11179,1), new = (11179,1) return 1 > closeHit: distance = 9.31323e-10 > Before : 0.000227405 > Updating: new exitpoint mu- (0.135687,-2.11921,-0.0281869) > new energy > loss 0.000305539 > Updated PSimHit: 11179 1 0.000532944 (0.134465,-1.96416,0.015) > (0.135687,-2.11921,-0.0281869) > // > // this is concatenated to the first one: (return 1 + closeHit) > // you see, here we are already outside a normal pixel > // detector: local z is -281 um > // > > .... and we go on! > > ... skipping > > 46 -60.8 12.5 -309 3.72e+05 1.49 4.56 231 PXBD MuIoni > > at this point, G4 claims it is in a PXBD detector but > position (global) > is -6 cm, 1.2 cm, z=-31 cm so in reality outside it! > > .... skipping > > 357 -191 39.1 -786 3.71e+05 0.493 1.52 > 726 PXBD MuIoni > > here global x = -19 cm , y = 4 cm, z = -79 cm > > ... skipping > 369 -196 40.2 -806 3.71e+05 0.832 2.71 > 747 PXBD MuIoni > // > // finally, after 370 steps INSIDE the pixel detector, the > muon goes to TID > // x = -20, y = -8, z=-81 cm > // > // the simhit in local coords the pixel hit has now entry, exit > // (0.134465,-1.96416,0.015) (0.552616,-57.2807,-15.392) (cm) > // > // > // the last step in Pixel Detector with a little more verbosity is > // > > > ++List of invoked processes > 1) Transportation > 2) msc > 3) MuIoni > > ++G4Step Information > Address of G4Track : 0xba2e7e0 > Step Length (mm) : 0.547 > Energy Deposit (MeV) : 0.132 > > -------------------------------------------------------------- > StepPoint Information PreStep PostStep > > -------------------------------------------------------------- > > Position - x (mm) : -196 -196 > Position - y (mm) : 40.2 40.2 > Position - z (mm) : -806 -806 > Global Time (ns) : 2.49 2.49 > Local Time (ns) : 2.49 2.49 > Proper Time (ns) : 0.000707 0.000707 > Momentum Direct - x : -0.263 -0.263 > Momentum Direct - y : 0.0534 0.0534 > Momentum Direct - z : -0.963 -0.963 > Momentum - x (MeV/c): -9.77e+04 -9.77e+04 > Momentum - y (MeV/c): 1.98e+04 1.98e+04 > Momentum - z (MeV/c): -3.58e+05 -3.58e+05 > Total Energy (MeV) : 3.71e+05 3.71e+05 > Kinetic Energy (MeV): 3.71e+05 3.71e+05 > Velocity (mm/ns) : 300 300 > Volume Name : PXBD PXBD > Safety (mm) : 0 0 > Polarization - x : 0 0 > Polarization - y : 0 0 > Polarization - Z : 0 0 > Weight : nan nan > Step Status : PostStep Proc Geom Limit > Process defined Step: MuIoni Transportation > > -------------------------------------------------------------- > > ... skipping > > > 370 -196 40.2 -806 3.71e+05 0.132 0.547 747 SVTX Transportation > 371 -216 44.1 -876 3.71e+05 0.0156 72.6 820 SPUP Transportation > 372 -217 44.5 -883 3.71e+05 2.09 7.45 827 TSFX Transportation > > ... skipping... > > 397 -266 54.4 -1.06e+03 3.71e+05 0 0.208 1.01e+03 SCG1 Transportation > > and reaches the TID detector at > > POSITION GLOBAL Entry (-225.48,46.1399,-912.622) Exit > (-225.528,46.1497,-912.8) (mm) > with local coordinates in the TID frame > (-1.94135,-5.535,0.00282753) (-1.94116,-5.53004,-0.015) (cm) which > not eve ok (at least it seems to me) since the entry point is > not on the > face of the detector (???). > > > all the other hits appear to be ok.... > > by the way, the first mu simhit is > (0.134465,-1.96416,0.015) (0.552616,-57.2807,-15.392) (cm) > with global exit > (-196.442,40.2494,-806.257) (mm) > > > reading with ORCA, I read > LPos 0.134465 -1.96416 0.015 0.552616 -57.2807 -15.392 > and transform global exit to -19.6442 4.02494 -80.6257 (cm) using the > DetUnit > so all the transformations / DB interactions are ok > > Tommaso **** 2nd information **************** Some more info [for] today [late October 2003]: - maybe it was not clear, but this [problem] happens only in the first track of the first event of a G4 run! (20 times in 20 cases we have seen it...) Has the problem you are referring to anything to do with initialization of the geometry? (By the way, we know this since I have checked the (x,y,z) local position of ~4 M hits, and only in these 20 cases local z is not within the detector shape) - PXBD is a <Box name="PXBD" dx="8.1*mm" dy="150*mum" dz="3.225*cm"/> and we have ~ 720 of them (I mean 720 separate PhysicalVolumes) Since the geometry we use is a conversion from another format, it is a plain file and no parameterizations are present. - I do not think it is a overlap problem, since as I told you it happens only in the first event. - I have no idea about boolean solids, but I will ask relevant persons. My first guess is no, since this volume is very close to the beam line... thanks a lot and I am eager to provide as many info as you ask; unluckily today I am on the hardware side of the moon.... at the moment, I have simply put the out from the event with problems with /tracking/verbose 3 in /castor/cern.ch/user/t/tboccali/out3.gz
Investigating the apparent spurious hit with Tommasso we have realised the source of the problem: in the relevant SensitiveDetector/Hit class the G4Navigator is used in a manner in which upsets its state for Geant4 transportation/tracking. I explain more below and try to document the necessary changes for this case (and others like it.) The issue --------- In creating the hit classes, the User class calls the Navigator to locate several volumes. It does this on the first hit of this detector, so it can occur on the first track of the first event or at some other 'random' early time. The Navigator calls upset the state of the Navigator - and the state is not reset before the next calls that are made in tracking. So the G4 geometry is completely confused and incorrect answers result. This type of use is fragile, so we suggest to examine other similar user code to check that it does not occur there. We intend also to improve the documentaion of this restriction. The preferred solution ---------------------- Since Geant4 6.0 it is possible to use two G4Navigators with the same geometry - and they will not confuse each other. There is no state stored in the physical / logical / solid volumes any more - while for Geant4 5.2 and before a backpointer in a physical volume identified the mother's physical volume and could be used by G4 and the user code. To avoid confusing the G4Navigator used for tracking you can create another one: G4Navigator* theNavigator = G4TransportationManager::GetTransportationManager()->GetNavi gatorForTracking(); G4VPhysicalVolume* theWorld= theNavigator->GetWorldVolume(); G4Navigator newNavigator(); newNavigator->SetWorldVolume( theWorld ); and then you can use it and let it go out of scope, when you do not need it. Also you can create (new) it if you prefer and keep it if you like without side-effects. Use the new Navigator for your other purposes. Another solution, less elegant, also good for old versions of Geant4 (pre-6.0) ----------------- Another way to get around this fragility of the Navigator (ie the assumptions in its use) is to re-locate the particle/track after you have used the 'tracking Navigator'. Locating it with the current step's PostStepPoint position and direction will put it in the state in which the G4 system expects it to be at the end of a step. I expect that the changes to use either solution are not very big for most use cases.
