MFCAL and GPCAL weirdness at L-band

[JamieStevens]

I was alerted to this problem by Gojko Vujanovic for project C2098.

The main problem is that GPCAL refuses to work for L-band data (apparently). I have put the dataset Gojko and I have been working with in /DATA/KAPUTAR_2/ste616/MIRIAD/gpcal_ticket. It is 1934-638.1750.

This dataset has been flagged to remove most RFI-affected channels.

The first problem, even after MFCAL has been run and uvplt/uvspec shows that there is data, running GPCAL gives the following output:

Task: gpcal

vis = 1934-638.1750/

select =

line =

flux =

refant =

minants =

interval =

tol =

xyphase =

options =

gpcal% go

Gpcal: version 1.0 7-Oct-04

Applying bandpass corrections to 1934-638.1750/

Number of antennae: 6

Reading the data ...

### Fatal Error: No data read from input file

Second, MFCAL refuses to make a bandpass solution for L-band data when the Stokes parameter is not specified, which is non-desired behaviour.

Running MFCAL with no Stokes parameter and viewing the output in uvspec gives the result in mfcal_result_nostokes.png (in the same directory). Obviously the bandpass solution isn't working! GPPLT shows that there are actually bandpasses for X and Y for each antenna (files gpplt_bandpasses_nostokes_*.png).

Running MFCAL with stokes=xx,yy makes the bandpass look much better (mfcal_result_stokes.png). It's reassuring that MFCAL can do the correction as expected, but it is puzzling why it needs stokes=xx,yy to be specified to work. GPPLT shows that the bandpasses look slightly different between running MFCAL with stokes specified and not (gpplt_bandpasses_stokes_*.png).

Either way, GPCAL does not work with this data. What is GPCAL looking for when it says "### Fatal Error: No data read from input file"?

I suspect this is a problem at S-band also (after some reduction of 1934 at S-band I did earlier that showed the bandpass problem as well).

[VincentMcIntyre]

Data files: 2009-07-20_1515.C2098

[MarkWieringa]

The data in question (20cm, 1750 MHz center freq), has 2 IFs at the same frequency. uvsplit does not split these into separate files, so you end up with two integrations at the same time for all the data. This seems to upset both gpcal and mfcal. When the data is loaded with ifsel=1 in atlod the resulting files can be processed ok with mfcal and gpcal.

I'll see if we can modify uvsplit to avoid or at least warn about this situation.