Facilities > VLA > Documentation > Manuals > Guide to Observing with the VLA > Disposition Letter and Scheduling Blocks

Disposition Letter and Scheduling Blocks

by Tony Perreault last modified Jan 25, 2018 by Amy Mioduszewski

Interpreting the Disposition Letter

A disposition letter is sent to the principal investigator and co-investigators of each VLA proposal. This letter contains comments from the cognizant Science Review Panel (SRP), a linear-rank score from the SRP, comments from the NRAO Technical Reviewer and, optionally, comments from the Time Allocation Committee (TAC). Guided by the linear-rank score and taking into account the time available, the TAC assigns a scheduling priority to each session in the proposal. If time is allocated at a scheduling priority of A, B, or C, the proposal is converted to a project which is eligible to compete for time in the dynamic queue.

The VLA disposition letter is arranged in six portions:

Synopsis This portion lists the proposal id, title, type, authors, cognizant Science Review Panel (SRP), and time allocation summary. The latter tells the proposers whether or not time was allocated to the proposal. If time was allocated, its scheduling priority (A, B, or C) is given and the proposers are responsible for preparing scheduling blocks for that time.

Science Review This portion gives the linear-rank score from the SRP, along with comments from the SRP that summarize the proposal, give its strengths and weaknesses and, optionally, note any technical issues. The community-based SRP consists of a chair and five anonymous members. The linear-rank score is on a scale from 0 (a high-ranked proposal) to 10 (a low-ranked proposal).

Comments from the TAC The TAC consists of the chairs of the eight SRPs. Taking into account the time available as a function of LST, the TAC assigns a scheduling priority to each session in each proposal. The TAC might comment on these assignments. The assigned scheduling priority depends on the linear-rank score of the proposal, the LST ranges involved in the session (daytime is harder to accommodate than nighttime), the total time requested in the session, and the competition from better-ranked proposals requesting time at similar LST ranges. For further details, refer to the VLA Prioritizer Memo.

Comments from the NRAO These describe the possible scheduling priorities, which are:

  • A = the observations will almost certainly be scheduled
  • B = the observations will be scheduled on a best effort basis
  • C = the observations will be scheduled as filler
  • N*= the observations will not be scheduled because they were explicitly rejected by the TAC
  • N = the observations will not be scheduled because they could not fit in the time available
  • H = not assigned because the proposal is being held for consideration at a future TAC meeting

Time Allocation For each session in the proposal, a table lists the session's name, array configuration, time in hours, LST range, bands and scheduling priority. For a given array configuration, time approved at a scheduling priority of A, B, or C may be divided into multiple scheduling blocks as appropriate. Factors to consider in this division include the scheduling priorities, the observing frequencies, the tabulated LST ranges for the sessions, and the LST pressure plot at the start of the array configuration.

Further information for proposers and observers, including statistics and important LST pressure plots, is available from the most recent TAC report that is referenced in the disposition letter.

Comments from the NRAO Technical Reviewer Comments concerning the Technical Justification portion of the proposal. These comments are available to the SRP and the TAC.


Proceeding with Conversion of Proposal to Project


This section discusses converting your proposal to a project, checking the LST pressure plots and how to find the most current version (generated every Friday), scheduling block duration for the different priorities, and some tips on building your scheduling blocks.

Converting a Proposal to a Project

If a proposal's disposition letter indicates that time is allocated at a scheduling priority of A, B, or C, then NRAO staff will convert the proposal to a project in the Observation Preparation Tool (OPT). This conversion occurs only about a month before the start of an array configuration (see the latest configuration schedule).

After the conversion is complete, the project's authors are notified that the project is ready in the OPT. A project contains one or more program blocks. A given program block will involve only one array configuration (which may be Any) and only one scheduling priority. The project's authors are responsible for atomizing a program block into scheduling blocks.

Interpreting the LST Pressure Plot

Figure 1.1 (below) shows an example of the pressure on dynamic time as a function of LST for the start of an array configuration; this example is for the A configuration in Semester 2016B. Similar pressure plots are available for each configuration in each semester and are published in the Time Allocation Committee (TAC) report for the semester.

Figure 1.1 encodes pressure by the scheduling priority assigned by the TAC, as well as by frequencies above 12 GHz (light shading) and below 12 GHz (dark shading). The time available per LST hour is shown by the solid black line for all frequencies, by the long-dashed black line for K-band conditions, and by the short-dashed black line for Q-band conditions. Maintenance, software and enhancement activities cause the thick black line to be less than the total number of LST days in the configuration. Such activities dominantly occur during daytime, causing the black lines to dip for the daytime LST range.

Scheduling priorities assigned by the TAC are encoded by color, with the following meaning:

  • A = the observations will almost certainly be scheduled (light green, dark green)
  • B = the observations will be scheduled on a best effort basis (light yellow, dark yellow)
  • C = the observations will be scheduled as filler (light red, dark red)
  • N*, N = the observations will not be scheduled (light blue, dark blue)

A project allocated time at a scheduling priority of A, B, or C is eligible to compete for time in the dynamic queue. To effectively schedule the VLA, it is necessary to approve more time than is actually available.

Scheduling Block Durations

The duration of an individual scheduling block (SB) cannot exceed the time allocated to its containing program block. Beyond that basic fact, the optimal duration of an SB depends strongly on the scheduling priority (A, B, or C) assigned to its containing program block. As an aid for observers, a pressure plot for the dynamic queue is updated and posted every Friday, and is accessible from the Schedsoc Home Page.

Priority A: Dynamic scheduling enables priority A SBs to observe during the requested observing conditions, as determined at the start of the observation. SBs of any duration are fine as far as the heuristics in the dynamic scheduler are concerned. However, there may be other considerations in determining the best SB duration. At high frequencies the length of time during which the specified observing conditions, evaluated at the start of the run, can be expected to be satisfied during the duration of the run needs to be considered. This is a function of the time of day and time of year. Daytime observing is also be limited by maintenance, software or enhancement activities, so SBs that can end by 8am or start after 5pm (local Mountain time) have an advantage.

Priority B: The amount of priority B time approved is designed to almost fit into the available hours per configuration. However, it is advantageous to submit SBs of several different durations. SBs with durations of 4 hours, for example, are more efficient, but shorter SBs will often be scheduled earlier, as they can fit around the priority A SBs which are emphasized early in the configuration. Moreover, as noted above, shorter SBs are recommended at high frequencies.

Priority C: These are filler projects. Monitor Friday's pressure plot located near the top of the Schedsoc Home Page. Early in the configuration, only SBs with durations of 1 hour or less have any chance of being scheduled. Later in the configuration, SBs with durations of 2 hours or less may be viable. If there are eventually only priority C SBs at your LST range(s) of interest, it may be profitable for you to submit SBs with longer durations.

Tips for More Flexible Scheduling Blocks

This section is particularly relevant for SBs with priority C, but also for SBs with priority B and involving the most popular LST ranges or the higher frequencies. Some of these tips may also be useful when preparing SBs with priority A.

More flexibility will increase the chance that a particular SB gets observed. However, if the conditions are too flexible or if the overhead becomes so large that the data cannot be calibrated or yields too little time or u-v coverage on the science target, the data set may not achieve the anticipated science goal. Always ensure that the data set can be calibrated. If there are options to consider, it may be better to choose the option that leans toward a more conservative calibration rather than the option that accrues more observing time on the science target. More conservative calibration will also ensure smoother data reduction.

Tips on how to increase the chance that an SB will be observed:

  • Submit the SB early. If the SB is not available when a scheduling gap occurs, it cannot be selected for observation. Gaps can occur at any time, including at the planned start of the array configuration (see the configuration schedule).
  • Submit a short SB. Short gaps occur more often than long gaps. Make SBs short and repeat them as many times as desired to accumulate observing time. SBs may now have arbitrary lengths.
  • Submit SBs with various durations. It is permissible to submit SBs that, in aggregate, exceed the total time allocated to a program block or a project. Use this to your advantage by submitting SBs with various durations. For example, if a scheduling gap of 1.5 hours is available then compete for it with an SB of duration 1.5 hours instead of an SB with a duration of 1.0 hour. That shorter SB can be used to compete for a later scheduling gap of 1.0 hour. Also, as the pressure from priority A and B SBs drops a few months into a principal configuration, scheduling gaps can sometimes accommodate priority C SBs longer than 2.0 hours.
  • Break up high and low frequency observations. There is more low frequency time than high frequency time, so it is usaully harder to get observed if the weather (API and wind) limits are very low.  If it does not matter if low and high frequencies are observed at the same time it is often advantageous to split observations into low and high frequency blocks.
  • Relax the API or wind limits for the SB. For example, if the science target is strong enough for self-calibration then the API limit can be relaxed compared to the default value.
  • Widen the possible start LST range(s) of the SB. Especially at low frequencies, consider observing down to the elevation limit of the antennas.


Scheduling Block Life Cycle


Project and Program Block Creation

After the approval of a project, the observers are responsible for creating valid Scheduling Blocks (SBs) to achieve their science goals. About one month before the first possible observation, i.e., the start of the requested array configuration in the observing semester, NRAO will create the Project tree with the Program Block (PB) assignments in the Observation Preparation Tool (OPT). Concurrently, the source list is automatically transferred from the Proposal Submission Tool (PST) to the Source Catalog Tool (SCT). If the project consists of observations in more than one array configuration, all PBs will be created at the time of the original import process. Another reminder email will be sent out about a month before observations are anticipated to start in the next array configuration. Once observers have been notified that the OPT has been populated with the Project and PB(s), they may begin creating and submitting valid SBs. Before doing so, it is strongly advised to check whether the import of sources into the SCT have been transferred correctly, e.g., the proper coordinates, epoch, and velocity information (with convention). This is also a good time to create a resource catalog within the Resource Catalog Tool (RCT), also known as the Instrument Configuration tool within the OPT. Once in the OPT, one may also (un)check if an individual on the project would like to receive email notifications for the project, i.e., SB submissions and the operator's observing log emails.

Scheduling Block Creation and Submission

The creation of the SB(s) is the responsibility of the observer(s). The Guide to Observing at the VLA aims to help with this step and contains several suggestions and background information. It is very important for the observer to read through the entire guide, especially the chapter(s) pertaining to their science, e.g., high frequency strategy, low frequency strategy, very low frequency strategy, calibration, polarimetry, spectral line setup, etc. To help observers validate their SB(s) and resource(s), read through the Presubmission Checklists. However, if there is uncertainty regarding the validity of the SB(s), please submit a ticket to the NRAO Helpdesk before submitting the SB(s).

After submission the status of the SB will change from NOT_SUBMITTED to SUBMITTED. The OPT will generate an SB submission email to alert the VLA data analysts to perform a validity check soon thereafter. Note that this is not a science check for, e.g., correct frequencies or spectral line setup, but merely checking the requirements and logistics so it will not disrupt observing. If a submitted SB requires corrections, it can be canceled (unsubmitted), changing the status back to NOT_SUBMITTED.

If the VLA data analysts find any problems with the submitted SB(s), the observer will be notified (preferably through the NRAO Helpdesk) and may be asked to cancel, improve, and/or submit the improved SB(s). Otherwise, when there are no logistical problems apparent, the VLA data analysts will approve the SB(s) for observing, thereby changing the status of the SB(s) to SCHEDULABLE for observing.

At rare occasions, for experienced observers in cases where SBs need to be able to execute very rapidly after submission, e.g., for a target of opportunity, the observers may be given special permission to self-approve their SBs at the time the PBs are created. There will be no validity check of the SB submissions by the VLA data analysts, and the responsibility of the successful execution remains entirely with the observer with the understanding that no make-up time will be granted for unsuccessful observations.

Scheduling Block Observation and Archiving

SBs for observation are drawn from a weighted pool of SCHEDULABLE observing blocks, according to the guidelines explained elsewhere in this guide. When an iteration of an SB gets queued, a copy is created known as an Execution Block (EB). The EB lives as QUEUED, RUNNING, PENDING FAILURE or PENDING COMPLETION before the final EB status of FAILED or COMPLETED. Note that these short-lived intermediate EB status designations are merely helpful to the operators and staff. After the successful execution (observation) of each iteration of the SB, the observer will be notified of the successful completion of an iteration of the SB. The status of the SB will remain SCHEDULABLE as long as there are remaining iterations. The successful completion of all repeat-iterations specified in the SB will mark the status of the SB as COMPLETED. The observer can retrieve the individual SB executions of the data from the NRAO data archive. Data will be proprietary to the original observers typically for one year after the last observation taken for the project; after which the data becomes public and accessible to all archive users.

Occasionally, mostly for logistical reasons, during the scheduling of observations in the dynamic scheduling process, the operator may defer an SB to ON HOLD. This is a very short-term status and the operator or NRAO staff will quickly release the SB back to the queue or take other actions to resolve any issues. In some cases, for miscellaneous reasons, the execution of an SB may not complete. Scheduling blocks with an EB having a status of FAILED will be investigated and, if appropriate, the observer will be contacted for follow up. An SB with a FAILED execution block typically triggers a re-observation at a later time.

Scheduling blocks that have not been observed, or have remaining repeat iterations at the end of the observing period allocated to the project (typically at the end of the allocated array configuration(s) or observing semester), will be given the status of EXPIRED and will be removed from the active observing queue. Once COMPLETED or EXPIRED, the SB becomes read-only and thus cannot be unsubmitted or edited. However, the SB can be read and (partially) copied to a new SB in a new or otherwise active PB which can then be modified for new observations.

Scheduling Block Status Monitoring

Observers who have switched on their email notifications in the Project will receive emails for each SB of the project when the status changes to SUBMITTED, or back to NOT_SUBMITTED. Currently, we are working on a notification when a SB becomes SCHEDULABLE or EXPIRED.

Anyone on the project can monitor the status of the SBs in the project by logging into the OPT. The status summary of all SBs in a program block (PB) is viewed by selecting the PB level of the Project tree. Here the number of anticipated executions (or counts), LST start range, and the wind and API constraints are listed. For each execution of an SB, including repeat executions, the PB level of a Project contains a table of Execution Blocks (EBs) listing the corresponding SB ID, status, duration, start and finish date/time (in LST and UTC), initial API and wind readings (which are likely to change during the observation) can be found below the table of SBs. The same information can be found under the Executions tab within a SB. This information is added after an SB is executed, and the corresponding EB is created.