New design of continuous processes

There are several issues with the current design of continuous processes:

• On the one hand, they are used to influence propagation (applying energy losses), i.e. they modify the particle (but not the track object, which leads to inconsistencies). On the other hand, radio and Cherenkov just "observe" the particle/track.
• different aspects of propagation are handled in several places (cascade, tracking, continuous processes)
• It is not well-defined what to which state the Particle argument of continuous processes refers: beginning, end, sth. else?
• The track object yields dense information only about some parts of the state (position, speed). Furthermore it does not take into account all influences on the propagation, in particular energy losses are not incorporated.

I propose the following redesign:

1. split ContinuousProcess into two:

• Processes which influence the motion. They take a state as parameter and return a differential change of that state. I will refer to this category as force process unless a better name comes up.
• Purely observing processes. They take a constant finite (in contrast to differential) track object as defined below.

2. The tracking part integrates the equations of motion

\frac{\mathrm d s}{\mathrm d t} = \sum_{i-\text{th force process}} \frac{\mathrm d s}{\mathrm d t}\Big\vert_i \qquad \text{(1)}

Here, s(t) refers to the continuous part of a particle state, i.e. position, 4-momentum, time - in contrast to constants like PID. The integration happens in time-discrete steps from t_0 to t_1. Moreover, a track object is created. It provides a handle to access s(t_0) and s(t_1) as well as an interpolation \tilde s(t_0 \leq t \leq t_1) and of couse the constant properties.

Steps:

1. There needs to be a way to extract the continuous state from a particle on the stack as independent, copyable and modifyable object in memory (not just this reference-to-stack-entry-thingy what a particle currently is). Essentially it would be like a std::tuple<TimeType, Point, MomentumVector>. For eq. (1) there needs to be a corresponding type with one temporal dimension less in the units. As there are several equivalent representations of the state, we need to think what is the best. Also: What about redundant information (energy is fixed by on-shellness, momentum suffices)
2. Force processes need to be implemented.
3. The sum in eq. (1) needs to be implemented.
4. An integrator/solver is needed. We probably better implement one ourselves because what we are doing is more than just solving some ODE system. We have to obey constraints like energy cuts (generally speaking, we would like to integrate right up to the point where a condition on a dependent variable is met, not further), we work with dimensionful quantities. The solver needs to provide dense output and should be adaptive.
5. A track class needs to be implemented.