... | ... | @@ -38,5 +38,5 @@ This is an as detailed as possible outline of the requirement list for physics p |
|
|
1. in particular thinking about point 6.4.1/2 we have to either further break down the interface, or we define a way to let "SecondariesProcesses" act only in specific cases. Consider a ```thinning``` SecondariesProcess, which should act on the output of ```collisons``` but *not* on the output of ```decays``` etc. Thus, logically we would like to distinguish ```interaction << decay << thinning``` from ```(interaction << thinning) << decay```
|
|
|
|
|
|
Notes from HD:
|
|
|
- Thinning should be handled by a process, not by the sequence. A ThinnedInteractionProcess would derive from the generic InteractionProcess and apply thinning to its output. For the ProcessSequence this is transparent.
|
|
|
- There are two kinds of thinning, which are distinctly different. There is the thinning that drops low-energy secondaries. This should be handled by a process, not by the sequence. A ThinnedInteractionProcess would derive from the generic InteractionProcess and apply thinning to its output. For the ProcessSequence this is transparent. The second kind of thinning happens after the shower has been fully simulated. To safe disk space, the shower core is either removed completely or further thinned as a function of lateral distance to the shower axis. This should be done by the particle writer, it is also not a responsibility of the ProcessSequence.
|
|
|
- Interactions and Decays are very similar and called by the ProcessSequence in essentially the same way. This common aspect of the two classes should be factored into a base class. InteractionProcess and DecayProcess remain distinct, but have a common ancestor, perhaps called InteractionOrDecayProcess. |
|
|
\ No newline at end of file |