GPBOOT Multiplying by NaN

[RowanMiller]

I'm working on 2.1GHz continuum data I observed over two sessions in Dec/Jan. First half of first session I reduced at Narrabri with no serious dramas. Now working on the remainder, and having issues:

With 1934-638 as primary (bandpass + flux), and 0438-436 as secondary, I'm following the fairly standard calibration strategy -
1. MFCAL (primary)
2. GPCAL (primary)
3. MFCAL (secondary)
4. GPCAL (secondary)
5. GPBOOT (primary to secondary)
6. MFBOOT
7. GPCOPY (secondary to source)

In steps 2 & 4 I'm splitting my 2GHz band into 4 chunks for an easier solution. Primary and Secondary data all look fine, but when I reach the GPBOOT step, it only partially works. The first two sub-bands are multiplied by a number (~0.95, as expected), but bands 3 and 4 have a factor of 'NaN' applied to them, which removes all the amplitude and phase information.

Because the given factors are not very far from 1, I tried continuing with the process without doing a GPBOOT, but this only moves the porblem down the line, removing amplitude and phase information for the sources.

Has anyone else come across this issue before?

[ste616]

Hi Rowan,

Yes, this is commonly seen in the 16cm band. The cause is RFI in the band preventing a stable solution from being found. This is why the higher bins in the 'nfbin' gpcal are affected, as they represent lower frequencies where the RFI is.

The solution is to do more flagging before calibration. But before you do this, you'll need to copy over a calibration solution that doesn't have these NaN values, and this usually comes from 1934-638.

Currently, the best option for flagging 16cm continuum data is the automated flagging routine built into pgflag.

Let us know how you go.

[and460]

Hi Rowan - Craig Anderson here. Just thought I'd give you my two cents because I have been working with 16cm data, calibrating it in much the same way.

I have found that the issue you mention occurs whenever GPCAL does not converge on a calibration solution within about 5 iterations or so for the sub-band in question. Whenever that occurs, in my experience, GPBOOT will then come up as having applied an NaN gain.

I've found that this happens under two circumstances - when there is still too much RFI present in the data, or when too much of the data within the sub-band in question has been flagged for RFI (presumably making it hard for the task to find a solution). If you are only splitting the CABB band into 4 sub-bands, I wouldn't have thought that over-flagging would be a problem though (it occurs for me, but I'm using nfbin =16). However, vast chunks of the band can be badly RFI-afflicted below ~ 1.6 GHz or so, so it could be a problem I suppose. You can check how much data is flagged with UVFSTATS.

I'll echo what Jamie said and say that I have found the automated sumthreshold flagging routine in PGFLAG to be the flagger with the deftest touch at the moment. It seems to mop up most RFI, without being overly heavy-handed.

Cheers,

Craig.

[Mark.Wieringa]

Hi Rowan,

I've done a few tests with gpcal on unflagged 16cm data and found it could produce NaNs in the leakage terms. These would then filter through to the gains and cause gpboot to fail.
I've now put some extra sanity checks in gpcal, and rather than continuing with leakages>100% it will print an error message and leave the leakages unchanged. This should fix the gpboot issue as well.
As Jamie and Craig have indicated - the real solution is to do more flagging and if not enough data is left, flag entire bins.

Cheers,

Mark