Welcome to iraf.net Saturday, October 21 2017 @ 08:29 AM GMT
IRAF V2.15.1a Release Now Available
- Monday, November 22 2010 @ 11:24 PM GMT
- Contributed by: fitz
- Views: 2,252
The release of the IRAF V2.15 system (featuring 64-bit platform support) is now available from NOAO. This release covers both 32- and 64-bit Linux and Mac OSX systems (Intel and PPC) and is now recommended for all users and developers. Modified sources for some 30 external packages which have been ported to 64-bit are also available from the FTP archive extern directory. Support for additional platforms and updated external package distributions will be made available in the coming weeks.
IRAF v2.15 is now distributed as a single-file download for each supported platform. Installation is now just a matter of unpacking this single tarfile and executing the iraf install script. Similarly, v2.15 also features a new external package mechanism to automate the download and installation of packages. A full list of features and changes is detailed in the Release Notes.IRAF v2.15 Distribution Files:
This release include a unified linux architecture suitable for all 32-bit Linux distributions. Similarly, the macosx architecture is now a Universal (Intel and PPC) 32-bit distribution. On 64-bit linux platforms the architecture name is linux64, the macintel architecture name now refers explicitly to 64-bit OSX (Intel). Despite the architecture name changes, older external packages can continue to be used (see the README or 64-bit Port Guide for details).
Please contact us or post questions to the support forums with any problems or questions you may have.
Update 1/26/11: An IRAF v2.15.1 Patch is now available, see story below for details.
Update 1/27/11: Exernal package repository now linkec against v2.15.1
Update 2/21/11: An IRAF v2.15.1a Patch release is now available, see story below for details. All external package releases are now linked against this version of the system for all platforms.
IRAF V2.15 Release Notes November 22, 2010 Revised February 24, 2011 These notes provide a summary of the major changes in the V2.15 release. IRAF V2.15 is a major release of the IRAF system for all supported platforms. The main feature of this release is support for 64-bit Linux and Mac OSX systems, although there are numerous other enhancements as well. Because changes to the system interfaces were fairly substantial, and extended test release was made available to the community to gather feedback about potential problems in the science code. There were only a few reported problems and we now consider the system to be stable for general release and recommended for all users. More detailed technical documentation of all system changes will be found in the 'notes.v214' file in the iraf$local directory, detailed revisions notes for each application package are in the package directories in a file called Revisions, e.g. onedspec$Revisions. Please see also the 'sysnotes.v215' file in this directory for a detailed list of the V2.15 changes, and similar files for the detailed revisions of each patch. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Contents: ========= 1. V2.15 Upgrade/Installation Instructions - Single-File Downloads - Building IRAF From Source - External Package Management o Getting Started o Installing and Updating Packages o How it Works o Repositories o Server-Side Repository Description - Mixed 64-bit IRAF and 32-bit External Packages - External Package Changes in v2.15 - External Packages -- They're Not All The Same, Anymore 2. Highlights of This Release 3. Platform Support 4. Core IRAF Revisions Summary - New Tasks - Existing tasks with new parameters/defaults - Existing tasks with new capabilities 5. NOAO Package Revisions Summary - New NOAO Package Tasks - Existing tasks with new parameters/defaults - Existing tasks with new capabilities 6. Bug Logs Fixed by This Release ============================================================================ 1. V2.15 Installation Instructions ============================================================================ IRAF V2.15 is a major release and will require a new installation, there is no upgrade path from earlier releases. This is, in part, due to some architecture name changes, and in part due to new installation procedures. This applies only to the core IRAF system, existing external packages may continue to be used (after proper installation) however we generally recommend that packages be updated in this release as well. To install this release, you should download the binary distribution file appropriate for your machine (either Linux or OSX) and then identify yourself as one of the following users and follow the steps described: - I am installing for the First Time: 1) Create an 'iraf' directory (preferrably /iraf/iraf) and unpack the distribution file for your platform there. 2) Define $iraf in your environment (with a trailing '/') 3) Run the $iraf/unix/hlib/install script to install the system - I am replacing an existing IRAF installation: 1) Save any local configuration file (graphcap, extern.pkg, etc) of the existing IRAF installation to a separate directory 2) Delete the existing IRAF tree 3) Unpack the distribution in the existing iraf root directory 4) Replace/merge local configuration files - I am installing multiple IRAF versions: 1) Create a new 'iraf' root directory and unpack the distribution file for the host platform 2) Define $iraf in your environment to be the full path to the IRAF system you wish to be the system-wide default. If this is the existing iraf installation you can skip this step, to make the v215 the default you'll redefine $iraf and run the install script 3) Set $iraf and $IRAFARCH in your environment as appropriate for the desired version before running the 'cl' command or compiling software - I want to build the IRAF system from source: 1) Download the iraf-src.tar.gz (or as.pcix.gen.gz) source-only distribution file 2) Create a new iraf root directory and unpack the distro 3) Define $iraf, $IRAFARCH in your environment and source the $iraf/unix/hlib/irafuser.csh script. Note a C-shell is required for this step 4) Run the $iraf/unix/hlib/install script to install the system 5) Configure the directory tree for the proper architecture and compile, e.g. on a 64-bit linux system: % cd /iraf/iraf % setenv iraf /iraf/iraf/ and iraf$noao/bin. directory. Note there are combined Linux (iraf-linux.tar.gz) and OSX (iraf-osx.tar.gz) distribution files as well as a single distribution that includes all supported binaries (iraf-all.tar.gz) 3) Define $iraf in your environment (with a trailing '/') 4) Run the $iraf/unix/hlib/install script to install the system We recommend if possible that a dedicated machine be used for testing to avoid possible confusion with a multi-version system. Note that while environment variables can typically be used to control which version of IRAF is started, these same environment variables when defined in startup files such as .login or .cshrc can cause confusion when building software. --------------------- Single-File Downloads --------------------- This release introduces a change in the distribution model used for IRAF. Specifically, we recognize the majority of users will be running on single-user machines such as personal laptops or desktop systems (the earlier distribution model was based on the idea of a central server supporting many client machines). As such, the need for separate source and binary distributions and a separation of these in the directory hierarchy is now unnecessarily complicated for most users. While the previous form of the distribution files are still available, the preferred method is to use the single-file distributions. All distribution files include full source, differences are in which binaries are also included. These distribution files are as follows: iraf-src.tar.gz Source-only distribution iraf-all.tar.gz All support binary platforms iraf-linux.tar.gz Combined 32/64-bit Linux distribution iraf-macosx.tar.gz Combined 32/64-bit Mac OSX distribution iraf.lnux.x86.tar.gz 32-bit 'linux' architecture iraf.lnux.x86_64.tar.gz 64-bit 'linux64' architecture iraf.macosx.uni.tar.gz 32-bit 'macosx' architecture (Universal Intel/PPC) iraf.macosx.x86_64.tar.gz 64-bit 'macintel' architecture (Intel only) All that is required for a complete IRAF installation is to download one of the above files and unpack in the desired iraf root directory before running the hlib$install script. ------------------------- Building IRAF From Source ------------------------- For source-only distributions, v2.15 includes a toplevel Makefile that automates the system build process. For example, % mkdir -p /iraf/iraf # create iraf root dir % cd /iraf/iraf # go there % tar zxf /path/iraf-src.tar.gz # unpack source tarball % setenv iraf /iraf/iraf/ # trailing '/' required % setenv IRAFARCH # set platform architecture % source $iraf/unix/hlib/irafuser.csh # pick up other env definitions % $iraf/unix/hlib/install # run the install script % make # configure system architecture % make sysgen # build the system While building the system from source is not required for most users, it is now much simpler. Where this new 'make' capabiity may be useful is in the case of user support recommending a code change to fix a bug and a recompile of the system is needed. This process is now just a matter of % setenv iraf /iraf/iraf/ # trailing '/' required % setenv IRAFARCH # set platform architecture % make # configure system architecture % make update # update the system This process is now the same whether there is an indivual application change, or a system interface change that affects all tasks needing relinking. --------------------------- External Package Management --------------------------- Dynamic package loading is a new feature in v2.15 that allows for package directories created in the iraf$extern directory to be automatically defined when the CL is started. The means that external package installation no longer *requires* that the hlib$extern.pkg file be edited to define the package, although that remains an option for packages which somehow cannot conform to this new scheme. Getting Started --------------- The IRAF v2.15 system is shipped with no defined external packages, instead we assume packages will be installed using this new feature. To begin, simply execute the 'configure' script in this directory to create the files needed. For example, % ./configure This will create a local 'manifest' file of packages available form the IRAF reposistory and iraf.noao.edu and skeleton directories of available packages will be created automatically along with a Makefile used to do the actual installation. THIS STEP IS REQUIRED BEFORE PACKAGE INSTALLATION! To get a listing of packages that can be installed, or to check which installed packages might need to be updated or are newly available, use the command: % make check Each listed package may then be installed using a simple 'make' command. For packages not on the list, a manual install is still required. The external package tree may be initialize to the distribution state using the command: % make init Updates to the distribution mechanism itself is done using the command: % make self_update This last command is used to update the system to new features or bug fixes that might be available as the mechanism evolves. Installing and Updating Packages -------------------------------- External packages may now be installed with a command such as: % make ctio mscred stsdas Note that dependency packages for each requested package will automatically be added to the installation so you do not need to necessarily list every package (e.g. you'll get FITSUTIL automatically by installing MSCRED, TABLES for STSDAS, etc). The next time you login to the CL the requested package will be defined. To update packages to the latest version at any time, use the command % make update The information about available packages will be updated, then a comparison of the timestamps of your installed packages with those on the repository will be made. If newer package versions are available they will be updated (along with dependencies) automatically. If a binary repository distribution of a package is not available at the moment, a 'source only' distribution will be installed and you will note a "[SOURCE ONLY]' status from the make command. The user is then responsible for compiling the packages locally even though the package will still be defined for use (but unusable). Our goal is to provide a binary distribution for all available packages we can reasonably support. Script- only packages will be installed and available for all platforms. How it Works ------------ This scheme relies on IRAF v2.15 changes to the CL login process to scan this directory for packages, as well as a server-side respository of distribution files suited for this method (see below). The 'configure' script customizes the package information for your platform and creates a 'Makefile' based on that information. Subsequent commands update these files, however we don't yet provide an automated system for multi-platform support. Multi-platform packages may be installed by setting the IRAFARCH environment variable to the desired architecture before issuing a 'make' command to install the package. The bulk of the work is done using utility scripts found in the iraf@util directory and called from the iraf$extern/Makefile. The management of the repository files is the responsibility of the distribution maintainers (by default, NOAO). Please contact us if you wish to have your package added to this repository system. Repositories ------------ The default package repository is defined in the $iraf/util/pkgrepo script and may be changed to point to a local respository (e.g. a mirror site). It may also be changed by pointing the 'IRAF_REPO' environment variable to a new URI source, e.g. setenv IRAF_REPO "ftp://localhost/myrepository" Of course, a network connection is assumed to exist in all cases. Local repositories may be preferred for faster local access via mirrors, please contact us for information on creating one. Server-Side Repository Description ---------------------------------- [The following comes from the README file on the repository] This is the IRAF v2.15 distribution repository directory. Files here are bundled so as to allow them to operate with the dynamic package mechanism or IRAF install procedurs for v2.15. Aside from the repository files themselves, this directory contains README This file REPO.DESC A description of each package MK Utility script to update repo checksum/manifest CHECKSUM Checksums files on repo tarballs created by MK REPO.MANIFEST Manifest file The MK script is used to generate the CHECKSUMS file and REPO.MANIFEST file automatically, it should be run whenever a package is installed or updated. The REPO.DESC file is a handcrafted description of the available package, this is important to describing the dependencies of each package. The MK script is also capable of determining which of the available packages may be used on which platform. For example, a "redhat" package will suffice for both a linux64 and linux IRAF system if there is no specific version available. The manifest file created will then list the redhat version as the file to be installed for the linux/linux64 platforms. If a binary distribution for a particular package is not provided, the MK script will default to use the source distribution tarball (if available). On the receiving end the user will then have the option of compiling the package locally. The reserved name "universal" is used for script-only packages, or distributions containing binaries for all supported platforms. When packages are installed in the IRAF dynamic package tree, both the REPO.MANIFEST and REPO.DESC files are downloaded. Scripts use these files to build up package lists that are available for a particular platform, as well as which packages are required to be installed to support the requested package. We assume the REPO.DESC file lists full dependencies, e.g. if A requires B, and B requires C the the dependency list for A is both B and C. The convention for file names is as follows: -.tar.gz where is the package name and is the iraf architecture. For external packages, tarfiles are build at the toplevel, i.e. when unpacked, a subdirectory of the package is created in th current directory. For IRAF distributions we violate this rule and assume the tarball is built from the $iraf root directory. When installing a new package, the REPO.DESC file should be edited and the MK script should be run. When installing an update to an existing repo package, or a new architecture version of a package, the MK script should be re-run. ---------------------------------------------- Mixed 64-bit IRAF and 32-bit External Packages ---------------------------------------------- In some cases, external packages can or will not be ported to 64-bit systems or otherwise updated with a new release, however IRAF v2.15 is very forgiving in the way that is allows multiple architectures to be used. For example, where the core system architecture might be 'linux64', external packages containing only the 32-bit 'linux' or older 'redhat' bin directories will be used automatically when a native 'linux64' binary cannot be found. The same is true for mixing the macintel and macosx architectures. Especially for 64-bit platforms we recommend users re-install external packages to get the latest version, however simply using an existing directory tree of packages that are defined in the hlib$extern.pkg file should continue to work as with all earlier IRAF releases. --------------------------------- External Package Changes in v2.15 --------------------------------- Support for 64-bit systems required changes to applications code that includes tasks in external packages. In many cases, these changes were trivial to make, in other cases it was realized that some external packages have either become redundant with core system tools, or are otherwise now obsolete. Because there are now source-code incompatabilities between v2.15 and earlier systems (specifically, a package modified for v2.15 might not compile on an earlier system), a new directory of v2.15 external packages was created to remove from distribution those packages that are no longer required, to release updated versions of supported packages that are now 64-bit enabled, and to re-bundle distribution files of packages maintained by outside sites that can be installed by the new package manager. A summary of the major changes to distributed v2.15 packages follows: COLOR Package is now part of v2.15 PROTO package without change. Need for external version is obsolete. FITSUTIL The NHEDIT task was removed and moved to the GMISC extpkg. This task has a different parameter interface than the version installed in v2.14 and the FITSUTIL version is only required for GEMINI package support. Moving this task to GMISC satisfied the GEMINI requirement and avoids conflicts caused by FITSUTIL in other packages. Package otherwise now compatible with v2.15. GEMINI Gemini has requested their package be removed from the v2.15 distribution system. We have no reason to believe this package is incompatible with IRAF v2.15 or other external package changes introduced in this release. GMISC Now includes the version of NHEDIT from an earlier FITSUTIL package version. This package will be mad eobsolete in a future IRAF release. MFILTERS All tasks are already included the core system. This package should no longer be listed as a dependency by other packages. NMISC All tasks are already included the core system. This package should no longer be listed as a dependency by other packages. STECF Distribution updated to last v1.5 release. STSDAS STScI has issued a statement about their plans for 64-bit support at http://www.stsci.edu/resources/software_hardware/stsdas/iraf64 Until/when a newer STSDAS package is available, the latest release of this package will continue to function under v2.15. TABLES TABLES was a required package for building core IRAF as well as several external packages. Thanks to the cooperation of STScI, the 'tbtables' library and TTOOLS tasks in this package are now part of the v2.15 system and satisfy these external requirements. Future TABLES releases will likely follow the model outlined above for STSDAS 64-bit support, however NOAO has now assumed primary responsibility for tbtables/TTOOLS platform support in v2.15 and beyond. The TABLES code in the core system is now essentially frozen except for bug fixes. To avoid conflicts with an existing TABLES installation, the TABLES.TTOOLS package tasks are installed as an NTTOOLS package in the UTIITIES package. For the moment, TABLES v3.12 and IRAF v2.15 UTILITIES.NTTOOLS are essentially the same code base, and since the TABLES code hasn't been updated in a while, there is some measure of backward-compatability with earlier TABLES versions even when using IRAF v2.15 and there is some confusion about which package currently is loaded. VOL Package is now part of v2.15 PROTO package without change. Need for external version is obsolete. In some cases there is no actual update of a package we distribute other than how the tar file is created (e.g. for script-only packages or re-packaging of packages developed by non-NOAO sites). While it may not always be possible to relink locally-developed packages against v2.15, neither is it required for these packages to continue to be used. A package which include binaries compatible on a v2.14 or earlier system can be declared for use in v2.15 without needing to be recompiled. Obviously, on 64-bit systems these packages will continue to run in 32-bit mode, developers are urged to review the 64-bit Porting Guide for information on how to update this code. ------------------------------------------------------ External Packages -- They're Not All The Same, Anymore ------------------------------------------------------- IRAF 64-bit support requires code changes, and in some cases NOAO has no actual control over what is supported by external developers, in other cases packages have limited usage in the community and don't automatically deserve the same level of support as more active packages. This leads to a stratification of external package support given our limited resources and our development model that an IRAF port do as much as possible to "bring along" external code to a new platform/release. IRAF v2.15 was designed to allow continued use of older package code whenever possible. Packages are now classified (in terms of how much support they'll receive) in an ad-hoc manner as follows: ACTIVE NOAO assumes responsibility for the package code and will update as needed for continued platform support. Examples include FITSUTIL, MSCRED, and NFEXTERN. An ACTIVE package might also include older code that is no longer being maintained by the original developers, but so long as it is trivial to build on supported IRAF platforms, can be built as a supported distribution. Examples include CTIO, RGO, MEM0 and XDIMSUM. UNIVERSAL Script-only packages require no specific platform support. Future releases will be checked for parameter changes, but otherwise we assume these packages work for all platforms. Examples include ESOWFI and CFH12K. DEPRECATED Existing packages which will be supported on platforms where the code compiles easily, however no extraordinary measures will be taken to provide binaries for all IRAF v2.15+ platforms. Examples include EUV and IUE. OBSOLETE These include packages no longer required to be external to the core system because tasks have already been included in the core release. If a re-issue of the package is required to expose new features this will become an ACTIVE package, otherwise these packages will no longer be available in the v2.15 release system. Examples include DIGIPHOTX, MFILTERS, and RVX. EXTERNAL These are packages actively maintained by non-NOAO institutions, often with their own release schedule and priorities. While we'll try to provide binary distrib- utions built from standard sources for the convenience of our users, we cannot offer direct support for applic- ations or support for 64-bit systems (due to code changes and testing required). Distribution binaries built for these packages will be unchanged, additional binaries we buid will be shared-risk, and we will refer questions to the developers for assistance when needed. Examples include STSDAS/TABLES, GEMINI and RVSAO. Developers who wish to include their packages in the IRAF v2.15 code repository system are encouraged to contact us to simplify installation for users. Likewise, code we now describe as 'obsolete' can be added to the repository upon request. ============================================================================ 2. Highlights of This Release: ============================================================================ o 64-bit Platform Binary Support Linux and Mac OSX systems running 64-bit operating systems are now supported in native 64-bit binary mode. There are currently NO plans to support 64-bit versions of other operating systems (e.g. Windows, Solaris, or FreeBSD). o New MEMIO Interface The MEMIO interface was necessarily changed to accomodate the 64-bit upgrade, specifically we added extra structure to a memory object to aid in debugging (e.g. sentinal values before/after a segment, a reporting mechanism etc). This adds a slight bit of overhead to each heap memory allocation, but we consider this to be minor given the capabilities of today's systems. A suite of environment variables can now also be set to manage/monitor this new interface (see below). o Single 'linux' Architecture for 32-bit Systems This is part of the overall architecture changes implemented in v2.15 systems. The original logic for separate 'suse', 'redhat' and 'linux' architectures was due to differences between these platforms in the GCC/GLibc systems used that were inherently incompatibile. These differences have since become irrelevant and now impose a burden to support and maintain separate platforms, and so a common 'linux' architecture is now preferred. Because external packages may lag in the changes needed to switch architectures, we try to support legacy references to e.g. 'redhat' as an alias to the new 'linux' structure and hope that the previous deprecation (in v2.14) of 'suse' has now been removed entirely. Since 64-bit support requires a new architecture name (i.e. 'linux' versus 'linux64') there will be no confusion between the 32- and 64-bit versions of systems. o Mac OSX Architecture Changes In previous IRAF releases the 'macintel' archicture was used for all OSX versions running on Intel hardware, and 'macosx' was reserved for PowerPC (PPC) CPUs. In order to avoid yet another IRAF architecture name to distinguish 64 and 32-bit Intel systems, and because OSX systems are moving generally towards Intel CPUs with 64-bit capabilities anyway, we decided that future IRAF systems will favor 64-bit Intel architectures as users upgrade machines. What this means is that starting with v2.15, the IRAF 'macintel' architecture will now refer exclusively to 64-bit Intel hardware. In order to retain compatibility with older systems, the 'macosx' IRAF architecture will encompass 32-bit binaries for both PPC and Intel CPUs in a Universal binary format. This is a departure from past platform architecture naming conventions where a new unique name is used, however future MacOSX systems will all be Intel-based and hardware will be 64-bit capable so shifting the focus to 'macintel' being the primary platform and 'macosx' supporting older systems made the most sense. (In hindsight, we would have preferred to be able to use 'macosx' as being more descriptive). The 'macosx' architecture now includes both PPC and Intel binaries in the system libraries (and those produced for external packages) and executables. These binaries are compatible for OSX 10.4 and later systems and the system will automatically use the appropriate binary for the hardware (e.g. on an OSX 10.4 PowerPC machine the PPC binary for the 'macosx' arch will execute the PPC binary in the iraf executable file). While earlier IRAF versions would allow that PPC 'macosx' binaries could be run on Intel systems using the Rosetta sytem, this isn't currently allowed with v2.15 as an Intel system would automatically use the Intel binary. Thus, to test 32-bit PPC binaries you will need a machine with a PPC CPU. This is seen as something that would affect a minimal number of users. o Compile-Time VOS/Kernel Prototype Checking All library code in the IRAF 'Virtual Operating Interface' (VOS) and IRAF Kernal (i.e. the $iraf/unix//os procedures) now have function prototypes that are checked during compilation of any SPP code. o Intra-Package Prototype Checking This is a feature that will be added in the near future and will provide the same level of prototype checking as with the core system libraries. The idea is that a 'libpkg.a' will produce a local prototype file that ensures all calls within the package meet the prototype calls. As with VOS/Kernel checking, this will validate the code within a package to trap any potential errors. o All C Library Code Converted to Clean ANSI-C As part of the 64-bit port, all C library code in the VOS and kernel was converted from the old-style "K&R" style to true ANSI C with full function prototypes. Additionally, the code was cleaned up to remove any warnings generated by the compiler, i.e. compilation with "-Wall" under GCC now compiles cleanly to further ensure the integrity of the code. o Cross-Compilation of Architectures Compilation is now defined by the user environment rather than the machine used to do the build, as before. What this means is that (within reason) it is now possible to cross-compile for a different IRAF architecture on machines which support such compilation. For instance, on a 64-bit Mac OSX Snow Leopard system (where the native IRAF architecture is 'macintel') one can now compile code for the 32-bit 'macosx' architecture (either PPC or Intel) by simply setting the 'IRAFARCH' environment varable as 'macosx' and reconfiguring the system/package approriately. The same is true for Linux 64-bit systems and 'linux64' and 'linux' architectures, meaning one doesn't need access to machines to produce binaries. Compilation flags are set auomatically based on the IRAFARCH variable in order to produce the desired binaries. o User-Selectable Architectures As with compilation, the IRAFARCH variable can be used to determine which binaries to run. For example, on a 64-bit Linux system (where the default arch would be 'linux64') the commands % setenv IRAFARCH linux % cl would allow a user to run the 32-bit 'linux' binaries and thus switch easily between systems to compare results and validate the science results of a reduction/analysis task. The same is true for Mac (Intel) systems where the 64-bit macintel and 32-bit macosx architectures could be selected by the user. o SVG Graphics Device for Better Web Presentation of Plots SVG graphics are an XML format supported by many modern browsers that permit scalable graphics for web presentation. This means that plots produced by IRAF may be used in web pages without loss of resolution or aliasing effects seen when using e.g. GIF images of a plot. A new 'g-svg' graphcap device was added to make use of this new driver. It produces a file called 'sgiXXXX.svg' in the current working directory (where 'XXXX' is a process id) and may be used as e.g. cl> contour dev$pix dev=g-svg or in cursor mode with a ":.snap g-svg". Either instance should be followed with a 'gflush' or ':.gflush' to flush to output to disk. SVG files can be embedded into HTML documents with the tag, the tag, or the tag. o Simplified Build From Source At the request of users, a toplevel 'Makefile' is now available for building or configuring the system with a single command. This Makefile is a simple driver for scripts that do all the work using conventional IRAF commands. Allowed 'make' command targets include: all alias for 'update' sysgen do a complete sysgen update update system since last sysgen updatex update with debugging flags enabled src clean system of current binaries clean clean system of current binaries pristine clean system of all binaries noao compile the NOAO package summary print core/noao/tables spool file summaries showarch show currently configure arch reconfigure for named architecture o Simplified Download/Install Process See the Single-File Installation description above. o Simplified External Package Installation See the External Package description above. o COLOR and VOL packages now part of Core System Both the COLOR and VOL external packages have been incorporated into the PROTO package. These packages are no longer being developed but are required by some users so will continue to be supported as prototype software. o Improved Documentation Thanks to Jason Quinn, the help pages for dozens of tasks have been cleaned of long-standing typo and formatting errors. In many cases Jason's suggestions have also served to clarify the meaning of the text, or correct the help wrt to how to task actually operates. ============================================================================ 3. Platform Support: ============================================================================ IRAF V2.15 supports only the following platforms: PC-IRAF - supports RedHat 9 thru Fedora/RHEL/Centos (LNUX) - supports Mac OS X 10.4 and higher (ppc and intel) (MACX) - supports Debian 3.1 and higher (LNUX) (The following platforms are planned but not yet available:) - supports FreeBSD 6.3 and higher (FBSD) - supports Solaris 10 (x86) (SSOL) - supports Cygwin (Windows XP and Vista) (CYGW) Sun/IRAF - supports SunOS 4.1 (SOS4) - supports Solaris 5.5.1 thru Solaris 10 (SSUN) Note that PC platforms not mentioned here specifically may still be supported by one or more of the distributions (e.g. Ubuntu can use LNUX). ============================================================================ 4. CORE IRAF REVISIONS SUMMARY ============================================================================ This section describes changes to tasks in the IRAF core system other than routine bug fixes. New Tasks --------- images.imcoords: hpctran - Convert between HEALPix row and spherical coordinate proto: mkglbhdr - Make global header from keywords in images and reference system: bench - Demonstration benchmark task Existing Tasks with New Parameters or New Parameter Defaults ------------------------------------------------------------ images.imfit.fit1d Adds new 'bpm' bad pixel mask parameter images.imutil.nhedit A 'rename' parameter switch was added to renaming a keyword. Existing Tasks with New Capabilities ------------------------------------ images.immatch.imcombine New 'quadrature' and 'nmodel' options to the 'combine' parameter are used for error propagation either with input sigma images (quadrature) or where the pixel sigmas may be computed by the noise model used by this task (nmodel). ============================================================================== 5. NOAO PACKAGE REVISIONS SUMMARY ============================================================================== This section describes changes to tasks in the NOAO package tasks other than routine bug fixes. New NOAO Package Tasks ---------------------- noao.nproto: skygroup - Group a list containing RA and Dec into spatial sublists skysep - Compute arc separation of two RA/Dec values Existing Packages and Tasks with New Parameters or New Parameter Defaults ------------------------------------------------------------------------- artdata.mkpattern Added 'long' to allowed list of data types. onedspec.specplot Added new 'transform' parameter to allow scaling the spectrum pixel values. Currently only 'log' is implemented. twodspec.apextract.apall Changed default for 'maxsep from 1000 to 100000. Existing Tasks with New Capabilities ------------------------------------ astcat.agetcat Added usnob1@usno, usnoa2@usno, nomad@usno and act@usno imred.doecslit imred.doefoe imred.doslit Changed the default maxsep from 1000 to 100000. Unless users reset the default their expectation is that marking apertures will not skip an aperture number no matter how far apart the aperturers are. fibers.skysub.cl Added 'sum' as an enumerated "combine" choice. nproto.skysep Added an 'enum' to the 'raunit' param to enforce choices. obsutil.sptime Made all graphs auto-scale. Added a "generic" disperser type to force using the desired wavelength and dispersion without defining a grating whose mapping between position on the detector and wave- length might be wrong. twodspec.apextract The 's' key now works on the current aperture rather than the nearest. ============================================================================== 6. BUG LOGS FIXED BY THIS RELEASE ============================================================================== The following buglog entries are fixed by the this V2.15 release: NUMBER: 567 MODULE: apall, apedit SYSTEM: V2.11-V2.14.1 DATE: Tue Oct 7 10:53:14 MST 2008 FROM: valdes BUG: The :parameters and :apertures commands cause the task to exit with an error that parameter "apertures" isn't found. This problem has existed for a long time due to a missing parameter in the hidden parameter sets. STATUS: Fixed for the next release. NUMBER: 568 MODULE: imcombine SYSTEM: -V2.14.1 DATE: Tue Oct 7 12:52:35 MST 2008 FROM: valdes BUG: When using avsigclip, ccdclip, or sigclip rejection around the median (mclip=yes) the resulting final median may be incorrect. This will generally only occur if unusually small low sigma values, such as lsigma=1, are used. This was due to using a wrong variable. STATUS: This is fixed for the next release. NUMBER: 570 MODULE: imexpr, mskexpr, or tasks other asks using the expression evaluator SYSTEM: -V2.14.1 DATE: Mon Nov 3 22:16:41 MST 2008 FROM: valdes BUG: Use of the built-in functions mod, min, max, and median produce an "incompatible types" error even though the types of the arguments are correct. This is a due to a coding error. There is no workaround other than using alternative ways to express the desired expression. STATUS: Fixed for the next release. NUMBER: 571 MODULE: IMAGES.IMUTIL.HSELECT SYSTEM: V2.14 DATE: Fri Jan 2 21:41:53 MST 2009 FROM: fitz BUG: The use of a '$' in a field name was causing the 'missing' value to always be printed even if the field exists in the image. This was caused by a failure to check for the character and removing it prior to getting the value from the header. There is no workaround, the code change is trivial. STATUS: Fixed for the next release. NUMBER: 573 MODULE: mscimage SYSTEM: - V4.9 August, 2008 DATE: Fri Sep 18 08:36:30 MST 2009 FROM: valdes (discovered and diagosed by Thomas de Boer) BUG: The task ignores the parameters "boundary" and "blank" which are fixed to be "constant" and "0." respectively. STATUS: This is fixed for the next release.