@@ -38,6 +38,7 @@ 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:
- 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.
