An illustration of the effect comes from Shari Breen, who observed maser sources strong enough to clearly see in each 10 second correlator cycle. She found that in the first cycle of most scans on these masers the emission seemed to be shifted in frequency compared to where it was in the other cycles. We can see this by looking at a waterfall plot of the data, as generated by pgflag:
![Image](http://www.narrabri.atnf.csiro.au/people/ste616/cabb_1stcycle_problem.png)
In this plot the channel number is increasing along the x-axis, while the time is increasing along the y-axis. The plot also makes clear that for two scans the problem doesn't appear, and in the last scan the problem has a different magnitude to the earlier scans.
Our correlator engineers are investigating this issue, and as yet a fix is not available. It has been found that this bug has existed since zooms were implemented, but obviously it requires a strong source and fast slews to be readily visible. Anyone who has used CABB zooms may be affected however.
The corruption is isolated to the first cycle of any particular scan, and the correlator engineers have told us that it looks like 50% of first cycles are affected.
Your observations may be affected if:
- You are using CABB zooms, either 1 MHz or 64 MHz (although only 1 MHz has shown definitive evidence of the corruption), AND
- Your first cycle of a scan contains on-source visibilities. If it takes more than 30 seconds to slew to your source, then this potentially corrupt first cycle will automatically flagged as off-source and you won't be affected.
To flag out the affected cycles most likely requires that you redo your data reduction from scratch. When you load your data with atlod, all the off-source cycles will be discarded; this is done to save space on the disk. However this also means that Miriad cannot later determine if the first cycle in a scan is actually the first correlator cycle, or if it is simply the first cycle while tracking the source. For example, we can look at the partial output of uvindex for a random observation loaded with atlod in the normal way:
Code: Select all
Time Source Antennas Spectral Wideband Freq Record
Name Calcode Channels Channels Config No.
14MAR14:22:10:04.9 1921-293 c 6 8196 0 1 1
14MAR14:22:22:44.9 1934-638 c 6 8196 0 1 3601
The "unflag" option in atlod makes it keep all the flagged cycles, although confusingly it won't actually unflag those cycles (which is good!); it simply means that all the data will be preserved in the output of atlod. Let's look at the same observation as before, loaded with atlod's "unflag" option:
Code: Select all
Time Source Antennas Spectral Wideband Freq Record
Name Calcode Channels Channels Config No.
14MAR14:22:10:04.9 1921-293 c 6 8196 0 1 1
14MAR14:22:20:24.9 1934-638 c 6 8196 0 1 3601
So how do we do the flagging? After using the "unflag" option in atlod, the Miriad task "qvack" can be used to flag the first cycle of every scan.
For example, the atlod step might look like:
Code: Select all
atlod "in=*.C007" out=c007.uv options=birdie,rfiflag,xycorr,opcorr,noauto,unflag
Code: Select all
qvack vis=c007.uv interval=0.1 force=0 mode=source
More information will be provided when we know if this issue can be fixed. Please feel free to reply to this post if you have questions.