problem after installing patch 2.15.1
giannicatanzaro wrote on Mar 23, 2011
dear All
after installing 2.15.1a patch on my IRAF 64bit (run on openSUSE 11.3) I got a very curious problem. It seems that there is a problem with the number format, for instance the aperture and order are 20 digits numbers and wavelengths are exponentials.
anyone can help me????????
after installing 2.15.1a patch on my IRAF 64bit (run on openSUSE 11.3) I got a very curious problem. It seems that there is a problem with the number format, for instance the aperture and order are 20 digits numbers and wavelengths are exponentials.
anyone can help me????????
Mike Fitzpatrick wrote on Mar 23, 2011
What task are you using? Is this a plot label, text output, or is the aperture header being being modified?
giannicatanzaro wrote on Mar 23, 2011
fitz
What task are you using? Is this a plot label, text output, or is the aperture header being being modified?
hello
using splot the aperture header is modified, using ecidentify the x axis (in wavelenght) has an exponential format. I realize this problem
when I tried to continue lamp calibration, I suppose that the task
has some problem in reading the ecXXXXX file previous generated.
If I try to start from scratch with ecidentify, the file ecXXXX is the follow:
# Thu 08:58:08 24-Mar-2011
begin ecidentify thar_y.ec_f_red
id thar_y.ec_f_red
task ecidentify
image thar_y.ec_f_red
units angstroms
features 2
4922050882201190400 17 2364.58 2363.57959 6588.5396 4.0 1 1
4922050882201190400 17 2548.94 2547.93823 6583.906 4.0 1 1
offset 75
Mike Fitzpatrick wrote on Mar 23, 2011
I think you may be seeing the effects of
http://iraf.net/article.php/20110309004941989
If you installed the patch in the last few days it may be something else, if it was done around the time the v2.15.1a patch was first released then re-applying the patch may solve it.
http://iraf.net/article.php/20110309004941989
If you installed the patch in the last few days it may be something else, if it was done around the time the v2.15.1a patch was first released then re-applying the patch may solve it.
starryeyed wrote on Mar 23, 2011
fitz
I think you may be seeing the effects of
http://iraf.net/article.php/20110309004941989
If you installed the patch in the last few days it may be something else, if it was done around the time the v2.15.1a patch was first released then re-applying the patch may solve it.
I re-applied the patch and it was fine...most likely the same issue going on here...
giannicatanzaro wrote on Mar 23, 2011
StarryEyed
fitz
I think you may be seeing the effects of
http://iraf.net/article.php/20110309004941989
If you installed the patch in the last few days it may be something else, if it was done around the time the v2.15.1a patch was first released then re-applying the patch may solve it.
I re-applied the patch and it was fine...most likely the same issue going on here...
I installed the patch yestarday, anyway I re-installed it but the problem is not fixed. Any idea?
Mike Fitzpatrick wrote on Mar 23, 2011
To rule out problems in installing the patch, please do a
The binary should date from 3/10/2011 and be 7017362 bytes in size, if not then please let me know which patch file you installed.
Otherwise, it's possible there is still a bug but you'll need to post the parameters you used and upload a sample image to the anonftp at ftp://iraf.noao.edu/pub so we can reproduce it.
cl> dir noaobin$x_onedspec.e long+The binary should date from 3/10/2011 and be 7017362 bytes in size, if not then please let me know which patch file you installed.
Otherwise, it's possible there is still a bug but you'll need to post the parameters you used and upload a sample image to the anonftp at ftp://iraf.noao.edu/pub so we can reproduce it.
giannicatanzaro wrote on Mar 23, 2011
fitz
To rule out problems in installing the patch, please do a
cl> dir noaobin$x_onedspec.e long+
The binary should date from 3/10/2011 and be 7017362 bytes in size, if not then please let me know which patch file you installed.
Otherwise, it's possible there is still a bug but you'll need to post the parameters you used and upload a sample image to the anonftp at ftp://iraf.noao.edu/pub so we can reproduce it.
the binary is ok. I uploaded three files
ThAr.jpg - to show you what I get in the screen when run ecidentify
thar_y.ec_f_red - the Th Ar spectrum
ecthar_y.ec_f_red - is the file generated when I identify two lines
thanks for help
Gianni
Mike Fitzpatrick wrote on Mar 23, 2011
It seems this is a continuation of the earlier problem, i.e. the first fix wasn't correct in this case. I think it is finally fixed now, you can either try to apply the patch file again (sorry for the inconvenience) or else get just the patched x_onedspec.e binary file from ftp://iraf.noao.edu/iraf/v215/support/linux64/x_onedspec.e and install in the noao$bin.linux64/ directory.
Let me know if you continue to have problems.
Let me know if you continue to have problems.
giannicatanzaro wrote on Mar 23, 2011
fitz
It seems this is a continuation of the earlier problem, i.e. the first fix wasn't correct in this case. I think it is finally fixed now, you can either try to apply the patch file again (sorry for the inconvenience) or else get just the patched x_onedspec.e binary file from ftp://iraf.noao.edu/iraf/v215/support/linux64/x_onedspec.e and install in the noao$bin.linux64/ directory.
Let me know if you continue to have problems.
yes, it works fine now, many thanks
gianni :D
dvbowen wrote on Mar 23, 2011
Just a quick note... I spent the morning working on this problem too, before I found this post. I copied the x_onedspec.e file you linked to, and it looks like the fix does indeed work (yay!). I thought it might be worth mentioning though that the version of IRAF I recently installed is labelled "IRAF V2.15.1a February 2011" so should be a version with all patches included? It looks like I picked up iraf.lnux.x86_64.gz on March-17 2011, so I wonder whether the fix really *is* the most up-to-date version?
Thought the info might be useful!
Cheers
Dave
Thought the info might be useful!
Cheers
Dave
Mike Fitzpatrick wrote on Mar 23, 2011
That is the most up to date version, I simply forgot to change the date on the version strings in all the rush to put the patch together.
Nancy D. Morrison wrote on Mar 23, 2011
Some time ago, you kindly fixed a problem I, along with some other people, was experiencing with splot in 2.15. Unfortunately, at the time I was so delighted when your fix worked that I didn't pay attention to the 15-digit aperture numbers. The aperture editor provides sensible aperture numbers and writes them in the database file, so I reduced a night of spectroscopic data up to the ecidentify stage, at which point I started getting arithmetic exceptions, segmentation violations, etc.
Now, I've installed the March 11, 2011 version of 2.15.1a. I still get the 20-bit aperture numbers with splot or ecidentify, but the behavior of ecidentify has changed. You can mark features, but in response to an 'f' command or a :read it misbehaves. Before, it crashed with a segmentation violation or an arithmetic exception. Now, it just does nothing.
I am running 2.15.1a under OS 10.6.6 on a 64-bit MacBook Pro. The version test you suggested gives the following.
I have uploaded two sample images: 21.fits raw, 21x.fits extracted (for testing ecidentify) to your ftp site.
Thanks.
Now, I've installed the March 11, 2011 version of 2.15.1a. I still get the 20-bit aperture numbers with splot or ecidentify, but the behavior of ecidentify has changed. You can mark features, but in response to an 'f' command or a :read it misbehaves. Before, it crashed with a segmentation violation or an arithmetic exception. Now, it just does nothing.
I am running 2.15.1a under OS 10.6.6 on a 64-bit MacBook Pro. The version test you suggested gives the following.
ecl> dir noaobin$x_onedspec.e long+
xb-rwr-r- root 4807528 Mar 11 17:51 noaobin$x_onedspec.e
I have uploaded two sample images: 21.fits raw, 21x.fits extracted (for testing ecidentify) to your ftp site.
Thanks.
Mike Fitzpatrick wrote on Mar 23, 2011
I checked the binaries in the current distribution files and they seem to still be correct (or at least, they're the same as what was mentioned earlier in the thread). FITSVERIFY does show a number of errors on the FITS files themselves but the pixels look reasonable and I can otherwise use the files.
What DOES seem off however are the image names: IRAF doesn't generally like images with only numbers as names (and '21x' is interpreted as a hex value for 33) and tasks that create database entries or temp files may only use the root name which leads to other problems. The first thing I'd try is to rename "21.fits" to "foo.fits" to see if it makes a difference.
If not, please post the parameters and details of what you did so I can reproduce the problem. If you still have problems I'll have to pass this on to Frank as being the expert.
What DOES seem off however are the image names: IRAF doesn't generally like images with only numbers as names (and '21x' is interpreted as a hex value for 33) and tasks that create database entries or temp files may only use the root name which leads to other problems. The first thing I'd try is to rename "21.fits" to "foo.fits" to see if it makes a difference.
If not, please post the parameters and details of what you did so I can reproduce the problem. If you still have problems I'll have to pass this on to Frank as being the expert.
Nancy D. Morrison wrote on Mar 23, 2011
You are correct! Simply changing the file name from '21.fits' to 'f21.fits' solved both the aperture number problem and the ecidentify problem, at least at first glance. Thanks!
Last post on Mar 23, 2011