Hi Tim,
My first question, in the case where 1934 is not only used for bandpass/flux density calibration but also phase, what is the best way to calibrate the data? Is there any need to break the data into two parts - one for the bandpass/flux density where there was 10 minutes of straight time on source, and the second for each of the phase reference scans? Or is it appropriate to simply use step 1 and 2 from above, except with options=xyvary,qusolve in gpcal? Could I make this the 'default' calibration, or would it do something bad to the other 10 secondary phase calibrators? My first thought is that breaking the data into two files would make the most sense, but if gpcal corrects for phase changes through time it wouldn’t matter whether they are broken up or not.
When you do the "gpcal" on 1934-638, you are calibrating it as a phase calibrator. The only reason why you don't have to give the "options=qusolve" parameter for 1934-638 is that we think we already know its linear polarisation to be zero, and so you don't need to solve for it (which is good since most people won't get enough parallactic angle coverage of 1934-638 to allow qusolve to work, although you might). After that step, you can use 1934-638 as a phase calibrator without doing anything further.
The only thing to possibly watch out for is selecting only a small range of 1934-638 data that overlaps closely in time and elevation to the source you want to flux calibrate. This is done in gpboot if you want to select the time range of the source you're calibrating, and it uses the entire time range of 1934-638. If this isn't appropriate, you might want to take a subset of the 1934-638 data using something like uvaver as the flux calibrator, but remember you can't do that after you've calibrated the whole 1934-638 dataset, since gpboot requires you to have the calibration tables in the dataset, not applied to the data. Perhaps it might be easiest simply to execute your idea of breaking the data into two parts.
Additionally, I was hoping to get clarification on how nfbin determines the frequency bins when a parameter for it has been supplied. I ask because, as mentioned in the previous thread, I have had to flag the upper end of my 11GHz data. When I supply an nfbin parameter, is it smart enough to compute these bins based on the minimum and maximum frequency of unflagged channels? I would think so simply because gpcal didn’t fall over, but i Would like to be sure. Perhaps including the frequency range of each bin could be included in the output where appropriate as it may be a useful reference?
I'm afraid nfbin just divides up the band without any regard to flagging. In most circumstances though, you probably don't need to even do "nfbin=4"; almost all of my calibration works well with "nfbin=2".
And finally, I am curious if there are any tasks or ways to inspect the flags file of a uv-file so as to identify the channels which have been flagged - ideally only those which have been flagged for all records? I ask because I plan to divide my data up into multiple sub-bands using the line parameter in invert, and I hope to balance them such that they all have a consistent number of useable channels. Knowing how to do this will definitely help me remain consistent, especially if I try to automated the imaging aspect of the project.
Use the "uvfstats" task with "mode=channel".