gpcal not calibrating correctly

[JamieStevens]

For reference please see conversation at: ​http://atcaforum.freeforums.org/l-band-flux-of-1934-638-depends-on-maxsize-t38.html

It appears that when a heavily flagged (in frequency space) 1934-638 dataset is input into gpcal, the resultant flux appears to be incorrect.

Is gpcal merely scaling the entire band to make the average flux level match the flux level expected of 1934-638 at the "centre" of the band? Is this a problem for other sources?

The mfcal task does not suffer from this defect.

Some example data that I used to replicate this problem can be found at /DATA/KAPUTAR_3/ste616/reduction/dominic_problem/.

Here, the 1934-638.1750.1 dataset can be calibrated using mfcal/gpcal to see how the flux levels vary between the two calibration methods (the spectral slope appears to stay the same). The dataset 1934-638.1750.aver removes the large flagged areas on either side of the usable part of the spectrum, and calibrating with this dataset results in a much smaller difference.

With this result, it would seem that gpcal has always been giving faulty results, although in the higher frequency bands where less spectral flagging is required, the effect is too small to be noticed.

[JamieStevens]

After some more investigation I have determined that although this is a real effect, the correction tasks gpboot and mfboot can be used to successfully restore absolute flux calibration with only a small amount of effort.

The details of the investigation can be found at the ATCA forum site listed in the parent post of this ticket.

This ticket will now change, to reflect that the documentation needs to be changed to make users aware of the correct flux calibration procedure.

[MarkWieringa]

I've implemented a minor fix to gpcal to calculate the mean frequency of all data used in the calibration (instead of the average frequency of the first spectrum). This looks like it resolves the issue. I'll check the fix in on Monday.