The instrumentation of the Prime Focus Spectrograph (PFS), a next generation facility instrument on the Subaru telescope, is now in the final phase of its commissioning process and its general, open-use operations for sciences will provisionally start in 2025. The instrument enables simultaneous spectroscopy with 2386 individual fibers distributed over a very wide (∼1.3 degrees in diameter) field of view on the Subaru’s prime focus. The spectra cover a wide range of wavelengths from 380nm to 1260nm in one exposure in the Low-Resolution (LR) mode (while the visible red channel has the Medium-Resolution (MR) mode as well that covers 710−885nm). The system integration activities at the observatory on Maunakea in Hawaii have been continuing since the arrival of the Metrology Camera System in 2018. On-sky engineering tests and observations have also been carried out continually since September 2021 and, despite various difficulties in interlacing commissioning processes with development activities on the schedule and addressing some major issues on hardware and software, the team successfully observed many targeted stars as intended over the entire field of view (Engineering First Light) in September 2022. Then in parallel to the arrival, integration and commissioning of more hardware components, validations and optimizations of the performance and operation of the instrument are ongoing. The accuracy of the fiber positioning process and the speed of the fiber reconfiguration process have been recently confirmed to be ∼ 20−30μm for 95% of allocated fibers, and ∼130 seconds, respectively. While precise quantitative analyses are still in progress, the measured throughput has been confirmed to be consistent with the model where the information from various sub-components and sub-assemblies is integrated. Long integration of relatively faint objects are being taken to validate an expected increase of signal-to-noise ratio as more exposures are taken and co-added without any serious systematic errors from, e.g., sky subtraction process. The PFS science operation will be carried out in a queue mode by default and various developments, implementations and validations have been underway accordingly in parallel to the instrument commissioning activities. Meetings and sessions are arranged continually with the communities of potential PFS users on multiple scales, and discussions are iterated for mutual understanding and possible optimization of the rules and procedures over a wide range of processes such as proposal submission, observation planning, data acquisition and data delivery. The end-to-end processes of queue observations including successive exposures with updated plans based on assessed qualities of the data from past observations are being tested during engineering observations, and further optimizations are being undertaken. In this contribution, a top-level summary of these achievements and ongoing progresses and future perspectives will be provided.
We present a simple sytem for job distribution built on the RabbitMQ open-source message broker. The system is based on the concept of job sources (origins), sinks (destinations) and realms (hubs), where a network of these entities can be readily established with a configuration file for each site and a RabbitMQ server running at each hub. Jobs are sent via persistent JSON-encoded packets and delivered reliably by RabbitMQ queues. The system was built primarily for robust data tranfers amidst volatile network connections but is general enough for any kind of flexible job distribution scheme where reliable delivery of job messages is needed. We are releasing the ”datasink” as an open-source Python package on Github. Aside from RabbitMQ, there are minimal additional requirements.
The Subaru Telescope recently celebrated its 20th year of operation. Despite that lengthy period of successful operation, it has never had a proper simulator for its telescope control system. This fact complicates the development and testing of observing scripts that need to send commands and receive realistic feedback from both telescope and instrument systems. The Subaru telescope control system was developed by a subcontractor and there was no requirement for it to be able to run in simulation mode. Furthermore, the source code is proprietary and is not accessible by current Subaru software engineers. These two facts greatly complicated the development of a telescope simulator. Prior to the current effort, the telescope simulator consisted of a “yes-man” interface, i.e., the rudimentary simulator would just respond that it received the command but would not simulate telescope motion or set any status items to provide feedback to the observing scripts. The telescope simulator developed in this effort currently simulates the following components: telescope and instrument rotator motion, focal station configuration, autoguide camera images and pointing errors, as well as facility hardware like dome shutters and mirror covers. We have plans to further refine all those components and implement features like simulated environmental conditions based on historical weather data. The simulator has already proven useful in testing observation scripts. In addition, the simulator will also be a good training aid for new telescope operators.
Subaru Telescope, an 8meter class optical telescope located in Hawaii, has been using a high availability commodity cluster as a platform for our Observation Control System for many years.1 A concerted attempt to virtualize this infrastructure using conventional virtual machines2 was eventually scuttled due to performance impacts on the observation software under sustained use. With the ascendance of container-based virtualization, and its promise of high-efficiency, we recently attempted this effort anew, and have found success with an approach that employs Linux (LXC) containers. This has provided immediate benefits in maintenance, risk management and availability. In this paper, we document our transition and discuss the rationale for this choice vs. the arguably more popular Docker containerization scheme. We list some of the issues we encountered and solved to realize a successful transition to containers. We have also recently converted our software stack to being based on Miniconda, a popular, opensource, crossplatform software distribution service. This move basically decoupled our software completely from the operating system platform, and provides a virtualized software stack with many desirable benefits. The combination of the LXC containers and Miniconda gives us an orthogonal three-axis virtualization scheme with extreme flexibility. We present our system for managing Miniconda environments, the benefits that accrue, and how this three-axis approach to virtualization has altered our deployment and management strategies.
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 Maunakea Laser Traffic Control System (LTCS) has been in use since 2002 providing a mechanism to prevent the laser guide star or Rayleigh scatter from a laser propagated from one telescope from interfering with science observations at any of the other telescopes that share the mountain. LTCS has also been adopted at several other astronomical sites around the world to address that same need. In 2014 the stakeholders on Maunakea began the process of improving LTCS capability to support common observing techniques with enhanced First On Target (FoT) equity. The planned improvements include support for non-sidereal observing, laser checkout at zenith, dynamic field of view size, dithering, collision calculations even when a facility is not laser impacted, multiple alert severity levels, and software refactoring. The design of these improvements was completed in early 2015, and implementation is expected to be completed in 2016. This paper describes the Maunakea LTCS collaboration and the design of these planned improvements.
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.
KEYWORDS: Computing systems, Control systems, Data acquisition, Observatories, Telescopes, Data archive systems, Astronomy, Data communications, Software development, Data processing
The high data rates and unique operation modes of the SCUBA-2 instrument made for an especially challenging effort
to get it working with the existing JCMT Observatory Control System (OCS). Due to some forethought by the original
designers of the OCS, who had envisioned a SCUBA-2 like instrument years before it was reality, the JCMT was
already being coordinated by a versatile Real Time Sequencer (RTS). The timing pulses from the RTS are fanned out to
all of the SCUBA-2 Multi Channel Electronics (MCE) boxes allowing for precision timing of each data sample. The
SCUBA-2 data handing and OCS communications are broken into two tasks, one doing the actual data acquisition and
file writing, the other communicates with the OCS through Drama. These two tasks talk to each other via shared
memory and semaphores. It is possible to swap back and forth between heterodyne and SCUBA-2 observing simply by
selecting an observation for a particular instrument. This paper also covers the changes made to the existing OCS in
order to integrate it with the new SCUBA-2 specific software.
The James Clerk Maxwell Telescope (JCMT) Telescope Control System (TCS) received significant upgrades to provide
new observing capabilities to support the requirements of the SCUBA-2 instrument. The core of the TCS is the Portable
Telescope Control System (PTCS), which was developed through collaboration between the Joint Astronomy Centre and
the Anglo-Australian Observatory. The PTCS provides a well-designed virtual telescope function library that simplifies
these sorts of upgrades. The TCS was previously upgraded to provide the required scanning modes for the JCMT
heterodyne instruments. The heterodyne instruments required only relatively simple raster or boustrophedon patterns,
which are basically composed of multiple straight-line scans to cover a rectangular area. The most recent upgrades built
upon those heterodyne scanning modes to satisfy the SCUBA-2 requirements. With these upgrades, the TCS can scan
the telescope in any pattern that can be described as a continuous function of time. This new capability has been utilized
during the current SCUBA-2 on-sky commissioning phase to scan the telescope in a variety of patterns (Lissajous, pong,
ellipse, and daisy) on the sky. This paper will give a brief description of the PTCS, provide information on the selection
of the SCUBA-2 scanning modes, describe the changes to the TCS that were necessary to implement the new scanning
modes, and show the performance of the telescope during SCUBA-2 commissioning.
This paper describes the key design features and performance of HARP, an innovative heterodyne focal-plane array
receiver designed and built to operate in the submillimetre on the James Clerk Maxwell Telescope (JCMT) in Hawaii.
The 4x4 element array uses SIS detectors, and is the first sub-millimetre spectral imaging system on the JCMT. HARP
provides 3-dimensional imaging capability with high sensitivity at 325-375 GHz and affords significantly improved
productivity in terms of speed of mapping. HARP was designed and built as a collaborative project between the
Cavendish Astrophysics Group in Cambridge UK, the UK-Astronomy Technology Centre in Edinburgh UK, the
Herzberg Institute of Astrophysics in Canada and the Joint Astronomy Centre in Hawaii. SIS devices for the mixers were
fabricated to a Cavendish Astrophysics Group design at the Delft University of Technology in the Netherlands. Working
in conjunction with the new Auto Correlation Spectral Imaging System (ACSIS), first light with HARP was achieved in
December 2005. HARP synthesizes a number of interesting features across all elements of the design; we present key
performance characteristics and images of astronomical observations obtained during commissioning.
UIST is a facility class near-infrared instrument recently commissioned at the UK Infrared Telescope (UKIRT). UIST provides a comprehensive imaging and spectroscopic facility with spatial resolution limited only by the delivered tip-tilt corrected seeing. In addition to long slit spectroscopic modes, UIST includes the first deployable cryogenic integral field unit in a common user instrument. We will present results obtained during the commissioning period in late 2002. These include measurements of the image quality and the sensitivities of the different observing modes of the instrument. We also discuss the use of an instrument-specific telescope pointing-model developed for UIST to allow the instrument to meet the stringent flexure requirements arising from the choice of 0.06arcsec/pixel and 0.12arcsec/pixel plate scales. We pay particular attention to the performance of the image slicing integral field unit (IFU). We will present astronomical results from the first year of UIST operations, during which time UIST carried out diverse programmes, from mineralogical studies of Mars to measuring the mass of the black hole at the centre of the most distant quasar.
The James Clerk Maxwell Telescope (JCMT), the world's largest sub-mm telescope, will soon be switching operations from a VAX/VMS based control system to a new, Linux-based, Observatory Control System1 (OCS). A critical part of the OCS is the set of tasks that are associated with the observation queue and the observing recipe sequencer: 1) the JCMT observation queue task 2) the JCMT instrument task, 3) the JCMT Observation Sequencer (JOS), and 4) the OCS console task. The JCMT observation queue task serves as a staging area for observations that have been translated from the observer's science program into a form suitable for the various OCS subsystems. The queue task operates by sending the observation at the head of the queue to the JCMT instrument task and then waits for the astronomer to accept the data before removing the observation from the queue. The JCMT instrument task is responsible for running up the set of tasks required to observe with a particular instrument at the JCMT and passing the observation on to the JOS. The JOS is responsible for executing the observing recipe, pausing/continuing the recipe when commanded, and prematurely ending or aborting the observation when commanded. The OCS console task provides the user with a GUI window with which they can control and monitor the observation queue and the observation itself. This paper shows where the observation queue and recipe sequencer fit into the JCMT OCS, presents the design decisions that resulted in the tasks being structured as they are, describes the external interfaces of the four tasks, and details the interaction between the tasks.
The Joint Astronomy Centre (JAC) operates the James Clerk Maxwell Telescope (JCMT), the world's largest sub-mm telescope, and the United Kingdom Infrared Telescope (UKIRT), the world's largest telescope dedicated solely to infrared astronomy. Although these two telescopes investigate different regions of the electro-magnetic spectrum and have different mounting arrangements, the JAC (in collaboration with the Anglo-Australian Observatory) has developed the Portable Telescope Control System (PTCS) software so that it can be used on both JAC telescopes. The benefit of this work is increased efficiency, reduced maintenance time, and reduced personnel costs as a result of using a common code base on both JAC telescopes. During the next year, the PTCS will be enhanced as part of the JCMT Observatory Control System (OCS) project so that configuration information can be transmitted to the PTCS via XML files. This will simplify the PTCS interface and expedite the implementation of the OCS. This paper gives an overview of the PTCS, describes its use on both telescopes, and indicates how XML files will be used to configure the telescope prior to the start of an observation.
The JCMT, the world's largest sub-mm telescope, has had essentially the same VAX/VMS based control system since it was commissioned. For the next generation of instrumentation we are implementing a new Unix/VxWorks based system, based on the successful ORAC system that was recently released on UKIRT.
The system is now entering the integration and testing phase. This paper gives a broad overview of the system architecture and includes some discussion on the choices made. (Other papers in this conference cover some areas in more detail). The basic philosophy is to control the sub-systems with a small and simple set of commands, but passing detailed XML configuration descriptions along with the commands to give the flexibility required. The XML files can be passed between various layers in the system without interpretation, and so simplify the design enormously. This has all been made possible by the adoption of an Observation Preparation Tool, which essentially serves as an intelligent XML editor.
KEYWORDS: Telescopes, Control systems, Gemini Observatory, Observatories, Data storage, Astronomy, Data acquisition, Java, Databases, Software development
The steady improvement in telescope performance at UKIRT and the increase in data acquisition rates led to a strong desired for an integrated observing framework that would meet the needs of future instrumentation, as well as providing some support for existing instrumentation. Thus the Observatory Reduction and Acquisition Control (ORAC) project was created in 1997 with the goals of improving the scientific productivity in the telescope, reducing the overall ongoing support requirements, and eventually supporting the use of more flexibly scheduled observing. The project was also expected to achieve this within a tight resource allocation. In October 1999 the ORAC system was commissioned at the United Kingdom Infrared Telescope.
Access to the requested content is limited to institutions that have purchased or subscribe to SPIE eBooks.
You are receiving this notice because your organization may not have SPIE eBooks access.*
*Shibboleth/Open Athens users─please
sign in
to access your institution's subscriptions.
To obtain this item, you may purchase the complete book in print or electronic format on
SPIE.org.
INSTITUTIONAL Select your institution to access the SPIE Digital Library.
PERSONAL Sign in with your SPIE account to access your personal subscriptions or to use specific features such as save to my library, sign up for alerts, save searches, etc.