|Message: Re: Step crosses a geometrical boundary and does not stop (from Run and Event forum)||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)|
Thank you for your clear message. What you report is unexpected, and I have no simple explanation.
You may have uncovered a problem, likely in a solid, but I would like to double check some things you report - and suggest some additional checks to make. There is always the possibility of a badly formed geometry (at the lowest level or some other level above that) which could lead to different results.
0) Could you please provide the parameters of the key solids (either posting to hNews or in a direct email) so that we can double-check the relevant solid(s) as you defined them.
You wrote: > "I know that physiBreast finishes at Z=61 mm and that Z=62.4 mm is in "physiSkin", so the latter output is the correct one."
This is very suspicious - if your understanding of the geometry description is correct. It would seem that an intersection is missed by the solid's DistanceToOut method, if this is the case. Given the parameters of the solid it should be easily possible to check this. The simplest way to confirm this is to use the following:
2) Could you please set the navigator to a higher verbosity /geometry/navigator/verbose 3 and report on the tracking (preferably providing a file with the output from this run, rather than copying the text into a posting)
3) Could you try to run in check mode: - use the geometry check_mode and set verbose to 1, in case a problem is found somewhere in the geometry /geometry/navigator/check_mode 1 /geometry/navigator/verbose 1
Likely this will be enough to double check that there is no obvious problem in your setup.
3) Could you experiment with the different ways of calling Locate Instead of calling it theNavigator->LocateGlobalPointAndSetup(worldPos, 0, false, true); allow the Relative search to be "true" and see whether the result remains the same.
G4VPhysicalVolume* LocateGlobalPointAndSetup(const G4ThreeVector& point, const G4ThreeVector* direction=0, const G4bool pRelativeSearch=true, const G4bool ignoreDirection=true);
I will appreciate if you provide the results of these two changes. ******* Finally, just in case these are not enough to locate the problem, it could aid to:
5) I expect that you identified this as an issue before adding the new code in ProcessHits which calls the G4Navigator. Calling the Navigator during the event loop is fragile, especially for points outside the current volume and on surfaces. So it will be best to double check the results which you get outside the event loop. I suggest to try to check the location of the key points: ### World Position: 68.80902495440318 -191.8953954647168 54.33532473714037 navigator volume: physiBreast ### World Position: 72.85229590945139 -195.7155628014604 62.35389344721722 navigator volume: physiSkin <-------------
If you can simply locate these points at a different point during the run, e.g. in a EndOfTrack action, or in a separate program which does not call the Geant4 Run/Event/Tracking but just sets up the geometry, initialises and make these calls directly, it would shed light on the issue of the location of these points without any possible interference with the continuation of these tracks.
Feel free to contact me/us with partial information (e.g. from the first two points) in order to see whether it identifies the underlying issue.
Best regards, John Apostolakis