[Difx-users] difx2fits FQ table issue

[Jan Wagner]

Hi all,

about difx2fits in current or recent DiFX trunk versions, and AIPS:
I used 'difx2fits --difx' to get three single-scan .difx outputs
into the same FITS. Under AIPS 31DEC16 a FITLD then produces a
number of warnings. Some of you may already know about this general
issue. On quick glance there might be three problems encountered
during FITLD in total. Typical output:

FITLD1: Sky frequencies (MHz) before re-ordering occurs:

FITLD1: Incoming FREQID #   1
FITLD1:  86348.00   86316.00   86284.00   86252.00
FITLD1:  86220.00   86188.00   86156.00   86124.00
FITLD1: Incoming FREQID #   2
FITLD1:  86348.00   86316.00   86284.00   86252.00
FITLD1:  86220.00   86188.00   86156.00   86124.00
FITLD1: Incoming FREQID #   3
FITLD1:  86348.00   86316.00   86284.00   86252.00
FITLD1:  86220.00   86188.00   86156.00   86124.00
FITLD1: !!!!! WARNING: FREQIDS   1 AND   2 ARE IDENTICAL
FITLD1: !!!!! WARNING: FREQIDS   1 AND   3 ARE IDENTICAL
FITLD1: !!!!! WARNING: FREQIDS   2 AND   3 ARE IDENTICAL

FITLD1: Warning: table type GN is of zero length
FITLD1: GETDEL: No IM entry stn  1 src   1 sub  1 FQ  1 at   0/16:40:00
FITLD1: GETDEL: No IM entry stn  6 src   1 sub  1 FQ  1 at   0/16:40:00
FITLD1: GETDEL: No IM entry stn  7 src   1 sub  1 FQ  1 at   0/16:40:00

FITLD1: MC2CL: WARNING       404 CL RECORDS DID NOT GET CLOCK AND
ATMOSPHERE

Each scan apparently gets its own frequency ID despite entirely
identical VEX mode/setup for all scans. Secondly 'IM' entries are
missing, whatever that means. The third warning is about mc2cl. The
latter is strange as well because PRTAB of the 'MC' table does show
proper-looking atmospheric and clock delays and delay rates for all
three frequency IDs.

Might this be an issue in AIPS FITLD? Or is it an issue in difx2fits?

cheers,
Jan