Using the Web to Plan Telescope Observations
Stephen Wampler
Gemini 8M Telescopes ProjectP.O. Box 26732, Tucson, Arizona 85732-6732, USA
Abstract
The new generation of large, ground-based telescopes
must operate differently than previous telescopes. The
cost of developing and operating these telescopes meansthat efficient and effective operation has a high priority.
While classical observing often means that astronomers
work out the details and sequencing of observations while
seated in front of the telescopes; the new telescopes require
careful planning to reduce costs and to take best
advantage of changing viewing conditions.
However, any advance planning tool presents a problem.
If it is not convenient and if it does not provide
astronomers with the tools to develop strong science
programs then the tool does not get used. Further, such atool should work for astronomers who are working awayfrom the observatory, yet still reflect the conditions at
the observatory. While the Internet and World-Wide Web
address the problems of off-site support for scienceplanning, traditional Internet-based solutions introduce
logistical problems. Similarly, traditional Web-based
approaches can quickly dissolve in user frustration overpoor network bandwidth and excessive delays.
Fortunately, new Web-based technologies address theselimitations. The Gemini 8M Telescopes Project has
adopted some of these technologies in the science
programming tools for use on Gemini telescopes. These
tools are used on- and off-site for both the development
and the execution of science programs, and works for bothclassically performed observations and preplanned, queuebased observations. This paper describes these tools andthe underlying technologies.
1 Observing with the Gemini 8M telescopes
Gemini is constructing two 8-meter aperture telescopes.
The first is located on Mauna Kea in Hawaii while thesecond is located on Cerro Pachon in Chile. Together, both
telescopes give full sky coverage with diffraction-limited
seeing in the near-infrared. Seeing image quality forground based observing is heavily dependent upon
atmospheric conditions, with the best seeing
conditions occurring approximately 10% of the time. For
this reason, science programs are characterized by theirseeing requirements. This allows on-site observersto match observations to existing conditions when
the observatory is operating using a queue of preparedscience programs. This, in turn, presupposes advance
preparation of science programs[1].
Science program preparation for the Gemini telescopes isa two-step process[2]. During Phase 1 proposal
preparation, scientists describe the science they would liketo perform using a Gemini telescope. Along with otherinformation, a proposal includes information about theinstrument configuration, celestrial target selection,
exposure times, and required seeing conditions foreach observation in the proposal. This proposal thenundergoes a review process that determines the suitability
and significance of the science that is involved. Proposals
that are accepted for execution at a Gemini telescope thenenters Phase 2 preparation, where a formal science
program[3] is constructed. This science program fully
describes the sequence of observations to be carried out bythe telescope.
When a proposal is awarded classical observing time, it
is scheduled to run in a series of blocks under thecontrol of the astronomer or an on-site observer. Duringclassical observing, the astronomer is taking a chance thatthe seeing conditions are sufficiently good during thescheduled time. If conditions are not good enough, thescience program is wasted. Proposals scheduled forqueue observing, however, are placed into a pool of queuebased programs. Staff astronomers can match seeing
conditions to seeing requirements for the observations inthis pool to select the best observation to perform. (Othercriteria, such as a scientific merit rating, are factors in thisselection process.)
2 Tools for program preparation
Effective use of the Gemini telescopes requires thatscience programs be prepared well in advance of actualuse of the telescopes. There are a number of factors that
impact this preparation.
•The Gemini partnership consists of six countries,
widely distributed around the globe (United States,United Kingdom, Canada, Chile, Argentina, andBrazil).
•Some sites within the partner countries suffer severe
performance limitations when using the Internet.

•Sites within the partnership use a variety of different
computer systems.

•Gemini resources are limited.

The Internet and the World-Wide Web are natural
resources to use in support of proposal and science
program preparation. However, experience with bandwidth
limitations and network delays has shown that traditional
web (typically cgi-script based) are not suitable.
Furthermore, this approach relies heavily on active
connections to a central site, which is problematic given
the locations of the observatory facilities. This leads to asolution where software is distributed from the central site
for execution off-site. Traditionally, this means bundlingthe software into an archive and then making the archiveavailable via ftp. Either the source or a binary distribution
can be provided in this manner.
Distributing software has its own problems, particularly
in a heterogenous environment of mixed computer
systems. Such distributions require large amounts ofsoftware support to handle a multiplatform distribution. An
additional problem is keeping the distributed softwaresynchronized. Since instrumentation at the observatorychanges over time it is important that astronomers use thecurrent version of a tool to ensure compatibility.

program that can then be complete during
2 process.

the Phase

2.1 New technologies
Recently, several new technologies have been introduced
that provide an infrastructure that address the above issues.
First, the emergence of Java as a system independent,
high-level programming language has greatly reduced theproblem of supporting software across a multiplatform
environment. Java's object-oriented design, support forgraphical user interfaces, and system independence are all
useful programming features.
Second, the support for push technology on the Web
helps with the problems of distributing and maintaining
software in a widely distributed environment. For example,
Marimba's Castanet technology allows software
to effectively update itself as needed by automaticallyconnecting to the central site to obtain updates. In this way
users can be assured of access to the most recent version ofa software tool.
The Gemini tools for proposal and program preparation
are written in Java and distributed with Castanet. Whenrunning, none of the tools require a network connection
to the observatory.

Figure 1 Phase 1 observation description

2.2 Phase 1 proposal preparation
The Phase 1 proposal tool[4] is intended to simplify theastronomer's entry of required information and theautomatic creation of a draft science program from theproposal. The tool is entirely GUI-based and includes
navigational aids as well as consistency checks. Figures 1
and 2 show two of the screens from the tool.
In Figure 1, the astronomer is entering information about
the observations that need to be taken as part of theproposal. Since obtaining high-quality data with a Gemini
telescope requires appropriate guide stars near each target,
selecting Find Guide Stars... results in a catalog search
to determine if any guide stars are available for the current
target.
Figure 2 shows the navigation window. As entry screensare completed, they are checked off in the navigation
window. This allows the astronomer to quickly determine
which parts of the proposal need more work.
When the astronomer is satisfied with the proposal, thetools submits it to the screening board, or Time Allocation
Committee(TAC) for the astronomer's country. Proposals
that are accepted by the country's TAC are then submitted
to a TAC for the entire partnership of countries. Successfulproposals end up at the Gemini observatory. The Phase
tool submits the proposal as a rudimentary science

Figure 2 Phase 1 navigator
2.3 The science programA science program (Figure 3) describes, in detail, theinformation needed to perform the requisite science. This
program is a hierarchical collection of objects. Basic levelsin the hierarchy are the program, groups of observations
called folders, observations, components, and iterators.
The program level collects a potentially large
set of observations all related to a single science goal.
Programs map one-to-one with proposals. Observations
collect information for one or more science frames
associated with a given target position in the sky.
Observations range from a simple stare at a given RA/Dec
to complex mosaic patterns, etc. Observations consist ofvarious components and an (optional) iterator. The
components describe the static setup and schedulingconstraints of an observation, for instance, the telescopeslew target, guide star selection, initial instrument
configuration, etc. Iterators describe how to operate on thestatic components in the observation to produce sciencedata. Example iterators include offset patterns for dithers
and mosaics and cycles of instrument filters. Iterators
allow sequences of repetitive tasks to be expressedconcisely, even if some properties (e.g., offset position orfilter selection) vary from exposure to exposure.

Figure 3

A Science Program (observing tool view)

2.4 The observing tool
Phase 2 preparation is done using the Observing Tool[5].
This tool allows the astronomer to provide detailed
information about the planned science, including fullsequencing of the individual observations involved. Unlessthe astronomer constrains the observations contained in thescience program, individual observations may be executedin any order, at any time. This allows the observatory staff
to schedule observations to make the most efficient use ofchanging conditions. The astronomer may, however,chain observations to be executed in a specific sequence
and also group observations to execute as a single block.
Components within an observation are configured using
an appropriate configuration editor - there are different
configuration editors for the different components. For
example, the editor for the Near Infrared Imager allows theastronomer to select filters, exposure times, etc., while thetarget editor allows the astronomer to associate specifictargets and guide stars with a given observation. Because
many pieces of configuration information relate
to positions on the sky, a position editor is available forvisually selecting and modifying these items. The position
editor (Figure 4) can display an image of a region of thesky and overlay target positions, nearby guide stars,auxiliary probe positions, and science detector positionand orientation.

Probes, target positions, and science detectors can thenbe moved to new positions using the mouse. The sky
image is typically loaded from one of a number of Webbased sky survey catalogs, as are the nearby guide stars.
Images can also be loaded from local files if desired.
When using the observing tool to complete a science
program, the astronomer must first access the observatory
and retrieve a copy of the science program. While working,the astronomer may choose to save the program locally orstore it back at the observatory. When the science programis ready, it must be stored back at the observatory forscheduling and execution. The Observing Tool uses Sun'sJoe (Java Objects Everywhere, based on CORBA/IIOPtechnologies) to communicate with the observatory.
One goal of the design of the Observing Tool is that it
also function on-site during interactive observing. This
provides astronomers with a common tool whether
planning observations or interacting directly with thetelescope during classical observing. During interactiveuse, the Observing Tool again uses Joe to interact with thecontrol system. Observations may be submitted for
immediate scheduling and execution.
3 Status
Both tools described here are currently in Beta test.
So far, both tools have been used on Sun Solaris, Linux,MacOS, Windows NT, and Windows '95 withno modifications to the tools (a shell script used to start thetools required minor modifications to work with theWindows operating systems). Although there are
performance concerns on some systems over the use ofJava, this will improve as Java matures. Both tools work
well when used on laptops, even when removed from theWeb. Naturally, some functionality is lost when
so isolated, but these operations are quickly restored whenreconnected to the Web.
Acknowledgments
The Phase 1 proposal tool was written by Dayle Kotturi.
The Observing Tool was written by Shane Walker. Kim
Gillies provided significant technical support, including
major infrastructure components, to both tools. Principal
scientific direction came from Phil Puxley.
References[1] Wampler, et al, Software Design Description, Controls
Group, Gemini 8M Telescopes Project, 1994.
[2] Wampler, Gillies, Puxley, and Walker, ``Scienceplanning for the Gemini 8M Telescopes'', in Telescope
Control Systems II, Hilton Lewis, Editor, Proceedings ofSPIE Vol. 3112, 246-253, 1997.
[3] Walker et al., Observing Tool Design Foundations,Controls Group, Gemini 8M Telescopes Project, 1997.
[4] Kotturi, Dayle, ``Gemini Phase 1 Science Proposal
Entry Tool'', SPIE Conference proceedings, 1998.
[5] Walker, et al, “Science planning with the Gemini
Observing Tool”, SPIE Conference proceedings, 1998.

Figure 4 The position editor