... | ... | @@ -41,8 +41,13 @@ Notes from HD: |
|
|
- ProcessSequences should not be created with `operator<<`, but just like `std::tuple`, by passing the elements to ctor. `ProcessSequence(process1, process2, ...)`. The `operator<<` is not good for initialization.
|
|
|
- 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.
|
|
|
- RU: indeed, there a physics-driven thinning that must happen inside the cascade - and it is up to the user to decide what and how exactly he wants to do that. There is *not* one thinning algorithm, there are many options with different applicability. In addition there is output-thinning just to save disk space. This is not physics-driven.
|
|
|
- RU: there is one aspect we should keep in mind: thinning will be applied to a longish list of processes in the cascade, e.g. high-energy hadronic model, low-energy hadronic model, nuclear hadronic model, eventually decays, e.m. pair production, e.m. bremsstrahlung, and maybe others that we don't think about right now. So changing the algorithm should be safe against making simple mistakes of inconsistency. I think ```ThinnedInteractionProcess<ThinAlgo, InteractionAlgo>``` might be good, but also ```ProcessSequence sub_list = (interactionAlog << thinAlgo);```. In the former case they are applied to a particular Process in the latter case to a corresponding piece of ProcessSequence. I think this is completely analogous and just a matter of taste.
|
|
|
- RU: there is one aspect we should keep in mind: thinning will be applied to a longish list of processes in the cascade, e.g. high-energy hadronic model, low-energy hadronic model, nuclear hadronic model, eventually decays, e.m. pair production, e.m. bremsstrahlung, and maybe others that we don't think about right now. So changing the algorithm should be safe against making simple mistakes of inconsistency. I think ```ThinnedInteractionProcess<ThinAlgo, InteractionAlgo>``` might be good, but also ```ProcessSequence sub_list = (interactionAlog << thinAlgo);```. In the former case they are applied to a particular Process in the latter case to a corresponding piece of ProcessSequence. I think this is completely analogous and just a matter of taste.
|
|
|
|
|
|
- HD to RU: No, it is not a matter of taste. Passing thinAlgo to the sequence is bad, because then it is the responsibility of the sequence to pass the thinning algorithm to the processes which need it. The flow of information is less clear and you prevent users from using different thinning algorithms for different processes. This is breaking modularity. The Thinning algorithm has to be provided to the InteractionProcess.
|
|
|
|
|
|
- DB: I am in favour of some kind of Wrapper to apply different thinning algorithms to a Process. This would reduce code duplication quite a bit and is still easy enough to understand. The difficulty here is that the interaction process needs to forward the information which particle was created to the thinning algorithm.
|
|
|
|
|
|
- HD to DB: You can have such a wrapper, but then the underlying processes must have a common interface that the wrapper can use. Which brings me back to my other point, that InteractionProcess and DecayProcess and possibly a future CherenkovProcess should inherit from a common base process.
|
|
|
|
|
|
- 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.
|
|
|
- RU: if we want a common anchestor, it probably should be ```DiscreteProcess```. However, what exactly should it do? The decay has "GetLifetime(projectile)" "DoDecay(projectile)" while the interaction has "GetInteractionLength(projectile)", "DoInteraction(projectile, target)". Note: the "target" in the last call is still missing but should be added for physics reasons.
|
... | ... | |