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.

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.

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

This paper describes how we have sustained the Montage image mosaic engine (http://montage.ipac.caltech.edu) first released in 2002, to support the ever-growing scale and complexity of modern data sets. The key to its longevity has been its design as a toolkit written in ANSI-C, with each tool performing one distinct task, for easy integration into scripts, pipelines and workflows. The same code base now supports Windows, JavaScript and Python by taking advantage of recent advances in compilers. The design has led to applicability of Montage far beyond what was anticipated when Montage was first built, such as supporting observation planning for the JWST. Moreover, Montage is highly scalable and is in wide use within the IT community to develop advanced, fault-tolerant cyber-infrastructure, such as job schedulers for grids, workflow orchestration, and restructuring techniques for processing complex workflows and pipelines.

Construction of the Large Synoptic Survey Telescope system involves several different organizations, a situation that poses many challenges at the time of the software integration of the components. To ensure commonality for the purposes of usability, maintainability, and robustness, the LSST software teams have agreed to the following for system software components: a summary state machine, a manner of managing settings, a flexible solution to specify controller/controllee relationships reliably as needed, and a paradigm for responding to and communicating alarms. This paper describes these agreed solutions and the factors that motivated these.

The Large Synoptic Survey Telescope (LSST) will be an 8.4m optical survey telescope sited in Chile and capable of imaging the entire sky twice a week. The data rate of approximately 15TB per night and the requirements to both issue alerts on transient sources within 60 seconds of observing and create annual data releases means that automated data management systems and data processing pipelines are a key deliverable of the LSST construction project. The LSST data management software has been in development since 2004 and is based on a C++ core with a Python control layer. The software consists of nearly a quarter of a million lines of code covering the system from fundamental WCS and table libraries to pipeline environments and distributed process execution. The Astropy project began in 2011 as an attempt to bring together disparate open source Python projects and build a core standard infrastructure that can be used and built upon by the astronomy community. This project has been phenomenally successful in the years since it has begun and has grown to be the de facto standard for Python software in astronomy. Astropy brings with it considerable expectations from the community on how astronomy Python software should be developed and it is clear that by the time LSST is fully operational in the 2020s many of the prospective users of the LSST software stack will expect it to be fully interoperable with Astropy. In this paper we describe the overlap between the LSST science pipeline software and Astropy software and investigate areas where the LSST software provides new functionality. We also discuss the possibilities of re-engineering the LSST science pipeline software to build upon Astropy, including the option of contributing affliated packages.

Collaborative research/computing environments are essential for working with the next generations of large astronomical data sets. A key component of them is a distributed storage system to enable data hosting, sharing, and publication. VOSpace is a lightweight interface providing network access to arbitrary backend storage solutions and endorsed by the International Virtual Observatory Alliance (IVOA). Although similar APIs exist, such as Amazon S3, WebDav, and Dropbox, VOSpace is designed to be protocol agnostic, focusing on data control operations, and supports asynchronous and third-party data transfers, thereby minimizing unnecessary data transfers. It also allows arbitrary computations to be triggered as a result of a transfer operation: for example, a file can be automatically ingested into a database when put into an active directory or a data reduction task, such as Sextractor, can be run on it. In this paper, we shall describe the VOSpace implementations that we have developed for the NOAO Data Lab. These offer both dedicated remote storage, accessible as a local file system via FUSE, and a local VOSpace service to easily enable data synchronization.

At IPAC/Caltech, we have developed the Firefly web archive and visualization system. Used in production for the last eight years in many missions, Firefly gives the scientist significant capabilities to study data. Firefly provided the first completely web based FITS viewer as well as a growing set of tabular and plotting visualizers. Further, it will be used for the science user interface of the LSST telescope which goes online in 2021. Firefly must meet the needs of archive access and visualization for the 2021 LSST telescope and must serve astronomers beyond the year 2030. Recently, our team has faced the fact that the technology behind Firefly software was becoming obsolete. We were searching for ways to utilize the current breakthroughs in maintaining stability, testability, speed, and reliability of large web applications, which Firefly exemplifies. In the last year, we have ported the Firefly to cutting edge web technologies. Embarking on this massive overhaul is no small feat to say the least. Choosing the technologies that will maintain a forward trajectory in a future development project is always hard and often overwhelming. When a team must port 150,000 lines of code for a production-level product there is little room to make poor choices. This paper will give an overview of the most modern web technologies and lessons learned in our conversion from GWT based system to React/Redux based system.

The NOAO Data Lab aims to provide infrastructure to maximize community use of the high-value survey datasets now being collected with NOAO telescopes and instruments. As a science exploration framework, the Data Lab allow users to access and search databases containing large (i.e. terabyte-scale) catalogs, visualize, analyze, and store the results of these searches, combine search results with data from other archives or facilities, and share these results with collaborators using a shared workspace and/or data publication service. In the process of implementing the needed tools and services, specific science cases are used to guide development of the system framework and tools. The result is a Year-1 capability demonstration that (fully or partially) implements each of the major architecture components in the context of a real-world science use-case. In this paper, we discuss how this model of science-driven development helped us to build a fully functional system capable of executing the chosen science case, and how we plan to scale this system to support general use in the next phase of the project.

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.

The Narrow Field Infrared Adaptive Optics System (NFIRAOS) is the first light Adaptive Optics (AO) system for the Thirty Meter Telescope (TMT). A critical component of NFIRAOS is the Real-Time Controller (RTC) subsystem which provides real-time wavefront correction by processing wavefront information to compute Deformable Mirror (DM) and Tip/Tilt Stage (TTS) commands. The National Research Council of Canada - Herzberg (NRC-H), in conjunction with TMT, has developed a preliminary design for the NFIRAOS RTC. The preliminary architecture for the RTC is comprised of several Linux-based servers. These servers are assigned various roles including: the High-Order Processing (HOP) servers, the Wavefront Corrector Controller (WCC) server, the Telemetry Engineering Display (TED) server, the Persistent Telemetry Storage (PTS) server, and additional testing and spare servers. There are up to six HOP servers that accept high-order wavefront pixels, and perform parallelized pixel processing and wavefront reconstruction to produce wavefront corrector error vectors. The WCC server performs low-order mode processing, and synchronizes and aggregates the high-order wavefront corrector error vectors from the HOP servers to generate wavefront corrector commands. The Telemetry Engineering Display (TED) server is the RTC interface to TMT and other subsystems. The TED server receives all external commands and dispatches them to the rest of the RTC servers and is responsible for aggregating several offloading and telemetry values that are reported to other subsystems within NFIRAOS and TMT. The TED server also provides the engineering GUIs and real-time displays. The Persistent Telemetry Storage (PTS) server contains fault tolerant data storage that receives and stores telemetry data, including data for Point-Spread Function Reconstruction (PSFR).

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