Adapt RadioPropagator to suit the needs of dens-media and cross-media showers
The current design and logic of the RadioPropagator is as follows:
- for a given particle position and antenna position, the Propagator is called
- it will give back a vector of SignalPaths that connect source and antenna
- the SignalPaths have relevant information that can be queried for the E-field calculation by the Formalism, for example refractive index at source, time delay along path, emit vector and receive vector
This is no longer sufficient in case of signal propagation in dense media with strong refractive index gradients, or for cross-media showers. After some discussion a reasonable change of design would be the following, inspired by how things are done in NuRadioMC (https://github.com/nu-radio/NuRadioMC/blob/develop/NuRadioMC/SignalProp/propagation_base_class.py):
- for a given particle position and antenna position, a Propagator is instantiated
- in its constructor, it will determine the relevant signal paths and store the relevant information
- the Propagator will provide an interface so that the Formalism can query the relevant information to calculate the E-field (such as emit vector, refractive index at source, time delay along path), for every solution found
- the Formalism will calculate the E-field
- then, the E-field needs still to be "propagated" to the antenna, taking into account media effects; this involves in particular
- rotation of the electric field vector such that it is perpendicular to the (-)receive vector at the antenna location
- application of Fresnel coefficients for any media boundaries with discontinuities in refractive index
- application of attenuation factors (could be frequency-dependent)
- (later: application of electric field modifications related to media birefringence)
- for this, the Propagator instantiated earlier will offer a method that applies these effects to the provisional E-field provided by the Formalism
- at the end, the Propagator object is deleted (creation and deletion are not good in terms of thread-safety, maybe can overcome by creating only once and re-using, but the issue is already present in the current design where we create and destry SignalPaths)