.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<stdio.h>\fR and \fI<ctype.h>\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.
distrib
>
Mageia
>
6
>
armv5tl
>
media
>
core-release
>
by-pkgid
>
30819c093f498f9dfa6444d2407d0521
>
files
>
5340
