[daip] Calibration transfer/frequency selection problem.

[Craig Walker]

I have observations which switched between 12 and 15 GHz.  I used
frequency selection in FITLD to load the two frequencies, in two
passes, into separate AIPS files.  After running VLBACALA, I found LA
had a few high gains (3 scans).  On investigation, I discovered that
those were the only scans that were correctly calibrated.  At first I
thought the CLCAL SELF option was broken, but on investigation, I see
that there are problems with the TY table, which propagate to produce
the effect.

The TY table has data from two FQ IDs, which is reasonable for the
archive data because we were switching frequencies.  But when FITLD ran
with frequency selection, only one of these IDs survived and it ended
up being called number 1.  But no data selection was done in the TY
table, so both frequency IDs are there and the one that corresponds to
the selected uv data is FQ ID 2.  Because of the renumbering, APCAL
uses only the FQ ID 1 data from the TY table - the wrong data.  I fear
that PCCAL etc may have similar problems but haven't checked.  So, the
upshot is that either the FQ IDs in the calibration tables need to be
altered along with the data, or the original FQ assignments for the
data need to be retained, even if there are not data for some.

I spotted the problem because of another glitch.  For the three scans
with the discrepant (correct) data, the TY table has two entries for
each time/antenna/source.  One is marked for FQ 1.  The other for FQ
2.  The Tsys's are identical and are correct for that scan (what would
be FQ 2 for all other scans at this frequency).  What APCAL had been
doing was using Tsys data from the adjacent 15 GHz scans (same source)
to calibrate all other scans.  But for the 3 scans with the duplicate
data, one with FQ 1, APCAL used that data as might be expected (except
for the first CL point which was closer to a preceeding scan TY
entry).  I have no idea how we ended up with the duplicate data, but
this should also be investigated.

The data set is on pingora disk 2:
AIPS 1:   28 1913 BW43U_J00_12.MULTI .    1 UV 06-APR-2001 10:23:10
I have the archive tapes.

The data were recorded in January 2000 and correlated on 14 Feb 2000
(Yes, a bit over a year old).  Sorry if this is an old, fixed problem,
but I have not heard about it.

I guess I now need to try to edit the TY table to remove all FQ 1 data,
then convert the FQ number to 1.

Craig