Space Telescope Science Institute: Tools
Environment
Anuradha Koratkar
April 9, 1999
EXECUTIVE SUMMARY
During the phase II proposal preparation stage a GO needs not only to make decisions about
many aspects of observing, but must also calculate many quantities. The bulk of information and
instructions for making these decisions and calculations is contained in the instrument handbooks
and proposal instructions. But, some helpful information is presently disseminated via tools
located in various places within the Institutes’ computer system. The present generation of tools
and their support is fairly informal. The Institute needs to have a more formal policy because
(1) a tools environment which is regularly maintained will assure access to current
information about HST and its instruments not only to the GO community, but also to the
internal staff.
(2) consolidation of tools will lessen confusion regarding access to current information.
(3) a properly organized tools environment will provide GOs with a checklist of all the
various aspects of the observing program to be considered.
(4) the ease of access and accuracy of our tools reflects the professional image of the
Institute.
In this document we provide general guidelines that could be used in developing a tools
environment, the level of oversight and technical support that will be necessary, and a list of tools
presently available to the GO community and/or internal staff. The status of the tools is also
discussed. Our initial recommendations are:
(1) to create a tools environment which should be useful to both the GO community and
internal staff.
(2) to make the tools available via the World-Wide Web.
(3) to designate a person who will be responsible for maintaining uniformity of similar
tools across instruments, although the various tools will be the responsibility of the
individual groups that generate them.
1. Introduction:
The Remote Proposal Submission Two (RPS2) software which is used during phase II
requires a number of inputs which have to be determined by the GO. Thus, the phase II preparation of a program can be quite daunting. This task can be made easier by providing GOs with
tools that can be used to calculate/determine the various aspects of the observing program. The
outputs of these various tools can then be used to fill in the RPS2 template. These tools along with
RPS2 (which is also a phase II proposal preparation tool) can be provided in a tools environment
which could also serve as a checklist in the preparation of the phase II proposal.
A number of electronic tools are presently available to a GO or internal staff member to
aid them in preparing a phase II proposal. Addition of some more new tools will not only help
GOs and internal staff, but will also lead to “cleaner” phase II submissions. The new tools will be
especially important for the new instruments, which are more complicated than the first generation instruments. Access to existing tools is sometimes not easy and may depend on who a person
asks for help. In general, awareness of new capabilities as they are implemented needs to be
improved. The existing tools are generated by various groups, with little coordination across different instrument groups or divisions.
The tools that are available become the official recommendation of the Institute, and as
such it is essential that the tools we provide and the framework in which we present them reflect
the service orientation of the Institute. With many of the existing tools being World-Wide Web
(WWW) based and increasing Web interaction with the GO community, we need to become more
systematic. A tools environment will provide a homogeneous user interface.
The overall goal of this tools environment is to ease the phase II proposal preparation process, via easily available tools which access current information about HST and its instruments.
To achieve this goal, this paper describes an approach that can be used to generate a consistent
tools environment. We also discuss the status of existing tools, and determine the need for new
tools.
The above task was undertaken by the author with comments from Stefi Baum, Michael
Dahlem, Ron Downes, Warren Hack, Stephen Hulbert, John MacKenty, Karla Peterson, Abhijit
Saha, and Richard Shaw. Some of the recommendations given below are based on the phase II GO
survey conducted by Daniel Golombek and Anuradha Koratkar.
2. Guidelines for the Generation of the Tools Environment:
2.1 Assumptions:
In discussing issues related to a tools environment, we make the following assumptions:
Purpose: The primary purpose of the tools environment will be to provide the GO community
with quality information and tools to help in the preparation of the phase II program.
Audience and Interface: The external audience are scientists who are preparing approved observing programs on HST. The internal audience are the members of the Institute staff who provide
GO support. The information that this audience are seeking must be up-to-date, useful and easy to
find. This implies that the interface will have to be organized by topic.
Information Content: Tools should be developed with the audience in mind. Support of the tools
should be distributed and maintained by the groups with expertise in the particular area (e.g.
instrument teams, PRESTO scientists, PRESTO developers, STSDAS developers). Standards for
how the tools are developed should be adopted. The tools should be organized with some consistency across instruments, keeping in mind that each instrument is unique in its capabilities.
Related information must be cross-referenced as often as possible and coordinated globally so
that the effects of any change to the tools can be assessed. Oversight as to general usability and
consistency of the tools is important.
Documentation: The various tools must be self explanatory whenever possible. If documentation
is required it must be easily available on-line. Useful, simple examples must exist for each task to
aid a beginner or to refresh an expert’s memory. The need for examples was indicated in the phase
II survey.
Information Organization: The organization of the tools environment must not only facilitate the
needs of a first time user, but simultaneously not restrict an experienced user. The organization
must be such that it highlights the various aspects of phase II that need to be considered. In the
future, as the capabilities of the tools environment increase, the organization can provide a user
with a checklist in the preparation of his/her phase II program.
2.2 Requirements:
The tools environment should satisfy the following requirements:
Quality Information: The primary requirement of the tools environment is to provide users with
quality information which can be easily accessed and used in developing HST programs. The
tools should help decrease the complexity of a task whenever possible. Full technical and scientific details necessary for the completion of the task should be presented at an appropriate level of
complexity. The tools should be maintained frequently in order to provide up-to-date information.
The applicability of the tools should be properly discussed.
Audience: The GO community is extremely innovative and can sometimes use the HST and its
instruments in non-standard modes. Tools cannot be generated for every possibility. Thus the
tools environment and the tools should be useful to everybody and should be applicable to at least
75% of the GO programs for a given instrument.
Responsibility: The responsibility for a clear user interface lies with the various groups that
develop the tools.
2.3 Description of the Tools Environment:
Definition: The tools environment is a collection of various tools that GOs can access
while generating a phase II proposal. These tools need not be based on just one particular computer language, but could be a grab bag of useful techniques. The usefulness of any tool depends
on many factors such as the interface, speed, feedback etc. If a tool is not suitable for a Web interface, or an interactive task is very slow because of the speed of the networks, a tool in the tools
environment could also be a set of text instructions on how to do a particular task. For example,
some tools such as the exposure time calculators can be Web-based, but a tool to determine target
coordinates could be a set of step-by-step instructions that help a GO measure their target coordinates in the STSDAS environment.
Interface: In discussing the possible interface for the tools environment, it was found that it is reasonable to assume that most GOs can access the STScI WWW pages, STSDAS and RPS2. The
phase II survey indicated that < 1% of GOs had no access to one or more of the above interfaces.
In such cases, the GO can come to the Institute, or his/her contact scientist/program coordinator
will have to provide some extra support.
The STScI WWW pages are the best location for the tools environment for the following
reasons:
• The tools presently available (see section 3) are mostly Web-based, although the user interface
needs to be enhanced for some of them (see section 3).
• Maintenance of the various tools on the Institutes’ machines will ensure that the latest information is presented to the users.
• A separate exportable tool (similar to RPS2) is not recommended, because it could easily run
into installation problems, development bugs etc. due to numerous user platforms.
Organization: The tools should be arranged with no implied sequence, but as a collection of useful tools. The tools environment is a storage place for all the tools necessary for the preparation of
a proposal. However, it must not be so cluttered that most users would find it hard to use. Therefore, a systematic arrangement is needed to ease the access to the tools.
A simple strategy would be to have a tools environment WWW page, accessible via both
the Observer page and the Instrument pages. This page would contain hotlinks to the various
tools. The hotlinks can be arranged such that a listing of this page will automatically highlight
many of the important aspects of the phase II proposal preparation that must be considered. The
instrument handbooks are the glue that bind the various tools together, and in the future, when
these handbooks become WWW friendly, they can easily be linked into the tools environment.
When the Handbooks are linked into the Web interface, the hotlinks in the tools environment can
be used as a checklist for the phase II submission process. In this context, the tools environment
page could have the following organization:
Target Coordinates: Requirements on the target coordinates for each instrument will
be discussed here, and a tool to determine the target coordinates will be provided.
Target Orientation: This section will provide a tool that calculates the orient angle that
must be provided to RPS2.
Viewing Time: This tool will provide information on dark time and CVZ.
Bright Target Check: This tool will let a GO know if a target is too bright for a given
instrument.
Duplication Check: This would be a link to the duplication checker in STARVIEW.
Specific Instrument Related Issues: This would link to each instrument’s tools page.
The instruments’ tool pages would provide the tools to determine exposure time, filter/
grating selection criteria, target acquisition strategies, dithering patterns, etc. These
tool pages would highlight many of the important subtleties of the instrument. Once
again, in the future these pages could be used as a checklist for that specific instrument.
Maintenance: Since many users may be expected to propose programs that utilize more than one
instrument, it is important that the tool interfaces present a similar look-and-feel and have similar
navigational aids. Likewise, it is also important that users be able to locate the relevant tool page
for each instrument in a similar way. Uniformity across tools whenever possible helps users to
understand the various tools quickly and decreases the level of frustration when learning a new
task. Hence, although the responsibility for each individual tool lies with the group that develops
it, a person should be designated who will be responsible for maintaining uniformity across
instruments and “functions”.
3. Status of Existing Tools:
3.1 Measurement of Target Coordinates:
The Institute recommends that GOs use target coordinates measured from the Guide Star
Catalog (GSC) plates and provide the plate ID. The same plate is then used to find guide stars,
thus improving the target acquisition accuracy because of the consistent reference frame. If different GSC plates are used the target coordinate errors could be large and the target pointing/acquisition could be jeopardized. In the overlap regions of adjoining GSC plates, discrepancies of 1” are
typical.
In previous cycles, since FOC, FOS, and GHRS have small fields of view, providing GSC
target coordinates and plate-IDs has been an observatory level requirement. In cycle 7 and
beyond, WFPC2 and NICMOS will not have the same stringent requirements for target coordinate
accuracy as the present spectrographs (FOS and GHRS). FOC will continue to require extremely
accurate target coordinates and information regarding the GSC Plate-ID, and STIS will require
reasonably accurate coordinates too, although the requirements may not be as stringent as the first
generation spectrographs. Although, target coordinate information will not be as strict as for the
present spectrographs, information on reasonably accurate target coordinates is good observing
strategy. Thus, most GOs will want to determine target coordinates to the best of their ability. A
tool to help them do so is therefore very useful.
Presently, GOs can determine the target coordinates by obtaining the FITS file of the GSC
image through the STScI WWW observer page and then following the Instructions for measuring
coordinates. These instructions inform a GO on how to retrieve or measure the target coordinates
if the target is bright enough to be in the GSC plate. If a target is not visible on the GSC plate, the
GO is asked to contact the program coordinator. A user within the Institute can also measure target coordinates in the GASP environment. This method for measuring coordinates is not available
to an outside GO, who cannot easily access the GASP environment. Determining coordinates
using GASP is not very difficult, but is not as user friendly as the IRAF/STSDAS environment
instructions discussed below. Target coordinates determined using the two methods agree to
within 0.1”. Since accessing GASP is not easy, we discuss the IRAF/STSDAS instructions in
detail.
Retrieving target coordinates: Targets brighter than V~15 have their coordinates already measured and available in the GSC. Instructions on retrieving target coordinates are simple and easy
to follow. The only recommendation for improving the WWW page that retrieves the coordinates
is a description of the catalogues that are available for searching. This description must be concise
and must let a user know the nature of the catalogue, limiting magnitude of the catalogue, and typical measurement uncertainties.
Measuring target coordinates: The instructions for measuring target coordinates for objects that
can be found on the GSC plate are also easy to follow. The measurements are done using the
IRAF/STSDAS environment. The actual steps involved are as follows:
(1) Retrieve FITS image
(2) Convert the FITS image into GEIS format in the IRAF/STSDAS environment.
(3) Centroid on the target and get the central pixel x, y values.
(4) Input the x, y values into another STSDAS task to get the target coordinates.
At the end of the process, the GO has not only the target coordinates, but also the Plate-ID.
Some of the shortcomings of the present target coordinate measurement tool are:
• There are no instructions to determine target coordinates for objects which are not bright
enough to be on the GSC plate or are saturated on the GSC plate.
• Although the instructions on retrieving or measuring target coordinates are clear and easy to
follow, we found from the phase II survey that 61% of the surveyed did not use the instructions available through the WWW pages. Of the people who used the instructions 44% had
difficulties measuring the target coordinates. An important factor seems to be that an older
version of STSDAS was being used. The instructions provided were incompatible with the
older versions of the software.
Some specific recommendations to overcome the above shortcomings and enhance the tool are:
1. For objects which are not bright enough to be on the GSC plate or are saturated on the GSC
plate, it is possible that GOs have good data from elsewhere which are usable. For such cases
instructions must be provided on how to transfer the GSC frame onto the user’s image. This
task can be accomplished in GASP. A tool, which could be a simple set of instructions on how
to transfer the GSC coordinate frame on to the user’s image, could easily be generated. This
tool may require access to GASP which is not presently available to the general community.
Limited access to GASP for all personnel actively involved in GO support and the availability
of such a tool would greatly help the Institute staff.
2. A large segment of the GO community re-observes their target after obtaining a WFPC2
image. There is an STSDAS task (metric) that allows users to determine the coordinates of a
WFPC2 pixel. A set of instructions on how to use metric on “old” WFPC/WFPC2 images to
obtain target coordinates would also be useful.
3. A simple solution to alleviate problems related to software and instructions provided as tools,
is to check instructions for backwards compatibility with the software. If backwards compatibility is not possible, users should be informed of the software requirements of the tool.
3.2 Orientation:
The orientation of the field of view (FOV)/aperture on the sky is important for many
observational programs. This is especially true if a GO has parallel observations in the observing
program. The ORIENT special requirement in phase II is used for this purpose. GOs use the ORIENT requirement not only to get a preferred direction on the sky, but also to exclude regions of
the sky. The latter is used preferentially to prevent a bright object from contaminating science
observations. Apart from being able to orient the field of view/aperture on the sky, GOs also like
to know the effect of an orient requirement on scheduling. Sometimes, depending on the guide
star availability, GOs might restructure their observing program or change the orient requirement.
Presently, we have a tool that can be accessed via STARVIEW. This tool overlays the FOV
on the sky for a given position angle. Although it is easy to use, the tool has many shortcomings,
and not all of the GO’s needs are met by this tool. Some of these shortcomings are:
• The tool does not provide the orient angle required by RPS2. The tool uses the position angle
of the V3 axis in its calculations. This axis is 180 degrees off from the axis used to measure
the ORIENT angle required in RPS2, which leads to a lot of confusion.
• The tool is not useful for any instrument other than WFPC2. This is because the FOV overlay
is only for the on-axis instrument which is WFPC2. Even for WFPC2, the STARVIEW preview facility is not detailed enough, since it does not rotate around different apertures (for
example pc1, wf1, wf2, wf3).
• The tool does not allow GOs to assess the implications of a particular orient angle to guide
star availability and scheduling.
Another simple, yet extremely useful orient tool exists for the FOC. This tool can be used
either during phase II or after data acquisition, because it does two different calculations. In one of
the calculations the tool determines the orient angle required by RPS2. In the second calculation
the tool provides the angle between North and the FOC Y axis, given a particular orient angle at
which data are acquired. Although the tool does not overlay the FOV on the sky, it does show the
orientation of the North direction and the U3 axis relative to the FOC axes. The tool also provides
the target position in the FOC XY reference frame for a particular reference position in the image.
The tool is very easy to use. Its only major shortcoming is that it does not directly overlay the
FOV on the sky for comparison. The only enhancements recommended for this FOC orient tool
are an example to guide users and improved documentation for usage.
3.3 Exposure Time Calculators:
In the past, prospective GOs have been provided with hard copy instrument manuals containing equations and tables for estimating exposure times for their targets. A small number of
more sophisticated proposers used the STSDAS “synphot” package to compute more accurate
throughputs, and indeed the exposure-related equations that appeared in the instrument manuals
were often derived (or at least verified) using synphot utilities.
Web-based software tools to aid the computation of exposure times or expected signal-tonoise ratios for a number of target types have been built by WFPC2 and FOC, and NICMOS and
STIS are in the process of developing similar tools. All these individual tools can/will be accessed
through the WWW pages for each instrument. These Web-based exposure time calculators do not
have the steep learning curve that exists when using the “synphot” package. Also these tools provide more information than is available via the synphot calculators. For example, the FOC calculator provides red leak information for the filter being used, the encircled count rate, and peak
count rate, not just the total counts. Thus the Web-based exposure time calculators (ETCs) are
very useful.
The popularity of ETCs in the past year (particularly for WFPC2) shows that such utilities
are perceived by the community as valuable and important for GO proposal preparation (both during phase I and phase II), and that investing further in this technology for new and continuing
instruments would be of great benefit. But there are serious shortcomings with the current Webbased ETCs, particularly when viewed from the perspective of long-term viability, software maintainability and extensibility, etc., while maintaining the highest standards of data quality. Such
issues must be addressed at a higher level than the individual instrument teams.
A few fairly specific requirements for Institute-sponsored ETCs are too often not being
met. The most important are:
1. All the ETCs should reference the CDBS (or files that are updated frequently from the
CDBS) in order to compute total system throughput and detector efficiencies.
2. The actual computation of the telescope and instrument throughput/efficiency and target
source characteristics should be performed with only one piece of software for which adequate resources for maintenance can be committed. Such software exists (for example, the
synphot package), and it should be used as a major component of the computing engine for
the ETCs.
3. The responsibility for a clear user interface lies with the various instrument groups, who must
provide sufficient context for users to effectively use the ETCs for all the modes of their
instruments. However, the interfaces must present a similar look-and-feel in order to aid
multi-instrument users to understand the tool being offered.
4. The tools should have examples available for the first time user.
Some specific recommendations in addition to the above are:
1. The FOC simulator FOCSIM is extensively commented (very helpful) and easy to use, yet the
amount of information provided bombards a user. It would be useful to highlight the most
important aspects of the output.
2. FOC needs to enhance FOCSIM so that exposure times can also be calculated for objective
prism exposures.
3. The WFPC2 simulator WFPC2 E.T.C. interface needs to be improved. If the program fails
there is no clear explanation as to what the user needs to do. An example would be highly
helpful. Old versions of the simulator must be hidden from a user, since they could easily lead
to confusion.
3.4 Filter/Grating Selection:
Choosing a filter/grating is important in any observing program. A GO always wants to
know which is the best filter/grating that can be used. To make this choice, information on pass
band, throughput, etc. is essential. Most of this information is presently provided in the instrument
handbooks.
WFPC2 users have a tool called the WFPC2 Linear Ramp Filter Calculator (LRFC),
which can be accessed via the WFPC2 WWW instrument page. The task is easy to use, but a few
improvements in the interface would enhance this tool. The recommendations are as follows:
1. There is no clear documentation as to when the LRFC tool should be used. Is it to be used to
determine which wavelength regions can be accessed by the ramp filters and which cannot? A
concise paragraph as to how the tool can be used would be extremely helpful. There are certain wavelength regions that are vignetted for the ramp filters, but the tool does not inform the
user of this. The standard message on using the tool is too general although it is very important. Adding information about vignetted wavelengths would enhance the usefulness of the
tool.
2. GOs do not have to use the LRFC in the preparation of their RPS2 files. They just need to
specify the central wavelength of interest and aperture in the RPS2 file. TRANS then determines the filter, and where and on which chip the target is to be located. This information is
given as a very terse note. Instead it would be useful to provide instructions to the GO as to
how the RPS2 file option parameters need to be filled in.
3.5 Dithering Patterns, Background Subtraction Patterns and Offsetting Patterns:
The WFPC2 dithering patterns (line and box) already exist in RPS2. Some comments
from the phase II survey indicated that the usage of the dithering pattern in RPS2 was ambiguous
and needed a workaround. An explanation and example within RPS2 might make the task easier
to use. In addition a paragraph or two with examples explaining how to use dithering patterns in
the WFPC2’s tool page is recommended.
4. Suggestions for New Tools:
4.1 Measurement of Target Coordinates:
1. To bypass the IRAF/STSDAS environment problems mentioned in section 3.1, the catalogues
branch would like to generate a much simpler tool. The tool’s WWW page would pull a clickable image, and the user would click on the target. Then target coordinates determined by centroiding on the clicked object along with the plate-ID would be made available to the user. The
speed of this tool is determined by the speed with which the GSC image can be accessed.
Thus the speed is projected to be the same as what is presently available for retrieving the
FITS image. Presently there is no timeline to make such a tool available, since the task has not
been made official. It is projected that it would take ~3-4 weeks to have such a task available
to the community. It would use the GASP environment to determine the target coordinates.
The improved tool would also be useful to STScI staff, since it will complete the task in one
step and will also reduce the need for disk space and image management.
2. The Institute has a policy to check target coordinates provided by GOs and provide the relevant plate-IDs. The fact that more than 60% of the GOs did not use the target coordinate measuring tool to get their plate-IDs may indicate that they depend on the Institute to provide the
plate-ID and to verify the target coordinates using the Institute provided “finder charts”. These
“finder charts” are generated by a task in the GASP environment by the program coordinators.
A WWW based task which generates “finder charts” could be made available to GOs. In this
task the GO will provide the RA and Dec of an object and obtain an image (whose size is
determined by the user). The information can be downloaded as a postscript, gif or fits format
file. This task will not only allow verification of target coordinates but also provide the plateIDs. It also relieves a user from doing a full blown determination of target coordinates if accuracy is not a major factor.
3. Although the following recommendation is not directly related to measuring target coordinates, it would be useful to have hotlinks to the tool “coco” that converts coordinates from one
reference frame to another, and also converts B1950 coordinates to the J2000 equinox.
4.2 Orientation:
In cycle7, users will want to orient the STIS long-slit aperture along a given direction. The
NICMOS users may want to place the three NICMOS apertures in a preferred position. Also, both
STIS and NICMOS have zone of avoidance requirements. Therefore, both these instrument teams
expect 75% of their proposals to have orient constraints. Hence, at least for these new instruments,
information on orient angle is essential to allow GOs to make educated decisions concerning the
orient requirement on scheduling.
An investigation for a detailed orient tool is being conducted by Abhijit Saha. His report
will consider the timeline required to develop such a tool, the medium for developing it, and any
other recommendations. In this paper we make the following recommendations that could be useful in the generation of orientation related tools.
1. GASP has the capability to overlay the WFPC2 FOV at any orient angle and any aperture on a
digitized sky survey image. This facility has been extensively used by some WFPC2 contact
scientists to help GOs determine the correct ORIENT angle. The GASP procedure can only be
accessed by a limited number of Institute staff. It is time consuming because of the various
steps involved and the need to transfer data from machine to machine. If this procedure is
streamlined and made easily available, it would be valuable to the contact scientists as well as
GOs. Further, the GASP procedure should be enhanced to include all instruments. Another
solution would be to have the GASP procedure available in the STSDAS gasp package, which
is already used by GOs for obtaining target positions.
2. The present RPS2 already has SPIKE which does contain schedulability and guide star information. An investigation on how the SPIKE information can be accessed and provided to GOs
needs to be conducted.
3. A procedure to overplot guide stars and bright objects on the digitized sky survey for a given
position and roll angle is also feasible in GASP. If this capability is made available to GOs
they could assess the implications of their orient requirements on guide star availability.
4.3 Exposure Time Calculators:
The STIS and NICMOS instrument teams are presently generating their exposure time
calculators. Evaluation of these tools will have to be conducted when they become available.
The STIS team is developing their ETC by generating a user friendly Web interface to the
one-dimensional synphot calculator. In this case, access to different databases is automatically
eliminated and only a minimum number of databases will need to be updated. The ETC will display throughput information for a particular mode, i.e., display a count rate vs. wavelength. Presently, there is no effort to generate a two-dimensional exposure time calculator.
The proposed NICMOS ETC is not wrapped around synphot, although the team proposes
to support synphot separately. Given this information we foresee that the ETC will suffer from the
generic problems discussed in section 3.3.
It is recommended that the new ETCs that are still in the development stage attempt to
meet the specific requirements for Institute sponsored ETCs discussed in section 3.3.
4.5 Dithering Patterns, Background Subtraction Patterns and Offsetting Patterns:
STIS has a few patterns called offsetting patterns, for acquiring targets using occulting
masks. These tasks effectively use POS TARG to generate the acquisition patterns. A tool displaying all target positions during a visit within the detector FOV would be extremely useful, since it
will allow a user to carefully plan observations. The tool will also help a GO to visualize where
the target will be positioned for any subsequent observation. A tool in the STSDAS environment
to display the STIS patterns is planned by the STIS team. Such a task would retrieve an image of
the sky on which the FOV and all target positions would have to be projected.
NICMOS has 9 background subtraction patterns. It is recommended that a tool to guide
GOs in selecting the correct background subtraction pattern for a given set of observational conditions be developed.
4.6 Magnitude Convertor:
NICMOS will require GOs to provide flux information in SI units and not magnitudes.
The NICMOS team is generating a tool that can be accessed via the NICMOS WWW pages. The
present tool will be capable of only a limited number of conversions. An expanded version of the
tool that will be able to convert all the various magnitude systems defined at the national and
international observatories is recommended since our GO community is drawn from all over the
world.
4.7 Viewing Time:
Some GOs also like to have information on the availability of dark time and CVZ. Presently PCs obtain this information from SPIKE and provide it to GOs. This task is time consuming.
A PC’s time could be effectively used elsewhere if a tool could be generated to determine viewing
time for GOs. The present RPS2 already has SPIKE which does contain the necessary information. An investigation on how the SPIKE information can be accessed and provided to GOs needs
to be conducted. The work requirements for this tool are similar to the schedulability information
tool discussed in section 4.2. Further, Abhijit Saha’s report (see section 4.2) will also consider this
issue.
4.8 Bright target alert:
Bright targets in the FOV of an instrument can safe the instrument, cause damage to an
observation, or contaminate a science observation. FOC, WFPC2 and STIS need a tool which
could provide a bright object check on the guide star catalog at all possible vehicle orientations or
a proposer specified orientation. This particular task may be an off-shoot of the orient tool (see
section 4.2) if the guide stars and bright objects are also marked simultaneously. The brightness
limits will have to be specified by the instrument teams.
4.9 Duplication Checker:
The Institute has strict rules about duplication of observations. There is a duplication
checker in STARVIEW which GOs access during phase I. The tool is extremely easy to use and
comprehend. A possible enhancement is to provide a concise summary on the rules of duplication
checking. This helps users by reminding them as to what constitutes a duplication. A couple of
examples would also be useful. We recommend that this tool be included in the tools environment
for completeness.
4.10 Phase Checker, Solar angle, Ephemeris information, FGS tools:
These are additional software tools that could be used by observers and may be appropriately included within the tools environment. A more detailed investigation was not considered
here because only <10% of the proposals need this information.
In the future, when the instrument handbooks are adapted for the Web interface, the tools
environment can effectively be used as a checklist in the preparation of phase II proposals. In this
scenario, the following three tools can easily be implemented.
I. Target Acquisition:
For the WFPC2, FOC and NICMOS cameras, target acquisition is not a big issue. But target acquisition is an issue that needs some consideration by a STIS user. The phase II survey
showed that 15% of the FOS GOs in comparison to less than 5% of all other GOs found it very
difficult to complete their phase II. Experience from FOS contact scientists has shown that target
acquisition is one of the most important issues with which GOs struggle during their phase II
preparation. The STIS target acquisition strategy is inherently not as difficult as that for FOS.
Hence, target acquisition templates will not be required. Yet, some extra support to GOs would be
appropriate. This can easily be achieved by providing hotlinks to the appropriate location on the
STIS WWW pages discussing target acquisition.
II. Filter/Grating Selection:
Presently STIS and NICMOS are planning to provide filter/grating information via the
instrument handbooks. A few relevant hotlinks/tools that would be very useful to GOs are discussed below.
1. STIS allows GOs to select a detector sub-array to be read out. When this capability is used,
the wavelength range observed depends on the detector sub-array used. Thus, a tool which
displays the wavelengths projected on a STIS detector for a selected grating and central wavelength would be useful.
2. In the present NICMOS handbook, the figures that provide the transmission/throughput information are extremely small and cannot be used effectively. These figures are small because
otherwise the handbook would be extremely bulky. This is understandable, yet the information in the figures is extremely important to a NICMOS user. A tool to display these figures
would be a solution. This tool can be enhanced to have a clickable image so that, for a given
wavelength, the GO can easily read-off the information on the absicssa. This type of tool
which displays wavelength vs. throughput, aperture throughputs, aperture distortion functions
etc. for the other instruments (WFPC2, FOC and STIS) will provide GOs with precise information on instrument details for comparison purposes. This set of tasks will not only be most
useful during phase I, but also during phase II when GOs have to finalize their observing strategies after the TAC allocations. This particular tool is extremely suitable to hotlinks in the
instrument handbooks once they are made more Web friendly.
III. Flow charts/Ckecklists:
The NICMOS team has developed flow charts in their instrument handbook to guide a GO
in determining his/her observing strategy. These flow charts are excellent for use as a checklist
when preparing a proposal (either in phase I or phase II). Simultaneously, the STIS team is generating a checklist in the instrument handbook for preparing proposals. These flow charts/checklists
can easily be linked into the tools environment to guide a GO. Such flow charts/checklists are also
recommended for the WFPC2 and FOC.
5. Recommendations:
We recommend the creation of a Web-based tools environment as discussed above. This
tools environment will be extremely useful to GOs in the preparation of their phase II programs.
Such an environment is a live document that can be periodically updated and enhanced. The
instrument handbooks bind the various tools together, and in the future, when these handbooks
become WWW friendly, one of the future enhancements suggested, is the ability to use the organization of the tools environment as a checklist during the phase II proposal preparation. The
effectiveness and viability of all the tools in the tools environment should be revisited periodically,
and should be in compliance with the requirements above.
A discussion of the existing tools and their status shows that, in some cases, only a more
user friendly interface and/or some enhancements may be necessary. In other cases new tools may
need to be generated. The discussions in sections 3 and 4 clearly state the detailed recommendations for a given tool. We recommend that, when instructions are provided in the tools environment there should be a check for backwards compatibility of a tool and the software it uses. If
backwards compatibility is not possible, users should be informed of the software requirements of
the tool.
The tools in the tools environment become an official recommendation and a basis for a
HOPR. They must therefore be kept up-to-date and consistent with all other methods of doing the
same calculation available to the GO. The tools should be dated so that any updates and the effect
of those updates can be easily determined. This is very important during Cycle 7 when the characteristics of the new instruments will be determined.
Many users propose programs that use multiple instruments, and so it is important that
interfaces to the various tools that determine very similar information present a similar look-andfeel, and have similar navigational aids. It is also important that users be able to locate the relevant
tool page for each instrument in a similar way from the instrument WWW pages.
Implicit in the above recommendations is the need for the supporting Web documents and
other resources to follow good Web authoring practices, and any Institute-wide standards or
guidelines that apply. Consolidation of tools will also lessen confusion regarding access to current
information. Many issues that must be addressed for the various tools and their interfaces lie outside the scope of this paper. However, it is important to realize that designing effective interfaces
(as well as the underlying tools) requires a serious and continuing effort, and one that must be
coordinated across the various functional groups if there is any hope for providing high quality
service to the community.
Although the responsibility for the individual tools lies with the various groups that
develop them, there should be a designated person who will be responsible for maintaining uniformity of similar tools. Since most of this uniformity will be across instruments, it is recommended that this designated person be from the USCC. This person will be responsible for; (1)
maintaining and updating the tools environment, (2) actively participating in increasing the audience’s awareness of new capabilities as they are implemented, and (3) coordinating the development of new tools.
The popularity of the existing Wed-based tools shows that such utilities are perceived by
the community as valuable and important. Investing further in this technology for new and continuing instruments would be of great benefit. But issues concerning the long-term viability, software maintainability and extensibility, etc., while maintaining the highest standards of data
quality must be addressed at a higher level than the individual instrument teams.
6. Future Activity:
1. Distribute this white paper for perusal by management.
2. Convene a meeting to discuss reactions, feedback and assessment of work required. Prioritize
recommendations and set timelines for generation of new tools or enhancements to existing
tools.
Space Telescope Science Institute: Tools
Environment
Anuradha Koratkar
April 9, 1999
EXECUTIVE SUMMARY
During the phase II proposal preparation stage a GO needs not only to make decisions about
many aspects of observing, but must also calculate many quantities. The bulk of information and
instructions for making these decisions and calculations is contained in the instrument handbooks
and proposal instructions. But, some helpful information is presently disseminated via tools
located in various places within the Institutes’ computer system. The present generation of tools
and their support is fairly informal. The Institute needs to have a more formal policy because
(1) a tools environment which is regularly maintained will assure access to current
information about HST and its instruments not only to the GO community, but also to the
internal staff.
(2) consolidation of tools will lessen confusion regarding access to current information.
(3) a properly organized tools environment will provide GOs with a checklist of all the
various aspects of the observing program to be considered.
(4) the ease of access and accuracy of our tools reflects the professional image of the
Institute.
In this document we provide general guidelines that could be used in developing a tools
environment, the level of oversight and technical support that will be necessary, and a list of tools
presently available to the GO community and/or internal staff. The status of the tools is also
discussed. Our initial recommendations are:
(1) to create a tools environment which should be useful to both the GO community and
internal staff.
(2) to make the tools available via the World-Wide Web.
(3) to designate a person who will be responsible for maintaining uniformity of similar
tools across instruments, although the various tools will be the responsibility of the
individual groups that generate them.
1. Introduction:
The Remote Proposal Submission Two (RPS2) software which is used during phase II
requires a number of inputs which have to be determined by the GO. Thus, the phase II preparation of a program can be quite daunting. This task can be made easier by providing GOs with
tools that can be used to calculate/determine the various aspects of the observing program. The
outputs of these various tools can then be used to fill in the RPS2 template. These tools along with
RPS2 (which is also a phase II proposal preparation tool) can be provided in a tools environment
which could also serve as a checklist in the preparation of the phase II proposal.
A number of electronic tools are presently available to a GO or internal staff member to
aid them in preparing a phase II proposal. Addition of some more new tools will not only help
GOs and internal staff, but will also lead to “cleaner” phase II submissions. The new tools will be
especially important for the new instruments, which are more complicated than the first generation instruments. Access to existing tools is sometimes not easy and may depend on who a person
asks for help. In general, awareness of new capabilities as they are implemented needs to be
improved. The existing tools are generated by various groups, with little coordination across different instrument groups or divisions.
The tools that are available become the official recommendation of the Institute, and as
such it is essential that the tools we provide and the framework in which we present them reflect
the service orientation of the Institute. With many of the existing tools being World-Wide Web
(WWW) based and increasing Web interaction with the GO community, we need to become more
systematic. A tools environment will provide a homogeneous user interface.
The overall goal of this tools environment is to ease the phase II proposal preparation process, via easily available tools which access current information about HST and its instruments.
To achieve this goal, this paper describes an approach that can be used to generate a consistent
tools environment. We also discuss the status of existing tools, and determine the need for new
tools.
The above task was undertaken by the author with comments from Stefi Baum, Michael
Dahlem, Ron Downes, Warren Hack, Stephen Hulbert, John MacKenty, Karla Peterson, Abhijit
Saha, and Richard Shaw. Some of the recommendations given below are based on the phase II GO
survey conducted by Daniel Golombek and Anuradha Koratkar.
2. Guidelines for the Generation of the Tools Environment:
2.1 Assumptions:
In discussing issues related to a tools environment, we make the following assumptions:
Purpose: The primary purpose of the tools environment will be to provide the GO community
with quality information and tools to help in the preparation of the phase II program.
Audience and Interface: The external audience are scientists who are preparing approved observing programs on HST. The internal audience are the members of the Institute staff who provide
GO support. The information that this audience are seeking must be up-to-date, useful and easy to
find. This implies that the interface will have to be organized by topic.
Information Content: Tools should be developed with the audience in mind. Support of the tools
should be distributed and maintained by the groups with expertise in the particular area (e.g.
instrument teams, PRESTO scientists, PRESTO developers, STSDAS developers). Standards for
how the tools are developed should be adopted. The tools should be organized with some consistency across instruments, keeping in mind that each instrument is unique in its capabilities.
Related information must be cross-referenced as often as possible and coordinated globally so
that the effects of any change to the tools can be assessed. Oversight as to general usability and
consistency of the tools is important.
Documentation: The various tools must be self explanatory whenever possible. If documentation
is required it must be easily available on-line. Useful, simple examples must exist for each task to
aid a beginner or to refresh an expert’s memory. The need for examples was indicated in the phase
II survey.
Information Organization: The organization of the tools environment must not only facilitate the
needs of a first time user, but simultaneously not restrict an experienced user. The organization
must be such that it highlights the various aspects of phase II that need to be considered. In the
future, as the capabilities of the tools environment increase, the organization can provide a user
with a checklist in the preparation of his/her phase II program.
2.2 Requirements:
The tools environment should satisfy the following requirements:
Quality Information: The primary requirement of the tools environment is to provide users with
quality information which can be easily accessed and used in developing HST programs. The
tools should help decrease the complexity of a task whenever possible. Full technical and scientific details necessary for the completion of the task should be presented at an appropriate level of
complexity. The tools should be maintained frequently in order to provide up-to-date information.
The applicability of the tools should be properly discussed.
Audience: The GO community is extremely innovative and can sometimes use the HST and its
instruments in non-standard modes. Tools cannot be generated for every possibility. Thus the
tools environment and the tools should be useful to everybody and should be applicable to at least
75% of the GO programs for a given instrument.
Responsibility: The responsibility for a clear user interface lies with the various groups that
develop the tools.
2.3 Description of the Tools Environment:
Definition: The tools environment is a collection of various tools that GOs can access
while generating a phase II proposal. These tools need not be based on just one particular computer language, but could be a grab bag of useful techniques. The usefulness of any tool depends
on many factors such as the interface, speed, feedback etc. If a tool is not suitable for a Web interface, or an interactive task is very slow because of the speed of the networks, a tool in the tools
environment could also be a set of text instructions on how to do a particular task. For example,
some tools such as the exposure time calculators can be Web-based, but a tool to determine target
coordinates could be a set of step-by-step instructions that help a GO measure their target coordinates in the STSDAS environment.
Interface: In discussing the possible interface for the tools environment, it was found that it is reasonable to assume that most GOs can access the STScI WWW pages, STSDAS and RPS2. The
phase II survey indicated that < 1% of GOs had no access to one or more of the above interfaces.
In such cases, the GO can come to the Institute, or his/her contact scientist/program coordinator
will have to provide some extra support.
The STScI WWW pages are the best location for the tools environment for the following
reasons:
• The tools presently available (see section 3) are mostly Web-based, although the user interface
needs to be enhanced for some of them (see section 3).
• Maintenance of the various tools on the Institutes’ machines will ensure that the latest information is presented to the users.
• A separate exportable tool (similar to RPS2) is not recommended, because it could easily run
into installation problems, development bugs etc. due to numerous user platforms.
Organization: The tools should be arranged with no implied sequence, but as a collection of useful tools. The tools environment is a storage place for all the tools necessary for the preparation of
a proposal. However, it must not be so cluttered that most users would find it hard to use. Therefore, a systematic arrangement is needed to ease the access to the tools.
A simple strategy would be to have a tools environment WWW page, accessible via both
the Observer page and the Instrument pages. This page would contain hotlinks to the various
tools. The hotlinks can be arranged such that a listing of this page will automatically highlight
many of the important aspects of the phase II proposal preparation that must be considered. The
instrument handbooks are the glue that bind the various tools together, and in the future, when
these handbooks become WWW friendly, they can easily be linked into the tools environment.
When the Handbooks are linked into the Web interface, the hotlinks in the tools environment can
be used as a checklist for the phase II submission process. In this context, the tools environment
page could have the following organization:
Target Coordinates: Requirements on the target coordinates for each instrument will
be discussed here, and a tool to determine the target coordinates will be provided.
Target Orientation: This section will provide a tool that calculates the orient angle that
must be provided to RPS2.
Viewing Time: This tool will provide information on dark time and CVZ.
Bright Target Check: This tool will let a GO know if a target is too bright for a given
instrument.
Duplication Check: This would be a link to the duplication checker in STARVIEW.
Specific Instrument Related Issues: This would link to each instrument’s tools page.
The instruments’ tool pages would provide the tools to determine exposure time, filter/
grating selection criteria, target acquisition strategies, dithering patterns, etc. These
tool pages would highlight many of the important subtleties of the instrument. Once
again, in the future these pages could be used as a checklist for that specific instrument.
Maintenance: Since many users may be expected to propose programs that utilize more than one
instrument, it is important that the tool interfaces present a similar look-and-feel and have similar
navigational aids. Likewise, it is also important that users be able to locate the relevant tool page
for each instrument in a similar way. Uniformity across tools whenever possible helps users to
understand the various tools quickly and decreases the level of frustration when learning a new
task. Hence, although the responsibility for each individual tool lies with the group that develops
it, a person should be designated who will be responsible for maintaining uniformity across
instruments and “functions”.
3. Status of Existing Tools:
3.1 Measurement of Target Coordinates:
The Institute recommends that GOs use target coordinates measured from the Guide Star
Catalog (GSC) plates and provide the plate ID. The same plate is then used to find guide stars,
thus improving the target acquisition accuracy because of the consistent reference frame. If different GSC plates are used the target coordinate errors could be large and the target pointing/acquisition could be jeopardized. In the overlap regions of adjoining GSC plates, discrepancies of 1” are
typical.
In previous cycles, since FOC, FOS, and GHRS have small fields of view, providing GSC
target coordinates and plate-IDs has been an observatory level requirement. In cycle 7 and
beyond, WFPC2 and NICMOS will not have the same stringent requirements for target coordinate
accuracy as the present spectrographs (FOS and GHRS). FOC will continue to require extremely
accurate target coordinates and information regarding the GSC Plate-ID, and STIS will require
reasonably accurate coordinates too, although the requirements may not be as stringent as the first
generation spectrographs. Although, target coordinate information will not be as strict as for the
present spectrographs, information on reasonably accurate target coordinates is good observing
strategy. Thus, most GOs will want to determine target coordinates to the best of their ability. A
tool to help them do so is therefore very useful.
Presently, GOs can determine the target coordinates by obtaining the FITS file of the GSC
image through the STScI WWW observer page and then following the Instructions for measuring
coordinates. These instructions inform a GO on how to retrieve or measure the target coordinates
if the target is bright enough to be in the GSC plate. If a target is not visible on the GSC plate, the
GO is asked to contact the program coordinator. A user within the Institute can also measure target coordinates in the GASP environment. This method for measuring coordinates is not available
to an outside GO, who cannot easily access the GASP environment. Determining coordinates
using GASP is not very difficult, but is not as user friendly as the IRAF/STSDAS environment
instructions discussed below. Target coordinates determined using the two methods agree to
within 0.1”. Since accessing GASP is not easy, we discuss the IRAF/STSDAS instructions in
detail.
Retrieving target coordinates: Targets brighter than V~15 have their coordinates already measured and available in the GSC. Instructions on retrieving target coordinates are simple and easy
to follow. The only recommendation for improving the WWW page that retrieves the coordinates
is a description of the catalogues that are available for searching. This description must be concise
and must let a user know the nature of the catalogue, limiting magnitude of the catalogue, and typical measurement uncertainties.
Measuring target coordinates: The instructions for measuring target coordinates for objects that
can be found on the GSC plate are also easy to follow. The measurements are done using the
IRAF/STSDAS environment. The actual steps involved are as follows:
(1) Retrieve FITS image
(2) Convert the FITS image into GEIS format in the IRAF/STSDAS environment.
(3) Centroid on the target and get the central pixel x, y values.
(4) Input the x, y values into another STSDAS task to get the target coordinates.
At the end of the process, the GO has not only the target coordinates, but also the Plate-ID.
Some of the shortcomings of the present target coordinate measurement tool are:
• There are no instructions to determine target coordinates for objects which are not bright
enough to be on the GSC plate or are saturated on the GSC plate.
• Although the instructions on retrieving or measuring target coordinates are clear and easy to
follow, we found from the phase II survey that 61% of the surveyed did not use the instructions available through the WWW pages. Of the people who used the instructions 44% had
difficulties measuring the target coordinates. An important factor seems to be that an older
version of STSDAS was being used. The instructions provided were incompatible with the
older versions of the software.
Some specific recommendations to overcome the above shortcomings and enhance the tool are:
1. For objects which are not bright enough to be on the GSC plate or are saturated on the GSC
plate, it is possible that GOs have good data from elsewhere which are usable. For such cases
instructions must be provided on how to transfer the GSC frame onto the user’s image. This
task can be accomplished in GASP. A tool, which could be a simple set of instructions on how
to transfer the GSC coordinate frame on to the user’s image, could easily be generated. This
tool may require access to GASP which is not presently available to the general community.
Limited access to GASP for all personnel actively involved in GO support and the availability
of such a tool would greatly help the Institute staff.
2. A large segment of the GO community re-observes their target after obtaining a WFPC2
image. There is an STSDAS task (metric) that allows users to determine the coordinates of a
WFPC2 pixel. A set of instructions on how to use metric on “old” WFPC/WFPC2 images to
obtain target coordinates would also be useful.
3. A simple solution to alleviate problems related to software and instructions provided as tools,
is to check instructions for backwards compatibility with the software. If backwards compatibility is not possible, users should be informed of the software requirements of the tool.
3.2 Orientation:
The orientation of the field of view (FOV)/aperture on the sky is important for many
observational programs. This is especially true if a GO has parallel observations in the observing
program. The ORIENT special requirement in phase II is used for this purpose. GOs use the ORIENT requirement not only to get a preferred direction on the sky, but also to exclude regions of
the sky. The latter is used preferentially to prevent a bright object from contaminating science
observations. Apart from being able to orient the field of view/aperture on the sky, GOs also like
to know the effect of an orient requirement on scheduling. Sometimes, depending on the guide
star availability, GOs might restructure their observing program or change the orient requirement.
Presently, we have a tool that can be accessed via STARVIEW. This tool overlays the FOV
on the sky for a given position angle. Although it is easy to use, the tool has many shortcomings,
and not all of the GO’s needs are met by this tool. Some of these shortcomings are:
• The tool does not provide the orient angle required by RPS2. The tool uses the position angle
of the V3 axis in its calculations. This axis is 180 degrees off from the axis used to measure
the ORIENT angle required in RPS2, which leads to a lot of confusion.
• The tool is not useful for any instrument other than WFPC2. This is because the FOV overlay
is only for the on-axis instrument which is WFPC2. Even for WFPC2, the STARVIEW preview facility is not detailed enough, since it does not rotate around different apertures (for
example pc1, wf1, wf2, wf3).
• The tool does not allow GOs to assess the implications of a particular orient angle to guide
star availability and scheduling.
Another simple, yet extremely useful orient tool exists for the FOC. This tool can be used
either during phase II or after data acquisition, because it does two different calculations. In one of
the calculations the tool determines the orient angle required by RPS2. In the second calculation
the tool provides the angle between North and the FOC Y axis, given a particular orient angle at
which data are acquired. Although the tool does not overlay the FOV on the sky, it does show the
orientation of the North direction and the U3 axis relative to the FOC axes. The tool also provides
the target position in the FOC XY reference frame for a particular reference position in the image.
The tool is very easy to use. Its only major shortcoming is that it does not directly overlay the
FOV on the sky for comparison. The only enhancements recommended for this FOC orient tool
are an example to guide users and improved documentation for usage.
3.3 Exposure Time Calculators:
In the past, prospective GOs have been provided with hard copy instrument manuals containing equations and tables for estimating exposure times for their targets. A small number of
more sophisticated proposers used the STSDAS “synphot” package to compute more accurate
throughputs, and indeed the exposure-related equations that appeared in the instrument manuals
were often derived (or at least verified) using synphot utilities.
Web-based software tools to aid the computation of exposure times or expected signal-tonoise ratios for a number of target types have been built by WFPC2 and FOC, and NICMOS and
STIS are in the process of developing similar tools. All these individual tools can/will be accessed
through the WWW pages for each instrument. These Web-based exposure time calculators do not
have the steep learning curve that exists when using the “synphot” package. Also these tools provide more information than is available via the synphot calculators. For example, the FOC calculator provides red leak information for the filter being used, the encircled count rate, and peak
count rate, not just the total counts. Thus the Web-based exposure time calculators (ETCs) are
very useful.
The popularity of ETCs in the past year (particularly for WFPC2) shows that such utilities
are perceived by the community as valuable and important for GO proposal preparation (both during phase I and phase II), and that investing further in this technology for new and continuing
instruments would be of great benefit. But there are serious shortcomings with the current Webbased ETCs, particularly when viewed from the perspective of long-term viability, software maintainability and extensibility, etc., while maintaining the highest standards of data quality. Such
issues must be addressed at a higher level than the individual instrument teams.
A few fairly specific requirements for Institute-sponsored ETCs are too often not being
met. The most important are:
1. All the ETCs should reference the CDBS (or files that are updated frequently from the
CDBS) in order to compute total system throughput and detector efficiencies.
2. The actual computation of the telescope and instrument throughput/efficiency and target
source characteristics should be performed with only one piece of software for which adequate resources for maintenance can be committed. Such software exists (for example, the
synphot package), and it should be used as a major component of the computing engine for
the ETCs.
3. The responsibility for a clear user interface lies with the various instrument groups, who must
provide sufficient context for users to effectively use the ETCs for all the modes of their
instruments. However, the interfaces must present a similar look-and-feel in order to aid
multi-instrument users to understand the tool being offered.
4. The tools should have examples available for the first time user.
Some specific recommendations in addition to the above are:
1. The FOC simulator FOCSIM is extensively commented (very helpful) and easy to use, yet the
amount of information provided bombards a user. It would be useful to highlight the most
important aspects of the output.
2. FOC needs to enhance FOCSIM so that exposure times can also be calculated for objective
prism exposures.
3. The WFPC2 simulator WFPC2 E.T.C. interface needs to be improved. If the program fails
there is no clear explanation as to what the user needs to do. An example would be highly
helpful. Old versions of the simulator must be hidden from a user, since they could easily lead
to confusion.
3.4 Filter/Grating Selection:
Choosing a filter/grating is important in any observing program. A GO always wants to
know which is the best filter/grating that can be used. To make this choice, information on pass
band, throughput, etc. is essential. Most of this information is presently provided in the instrument
handbooks.
WFPC2 users have a tool called the WFPC2 Linear Ramp Filter Calculator (LRFC),
which can be accessed via the WFPC2 WWW instrument page. The task is easy to use, but a few
improvements in the interface would enhance this tool. The recommendations are as follows:
1. There is no clear documentation as to when the LRFC tool should be used. Is it to be used to
determine which wavelength regions can be accessed by the ramp filters and which cannot? A
concise paragraph as to how the tool can be used would be extremely helpful. There are certain wavelength regions that are vignetted for the ramp filters, but the tool does not inform the
user of this. The standard message on using the tool is too general although it is very important. Adding information about vignetted wavelengths would enhance the usefulness of the
tool.
2. GOs do not have to use the LRFC in the preparation of their RPS2 files. They just need to
specify the central wavelength of interest and aperture in the RPS2 file. TRANS then determines the filter, and where and on which chip the target is to be located. This information is
given as a very terse note. Instead it would be useful to provide instructions to the GO as to
how the RPS2 file option parameters need to be filled in.
3.5 Dithering Patterns, Background Subtraction Patterns and Offsetting Patterns:
The WFPC2 dithering patterns (line and box) already exist in RPS2. Some comments
from the phase II survey indicated that the usage of the dithering pattern in RPS2 was ambiguous
and needed a workaround. An explanation and example within RPS2 might make the task easier
to use. In addition a paragraph or two with examples explaining how to use dithering patterns in
the WFPC2’s tool page is recommended.
4. Suggestions for New Tools:
4.1 Measurement of Target Coordinates:
1. To bypass the IRAF/STSDAS environment problems mentioned in section 3.1, the catalogues
branch would like to generate a much simpler tool. The tool’s WWW page would pull a clickable image, and the user would click on the target. Then target coordinates determined by centroiding on the clicked object along with the plate-ID would be made available to the user. The
speed of this tool is determined by the speed with which the GSC image can be accessed.
Thus the speed is projected to be the same as what is presently available for retrieving the
FITS image. Presently there is no timeline to make such a tool available, since the task has not
been made official. It is projected that it would take ~3-4 weeks to have such a task available
to the community. It would use the GASP environment to determine the target coordinates.
The improved tool would also be useful to STScI staff, since it will complete the task in one
step and will also reduce the need for disk space and image management.
2. The Institute has a policy to check target coordinates provided by GOs and provide the relevant plate-IDs. The fact that more than 60% of the GOs did not use the target coordinate measuring tool to get their plate-IDs may indicate that they depend on the Institute to provide the
plate-ID and to verify the target coordinates using the Institute provided “finder charts”. These
“finder charts” are generated by a task in the GASP environment by the program coordinators.
A WWW based task which generates “finder charts” could be made available to GOs. In this
task the GO will provide the RA and Dec of an object and obtain an image (whose size is
determined by the user). The information can be downloaded as a postscript, gif or fits format
file. This task will not only allow verification of target coordinates but also provide the plateIDs. It also relieves a user from doing a full blown determination of target coordinates if accuracy is not a major factor.
3. Although the following recommendation is not directly related to measuring target coordinates, it would be useful to have hotlinks to the tool “coco” that converts coordinates from one
reference frame to another, and also converts B1950 coordinates to the J2000 equinox.
4.2 Orientation:
In cycle7, users will want to orient the STIS long-slit aperture along a given direction. The
NICMOS users may want to place the three NICMOS apertures in a preferred position. Also, both
STIS and NICMOS have zone of avoidance requirements. Therefore, both these instrument teams
expect 75% of their proposals to have orient constraints. Hence, at least for these new instruments,
information on orient angle is essential to allow GOs to make educated decisions concerning the
orient requirement on scheduling.
An investigation for a detailed orient tool is being conducted by Abhijit Saha. His report
will consider the timeline required to develop such a tool, the medium for developing it, and any
other recommendations. In this paper we make the following recommendations that could be useful in the generation of orientation related tools.
1. GASP has the capability to overlay the WFPC2 FOV at any orient angle and any aperture on a
digitized sky survey image. This facility has been extensively used by some WFPC2 contact
scientists to help GOs determine the correct ORIENT angle. The GASP procedure can only be
accessed by a limited number of Institute staff. It is time consuming because of the various
steps involved and the need to transfer data from machine to machine. If this procedure is
streamlined and made easily available, it would be valuable to the contact scientists as well as
GOs. Further, the GASP procedure should be enhanced to include all instruments. Another
solution would be to have the GASP procedure available in the STSDAS gasp package, which
is already used by GOs for obtaining target positions.
2. The present RPS2 already has SPIKE which does contain schedulability and guide star information. An investigation on how the SPIKE information can be accessed and provided to GOs
needs to be conducted.
3. A procedure to overplot guide stars and bright objects on the digitized sky survey for a given
position and roll angle is also feasible in GASP. If this capability is made available to GOs
they could assess the implications of their orient requirements on guide star availability.
4.3 Exposure Time Calculators:
The STIS and NICMOS instrument teams are presently generating their exposure time
calculators. Evaluation of these tools will have to be conducted when they become available.
The STIS team is developing their ETC by generating a user friendly Web interface to the
one-dimensional synphot calculator. In this case, access to different databases is automatically
eliminated and only a minimum number of databases will need to be updated. The ETC will display throughput information for a particular mode, i.e., display a count rate vs. wavelength. Presently, there is no effort to generate a two-dimensional exposure time calculator.
The proposed NICMOS ETC is not wrapped around synphot, although the team proposes
to support synphot separately. Given this information we foresee that the ETC will suffer from the
generic problems discussed in section 3.3.
It is recommended that the new ETCs that are still in the development stage attempt to
meet the specific requirements for Institute sponsored ETCs discussed in section 3.3.
4.5 Dithering Patterns, Background Subtraction Patterns and Offsetting Patterns:
STIS has a few patterns called offsetting patterns, for acquiring targets using occulting
masks. These tasks effectively use POS TARG to generate the acquisition patterns. A tool displaying all target positions during a visit within the detector FOV would be extremely useful, since it
will allow a user to carefully plan observations. The tool will also help a GO to visualize where
the target will be positioned for any subsequent observation. A tool in the STSDAS environment
to display the STIS patterns is planned by the STIS team. Such a task would retrieve an image of
the sky on which the FOV and all target positions would have to be projected.
NICMOS has 9 background subtraction patterns. It is recommended that a tool to guide
GOs in selecting the correct background subtraction pattern for a given set of observational conditions be developed.
4.6 Magnitude Convertor:
NICMOS will require GOs to provide flux information in SI units and not magnitudes.
The NICMOS team is generating a tool that can be accessed via the NICMOS WWW pages. The
present tool will be capable of only a limited number of conversions. An expanded version of the
tool that will be able to convert all the various magnitude systems defined at the national and
international observatories is recommended since our GO community is drawn from all over the
world.
4.7 Viewing Time:
Some GOs also like to have information on the availability of dark time and CVZ. Presently PCs obtain this information from SPIKE and provide it to GOs. This task is time consuming.
A PC’s time could be effectively used elsewhere if a tool could be generated to determine viewing
time for GOs. The present RPS2 already has SPIKE which does contain the necessary information. An investigation on how the SPIKE information can be accessed and provided to GOs needs
to be conducted. The work requirements for this tool are similar to the schedulability information
tool discussed in section 4.2. Further, Abhijit Saha’s report (see section 4.2) will also consider this
issue.
4.8 Bright target alert:
Bright targets in the FOV of an instrument can safe the instrument, cause damage to an
observation, or contaminate a science observation. FOC, WFPC2 and STIS need a tool which
could provide a bright object check on the guide star catalog at all possible vehicle orientations or
a proposer specified orientation. This particular task may be an off-shoot of the orient tool (see
section 4.2) if the guide stars and bright objects are also marked simultaneously. The brightness
limits will have to be specified by the instrument teams.
4.9 Duplication Checker:
The Institute has strict rules about duplication of observations. There is a duplication
checker in STARVIEW which GOs access during phase I. The tool is extremely easy to use and
comprehend. A possible enhancement is to provide a concise summary on the rules of duplication
checking. This helps users by reminding them as to what constitutes a duplication. A couple of
examples would also be useful. We recommend that this tool be included in the tools environment
for completeness.
4.10 Phase Checker, Solar angle, Ephemeris information, FGS tools:
These are additional software tools that could be used by observers and may be appropriately included within the tools environment. A more detailed investigation was not considered
here because only <10% of the proposals need this information.
In the future, when the instrument handbooks are adapted for the Web interface, the tools
environment can effectively be used as a checklist in the preparation of phase II proposals. In this
scenario, the following three tools can easily be implemented.
I. Target Acquisition:
For the WFPC2, FOC and NICMOS cameras, target acquisition is not a big issue. But target acquisition is an issue that needs some consideration by a STIS user. The phase II survey
showed that 15% of the FOS GOs in comparison to less than 5% of all other GOs found it very
difficult to complete their phase II. Experience from FOS contact scientists has shown that target
acquisition is one of the most important issues with which GOs struggle during their phase II
preparation. The STIS target acquisition strategy is inherently not as difficult as that for FOS.
Hence, target acquisition templates will not be required. Yet, some extra support to GOs would be
appropriate. This can easily be achieved by providing hotlinks to the appropriate location on the
STIS WWW pages discussing target acquisition.
II. Filter/Grating Selection:
Presently STIS and NICMOS are planning to provide filter/grating information via the
instrument handbooks. A few relevant hotlinks/tools that would be very useful to GOs are discussed below.
1. STIS allows GOs to select a detector sub-array to be read out. When this capability is used,
the wavelength range observed depends on the detector sub-array used. Thus, a tool which
displays the wavelengths projected on a STIS detector for a selected grating and central wavelength would be useful.
2. In the present NICMOS handbook, the figures that provide the transmission/throughput information are extremely small and cannot be used effectively. These figures are small because
otherwise the handbook would be extremely bulky. This is understandable, yet the information in the figures is extremely important to a NICMOS user. A tool to display these figures
would be a solution. This tool can be enhanced to have a clickable image so that, for a given
wavelength, the GO can easily read-off the information on the absicssa. This type of tool
which displays wavelength vs. throughput, aperture throughputs, aperture distortion functions
etc. for the other instruments (WFPC2, FOC and STIS) will provide GOs with precise information on instrument details for comparison purposes. This set of tasks will not only be most
useful during phase I, but also during phase II when GOs have to finalize their observing strategies after the TAC allocations. This particular tool is extremely suitable to hotlinks in the
instrument handbooks once they are made more Web friendly.
III. Flow charts/Ckecklists:
The NICMOS team has developed flow charts in their instrument handbook to guide a GO
in determining his/her observing strategy. These flow charts are excellent for use as a checklist
when preparing a proposal (either in phase I or phase II). Simultaneously, the STIS team is generating a checklist in the instrument handbook for preparing proposals. These flow charts/checklists
can easily be linked into the tools environment to guide a GO. Such flow charts/checklists are also
recommended for the WFPC2 and FOC.
5. Recommendations:
We recommend the creation of a Web-based tools environment as discussed above. This
tools environment will be extremely useful to GOs in the preparation of their phase II programs.
Such an environment is a live document that can be periodically updated and enhanced. The
instrument handbooks bind the various tools together, and in the future, when these handbooks
become WWW friendly, one of the future enhancements suggested, is the ability to use the organization of the tools environment as a checklist during the phase II proposal preparation. The
effectiveness and viability of all the tools in the tools environment should be revisited periodically,
and should be in compliance with the requirements above.
A discussion of the existing tools and their status shows that, in some cases, only a more
user friendly interface and/or some enhancements may be necessary. In other cases new tools may
need to be generated. The discussions in sections 3 and 4 clearly state the detailed recommendations for a given tool. We recommend that, when instructions are provided in the tools environment there should be a check for backwards compatibility of a tool and the software it uses. If
backwards compatibility is not possible, users should be informed of the software requirements of
the tool.
The tools in the tools environment become an official recommendation and a basis for a
HOPR. They must therefore be kept up-to-date and consistent with all other methods of doing the
same calculation available to the GO. The tools should be dated so that any updates and the effect
of those updates can be easily determined. This is very important during Cycle 7 when the characteristics of the new instruments will be determined.
Many users propose programs that use multiple instruments, and so it is important that
interfaces to the various tools that determine very similar information present a similar look-andfeel, and have similar navigational aids. It is also important that users be able to locate the relevant
tool page for each instrument in a similar way from the instrument WWW pages.
Implicit in the above recommendations is the need for the supporting Web documents and
other resources to follow good Web authoring practices, and any Institute-wide standards or
guidelines that apply. Consolidation of tools will also lessen confusion regarding access to current
information. Many issues that must be addressed for the various tools and their interfaces lie outside the scope of this paper. However, it is important to realize that designing effective interfaces
(as well as the underlying tools) requires a serious and continuing effort, and one that must be
coordinated across the various functional groups if there is any hope for providing high quality
service to the community.
Although the responsibility for the individual tools lies with the various groups that
develop them, there should be a designated person who will be responsible for maintaining uniformity of similar tools. Since most of this uniformity will be across instruments, it is recommended that this designated person be from the USCC. This person will be responsible for; (1)
maintaining and updating the tools environment, (2) actively participating in increasing the audience’s awareness of new capabilities as they are implemented, and (3) coordinating the development of new tools.
The popularity of the existing Wed-based tools shows that such utilities are perceived by
the community as valuable and important. Investing further in this technology for new and continuing instruments would be of great benefit. But issues concerning the long-term viability, software maintainability and extensibility, etc., while maintaining the highest standards of data
quality must be addressed at a higher level than the individual instrument teams.
6. Future Activity:
1. Distribute this white paper for perusal by management.
2. Convene a meeting to discuss reactions, feedback and assessment of work required. Prioritize
recommendations and set timelines for generation of new tools or enhancements to existing
tools.
Space Telescope Science Institute: Tools
Environment
Anuradha Koratkar
April 9, 1999
EXECUTIVE SUMMARY
During the phase II proposal preparation stage a GO needs not only to make decisions about
many aspects of observing, but must also calculate many quantities. The bulk of information and
instructions for making these decisions and calculations is contained in the instrument handbooks
and proposal instructions. But, some helpful information is presently disseminated via tools
located in various places within the Institutes’ computer system. The present generation of tools
and their support is fairly informal. The Institute needs to have a more formal policy because
(1) a tools environment which is regularly maintained will assure access to current
information about HST and its instruments not only to the GO community, but also to the
internal staff.
(2) consolidation of tools will lessen confusion regarding access to current information.
(3) a properly organized tools environment will provide GOs with a checklist of all the
various aspects of the observing program to be considered.
(4) the ease of access and accuracy of our tools reflects the professional image of the
Institute.
In this document we provide general guidelines that could be used in developing a tools
environment, the level of oversight and technical support that will be necessary, and a list of tools
presently available to the GO community and/or internal staff. The status of the tools is also
discussed. Our initial recommendations are:
(1) to create a tools environment which should be useful to both the GO community and
internal staff.
(2) to make the tools available via the World-Wide Web.
(3) to designate a person who will be responsible for maintaining uniformity of similar
tools across instruments, although the various tools will be the responsibility of the
individual groups that generate them.
1. Introduction:
The Remote Proposal Submission Two (RPS2) software which is used during phase II
requires a number of inputs which have to be determined by the GO. Thus, the phase II preparation of a program can be quite daunting. This task can be made easier by providing GOs with
tools that can be used to calculate/determine the various aspects of the observing program. The
outputs of these various tools can then be used to fill in the RPS2 template. These tools along with
RPS2 (which is also a phase II proposal preparation tool) can be provided in a tools environment
which could also serve as a checklist in the preparation of the phase II proposal.
A number of electronic tools are presently available to a GO or internal staff member to
aid them in preparing a phase II proposal. Addition of some more new tools will not only help
GOs and internal staff, but will also lead to “cleaner” phase II submissions. The new tools will be
especially important for the new instruments, which are more complicated than the first generation instruments. Access to existing tools is sometimes not easy and may depend on who a person
asks for help. In general, awareness of new capabilities as they are implemented needs to be
improved. The existing tools are generated by various groups, with little coordination across different instrument groups or divisions.
The tools that are available become the official recommendation of the Institute, and as
such it is essential that the tools we provide and the framework in which we present them reflect
the service orientation of the Institute. With many of the existing tools being World-Wide Web
(WWW) based and increasing Web interaction with the GO community, we need to become more
systematic. A tools environment will provide a homogeneous user interface.
The overall goal of this tools environment is to ease the phase II proposal preparation process, via easily available tools which access current information about HST and its instruments.
To achieve this goal, this paper describes an approach that can be used to generate a consistent
tools environment. We also discuss the status of existing tools, and determine the need for new
tools.
The above task was undertaken by the author with comments from Stefi Baum, Michael
Dahlem, Ron Downes, Warren Hack, Stephen Hulbert, John MacKenty, Karla Peterson, Abhijit
Saha, and Richard Shaw. Some of the recommendations given below are based on the phase II GO
survey conducted by Daniel Golombek and Anuradha Koratkar.
2. Guidelines for the Generation of the Tools Environment:
2.1 Assumptions:
In discussing issues related to a tools environment, we make the following assumptions:
Purpose: The primary purpose of the tools environment will be to provide the GO community
with quality information and tools to help in the preparation of the phase II program.
Audience and Interface: The external audience are scientists who are preparing approved observing programs on HST. The internal audience are the members of the Institute staff who provide
GO support. The information that this audience are seeking must be up-to-date, useful and easy to
find. This implies that the interface will have to be organized by topic.
Information Content: Tools should be developed with the audience in mind. Support of the tools
should be distributed and maintained by the groups with expertise in the particular area (e.g.
instrument teams, PRESTO scientists, PRESTO developers, STSDAS developers). Standards for
how the tools are developed should be adopted. The tools should be organized with some consistency across instruments, keeping in mind that each instrument is unique in its capabilities.
Related information must be cross-referenced as often as possible and coordinated globally so
that the effects of any change to the tools can be assessed. Oversight as to general usability and
consistency of the tools is important.
Documentation: The various tools must be self explanatory whenever possible. If documentation
is required it must be easily available on-line. Useful, simple examples must exist for each task to
aid a beginner or to refresh an expert’s memory. The need for examples was indicated in the phase
II survey.
Information Organization: The organization of the tools environment must not only facilitate the
needs of a first time user, but simultaneously not restrict an experienced user. The organization
must be such that it highlights the various aspects of phase II that need to be considered. In the
future, as the capabilities of the tools environment increase, the organization can provide a user
with a checklist in the preparation of his/her phase II program.
2.2 Requirements:
The tools environment should satisfy the following requirements:
Quality Information: The primary requirement of the tools environment is to provide users with
quality information which can be easily accessed and used in developing HST programs. The
tools should help decrease the complexity of a task whenever possible. Full technical and scientific details necessary for the completion of the task should be presented at an appropriate level of
complexity. The tools should be maintained frequently in order to provide up-to-date information.
The applicability of the tools should be properly discussed.
Audience: The GO community is extremely innovative and can sometimes use the HST and its
instruments in non-standard modes. Tools cannot be generated for every possibility. Thus the
tools environment and the tools should be useful to everybody and should be applicable to at least
75% of the GO programs for a given instrument.
Responsibility: The responsibility for a clear user interface lies with the various groups that
develop the tools.
2.3 Description of the Tools Environment:
Definition: The tools environment is a collection of various tools that GOs can access
while generating a phase II proposal. These tools need not be based on just one particular computer language, but could be a grab bag of useful techniques. The usefulness of any tool depends
on many factors such as the interface, speed, feedback etc. If a tool is not suitable for a Web interface, or an interactive task is very slow because of the speed of the networks, a tool in the tools
environment could also be a set of text instructions on how to do a particular task. For example,
some tools such as the exposure time calculators can be Web-based, but a tool to determine target
coordinates could be a set of step-by-step instructions that help a GO measure their target coordinates in the STSDAS environment.
Interface: In discussing the possible interface for the tools environment, it was found that it is reasonable to assume that most GOs can access the STScI WWW pages, STSDAS and RPS2. The
phase II survey indicated that < 1% of GOs had no access to one or more of the above interfaces.
In such cases, the GO can come to the Institute, or his/her contact scientist/program coordinator
will have to provide some extra support.
The STScI WWW pages are the best location for the tools environment for the following
reasons:
• The tools presently available (see section 3) are mostly Web-based, although the user interface
needs to be enhanced for some of them (see section 3).
• Maintenance of the various tools on the Institutes’ machines will ensure that the latest information is presented to the users.
• A separate exportable tool (similar to RPS2) is not recommended, because it could easily run
into installation problems, development bugs etc. due to numerous user platforms.
Organization: The tools should be arranged with no implied sequence, but as a collection of useful tools. The tools environment is a storage place for all the tools necessary for the preparation of
a proposal. However, it must not be so cluttered that most users would find it hard to use. Therefore, a systematic arrangement is needed to ease the access to the tools.
A simple strategy would be to have a tools environment WWW page, accessible via both
the Observer page and the Instrument pages. This page would contain hotlinks to the various
tools. The hotlinks can be arranged such that a listing of this page will automatically highlight
many of the important aspects of the phase II proposal preparation that must be considered. The
instrument handbooks are the glue that bind the various tools together, and in the future, when
these handbooks become WWW friendly, they can easily be linked into the tools environment.
When the Handbooks are linked into the Web interface, the hotlinks in the tools environment can
be used as a checklist for the phase II submission process. In this context, the tools environment
page could have the following organization:
Target Coordinates: Requirements on the target coordinates for each instrument will
be discussed here, and a tool to determine the target coordinates will be provided.
Target Orientation: This section will provide a tool that calculates the orient angle that
must be provided to RPS2.
Viewing Time: This tool will provide information on dark time and CVZ.
Bright Target Check: This tool will let a GO know if a target is too bright for a given
instrument.
Duplication Check: This would be a link to the duplication checker in STARVIEW.
Specific Instrument Related Issues: This would link to each instrument’s tools page.
The instruments’ tool pages would provide the tools to determine exposure time, filter/
grating selection criteria, target acquisition strategies, dithering patterns, etc. These
tool pages would highlight many of the important subtleties of the instrument. Once
again, in the future these pages could be used as a checklist for that specific instrument.
Maintenance: Since many users may be expected to propose programs that utilize more than one
instrument, it is important that the tool interfaces present a similar look-and-feel and have similar
navigational aids. Likewise, it is also important that users be able to locate the relevant tool page
for each instrument in a similar way. Uniformity across tools whenever possible helps users to
understand the various tools quickly and decreases the level of frustration when learning a new
task. Hence, although the responsibility for each individual tool lies with the group that develops
it, a person should be designated who will be responsible for maintaining uniformity across
instruments and “functions”.
3. Status of Existing Tools:
3.1 Measurement of Target Coordinates:
The Institute recommends that GOs use target coordinates measured from the Guide Star
Catalog (GSC) plates and provide the plate ID. The same plate is then used to find guide stars,
thus improving the target acquisition accuracy because of the consistent reference frame. If different GSC plates are used the target coordinate errors could be large and the target pointing/acquisition could be jeopardized. In the overlap regions of adjoining GSC plates, discrepancies of 1” are
typical.
In previous cycles, since FOC, FOS, and GHRS have small fields of view, providing GSC
target coordinates and plate-IDs has been an observatory level requirement. In cycle 7 and
beyond, WFPC2 and NICMOS will not have the same stringent requirements for target coordinate
accuracy as the present spectrographs (FOS and GHRS). FOC will continue to require extremely
accurate target coordinates and information regarding the GSC Plate-ID, and STIS will require
reasonably accurate coordinates too, although the requirements may not be as stringent as the first
generation spectrographs. Although, target coordinate information will not be as strict as for the
present spectrographs, information on reasonably accurate target coordinates is good observing
strategy. Thus, most GOs will want to determine target coordinates to the best of their ability. A
tool to help them do so is therefore very useful.
Presently, GOs can determine the target coordinates by obtaining the FITS file of the GSC
image through the STScI WWW observer page and then following the Instructions for measuring
coordinates. These instructions inform a GO on how to retrieve or measure the target coordinates
if the target is bright enough to be in the GSC plate. If a target is not visible on the GSC plate, the
GO is asked to contact the program coordinator. A user within the Institute can also measure target coordinates in the GASP environment. This method for measuring coordinates is not available
to an outside GO, who cannot easily access the GASP environment. Determining coordinates
using GASP is not very difficult, but is not as user friendly as the IRAF/STSDAS environment
instructions discussed below. Target coordinates determined using the two methods agree to
within 0.1”. Since accessing GASP is not easy, we discuss the IRAF/STSDAS instructions in
detail.
Retrieving target coordinates: Targets brighter than V~15 have their coordinates already measured and available in the GSC. Instructions on retrieving target coordinates are simple and easy
to follow. The only recommendation for improving the WWW page that retrieves the coordinates
is a description of the catalogues that are available for searching. This description must be concise
and must let a user know the nature of the catalogue, limiting magnitude of the catalogue, and typical measurement uncertainties.
Measuring target coordinates: The instructions for measuring target coordinates for objects that
can be found on the GSC plate are also easy to follow. The measurements are done using the
IRAF/STSDAS environment. The actual steps involved are as follows:
(1) Retrieve FITS image
(2) Convert the FITS image into GEIS format in the IRAF/STSDAS environment.
(3) Centroid on the target and get the central pixel x, y values.
(4) Input the x, y values into another STSDAS task to get the target coordinates.
At the end of the process, the GO has not only the target coordinates, but also the Plate-ID.
Some of the shortcomings of the present target coordinate measurement tool are:
• There are no instructions to determine target coordinates for objects which are not bright
enough to be on the GSC plate or are saturated on the GSC plate.
• Although the instructions on retrieving or measuring target coordinates are clear and easy to
follow, we found from the phase II survey that 61% of the surveyed did not use the instructions available through the WWW pages. Of the people who used the instructions 44% had
difficulties measuring the target coordinates. An important factor seems to be that an older
version of STSDAS was being used. The instructions provided were incompatible with the
older versions of the software.
Some specific recommendations to overcome the above shortcomings and enhance the tool are:
1. For objects which are not bright enough to be on the GSC plate or are saturated on the GSC
plate, it is possible that GOs have good data from elsewhere which are usable. For such cases
instructions must be provided on how to transfer the GSC frame onto the user’s image. This
task can be accomplished in GASP. A tool, which could be a simple set of instructions on how
to transfer the GSC coordinate frame on to the user’s image, could easily be generated. This
tool may require access to GASP which is not presently available to the general community.
Limited access to GASP for all personnel actively involved in GO support and the availability
of such a tool would greatly help the Institute staff.
2. A large segment of the GO community re-observes their target after obtaining a WFPC2
image. There is an STSDAS task (metric) that allows users to determine the coordinates of a
WFPC2 pixel. A set of instructions on how to use metric on “old” WFPC/WFPC2 images to
obtain target coordinates would also be useful.
3. A simple solution to alleviate problems related to software and instructions provided as tools,
is to check instructions for backwards compatibility with the software. If backwards compatibility is not possible, users should be informed of the software requirements of the tool.
3.2 Orientation:
The orientation of the field of view (FOV)/aperture on the sky is important for many
observational programs. This is especially true if a GO has parallel observations in the observing
program. The ORIENT special requirement in phase II is used for this purpose. GOs use the ORIENT requirement not only to get a preferred direction on the sky, but also to exclude regions of
the sky. The latter is used preferentially to prevent a bright object from contaminating science
observations. Apart from being able to orient the field of view/aperture on the sky, GOs also like
to know the effect of an orient requirement on scheduling. Sometimes, depending on the guide
star availability, GOs might restructure their observing program or change the orient requirement.
Presently, we have a tool that can be accessed via STARVIEW. This tool overlays the FOV
on the sky for a given position angle. Although it is easy to use, the tool has many shortcomings,
and not all of the GO’s needs are met by this tool. Some of these shortcomings are:
• The tool does not provide the orient angle required by RPS2. The tool uses the position angle
of the V3 axis in its calculations. This axis is 180 degrees off from the axis used to measure
the ORIENT angle required in RPS2, which leads to a lot of confusion.
• The tool is not useful for any instrument other than WFPC2. This is because the FOV overlay
is only for the on-axis instrument which is WFPC2. Even for WFPC2, the STARVIEW preview facility is not detailed enough, since it does not rotate around different apertures (for
example pc1, wf1, wf2, wf3).
• The tool does not allow GOs to assess the implications of a particular orient angle to guide
star availability and scheduling.
Another simple, yet extremely useful orient tool exists for the FOC. This tool can be used
either during phase II or after data acquisition, because it does two different calculations. In one of
the calculations the tool determines the orient angle required by RPS2. In the second calculation
the tool provides the angle between North and the FOC Y axis, given a particular orient angle at
which data are acquired. Although the tool does not overlay the FOV on the sky, it does show the
orientation of the North direction and the U3 axis relative to the FOC axes. The tool also provides
the target position in the FOC XY reference frame for a particular reference position in the image.
The tool is very easy to use. Its only major shortcoming is that it does not directly overlay the
FOV on the sky for comparison. The only enhancements recommended for this FOC orient tool
are an example to guide users and improved documentation for usage.
3.3 Exposure Time Calculators:
In the past, prospective GOs have been provided with hard copy instrument manuals containing equations and tables for estimating exposure times for their targets. A small number of
more sophisticated proposers used the STSDAS “synphot” package to compute more accurate
throughputs, and indeed the exposure-related equations that appeared in the instrument manuals
were often derived (or at least verified) using synphot utilities.
Web-based software tools to aid the computation of exposure times or expected signal-tonoise ratios for a number of target types have been built by WFPC2 and FOC, and NICMOS and
STIS are in the process of developing similar tools. All these individual tools can/will be accessed
through the WWW pages for each instrument. These Web-based exposure time calculators do not
have the steep learning curve that exists when using the “synphot” package. Also these tools provide more information than is available via the synphot calculators. For example, the FOC calculator provides red leak information for the filter being used, the encircled count rate, and peak
count rate, not just the total counts. Thus the Web-based exposure time calculators (ETCs) are
very useful.
The popularity of ETCs in the past year (particularly for WFPC2) shows that such utilities
are perceived by the community as valuable and important for GO proposal preparation (both during phase I and phase II), and that investing further in this technology for new and continuing
instruments would be of great benefit. But there are serious shortcomings with the current Webbased ETCs, particularly when viewed from the perspective of long-term viability, software maintainability and extensibility, etc., while maintaining the highest standards of data quality. Such
issues must be addressed at a higher level than the individual instrument teams.
A few fairly specific requirements for Institute-sponsored ETCs are too often not being
met. The most important are:
1. All the ETCs should reference the CDBS (or files that are updated frequently from the
CDBS) in order to compute total system throughput and detector efficiencies.
2. The actual computation of the telescope and instrument throughput/efficiency and target
source characteristics should be performed with only one piece of software for which adequate resources for maintenance can be committed. Such software exists (for example, the
synphot package), and it should be used as a major component of the computing engine for
the ETCs.
3. The responsibility for a clear user interface lies with the various instrument groups, who must
provide sufficient context for users to effectively use the ETCs for all the modes of their
instruments. However, the interfaces must present a similar look-and-feel in order to aid
multi-instrument users to understand the tool being offered.
4. The tools should have examples available for the first time user.
Some specific recommendations in addition to the above are:
1. The FOC simulator FOCSIM is extensively commented (very helpful) and easy to use, yet the
amount of information provided bombards a user. It would be useful to highlight the most
important aspects of the output.
2. FOC needs to enhance FOCSIM so that exposure times can also be calculated for objective
prism exposures.
3. The WFPC2 simulator WFPC2 E.T.C. interface needs to be improved. If the program fails
there is no clear explanation as to what the user needs to do. An example would be highly
helpful. Old versions of the simulator must be hidden from a user, since they could easily lead
to confusion.
3.4 Filter/Grating Selection:
Choosing a filter/grating is important in any observing program. A GO always wants to
know which is the best filter/grating that can be used. To make this choice, information on pass
band, throughput, etc. is essential. Most of this information is presently provided in the instrument
handbooks.
WFPC2 users have a tool called the WFPC2 Linear Ramp Filter Calculator (LRFC),
which can be accessed via the WFPC2 WWW instrument page. The task is easy to use, but a few
improvements in the interface would enhance this tool. The recommendations are as follows:
1. There is no clear documentation as to when the LRFC tool should be used. Is it to be used to
determine which wavelength regions can be accessed by the ramp filters and which cannot? A
concise paragraph as to how the tool can be used would be extremely helpful. There are certain wavelength regions that are vignetted for the ramp filters, but the tool does not inform the
user of this. The standard message on using the tool is too general although it is very important. Adding information about vignetted wavelengths would enhance the usefulness of the
tool.
2. GOs do not have to use the LRFC in the preparation of their RPS2 files. They just need to
specify the central wavelength of interest and aperture in the RPS2 file. TRANS then determines the filter, and where and on which chip the target is to be located. This information is
given as a very terse note. Instead it would be useful to provide instructions to the GO as to
how the RPS2 file option parameters need to be filled in.
3.5 Dithering Patterns, Background Subtraction Patterns and Offsetting Patterns:
The WFPC2 dithering patterns (line and box) already exist in RPS2. Some comments
from the phase II survey indicated that the usage of the dithering pattern in RPS2 was ambiguous
and needed a workaround. An explanation and example within RPS2 might make the task easier
to use. In addition a paragraph or two with examples explaining how to use dithering patterns in
the WFPC2’s tool page is recommended.
4. Suggestions for New Tools:
4.1 Measurement of Target Coordinates:
1. To bypass the IRAF/STSDAS environment problems mentioned in section 3.1, the catalogues
branch would like to generate a much simpler tool. The tool’s WWW page would pull a clickable image, and the user would click on the target. Then target coordinates determined by centroiding on the clicked object along with the plate-ID would be made available to the user. The
speed of this tool is determined by the speed with which the GSC image can be accessed.
Thus the speed is projected to be the same as what is presently available for retrieving the
FITS image. Presently there is no timeline to make such a tool available, since the task has not
been made official. It is projected that it would take ~3-4 weeks to have such a task available
to the community. It would use the GASP environment to determine the target coordinates.
The improved tool would also be useful to STScI staff, since it will complete the task in one
step and will also reduce the need for disk space and image management.
2. The Institute has a policy to check target coordinates provided by GOs and provide the relevant plate-IDs. The fact that more than 60% of the GOs did not use the target coordinate measuring tool to get their plate-IDs may indicate that they depend on the Institute to provide the
plate-ID and to verify the target coordinates using the Institute provided “finder charts”. These
“finder charts” are generated by a task in the GASP environment by the program coordinators.
A WWW based task which generates “finder charts” could be made available to GOs. In this
task the GO will provide the RA and Dec of an object and obtain an image (whose size is
determined by the user). The information can be downloaded as a postscript, gif or fits format
file. This task will not only allow verification of target coordinates but also provide the plateIDs. It also relieves a user from doing a full blown determination of target coordinates if accuracy is not a major factor.
3. Although the following recommendation is not directly related to measuring target coordinates, it would be useful to have hotlinks to the tool “coco” that converts coordinates from one
reference frame to another, and also converts B1950 coordinates to the J2000 equinox.
4.2 Orientation:
In cycle7, users will want to orient the STIS long-slit aperture along a given direction. The
NICMOS users may want to place the three NICMOS apertures in a preferred position. Also, both
STIS and NICMOS have zone of avoidance requirements. Therefore, both these instrument teams
expect 75% of their proposals to have orient constraints. Hence, at least for these new instruments,
information on orient angle is essential to allow GOs to make educated decisions concerning the
orient requirement on scheduling.
An investigation for a detailed orient tool is being conducted by Abhijit Saha. His report
will consider the timeline required to develop such a tool, the medium for developing it, and any
other recommendations. In this paper we make the following recommendations that could be useful in the generation of orientation related tools.
1. GASP has the capability to overlay the WFPC2 FOV at any orient angle and any aperture on a
digitized sky survey image. This facility has been extensively used by some WFPC2 contact
scientists to help GOs determine the correct ORIENT angle. The GASP procedure can only be
accessed by a limited number of Institute staff. It is time consuming because of the various
steps involved and the need to transfer data from machine to machine. If this procedure is
streamlined and made easily available, it would be valuable to the contact scientists as well as
GOs. Further, the GASP procedure should be enhanced to include all instruments. Another
solution would be to have the GASP procedure available in the STSDAS gasp package, which
is already used by GOs for obtaining target positions.
2. The present RPS2 already has SPIKE which does contain schedulability and guide star information. An investigation on how the SPIKE information can be accessed and provided to GOs
needs to be conducted.
3. A procedure to overplot guide stars and bright objects on the digitized sky survey for a given
position and roll angle is also feasible in GASP. If this capability is made available to GOs
they could assess the implications of their orient requirements on guide star availability.
4.3 Exposure Time Calculators:
The STIS and NICMOS instrument teams are presently generating their exposure time
calculators. Evaluation of these tools will have to be conducted when they become available.
The STIS team is developing their ETC by generating a user friendly Web interface to the
one-dimensional synphot calculator. In this case, access to different databases is automatically
eliminated and only a minimum number of databases will need to be updated. The ETC will display throughput information for a particular mode, i.e., display a count rate vs. wavelength. Presently, there is no effort to generate a two-dimensional exposure time calculator.
The proposed NICMOS ETC is not wrapped around synphot, although the team proposes
to support synphot separately. Given this information we foresee that the ETC will suffer from the
generic problems discussed in section 3.3.
It is recommended that the new ETCs that are still in the development stage attempt to
meet the specific requirements for Institute sponsored ETCs discussed in section 3.3.
4.5 Dithering Patterns, Background Subtraction Patterns and Offsetting Patterns:
STIS has a few patterns called offsetting patterns, for acquiring targets using occulting
masks. These tasks effectively use POS TARG to generate the acquisition patterns. A tool displaying all target positions during a visit within the detector FOV would be extremely useful, since it
will allow a user to carefully plan observations. The tool will also help a GO to visualize where
the target will be positioned for any subsequent observation. A tool in the STSDAS environment
to display the STIS patterns is planned by the STIS team. Such a task would retrieve an image of
the sky on which the FOV and all target positions would have to be projected.
NICMOS has 9 background subtraction patterns. It is recommended that a tool to guide
GOs in selecting the correct background subtraction pattern for a given set of observational conditions be developed.
4.6 Magnitude Convertor:
NICMOS will require GOs to provide flux information in SI units and not magnitudes.
The NICMOS team is generating a tool that can be accessed via the NICMOS WWW pages. The
present tool will be capable of only a limited number of conversions. An expanded version of the
tool that will be able to convert all the various magnitude systems defined at the national and
international observatories is recommended since our GO community is drawn from all over the
world.
4.7 Viewing Time:
Some GOs also like to have information on the availability of dark time and CVZ. Presently PCs obtain this information from SPIKE and provide it to GOs. This task is time consuming.
A PC’s time could be effectively used elsewhere if a tool could be generated to determine viewing
time for GOs. The present RPS2 already has SPIKE which does contain the necessary information. An investigation on how the SPIKE information can be accessed and provided to GOs needs
to be conducted. The work requirements for this tool are similar to the schedulability information
tool discussed in section 4.2. Further, Abhijit Saha’s report (see section 4.2) will also consider this
issue.
4.8 Bright target alert:
Bright targets in the FOV of an instrument can safe the instrument, cause damage to an
observation, or contaminate a science observation. FOC, WFPC2 and STIS need a tool which
could provide a bright object check on the guide star catalog at all possible vehicle orientations or
a proposer specified orientation. This particular task may be an off-shoot of the orient tool (see
section 4.2) if the guide stars and bright objects are also marked simultaneously. The brightness
limits will have to be specified by the instrument teams.
4.9 Duplication Checker:
The Institute has strict rules about duplication of observations. There is a duplication
checker in STARVIEW which GOs access during phase I. The tool is extremely easy to use and
comprehend. A possible enhancement is to provide a concise summary on the rules of duplication
checking. This helps users by reminding them as to what constitutes a duplication. A couple of
examples would also be useful. We recommend that this tool be included in the tools environment
for completeness.
4.10 Phase Checker, Solar angle, Ephemeris information, FGS tools:
These are additional software tools that could be used by observers and may be appropriately included within the tools environment. A more detailed investigation was not considered
here because only <10% of the proposals need this information.
In the future, when the instrument handbooks are adapted for the Web interface, the tools
environment can effectively be used as a checklist in the preparation of phase II proposals. In this
scenario, the following three tools can easily be implemented.
I. Target Acquisition:
For the WFPC2, FOC and NICMOS cameras, target acquisition is not a big issue. But target acquisition is an issue that needs some consideration by a STIS user. The phase II survey
showed that 15% of the FOS GOs in comparison to less than 5% of all other GOs found it very
difficult to complete their phase II. Experience from FOS contact scientists has shown that target
acquisition is one of the most important issues with which GOs struggle during their phase II
preparation. The STIS target acquisition strategy is inherently not as difficult as that for FOS.
Hence, target acquisition templates will not be required. Yet, some extra support to GOs would be
appropriate. This can easily be achieved by providing hotlinks to the appropriate location on the
STIS WWW pages discussing target acquisition.
II. Filter/Grating Selection:
Presently STIS and NICMOS are planning to provide filter/grating information via the
instrument handbooks. A few relevant hotlinks/tools that would be very useful to GOs are discussed below.
1. STIS allows GOs to select a detector sub-array to be read out. When this capability is used,
the wavelength range observed depends on the detector sub-array used. Thus, a tool which
displays the wavelengths projected on a STIS detector for a selected grating and central wavelength would be useful.
2. In the present NICMOS handbook, the figures that provide the transmission/throughput information are extremely small and cannot be used effectively. These figures are small because
otherwise the handbook would be extremely bulky. This is understandable, yet the information in the figures is extremely important to a NICMOS user. A tool to display these figures
would be a solution. This tool can be enhanced to have a clickable image so that, for a given
wavelength, the GO can easily read-off the information on the absicssa. This type of tool
which displays wavelength vs. throughput, aperture throughputs, aperture distortion functions
etc. for the other instruments (WFPC2, FOC and STIS) will provide GOs with precise information on instrument details for comparison purposes. This set of tasks will not only be most
useful during phase I, but also during phase II when GOs have to finalize their observing strategies after the TAC allocations. This particular tool is extremely suitable to hotlinks in the
instrument handbooks once they are made more Web friendly.
III. Flow charts/Ckecklists:
The NICMOS team has developed flow charts in their instrument handbook to guide a GO
in determining his/her observing strategy. These flow charts are excellent for use as a checklist
when preparing a proposal (either in phase I or phase II). Simultaneously, the STIS team is generating a checklist in the instrument handbook for preparing proposals. These flow charts/checklists
can easily be linked into the tools environment to guide a GO. Such flow charts/checklists are also
recommended for the WFPC2 and FOC.
5. Recommendations:
We recommend the creation of a Web-based tools environment as discussed above. This
tools environment will be extremely useful to GOs in the preparation of their phase II programs.
Such an environment is a live document that can be periodically updated and enhanced. The
instrument handbooks bind the various tools together, and in the future, when these handbooks
become WWW friendly, one of the future enhancements suggested, is the ability to use the organization of the tools environment as a checklist during the phase II proposal preparation. The
effectiveness and viability of all the tools in the tools environment should be revisited periodically,
and should be in compliance with the requirements above.
A discussion of the existing tools and their status shows that, in some cases, only a more
user friendly interface and/or some enhancements may be necessary. In other cases new tools may
need to be generated. The discussions in sections 3 and 4 clearly state the detailed recommendations for a given tool. We recommend that, when instructions are provided in the tools environment there should be a check for backwards compatibility of a tool and the software it uses. If
backwards compatibility is not possible, users should be informed of the software requirements of
the tool.
The tools in the tools environment become an official recommendation and a basis for a
HOPR. They must therefore be kept up-to-date and consistent with all other methods of doing the
same calculation available to the GO. The tools should be dated so that any updates and the effect
of those updates can be easily determined. This is very important during Cycle 7 when the characteristics of the new instruments will be determined.
Many users propose programs that use multiple instruments, and so it is important that
interfaces to the various tools that determine very similar information present a similar look-andfeel, and have similar navigational aids. It is also important that users be able to locate the relevant
tool page for each instrument in a similar way from the instrument WWW pages.
Implicit in the above recommendations is the need for the supporting Web documents and
other resources to follow good Web authoring practices, and any Institute-wide standards or
guidelines that apply. Consolidation of tools will also lessen confusion regarding access to current
information. Many issues that must be addressed for the various tools and their interfaces lie outside the scope of this paper. However, it is important to realize that designing effective interfaces
(as well as the underlying tools) requires a serious and continuing effort, and one that must be
coordinated across the various functional groups if there is any hope for providing high quality
service to the community.
Although the responsibility for the individual tools lies with the various groups that
develop them, there should be a designated person who will be responsible for maintaining uniformity of similar tools. Since most of this uniformity will be across instruments, it is recommended that this designated person be from the USCC. This person will be responsible for; (1)
maintaining and updating the tools environment, (2) actively participating in increasing the audience’s awareness of new capabilities as they are implemented, and (3) coordinating the development of new tools.
The popularity of the existing Wed-based tools shows that such utilities are perceived by
the community as valuable and important. Investing further in this technology for new and continuing instruments would be of great benefit. But issues concerning the long-term viability, software maintainability and extensibility, etc., while maintaining the highest standards of data
quality must be addressed at a higher level than the individual instrument teams.
6. Future Activity:
1. Distribute this white paper for perusal by management.
2. Convene a meeting to discuss reactions, feedback and assessment of work required. Prioritize
recommendations and set timelines for generation of new tools or enhancements to existing
tools.