Every OB for Service Mode observation that passes the Phase 2 review and is hence approved, is added to the instrument's queue. At the start of the observing period, the queues of that specific period are available at the observatory and used by the ESO staff astronomer on duty to perform observations. Given the large amount of OBs with very similar constraints within each observing run and a large number of different observing runs with similar or different targets and constraints, ESO has implemented a ranking algorithm to help the observer at the telescope to choose the best OB to be executed at any given time of the night among the large number of different OBs. The ranking algorithm produces an ordered list of OBs, whose order depends on:

• the relative scientific prority between the observing runs to which OBs belong
• the absolute time constraints assigned to all sorts of OBs (either "loose" or within a Scheduling Container);
• the relative time constraints assigned to time link OBs (which are eventually translated to absolute time constraints during OB execution);
• the user priority assigned to individual OBs or to a container;
• the group contribution assigned to group OBs.

The ranking algorithm in a nutshell 

We describe here briefly how the ranking based on these different priorities is computed. The algorithm described here was implemented first for VISTA (for more details see Bierwirth et al. 2010, SPIE 7737, 19), and was later extended for use on VST, VLT and VLTI with minor adaptations for specific instruments (e.g. adding filtering and ranking according to LST intervals, availability of laser, availability of a given baseline for VLTI observations, MOS masks, and other hardware components, as well as considering modifications needed to include additional constraints such as PWV and ATM). 

During the Service Mode observing night, the ranking algorithm is used within the Observing Tool (OT), a software dedicated to the managements of OBs and support of telescope operations. OT applies a ranking algorithm to the OBs in the queue. The result is a list of ordered OBs. As a general principle, the OB that is ranked at the top of the list should be executed first. Still, the complexity of the observations cannot be fully covered by the algorithm. As such, the raked list of OBs is always monitored and evaluated by the night astronomer who ultimately makes the real-time decision on which OB to send to execution.

Overall, OT calculates a rank string for all OBs that are observable at any given time of the night. The rank string is composed of the following substrings:

rank string = (observability class)_(run class rank)_(user priority)_(group rank)

The individual ingredients and criteria used to compute the rank string are reported here and sorted to reflect the logic encapsulated by the algorithm:

1. The non-observable OBs. First the non-observable OBs are filtered out, taking into account the real-time observing conditions (seeing, sky transparency, lunar illumination, moon distance, PWV, absolute or sidereal time intervals) with respect to the constraints set in the OBs as well as visiblity of the target given its coordinates and requested maximum airmass.
2. The observability class. Based on the current observing conditions (seeing, sky transparency, moon constraints, PWV), as well as the target’s remaining tracking time (depending on airmass and sidereal time) and observability within absolute time windows (OBs are ranked based on how much time is left to observe them within the suitable time window), the observability class for each OB is computed, assigning higher priority to those OBs which have smaller probability to satisfy all the combined constraints. 

   The observability class for OBs is further modified by a push-pull (PP) factor. The C-ranked (filler) programme OBs have a positive PP factor which pushes them to the bottom, while the pre-imaging runs, carryover, Large Programme and DDT runs, have a slightly negative PP factor, pulling them towards the top of the ranked list of OBs. 

3. The run class rank. The run class rank is the relative scientific priority between different runs (programmes) set by the proposal review panels or distributed peer review process. All the OBs that satisfy the current observing conditions are ranked according to the run class rank priority. First is the A-rank class for Large Programmes (A1), followed by all other A-rank runs (A2) and then come B-rank class and at the bottom C-rank runs. Within each rank class the runs are also sorted according to the scientific grade.
4. The user priority. The user priority is assigned to loose (independent) OBs and to scheduling containers. All OBs belonging to a scheduling container have the same user priority, which they inherit from their container. The user priority ranges from 1 to 10, where the smaller number corresponds to the higher priority. The user priority at the OB or container level can be selected by the user when preparing observations in p2. The default user priority value is 1.
5. The group rank. The group rank is composed of group score and group contribution. OBs belonging to a group are given a group contribution value, indicating how much the overall group’s score is increased by executing that OB. The group contribution is an integer in the range [1 .... MaxGrpContrib] and it is entered using the p2UI in the Schedule tab window (default group contribution value for all OBs within a group container is 10). The group score is a dynamic value - it is calculated by summing up all group contribution values of the executed and completed OBs within the group.

6. In order to make different group scores comparable, they are normalised by the total group contribution, and are expressed in terms of percentage with two significant decimal digits. Finally, the normalised group score and contribution are inverted, such that the lower values correspond to higher priorities (same as for user priority). The contribution of group ranking to the overall rank of the OB can then be defined as follows:

   group rank = (inverted normalised group score) - (inverted normalised group contribution)

   Whenever a group OB is executed, it raises the group’s (non-inverted) normalised score by its (non-inverted) normalised group contribution, i.e. the update of the group score has to operate on non-inverted values, before inverting the new score for updating the group rank. So, while the user priority of an OB (or a container) is static, the group score is a dynamic ranking criterion.

   This is best illustrated in the following practical example. 

Let's assume that there is an observing run with two identical groups (with the same priorities based on all other criteria). Group 1 contains 3 OBs (OB_A, OB_B, and OB_C), and Group 2 also contains three OBs (OB_D , OB_E , and OB_F ).

The night astronomer uses the OT to make a first ranking. OT computes the inverted normalised group score and the group contribution to form the group rank. Given that none of the OBs is completed, the normalised group scores are the same and they get sorted according to the normalised (inverted) group contribution values.

The execution of Group 1 is started by executing OB_A. The group score then raises to 50.00%, and immediately after that the OB_C is executed raising the group score of OB_B to 80.00%. 

From the above, it is clear that, once the execution of OBs belonging to Group 1 is started, the priority of the OBs within the same group increases with respect to the OBs belonging to Group 2.

Let's assume that OB_B is not observable as a certain observing constrain (e.g. seeing conditions) is violated. Group 1 has no more observable OBs to offer and hence the execution is switched to Group 2. Then OB_D is executed, increasing the group score to 50.00% of all OBs belonging to Group 2.

The execution will return to Group 1 as soon as OB_B becomes observable again (seeing is back within the requested contraints). After that OB_F is executed, increasing its group score to 80.00%.