[daip] CLCAL: interpolation over blanked values

[Eric Greisen]

Olaf Wucknitz wrote:
> Hello,
> 
> I am (not for the first time) having problems when interpolating or 
> extrapolating calibration solutions from a calibrator to target sources.
> Interpolation can of course only be done between good solutions. The 
> problem occurs if there are blanked solutions at either end of the scan. 
> In such a case CLCAL should neglect these values and instead interpolate 
> between the next good values, but this is not the case.
> This seems to be true for interpolation and extrapolation.
> 
> A typical example is the extrapolation from the last calibrator scan to a 
> target scan starting directly after it. If the last values of the 
> calibrator are blanked, no solutions are extrapolated.
> 
> Currently I am smoothing the solutions a bit (with DOBLANK=0), which 
> unblanks most (but not all) of the bad values. 
> 
> My current workaround is to call SNSMO before CLCAL and do the wanted 
> smoothing (DOBLANK=0) there. After that I call CLCAL with DOBLANK=1 and 
> extended smoothing to unblank all values. This seems to work, but a better 
> solution would be to fix CLCAL so that its interpolation interprets 
> blanked solutions in the same way as non-existing entries.
> 
> 
> I remember having related problems with blanked solutions in SNSMO in 
> July 2003 when the phase wrap was handled incorrectly around 
> blanked solutions. That was corrected by Eric (11363. July 30, 2003).

I have looked at this issue some, but I have decided that the software 
is acting as intended.  Blanked solutions are viewed as serious and must 
be dealt with prior to application of an SN table.  One choice would be 
to introduce a second smoothing option into CLCAL which would do an 
additional smooth - presumably over a long time range to replace all 
blanked solutions remaining after the first smooth over a short range.
The confusion - and user anger - that arose when I cleaned up CLCAL to 
separate smoothing of SN from application of SN suggests that I should 
not introduce further complications in CLCAL.  This is an area that can 
cause serious troubles in user data and users should probably be much 
more careful - as you are being - than I suspect that they are.

Eric Greisen