imexam problems in 2.15.1a on 64 bit Mac
Mike Smutko wrote on Mar 22, 2011
I am trying to use imexam with ds9 and IRAF 2.15.1a on a new i7 macbook pro. But when I try to use c, r, j, k, h inside of imexam I get either strange plots or "ERROR: arithmetic exception" and imexam crashes. This happens using either xterms or xgterms.
The same fits file works correctly on an older macbook pro running IRAF 2.14. Oddly, an older fits file from the same instrument works correctly on the new Mac with IRAF 2.15.1a. I don't understand why the old file works but not the newer one.
But as it turns out, the instrument had some electronics changed recently, so I'm trying to figure out if the problem is in the new fits files, my new IRAF install, or both.
Is there somewhere that I can post a couple of fits files for you to take a look at and try to reproduce my problem?
The same fits file works correctly on an older macbook pro running IRAF 2.14. Oddly, an older fits file from the same instrument works correctly on the new Mac with IRAF 2.15.1a. I don't understand why the old file works but not the newer one.
But as it turns out, the instrument had some electronics changed recently, so I'm trying to figure out if the problem is in the new fits files, my new IRAF install, or both.
Is there somewhere that I can post a couple of fits files for you to take a look at and try to reproduce my problem?
Mike Fitzpatrick wrote on Mar 22, 2011
Sample files can be posted to the anonftp at ftp://iraf.noao.edu/pub
It would help if you could better define "strange plots" or show a screenshot of what "works correctly" at a particular coord.
It would help if you could better define "strange plots" or show a screenshot of what "works correctly" at a particular coord.
Mike Smutko wrote on Mar 22, 2011
Sorry to be vague; I don't know how to describe it and it wasn't obvious how to attach screenshots to these posts.
Anyway, I've posted two files to the anonftp site:
a_2011.fits.zip which is an example of the files that are causing problems
g_2005.fits.zip which is an older file that works fine
mfs485-1.png is an example of what I get when I try to use imexam with the 'c' command on a_2011. Notice the range of pixel values: 10^13 ! Also notice how the bottom half of the chip goes to zero.
mfs485-2.png is an example of what I get if I try 'j' on a star in a_2011. I get arithmetic exception every time. I also get an exception with the k and r commands.
mfs485-3.png is an example of 'j' on star in the older file b_2005. Everything works as expected.
Please let me know if I can send any other info.
Anyway, I've posted two files to the anonftp site:
a_2011.fits.zip which is an example of the files that are causing problems
g_2005.fits.zip which is an older file that works fine
mfs485-1.png is an example of what I get when I try to use imexam with the 'c' command on a_2011. Notice the range of pixel values: 10^13 ! Also notice how the bottom half of the chip goes to zero.
mfs485-2.png is an example of what I get if I try 'j' on a star in a_2011. I get arithmetic exception every time. I also get an exception with the k and r commands.
mfs485-3.png is an example of 'j' on star in the older file b_2005. Everything works as expected.
Please let me know if I can send any other info.
Mike Fitzpatrick wrote on Mar 22, 2011
Thanks for the data. I can reproduce the problem but it appears to be data-specific, i.e. any other 32-bit integer FITS file I have works fine. I'll have a look and let you know when I figure out what's happening.
Mike Smutko wrote on Mar 22, 2011
Thanks--glad to know that I wasn't just doing something dumb. Let me know if you'd like any more example files.
Mike Smutko wrote on Mar 22, 2011
Hi Fitz, any progress in tracking down this bug? I've got a deadline coming up, so I'm trying to decide if I should hang in there for a fix or give up on 2.15.1 and go back to 2.14.
Mike Fitzpatrick wrote on Mar 22, 2011
I'm sorry to ask, but could you upload the image again and I'll try to get you an answer by Monday. Did you have any luck in finding out whether the new instrument files were indeed different, and how??
Mike Smutko wrote on Mar 22, 2011
I have uploaded the images again as mfs485.tar.gz The filenames are the same as I described in the earlier post above.
It's a strange combination of events. If I use older files (g_2005) under 2.15, they work fine. Also, if I use the newer files (a_2011) on a different Mac running IRAF 2.14, they also work fine. There's something about the combination of the newer files and IRAF 2.15 that doesn't work.
I will email the camera builders to see if they can provide any info and report back.
It's a strange combination of events. If I use older files (g_2005) under 2.15, they work fine. Also, if I use the newer files (a_2011) on a different Mac running IRAF 2.14, they also work fine. There's something about the combination of the newer files and IRAF 2.15 that doesn't work.
I will email the camera builders to see if they can provide any info and report back.
Mike Fitzpatrick wrote on Mar 22, 2011
I think I found a problem that was caused by relative differences between the size of the integer values used internally, and the real valued array being used by the task. In theory this affects all tasks, but practically speaking it only affects columnar access to the data.
In any case, I've put a patched x_tv.e binary in ftp://iraf.noao.edu/iraf/v215/support/macintel that should fix your IMEXAM problem, there's also an x_images.e binary that will fix many other tasks.
Longer term until a patch is built, I'd suggest you install the V2.15 that includes both the 'macosx' and 'macintel' binaries. if you run into other problems a quick workaround is to then fall-back to using the 32-bit binaries by setting an 'IRAFARCH' environment variable (with a value of 'macosx') before logging into the CL. Otherwise, let me know if you're still have problems with IMEXAM, I'm still running a few tests.
In any case, I've put a patched x_tv.e binary in ftp://iraf.noao.edu/iraf/v215/support/macintel that should fix your IMEXAM problem, there's also an x_images.e binary that will fix many other tasks.
Longer term until a patch is built, I'd suggest you install the V2.15 that includes both the 'macosx' and 'macintel' binaries. if you run into other problems a quick workaround is to then fall-back to using the 32-bit binaries by setting an 'IRAFARCH' environment variable (with a value of 'macosx') before logging into the CL. Otherwise, let me know if you're still have problems with IMEXAM, I'm still running a few tests.
Mike Smutko wrote on Mar 22, 2011
Hi Fitz--swapping out x_tv.e and x_images.e with your newer versions from the ftp site did the trick. I haven't had a chance to test the results in detail, but so far everything seems to be working again.
I also tried setting the IRAFARCH variable to macosx and that worked as well--thanks for the tip about that. It's good to know that it is so easy to switch between the 32 and 64 bit versions in case I run into to any other issues.
Thanks for the fixes!
I also tried setting the IRAFARCH variable to macosx and that worked as well--thanks for the tip about that. It's good to know that it is so easy to switch between the 32 and 64 bit versions in case I run into to any other issues.
Thanks for the fixes!
Last post on Mar 22, 2011