P2PP has been in use at ESO telescopes since 1997 and has undergone much evolution since then, trying to adapt to both operational and user-friendliness needs as they have been identified, and providing enhanced functionality.

P2PP development continues. Motivated by specific requirements that were set by the ESO Public Survey programmes with Survey Telescopes, VST and VISTA, on Paranal, the new P2PP version 3 (P2PP3) has been developed. Many of these new functionalities and enhancements of P2PP3 are useful also for all Service Mode users of ESO telescopes, including those conducting short programmes. Therefore ESO has started to extend the use of the new P2PP3 also for "normal" programmes on the VLT and other telescopes in the future. Since Period 90 P2PP3 has to be used for preparation of observations of all instruments on the VLT, VLTI, VST or VISTA.

This page provides a quick overview of the enhancements to the functionality of P2PP version 3 and provides links to the relevant documentation.

User Manual and Related Documents

The users preparing the observations for the VLT, VLTI, VST, and VISTA instruments should read the P2PP version 3 User Manual for a detailed description of the currently available functionalities.

The text and video tutorials are available to describe the tool and guide you step-by-step through the observation preparation process.

Phase 2 Delegation

Starting with Phase 2 preparation for Period 90 with P2PP 3.3.0 it is now possible for a PI of an observing run to allow another user to create the OBs, READMEs, etc. using their own User Portal account by delegating Phase 2 preparation permission to them. This means that there is no longer a need for the PI to reveal their User Portal login credentials to anyone for this purpose.
The delegate need not be a Co-I on the proposal, but must be a registered User Portal user. Note that unlike Data Access Delegation (with which a PI can delegate data access to multiple User Portal users) Phase 2 Delegation can only be granted to one person per observing run at a time. A different person can be chosen as the delegate for different runs of the same programme. Delegating Phase 2 does not remove Phase 2 access permissions from the PI him/herself. Thus, PIs who use Phase 2 delegation are kindly asked to coordinate Phase 2 preparation between themselves and their delegate. Delegation can be viewed and administered though the Access Control ESO web page.
Once a user has been granted Phase 2 permissions for a run they will see the run in P2PP (with a small green check mark distinguishing it as a delegated run) after logging in with their own credentials.

Time-linking of OBs

It is frequent that 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 P2PP 3. 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 P2PP version 3 within the new "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 main P2PP Gui window. However, please notice that this sequence is not strictly enforced during execution.

Definition of groups of OBs

In P2PP 2 it was already 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.