grayro |
07/01/2014 07:50PM (Read 3544 times)
|
|
|
Status: offline
Registered: 03/15/2014
Posts: 23
|
Hi,
I have just migrated to a new hard disk on my laptop. I have re-installed IRAF 2.16, and have as well installed the patch. However, when I run a script (called axom1_2cb.cl), which works perfectly well on other computers, I am consistently getting a segmentation fault early on when the script attempts to subtract the master bias from each individual dark frame. The offending code is as follows:
while( fscan(list,s1) != EOF) {
print(s1)
imarith(s1, "-", "BIAS",s1)
}
The list does indeed contain the names of the dark files, as indicated by print(s1) which prints out "dark0001" before choking on the imarith line. If I attempt to do this manually, it again fails with a segmentation violation:
imarith dark0001 "-" BIAS dark0001
but
imarith dark0001 "-" BIAS try
works. I know from scanning the forum archive that imarith should automatically overwrite. Indeed, the bias subtracted dark is produced, and has the name tmpNNNNa.fits, but imarith is apparently failing then in overwriting the dark0001. This works without fail on all other machines I have running iraf, including on the old hard disk on the laptop. Any clues??
Richard
|
|
|
|
grayro |
07/16/2014 01:42PM
|
|
|
Status: offline
Registered: 03/15/2014
Posts: 23
|
Hi,
I posted this problem over two weeks ago with no reply. I am still having this problem. I have tried a number of things to try to resolve this problem, including making the output type from all rfits reads a uniform type (real). But no success. I could try to reinstall IRAF but would like to know if there is an easy workaround or solution before I do that.
Richard
|
|
|
|
fitz |
07/16/2014 06:32PM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
Check that your 'cache' environment variable is NOT set to /tmp. This gets defined initially when you run the install script, and is also set in your login.cl file, however a /tmp/ path has a known bug that will be fixed in the next release. The workaround is to reset the 'cache' variable to home path such as /iraf/cache/ or rerun the install script and set the path when prompted.
|
|
|
|
grayro |
07/16/2014 07:45PM
|
|
|
Status: offline
Registered: 03/15/2014
Posts: 23
|
Hi,
My login.cl file sets the cache to /iraf/cache/iraf1. On my machine I set up IRAF using username iraf, but when using IRAF for reducing data, I do it under the iraf1 account. The /iraf/cache/iraf1 directory exists. It belongs to iraf, and iraf1 only has read and execute permissions. Should it have write permission as well, or am I barking up the wrong tree?
If I run printenv after starting iraf, I do not see a cache environment variable.
Richard
|
|
|
|
fitz |
07/16/2014 09:06PM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
Yes, the cache directory should be owned by the same user and/or have write permissions. In your case, if you use the 'iraf1' account then the /iraf/cache/iraf1 directory should be owned by iraf1 and have permissions of at least "drwx-------", also be sure the cache path is specified in the login.cl/environment as having a trailing '/' (i.e. "/iraf/cache/iraf1/").
'printenv' is a unix command, to see the value in IRAF use "cl\$this->_split2($m[0]) show cache" (or just "cl\$this->_split2($m[0]) show" for all variables).
|
|
|
|
grayro |
07/16/2014 09:29PM
|
|
|
Status: offline
Registered: 03/15/2014
Posts: 23
|
Hurray! That did it. Thanks!
Richard
|
|
|
|