Cycle 1 Specification for adding a second phase calibrator
(based on the Cycle 1 Observing Modes workshop (July 2012)
SB generation by the OT in Cycle 1
Action Item: A frequency and resolution-dependent criterion will be
provided to Alan for the decision as to whether or not a Check Source
is included. For Cycle 1, these will be internally identified using
the DelayCal intent, a new dedicated intent will be added for Cycle 2.
My Response: (sent to Alan Bridger and Jeff Kern on August 30, 2012)
An astrometric "check" source should be generated using the same
Spectral Spec as the normal phase calibrator. It should be observed
every other phase calibration cycle. It should be added automatically
by the OT under these conditions:
1) Observations in any band in which the ratio of (lambda /
max_baseline) is less than 1.75e-6, where lambda is the
wavelength of the highest frequency spectral window
2) Observations in Band 9 or above.
Note: Item 1 corresponds to configurations with a maximum baseline
greater than 500m at 345 GHz, and greater than 1.9km at 90 GHz. For
Cycle 1, this criterion effectively limits the automatic use of check
sources to Band 6 and above.
A) The P2G member may remove the check source from Band 9 observations
that do not meet Criterion 1, but only if the primary calibrator is less
than 5 deg away from any science target and
it has a recent Band 9
flux measurement greater than 0.7 Jy.
B) The P2G member should confirm that the chosen check source is
within 30 degrees of at least one of the science targets.
On 9/18/12 6:53 AM, Bridger, (Alan) (ROE,UKATC) wrote:
'> Hi Todd
'> Thanks. I've added this to our spec. (I will circulate a link to our spec. soon).
'> I had a question though: the Executive Summary states that the check source "will be implemented as a DelayCal" - what does this mean for OT setups? We have a DelayCalParameters setup that could be used, but is that what the statement means? Or should we just treat this as a secondary phase cal and give it PhaseCalParameters? (In the OT both can be applied, but I don't believe the control/scripting side recognizes this yet).
I believe the objection to having it labeled as a second PhaseCal
was from the point of view
of the pipeline. Because we don't have the concept of an intent called CALIBRATE_PHASE_SECONDARY,
the pipeline cannot tell the difference between the two and it will simply use them both, which is not generally what
we want to do in data reduction. The choice remains as to where it gets relabeled as a delay cal.
I thought that this would happen in the control script, which if it sees more than one phase calibrator
it would use the one with the fastest cadence and label the others as delay calibrators. But perhaps
Stuartt interpreted this as meaning that we would insert them as delay calibrators in the OT setup from
the beginning He should probably comment here.