Search

IRIS (Infrared Imaging Spectrograph) is the near-infrared (0.84 to 2.4 micron) diffraction-limited imager and Integral Field Spectrograph (IFS) designed for the Thirty Meter Telescope (TMT) and the Narrow-Field Infrared Adaptive Optics System ( NFIRAOS ). The imager will have a 34 arcsec x 34 arcsec field of view with 4 milliarcseconds (mas) pixels. The IFS consists of a lenslet array and slicer, enabling four plate scales from 4 mas to 50 mas, with multiple gratings and filters. We will report the progress on the development of the IRIS Data Reduction System ( DRS ) in the final design phase. The IRIS DRS is being developed in Python with the software architecture based on the James Webb Space Telescope science calibration pipeline. We are developing a library of algorithms as individual Python classes that can be configured independently and bundled into pipelines. We will interface this with the observatory software to run online during observations and we will release the package publicly for scientists to develop custom analyses. It also includes a C library for readout processing to be used for both in real-time processing (e.g., up-the-ramp, MCDS) as well the ability for astronomers to use for offline reduction. Lastly, we will also discuss the development of the IRIS simulation packages that simulate raw spectra and image readout-data from the Hawaii-4RG detectors, which helps in developing reduction algorithms during this design phase., Software and Cyberinfrastructure for Astronomy VI, December 14-18, 2020, Online Only, United States, Series: Proceedings of SPIE

The Thirty Meter Telescope (TMT) is a massive international undertaking with a myriad of software packages delivered by partners around the world. A comprehensive software development process with a focus on quality assurance has been established and agreed to by the partners to ensure a consistent and well-integrated system. Additionally, thorough requirements verification is necessary to ensure the deliverables meet the needs and requirements of the observatory. As software engineering continues to progress, technologies such as cloud-based collaboration tools and automated testing through continuous integration systems have become common place and facilitate the development and verification processes. We describe how TMT leverages the use of modern software development tools and methodologies to promote a cohesive and complete software system, using the recent construction and delivery of TMT Common Software as an example.

The TMT Software System consists of software components that interact with one another through a software infrastructure called TMT Common Software (CSW). CSW defines the types of components in the software system and their functional roles, software services for integrating components, and library code that is used by developers to create the components and subsystems that make up the TMT Software System. The unique features of CSW include the use of multiple, open-source products as the basis of the services, and an approach that works to reduce the amount of CSW-produced infrastructure code. The core of CSW is implemented on the JVM in the Scala programming language with both Java and Scala programming interfaces as well as limited access from C/C++ and Python. The source code for CSW is open source and available on GitHub. TMT CSW has recently completed its construction phase and has been delivered to the project by our India partners. This paper summarizes the technical design, construction process, construction deliverables, changes in the design during implementation, and lessons learned.

The Thirty Meter Telescope (TMT) is a massive international undertaking with a myriad of software packages delivered by partners around the world. The Executive Software (ESW) package is the part of the TMT software system that is responsible for providing unified high-level control of observatory operations. It consists of five parts: a) a Sequencer Component that can be tailored to various sequencing needs by the loading of custom “scripts”, written in a TMT sequencing Domain Specific Language (DSL); b) a collection of these sequencing scripts used for critical observing tasks such as acquisition; c) user interface (UI) infrastructure that provides browser-based UI standards and access to TMT components and services; d) the set of UIs that observatory staff will use during operations to conduct TMT activities such as observing; and e) tools that assist in the visualization of observation data for quality assurance. In this paper, we describe the design of ESW, and give an update on the current status of the package, which is currently under construction.

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). Now approaching the end of its final design phase, we provide an overview of the instrument control software. The design is challenging since IRIS has interfaces with many systems at different stages of development (e.g., NFIRAOS, telescope control system, observatory sequencers), and will be built using the newly-developed TMT Common Software (CSW), which provides framework code (Java/Scala), and services (e.g., commands, telemetry). Lower-level software will be written in a combination of Java and C/C++ to communicate with hardware, such as motion controllers and infrared detectors. The overall architecture and philosophy of the IRIS software is presented, as well as a summary of the individual software components and their interactions with other systems., Comment: 20 pages, 9 figures, SPIE (2020) 11452-28

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. 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.

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 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.

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 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.

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 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.

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 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.

SPIE Astronomical Telescopes + Instrumentation, 2006, Orlando, Florida, United States, Series: Proceedings of SPIE; no. 6270

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.

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, mul-ticonjugate deformable mirror configurations, and integrated adaptive optics/image postprocessing techniques. Adaptive optics sys-tem performance is evaluated in terms of mean optical transfer functions, mean point spread functions, and related quantities. Theseestimates account for the integrated effects of error sources including servo lag, fitting error, sensor noise, and anisoplanatism. Theyare computed using minimal variance wavefront reconstruction algorithms which will optimize system performance for the givenoperating conditions.The graphical user interface for this software package was written using the Tool Command Language, TCL, for UNIX workstations.Features of the interface include input windows for entering adaptive optics system parameters, graphics output illustrating the wavefront sensor, deformable mirror, and guide star geometries specified by the user, and graphics output describing the adaptive opticsperformance estimates computed for the specified system and scenario.