The reality of using other people’s software requires substantial architectural or even hardware buy-in and there is substantial research needed in the field of buy-in software. For example it is not known how the effort to develop buy-in software relates to more sophisticated implementations (for a more in-depth discussion see e.g., Conroy et al., 1998; Mandel and Murray, 1998). The hardware used to control the LT optical camera is required to run on a SUN workstation, and in order to keep the number of different computers at the LT site to a minimum the PL will also be required to operate on a SUN workstation. As will be seen later this has important implications for data input/output.
Controlling complexity is the major problem facing the developers of any analysis system, they must keep tasks, their interfaces and execution environment as simple as possible, to ease modification and adaptability (see Conroy et al., 1998). To avoid a complex system architecture the LT PL is written in a modular manner. In much the same way as the prototype PL was written using several “pipes” that used different packages, the production PL will be written in a modular format, each “module” or “pipe” accomplishing a set task, in such a way as to be transparent to the rest of the PL. In a similar manner each individual pipe will be written in a modular way allowing program subroutines to be upgraded.
The PL’s dynamic parameters (e.g., bias, gain, binning, windowing) are calculated directly from the current dataset and primary FITS file (i.e., the frame currently being reduced). This generic feature allows the PL to be reconfigured (Conroy et al., 1998) for new data sets automatically. This feature also eliminates contradictory data from contaminating the PL.
The LT will have several “modes” of operation, primarily these will be (i) engineering; essentially manual operation, used for commissioning and debugging. (ii) Planetarium; allowing real-time interactive, but distant operation and (iii) Robotic; the telescope’s primary mode giving fully robotic and autonomous operation. The PL will automatically operate on data acquired during Planetarium and Robotic modes, and will have a menu driven semi-autonomous reduction system, allowing more user control, built-in for use in engineering mode.
The purpose of planetarium mode is to be able to observe an object, sufficiently reduce the image to a state where the object is recognisable (e.g., de-bias, flat-field and de-fringe) and enable viewing at a remote location (e.g., Liverpool Museum) in real-time. The transmission of the data is carried out in an electronically compressed form via the internet (see McNerney and Steele, 2000). The online PL will, as a matter of course, perform all necessary reduction required by the planetarium mode.
As a result of collaboration with the LT software design team, it was discovered that a significant degree of overlap between the PL and control software (CS) was planned, as a result it was decided to split the PL into two major pipes, to be called the online pipe-line (Section 5.6) and the off-line pipe-line (see Section 5.7).
This chapter follows the evolution of the production PL from its conception to the finished work, culminating with a demonstration that the results produced are of scientific value. Sections 5.2-5.5 present the necessary information to be considered during the planning of the PL’s infrastructure, with each subsection introducing a new topic. Section 5.6 explains why the PL has been split into two distinct sections, and explains the first of these - the online PL. Finally Section 5.7 details the off-line PL through each of its 3 versions and presents results derived from the PL.
Print
Email
News!