1. November 1994: Instrument PDR 2. November 1995: Mechanical/Electrical/Optical CDR 3. March 1996: Software PDR 4. April 1996: Mechanical/Optical Structure Review 5. mid-1996: CCD Detectors/Controllers Review 6. late-1996: Flexure Compensation & TV Guider Review 7. late-1996: Software CDRWhile the November 1994 review contained a brief section on software, the two reviews held to date have focused primarily on optical/mechanical design and fabrication issues. The primary purpose of this review is to verify that the overall software functional requirements for DEIMOS are understood and that a preliminary design exists which meets those requirements. Other items to be evaluated by this review include:
This review is intended to be as thorough a discussion of the topics presented here as is possible before we start expending significant labor on detailed design, evaluation of software and hardware tools, and extensive testing of prototypes. Advice from the review committee (and other reviewers) will be used as much as possible in the selection and evaluation of tools and in the detailed design effort. The detailed design for those subsystems discussed today will be reviewed at the software CDR (review 7) to be held late this year, along with the designs for those subsystems whose preliminary software reviews have been deferred to reviews 5 and 6.
Major purchases of computing hardware and software tools and major expenditure of labor for software implementation will begin in early 1997, following the software CDR. In establishing priorities for completion of the various major components of the DEIMOS software, we have identified the following six target dates:
A. Spring 1997: Test readout of partial CCD mosaic B. Summer 1997: Start of instrument integration in Lick Labs C. Spring 1998: Begin DEIMOS commissioning at Keck D. Summer 1998: Begin DEIMOS science observations at Keck E. Summer 1999: Observing + 1 year: complete first round software upgrades F. Summer 2000: Observing + 2 years: complete final upgrades; release public dataIn establishing these dates, we make explicit our intention that the DEIMOS software development effort will not cease with delivery of the instrument to Hawaii in early 1998. Rather, it will continue for up to two more years, ramping down to final completion in mid-2000. Our software schedule and budget (presented in Chapter 12) reflects this plan. In describing the various software components reviewed here, we have attempted to identify which portions are needed at each of the target dates.
DEIMOS is planned as a dual-beam instrument, but due to current funding limitations only one beam will be built for first light. When additional funding becomes available, the second beam will be built here and installed in Hawaii. Since both beams are nearly identical, construction of the second beam primarily involves duplication of the hardware and software developed for the first beam. Those features of the control software which are either unique to the second beam, or involve interactions between the two beams, will be included in our initial one-beam detailed software design effort, but their implementation will probably be deferred until the funding for the second beam is secured. If such funding is secured in time, implementation of the software for the second beam would be included in the first round of DEIMOS software upgrades planned for Summer 1999.
The remainder of this chapter describes our primary assumptions and our software design philosophy, and identifies the major challenges to be tackled. The remaining chapters are organized as follows:
DEIMOS, like HIRES, MOS, and most of the Keck-I instruments and telescope control system, will employ a keyword-based methodology for instrument control and status monitoring, and will make use of the existing Keck Tasking Library (KTL) mechanisms to implement the DEIMOS keyword library. (Note: KTL keywords, also sometimes referred to as KICS keywords, represent a special subset of FITS keywords. While both are similar in appearance, KTL keywords are mapped to specific actions or states in the KICS control system; writing to a KTL keyword can command an action, such as moving a filter wheel, while reading a KTL keyword can return the current status of a device, such as the current position of that filter wheel. While both FITS keywords and KTL keywords can be recorded in a FITS header, only KTL keywords are mapped to actions or states in the control system.) This methodology will be discussed in greater detail in subsequent chapters (particularly chapter 4), and is documented in a series of Keck Software Documents (KSD numbers 8, 28, and 46) which are available on-line to selected sites from the Keck World-Wide Web server (http://www.keck.hawaii.edu:8080/kroot/doc/ksd/doc_numbers.html). The provision of a keyword-based interface to control DEIMOS is in fact a mandated Keck II software requirement, and one with which we are quite pleased to comply.
In addition to adopting much of the software model and libraries used successfully to implement the HIRES and MOS systems, we plan to adopt as much existing software as is practical from a variety of different sources. Many of the user-interface (UI) forms-based tools that will be developed as part of the information management component of the DEIMOS software will be derived directly from existing tools developed at Lick for various administrative applications and catalog search utilities. The DEIMOS slit mask design software package will be derived from a similar package developed at Lick for design of slit masks for LRIS. We are also looking into use of publicly available tools developed by outside sites, including the real-time image display tool developed at ESO for use in displaying images from the guide camera. In terms of quick-look data reduction, we anticipate heavy use of relevant portions of the IRAF package.
In addition, relying on non-proprietary software avoids the problems associated with initial licensing costs and maintenance agreements, and relieves us of limitations on our ability to share our software with other sites. Since several of the DEIMOS software components (e.g., mask design software, or any components required to support remote observing) will need to be made available to observers at a variety of sites, this is a significant concern. Finally, it avoids the unpleasant situation where a commercial product's license-key expires or a license server develops problems during the middle of the night when vendors of such proprietary software are usually not available to provide assistance. Avoiding commercially-licensed software that is keyed to a particular host also means that any other host of like architecture can serve as backup for any critical software component.
Toward this end, we plan to do the bulk of our software development using non-commercial tools, including the GNU compilers and make facilities, and RCS (or RCS-based) systems for code management. In terms of GUI development, Tcl/Tk and related packages will be our primary development tool. IRAF, its associated layered packages, and certain of its specific algorithms, will form the core of the DEIMOS quick look and data reduction software. Although we are still evaluating several alternatives, we hope to select (and adapt) an image display server from among several non-commercial alternatives, including SAOtng, Keck figdisp, and the ESO real-time display. (A demonstration of the ESO real-time display will be provided at the PDR.)
This PDR document represents our first effort at documenting a major software project in this fashion, and we are still working to develop a consistent style and nomenclature (as should be obvious from the format of this document)! However, we see tremendous advantages to this approach, in that it will make our documentation available on-line to remote sites such as observers' home institutions.
It is also worth noting that this approach does not preclude the use of proprietary packages, such as FrameMaker, which can optionally provide built-in translators for converting their internal formats to HTML. Thus, other components (e.g., optical and mechanical design reports) of the DEIMOS documentation which have already been prepared with FrameMaker can automatically be converted to HTML, if and when such conversion is deemed necessary. Publications support staff who are not fluent in HTML but who are experienced in using existing commercial products such as Framemaker can continue to use these products to prepare DEIMOS documents. Those documents can then automatically be rendered into HTML as needed.
Second, given the extremely rapid pace of improvements in computing technology, it is unclear today which vendor will provide the most cost-effective and practical solution to meet the DEIMOS computing requirements. Given the massive size of the DEIMOS images (64 megapixels per exposure per beam), the instrument computers will need to have as much processing power as we can reasonably afford. Accordingly, we plan to defer the purchase of major computing equipment for DEIMOS as long as possible, in order to obtain the most capable machine within the constraints of our budget. This means that we will start to develop software before the choice of specific machine architecture and operating system is known, and thus we need to provide for multiple architecture and operating support from the start.
Third, given that we intend significant portions of the DEIMOS software suite to be exportable to observers' home institutions, we need to provide support for a reasonable variety of machine architectures and operating systems. However, we do not intend to develop and test for every conceivable combination of architecture and operating system, only for those which we consider to be the likely choices for DEIMOS or those likely to be in use at observers' home institutions. Initially, we will develop for the following two combinations, since we have such platforms already available at Lick.
A final reason for developing and testing DEIMOS code on at least two different platforms is that it often shows up subtle bugs or portability problems. The Dec-Alpha architecture is particularly good at finding non-portable constructs involving imprecise usage of and/or mingling of pointers with integers.
For this strategy to be successful, one needs to have existing development platforms that are sufficient to the requirements of the instrument. Given the massive size of the DEIMOS mosaic images, we will clearly need development machines with several hundred MB of RAM and tens of gigabytes of disk. We have recently acquired a Dec-Alpha machine providing most of this capability. The funding for this machine was primarily from non-DEIMOS sources, with DEIMOS purchasing only some expansion RAM. The DEIMOS software team will have primary use of this machine during the day, and it will be used for data reduction during the evening. Thus, we have assembled a viable Dec-Alpha platform, while conserving the bulk of our DEIMOS instrument computer funds. We will probably take a similar approach towards configuring an interim Sun-Sparc development platform. When the time comes to purchase the DEIMOS instrument computer for Keck, the expansion RAM (and disk) from the interim development platform of the matching architecture will (we hope) be transferable to the machine that is shipped to Keck.
There are also cases where coordination may involve observers who are both working locally at the telescope, but at different locations within the dome. For example, during initial instrument shakedown or even during routine set-up, one observer may be in the control room giving commands, while another observer or technician is out in the dome adjacent to the instrument, watching to see if the instrument actually rotates or if the hatch opens or closes. The observer in the dome will want to watch what commands the downstairs observer is issuing. Alternatively, the technician next to the instrument may want to give commands to move the guider TV stage and visually verify stage motion, while the observer in the control room monitors this sequence of commands and correlates these with what is observed on the control room's video display for the guide TV camera.
The control system that we developed for HIRES provides nearly all of this functionality, and we hope to improve upon it for DEIMOS by insuring that all observers get a clearer view of each other's actions, and by providing remote observers with more direct access to CCD images as they are being read out of the detectors. For controlling the instrument locally from the Nasmyth platform, we plan to provide not only local manual control paddles for low-level maintenance operations, but also a portable X terminal on a rolling cart (or an X-capable hand-held/laptop computer) adjacent to the instrument, from which the standard user interfaces can be run during installation and checkout of slitmasks, filters, and gratings. During normal observing, this terminal would be turned off to avoid heat and light pollution into the dome.