Service Mode Rules and Recommendations for Observation Blocks

Preparing Observation Blocks

Observations at all ESO telescopes are carried out by executing Observation Blocks (OBs) provided by the users. OBs for Service Mode runs with Paranal Instruments must be made with p2. For (designated) Visitor Mode observation preparation, please follow dedicated Visitor Mode Guidelines.

Please refer to the P2PP3 User Manual and to the User Manuals of the different instruments for more specific information on the structure and content of OBs, and how to build OBs for different instruments. A number of tutorials describing step-by-step the construction of OBs for different instruments is available.

Service Mode OBs: rules and advices

It is important to keep in mind the Service Mode policies and the following rules and guidelines when designing a Service Mode programme or when preparing a Phase 2 package:

  • Some observing strategies cannot be supported in Service Mode; in particular, real-time decisions about the sequencing of OBs, complex OB sequencing, or decisions based on the outcome of previously executed OBs (like adjustment of integration times or execution of some OBs instead of others).
  • OBs are only executed once. If you want to repeat an identical observation multiple times, you must submit multiple OBs. This requirement applies to standard stars as well.
  • OBs are normally executed non-contiguously. Since efficient Service Mode operations require continuous flexibility to best match the OB constraints with actual observing conditions, OBs for a given programme may be scheduled non-contiguously. Therefore, users should not expect their OBs to be executed in a specific sequence or in a linked way, unless a sound scientific justification (indicated in the README file and approved with a Phase 2 Waiver in case of a contiguous execution lasting longer than 1 hr) exists. Approved OB sequences should then be prepared as concatenations. Exceptions to this rule are cases in which one OB observing a calibration source needs to be executed contiguously to a science OB. In such a case place both OBs into a concatenation scheduling container to enforce their contiguous execution.
  • Multi-mode, multi-configuration OBs are normally not permitted in Service Mode. Although multiple configurations within one OB may sometimes reduce overheads, scheduling and calibrating such OBs is extremely inefficient and can increase the calibration load to an unsustainable level. Examples of such multi-configuration OBs are those combining imaging and spectroscopy in a single OB, spectroscopy with multiple grisms or multiple central wavelength settings, or imaging with a large number of filters (although most imagers allow multiple broadband filters in one OB). Multi-configuration OBs are accepted only if duly justified and authorized by means of a Phase 2 Waiver Request.
  • OB execution times must be below 1 hour. Long OBs are more difficult to schedule and execute within the specified constraints because of the unpredictable evolution of the observing conditions. For this reason, OBs taking more than one hour to execute are accepted by ESO only in exceptional cases and provided that a Phase 2 Waiver Request is submitted and approved. In such cases, ESO will consider the OB successfully executed if the constraints were fulfilled during the first hour of execution, even if conditions degrade after that time.
  • Concatenation scheduling container execution time must be below 1 hour and exceptionally for CRIRES instrument science+telluric standard concatenation must be below 1.5h. Only in exceptional cases, and provided that a Phase 2 Waiver Request is submitted and approved, longer concatenations may be submitted. In such cases, ESO will consider the concatenated OBs successfully executed if the constraints were fulfilled during the first hour of execution, even if conditions degrade after that time.
  • User-provided calibration OBs that need to be executed contiguously with science OBs need to be specified via concatenation scheduling containers.
  • Time constraints must be indicated in the OBs. If you intend to observe time-critical events or monitor a target at specific time windows, you need to indicate this under the Time Intervals tab of the OBs. Please note that absolute (UT) time constraints refer to the interval in which the OB can be started, whereas for Local Sidereal Time (LST) time intervals, the time interval refers to the entire duration of the OB. For monitoring observations it is often more appropriate to put OBs in a time-link container. Specifying time windows as broad as possible will reduce the possibilities that your OBs are not executed because of higher priority programmes or because the observing conditions did not allow the observations during the interval that you specified.  Usage of absolute time intervals must be scientifically justified in the README file. Please read carefully the time-critial OB execution policy.
  • Specify the weakest possible Constraint Set values. OBs that can be executed under a broad range of conditions are easier to schedule. In particular, if photometry is needed of a field, it is normally sufficient to obtain a short integration under photometric conditions (transparency = PHO) and carry out the rest of the integration with OBs having a transparency = CLR constraint.

Time-linking of OBs

Some OBs must be executed within precise time windows, rather than any time when the external conditions (moon, seeing, transparency...) would allow the execution. The following types of time-dependencies can be recognized:

  • Absolute time constraints, meaning that an OB must be executed at specific dates that can be predetermined. An example is the observation of a binary star at a precise phase of its period.
  • Relative time links, implying that an OB must be executed within a time interval after the execution of a previous OB, but not necessarily at a fixed date. Examples of this are monitoring observations of a variable source at roughly constant intervals.

Both types of time-dependency are implemented within p2. Whereas absolute time constraints are available at the level of single OBs, the relative time links are implemented within the new "Time Link" container.

Within a Time Link container, the user can define a series of OBs, having the earliest and latest time when a given OB in the series must be executed with respect to the preceding OB. The time-related information is stored in a database, from where it is retrieved by scheduling tools available to the operator on the mountain in order to build up a short-term schedule that properly takes these constraints into account.

Concatenation of OBs

In some cases it may be desired to execute the OBs consecutively, with no other observations in between. This has been implemented in p2 within the "Concatenation" container. The Concatenation container consists of two or more OBs that must be executed "back-to-back" without breaks. The sequence of the execution of OBs in a Concatenation follows the sequence as they are listed in the p2 window. However, please notice that this sequence is not strictly enforced during execution.

Definition of groups of OBs

In P2PP v2 it was possible to assign an execution priority to each OB, so that the operator is aware of the ones that have a higher scientific importance at the time of deciding on observations to execute for a given programme.

It has been recognized nevertheless that such simple priority scheme is sometimes insufficient to deal with programmes containing large number of OBs, and especially for surveys containing large numbers of target fields observed in a number of instrumental setups. In such cases the need for a prioritization scheme above the individual OB level, which can take into account the past execution history of the programme, becomes clear. One can consider for instance the case of a survey of several target fields to be observed through several different filters, with each field and filter specified in a single OBs. Depending on the science goals of the programme it may be desirable to complete the observations of a given field in all filters before proceeding to the next field, or conversely to observe all the fields in a given filter before proceeding to the next filter, or even ensure that contiguous coverage among the fields takes priority.

The approach adopted to deal with such cases is the definition of Groups of OBs, in which internal priorities within each group are reflected in the form of a contribution of each OB to the total group score. The short-term scheduling tools available on the mountain will take into account the current scores of each group of OBs, and will then apply a number of rules in order to prioritize the possible OBs to be executed according to them. Such rules will for instance give the highest execution priority to those OBs that set a new maximum of the score among the existing groups; and among those, the highest priority will be given in turn to those that produce the largest increase in group score. By assigning to the OBs the appropriate contributions to the scores of their respective groups, the users can make sure that the progress in the execution of the programme will take place in a way that is consistent with the scientific priorities of the observations. In addition, it will be possible to assign different priorities to each group.

Import of target fields produced by the Survey Area Definition Tool

The Survey Area Definition Tool (SADT) is a utility developed by the VISTA consortium that allows users to define areas to be covered by surveys executed with either VIRCAM at VISTA or OmegaCam at the VST according to a number of criteria. The SADT determines the central coordinates of the different pointings required to cover the field according to the specifications, as well as ancillary guide star information to allow acquisition and guiding. The output produced is a file to be ingested into P2PP version 3 containing all the target information needed for the preparation of the OBs with which the survey will be executed.

The latest distribution of the tool can be downloaded from the SADT web page, where also a video tutorial and the SADT Cookbook with step-by-step instructions and examples can be found.


Additional Service Mode Requirements for NACO

Recommendations for Cube Mode usage

The window size is now selectable with the following choices: 1024 (full frame), 768, 512, 384, 256, 128, and 64. The window will be square, and centered on pixel (512,512). Choosing small windows allows shorter DITs but increases the noise. For small windows some 8-pixel noise pattern appears in the frames.

The maximum file size for a cube is 512 MB. This, in turn, constrains the maximum value for NDIT according to the following Table (but consult the User Manual for important notes!):

Detector Setup Window size Min DIT Max NDIT Frame Loss Time Loss
DCR/HD 1024 0.35 126 20-22% ~16s
DCR/HD 1024 0.50 126 0 0
DCR/HD 768 0.27 224 0 0
DCR/HD 512 0.109 508 0 0
DCR/HD 384 0.075 900 0 0
DCR/HD 256 0.039 2027 0 0
DCR/HD 128 0.016 8049 0 0
DCR/HD 64 0.007 31711 0 0
           
FNS/HS 1024 1.793 126 1 frame 0
FNS/HS 768 1.2 224 1 frame 0
FNS/HS 512 0.419 508 1 frame 0
FNS/HS 384 0.35 900 1 frame 0
FNS/HS 256 0.145 2027 1 frame 0
FNS/HS 128 0.048 8049 1 frame 0
FNS/HS 64 0.014 31711 1 frame 0
           
UCR/HD 1024 0.175 126 ~39% ~15s
UCR/HD 1024 0.35 126 0 ~3s
UCR/HD 768 0.14 224 ~30% ~15s
UCR/HD 512 0.055 508 ~25% ~5s
UCR/HD 512 0.08 508 0 0
UCR/HD 384 0.045 900 0 0
UCR/HD 256 0.02 2027 0 0
UCR/HD 128 0.008 8049 0 0
UCR/HD 64 0.004 31711 ~21% ?
           
UCR/HWD 1024 0.175 126 ~39% ~15s
UCR/HWD 1024 0.35 126 0 ~3s
UCR/HWD 768 0.14 224 ~30% ~15s
UCR/HWD 512 0.055 508 ~28% ~5s
UCR/HWD 512 0.08 508 0  
UCR/HWD 384 0.045 900 0 0
UCR/HWD 256 0.02 2027 0 0
UCR/HWD 128 0.008 8049 0 0
UCR/HWD 64 0.004 31711 ~21% ?
UCR/HWD 64 0.007 31711 0 0

Minimum time between exposures

The minimum time between exposures should be 20 seconds. Depending on which template is used, the integration time parameters (DIT, NDIT) should be defined so as to ensure that this rule is strictly followed. The reason for this limitation is to allow the Active Optics to settle and correct the M1 at least once. In the course of a template, if Active Optics corrections are not sent to the mirror, aberrations will start piling up, significantly affecting the achievable image quality.

Bright sources

Direct imaging of very bright objects results in residual images lasting for several minutes. In Service Mode, this problem can affect subsequent observations of other programs.

Brightness limits.

Observations involving fields with objects brighter than those specifed in the table below cannot be guaranteed.

Requests for observations not compliant with these limits must be submitted as a Phase 2 Waiver Request.

Mode Magnitude Limit
SW broad band imaging 6
SW narrow band imaging 4
LW broad band imaging 5
LW narrow band imaging 3
spectroscopy 2

Brightness limits: Acquisition

For acquisition of bright targets, the following filter settings must be used. Note that this applies not only to standard stars, but also to other bright objects in the field of view.

IR Magnitude Filters to use
> 6 Any
>4 and <6 Any Narrow Band filter
>2 and <4 Any filter together with a neutral density filter (ND_short for SW filters and ND_Long for LW filters)
0 - 2 Any Narrow Band filter together with a neutral density filter (ND_short for SW filters and ND_Long for LW filters)

Important note: in case of spectroscopic observation when the bright object in the field of view is not the science target, the target may become too faint to centre on slit due to the use of the Narrow Band filter(s). In this case offsets from a reference star should be used.

LST ranges and targets to be tracked through the meridian

There are a three basic rules that must be abided by for such cases:

  • For targets that are to be tracked through the meridian the name of the OB must be suffixed with "_meridian".
  • For targets that are to be tracked through the meridian the OB must contain an LST time interval. This makes it straightforward to schedule at the telescope.
  • For any OB that has an LST time interval specified the length of that interval must exceed the total execution time for the OB itself, but by no more than 10 minutes.

PSF OBs and concatenations

There are two basic rules that must be followed for the case where you are using PSF calibration OBs, to facilitate their correct scheduling at the telescope:

  • The science OB and its corresponding PSF OB must be placed together into a concatenation.
  • The PSF OB must be listed second in the concatenation (that is, it must appear below the science OB).

Atmospheric Turbulence Model Constraint Set Parameter

The "Atmospheric Turbulence Model." Constraint Set parameter is used at the telescope to assist in the scheduling of OBs. The default value for this parameter is "no constraint," which implies that no consideration for the atmospheric turbulence is to be considered when scheduling such an OB. The other value for this parameter, "default Paranal atmosphere model," implies that the atmospheric turbulence is to be considered in the scheduling of the associated OB. Hence, users who are preparing OBs for "No AO" mode must use "no constraint" while users preparing OBs that make use of adaptive optics must select "default Paranal atmosphere model."

Editing the configuration file that is produced by the Preparation Software (PS).

The PS produces an ASCII file with the extension aofcg which is required by P2PP and is used to set up NAOS. This file should never be manually edited. If you do, the execution of your OB will be severely compromised and your name will go on a yellow piece of paper on a big white board.

Instrument selector

On this page: