maravelias.info

IRAF has become lately available through Debian‘s repositories. So I was curious to see how it works. But I was missing the right moment. About a month ago, I finally found the proper motivation so I went on to install it. As always … there were a few, minor, problems. Thanks to John K. we were able to resolve them! What follows is a small guide of what I faced during the installation (on a Debian 10/Buster).

Instead of previous (relatively) easy solutions to install IRAF now you can just do:

sudo apt-get install iraf

And the magic happens! It is typical to “mkiraf” then to build the necessary login.cl file. And that’s the very first problem as there is no such a thing (try mkiraf and you will get nothing).

Fortunately, mkiraf is not that necessary as the login.cl is just an ascii file with some default parameters set. We can easily copy such a file from another machine and we can put it here (under a proper directory, typically I create one under home, such as /home/user/iraf/). In all cases, what we need to change is the first few lines:
set home = "/home/user/iraf/"
set imdir = "home$images"
set cache = "home$cache"
set uparm = "home$uparm/"
set userid = "user"

where you replace the user with your username (or you put the appropriate path in the first line, and your username in the last one).

Another key feature is the shell used (typically xterm, xgterm, …). The original login.cl file will have already something (as the shell type is asked when IRAF is set with mkiraf), similar to:
# Set the terminal type. We assume the user has defined this correctly
# when issuing the MKIRAF and no longer key off the unix TERM to set a
# default.
if (access (".hushiraf") == no)
print "setting terminal type to 'xterm' ..."
stty xterm

Either you do not need to do anything (if you have xterm installed already) or you place the shell you are using.
Do not edit anything else from the rest of the file as these are the default IRAF parameters.

[NOTE: copy a fresh login.cl after running mkiraf, else you may end up with a version of a file with modified parameters set by the owner – although you should be always careful to ‘unlearn’ the commands and check the parameters used!)

Then you should be ready to use IRAF! Typing the usual “cl” or “ecl” unfortunately doesn’t work¹ (and it is a bit frightening at the beginning). But with this installation you just do “irafcl” and the normal ecl terminal starts immediately (nice!).

However, ecl is not that convenient, so we urgently needPyRAF. This can be easily installed through pip:

pip install pyraf
pip3 install pyraf

(for Python 2 and 3, respectively). Now even though pip instals all files under separate dirs it builds only one binary under ~/.local/bin/pyraf. So if you installed PyRAF for python2 first, you will see it running properly when using python2. If you add also pip3 version then you will notice that only PyRAF for python3 is available. Frustrating? You bet!

After some exploration we figured out that PyRAF creates only one binary so it overwrites the previous one. Although we tried to change the name and see if it can run individually this didn’t work (for whatever reason … probably bound to something else?). So there is no way (I wonder?) that you can have PyRAF for both Python versions. [Before asking why to keep both versions, keep in mind that somebody may want to use scripts from older versions! ]

The (not at all convenient) solution found so far is to:

1. install first PyRAF for Python v2
2. rename the pyraf binary (~/.local/bin/pyraf) to something else (e.g. pyraf-v2, this is only a back up as it doesn’t work even if you call it explicitly)
3. install PyRAF for Python v3
4. keep the pyraf binary as it is (for use with Python 3)
5. change the names accordingly if you want to use the older version

[There is another package python3-pyraf that I didn’t test², as I tend to keep as clean as possible Python’s installations by using pip only.]

However, even after that PyRAF may still not run properly. For example:
user@mymachine:~$ pyraf

Your “iraf” and “IRAFARCH” environment variables are not defined and could not
be determined from /usr/local/bin/cl. These are needed to find IRAF tasks.
Before starting pyraf, define them by doing (for example):

setenv iraf /iraf/iraf/
setenv IRAFARCH linux

at the Unix command line. Actual values will depend on your IRAF installation, and they are set during the IRAF user installation (see iraf.net), or via Ureka installation (see http://ssb.stsci.edu/ureka). Also be sure to run the “mkiraf” command to create a logion.cl (http://www.google.com/search?q=mkiraf).

What is missing now is to define these environment variables properly. You can either type the following lines in the terminal or add them to your .bashrc file, so that PyRAF is available at all times:

export iraf='/usr/lib/iraf/'
export IRAFARCH='linux'

Another working IRAF/PyRAF environment has been deployed!

17/7/2019 Update: Check olebole’s comment below regarding points 1 and 2.

During the last few days I have struggled a bit with the wavelength calibration of some long-slit spectra. When using the identify task of IRAF I found that I could select (“m”ark) only some of the lines, without any clear indication why the rest were not recognized (some were indeed stronger but others were equal or weaker). The actual error that kept popping out was “Center not found: check cursor position”. Although I went on to investigate all parameters (even the aidpars !) the one thing that solved the problem was finally to increase a bit the full-width of the features to be identified (fwidth), from the default value of 4.0 to 10 pixels. Apparently some of the lines seems too wide to be determined as real features by the task.

Between 12 to 19 of September 2016, we organized the Ondřejov Summer School 2016, which was held at the Stellar Stellar Department of the Astronomical Institute (Czech Academy of Sciences), in Ondřejov. The main aim of the school was to provide students hands-on experience with real observational data, i.e. to understand observations, reduce them, and discuss their results. This project-oriented activity was supplemented with lectures on various techniques and one of them was a workshop on Python and IRAF/PyRAF.

As a workshop the main focus was given to show examples that the students could repeat at the own computers. Its structure was based on a very small introductory talk and then examples of how to use Python and IRAF in real problems. With this post I make public all of this material both as a reference and as a (hopeful) help to others.

Material:

I have been working lately with IRAF/daophot with the PyRAF environment in a 32bit machine and everything is smooth except for the fact that it takes many hours to finish the run in each field I examine. As I would like to finish this analysis as soon as possible I opted to use a 64bit machine (with a larger number of more powerful processors). But still, the daophot task was failing, in particular during the psf task of daophot (when it needs to plot the stars from which you select the stars to create the psf model). The error message was the following:

ERROR (851, “Cannot restore graphics world coordinate systems”)

The same error was raised in both 64bit machines I used (a. PyRAF 2.1.3 and IRAF 2.16.1 in Debian 8, b. PyRAF 2.1.7 and IRAF 2.16.1 in CentOS 7.2), and actually regardless if I used the pyraf or the native cl environment. So the most probable cause should be somehow connected with the 64bit architecture (even though one possibility could be a typo in the iraf/unix/hlib/extpkg.cl file [1], but this is not the case for these PyRAF versions).

After asking this very question in iraf.net forum [2] I got an answer from fitz that

The problem happens because in the 64-bit v2.15 port the size of the WCS graphics structure was changed, and a corresponding change was required in pyraf (which is responsible for the graphics the same way the CL is). This bug was fixed in pyraf but apparently only for the 32-bit version

The proposed workaround is to download the 32bit version of daophot (at [3]) and put it under iraf$noao/bin.linux64 directory. If this is under /iraf (under root) then you need root permissions to copy there and make it executable, preferably as chmod +x x_daophot.e, to make it available for all users in the same machine.

So, we have to keep in mind that the 32bit versions could be the replacement for other non-working tasks as well. Let’s hope that there will be finally future releases of PyRAF [4].

[1] STScI / PyRAF FAQ #1.5
[2] iraf.net/forum: “PyRAF and DAOPHOT – ERROR 851”
[3] ftp://iraf.noao.edu/iraf/v216/support/linux/x_daophot.e
[4] 0. Support Status : “Due to reduced budgets for HST, we can only provide minimal pyraf support. If you have a problem that cannot be solved quickly by our first tier support, we may be unable to help. This is unfortunate, but it is the best we can do with the resources available. “,
STScI / PyRAF FAQ #0, accessed 15 March 2016

After having looked and searched into the whole IRAF/PyRAF directory to point out the directory that contains the template spectra for the stsdas/synphot package it was just a matter of a quick look at the front page of the package to resolve the issue!

As it is said: “Since the data files used by synphot in its calculations are rather large, they are distributed separately”
and they provide the links to the compressed files containing all the template data.

At the beginning we started looking into which path these files are stored since you can call each template by using the environmental variable crcalspec$template_spectrum. But this variable looks at the path where these templates are stored (outside IRAF), as it is defined (when installed) though the crref variable.

Perhaps looking for this (after importing os):

os.environ["VARIABLE"]="/path/to/program"


This is needed for example to set the jref path in order for multidrizzle package to run through a script.

Without login.cl iraf/pyraf does not work properly. Some commands may execute (like zerocombine, ie the binaries) but when the command will need to retrieve some information (like wavelength calibration/plotting, even shell commands like ls ) it will not respond (see error examples below).

IRAF: Select a directory (like user’s home) and “mkiraf” (type it in a terminal) in this. This creates the login.cl and uparm directory. Then you should always start iraf from that directory (one of the main drawbacks).

PyRAF: Make an iraf directory (at user’s home) and inside this “mkiraf”. Then you can start pyraf from any directory (as it will always find the iraf directory previously created to search for parameters and settings). When you first run pyraf it will also create a pyraf directory (including a cache directory)

PyRAF errors (showing that a login.cl file is missing):
--> epar ccdred
...
File "/scisoft/lib/python2.5/site-packages/pyraf/iraffunctions.py", line 3051, in _expand1
(varname, instring))
IrafError: Undefined variable `uparm' in string `uparm$imdccdred.par'

--> ls
Traceback (innermost last):
File "", line 1, in
NameError: name 'ls' is not defined

What do you get if you combine IRAF and Python ? Of course something that starts with Py and ends with RAF, PyRAF, which combines IRAF’s tasks with the Python’s command (allowing to create more sophisticated scripts than the cl ones).

But in order to implement these abilities in a python script you have to include (aka import) the packages you want to use (thanks to this post!).
Suppose that we want to use the ccdhedit command which is included in noao/imread/ccdred package. Then we write:

#!/usr/bin/env python
from pyraf import iraf
from iraf import noao, imred, ccdred

iraf.ccdhedit("bias*.fit", parameter="imagetyp", value="zero")
print "All done!"

Every parameter is given inside the () like what we would do if we were using the command line. The wildcard * is still valid and the ccdhedit will change the imagetyp header keyword to zero all the bias images in this case.