JSKenyon
commented
1 year ago Just following up on this before the long weekend as it is currently a WIP. Loading an existing parameterised term is not difficult - all the needed information is stored in the gain datasets. I just need to add the code to propagate the initial values into the solvers.
The actual problem (well, not really a problem but the reason that this isn't trivial) stems from the fact that we have to interpolate angles. This is not supported in most common interpolation routines e.g. scipy.interpolate, and also means that we have to explicitly provide a means of differentiating between the angle and non-angle cases.
As a random consequence of checking QC's current behaviour, I have convinced myself that interpolating in real and imaginary is not the correct thing to do in almost all cases so I will be removing that option.
I have just written my own custom numba implementation of bilinear interpolation which is slightly/much (when using threads) faster than scipy.interpolate. This also makes the "angle-like" case easier to handle. That said, I am still exploring various alternatives in an effort to simplify the code.
The final hurdle is that the interpolated parameters are not particularly useful on their own - we also require the gains associated with those parameters. This means that each gain has to have methods to support evaluation their own parameterization. This functionality already exists inside the solvers but it may require a fair amount of work to expose it in a sensible fashion, as the evaluation needs to know about the various mappings.
To summarize, I am working on it but I am confident that the new code will be substantially more reliable/correct than the old.
As discussed, it is currently a little hacky to do an additional solve when loading in a parametrised term. The problem is that gains and not parameters are interpolated when loading parametrised terms. There should at least be a way to initialise parameters directly when no interpolation is required but I also believe that parameters can be interpolated as long as we expect them to be smooth. This does get a little complicated because different parametrisations may require different interpolation strategies but maybe the logic for interpolating a specific type of term can live in the dedicated gain classes? Note the current workaround is to load without solving and then add an additional identical term to the chain. The two can be combined by using the new flexible net gains specification