Infrared Imaging Spectrograph (IRIS) is the first light instrument for the Thirty Meter Telescope (TMT) that consists of a near-infrared (0.84 to 2.4 micron) imager and integral field spectrograph (IFS) which operates at the diffraction-limit utilizing the Narrow-Field Infrared Adaptive Optics System (NFIRAOS). The imager will have a 34 arcsec x 34 arcsec field of view with 4 milliarcsecond (mas) pixels. The IFS consists of a lenslet array and slicer, enabling four plate scales from 4 mas to 50 mas, multiple gratings and filters, which in turn will operate hundreds of individual modes. IRIS, operating in concert with NFIRAOS will pose many challenges for the data reduction system (DRS). Here we present the updated design of the real-time and post-processing DRS. The DRS will support two modes of operation of IRIS: (1) writing the raw readouts sent from the detectors and performing the sampling on all of the readouts for a given exposure to create a raw science frame; and (2) reduction of data from the imager, lenslet array and slicer IFS. IRIS is planning to save the raw readouts for a given exposure to enable sophisticated processing capabilities to the end users, such as the ability to remove individual poor seeing readouts to improve signal-to-noise, or from advanced knowledge of the point spread function (PSF). The readout processor (ROP) is a key part of the IRIS DRS design for writing and sampling of the raw readouts into a raw science frame, which will be passed to the TMT data archive. We discuss the use of sub-arrays on the imager detectors for saturation/persistence mitigation, on-detector guide windows, and fast readout science cases (< 1 second).
The InfraRed Imaging Spectrograph (IRIS) is the first-light client instrument for the Narrow Field Infrared Adaptive Optics System (NFIRAOS) on the Thirty Meter Telescope (TMT). IRIS includes three natural guide star (NGS) On-Instrument Wavefront Sensors (OIWFS) to measure tip/tilt and focus errors in the instrument focal plane. NFIRAOS also has an internal natural guide star wavefront sensor, and IRIS and NFIRAOS must precisely coordinate the motions of their wavefront sensor positioners to track the locations of NGSs while the telescope is dithering (offsetting the telescope to cover more area), to avoid a costly re-acquisition time penalty. First, we present an overview of the sequencing strategy for all of the involved subsystems. We then predict the motion of the telescope during dithers based on finite-element models provided by TMT, and finally analyze latency and jitter issues affecting the propagation of position demands from the telescope control system to individual motor controllers.
The TMT Software System consists of software components that interact with one another through a software infrastructure called TMT Common Software (CSW). CSW consists of software services and library code that is used by developers to create the subsystems and components that participate in the software system. CSW also defines the types of components that can be constructed and their roles. The use of common component types and shared middleware services allows standardized software interfaces for the components. <p> </p>A software system called the TMT Interface Database System was constructed to support the documentation of the interfaces for components based on CSW. The programmer describes a subsystem and each of its components using JSON-style text files. A command interface file describes each command a component can receive and any commands a component sends. The event interface files describe status, alarms, and events a component publishes and status and events subscribed to by a component. A web application was created to provide a user interface for the required features. Files are ingested into the software system’s database. The user interface allows browsing subsystem interfaces, publishing versions of subsystem interfaces, and constructing and publishing interface control documents that consist of the intersection of two subsystem interfaces. All published subsystem interfaces and interface control documents are versioned for configuration control and follow the standard TMT change control processes. Subsystem interfaces and interface control documents can be visualized in the browser or exported as PDF files.
IRIS (InfraRed Imaging Spectrograph) is the diffraction-limited first light instrument for the Thirty Meter Telescope (TMT) that consists of a near-infrared (0.84 to 2.4 μm) imager and integral field spectrograph (IFS). The IFS makes use of a lenslet array and slicer for spatial sampling, which will be able to operate in 100’s of different modes, including a combination of four plate scales from 4 milliarcseconds (mas) to 50 mas with a large range of filters and gratings. The imager will have a field of view of 34×34 arcsec2 with a plate scale of 4 mas with many selectable filters. We present the preliminary design of the data reduction system (DRS) for IRIS that need to address all of these observing modes. Reduction of IRIS data will have unique challenges since it will provide real-time reduction and analysis of the imaging and spectroscopic data during observational sequences, as well as advanced post-processing algorithms. The DRS will support three basic modes of operation of IRIS; reducing data from the imager, the lenslet IFS, and slicer IFS. The DRS will be written in Python, making use of open-source astronomical packages available. In addition to real-time data reduction, the DRS will utilize real-time visualization tools, providing astronomers with up-to-date evaluation of the target acquisition and data quality. The quick look suite will include visualization tools for 1D, 2D, and 3D raw and reduced images. We discuss the overall requirements of the DRS and visualization tools, as well as necessary calibration data to achieve optimal data quality in order to exploit science cases across all cosmic distance scales.
TMT Common Software (CSW). CSW consists of software services and library code that is used by developers to create the subsystems and components that participate in the software system. CSW also defines the types of components that can be constructed and their functional roles in the software system. TMT CSW has recently passed its preliminary design review. The unique features of CSW include its use of multiple, open-source products as the basis for services, and an approach that works to reduce the amount of CSW-provided infrastructure code. Considerable prototyping was completed during this phase to mitigate risk with results that demonstrate the validity of this design approach and the selected service implementation products. This paper describes the latest design of TMT CSW, key features, and results from the prototyping effort.
The InfraRed Imaging Spectrograph (IRIS) will be a first-light client instrument for the Narrow Field Infrared Adaptive Optics System (NFIRAOS) on the Thirty Meter Telescope. IRIS includes three configurable tip/tilt (TT) or tip/tilt/focus (TTF) On-Instrument Wavefront Sensors (OIWFS). These sensors are positioned over natural guide star (NGS) asterisms using movable polar-coordinate pick-ofi arms (POA) that patrol an approximately 2-arcminute circular field-of-view (FOV). The POAs are capable of colliding with one another, so an algorithm for coordinated motion that avoids contact is required. We have adopted an approach in which arm motion is evaluated using the gradient descent of a scalar potential field that includes an attractive component towards the goal configuration (locations of target stars), and repulsive components to avoid obstacles (proximity to adjacent arms). The resulting vector field is further modified by adding a component transverse to the repulsive gradient to avoid problematic local minima in the potential. We present path planning simulations using this computationally inexpensive technique, which exhibit smooth and efficient trajectories.
Proc. SPIE. 9913, Software and Cyberinfrastructure for Astronomy IV
KEYWORDS: Observatories, Astronomy, Thirty Meter Telescope, Databases, Data acquisition, Software development, Computer architecture, Computer architecture, Systems modeling, Prototyping, Process engineering
The purpose of the Observatory Software System (OSW) is to integrate all software and hardware components of the Thirty Meter Telescope (TMT) to enable observations and data capture; thus it is a complex software system that is defined by four principal software subsystems: Common Software (CSW), Executive Software (ESW), Data Management System (DMS) and Science Operations Support System (SOSS), all of which have interdependencies with the observatory control systems and data acquisition systems. Therefore, the software development process and plan must consider dependencies to other subsystems, manage architecture, interfaces and design, manage software scope and complexity, and standardize and optimize use of resources and tools. Additionally, the TMT Observatory Software will largely be developed in India through TMT’s workshare relationship with the India TMT Coordination Centre (ITCC) and use of Indian software industry vendors, which adds complexity and challenges to the software development process, communication and coordination of activities and priorities as well as measuring performance and managing quality and risk. The software project management challenge for the TMT OSW is thus a multi-faceted technical, managerial, communications and interpersonal relations challenge. The approach TMT is using to manage this multifaceted challenge is a combination of establishing an effective geographically distributed software team (Integrated Product Team) with strong project management and technical leadership provided by the TMT Project Office (PO) and the ITCC partner to manage plans, process, performance, risk and quality, and to facilitate effective communications; establishing an effective cross-functional software management team composed of stakeholders, OSW leadership and ITCC leadership to manage dependencies and software release plans, technical complexities and change to approved interfaces, architecture, design and tool set, and to facilitate effective communications; adopting an agile-based software development process across the observatory to enable frequent software releases to help mitigate subsystem interdependencies; defining concise scope and work packages for each of the OSW subsystems to facilitate effective outsourcing of software deliverables to the ITCC partner, and to enable performance monitoring and risk management. At this stage, the architecture and high-level design of the software system has been established and reviewed. During construction each subsystem will have a final design phase with reviews, followed by implementation and testing. The results of the TMT approach to the Observatory Software development process will only be preliminary at the time of the submittal of this paper, but it is anticipated that the early results will be a favorable indication of progress.
The software system for TMT is a distributed system with many components on many computers. Each component integrates with the overall system using a set of software services. The Event Service is a publish-subscribe message system that allows the distribution of demands and other events. The performance requirements for the Event Service are demanding with a goal of over 60 thousand events/second. This service is critical to the success of the TMT software architecture; therefore, a project was started to survey the open source and commercial market for viable software products. A trade study led to the selection of five products for thorough testing using a specially constructed computer/network configuration and test suite. The best performing product was chosen as the basis of a prototype Event Service implementation. This paper describes the process and performance tests conducted by Persistent Systems that led to the selection of the product for the prototype Event Service.
Gemini Observatory is using a new approach with instrument software that takes advantage of the strengths of our
instrument builders and at the same time better supports our own operational needs. A lightweight software library in
conjunction with modern agile software development methodologies is being used to ameliorate the problems
encountered with the development of the first and second-generation Gemini instruments.
Over the last two years, Gemini and the team constructing the software for the Gemini Planet Imager (GPI) have been
using an agile development process to implement the Gemini Instrument Application Interface (GIAPI) and the highlevel
control software for the GPI instrument. The GPI is being tested and exercised with the GIAPI, and this has
allowed us to perform early end-to-end testing of the instrument software. Early in 2009 for the first time in our
development history, we were able to move instrument mechanisms with Gemini software during early instrument
construction. As a result of this approach, we discovered and fixed software interface issues between Gemini and GPI.
Resolving these problems at this stage is simpler and less expensive than when the full instrument is completed.
GPI is currently approaching its integration and testing phase, which will occur in 2010. We expect that utilizing this
new approach will yield a more robust software implementation resulting in smoother instrument integration, testing,
and commissioning phases. In this paper we describe the key points of our approach and results of applying the new
instrument API approach together with agile development methodologies. The paper concludes with lessons learned and
suggestions for adapting agile approaches in other astronomy development projects.
The telescope development projects of the 1990's produced a set of capable 8-10m telescopes that are now in operations
across the northern and southern hemispheres. This was the first generation of telescopes to benefit from carefully
engineered software systems, yet several years of 8m operations have revealed weaknesses in a common architecture
employed by many of them. Today engineers are working on the next generation of telescopes, the extremely large
telescopes (ELTs), along with their software systems. It is our view that many of the fundamental assumptions about
how software systems for 8-m class large telescopes should be constructed are not optimal for the next generation of
extremely large telescopes. In fact, these ideas may constrain the solution space and result in overly complex software
and increased development costs. This paper points out issues with current architecture solutions and how they impact
the software needed for extremely large telescopes. It then provides the outline of a new approach for the design of the
software running at the telescope that is targeted towards the development issues of ELTs and large telescope operations.
The challenges facing the developers of user interfaces for astronomy applications has never been greater. Astronomers
and engineers often use well-designed commercial and web applications outside their work environment and have come
to expect a similar user experience with applications developed for their work tasks. The connectivity provided by the
Internet and the ability to work from anywhere can improve user productivity, but it is a challenge to provide the kind of
interactivity and responsiveness needed for astronomical applications to web based projects. It is fair to say that browserbased
applications have not been adequate for many kinds of workhorse astronomy applications. The Flex/Actionscript
framework from Adobe has been used successfully at the Space Telescope Science Institute in a variety of situations that
were not possible with other technologies. In this paper, the Flex framework and technology is briefly introduced
followed by a discussion of its advantages and disadvantages and how it addresses user expectations. Three astronomy
applications will be presented demonstrating the technology capabilities with useful performance data. Flex/Actionscript
is not well known within the astronomy development community, and our goal is to demonstrate that it can be the right
choice for many astronomy applications.
Gemini Observatory is now developing its next generation of astronomical instruments, the Aspen instruments. These
new instruments are sophisticated and costly requiring large distributed, collaborative teams. Instrument software
groups often include experienced team members with existing mature code. Gemini has taken its experience from the
previous generation of instruments and current hardware and software technology to create an approach for developing
instrument software that takes advantage of the strengths of our instrument builders and our own operations needs. This
paper describes this new software approach that couples a lightweight infrastructure and software library with aspects of
modern agile software development. The Gemini Planet Imager instrument project, which is currently approaching its
critical design review, is used to demonstrate aspects of this approach. New facilities under development will face
similar issues in the future, and the approach presented here can be applied to other projects.
The new observatories currently being built, upgraded or designed represent a big step up in terms of complexity (laser
guide star, adaptive optics, 30/40m class telescopes) with respect to the previous generation of ground-based telescopes.
Moreover, the high cost of observing time imposes challenging requirements on system reliability and observing
efficiency as well as challenging constraints in implementing major upgrades to operational observatories. Many of the
basic issues are common to most of the new projects, while each project also brings an additional set of very specific
challenges, imposed by the unique characteristics and scientific objectives of each telescope. Finding ways to share the
solution and the risk for these common problems would allow the teams in the different projects to concentrate more
resources on the specific challenges, while at the same time realizing more reliable and cost efficient systems. In this
paper we analyze the many dimensions that might be involved in sharing and re-using observatory software (e.g.
components, design, infrastructure frameworks, applications, toolkits, etc.). We also examine observatory experiences
and technology trends. This work is the continuation of an effort started in the middle of 2007 to analyze the trends in
software for the control systems of large astronomy projects.
The Gemini Observatories primarily operate a multi-instrument queue, with observers selecting observations that are best suited to weather and seeing conditions. Queue operations give higher ranked programs a greater chance for completion than lower ranked programs requesting the same conditions and instrument configuration. Queue observing naturally lends itself to Target of Opportunity (ToO) support since the time required to switch between programs and instruments is very short, and the staff observer is trained to operate all the available instruments and modes. Gemini Observatory has supported pre-approved ToO programs since beginning queue operations, and has implemented a rapid (less than 15 minutes response time) ToO mode since 2005. We discuss the ToO procedures, the statistics of 2+ years of rapid ToOs at Gemini North Observatory, the science that this important mode has enabled, and some recent software modifications which have improved both standard and rapid ToO support in the Gemini Observing Tool.
The Thirty Meter Telescope (TMT) project is a partnership between the Association of Canadian Universities for Research in Astronomy (ACURA), Associated Universities for Research in Astronomy (AURA), Caltech and the University of California. The complexity of TMT and its diverse suite of instrumentation (many of which will be assisted by adaptive optics front-ends) necessitates the design and implementation of a highly-automated, well-tuned observatory software system. The fundamental system requirements are low operating costs and excellent reliability, both of which necessitate simplicity in software design. This paper will address how these requirements will be achieved as well as how the system will handle observing program execution.
Gamma-ray bursts and other targets of opportunity require a quick response by observers to maximize the significance of observations. Because of this need for quickness, these types of observations are often observed at smaller facilities where observers and institutions have more freedom to respond to serendipitous events. The two Gemini 8-m telescopes have a well-developed workflow for queue observing that allows investigators to be involved in their science program throughout its lifecycle. To coincide with the startup of the Swift Gamma Ray Burst Explorer orbiting observatory in late 2004, the Gemini observing policies, workflow, and observing tools were enhanced to allow investigators to participate in target of opportunity programs. This paper describes how target of opportunity has been integrated into Gemini operations to allow investigators to trigger observations at the Gemini telescopes within minutes of an event.
The software for the Thirty Meter Telescope (TMT) is currently in the specification and design phase. A decision was
made early on to provide a common software package that will provide basic infrastructure and services to be used by all
project software packages. A roadmap for defining Common Software was written. The first roadmap step of defining
what should be included in common software was accomplished by analyzing similar projects. The result was the
definition of a reference architecture for end-to-end observatory software systems called the Observatory Software
Domain Architecture. This architecture was then used to define the specifications for the TMT common software. This
paper describes the roadmap, the reference architecture, and the current definition of TMT common software.
At Gemini, support for observers during Phase 2 is a collaborative effort among individuals spread across four continents at many institutions. Short Phase 2 preparation periods necessitate close communication between observers and support personnel. Email alone has not been an adequate solution. For the 2003B semester, the Gemini Observing Tool has been extended to allow off-site investigators and national project office support personnel to directly access the science program database. The observer is able to keep up to date with changes by accessing his program at any time. Email notifications are generated automatically when activities occur in the science program lifecycle. This paper will give an overview of how this system, based upon Java and freely available open source software, provides these new capabilities.
Processing astronomical images is an inherently resource intensive procedure that is typically time consuming as well. At the same time, first order reductions are particularly important during the observing process since they can provide key quality assessment information. To resolve this conflict, the Online Data Processing (OLDP) system being commissioned at the Gemini Observatory automatically maps reduction sequences onto a cluster of servers during observing, taking advantage of available concurrency where possible. The user constructs a visual representation of the sequence for an observation using the Gemini Observing Tool. No constraints are placed upon the series of steps that comprise the sequence. At runtime, the OLDP reads the reduction sequence from the Observing Database and splits it into smaller pieces for simultaneous execution on the cluster. Recipe steps can be implemented in IRAF, shell scripts, or Java, and other types can be plugged into the architecture without modifying the core of the code base. This paper will introduce the Gemini OLDP and demonstrate how it utilizes modern infrastructure technology like Jini and JavaSpaces to achieve its goals.
Today's astronomers may use the telescopes and instruments of many observatories to execute their science observations. Discovering the distributed resources that are available is time consuming and error prone because astronomers must manually take facility information and match it to the needs of their science observations. While Phase 1 and Phase 2 of the
proposal process are well supported by a wide variety of software tools, the initial phase of discovering what resources are available, Phase 0, suffers from a lack of software support. This paper describes and proposes the creation of a Phase 0 Network to fill this void. The network is built upon peer-to-peer (P2P) technology, showing that this new approach to distributed computing has viable uses in astronomy.
Construction of the first Gemini 8-m telescope is well underway. The software that provides the user interface and high-level control of the observatory, the observatory control system (OCS), is also proceeding on track. The OCS provides tools that assist the astronomer from the proposal submission phase through planning, observation execution, and data review. A capable and flexible software infrastructure is required to support this comprehensive approach. New software technologies and industry standards have played a large part in the implementation of this infrastructure. For instance, the use of CORBA has provided many benefits in the software including object distribution, an interface definition language, and implementation language independence. In this paper, we describe the infrastructure of the OCS that supports observation planning and execution. Important software decisions and interfaces that allow Internet access and the ability to substitute alternate implementations easily are discussed as a model for other similar projects.
A discussion of the interactive operator user interface developed for the Gemini 8-m Telescopes is presented. Topics include the use of a layered synthesized view of the area of interest on the sky, a data driven approach to the control of the subsystems, and an adaptive view on the health of those subsystems. The synthesized view utilizes information from pre-existing databases; guide, wavefront and scientific detector image data; as well as operating and performance limits. This information is presented to the user in layers, with each layer containing an observer, subsystem or other logically oriented view. The ability to control which layers are presented, as well as which parameters are directly modifiable is vested in both the user and the configuration software. Implementing this above a data driven control interface encourages the use of observing templates. Exhaustive parameter control with parallel realization in the lower level mechanisms results in fast, fine grained and repeatable control. Combining the major control interfaces, each with a different view of the desired behavior, error in behavior, and possible corrections allows the operator to spend more time optimizing observations, rather than setting up equipment. Maximizing time with quality light falling on the science detectors is a primary goal.
The new 8-meter class telescopes represent large investments by the development communities. This means that these telescopes must be operated efficiently to provide the best possible return on these investments and a great deal of effort has been made to provide control software that supports effective use of the telescopes. However, efficient use must be more than just keeping the telescopes operating; it is important that observers be provided tools that enable them work effectively. The Gemini 8 m Telescopes have developed a strategy for helping astronomers plan observations through the design of science programs. While there are a number of unique aspects to this strategy, this paper focuses on the methods used as the foundation for connecting astronomers to the facilities of the observatories during the design of science programs. The methods under development take advantage of emerging Internet technologies to help reduce the maintenance issues normally associated with supporting remote sites, while freeing users from many of the performance problems associated with web-based solutions.
The processing of high-level system commands within an experimental physics and industrial control system (EPICS) database application shares many issues with the design of EPICS motor control records in that the traditional synchronous/asynchronous record processing model is not adhered to. This paper presents the design of the Gemini CAD (command action directive) and CAR (command action response) EPICS database records and illustrates their use in a telescope mount control context dealing with the handling of repeated offset and slew commands.
During 1993 we have upgraded our adaptive optics analysis software package to execute under an interactive, graphical user interface. This software may be used to evaluate a wide range of adaptive optics concepts, including constellations of multiple guide stars, multiconjugate deformable mirror configurations, and integrated adaptive optics/image postprocessing techniques. Adaptive optics system performance is evaluated in terms of mean optical transfer functions, mean point spread functions, and related quantities. These estimates account for the integrated effects of error sources including servo lag, fitting error, sensor noise, and anisoplanatism. They are computed using minimal variance wavefront reconstruction algorithms which will optimize system performance for the given operating conditions.