OPERATIONAL MODEL UNDER FLEXIBLE SCHEDULING

Introduction

Experiments carried out at UKIRT between 1999 and 2002 demonstrated the power of flexible scheduling (flexing) in the context of a multi-purpose infrared telescope such as UKIRT. At its July 2002 Board meeting, the UKIRT Board strongly endorsed a move to full flexing from the start of semester 03A. This document describes the adopted operational model, which takes into account the Board's recommendations and the results of a user survey undertaken in mid-2002. Observers granted time (and summit occupancy) should make sure that they understand the principles and implications of this model for their observing run. 

Modifications to the model resulting from operational experience are listed in a series of Amendments, linked to at the end of the document.

Principles

Flexible scheduling of UKIRT is based on the following principles.

We do not enforce a strict queue-scheduled operation. For example there is no global Phase II deadline; programmes can be built up in stages as the science develops. The aim is to accrue the substantial gains of matching rare conditions to the projects best able to make use of them while retaining all the best features of classical scheduling: the ability for observers to apportion their time as they choose and to change their observing strategy on the basis of early results.

Model

The model is in fact most closely grounded in the third principle stated above - that the observer should have a good chance (though not the guarantee) to execute their own programme. The first two principles are then satisfied by choice of observers and the details of programme selection at the summit.

Proposal stage

Proposals are submitted through the standard UKIRT submission system, which solicits atmospheric-condition requirements through the web form. Proposals which do not adequately specify their weather requirements (or fail to show that they have none) have appropriate requirements added at the technical assessment. P.I.s should note that the complexity of data analysis is not necessarily an argument in favour of working at the summit; all data will be transmitted to remote P.I.s and analysis in the UK (etc.) during daytime may be preferable.

Allocation and Scheduling stage

The TAG allocates a science priority and a total-time allocation to every proposal above a given grade; proposals which fall below that grade are not accepted into the semester database. The most highly-rated programmes are overallocated summit (though not telescope) time, placing the owner of the programme at the summit for longer. Since, as discussed later, the Observer's programme cannot be trumped by a still more highly-rated programme which requires the same conditions, this increases the chance of the programme being done. At the TAG meeting the loading of each month is monitored to ensure that runs allocated time have a reasonable chance of execution. A small number (typically two or three) programmes may be granted "carryover" status, where it is sensible in terms of source position and initial scheduling, and the programme is sufficiently highly rated. Further, it is possible to allocate some programmes time in the semester before the one applied for ("carry-back" status) in the event that the source list permits it.

Observer selection

Observer selection is done at the TAG meeting. To avoid a gradual shrinkage of the pool of selectable observers, and to satisfy the other criteria, observers are selected on the basis of science priority, programme complexity and weather requirements rather than on observing experience (though this may be a factor also). Observers are expected to come for n-night runs (where n is at least 3 and at most normally 7), one or two observers per run (PATT support will be available for two observers in cases where UK teaching commitments make a long stay impracticable, and students may be added at STFC discretion). P.I.s who believe their programme (or real-time interpretation of the resulting data) is sufficiently complex to require their presence whatever their science grading must make a case for this clearly in the technical section of their proposal. In practice this is likely to apply only to a small fraction of the accepted proposals.

Observation submission

Submission of observations into the database is dynamic, reponsive to the changing needs and priorities of the programme. P.I.s must submit a reasonable (defined on a case-by-case basis) subset of their Observations at the outset of the semester in which they are scheduled for execution. This provides time for the support scientist to vet the proposed observations both for consistency with the original proposal (weather conditions and astronomical) and for adequacy of the comments attached to the observations.

Each successful proposal is given a "latest date of first submission" (support scientist responsibility). Database entries for the programme must begin to appear by this date, with the sanction of removing the programme from the system if they do not.

Observation stage

The observer at the telescope carries out his or her own observing programme if the weather conditions are consistent with (or better than) their stated requirements. If not, they execute observations from other programmes in the database. It is appropriate to define some terminology at this point. The observer's own programme is (naturally) called the "Observer's programme". Others are referred to as "Queue programmes". These are selected on the basis of match to weather conditions, science priority and completion status (of course, highly-rated science is never done in inappropriate weather conditions). In practice, these programmes may be more highly rated than the observer's own. If the observer's programme has been completed, they continue to execute Queue Programmes until the end of their schedule slot. It is possible that the Observer's programme has been completed before they arrive at the telescope; but this is unlikely given the range of weather constraints against which the flexing is carried out. If this is the case, however, the observer is expected to carry out queue observing.

The TSS, scheduler and support scientists are responsible for monitoring the observer's selections (and non-selections) to ensure that programmes near the top of the database queue all receive an equal chance of execution. The only reason for not executing the programme at the top of the weather-filtered queue is lack of expertise or the complexity of the programme, as discussed with the support scientist and scheduler.

Additionally, there will be occasions when the Observatory deems that an engineering task is of sufficient importance to be undertaken during a PATT observing run. Under these conditions, observatory staff will ba at the telescope for the duration of the engineering observations. Every effort will be made to return any observing hours used to PATT time at a later date. In most cases the engineering will have the status of the highest-rated queue observation and thus engineering will not trump the summit observer's programme.

Poor Weather / Empty Queue

If the observing conditions are such that a search carried out on the current conditions turns up no executable MSBs, then the time is by definition lost to weather. In such circumstances, the summit observer may carry out backup projects of their own, executing them from within their own OMP project, but with no charge to the project. In such circumstances, the observer/TSS should maintain a watch on the conditions, run scenario-mode queries and revert to the queue if things improve to the point where the queue is no longer empty. It is permissible for the observer to complete a reasonably-sized MSB before reverting, if conditions do improve. We would expect this overhead to not exceed 15-30 minutes in any case. If an MSB has been commenced which will definitely take more than 30 minutes to complete and conditions are now good enough for the queue, then a call should be placed to the Associate Director, UKIRT, for confirmation.

Support

Each programme, and hence each observer, is allocated a support astronomer, who takes responsibility for vetting the PI's programme entries as they come in, is first contact in the event of problems at the telescope, and supports the PI in reducing their data. This person is the first contact for the observer in the event of problems, and is expected to be available by phone for the duration of the observer's run. They are not expected to sort out problems occurring in the course of a night with a programme other than the observer's own; such problems are reported for follow-up the day after. P.I.s of Queue Programmes will have the support astronomer of their programme as the first point of contact.

Software

The Observation Management Project (OMP) software provides observation selection and execution, and feedback to aid observers and P.I.s in taking and assessing data over a range of programmes according to conditions. It does this without subverting the observer's discretion at the telescope. Here we briefly state the technical details of the OMP; note, however, that it is not simply the OMP but also the ORAC preparation tools and considerable input from the support astronomer that ensures success of a given programme.

Successful P.I.s prepare their programmes (remotely) with the ORAC OT. They are required to include a Site Quality Component in their programme observations, which specifies requirements on seeing, photometric conditions, tau and moon brightness. Observations in a submitted science programme are assumed schedulable at any time; if a P.I. wants two observations scheduled together (for example because one is a calibrator for the other) they group them together in a "Minimum Schedulable Block". A single observation is treated as an "MSB of one" for the purposes of querying the summit database. If an observation comprises a long integration that can be done on different nights, the P.I. can turn it into several MSBs of shorter duration, thus increasing its chances of being scheduled later in the night where a single long observation would not fit.

The OMP database server splits submitted science programmes into their constituent MSBs and extracts information of a schedulable nature - the Site Quality information but also RAs, estimated duration, instrument configuration and so on. This information is stored in a relational database for efficient searching.

At the telescope, the observer uses the "Query Tool" (QT) to retrieve the most appropriate MSBs in any PI's programme. Selection criteria include whether the source is currently accessible, the weather conditions and the instrument availability. Although the list of MSBs is sorted using an algorithm that folds the conditions requirements with project properties such as TAG priority and completion status, the observer is free to exercise their judgement and choose an MSB that is further down the list. They can also rule out certain instrument configurations - for example a novice observer with only imaging experience would be permitted to remove spectropolarimetry MSBs from consideration.

Feedback to and from absent P.I.s is vital to the success of flexible scheduling. The OMP provides a feedback system whereby the P.I. is informed of the progress of their project, can retrieve their data, and can discuss any issues with observatory staff.

Initial weather bands

The OMP allows the P.I. to specify weather constraints as shown in the table below. The "thin cloud" category is only required for flexibility at the telescope; it is useful to identify those programmes which can be done in the presence of thin cirrus. It is not our experience that any programme will actually require thin cloud.

Exceptions

Time-critical programmes

Programmes with specific timing needs are scheduled without flexing. Their observers come to the telescope for just the nights in question. This applies, for example, to transient objects with a specific timing requirement, and also to monitoring programmes which have to be carried out at regular intervals.

Moving objects

In the longer term, the OMP will cater for moving objects, allowing orbital elements into the database.

Non-UK P.I.s

Non-UK P.I.s do not receive travel and other expenses from STFC and it is not possible to enforce the slightly longer stays at the telescope that are implied in the model above. However these P.I.s have been allocated time in the same manner as all other programmes and they should be flexed with the rest of the successful applicants. Non-UK P.I.s are therefore invited to stay at the summit for a period equal to or greater than their total allocation, up to a maximum of 7 nights as stated above. In other respects their programmes are treated the same as the rest: if not complete by the end of the schedule slot, they remain in the queue.

Overrides

PATT allocates override status to projects requiring quick response to targets such as Gamma-Ray Bursts. MSBs for such projects will, when a suitable target becomes available, typically appear in the queue with priority zero and should be executed by the summit observer as soon as possible. It is not, unless otherwise stated, necessary to break the currently executing MSB. Any queries about a particular override should be directed to the telescope Associate Director, night or day.

Overrides can be called during PATT nights and UKIDSS time (the case for overriding UKIDSS needs to be made in the proposal's science case). Engineering time cannot be overridden formally, but requests may be treated on a case-by-case basis. In general, overrides will not be executed in engineering time (i) if this would affect an engineering data taking sequence such as a WFS run; (ii) if it would result in engineering observing being put off into a subsequent night (with consequent risk due to unknown weather conditions).

Practicalities and case notes

Case notes: Changes in observing conditions

Case 1. The weather improves during the execution of a Queue programme's MSB. In this case the MSB underway is completed and calibrated before switching to the Observer's programme. This is consistent with the flexing rules operated between 1999 and 2002.

Case 2. The weather deteriorates while an Observer's programme with a weather requirement is being executed (e.g. halfway through). In this case the Observer's programme's MSB is not completed, and the unused part of the MSB's total time remains available to the programme in the database.

Overheads

Overheads are in general allowed to average out, but there may be some circumstances in which the observer or TSS believes a particular programme has been systematically hit by overheads (switching instruments for example). In those cases the TSS files a note at the end of the night and the programme is credited back the time. UKIRT will provide guidance as to the maximum recommended number of instrument changes per night.

Conditions constraints

P.I.s must adequately specify conditions constraints, rather than relying on chance to get their programmes done. Note that the selection criteria for observers increase the chance that unless highly-rated, under-specified programmes will probably be executed by others. Technical assessment of proposals is highly important in this scheme, and on occasion the TAG will enforce constraints on programmes over the head of the P.I.

Acknowledgment

An observer who carries out essentially all of another observer's programme arguably deserves a degree of recompense in the published literature. UKIRT does not force co-authorship on an unwilling P.I. who has not had the opportunity to observe their own programme, but in the spirit of generosity we suggest at least an acknowledgement, and co-authorship at the discretion of the P.I. in exceptional cases where the observer added significant value to the science potential of the data.

Amendments