The Lowell Observatory Public Astronomical Research Center

The Lowell Observatory Public Astronomical Research Center by Jeffrey C. Hall
The Lowell Observatory Public Astronomical Research Center (LOPARC) is an Internet observatory that allows users to access a research-grade telescope, an online digital archive of astronomical images, and server-side software that many professional astronomers use in their research. Online activities are available at a variety of conceptual levels, allowing anyone from primary school students to adults to use the facility with appropriate content. Two versions of the user interface allow clients to be deployed for general home or private-venue access, as well as in a more restricted point-and-click mode in public venues such as museums and public libraries. The facility is currently open in its initial public release at Lowell Observatory's campus in Flagstaff, Arizona, and is slated for full Internet availability by September, 2003.

Contents

Introduction
Design goals
System design
Maintenance, expansion, and administration
Conclusion

Introduction

The Lowell Observatory in Flagstaff, Arizona, is a 108-year old, private, non-profit institution dedicated to astronomical research and education. The 22 astronomers on our science staff are leaders in their areas of specialization, while our education and outreach program brings some 70,000 visitors each year to our campus. Our 6,500 square-foot Steele Visitor Center is open 360 days per year, and has a large exhibit hall and auditorium that serves as the focal point of our programs. On our campus are two telescopes dedicated to public education: the historic 24" Alvan Clark refractor, used by Percival Lowell a century ago to map features on the surface of Mars, and the 16" reflecting telescope of the John Vickers McAllister Public Observatory, installed in 1996 about 100 feet south of the Clark telescope dome.

Figure 1: The John Vickers McAllister Public Observatory is located at an elevation of 7,250 feet on the campus of Lowell Observatory. Inside this dome is a high-quality 16" telescope dedicated to public outreach.

In late 1999, we undertook initial fundraising to make the 16" McAllister telescope available for public use via the Internet. Remote control of telescopes is now commonplace for both research and education, but we proposed to develop a new access model that provided easy, first-come first-served control of the telescope, research-grade server-side software for data analysis, and extensive online help and guided activities at a variety of conceptual levels. The result of this effort is the Lowell Observatory Public Astronomical Research Center (LOPARC). The telescope dome is shown in Figure 1, and the control room in our visitor center is shown in Figure 2. Development of LOPARC began in early 2000, and beta testing of the completed core system began in December 2002. The public version 1.00 code freeze occurred on schedule on 4 April 2003, with release of the initial public URL on 7 April. In this note, I provide a brief overview of this system and its capabilities.

Figure 2: The LOPARC control room is located near the exhibit hall in Lowell's Steele Visitor Center, about 125 feet from the telescope dome. In this photograph, informational displays and a video feed from the telescope are visible at the front of the room, while the six clients are housed in consoles and are controlled via a point-and-click interface.

Design goals

Our needs analysis, carried out in early 2000, revealed four user groups: museum or science center visitors, schools, casual home users, and knowledgeable amateurs. Each group would have different demands on the system. Teachers were understandably interested in guided activities aligned with state and national curriculum standards, while astronomy enthusiasts wanted freer exploration of the digital archive, as well as the ability to retrieve data in a standard scientific format for their own use. Users in our visitor center or in other public venues would need concise, clear expositions of the data and the concept being illustrated, while home users would want a system they could explore in a more leisurely fashion. A desire to accommodate all four of these user groups led to the following five design goals, all of which are realized in the final system.

Goal 1: Continuous access. Since the telescope can only be open on clear nights, and will be reserved on many of those nights for users in our Visitor Center, the archive of images must be continuously accessible, and tools must be in place to let users browse, study, and download the data as they desire, even when the telescope is closed. Users should be able to choose from a pre-selected list of objects, as well as search the archive for a specific object and data frame. Users onsite in our visitor center should be able to access the system at the same time as remote users.

Goal 2: Multiple avenues of access. The online activities must be accessible in a variety of ways. Casual users should be able to find guided, step-by-step projects that illustrate basic concepts in astronomy and image processing, while more advanced users should find more challenging presentations of the concepts, as well as freer, less strictly-guided exploration of the data. Children and adults alike should be able to find accessible descriptions of the images and concepts.

Goal 3: Rapid, "hot-swap" maintenance and expansion. System administrators should be able to add components such as activities and help items to the system while it is live, requiring no logoffs by users or rebooting of the server. We should be able to change projects, text, help, quiz questions, and other system elements even as users are interacting with the system, allowing us to rapidly change content to suit the needs of specialized user groups (e.g., K-12 classes), as well as to quickly fix errors and bugs in the system.

Goal 4: Rigorous science. The system should not talk down to any user. Data should not be altered in any way in an attempt to make them "pretty," and should be available for download in a standard, portable scientific format. Text should explain concepts clearly, but not in an oversimplified way, even in material targeted for more elementary conceptual levels.

Goal 5: Supplementary information. The system should provide online help, information on current Flagstaff weather, current user load, and status of the telescope.

System design

Software platform

Meeting the five design goals given above required a model that would be flexible, accessible, yet also provide users with research-grade computing power and software tools. In the early stages of system design, we identified a software solution that would make the stated goals attainable, while also taking advantage of significant existing expertise.

The primary software used in LOPARC is the Interactive Data Language (IDL), a product of Research Systems, Inc. (RSI), in Boulder, Colo. The IDL kernel is optimized for fast processing of vector data such as two-dimensional, digital astronomical images. In addition, IDL provides a complete programming language with support for object-oriented code, as well as a large built-in library of math, I/O, plotting, and other routines. Many astronomers, including the author and a number of other Lowell scientists, use IDL exclusively in their research, and the extensive in-house knowledge of the IDL language enabled rapid progress in the initial design.

To make access to IDL available to users who do not own an IDL copy or license, RSI produces a companion product, IDL On the Net (ION), which provides a set of Java classes that

manage a persistent socket connection between a client running a Java-enabled browser and an ION server,

accept IDL commands from the client and run them in a server-side IDL session, and

translate graphic output from IDL to Java graphic primitives to be sent to the client and rendered in the Web browser.

The combination of ION and IDL therefore allows Internet users to run an IDL session on the remote server and have the results rendered in their Web browser.

The LOPARC core software is based on this ION/IDL paradigm. We have written Java applets that perform the tasks necessary to allow Internet users to operate LOPARC from their Web browsers, and we have also written an object-oriented image processing and analysis class library in IDL, which remote users access on our server when they connect via the ION Java applet.

Supplementing this software is a native Java application that manages a first-in first-out observing queue. This application dispatches the necessary commands to move the telescope, control the detector, transfer newly acquired data to the server, and prepare the data for use in an IDL session. If observation requests are posted by users faster than they can be executed, they stack up in the order received and are carried out once previous observations have finished.

Access to the ION server is managed through a Web site written using primarily PHP. Logins are restricted via an elementary user ID/password shell; this serves the dual purpose of allowing us to restrict access to the telescope queue to any set of clients we wish, as well as managing the overall usage burden on the server.

This approach transfers nearly all the computing and storage burden of the system to the server: The digital archive is stored there, and image processing tasks are performed server-side, with output and results sent to the client. The advantage of the IDL/ION platform to the Internet user is access to this heavy-duty analysis software and a research-grade archive. The tradeoff is somewhat longer response time relative to that of a pure Java applet, due to the graphics transfer from server to client that must be carried out with each input by the user. This larger system latency is noticeable only on moderate to slow (28 Kbps or less) dialup connections, and we have tailored the layout and size of the applet to minimize it.

Applet versions

LOPARC has two applets that are functionally similar but tailored to different environments. When users register on the LOPARC Web site, they are classified in the user database as public. When public users connect to LOPARC, they run what we call the browser-mode applet, as shown in Figure 3.

Figure 3: The browser-mode applet uses native Java components to render text, menu items, and user options at left. The black area at right is the graphics canvas used for IDL output. Selected areas of this canvas can be made clickable, allowing users to select portions of the image for study and modify the project parameters. Dialog boxes can be called up from the menu that provide continuously updating system status information, weather reports, and detailed online help.

This applet contains instructions, and option list, and online help and details on the left side of the GUI, while the IDL output appears on the right. This GUI is designed for home use, allowing hotkey and text input, and having a relatively small IDL graphic area to improve the system response on slow connections.

Alternatively, users may (upon request) be reclassified in our database as kiosk users, in which case their connection to LOPARC will open the kiosk-mode applet displayed in Figure 4 below.

Figure 4: The kiosk-mode applet employs a single large ION Java canvas to render graphical output from IDL. The resulting display is an attractive interface for exhibit and museum venues, while its point-and-click character provides controlled access for public areas. The dialogs available with the browser-mode applet are not available in kiosk mode, but otherwise it is functionally similar to that version of the software.

This much larger graphic display area opens in full-screen mode, and employs a purely point-and-click interface. It is intended for use in public venues such as visitor centers, public libraries, and other locations where controlled access is desirable. Because of the large graphic that must be transferred from our server to a kiosk client, we recommend this applet be used only by users with broadband connections.

IDL Class Library

The LOPARC Java applets primarily provide interfaces through which users access the main software — the server-side IDL class library — that does the real work. The central challenge of the IDL class library design was to create a system that would let users customize the nature and difficulty of the activities they access, while also allowing administrators to respond quickly to requests and problems.

We call LOPARC activities "projects," and the design of the class library allows users to select from a variety a conceptual level and projects for every image in the archive. Therefore, rather than a "straight-line" entry into the system (where, for example, we might offer the user a single activity suitable for a particular grade level), we have adopted a "3D" entry, where users customize difficulty, project topic, and data to be studied with every session. Based on user inputs at the start of a session, the object-oriented IDL system creates instances of objects that deliver the type of interaction requested. Each time users leave a project, they are returned to the start screen, allowing them to exit the system or begin another project of their choosing.

A full description of the library design is beyond the scope of this note, so I will summarize its essential structure only. At the top of the class hierarchy is an abstract parent class Root that provides basic event logging services, and from which several important hierarchies are derived. These comprise groups of classes that

manage interaction with the data archive,

load and execute projects in response to user-defined parameters as described above,

define Tools, which comprise a large set of classes, each of which defines a specific operation upon arbitrary binary data,

manage the import and export of variables that must be synchronized with the Java clients, and

parse the spectrum of options and requests the users can post to the server.

This class library now comprises over 1,000 object methods, with a large number of Tool-derived objects still under development.

Care has been taken to ensure that basic operations essential to the LOPARC project model are encapsulated in abstract classes, making possible the adoption of the LOPARC model by other institutions.

Maintenance, expansion, and administration

From the outset, we wished to have a system that could be maintained and modified without requiring programming expertise of administrators. We have done this using the standard paradigm of separating

the content,

the software objects that display the content, and

the software objects that manage user interaction with the content.

First, many of the administrative and system status flags are stored in plain text or binary data files in a protected area of the server, with access to these files managed by an IDL class accessible only to system administrators. The telescope can be opened and closed, for example, by staff with no prior computer experience; all that is required is to enter the appropriate command to the administrator class, and all active clients will register the change. Additionally, most of the text content of the system — whether in the applet displays or online help — is maintained in text files, and can therefore be modified while users are logged in to the system.

The second design element involves the method by which new projects are introduced into the system. A LOPARC project is defined by a plain text resource file that specifies the user options, clickable areas of the interface, and the software objects the project will need. Designers of a project need not know how the software object works; they only must specify the proper initialization and it will be incorporated into the userÕs session when the project is loaded. Project designers can specify the use of any software objects and text files they wish, tailoring the project to any desired level of complexity. Typically, a given project has three parallel resource files that define it at the three main conceptual levels available to users. Projects can be defined as rigorous step-by-step activities or as completely open-ended explorations of the data, as defined by what we term a decision matrix in the project resource file that specifies what users can do or click, and what they will see, at a given point in the project. At first glance, the decision matrices look arcane, but this merely stems from the shorthand that goes into coding them in a form that is reasonably straightforward for a computer to parse; no programming knowledge is required to create them.

An essential part of the ongoing maintenance and development of the system is assessment of its effectiveness. The IDL class library defines a Monitor object, to permit assessment of LOPARC system administrators and assessment professionals. Every user interaction with the system is logged with a timestamp by the Monitor object, enabling us to see how users progress through a project, whether they are carrying out the activities in the expected order, and whether the results of self-check quizzes available with each project indicate that the material was effective. A direct, seven-question evaluation of LOPARC is also available at the end of each project for kiosk-mode clients. The administrative class includes methods to display quantitative analyses of these assessment data.

Conclusion

We have deployed a public Internet observatory at our campus in Flagstaff, Arizona, using an object-oriented software system that provides flexible access to online activities at a variety of conceptual levels. Initial design of this system began in early 2000, and this paper follows the general outline of a status report on the advanced stages of the project given at the Web-Wise conference held in Washington, D.C., 26 to 28 February 2003.

As of April 2003, the initial public release of the system is available at our Web site at http://kraken.lowell.edu/leo.php. This release allows access to our online archive of previously acquired images, while real-time observations with the telescope are scheduled to begin on site at Lowell in May 2003, and to the Internet at large in the summer of 2003. During the public release of the system, we will continuously expand the projects and options available to users, providing both guided activities and free exploration of the data.

About the Author

Jeffrey Hall is an Assistant Research Scientist and Associate Director for Education and Special Programs at Lowell Observatory. He received a B.A. in Physics in 1986 from the Johns Hopkins University and a PhD in Astronomy and Astrophysics in 1991 from the Pennsylvania State University. He joined the staff at Lowell Observatory in 1992, where he divides his time between research and public outreach.
E-mail: jch@lowell.edu

Acknowledgements

The author thanks Arizona Public Service (APS) for a foundation grant that provided launch funding for this project, and the City of Flagstaff for support through the Flagstaff Arts & Sciences Commission and the Flagstaff Cultural Partners. A 2001 National Leadership Grant from the Institute of Museum and Library Services (IMLS) provided funds needed to complete the project. In-kind contributions from Sun Microsystems and Research Systems, Inc., assisted with the hardware and software acquisition costs associated with the project. Additional funds have been provided through generous contributions from numerous corporate foundations and individuals.

Editorial history

Paper received 8 April 2003; accepted 12 April 2003.

Copyright ©2003, First Monday

Copyright ©2003, Jeffrey C. Hall

The Lowell Observatory Public Astronomical Research Center by Jeffrey C. Hall
First Monday, volume 8, number 5 (May 2003),
URL: http://firstmonday.org/issues/issue8_5/hall/index.html