|Message: Bad transportation for suspended tracks||Not Logged In (login)|
Click on the Forum title, e.g. on the "Forums by Category" page, to read a sequence of postings to the Forum and its threads all in one page. If you are only interested in one thread or the thread following a specific posting, click the thread or the posting, which takes you to a smaller page, which contains only the part you are interested in and may be easier to navigate.
Messages are "chained" if there are only replies at the first level, i.e. 1/1.html, 1/1/1.html etc. In case of "chained" messages the message number is replaced by the icon and there is no indentation.
Inline: Display the subject line only or also the text of the posting(s); for the choice "All" the "Outline" choices are switched off.
|1||0||1||no text / full text of posting|
|2||1||All||text for level 1 only / text for All postings|
Outline: Choose the depth of the posting thread, successive toggle controls provide increasing detail.
|1||2||1||2 levels / 1 level (original posting)|
|2||3||2||3 levels / 2 levels|
|3||3||All||3 levels / all levels (all postings)|
I've been tracking a rare and strange bug in our simulation program for the ILC, Mokka, and it seems to be related with a problem in the G4Transportation process when dealing with suspended tracks.
Each time the tracking changes the track being tracked the G4Transportation process has to reset several private attributes. It's done in the beginning of the G4Transportation:: AlongStepGetPhysicalInteractionLength method. In the current Geant4 relase (7.1-patch01) this reset is done if and only if the track step number is equal to 1.
The problem arises when a suspended track comes back to be tracked. In this case the G4transportation doesn't reset these several attributes. So the suspended track restarts with a bad G4Touchable which lets to error in the navigation.
Here you have a example: In this case a back scatter starts at (308,-713,2.5e+03): ... ... 25 308 -715 2.5e+03 0.397 0.00721 0.17 6.28 TPCEnd eIoni 26 308 -715 2.5e+03 0.388 0.00885 0.23 6.51 TPCChamber Transportation 27 306 -715 2.47e+03 0.38 0.00668 27.9 34.4 TPCChamber eIoni
At this point, as it enters in the tracker region, Mokka suspends the track. When it came back to be tracked again we get the following steps:
28 306 -715 2.47e+03 0.379 0.000621 1.85 36.3 SiBarrel Transportation 29 306 -715 2.47e+03 0.358 0.0146 0.0466 36.3 SiBarrel eIoni
The particle was in the TPCChamber volume before being suspended. As soon as it's restarted, the Transportation decides that it's on the boundary of the SiBarrel volume. The problem is that the SiBarrel volume normally is in the Ecal barrel, far away from the TPCChamber. The Ecal barrel starts at R= ~1700 mm! Both volumes are not neighbors, so it should not be a problem of ktolerance on the boundary.
This problem is reported as problem report #820. You can get a patched G4Transportation copy (for 7.1-patch01 release only) by myself in the URL
while waiting for a official one.
|Inline Depth:||Outline Depth:||Add message:|