IRAF (Mar02) V2.12EXPORT Release Notes IRAF (Mar02) IRAF V2.12EXPORT Release Notes January 25, 2002 Updated: March 25, 2002 These release notes provide a summary of the major changes in V2.12. This is a major release of IRAF and will be available for all supported platforms. More detailed technical documentation of all system changes will be found in the 'notes.v211' and 'notes.v212' files in the iraf$doc and iraf$local directories. Detailed revisions notes for each application package are in the package directories in a file called Revisions, e.g. apphot$Revisions. 1. Highlights of This Release 2. IRAF System Revisions Summary 3. Core IRAF Revisions Summary 3.1 New Tasks 3.2 Existing tasks with new parameters/defaults 3.3 Existing tasks with new capabilities 4. NOAO Package Revisions Summary 4.1 New NOAO Packages 4.2 New NOAO Package Tasks 4.3 Existing tasks with new parameters/defaults 4.4 Existing tasks with new capabilities 5. General Package Changes 6. General Task Changes 7. Parameter File Changes 8. Details of Major System Changes 8.1 FITS Kernel Changes 8.2 Large Image Support 8.3 Virtual Memory Cache 8.4 New Developer libraries 9. System Changes Which May Affect You 9.1 Shared Library Version Incremented 9.2 External Package Recompilation 9.3 Parameter File Changes 9.4 Installation Script Changes 9.5 Help System Changes 9.6 Image Display Changes 9.7 PLIO Changes 9.8 New Environment Variables Changes 1. Highlights of This Release o Pixel Mask Support Added to FITS Kernel The FITS kernel was modified to add support for storing images in extensions as compressed pixel masks using the binary table extension. These masks may be accessed like any other image and allow for tasks to more easily store bad-pixel masks, regions masks, or error arrays in the same image file as the science data. o New Pixel Mask Tasks Several new tasks have been added to the system PROTO package for manipulating pixel masks: o MIMSTATISTICS allows image statistics to be computed while rejecting pixels specified by an input mask. o MSKEXPR task is a general-purpose mask expression evaluator similar to IMEXPR for images, but has builtin boolean region functions which can be used to set values inside or outside of certain geometric shapes. o MSKREGIONS creates an output mask based on an input text de- scription. Region descriptions can be composed of geometric shapes and logical operation on mask regions. o OBJMASKS in the NPROTO package is a new task for detecting objects in an image and creating an output catalog or pixel mask of found objects. o Shared Memory Limitations Eased The IMAGES and DAOPHOT packages executables are now linked statically to remove per-process memory limitations imposed by the IRAF shared library on Sun and Dec Alpha systems. Previously tasks such as DAOFIND and IMCOMBINE were limited to 268Mb on Sun systems, these tasks can now use up to the machine memory limits. o Image I/O Buffer Sizes Increased Support for large image I/O was improved by changes to the internal buffer sizes. These buffers may automatically adjust to optimal values for the image being accessed, however new environment variables may be set to further tune the buffers at the user level. Where needed applications tasks were modified to take advantage of these buffer size changes to force the imio buffer to be the size of the input image. o Simplified Installation Script The install script was rewritten to clarify the output and provide some basic checking of the IRAF system setup prior to installation, and to do some of the most common post-install configuration. The script will print an explanation of any errors it finds and suggest corrective action, the hope is this will lead the user past some of the most common installation errors. In addition, the SYSINFO diagnostic script which does more extensive checking of the system is also now part of the distribution. This script can be used to verify the system once the install is complete, or to generate a report of the system configuration if needed by site support. An UNINSTALL script to remove iraf command links and files created by the INSTALL script is also available to remove IRAF from a machine. All scripts are now installed in the hlib$ directory. o New HELP GUI and Output Options The HELP task was enhanced to have a new GUI option for XGterm users. This is essentially the XHELP task which has been available in the GUIAPPS external package for some time, however the task is fully backwards compatible and the text-mode output is still the default. As part of this work, help pages may also now be formatted as either HTML or Postscript for web presentation or pretty-printing to a hardcopy device. The LROFF task was similarly modified to provide direct conversion of lroff text sources. o DISPLAY Task Changes As part of the recent X11IRAF enhancements, the DISPLAY task and others such as IMEXAMINE which interact with the display server were modified to take advantage of the new features in XImtool V1.3. These include support for 16 frame buffers (increased from 4 in previous versions), and enhanced WCS readout capabilities. The changes are fully backwards compatible for use with older XImtool versions or display servers such as SAOimage, SAOtng, or DS9 which have not yet been updated. X11IRAF V1.3 is being released simultaneously (but still separately) with IRAF V2.12. While V2.12 is fully compatible with older versions of X11IRAF, however users will need to upgrade both systems to take full advantage of all the new features. Users should consult the X11IRAF Release Notes for details on what has changed there. o New Packages Several new packages are available in this release (see the NOAO package change notes below for details): - A new ASTCAT package for extracting astrometric and photometric calibration data from remote or local catalogs was added to NOAO. - A new CRUTIL package for doing cosmic ray detection and removal package was installed in the IMRED package. - A new QUADRED reduction package for QUAD format data was installed in the IMRED package. This is a generalized replacement for the ARED.QUAD and XCCDRED external packages for processing CTIO and ESO FORS1 multi-amplifier data. - A new OBSUTIL package was installed in NOAO. This is a collection of tasks from various external packages which are useful to plan or carry out observations. o New Developer Libraries. Several new libraries are available for SPP developers: - PSIO is a new Postscript text generation library installed in sys$psio. - CATQUERY is a remote astrometric/photometric catalog access lib installed in the XTOOLS utility library. - SKYWCS is a sky coordinate transformation library installed in the XTOOLS utility library. 2. IRAF System Revisions Summary o The IRAF shared library version number was incremented for SunOS and Solaris systems. See below for details on how this change will affect external packages and locally-compiled software. o The maximum number of nodes in a local iraf network was increased from 320 to 512. o The max number of open files in FIO, FIO_MAXFD, was increased from 256 to 4096. This is the "hard limit" on the maximum number of open files in an IRAF process. o The maximum number of host level open files, MAXOFILES, was increased from 64 to 256. This is the maximum number of files that can be simultaneously open at the host level. It determines the maximum number of files that can be simultaneously open by an IRAF process in the usual case. o The number of keywords in a group header block for STF images (i.e. the MAX_PCOUNT) was increased from 50 to 99 in the STF image kernel. o Added support for the bitwise boolean operators: '&' (and), '|' (or), '^' (xor), and '~' (not/complement), to vectory expression evaluator fmtio$evvexpr.gy. The IMEXPR task was modified to allow these new bitwise operations. o Added new vector operators to VOPS library: alan, alank (logical AND) and alor, alork (logical OR). These take any integer data as input (short, int, long) and return a logical (expressed as int) result. o The 'imextn' environment variable will now accept upper-case extensions to specify image types. o Host Command Execution: The way command line arguments are parsed was modified to make it easier to set the value of a string parameter to the null string. Whitespace is still skipped in @par files as before, however null strings are valid parameter values and will no longer cause a parameter prompt. o The MKPKG special file list link support was enhanced to allow replacing LFLAGS (the link flags variable) as well as the entire link line. This makes is possible to write special-file list entries for packages which need e.g. to be compiled nonshared on certain platforms without creating a platform specific mkpkg file for the package itself. o The HSI zawset.c routine which controls a process working set size was modified to automatically detect the physical size of system memory (with a maximum return value of 2Gb). The hard upper limit on memory utilization defined by the unix kernel can be limited either by the value return by the IRAF kernel (up to 90% of physical memory), or by the value set in the user environment variable MAXWORKSET (given in units of Mb). o New stdimage display devices were added to support the display of Gemini GMOS CCD data. These devices are named 'imt45' thru 'imt49' and correspond to the following frame buffer sizes: imt45 2080 x 4644 # imt45|imtgmosccd imt46 6400 x 4644 # imt46|imtgmos imt47 3200 x 2322 # imt47|imtgmos2 imt48 1600 x 1161 # imt48|imtgmos4 imt49 800 x 581 # imt49|imtgmos8 3. CORE IRAF REVISIONS SUMMARY 3.1 New Tasks imcoords.ccget - extract objects from a test file catalog imcoords.ccstd - transform to and from standard astrometric coordinates proto.mimstatistics - do image statistics through a mask proto.rskysub - sky subtract images using running mean or median proto.mskexpr - general mask expression evaluator proto.mskregions - create a mask from a list of region specifications 3.2 Existing Tasks with New Parameters or New Parameter Defaults immatch.imcentroid - new parameter maxshift immatch.imalign - new parameter maxshift immatch.geomap - new parameter maxiter, default reject = 3.0 not INDEF imcoords.ccmap - new parameter maxiter, default reject = 3.0 not INDEF imcoords.imcctran - new parameter longpole imutil.hedit - new parameter addonly imutil.imstatistics - new parameters nclip, lsigma, usigma, cache 3.3 Existing Tasks with New Capabilities immatch.imcentroid - optionally rejects objects whose centers wander too much immatch.imalign - optionally rejects objects whose centers wander too much immatch.geomap - iterative rejection capability added imcoords.ccmap - iterative rejection capability added imcoords.imcctran - support for non-zenithal projections added imutil.hedit - support for add keyword only if new option imutil.imstatistics - support for iterative rejection and memory caching added imutil.imexpr - support for bitwise operators or, and, xor, and not added 4. NOAO PACKAGE REVISIONS SUMMARY 4.1 New NOAO Packages astcat - Astronomical catalog and surveys access package crutil - Cosmic ray detection and removal package obsutil - Observing utilities package 4.2 New NOAO Package Tasks apphot.pcalc - Do arithmetic operations on a list of apphot databases apphot.pconvert - Convert a text database to a tables database apphot.pdump - Print selected fields from a list of apphot databases apphot.pexamine - Interactively examine and edit an apphot database apphot.prenumber - Renumber stars in an apphot database apphot.pselect - Select records from an apphot database apphot.psort - Sort an apphot database astcat.aclist - List the supported astrometric catalogs astcat.agetcat - Extract astrometry files from astrometric catalogs astcat.afiltcat - Filter astrometry files derived from astrometric catalogs astcat.adumpcat - Catalog access debugging task astcat.aslist - List the supported image surveys astcat.agetim - Extract FITS images from image surveys astcat.ahedit - Initialize the image wcs and set standard keywords astcat.aimfind - Select images containing catalog objects astcat.adumpim - Image survey access debugging task astcat.aregpars - Default region parameter set astcat.acatpars - Default astrometry file format parameter set astcat.afiltpars - Default astrometry file filtering parameters astcat.aimpars - Default image data parameters astcat.awcspars - Default image wcs parameters crutil.cosmicrays - Remove cosmic rays using flux ratio algorithm crutil.craverage - Detect CRs against average and avoid objects crutil.crcombine - Combine multiple exposures to eliminate cosmic rays crutil.credit - Interactively edit cosmic rays using an image display crutil.crfix - Fix cosmic rays in images using cosmic ray masks crutil.crgrow - Grow cosmic rays in cosmic ray masks crutil.crmedian - Detect and replace cosmic rays with median filter crutil.crnebula - Detect and replace cosmic rays in nebular data obsutil.psfmeasure - Measure PSF sizes from stellar images obsutil.specfocus - Determine spectral focus and alignment variations obsutil.starfocus - Determine direct focus variations from stellar images obsutil.ccdtime - CCD photometry exposure time calculator obsutil.pairmass - Plot airmass vs time for a given coordinate obsutil.sptime - Spectroscopic exposure time calculator obsutil.specpars - Spectrograph instrument parameters for sptime obsutil.bitcount - Accumulate the bit statistics for a list of images obsutil.findgain - Estimate the gain and readnoise of a CCD obsutil.shutcor - Shutter correction from images of varying exposure times nproto.objmasks - detect and catalog objects in image 4.3 Existing Packages and Tasks with New Parameters or New Parameter Defaults apphot - new package parameters wcsin, wcsout, and cache apphot.center - new parameters wcsin, wcsout, cache apphot.daofind - new parameters wcsout, cache apphot.fitpsf - new parameters wcsin, wcsout, cache apphot.fitsky - new parameters wcsin, wcsout, cache apphot.phot - new parameters wcsin, wcsout, cache apphot.polymark - new parameters wcsin, wcsout, cache apphot.polyphot - new parameters wcsin, wcsout, cache apphot.qphot - new parameters wcsin, wcsout, cache apphot.radprof - new parameters wcsin, wcsout, cache apphot.wphot - new parameters wcsin, wcsout, cache apphot.txdump - replaced by pdump, available as a hidden task astutil.setairmass - new parameters ra, dec, equinox, st, ut, scale daophot - new package parameters wcsin, wcsout, wcspsf, and cache daophot.addstar - new parameters wcsin, wcsout, wcspsf, and cache daophot.allstar - new parameters wcsin, wcsout, and wcspsf daophot.daoedit - new parameters cache daophot.daofind - new parameters wcsout, and cache daophot.group - new parameters wcsin, wcsout, wcspsf, and cache daophot.nstar - new parameters wcsin, wcsout, wcspsf, and cache daophot.peak - new parameters wcsin, wcsout, wcspsf, and cache daophot.phot - new parameters wcsin, wcsout, and cache daophot.psf - new parameters wcsin, wcsout, and cache daophot.substar - new parameters wcsin, wcsout, and cache 4.4 Existing Tasks with New Capabilities apphot.center - coordinate system support, optional image cacheing apphot.daofind - coordinate system support, optional image cacheing apphot.fitpsf - coordinate system support, optional image cacheing apphot.fitsky - coordinate system support, optional image cacheing apphot.phot - coordinate system support, optional image cacheing apphot.polymark - coordinate system support, optional image cacheing apphot.polyphot - coordinate system support, optional image cacheing apphot.qphot - coordinate system support, optional image cacheing apphot.radprof - coordinate system support, optional image cacheing apphot.wphot - coordinate system support, optional image cacheing astutil.setairmass - ra, dec, equinox, st, ut, scale are no longer hardwired astutil.rvcorrect - more flexibility in setting ut daophot.addstar - coordinate system support, optional image cacheing daophot.allstar - coordinate system support daophot.daoedit - optional image cacheing daophot.daofind - coordinate system support, optional image cacheing daophot.group - coordinate system support, optional image cacheing daophot.nstar - coordinate system support, optional image cacheing daophot.peak - coordinate system support, optional image cacheing daophot.phot - coordinate system support, optional image cacheing daophot.psf - coordinate system support, optional image cacheing daophot.substar - coordinate system support, optional image cacheing 5. General Package Changes NOAO ONEDSPEC More than 999 apertures are now allowed. APPHOT Coordinate Support: All the apphot tasks have been modified to accept input coordinates in the logical, tv, physical, or world systems, and to write output coordinates in the logical, tv, or physical coordinate systems. One consequence of this is that the apphot tasks will now work correctly on image sections in interactive mode. Another is that users can now work directly on image sections while preserving the coordinate system of the parent image. Image Cacheing Support: All the apphot tasks which accept image pixel input have been mod- ified to optional cache the entire input image in memory. Cacheing may significantly improve the performance of tasks where many random access operations are performed. File and image name directory information removed from output files All the apphot tasks have been modified to strip directory infor- mation from the image and coordinate file names written to the output files, to the terminal, and to the plot headers. The colon commands will still read and write full image and coordinate file path names. New PTOOLS Tasks Added The ptools package tasks pcalc, pconvert, pdump, prenumber, pselect and psort were added to the apphot package. The functionality of the old txdump task as been replaced by the pdump. TXDUMP is still avail- able as a hidden task. ASTCAT The astcat package is a set of tasks for extracting astrometric and photometric calibration data from remote or local catalogs, filtering the data, extracting FITS images from remote or local surveys, and adding standard keywords to the extracted images. There is also a task for selecting images which contain catalog objects and locating the catalog objects in the image. IMRED.CRUTIL Cosmic ray detection and removal package. This package includes new tasks and links to tasks from other package. It replaces the CRUTIL external package. IMRED.QUADRED Reduction package for QUAD format data. This replaces the ARED.QUAD and XCCDRED external packages for processing CTIO and ESO FORS1 multi- amplifier data. DAOPHOT Coordinate Support All the daophot tasks have been modified to accept input coordinates in the logical, tv, physical, or world systems, and to write the output coordinates in the logical, tv, or physical coordinate systems. One consequence of this is that the daophot tasks will now work correctly on image sections in interactive mode. Another is that users can now work directly on image sections while preserving the coordinate system of the parent image. Image Cacheing Support All the daophot tasks which accept image pixel input have been modified to optionally cache the entire input image in memory. Cacheing signif- icantly improves the performance of the tasks when many random access operations are performed. The cacheing already performed by the ALLSTAR task is unchanged. File and image name directory information removed from output files All the daophot tasks have been modified to strip directory information from the image and coordinate file names written to the output files, to the terminal, and to the plot headers. The colon commands will still read and write full image and coordinate file path names. OBSUTIL New observing utilities package. This collects tasks from the NMISC, SPECTIME, PROTO, and NLOCAL external package which are useful to plan or carry out observations. The new tasks are: PSFMEASURE STARFOCUS SPECFOCUS CCDTIME PAIRMASS SPTIME BITCOUNT FINDGAIN SHUTCOR OBSOLETE o Added tasks OIMCOMBINE and OIMSTATISTICS which are the previous versions from V2.113b system o Deleted the ODISPLAY task 6. General Task Changes NOAO ONEDSPEC.SPLOT Rather than refusing to evaluate errors when there is negative data, negative data is treated as zero. ASTUTIL.SETAIRMASS Modified to have greater flexibility in selecting the keyword defining the universal time. New parameters define the keywords for RA, dec, equinox, siderial time, universal time, and astrospheric scale height. ASTUTIL.RVCORRECT Modified to have greater flexibility in selecting the keyword defining the universal time. IMRED.ECHELLE.ECIDENTIFY Help page describes how to externally evaluate the dispersion fcns. IMRED.CCREDRED.COSMISRAYS Task was removed (see CRUTIL) NPROTO.FINDGAIN Task was removed (see OBSUTIL) NPROTO.OBJMASKS This is a new task for detecting objects in an image and creating an output catalog or pixel mask of found objects. TWODSPEC.LONGSLIT.FITCOORDS - Help page describes the contents of the database and how to ext- ernally evaluate the fits. - The RMS is shown in the graph title and in the :show output. TWODSPEC.APEXTRACT.APEDIT When there is just one aperture the background regions are shown on the graph without needing to enter the 'b' background mode. IMAGES TV.DISPLAY - The mask overlay feature when the displayed image is a reduction of mask (e.g. a block average) now uses the maximum of all mask pixels within the display pixel. - The task will now allow up to 16 frame buffers to be used for the display if allowed by the server. (Currently requires XIMtool V1.3). TV.IMEXAMINE - A new key 't' allows output of a region centered on the cursor as an image for further analysis by other programs. - The task will now allow up to 16 frame buffers to be used for the display if allowed by the server. (Currently requires XIMtool V1.3). - Cursor readback will now properly detect the correct image when more than one image is displayed per frame, e.g. in a mosaic. (Currently requires XIMtool V1.3). IMMATCH.IMCOMBINE - New parameters "headers", "bpmasks", "rejmasks", "nrejmasks", and "expmasks" provide additional types of output. The old parameters "rejmask" and "plfile" were removed. The new "nrejmasks" parameter corresponds to the old "plfile" and the new "rejmasks" parameter corresponds to the old "rejmask". - There is a new "combine" type "sum" for summing instead of averaging the final set of offset, scaled, and weighted pixels. - There is a new parameter "outlimits" to allow output of a subregion of the full output. This is useful for raster surveys with large numbers of images. - Additional keywords may appear in the output headers. - Scaling is now done relative to the first image rather than an average over the images. This is done so that flux related keywords such as exposure time and airmass remain representative. - A median calculation was made faster. - The previous version is available in the OBSOLETE package. IMMATCH.IMCENTROID IMMATCH.IMALIGN A new parameter maxshift has been added to the imcentroid and imalign tasks. Maxshift defines the maximum permitted difference between the predicted and computed shifts. It is used to reject objects whose positions have wandered too far from the predicted positions. IMMATCH.GEOMAP IMCOORDS.CCMAP An iterative rejection capability has been added to the geomap and ccmap tasks. The new parameter maxiter in combination with the existing parameter reject define the rejection parameter. The default value of the reject parameter has been changed from INDEF to 3.0. The colon command ":order <value>" has been added to the geomap and ccmap tasks. The new command enables the user to change all the order parameters simultaneously when experimenting with different fitting functions. IMCOORDS.STARFIND The starfind task background estimation algorithm has been modified so that it no longer depends on the value and density of the central pixel. IMCOORDS.IMCCTRAN Support for non-zenithal projections has been added to the imcctran task. The previous technique of rotating the cd matrix does not work properly for these functions. The new parameter longpole was added to imcctran. Longpole enables the user to select either the cd matrix or longpole / latpole method for transforming zenithal projections. IMCOORDS.CCGET The new task ccget was added to the imcoords package. Ccget extracts objects in a user specified region from a a simple text file catalog. IMCOORDS.CCSTD The task ccstd was added to the imcoords package. Ccstd transforms pixel and celestial coordinates to standard coordinates and vice versa. IMUTIL.HEDIT The new parameter addonly was added to hedit task. The addonly switch is used to add a parameter to the image header only if it does not already exist. The addonly switch has a precedence intermediate between the add and delete switches. IMUTIL.IMSTATISTICS An interative rejection capability has been added to the imstatistics task. The new parameters nclip, lsigma, and usigma define the rejection parameters. A memory cacheing option was also added to imstatistics in order to optionally speed up performance if iterative rejection is en- abled or the midpt/mode is computed. IMUTIL.IMEXPR Support for the bitwise operators or (|), and (&), exclusive or (^), and not (~) has been added to the imexpr task. The logical operators or (||) and and (&&) have ben made truly logical i.e. they return 0's or 1's, rather than results of a bitwise or and and. PROTO MIMSTATISTICS The new task mimstatistics has been added to the proto package. Mimstatistics does image statistics through a mask. RSKYSUB The new task rskysub was added to the proto package. Rskysub does a running mean or median sky subtraction on an ordered list of images using optional background scaling and object masking. MSKEXPR The new task mskexpr has been added to the proto package. Mskexpr creates a new mask from a user supplied expression, an optional reference image, and an optional reference mask. MSKREGIONS The new task mskregions has been added to the proto package. Mskregions creates a new mask or modifies an existing mask using a list of region definitions or region expressions. XTOOLS SKYWCS A new library skywcs has been added to the xtools package. The skywcs library is a set of routines for managing image and catalog celestial coordinate systems and for transforming from one celestial coordinate system to another. Skywcs is layered on the Starlink Positional Astronomy library slalib which is installed in the iraf math package. CATQUERY A new library catquery was added to the xtools package. The catquery library is a set of routines for doing local and remote catalog and image survey access. SYSTEM HELP Task was modified to call the XHELP code to run the GUI version of the task if requested. Task output is the same if the device remains the default 'terminal' value, however resetting the 'device' parameter to one of 'gui', 'html', or 'ps' will either spawn the GUI task under xgterm or print the converted help page to the stdout. LROFF The task was enhanced with a new 'format' parameter that allows the text to be formatted as one of: plain-text, HTML, or Postscript. 7. Parameter File Changes In the tables below each parameter change is identified with one of the following codes followed by task name and the description of the change. * n = new parameter * c = changed/modified parameter * d = deleted parameter CL n cl Added the new CL parameter "release". This is a string valued parameter with values such as "2.11.3a", "2.12", "3.0" etc. This differs from "version" which is a descriptive string such as "NOAO/IRAF V2.11.3 EXPORT". There can be multiple releases of one version of the software, and "release" specifies exactly what build the software is. The release strings are composed in such a way that they can be used in expressions, e.g. (release >= 2.11.3) would be true for IRAF V2.11.3 and all subsequent releases. DATAIO c dataio.export Made the 'format' parameter automatic mode c dataio.import Made the 'format' parameter automatic mode IMAGES n imcoords.imcctran Added a new parameter longpole to the imcctran task. If longpole=yes then coordinate transfor- mations with zenithal projections will be rot- ated using longpole rather than the CD matrix. c immatch.wregister Fixed boundary option typo, "refect" to "reflect". c immatch.sregister Fixed boundary option typo, "refect" to "reflect". n immatch.imcentroid Added a new parameter maxshift to the imcentroid immatch.imalign and imalign tasks. Maxshift is the maximum perm- itted difference between the computed and predicted shifts. Maxshift can be used to reject objects whose centers have wandered too far from the expected center. By default maxshift is undefined. n immatch.geomap Added a new parameter maxiter to the geomap and immatch.ccmap ccmap tasks. Maxiter defines the maximum number of rejection iterations and has a default value of 0 for no rejection. c immatch.geomap Changed the default value of the ccmap and geomap c immatch.ccmap parameter reject from INDEF to 3.0. c immatch.imcombine Numerous changes, see details above c imgeom.imlintran Changed the nrows argument names to nlines n imutil.hedit Added a new addonly parameter to the hedit task. If addonly is set a new field will only be added to the image header if it does not already exist. n tv.imexamine Added new parameters 'output', 'ncoutput', and 'nloutput' used by the new 't' keystroke when outputting an image section centered on the cursor. SYSTEM n help New parameters required for GUI options, output formats for HTML/PS, printer, etc. n lroff Added new 'format' parameter for HTML/PS output UTILITIES c utilities.surfit Added support for the half cross-terms option to the surfit task. This involved changing the type of the xterms parameter from boolen (yes/no) to string (none,half,full). NOAO ASTUTIL n astutil.setairmass new parameters ra, dec, equinox, st, ut, scale DIGIPHOT n apphot new package parameters wcsin, wcsout, and cache n apphot.center new parameters wcsin, wcsout, cache n apphot.daofind new parameters wcsout, cache n apphot.fitpsf new parameters wcsin, wcsout, cache n apphot.fitsky new parameters wcsin, wcsout, cache n apphot.phot new parameters wcsin, wcsout, cache n apphot.polymark new parameters wcsin, wcsout, cache n apphot.polyphot new parameters wcsin, wcsout, cache n apphot.qphot new parameters wcsin, wcsout, cache n apphot.radprof new parameters wcsin, wcsout, cache n apphot.wphot new parameters wcsin, wcsout, cache n daophot new package params wcsin, wcsout, wcspsf, and cache n daophot.addstar new parameters wcsin, wcsout, wcspsf, and cache n daophot.allstar new parameters wcsin, wcsout, and wcspsf n daophot.daoedit new parameters cache n daophot.daofind new parameters wcsout, and cache n daophot.group new parameters wcsin, wcsout, wcspsf, and cache n daophot.nstar new parameters wcsin, wcsout, wcspsf, and cache n daophot.peak new parameters wcsin, wcsout, wcspsf, and cache n daophot.phot new parameters wcsin, wcsout, and cache n daophot.psf new parameters wcsin, wcsout, and cache n daophot.substar new parameters wcsin, wcsout, and cache ONEDSPEC n standard new parameter mag, magband, and teff. These n splot params can be use to specify calibration files n lcalib as blackbody curves scale to a specified magnitude TWODSPEC c apextract.apall1 Reduced the 'polysep' parameter. c apextract.apdebug Reduced the 'polysep' parameter. c apextract.apfit1 Reduced the 'polysep' parameter. c apextract.apnoise1 Reduced the 'polysep' parameter. c apextract.apnorm1 Reduced the 'polysep' parameter. c apextract.apparams Reduced the 'polysep' parameter. 8. Details of Major System Changes 8.1 FITS kernel changes The FITS kernel was modified to add support for storing images in extensions as compressed pixel masks. The mask is stored as a binary table using the "ZIMAGE" (compressed image) convention proposed by White, Greenfield, Pence, and Tody in 1999: http://heasarc.gsfc.nasa.gov /docs/software/fitsio/compression/compress_image.html In the current implementation only the "PLIO_1" compression algorithm is implemented. Mask extensions may be read or written directly by the kernel. When writing a new extension it will be appended to the MEF file. To append an image to a MEF file as a mask, include "type=mask" in the image kernel section when the output image is opened. Masks are interfaced to the system as images and may be read and written like any other image via IMIO. They have a normal image header and can be manipulated with any program that deals with images. The pixel type is INT. It is also possible to access a mask image as a PLIO mask. An IMSTATI query for IM_PLDES parameter will return the PLIO mask descriptor. While a mask extension is opened under IMIO it is represented as a PLIO mask and may be accessed in this form like any other mask. The mask image is stored in the FITS binary table (BINTABLE) extension when the image is closed, and is loaded from the extension when the image is opened. The compression representation used to store the mask in the binary table is the same as is used within PLIO. The new (V2.12) encoding is used, allowing very large masks to be stored. Currently masks up to 3D are supported. Data on each 2D mask plane will be compressed in both X and Y as with PLIO. The depth of the mask is preserved. Although a mask is stored as a binary table the format of the table is not completely general. In the current implementation there can be only one column in the table (COMPRESSED_DATA). This is an integer-valued variable length array column containing, for each line of the N-dimensional image, the PLIO compressed version of that image line. The actual compressed data is stored in the heap area of the table. Multiple image lines may point to the same compressed line list, e.g., to store the empty line or to compression in Y. 8.2 Large Image Support The following changes were made to enable IMIO to use larger buffer sizes to optimize i/o for large images: The default file buffer size set by IMIO is unchanged: it is still about 512 MB, the value set for V2.11.2. However, a new parameter IM_BUFFRAC was added. Both IM_BUFSIZE and IM_BUFFRAC are used to help determine the FIO buffer size set when an image is opened. The logic for this is implemented in imsetbuf.x. Backwards compatibility. If you do nothing about IMIO/FIO buffers in your program, the system may transparently use a larger buffer for larger images. If you set BUFSIZE in your program, the system will by default use the value you give, or possibly a larger value, if the image you are accessing is very large. If you set BUFSIZE and you want to guarantee that the value you set is used (even for very large images) then you should also set BUFFRAC=0 to ensure that only BUFSIZE is used. How it works. BUFFRAC specifies the default FIO buffer size used to access an image, expressed as a percentage of the size of the image. For example, the builtin default value of BUFFRAC=10 will try to make a FIO buffer 10% of the size of the image. The actual value used will be given by BUFFRAC, but will be at least BUFSIZE, and no more than a builtin default maximum value, currently 32 MB. Given the builtin defaults, the buffer size will range from 0.5 to 32 MB depending upon the size of the image being accessed. As noted above, BUFSIZE and BUFFRAC can be set to force the buffer size to a specific value if desired. Environment variables for both parameters are provided. The names are "IMIO_BUFSIZE" (specified as bytes) and "IMIO_BUFFRAC" (specified as a decimal fraction). If defined, these override (at image open time) the builtin default values for both parameters. An IMSET call by the application will override all such defaults. The FIO buffer allocated will not be larger than the size of the image. The FIO buffer will also not exceed the maximum size set by the file driver being accessed. For example, for PLIO images the file buffer will not exceed about 2KB, even for a very large mask. This is because the "pixel file" for a PLIO image is dev$null, the driver for which specifies a maximum i/o buffer size of 2K (the real file to load or save the mask will use a different descriptor). The intent here is to provide an adaptive mechanism for setting the FIO buffer size used to access an image, which automatically adapts to the size of the image being accessed. If you access a lot of small images you will get smaller buffers - everything will be as before. If you access very large images, you may get large buffers up to the builtin maximum value of (currently) 32 MB. Using large buffers could cause a machine to run out of memory. However, it is likely that if someone is working on 300 MB images that they are using a machine which has a memory at least that large - probably larger. If there are problems, the environment variable overrides can be used to tune IMIO. The reason for large file buffers is to limit the number of disk data transfers, and hence the number of disk seeks. Using buffers larger than a certain amount (32 MB is generous) is probably counterproductive. If the i/o system provides 20 MB/sec i/o transfers, 32 MB will take 1.6 seconds. This should be more than a large enough granularity to provide efficient i/o, hence is a reasonable limit (at this point paging effects are likely to dominate). 8.3 Virtual Memory Cache The VMcache client interface and daemon provide a method by which data-intensive IRAF tasks (or non-IRAF tasks for that matter) can manage how files/images are maintained in virtual memory to avoid excessive system paging. In essence it's a way to "lock" a specific image in memory to improve performance. As of this release no tasks in the system have been modified to make use of the VMcache daemon, however installing it in the system at this point provides a framework for future applications and systems development. The following notes summarize the changes made for this feature and describe it's function in more detail. A more complete description of the interface, environment variables which control it, etc can be found in the main systems revisions file iraf$local/notes.v211. The source for the developmental version of the VMcache library and the VMcache daemon (vmcached) have been installed in the unix$boot tree and the HSI binary file driver was modified to add VMcache client support. This adds two new capabilities to the driver: 1) built-in support for direct i/o (on systems that support it), and 2) a client interface to the VMcache daemon to permit the daemon to optimally manage binary file i/o if a VMcache daemon is present. The vmcached code is complete but only enough debug/testing was done to support development of the VMcache client interface for IRAF (the vmcached code is debugged but the new version of the vmcache library code has not been tested). Since the daemon can be utilized outside the normal IRAF release we do not have to fully develop it for the release. It should be stressed that VMcache is only useful or warranted for systems that are very data intensive. The standard host operating system file access heuristics are best for "normal" processing where either the system is not really busy, or the datafiles are not excessively large. On systems with very large physical memories where massive amounts of data are being processed, VMcache can make a significant difference in overall system performance. VMcache is too complex to document here. Without going into the details, its function is to manage a cache of files in system virtual memory. Files can be explicitly cached or uncached, or they can be "accessed", and VMcache will decide whether or not to cache the file in virtual memory. This is what the VMcache client interface does: every time it accesses (opens or extends) a file larger then the VM threshold it sends an "access" directive to the VMcache daemon. The daemon sends back a response of 0 (file not cached; use direct i/o to access the file), or 1 (file cached in VM; use normal VM-buffered i/o to access the file). Even if a file is not cached the daemon keeps track of all accesses. Files which are frequently accessed will have a higher prority and are more likely to be cached in memory. The VMcache daemon is a separate system-level program outside of IRAF. This is necessary to provide a central system-wide cache controller. It also provides flexibility, allowing multiple versions of the daemon to exist, e.g., to allow experimentation with different types of caching algorithms. It also allows easy customization of the daemon independently of the IRAF applications using the VMcache client interface. 8.4 New Developer Libraries o Several new libraries are now available for developers: PSIO New Postscript text generation library installed in the sys$psio. The PSIO interface is used to format a block of text as Postscript output on a page of a given size (Letter, Legal, A4 or B5). See the psio$README file for details. CATQUERY Remote astrometric/photometric catalog access lib installed in the XTOOLS utility library. The catquery package provides a set of routines for local and remote catalog and image survey server access. The sup- ported catalogs and image surveys are described in records stored in a catalog and image survey configuration file respectively. The catalog and image survey records specify the network address, the query format, and the output format for each supported catalog or image display server. See "help catalogs" and "help surveys" for details. SKYWCS Sky coordinate transformation library installed in the XTOOLS utility library. The skywcs package contains a simple set of routines for managing sky coordinate information and for transforming from one sky coordinate system to another. The sky coordinate system is defined either by a system name, e.g. "J2000", "galactic", etc., or by an image system name, e.g. "dev$ypix" or "dev$ypix world". 9. System Changes Which May Affect You * SHARED LIBRARY VERSION INCREMENTED (Sun/IRAF only) The IRAF shared library for SunOS and Solaris platforms has been incremented with this release due to the nature of various system changes. Existing IRAF binaries (e.g. locally written software or external packages) will continue to run using the old shared image, however they will need to be recompiled against V2.12 in order to pick up the numerous system bug fixes and features in this release. In particular, pixel masks produced by V2.12 IRAF tasks may be incompatible with external packages which have not been recompiled. * EXTERNAL PACKAGE RECOMPILATION The V2.12 release contains changes to the FIO and PLIO/PMIO interface header files used by numerous applications. Relinking of an external package may fail to pick up these changes and not recompile a source file which uses one of these header files if the mkpkg file doesn't correctly list all of the dependencies (nearly all packages have one or more mkpkg files which have this problem). In the worst cases this could lead to a runtime error due to the incompatibilities. For this reason we recommend that all packages and local tasks be recompiled (completely from source* (rather than simply relinked against the new version) to assure that all changes and new features will be included. Recompilation also guarantees that packages can take advantage of some of the larger buffer sizes and optimizations in this release. Site support can supply a list of missing mkpkg dependencies for most external packages being developed outside NOAO that wish to fix these files for a future release. * PARAMETER FILE CHANGES As with all major releases, we recommend that you do a MKIRAF and delete all your old parameter files after the IRAF upgrade. You may choose not to do this if you are in the midst of a project and have setups that may be difficult to reproduce. The automatic parameter file update/merge mechanism, which is used if you do not initialize your parameters with MKIRAF, is based on file date comparisons. If you run IRAF V2.11 after V2.12 has been installed, the file dates on your uparm parameter files will be more recent than the V2.12 installation date. If you then try to run V2.12, the automatic parameter file merge/update will fail due to the file dates. The system only updates personal parameter files which are older than the update date of the system. A MKIRAF avoids the problem if you delete your parameter files, causing them to be updated from the system default versions. * INSTALLATION SCRIPT CHANGES As the first step of an ongoing effort to simplify the installation and system configuration, the IRAF install script was rewritten to do some error-checking of the iraf setup, present a simplified and easier to read output, and do some common post-install configuration of the system. Additionally, the SYSINFO diagnostic script for finding system errors and reporting on the configuration, and a new UNINSTALL script for removing IRAF files/links from the system have also been installed. The old install script is still available as a fallback in case problems with the new script are found. * HELP SYSTEM CHANGES The HELP task was modified with several new parameters controlling the display and formatting of the help pages. Help may now be presented as formatted text (as before), HTML, or fully formatted Postscript. Additionally, users running under an XGterm window can use the task in a new GUI mode. The help GUI allows users to browse the help system and easily search for tasks/topics using a familiar web-like interface. The GUI mode is not the default, but can be enabled easily using the 'device' parameter. * IMAGE DISPLAY CHANGES Tasks which display images or interact with the image display were modified to take advantage of new features added to XImtool V1.3 (e.g. the multiple WCS and pixel-value readouts and 16 display frame buffers). These changes were done in a backwards compatible way so interaction with display servers such as SAOimage, SAOtng, DS9, or older XImtool versions should be unaffected. If problems are dis- covered a CL environment variable 'disable_wcs_maps' can be defined to force all of the old behaviors. These changes do not add any new functionality to the tasks themselves, only the underlying display protocols. * PLIO Changes The LEN and BLEN fields of the encoded line list (LL) descriptor would limit the length of a pixel area (and hence the size of a pixel mask) to the max size of a signed short, 32768. This was due to the use of a simple array of type short to encode the line list (which simplifies handling considerably). Nonetheless the limit to 32K was unacceptable. The fix adopted was to increase the LL header from 3 to 7 words. Two 16 bit words are now used to encode each of LEN and BLEN. A "version" word was added to allow the old, new, and future encodings to be distinguished. A "hdrlen" word was added to parameterize the length of the LL header, rather than fix it at compile time as in the initial version. With this change, the maximum length of an image line under PLIO is increased from 32768 to 1073741824 (32768*32768). All the higher level PLIO code is integer, so should already support larger masks. This was done in such a way that old line lists can still be read, although PLIO will always write out new format line lists (pixel mask files and images, QPOE, and MWCS all store encoded line lists in external storage, so backwards compatibility is important; also existing complied programs will continue to generate the old format). The cost is 8 bytes per encoded line list. For most masks this should only increase the size of the mask by a few percent at most. * NEW ENVIRONMENT VARIABLES The following new environment variables may be defined to tune the size of the system file i/o buffers used by the image i/o system. The system will automatically adjust to use larger buffers when accessing larger images, these variables may be set to further optimize the buffers IMIO_BUFSIZE Size of the FIO buffer size in bytes. IMIO_BUFFRAC FIO buffer size expressed as a percentage of the image size. Actual value will be at least BUFSIZE and no more than BUFMAX. IMIO_BUFMAX Max size of FIO buffer which will override the 32Mb default. Other miscellaneous environment variables: disable_wcs_maps If defined or set to 'yes', this variable will force any tasks which interact with the image display to use the old protocols. pspage Variable which is used by the PSIO interface to set the default page size. Acceptable values include "letter" (the default) for US Letter, "legal" for US Legal, and "a4" and "b5" for the most common European sizes. Pspage can be used by the new HELP and LROFF tasks to automatically set the desired Postscript page size. IRAF (Aug97) V2.11 Revisions Summary IRAF (Aug97) IRAF V2.11 Revisions Summary August 27, 1997 Introduction Modifications and additions to IRAF V2.11EXPORT, compiled since the last documented release of IRAF, V2.10.3, are summarized below. V2.11EXPORT is a major release of IRAF and will be available for all supported platforms. These release notes provide a summary of the major changes in V2.11. More detailed technical documentation of all system changes will be found in the "notes.v210" and "notes.v211" files in the iraf$doc and iraf$local directories. 1. Things to be aware of or watch out for 1.1. Parameter file changes 1.2. Networking change 1.3. Image format change 1.4. FITS kernel 1.5. RFITS/wfits changes 1.6. Merged SunOS and Solaris IRAF systems 1.7. Tape access 1.8. Default magnitude zero changed 2. IMAGES package changes 3. Major system changes 3.1. New FITS image kernel (FXF) 3.2. Changes to the IRAF native image format (OIF) 3.3. IMFORT changes 3.4. Environment variables 3.5. New intrinsic functions 3.6. System default modifications 3.7. Libraries added 3.8. Graphics changes 3.9. FITS-related core-level task changes 3.10. General changes 4. New tasks, or old tasks moved to new packages 5. Task and package deletions 6. Modifications to old tasks 7. Parameter file changes The IRAF V2.11 release notes can also be found online on the Internet at the URL http://iraf.noao.edu/v211revs.html. 1. Things to be aware of or watch out for 1.1 Parameter file changes Since this is a major release we recommend that you do a mkiraf and delete all your old parameter files. You may choose not to do this if you are in the midst of a project and have setups that may be difficult to reproduce. Old IMAGES package parameter files will no longer be recognized, however, because of the package reorganization mentioned below. Generally, old parameter files are merged automatically with any new parameter files if there have been any changes, but if you do have problems you will need to unlearn the task before you can proceed. A list of the parameter file changes appears below and you may wish to check this list to see how this will affect your setups. The automatic parameter file update/merge mechanism, which is used if you do not initialize your parameters with mkiraf, is based on file date comparisons. If you run IRAF V2.10 after V2.11 has been installed, the file dates on your uparm parameter files will be more recent than the V2.11 installation date. If you then try to run V2.11, the automatic parameter file merge/update will fail due to the file dates. The system only updates personal parameter files which are older than the update date of the system. A mkiraf avoids the problem if you delete your parameter files, causing them to be updated from the system default versions. 1.2 Networking change The "set node = foo" syntax, used to enable remote image display under IRAF networking, has changed. The new syntax requires that an exclamation be appended to the node name as in the example below (this dates back to V2.10.4 so many users will already be familiar with the feature). cl> set node = "orion!" 1.3 Image format change The internal IRAF image format (.imh images) has changed. V2.11EXPORT can read the old image format but the new image format is not readable by V2.10.4 or earlier versions. This means that you can not easily go from the new IRAF system (V2.11) to an old one (V2.10.4 or earlier) unless you first convert the V2.11 IRAF images to FITS files. All your old V2.10.4 or earlier images are readable by V2.11EXPORT. The benefit is that the new image format is machine independent, slightly more storage efficient, and supports long file pathnames. If it is necessary to be able to read images written by V2.11 with older software, V2.11 can be made to write the old IRAF image format by setting the oifversion environment variable, e.g., "set oifversion = 1" (the default is version 2). See below for details. 1.4 FITS kernel A FITS image kernel is available in V2.11, allowing runtime read and write access to FITS files on disk. There are many related changes to IRAF image i/o and FITS support. More information on the new image kernel, and on the expanded FITS support available in V2.11, is given below. 1.5 RFITS/WFITS changes rfits and wfits have been modified to support multi-extension FITS files. The extension numbering convention used is the same as in the FITS image kernel. As a result, users who read simple FITS files on disk with a command such as "rfits diskfilename 1 foo" will find that this no longer works - instead use "rfits diskfilename 0 foo". See below for details. 1.6 Merged SunOS and Solaris IRAF systems A single installation of Sun/IRAF will now simultaneously support both SunOS and Solaris (previously separate IRAF distributions were required for each). 1.7 Tape access The "tapecap" mechanism has changed. The system now looks for the filename "tapecap.<node>" followed by the default "tapecap". <node>: should be the hostname (as used by IRAF networking) of the server hosting the tape drives described by the tapecap file. For example if host "gemini" serves up some tape drives it's tapecap file is named "tapecap.gemini". If a server-specific tapecap file is not found the default "tapecap" (on the possibly remote server node) is used. This feature allows a single IRAF installation to be shared by multiple servers. 1.8 Default magnitude zero changed The default APPHOT magnitude zero point has been changed from 26.0 to 25.0 to bring it into agreement with the DAOPHOT package default value and thereby avoid confusion for users who switch back and forth between packages. The affected APPHOT tasks are phot, photpars, polypars, polyphot, qphot, radprof, and wphot. The APPHOTX package in the addon DIGIPHOTX package will retain the old zero point values until IRAF 2.11 is released after which they will be updated. The default value of the magzero parameter in imexamine was changed from 30.0 to 25.0 for consistency with the DIGIPHOT package. 2. IMAGES package changes The IMAGES package has been reorganized by function into the 7 subpackages listed below. imcoords - Image coordinates package imfilter - Image filtering package imfit - Image fitting package imgeom - Image geometric transformation package immatch - Image matching and combining package imutil - Image utilities package tv - Image display utilities package The new IMAGES package contains a total of 82 tasks, including 26 new tasks from the IMMATCH and VOL external addon packages, 6 existing PROTO package tasks, and 1 existing NOAO.PROTO package task. The undocumented IMAGES package IMDEBUG and its 6 tasks have been deleted from the IMAGES package. User should use the tasks in the ARTDATA package instead. This reorganization of the IMAGES package should be mostly transparent to the user and not affect any existing scripts, unless you were using any of the 6 deleted tasks. By default, the IMAGES subpackages are automatically loaded when you log in to the CL. Old parameter files will not be recognized since the package names have changed. 3. Major system changes 3.1 New FITS image kernel (FXF) V2.11 introduces a new image kernel providing runtime access to FITS multi-extension image datafiles. What this means is that IRAF tasks can now read and write FITS images directly at runtime. The native IRAF image format (used by images with the .imh extension), remains the default as it is the most efficient and well-tested format. IMH, FITS, and the other types of images supported by IRAF can be used interchangeably in most IRAF tasks. Although we have extensively tested the new FITS image kernel, it is still evolving, is complex, and still has some bugs. Users should use it with caution. Please let us know of any problems. Besides support for classical FITS images, the new FITS kernel also supports multi-extension FITS files: several FITS files packed into one large file with a PHU (Primary Header Unit) that contains global header information shared by the other files. Multi-extension FITS files are 0-indexed, with the PHU being 0 and the first image extension (or other data extension) at index 1. If there is no PHU then the first FITS image is 0 and there is no global header. For further details about the FITS kernel please see the new FITS Kernel User's Guide by Nelson Zarate. 3.2 Changes to the IRAF native image format (OIF) o It was necessary to change the IRAF image format to increase the maximum path length for header and pixel files. This made it necessary to change the disk image format, since the old format only allowed 80 characters for the pixel file pathname. The path lengths can now be up to 255 characters. Support for two versions of the image and pixel file headers was added. V2.11 will read both the old image format (V1) and the new image format (V2). But the new image format is not readable by older versions of IRAF. o Native format IRAF images (OIF type or extension ".imh") are now machine independent, for example, a PC and a Sun can now access the same images. o Support was added for byte swapping pixels. With the machine independent image header, this allows .imh images to be read on any node (integer) or any IEEE-compatible node (floating). o Some pointers: "strings foo.imh" (or other tools like the "less" file viewer) can be used at the Unix level to look at the text contained in the new V2 OIF image headers. 3.3 IMFORT changes o IMFORT was brought up to date to read and write the new V2 ".imh" images. The old V1 format is still supported but new images are written using the new machine independent V2 format by default. o Image headers can now be any size (the old IMFORT had a fixed, relatively low, limit on the image header size). o The "min_lenuserarea" variable is now supported by IMFORT (since IMFORT is host level the variable must be defined in the host environment). The builtin default header buffer is 64000 chars, which is about 800 card images. 3.4 Environment variables Several new environment variable have been added to the system. o The new environment variable imextn determines the image kernels (image file formats) recognized by IRAF and defines the mapping of imagefile extensions to these image formats. A file that does not have an extension listed in imextn may not be recognized as an image by all IRAF tasks. The default value of imextn is as follows: imextn = "oif:imh fxf:fits,fit plf:pl qpf:qp stf:hhh,??h" IRAF tasks will not recognize a file as an image unless it has an extension (except rfits which will read FITS files on disk that have no extensions). The rename task can be used to add extensions to image files if needed. "imextn" can be redefined (use reset imextn = "new-value") to modify the mapping of extensions to image types. The meaning of the fields of the default "imextn" are as follows. Each substring corresponds to a single kernel. The "xxx:" is the internal name of the image kernel, i.e. "oif", "fxf", "plf", etc. A comma delimited list of the extensions, or extension patterns, associated with that image format follows the colon. For example, for the FITS image kernel, the internal kernel name is "fxf" and the system default file extensions are ".fits" and ".fit". - oif:imh - The original (native) IRAF image format. - fxf:fits,fit - The FITS image extension format, which supports classical FITS images as well as multi-extension FITS files. - plf:pl - The pixel list format used for compressed pixel masks. - qpf:qp - The QPOE image format for event list data (typically X-ray or other high energy data). - stf:hhh,??h - The Space Telescope runtime GEIS image format. Users can define extensions for the fxf and stf kernels. For example, if you have FITS files on disk that have a .ft extension then you can reset imextn so that IRAF will recognize these image extensions: cl> reset imextn="fxf:ft" The new .ft extension for the FITS kernel images will now override the default values - the other kernels remain unchanged. ".fits" will no longer be recognized as a FITS file unless you include it in the list of extensions for the "fxf" kernel. The first extension given for a kernel defines the default file extension for new images of that type (rather than e.g. the value of imtype, or a builtin default). The value of "imextn" is only read once when a process starts up. Hence it is advisable to do a "flpr" (flush process cache) after changing this variable, to force all processes to re-read it. o The environment variable imtype defines the default image type for new images created by IRAF. If a file extension is given explicitly when creating a new image then this file extension, in combination with the "imextn" mappings, determines the type of the new image. Otherwise the type is determined by the value of "imtype". Typical values are "imh" for native IRAF images, or "fits" for FITS images. The internal kernel name documented above for "imextn" can be used instead of a file extension to ensure that the desired image format is used regardless of what extensions are assigned to that type by imextn. The default value of imtype is "oif,noinherit" which means that the IRAF native format is the default for all new images, regardless of the type of the input image (i.e. do not "inherit" the input image type). "inherit" was the default in V2.10 and earlier versions of IRAF. For example, if you wish to use FITS as the default for new images you can set imtype=fits as follows: cl> reset imtype="fits" cl> flpr % needed before the next task execution Assuming "imextn" defines ".fits" as a valid file extension for FITS imagefiles (kernel "fxf"), all new images produced by IRAF will be FITS files with the extension .fits unless some other extension is given explicitly when creating a new image. cl> reset imtype = "imh,inherit" This example sets the default type for new images to ".imh" for native format images, but enables image type inheritance. By default new images will be of the same type as the input image. For example if a FITS image is being read another FITS image will be output, or if a pixel mask is being read a pixel mask will be created. You can override the default output image type specified by imtype by giving an image extension (as defined by imextn) explicitly in the image name, e.g. "pix.imh", "pix.fits", "pix.pl" and so on. o A new environment variable called imclobber has been added. The default value is set to no. If imclobber is set to yes, images can and will be overwritten, without warning, when you create new images. o The original IRAF image format (OIF) kernel now supports an environment variable oifversion which, if defined, specifies the file version for new OIF images (for example, oifversion=2 produces the new format, or version 2 images). By default the variable is undefined, the builtin OIF default will be in effect, and new-format images will be generated. This variable is provided only for backwards compatibility, e.g., when using V2.11 IRAF with old software which cannot easily be updated. 3.5 New intrinsic functions Two new intrinsic functions were added to the CL, imaccess and defvar. imaccess tests whether an image exists, e.g., (imaccess("dev$pix")) or (imaccess(foo.fits[3])). defvar tests whether an environment variable exists, e.g. (defvar("imextn")). 3.6 System default modifications o The default size of the user area (min_lenuserarea) was increased to 64000 (about 800 80 character cards). There was some ambiguity about units for min_lenuserarea; it should be consistently characters now. o The maximum number of open IRAF logical files was increased from 128 to 256. This is good news for imcombine users. o Various buffer limits were increased: - The IRAF line length was increased from 161 to 1023 characters. One often ran into this lower limit when entering a long list of input image names, for example. - CL commands can now be 2047 characters long (the old limit was 1024) - this is particularly useful for scripts. - IRAF file names can now be up to 255 characters long. - Expanded file names (pathnames) can be up to 511 characters long. 3.7 Libraries added The Starlink positional astronomy library SLALIB was added to the math package. 3.8 Graphics changes o SGI Translator change: Modified the header ID string produced by sgi2uapl to be "%!PS", this is required by certain models of printers. o Installed graphcap support for the STSDAS PostScript graphics kernel. o The SGI graphics kernel was upgraded with a better roman font, and a new greek font was added. To use the new high-quality greek fonts use the "\fG" escape sequence when you use the "T" keystroke to mark text in a plot, e.g., \fGa Hydra would produce " Hydra". The greek font may also be used in label parameters for tasks like GRAPH, for example cl> graph dev$pix xlabel="Wavelength\\fG(A)" would produce an Angstrom symbol in parenthesis. The double backslash is necessary to pass the escape string thru the CL. A file containing the mappings for the greek fonts and other special characters can be found at http://iraf.noao.edu/greek.ps. 3.9 FITS-related core-level task changes 3.9.1 IMHEADER The behavior of imheader has changed a bit - typed with no arguments it will list all the images in the current directory, as in the following example: cl> imhead pix4.imh[512,512][short]: m51 B 600s boc.fits: FXF: must specify which FITS extension (boc.fits) fits.fits[512,512][short]: m51 B 600s pix.fits[512,512][short]: m51 B 600s pix3.fits[512,512][short]: m51 B 600s pix5.fits: FXF: must specify which FITS extension (pix5.fits) zero.fits: FXF: must specify which FITS extension (zero.fits) mask.pl[512,512][int]: m51 B 600s foo.qp[1024,811][int]: The multi-extensions FITS files show up in the list with the message "FXF: must specify which FITS extension", since these files contain multiple images and the task does not know which image to open to get header information. At present imheader does not use "imextn" to determine what is and is not an image. The parameter "imlist" defines the valid imagefile extensions. If imextn is modified "imlist" may need to be modified as well. 3.9.2 RENAME The rename task was modified to allow a destination directory to be specified without changing the filename. A new "field" parameter option "all" was added and made the default so the entire filename is changed (or moved in the case of a destination directory). When field is set to "extn" filenames without an extension will not have the new extension appended so a filename isn't generated which can get overwritten. 3.9.3 rfits/wfits Some changes were also implemented in rfits and wfits to add support for multi-extension FITS files. o The default action of wfits when writing to tape is unchanged for single image files. wfits now has a new parameter called "fextn" and it is set to "fits". This parameter only affects FITS files written by wfits to disk - the extension .fits will automatically be added to the filenames, so that the files will be automatically recognized by the FITS image kernel. wfits also has two additional parameters called "extensions" and "global_hdr" that deal with writing multi-extension FITS files. o The default action of rfits from tape to disk remains unchanged. If rfits is used to read FITS files on disk then users need to be aware of a change to the behavior of the "file-list" parameter. File-list is now used to define the list of files on the tape as well as the list of extensions in a multi-extension FITS image. To read single FITS images on disk use "" as the value for "file-list". Some users have been using "1" for this value but now that value will try to read the first extension which doesn't exist - use "0" if you wish to put something there. rfits will unpack multi-extension FITS files upon a read. If you wish to retain the multi-extension FITS format then use T2D and RENAME. The help pages have been updated to reflect these changes. wfits now writes ushort (16 bit unsigned short) images to FITS images with bitpix=16, bscale=1.0, and bzero=32768.0 by default. rfits will read these images back as type ushort. 3.10 General changes o The GSURFIT package has been updated to include support for the "half" cross terms option useful in computing plate solutions. Tasks that can make use of this feature have been updated although their default behaviors have not changed. o The code which computes the CD matrix from CDELT/CROTA was modified. The old code computed the diagonal (scale) terms correctly but the rotation terms were evidently incorrect. The old code was based on the 1988 Hanisch and Wells WCS paper and the new code is based on a more recent paper by Mark Calabretta et al, which supercedes the 1988 representation. The affect of this change should be limited as it only affects rotated images for which CDELT is given but no CD matrix is defined. (V2.10.4p2) o Several new celestial coordinate projection functions have been added. Users with IPAC data that use the CAR projection function should now be able to read the image coordinates directly with LISTPIXELS, etc. 4. New tasks, or old tasks moved to new packages Task Name Package Function CCXYMATCH IMCOORDS Four new tasks for computing and evaluating CCMAP simple astrometric plate solutions and storing CCSETWC them in the image headers in fits-compatible CCTRAN format. CCFIND IMCOORDS CCFIND locate objects in an image given a celestial coordinate list and the image wcs. IMCCTRAN IMCOORDS Two new tasks for transforming celestial SKYCTRAN coordinate lists and image celestial coordinate systems from one celestial coordinate system to another. STARFIND IMCOORDS STARFIND automatically detects stellar objects in a list of images. WCSCTRAN IMCOORDS A new task for transforming between IRAF image coordinate systems. WCSEDIT IMCOORDS Two unaltered former PROTO package tasks for WCSRESET editing IRAF image coordinate systems. FRMEDIAN IMFILTER Four new tasks for doing circular/elliptical/ FRMODE ring image median filtering. RMEDIAN RMODE IM3DTRAN IMGEOM The former addon VOL package task IM3DTRAN for doing 3D image transposes. GEOXYTRAN IMMATCH A new task for transforming coordinate lists using the results of the GEOMAP task. IMCENTROID IMMATCH Four new tasks for computing matched pixel SKYXYMATCH lists. IMCENTROID is a modified version of the WCSXYMATCH PROTO package task of the same name. XYXYMATCH SKYMAP IMMATCH Two new tasks for computing geometric WCSMAP transforms using the image coordinate system information. IMALIGN IMMATCH Three new tasks for doing automated image SREGISTER registration. IMALIGN is a modified version WREGISTER of the PROTO package task of the same name. WCSCOPY IMMATCH A new task for copying the coordinate system of a reference image to a set of input images. PSFMATCH IMMATCH A new task for matching the PSFs of a set of input images to the PSF of a reference image using Fourier techniques. LINMATCH IMMATCH A new task for matching the linear intensity a scale of a set of input images to the intensity scale of a reference image. IMFUNCTION IMUTIL The former PROTO package task for applying a single argument function to an image. IMJOIN IMUTIL The former addon VOL package task for joining same-dimensioned images along a specified dimension. IMREPLACE IMUTIL The former PROTO package task IMREPLACE for replacing bad pixels based on their value. IMTILE IMUTIL A modified version of the NOAO.PROTO IRMOSAIC task for tiling same sized 2D images into a single mosaiced image. EXPORT DATAIO Two new tasks from the external IMCNV package IMPORT for exporting IRAF images to binary formats and for importing binary files into IRAF images. TEXT2MASK PROTO This new task appears in conjunction with a new pixel mask based version of FIXPIX. IMEXTENSIONS PROTO This task selects and lists image extensions in files. Image extensions currently occur in multi-extension FITS files and multi-group Geiss (STF format) files. CCDMASK CCDRED This new task creates a pixel mask from a CCD image. AIDPAR ONEDSPEC New parameter set for automatic line identification for the tasks AUTOIDENTIFY, IDENTIFY and REIDENTIFY. AUTOIDENTIFY ONEDSPEC A new task to automatically identify lines and fit the dispersion function. SKYTWEAK ONEDSPEC Sky spectra are shifted and scaled to best subtract sky features from data spectra. TELLURIC ONEDSPEC Telluric calibration spectra are shifted and scaled to best divide out telluric features from data spectra. ASTCALC ASTUTIL An astronomical calculator. ASTRADIUS ASTUTIL Finds images within a circle on the sky. 5. Task and package deletions CUBE, DUMP, GSUBRAS, MAXMIN, MKIMAGE, MKTEST: These tasks have been superseded by the equivalent tasks in the IMAGES or ARTDATA packages. The functionality of these tasks still exists in the iraf$pkg/images/lib/zzdebug.x file. REGISTER: This task has been renamed to GREGISTER. IMALIGN, IMCENTROID, IMFUNCTION, IMREPLACE, WCSEDIT, WCSRESET: Moved to the IMAGES package. 6. Modifications to old tasks Grouped by package, a list of modifications to old tasks in IRAF are summarized below. We have included modifications since the V2.10.3 release. IMFILTER: FMEDIAN, FMODE, MEDIAN, MODE Minimum and maximum good data value parameters zloreject and zhireject and a verbose option parameter were added. MEDIAN, MODE The 64 x 64 maximum kernel size limit was removed from these tasks. IMMATCH: GEOMAP Renamed the output parameter to database for the sake of consistency with other new images tasks. Changed the default value of the reject parameter from 0.0 to INDEF. Added the transforms parameter. Transforms permits the user to specify the names of the output database records explicitly. Added the parameter results. Results permits the user to save a summary of the results including a description of the transform geometry, and a listing of the input coordinates, the fitted coordinates, and the fit residuals. Added the fitgeometry parameter. Fitgeometry permits the user to constrain the linear part of the fit to: 1) x and y shifts only, 2) x and y shifts and rotation only, 3) x and y shifts and x and y scale changes only, 4) x and y shifts, rotation, and a scale change only, 5) x and y shifts, rotation, x and y scale changes only, and 5) x and shifts, rotation, skew, and x and y scale changes. GREGISTER Renamed the register task gregister to emphasize that it is paired with the geomap task and to avoid confusion with the new registration tasks. GEOTRAN, GREGISTER Renamed the transform parameter to transforms. Added the verbose parameter. GEOTRAN Added the ability to write to a section of an existing image. IMCOMBINE The limit of the number of images that may be combined has been removed. If the number of images exceeds the maximum number of open images permitted then the images are stacked in a single temporary image and then combined with the project option. Note that this will double the amount of diskspace temporarily. There is also a limitation in this case that the bad pixel mask from the first image in the list will be applied to all the images. Integer offsets may be determined from the image world coordinate system. A combination of ushort and short images now defaults to integer. Added support for type ushort images. Added a new options for computing offsets using the image wcs. Removed the limit on the maximum number of images that can be combined. IMALIGN, IMCENTROID Renamed the images parameter to input, changed the reference parameter mode from hidden to automatic, and reversed the order of the reference and coords parameters. IMUTILS: IMEXPR Modified the task so that it will accept an image name that looks like a number in the first few characters, but which is really an image name. For example, "123.imh" or "../foo.imh". The previous version of imexpr was treating any string which looked like a number in the first few characters as a numeric constant. (V2.10.4p2) IMREPLACE The lower value is now rounded up for integer images so that a range like 5.1-9.9 affects pixels 6-9 instead of 5-9. IMSUM Now allows "ushort" data types. TV: DISPLAY The bad pixel mask, overlay mask, sample mask, and overlay colors parameters and functionality have been added. The "nsample_lines" parameter is now an "nsample" parameter. Bugs in the coordinate system sent to the image display for cursor readback were fixed. IMEDIT If xorder or yorder are zero then a median background is computed for the 'a' and 'b' keys. IMEXAMINE ('a' and 'r'): The fit to the radial profile points now includes both a Gaussian and a Moffat profile. The Moffat profile exponent parameter, beta, may be fixed or left free to be fit. ('a' and 'r'): New estimates fo the FWHM were added to the 'a' and 'r' keys. These include the Moffat profile fit noted above, a direct measurement of the FWHM from the radially binned profile, and a Gaussian or Moffat fit to the radial enclosed flux profile. The output from these keys was modified to include the new information. ('a' and 'r'): The direct FWHM may be used to iteratively adjust the fitting radius to lessen the dependence on the initial fitting radius value. ('k'): Added a kimexam parameter set. The default value of rimexam.magzero parameter was changed from 30.0 to 25.0 for consistency with the digiphot package. PROTO: FIELDS The default value for the lines parameter was changed to an open upper limit. Changed the default value of the lines parameter from "1-999" to "1-" so that the upper bound would be open ended. FIXPIX This task replaces the old task (now obsolete.ofixpix) and works with the more general pixel mask facilities. It also provides greater flexibility in chosing the interpolation direction. ICFIT used in various tasks: ICFIT The :xyshow output was modified to 1) not include colon labels, 2) print (X, Y, Y fit, Weight) instead of (X, Y fit, Y), and 3) the printed values are those actually used in the fit when using composite points (naverage not 1). ARTDATA: MK1DSPEC Lorentzian and Voigt profiles were added and the parameters and input line list format were changed. The widths are now FWHM instead of gaussian sigmas. MKOBJECTS, MKNOISE The default value of "ranbuf" was changed to zero. GALLIST The default value for the minimum elliptical galaxy axial ratio was changed to 0.3 to cover the range E0-E7 uniformly. MKPATTERN Now allows ndim=0 to make an dataless header. Now allows ushort pixel type. ASTUTIL: SETJD The checking of the epoch keyword value was improved. Previously if there was a problem with the keyword value (missing or malformed) the task would use the epoch of the observation. Now it is an error if an epoch keyword is specified but the epoch value can't be determined. Also a leading 'B' or 'J' is allowed and a warning will be given if the epoch value is unlikely. ASTHEDIT There are new astronomical functions and input/output functions. The command syntax may now use "=" as a delimiter as well as the whitespace. A new parameter "update" allows protecting images and accessing read-only images for the purpose of calculating and printing quantities. The special variable name "$I" has the value of the image name, $D the current date, and $T the current time. The case of no image name creates and deletes a temporary image so the task can be used purely as a calculator (but see astcalc). CCDRED: CCDPROC The bad pixel fixing was modified to allow use of pixel masks, images, or the text file description. Bad pixel masks are the desired description and use of text files is only supported for backward compatibility. Note that support for the trimmed or untrimmed conversion from text files has been eliminated. Line-by-line overscan/prescan subtraction is now provided with three simple algorithms. COMBINE The limit of the number of images that may be combined has been removed. If the number of images exceeds the maximum number of open images permitted then the images are stacked in a single temporary image and then combined with the project option. Note that this will double the amount of diskspace temporarily. There is also a limitation in this case that the bad pixel mask from the first image in the list will be applied to all the images. Integer offsets may be determined from the image world coordinate system. Fixed a bug where a variable was improperly used for two different purposes causing the algorithm to fail. This also affected IMCOMBINE and SCOMBINE. See bug 316 for details. (V2.10.4p2) COSMICRAYS The output bad pixel data accidentally included some extra fields making it incorrect to use the file directly with BADPIXIMAGE. The extra diagnostic fields were removed. For details, see bug 311 in the buglog. (V2.10.4p2) ECHELLE: ECIDENTIFY The dispersion units are now determined from a user parameter, the coordinate list, or the database entry. IMRED Spectral Packages: DOARGUS, DOFIBERS, DOHYDRA A sky alignment option was added. The aperture identification can new be taken from image header keywords. The initial arc line identifications is done with the automatic line identification algorithm. DOSLIT, DO3FIBER The initial arc line identifications is done with the automatic line identification algorithm. ONEDSPEC: Support for the Sloan Sky Survey was added by allowing multifiber reductions with up to 500 fibers with non-linear dispersions. (V2.10.4p2) BPLOT Fixed a general problem in BPLOT and SLIST that caused a segmentation violation error. See buglog 312 for details. (V2.10.4p2) FITPROFS Modified to include lorentzian and voigt profiles. The parameters and positions file format have changed in this version. A new parameter controls the number of Monte-Carlo samples used in the error estimates. IDENTIFY The dispersion units are now determined from a user parameter, the coordinate list, or the database entry. A new key, 'e', has been added to add features from a line list without doing any fits. This is like the 'l' but without the automatic fitting before and after adding new features. A new key, 'b', has been added to apply an automatic line identification algorithm. The 'x' key has been changed to use the automatic line identification algorithm. The allows finding much larger shifts. The match parameter may now be specified either in user coordinates or in pixels. The default is now 3 pixels. The default threshold value has been changed to 0. REIDENTIFY A new parameter, "search", was added to specify a search radius for the automatic line identification algorithm. The "nlost" parameter now also applies when not tracing; i.e. it will issue a warning and not record a solution if the specified number of features is lost when reidentifying against a specific reference spectrum as is done with multispec data. The task will now work with only a warning if the reference image is absent; i.e. it is possible to reidentify given only the database. The addfeatures function will now add features before a fit if there are no reference database features. Previously features could only be added after an initial fit using the reference features and, so, required the reference database to contain features for reidentification. This new feature is useful if one wants to uses a dispersion function from one type of calibration but wants to add features for a different kind of calibration. SAPERTURES This task has been modified to allow use of image header keywords as done in the APEXTRACT package. SARITH Previously both w1 and w2 had to be specified to select a range to be used. Now if only one is specified the second endpoint defaults to the first or last pixel. The noise band in multispec data is only copied from the primary spectrum and not modified. This is a kludge until the noise is handled properly. Fixed a problem in SARITH and SCOPY where a segmentation error occurred when a wavelength range was specified in the reverse sense of the data and without rebinning. See buglog 323 for details. (V2.10.4p2) SBANDS Fixed a problem in SBANDS that caused a segmentation violation when the number of input bandpasses was greater than 10. See buglog 298 for details. (V2.10.4p2) SCOPY Previously both w1 and w2 had to be specified to select a range to copy. Now if only one is specified the second endpoint defaults to the first or last pixel. SPECPLOT The scale and offset parameters may now be a value, a filename, or and image header keyword. The 'f' key was added to toggle between world and logical pixel coordinates. SPLOT The profile fitting and deblending was expanded to include lorentzian and voigt profiles. A new parameter controls the number of Monte-Carlo samples used in the error estimates. RSPECTEXT The task now automatically senses the presence of a header. APEXTRACT: APALL, APSUM, APNOISE, APNORMALIZE, APSCATTER, APTRACE, APRECENTER, APRESIZE, APMASK, APFIND, APFLATTEN The "apertures" parameter can be used to select apertures for resizing, recentering, tracing, and extraction. This parameter name was previously used for selecting apertures in the recentering algorithm. The new parameter name for this is now "aprecenter". APALL, APSUM The "nsubaps" parameter now allows onedspec and echelle output formats. The echelle format is appropriate for treating each subaperture as a full echelle extraction. APALL The aperture ID table information may now be contained in the image header under the keywords SLFIBnnn. APSUM The dispersion axis parameter was moved to purely a package parameter. As a final step when computing a weighted/cleaned spectrum the total fluxes from the weighted spectrum and the simple unweighted spectrum (excluding any deviant and saturated pixels) are computed and a "bias" factor of the ratio of the two fluxes is multiplied into the weighted spectrum and the sigma estimate. This makes the total fluxes the same. In this version the bias factor is recorded in the logfile if one is kept. Also a check is made for unusual bias factors. If the two fluxes disagree by more than a factor of two a warning is given on the standard output and the logfile with the individual total fluxes as well as the bias factor. If the bias factor is negative a warning is also given and no bias factor is applied. In the previous version a negative (inverted) spectrum would result. RV: RVIDLINES, RVREIDLINES These tasks now work in the units of the input spectra. FXCOR The input spectra are converted to Angstroms for the crosscorrelation and analysis. Thus the velocities will be correctly computed regardless of the units of the input spectra. DAOPHOT: DAOFIND A major bug in the DAOFIND task centering code that affects the computed x and y positions was fixed. Users should refer to bug log entry number 332 for details. (V2.10.4p2) A new roundness statistic was added to the DAOFIND output to bring the task into conformance with standalone DAOPHOT II. The new statistic is sensitive to and tries to eliminate detected objects which are significantly elongated in directions other than 0, 90, 180, and 270 degrees. The original roundness statistic is stored in the ground column, the new one in the sround column. The same default roundness limits apply to both statistics. (V2.10.4p2) DAOPARS Added a new parameter "mergerad" to the DAOPARS parameter set. Mergerad permits the user to control the merging process. If mergerad is INDEF (the default setting) the default merging radius is used. If mergerad is 0 object merging is turned off altogether. Otherwise the user can set the merging radius to a specific value. Mergerad is used by the nstar and allstar tasks, but their default behavior is unchanged. (V2.10.4p2) Changed the name of the "critovlap" parameter to "critsnratio" to avoid confusion with the the meaning of the parameter especially with regard the mergerad parameter. The behavior of the parameter is unchanged. (V2.10.4p2) 7. Parameter file changes The parameter file changes below are for modifications between V2.10.4 and V2.11. For a list of parameter file changes between V2.10.3 and V2.10.4 see the file iraf/v210/params.v2104.Z in the IRAF FTP archives. In the tables below each parameter change is identified with one of the following codes followed by task_name.parameter_name and the description of the change. n = new parameter c = changed/modified parameter d = deleted parameter TV: n display.nsample: replaces nsample_lines d display.nsample_lines: replaced by nsample n display.bpmask: specify a bad pixel mask n display.bpdisplay: specify display mode for bad pixel mask n display.bpcolors: specify overlay colors for bad pixel mask n display.overlay: specify an overlay mask n display.ocolors: specify overlay colors for overlay mask n display.zmask: specify a sample mask for the zscale calculation c imedit.xorder: now allows a value of zero for median background c imedit.yorder: now allows a value of zero for median background n rimexam.fittype: specify a profile type to fit - default is now moffat n rimexam.iterations: specify number of iterations to adjust fitting radius n rimexam.beta: specify beta value for moffat fitting c rimexam.buffer: default value changed from 1 to 5 c rimexam.width: default value changed from 2 to 5 c rimexam.magzero: default value changed from 30 to 25 n wcslab.overplot: specify overplotting DATAIO: n wfits.fextn: extension to append to output disk FITS filename - default is fits n wfits.extensions: write all images to a single FITS file ? - default is no n wfits.global_hdr: prepend a global header to the FITS extensions - default is yes IMAGES: n fmedian.zloreject: good data minimum n fmedian.zhireject: good data maximum n fmedian.verbose: verbose option n fmode.zloreject: good data minimum n fmode.zhireject: good data maximum n fmode.verbose: verbose option n median.zloreject: good data minimum n median.zhireject: good data maximum n median.verbose: verbose option n mode.zloreject: good data minimum n mode.zhireject: good data maximum n mode.verbose: verbose option n geomap.transforms: list of record names n geomap.results: results summary file n geomap.fitgeometry: fitting geometry d geomap.output: renamed to database c geomap.reject: changed from 0.0 to INDEF n [g]register.verbose: verbose option d [g]register.transform: renamed to transfo n geotran.verbose: verbose option d geotran.transform: renamed to transforms c imcombine.offsets: now allows specifying "wcs" to compute offsets from WCS d imalign.images: renamed to input c imalign.reference: went from hidden to auto c imalign.coords: reversed places with reference d imcentroid.images: renamed to input c imcentroid.reference: went from hidden to auto c imcentroid.coords: reversed places with reference n imheader.imlist: default image names PLOT: n graph.ltypes: specify the line types n graph.colors: specify the colors PROTO: n fixpix.masks: new version specifies bad pixel masks n fixpix.linterp: specify mask values for line interpolation n fixpix.cinterp: specify mask values for column interpolation n fixpix.pixels: list pixels that are modified d fixpix.badpixels: new version does not use bad pixel region description c fields.lines: default value changed from "1-9999" to "1-" ARTDATA: n mk1dspec.profile: define the profile type n mk1dspec.gfwhm: replaces sigma for gaussian profile width n mk1dspec.lfwhm: width for lorentzian profile c artdata.randbuf: default value changed from 1000 to 0. c mkpattern.ndim: allows a value of 0 for a dataless header. c mkpattern.pixtype: allows ushort. c gallist.ar: default value changed to 0.3. d mk1dspec.sigma: replaced by gfwhm ASTUTIL: n rvcorrect.keywpars: added to define keywords used n asthedit.prompt: used for new calculator option n asthedit.update: update the header n asthedit.oldstyle: to allow backward compatibility APEXTRACT, IMRED spectral packages: n apnoise.apertures: select apertures to be used n apfit.apertures: select apertures to be used n apedit.apertures: select apertures to be used n apfind.apertures: select apertures to be used n apnormalize.apertures: select apertures to be used n apscatter.apertures: select apertures to be used n apsum.apertures: select apertures to be used n aptrace.apertures: select apertures to be used n apresize.apertures: select apertures to be used n apmask.apertures: select apertures to be used n apflatten.apertures: select apertures to be used n aprecenter.apertures: select apertures to be used n aprecenter.aprecenter: was what was previously the apertures parameter n apall.apertures: select apertures to be used n apall.aprecenter: was what was previously the apertures parameter ARGUS, HYDRA, SPECRED: n doargus.crval: for automatic line identifications n doargus.crdelt: for automatic line identifications n doargus.skyalign: night sky alignment option n dohydra.crval: for automatic line identifications n dohydra.crdelt: for automatic line identifications n dohydra.skyalign: night sky alignment option n dofibers.crval: for automatic line identifications n dofibers.crdelt: for automatic line identifications n dofibers.skyalign: night sky alignment option n do3fiber.crval: for automatic line identifications n do3fiber.crdelt: for automatic line identifications ARGUS, HYDRA, KPNOCOUDE, KPNOSLIT, SPECRED: c params.match: default value changed to -3 (3 pixels instead of Angstroms) c sparams.match: default value changed to to -3 (3 pixels instead of Angs) ONEDSPEC, IMRED spectral packages: d fitprofs.sigma: replaced by gfwhm d fitprofs.function: replaced by profile d fitprofs.fitsigmas: replaced by fitgfwhm d rspectext.header: removed since the task now senses the header information ONEDSPEC, LONGSLIT, IMRED spectral packages: n identify.units: specify the desired units for the dispersion function n identify.crval: for automatic line identifications n identify.crdelt: for automatic line identifications n identify.aidpars: parameter set for automatic line identifications c identify.match: default value changed to -3 (3 pixels instead of Angstroms) c identify.threshold: default value changed from 10 to 0. c reidentify.match: default value changed to -3 (3 pixels instead of Angs) c reidentify.threshold: default value changed from 10 to 0. n reidentify.crval: for automatic line identifications n reidentify.crdelt: for automatic line identifications n reidentify.aidpars: parameter set for automatic line identifications n reidentify.search: specify a search radius for the automatic line identification algorithm n ecidentify.units: specify the desired units for the dispersion function n fitprofs.profile: define the profile type n fitprofs.gfwhm: replaces sigma for gaussian profile width n fitprofs.lfwhm: width for lorentzian profile n fitprofs.fitgfwhm: replaces fitsigmas n fitprofs.fitlfwhm: select whether to fit lorentzian profile widths n fitprofs.nerrsample: allows control of the error calculation accuracy n splot.nerrsample: allows control of the error calculation accuracy CCDRED: c ccdproc.fixfile: this now specifies a bad pixel mask c combine.offsets: now allows specifying "wcs" to compute from WCS RV: n rvcorrect.par: Added the KEYWPARS pset declaration DAOPHOT: c daopars.critsnratio: critical S/N ratio for group membership - changed the name only from critovlap (V2.10.4p2) n daopars.mergerad: critical object merging radius in scale units (V2.10.4p2) IRAF (Jul92) V2.10 Revisions Summary IRAF (Jul92) IRAF Version 2.10 Revisions Summary July 1992 1. Introduction This document summarizes the changes made to IRAF in version 2.10. V2.10 is a major release of IRAF, meaning that there were significant changes to both the system and applications software, and the release will eventually be made available on all supported platforms. By IRAF version 2.10 we refer only to the core IRAF system and NOAO packages. Numerous external or "layered" packages are also available for IRAF, for example the NSO package (solar astronomy), the ICE package (data acquisition), the STSDAS package from STScI (HST data reduction and analysis), the TABLES package from STScI (tabular data), the XRAY package from SAO (X-ray data analysis), and so on. These packages are layered upon the IRAF core system, and once installed, are indistinguishable from the rest of IRAF. Layered packages are developed and maintained separately from the core IRAF release and follow independent release schedules, hence we will not discuss them further here. Contact the IRAF project or any of the outside groups supporting IRAF layered packages for additional information on what is available. This document is intended only as an overview of what is new in version 2.10 IRAF. More detailed documentation will be found in the systems and applications notes files (files sysnotes.v210.Z and pkgnotes.v210.Z in the network archive), in the online help pages, and in any reference papers or user's manuals distributed with the software. The IRAF Newsletter is a good source of information for new IRAF software. This revisions summary is organized as follows: 1. Introduction 2. IRAF System Revisions 3. IRAF and NOAO Package Revisions 3.1. Changes to the System Packages 3.2. Changes to the NOAO Packages 4. Programming Environment Revisions 4.1. Compatibility Issues 4.2. Portability Issues 4.3. Software Tools 4.4. Programming Interface Changes 5. Getting Copies of this Revisions Summary The reader is assumed to already be familiar with the basic concepts and operation of the IRAF system. In particular, familiarity with V2.9 IRAF is assumed. 2. IRAF System Revisions 2.1 Starting up V2.10 IRAF Before attempting to start V2.10 IRAF each user should run the mkiraf command in their IRAF login directory. This will create a new login.cl file and uparm (user parameter) directory. mkiraf should be allowed to delete any existing parameter files, as there have been many changes to task parameter sets in the new version of IRAF. 2.1.1 LOGIN.CL changes The login.cl file is read by the CL during startup to perform some runtime initialization and to customize IRAF for each user. A standard login.cl file is created and initialized by the mkiraf command when the user's IRAF login directory is configured. For V2.10 IRAF the login.cl file has undergone the following changes. o The IRAF version number is now checked automatically whenever you login, and a warning message will be printed if your login.cl file is out of date. If you see this message it means that important changes have been made to the login.cl file and you need to rerun mkiraf to update this file. o Most of core IRAF system packages are now loaded automatically at login time by the login.cl file. If you use a personal loginuser.cl file and you previously loaded any core system packages in this file, you should edit the file and remove those entries. o A "quiet" login option is now provided. If a file named .hushiraf exists in the login directory when you start up the CL, printing of the usual login messages will be disabled (the only output seen will be the "cl>" prompt). o On UNIX/IRAF systems the login script now looks at the host system environment variable TERM and checks for the common terminal types "sun" and "xterm", configuring the IRAF stty accordingly if either terminal type is seen (note that the default number of lines set for an xterm terminal window may need to be modified). The logic used to do this is not foolproof however, and is provided only as an example illustrating how to make use of the host system terminal definitions. You may need to customize this portion of the script, or override it in your loginuser.cl file. o The CL hidden parameter showtype is now set to "yes" by default. This will cause a character to be printed after the name of each package or named pset in CL package menus to allow these objects to be easily distinguished from ordinary tasks. Packages are marked with a trailing period (".") and psets with an ampersand ("@"). This feature can be disabled with a "showtype=no" statement. o The V2.10 login script contains a call to a new internal (non-user) IRAF task mtclean. Be sure to leave this alone, it is required for the correct operation of the new magtape i/o system. The USER package defined in the template login.cl has been extensively revised, adding many new tasks. These are mainly used to make common UNIX commands available from within the IRAF environment. Type "?user" in the CL to see what is available, e.g.: cl> ?user adb cp fc lpq mv rlogin spell top bc csh find ls nbugs rsh sps touch buglog date finger mail nm rtar strings vi cal df ftp make od ruptime su w cat diff generic man ps rusers sync wc cls du grep mkpkg pwd rwho telnet wtar comm emacs less mon rcp sh tip xc Note that since the USER package is defined in the user's login file it is easily customized to add new tasks. Refer to the existing package for examples illustrating how to do this. 2.1.2 Compatibility Issues Version 2.10 IRAF requires the new login.cl file; if the CL does not start up correctly, it may be because the user has not done a mkiraf, or because they have some construct in their loginuser.cl file which is incompatible with V2.10 IRAF. The V2.10 login file is usable with V2.9 IRAF, however this is not recommended. There have been many task parameter changes between V2.9 and V2.10. If "parameter not found" messages are seen, most likely the user has an old uparm directory, or has been switching back and forth between IRAF versions. An unlearn or mkiraf should fix the problem. The V2.10 IRAF networking system is not fully compatible with earlier versions of IRAF. This can cause problems when, e.g., a newly installed V2.10 system is used to communicate with an older version of IRAF on another system. The best solution is to update to V2.10 on all systems, but if this is not convenient it is possible to configure the networking system to avoid the problems. See the discussion of the new networking system given below. Accessing a remote magtape device via IRAF networking will not work between V2.10 and older versions of IRAF (the remote procedure calls have changed). To remotely access magtape devices you will need to install V2.10 IRAF on both the client and server nodes. In most respects installing V2.10 IRAF will be very similar to installing earlier versions of IRAF. The main difference is the tapecap file required to use the new magtape system. The old dev$devices file is no longer used. See the discussion of the new magtape system given below for more details. Due to name changes in certain low level system routines (made to avoid name clashes when linking with host level libraries) the V2.10 libraries are incompatible with older versions of IRAF. Any IRAF programs or external packages relinked under V2.10 will have to be fully recompiled or the linker will complain about unresolved externals. Note that so long as the old program is not relinked there should be no problem, even if the program uses the IRAF shared image, since the V2.9 shared image is included in V2.10 (this applies to Sun/IRAF systems only). Starting with V2.10, many IRAF applications now fully support generalized world coordinates (WCS). While in principle this should not pose any compatibility problems, the image headers do contain more information in V2.10 than previously, and there can be problems if, for example, an input image contains an illegal WCS. Previous versions of IRAF would ignore this but in V2.10 such an image could result in an error or warning message. If WCS related problems are encountered it is probably best to contact the IRAF group for help. 2.2 CL Enhancements 2.2.1 Formatted scans and prints, scan from a pipe New in the V2.10 CL (command language) are formatted scan and print routines, and the ability to scan from a pipe or other form of redirected input. These new facilities will prove most useful in CL scripts. The old unformatted scan and print routines are the following. These are still available and are the simplest routines to use where they are adequate. scan (arglist) # scan standard input fscan (list, arglist) # scan a list print (expr, exprlist) # print to standard output fprint (param, exprlist) # print to a string buffer For example, list = "filename" while (fscan (list, x, y) != EOF) print ("x=", x, "y=", y) In the above, arglist is a comma delimited list of output arguments (parameter or parameter field names) and exprlist is a comma delimited list of expressions to be printed. list is the name of a list-structured parameter to be scanned, and param is the name of a parameter, the value field of which is to receive the output string. The unformatted scan routines will automatically convert output data values to match the types of the output arguments. The new formatted routines are as follows. These take an extra format argument which tells how to parse the input string in the case of the scanf routines, or how to format the output in the case of the printf routines. scanf (format, arglist) # formatted scan from stdin fscanf (list, format, arglist) # formatted scan from a list printf (format, exprlist) # formatted print to standard output Currently there is no fprintf routine. For the printf routine the format argument is similar to that for the SPP/VOS printf (which is similar to the C printf). The format argument for the scanf routines is the same as the VOS LIBC scanf, which is patterned after the C scanf (in fact the UNIX manual page for scanf can be used as a guide to the CL scanf with only minor deviations). The following examples illustrate the new routines. cl> printf ("%d foo %7.3f\n", 5, 12.123) | scanf ("%d foo %g", i, x) cl> printf ("new values are i=%d, x=%g\n", i, x) new values are i=5, x=12.123 or, while (fscanf (list, " %*d size=%d name=%s", i, s1) != EOF) printf ("size=%05o, name=`%s'\n", i, s1) Note in the first example the use of scanf to scan from a pipe. There are actually two different versions of scan and scanf in V2.10 IRAF, an intrinsic function version and a procedure version. When called as an intrinsic function, a scan routine returns as its function value the number of operands successfully scanned, or EOF. When called as a procedure, the function value of a scan routine is discarded. Here is another example illustrating scan from a pipe, in this case using an unformatted scan since the hselect output is in a simple tabular format (hselect prints selected fields of the image header). cl> hselect dev$pix naxis,naxis1,naxis2 yes | scan (i, j, k) cl> printf ("naxis=%d, axlen=[%d,%d]\n", i, j, k) naxis=2, axlen=[512,512] When using the formatted scan routines, care must be taken to ensure that the data types implied by the format argument match the actual data types of the output parameters. The scanf routines are implemented using an internal call to the C (LIBC) scanf, with the output parameter value fields referenced directly via a pointer. If the data type is incorrect the output value may be meaningless. 2.2.2 Unlearning package parameters The unlearn task now works for package parameters as well as task parameters. In a command such as "unlearn pkgname" the package parameters for the named package will be unlearned, as well as the parameters for all the tasks in the package. This works whether or not the package is loaded. 2.2.3 Loading packages at login time A bug has been fixed which affected packages with package parameters loaded at login time. It is now permissible to load any package at login time regardless of whether it has package parameters (V2.9 users will recognize this bug as one which prevented loading CCDRED in the login script). 2.2.4 Environment variables The environment variables imtype, cmbuflen, and min_lenuserarea are now defined at login time. Previously, explicit values for these variables were not defined, and the system would use the builtin internal defaults. Explicit definitions were added so that the user can query the current value, e.g. cl> show cmbuflen 128000 A show or set with no arguments will print the full environment list. New values for these and other common environment variables may be set in the user login.cl file. 2.3 System Management Related Changes 2.3.1 Install script The UNIX/IRAF install script underwent minor changes to make it more robust. Problems are still possible if the IRAF root pathname is set to different values in the various system dependent files modified by the script. The system as shipped from NOAO has the same initial root pathname set in all such files, but problems can occur if the files are manually edited during or after installation. To avoid problems always use the install script to make system changes such as installing at a different root directory. 2.3.2 Caching of termcap entries User caching of termcap or graphcap entries with the old mkttydata task is no longer recommended. The most common entries (e.g. sun, xterm, vt100) are already cached. Modern workstations are so fast that there is no longer much point in caching termcap entries; it is sufficient to merely place local additions near the top of the file. Most programs that repeatedly access the terminal cache the entries internally during execution. Custom caching of termcap or graphcap device entries requires that the system be relinked, and the risk inherent in relinking the system (hence giving up the prebuilt, pretested binaries) is not worth the small performance gain achieved. 2.3.3 Sorting of UNIX directories The UNIX-based versions of IRAF now sort UNIX directories whenever a directory is accessed to expand a file or image template. This will fix the problem sometimes seen in earlier versions of IRAF, in which an image template could appear to be expanded in a seemingly random fashion. 2.3.4 UMASK support The UNIX-based versions of IRAF now support the host level umask file creation mask correctly. If files or directories created by V2.10 IRAF do not have the desired permissions, it is because you do not have umask set correctly at the UNIX level (most people set umask to 022). 2.4 Networking Enhancements 2.4.1 New networking driver The UNIX/IRAF networking driver has been completely rewritten for version 2.10 IRAF, with the goals of eliminating redundant password prompts, improving efficiency, and enhancing system security. For the most part the changes will be transparent to the user. Once the IRAF system manager has configured the dev$hosts file for the local site the networking system should function automatically; in the default configuration a password prompt should be seen only when connecting to a server for which rhosts ("trusted" hosts) permission is not granted. The following information is provided mainly for IRAF system managers. In normal use the user does not need to understand how the networking system functions. 2.4.1.1 How it works The IRAF networking system is an RPC (remote procedure call) mechanism for the IRAF kernel; all kernel procedures may execute either locally or remotely, and the client and server nodes do not even need to run the same operating system. IRAF applications may be distributed, and may access resources which reside anywhere on the network. IRAF networking is layered upon standard low level networking protocols such as TCP/IP and DECNET. The IRAF networking system defines one or more connection protocols which are used by a client to connect to the IRAF kernel server on a remote machine. The old networking driver supported only one connection protocol, the rexec protocol, which requires a login name and password. The new driver adds support for an rsh based protocol. This is the default connection protocol for V2.10 IRAF; automatic fallback to the rexec protocol is provided in the event that the rsh connect fails. The rsh connection protocol bootstraps off the suid-root rsh command found in most BSD derived UNIX systems (most System V systems provide the equivalent command remsh). The connection protocol is used to start the in.irafksd IRAF networking daemon on the remote server node. This daemon executes with the same uid and permissions as the account which initiated the connection, and there is one such daemon per user per server node. Once the daemon has been started via the rsh or rexec connection protocol, new client connections are made very quickly, by merely forking the daemon to create the IRAF kernel server process, and setting up a direct socket connection between the IRAF client process and the server. The daemon process runs indefinitely, shutting down if idle for longer than a certain interval (the current default is one hour). When connecting to the daemon a client must supply an authentication key to gain access to the daemon. If authentication fails the daemon shuts down and it is necessary to reestablish the connection. 2.4.1.2 The .irafhosts file The new networking driver retains the old irafhosts file, used to store information telling how to connect to various IRAF hosts (the irafhosts file is the file .irafhosts in the user's login directory). The networking system will automatically create this file for the user if the file is not found; if an old-style file is found, it will be edited by the system to make it compatible with the new networking system. While it is no longer necessary for the irafhosts file to contain password information to avoid password prompts, the file is used to store the user authentication key, hence the file should be read protected. The networking system will automatically read protect the file if it is not already protected. To avoid authentication failures when clients on different nodes attempt to connect to the same server, the same authentication code should be used on all server nodes. Unfortunately there is no way that the networking system can do this automatically (without going to some much more complicated authentication scheme, such as a key server), so users who make heavy use of the networking system should install a copy of their irafhosts file in their login directory on all server nodes. If this is not done the networking system will still work, but will be less efficient than it could be, when simultaneously accessing the same server from IRAF sessions running on multiple client nodes. The truly paranoid may not be happy with even the unique user authentication code used in the current networking system. If this is the case the port parameter (see below) may be set to zero to force rsh to be used for every connection (in effect the in.irafksd daemon has to be restarted for every connection). This imposes an overhead of as much as several seconds on every server connect. Alternatively, KSAUTH can be defined in the user environment at login time, setting the value string to some random integer value selected at login time. If defined in the user environment, KSAUTH will override the value of auth given in the irafhosts file. This approach would at least allow efficient connects for a single login process tree. The irafhosts file consists of two sections. The first section defines several networking parameters: port, auth, hiport, and timeout. The second section is a list of server nodes, with login and password information describing how to connect to each node. port = default auth = 1234567890 hiport = default timeout = default ursa : <user> ? * : <user> <user> The example above illustrates a typical irafhosts file. Typically a unique authentication code is allocated automatically by the system when the file is first created, and the other parameters retain their default values as shown (i.e., the string "default"). In the example the host list consists of an entry for the node "ursa", and an entry for everything else. The format of a host entry is "host-name : login-name password". If login-name is the reserved string "<user>" the user name on the client node is used for login authentication on the remote node. Setting the password to "<user>" as well causes the rsh connect protocol to be used; anything else causes the rexec protocol to be used. If the rexec protocol is used the password field may be set to the actual password or to the string "?", in which case the system will prompt for the password whenever a connection attempt is made. The "*" entry should always be the last entry in the list, since it matches all nodes. The default host list contains only the "*" entry. Additional information on the irafhosts file is provided in the comments in the file dev$irafhosts, and in the system notes file. 2.4.1.3 Compatibility By default the new networking system will try to use the rsh protocol to connect to the server node. If the server is running an older version of IRAF the connection attempt will hang and eventually time out. If this occurs the networking system will fall back on the rexec protocol and issue a password prompt, but by then the user will probably have interrupted the connect. The best way to avoid this problem is to update the server node to V2.10, but if this is not possible, an explicit entry for the node can be made in the irafhosts file, setting the password field so that the rexec protocol will be used. An older, e.g. V2.9 client connecting to a V2.10 server should not be a problem. In this case the V2.10 server will see an attempt to connect with the rexec protocol, which should be processed as in the past. Aside from the problem of making a connection the pre-V2.10 and V2.10 networking systems are compatible, except for the magtape i/o calls. Since the magtape driver calling sequences were changed in V2.10, remote magtape access between V2.10 and older systems is not supported. 2.4.2 The hosts file The file dev$hosts is used to interface new host machines to the IRAF networking system. This file defines, for each host, the primary host name, any aliases, and the command to be executed remotely to start up the IRAF kernel server on a remote node. The format and role of the hosts file is unchanged in V2.10. Two changes were made which affect the use of this file. o A user can now have a private copy of the hosts file. To enable this feature, the variable irafhnt (IRAF host name table) should be defined in the user's IRAF or host level environment, with the string value giving the file pathname of the user's private host name table file. o The maximum number of entries in the host name table has been increased from 64 to 128. In the current implementation these entries are statically buffered, so it is necessary to keep the maximum number of entries to a reasonable value. The hosts file must be configured to enable IRAF networking. IRAF networking is disabled if there is no entry for the local host in this file. The netstatus command may be used to examine the state of the host name table after it has been loaded by the networking system. There is another file dev$uhosts which often confuses people. This file is not used by UNIX/IRAF and can be ignored; it is there for VMS/IRAF and other IRAF implementations which do not provide the equivalent of the UNIX system routine gethostbyname. On host machines which implement name server facilities IRAF will use the name server, allowing any machine on the internet to be accessed via IRAF networking, so long as there is an entry in the system wide or user IRAF hosts file. 2.5 Magtape System Enhancements The magtape subsystem underwent a major revision in V2.10. The VOS level MTIO interface was extensively revised, and the host-level IRAF magtape driver ZFIOMT is completely new. A new device configuration facility called tapecap was introduced. Together with the new "programmable" magtape driver, this makes it possible to interface almost any removable media mass storage device to the magtape subsystem. The DATAIO applications, in particular the FITS programs, underwent minor, but important revisions. A full specification of the new magtape subsystem, particularly the tapecap facility, is beyond the scope of this document. Our intention here is merely to introduce the new facilities. A reference paper is planned, time permitting, which will fully document the new magtape system and tapecap. 2.5.1 Basic usage In most respects basic usage of the magtape system is unchanged from previous releases. Many new capabilities have been added, but these are upwards compatible with earlier releases. 2.5.1.1 Logical device names Magtape devices are still referred to in IRAF applications much as they have been in the past. Whether or not the logical device names are the same before and after the V2.10 upgrade depends upon how the IRAF system manager configures the tapecap file. The new magtape system is much more flexible than previously regarding device names, but to avoid user confusion it is recommended that the old names be supported as aliases regardless of whatever the full device name may be. As in earlier versions of IRAF, a simple magtape reference might be cl> mtexamine mta where "mta" is the device name. To examine only file 3 on the tape one might enter cl> mtex mta[3] If the device is on the remote node "ursa" the command would be cl> mtex ursa!mta[3] If the device is a 9 track tape supporting multiple densities we might specify the density explicitly, e.g. cl> mtex mta1600[3] Device names can be more complex. For example, cl> mtex mtwd might refer to a WangDAT drive, and cl> mtex mtwdc to the same drive, but with data compression enabled. Devices can have multiple names, possibly with slightly different behavior or characteristics. Device names such as "mta" are usually only host specific aliases for the lower level, host independent device names. The names "mta" and "mtb" might be aliases for the actual device names "mthp0" and "mtxt1". This can be useful in networked systems where IRAF and the tapecap file reside on a server node, but the user is running IRAF on their workstation with a local tape drive attached. In this case there may be no entry for the local drive in the installed tapecap file, but the user can still access the local drive using the lower level, host independent device entry (it is also possible to have a private tapecap file as we shall see later). To see what logical devices are known to the magtape system you can enter the following command (the task gdevices was intended for graphics devices but can be pressed into service to list a tapecap file as well). Just because a device is listed does not mean that the physical device actually exists on a particular host system. cl> gdev devices='^mt' graphcap=dev$tapecap In IRAF V2.10 it is possible to include tapecap parameters in the device specification to do clever things, as in the following example. cl> mtex "mta[:so=lepus:se:nb]" This is discussed further below in the section describing the tapecap facility. 2.5.1.2 Device allocation Device allocation operates much the same in V2.10 as in earlier versions of IRAF. The main change is that it is no longer necessary to allocate a device in order to be able to access it. It is strongly recommended however that you always allocate a device before accessing it in IRAF. If the device is not allocated anyone can access the drive, e.g., changing the tape position, and this can cause data to be lost or improperly read back. The only reason to access the drive without allocating it is if there is some problem with device allocation on your system. A device is allocated with the allocate command, e.g. cl> alloc mta A device is deallocated with deallocate. If the tape has already been unmounted use the rewind=no option to avoid accessing the drive. By default the tape will be rewound when it is deallocated. Deallocating and reallocating a drive initializes the magtape system, i.e., all cached knowledge of the status of the drive is discarded. 2.5.1.3 Device status The device status can be examined at any time that the magtape device is idle (not being actively accessed by an IRAF task) using the devstatus task. cl> devs mtc # Magtape unit mtc status Thu 12:54:02 04-Jun-92 user v14 file = 4 record = 1 nfiles = 0 tapeused = 405 pflags = 0 Of particular interest are the tapeused and nfiles fields. nfiles refers to the total number of files on the tape (if a file is appended to the tape it will be file nfiles+1). If nfiles is given as zero that means that the magtape system does not yet know how many files are on the tape (it has not seen the end of tape). tapeused reports the amount of tape used in units of kilobytes. This is intended to refer to the amount of tape used up to and including the end of tape (EOT). However, the magtape system only knows about data that it has seen, i.e. physically read or written, so whether or not tapeused is accurate depends upon how you have accessed the tape. For example, if you started out with a fresh tape and appended a number of files the number should be accurate. If you just completed a full scan of the tape with mtexamine the number should be accurate, since all the data was read. If you just put on a new tape and did a scan of the FITS headers with "rfits make-", the number may or may not be accurate, depending upon the device and how file skipping forward was done. In most cases only the header area of each file will have been read and tapeused will not reflect the full contents of the tape. If however, "rfits make-" is done immediately after writing to a new tape, the number will be accurate, since all the data was written before the tape was rescanned to print the FITS headers. Be advised that by default an explicit rewind will clear the nfiles and tapeused fields, since by default rewind initializes the magtape system. See the discussion of rewind below. In summary tapeused can be useful for monitoring how much space is left on a tape, but you have to know what you are doing. When writing to a new tape the number will be accurate so long as you avoid doing an explicit rewind. A simple procedure which will always work when mounting a non-empty tape and appending files to it, is to do an mtexamine of the tape and then append the new files. This can be time consuming for large tapes but does provide a safe and device-independent method for getting the maximum amount of data on a tape. 2.5.1.4 File positioning File positioning when accessing magtape files in IRAF is straightforward in the sense that you can simply specify the file number to read an existing file, or "append" (as in wfits new-) to append a file to an existing tape. Most tasks accept range lists to access existing files, e.g. cl> mtexamine mta file="3,5,9-11" It is even possible to position a tape to a specific record within a file. Opening a tape with file zero (as in "mta[0]") disables file positioning, allowing the tape to be positioned with host level utilities to workaround media problems. There can be problems with this simple scheme however, with modern tape devices such as DAT and Exabyte which have capacities in the gigabyte range and which may be used to store thousands of files. It is beyond the scope of a revisions summary to go into this in detail here, but a simple example will help illustrate the problem. Assume we have a tape mounted on device "mtwd" containing 900 files. We want to append image "pix" as a FITS file. The obvious thing to do is enter the following command. cl> wfits pix mtwd new- This will certainly work. The only problem is that if the tape is freshly mounted the magtape system will not know how many files there are on the tape, and it will have to skip forward one file at a time to count the files and determine where EOT is. In the worst case of a tape containing several thousand files this could literally take hours. If we know apriori the number of files on the tape, e.g., 900 in our example, the following command would be much faster (something like 10-40 seconds on most DAT drives, assuming a decent host level driver). cl> wfits pix mtwd[901] Of course, if there were actually 930 files on the tape, the last 30 files would be overwritten. There is a useful trick which works in some cases if we don't care exactly how many files are on the tape (whether this works depends upon the specific device and the host driver). Assume that we know there are several hundred files on the tape, but less than 1000. We enter the following command to append a file to the tape. cl> wfits pix mtwd[1000] If this works, after the operation the magtape system will think there are 1000 files on the tape. A subsequent "wfits new-" would be very fast regardless of the tape position, since so long as the magtape system knows where the end of tape is relative to the current position, it can get there very fast. If the trick doesn't work for your particular device or driver you will probably get a positioning error when attempting to position to a nonexistent file beyond the EOT. More automated techniques for rapid positioning with very high capacity tapes are still a matter for study. One promising technique would be to formalize the above approach by supporting EOT-relative positioning. A tape catalog based approach is also possible. The best approach may simply be to not write so many small files on large tapes, by grouping images or other data system files into a single large tape file (as with UNIX tar). None of these approaches are implemented in V2.10. 2.5.1.5 Rewind In IRAF a magtape device is rewound with the rewind command, as in the following example. cl> rewind mta By default this will not only rewind the tape but also initialize the magtape system, in the sense that all cached information regarding the named device is erased (e.g., nfiles and tapeused in the cached device status). This is necessary when changing tapes without deallocating the drive; always do an explicit rewind (or deallocate) of the device before removing a tape or mounting a new one. Having rewind initialize things is also useful if error recovery should fail following an interrupt or program abort. In some cases it may be useful to be able to do a rewind without erasing the cached device status. This is done by specifying the init- option on the command line. 2.5.2 New magtape driver The IRAF magtape driver is new for V2.10. The chief feature of the new driver is that it is programmable, via the tapecap device entry, making it possible to interface new devices or host drivers without having to make any binary code changes to IRAF. All one has to do is add a device entry in the tapecap file. 2.5.2.1 Software structure The IRAF magtape system has enough layers that it may be confusing exactly what the magtape driver is and what role it plays. A brief review of the software structure may help clarify things. Starting at the top we have applications, such as the DATAIO and MTLOCAL tasks, which can access magtape files. These use the IRAF/VOS interfaces FIO (file i/o) and MTIO (magtape i/o) to do i/o to tape devices. For the most part i/o is done with FIO and is device independent, but a call to the magtape system is required to open a magtape device. The tapecap file is read by the GTY interface, which is called by MTIO. MTIO passes the tapecap device entry as a string to ZFIOMT, the IRAF magtape device driver, when a tape file is opened. All magtape positioning and i/o is done by ZFIOMT driver under the control of the MTIO interface. Device allocation is done prior to accessing the device by the CL and is handled by the allocation routines in the ETC interface, with kernel support (this is largely independent of the magtape system). All of the code listed above is part of the portable IRAF system (i.e., is OS independent and shared by all host versions of IRAF) until we get to the ZFIOMT driver. This is in the IRAF kernel and is host system dependent. At present the only version of ZFIOMT is the UNIX version; other versions, e.g., for VMS will follow as IRAF is updated to V2.10 on these systems. The UNIX version of ZFIOMT uses only generic UNIX ioctls and should compile on most UNIX systems without change. All of the system and device dependence has been concentrated in the tapecap file. The ioctls used to communicate with a UNIX tape device are fairly standard, but the semantics are often poorly defined and are certainly not standardized. Beneath the IRAF driver are the host level magtape device drivers. A given host system may have more than one of these, typically one for each class of magtape device. Some systems, notably Sun with their ST (SCSI tape) driver, try to control more than one type of device with a single host driver. The host driver may come with the OS or may be supplied by a third party vendor. Beneath the host driver is the actual tape device. Often these days this is a SCSI tape device such as a DAT or Exabyte. These devices are intelligent peripherals; control of the physical tape hardware resides in the tape unit. There is a small computer in each tape drive which communicates with the host computer via the SCSI interface, passing commands and data back and forth. The drive will buffer 256K to 512K of data passed in bursts over the SCSI bus, and then copied to or from the physical media at a much slower rate. These drives emulate variable size records by blocking and deblocking within the drive unit, and writing fixed size blocks to the media. Features such as error correction and data compression are also handled within the drive. Although we usually speak of tape devices, the "magtape" device does not have to be a tape device at all. The IRAF magtape system can also make use of, e.g., a floppy disk, or anything that looks like a raw disk partition. The problem with the latter devices is that they usually don't support files and file positioning, hence can only be used to store one "file". 2.5.2.2 Driver features A detailed description of the magtape driver is beyond the scope of this document. Briefly, the driver supports two main classes of devices, variable record size devices and fixed block devices. All file positioning is handled by the driver, and while the driver has the device open it is responsible for keeping track of the device position (the saved device position is passed in at open time and saved by the high level code at close time). A couple of dozen tapecap parameters are defined which describe the characteristics of each device, such as whether it supports variable records, the maximum record size, whether it can backspace, and so on. A socket or file based status logging feature is provided which allows detailed monitoring of the tape status during execution (see below). In the simplest case the new magtape system, coupled with the UNIX version of the magtape driver, will emulate simple UNIX commands such as tar and mt insofar as the requests made to the host system and magtape device are concerned. That is, if one writes a series of files the only system requests made for each file will be open, write, and close. When reading a series of files in sequence the only requests made will be open, read, and close. Providing no file positioning is attempted it is possible to get by with no file positioning requests other than rewind. The driver provides extensive facilities for file positioning, using tapecap parameters to work around any shortcomings of the host system or device, but in case of trouble it is possible to operate with only open, close, read, and write requests, which should work for any device (unless it is truly broken). 2.5.3 Tapecap The tapecap file, or magtape device capabilities file, defines the magtape devices known to the system and how to access these devices. While large portions of this file depend only upon the host operating system and device type and hence are fairly site independent, it will typically be necessary to customize the tapecap file to configure the IRAF magtape system for a site. In normal use the tapecap file is invisible to the user, but users with special problems may wish to learn more about tapecap to gain more control over the behavior of the magtape system. 2.5.3.1 Using tapecap The standard tapecap file is the file dev$tapecap. A system environment variable tapecap is defined which by default points to this file. Users can customize or manipulate tapecap entries in either of two ways. The user can have their own private copy of the tapecap file (much as is currently done with the termcap and graphcap files), by resetting the value of the tapecap environment variable to point to their local copy of the file. For example, cl> reset tapecap = home$tapecap This may be necessary to customize a device entry, or add support for a local device not supported by the system wide tapecap file. It is also possible to modify a tapecap device entry "on the fly", by overriding the values of specific tapecap parameters on the command line when the device is accessed. For example, cl> mtex "mta[:so=/dev/tty]" would override the default value of the tapecap parameter "so" for device mta (in this case enabling status output logging and directing this output to the user terminal). Specifying tapecap parameters on the command line is useful for experimentation but rapidly becomes tiresome if many commands are entered. In this case it becomes simpler to redefine tapecap to include the desired tapecap parameter overrides. cl> reset tapecap = ":so=/dev/tty" As we see, the tapecap environment variable can be used to either specify the tapecap file name, or globally override specific tapecap parameters (all device entries are affected). The full form of the value string for tapecap is cl> reset tapecap = [tapecap-file] [`:' capabilities-list] Any number of colon-delimited tapecap capabilities or parameters may be given. It is beyond the scope of this document to detail all the tapecap parameters here. A reference paper for the magtape system is planned. For the present, there is a summary of the tapecap parameters in the ZFIOMT driver source file, os$zfiomt.c. For examples of actual usage refer to the tapecap file in the distributed system. 2.5.3.2 Configuring tapecap The tapecap file uses the standard "termcap" file format, originally developed for BSD UNIX and adopted long ago for IRAF. Any UNIX system will probably have a manual page defining the termcap file format, if not this can be obtained from the IRAF group. The distributed tapecap file is divided into three sections: the host machine specific device aliases (names like "mta" etc.), the site logical devices, and the generic device entries. To customize the tapecap file for a site you modify the first and second sections. To configure the tapecap file for a particular host machine you uncomment the entries for that host in the first section of the file. Sites which don't have a large network of hosts may prefer to combine the first two sections to simplify things. Site specific changes should never be made to the bottom, or generic, part of the tapecap file, as you will want to update this portion of the file when new versions of IRAF are released. Don't be intimidated by the apparent complexity of some of the tapecap device entries. In most cases the generic device entry will already exist for the device you need to interface, and all you need to do is add a site entry which references the generic entry. In some cases the generic entry itself may be sufficient (for example, in the distributed SunOS version of tapecap, logical device "mtxb0" would provide access to Exabyte unit 0 interfaced with the Sun ST driver, "mtxb1" would be the same but unit 1, "mthp0" the HP 9 track tape on unit 0, and so on). For example to interface Exabyte unit 2, using the Sun ST driver, as local device "mta", the following entry would suffice. mta| :tc=mtst2-exb: If the generic device entry provided doesn't quite work and minor modifications are needed, these should be made to the local entry and not the standard generic entry. This is easily done with termcap parameter redefinitions. For example, in SunOS 4.1.2 (but not earlier versions of SunOS) there is a bug in the Sun ST driver which necessitates rewinding the tape after a tape scan is made to position to EOT (!). The capabilities ":se:nb" can be added to the tapecap entry for the device to workaround this bug, as in the following example. mta| :se:nb:tc=mtst2-exb: The parameters mean that the device spaces past EOT in a read (se) and cannot backspace (nb). Neither of these things is actually true, but the effect is that the tape is rewound and spaced forward to get back to the desired file, working around the host level driver bug. Access will be less efficient than it should be, but the interface will work properly and the user does not have to be concerned with the problem. As a final example, suppose we need to write a new tapecap entry from scratch because there is no generic entry for the device in the distributed tapecap file. To simplify things we assume that no special tapecap parameters are needed, i.e., that the standard UNIX defaults builtin to the driver will work for the device. We are upgrading from an old version of IRAF so we already have an old dev$devices file to work with. For the purposes of our example we use an old HP 88780 1/2 tape drive entry, but pretend that the device is something which is not already supported. The old devices file entry was as follows. mta nrst20 nrst4 nrst12 nrst28 rst4 rst12 rst20 rst28 mta.6250 nrst20 nrst4 nrst12 nrst28 rst4 rst12 rst20 rst28 The minimal tapecap entry required to duplicate this is the following. mta|mta6250|HP 88780 1/2 inch tape drive:\ :al=nrst4 nrst12 nrst20 nrst28 rst4 rst12 rst20 rst28:\ :dv=nrst20:lk=st4:tc=9tk-6250: Here, the "al" parameter lists the device files to be allocated, the "dv" parameter is the device file to be used for i/o at the desired density (6250bpi in this case), and "lk" is the root file name to be used for the ".lok", or device status file. The "tc=" picks up the standard parameters for a 9 track 1/2 inch tape drive operating at 6250 bpi. Two device aliases are defined, "mta" and "mta6250". 2.5.3.3 Supported devices The IRAF magtape system itself should support almost any magtape device if properly configured. What devices are actually supported at a site depends upon the tapecap file, and in particular upon the host system (different host systems have different tapecap files). Device Driver QIC-11 cartridge tape Sun st QIC-24 cartridge tape Sun st QIC-150 cartridge tape Sun st Pertec compatible 1/2 inch drives Xylogics HP 88780 1/2 inch drive Sun st WangDAT 1300, 2000 ApUNIX HP DAT ApUNIX Exabyte 8200, 8500 ApUNIX, Sun st, Ciprico DC2000 cartridge tape A/UX tc FDHD floppy disk A/UX fd As an example, the tapecap file distributed in the V2.10.0 release of Sun/IRAF supported the devices listed in the table above. New devices are constantly being added. As V2.10 IRAF propagates to the various platforms on which IRAF is supported, similar tapecap files will be configured for those systems. 2.5.4 Status output The new magtape driver has a facility known as status output logging which can be used to monitor interactively lengthy tape jobs while i/o is in progress. The status output facility can also be useful for debugging magtape problems. In its simplest form, the status output may be directed to a file, e.g., an actual text file, or a terminal device. Status output is enabled by setting the "so" option in tapecap. For example, cl> mtex "mta[:so=/tmp/mta.out]" would enable status output logging and direct the output text to the file /tmp/mta.out. Likewise, cl> mtex "mta[:so=/dev/ttyp7]" would enable status output and direct the output to a pseudoterminal, e.g., an xterm window. When this form of status output logging is used one sees the raw, driver level status messages, as in the following example. cl> mtex "mta[:so=/dev/tty]" open device tc2n\n devtype = Apple Tape 40SC tapetype = DC2000 tapesize = 38500 density = na blksize = 8192 acmode = read file = -1 record = -1 nfiles = 0 tapeused = 0 device tc2n opened on descriptor 4\n rewinding... done\n position to file 1\n file = 1 record = 1 reading...\n recsize = 65536 record = 9 tapeused = 64 (etc.) The UNIX version of the new magtape driver also has an option to direct status output to a TCP/IP socket, which can be anywhere on the network. For this option to be useful one must have a program which will listen on the designated socket, accept the connection when the magtape driver tries to open a connection, and then read and process the status messages (which are still text, exactly as in the example above). Status output to a socket is enabled by giving a host name instead of a file name in the "so" directive: cl> mtex "mta[3:so=lepus]" to examine file 3, directing status messages to a socket on node "lepus". An X11 client application called xtapemon has been developed to listen on a socket, read messages from the tape driver, and provide a real-time display of the status of the tape device. While not included in the V2.10 IRAF distribution, this utility will be available later in 1992 as part of the X11 support package currently under development. 2.5.5 Error recovery Considerable effort went into "bullet proofing" the new magtape system to make it recover gracefully from ctrl/c interrupts or other program aborts. In practice it can be very difficult to reliably catch and recover from interrupts in a multiprocess, distributed system such as IRAF. No doubt there are still conditions under which an interrupt will leave the magtape system in a bad state, but in most circumstances the system should now be able to successfully recover gracefully from an interrupt. If it is necessary to interrupt a tape operation, it is important to understand that the host system will not deliver the interrupt signal to the IRAF process until any pending i/o operation or other driver request completes. For example, in a read operation the interrupt will not be acted upon until the read operation completes, or in a tape positioning operation such as a rewind or file skip forward, the interrupt will not be acted upon until the tape gets to the requested position. For a device such as a disk you rarely notice the delay to complete a driver request, but for a magtape device these operations will take anywhere from a few seconds to a few tens of seconds to complete. Type ctrl/c once, and wait until the operation completes and the system responds. If a magtape operation is interrupted, the IRAF error recovery code will mark the tape position as undefined (devstatus will report a file number of -1). This will automatically cause a rewind and space forward the next time the tape is accessed. The rewind is necessary to return the tape to a known position. 2.5.6 Device optimization In addition to making it possible to characterize the behavior of a magtape device to permit the device to be accessed reliably, the tapecap facility is used to optimize i/o to the device. The parameter "fb" may be specified for a device to define the "optimum" FITS blocking factor for the device. Unless the user explicitly specifies the blocking factor, this is the value that the V2.10 wfits task will use when writing FITS files to a tape. Note that for cartridge devices a FITS blocking factor of 22 is used for some devices; at first this may seem non-standard FITS, but it is perfectly legal, since for a fixed block size device the FITS blocking factor serves only to determine how the program buffers the data (for a fixed block device you get exactly the same tape regardless of the logical blocking factor). For non-FITS device access the magtape system defines an optimum record size which is used to do things like buffer data for cartridge tape devices to allow streaming. Some devices, i.e., some DAT and Exabyte devices, are slow to switch between read and skip mode, and for files smaller than a certain size, when skipping forward to the next file, it will be faster to read the remainder of the file than to close the file and do a file skip forward. The "fe" parameter is provided for such devices, to define the "file equivalent" in kilobytes of file data, which can be read in the time that it takes to complete a short file positioning operation and resume reading. Use of this device parameter in a tape scanning application such as rfits can make a factor of 5-10 difference in the time required to execute a tape scan of a tape containing many small files. On most cartridge tape devices backspacing, if permitted at all, is very slow. On such devices it may be best to set the "nf" parameter to tell the driver to rewind and space forward when backspacing to a file. 2.5.7 MTIO interface changes A number of new routines were added to the MTIO (magtape i/o) programming interface. These are documented in the summary of programming environment revisions given below. Existing magtape applications may benefit from being modified to make use of these new routines. 2.6 Graphics and Imaging Subsystem Enhancements 2.6.1 New graphics applications New tasks for histogram plotting, radial profile plotting, and producing lists of the available graphics devices have been added to the PLOT package. All of the tasks in this package were revised to add support for world coordinates. A related task for drawing world coordinate grid overlays on images or plots was added to the IMAGES.TV package. See the appropriate sections of IRAF and NOAO package revisions below for further information on these changes. 2.6.2 Graphics system changes 2.6.2.1 Encapsulated postscript SGI kernel A new encapsulated postscript SGI kernel has been added. Graphics output may be directed to any of the logical graphics devices eps, epsl, epshalf, etc. to render a plot in encapsulated postscript, e.g., for inclusion as a figure in a document. For example, cl> prow dev$pix 101 dev=eps; gflush will leave a ".eps" file containing the plot in the current directory. The command "gdev dev=eps" will produce a list of the available EPS logical graphics devices. 2.6.2.2 Graphics output to the default printer Graphics output (SGI postscript) can now be directed to the UNIX default printer device by directing output to any of the logical devices "lpr", "lp", or "lw". cl> prow dev$pix 101 dev=lpr Output will be sent to the default device for the UNIX lpr command (set by defining "PRINTER" in your UNIX environment). This makes it possible to make immediate use the distributed IRAF graphcap without having to add entries for specific local devices (although you may still wish to do so). 2.6.2.3 Tick spacing algorithm improved The algorithm used to draw the minor ticks on IRAF plots was replaced by an improved algorithm contributed by the STScI STSDAS group (Jonathan Eisenhamer in particular). This was derived from similar code in Mongo. 2.6.2.4 Graphics metacode buffer The default maximum size of the graphics metacode buffer in the CL, used to buffer graphics output for cursor mode interaction, was increased from 64K to 128K graphics metacode words (256Kb). The cmbuflen environment variable may be used to change this value. 2.6.2.5 IMTOOL changes The imtool display server (SunView) was enhanced to add additional builtin color tables, support for user color tables, and setup panel control over the screen capture facilities. A version supporting encapsulated postscript output is in testing. This will be the final version of the SunView based version of imtool (the new display servers are all X window system based). 2.6.2.6 IMTOOLRC changes The imtoolrc file, used by display servers such as imtool and saoimage to define the available image frame buffer configurations, has been relocated to the DEV directory to make it easier for local site managers to customize. The IRAF install script now uses a link to point to this file, rather than copying it to /usr/local/lib. The maximum number of frame buffer configurations was increased from 64 to 128. 2.6.2.7 X11 support The released version of V2.10 does not contain any changes insofar as X11 support is concerned. Since our X11 support code is host level stuff, with minimal ties to IRAF per se, it is being developed independently of the V2.10 release and will be distributed and installed as a separate product. 2.7 Image Structures 2.7.1 Image I/O (IMIO) The image i/o interface (IMIO) is that part of the IRAF system responsible for imagefile access and management. The changes to IMIO for V2.10 included the following. 2.7.1.1 Null images Null images are now supported for image output, much like the null files long supported by the file i/o system. For example, cl> imcopy pix dev$null would copy the image "pix" to the null image. This exercises the software but produces no actual output image. Unlike null files, null images do not work for input since images have some minimal required structure, whereas files can be zero length. 2.7.1.2 Preallocating pixel file storage In the UNIX versions of IRAF, when a new image is created storage is not physically allocated for the output image until the data is written. This is because most UNIX systems do not provide any means to preallocate file system storage. The UNIX/IRAF file creation primitive zfaloc, used by IMIO to create pixel files, now provides an option which can be used to force storage to be physically allocated at file creation time. This feature is enabled by defining the environment variable ZFALOC in the UNIX environment. For example, % setenv ZFALOC can be entered before starting IRAF to cause space for all pixel files to be preallocated as images are created. If it is not desired to preallocate all image storage (there is a significant runtime overhead associated with preallocating large images) then a value string can be given to specify which types of images to preallocate storage for. For example, % setenv ZFALOC /scr5 would preallocate only those pixel files stored on the /scr5 disk, and % setenv ZFALOC "/scr5,zero" would preallocate only images on /scr5, or images containing the substring "zero" in the image name. In general, the string value of ZFALOC may be the null string, which matches all images, or a list of simple pattern substrings identifying the images to be matched. In most cases the default behavior of the system, which is to not physically allocate storage until the data is written, is preferable since it is more efficient. The preallocation option is provided for users who, for example might have an application which spends a lot of time computing an image, and they want to ensure that the disk space will be available to finish writing out the image. 2.7.1.3 Image templates now sorted As mentioned earlier in the System Management section, UNIX/IRAF now sorts UNIX directories. One result of this is that the sections of image templates which are expanded via pattern matching against a directory will now be sorted, or at least logically ordered (the final output list will not necessarily be fully sorted if string substitution is being performed - this is the reason the output list itself is not sorted). 2.7.1.4 The dev$pix test image Minor changes were made to clean up the image header of the standard test image dev$pix. A second test image dev$wpix has been added. This is the same image, but with a different header containing a test world coordinate system (actually the image is just a second image header pointing to the dev$pix pixel file, now shared by both images). 2.7.2 Image kernels (IKI) The IMIO image kernels are the data format specific part of the IRAF image i/o subsystem. Each kernel supports a different image format. Existing disk image formats range from the conventional image raster formats (OIF and STF) to the photon image format (QPF and QPOE) and the pixel mask image format (PLF and PMIO/PLIO). There also exist special image kernels which allow IMIO to be used to access non-disk storage devices such as image display frame buffers. 2.7.2.1 New PLF image kernel A new image kernel, the PLF image kernel, has been added which allows IRAF PMIO/PLIO pixel masks to be stored as images. This kernel first appeared as a patch to version 2.9 IRAF but was actually developed within V2.10. Pixel mask images may be created, deleted, read, written, etc. like other IRAF images, but the image is stored in a special compressed format designed specially for image masks. An image mask is an N-dimensional raster-like object wherein typically there are regions of constant value but arbitrary shape. Masks are used by applications involving image decomposition. The image is decomposed into regions of different types, the type of region being very dependent upon the type of image analysis being performed. A special type of mask image is the bad pixel mask, used to flag the bad pixels in an image. Other applications use masks for data quality, to identify the region or regions to be used for analysis, and so on. A PMIO image mask is a special case of a PLIO pixel list. Masks can exist and be accessed independently of the image i/o system, but the PLF image kernel allows a mask to be stored and accessed as an IRAF image. Any IRAF application which operates upon images can operated upon a mask image. For example, the imcalc (image calculator) program in the SAO XRAY package can be used to combine images and masks, or compute new masks by evaluating an algebraic expression over an image. Mask images have the reserved image extension ".pl". Some of the features of mask images are illustrated by the following example. cl> imcopy dev$pix pix.pl dev$pix -> pix.pl cl> imstat dev$pix,pix.pl # IMAGE NPIX MEAN STDDEV MIN MAX dev$pix 262144 108.3 131.3 -1. 19936. pix.pl 262144 108.3 131.3 6. 19936. This is a sort of worst case test of the mask encoding algorithm, since our test image is not a mask but a noisy image (and hence not very compressible). Note that masks must be positive valued, hence the MIN value is different for the two images. Storing dev$pix as a mask does not result in any significant compression, but for a real mask very high compression factors are possible. The compression algorithm used in PLIO is simple and fast, combining 2D run length encoding and a differencing technique in a data structure allowing random access of multidimensional masks (masks are not limited to one or two dimensions). For further information on pixel lists and pixel masks, see the document plio$PLIO.hlp in the online system. This is also available as plio.txt.Z in the IRAF network archive. 2.7.2.2 OIF image kernel changes The OIF image kernel is the kernel for the old IRAF image format - this is still the default IRAF image format. Revisions to the OIF kernel for V2.10 included the following items. o A valid image header is now written even if an application which writes to a new image is aborted. Previously, the pixel file would be written but the image header would be zero length until the image was closed. If an image creation task aborts the image will likely be incomplete in some way, e.g., part of the pixels may not have been written to, or the header may be missing application specific keywords. By valid image header we mean that the header will be valid to IMIO, allowing the image to be accessed to try to recover the data, or to delete the image. o The image header file of a new image is now written to and closed at image create time, then reopened at image close time to update the header. This frees one file descriptor, an important consideration for applications which for some reason need to write to dozens of output images simultaneously. o The OIF image kernel uses file protection to prevent inadvertent deletion of the image header file. In UNIX/IRAF systems file delete protection is simulated by creating a ".." prefixed hard link to the file. This could cause problems with images if the user deleted the image header file outside of IRAF, leaving the ".." prefixed link to the file behind. A subsequent image create operation with the same image name would fail due to the existence of the hidden ".." prefixed file. It is unlikely that such a file (with a ".." prefix and a ".imh" extension) could ever be anything but an old IRAF image header file, so the system will now silently replace such files when creating a new image. A couple of related system changes were made which, while not implemented in the OIF kernel, do involve the OIF or ".imh" image format. The default template login.cl now defines the environment variable imtype and sets it to "imh". The environment variable min_lenuserarea is also defined now at login time, with a default value of 20000, allowing image headers with up to about 250 header parameters. 2.7.2.3 STF image kernel changes The STF image kernel is the kernel for the online HST (Hubble Space Telescope) image format. This format allows multiple images to be grouped together in a single "group format" image. There is a common image header stored in a FITS-like format, as well as a small fixed format binary header associated with each image in the group. o A check was added for a group index out of range. This yields a more meaningful error message about no such group, rather than having IMIO complain about a reference out of bounds on the pixel file. o Support was added for non-group STF images (GROUPS=F in the header). At first glance a non-group group format image might seem a little silly, but it turns out that a non-group STF image with a zero length group parameter block is very close to "FITS on disk", since the header is FITS-like and the image matrix is simple. It is still not true FITS since the header and pixels are stored in separate files and the pixels are not encoded in a machine independent form, but on UNIX hosts which are IEEE standard and not byte swapped, it comes close enough to be useful for communicating with external applications in some cases. A true FITS image kernel is planned for IRAF. This will probably appear in one of the V2.10 patches, sometime during 1992. 2.7.2.4 QPF image kernel changes The QPF image kernel is the interface between the QPOE (position ordered event file) interface and IMIO, allowing QPOE event files to be accessed as images by general IRAF applications. Photon "images" are unique in that the image raster is generated at runtime as the image is accessed, optionally passing the photon list through event attribute and spatial filters, and sampling the photons to produce a raster image. For example, cl> imcopy "snr[time=@snr.tf,bl=4]" snr.imh would filter the event list stored in the file "snr.qp" by the time filter stored in file "snr.tf", sample the image space blocking by a factor of 4, and store the resultant image raster in the OIF image file "snr.imh". cl> display "snr[time=@snr.tf,bl=4]" 1 would display the same image raster without creating an intermediate disk image. The changes to the QPF interface for V2.10 included the following. o A bug was fixed which would prevent very long filter expressions from being correctly recorded in the IMIO image header. The current version of IMIO stores applications header parameters in FITS format, hence multiple FITS cards are required to store long filter expressions. The bug would cause only one such card to be output. o A new facility was added which allows general expressions to be computed for the input event list and stored as keywords in the output image header. The header of the input QPOE file can contain one or more parameters named defattr1, defattr2, and so on. If present, the string value of each such parameter should be a statement such as exptime = integral time:d which will cause a keyword named "exptime" to be added to the output image header, the scalar value of the keyword being the value of the expression on the right. Currently, only the integral function is provided. This computes the included area of a range list field of the event attribute expression, such as a time filter. In the example, "time" is the name of the event attribute to be integrated, and the ":d" means use a range list of type double for the computation. The data types currently supported are integer, real and double. Other minor changes to QPF included improvements to the error recovery, and other changes to support very large filters. 2.7.3 World coordinate system support (MWCS) MWCS is the IRAF world coordinate system package, one of the major new system interfaces developed for the new image structures project. A full description of the MWCS interface is given in the file mwcs$MWCS.hlp in the online system, and in the file mwcs.txt.Z in the IRAF network archive. 2.7.3.1 Applications support MWCS was first released in V2.9 IRAF and at the time the interface was new and few applications were yet using it. In V2.10 IRAF most (but not all) applications which deal with coordinates now use MWCS. These include all of the system plotting tasks, and the spectral reduction packages. Details of the MWCS support added to the system and science applications in V2.10 are given in the IRAF and NOAO package revisions section of this revisions summary. 2.7.3.2 New function drivers Function drivers for the arc, sin, and gls nonlinear sky projections were added, as well as a special function driver for the multispec image format. The latter allows general programs which don't know anything about spectra to access and display spectra in world coordinates, e.g., for plotting. 2.7.3.3 WCS attributes The maximum number of "attributes" per WCS was increased from 64 to 256, mainly to support the multispec function driver, which makes heavy use of attributes. A limit on the size of a single attribute value string was removed, allowing arbitrarily large attribute values to be stored. 2.7.3.4 Axis mapping Axis mapping is now fully implemented. Axis mapping is used when, for example, you extract a 2 dimensional section from a 3 dimensional image and write the result to a new image. Axis mapping allows the 2 dimensions of the new image to be mapped backed into the original 3 dimensional WCS, making it possible to get the full physical coordinates (which are 3 dimensional) for any point in the extracted image. A new header keyword WAXMAPnn was added to store the axis map in image headers. 2.7.3.5 MWCS save format The newer IRAF image formats such as QPOE are capable of storing arbitrarily complex objects such as a MWCS in an image header keyword. In the case of a stored MWCS object, the MWCS interface is responsible for encoding the object in its external storage format, and restoring it to a MWCS descriptor when the MWCS is accessed. The code which does this was revised to add a new version number for the stored V2.10 MWCS, to make it possible to differentiate between the MWCS save formats used in V2.9 and V2.10 and allow recovery of MWCS objects from data files written under V2.9. 2.7.3.6 Bug fixes Since MWCS is a new interface and V2.10 saw its first real use in applications, a number of interface bugs were discovered and fixed. Most of the bugs turned out to be in the part of MWCS which converts between the internal MWCS WCS representation, and the FITS WCS representation, used for those image formats that still use FITS-like headers. Bug fixes included a problem with the treatment of CROTA2, a problem with the FITS CD matrix, an axis mapping problem that caused "dimension mismatch" errors, and a problem with support for the old-style CDELT/CROTA which could result in a singular matrix during WCS inversion when compiling a transformation. 2.7.4 Event files (QPOE) The QPOE interface is the interface responsible for creating and accessing event files, the main data format produced by event counting detectors. We summarize here the main enhancements to QPOE made during the preparation of V2.10. Some of these features appeared earlier in the patches made to V2.9 IRAF but these revisions have never been formally documented so we summarize both the old and new revisions here. See also the discussion of the QPF image kernel given earlier. 2.7.4.1 Blocking factors The builtin default blocking factor, when sampling the event list to make an image raster, is one. This may be changed on a per-datafile basis by defining the parameter defblock in the QPOE file header. 2.7.4.2 Parameter defaults Since parameters such as the blocking factor can be set at a number of levels, a parameter defaulting scheme was defined to determine the precedence of parameter overrides. The lowest level of precedence is the builtin default. Next is any datafile specific value such as defblock. A value such as blockfactor set in the QPDEFS file will override the datafile default value if any. Specifying the parameter value in a runtime filter expression or qpseti call is the highest order of precedence and will override any other setting. Another way to think of this is the more recently the parameter was set, the higher the precedence. The oldest value is the default builtin to the code. Next is the datafile value, usually set when the datafile was created. Next is the QPDEFS macro file, usually set by the user or for a site. Last (highest precedence) is the value set by the user when the data is accessed. 2.7.4.3 Referencing the current datafile in macros A special symbol $DFN is now recognized during macro expansion and if present is replaced by the filename of the current QPOE file. This allows macros to be written which automatically perform some operation involving the datafile to which they applied, e.g., computing an attribute list from aspect or data quality information stored in the datafile header. 2.7.4.4 Bitmask expressions Bitmask expressions may now be negated, e.g., "%3B" is the mask 03 octal, "!%3B" or "!(%3B)" is the complement of 03 octal. 2.7.4.5 Large time filters A number of changes and bug fixes were made to QPOE for V2.10 to support large time filters. These are lists of "good time" intervals used to filter the event list. These large time filters may contain several hundred double precision time intervals spanning the exposure period. Often a large time filter is combined with a complex spatial filter (PLIO mask) to filter an event list consisting of from several hundred thousand to several million events. QPOE can handle this efficiently regardless of whether the data is temporarily or spatially sorted and regardless of the complexity of the temporal or spatial filters. A number of minor bugs were fixed caused by the large filter expressions overflowing various buffers. The default sizes of the program and data buffers used to compile filter expressions were increased to allow all but very large filters to be compiled without having to change the defaults. If the buffers overflow more space can be allocated by setting the progbuflen and databuflen parameters in QPDEFS (these buffers are not dynamically resized at runtime for efficiency reasons). During testing with large time filters it was discovered that a routine used to test floating point equality was being used inefficiently, and compilation of large time filters was taking a surprisingly long time. A change was made which reduced the time to compile large filters by a factor of 10 to 15. 2.7.4.6 Default filters QPOE now fully supports default event attribute and spatial filtering of data at runtime. The idea is that the full data set (all events) is stored in the QPOE file, along with default event attribute and spatial filters. When the data is accessed these filters are, by default, automatically applied. Any user specified event attribute or spatial filters are "added" to the builtin default filters to produce the combined filter used when the event list is accessed. The point of all this is to make it easy for the user to modify or replace the default filters and "reprocess" the raw event list. In effect the raw and processed event list are available in the same file. The default filter and mask, if any, are stored in the datafile header parameters deffilt and defmask. If the datafile contains multiple event lists a default filter or mask may be associated with each list by adding a period and the name of the event list parameter, e.g., "deffilt.foo" would be the default filter for the event list "foo". By default, if a default filter or mask exists for an event list it is automatically applied when the event list is accessed. Use of the default filter or mask can be disabled in QPDEFS with either of the following statements: set nodeffilt set nodefmask The default filter and mask can also be disabled in a filter expression by adding a "!" before the expression, as in the following example. display "snr[!time=@times.lst,pha=(3,8:11)]" There are actually several variants on the "=" assignment operator used in filter expressions such as that above. The operator "=" is equivalent to "+=", meaning the expression term on the right adds to any existing filter specified for the event attribute on the left. The operator ":=" on the other hand, means replace any existing filter by the new filter expression. 2.7.4.7 Alternate coordinate systems The event structure used to represent each event in an event list may contain multiple coordinate systems if desired, for example, detector and sky coordinates. One coordinate system should be defined as the default when the event list is created, and if the event list is to be indexed it must be sorted using the coordinate system specified as the default. Any coordinate system may be used when the data is accessed however; this can result in quite different views of the same data set. For example, cl> display snr.qp 1 would display the QPOE file "snr.qp" in display frame 1, using all defaults for the event list, blocking factor, filter, mask, and so on. The default event coordinate system would probably be sky coordinates. To display the same event list in detector coordinates, one could enter the following command. cl> display "snr.qp[key=(dx,dy)]" 1 This assumes that the event structure fields "dx" and "dy" are defined somewhere, either in the datafile header or in QPDEFS (otherwise the actual field datatype-offset codes must be given). Currently if the QPOE datafile has a WCS associated with it this WCS can only refer to one coordinate system, normally the default event coordinate system. Additional WCS can be stored in the QPOE file, either in the stored MWCS object or as separate MWCS objects, but at present there is no mechanism for selecting which will be used (if the parameter qpwcs exists in the QPOE file header, this is assumed to be a stored MWCS object and this is the WCS which will be used). 2.8 System Specific Changes 2.8.1 Sun/IRAF Since V2.10 has only just been completed and at this stage has only been released on Sun platforms, there are few system specific revisions to report. For SunOS there were several system specific revisions worth noting here. o The HSI binaries for the sparc architecture are now statically linked. This makes them considerably larger, but avoids problems with SunOS complaining about shared library version mismatches (note that we refer here to to Sun shared libraries - this is not a problem with the IRAF shared library facility since we control the version numbers). o The HSI binaries for the Motorola architectures (f68881 and ffpa) are not statically linked since they cannot be without running into linker problems warning about f68881_used etc. To avoid or at least minimize warnings about SunOS shared library versions the system was linked on 4.1.1 instead of 4.1.2. SunOS 4.0.3 versions of the Motorola HSI binaries are also available upon request. o The system as distributed was linked with the name server library, -lresolv. This means that if the local host is configured to use the name server, IRAF will be able to access almost any host on the Internet without an entry in the /etc/hosts file on the local host. Additional system specific changes will be reported in the documentation distributed with each release, as V2.10 is moved to the various platforms for which IRAF is supported. 3. IRAF and NOAO package revisions The revisions for the various packages in the IRAF core system and in the NOAO packages are summarized below. There have been many changes with this release. Users are encouraged to refer to the help pages, user's guides provided with some packages, revisions notes, and more recent issues of IRAF Newsletters for more details. Comprehensive notes on systems and applications modifications are in the files pkgnotes.v210.Z and sysnotes.v210.Z in the directory iraf/v210 in the network archive. This summary can be read online by typing news. Revisions notes for the various packages can also be accessed online as in the following example. cl> phelp dataio.revisions opt=sys One of the system changes that affects many tasks in the IMAGES, PLOT, and LISTS packages as well as most tasks in the spectroscopic packages in NOAO is the full implementation of the world coordinate system (WCS), introduced in V2.9 but not fully integrated into the IRAF and NOAO tasks at that time. There are currently three classes of coordinate systems: the logical system is in pixel units of the current image section; the physical system is in pixel units of the parent image (for a WCS associated with a raster image); the world system can be any system defined by the application, e.g. RA and DEC or wavelength. In general, this should be transparent to the user since most defaults have been chosen carefully so that tasks perform the same as in V2.9. The NOAO spectroscopic tasks also use the WCS extensively, but again, this should be transparent to the user, although it can cause some problems with backward compatibility. Users will notice the biggest difference in the image headers with additional keywords added by the interface. Two tasks in the PROTO package may help the interested user understand more about the WCS - see wcsedit and wcsreset. Technical notes on the WCS are available in a paper in the iraf$sys/mwcs directory. Type the following to read more about the MWCS interface. cl> phelp mwcs$MWCS.hlp fi+ 3.1 Changes to the IRAF system packages 3.1.1 DATAIO package modifications o The output defaults for wfits have been modified. If the pixel type on disk is real or double precision the output will be IEEE format (FITS bitpix = -32 or -64, respectively). If the pixel type on disk is short integer then the output will be integer format (bitpix = 16) as before. These defaults can of course be changed by modifying the parameters for wfits. o The wfits "blocking_factor" parameter can accept values up to and including 10 for variable blocked devices, i.e. 1/2" tape drives, Exabytes, and DATs. If the "blocking_factor" parameter is set to "0", as in the default, the value is read from the "fb" parameter in the tapecap file (usually 10 for variable blocked devices). For fixed blocked devices such as cartridge tape drives the default value for the "fb" parameter in the tapecap file is 22 (used to determine a buffer size) and the block size of the device is given by the "bs" parameter. o All tasks were modified to accept tapecap parameters as part of the magtape file name syntax. Tapecap parameters can now be appended to the magtape file name to add to or override values in the tapecap file. For example, "mta6250[:se]" is a valid magtape file name (the "" are important when tapecap parameters are specified at execution time). See the file os$zfiomt.c for more details about the tapecap parameters. o The rfits task has been modified to permit a short last record, i.e. a last record that has not been padded out to 2880 bytes. No warning messages are issued. o rfits was modified to map ASCII control characters in the header to blanks. o The sequence number appended to disk file names by rfits and wfits was modified to 4 digits, i.e. 0001 - 9999. 3.1.2 IMAGES package modifications o WCS (world coordinate system) support was added to all tasks in the IMAGES package that could introduce a coordinate transformation. Some tasks had already been modified for the V2.9 release. These tasks (blkavg, blkrep, geotran, imcopy, imlintran, imshift, imslice, imstack, imtranspose, magnify, register, rotate, and shiftlines), upon execution, will update the image header to reflect any transformation. o The listpixels task was modified to list the pixel coordinates in either logical, physical, or world coordinates. A format parameter was added to the task for formatting the output pixel coordinates taking precedence over the WCS in the image header, if used. o A new imcombine task was added to the package. This new task supports image masks and offsets, and has an assortment of new combining algorithms. See the help pages for complete details on this powerful new task. o The imhistogram task has a new "binwidth" parameter for setting histogram resolution in intensity units. o The default values for the parameters "xscale" and "yscale" in the register and geotran tasks were changed from INDEF to 1.0, to preserve the scale of the reference image. 3.1.3 IMAGES.TV package reorganization and modifications o The TV package has been reorganized. The IIS dependent tasks have been moved into a subpackage, TV.IIS. The imedit, imexamine, and tvmark tasks that were previously in PROTO have been moved to TV. o A new task wcslab developed at STScI by Jonathan Eisenhamer was added to the package. wcslab overlays a labeled world coordinate grid on an image using WCS information stored in the header of the image or in parameters of the task. o imexamine was modified to use WCS information in axis labels and coordinate readback, if selected by the user. Two new parameters, "xformat" and "yformat", were added to specify the format of the WCS if it is not present in the header of the image. o A new option was added to imexamine to allow for fitting 1D gaussians to lines or columns. o tvmark had two cursor key changes. The "d" keystroke command that marked an object with a dot was changed to "."; the "u" keystroke command that deleted a point was changed to "d". 3.1.4 LISTS package modifications o Two new parameters were added to the rimcursor task, "wxformat" and "wyformat". These parameters allow the user to specify the coordinate formats for the output of the task and override any values stored in the WCS in the image header. 3.1.5 OBSOLETE package added o An new package called OBSOLETE was added. Tasks will be moved to this package as they are replaced by newer tasks in the system. OBSOLETE tasks will then be removed at the time of the next release. o mkhistogram, imtitle, radplt, and the old imcombine task have been moved to the OBSOLETE package. Users should become familiar with phistogram, hedit, pradprof, and the new imcombine and use them instead since mkhistogram, imtitle, radplt, and oimcombine will be retired with the next release. 3.1.6 PLOT package modifications o A new task called phistogram was added to the PLOT package. This task takes input from an image or from a list and allows full control over the plotting parameters. This task replaces the obsolete.mkhistogram task. o A new task pradprof was added to the PLOT package. This task plots or lists the radial profile of a stellar object. This task replaces the obsolete.radplt task. o A new task called gdevices was added to the package. gdevices prints available information known about a particular class of device. The default parameters are set up to print a list of the available stdimage devices in the standard graphcap file. o WCS support was added to the tasks graph, pcol(s), and prow(s). A new parameter called "wcs" was added to define the coordinate system to be used on the axis, either logical, physical or world. Two additional parameters, "xformat" and "yformat", were also added to allow the user to set the format for axis labels overriding any values in the image header. The "xlabel" parameter values were extended to include the special word "wcslabel" to select the WCS label for the x axis from the image header. o WCS support was added to the task implot. A new parameter called "wcs" was added to define the coordinate system for plotting, either logical, physical, or world. Two new ":" commands were also added: ":w" allows the user to set a new WCS type interactively; ":f" allows the user to change the axis format, for instance, ":f %H" would change the axis to read h:m:s, if the world coordinate RA had been defined in the image header. The "space" key now prints out the coordinate and pixel value information. o graph has a another new parameter "overplot" that allows the user to overplot multiple plots with different axes. o The default parameters for "floor" and "ceiling" in contour and surface were changed to INDEF. 3.1.7 PROTO package reorganization and modifications This package has been reorganized. The PROTO package now resides in the core system. Tasks in the old PROTO package that were general image processing tools were kept in this new PROTO package. Tasks that were more data reduction specific were moved to the new NPROTO package in the NOAO package. The current PROTO package now contains the tasks binfil, bscale, epix, fields, fixpix, hfix, imalign, imcentroid, incntr, imfunction, imreplace, imscale, interp, irafil, joinlines, suntoiraf, wcsedit, and wcsreset. o The new task hfix was added to the package. This task allows the user to extract the image headers into a text file, view or modify this file with a specified command, and then update the image header with the modified file. o A new task called suntoiraf was added to this package. This is a host dependent task that will most likely be useful only on Sun's. This task converts a Sun raster file into an IRAF image. o Two new tasks dealing with the WCS were added to this package, wcsreset and wcsedit. wcsreset resets the coordinate systems in the image header to the logical coordinate system. wcsedit allows the user to modify the existing WCS or to create a new WCS and then update the image header. o A new version of bscale was added to the package. The task now takes a list of input images and output images. o A new version of imfunction was added to the package. The task supports many more functions, for example log10, alog10, ln, aln, sqrt, square, cbrt, cube, abs, neg, cos, sin, tan, acos, asin, atan, hcos, hsin, htan, and reciprocal. o imreplace was modified to support the "ushort" pixel type. o The task join has been renamed joinlines. 3.1.8 Additions to XTOOLS and MATH Programmers may be interested in the following new additions to the XTOOLS and MATH libraries. o The interactive non-linear least squares fitting package INLFIT, developed by Pedro Gigoux at CTIO, was added to XTOOLS. o The 1D image interpolation routines in the MATH library were modified to support sinc interpolation. 3.1.9 Glossary of new tasks in the IRAF core system Task Package Description gdevices plot List imaging or other graphics devices hfix proto Fix image headers imcombine images Combine images pixel-by-pixel phistogram plot Plot or print the histogram of an image or list pradprof plot Plot or list the radial profile of an object suntoiraf proto Convert Sun rasters into IRAF images wcsedit proto Edit the image coordinate system wcslab tv Overlay an image with a world coordinate grid wcsreset proto Reset the image coordinate system 3.2 Changes to the NOAO Packages An updated version of the observatory task has been installed at the NOAO level. The task sets observatory parameters from a database of observatories or from the parameters in the task itself. Many packages and tasks within the NOAO packages that need information about where the data was observed use information supplied by the observatory task. 3.2.1 ARTDATA package modifications A new version of the ARTDATA package was released with IRAF version 2.9.1. A summary of those changes plus modifications since that update are listed below. A more comprehensive list of the changes included in V2.9.1 are discussed in IRAF Newsletter Number 10. o A new task mkechelle has been added that creates artificial 2D echelle images. o A new task mkexamples has been added. The task is intended to generate a variety of artificial images to be used in testing or demonstrations. o A new task mkheader adds or modifies image headers using a header keyword data file. o The mk1dspec task was modified to create multispec and echelle format images, line by line. o A parameter "header" was added to mkobjects, mknoise, mk1dspec, and mk2dspec so that a header data file could be added to the output image. Other header parameters are also added to the image header such as gain, rdnoise, and exptime. o A "comments" parameter was added to various tasks to include/exclude comments in the header of the output image that describe the data parameters. 3.2.2 ASTUTIL package modifications o A new task gratings has been added to the package. This task computes grating parameters; five of the seven parameters must be specified at one time. o A new task setjd has been added to the package. setjd computes the geocentric, heliocentric, and integer local Julian dates from information given in the headers of the input list of images. This information is then listed or added to the image headers. o A few changes were made to setairmass. The default value for "update" was changed to "yes"; an update field was added to the "show" messages; a warning is printed if both "show" and "update" are set to "no" indicating that nothing was done. 3.2.3 DIGIPHOT package modifications A new version of the DIGIPHOT package was installed. Some changes were made to the existing APPHOT package used for aperture photometry, and those are mentioned below. But three new packages have also been installed, DAOPHOT, PHOTCAL, and PTOOLS. DAOPHOT has been available for the past two years as an add-on package known as TESTPHOT. It is now part of the distributed system. The IRAF version of DAOPHOT, used to do photometry in crowded fields, has been a collaborative effort with Peter Stetson and Dennis Crabtree of the DAO. For the convenience of the many TESTPHOT users, changes to the package since the last release of TESTPHOT are summarized below. PHOTCAL is the photometric calibration package for computing the transformations of the instrumental magnitudes output from APPHOT and DAOPHOT to the standard photometric system. This package has been a collaborative effort with Pedro Gigoux at CTIO. PTOOLS is a package containing an assortment of tools for manipulating the data files produced from APPHOT and DAOPHOT. If users are using STSDAS TABLES format data files then they must first install the TABLES layered package. This package can be obtained from either STScI or NOAO (see iraf/contrib in the IRAF network archive). 3.2.4 DIGIPHOT.APPHOT package modifications o The apselect task was replaced with the functionally equivalent txdump task. txdump allows the user to select fields of data from the output data files produced from APPHOT tasks and either simply list the extracted data or save it in another file. o A new task called pexamine has been added to the package. pexamine is a general purpose tool for interactively examining and editing the data files produced from tasks in either APPHOT or DAOPHOT. This task is intended to complement the batch oriented task txdump. o All of the APPHOT tasks will now query to verify the "datamin" and "datamax" values, if these values are used by the tasks. o The time of the observation, i.e. UT, can now be carried over into the output data files, if a keyword in the image header contains this information. o If there is bad data within the photometry aperture a value of INDEF will be stored in the data file for that magnitude. 3.2.5 DIGIPHOT.DAOPHOT (TESTPHOT) package modifications This is a new package but for the convenience of the many users of the TESTPHOT add-on package, the changes to TESTPHOT between its last release and its installation into the DIGIPHOT package as DAOPHOT are summarized below. o The append, convert, dump, renumber, select, and sort tasks were renamed to pappend, pconvert, pdump, prenumber, pselect, and psort. o The "text" parameter was moved from daopars to the DAOPHOT package parameters. o All the DAOPHOT routines were modified so that "psfrad", "fitrad", and "matchrad" are defined in terms of scale. o The tasks allstar, group, nstar, peak, psf, and substar were all modified to include "datamin" and "datamax" in their verify routines. o Support was added for a time of observation parameter to all the appropriate DAOPHOT tasks. If present, this time will be carried over into the output data files. o All the DAOPHOT tasks except psf have been modified to accept lists of input and output files. o The new pexamine task was added to this package. pexamine is a general purpose tool for interactively examining and editing the data files produced from tasks in either APPHOT or DAOPHOT. This task is intended to complement the batch oriented task txdump. o Several changes were made to psf: the default PSF image header will now hold up to 66 stars (but it is still dependent on the environment variable min_lenuserarea); a check was added so that the same star can not be added to the PSF twice; potential PSF stars are now rejected if their sky or magnitude values are INDEF; a check was added so that stars with INDEF valued positions are treated as stars that were not found. o group was modified so that the groups are output in y order instead of in order of the size of the group. o Both group and peak were modified so that stars with INDEF centers are not written to the output file. 3.2.6 IMRED package modifications The spectroscopic packages within the IMRED package have undergone quite a bit of work and reorganization. The spectroscopic packages are now ARGUS, CTIOSLIT, ECHELLE, HYDRA, IIDS, IRS, KPNOCOUDE, KPNOSLIT, and SPECRED. These packages are a collection of tasks from APEXTRACT and ONEDSPEC that are appropriate for the specific applications. All these packages use the new versions of the APEXTRACT and ONEDSPEC packages; the changes for APEXTRACT and ONEDSPEC are summarized below. Earlier versions of all these packages were released as the NEWIMRED add-on package. The NEWIMRED package is now defunct and the distributed system contains the latest versions of these packages. The spectroscopic packages now contain "DO" tasks that are scripts that streamline the reduction process for the user. The "DO" tasks have been modified for each particular application. The ARGUS package is for the reduction of data taken with the CTIO argus instrument. Its corresponding script task is doargus. The CTIOSLIT package is similar to the ARGUS package except that is a collection of spectroscopic tasks used for general CTIO slit reductions. The doslit task allows for streamlined reductions. The ECHELLE package has the addition of the doecslit task for simplied echelle reductions. The dofoe task has been added for the reduction of Fiber Optic Echelle (FOE) spectra. The HYDRA package is used for the reduction of multifiber data taken at KPNO. The dohydra task has been customized for streamlining nessie and hydra reductions. The KPNOCOUDE package has been customized for the KPNO Coude. The doslit task allows the user to go through the reduction process with as few keystrokes as possible. The do3fiber task is specialized for the 3 fiber (two arc and one object) instrument. The KPNOSLIT package can be used for general slit reductions at KPNO. The doslit task in this package is similar to that in the other packages. The SPECRED package is the old MSRED package, used for general multispectral reductions. This is a generic package that can be used for slit and multifiber/ aperture data. General doslit and dofibers tasks are available. Several of the spectroscopic packages has a special task called msresp1d for creating 1d aperture response corrections from flat and throughput data. This task is specialized for multiaperture or multifiber data. All of the "DO" tasks have reference manuals that are available in the network archive in the iraf/docs directory. 3.2.7 IMRED.CCDRED package modifications o A new task ccdinstrument was added to the package. The purpose of this task is to help users create new CCD instrument translation files to use with the package. o The combine task (as well as darkcombine, flatcombine, and zerocombine) is the same task as the new imcombine task in IMAGES. A few parameters were added for compatibility with the CCDRED tasks. o A new parameter was added to ccdproc called "minreplace". Pixel values in flat fields below the value for "minreplace" are replaced by the same value (after overscan, zero, and dark corrections). This avoids dividing by zero problems. o The default computation and output "pixeltype" in the package parameter for CCDRED are both real. Note that both can now be specified separately. o The default parameters for darkcombine and flatcombine have been changed. 3.2.8 NOBSOLETE package added This new package has been defined but currently no tasks reside in it. This package will be used as a repository for tasks that have been replaced by newer tasks in the NOAO packages. The NOBSOLETE tasks will then be removed at the time of the next release. 3.2.9 NPROTO package modifications The old PROTO package was divided into two separate packages, one called PROTO that now resides in the IRAF core system and the other called NPROTO that resides in the NOAO package. The current NPROTO tasks are binpairs, findgain, findthresh, iralign, irmatch1d, irmatch2d, irmosaic, linpol, and slitpic. The imedit, imexamine, and tvmark tasks were moved to the IMAGES.TV package. The ndprep task was moved to ONEDSPEC. All other tasks were moved to the PROTO package at the core level. o Two new tasks called findgain and findthresh were added to this package. findgain determines the gain and read noise of a CCD from a pair of dome flats and from a pair of bias/zero frames using the Janesick method. findthresh estimates the background noise level of the CCD using a sky frame and the gain and readnoise of the CCD. o A new task called linpol has been added to the PROTO package. This task calculates the pixel-by-pixel fractional linear polarization and polarization angle for three or four images. The polarizer must be set at even multiples of a 45 degree position angle. o The task ndprep used for CTIO 2DFRUTTI reductions was moved to the ONEDSPEC package. o The task toonedspec was removed since its function can now be performed by the onedspec.scopy task. 3.2.10 ONEDSPEC package reductions There have been significant changes to the ONEDSPEC package. A more detailed revisions summary is available in the IRAF network archive as file onedv210.ps.Z in the subdirectory iraf/docs. The new package supports a variety of spectral image formats. The older formats can still be read. In particular the one dimensional "onedspec" and the two dimensional "multispec" format will still be acceptable as input. Note that the image naming syntax for the "onedspec" format using record number extensions is a separate issue and is still provided but only in the IMRED.IIDS and IMRED.IRS packages. Any new spectra created are either a one dimensional format using relatively simple keywords and a two or three dimensional format which treats each line of the image as a separate spectrum and uses a more complex world coordinate system and keywords. For the sake of discussion the two formats are still called "onedspec" and "multispec" though they are not equivalent to the earlier formats. In addition, the one dimensional spectral tasks may also operate on two dimensional images. This is done by using the "dispaxis" keyword in the image header or a package dispaxis parameter if the keyword is missing to define the dispersion axis. In addition there is a summing parameter in the package to allow summing a number of lines or columns. If the spectra are wavelength calibrated long slit spectra, the product of the longslit.transform task, the wavelength information will also be properly handled. Thus, one may use splot or specplot for plotting such data without having to extract them to another format. If one wants to extract one dimensional spectra by summing columns or lines, as opposed to using the more complex APEXTRACT package, then one can simply use scopy (this effectively replaces proto.toonedspec) Another major change to the package is that spectra no longer need to be interpolated to a uniform sampling in wavelength. The dispersion functions determined by identify/reidentify can now be carried along with the spectra in the image headers and recognized throughout the package and the IRAF core system. Thus the WCS has been fully implemented in the ONEDSPEC tasks and although much is to be gained by this it can cause problems with earlier IRAF systems as well as making it difficult to import data into non-IRAF software. But it is now possible to use imcopy with an image section on a spectrum, for instance, and have the wavelength information retained correctly. A sinc interpolator is now available for those tasks doing geometric corrections or interpolations. This option can be selected by setting the "interp" parameter in the ONEDSPEC package parameters. Other changes are summarized: o The new task deredden corrects input spectra for interstellar extinction, or reddening. o The new task dopcor corrects input spectra by removing a specified doppler velocity. The opposite sign can be used to add a doppler shift to a spectrum. o The new task fitprofs fits 1D gaussian profiles to spectral lines or features in an image line or column. This is done noninteractively and driven by an input list of feature positions. o The task ndprep was moved to this package from the PROTO package. ndprep is used for CTIO 2DFRUTTI reductions. o The new task sapertures adds or modifies beam numbers and aperture titles for selected apertures based on an aperture identification file. o The new task sarith does spectral arithmetic and includes unary operators. The arithmetic can be performed on separate input spectra or on apertures within a multispec format image. o The task scombine has been added to the package. This new task is similar to the new imcombine task in the IMAGES package but is specialized for spectral data. o The new task scopy copies subsets of apertures and does format conversions between the different spectrum formats. o The new task sfit fits spectra and outputs the fits in various ways. This includes a new feature to replace deviant points by the fit. Apertures in multispec and echelle format are fit independently. o The tasks addsets, batchred, bswitch, coincor, flatdiv, flatfit, subsets and sums were moved to the IIDS and IRS packages. o The task combine was removed with the all new scombine suggested in its place. o The tasks rebin, sflip and shedit were removed from the package. Rebinning of spectra can now be done with scopy or dispcor. scopy and imcopy can now be used in place of sflip. And hedit is an alternative for shedit. o bplot and slist have been modified to support the multispec format. o The task continuum now does independent fits for multispec and echelle format spectra. o There is now only one dispcor task doing the work of the three previous tasks dispcor, msdispcor and ecdispcor. Several of the parameters for this task have been changed. The old "recformat" and "records" parameters for supporting the old onedspec format have been removed except in the IIDS/IRS packages. A "linearize" parameter has been added for setting the interpolation to yes or no on output. The "interpolation" parameter was removed since this information is now read from the package parameter "interp". The "ignoreaps" parameter has been changed to "samedisp". o identify and reidentify now treat multispec format spectra and two dimensional images as a unit allowing easy movement between different image lines or columns. The database is only updated upon exiting the image. The "j", "k", and "o" keys have been added to the interactive sessions to allow for scrolling through the different lines in a two dimensional image. The database format now uses aperture numbers rather than image sections for multispec format spectra. o The task specplot has new parameters "apertures" and "bands" to select spectra for plotting in the multispec format. o splot now allows deblending of any number of components and allows simultaneous fitting of a linear background. Several cursor keys have been redefined and colon commands have been added to fully support the new multispec format and to add even more flexibility to the task than before! Please see the help pages for details. o The reidentify task is essentially a new task. The important changes are an interactive review option, the ability to add features from a line list, using the same reference spectrum for all other spectra in a 2D reference image rather than "tracing" (using the results of the last reidentification as the initial guess for the next one) across the image, and matching image lines/columns/apertures from a 2D reference image to other 2D images rather than "tracing" again. 3.2.11 RV package added This is a new package installed with IRAF version 2.10. A version of this package, RV0, has been available as an add-on for the past year or so. The package contains one main task fxcor that performs a Fourier cross-correlation on the input list of spectra. The package supports the multispec format. 3.2.12 TWODSPEC package modifications The old MULTISPEC package that has resided in the TWODSPEC package for years has been disabled. The code is still there for browsing, however, and the package can be resurrected easily if needed. The observatory task was moved to the NOAO package itself. The setairmass task was moved to LONGSLIT. And the setdisp task is no longer needed; task or package parameters are used in its place. Changes to the APEXTRACT and LONGSLIT packages are summarized below. 3.2.13 TWODSPEC.APEXTRACT package modifications A new version, version 3, of the IRAF APEXTRACT package has been completed. A detailed revisions summary is available in the IRAF network archive (file apexv210.ps.Z in iraf/docs). There were three goals for the new package: new and improved cleaning and variance weighting (optimal extraction) algorithms, the addition of recommended or desirable new tasks and algorithms (particularly to support large numbers of spectra from fiber and aperture mask instruments), and special support for the new image reduction scripts in the various IMRED packages. The multispec format, the default image format for all spectroscopic packages except IIDS and IRS, is either 2D or 3D (the 3D format is new with this release). The 3D format is produced when the parameter "extras" is set to yes in the extraction tasks. The basic 2D format, which applies to the first plane of the 3D format, has each 1D aperture spectra extracted in a line. Thus, the first coordinate is the pixel coordinate along the spectra. The second coordinate refers to the separate apertures. The third coordinate contains extra information associated with the spectrum in the first plane. The extra planes are: 1: Primary spectra which are variance and/or cosmic ray cleaned 2: Spectra which are not weighted or cleaned 3: Sky spectra when using background subtraction 4: Estimated sigma of the extracted spectra If background subtraction is not done then 4 moves down to plane 3. Thus: output.ms[*,*,1] = all primary spectra output.ms[*,5,1] = 5th aperture spectrum which is cleaned output.ms[*,5,2] = raw/uncleaned 5th aperture spectrum output.ms[*,5,3] = sky for 5th spectrum output.ms[*,5,4] = sigma of 5th spectrum The following summarizes the major new features and changes. o New techniques for cleaning and variance weighting extracted spectra have been implemented. o Special features for automatically numbering and identifying large numbers of apertures have been added. o There is no longer a limit to the number of apertures that can be extracted. o The new task apall integrates all the parameters used for one dimensional extraction of spectra. o The new task apfit provides various types of fitting for two dimensional multiobject spectra. o The new task apflatten creates flat fields from fiber and slitlet spectra. o The new task apmask creates mask images from aperture definitions using the new pixel list image format. No tasks have yet been written, however, to use this new mask image format. o The new tasks and algorithms, aprecenter and apresize, will automatically recenter and resize aperture definitions. o The task apio is defunct. Its functionality has been replaced by the APEXTRACT package parameters. o The task apstrip has been removed. o Minor changes have been made to the old "AP" tasks to accommodate these new changes in the package; in some cases new parameters have been added to the task and in other cases new cursor options have been implemented. See the help pages for details. 3.2.14 TWODSPEC.LONGSLIT package modifications o The "dispaxis" parameter was added to the package parameters. This value is used unless DISPAXIS is in the image header. 3.2.15 Glossary of new tasks in the NOAO packages Task Package Description addstar daophot Add artificial stars to an image allstar daophot Group and fit psf to multiple stars apall apextract Extract 1D spectra apfit apextract Fit 2D spectra apflatten apextract Remove shapes from flat fields apmask apextract Create an IRAF pixel mask from apertures aprecenter apextract Recenter apertures apresize apextract Resize apertures ccdinstrument ccdred Review instrument translation files centerpars daophot Edit the centering algorithm parameters chkconfig photcal Check the configuration file continpars rv Edit continuum subtraction parameters daofind daophot Find stars using the DAO algorithm daopars daophot Edit the daophot algorithms parameter set datapars daophot Edit the data dependent parameters deredden onedspec Apply interstellar extinction correction do3fiber kpnocoude Process KPNO coude three fiber spectra doargus argus Process ARGUS spectra doecslit echelle Process Echelle slit spectra dofibers specred Process fiber spectra dofoe echelle Process Fiber Optic Echelle (FOE) spectra dohydra hydra Process HYDRA spectra dopcor onedspec Apply doppler corrections doslit ctioslit Process CTIO slit spectra doslit kpnocoude Process KPNO coude slit spectra doslit kpnoslit Process slit spectra doslit specred Process slit spectra evalfit photcal Compute standard indices filtpars rv Edit the filter function parameters findgain nproto Estimate the gain and readnoise of a CCD findthresh nproto Estimate a CCD's sky noise fitparams photcal Compute transformation equations fitprofs onedspec Fit gaussian profiles fitskypars daophot Edit the sky fitting parameters fxcor rv Radial velocities via cross correlation gratings astutil Compute and print grating parameters group daophot Group stars grpselect daophot Select groups from a daophot database invertfit photcal Compute the standard indices by inversion istable ptools Is a file a table or text database file? linpol nproto Polarization and Stoke's parameters keywpars rv Translate image header keywords mkcatalog photcal Type in a standard star catalog mkconfig photcal Prepare a configuration file mkechelle artdata Make artificial 1D and 2D echelle spectra mkexamples artdata Make artificial data examples mkheader artdata Append/replace header parameters mkimsets photcal Prepare an image set file for mkNobsfile mk(n)obsfile photcal Make a starfield observations file mkphotcors photcal Check photometric corrections files msresp1d argus Create 1D response spectra msresp1d hydra Create 1D response spectra msresp1d kpnocoude Create fiber response spectra msresp1d specred Create 1D response spectra nstar daophot Fit the psf to groups of stars obsfile photcal Make a starfield observations file pappend daophot Concatenate daophot databases pappend ptools Concatenate apphot/daophot databases pconvert daophot Convert text database to tables database pconvert ptools Convert text database to tables database pdump daophot Print fields from daophot databases pdump ptools Print columns of daophot/apphot databases peak daophot Fit the psf to single stars pexamine apphot Examine or edit an apphot output file pexamine daophot Examine and edit a daophot database pexamine ptools Examine and edit an apphot/daophot database phot daophot Compute sky values and initial magnitudes photpars daophot Edit the photometry parameters prenumber daophot Renumber stars in a daophot database prenumber ptools Renumber a list of apphot/daophot databases pselect daophot Select records from daophot database pselect ptools Select records from apphot/daophot databases psf daophot Fit the point spread function psort daophot Sort a daophot database psort ptools Sort a list of apphot/daophot databases sapertures onedspec Set or change aperture header information sarith onedspec Spectrum arithmetic scombine onedspec Combine spectra scopy onedspec Select and copy apertures seepsf daophot Compute an image of the PSF setjd astutil Compute and set Julian dates in images sfit onedspec Fit spectra substar daophot Subtract the fitted stars tbappend ptools Concatenate apphot/daophot tables databases tbdump ptools Print columns of tables databases tbrenumber ptools Renumber apphot/daophot tables databases tbselect ptools Select records from apphot/daophot databases tbsort ptools Sort apphot/daophot tables databases txappend ptools Concatenate apphot/daophot text databases txdump apphot Dump selected fields of apphot output file txdump ptools Print columns of text databases txrenumber ptools Renumber apphot/daophot text databases txselect ptools Select records from text databases txsort ptools Sort apphot/daophot text databases 4. Programming Environment Revisions 4.1 Compatibility Issues V2.10 IRAF requires that any local IRAF programs external to the V2.10 system (such as layered packages or locally written tasks) be fully recompiled if they are relinked against V2.10. The problem arises only if the programs are relinked; external programs will continue to run after V2.10 is installed, but linker errors will be seen if the programs are relinked without being fully recompiled. This is because the internal names of some important system routines were changed in V2.10 to avoid name clashes with host system routines. For example, the SPP procedure "rename" is now translated to "xfrnam" when the SPP code it appears in is compiled. As always, actual interface changes affecting existing source code were very few. The macro "E" in <math.h> was renamed to "BASE_E" to minimize the chance of an accidental name collision. The calling sequence for the onentry procedure (ETC) was changed, but since this is a little used system procedure very few tasks should be affected. A number of new procedures were added to MTIO and the syntax of a magtape device has changed; old applications should be modified to use the MTIO procedures to operate upon magtape device names. These and other revisions affecting the programming environment are discussed in more detail below. 4.2 Portability Issues The V2.10 UNIX/IRAF kernel now includes "#ifdef SYSV" support for System V UNIX, making it easier to port IRAF to SysV based systems. The UNIX/IRAF HSI (host system interface) is still not as portable to UNIX variants as it could be, but at this point it is easier for us to make the minor revisions required for a new port than to further refine the HSI. The disadvantage is that it is harder than it should be for people in the community to do their own IRAF ports, due to the level of IRAF expertise required to tune the code. Someday we plan to generate a generic-UNIX HSI. Note that these comments pertain only to the few thousand lines of code in the HSI - the bulk of the IRAF code is 100% portable (identical on all IRAF systems) as it has always been. The recent port of IRAF to A/UX (the Apple Macintosh UNIX) is interesting from a portability standpoint because we used the publically available Fortran to C translator f2c plus the GNU C compiler gcc to compile all the SPP and Fortran code in IRAF. This was remarkably successful and means that the IRAF code is now portable to any system with a C compiler. In the process of performing these compilations a few dozen minor bugs were found by the static compile time checking performed by f2c and gcc. The IRAF C code was run through gcc with ANSI mode enabled, and hence should now be ANSI-C compatible. The GNU debugger gdb proved to be an effective tool for debugging of IRAF code compiled with gcc. 4.3 Software Tools 4.3.1 LOGIPC feature A new facility has been added to UNIX/IRAF (all systems) for debugging interprocess communication (IPC). This feature will also be useful for debugging tasks standalone, particularly in cases where a bug seen when running a task from the CL is difficult to reproduce when the task is run standalone. The new facility allows one to carry out a normal IRAF session while transparently logging all interprocess communications. Each process can then be rerun individually using the logged IPC to exactly duplicate the functioning of the process to, e.g., examine the program operation in detail under a debugger. The facility is this: if LOGIPC is defined in the host environment when an iraf process is started, the process will create two files pid.in and pid.out, where pid is the process id. Everything read from the IPC input file is copied to the .in file, and everything written to the IPC output (i.e., sent back to the CL) is copied to the .out file. This is done only for connected subprocesses. It will work for any connected subprocess, e.g., normal cached processes and graphics subkernels in both foreground and background CLs, but not the i/o of the CL itself since the CL is not driven by IPC. The IPC streams saved are an exact binary copy of whatever was sent via IPC, including the binary IPC packet headers, and binary graphics data, and so on. All the IPC communications used to start up the process, run zero or more tasks, and close the process down will be logged. Most IPC traffic is textual in nature so it will usually be possible to examine the IPC files with a file pager, although the results may be less than satisfactory if binary data such as a graphics metacode stream is logged. It is not necessary to examine the IPC files to use them for process execution or debugging. A particularly interesting use of this feature is to allow a process to be run under the CL in the normal fashion, then rerun under a host level debugger using the saved IPC input to duplicate the input and actions of the process when run under the CL. For example, % setenv LOGIPC % cl cl> dir cl> logout % unsetenv LOGIPC will run the CL, saving the IPC of all subprocesses, e.g. x_system.e. We can then run the system process manually, using the saved IPC input: % $iraf/bin/x_system.e -c < pid.in To run the process under adb or dbx, using the saved input: % adb $iraf/bin/x_system.e :r <pid.in -c or % dbx $iraf/bin/x_system.e dbx> r -c < pid.in Note that the redirection has to be given first for adb, and last for dbx. This also works for gdb using the run command. Some implementations of adb are picky about syntax and will not allow a space between the "<" and the process id in the :r command. Running a task in this way is not identical to running the task standalone, e.g. using a dparam file for parameter input, because the full runtime context of the process as run under the CL is reproduced by LOGIPC but not when the task is run standalone. The differences are subtle but can be important when trying to reproduce a bug seen when the process is run under the CL. It is often the case that a bug seen when a task is run from the CL will disappear when the task is run standalone, but in most cases LOGIPC will duplicate the bug. 4.3.2 XC changes The xc program (IRAF compiler-linker) underwent the following changes for V2.10, in addition to the usual host-system specific changes required to support new host compiler versions. Multiple "-p pkgname" arguments are now supported. These are used when compiling a module which uses multiple package environments, e.g., cl> xc -p noao -p tables foo.x Each package environment may define package environment variables, directories to be searched for include files and libraries, and so on. Package environments are used by the IRAF layered packages. Host libraries named on the command line using the -l switch (e.g., "-lresolv") are now searched after the IRAF system libraries, rather than before as in previous versions of xc. If the host library is referenced by absolute pathname it is still searched before the IRAF libraries, since the command line order determines the search order. 4.3.3 SPPLINT code checker A static code checker utility spplint has been developed for checking SPP programs. This uses the SPP translation utilities in IRAF to convert SPP to Fortran, f2c to generate C code, and lint to check the C code. The code is checked in various ways at all phases of translation. Some of the most useful checking are performed by f2c, which checks the number and type of arguments in all calls to IRAF VOS library procedures. In other words, spplint will determine if an IRAF library procedure is called incorrectly, as well as perform a variety of other checks. The spplint utility is not included in the main IRAF release, but is available separately. Contact the IRAF project for information on the availability of this and other optional code development utilities. 4.3.4 Multiple architecture support Multiple architecture support is a way of using multiple sets of compiled program binaries within a single copy of IRAF. Multiple sets of binaries are used to support different machine architectures (e.g. sparc and Motorola), different compiler options (floating point options, vectorization options, profiling options), different compilers, and so on. The command for checking the architecture of the IRAF core system or a layered package has been changed from showfloat to arch to reflect the fact that multiple architecture support is no longer used merely to select the floating point option. cl> mkpkg arch sparc The default architecture of the distributed system is "generic", meaning no specific architecture has been set (the source tree is generic, not configured for any particular architecture). It is suggested that developers of layered software for IRAF adopt this same convention in their root mkpkg files. 4.3.5 Package environments All the HSI software utilities now permit multiple "-p pkgname" package environment references. The host PKGENV environment variable now also permits multiple package environments to be referenced, e.g. % setenv PKGENV "noao tables xray" The package names should be whitespace delimited (PKGENV is used to avoid having to give the "-p" flags on the mkpkg or xc command line). To successfully load a package enironment, the package root directory must be defined in hlib$extern.pkg or in the user's host environment. A host environment definition will override the value given in extern.pkg. 4.3.6 Finding module sources IRAF V2.10 includes a "tags" file in the IRAF root directory to aid software development. This file contains an index to all procedures in the IRAF VOS and HSI and can be used with host editors such as vi to rapidly find and display the source for IRAF system procedures. Note that the names of the kernel procedures are given in upper case, e.g., "ZOPNBF", whereas the names of the VOS procedures are given in lower case. To use the tags file with vi, start the editor at the IRAF root directory and while in the editor, type a command such as ":ta foo" to view the source for procedure foo. 4.4 Programming Interface Changes 4.4.1 IEEE floating support Modifications were made to the IEEE floating conversion routines in the OSB package to support NaN mapping. This is a low level package used by, e.g., the MII package in ETC. The interface as it currently stands is summarized below. ieepak[rd] (datum) # pack scalar value ieeupk[rd] (datum) # unpack scalar value ieevpak[rd] (native, ieee, nelem) # pack vector ieevupk[rd] (ieee, native, nelem) # unpack vector iee[sg]nan[rd] (NaN) # set/get NaN value ieemap[rd] (mapin, mapout) # enable/disable NaN mapping ieestat[rd] (nin, nout) # get count of NaN values ieezstat[rd] () # zero NaN counters The new or modified routines are ieesnan, ieegnan, ieemap, ieestat, and ieezstat. By NaN (not-a-number) we refer collectively to all IEEE non-arithmetic values, not just IEEE NaN. The routines ieesnan and ieegnan set or get the native floating value used to replace NaNs or overflows occurring when converting IEEE to the native floating format (any floating value will do, e.g., zero or INDEF). If NaN mapping is enabled, the ieestat routines may be used to determine the number of input or output NaN conversions occurring since the last call to ieezstat. Both real and double versions of all routines are provided. The NaN mapping enable switch and statistics counters are undefined at process startup; programs which use the IEEE conversion package should call ieemap to enable or disable NaN mapping, and ieezstat to initialize the statistics counters. 4.4.2 MATH libraries The following changes were made to the MATH libraries in the IRAF core system. Refer to the online help pages of the affected routines for detailed information. o The one-dimensional image interpolation library iminterp was modified to add support for sinc interpolation. o A new library nlfit was added for non-linear function fitting. An interactive graphics front end to this was also added in XTOOLS. o The name of the symbol E in <math.h> was changed to BASE_E to minimize the chance of name clashes. 4.4.3 CLIO interface The CLIO (command language i/o) interface underwent the following changes for version 2.10 IRAF. o A README file was added to the source directory containing an up to date interface summary. o The routines clgpset and clppset (get/put string valued parameter) were renamed clgpseta and clppseta. The old procedures were retained for compatibility but are now obsolete and may at some point in the future disappear or be reused for some other function. o Two new routines cllpset and clepset were added for listing and editing psets (parameter sets). The calling sequences for the new pset routines are as follows. cllpset (pp, fd, format) # list pset clepset (pp) # edit pset These new routines are still considered experimental and should be avoided or used with caution (they could change). Internal to the CLIO code, the CLIO parameter caching package underwent minor changes to add a new clc_compress routine and improve pset handling, as part of the minilanguage support effort. 4.4.4 ETC interface The ETC interface contains miscellaneous system interface routines. The ETC interface underwent the following changes for V2.10 IRAF. 4.4.4.1 Calling sequence for onentry changed The calling sequence for the onentry routine was changed. The new calling sequence is as follows. action = onentry (prtype, bkgfile, cmd) The onentry procedure is an optional procedure which is called when an IRAF process starts up. Normally the onentry procedure is a no-op, passing control to the IRAF main in-task interpreter. Custom IRAF applications, e.g., the CL, have a special onentry procedure which replaces the default in-task interpreter. The change made to the onentry calling sequence was the addition of the additional argument cmd. This argument receives the command line used to invoke the IRAF process at the host level. The application can parse this command line to extract arguments, allowing the IRAF process to operate as a host program (it is already possible to call any IRAF task from the host level, but use of an onentry procedure allows the in-task interpreter to be bypassed and gives the application control over parsing the command line). See etc$onentry.x for additional information on how to use this procedure. 4.4.4.2 New onerror and onexit procedures Two new procedures onerror_remove and onexit_remove were added. These have the following calling sequences. onerror_remove (proc) # remove posted onerror procedure onexit_remove (proc) # remove posted onexit procedure The new routines are used to remove onerror or onexit procedures posted by a task during task execution. Such user procedures are called if the task aborts (onerror procedures) or during normal task exit (onexit procedures). Formerly there was no way to "unpost" the procedures other than by the normal cleanup occurring during task termination. 4.4.4.3 New gqsort routine A new quick-sort routine gqsort (generalized quick sort) was added. This has the following calling sequence. gqsort (x, nelem, compare, client_data) gqsort is identical to the old qsort routine except for the addition of the fourth argument client_data. This is an integer value which is passed on to the compare procedure during sorting to compare two data values. The compare routine is called as follows. result = compare (client_data, x1, x2) The new routine eliminates the need to use a common area to pass information to the compare routine, as was often necessary with qsort. 4.4.5 FIO interface The FIO interface (file i/o) underwent minor changes to fix some bugs affecting pushed back data. The F_UNREAD file status parameter will now correctly report pushed back data as well as any buffered input file data. The F_CANCEL file set option will now cancel any pushed back data. 4.4.5.1 Nonblocking terminal i/o A new nonblocking form of raw mode terminal input has been added. This permits polling the terminal for input without blocking (suspending process execution) if no input is available. In a character read, EOF is returned if no input is available otherwise the character value is returned. An example illustrating the use of nonblocking terminal i/o follows. include <fset.h> task foo procedure foo() int fd, ch int getci() begin fd = STDIN call fseti (fd, F_IOMODE, IO_RAW+IO_NDELAY) repeat { if (getci(fd,ch) == EOF) call printf ("no pending input\r\n") else { call printf ("ch = %03o\r\n") call pargi (ch) } call sleep (1) } until (ch == '\004' || ch == 'q') call fseti (fd, F_IOMODE, IO_NORMAL) end This sample program sets the terminal i/o mode to nonblocking raw mode and polls the terminal once per second, printing the character value in octal if a character is typed on the terminal, exiting when ctrl/d or 'q' is typed. Note that in raw mode characters such as ctrl/d or ctrl/c are passed through as data and do not get mapped to EOF, generate an interrupt, and so on. Raw mode i/o such as this will work both when running a task under the CL and standalone, and in combination with IRAF networking (e.g. to access a remote device). Nonblocking terminal input is used in applications which run continuously but which we wish to be able to control interactively. 4.4.6 FMTIO interface The FMTIO interface (formatted i/o) is used to format output text or decode input text. The V2.10 release adds two new printf output formats, %H and %M. These are used to print numbers in hours-minutes-seconds or minutes-seconds format and are equivalent to the older output formats %h and %m except that the number is first divided by 15. This converts degrees to hours allowing values given in units of degrees to be printed as hours with just a change of the output format. In other words, given a number N in units of degrees, %H would print the number in hours-minutes-seconds, i.e., "hh:mm:ss.ss", whereas %h would print the same number as degrees-minutes-seconds, "dd:mm:ss.ss". The %m formats are similar except that only two of the three fields are printed. 4.4.7 GTY interface The GTY interface is a generalized version of that portion of the older TTY interface dealing with termcap format files. The TTY code which accesses termcap format files has been extracted to form the new GTY interface, allowing arbitrary termcap format files to be accessed by filename, unlike TTY which returns TTY descriptors given the termcap or graphcap device name. GTY was contributed by Skip Schaller of Steward Observatory. gty = gtyopen (termcap_file, device, ufields) gtyclose (gty) cp = gtycaps (gty) pval = gtyget[bir] (gty, cap) nchars = gtygets (gty, cap, outstr, maxch) The gtyopen call returns the GTY descriptor for the named device from the file termcap_file. The ufields string may be either NULL or a list of colon-delimited device capabilities, which will override the corresponding capabilities in the device entry given in the termcap file. If termcap_file is the null string ufields is taken to be the device entry for the named device. The gtycaps routine may be used to get the entire device entry as a string, whereas the gtyget and gtygets routines are used to get the values of individual capabilities or parameters. 4.4.8 MTIO interface MTIO is the magtape i/o interface. The magtape i/o subsystem was extensively revised for V2.10 IRAF, as documented earlier in this revisions summary. The VOS level MTIO interface itself was not changed other than to add a few new routines. The tapecap facility is new in V2.10. The revisions to the host level magtape driver ZFIOMT required that the calling sequences of some of the interface routines be changed. 4.4.8.1 MTIO applications programming interface The current MTIO applications programming interface is summarized below. Most of these routines are new: the old routines are mtfile, mtopen, mtrewind and mtposition. yes|no = mtfile (fname) yes|no = mtneedfileno (mtname) gty = mtcap (mtname) mtfname (mtname, file, outstr, maxch) mtparse (mtname, device, fileno, recno, attrl, maxch) mtencode (mtname, maxch, device, fileno, recno, attrl) fd = mtopen (mtname, acmode, bufsize) mtrewind (mtname, initcache) mtposition (mtname, file, record) The mtfile routine is used to test whether the given filename is a magtape file or something else, i.e., a disk file. mtneedfileno tests whether a file number has been specified in mtname (e.g., to determine whether or not to query for a file number parameter). mtfname takes mtname and a file number and constructs a new magtape device name in the output string. mtparse parses a magtape device name into its component parts, and mtencode does the reverse. mtcap returns the GTY descriptor of the tapecap entry for the device. gtyclose should be used to free this descriptor when it is no longer needed. Some older magtape applications programs parse the magtape device name directly, looking for characters like `['. These old programs are making assumptions about the form of a magtape device name which are probably no longer true. Such old applications should be rewritten to use the new MTIO procedures for all magtape device name operations. 4.4.8.2 MTIO system procedures The MTIO interface also includes a number of procedures intended for use in systems code. These are summarized in the table below. mtallocate (mtname) mtdeallocate (mtname, rewind_tape) mtstatus (out, mtname) mtclean (level, stale, out) The only new routine here is mtclean. This is called by the mtclean task in the V2.10 SYSTEM package and is used to scan the magtape status file storage area to delete old magtape position status files. Prior to V2.10 these files were stored in the user's UPARM directory, but in V2.10 the files are stored in /tmp so that multiple IRAF sessions will share the same tape position information. A special task is needed to delete old position files in order to protect against, e.g., one user deleting another user's device position file while the device is actively in use. 4.4.8.3 Magtape driver procedures All access to the physical magtape device is via the host level IRAF magtape device driver ZFIOMT. The driver procedures had to be revised for V2.10 to add support for the tapecap facility and to accommodate changes in the way the device position is maintained. The new driver procedures are summarized below. zzopmt (device, acmode, devcap, devpos, newfile, chan) zzrdmt (chan, buf, maxbytes, offset) zzwrmt (chan, buf, nbytes, offset) zzwtmt (chan, devpos, status) zzstmt (chan, param, value) zzclmt (chan, devpos, status) zzrwmt (device, devcap, status) The corresponding KI (kernel interface) routines were also modified to reflect the new calling sequences. A result of this is that IRAF networking for magtape devices is incompatible between V2.10 and earlier versions of IRAF. The host level device driver procedures are not normally called directly in applications code (applications use mtopen). Refer to the comments in the source file os$zfiomt.c for additional details. 4.4.9 MWCS interface The MWCS interface provides world coordinate system support for the IRAF system and applications. The main changes in the MWCS interface for V2.10 were bug fixes and semantic changes, e.g. various restrictions having to do with WCS attributes were removed, new function drivers were added, and so on. These changes are documented elsewhere in this revisions summary. The only interface change affecting MWCS was the addition of the new MWCS procedure mw_show. mw_show (mw, fd, what) This is used to dump a MWCS descriptor to the given output file, and is useful for examining MWCS descriptors while debugging applications. 5. Getting Copies of this Revisions Summary Additional copies of this revisions summary are available via anonymous ftp from node iraf.noao.edu in the directory iraf/v210, or via email from iraf@noao.edu. IRAF (Mar90) V2.9 Revisions Summary IRAF (Mar90) IRAF Version 2.9 Revisions Summary April 10, 1990 1. Introduction This document summarizes the changes in IRAF version 2.9. This was primarily a development release intended to support applications software development, hence the major changes were in the programming environment, although there are important new features of interest to general users too. Since IRAF V2.9 is primarily a development release, it is not being released on all platforms, and it is expected that many sites will not need to upgrade until IRAF V2.10 is available. Sites interested in obtaining IRAF V2.9 should contact the IRAF project to determine if the release is available for a particular host system. At the present time, the release is being made available for all Sun systems, for VAX/VMS, and for the DECstation running Ultrix. What follows is a brief description of some of the new features available in IRAF Version 2.9. This is not intended to be an exhaustive list, but rather a brief summary of the major changes since the last release of IRAF, Version 2.8, released in July 1989. More detailed revisions notes are available in the system notes file, iraf$local/notes.v29, as well as in the online revisions notes for the various packages. Users looking for information on a particular new package should note that if the package is not mentioned in these release notes and therefore is not included in IRAF V2.9, that does not necessarily mean that it is not available. Most major reduction and analysis packages are now made available for testing as user installable layered packages before they are included in the standard distribution. For information on the available add-on packages, contact the IRAF group, or check the latest IRAF Newsletter. This revisions summary is organized as follows: 1. Introduction 2. IRAF System Revisions 3. IRAF Package Revisions 3.1. Changes to the System Packages 3.2. Glossary of New Tasks in the IRAF System Packages 3.3. Changes to the NOAO Packages 3.4. Modifications and Additions to Calibration Data 3.5. Glossary of New Tasks in the NOAO Packages 4. Programming Environment Revisions 4.1. Changes to the Programming Utilities 4.2. Programming Interface Changes 2. IRAF System Revisions 2.1 IEEE to native floating point conversions Support has been added to the programming interfaces (section 4.2.3) for converting between the IEEE floating point and native floating point data formats, including both single and double precision. The FITS programs in DATAIO (section 3.1.1) make use of this, allowing floating point data to be exchanged in FITS format without having to convert to type integer. 2.2 World coordinate system support A major new VOS interface MWCS has been added to support general world coordinate systems (WCS) and transformations thereon (section 4.2.1). This includes support for linear, piecewise linear or sampled WCS, and general nonlinear WCS such as the tangent plane or gnomonic projection. If a FITS image is read into the system which has WCS information in the header, the WCS will be retained in the IRAF image header and can be used in coordinate transformations. The IMAGES tasks which move pixels around have been modified to edit the WCS to reflect the transformation (section 3.1.2). The image i/o system will automatically propagate the WCS of an image to a new copy of the image, and will edit the WCS as necessary if an image section is copied (this applies to all IRAF tasks which operate upon images). The task RIMCURSOR in the LISTS package has been rewritten to add support for coordinate transformations (section 3.1.3), and can be used, e.g., to read out the RA and DEC of objects on the image display using the image cursor, if the image has the necessary WCS information in the image header. Full integration of the new world coordinate facilities into all the IRAF applications, e.g., the graphics tasks and the spectral reduction packages, will take a year or longer due to the amount of software involved. In V2.9 the IRAF spectral packages have not yet been converted to use MWCS, and if MWCS is enabled it could alter the normal behavior of these packages. IRAF V2.9 is therefore shipped with MWCS disabled. What "disabled" means is that WCS information in the image headers is not edited to reflect operations involving image sections, or geometric transformations of images. Tasks such as RIMCURSOR which use an already existing WCS will still work whether or not header editing is disabled. If the spectral tasks will not be used and it is desired that world coordinates be propagated correctly in image transformations, MWCS header editing can be enabled in either of the following ways. The MWCS transformations are disabled by defining the variable "nomwcs" in the IRAF environment. To globally enable MWCS by default for everyone using the system, edit the file "hlib$zzsetenv.def" and comment out the following line as shown (you want to add the leading #, which will be missing in the distributed version): #set nomwcs = yes To enable MWCS header editing temporarily, for the current IRAF run: cl> reset nomwcs = no Detailed information on the coordinate systems defined by MWCS can be obtained in the online system with the command cl> phelp mwcs$MWCS.hlp fi+ Additional information is also given in the help page for RIMCURSOR. 2.3 IMFORT changes The IMFORT interface (host level Fortran or C interface to the IRAF image format) has undergone the following bug fixes and enhancements: o A couple of bugs associated with the IMDIR (image pixel-file directory) feature introduced in IRAF V2.8 have been fixed. o Image clobber checking has been added. By default, if you create a new image and another image with the same name already exists, the image create will now return an error code leaving the existing image unchanged. To override clobber checking in IMFORT programs, restoring the previous behavior of the interface, define "clobber" in your host environment. o IMFORT will now perform a limited filename translation service using the IRAF VOS filename translation code. This should allow most IRAF filenames to be used as input to host level IMFORT programs. Full VOS filename mapping is not provided, but filenames containing upper case characters and multiple "." delimited fields should be translated as in IRAF programs. o On systems with multiple architecture support (e.g., Sun, Convex) the FC task, used to compile and link IMFORT programs from within the IRAF environment, is now a script rather than a simple foreign task front end to XC. The purpose of the script is to see that all the necessary IRAF and host level command line switches and environment definitions (IRAFARCH, FLOAT_OPTION, etc.) are used. Previously, users had to make these environment definitions manually, and if they forgot the IMFORT program could fail to link or execute. o On most UNIX/IRAF systems, the host library -lU77 is now searched automatically by FC when an IMFORT program is linked. This library is not used by any of the IRAF code, but is required to link some Fortran programs that might want to use IMFORT. Users are encouraged to use FC to link their IMFORT programs. It is possible to manually link against the IRAF libraries if you know what you are doing, but the location of the libraries and the required host level command line switches vary for different systems and for different architectures of a single system, and it is easy to make mistakes. 2.4 MKIRAF now copies login.cl to login.cl.OLD On UNIX/IRAF systems, the MKIRAF command will now copy any existing login.cl file to login.cl.OLD, so that, for example, you can more easily merge any custom changes back in after running MKIRAF. On VMS/IRAF systems a new file version is created, as before. 2.5 Local additions to termcap/graphcap The termcap and graphcap device capability files have been reorganized with a section at the top for local additions. It is recommended that any locally added entries be made in this area, to simplify future system updates. The local additions can then be simply transferred to the new version of the file when a new version of IRAF is installed (any entries which are modified versions of standard entries should always be checked to see if anything has changed in the distributed version). 2.6 BIN directories now smaller On systems with multiple architecture support, the architecture save file OBJS.arc stored in the BIN directory for each architecture is now maintained as a compressed file. In a typical case this reduces the size of the file by about a factor of two, saving 1-2 Mb of disk space in each BIN directory. 2.7 Various system buffers increased in size The layered software support in IRAF V2.8 (extern.pkg and all that) had a problem with very long helpdb environment strings, limiting the number of external packages which could be defined. To fix this problem, various buffers were increased in size all over the system. The maximum length of an environment variable such as helpdb is now 960 characters (12 80 character lines of text). String parameters to tasks can also be larger, and the system is more resistant to problems when size limits are exceeded. Foreign task commands, OS escapes, etc., can all be larger now. The current limit on such strings is about 1024 characters, and is defined at sysgen time by the new system parameter SZ_COMMAND in hlib$iraf.h. 2.8 Shared library versions The Sun/IRAF shared library mechanism was modified to add support for shared library versions. The result is that when you install IRAF V2.9, which has a different shared library than V2.8, any local programs or other layered software linked under V2.8 will continue to run, because both the old V2.8 shared library and the new V2.9 shared library are included in V2.9 (with different version numbers). Although old programs will continue to run with V2.9, it is recommended that they be relinked eventually to take advantage of the many features and bug fixes provided by V2.9. In the case of very large packages, e.g., STSDAS 1.0, it may be wise to wait until the latest release can be obtained and installed before relinking, as the old version will not have been tested under IRAF V2.9 (which of course, didn't exist back then). 2.9 File pager enhancements The system file pager, used in the PAGE task, the new PHELP task, and other places, has undergone the following enhancements. o The N and P keys, used to move to the next or previous file when paging a list of files, now have a dual meaning: when paging a single file containing multiple formfeed delimited pages, the keys will move to the next or previous page in the file. This feature is used in the new PHELP task to page a large file containing, e.g., all the HELP pages for a package. o A limited upscrolling capability is now supported, e.g., if you hit the 'k' key while in the pager, the screen will be scrolled up one line in the file being paged. This feature may not be supported for some terminals, in which case the entire screen is redrawn at the new file location. 2.10 STF image kernel enhancements Extensive work has been done on the STF image kernel in this release (the STF kernel allows IRAF to access the Space Telescope image format directly). The changes included the following. o Header file caching. STF images often have quite large FITS headers which can be time consuming to read. A header file caching scheme is now used to optimize the kernel in cases where the same imagefile is repeatedly accessed, e.g., when successively reading each element of a large group format image. By default up to 3 header files will be cached; this default should be fine for most applications. If necessary the number of cache slots can be changed by defining the integer variable "stfcache" in the IRAF environment (the builtin maximum is 5 cached headers per process). o The semantics of the kernel regarding header updates have changed. STF images differ from other IRAF images in that they may consist of a group of images all in the same file, with each individual image having its own header (the group header), plus a single global FITS header shared by all images in the group. This is no problem in a read operation, but in a write or update operation there can be problems since parameters cannot be added to or deleted from the individual group headers. The new semantics regarding STF image header updates are as follows: 1) when updating the header of a multigroup image (not recommended) only the group header is updated, and attempts to add new parameters are ignored; 2) when updating the header of an image containing a single group, both the group header and the FITS header are updated. As a result of these changes, the behavior of a single group STF image is now identical to that of a regular IRAF image. It is recommended that multigroup STF images be treated as read only if possible, creating only single group images during interactive processing (except when running a program that is explicitly designed to create multigroup images). o The kernel was modified to work with the new MWCS (world coordinate system) interface. The image section transformation is now performed by MWCS rather than by the STF kernel. o A number of minor changes were made to the way the group parameter block (GPB) cards are maintained in the IRAF image descriptor. The comments on GPB definition cards are now preserved. Restrictions on the grouping of GPB cards in the header have been removed. o A number of bugs were fixed and restrictions removed, e.g., the size of a header is no longer limited to 32767 characters (404 lines). The IRAF core system and NOAO science applications were extensively tested with both single and multigroup STF images using the new kernel, and we now feel that it is safe to use the STF image format with these tasks, although the regular format is preferred if there is no special reason to use the STF format (the regular format is more efficient). 2.11 QPOE (event list image format) enhancements The QPOE image kernel, used for event list data (photon counting detectors, e.g., X-ray satellites such as ROSAT) underwent the following changes. o MWCS (world coordinate system) support has been added (section 4.2.2). This provides a consistent coordinate system despite, e.g., the blocking factor, rect, or image section used to construct an image matrix from an event list. o When opening a QPOE file as an IRAF image, the runtime filter expression used to create the image matrix is now saved in the parameter QPFILTn in the image header (multiple cards are used for long expressions). o Region masks of arbitrary complexity and size can now be used to mask the event list when reading time-ordered or unordered (unindexed) event lists. This is done using the new PLRIO package (section 4.2.5) which provides the capability to efficiently random access large image masks of arbitrary complexity. o Unmatched brackets, braces, or parentheses are now reported as an error by the filter expression parser (this can occur even with a valid expression, e.g., due to truncation of the expression string). A reference to an undefined keyword, e.g., due to a spelling error, is now detected and reported as an error. Any errors occurring during expression parsing will now result in termination of the calling task, unless caught in an error handler. o A number of bugs were fixed. 2.12 Changes affecting image display in VMS/IRAF A new version of Nigel Sharp's UISDISPLAY program, for image display on VMS systems running UIS, has been installed in "iraf$vms/uis". An executable for an early version of the SAOIMAGE display program for the X window system, written by Mike VanHilst (SAO), and ported to VMS by Jay Travisano (STScI) has been placed in the directory "iraf$vms/x11". An executable for a VMS version of XTERM (the X window terminal emulator, ported to VMS by Stephan Jansen), is also in this directory. We wanted our VMS users to have access to these programs, although more development work and testing is needed before we can offer good support for X window based image display and graphics on VMS. A more comprehensive package providing enhanced capabilities should be available as an add-on later this year. 3. IRAF Package Revisions The most notable changes to the tasks in the IRAF packages are summarized below. Further information may be obtained by reading the help page for each task, or by paging the revisions file for a particular package. For example, to page the revisions for the DATAIO package: cl> phelp dataio.revisions op=sys 3.1 Changes to the System Packages 3.1.1 Modifications to tasks in the DATAIO package o The RFITS and WFITS tasks have been modified to add support for the IEEE floating point format. The "bitpix" parameter in WFITS can be set to -32 or -64 to specify real or double precision IEEE floating numbers on output. RFITS recognizes these same values in the bitpix keyword in the FITS header on input and converts the data accordingly. Note that this option must be selected by the user as the defaults for writing a FITS tape have not changed. The user is cautioned that support for the IEEE floating formats is a new feature of FITS and may not be supported by all FITS readers. o RFITS was modified so that the "iraf_file" parameter can be a list of output images or a image root name. 3.1.2 Modifications to tasks in the IMAGES package o MWCS (world coordinate system) support was added to those tasks in the IMAGES package which change the geometry of an image, i.e., IMSHIFT, SHIFTLINES, MAGNIFY, IMTRANSPOSE, IMCOPY, BLKREP, BLKAVG, ROTATE, IMLINTRAN, REGISTER, and GEOTRAN (REGISTER and GEOTRAN only support simple linear transformations). If one of these tasks is used to linearly transform an image, the world coordinate system (WCS) in the image header will be updated to reflect the transformation. Note that MWCS is disabled by default in IRAF V2.9, and must be explicitly enabled to allow these tasks to edit the image header to update the WCS (see section 2.2). o The IMSTATISTICS task was modified. The "verbose" parameter was renamed "format" with the default being set to "yes" (fixed format with column labels). Otherwise the fields are printed in free format with 2 blanks separating the fields. The name of the median field has been changed to "midpt". o The IMHISTOGRAM task has a new parameter called "hist_type" that gives the user the option of plotting the integral, first derivative, or second derivative of the histogram instead of the normal histogram. 3.1.3 Modifications to tasks in the LISTS package o The RIMCURSOR task in the LISTS package was completely rewritten to add MWCS support, so that coordinates may be output in any user specified coordinate system defined by the WCS information in the image header of the reference image. For example, if an image with a TAN projection WCS is loaded into the image display, RIMCURSOR may be used to print the right ascension and declination at the location defined by the image cursor. Refer to the help page for details. 3.1.4 Modifications to tasks in the PLOT package o A new graphics kernel task IMDKERN (written by Zolt Levay at STScI) has been added to the PLOT package. The new graphics kernel allows the graphics output of any task to be plotted as a graphics overlay on the image display. As with the other graphics kernels, this may be done by calling the IMDKERN task directly, but is more often done by specifying the image display (e.g., device "imd") as the output device when running a graphics task. Refer to the help page for details. o The CONTOUR task was modified so that it could be used with IMDKERN to overlay contour plots on the image display. If the parameters fill=yes and perimeter=no are set the contour plot is scaled to fill the entire device viewport and all axis and plot labeling is disabled. If the image being displayed also fills the entire device viewport (display frame) then the contour plot will be drawn to the same scale as the displayed image. Refer to the help page for details. o Several tasks in the PLOT package were modified to allow use with image specifications containing brackets, e.g., group format images, QPOE filter expressions, and image sections. The tasks modified were PROW, PROWS, PCOL, PCOLS, SURFACE, and CONTOUR. o An option was added to the PVECTOR task to output the vector (cut through the image at an arbitrary angle and center) as a text file or image, rather than plotting the vector. 3.1.5 Modifications to tasks in the SYSTEM package o A new task PHELP (paged help) was added to the SYSTEM package. PHELP is a script task front end to HELP which collects the output of HELP in a scratch file and pages it with the system pager, allowing one to randomly skip around to read the help text. Note that paging of all the help pages in a package is supported, e.g., cl> phelp images.* would page all the help files for the IMAGES package. o The NEWS task was completely rewritten, and is now used to page the revisions summary for the current and previous releases. In other words, one can now type NEWS to find out what is new in the current release. o The GRIPES task was modified to send mail to iraf@noao.edu or 5355::iraf. The IRAF site administrator may want to check this script for compatibility with the local mail system. 3.2 Glossary of New Tasks in the IRAF System Packages Task Package Description imdkern plot Image display device (IMD) graphics kernel news system Summarize what is new in the current release phelp system Paged HELP: collects and pages the output of HELP rimcursor lists Read image cursor position in world coordinates 3.3 Changes to the NOAO Packages 3.3.1 New NOAO Packages A new package ARTDATA, used to generate artificial data, has been added to the NOAO packages. ARTDATA includes tasks for the generation of star fields, optionally containing galaxies, and one and two dimensional spectra as well as simple test pattern images. The tasks GALLIST and STARLIST provide many options for producing lists of galaxies or stars that can then be used by the task MKOBJECTS to produce output images. The tasks MK1DSPEC and MK2DSPEC provide tools for making artificial spectral data. The task MKNOISE allows the user to add readout noise, poisson noise and/or cosmic ray events to new or already existing images. The task MKPATTERN allows the user to make images from a choice of patterns. 3.3.2 Modifications to Existing NOAO Packages 3.3.2.1 The ASTUTIL package o The task SETAIRMASS in the ASTUTIL package was modified so that it now precesses the coordinates to the epoch of the observation. 3.3.2.2 The DIGIPHOT.APPHOT package o A new task APTEST was added to the DIGIPHOT.APPHOT package that tests the execution of the package. Output files are generated that the user can review. o Two new parameters were added to DATAPARS, "datamin" and "datamax". Pixels outside this range are rejected from the sky fitting algorithms and from the non-linear least square fits in FITPSF and RADPROF. o An "update" parameter was added to all of the APPHOT tasks. If the "verify" parameter is set to "yes" and the task is run in noninteractive mode update=yes will update the critical parameters in their respective parameter sets. o Four new parameters, "airmass", "xairmass", "filter", and "ifilter", were added to the DATAPARS task. These parameters provide the user the option of having the filter and airmass quantities from the image headers to be carried over into the APPHOT database files for later transmission to calibration programs. o A new algorithm "mean" was added to the sky fitting options. o A setup menu mode was added to all the APPHOT tasks. When the user types "i" in interactive mode a setup menu is presented rather than a fixed set of predefined commands. 3.3.2.3 The IMRED.IRRED package o The APSELECT task (from the APPHOT package) has been made visible. o The image i/o for IRMOSAIC, IRALIGN, IRMATCH1D, and IRMATCH2D has been optimized so things should run much faster. There is now an option to trim each section before insertion into the output image. The actions of these tasks can now optionally be output to the terminal. 3.3.2.4 The IMRED.MSRED package o A task called MSBPLOT was added to the IMRED.MSRED package. This task allows the user to plot a range of lines in multispec images in batch mode. 3.3.2.5 The ONEDSPEC package o Several modifications were made to the ONEDSPEC package. These changes affect all of the IMRED packages that include these tasks as well. o The equivalent width measurement using the "e" keystroke in SPLOT is now computed using the ratio of the spectrum to the continuum. The previous approximation is included in the logfile for comparison. o The DISPERSION task will now add CDi_j (CD matrix) keywords to the image header as an alternative way of expressing the dispersion function. If the keywords W0 and WPC or CRVALn and CDELTn are not in the image header the tasks reading this information for setting the wavelength (IDENTIFY, SENSFUNC, SPLOT, and SPECPLOT) will look for the CDi_j keywords. This change should have no affect on the NOAO applications but provides compatibility with STSDAS applications using the new MWCS interface provided with IRAF version 2.9. o The call to the CALIBRATE task in the script task BATCHRED was modified so that the "extinct" parameter is always set to "yes". Since CALIBRATE checks to be sure the data has not been previously extinction corrected this simple change provides more flexibility. 3.3.2.6 The PROTO package o Two new tasks, IMALIGN and IMCENTROID, were added to the package. IMCENTROID computes a set of relative shifts required to register a set of images. The task IMALIGN both computes the shifts and aligns the images. o The JOIN task (previously a simple script) has been replaced by a compiled version which removes many of the restrictions of the previous version. o The IR tasks have been modified as mentioned above under the IMRED.IRRED section (section 3.3.2.3). o The TVMARK task was modified to permit deletion (the "u" key) as well as addition of objects to the coordinate file. Another cursor keystroke, the "f" key, was added allowing the user to draw a filled rectangle. 3.3.2.7 The TWODSPEC.LONGSLIT package o Tasks in the TWODSPEC.LONGSLIT package that are used for setting wavelength information (EXTINCTION, FLUXCALIB, and TRANSFORM) were modified for the CDi_j keywords as outlined above for ONEDSPEC. 3.4 Modifications and Additions to Calibration Data The calibration data used by some of the tasks in the TWODSPEC, ONEDSPEC, and many of the IMRED packages are kept in a directory called ONEDSTDS in noao$lib. The current contents of this directory are best summarized by paging through its README file, e.g., cl> page noao$lib/onedstds/README A new directory spec50redcal in "noao$lib/onedstds" has been added containing flux information for standard stars. The data in this list are from Massey and Gronwall, Ap. J., July 20, 1990. 3.5 Glossary of New Tasks in the NOAO Packages Task Package Description aptest apphot Run basic tests on the apphot package tasks gallist artdata Make an artificial galaxies list imalign proto Register and shift a list of images imcentroid proto Compute relative shifts for a list of images mk1dspec artdata Make/add artificial 1D spectra mk2dspec artdata Make/add artificial 2D spectra mknoise artdata Make/add noise and cosmic rays to 1D/2D images mkobjects artdata Make/add artificial stars and galaxies to 2D images mkpattern artdata Make/add patterns to images msbplot msred Batch plots of multispec spectra using SPLOT starlist artdata Make an artificial star list 4. Programming Environment Revisions 4.1 Changes to the Programming Utilities 4.1.1 MKPKG changes The MKPKG utility can now substitute the contents of a file back into the input stream, as a special case of the macro replacement syntax. For example, the sequence abc$(@file)def would be translated as abc10def if the file "file" contained the string "10". The replacement is performed by inserting the contents of the file back into the input stream, replacing sequences of newlines, spaces, or tabs by a single space, and omitting any trailing whitespace. The "-p <pkg>" argument to MKPKG, XC, and so on loads the environment of the named package pkg, to define the package environment variables, load the mkpkg special file list, define the directories to be searched for global include files and libraries, and so on. Multiple "-p" arguments may be given to load multiple package environments. What is new is that if pkglibs is defined in the environment of a package to list the package library directories to be searched (the usual case), and multiple package environments are loaded, successive redefinitions of pkglibs will add to the list of directories to be searched, rather than redefining the old list as each new package environment is loaded. For example, if two package environments are loaded, and each defines its own library, both libraries will be searched. 4.1.2 Generic preprocessor A minor change was made to the generic preprocessor which affects how strings such as "FOO_PIXEL" are translated. In the usual case, the preprocessor replaces all occurrences of "PIXEL" by "int", "real", or whatever the actual datatype is. The translation is now context sensitive. Rather than translating "FOO_PIXEL" as "FOO_int" (e.g., "MII_PIXEL" -> "MII_int"), the type name will now be output in upper case if the rest of the name in which it occurs is upper case. Hence, a string such as "MII_PIXEL" will now be translated as "MII_INT". This allows the use of generic constructs to symbolize SPP macros. 4.1.3 SPP changes The language constant ARB, formerly defined as 32767, is now treated differently depending upon how it is used. In a declaration of an array argument, ARB is replaced in the output Fortran by a "*", e.g., "int data[ARB]" becomes "INTEGER DATA(*)". In an executable statement, ARB is replaced by a very large ("arbitrarily" large) integer value, e.g., to define a DO-loop which is to loop an arbitrary number of times. If ARB is mistakenly used to dimension an array which is a local variable rather than an argument, the SPP translator will now detect and report the error. 4.1.4 Interactive development and the process cache Whenever a CL task is run and the process containing the task is already idling in the CL process cache, the CL will now check to see if the modify date on the process executable has changed, and restart the process if the executable has been modified. For example, when doing software development from within the CL and a process is alternately relinked and tested, the CL will now automatically detect that the process has been relinked and will run the new process, without any need to manually flush the process cache. 4.2 Programming Interface Changes 4.2.1 New MWCS interface (world coordinate system support) A major new VOS interface MWCS, providing general facilities for linear and nonlinear world coordinate systems, has been added to the programming environment and is used in IRAF V2.9 in IMIO, IMAGES, and other parts of the system. MWCS is intended for use in scientific applications as well as in system code such as IMIO, hence is of potential interest to anyone developing software within the IRAF environment. The source directory is "mwcs" and the interface is documented in the file "mwcs$MWCS.hlp". Users should be aware that, although the new interface addresses the general WCS problem and has been carefully designed, a second version of the interface is planned and the current interface is not yet a "frozen" interface. 4.2.2 QPOE interface changes The QPOE (event list image) interface has been extended to add routines to store MWCS objects in the QPOE header. By default, there is one MWCS per QPOE file, stored encoded in a machine independent binary format in a variable length array qpwcs of type opaque. The new routines are as follows: mw = qp_loadwcs (qp) qp_savewcs (qp, mw) mw = qpio_loadwcs (io) The routines qp_savewcs and qp_loadwcs merely save a MWCS in the QPOE header, or load a previously saved one. The QPIO (event i/o) routine qpio_loadwcs is like qp_loadwcs, except that it will also modify the Lterm of the MWCS to reflect any blocking factor or "rect" specified in the filtering expression when the event list was opened. The new routine is called automatically by QPF and IMIO whenever a QPOE event list is opened under image i/o, making the physical coordinate system of the image matrix the same as physical event coordinates. The calling sequences of the qp_add and qp_astr routines, used to conditionally add or update header parameters, have been changed (so far as we could determine very few programs exist yet which use these routines, so we decided to risk an interface change). The change made was to add a comment argument. This change was motivated by the observation that people would not use the routines but would instead use lower level routines, in order to be able to set the comment field if the parameter has to be added to the header. 4.2.3 IEEE support routines added Routines for IEEE floating to native floating conversions have been added to the MII and OSB interfaces. The new MII routines are as follows: nelem = miiread[rd] (fd, spp, maxelem) miiwrite[rd] (fd, spp, nelem) miipak[rd] (spp, mii, nelems, spp_datatype) miiupk[rd] (mii, spp, nelems, spp_datatype) The miiread and miiwrite routines are like their FIO counterparts, except that they are used only with data of the indicated type, and perform the IEEE to native floating conversion (or vice versa) as part of the i/o operation. The miipak and miiupk routines pack (native->IEEE) and unpack (IEEE->native) arrays of the indicated type. The lowest level conversion routines are the OSB routines, which are what the MII routines use to perform the lowest level translation. ieepak[rd] (datum) ieeupk[rd] (datum) ieevpak[rd] (native, ieee, nelem) ieevupk[rd] (ieee, native, nelem) iee[sg]nan[rd] (NaN) The ieepak and ieeupk routines transform a single scalar value in place, while the ieevpak and ieevupk routines transform vectors (note that the package prefix is "iee", not "ieee"). In-place vector conversions are permitted. Since IRAF does not support the IEEE not-a-number formats, NaN, Inf etc. values are converted to a legal native floating value on input. The native floating value to which NaNs are mapped (default zero) may be globally set with ieesnan. On some systems, e.g., the VAX, the low level conversion routines may be written in assembler or machine dependent C. If so, the source file actually used by the system will be found in the "host$as" directory. 4.2.4 New routine GETLLINE added to FIO A new routine getlline (get long line) has been added to FIO. This is similar to getline, except that it will reconstruct arbitrarily long newline delimited lines of text, whereas getline returns at most SZ_LINE characters. nchars = getlline (fd, outstr, maxch) The new routine should not be confused with the old routine getlongline, a higher level routine which performs a similar function, but which also ignores comment lines and help blocks, and maintains a line counter. 4.2.5 Modifications to PLIO/PMIO A new routine p[lm]_sectnotconst has been added to PLIO and PMIO (the pixel list and image mask interfaces). As the name suggests, the routine tests whether a given rectangular section of the mask is all at the same value, and if so returns the mask value as an output argument. bool = pl_sectnotconst (pl_src, v1, v2, ndim, mval) A new subpackage PLRIO has been added. This is used to efficiently random access any 2D plane of an existing pixel list or image mask. plr = plr_open (pl, plane, buflimit) plr_setrect (plr, x1,y1, x2,y2) mval = plr_getpix (plr, x, y) plr_getlut (plr, bufp, xsize,ysize, xblock,yblock) plr_close (plr) The mask is opened for random access on a special descriptor which incorporates a scaled, active 2D lookup table. Most subsequent plr_getpix calls will return the given mask value directly from the table with very little overhead; only if the referenced pixel occurs in a region too complex to be described by a single table entry is the value computed by direct evaluation of the mask. A special 2D binary recursive algorithm (using pl_sectnotconst above) with log2(N) performance is used to calculate the scaled lookup table. These algorithms provide efficient table generation and random mask pixel access even for very large masks. IRAF (Mar90) V2.8 Revisions IRAF (Mar90) IRAF Version 2.8 Revisions Summary June 30, 1989 1. Introduction This revisions notice coincides with the release of version 2.8 of IRAF. The V2.8 release is a general release for all supported IRAF hosts. The following is a brief description of some of the new features available in IRAF Version 2.8. This is not intended to be an exhaustive list, but rather a brief summary of the major changes since the last major release of IRAF Version 2.5 in July 1987 and subsequent intermediate releases primarily to support Sun/IRAF: IRAF Version 2.6 (February 1988), IRAF Version 2.6+ (March 1988), and IRAF Version 2.7 (December 1988). More detailed revisions notes are available in the system notes files in the iraf$doc and iraf$local directories, as well as in the online revisions notes for the various packages. 2. IRAF System Revisions This document highlights the most notable revisions made to the IRAF core system software for Version 2.8. This is only a revisions summary; no attempt is made to provide detailed technical documentation for each revision, nor is there any attempt to exhaustively summarize all revisions. A complete record of all core system revisions will be found in the System Notes for V2.8. Additional information on some of the topics covered below will be found in the various Installation Guides and Site Manager's Guides, and in the IRAF User and Technical Documentation manual sets. 2.1 Copyright notice Subject to AURA and NSF approval, the IRAF software will be copyrighted sometime during 1989. As a first step in this process, a copyright notice has been added to all core system source files. The notice reads as follows: "Copyright(c) 1986 Association of Universities for Research in Astronomy Inc". We will also be adding a file called COPYRIGHT to the distribution stating the terms of the copyright and associated licensing agreement for the software. The intent of this action is solely to protect the software from unauthorized commercial exploitation, and the copyright grants, or will grant, the right to copy, modify, and redistribute the IRAF software provided the original copyright notice remains intact, the software is made available in source form, and the rights we grant are passed on with the software. We wish to prevent others, especially commercial firms, from copyrighting IRAF software in their own name and possibly taking away the rights we grant with the software. Granting the right to modify and redistribute IRAF software does not mean we want to encourage people to do so, we merely want them to have the legal right to do so if they feel they need to. 2.2 Major system enhancements The information in this section is provided primarily for the benefit of IRAF site managers and programmers. The reader interested primarily in science applications may wish to skip ahead. Some systems level familiarity with the current IRAF system is assumed. 2.2.1 Layered software enhancements A given IRAF installation consists of the core IRAF system, and any number of layered software products or external packages. The goal of the layered software enhancements introduced in V2.8 is to make layered software products self contained and hence independent of the core system and of other layered software. Examples of layered software products are the NOAO packages, LOCAL, STSDAS, PROS, and so on. The layered software enhancements make it possible to install or deinstall a layered product by modifying only a single file in the core IRAF system. The core system may be updated without affecting layered software, and vice versa. Since layered products are independent and are simple to install, IRAF can easily be configured with only those packages needed at a particular site. Software developers benefit from the layered software enhancements because the facilities provided for development and maintenance of layered software are equivalent to those provided for development of the core IRAF system and the NOAO packages. User sites benefit because it is easy to extend the system with LOCAL packages of their own making. Each layered product (usually this refers to a tree of packages) is a system in itself, similar in structure to the core IRAF system. Hence, there is a LIB (global system library), one or more BINs (binary file directories), a Help database, a set of global environment definitions, and all the sources and runtime files, all contained within the same directory tree. Layered software products, in their source only form, are portable without change to any computer which runs IRAF. 2.2.1.1 The hlib$extern.pkg file This is the file which is modified to install or deinstall layered software products. To install a layered product, one creates a directory to hold the software, restores the files to disk, and edits the extern.pkg file to tell IRAF the name of the root package of the layered product, and where the root directory is located. If the layered software is distributed in source only form it will also be necessary to recompile the software, but this is a completely automated process. 2.2.1.2 NOAO and LOCAL packages reorganized As part of the project to better support layered software, the NOAO and LOCAL packages have been reorganized as layered products. These packages are now structurally equivalent to third party (non-NOAO) packages, except that the directory trees are rooted in IRAF. Both packages are now self contained, with their own LIB, BINs, Help database, etc., and with an entry in extern.pkg, like other layered products. The NOAO package serves as a working example of how to configure a layered package. The reorganization of these packages should be transparent to anyone merely using the system. 2.2.1.3 The template LOCAL The LOCAL package included with the distributed system has been stripped of all NOAO site-local tasks and restructured as a layered product, the template local. The template local contains only two sample tasks and is not intended as an end-user package, but rather as a template to be copied and modified by sites to construct their own site dependent LOCAL package. The desire to be able to easily develop and maintain locally added packages was one of the major motivations for the layered software enhancements project, and we hope that sites will realize the significance of this new capability and take advantage of it. 2.2.1.4 CL now supports package level BIN directories Rather than assuming a global BIN directory for all tasks and packages, the CL now permits multiple BIN directories, each BIN directory being associated with the package of definition and all subpackages of that package (unless they have their own BIN). A new BIN directory is declared with the optional argument bindir=path in the package statement, e.g., in a package script task. 2.2.1.5 MKPKG support for package environments Layered packages now have their own private LIB, including an environment definitions file (zzsetenv.def), mkpkg global include file (mkpkg.inc), and, optionally, a mkpkg special file list file for each supported host system, listing files requiring special compilation to work around host compiler bugs or whatever. The full mkpkg environment is formed by reading the IRAF core system environment and mkpkg definitions and include files, followed by the package definitions and include files. Reading of the package environment occurs only if mkpkg is called with the "-p" flag, or if the variable PKGENV is defined in the user's environment. Another way of expressing this is, when using mkpkg within a layered package, one must now specify the name of the layered package in order to pick up the package environment definitions. For example, to update the MTLOCAL package in NOAO, one would type "mkpkg -p noao update" in the mtlocal directory. If this is not done compilation errors may result, or the exectable may not be successfully installed in the package BIN directory. 2.2.2 Multiple architecture support A single IRAF system (or layered package) can now simultaneously support any number of machine architectures using multiple BIN directories sharing a single machine independent copy of IRAF. Each BIN directory contains all the object modules, object libraries, and executables for a particular architecture. An architecture can represent either a type of hardware, e.g., sparc, mc68020+f68881, mc68020+ffpa, vax, etc., or a software distinction, e.g., systems compiled with different sets of compiler flags, or different versions of a system. Multiple architectures are now supported both for IRAF execution, and for IRAF based software development, e.g., a single version of IRAF can now be used to develop and run IMFORT programs on both Sun-3 and Sun-4 nodes. The only case where multiple architecture support is used at the present time is in Sun/IRAF, which is often installed on a heterogeneous network of workstations, e.g., Sun-3s with various hardware floating point options, and Sun-4s. A single copy of IRAF will be configured with several BIN directories, one for each supported architecture, and NFS mounted on all the network nodes which will be using IRAF. There is no reason that this feature need be restricted to use with Sun/IRAF, however. 2.2.2.1 IRAFBIN and IRAFARCH Starting with IRAF V2.8, the old environment variable IRAFBIN has been obsoleted and replaced by IRAFARCH. On machines which support multiple architectures, the latter defines the architecture to be used for both IRAF execution and software development. If only IRAF execution is needed the variable is optional, with the best architecture being selected automatically when the CL is started. If one will be doing software development (including IMFORT) it is best to define the variable in the host environment before starting IRAF or doing any host level software development. Typical values of IRAFARCH for a Sun workstation are "sparc", "i386", "f68881", and "ffpa". 2.2.2.2 System libraries moved to the BIN directory As part of the revisions required for multiple architecture support for software development, all object libraries have been moved from the global, architecture independent LIB to the architecture dependent BIN, with the LIB entries being replaced by symbolic links (in the case of Sun/IRAF). This should be transparent to both end users and programmers. 2.2.2.3 New bin.generic architecture On Sun/IRAF systems, which are distributed configured for multiple architecture support, the system architecture is set to generic in the distributed system. What this means is that all architecture dependent files (objects and object libraries) have been removed from the system directories and archived in the file OBJS.arc in the BIN directory for each architecture. Rebuilding any of the packages in a system would require restoring the binaries for a particular architecture, e.g., typing "mkpkg sparc" at the IRAF root would restore the sparc binaries for the core system on a Sun/IRAF installation. Note that this only affects software development for the system in question; software development for external packages or private user software is not affected. 2.2.3 Shared library facility IRAF version 2.8 adds support for a general shared library facility for UNIX based systems. Although currently only used with Sun/IRAF, this facility is potentially useful for other UNIX based IRAF systems as well (VMS/IRAF already has its own shared library facility). What the shared library facility does is take most of the IRAF system software (currently the contents of the ex, sys, vops, and os libraries) and link it together into a special sharable image, the file S.e in each core system BIN directory. This file is mapped into the virtual memory of each IRAF process at process startup time. Since the shared image is shared by all IRAF processes, each process uses less physical memory, and the process pagein time is reduced, speeding process execution. Likewise, since the subroutines forming the shared image are no longer linked into each individual process executable, substantial disk space is saved for the BIN directories. Link time is correspondingly reduced, speeding software development. With the introduction of the shared library facility, the disk space required for Sun/IRAF is substantially reduced. Due to the increased memory sharing and reduced process pagein times performance is substantially improved, especially on systems like the Sun/386i which has a relatively slow SCSI disk and often limited memory. The disk size of small programs is reduced by up to a factor of ten in some cases, e.g., an executable for a small program that was formerly 250 Kb in size might be as small as 25 Kb if the shared library is used and the shared image symbols are omitted at link time. 2.3 User interface changes 2.3.1 Calling IRAF tasks from the host environment The IRAF main and zmain were modified to make it easier to call IRAF tasks as host level tasks, i.e., without having to set up a command file and run the process with the standard input redirected. In the new scheme, any extra arguments given on the process command line are passed into the IRAF main as a command buffer containing the IRAF command or commands to be run. For example, cl> x_system.e netstatus would run the command netstatus in process x_system.e. cl> x_system.e count "files=*.x" would run the count task, counting all ".x" files in the current directory. cl> x_system.e count "files=*.x 4>_o" would do the same, redirecting the output at the IRAF main level to the file _o. cl> x_system.e 'directory @pars $nargs=0' would run the directory task with the given parameter set, with $nargs set to 0. If any of the parameters to a task are omitted the task will query the terminal for them in the usual way, so for example cl> alias count "$iraf/bin/x_system.e count files=" would make the IRAF task count available in UNIX, allowing the IRAF template specifying the files to be counted to be either given on the UNIX command line, or prompted for if omitted. Given the above alias, one could enter a UNIX command such as cl> count 'cl$*.h' This feature is available in all UNIX based versions of IRAF V2.8, but did not make it into VMS/IRAF version 2.8. 2.3.2 Image packing density control (impkden) Some users have complained about images taking up more disk space than they have to, due to the IMIO feature which conditionally blocks image lines to fill an integral number of disk blocks. This can result in more efficient image i/o but can also make a significant difference in the amount of disk space consumed by an image in some cases. IMIO can actually support both block-aligned and fully packed images. The decision is made at image creation time and is based on the image packing density if image lines are block aligned. If the packing density is too low for a block-aligned image, a fully packed image is created to avoid wasting disk space. The default minimum packing density is 0.6, i.e., up to 40% wasted space before IMIO switches to full packing (no wasted space). For finer control over the packing density, the user can now specify the optional environment variable impkden, the numeric value being the mininum packing density. For example, cl> set impkden = 1.0 would completely disable block-alignment of image lines in IMIO. 2.3.3 User libraries (IRAFULIB) It is now possible for the programmer (SPP or IMFORT) to specify a private directory to be searched at compile or link time when developing IRAF or IMFORT programs. This is done by defining the path to the directory in the user environment as the variable IRAFULIB. When locating a particular file, this directory will be searched before the IRAF system libraries are searched, hence this feature may be used to substitute custom versions of files in the IRAF system libraries, e.g., for debugging purposes. 2.3.4 New logical printer device LPR A new logical line printer or plotter device lpr is now supported on all UNIX/IRAF systems. This treats the UNIX task lpr as a kind of pseudo-device, leaving it up to UNIX to decide what physical device to dispose of the output to. This default is system dependent, but on some systems can be controlled by defining the variable PRINTER in the user environment. 2.3.5 Machine independent help database The IRAF help task uses a precompiled binary database to speed help keyword searching. This file is now machine independent, allowing it to be generated on one system and included in software distributions without having to be recompiled. In addition, as part of the layered software support, help now allows each external package to have its own private help database. The first time help is run, all such databases are read and linked to produce a database containing entries for all help modules in the core system and all installed external packages. The help database file is the file helpdb.mip in the LIB directory of the core system and each external package. 2.3.6 Set terminal type will no longer hangup On systems, e.g., workstations, which provide virtual terminal windows which can change in size, IRAF may query the terminal at run time to determine the screen size. This query is performed, for example, at login time if the terminal type is set to gterm or sun. Formerly this could cause the login process to hang indefinitely (i.e., until the user typed return or interrupt) if the terminal did not respond to the size query, as would happen when the terminal type was set improperly and the actual terminal ignored the query. Thanks to the addition of non-blocking raw terminal i/o in V2.8 IRAF, the terminal screen size query will now time out with a warning message to reset the terminal type, if the terminal does not respond to the query within several seconds. 2.3.7 Installing a new version of IRAF obsoletes old user parameter files The problem of old, obsolete user (uparm) parameter files being used with a newly installed version of IRAF, which could lead to "parameter not found" error aborts, has been fixed. The CL now checks the date of the file utime in HLIB, and refuses to use the user pfile if it is older than either utime or the package pfile provided with the new system. The contents of old user pfiles are merged into the new system pfile, as before, preserving learned parameter values even when the user pfile is obsolete. 2.3.8 @file list bug fixed The problem of the "@file" (at-file-list) syntax not working when the file in question was not in the current directory has been fixed. 2.4 Programming interface changes 2.4.1 IMFORT pixel directory control IMFORT has been modified to permit specification of the pixel file directory by the calling program. The modifications are completely upwards compatible, i.e., existing programs linked with the new interface will still create pixel files in the same directory as the header file, with "HDR$" in the image header. The Fortran programmer may set or query the pixel file directory using the following routines: imsdir (dir) # set pixel directory pathname imgdir (dir) # get pixel directory pathname where dir is a Fortran character variable. The value should be either "HDR$" (the default) or a concatenatable host directory pathname (i.e., trailing / required for unix). Once set, the pixel directory will be used for all subsequent image create or rename operations by the calling process. For example, call imsdir ("/tmp3/pixels/") call imcrea (image1, axlen, naxis, dtype, ier) call imcrea (image2, axlen, naxis, dtype, ier) If desired the default pixel directory may be specified in the host environment as imdir or IMDIR before running the program. IMFORT will check the host environment for this environment variable then use "HDR$" as the default if no host definition is found. Note that although this is similar to setting the value of imdir in the IRAF environment, IMFORT programs are not part of the IRAF environment and are not affected by changes to the IRAF imdir. Also, since IMFORT is a host level facility and IRAF networking is not supported, the network prefix (e.g., "node!") is omitted from the pixelfile pathname, and since IMFORT programs are not necessarily used in conjunction with IRAF, the ".." (hidden file protection) files are not used to protect against image deletion. 2.4.2 Image display interface: IMD A new interface IMD has been added to provide a rudimentary facility for interactive image display device control. This is an interim prototype interface which will be replaced by the new display interfaces when the latter become available. The IMD interface operates by mapping an image display device frame buffer onto an IMIO image descriptor. The display frame buffer may then be randomly edited by normal image i/o operations, e.g., to modify subrasters of the displayed image, or overlay the image with color graphics. The image pixel to display frame buffer coordinate transformation is supported, allowing applications to work in image pixel coordinates if desired. This interim interface is what is used by the new display oriented tasks imexamine, imedit, and tvmark. 2.4.3 Image masks: PLIO, PMIO, MIO The following new VOS interfaces have been added in V2.8 to provide a general boolean or integer image mask facility. PLIO pixel list i/o PMIO pixel (image) mask i/o MIO masked image i/o (image i/o through a mask) PLIO is a general interface for storing and manipulating multidimensional integer valued rasters containing regions of constant value (i.e., masks). The masks are stored in a highly compressed form, the size of the compressed mask being a function of the information content of the mask. Both pixel array and range list i/o facilities are provided, as well as a set of general boolean raster operators, e.g., to extract or insert subrasters, AND or OR a source with a destination, do the same through a stencil, draw regions of various kinds (point, line, box, circle, polygon), and so on. See the PLIO.hlp file in the PLIO source directory for further information. An interactive debug program (plio$zzdebug.x) is provided for experimenting with masks. Note that PLIO is a stand alone interface and is not tied in any way to IMIO, even though the data structure operated upon is similar to an image matrix. PMIO is very similar to PLIO except that it is used to associate a masks with an IMIO maintained reference image. Currently, the PMIO mask must be the same resolution as the physical reference image. All coordinates input to PMIO are in the image section coordinates of the reference image. Hence, given a physical image and associated mask, one can operate upon both through a user specified image section transparently to the applications program. This includes all PLIO style boolean rasterop operations, as well as mask pixel and range list i/o. The PMIO interface is layered upon PLIO and IMIO, and the calling sequences are identical with PLIO except for the package prefix, and the addition of several new PMIO specific routines. MIO is essentially an extension of image i/o for pixel i/o through a mask. The central routines are the following: mio_setrange (mp, vs, ve, ndim) n|EOF = mio_[gp]lseg[silrdx] (mp, ptr, mval, v, npix) One defines a rectangular region of the image with mio_setrange, and then sequentially reads or writes line segments until all pixels visible through the mask have been accessed. This type of i/o should be ideal for most image processing applications which need to operate upon only those pixels visible through a region mask (e.g., a surface fitting task), upon all pixels except those on a bad pixel mask (e.g., any analysis program), and so on. PLIO (or PMIO) masks may be stored in binary files on disk, the files having the extension ".pl". The V2.8 version of IMIO has the capability to treat such masks as if they were images, allowing masks to be easily displayed, used in image expressions, converted to image matrices and vice versa, etc. Applications may do either pixel or range list i/o to a mask image via IMIO, if MIO is not suitable for some reason. 2.4.4 Photon images: QPOE, QPIO, QPEX A new set of VOS interfaces supporting photon or event list data are now available. The QPOE interface implements the Position Ordered Event list object, which consists of a general header mechanism plus an event list, wherein the events are little data structures, e.g., the attributes required to describe a photon detection (position, energy, time, etc.). QPOE is designed to efficiently access very large event lists, e.g., several hundred thousand or several million events in size. Builtin event attribute filtering and region filtering capabilities are provided for selecting photons from the event list. These filtering capabilities may be combined with the sampling capability to produce filtered, block averaged image matrices from event lists. The QPOE interfaces are the following: QPOE header and file access and management facilities QPIO raw and filtered event i/o QPEX event attribute filter mechanism QPF IMIO/IKI kernel for image interface to QPOE files QPOE and QPF add a new image type to the system, with .qp file extension. Hence, event list data can be used as input to any of the image processing tasks in standard IRAF, in addition to being analyzed by tasks which deal with the individual photon events. A QPOE image is contained in a single file. When a QPOE file is accessed as an image the interface filters and samples the event list in real time, using a user defined filter, block averaging factor, region mask, and so on, producing the image matrix seen by applications at the IMIO level. The QPOE object may be repeatedly examined with different event filters to view the data in different ways. The QPOE interface, in addition to providing an event list capability for IRAF, serves as a prototype for the "flex-header" portion of the new image structures project. Many of the capabilities to be provided for image storage under the new image structures are already present in QPOE. Further information is given in the QPOE.hlp file in the QPOE source directory. 2.4.5 File manager: FMIO A new VOS library FMIO has been installed. FMIO is "File Manager I/O", and is used to implement a simple binary file manager which maintains the file data of so-called "lfiles" (lightweight files) inside a single host binary file. The system overhead for accessing lfiles is much less than that of host files, and many lfiles can be used to store a complex data structure without cluttering a host directory or incurring the inefficiency of accessing host files. FMIO is part of the DFIO project and will serve as the lowest level interface within DFIO; it is also used currently in the QPOE interface. Additional information is given in the README file in the source directory for the interface. 2.4.6 IMIO changes IMIO is the image i/o interface, the standard IRAF VOS interface for managing all varieties of image data. 2.4.6.1 Mask image support IMIO now supports a new type of image, the mask image, stored as a highly compressed binary (PLIO) file with the extension ".pl". Image masks are most commonly used to store information describing selected pixels in an associated data image. An image mask is logically a boolean or integer image, up to 28 bits deep, containing information only on selected pixels or regions of pixels. Masks are stored in highly compressed format, e.g., a simple mask may be stored in only a few hundred bytes of space. Mask images are readable, writable, and randomly modifiable, like ordinary raster images. See \(sc2.4.3 for more information. 2.4.6.2 Photon image support Support has also been added to IMIO for event list images, stored as position ordered event list datafiles using the QPOE interfaces. This new image type has the extension ".qp". QPOE images are read-only under IMIO. Subject to that restriction, they may be accessed like any other image by any IRAF image analysis program. Accessing an event list image as a raster image necessarily involves a runtime sampling operation, wherein the events in the region of interest are accumulated into an initially zero image matrix; in the process the event list may optionally be filtered by event attribute or event position, e.g., cl> display "xray.qp[t=(30:40),pha=10,block=4]" would display the QPOE image xray.qp with a blocking factor of 4, selecting only those events with t (time) in the range 30 to 40 and for which pha (energy) has the value 10. The event attributes and their names are user definable and may vary for different types of data. See \(sc2.4.4 for more information. 2.4.6.3 IMPUTH A new procedure imputh has been added to the IMIO header access library. The new procedure is used to append FITS like HISTORY or COMMENT cards to the image header. 2.4.6.4 IMPARSE The calling sequence of the internal IMIO procedure imparse has changed. Although this procedure is internal to the IMIO interface and is not supposed to be used within applications, there may be applications which make use of this procedure. Any such applications must be modified to reflect the new procedure calling sequence or runtime problems are guaranteed. 2.4.7 Null string environment variables The semantics of the VOS procedures envgets and envfind have changed. This could affect existing programs and any programs which use these functions should be checked to make certain they will still work properly. These procedures, used to fetch the string values of environment variables, return the length of the output string as the function value. Formerly, a value of zero would be returned both when the named variable existed but had a null string value, and when the variable was not found. This made it impossible to discriminate between the case of a variable not being defined, and one which is defined but has a null value. The routines have been changed to return the value ERR (a negative integer) if the variable is not defined. Programs which do not wish to make the distinction between undefined and null-valued should check for a function value less than or equal to zero. Programs which check for a function value equal to zero will fail if the named variable is not defined. 2.4.8 Environment substitution in filenames The VOS filename mapping code has been modified to add support a powerful new environment substitution syntax. Previously the only environment substitution mechanism available was the logical directory facility, which could only be used to parameterize the directory field. The new facility may be used to perform environment substitution anywhere in a filename. This is used in IRAF version 2.8 to implement multiple architecture support, e.g., cl> set bin = "iraf$bin(arch)/" is how the core system BIN is defined in V2.8 IRAF. The syntax "(arch)" tells the filename mapping code to substitute the string value of the environment variable arch, if defined. If the variable is not defined the null string is substituted. Hence, if the host system does not implement multiple architecture support and arch is not defined, BIN is defined as "iraf$bin/", which is the backwards compatible definition. If arch is defined as, e.g., ".vax", then BIN is defined as "iraf$bin.vax/". The new feature allows use of a single environment variable to define the architecture, not only to form filenames, but for other purposes as well, e.g., to generate compiler switches or to control library searching in mkpkg. 2.4.9 Nonblocking raw terminal i/o The VOS file i/o interfaces have been modified to add support for nonblocking terminal i/o. This facility makes it possible to, in effect, "poll" the terminal to see if there is any input waiting to be read, to allow interaction without having a program block if the user has not typed anything. The immediate application of this in version 2.8 was the modification of the stty (set-terminal) facility to implement a time out for the terminal size query. Formerly, stty would hang up indefinitely when the terminal type was set to "gterm" but the actual terminal was something different, causing the screen size query to be ignored. In the more general case, nonblocking terminal i/o makes possible a new class of user interface, which is not only interactive, but event driven. Nonblocking i/o makes it possible for an application to be continually processing, while checking the terminal occasionally to see if the user has input any commands. At present, nonblocking i/o is always used in conjunction with raw mode input from a terminal. A new flag F_NDELAY, defined in <fset.h>, is used to enable or disable nonblocking i/o. For example, call fseti (fd, F_RAW, YES) enables conventional blocking, single character raw mode reads, and call fseti (fd, F_RAW, YES + F_NDELAY) enables nonblocking raw mode input (YES, NO, and F_NDELAY are bit flags). These modes are mutually exclusive, e.g., the first call may be issued while nonblocking raw mode is in effect to make the reads block, and vice versa. A call to fset(fd,F_RAW,NO) disables both raw mode and nonblocking mode. Once nonblocking raw mode is in effect one merely reads characters from the terminal in the usual way, using getc. EOF is returned if a read is performed when no data is available for input, otherwise the next character is returned from the input queue. Further information on nonblocking i/o is given in the system notes file. 2.4.10 Function call tables (ZFUNC) IRAF has always had the ability to compute the integer valued address of a procedure, store that address in a table, and later use the address as an argument to one of the zcall kernel primitives to call the addressed procedure. This facility has been extended by the addition of a set of zfunc primitives, used to call integer valued functions. Only integer valued functions are supported (in order to simplify the kernel support required), but in the systems oriented applications where procedure call tables are used, this is unlikely to be a serious limitation. 2.5 Sun/IRAF specific revisions 2.5.1 IEEE exception handling By default the IEEE hardware is now configured, on all Sun systems, with the invalid, overflow, and divide by zero IEEE exceptions enabled, and with the default rounding direction and precision modes (nearest, extended) in effect. This configuration should ensure that all questionable floating point operations are detected, and that no IEEE "funny numbers" (NaN, Inf, etc.) get into the data. These values, since they don't behave like ordinary numbers, can cause programs to misbehave, e.g., go into an infinite loop. In Sun/IRAF V2.8, if a computation results in an IEEE funny number being generated, an exception abort will result. The most common example is divide by zero. The IRAF/IEEE interface offers a special debug feature that may be of interest to programmers developing numerically sensitive software. If desired, one can change the default rounding direction and precision (e.g., to test the numerical stability of applications) by using the debugger to set a nonzero value of the variable debug_ieee before running an executable. The procedure for doing this is documented in the system notes file. 2.5.2 IMTOOL enhancements A number of enhancements and bug fixes have been made for V2.8 to the SunView based IMTOOL image display server. The most notable changes are summarized here; refer to the IMTOOL manual page for a more complete description of the new features. 2.5.2.1 Software ZOOM added IMTOOL, which has had for some time the ability to pan about on a large image, now has the ability to zoom as well. Both pan and zoom are controlled very conveniently by the middle mouse button: place the mouse on an object and tape the middle button once to pan the object to the center of the display window; tap it again and the image will be zoomed. Zoom, currently implemented by writing directly into the hardware frame buffer, is very fast, almost as fast as a normal unzoomed window refresh. The default set of zoom factors is 1,2,4,8 after which the sequence wraps around to 1. The zoom factors are user configurable via the IMTOOL setup panel; very large zoom factors, e.g., x64, are possible. Dezoom (making a large image smaller) is not currently supported. 2.5.2.2 WCSDIR eliminated The host level WCSDIR environment variable, and the text file used to communicate image coordinate (WCS) information between the display task and the display server, have been eliminated. All WCS information is now passed via the datastream used to pass commands and data between the client and the display server. This eliminates the need for users to have to remember to define WCSDIR in order to get coordinates in image units, and some subtle process synchronization problems are eliminated as well. In a related change, the frame buffer configuration index is no longer passed in during a frame erase, hence it is no longer necessary to erase a frame before displaying an image to ensure that a frame buffer configuration change is passed to the server. The configuration index is now passed when the WCS information for a frame is set. 2.5.2.3 Graphics colors IMTOOL now allocates a range of pixel values for use as graphics overlay colors. Setting a frame buffer pixel to one of these values causes it to always be displayed with the assigned color. The graphics color values are not affected by windowing the display. The most common use of graphics colors with V2.8 IRAF is for drawing graphics into a displayed frame with the new tvmark task, available in PROTO. See the IMTOOL manpage for a table listing the color index assignments. 2.5.2.4 New imtoolrc entries Several new predefined frame buffer configurations have been added to the default imtoolrc. These include an 128 pixel square frame buffer (imt128), a 256 pixel square frame buffer (imt256), and a full screen display with the same aspect ratio as a 35 mm slide (imtfs35). 2.5.2.5 System crash (FIFO) bug fixed Versions of SunOS through at least 4.0.1 have a bug in the FIFO driver code which can cause the internal kernel FIFO data buffer to be deallocated while it is still in use. This will result in a bad kernel which will eventually panic and reboot the system. This is the cause of the IMTOOL crash problem which some sites may have experienced. IMTOOL has been modified to avoid the circumstances (repeated 4096 byte transfers) which cause the bug to surface. So far as we know, the real bug (in SunOS) has not yet been fixed, but at least on the NOAO systems, the frequency of occurrence of the system crashes is greatly reduced with the new version of IMTOOL which incorporates the workaround for the SunOS bug. 2.5.2.6 Cursor marking now disabled by default When the interactive image cursor read facility was first added to IMTOOL, the default response to each cursor read was to draw a small white dot at the position of the cursor. This is convenient when marking a series of objects to make a list, but with the increasing number of IRAF programs making user of the interactive image cursor, it has been necessary to change the default to disable automatic marking of each cursor read. The cursor mark feature is still available as an option and can be enabled via the setup panel. 2.5.2.7 Ctrl/b may be used for manual blinking In addition to the list of blink frames and the timed blink feature IMTOOL has provided for some time, it is now possible to manually cycle through the blink frames with the <ctrl/b> key. Typing <ctrl/b> while the mouse is in the image window will cause the display to display the next blink frame in sequence. 2.5.2.8 F4 key will now toggle setup panel The F4 function key on the Sun keyboard may now be used to toggle whether or not the setup panel is displayed. This provides a single keystroke alternative to calling up the setup panel with the frame menu. 2.6 VMS/IRAF specific revisions 2.6.1 NEWUISDISP added to VMS/IRAF Nigel Sharp's NEWUISDISP display program, used for image display under UIS on microvaxes with bitmapped displays, is now available in the standard VMS/IRAF release, in the directory [IRAF.VMS.UIS]. 2.6.2 New INSTALL.COM script A new INSTALL.COM script (also written by Nigel Sharp) has been added to VMS/IRAF. This script, run by the system manager to install selected IRAF executable images, will now automatically check for and deinstall any old versions of the executables before installing the new ones. 2.6.3 VMS 4.7/5.0 Testing of the standard V2.8 VMS/IRAF release, which was prepared on VMS 4.7, on a VMS 5.0 system has thus far not revealed any problems (NOAO is still running VMS 4.7 as our standard system). Hence it appears that the standard V2.8 VMS/IRAF will run under VMS 5. It is likely, however, that any attempt to recompile VMS/IRAF under VMS 5 would cause problems, since we have not yet tried to rebuild IRAF under VMS 5, and such a major operating system upgrade will often require changes to the IRAF code. The system may be relinked under VMS 5 if desired, and this does not appear to cause any problems, but neither does there appear to be any benefit to be gained from doing so. 2.7 Summary of IRAF System Packages Revisions o The tasks RFITS and WFITS in the DATAIO package now support the reading and writing of arbitrary sized data blocks (IRAF version 2.7 and later). o Several new tasks were added to the IMAGES package. IMCOMBINE (IRAF version 2.6 and later) provides for the combining of images by a number of algorithms. The new task CHPIXTYPE (IRAF version 2.7 and later) changes the pixel types of a list of input images. The task IMSLICE slices images into images of one less dimension (IRAF version 2.8). The task IMSTACK has been moved into the IMAGES package (although it still resides in PROTO as well). The IMSTATISTICS task has been rewritten and now allows the user to select which statistical parameters to compute and print (IRAF version 2.8). The IMRENAME task has been modified to allow "in place" image renames, used chiefly for moving the pixel files to a new IMDIR. Several other tasks in the IMAGES package were modified (IRAF version 2.8). IMSHIFT was modified to accept a list of shifts from a file. REGISTER and GEOTRAN were modified to accept a list of transforms instead of only a single one. IMHISTOGRAM has undergone extensive revision including support for "box" type plots, support for linear or log scaling in the y coordinate, as well as support for antialiasing of the histogram bins. o All the tasks in the IMAGES.TV package were modified (IRAF version 2.8) so that if a task is used with an unsupported display device a message is printed to that effect. o The STTY task in the LANGUAGE package has been improved (IRAF version 2.6 and later) to better facilitate its "playback" feature. These changes have been documented in the online help for the task. This feature is little used by external sites but can be a very useful instructional aid if users are aware of its capability. o A new task PVECTOR was added to the PLOT package that allows one to plot an arbitrary vector in a two dimensional image (IRAF version 2.6 and later). The task STDPLOT was modified (IRAF version 2.8) so that it uses the more popular SGI kernel rather than the NSPP (NCAR) kernel (STDPLOT is now equivalent to the SGIKERN task). A new task NSPPKERN was added that uses the NSPP kernel. o Two new tasks were added to the SYSTEM package (IRAF version 2.8). The task DEVICES simply prints the dev$devices.hlp file as edited by the site manager listing available devices on the local host or network. The REFERENCES task is used to search the help database for all tasks or other help modules pertaining to a given topic, e.g., references vector will list all tasks that have the string "vector" in their one line description. 2.8 Glossary of New Tasks in the IRAF System Packages Task Package Description chpixtype images Change the pixel type of a list of images devices system Print information on the locally available devices imcombine images Combine images pixel-by-pixel using various algorithms imslice images Slice images into images of lower dimension imstack images Stack images into a single image of higher dimension nsppkern plot Plot metacode on a NSPP (NCAR) plotter device pvector plot Plot an arbitrary vector in a 2D image references system Find all help database references for a given topic In addition, there are new image display oriented tasks imexamine, imedit, and tvmark in the PROTO package in NOAO (used to interactively examine and edit images, or draw graphics into image display frames). These really belong in the core system but have been placed in noao.proto since they are prototype tasks. 3. NOAO Package Revisions Some of the major revisions to the NOAO packages are listed below. 3.1 Summary of NOAO Packages Revisions 3.1.1 New NOAO Packages Several new packages have been added to the NOAO suite of packages. o The APPHOT package is a set of tasks for performing aperture photometry on uncrowded or moderately crowded stellar fields in either interactive or batch mode. This package is now installed in the DIGIPHOT package (IRAF version 2.7 and later). The APPHOT package was available as an add-on package to IRAF version 2.5 and later while it was undergoing alpha testing. Many new features have been added to the package since it first became available including the new task QPHOT (quick aperture photometry) and interaction with the image display cursor for supported image displays (Sun workstation, IIS model 70). o The CCDRED package provides tools for the easy and efficient reduction of CCD images. This package has been installed in the IMRED package (IRAF version 2.6 and later). The CCDRED package was also available as an add-on to IRAF version 2.5. A short demonstration of many of the tasks in the CCDRED package is provided with the DEMO task in the CCDRED.CCDTEST package. o The IMRED.ECHELLE package has been replaced with a more sophisticated collection of tasks for reducing echelle type data (IRAF version 2.7 and later). The new ECHELLE package recognizes a new image format in which each extracted echelle order becomes a line in a two dimensional image rather than having a separate one dimensional spectrum for each order, although this old output format is still available as an option. Several new tasks exist for computing and applying a wavelength calibration to the data using the echelle relationship between the orders (ECIDENTIFY, ECREIDENTIFY, and ECDISPCOR) as well as for manipulating the new echelle format (ECSELECT, ECCONTINUUM, and ECBPLOT). o The IRRED package has been added to the IMRED package. The IRRED package collects together in one place those tasks used most frequently by users reducing IR data such as that taken with the IR imager at KPNO. The IRMOSAIC and IRALIGN tasks were available with IRAF version 2.6 and later. IRMOSAIC takes an ordered list of input images and places them on a grid in an output image. IRALIGN uses this grid and a coordinate list of overlapping objects from the individual subrasters to produce an aligned output image. The tasks IRMATCH1D and IRMATCH2D were available with IRAF version 2.7 and later. These tasks are similar to IRALIGN expect that the intensities of adjacent subrasters can be matched as well. A script called MOSPROC (IRAF version 2.8) has also been added that prepares a list of images for a quick look mosaic. o The MSRED package has been added to the IMRED package. The MSRED package is a collection of tasks used for reducing multispectral types of data, e.g. fiber arrays, where the individual spectra are for different objects. Like the ECHELLE package, it also has its own multispectral image format (a two dimensional image in which each line is an extracted spectrum). Several new tasks have been added to the package for wavelength calibration of multispectral data. 3.1.2 Modifications to Existing NOAO Packages o The ASTUTIL package was reorganized (IRAF version 2.6 and later - see IRAF Newsletter No. 3 for details) and several tasks were added and/or modified. A new task ASTTIMES computes and prints astronomical dates and times given a local date and time. A new task RVCORRECT computes and prints radial velocity corrections for an observation. The tasks PRECESS and GALACTIC were modified slightly using different but more accurate algorithms. The new task SETAIRMASS (IRAF version 2.8) computes the effective airmass and middle UT of an exposure. This task was also made available in the TWODSPEC and IMRED packages. o The two tasks in the IMRED.BIAS package, COLBIAS and LINEBIAS, were modified slightly (IRAF version 2.7 and later) so that the fitting parameters for the overscan region can be set by the user as hidden parameters to the tasks. o The task COSMICRAYS (from the CCDRED package) was made available in the IMRED.GENERIC package (IRAF version 2.6 and later). o A new task called SYNDICO has been added to the IMRED.VTEL package (IRAF version 2.6 and later). SYNDICO makes glossy prints on the NOAO Dicomed printer of the synoptic, full disk, magnetograms and spectroheliograms taken at the vacuum telescope at Kitt Peak. o Modifications were made to the IMRED.DTOI package. These changes have been documented in IRAF Newsletter No. 4. o Three new tasks in the ONEDSPEC package, REFSPECTRA, SEXTRACT, and SPECPLOT, were made available in the IMRED.COUDE, IMRED.IIDS, IMRED.IRS, and IMRED.SPECPHOT packages. o Many new tasks and features have been added to the ONEDSPEC package. The SENSFUNC task was completely rewritten (IRAF version 2.6 and later) to allow determination of extinction, display of flux calibrated spectra, and many new features for displaying and manipulating the data. IDENTIFY, REIDENTIFY and DISPCOR were modified (IRAF version 2.6 and later) so that a dispersion solution from IDENTIFY could be shifted without changing the original shape of the coordinate function (see IRAF Newsletter No. 3 for details). A new deblending algorithm was added to SPLOT (IRAF version 2.7 and later). See the online help for SPLOT as well as the article in IRAF Newsletter No. 4. The tasks in the ONEDSPEC.ONEDUTIL package were absorbed into the ONEDSPEC package (IRAF version 2.7 and later). The EXTINCT task disappeared with its functionality being taken over by a rewritten CALIBRATE (IRAF version 2.7 and later). The COEFS task was moved to the IMRED.IIDS and IMRED.IRS packages since this is a very instrument specific task (IRAF version 2.7 and later). Three new tasks were added to the package. SEXTRACT (IRAF version 2.6 and later) extracts subspectra from one dimensional input spectra. REFSPECTRA (IRAF version 2.7 and later) takes over part of the functionality of the old DISPCOR task and allows the user to define which arc spectra are to be used in the calculation of the dispersion solution of object spectra. SPECPLOT (IRAF version 2.8) is a new plotting task that allows the compression of many spectra to a page (see IRAF Newsletter No. 6). o Several new tasks have been added to the PROTO package. Four tasks were added to IRAF version 2.6 and later. BSCALE is a task that can be used to linearly scale images by the mean, average, or mode of the image. IRMOSAIC and IRALIGN can be used to combine many frames into one large image. These three tasks are also available in the IMRED.IRRED package. MKHISTOGRAM calculates the histogram of the data in a text file. Three new tasks were added to IRAF version 2.7 and later. IMSLICE is a task that slices an image into images of lower dimension. IRMATCH1D and IRMATCH2D are two tasks that allow combining of many overlapping images while matching the background intensities in two different ways. Three new tasks have been added to IRAF version 2.8 that allow the user to interact with the image display (for supported display devices, ie Sun workstation, IIS model 70). IMEXAMINE allows the user to interactively examine portions of the displayed image. TVMARK allows the user to mark objects on the image display. IMEDIT allows the user to interactively edit an image. o The APEXTRACT package in the TWODSPEC package has ungone several rounds of modifications, as discussed in the IRAF Newsletters, No. 3 and 4. These changes included improved techniques and additional options for the extraction of data. A new task, APSCATTER, has been added to the package (IRAF version 2.8). This task determines and subtracts scattered light from two dimensional aperture or echelle spectra. The task was also made available from within the ECHELLE package. This task was discussed in IRAF Newsletter No. 6. 3.2 Modifications and Additions to Calibration Data The calibration data used by some of the tasks in the TWODSPEC, ONEDSPEC, and many of the IMRED packages are kept in a directory called ONEDSTDS in noao$lib. The current contents of this directory are best summarized by paging through its README file, e.g., cl> page noao$lib/onedstds/README Two additional line lists (used by IDENTIFY) have been added to this directory (IRAF version 2.8). These lists, vacidhenear.dat and vacthorium.dat, are simply the standard .dat files in air wavelengths converted to vacuum wavelengths. The equation used for the conversion as well as the appropriate reference in the literature are contained in the README file. The thorium.dat file has been updated to contain thorium lines from 3180 Angstroms to 9540 Angstroms (IRAF version 2.6 and later). Please see the README file for the source. Two new directories have been added containing flux information for standard stars (IRAF version 2.6 and later): SPECHAYESCAL and SPEC50CAL. Both of these lists are from Massey et al., 1988, Ap. J., Vol. 328, p. 315. 3.3 Glossary of New Tasks in the NOAO Packages Task Package Description apscatter(1) apextract Fit and subtract scattered light apselect apphot Extract select fields from apphot output files asttimes astutil Compute UT, Julian day, epoch, and sidereal time badpiximage ccdred Create a bad pixel mask image from a bad pixel file bscale(3) proto Brightness scale images: new = (old-bzero) / bscale ccdgeometry ccdred Discussion of CCD coordinate/geometry keywords ccdgroups ccdred Group CCD images into image lists ccdhedit ccdred CCD image header editor ccdlist ccdred List CCD processing information ccdproc ccdred Process CCD images ccdred ccdred CCD image reduction package ccdtypes ccdred Description of the CCD image types center(3) apphot Compute accurate centers for a list of objects centerpars(3) apphot Edit the centering parameters combine ccdred Combine CCD images cosmicrays(4) ccdred Detect and replace cosmic rays daofind apphot Find stars in an image using the DAO algorithm darkcombine ccdred Combine and process dark count images datapars(3) apphot Edit the data dependent parameters demo ccdtest Run a demonstration of the CCD reduction package ecbplot echelle Batch plots of echelle spectra eccontinuum echelle Fit the continuum of echelle spectra ecdispcor echelle Dispersion correct spectra ecidentify echelle Identify features in spectrum for dispersion solution ecreidentify echelle Automatically reidentify features in spectra ecselect echelle Select and extract apertures from echelle spectra fitpsf apphot Model the stellar psf with an analytic function fitsky apphot Compute sky values in a list of regions fitskypars apphot Edit the sky fitting parameters flatcombine ccdred Combine and process flat field images flatfields ccdred Discussion of CCD flat field calibrations guide ccdred Introductory guide to using the CCDRED package imedit proto Examine and edit pixels in images imexamine proto Examine images using image display, graphics, and text imslice proto Slice images into images of lower dimension instruments ccdred Instrument specific data files iralign(3) proto Align the mosaiced image produced by irmosaic irmatch1d(3) proto Align and intensity match image produced by irmosaic irmatch2d(3) proto Align and intensity match image produced by irmosaic irmosaic(3) proto Mosaic an ordered list of images onto a grid mkfringecor ccdred Make fringe correction images from sky images mkhistogram proto List or plot the histogram of a data stream mkillumcor ccdred Make flat field illumination correction images mkillumflat ccdred Make illumination corrected flat fields mkimage ccdtest Make or modify an image with simple values mkskycor ccdred Make sky illumination correction images mkskyflat ccdred Make sky corrected flat field images mosproc irred Prepare images for quick look mosaicing msdispcor msred Dispersion correct spectra msreidentify msred Reidentify features from/to a multispec image msselect msred Select and extract apertures from spectra observe ccdtest Create an artificial CCD observation phot apphot Measure magnitudes for a list of stars photpars apphot Edit the photometry parameters polymark apphot Create polygon lists for polyphot polypars apphot Edit the polyphot parameters polyphot apphot Measure magnitudes inside a list of polygonal regions qphot apphot Measure quick magnitudes for a list of stars radprof apphot Compute the stellar radial profile of a list of stars refspectra(5) onedspec Assign wavelength reference spectra to other spectra rvcorrect astutil Compute radial velocity corrections setairmass(6) astutil Compute effective airmass for an exposure setinstrument ccdred Set instrument parameters sextract(2) onedspec Extract subspectra from dispersion corrected spectra specplot(5) onedspec Stack and plot multiple spectra subsection ccdtest Create an artificial subsection CCD observation subsets ccdred Description of CCD subsets syndico vtel Make dicomed print of daily grams 18 cm across tvmark proto Mark objects on the image display wphot apphot Measure magnitudes for a list of stars with weighting zerocombine ccdred Combine and process zero level images Notes: (1) Tasks also in echelle and msred packages. (2) Tasks also in coude, iids, irs, and specphot packages. (3) Tasks also in irred package. (4) Tasks also in generic package. (5) Tasks also in coude, echelle, iids, irs, msred, and specphot packages. (6) Tasks also in imred and twodspec packages. NEWS (Jul86) Ancient News NEWS (Jul86) 30 July 86 IMIO Modifications ------------------------------------------------------------------------------- The new IMIO interface, used by all IRAF tasks to access bulk image data on disk, is now capabable of operating upon both the old IRAF format (OIF) images as well as STScI SDAS/GEIS format images. The default image type is the OIF format. Any existing OIF format images are readable by the new system without change. Although IRAF can read either OIF or STF format images, SDAS can read only STF format images, so serious SDAS users should configure IRAF to work with STF format images as the default. All other users should continue to use the OIF format images as image access is more efficient, and the IRAF software has been extensively tested only for OIF format images. Users of the OIF format should note that they can read a VMS BACKUP tape (or UNIX TAR tape) containing STF format images directly to disk and immediately access the images, without changing the default configuration of IRAF. The image type is specified by a filename extension; extensions for the OIF format images are new in this release of the system. The recognized extensions are shown below. image type header file extensions OIF .imh STF .??h (? stands for any character) In most cases when operating upon an image with an IRAF task the extension can be omitted. The most important exception occurs in image templates. THE PATTERN GIVEN IN AN IMAGE TEMPLATE MUST FULLY MATCH THE IMAGE HEADER FILE NAMES AS THEY APPEAR IN A DIRECTORY LISTING, i.e., the header filename extension must be matched by the image template. The image type extension must also be specified to access an image which is not of the default image type (OIF or STF), or when changing the type of an image. For example, cl> imcopy dev$pix.imh pix.hhh will make an STF format copy in the current directory of the OIF format image "dev$pix". The default image type is controlled by the new environment variable IMTYPE. The string value of IMTYPE is the desired image header file extension, e.g., "imh" (omit the dot) for an OIF format image. If IMTYPE is not defined the default image type is "imh". For STF format images there are many possible image header extensions, and IMTYPE specifies the default type IMIO should look for when the extension is not explicitly given, or the default extension to use when a completely new image is to be created. When making a new copy of some existing image, IMIO will make a new image of the same type as the existing input image unless an extension is given to force some other type of image to be created. environment variable description IMTYPE the default image type (extension) IMDIR pixel storage directory for OIF images The IMDIR environment variable defines the directory in which the pixel file is to be placed when creating a new OIF format image. In V2.2 and older versions of IRAF, IMDIR could only be a logical or machine dependent directory pathname. The new system also recognizes the special "builtin" logical directory name "HDR$" (must be upper case). If the value of IMDIR is "HDR$", IMIO will create the pixel file in the SAME directory as the header file, rather than in some other directory. It is also possible to place the pixel file in some subdirectory of the header directory, e.g., "HDR$pixels/" will cause the pixel files to go into the subdirectory "pixels". set imdir = "/tmp/user/" # pixel files -> specified directory set imdir = "HDR$" # pixel files -> header file directory set imdir = "HDR$pixels/" # pixel files -> subdirectory of HDR$ The root filename of OIF pixel files is now the same as that of the header file, rather than a computer generated name. The filename extension of an OIF pixel file is ".pix". The STF format images support group format, a format very similar to that used for group format FITS tapes. IRAF users accessing an STF group format image can specify the `group' (subimage) to be accessed by appending a subscript to the image name, e.g., cl> imstat pix.aah[3] # access group 3 or cl> imstat pix.aah[3][*,100] # line 100 of group 3 A new group format image can be created in a similar fashion, specifing the number of groups to preallocate space for, e.g., cl> imcopy dev$pix testimage[1/10] would create a new group format image "testimage" with space for 10 groups (subimages), and initialize group 1. The remaining groups would then be initialized by specifying only the group subscript "[N]". Note that all groups must be the same size, new groups cannot be allocated, old groups cannot be deleted, the set of possible group parameters is fixed at creation time, and all groups share the same FITS header. 15 June 86 System Tasks ------------------------------------------------------------------------------- The DIRECTORY, HELP, and PAGE system tasks have all undergone important revisions. The directory task has been completely rewritten and now handles directory pathnames, etc., correctly, and in addition it has a more concise syntax. The HELP and PAGE tasks have been modified to replace the old "more" boolean query mechanism (used to pause between pages of output) with a nicer keystroke driven mechanism which offers more options and is faster. Read the manual pages for additional details. The old parameter files should be unlearned. 28 April 86 Package Reorganization ------------------------------------------------------------------------------- The basic package structure of IRAF has been modified to make a distinction between the system packages and the NOAO optical astronomy packages. The basic directory structure of the system was also changed to reflect the new package organization, and the printed documentation will be changed as well when time permits. These changes were necessary to better isolate science software such as the NOAO and STScI/SDAS packages from the system software, for a more logical package structure, and to make it easier to install and maintain the science packages. The new root menu of IRAF is as follows: dataio images lists noao sdas system dbms language local plot softools utilities The NOAO menu is as follows: artdata astutil focas mtlocal proto twodspec astrometry digiphot imred onedspec surfphot Three new packages were added and three old packages were extensively revised. The NOAO mountain tape readers were moved from the DATAIO package into the new MTLOCAL package. The astronomically oriented utility tasks were moved from the UTILITIES package to the new ASTUTIL package. The old LOCAL package was renamed PROTO, and a new LOCAL package was added in the directory "iraf$local/tasks". The concept of the new PROTO package is appropriate for what the old LOCAL package was used for, i.e., prototype, temporary, or contributed tasks which are part of the NOAO package and which are exported with the system, but which are expected to eventually disappear or be replaced by planned system facilities. The new LOCAL package is a place to put tasks of strictly local interest, or tasks which are not portable, e.g., foreign tasks and the Peritek package. The LOCAL package should be particularly useful for outside sites as it gives them a place to put locally added tasks which will not be affected by future updates of the system. Also, the framework (mkpkg, local.cl, etc.) is all set up, making it easier for outside sites to add their own software without having to figure out how to set up an IRAF package. 20 Feb 85 Recovery from Interrupts ------------------------------------------------------------------------------- Tests today (unfortunately only shortly before the first IRAF release) have shown that VMS/IRAF has higher failure rate than expected for recovery from a ctrl/c interrupt of a running subprocess, especially if the process is actively doing i/o. It is probably much safer to interrupt a compute bound process than a process which is doing heavy i/o, e.g., reading a tape or doing many file opens, or probably large numbers of any type of system calls. The failure rate for i/o intensive processes was as high as 1 failure to recover in 4 interrupts in some of the cases tested. Testing of UNIX/IRAF turned up some of the same problems, but the failure rate was considerably lower, probably because the kernel and i/o system are so much simpler. Interrupting a process at the wrong time can cause many problems, e.g., [1] subprocess memory can be corrupted, resulting in unpredictable behaviour and possibly deadlock when the CL later tries to talk the the process, [2] a VMS forced exit of the process can occur, e.g., when trying to deliver an AST to an invalid address, [3] corruption of the CL/subprocess communications protocol can occur, resulting in deadlock or the loss of sync (the output of a task will come out when the next command is entered), and various other problems as well. Tests on the old version of VMS/IRAF, which dates back to last fall, show that the problem has existed all along. The fact that we did not fully appreciate the problem until now indicates that the problem is not a serious hindrance provided one is conservative about the use of interrupts. It also appears that this will not be an easy problem to solve, hence it is likely to be with us for a while. Probably nothing at all will be done about it for some months since other projects are likely to have a higher priority if this problem is understood and can be worked around. In summary, try to minimize the use of interrupts, and in particular, avoid interrupting processes which are doing heavy i/o. When in doubt, type "flpr" after interrupting a process to force it to be restarted. If a subprocess becomes hung it may be necessary to restart the CL itself. 20 Feb 85 Process connect failure during ":.snap" in cursor mode ---------------------------------------------------------------------------- We are still ocasionally having problems when trying to spawn a graphics subkernel in response to a ":.snap" command in cursor mode. This happens infrequently (which is why it is so hard to find the bug), and will usually go away after exiting and reentering cursor mode and trying again. It might also help to do a ":.gflush" while in cursor mode.