GPPLT: I/O error when reading bandpass table

[Catherine Brocksopp (cb4@…]

Have any of you come across an error message:

### Warning:  I/O error when reading bandpass table, in Gains routines.
### Fatal Error:  End of file detected

Everything seemed to be fine until I ran mfcal/gpcal and the message comes up if I run eg uvplt. Although uvplt works fine if I set options=nopass

Similarly if I try to plot the bandpass table I get:

GpPlt: version 23-Jan-07
### Warning:  Error reading the bandpass table
### Fatal Error:  End of file detected

I don't think it's the data as the same problem now occurs if I recalibrate the previous epoch which had been fine. How could I have broken the software?!

I'm looking at the files 2009-11-08*.C989 although once I got this problem I also tested a dataset that had previously worked ok, 2009-11-05*.C989, and now I get it with that as well.

I've run atlod, uvaver, uvsplit and blflag with no problems. Then mfcal/gpcal appear to run without problems. Then after that I get the error mentioned below when I try to do anything that tries to apply the calibration (blflag, uvplt, gpplt).

The task parameters I'm using are all fairly standard:

mfcal - vis=1817-254.5500, stokes=i, interval=2

gpcal- vis=1817-254.5500, stokes=i, interval=2, options=qusolve,xyvary

uvplt - vis=1817-254.5500, stokes=i, device=\xs, nxy=1 (including
options=nopass gets rid of the error)

I'm running the current version of miriad/rpfits on Mac OS X 10.5.7

[MarkWieringa]

I've reproduced the problem, but not yet solved it. I noticed that if you run mfcal again the problem goes away. It's clearly related to the bandpass code changes I made late September.

[MarkWieringa]

It looks like the problem arises from the use of stokes=i in mfcal.

mfcal and gpcal update the nfeeds header item. With stokes=i mfcal sets it to 1, and produces a single polarization bandpass. Running gpcal after mfcal, resets the nfeeds item to 2, making the header and the bandpass table inconsistent.

If you leave stokes unset in mfcal it does a solution for xx and yy, making the bandpass table the correct size.

The gpcal parameter stokes=i in the example gets ignored, so the two solutions (gains and bandpass) become inconsistent.

The bandpasses for x and y on each antenna are different, so it makes sense to solve for both independently.

I've updated uvgn.for to give a better error message.