Welcome to iraf.net Monday, December 18 2017 @ 05:16 AM GMT

IRAF V2.15.1a Release Now Available

  • Monday, November 22 2010 @ 11:24 PM GMT
  • Contributed by:
  • Views: 2,317

    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.
        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
        - 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
    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
        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.
        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:
        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
        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
    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
    		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
        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
                    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).
    	This section describes changes to tasks in the IRAF core system
    other than routine bug fixes.  
    New Tasks
            hpctran - Convert between HEALPix row and spherical coordinate
           mkglbhdr - Make global header from keywords in images and reference
              bench - Demonstration benchmark task
    Existing Tasks with New Parameters or New Parameter Defaults
            Adds new 'bpm' bad pixel mask parameter
            A 'rename' parameter switch was added to renaming a keyword.
    Existing Tasks with New Capabilities
    	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).
    	This section describes changes to tasks in the NOAO package tasks
    other than routine bug fixes.  
    New NOAO Package Tasks
           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
            Added 'long' to allowed list of data types.
            Added new 'transform' parameter to allow scaling the spectrum
            pixel values.  Currently only 'log' is implemented.
            Changed default for 'maxsep from 1000 to 100000.
    Existing Tasks with New Capabilities
    	Added usnob1@usno, usnoa2@usno, nomad@usno and act@usno
        	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.
     	Added 'sum' as an enumerated "combine" choice.
    	Added an 'enum' to the 'raunit' param to enforce choices.
    	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.
    	The 's' key now works on the current aperture rather than the nearest.
    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
    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
    STATUS:	Fixed for the next release.
    NUMBER:	571
    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.
IRAF V2.15.1a Release Now Available | 9 comments | Create New Account

The following comments are owned by whomever posted them. This site is not responsible for what they say.

  • IRAF V2.15 Release Now Available
  • Authored by: nev on Tuesday, November 23 2010 @ 06:40 PM GMT
Congratulations on 2.15 Release!
  • 2nd "64-bit Port Guide" link in the news text is missing 'D'. It links to PORT.GUIE
  • Where is iraf_v215-src.tar.gz ?
Thanks for your time, N::
  • IRAF V2.15 Release Now Available
  • Authored by: fitz on Tuesday, November 23 2010 @ 06:46 PM GMT
Thanks for the link typo, it has been fixed. Look for the
addition of a 'src' and combined-binary distribution files
later today (there'll be new links on the homepage), the
repository files and docs are being polished as well.
  • IRAF V2.15 Release Now Available
  • Authored by: jrl on Thursday, December 02 2010 @ 12:44 PM GMT
Hi, I'm having trouble with the 2.15 version of ecl on my fedora 13 laptop. The old problem with undefined libtermcap.so has resurfaced. Would it be possible to have a statically linked version of ecl? Thanks very much!

cheers, Jim
  • IRAF V2.15 Release Now Available
  • Authored by: fitz on Friday, December 03 2010 @ 10:38 AM GMT
See http://iraf.net/ftp/pub/fitz/ecl.e for a static 32-bit
binary (will run on 64-bit). There've also been some
recent posts about this suggesting how to make a symlink
to resolve the library, e.g.
  • IRAF V2.15 Release Now Available
  • Authored by: fitz on Tuesday, December 07 2010 @ 08:07 AM GMT
I've put new binaries of the ECL in


for each platform that was linked against the '-lncurses'
library instead of the older '-ltermcap' lib that should
hopefully fix this problem. There are still issues with
building a static version of the binary, however if you
want one a 32-bit linux static binary is available at


If you still have problems with shared libs in the above
binaries please post back.
  • IRAF V2.15 Is their a cygwin version available
  • Authored by: robsteele49 on Monday, December 06 2010 @ 11:47 PM GMT
Is their a cygwin version available for version 2.15?

Rob Steele (Robert.D.Steele@jpl.nasa.gov)
  • IRAF V2.15 Is their a cygwin version available
  • Authored by: fitz on Monday, December 06 2010 @ 11:59 PM GMT

Not yet, it'll be in the next round of platform releases.
Also, there are no plans (or means) to support 64-bit on
Cygwin (32-bit XP is still the baseline system used to build
the release).
  • IRAF V2.15 Release Now Available
  • Authored by: robsteele49 on Tuesday, December 07 2010 @ 09:01 PM GMT
Sounds good. Any estimate when this might be ready for prime time?

Rob Steele (Robert.D.Steele@jpl.nasa.gov)
  • IRAF V2.15 Release Now Available
  • Authored by: fitz on Wednesday, December 08 2010 @ 12:06 AM GMT
After the new year is all I can promise for sure, likely in
the next few months as time permits. Cygwin is not a
major platform for us.

Privacy Policy
Terms of Use

User Functions