Service Mode Rules and Recommendations for Observation Blocks
Preparing Observation Blocks
Both Visitor and Service Mode programmes are carried out at all ESO telescopes by executing Observation Blocks (OBs) provided by the users. OBs are constructed and submitted to ESO using the P2PP version 3 (P2PP3) Tool for all Paranal instruments.
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 are normally 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 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. 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, especially if they belong to priority groups B or C. 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.
Additional Service Mode Requirements for HAWK-I
Saturation limits and persistence
Like many other infrared detectors the HAWK-I detectors show a persistence effect if the observed sources are too bright. In Service Mode, this problem would seriously compromise subsequent observations of other programmes, therefore the following rules apply:
- When using DITs smaller than 30 secs, persistence effects can be neglected.
- When using larger DITs the maximum accepted saturation is 7 times the saturation level.
Because the saturation level on a given object also depends on the sky conditions, users are recommended to check carefully their fields against saturation using the HAWKI Exposure Time Calculator during Phase II.
The magnitude of the brightest object in the field, including standard stars, must be indicated in the "Instrument comments" field in each OB.
Requests for imaging observations not compliant with these limits must be submitted as a Phase 2 Waiver Request, which will be evaluated on individual case basis. If judged acceptable, ESO will try to devise operational strategies (e.g. observations at the end of the night, scheduling other BB imaging OBs after the observations in question).
Minimum Time between offsets
Rapid offsets of the telescope lead to a degradation of image quality and to excessive overheads (>> 100%). Therefore, the minimum time allowed between telescope offsets is one (1) minute. The integration time parameters (DIT, NDIT, NEXP) should be defined so as to ensure that this rule is strictly followed. Please consider that with large sky offsets and DIT * NDIT * NEXP = 60s, the overheads are already on the order of 100%.
In order to prevent daytime calibrations to run over an unreasonable execution time, the DIT values for long exposure times are restricted. In Service Mode it is therefore mandatory to select one of the following DIT values in case the DIT exceeds 120 seconds: 150, 180, 240, 300, 600, 900 seconds. For observations with broad-band filters please remember to define short DIT values,i.e. lower than 15 seconds, in order to avoid saturation on the sky background.
HAWK-I follows the standard astronomical offset conventions and definitions: North is up and East to the left.
All offsets are given as telescope offsets in arcseconds: if the telescope moves towards N-E the target moves in the opposite direction, i.e. towards S-W.
Detector gaps and target acquisition
Mind the gaps! The HAWK-I field consists of 4 detectors with gaps of 15" in between them. If you don't want your target to fall onto the center of the gaps, you should define an offset in the acquisition template. This is done by using the following two entries in the HAWKI_img_acq_Preset template:
- TEL.TARG.OFFSETALPHA "Alpha offset for the target (arcsec)"
- TEL.TARG.OFFSETDELTA "Delta offset for the target (arcsec)"
The figure below shows the offset conventions (TEL.TARG.OFFSETALPHA, TEL.TARG.OFFSETDELTA) to place the target in the center of one of the four quadrant, assuming that your target coordinates match the OB coordinates (i.e. at the beginning of the acquisition your target is in the middle of the gap).
For instance, to place the target in the center of Q1, which is the lower left quadrant (S-E), the telescope must move towards N-W, hence you must use the following offsets in the P2PP:
- TEL.TARG.OFFSETALPHA "Alpha offset for the target (arcsec)" : -115"
- TEL.TARG.OFFSETDELTA "Delta offset for the target (arcsec)" : +115"
The positive position angle is defined from North to East. As shown in the figures below, if for PA=0 your target falls in the center of Q1 and you want to move it in Q4 you can either change the parameters TEL.TARG.OFFSETALPHA, TEL.TARG.OFFSETDELTA (see previous section) or just rotate the PA by +90 degrees.
FastPhot mode observations
FastPhot mode (FastJitter observations) is offered both in VM and in SM. However, in the case of occultations, only disappearances are offered in SM. VM must be requested in the case of appearances.
The following constraints on the detector window parameters are imposed:
- Only contiguous windows that span entirely the width of the detectors are offered. This implies that "Number of columns for each window stripe"=128 and "First column of window within a stripe"=1. Therefore, the total size of the output file along the X axis is always 128 x 32 = 4096 pixels.
- Only 3 values for the window height are allowed, hence "Number of rows for each window stripe" can be set to 32, 64 or 128 pixels. There are no restrictions on where the windows are located along the Y axis, the users are free to select any possible value, from 1 to 2048, as the "First row of window within a stripe".