From fa080de7afc95aa1c19a6e6fc0e0708ced2eadc4 Mon Sep 17 00:00:00 2001 From: Joseph Hunkeler Date: Wed, 8 Jul 2015 20:46:52 -0400 Subject: Initial commit --- doc/iraf.ms | 1779 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1779 insertions(+) create mode 100644 doc/iraf.ms (limited to 'doc/iraf.ms') diff --git a/doc/iraf.ms b/doc/iraf.ms new file mode 100644 index 00000000..26f28220 --- /dev/null +++ b/doc/iraf.ms @@ -0,0 +1,1779 @@ +.pl 8.5i +.nr PS 11 +.nr VS 12 +.nr PD 1v +.nr PO 0.875i +.nr LL 9.215i +.nr HM 0.5i +.nr FM 0.5i +.de CH +.. +.LP +.TL +The IRAF Data Reduction and Analysis System +.AU +Doug Tody +.AI +National Optical Astronomy Observatories +P.O. Box 26732, Tucson, Arizona, 85726 +.AB +.ti 0.75i +The Image Reduction and Analysis Facility (IRAF) is a general purpose +software system for the reduction and analysis of scientific data. +The IRAF system provides a good selection of programs for general image +processing and graphics applications, plus a large selection of programs +for the reduction and analysis of optical astronomy data. The system also +provides a complete modern scientific programming environment, making it +straightforward for institutions using IRAF to add their own software to +the system. Every effort has been made to make the system as portable +and device independent as possible, so that the system may be used on a +wide variety of host computers and operating systems with a wide variety +of graphics and image display devices. +.AE +.LP + +.ce +\fB1. Introduction\fR +.PP +The IRAF project began in earnest in the fall of 1981 at Kitt Peak National +Observatory (NOAO did not yet exist at that time). The preliminary design of +the system was completed early in 1982, and the first versions of the command +language (CL) and the applications programming environment were completed +during 1982. The NOAO IRAF programming group was formed in 1983. The first +internal release of the system occurred at NOAO in 1984, and a beta release +of the system to a few outside sites occurred in 1985. +.PP +The Space Telescope Science Institute (STScI) selected IRAF to host their +Science Data Analysis System (SDAS) in December of 1983, and carried out the +initial port of IRAF to VMS, as well as some CL extensions, during 1984 and +1985. In June of 1985, UNIX/IRAF became the primary reduction and analysis +facility at NOAO/Tucson. By October the VMS version of the system was fully +functional at NOAO on the newly installed VAX 8600, which soon became our +primary data processing system. By late 1985 the system had been ported to +such disparate systems as +a Sun workstation running UNIX and to a Data General MV/10000 running AOS/VS +(the latter port was still in progress when this paper was written and was +being undertaken by Steward Observatory, Univ. of Arizona). In February of +1986 a limited public release of the system occurred, with UNIX and VMS +versions of the system being distributed to about 40 astronomical sites. +The system is expected to be made generally available sometime in 1987. +.PP +This paper describes the system as it existed in March of 1986, shortly after +the first public release. The focus of the paper is primarily on the IRAF +system software as seen by the user and by the software developer, although +the NOAO science applications software is briefly introduced. The distinction +is made because the IRAF system software is expected to be used by numerous +institutions to host the science software developed independently by each +institution. The NOAO and STScI science software packages are the first +examples of this; similar undertakings are already in progress, and more are +expected in the future as the system becomes more mature and more widely used. +These science software systems are major projects in their own right and are +best described elsewhere. +.PP +The purpose of this document is to present an overview of the IRAF system +from the system designer's point of view. After a brief discussion of the +global system architecture, we take a tour through the system, starting at +the user level and working down through the programming environments and +the virtual operating system, and ending with the host system interface. +The emphasis is on the system design, on the functionality provided by the +various subsystems, and on the reasoning which went into the design. +The reader is assumed to be familiar with the technology and problems +associated with large software systems and large software development projects. + +.sp +.ce +\fB2. System Architecture\fR +.SH +2.1 Major System Components +.PP +The major components of the IRAF system are outlined in Figure 1. +The \fBcommand language\fR, or CL, is the user's interface to IRAF. +The CL is used to run the \fBapplications programs\fR, which are grouped +into two classes, the system utilities and the scientific applications programs. +Both the CL and all standard IRAF applications programs depend upon the +facilities of the IRAF \fBvirtual operating system\fR (VOS) for their +functioning. The VOS in turn depends upon the \fBkernel\fR, the runtime +component of the host system interface (HSI), for all communications with +the host system. All software above the host system interface is completely +portable to any IRAF host, i.e., to any system which implements the HSI. +The system is ported by implementing the HSI for the new host; note that +the effort required to port the system is independent of the amount of code +above the HSI, and once the system is in place no additional effort is +required to port new applications software. + +.KS +.TS +center; +l l. +Command Language (CL) user interface, command interpreter +Applications Programs system utilities, scientific applications programs +Virtual Operating System (VOS) the system libraries, all i/o interfaces +Host System Interface (HSI) bootstrap utilities, \fBkernel\fR primitives +.TE +.ce +Figure 1. Major System Components +.KE +.PP +From the point of view of the system structure, the CL is itself an +applications program in that it uses only the facilities provided by the +IRAF VOS. In principle an applications program can do anything the CL +can do, and multiple command languages can coexist within the same system. +In practice only the CL is allowed to interact directly with the user +and spawn subprocesses, in order to provide a uniform user interface, +and to minimize the kernel facilities required to run an applications +program. All standard IRAF applications programs can be run directly at +the host system level as well as from the CL, making it possible to run +the science software on a batch oriented system which is incapable of +supporting the CL. +.SH +2.2 Process Structure +.PP +In normal interactive use IRAF is a multiprocess system. The standard +process structure is depicted in Figure 2. The CL process handles all +communications to the user terminal, which is usually a graphics terminal +of some sort. All applications programs run as concurrent subprocesses of +the CL process. A single applications process will usually contain many +executable programs or compiled \fBtasks\fR; the CL maintains a +\fBprocess cache\fR of connected but idle (hibernating) subprocesses to +minimize the process spawn overhead. +If graphics i/o to a device other than the graphics terminal is necessary, +a graphics kernel process is connected to the CL as a subprocess. +.PP +The process cache always contains the process "x_system.e", which contains all +the tasks in the \fBsystem\fR package. The system subprocess is locked in the +cache by default. The remaining process cache slots (typically 2 or 3 slots) +are dynamically assigned as tasks are run by the user. Up to 3 graphics kernels +may be simultaneously connected. The entire process structure is duplicated +when a background job is submitted by the user from an interactive CL. + +.KS +.PS +box "CL"; line <->; box dashed "GIO" "subkernel" +line <-> down at 1st box.s +box width 1.2i "applications" "process" +.PE +.ce +Figure 2. IRAF Process Structure +.KE +.PP +The multiprocess architecture has significant \fBflexibility advantages\fR +over the alternative single process and chained process architectures. +The system is highly modular and easily extended, allowing new versions of +the CL or a new graphics kernel to be tested or installed even while the +system is in use, without having to relink all the applications modules. +New applications modules can be debugged outside the normal CL environment +using host system facilities, and then installed in the system while the +system is in use without any affect on the rest of the system. There is no +limit to the number of applications packages which the system can support, +nor is there any limit to the number of graphics devices which the system +can be interfaced to. Support for a new graphics device can be added to a +running system without any affect on the existing applications programs. +.PP +The multiprocess architecture also has significant \fBefficiency advantages\fR +over less modular architectures. Since most of the system software resides in +independent processes, the amount of code which has to be linked into an +applications program is minimized, reducing the link time as well as the +disk and memory requirements for an executable. Since all users on a multiuser +system use the same CL executable, graphics kernels, and other system +executables, significant savings in physical memory are possible by employing +shared memory access to the executables. The ability of IRAF to link many +tasks into a single executable promotes code sharing, reducing disk and memory +requirements and greatly improving interactive response by minimizing process +connects. Paradoxically, the use of multiple concurrent processes can actually +improve performance by permitting pipelined execution, e.g., the applications +process can be busy generating graphics metacode while the CL or graphics +kernel is waiting for i/o to a graphics device. +.PP +The \fBchief disadvantage\fR of the IRAF process structure is the difficulty of +error recovery in response to a user interrupt or program abort. An interrupt +may occur while all processes in the group are busily computing and passing +messages and data back and forth via interprocess communication (IPC), making it +necessary to terminate the current task and clear and synchronize the entire +IPC data path. That this problem is tractable at all is due to the +master/slave nature of the IPC protocol. At any one time there will be only +one master process in the system. When an interrupt occurs it is only the +master process which is (logically) interrupted. If the task currently +executing in the master process does not intercept the interrupt and either +ignore it or take some special action, control will pass to the VOS error +recovery code in the master process, which will oversee the synchronization +and cleanup of the i/o system before returning control to the CL. + +.sp +.ce +\fB3. The Command Language (CL)\fR +.SH +3.1 Basic Concepts +.PP +The IRAF Command Language (CL) is the user's interface to the IRAF system. +The CL organizes the many system and applications \fBtasks\fR (programs) +into a logical hierarchy of \fBpackages\fR. A package is a collection of +logically related tasks, and is represented to the user using a type of +\fBmenu\fR. Each task has its own local set of \fBparameters\fR. To keep +the calling sequence concise, each task has only a few required or +\fBquery mode\fR parameters. For maximum flexibility, tasks may provide +any number of optional \fBhidden mode\fR parameters as well, each with +a reasonable default value chosen by the programmer but modifiable by the +user, either permanently or via a command line override. +.PP +A package is implemented as a special kind of task, and packages often contain +"tasks" which are really subpackages, hence the logical organization of +packages is a tree. A package must be \fBloaded\fR by typing its name +before any of the tasks therein can be executed or referenced in any other +way by the CL. Loaded packages are organized as a linear list, with the +list order being the order in which the packages were loaded. References to +tasks in loaded packages are resolved by a circular search of this list, +starting with the \fBcurrent package\fR, which may be any package in the +set of loaded packages. If a task with the same name appears in more than +one package, the package name may optionally be specified to resolve the +ambiguity. Note that is is not necessary to traverse the package tree to +execute a task in a loaded package. +.SH +3.2 Command Language Features +.PP +The most notable features of the IRAF command language are summarized in +Figure 3. The CL is designed to serve both as a \fBcommand language\fR and +as an interpreted \fBprogramming language\fR. The emphasis in this initial +version of the CL has been on providing good command entry facilities. +Extensive CL level programming facilities are also provided in the current CL, +but full development of this aspect of the CL is a major project which must +wait until development of the baseline IRAF system is completed. + +.KS +.TS +center; +l l. +\(bu provides a uniform environment on all host systems +\(bu package structure for organization and extensibility +\(bu menus and extensive online help facilities +\(bu concise command syntax similar to UNIX cshell +\(bu i/o redirection and pipes; aggregate commands +\(bu minimum match abbreviations for task and parameter names +\(bu both local and global parameters, hidden parameters +\(bu direct access to host system; foreign task interface +\(bu parameter set editor; command history editor (edt, emacs, vi) +\(bu background job submission (including queuing) +\(bu logfile facility for recording all task invocations +\(bu graphics and image display cursor mode facilities +\(bu virtual filename facility; unix style pathnames to files +\(bu programmable: procedures, C style expressions and control constructs +.TE +.sp +.ce +Figure 3. Selected Features of the IRAF Command Language +.KE +.PP +The basic IRAF command syntax is the same as that used in the UNIX cshell. +Similar \fBi/o redirection\fR and \fBpipe\fR facilities are provided, +extended in the CL to provide support for the standard graphics streams. +\fBBackground job\fR submission facilities are provided, including support +for batch queues, control of job priority, and servicing of parameter queries +from background jobs after the job has been submitted. A cshell like +\fBhistory mechanism\fR is provided, extended in the CL to record multiline +command blocks rather than single command lines, and including a builtin +screen editor facility for editing old commands. Minimum match abbreviations +are permitted for task and parameter names, allowing readable (long) names +to be used without sacrificing conciseness. +.PP +Extensive online \fBhelp\fR facilities are provided, including the package +menu facility already mentioned, a utility for listing the parameters of +a task, as well as online manual pages for all tasks. An interactive +\fBcursor mode\fR facility provides a builtin graphics or image display +control capability operable whenever a cursor is read by an applications +program, without need to exit the applications program. Cursor mode is +discussed further in \(sc6.6. +.PP +While the CL provides a fully defined, complete environment independent of +the host system, an \fBescape mechanism\fR is provided for interactively sending +commands to the host system. In addition, host system tasks, including user +written Fortran or other programs, may be declared as IRAF \fBforeign tasks\fR +and accessed directly from the CL much like true IRAF tasks, permitting the +use of the CL i/o redirection, background job submission, etc. facilities for +these tasks. A host system \fBeditor\fR interface is provided so that the +user may access their favorite editor from within the IRAF environment. +New IRAF programs and packages may be developed and tested from within the +IRAF environment, or programs (CL procedures) may be written in a C like +dialect of the command language itself. +.PP +It is beyond the scope of this paper to attempt to discuss the user level +features of the CL in any detail. The reader is referred to any of the +following references for additional information. +\fIA User's Introduction to the IRAF Command Language\fR explains the basic +use of the language, and the \fIThe IRAF User Handbook\fR contains many +examples as well as manual pages for the CL language features. The document +\fIDetailed Specifications for the IRAF Command Language\fR presents the +author's original design for the CL, and although now rather dated contains +information about the conceptual design and inner workings of the CL not +found in any of the more recent user oriented manuals. +.SH +3.3 Principles of Operation +.PP +With very few exceptions, all user interaction in IRAF is via the CL. +This ensures a consistent user interface for all applications programs, +simplifies applications code, and provides maximum flexibility, since +the CL (and hence the user) controls all aspects of the environment in +which a program is run. Applications programs do not know if they are +being used interactively or not, or even if they are being called from +the CL. Indeed, any IRAF program may be run at the host system level +as well as from the CL, although the user interface is much more primitive +when the program is called at the host level. +.PP +The CL executes concurrently with the applications process, responding to +parameter requests from the applications process, managing the standard i/o +streams, processing graphics output and managing cursor input, and so on. +In effect the CL and the applications task are one large program, except +that binding occurs at process connect time rather than at link time. +This makes it possible for programs to have a highly interactive, sophisticated +user interface, without linking enormous amounts of code into each executable. +A further advantage is that since a single process is used for all user +interaction, the \fIcontext\fR in which a task executes is preserved from +one task to the next, without need to resort to inefficient and awkward +techniques using disk files. +.PP +The CL recognizes a number of different types of tasks, most of which have +already been mentioned. The \fBbuiltin tasks\fR are primitive functions which +are built into the CL itself. \fBScript tasks\fR are interpreted CL procedures. +\fBCompiled tasks\fR are IRAF programs written in some compiled language and +executing in a connected subprocess residing in the process cache. Lastly, +\fBforeign tasks\fR are compiled host programs or host command scripts, +which the CL executes by sending commands to the host system. +A special case of a builtin task is the \fBcl task\fR, the function of which +is to interpret and execute commands from a command stream, e.g., the user +terminal. +.PP +All of these types of tasks are equivalent once the task begins executing, +i.e., while a task is executing the function of the CL is to interpret and +execute commands from the \fItask\fR, until the task informs the CL that it +has completed. If a command is received which causes another task to be run, +the CL pushes a new task context on its control stack and executes the new +task, popping the old context and resuming execution of the old task when +the called task terminates. Logout occurs when the original "cl" task exits. +The key point here is that the CL functions the same whether it is taking +commands from the user, from a script, or from a compiled applications program. +This is known as the principle of \fBtask equivalence\fR, and is fundamental +to the design of the CL. +.SH +3.4 Extensibility +.PP +New tasks or entire packages may be added to the CL at any time by entering +simple declarations, hence the CL environment is easily extended by the user. +The mechanism used to do this is the same as that used for the packages and +tasks provided with the standard system, hence the user has full access to +all the facilities used for the standard IRAF tasks, including the help +mechanism. No changes have to be made to the standard system to add locally +defined packages and tasks. Conversely, a new version of the standard system +can be installed without affecting any local packages (provided there have +been no interface changes). + +.sp +.ce +\fB4. Applications Software\fR +.SH +4.1 System Packages +.PP +The IRAF applications packages are divided into two broad classes, the system +packages and the scientific reduction and analysis packages. In this section +we introduce the system packages, which are listed in Figure 4. When +describing the applications packages, we list all packages which have been +implemented or which we plan to implement, since the purpose of this paper +is as much to present the design of IRAF as to report its current state. +The status of each package is indicated in the table below, where \fIdone\fR +means that the package has reached its planned baseline functionality +(of course, all packages continue to evolve after they reach this state), +\fIincomplete\fR means that the package is in use but has not yet reached +baseline functionality, \fIin progress\fR means the package is actively being +worked on but is not yet in use, and \fIfuture\fR means that work has not yet +begun on the package. It should be pointed out that each of these packages +typically contains several dozen tasks, and many contain subpackages as well. +It is beyond the scope of this paper to delve into the contents of these +packages in any detail. + +.KS +.TS +center; +ci ci +n c. +package status (March 86) + +dataio -\& Data input and output (FITS, cardimage, etc.) done +dbms -\& Database management utilities future +images -\& General image processing, image display incomplete +language -\& The command language itself done +lists -\& List processing incomplete +plot -\& General graphics utilities done +softools -\& Software tools, programming and system maintenance done +system -\& System utilities (file operations, etc.) done +utilities -\& Miscellaneous utilities done +.TE +.ce +Figure 4. System Packages +.KE +.PP +The system packages include both those packages containing the usual operating +system utilities, e.g., for listing directories or printing files, as well as +those packages which are required by any scientific data processing system, +e.g., for general image processing and graphics. The conventional operating +system utilities are found in the \fBsystem\fR package. The \fBlanguage\fR +package contains those tasks which are built into the CL itself. +The \fBsoftools\fR package contains the software development and system +maintenance tools, including the HSI bootstrap utilities, i.e., the compiler, +librarian, the \fImkpkg\fR utility (similar to the UNIX \fImake\fR), +the UNIX \fItar\fR format reader/writer programs, and so on. +The \fBdbms\fR package is the user interface to a planned IRAF relational +database facility. The \fBlists\fR package contains an assortment of tasks +for operating upon text files containing tabular data, e.g., for performing +a linear transformation on one or more of the columns of a list. +.PP +The \fBdataio\fR package contains a number of tasks for reading and writing +data in various formats, including FITS, cardimage, and a number of other +more NOAO specific formats. These programs are typically used to read or +write magtape files, but all such programs can be used to operate upon a +disk file as well, a useful alternative for sites which have access to +an electronic network. The \fBplot\fR package contains a number of vector +graphics utilities, including CL callable versions of all the NCAR graphics +utilities (using the IRAF/GIO GKS emulator). The \fBimages\fR package, +which is actually a tree of related packages, contains the general image +processing tasks plus the image display and display control tasks. +.SH +4.2 Optical Astronomy Packages +.PP +The NOAO packages for the reduction and analysis of optical astronomy data +are summarized in Figures 5 and 6. There are two categories of optical +astronomy packages. The packages listed in Figure 5 are intended to be of +general use for any optical astronomy data, not just for data taken at an NOAO +observatory with an NOAO instrument. Since these are intended to be general +purpose, instrument independent packages, naturally they are not always the +most convenient packages to use for reducing data from a specific instrument. +The \fBimred\fR packages, summarized in Figure 6, fulfill the need for easy to +use or "canned" reduction procedures for specific instruments. In many cases +the tasks in the \fBimred\fR packages are CL scripts which fetch instrument +specific parameters from the image headers and call tasks in the more general, +instrument independent packages. The list of \fBimred\fR packages is +continually growing as new instruments are supported. + +.KS +.TS +center; +ci ci +n c. +package status (March 86) + +artdata -\& Artificial data generation package in progress +astrometry -\& Astrometry package future +digiphot -\& Digital photometry package in progress +focas -\& Faint object detection and classification package future +imred -\& NOAO Instrument reduction packages done +local -\& Local user added tasks (not configuration controlled) - +onedspec -\& One dimensional spectral reduction and analysis package done +twodspec -\& Two dimensional spectral reduction and analysis packages done +surfphot -\& Galaxy surface brightness analysis package future +.TE +.ce +Figure 5. General Optical Astronomy Reduction and Analysis Packages +.KE +.PP +The \fBartdata\fR package consists of tasks for generating various types of +test data, e.g., pure test images, artificial starfields, artificial spectra, +and so on. The \fBastrometry\fR package is used to obtain astrometric +coordinates for objects in stellar fields. +The \fBdigiphot\fR package contains +a collection of tasks for automatically generating starlists, for performing +aperture photometry on an image (fractional pixel, multiple concentric +apertures, polygonal apertures), and for performing photometry using point +spread function fitting techniques. The \fBfocas\fR package performs faint +object detection and classification (e.g., to discriminate between faint +stars and galaxies), and will be largely a port of the existing UNIX +package of the same name to IRAF. The \fBonedspec\fR package provides a +standard set of tools for the dispersion correction, flux calibration, and +analysis of one dimensional spectra. The \fBtwodspec\fR package performs +the same operations for two dimensional spectra of various types, and currently +consists of the subpackages \fBlongslit\fR, \fBmultispec\fR, and +\fBapextract\fR. The \fBsurfphot\fR package fits ellipses to the isophotes +of galaxies. + +.KS +.TS +center; +ci ci +n c. +package status (March 86) + +imred.bias -\& General bias subtraction tools done +imred.coude -\& Coude spectrometer reductions done +imred.cryomap -\& Cryogenic camera / multi-aperture plate reductions done +imred.dtoi -\& Density to intensity calibration in progress +imred.echelle -\& Echelle spectra reductions done +imred.generic -\& Generic image reductions tools done +imred.iids -\& KPNO IIDS spectral reductions done +imred.irs -\& KPNO IRS spectral reductions done +imred.vtel -\& NSO (solar) vacuum telescope image reductions done +.TE +.ce +Figure 6. Current NOAO Instrument Reduction Packages +.KE +.PP +The \fBimred\fR packages perform general CCD image reductions, as well as the +reductions for other more specialized instruments. The \fBcryomap\fR, +\fBiids\fR, \fBirs\fR, and \fBvtel\fR packages deal with specific NOAO +instruments and are probably only of interest to people who observe at an NOAO +observatory. The remaining packages should be useful for anyone with CCD, +Echelle, or photographic (density) data. +.SH +4.3 Third Party Software +.PP +In addition to the applications packages already mentioned, all of which are +being developed by the IRAF group at NOAO, we anticipate that a fair amount of +third party software will eventually be available for use within IRAF as well. +The STScI SDAS software is the first example of this. +Third party software appears within IRAF as a new branch on the package tree. +There is no limit on the size of such an addition, and in the case of SDAS +we find a suite of packages comparable to the IRAF system itself in size. +As of this writing, a number of other groups are either actively developing +additional third party software or are contemplating doing so, +but it would be inappropriate to be more specific until these packages +are announced by the institutions developing them. +.PP +Third party software may unfortunately not meet IRAF standards, +hence the software may not be usable on all IRAF hosts, nor usable with all +the graphics and image display devices supported by IRAF. +Applications software which is built according to IRAF standards is +automatically portable to all IRAF hosts without modification (although +some debugging is typically required on a new host), hence sites considering +adding their own software to IRAF are encouraged to model their software +after the existing NOAO IRAF applications. + +.sp +.ce +\fB5. Programming Environments\fR +.SH +5.1 Overview +.PP +It is unrealistic to expect any finite collection of applications packages +to provide everything that a particular user or institution needs. +To be most useful a system must not only provide a good selection of ready +to use applications software, it must make it easy for users to add their own +software, or to modify the software provided. Furthermore, implementation and +development of even the standard IRAF applications packages is a major project +requiring many years of effort, hence the system must minimize the effort +required for software development by professional programmers as well as by +users. The solution to these problems is a \fBprogramming environment\fR, +or more precisely, a set of programming environments, each tailored to a +particular type of software and to the level of expertise expected from the +programmer. +.PP +The term programming environment refers to the languages, i/o libraries, +software tools, and so on comprising the environment in which software +development takes place. A good programming environment will provide all +the facilities commonly required by applications programs, ideally in +a form which is high level and easy to use without sacrificing flexibility +and efficiency. The facilities provided by the environment should be +layered to provide both high and low level facilities and to maximize code +sharing and minimize program size. The programming environment should +provide machine and device independence (code portability) as an inherent +feature of the environment, without requiring an heroic sacrifice or +transcendent wisdom on the part of the programmer to produce portable code. +.PP +IRAF currently provides three quite different programming environments. +The highest level environment is the CL, where the programming language is +the command language itself, and the environment is defined by the CL callable +packages and tasks. This is a very attractive programming environment for +the scientist/user because of its high level, interactive nature, but much +work remains to be done before this environment reaches its full potential. +At the opposite extreme is the host Fortran interface, which allows Fortran +programs written at the host level, outside of IRAF, to access IRAF images +and to be called from the CL. This is of interest because it allows +existing Fortran programs to be productively used within IRAF with minimal +modifications, and because it makes it possible for users to write image +operators immediately without having to learn how to use a more complex +(and capable) environment. +.PP +The third programming environment is that defined by the IRAF VOS. This is the +most powerful and best developed environment currently available, and is used +to implement nearly all of the existing IRAF systems and applications software. +Full access to the VOS facilities and full portability are available only for +programs written in the IRAF SPP (subset preprocessor) language, the language +used to implement the VOS itself. A C language interface is is also available, +but only a small subset of the VOS facilities are available in this interface, +and there are serious portability problems associated with the use of this +interface in applications programs (it is currently used only in highly +controlled systems applications, i.e., the CL). While IRAF does not currently +provide a Fortran interface to the VOS facilities, Fortran subroutines may +be freely called from SPP programs, allowing major portions of an applications +program to be coded in Fortran if desired. There are, however, serious +portability problems associated with the direct use of Fortran for applications +programs. +.PP +Only the SPP language adequately addresses the problem of providing full +functionality without compromising portability. This is because the SPP +language is an integral part of a carefully conceived, complete \fIprogramming +environment\fR, whereas C and Fortran are merely general purpose third +generation programming \fIlanguages\fR. Because it is specially designed +for large scientific programming applications, the SPP language and associated +programming environment will never see widespread usage like C and Fortran, +but for the same reasons it is ideally suited to our applications. +.SH +5.2 SPP Language Interface +.PP +The IRAF SPP (subset preprocessor) language is a general purpose programming +language modeled after C but implemented as a Fortran preprocessor. +Programming in SPP is conceptually very similar to programming in C; +the SPP language provides much the same basic facilities and syntax as C, +including pointers, structures, automatic storage allocation, \fBdefine\fR and +\fBinclude\fR, C style character data type, and Ratfor style versions of all +the usual control constructs. +The same problem will generally be solved the same +way in both languages. Since the SPP language resembles C but is translated +into Fortran, SPP combines the software engineering advantages of C with the +scientific programming advantages of Fortran. In addition, since SPP is an +integral part of the IRAF system, SPP provides language level support for +the VOS and for the IRAF programming environment in general. +.PP +The significance of the SPP language cannot be understood by studying only +the language itself as one would study C or Fortran. Rather, one must study +the programming environment and the role played by the SPP language in that +environment. The major components of the IRAF programming environment are the +SPP language, the VOS (\(sc6.1), the software tools, e.g., the \fBxc\fR +compiler, \fBmkpkg\fR, etc. (\(sc7.2), the applications libraries, e.g., +\fBxtools\fR, and the various math libraries, e.g., \fBcurfit\fR, \fBsurfit\fR, +\fBiminterp\fR, etc (\(sc5.6). +Considered as a whole, these components define a very rich +programming environment. Few systems provide a programming environment of +comparable capability, let alone in a machine and device independent format. +.PP +The chief problem facing a programmer trying to write their first applications +program in IRAF is learning the programming environment and "how things are +done" in IRAF. Learning the SPP language itself is generally a simple problem +dispensed with in hours or days, depending upon the individual. While most +people can be productively generating new programs within a few days, +weeks or months may be required to develop a deep understanding of and +fluency with the full environment. This is typical of any large software +system capable of supporting sophisticated applications programs, +and demonstrates that porting applications programs and applications +programmers between different programming environments is a myth. +In a sense, there are no (nontrivial) portable applications \fIprograms\fR, +only transportable programming \fIenvironments\fR. +.PP +Since a program is only as portable as the environment it is written for, +there are few portability advantages to programming large applications in a +standardized language (a case can however be made for purely numerical +routines). In fact the opposite is often the case, since few if any compilers +have ever been written which rigorously implement a language standard and +nothing more nor less. In the case of a language like Fortran, +it is not uncommon for half of the features offered by a particular +manufacturer's compiler to be nonstandard extensions to the formal language +standard, or even more dangerous, relaxations of subtle restrictions imposed +by the standard. It is difficult for a programmer to resist using such +extensions even when they know what the nonstandard extensions are, and usually +a programmer will be more concerned with getting the program functioning +as soon as possible than with making it portable. + +.KS +.PS +box wid 0.9 "SPP" "module"; arrow; ellipse width 1.1i "preprocessor" +arrow; box wid 0.9 "Host Fortran" "module" +line <- down at 1st ellipse.s +box "translation" "tables" +.PE +.ce +Figure 7. Preprocessor Dataflow +.KE +.PP +.PP +The SPP language solves this problem by providing all the features the +programmer needs directly in the language, so that the programmer +does not have to do without. If a new feature is needed and can be justified, +it can easily be added to the language since IRAF defines the SPP language +standard. Since the SPP translator is part of IRAF rather than part of the +host system, there is only one translator and the problem of writing code +which will be accepted by a variety of host compilers is greatly minimized. +The intermediate Fortran generated by the translator uses only the most +common features of Fortran, hence is intrinsically highly portable. +The intermediate Fortran is prettyprinted (indented to show the structure, +etc., so that a human can read it) and may optionally be saved and used for +symbolic debugging with the host system debugger. +.PP +Since a mechanical translator is used to generate the host Fortran when an +SPP program is compiled, nonstandard host Fortran extensions can be used +without compromising the portability of applications programs, by simply +modifying the host dependent tables used to drive the translation. +Since the SPP compiler is part of the IRAF environment rather than the +host environment, it understands IRAF virtual filenames, an essential +capability for referencing global include files. The \fBdefine-include\fR +facility itself is vital for parameterizing the characteristics of the +host machine and VOS configuration, as well as for structuring applications +software. Since the SPP language places an interface between IRAF +applications programs and the host Fortran compiler, our considerable and +ever growing investment in applications software is protected from future +changes in the Fortran standard. +.PP +As the name subset preprocessor implies, the SPP language implements a +subset of a planned future language. Most of the limitations of the +current SPP language are due to the use of preprocessor technology +to carry out the translation. A much more powerful approach is to use +a full syntax directed compiler with an associated code generator which +generates host Fortran statements rather than assembler instructions. +This will greatly improve compile time error checking, increase the +portability of both the applications software and the compiler, +and will make it possible to include certain advanced features in the +language for generalized image and vector processing. +This is an exciting area for future research, as compiler technology +makes possible the solution of a large class of image processing problems +which cannot readily be addressed any other way. +.PP +In summary, the IRAF SPP language interface provides a rich scientific +programming environment without compromising program portability. +Programmers using this environment can concentrate on the problem to be +solved without concern for the portability of the resultant software, +and are free to use all of the facilities provided by the language and the +environment. All of the facilities one needs for a particular application +are likely to either be already available somewhere in the environment, or +easily constructed using lower level facilities available in the environment, +and are guaranteed to be available in the same form on all IRAF host machines. +The proof of the concept of this interface is found in the current IRAF +system, where thousands of files in hundreds of directories are routinely +moved between quite different IRAF hosts, then compiled and run without +any changes whatsoever. +.SH +5.3 Host Fortran Interface +.PP +The host Fortran program interface (IMFORT) is in most respects the opposite +of the SPP/VOS programming environment. The IMFORT interface is a small +Fortran callable library which may be linked with host Fortran (or C) programs +to get the foreign task command line from the CL and perform some operation +upon an IRAF image or images. The host Fortran program may be declared as a +foreign task in the CL and accessed much as if it were a conventional IRAF +task, using the CL to parse, evaluate, and concatenate the command line to +be passed to the foreign task as a string. As a foreign task, the host +program may also be run outside the CL, using the host system command +interpreter, if desired. +.PP +The purpose of the IMFORT interface is to allow the existing Fortran programs +in use at a site when IRAF arrives to be modified for use within the IRAF +environment with minimal effort. The interface is also useful for the +scientist who needs to write a small program and does not want to take the +time to learn how to use the SPP/VOS environment. The IMFORT interface +consists of only a dozen or so routines hence almost no effort is required +to learn how to use the interface. Of course, the IMFORT interface does +not provide access to the extensive facilities of the SPP/VOS programming +environment, hence is not suitable for the development of large programs. +Programs written using the IMFORT interface are generally not portable +to other hosts, but this may not be a serious consideration to scientists +writing programs for their own personal use. +.SH +5.4 IRAF Fortran Interface +.PP +As noted earlier, IRAF does not currently have a Fortran applications +programming interface, other than the host Fortran program interface. +An IRAF Fortran programming environment would provide a subset of the +functionality provided by the SPP environment as a higher level library +of Fortran callable procedures. This differs from the host Fortran interface +in that the resultant programs would be fully integrated into IRAF, with +potential access to all SPP environment facilities, whereas the host Fortran +interface provides only limited imagefile access and the ability to fetch +the CL command line as a string, plus unrestricted access to host system +facilities. +.PP +We are considering adding such an interface for the scientist/programmer who +needs more than the IMFORT interface but is unwilling or unable to invest +the time required to learn to use the SPP environment. Unfortunately, +the lack of structures, pointers, dynamic memory allocation, +\fBdefine-include\fR, filename translation, etc. in ANSI standard Fortran +makes it prohibitively difficult to define a Fortran interface with capabilities +comparable to the SPP programming environment. Also, the resultant Fortran +programs would inevitably use the nonstandard features of the host Fortran +compiler and hence would not be portable. If such an interface were made +available and then used extensively, it seems likely that it would gradually +grow until it approximated the SPP environment in complexity, without the +advantage of the more elegant interface made possible by the SPP language. +.PP +If an embedded Fortran programming environment is ever added to IRAF it +therefore makes sense only if the environment is expressly designed with the +scientist/programmer in mind. The interface should provide all the necessary +facilities for small scientific programs but nothing more, and it should be +possible to become familiar with the use of the interface in a day or less. +Simplicity of use should be emphasized rather than efficiency. All large +applications projects and all "user qualified" software should continue to +be implemented in the SPP language and environment. +.SH +5.5 C Language Interface +.PP +The IRAF C language interface (library LIBC) consists of a fairly complete +UNIX STDIO emulation plus a C binding for a systems programming +subset of the IRAF VOS, comparable in capability to a V7 UNIX kernel. +All of the standard Berkeley UNIX STDIO facilities are provided, e.g., +the definitions in the include files \fI\fR and \fI\fR, +and functions such as \fIfopen\fR, \fIfread\fR, \fIfwrite\fR, \fIgetc\fR, +\fIputc\fR, \fIprintf\fR, \fIscanf\fR, \fImalloc\fR, and so on. +The STDIO procedures are implemented as an interface to the IRAF VOS, +hence calls to the VOS i/o procedures may be intermixed with calls to the +STDIO procedures, and the STDIO emulation is thus part of the portable system. +No UNIX sources are used hence a UNIX license is not required to use the +interface. Existing UNIX/C programs may be ported to the C language +environment with minor modifications (some modifications are always required), +assuming that the i/o requirements of the programs are modest. +.PP +The C language interface is currently used only to support the CL, which is +written in C primarily for historical reasons (the original CL was developed +concurrently with the VOS). The C language interface could in principle be +expanded to include more VOS facilities, but the sheer size of the VOS and +of the rest of the programming environment makes this impractical. +In any event, the SPP language is more suited to scientific programming, +avoids the portability problems of calling Fortran library procedures from C, +and will always be better integrated into the IRAF programming environment. +The use of the C language interface is not recommended except possibly for +porting existing large systems programs written in C to IRAF. +.SH +5.6 Applications Libraries +.PP +The standard applications libraries currently available in IRAF are summarized +in Figure 8. All libraries may be called from SPP programs. Only the purely +numerical Fortran libraries may be called from Fortran programs. +The sources for all libraries used in IRAF are included with the distributed +system and are in the public domain. In some cases the sources for the standard +numerical libraries have had to be modified slightly to eliminate calls to +the Fortran STOP, WRITE, etc. statements, sometimes used in error handlers. +Some major public domain math packages have yet to be installed in IRAF, e.g., +for nonlinear least squares and for evaluating special functions, for the +simple reason that we haven't needed them yet in our applications. + +.KS +.TS +center; +ci ci +l l. +library description + +bev Bevington routines (generally, these should be avoided) +curfit 1-D curve fitting package (SPP) +deboor DeBoor spline package +gks IRAF GKS emulator (subset of Fortran binding) +gsurfit Surface fitting on an irregular grid (SPP) +iminterp Image interpolation package, equispaced points (SPP) +llsq Lawson's and Hanson's linear least squares package +ncar NCAR graphics utilities, GKS version (uses GKS emulator) +nspp Old NCAR system plot package +surfit Surface fitting on a regular grid (SPP) +xtools General tools library for SPP applications programs +.TE +.ce +Figure 8. Applications Libraries (March 86) +.KE +.PP +The most heavily used numerical libraries in IRAF are those which were +written especially for IRAF (marked SPP in the figure). Our experience has +been that most of the generally available interpolation, curve and +surface fitting packages are overly general and inefficient for +use on bulk image data where the data points tend to be on an even grid, +or where the same X vector may be used to fit many Y vectors. +The SPP based math packages are nicely packaged, using dynamic memory +allocation to internally allocate a descriptor and all working storage, +and to hide the details of which of the possible algorithms supported by a +package is actually being used. +The supported interpolators include nearest neighbor, linear, +cubic spline, and third and fifth order divided differences. +The supported curve types include linear spline, cubic spline, +and the Chebyshev and Legendre orthogonal polynomials. +As far as possible the packages are vectorized +internally using the VOPS operators, to take advantage of the vector +processing hardware anticipated on future machines. + +.sp +.ce +\fB6. The Virtual Operating System (VOS)\fR +.SH +6.1 Major Components of the VOS +.PP +The primary functions of the VOS are to provide all the basic functionality +required by applications programs, and to isolate applications programs from +the host system. The VOS defines a complete programming environment suitable +both for general programming and for scientific programming in particular. +In addition to the standard facilities one expects from a conventional +operating system, e.g., file i/o, dynamic memory allocation, process control, +exception handling, network communications, etc., the VOS provides many +special facilities for scientific programming, e.g., a CL interface, +image i/o (access to bulk data arrays on disk), and a graphics subsystem +supporting both vector graphics and image display devices. The major +subsystems comprising the IRAF VOS are outlined in Figure 9. + +.KS +.TS +center; +l l. +CLIO command language i/o (get/put parameters to the CL) +DBIO database i/o (not yet implemented) +ETC exception handling, process control, symbol tables, etc. +FIO file i/o +FMTIO formatted i/o (encode/decode, print/scan) +GIO graphics i/o (both vector graphics and image display access) +IMIO image i/o (access to bulk data arrays on disk) +KI kernel interface (network communications) +LIBC UNIX stdio emulation, C binding for the VOS, used by the CL +MEMIO memory management, dynamic memory allocation +MTIO magtape i/o +OSB bit and byte primitives +TTY terminal control (\fItermcap\fR, \fIgraphcap\fR access) +VOPS vector operators (array processing) +.TE +.ce +Figure 9. Major Subsystems Comprising the IRAF VOS +.KE +.PP +Although the VOS packages are normally presented as independent packages, +there is naturally some vertical structure to the packages. The highest level +packages are GIO and IMIO, which depend upon many of the lower level i/o +packages. The most fundamental packages are FIO and MEMIO, which are used +by everything which does i/o. At the bottom are the KI (the kernel interface) +and the kernel itself, which is part of the host system interface (\(sc7.3). +All of the VOS code is portable with the exception of certain GIO graphics +device kernels, hence the VOS is functionally equivalent on all IRAF hosts. +.PP +Most of the capabilities provided by the VOS are already present in existing +commercial operating systems or in commercial or public domain libraries +available for such systems. It is certainly possible to assemble a functional +reduction and analysis system by starting with the facilities provided by a +particular host OS, obtaining a few libraries, and building the rest of the +software locally. This is the approach most organizations have followed, and +it certainly would have been a lot easier (and less controversial) for us to +do the same rather than construct an entire virtual operating system as we did. +.PP +The chief problem with the off-the-shelf approach is of course that the +resulting programming environment is unlikely to be very portable and would very +likely be incomplete, forcing applications software to bypass the environment +and use host facilities to get the job done. Furthermore, it is hard to +produce a consistent, efficient, well engineered \fIsystem\fR by patching +together independently developed subsystems, even if the individual subsystems +are very good considered all by themselves (and often they are not, nor are they +often in the public domain). These problems typically scale as some large power +of the size of the system being developed. The off-the-shelf approach shows +results sooner, but in the long run it costs far more, particularly if the +planned system is large and has to be maintained in numerous configurations +on numerous host machines. +.PP +The approach we have adopted results in a better system which is easier to +port initially to a new machine (because the host interface is small, well +isolated, and well defined), and which is much easier to support once the +initial port has been carried out. The VOS subsystems are often quite large +and are expensive to develop, but they do exactly what we want, fit into the +system just right, and once they have been developed they become a permanent +fixture in the environment requiring little or no maintenance, freeing our +limited resources for interesting new projects. +.SH +6.2 The File I/O (FIO) Subsystem +.PP +At the heart of the VOS i/o subsystem is \fBFIO\fR, the file i/o interface. +FIO makes a distinction between two broad classes of file types, text +files and binary files. The type of a file must be specified at open +time, but once a file has been opened file i/o is device independent. +FIO supports a wide range of \fBstandard devices\fR, e.g., disk resident +text and binary files, terminals, magtapes, line printers, IPC (interprocess +communications channels), static files (can be preallocated and mapped into +virtual memory), network communications channels, the pseudofiles +(see below), and text and binary memory-buffer files. Device drivers for +\fBspecial devices\fR may be dynamically loaded at run time by applications +programs, hence the FIO interface (and all programs which use FIO) may be +used to access any physical or abstract device. For example, an applications +program may interface an image display device as a binary file and then +use IMIO to access the display. +.PP +\fBText files\fR are stored on disk in the host system text file format, +e.g., in a format acceptable to host system text file utilities such as +an editor or file lister. Reading or writing a text file implies an +automatic conversion between the IRAF internal format and the host system +format. The internal format is a stream of ASCII characters with linefeed +characters delimiting each line of text (as in UNIX). The text file +abstraction is required in a portable system to be able to use the host +utilities on text files generated by the portable system, and vice versa. +.PP +\fBBinary files\fR are unstructured byte stream arrays; data is written to and +read from a binary file without any form of conversion. There are two +subclasses of binary files, the \fBstreaming\fR binary files, and the +\fBrandom access\fR binary files. The streaming files can only be read and +written sequentially; examples are IPC and magtape. Random access binary +devices are assumed to have a fixed device block size which may differ for +each device. A binary device is characterized by device dependent block size, +optimum transfer size, and maximum transfer size parameters read dynamically +from the device driver when a file is opened on the device. By default FIO +configures its internal buffers automatically based on the device parameters, +but the buffer size for a file may be overridden by the user program if +desired. +.PP +FIO supports a special builtin type of file called the \fBpseudofile\fR, +a binary streaming file. The pseudofile streams are opened automatically +by the system when a task is run. The pseudofile streams of interest to +applications programs are STDIN, STDOUT, and STDERR (the standard input, +output, and error output streams), and STDGRAPH, STDIMAGE, and STDPLOT +(the standard vector graphics, image display, and plotter streams). +These streams are normally connected to the terminal, to a graphics device, +or to a file by the CL when a task is run. The user may redirect any of +these streams on the command line. Pseudofile i/o is multiplexed via IPC +to the CL process whence it is directed to the physical device, graphics +subkernel, or file connected at task initiation time. Graphics frames +output to STDGRAPH are spooled in a buffer in the CL process so that the user +may later interact with the graphics output in \fIcursor mode\fR (\(sc6.6). +.PP +The top level FIO procedures are stream oriented. The FIO \fBuser interface\fR +is a simple open-close, getc-putc, getline-putline, read-write-seek, etc. +interface which is quite easy to use. +Character data may be accessed a character at a time or a line at a time; +terminal i/o is normally a line at a time but a \fBraw mode\fR is provided +as an option (this is used for keystroke driven programs such +as screen editors). Binary data may be read and written in chunks of any +size at any position in a file. On random access devices a seek call is +required to position within the file. FIO handles record blocking and +deblocking, read ahead and write behind, etc., transparently to the +applications program. An asynchronous, unbuffered, block oriented, direct +to user memory interface is also provided for applications with unusual +performance requirements (for binary files only). +.SH +6.3 FMTIO, MEMIO, TTY, VOPS, ETC +.PP +The \fBformatted i/o\fR interface (FMTIO) is concerned with formatting output +text and decoding input text. The primary high level stream oriented procedures +\fIscan\fR, \fIfscan\fR, \fIprintf\fR, \fIfprintf\fR, \fIsprintf\fR, etc., +are modeled after the UNIX facilities for which they are named. +A set of low level string oriented procedures provide a variety of numeric +encode/decode functions, a set of general string operator functions, +some lexical analysis functions, and a general algebraic expression evaluation +function. The FMTIO numeric conversion routines fully support indefinite +valued numbers (INDEF). +.PP +The \fBmemory i/o\fR interface (MEMIO) provides a dynamic memory allocation +facility which is heavily used throughout the IRAF system. Both \fBheap\fR +and \fBstack\fR facilities are provided. The high level heap +management procedures \fImalloc, calloc, realloc\fR, and \fImfree\fR are modeled +after the comparable UNIX procedures, although there are some minor differences. +An additional procedure \fIvmalloc\fR is provided to allocate buffers aligned +on virtual memory page boundaries. A pair of procedures \fIbegmem\fR and +\fIfixmem\fR are provided to dynamically adjust the working set size at +runtime, or to simply query the amount of available physical memory if the +working set cannot be adjusted. This is used to dynamically tune large-memory +algorithms to avoid thrashing. The stack procedures are used mainly to +simulate automatic storage allocation, with the advantage that the amount +of space to be allocated is a runtime rather than compile time variable. +MEMIO relies heavily upon the pointer facility provided by the SPP language. +.PP +The terminal capabilities database interface (TTY) provides a basic +screen management capability for terminals. The TTY interface uses the +Berkeley UNIX \fBtermcap\fR terminal database, which supports dozens of +terminals and which is easily extended by the user. The database capabilities +of the TTY interface are also used for the line printer interface and for +the IRAF \fBgraphcap\fR database, used to store device dependent information +describing the various graphics terminals, image displays, and plotters +supported by IRAF. +.PP +The \fBvector operators\fR interface (VOPS) is a large library of subroutines, +each of which performs some simple operation on one or more one dimensional +arrays. Operators provided include the arithmetic operators, sqrt, power, +abs, min, max, reciprocal, the trig functions, a full matrix of type conversion +operators, fill array, clear array, memory to memory copy, a set of boolean +operators, sort, statistical functions (median, average, etc.), rejection mean, +weighted sum, lookup table operations, vector interpolation, inner product, +vector sum, sum of squares, various linear transformations, convolution, +fourier transform operators, and so on. The VOPS operators are written in +a generic dialect of the SPP language and are expanded into a full set of +type specific operators by the \fBgeneric preprocessor\fR before compilation +and insertion into the VOPS library. A full range of datatypes is supported +for each operator, including type complex where appropriate. +.PP +Using the conditional compilation facilities provided by \fImkpkg\fR, selected +VOPS operators may be hand optimized in assembler or host specific Fortran +(e.g., using Fortran vector extensions on vector machines) without +compromising the portability of the system. +Similarly, selected VOPS operators might be +implemented in an array processor on a host which has one; ideally the array +processor should be tightly coupled to the cpu for this to be worthwhile +(a shared memory interface using MEMIO support is possible). The VOPS +operators are used heavily throughout IRAF with the expectation that +\fBvector machines\fR will become increasingly common in the future. +.PP +The ETC package is the catch-all for those VOS facilities too small +to warrant full fledged package status. Major ETC subpackages include the +\fBprocess control\fR facilities, used to spawn and control connected +subprocesses and detached processes, the \fBexception handling\fR facilities, +used to trap interrupts, post signal handlers, etc., and the \fBenvironment\fR +(logical name) facility. ETC also contains the \fBdate and time\fR facilities, +the \fBdevice allocation\fR facilities, a general purpose \fBsymbol table\fR +facility, and a number of other subpackages and miscellaneous system procedures. +IRAF relies upon the environment facilities to map virtual filenames to host +filenames and to assign logical names to physical devices. The VOS +automatically propagates the environment and current default directory to +connected subprocesses. +.SH +6.4 The Command Language I/O (CLIO) Subsystem +.PP +The CL is almost completely invisible to the applications program. The CLIO +interface consists of little more than a set of get/put procedures for CL +parameter i/o. Parameters may be accessed either by name or by the offset +of the parameter in the command line. A task may query the number of +positional parameters on the command line, or whether a particular pseudofile +stream has been redirected on the command line. +.PP +The CLIO interface is very simple at the applications level; all of the +complexity and power of the interface is hidden behind the CLIO interface +in the CL itself. +Parameter requests may be satisfied either directly by the applications +process, i.e., when it is run outside the CL, or by the CL at task invocation +time or while the task is executing. The CL (i.e., the user) determines how +a parameter request is satisfied transparently to the applications program. +Some parameter requests result in interactive queries, +others are satisfied immediately without a query. If a task repeatedly +requests the same CL parameter, a different value may be returned for each +request, allowing tasks to be used interactively. By assigning a text file +containing a list of values to such a parameter, the user may run such tasks +in batch mode. The graphics and image display cursors are implemented as +CL parameters, and cursor input may be either interactive (causing cursor +mode to be entered) or batch (input is taken from a text file assigned to the +cursor type parameter by the user). +.SH +6.5 The Image I/O (IMIO) Subsystem +.PP +The IMIO interface is used to access bulk data arrays or \fIimages\fR +(rasters, pictures) normally stored in random access binary files on disk. +An \fBimage\fR consists of an N-dimensional array of \fBpixels\fR and an +associated \fBimage header\fR describing the physical and derived attributes +of the image. Arbitrary user or applications defined attributes may be +stored in the image header. The present interface supports images with +from zero to seven axes. There are no builtin limits on the size of an +image since all data buffers are dynamically allocated. The datatype of +the pixels in an image may be any SPP datatype, i.e., \fIshort\fR (signed +16 bit integer), \fIlong\fR, \fIreal, double\fR, or \fIcomplex\fR, or the +special disk only datatype \fIushort\fR (unsigned 16 bit integer). +.PP +IMIO is primarily a conventional binary file i/o type of interface. While it is +possible to map all or portions of an image into \fBvirtual memory\fR if the +host system supports such a facility and if a number of runtime conditions +are met, all current IRAF applications use only the conventional binary file +i/o access method. +This is necessary for full portability (a true virtual memory machine is not +required to run IRAF) and furthermore is the most flexible and +efficient type of access for the majority of our image processing applications. +While there are some difficult image analysis applications which benefit +significantly from the use of virtual memory, most applications access the +entire image sequentially and can easily be programmed using binary file i/o. +Sequential whole image operators are most efficiently implemented using binary +FIO; the heavy page faulting resulting from sequential image access via a +virtual memory interface places a greater load on the system. +More importantly, the price of using virtual memory is the loss of +\fIdata independence\fR, which greatly limits the flexibility of the interface. +.PP +While IMIO imposes certain restrictions upon the logical representation of +an image as seen by an applications program, there are few restrictions on +the physical storage format, and indeed IMIO is capable of supporting multiple +disk data formats, including site dependent formats if desired. The primary +restriction on the physical storage format is that images are assumed to be +stored in a noninterleaved \fBline storage mode\fR, i.e., like a Fortran array, +although the image lines may be aligned on device block boundaries if desired. +While no other storage modes are supported by the current interface, we hope +to add support for band interleaved, binary nested block (BNB), etc. storage +modes in the future. An efficient implementation of the BNB storage format +which preserves data independence will probably require language support. +.PP +The IMIO \fBuser interface\fR consists primarily of a set of procedures to +get/put image lines and subrasters. The high level IMIO routines are written +in generic SPP and a version of each i/o procedure is available for each +SPP datatype, allowing programs to be written to deal with any single datatype +or with multiple datatypes. The IMIO interface will automatically coerce the +datatype of the pixels when i/o occurs, if the type requested by the +applications program does not match that on disk. +.PP +Much of the flexibility and efficiency inherent in the IMIO interface derives +from the fact that pixel data is buffered internally in IMIO, returning a +\fIpointer\fR to the buffered line or subraster to the user, rather than +copying the data to and from the user buffer. This makes it possible for +IMIO to return a pointer directly into the FIO buffer if all the right +conditions are met, avoiding a memory to memory copy for the most efficient +possible i/o. Leaving the buffer management to IMIO also makes the interface +easier to use. +.PP +IMIO provides a number of optional features which make certain common +types of image applications easier to code. The number of input line buffers +may be set by the user to some value greater than one, allowing the use +of a \fBscrolling region\fR for filtering applications. A program may +optionally reference beyond the boundary of an image, with IMIO using the +specified \fBboundary extension\fR technique (nearest neighbor, constant value, +reflect, wrap around, etc.) to generate values for the out of bounds pixels. +This is useful for convolution or subraster extraction applications to avoid +having to deal with the boundary region as a special case. +.PP +Perhaps the most novel, most popular, and most useful feature of IMIO is the +built in \fBimage section\fR capability. Whenever the user enters the name of +an image they may optionally append an image section to specify the subset +of pixels in the image to be operated upon. For example, if image \fLpix\fR is +a 512 square, 2-dimensional image, then \fLpix[*,-*]\fR is the same image +flipped in Y, \fLpix[*,55]\fR is a one dimensional image consisting of line 55 +of the image, \fLpix[19:10,50:69:2]\fR is a 10 by 10 subraster obtained by +flipping in X and subsampling by 2 in Y, and so on. +If \fLcube\fR is a three dimensional image, \fLcube[*,*,5]\fR is band 5 of +the image cube (a two dimensional subimage), \fLcube[*,5,*]\fR is the XZ plane +at Y=5, and so on. The image section is processed by IMIO when the image is +opened, transparently to the applications program, which sees what appears +to be a smaller image, or an image of lesser dimensionality than the original. +The image section facility is automatically available for \fIany\fR program +that uses IMIO, and is only possible by virtue of the data independence +provided by the interface. +.SH +6.6 The Graphics I/O (GIO) Subsystem +.PP +For many scientific applications programs, fast interactive graphics is the key +to a good user interface. High quality graphics hardcopy is likewise essential +for presenting the final results of data analysis programs. These requirements +are the same both for vector graphics applications and for image processing +applications, and ideally the same interface should serve both types of +applications. Not everyone has ready access to an image display, so it should +be possible to run software intended for use with an image display device on +a graphics terminal. Likewise, it should be possible to overlay vector +graphics on an image display, even if the graphics program was intended for +use on a graphics terminal. While an interactive cursor driven graphics +interface is desirable for interactive reductions, one should not be forced +to use a program interactively, hence the graphics system should allow any +cursor driven graphics program to be used noninteractively as well. +Lastly, since a great variety of graphics and image display devices are in +use and more are being developed every day, the graphics system must make it +as easy as possible to interface to new devices and to support multiple +devices. +.PP +These were the primary performance requirements which the IRAF graphics i/o +subsystem (GIO) was designed to meet. GIO provides a uniform, device +independent interface for graphics terminals, graphics workstations, raster +and pen plotters, laser printers, and image display and image hardcopy devices. +GIO is one of the largest subsystems in IRAF, and is unlike most of the IRAF +interfaces in that it is not completely self contained, but rather is designed +to make use of existing non-IRAF graphics packages such as GKS, CORE, NCAR, +and so on. Nonetheless, GIO does provide all of the software necessary to +meet its primary requirement of providing fast interactive graphics for IRAF +applications normally run on a graphics terminal. GIO can be interfaced to +virtually any graphics terminal without modifying or writing any software, +and without relinking any executables. +.DS +.PS 8 +AP: box wid 0.9i "applications" "program" +NCAR: ellipse "NCAR" at AP.e + (1.0i,0.5i) + arrow right +GK1: ellipse "GKS" "emulator" + +GIO: box "GIO" at AP.e + (3.6i,0) + spline -> right .2i from AP.e + (0,0.1i) then to NCAR.w - (.2,0)\ + then to NCAR.w + spline -> right .2i from GK1.e then to GIO.w + (-.2,0.1i) \ + then to GIO.w + (0,0.1i) + line -> right at AP.e to GIO.w "(graphics output)" above + +GK2: ellipse "GKS" "emulator" at AP.e + (1.6i,-0.5i) + spline -> right .2i from AP.e - (0,0.1i) then to GK2.w - (.2,0) \ + then to GK2.w + spline -> right .2i at GK2.e then to GIO.w - (.2,0.1i) \ + then to GIO.w - (0,0.1i) + + line -> right 0.8i at GIO.e "GKI" "metacode" +CM: box dashed "cursor" "mode" + line <-> +GK: box "graphics" "kernel" + line <-> + box "graphics" "device" + +CLIO: box "CLIO" at GIO.n + (0,1.0i) + spline <- right .2i at CLIO.e - (0,0.1i) then to CM.n + (0,.2)\ + then to CM.n + line <- right at CLIO.e + (0,0.1i); ellipse dashed "cursor" "listfile" + spline <- up .4i at AP.n to AP.n + (.5,.6) then to CLIO.w - (.2i,0)\ + then to CLIO.w + "(cursor input)" at CLIO.w - (2.0,0) + + "(applications process)" at GIO - (2,1.1) + "|" at GIO + (0.8,-1.1) + "(CL)" at CM + (0,-1.1) + "|" at CM + (0.65,-1.1) + "(CL or subkernel)" at GK + (0.5,-1.1) +.PE +.sp +.ce +Figure 10. GIO Dataflow +.DE +.PP +The major components of the GIO subsystem and the flow of data between them +(graphics output and cursor input) are shown in Figure 10. A different, +somewhat simplified view emphasizing the process structure is given in Figure 2. +The first thing to note is that normally only a portion of the graphics system +is linked into an applications program. This reduces the size of applications +programs, makes it possible to add support for new graphics devices without +relinking the system, increases concurrency on single user systems, reduces +physical memory requirements on multiuser systems (since multiple users can +share the memory used by the graphics kernel process), reduces startup time +(since the same kernel process can be used by many tasks), and reduces the +need to worry about memory utilization in the graphics kernels, since the +kernel has an entire process to itself. +.PP +Applications programs normally contain only the device independent, output +oriented part of the graphics system. This includes any high level graphics +packages such as the NCAR utilities and the GKS emulator, the GIO axis drawing +and labelling code, and that part of GIO which transforms vectors input in +world coordinates into clipped NDC (normalized device) coordinates. +The graphics output of an applications program consists of GKI metacode, +a device and machine independent stream of 16 bit signed integer graphics +instruction opcodes and data. +.PP +The GKI opcodes, as well as the lowest level GIO interface procedures available +to the programmer, resemble the graphics primitives of the GKS standard, i.e., +polyline, polymarker, polytext, fill area, cell array, and so on. +The GIO \fBprogrammer interface\fR includes several layers of higher level +calls based on these primitives, providing everything likely to be needed by +applications software, e.g., autoscaling routines, coordinate transformations, +multiple world coordinate systems including optional log scaling in either axis, +both relative and absolute drawing commands (these build up polylines +internally), mark drawing routines, vector plotting routines, +the standard axis drawing and labelling routines, and so on. +.PP +The primary component of the GIO \fBuser interface\fR is the \fBcursor mode\fR +facility. The graphics system makes a clear distinction between graphics +output and cursor input. Often the task which reads the graphics cursor +is different than that used to generate the graphics output. When a graphics +frame is output, the world coordinate systems (WCS) associated with the frame +and all or part of the frame itself (a stream of GKI metacode instructions +beginning with a screen clear) is saved in a cursor mode \fIframe buffer\fR +in the CL process. +.PP +Sometime later the cursor position may be read by the task which generated +the frame, by a different task, or by the user by typing a command into the CL. +This causes cursor mode to be entered; cursor mode is terminated when the +user types a lower case or nonalphanumeric key on the terminal. +The cursor position is returned encoded as a string consisting of the fields +X, Y, WCS number, key typed, and an optional character string entered by the +user. While in cursor mode the user may zoom and pan the buffered frame, +repaint the screen, print the cursor position in world coordinates, draw axes +around the current window into the buffered frame, annotate the frame, +save the frame in a metacode file or reload the frame from such a file, +take a "snapshot" of the frame on a plotter device, and so on. Cursor mode +reserves the upper case keystrokes for itself, leaving the lower case +keystrokes and most of the nonalphanumeric characters for the applications +program. +.PP +The GKI metacode output by an applications program is normally transmitted +via IPC or the network interface to the CL process and then on to a graphics +kernel, which may be linked directly into the CL process or which may reside +in a subkernel, i.e., in a CL subprocess connected upon demand by the +pseudofile i/o system. GKI metacode may also be spooled in +a file by specifying the graphics output device \fBvdm\fR (virtual device +metafile), by redirection of the graphics stream on the command line, +or by running the applications process outside the CL with the graphics +stream redirected into a file. A variety of utilities are provided for +operations upon metacode files, e.g., for decoding the GKI instructions in +a metacode file (useful for debugging), for extracting frames from a metacode +file, for printing a directory of the frames in a metacode file, for generating +a new metacode file wherein each frame contains a mosaic of N of the frames +in the input metacode file, and so on. Spooled metacode may be used as input +to any graphics kernel to make plots on any device supported by that kernel. +.PP +All of the pieces of the graphics subsystem thus far discussed have been +device independent. The device dependent part of the graphics system is +the GIO \fBgraphics kernel\fR. The function of a graphics kernel is to +convert a stream of GKI metacode instructions into device instructions to +control the device or to perform i/o to the device. Since all WCS to NDC +coordinate transformations and clipping are handled by the device (and kernel) +independent GIO software, the graphics kernel sees only integer NDC +coordinates in the range 0 to 32767. The graphics kernel is an independent +module in the system, and GIO may support any number of distinct graphics +kernels. A GIO kernel may be a direct interface to a particular device, +or an interface to an external graphics library which may support any number +of physical or logical devices. +.PP +The IRAF system includes one graphics kernel which is completely portable and +hence available on any system. The STDGRAPH (standard vector graphics) kernel +is used for interactive graphics on the user's graphics terminal. To provide +the fastest possible response for interactive applications, the STDGRAPH kernel +is linked directly into the CL process. The STDGRAPH kernel is capable of i/o +to virtually any graphics terminal which has a serial interface. +A \fBgraphcap\fR entry for the device must be provided to tell the STDGRAPH +kernel the characteristics of the device, e.g., how to encode a pen motion +command, the resolution of the device, how to plot text, the number of +hardware text fonts available, and so on. Tektronix compatible terminals are +the most common, but the graphcap facility is general enough to describe most +other terminals as well (in fact, the more smarts the terminal has the better). +A graphcap entry is a runtime table typically consisting of less than a dozen +lines of text; new entries can easily be added by the user. +.PP +A GIO kernel is implemented as a \fIlibrary\fR, consisting of a pair of +open-kernel and close-kernel subroutines, plus one subroutine for each GKI +instruction. The GKI interface (graphics kernel interface) may be used to +call the kernel subroutines either directly, i.e., if the kernel is linked +into the same process as the program using GIO, or indirectly via a GKI +metacode data stream transmitted via pseudofile i/o if the kernel resides +in a different process. All GIO kernels are also installed in the system +linked into compiled IRAF tasks callable either as \fBsubkernels\fR by the +pseudofile i/o system, or by the user as a conventional CL task. When called +as a subkernel the GIO kernel reads metacode from a pseudofile stream; +when called as a CL task the kernel reads metacode from a file. +.PP +The IRAF system currently (March 86) provides kernels for the old NCAR system +plot package, for the Calcomp graphics library, and for the SUN-3 +implementation of the proposed CGI standard. Eventually, GIO kernels should be +available for GKS, CORE, and possibly other standard graphics libraries as well. +If a kernel is not already available for the host system and graphics devices +used at a particular site, it should not be difficult to generate a new +kernel by modifying one of the existing ones. Often it should only be +necessary to relink one of the GIO kernels supplied with the system with the +local GKS, Calcomp, etc. library to get a functional kernel. As a last resort, +a new GIO kernel can be built to talk directly to a specific physical device. +.PP +The current GIO subsystem supports vector graphics and batch plotter devices +quite well, but has not yet been used extensively for \fBimaging devices\fR +because there is no standard graphics interface for these devices. +A standard set of Fortran callable subroutines for interfacing to imaging +devices is currently being defined by an international consortium of +astronomical centers. Our intention is to build a GIO kernel which uses this +device independent image interface as soon as the interface definition is +complete. Implementations of the interface subroutines for the half a +dozen or so types of image displays used at NOAO are also planned. Once the +image display interface subroutines are defined and a GIO kernel which uses +them is in place, users will be able to interface new image devices to IRAF +by implementing the standard subroutines, relinking a few executables, +and adding a graphcap entry for each new device. +.PP +For more detailed information on the design of the GIO subsystem, including +specifications for the interface subroutines, for the graphcap facility, +and so on, the reader is referred to the document \fIGraphics I/O Design\fR +(March 85), which is available from the author. +.SH +6.7 The Database I/O (DBIO) Subsystem +.PP +The DBIO subsystem is the only subsystem in the original VOS design remaining +to be implemented. DBIO will be used for image header storage, for intermodule +communication in large packages, and for the storage of large catalogs such as +those produced by analysis programs as well as existing astronomical catalogs. +DBIO will be essentially a record manager type interface. The related CL +package DBMS will provide a relational database interface to catalogs and +other data maintained under DBIO. The planned database subsystem is a major +facility comparable in size and complexity to the existing graphics subsystem. +The reader is referred to the document +\fIDesign of the IRAF Database Subsystem\fR (draft, October 85) for additional +information on DBIO and DBMS, including a discussion of some of the potential +applications of database technology to astronomy. +.SH +6.8 Networking Facilities +.PP +The portable IRAF system includes support for network access to any physical +resource resident on a remote node, including disk binary and text files, +magtape devices, terminals, image displays, printer/plotters, and even +subprocesses and batch queues. Since this facility is provided by the portable +IRAF system the network nodes do not have to run the same operating system. +It is permissible for the nodes to be architecturally incompatible computers, +provided the higher level IRAF systems or applications software maintains data +externally in a machine independent format. +.PP +The broad scope of the IRAF networking facilities is made possible by the +fact that all access to host system resources in IRAF has to go through the +IRAF kernel, a part of the host system interface (\(sc7.3). The IRAF +networking capability is provided by a VOS package called the +\fBkernel interface\fR (KI). The KI is a sysgen option in IRAF and is not +required to run the system on a single node. The relation of the KI to the +rest of the VOS and to the IRAF kernel is illustrated in Figure 11. +.DS +.PS + down + box "VOS" + line <-> +KI1: box "KI" + line <-> + box "local" "kernel" + +KI2: box dashed "kernel" "server" at KI1.e + (2,0) + line <-> down + box dashed "remote" "kernel" + + line <-> from KI1.e to KI2.w "network" "channel" + line -> right from KI2.e + " (etc)" ljust +.PE +.sp +.ce +Figure 11. The Kernel Interface +.DE +.PP +In an IRAF system configured without networking, the VOS code directly calls the +procedures forming the IRAF kernel for the local node. In a system configured +with networking, the VOS code calls instead KI procedures which are functionally +equivalent to the regular kernel procedures. If the kernel resource resides on +the local node the KI procedure merely calls the corresponding kernel procedure +on the local node, hence the KI adds a fixed overhead of one procedure call +when it is present in a system but not used to access remote nodes. +If the kernel resource resides on a remote node, the KI encodes the procedure +call in a machine independent format and passes it to a \fBkernel server\fR +on the remote node via a data stream network interface, returning any output +arguments to the local VOS via the same interface. +.PP +A remote resource is referenced by prefixing the resource name with the node +name and an exclamation character, i.e., \fInode!resource\fR. For example, +the command "\fLpage lyra!dev$graphcap\fR" might be entered to page the +\fLgraphcap\fR file on node \fLlyra\fR. Logical node names may be defined to +avoid introducing site dependent information into resource +names in portable code. When the first reference to a resource on a remote +node is received the KI "connects" the remote node, i.e., it spawns a kernel +server process on the remote node. The kernel server remains connected until +the client process on the local node terminates, or until an i/o error occurs +on the KI channel. In the current implementation of the KI, each client process +on the local node requires a dedicated kernel server process on the remote node. +A future implementation of the KI may permit a single server process to serve +an entire process tree on the local node. +.PP +The beauty of the kernel interface is that since it intercepts all kernel +requests it automatically provides such exotic network services as the ability +to interactively access a remote graphics device, or to spawn and interactively +run a subprocess on the remote node, without requiring any changes to the VOS +or to applications software. Furthermore, implementation of the KI required +no changes to the IRAF kernel (which is unaware that the KI exists), and the +KI software itself is portable, as is the kernel server task. The only machine +dependent software required is a FIO binary file driver capable of "opening" +a "file" (spawning a kernel server process) on a remote node, and providing +bidirectional binary communications with the remote server. +.PP +The network interface is currently in regular use at NOAO for remote image +display, plotter, and file access between VAX nodes running both UNIX and VMS, +using a TCP/IP network interface and Ethernet hardware. For example, a user +on node A might make a line plot of an image resident on node B, enter cursor +mode, and use the "snapshot" facility to dump the plot to a laser printer +on node C. We have not yet made use of the remote process and batch queue +capabilities. A DECNET interface also exists and will soon be tested in a +MicroVax to mainframe configuration. + +.sp +.ce +\fB7. The Host System Interface (HSI) +.SH +7.1 Major Components of the Host System Interface +.PP +The host system interface (HSI) is the interface between the portable +IRAF system and a particular host operating system. While the HSI contains +all of the machine dependent or potentially machine dependent code in IRAF, +much of the code in the HSI is actually fairly portable. To port IRAF to +a new operating system one must implement the HSI. Once the HSI has been +implemented for a new OS, the entire VOS and all of the IRAF system packages +and NOAO science packages will in principle compile and run without modification +(in reality, some testing and bug fixes are always required). Note that once +IRAF has been \fIported\fR to a new host OS, i.e., once the HSI has been +implemented for a particular host OS, one must still configure the site and +device dependent tables for a particular host to \fIinstall\fR IRAF on that +host. +.PP +The HSI currently consists of the following components. The IRAF \fBkernel\fR +is a subroutine library containing all the host dependent primitive functions +required by the VOS, and is usually the most machine dependent part of the HSI, +and the major item to be implemented in a port. The \fBbootstrap utilities\fR +are a set of utility programs required to compile and maintain the main IRAF +system; these are written in C and are mostly portable (they use the kernel +facilities when possible). The \fBhlib\fR library is a directory containing +a number of host and site dependent compile and run time tables used to +parameterize the characteristics of the host system. The \fBas\fR directory +contains the source for any library modules which have been written in +assembler for one reason or another; while IRAF currently requires only one +assembler module, any library module may be hand optimized in assembler if +desired, without compromising the portability of the system. Lastly, the +\fBgdev\fR directories contain the host dependent i/o interfaces for any +binary graphics devices supported by otherwise machine independent GIO kernels. +Often it is possible to write a portable (but device dependent) GIO kernel if +the i/o functions are factored out into a separate interface. +.SH +7.2 The Bootstrap Utilities Package +.PP +The bootstrap utilities are required to compile and maintain the rest of the +IRAF system. Since the bootstrap utilities must run before IRAF does, they +are implemented as \fIforeign tasks\fR callable either from the host system +or from the CL. Since the bootstrap utilities are required to compile and +maintain the VOS as well as the rest of the portable system, they do not +use the VOS facilities. Rather, they use a special \fIbootlib\fR library +which requires some direct access to host facilities but which mostly uses +the kernel facilities. + +.DS +.TS +center; +l l. +generic The generic preprocessor +mkpkg The "make package" library and package maintenance tool +rmbin Removes binary files in a directory tree +rmfiles Removes classes of files in a directory tree +rtar Reads TAR format tape or disk files +spp The XC compiler for the SPP language +wtar Writes TAR format tape or disk files +xyacc YACC compiler-compiler for SPP (requires UNIX license) +.TE +.sp +.ce +Figure 12. The Bootstrap Utilities +.DE +.PP +The bootstrap utilities are summarized in figure 12. The major utilities +are the \fImkpkg\fR program and the \fIxc\fR compiler; both of these are +required to compile and maintain the portable IRAF system. The \fIrmbin\fR +and \fIrmfiles\fR utilities are used to strip all binaries from the system +prior to a full sysgen, or to strip all sources from a runtime system to +save disk space. The \fItar\fR format reader/writer programs are used to +transport directory trees between IRAF systems running on different host +operating systems. For example, one might use \fIwtar\fR to make a source only +archive of a package in a disk file on a UNIX node, push the file through +the network to a VMS node, unpack the archive with \fIrtar\fR, and compile +and link the new package with \fImkpkg\fR, all without any knowledge of +the contents of the package and without editing any files (we do this all +the time). The \fIxyacc\fR utility is used to make SPP parsers. This utility +is not needed other than on our software development machine, since the output +of the utility is an SPP module which can be compiled and used on any IRAF host. +.SH +7.3 The IRAF Kernel +.PP +The IRAF kernel (also known as the OS package) is a library of fifty or so +files containing a number of Fortran callable subroutines. The kernel +procedures may be written in any language provided they are Fortran callable; +all current IRAF kernels are written in C. As far as possible, IRAF is designed +to implement all complex functions in the VOS, making the kernel as simple +as possible and therefore easier to implement for a new host. +The kernel is a well defined, well isolated interface which can be implemented +according to specifications without any knowledge of the rest of the system. +The current 4.2BSD UNIX/IRAF kernel contains 5900 lines of C code (something +like three percent of the full system), half of which is probably in the +various FIO device drivers. The IRAF kernel is discussed in detail in the +document \fIA Reference Manual for the IRAF System Interface\fR (May 84). + +.sp +.ce +\fBConclusions\fR +.PP +The IRAF system provides a large and steadily growing capability for the +reduction and analysis of astronomical data, as well as a general purpose +image processing and graphics capability useful for image data of any type. +The system itself is nonproprietary and no proprietary external libraries +are required to run IRAF. IRAF is a machine and device independent system, +hence is easily ported to many current machines as well as to future machines. +IRAF provides a complete modern programming environment suitable for general +software development and for scientific software development in particular. +.PP +IRAF has been designed from the beginning with the capabilities +of the next generation of computers in mind, hence the system is designed +to make use of the vector hardware, networking facilities, bit-mapped graphics +displays, large memories, and personal workstations expected to become +increasingly available during the next decade. The system has been designed +and implemented to a consistently high standard, and the combination of a +modern design and many advanced capabilities, plus a high degree of efficiency, +portability and device independence insure that the system will continue to +grow in capability and use in the years to come. + +.sp +.ce +\fBAcknowledgments\fR +.PP +The author wishes to acknowledge the efforts of the many people who have +contributed so much time, energy, thought and support to the development +of the IRAF system. Foremost among these are the members of the IRAF +development group at NOAO (Lindsey Davis, Suzanne Hammond, George Jacoby, +Dyer Lytle, Steve Rooke, Frank Valdes, and Elwood Downey, with help from +Ed Anderson, Jeannette Barnes, and Richard Wolff) and members of the VMS/IRAF +group at STScI (Peter Shames, Tom McGlynn, Jim Rose, Fred Rommelfanger, +Cliff Stoll, and Jay Travisano). +.PP +The continuing patience and understanding of members of the scientific +staff at both institutions has been essential to the progress that has +so far been achieved. A major software project such as IRAF cannot +be attempted without the cooperation of many individuals, since the +resources required must inevitably place a drain on other activites. +In particular, the support and encouragement of Buddy Powell, Harvey Butcher, +and Garth Illingworth was of critical importance during the first years +of the project. In recent years the support of John Jefferies, Steve Ridgway, +and Ethan Schreier has been invaluable. Mention should also be made of +Don Wells, who in 1978 started in motion the process which eventually led +to the creation of the IRAF system. + +.sp +.ce +\fBReferences\fR +.PP +The references listed here pertain only to the IRAF system software. +Unless otherwise noted, all papers are by the author. +These are mostly design documents; comprehensive user documentation for the +programming environment is not yet available. Considerable additional +documentation is available for the IRAF system packages and for the NOAO +and STScI science packages. Contact the responsible institution directly +for information on the science software. +.sp +.pg +.ta .3i +.in .3i +.ftR +.sp.3 +.ti0 +1. Shames, P.M.B, and Tody, D., +.ul +A User's Introduction to the IRAF Command Language Version 2.0, +revised February 1986. The current user's guide to the CL. +.sp.3 +.ti0 +2. +.ul +Detailed Specifications for the IRAF Command Language, +January 1983. The original CL design paper. No longer accurate or +comprehensive, but still contains useful information about the inner +workings of the CL. +.sp.3 +.ti0 +3. +.ul +IRAF Standards and Conventions, +August 1983. Coding standards, program design principles, portability +considerations for programming in the SPP environment. +.sp.3 +.ti0 +4. +.ul +A Reference Manual for the IRAF Subset Preprocessor Language, +January 1983. The most up to date documentation currently available for +the SPP language proper. +.sp.3 +.ti0 +5. +.ul +The Role of the Preprocessor, +December 1981. The original design document for the SPP language. +Primarily of historical interest. Documents the reasoning which led to +the decision to use a preprocessor language in IRAF. +.sp.3 +.ti0 +6. +.ul +Programmer's Crib Sheet for the IRAF Program Interface, +September 1983. Summarizes the contents of the various i/o subsystems +comprising the VOS. Somewhat out of date, but still useful. +.sp.3 +.ti0 +7. +.ul +Graphics I/O Design, +March 1985. Specifications for the graphics i/o subsystem. +Reasonably up to date. +.sp.3 +.ti0 +8. +.ul +Design of the IRAF Database Subsystem, +draft, October 1985. Presents the conceptual design of the planned database +subsystem. +.sp.3 +.ti0 +9. +.ul +A Reference Manual for the IRAF System Interface, +May 1984. An essential document describing the IRAF kernel, including the +principles of operation and specifications for the kernel routines. +.sp.3 +.ti0 +10. +.ul +UNIX/IRAF Installation and Maintenance Guide, +March 1986. +.sp.3 +.ti0 +11. +.ul +VMS/IRAF Installation and Maintenance Guide, +March 1986. +.sp.3 +.ti0 +12. +.ul +A Set of Benchmarks for Measuring IRAF System Performance, +March 1986. Contains comparative benchmarks for IRAF running on VAX/UNIX, +VAX/VMS (750,780,8600), the SUN-3, and additional machines in the future. -- cgit