Introduction

The computer software used to schedule and execute HST observations can interpret the proposal information only if it is in the proper format. Therefore, proposals must be filled out accurately, completely, and in strict accordance with the instructions in this document. Observers now have the capability and responsibility, with the help of their Program Coordinator (PC) and/or Contact Scientist (CS) for creating and submitting proposals that are not only syntactically correct but also feasible and schedulable. The Astronomer’s Proposal Tool (APT) will help you achieve this.

Note: Starting with Cycle 27, proposers are now required to explicitly list and justify the use of all special requirements in the Phase I proposal. Special requirements not justified in the Phase I proposal may not be used in the Phase II proposal. See the Special Requirements section of HST Preparation of the PDF Attachment.

Astronomer's Proposal Tool (APT)

With APT you can prepare your Phase II program on your computer and then submit it electronically to STScI. You will use a copy of your Phase I proposal (marked up in XML), which contains all the information from your Phase I submission. If you haven’t done so already, please consult the APT web page for detailed instructions on how to install and use APT on your computer. Observers without access to a suitable computer platform to run APT for Phase II should contact their PC.

Entering Information: The APT Graphical User Interface (GUI) versus the Text Proposal File

In the previous proposal entry system, RPS2, you could enter and edit information as text (usually in the form <keyword>=<value>) using a template and your favorite text editor. Also, you could use the Proposal Editor (PED), a graphical editor in RPS2 designed for editing your Phase II program.

In APT you can enter proposal information by using either the APT Form/Spreadsheet Editors via a GUI or a Text Proposal File that employs a "simplified" RPS2 syntax. This text file has been developed for APT  as an alternative method for editing proposals outside of the APT GUI; you use a flat ASCII file format that is similar to the RPS2.prop file that was used in HST cycles 5-11. Small changes to the original RPS2 format were necessary to accommodate enhancements that came with APT, and some of the syntax has been made stricter in order to make reading of the file more robust. You create this file in APT by exporting your proposal into a text proposal file format (for details please see the APT web page).

Using the APT GUI

In most of the fields in the APT graphical interface, you choose a keyword or parameter <value> in a list from a pull-down menu, or check a box. In a few other fields (e.g., Other Fluxes, Observing Windows and Criteria in the Targets forms) you enter free text in the field using the formats specified in this document. Required items are marked with a red “x” if you haven’t selected or entered a <value>. Also, for many of the keywords, a tooltips message will appear when you place your pointer on the keyword: <value> area.

Using the Text Proposal File

When creating or editing large repetitive proposals, editing with APT’s graphical interface can be inefficient and prone to error. We present two examples where you may want to use a text proposal file.

1. You are building a large repetitive program with many targets and visits in order to create a mosaic. Initially, you would use APT to build a proposal that has one or two targets and one of each of the unique visits. You would then run the Orbit Planner and Visit Planner to make sure that the visits fill the right number of orbits and schedule. Then, you would export this small template proposal to the Text Proposal File format, and use scripts or your favorite editor to build your program into a larger version. You would then import the resulting file back into APT for checking and processing.
2. You have already built a fairly large program in APT by creating unique exposures and visits, and then used the duplicate and multiple duplicate features in APT. Then, you discover that you need to make a small change to a large number of exposures (such as removing or adding an optional parameter). This would be tedious to do in the APT GUI, but straightforward in the Text Proposal File. Simply export your program to the Text Proposal File format, make your changes in an editor, and then import the Text Proposal File back into APT for new processing.

Table 2.1 summarizes some of the differences between the APT GUI and the Text Proposal File.

Table 2.1: Comparison of APT GUI and the Text Proposal File

APT Tools

APT also provides tools to help you plan your observations, such as an Aladin based visualization tool, an Orbit Planner and a Visit Planner (see the Using APT web page). If you have any problems using APT, or have any questions about your proposal, please feel free to contact your assigned Program Coordinator (PC) and/or Contact Scientist (CS). Programs without an assigned CS may also contact the STScI HST Help Desk (web: https://hsthelp.stsci.edu; email: help@stsci.edu) for help with APT. We encourage use of the new website where you can submit questions directly to the appropriate team of experts.

Submitting Your Program

After you submit your Phase II program, the APT system will give you an automatic electronic acknowledgment. This should be followed in a few days by an acknowledgment from your PC. If, at the time of submission, the proposal contains errors, the APT submission system will give a warning, but will allow the proposal to be submitted. However, the proposal will be flagged, and your PC will contact you within a few days to discuss how to proceed.

What to Submit

Observers must submit their Phase II proposal to STScI by the Cycle 32 Phase II deadline. It should contain the following:

• Updated Proposal Information: This section includes the title, the abstract, a Phase II ID, a proposal description, PI and CoI information. Please note that some general information is very useful for a thorough and helpful technical review of your proposal. You may wish to include parts of your Phase I science discussion, but please note that all the Phase II information you provide will be freely available via the Web.
• Target Information: The information for one or more of the Fixed, Solar System, or Generic Targets must be completed. If necessary, proper motion and parallax information should be supplied for fixed targets. Detailed instructions for filling out the target data, as well as the proper motion and parallax information, are provided in sections 3.1 Fixed Targets, 3.3 Generic Targets, and 3.2 Solar System Targets.
• Visit, Exposure Group, and Exposure Specifications: These specifications include orientation information, scheduling requirements, SI information, exposure special requirements and so on. Required items will be clearly noted as you complete the specifications. General instructions for completing this section are provided in Chapter 4: Visits, Exposures, and Exposure Groups.

General Instructions

When you first bring up APT, you will have to convert the information in your Phase I proposal, which is an XML file, into a Phase II program format using the “Phase I->Phase II” conversion button on the APT User Interface.

Note the following general instructions and conventions when entering your Phase II information:

• After converting your Phase I Proposal into Phase II information, please verify that all the general information is correct and readable.
• Entries in text must precisely conform to the formats specified in this document. If you have decided to use the Text Proposal File, the order of the entries must be correct as well (see Text Proposal File).
• Proposal data text may contain only standard ASCII characters. All other symbols must be spelled out. Greek letters must be spelled out (e.g., BETA-LYR, H-ALPHA). The degree sign should be replaced with “D” (e.g., BD+16D516). Subscripts and superscripts are not allowed.
• When providing a Target “Description” please use the target keywords and syntax presented in Target Description tables (for Fixed and Solar System targets).

If you are unable to use the APT software, please contact your PC (listed in your notification letter) to make other arrangements.

Proposal Information [Proposal_Information]

This block contains basic information about the proposal including the Title, Abstract, Category, and Cycle. After converting your proposal from Phase I to Phase II, your Phase II program will have the program information filled out based on your Phase I submission.

Proposal Title

The title from your Phase I submission will be used.

Abstract

The abstract from your Phase I submission will be used. Please check this since you may need to update this text based on your final TAC allocation.

If a Phase II submission is not based on a Phase I proposal, please fill in missing information.

Phase II ID

This ID will be provided to you by your Program Coordinator.

STScI Edit Number

This field holds a counter for an operational version number of the proposal and cannot be edited by the user. If you are connected to the Internet, the version number in your proposal file is compared to the one in the STScI proposal database when a proposal is opened or submitted. In either case, if your file’s version number is less than the database’s number for that proposal, you will get a pop up warning that a more recent version is available (via APT’s Retrieve from STScI). This prevents you from doing an update with an old copy of the proposal, or making edits to a version that does not include changes your PC has made to the proposal. The STScI software increments this number whenever the Phase II file is edited by STScI staff.

Proposal Category

For those Phase II submissions that are not based on a Phase I proposal, the Category should be selected from one of the following:

A Category of SNAP is used for “snapshot” programs. By their nature these programs take advantage of otherwise-unused blocks of telescope time for relatively short exposures. SNAP exposures therefore must carry as few restrictions as possible. In particular, Special Requirements should not ordinarily be used with SNAP programs (consult with your Program Coordinator if you feel you need to do so). Some special policies apply to SNAP programs: in particular, STScI will not repeat failed SNAP exposures.

Pure Parallels

For pure parallel proposals, check the “Parallel” checkbox next to the Proposal Category in the Proposal Information form. Please note that SNAP/PAR is not a valid proposal type.

Proposal Cycle

Unless you have been told otherwise, the Cycle should be 32. Multiple values of Cycle are not permitted.

Availability

You must choose supported. If the observing modes normally offered by STScI to GOs do not meet the needs of your program, please contact your Program Coordinator.

Target of Opportunity Number Of Activations

Enter the total number of ToO activations requested for each type of Target of Opportunity visit in the program. The four separate parameters correspond to the Target of Opportunity Response Times specified in the ToO visit level special requirements: 

• Non Disruptive: Required when a Non Disruptive Target of Opportunity Response Time (longer than 3 weeks) is specified for any visit in the program.
• Disruptive: Required when a Disruptive ToO has been specified in Target of Opportunity Response Time (shorter than 3 weeks) is specified for any visit in the program.
• Ultra Disruptive: Required when an Ultra Disruptive ToO has been specified in Target of Opportunity Response Time (shorter than 2 days) is specified for any visit in the program.
• Flexible: Required when the Target of Opportunity Flex Day check box has been checked for any visit in the program.

Proposal Description

Proposal Text Sections

These four sections are needed for STScI to execute your program properly. Not all questions will need to be answered by every observer, and note that the answers to these questions will be made public. As with the Abstract, please review this text to make certain the information is correct.

Description of Observations [Observing_Description]

Provide a detailed description of your observing plans. Text from your Phase I proposal will need updating based on your final TAC allocation and on details to be worked out in Phase II.

Investigators

This section contains the names of the Principal Investigator (PI), all Co-Investigators^[1] (CoI), and their institute affiliations. This information comes from your Phase I proposal submission.

Phase II Contact

If a Co-Investigator is also to be a contact for a program, then the Phase II Contact keyword box should be checked. More than one Co-Investigator may be designated as a Contact. The Contact(s) will receive the same (non-budgetary) automated e-mails for the program as the PI.

If any of the Investigators have changed addresses between the Phase I and Phase II submissions (or any time after the Phase I submission), please contact your Program Coordinator with the updated address, or by logging on to MyST at: https://proper.stsci.edu/proper/authentication/auth. You cannot use the Phase II submission to implement address changes.

For Phase II submissions that are not based on a Phase I proposal, please fill in the information accordingly.

Target Information [Fixed_Targets, Solar_System_Targets, Generic_Targets]

Sections 3.1 Fixed Targets, 3.3 Generic Targets, and 3.2 Solar System Targets describe how to fill out the Target Lists.

Visit Information [Visits]

The Chapter 4: Visits, Exposures, and Exposure Groups article describes how to fill out the Visit and Exposure Specifications. Instructions for submitting parallel observations are given in Chapter 5: Parallel Science Exposures, and the detailed, instrument-specific parameters are described in the ACS, COS, FGS, STIS, and WFC3 chapters.

Examples and General Advice

Phase constraints for periodic observations

Phase constraints in a Phase II program are applicable when the observations are to follow a periodic event, such as an exoplanet transit or a regularly-variable object. The most important aspect to have in mind is that the phase range on an exposure sets a window over which that exposure may start.

In particular for exoplanet transit observations, it is important to set the phase range in a way that allows for an adequate out-of-transit baseline that includes one or more exposures before the ingress of the exoplanet. For example, setting a PHASE 0.95 TO 0.05 for a transit with ingress happening at phase 0.98 may lead to missing the pre-transit time, since the exposure may be scheduled with a start time after the ingress. Consider instead PHASE 0.94 TO 0.97, since it would guarantee that the exposure starts before the ingress phase 0.98.

More details about the phase constraints of periodic observations can be found in Sections 6.2.3 Timing Visit-level Special Requirements and 6.3.2 Timing Exposure-level Special Requirements.

Acquisitions and Pointings

Getting HST located and oriented properly lies at the heart of successful observations, especially when a small aperture is being used, and there are a number of ways to do that. The remarks here apply specifically to fixed targets, and mostly apply to the use of small apertures, although many of them can be applied to moving targets as well. For more information, see Section 3.1 Target Position Type.

First, you have to acquire an object successfully that is at or near the position at which the science observation will be made. The object to be acquired should meet these conditions:

1. It should be a point source or nearly enough to point-like that the centering algorithms can determine a precise centroid.
2. The object’s coordinates must be both precise and accurate and any proper motion must be known. This requirement boils down to the need for the object to fall within the search region at the time of the acquisition. For this to happen the coordinates must also be consistent with the Guide Star Catalog or they must fall within another system that can be related to the GSC. This is why the source of the acquired object’s coordinates are required.
3. The object must be neither too bright nor too faint for the instrument mode used. These conditions are described in the various Instrument Handbooks.

The coordinates for the acquired object can be specified in several ways:

• As explicit absolute celestial coordinates, i.e., RA and DEC. See Equatorial Coordinates.
• As celestial coordinates relative to another nearby object, using offsets in RA and DEC. See Positional Offsets.
• As a REGION; see Region of Sky.

Second, once the acquisition has been made, the telescope must be repositioned to the precise point desired. This step is unnecessary, of course, if the object acquired in the first instance is the object to be observed. Repositioning can be implicit or explicit.

An offset is implicit when a target such as “XX-OFFSET” is acquired with some ACQ mode, and then “XX” is observed via a science exposure. This often leads to confusion because no specific motion of the telescope has been provided, but that motion is implied by specifying the separate targets with different coordinates. “XX-OFFSET” is specified for the acquisition because it is bright enough and point-like enough to be acquired successfully, but the coordinates specified by “XX” are what is to be observed.

An offset is explicit when you use a Special Requirement such as POS TARG to move the telescope away from the position acquired. In this scheme, the position specified in the acquisition is placed at the fiducial point for the aperture requested (in general the geometric center of the aperture). The POS TARG then moves the telescope relative to that nominal position. Thus POS TARGs are not cumulative, and always refer back to the original acquired position.

Examples

People who are looking for examples of APT files are encouraged to go to:

http://archive.stsci.edu/hst/abstract.html

and do a search for a selection of proposals from the most recent cycle. For any program that appears as though it could serve as a useful example, the APT file can be obtained by typing the proposal ID number into the search form at:

https://www.stsci.edu/hst/observing/program-information

Additionally, several examples of ACS dither patterns using POS TARGs which may be used in an APT proposal can be found on the ACS Web site at:

http://www.stsci.edu/hst/instrumentation/acs

Common Problems

Incorrect Proposal Format

When you are entering text in a field the formats described in this document must be followed exactly, since the information in the forms is interpreted by computer software. Some items that warrant repetition are:

• Visit numbers must be unique.
• Target names must be spelled exactly the same throughout the proposal.
• The format for target positions must be followed to the letter. For more information on coordinates, see Section 3.1 Target Coordinates.
• The format for Optional Parameters and Special Requirements must be followed to the letter.
• Observations which cannot be defined using the syntax in these Instructions may be described in Comments fields, but such comments should be used very sparingly, if at all, and their use may impede execution of a program.

Imprecise Target Positions

See the discussion of required position accuracies in the table of Required Coordinate Accuracies. The requirements are much more stringent than is typically the case for ground-based observations.

Lack of Acquisition Exposures with Small Apertures

When exposures are requested in very small apertures or fields of view, a separate acquisition exposure is generally required. Please consult the Instrument Handbooks for the instrument you are using.

Consideration of Limited Resources

Starting with Cycle 26, proposers are now required to explicitly list and justify the use of all special requirements in the Phase I proposal. Special requirements not justified in the Phase I proposal may not be used in the Phase II proposal.

Proposers should be aware that several of the Special Requirements  impose serious constraints on the scheduling system because they require the use of limited resources; for example, RT ANALYSIS requires real-time use of the Tracking and Data Relay Satellite System (TDRSS) that is only available some of the time. Hence these Special Requirements should be requested only if they are absolutely necessary to achieve the scientific goals of a project. It is quite possible that some proposals will be impossible to schedule because of their resource requirements, rather than a lack of scientific merit. The limited-resource Special Requirements can force the planning system to schedule the observations at a less than optimal time. The use of limited-resource Special Requirements by many observers can reduce the overall efficiency with which the planning system can schedule the science program. For these reasons, these Special Requirements should only be used when necessary to achieve the science objectives of the program. The STScI will review the necessity for the Special Requirements and in some cases may suggest removing them, or using alternate methods to obtain the same goal.

The Table 2.2 summarizes the Special Requirements that involve seriously limited resources.

The need for many of these Special Requirements must be justified in the Proposal Description. Those are: CVZ, SHADOW, LOW-SKY, and ON HOLD for Targets of Opportunity.

Table 2.2: Limited-Resource Special Requirements

¹The number of CoIs is limited to 999.

Change Log