Search

Subaru Telescope, an 8-meter class optical telescope located in Hawaii, has been using a high-availability commodity cluster as a platform for our Observation Control System (OCS). Until recently, we have followed a tried-and-tested practice of running the system under a native (Linux) OS installation with dedicated attached RAID systems and following a strict cluster deployment model to facilitate failover handling of hardware problems,1.2 Following the apparent benefits of virtualizing (i.e. running in Virtual Machines (VMs)) many of the non- observation critical systems at the base facility, we recently began to explore the idea of migrating other parts of the observatory's computing infrastructure to virtualized systems, including the summit OCS, data analysis systems and even the front ends of various Instrument Control Systems. In this paper we describe our experience with the initial migration of the Observation Control System to virtual machines running on the cluster and using a new generation tool – ansible - to automate installation and deployment. This change has significant impacts for ease of cluster maintenance, upgrades, snapshots/backups, risk-management, availability, performance, cost-savings and energy use. In this paper we discuss some of the trade-offs involved in this virtualization and some of the impacts for the above-mentioned areas, as well as the specific techniques we are using to accomplish the changeover, simplify installation and reduce management complexity.

The astronomical community has a long tradition of sharing and collaborating on FITS file tools, including viewers. Several excellent viewers such as DS9 and Skycat have been successfully reused again and again. Yet this "first generation" of viewers predate the emergence of a new class of powerful object-oriented scripting languages such as Python, which has quickly become a very popular language for astronomical (and general scientific) use. Integration and extension of these viewers by Python is cumbersome. Furthermore, these viewers are also built on older widget toolkits such as Tcl/Tk, which are becoming increasingly difficult to support and extend as time passes. Suburu Telescope's second-generation observation control system (Gen2) is built on a a foundation of Python-based technologies and leverages several important astronomically useful packages such as numpy and pyfits. We have written a new flexible core widget for viewing FITS files which is available in versions for both the modern Gtk and Qt-based desktops. The widget offers seamless integration with pyfits and numpy arrays of FITS data. A full-featured viewer based on this widget has been developed, and supports a plug-in architecture in which new features can be added by scripting simple Python modules. In this paper we will describe and demonstrate the capabilities of the new widget and viewer and discuss the architecture of the software which allows new features and widgets to easily developed by subclassing a powerful abstract base class. The software will be released as open-source.

The Fibre Multi-Object Spectrograph for Subaru Telescope (FMOS) is a near-infrared instrument with 400 fibres in a 30' filed of view at F/2 prime focus. To observe 400 objects simultaneously, we have developed a fibre positioner called "Echidna" using a tube piezo actuator. We have also developed two OH-airglow suppressed and refrigerated spectrographs. Each spectrograph has two spectral resolution modes: the low-resolution mode and the high-resolution mode. The low-resolution mode covers the complete wavelength range of 0.9 - 1.8 μm with one exposure, while the high-resolution mode requires four exposures at different camera positions to cover the full wavelength range. The first light was accomplished in May 2008. The science observations and the open-use observations begin in May 2010. © 2010 Copyright SPIE - The International Society for Optical Engineering.

Subaru Telescope is commissioning a second-generation Observation Control System (OCS), building upon a 10 hear history of using the first generation OCS. One of the primary lessons learned about maintaining a distributed OCS system is that the idea of individual computer nodes specialized for specific functions greatly complicates troubleshooting and failover, even with a dedicated "hot spare" for each specialized node. In contrast, the Generation 2 (Gen2) system was designed from the ground up around the principle of a High-Availability (HA) cluster, commonly used for high-traffic, mission-critical web sites. In such a cluster, nodes are not specialized, and any node can perform any function of the OCS. We describe the problems encountered in trying to troubleshoot and manage failure on the legacy OCS system and describe the architectural design of the HA cluster for the new system, including special characteristics designed for the high-altitude, remote environment of the summit of Mauna Kea, where there is a greatly increased probability of such failures. Although the focus is primarily on the hardware, we touch upon the software architecture written to take advantage of the features of the HA cluster design. Finally, we outline the advantages of the new system and show how the design greatly facilitates troubleshooting, robustness and ease of failure management. The results may be of interest to anyone designing a distributed system using COTS hardware and open-source software to withstand failure and improve manageability in a remote environment.

Subaru Telescope is deploying and commissioning a second-generation Observation Control System (OCS), building upon a 10 hear history of using the first generation OCS, and seeking to improve several key aspects of managing and using it. Replacing an extensive, functional, mission-critical software at the core of the telescope is an ambitious undertaking. In this paper we present some important and sometimes surprising lessons learned during the buildout and commissioning phase of the Generation 2 OCS at Subaru Telescope. We present our experience with the rewrite vs. refactor decision, aspects of testing including unit and functional tests, compatibility decisions regarding legacy systems, and managing telescope priorities vs. developer priorities.