[daip] gain missing in APCAL

[Amy Mioduszewski]

Paul and I looked at the sniffer plots for this project and the scan with the 
weird freq setup (IF1-4: 22GHz; IF5-8: 0GHz) is seen in the autocorrelation 
plots.  So we think the rdbe on HN failed to setup correctly for that scan, 
which is/was an infrequent but known problem with the VLBA.  So the spurious 
autocorrelations are real.

Also, FREQIDs not IFs, there is one FREQID with S/X and the second one is just 
wrong, was never observed and caused by one of the antennas misbehaving.

Amy

On 09/17/2014 02:07 AM, Arnaud Collioud wrote:
> Hi Amy,
>
> Thank you! That makes sense now!
> To avoid this, I will probably be more careful in the separation of the IFs (using UVCOP as you did).
>
> Cheers,
> Arnaud
>
> Le 17 sept. 2014 à 00:29, Amy Mioduszewski a écrit :
>
>> Hi Arnaud,
>>
>> I figured out the problem, but it is one of those complicated things that there could be bugs in various tasks connected to it, so it might take a bit to have a final fix.  There are a few easy work arounds though.  The issue is the spurious 2nd freqid that exists in the data.  If you do a PRTAB (INEXT='FQ') or a LISTR it will show you this FREQID.  Anyway, there seems to be a few minutes of autocorrelation on antenna 4 with FQ#2.  So when ANTAB loads the TY table it assigns some Tsys entries to FQ#2, and when APCAL encounters these entries, it looks for a GC entry for FQ#2 and doesn't find one.  I think I might add the FREQID to that error message since that would have helped diagnosing the problem.  This also explains why I didn't get this error when I UVCOPied the data because I only copied FQ#1.  The easiest work around is to explicitly set FREQID=1 in APCAL.  I tested this and it worked.
>>
>> The question is how this situation could be handled better in AIPS.  I suspect the autocorrelations are "real" so how could AIPS have done things differently?
>>
>> Cheers,
>>
>> Amy
>
>