|Message: Stepping Problem with Shared Boundary||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)|
In my calorimeter simulation, I generally have two material boundaries that "touch" each other--like a liquid Xenon tower against its Aluminium cryostat. Occasionally, a particle apparently becomes "stuck" between the boundaries. I'm guessing a step places the particle at the interface. At this point, the stepping process enters an infinite loop.
I'm not sure whether:
1: The program cannot decide which material its in. or 2: Each following steps remain in the plane of the interface and the particle is bouncing around between the two materials.
Each step is identical except for the volume it reports it is in, which swaps between the two volumes at the interface.
Currently I'm handling the problem by doing:
if (pStep->GetTrack()->GetCurrentStepNumber() > 9999) pStep->GetTrack()->SetTrackStatus(fStopAndKill);
in my G4SteppingAction::UserSteppingAction(const G4Step * pStep). However, I believe this will result in the loss of the particle's track and energy deposit, resulting in a loss of precision in my analysis.
While this is disturbing, it is fairly uncommon to occur. Still, it seems that there should be a solution, like:
1: randomly selecting the material and sticking with it 2: determining which material would be the most likely interactor 3: analyzing both until it leaves the interface or interacts with one of the materials.
Currently, I'm using G4 v5.2 and am planning to upgrade to v6. As I've seen this also appear in other simulations, has this problem been addressed yet?
|Inline Depth:||Outline Depth:||Add message:|