|Message: Re: triggering hadronic Inelastic interactions inside ModelTrigger||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 think that a few key points are not clear in the discussion of some detailed aspects of the existing module and of the suer needs and the emerging user implementation.
I will try to step back and summarize my understanding of the relevant capability in fast simulation. Then I note what I see as a new scenario or use case, emphasizing aspects which appear different to the existing one(s).
I see these as necessary steps for understanding how your use case differs from existing Geant4 use cases/scenarios. Once this is clear we can potentially offer advise and suggestions how to use the existing functionality for the new use case (if it can be adapted). Else we will need to consider the needs of your scenario and try to see how to respond with potential new development. (Also note that the fast simulation interface is not the only mechanism for such 'interaction' with the Geant4 system.)
First I try to clarify the existing scenario(s) for fast simulation in G4, and then below to express simply the new scenario/use case for this way of hadronic parameterization.
A. Clarifying existing capability
The current use case or scenario for Fast Simulation has some key characteristics:
- The parameterisation determines when it will trigger using its own criteria, independent of other processes;
- The fast simulation process takes over full control of the relevant step, before other processes occur.
I have checked these key aspects with our fast simulation developer and maintainer.
Other aspects, likely less relevant:
-The fast simulation process calls the trigerring parameterization.
-The parameterization deposits hits.
-The parameterization can propose new tracks (eg a punch-through primary) for further full/detailed simulation.
Note: in this scenario, the Fast Simulation Manager Process must act before any physics processes.
B. Use-case for hadronic shower parameterization
The proposed use-case/scenario for hadronic fast simulation appears to differ from this existing scenario (what Marc tried to call the 'standard' scenario) for Fast simulation. Here are the key points as I currently understand them:
- The parameterization wishes to trigger using the occurrence of an inelastic interaction; - It wishes to take all the energy of the particle exactly before the interaction, and to use it itself (in fact replacing the results of the interaction, as modeled by the relevant Geant4 process.)
Eg if the initial pre-step energy of the step was 72.304 GeV and energy loss (or something else) had reduced it to 72.230 GeV by the Post-Step point (before the interaction occurred or was applied by G4), then it would want to see 72.230 GeV as the energy available for itself.
* Currently identifying the process as the Inelastic interaction does not appear to be enough: sometimes the process does not produce secondaries).
* The trigger now involves checking the results of the interaction, to ensure that secondaries were created (and possibly in the future that more than one resulted?)
Could we try to clarify these points - to establish the differences of the existing capabilities and the ones needed for your case ?
After these, I suggest that we:
- understand how, if possible, the new scenario could utilize existing capabilities, in order to work with existing releases;
- consider having a presentation of the scenario and the new needs at the next Technical Forum (expected mid-July) to make these known more widely and enable a dialog that includes other users who could be interested or potentially affected.
Best regards, John Apostolakis
|Inline Depth:||Outline Depth:||Add message:|