Automated sumthreshold routine in PGFLAG kills real flux?

Got a calibration problem? Discuss it here.

Moderator: Mark.Wieringa

Post Reply
and460
Posts: 79
Joined: Thu Sep 01, 2011 12:23 pm

Automated sumthreshold routine in PGFLAG kills real flux?

Post by and460 »

Hi guys,

I have been trying to create some Stokes I spectra from various point sources that I have been imaging through the 16 cm CABB band, and I've come up against an interesting/frustrating (mainly frustrating) problem.

The issue is that I have noticed pronounced 'dips' in the Stokes I spectrum, and these dips seem to correlate very strongly with peaks in the flagged percentage of the 32MHz channels combined to create my MFS images. That is, I appear to be 'losing flux' whenever the routine flags a lot of data, or pushing this line of thought a bit further into the realm of interpretation, the routine seems like it might be killing off real flux from the source. I have attached a plot showing this effect, where I have plotted the Stokes I data points in red and the flagged percentage on a second axis in blue.

There was a lot of RFI during these observations, and a correlator block seems to have dropped unnoticed part way through which doesn't help matters. But the effect seems clear, and I haven't exactly been smashing the data with sumthreshold - I used the automated routine with standard settings and command="=<<b", flagging both Stokes I and V off each other, which seemed reasonably conservative to me given that I then had to go in with PGFLAG and pick off little residual bits of RFI from the uv data manually. Anyway, the effect diminishes when short baselines are excluded in the imaging process and a robust parameter of < 0 is used, which all seems to confirm to me that the issue appears to be associated with RFI / flagging.

I was wondering if anyone had noticed anything like this behaviour before, and whether anyone had any recommendations for the flagpar settings in PGFLAG that would minimise this sort of effect. As I said, I can make things a bit better by throwing away short baselines and by using more uniform weighting schemes in the imaging process, but it seems rather heavy handed to throw away that much data if it isn't completely necessary. It also seems strange that I guess what I am suggesting is that over-flagging is responsible for the problem that I'm seeing, and the only solution I have come up with that seems to help is to throw away MORE data in the form of short baselines / visibilities from short uv distances.

Anyway - it is weird, and any help or suggestions would be very welcome!

Cheers,

Craig.
Attachments
Screen Shot 2013-03-01 at 12.27.18 PM.png
Screen Shot 2013-03-01 at 12.27.18 PM.png (47.29 KiB) Viewed 12836 times
ste616
Site Admin
Posts: 220
Joined: Thu Feb 04, 2010 3:27 pm
Location: Paul Wild Observatory Narrabri NSW

Re: Automated sumthreshold routine in PGFLAG kills real flux

Post by ste616 »

Hi Craig,

Could you please give us an outline of the calibration process you used here, so I can speculate more confidently on what may be occurring?
cheers
Jamie Stevens
ATCA Senior System Scientist
Post Reply