p1 - Help

Here we provide a detailed description of the new p1 interface, by guiding you through each of the steps required to complete the preparation of an observing proposal.  

A few general remarks:

1. Any time you type something, a red asterisk will appear at the top of the window that is being edited. This asterisk disappears once the text has been saved in the database.

2. As soon as you create a new proposal, immediately below the Title, there will appear a red box. This is to remind you which sections of the proposal still have to be completed and any associated issues applicable.

3. Once you have added the CoI(s) all the collaborators can edit the proposal simultaneously. You also the option of nominating one as dPI (see below). 

4. The PI can submit, retract and/or delete a proposal. Delegated PIs (dPI) have the same privileges, although the ultimate responsibility for the content of the proposal lies with the PI.

A short video (about 4min) is available to guide you through the basic steps of proposal preparation and submission.

 

p1 is implemented using Google’s Angular framework and it should work on any recent browser (Chrome, Firefox, Edge, Safari). The system requirements of p1 are less stringent than basic security requirements. If you suspect that p1 does not run because your browser is too old, you most likely have a dangerously old version. For more details, refer to Angular browser support



Summary

The section provides an overview of all sections of your observing proposal. The individual parts can be accessed through the menu in the left column, or via the buttons in each section.   

At the very top of the Summary, some high-level information can be found: ProgrammeID (this will be assigned only after you submit the proposal), Programme Type, Cycle, and the current Status of your proposal (Draft, Valid or Submitted, being the most common ones).

At the side, there are a few key buttons:

Submit/Unsubmit allows you to submit or unsubmit a proposal, if you wish to update/change something. This action can be performed only by the PI or their delegated PI (dPI). Once submitted, the Status of your proposal will change to Valid (for DDT proposals) or Submitted (for regular proposals calls; it will then turn into Valid after the submission deadline); if unsubmitted, its status will be reverted to Draft.  Important: if a proposal is in Draft status it will be ignored, even if already submitted once.  

'Delete' allows you to delete entirely your proposal. Important: there is no undo for the Delete action - once clicked, the proposal is lost.

'PDF' allows you to create a pdf printer-friendly version of your proposal.  

Red Box: this highly visible checklist box alerts you about all pending issues that need to be resolved before you can submit your proposal. Since this box appears as soon as you create a new proposal, it will list all issues of a still empty proposal at first, but as you progress with your proposal preparation, the alerts will start to disappear.

 

file
file

 

 

Title & Abstract

The Title is the first thing that one usually specifies when creating a New Proposal from the p1 interface. It can be of course revised also later on while working on the proposal.

The Abstract is a free text box where you need to summarise the scientific goals of your proposal. 

 

Keywords

For the time being, the Keywords are the OPC Science Categories (A, B,C and D and the sub-categories therein). You need to choose the one that is the closest match to the scientific field of your proposal.  

In the near future, the OPC Science Categories will be replaced by the same Scientific Keywords that are used by scientific journals to classify your research manuscripts. These keywords will also appear in your User Portal profile, so that if eventually recruited to serve as an OPC referee, proposals can easily be matched to the expertise of referees.

file

Investigators

Here is where you define your proposal team of investigators. You, as the PI, will already be listed, since you have used your User Portal credentials to login onto the p1 system. 

NEW - All investigators (PI, dPI, coIs) must be registered in the ESO User Portal.  

If some of your collaborators are not registered yet, invite them to do so by visiting the User Portal registration page. 

To add collaborators, type their email in the search field, and select the person from the list (because of personal data protection constraints, the system does not allow name-based searches). 

file

Next, select the role of the collaborator you are adding:

Principal Investigator (PI): full privileges to modify, submit, retract and delete proposals, to get a PDF of the proposal, and to add and remove collaborators, and change their privileges.

Delegated PI (dPI): full PI privileges.

Co-Investigator (coI): privileges to modify the proposal and get a PDF.

The roles can also be modified at a later stage of the proposal preparation.   

Beware that, as PI or dPI, you can also strip yourself of the PI/dPI privileges. If you do so, you will not be able to submit/retract the proposal, or change the list of collaborators.

file

Rationale

Here is where you upload the Scientific Rationale of your observing proposal in PDF format, which you have prepared offline using one of the provided templates:

·       Google Doc: Open the file, click File > Make a Copy  to edit in your Google Drive.

·       Microsoft Word: Normal or Large

·       LaTeX: template file (same template for Normal and Large Programmes). No sty file needed. In case you wish to latex the template file, here are the two associated figures (Fig1.pdf and Fig2.pdf)

These templates can be edited collaboratively with Google Drive sharing, MS Word 360 and similar sharing mechanisms. LaTeX template can be edited collaboratively on overleaf.com

 

Page Limits

For Large and GTO-Large proposals, the pdf must be 5 pages of less (up to 3 pages for the scientific rationale; up to 2 pages for figures).

For Normal and all other types of proposals, the pdf must be 2 pages or less.

Longer files will be rejected.

Important note: Changes to Section Headings and/or text formatting are forbidden. The format of the templates is not checked. However, proposals with blatantly modified format (smaller font, smaller margins, smaller interline...) will not be considered. It is acceptable to use smaller (but still comfortably readable) fonts for picture captions, references and similar ancillary material.

 

Targets

Here you define the science targets that you wish to observe, any Reference Star (as required by some instruments), and you can add special target notes.

Depending on the size of your targets list, you can either take advantage of the 'Add target' or 'Import target list' functionalities. 

The former is recommended for short lists of targets. It opens a window that retrieves basic details directly from Sesame, after you have specified your object identifier. It's always good to double check that the information thus retrieved is correct. Information can be modified (e.g. to fine-tune coordinates) or added.

file

The latter is recommended for long lists of targets. It allows you to upload a list of targets, in CSV format. The minimum set of information that needs to be specified is 'Name, RA, Dec, Mag', but a target table can include the following entries:

  • Name = object identifier. Each target must have a different identifier. Each identifier must include at least three characters.

  • RA = Right Ascension, hh:mm:ss.sss

  • Dec = Declination, +dd:mm:ss.ss

  • System = Coordinate system: J2000 (for FK5), B1950 (for FK4), ICRS. Other systems are not accepted.

  • Rv = Radial Velocity, in km/s  

  • Mag = magnitudes. Group them between brackets:  (V=21.2,R=23.1,J=20.9)

  • Note = comment, free text.

For distant objects:

  • pmra_arcsec ,  pmde_arcsec = proper motion in arcsec/year

  • Epoch used for the proper motions

  • Plx = paralax, in milli-arcsec

  • z = redshift

For Solar System Objects:

  dra ,  dde = representative non-sidereal motion, in arcsec/sec

Important note: if your table columns are not labeled, then the system expects to process the complete table with the columns ordered as listed above; if your table has fewer columns or has a different order of the columns, then you need to label each column with its exact content (using the names listed above) so that the system can recognise the content of the table.

Examples of valid CSV files are available: minimalist, complete. Note that properly formatted CSV files are easy to produce with spreadsheets, like MS-Excel or Google-Sheet.

If you have many targets (>50) and if your science case allows it, you can define a smaller number of representative targets, each representing n real targets (e.g., n=10). When defining the individual observations on these representative targets, set the Repeat factor to the same n to account for the total telescope time.

 

Runs

Here is where you specify the observing runs; one per instrument, run type and observing mode, because a run represents the minimum schedulable entity. For each run, you will also have to specify the atmospheric constraints required by your observations.  

A Run defines a series of observations to be performed with one instrument, with a common set of observing constraints (that is, all the observations require conditions that have the same probability of realization). Depending on the instrument there may be additional constraints on what can be mixed and matched in a Run.

 

How to start:

Create a new Run with [+add Run]. Assign a name to the Run – you can call them A, B, C... if you want to reproduce the old ESOFORM look, but more informative names can be used. Select the Instrument, Run Type, Observing Mode, Proprietary Period. For some types of programmes, the Period during which the observations are to be extecuted can be chosen (Large, Monitoring programmes). Set the proprietary period to reduce the default or leave the default value.

file

Warning: as of today, it is not (yet) possible to change the TYPE nor MODE of a Run . This will be implemented in due course. 

Define the type of observations you will need for this Run by adding one or more Set-Up(s) to your Run with [+ add observing setup]. Each type of observation is one Set-Up. There can be more than one for a Run.

Define a Set-Up: the interface will guide you through this, by prompting you with a series of pull-down menus. You will start by selecting one generic Mode (which applies to all observations in that set-up, e.g. “FORS Imaging”, or “SPHERE IRDIS Long-slit spectro”, "UVES Slit"), and one or more individual observation(s) - these can be added by clicking on the + button). Each of these are further defined by selecting those set-up elements that are relevant at Phase1, i.e. for scheduling the observations and for performing the technical feasibility reviews. Users familiar with the ESO p2 system will recognize some of the features.  

 

add-on

 

Duplicate: a Run can be duplicated (by clicking on the small 'double-proposal' icon on the right side of the Run) and then edited. For instance, you may find this feature useful when you need to specify similar observations to be performed under different conditions (e.g., good seeing for faint sources, relaxed seeing for bright sources), or different time constraints. However, beware, it is possible to type incompatible time constraints, thus rendering the run unschedulable.


Time Constraints: Each run can have separate time constraints. These are specified with a custom language that is defined here. These time constraints replace and consolidate the series of independent time constraints fields of the old ESOFORM, allowing for both absolute and relative time constraints. The new schema also lets you visualize immediately the time constraints you specify.

 

timeconstraints

Targets --> Runs

This is where you associate targets to runs, by selecting the target(s) and the run that should observe it(them). There is no constraint on the number of targets associated to a run (1, 2, .. all), so long as at least one target is associated to each run that you have created. 

By performing this association, you create a series of individual Observations:  each observing Set-Up of the Run will become an Observation for each Target. For instance, if you associate 5 Targets to a Run with 2 Set-Ups, this creates 10 Observations, 2 for each of the 5 Targets. 

targetsruns

If you want to skip a given Observation for a given Target, this can be done by setting its 'Repeat' to 0 (see next section below). If you want to skip many Observations or many Targets, it is probably more convenient to split the Run.

 

Observations

In this section, you can request time for each of the Observations you have defined. Within a Run, every Target gets associated to (at least) one Observing Set Up to form an Observation.

Please note that there are 3 levels of telescope times that are reported. From bottom to top, you should first define the total time required to perform a given observation; this will then be propagated to the target level, i.e. you will see the total time associated to a given target in case more than one observation has been specified; finally, you can see the total time for the run, including the aforementioned target(s) and observation(s). 

For each Observation, you must fill the blue box ('Total Time per Observation) by specifying the corresponding Telescope Time (i.e. Integration Time + all Overheads)

o    If you need to repeat the observation (either to reach a higher S/N, or e.g. to monitor the object), mark this accordingly in the Repeat box.

o    If you want to skip this observation (i.e., you do not need this Observing Set Up on this Target), set Repeat to 0.

All 'Total Time per Observation' (more than one, if more Observations have been defined) are then propagated to compute the Target Tel. Time and the Run Tel. Time.  

Overheads: please consult the overheads table for estimating the overheads of your observations or, even better, use the p2demo to derive them accurately.

 

Optional: For each Observation, you can also fill the details of the individual components of the observation:

o   Telescope Overhead (first box), this is for the preset and acquisition overheads. Please note that the 600s are just a default value - these need to be revised depending on the instrument you have specified;

o   Integration Time, the total integration time for that specific observation (e.g., DITxNDITxNEXP);

o   Instrument Overheads, the overheads associated to the specific instrumental setup (e.g., instrument set-up, read-out);

o   S/N, the signal-to-noise you expect from this Integration Time.

 

Although these are optional, we recommend you fill them for at least some representative observations, to illustrate your time request justification.

Use the box "Time Justification" to discuss the details of the time you request (see the section on Remarks & Justifications below).

 

file

Remarks & Justifications

Several text fields are to be filled in this section. Please note that they are almost all mandatory - for those not applicable to your case, please simply add N/A in the text box.

Special Remarks: This is to be used for any special remark you deem useful or necessary to pass on to the OPC.

Lunar Phase and Constraints Justification [mandatory]: Here is where the choice of FLI and atmospheric constraints should be justified. However, remember not to over-constrain your observations.   

Time Justification [mandatory]: Here is where the total Telescope Time requested should be detailed and justified.

Telescope Justification [mandatory]: Why ESO? Why the specific telescope/instrument you have chosen?  

Observing Mode Justification [mandatory]: Here is where you specify why you chose a given observing mode (SM, VM, dVM) and whether or not  you state if the observations could also be carried out with a different observing mode.  

Calibration Request: To be used if Special Calibrations, on top of those included in the Standard Calibration Plan of your proposed instrument(s), are needed.

Experience of the Team [only for Large Programmes / GTO LP; mandatory]: This is where you describe, in detail, the expertise of your team with respect to the telescope time request and how the work and data analysis will be distributed and carried out.  

Data Product Delivery Plan [only for Large Programmes / GTO LP; mandatory]: This is where the delivery plan of advanced data products via ESO Phase 3 interface should be described.  

Duplication with ESO Science Archive [mandatory]: If there are no duplications, please specify N/A.

GTO & Survey Target Duplication Justification [mandatory]: If there are no duplications, please specify N/A.

 

Awarded & Future Times

Related to the telescope time application you are preparing, you can specify here what has already been awarded to the same scientific case and what will still be needed in the coming semesters.

Important Note: hitting the Return key and/or adding a new row (even if you do not need it) will automatically save the information that has been specified so far.

 

awardedfuturetimes

Previous Usage  

This section allows you to specify the previous uses of ESO facilities most relevant to your current telescope time request. You can do so for yourself and your co-Is, by selecting the names of your team members, one at a time.

 

Applicants' Publications

Here is where you can add the team publications that are most relevant to your observing proposal.

We recommend using the following format:

Author1, A., Author2, B. Author3, C., et al. (year) "Title," Journal, Volume, p.start-p.end - BibCode

or, for instance

Giacconi, R., Gilmozzi, R., Leibundgut, B., et al. (1999) "Science verification of the Unit Telescope 1 of the ESO Very Large Telescope," A&A, 343, L1-L4 - 1999A&A...343L...1G


This format can easily be produced using ADS as follows: 

select the paper(s) you wish to report, click [export], select [Custom Format] and enter %3.3l (%Y) "%T," %q, %V, %pp - %R
This will automatically link the reference to the article.