Closed IanHeywood closed 1 year ago
It should b a simple fix, I'll do it tomorrow...
@IanHeywood could you check the issue-428
branch please?
I know how you got into uncharted waters here: my own workflow has been to use a standard complex-2x2
gain with --load-from and intervals of 1,1. It is a little-documented but cool feature that the gain tables generated by f-slope can also be loaded by a standard gain machine... whereas you took the far more obvious (to the non-developer) route of using the same kind of f-slope machine to load the gains into, and that's where the bug lurked.
Anyway please carry on with --k-type f-slope --k-load-from
, as this really needs to be tested properly, but know that you have a working fallback.
Just to clarify: Will using 1,1
and --load-from
apply the nearest solution in time/freq?
Interpolation requires --xfer-from
?
Not exactly. -load-from
will throw an error if the grids (by which I mean the time/frequency intervals derived from the underlying data grid) don't match the table exactly. The idea was that you would use -load-from
when you're sure that you intend to be using solutions from exactly the same field, as is, no interpolation required. (And so you presumably do want to see an error message if this is not the case, because that means something went screwy. At least that was the idea).
-xfer-from
will happily interpolate all over the place, no matching grids needed.
One wrinkle here is that slope solutions with timeint=N, freqint=0 will result in a gain solutions table with a grid of timeint=N, freqint=1 (since it unrolls the frequency slope implicitly.) Hence, intervals of 1,1 are used above for loading (assuming 1,0 was used for solving.)
I've generated f-slope K solutions and now I'm trying to apply them whilst I solve for complex-2x2 G solutions in a second run, but it crashes with the following:
I'm hoping this is possible to save having to write out intermediate visibilities and play musical columns with the MS, but maybe it isn't...
Here is the parset: