p2 API Python Tutorial
The Phase 2 Application Programming Interface (API) uses the lightweight JSON standard as data format to exchange information between your application and the phase 2 server at ESO. In order to program more conveniently against the API, it is helpful to create small, language-specific bindings to the API. We provide a simple example binding for Python, i.e. p2api.py. In the following sections, we discuss basic OB programming using this binding with hands-on coding examples. Note that the data exchanged in the various API calls is often instrument-specific. In order to fully understand the data required and returned by the various API calls and their detailed behaviour, please consult the Phase 2 API Specification.
Although the API binding should also work in Python 2.7, we use Python 3 for this tutorial. Please ensure that it is installed and the executable python3 is on your command line search path.
The p2api is available for macOS, recent Fedora and CentOS-7 systems as MacPorts or RPM packages from the ESO Software Repositories. Please see the instructions here to enable the relevant repositories. The package names are py<NN>-eso-p2api (where NN is one of [27,34,35,36,37,38]) for MacPorts and python2-eso-p2api (and on systems which support python3 python3-eso-p2api).
If you do not have macOS or a supported Fedora or CentOS system, or for whatever reason you prefer to install/update from "source" then the p2api Python binding is hosted at the Python Package Index, where any new version will be published. We recommend also installing pretty printing support. The following command will install p2api and pretty printing in your account for python3.
This will also install p2api's dependencies. For this tutorial we will use the interactive Python3 interpreter. Please start it and type the listed commands as we go through this tutorial. Fear not, you are safe to play in the demo environment.
You can also download the example source code hello_world.py.
Pretty Printing Support
In order to print JSON data returned from the various API calls in a somewhat more readable way, we first add pretty printing support to our code. Type
To get an overview of the available API calls, you can now type
Now let's get access to the API and log in using the 'demo' environment. Other supported environments are the 'production' environment for Paranal observation preparation and the 'production_lasilla' environment for La Silla observation preparation. Run the following code, you should see not output.
Create a Folder
Let's create a dedicated Folder in which we work. A Folder has no impact on observation execution. It is just a means to structure your content. All kinds of containers in which Observing Blocks can be created have a containerId, i.e. Runs, Folders/Subfolders, TimeLinks, Concatenations, Groups. Point your browser to the Phase 2 Demo, you will be automatically logged in with the tutorial account. Click on the "60.A-9252(G) · UVES" observing run. Details of the run will be displayed, including a "ContainerID for obximport" which should be 1538878. Let's call this ID the runContainerId. Type and execute the following
The output should be similar to
Now go back to your web browser, expand the run by clicking on its plus icon. You should now see the created Folder.
Create an OB
Now let's create a new OB inside our Folder. Run the code below.
The output should be similar to
Note that the second parameter returned from each API call, such as api.createOB(folderId, 'My First OB') is almost always a version of the created, modified or retrieved resource (OB, Template, Folder, Readme, ...). A version parameter is always required whenever such resource is modified with an API call, so that the server can protect itself against uncontrolled concurrent modifications. The detailed printout of the OB allows you to understand the properties and sub-properties an OB has, so that you can modify them.
Now go back to your browser, close and re-expand the Folder by clicking on its Folder icon. The new OB should now be visible. You can click on it to show its details.
The following code modifies some OB-level properties and then saves the OB. Note that depending on the instrument, observing constraints may or may not be available. Sending non-existent constraints results in an exception being thrown. When updating the OB, its current obVersion must be passed as parameter to the API call. Please check in the browser that the changes have arrived by refreshing the page showing OB details.
Attach Acquisition Template
Now attach an Acquisition Template, identified by its name.
With an output similar to
Please refresh your OB in the browser to verify that you template has arrived.
Edit Acquisition Template Parameters
You can set any template parameter which are not of type file or paramfile as follows. Remember, we must provide the acqTplVersion when updating the existing template.
Please refresh your OB again in the browser to verify that the values changed in the acquisition template.
Attach Science Template
Now attach a science template again identified by its name.
With an output similar to
Edit Science Template Parameters
Edit some parameters in the science template.
Define Absolute Time Constraints
Now let's define a number of absolute time constraints on our OB. In order to provide a version atcVersion to the API call, we must first retrieve the current time constraints (which are empty)
Define Sidereal Time Constraints
Sidereal time constraints work in exactly the same way as absolute ones, only their format is limited to HH:MM.
Attach and delete an Ephemeris File
ESO-compliant ephemeris files for moving targets can be produced at this website. Assuming you have produced a valid file ephem.txt, attach this as always by first getting the current version and then saving the new file
Attach, delete and download Finding Charts
You can attach up to 5 finding charts in JPEG format (each < 1 MByte) as follows, no version handling is required in this case. Let's attach two finding charts and then retrieve the list of all finding chart filenames attached (not the actual binary data). Finding charts of an OB are indexed with a 1-based index. Finally, we delete again the second one. Obviously you need to have some JPEGS in your local directory for this to work.
Refresh your OB in the browser and verify that you can see the finding charts. You can download a finding chart again by index. Note that it is considered insecure to let the server decide the filename. Instead, you have to specify it explicity. To download into file olieph.txt execute
Verify OB to status (D) or (+)
When we are done editing the OB, we should verify it. Note that we can simply verify the OB without status change as a preliminary step, or have the OB change status from (P)artially Defined to (D)efined for service mode OBs or to (+)Executable for visitor mode respectively. This is controlled by the boolean "submit" flag. In order to submit an OB to ESO for observation, it must have the respective state.
Which, if successful prints something similar to
Now fetch the OB again to confirm its changed status
Now let's duplicate our OB so we have a copy in within the same Folder (you can also duplicate to a different Folder or Scheduling Container). Also, let us verify the copy to status (D) as well so that we have two observable OB. Have a look into your browser again!
Populate the Visitor Execution Sequence (VES)
Note: The following only works if your run is a visitor mode run which are not available on the tutorial account in demo. So you cannot use the OBs that we prepared so far. Every user has a single dedicated Visitor Execution Sequence for each instrument. We can add observable visitor mode OBs in status (+) to the visitor execution sequence. If you have visitor OBs in status (+) available, this would work as follows
Creating Scheduling Containers
Assuming we are working with a service mode run, we can define Scheduling Containers, i.e. Concatenations, Groups and TimeLinks. Let's create one of each inside the Folder that we created earlier.
Refresh your browser to see those three empty Scheduling Containers in your Folder. Let us now populate those Scheduling Containers with some OBs. We could of course create new OBs as before, but for simplicity let us simply duplicate the OBs from our Folder into the three Scheduling Containers. Note that as opposed to the previous duplication, we duplicate OBs to a different destination container.
No we have 3 Scheduling Containers each with 2 OBs inside. Note that the status of these duplicated OBs is back to (P)artially Defined, we need to verify them again to move them into status (D)efined.
Changing Group Contribution of a Group OB
Each OB in a Group has an individual Group Contribution. We can access such scheduling information as follows.
No let's change the group contribution and save.
In your web browser, you would have to navigate to the Schedule view to see this value.
Changing Earliest/Latest After Previous of a TimeLink OB
All but the first OB of a TimeLink have the two relative time constraints with respect to the previous OB referred to as earliest_after_previous and latest_after_previous.
Let us modify this interval to [10 - 42 days].
Finalizing for Submission
In order to finalize our work, let us verify all six Scheduling Container OBs to status (D)
Note that once the OBs are in status (D), they can no longer be edited. The status (D) is supposed to help you in marking which OBs are completed and ready for submission to ESO. If you wish to go back to editing those OBs, you can do so by changing their status back to (P) using the API api.reviseOB(obId). Prior to submission to ESO, we also have to verify each Scheduling Container to status (D) to complete our work.
If you refresh your browser you should now see that all Scheduling Containers have also changed status to (D)efined. Once the Scheduling Containers are in status (D), they can no longer be edited, hence you can no longer add new OBs, change the order of OBs, etc. If you wish to go back to editing those Scheduling Containers, you can do so by changing their status back to (P) using the API api.reviseContainer(containerId). Note that whenever you revise an OB in a Scheduling Container back to status (P), as a side effect, also the Scheduling Container status will change back to (P).
Submission to ESO
You can now submit your run to ESO. For this, we have to read the runId from the browser URL, which is the trailing number in https://www.eso.org/p2demo/home/run/6092526
This call will return a summary of the submitted observations. Note that status of all submitted Scheduling Containers and OBs will change to (R)eview so that they become read-only.
Well done! You made it to the end of this tutorial. If you have any questions or suggestions for improvements, please don't hesitate to get in touch with us via Helpdesk portal.