SPR1-1869: Pre_g solutions are relative to the mean

[KimMcAlpine]

Previously pre_g gain solutions were altered to be relative to the first solution per antenna. This was intended to make the solutions more robust to poor antennas, while still allowing the pre_g gain solution to remove any gain drift across the calibrator scan.

Unfortunately this makes the solutions very sensitive to the quality of the first dump in the scan. If this dump is flagged (as can easily happen if an antenna is straggling) then all solutions relative to this flagged (NaN'ed) solution will become NaN. To prevent this the solutions are now relative to the mean solution for scan interval.

[ludwigschwardt]

What about the pre-G solve in polcal here? It lacks a relative=True setting, which seems wrong. Not that anyone uses this tag, right? 😛

[KimMcAlpine]

What about the pre-G solve in polcal here? It lacks a relative=True setting, which seems wrong. Not that anyone uses this tag, right? stuck_out_tongue

I don't think this one should be 'relative'. In the case of the polcal tag you want the data to be fully parallel hand calibrated so that all the XY baselines have the same phase and delay, (and all the YX baselines are the complex conjugates of the XY baselines). I think then all the baselines should have the phase = difference of phase between X and Y at the refant, and the delay equal to the difference of the delay between X and Y at the refant. This allows all the baselines to averaged together to increase the SNR for the delay fit on the polarisation calibrator. If you don't apply a proper gain correction then each baseline will have a different phase, which might cause some strange effects when you average all the baselines together. In this case the pre-g solution is acting as an actual gain calibration, that we just don't want to add to our calibration store.

[ludwigschwardt]

Cool, good to know!