Refactoring DecayProcess<T> and decay model selection.

As per the discussions during the last corsika-devel meeting (03/06), I've started work on refactoring DecayProcess<T> and the current concrete implementations (SIBYLL::Decay, Pythia::Decay, TAUOLA). In particular,

1. Remove GetLifetime() from DecayProcess<T> (since it is identical across all implementations) and compute the boosted decay time in Cascade::Step. This was previously discussed in #134.
2. Remove the duplicate book keeping in the Pythia, Sibyll, and TAUOLA implementations to decide on which model should decay which particle. This was previously discussed in #255.

There are several important design decisions that should be made before I start work on 2). Primarily,

1. Do we want the model selection to be "by particle" (so each particle is handled exclusively by one model) or, as suggested in #134, do we want to allow for different decay modes to be assigned to different decay models using the tabulated branching fractions? The first option is more straightforward to implement and might be more self-consistent? Is there a clear advantage to breaking up the decay model by branching fraction?
2. Do we want this decision to be made at runtime or at compile-time? There is obviously additional flexibility with being able to configure this as part of the simulation (especially once we start shipping C8 binaries as opposed to sources) but there is a small run-time cost with mapping particle codes to decay implementations. With compile-time polymorphism, the mapping from particle to decay model can be done at compile time so we don't occur any runtime cost for deciding on the decay model for a given particle type.

Does anyone have any thoughts or comments on the above? My inclination is for a "by particle" runtime model but I am open to suggestions!

(cc'ing some people who were involved in the two prior issues: @riehn @rulrich)

added Development Discussion labels

I would tend to keep it flexible as it is right now with potentially multiple processes handling the same decaying particle. One application is studying new physics: Let's say you come up with a new, additional decay channel (concrete example:

\pi^0, \eta, \ldots \rightarrow

millicharged particles). Then you just write a new process implementing just this additional decay channel with without having to care about anything else.

If particles are unintentionally handled by multiple processes (say, you have both Pythia and TAUOLA and both feel responsible for

\tau^\p,

decays), I think a good solution is sth. just like what we already have for interactions: the SwitchProcess, which currently decides based on energy which process to select. This could easily be extended for generalized predicates like particle ID, and handling decays in addition to interactions. This has the advantage that you do not need to know how to configure or modify each process to ignore the particles it should not handle.

mentioned in merge request !200 (closed)

changed milestone to %First full release: CORSIKA 8.0.0

mentioned in issue #254 (closed)

changed milestone to %Rework of particle decays

mentioned in merge request !462 (closed)