OB containers
​
Sometimes an observation may need a more complex structure than a simple or several loose OBs. This might happen if the OB must be executed with a sequence or during the same night, or if they have a specific cadence. To To give you more control over your observation and its execution, you can group your OBs in so called containers. These could be of different nature depending on your need. You can find here a complete list of all possibility together with the utorials on how to create a specific container.
​
Definition of groups of OBs
Groups of OBs are used to express the preference to complete observations of a given group of OBs before continuing with other OBs (or groups of OBs) within the same observing run. This is the most loose scheduling container concept, and the priority for execution of the group with respect to other groups within the same run is defined though group priority that has values 1-10 (1 top, 10 lowest priority) as for the user priority for loose OBs. The priority for execution of OBs within the given group is regulated through the OB group contribution.
If OBs within the group, whose observation started, are not observable (constraints are not fulfilled), it is possible to start observations of another group. After that group score defines which group will be given priority in case both groups of OBs are observable again.
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 typically follows the sequence as they are listed in the p2 window.
​
Time-linking of OBs
Some OBs must be executed within precise time windows for scientific reasons, 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 or a planetary transit observation.
-
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 some pre-defined 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.
If an OB with absolute time constraint or time-linked OB that acquired an absolute time constraint following execution of a previous OB in sequence (i.e. OB to be observed after earliest from and before latest from time of the previous OB in the sequence) is not successfully completed within the specified time interval, it will expire and get status F(ailed). Such an OB is not observable any more and policy for time-critical OB execution applies.
If the time-linked OB expired in the middle of a time-link sequence, the sequence execution continues as follows:
-
If the failed OB is not the very first OB of the time link, it had the absolute time window corresponding to delay from the previously executed OB. After it expired the next OB acquires an absolute time window by adding the relative minimum and maximum time delays to an assumed hypothetical execution for the failed OB in the middle of its constraint window.
-
If the failed OB is the very first OB of the time link, the failure can only occur if this OB has one or more absolute time constraints defined and all of them have expired. In this case the next OB acquires an absolute time window by adding its relative minimum and maximum time delays to an assumed hypothetical execution of the failed OB at the end of its last absolute time interval.
It should be noticed that, depending on the length of the relative time intervals, and the delays between them, a failure of an OB in a sequence may result in a cascade of failing OBs.
​