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

SOXS (Son Of X-Shooter) is a forthcoming instrument for ESO-NTT, mainly dedicated to the spectroscopic study of transient events and is currently starting the AIT (Assembly, Integration, and Test) phase. It foresees a visible spectrograph, a near-Infrared (NIR) spectrograph, and an acquisition camera for light imaging and secondary guiding. The optimal setup and the monitoring of SOXS are carried out with a set of software-controlled motorized components and sensors. The instrument control software (INS) also manages the observation and calibration procedures, as well as maintenance and self-test operations. The architecture of INS, based on the latest release of the VLT Software (VLT2019), has been frozen; the code development is in an advanced state for what concerns supported components and observation procedures, which run in simulation. In this proceeding we present the INS current status, focusing in particular on the ongoing efforts in the support of two non-standard, "special" devices. The first special device is the piezoelectric slit exchanger for the NIR spectrograph; the second special device is the piezoelectric tip-tilt corrector used for active compensation of mechanical flexures of the instrument., 8 pages, 4 figures

The forthcoming SOXS (Son Of X-Shooter) will be a new spectroscopic facility for the ESO New Technology Telescope in La Silla, focused on transient events and able to cover both the UV-VIS and NIR bands. The instrument passed the Final Design Review in 2018 and is currently in manufacturing and integration phase. This paper is focused on the assembly and testing of the instrument control electronics, which will manage all the motorized functions, alarms, sensors, and electric interlocks. The electronics is hosted in two main control cabinets, divided in several subracks that are assembled to ensure easy accessibility and transportability, to simplify test, integration and maintenance. Both racks are equipped with independent power supply distribution and have their own integrated cooling systems. This paper shows the assembly strategy, reports on the development status and describes the tests performed to verify the system before the integration into the whole instrument.

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)., 14 pages, 5 figures, 6 tables, Proceeding 10707-112 of the SPIE Astronomical Telescopes + Instrumentation 2018

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., 21 pages, 19 figures, SPIE (2018) 10707-49

We present design considerations and a prototyping progress report for a low-level monitor and control communication system designed to operate on the Stratix-10 System on a Chip (SoC) Field Programmable Gate Array (FPGA) equipped with a Hard Processor System (HPS). The goal of this activity is to allow remote clients to use high level communication protocols (ie. TANGO) to access IP blocks within a Stratix-10 FPGA chip by taking advantage of very low latency communication between HPS and the FPGA fabric, eliminating the need to implement Ethernet protocols within the FPGA logic., Software and Cyberinfrastructure for Astronomy V, June 10-15, 2018, Austin, TX, USA, Series: Proceedings of SPIE; no. 10707

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.

The international Square Kilometre Array (SKA) project to build two radio interferometers is approaching the end of its design phase, and gearing up for the beginning of formal construction. A key part of this distributed Observatory is the overall software control system: the Telescope Manager (TM). The two telescopes, a Low frequency dipole array to be located in Western Australia (SKA-Low) and a Mid-frequency dish array to be located in South Africa (SKA-Mid) will be operated as a single Observatory, with its global headquarters (GHQ) based in the United Kingdom at Jodrell Bank. When complete it will be the most powerful radio observatory in the world. The TM software must combine the observatory operations based at the GHQ with the monitor and control operations of each telescope, covering the range of domains from proposal submission to the coordination and monitoring of the subsystems that make up each telescope. It must also monitor itself and provide a reliable operating platform. This paper will provide an update on the design status of TM, covering the make-up of the consortium delivering the design, a brief description of the key challenges and the top level architecture, and its software development plans for tackling the construction phase of the project. It will also briefly describe the consortium’s response to the SKA Project’s decision in the second half of 2016 to adopt the processes set out by the Software Engineering Institute (SEI) for system architecture design and documentation, including a re-evaluation of its deliverables, documentation and approach to internal reviews., Software and Cyberinfrastructure for Astronomy V, June 10-15, 2018, Austin, USA, Series: Proceedings of SPIE; no. 10707

SOXS (Son Of X-Shooter) is a new spectrograph for the ESO NTT telescope, currently in the final design phase. The main instrument goal is to allow the characterization of transient sources based on alerts. It will cover from near-infrared to visible bands with a spectral resolution of $R \sim 4500$ using two separate, wavelength-optimized spectrographs. A visible camera, primarily intended for target acquisition and secondary guiding, will also provide a scientific "light" imaging mode. In this paper we present the current status of the design of the SOXS instrument control software, which is in charge of controlling all instrument functions and detectors, coordinating the execution of exposures, and implementing all observation, calibration and maintenance procedures. Given the extensive experience of the SOXS consortium in the development of instruments for the VLT, we decided to base the design of the Control System on the same standards, both for hardware and software control. We illustrate the control network, the instrument functions and detectors to be controlled, the overall design of SOXS Instrument Software (INS) and its main components. Then, we provide details about the control software for the most SOXS-specific features: control of the COTS-based imaging camera, the flexures compensation system and secondary guiding., 8 pages, 5 figures

Software and Cyberinfrastructure for Astronomy V : [Proceedings] - SPIE, 2018. - ISBN:9781510619678 ISBN:9781510619685(electronic) - doi:10.1117/12.2313437 Software and Cyberinfrastructure for Astronomy V, Austin, United States, 10 Jun 2018 - 13 Jun 2018; Proceedings of SPIE 10707, 107070D (2018). doi:10.1117/12.2313437, The Cherenkov Telescope Array (CTA) will be the next-generation ground-based instrument for detecting veryhigh energy gamma rays. It will consist of roughly 100 telescopes of different sizes and designs. In addition, a variety of auxiliary instrumentation will be part of the array. The Observation Execution System (OES) is the software system in charge of operating and monitoring all telescopes and devices, applying short-term observation schedules depending on the hardware status and environmental conditions and handling the data. Motivated by the wealth of tasks to accomplish and requirements to fulfil, a software development procedure is conceived for the development of OES. Part of this development process is the application of software testing procedures. These procedures range from unit tests up to system tests and stress tests. In this contribution, the software development process and the application of static and dynamic code analysis tools are described., Published by SPIE, Bellingham, Wash.

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

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.

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