iraf.net

My longslit spectra tilt by ~10 pixels from blue to red. When I use fitcoords (as I have for a long time) after identify and reidentify work normally, the results are unrealistic. For example, the fitcoords xy pixel map is bizarre: there are 341 rows in the data, but the xy map shows the lines of the individual stars' spectra going from 0 at the blue end to -1500 on the red end. I have tried individual fits, combined fits, smaller wavelength range fits, but the result is always the same. The top and bottom pixel values differ by 300 pixels on both the left and right sides. I can't find any parameters that look odd - I must have missed something, but I don't know what. Thanks!

Hi Karen,See Buglog #555 (near the bottom of the iraf.net homepage) and let me know if you think you're seeing something else. The fix for that bug isn't yet in one of the released versions, but I can get you a binary if needed.Cheers,
-Mike

Hi Mike-Yes, this sounds like what I'm seeing. And since I don't really understand the described workaround, can I ask you to please sned me the binary you mention? My immediate need is for an Intel version, but it would be great to have the PowerPC version too for our other department machines.Thanks!
Karen

Hi Karen,Patched FITCOORDS binaries for various platforms inhttps://iraf.net/ftp/pub/x_longslit.e.MACINTEL
https://iraf.net/ftp/pub/x_longslit.e.MACOSX
https://iraf.net/ftp/pub/x_longslit.e.RHUXDownload in binary mode, rename x_longslit.e and make sure it's executable (i.e. "chmod 755 x_longslit.e") and install in noao$bin.<arch> Let me know if you still have problems.Cheers,
-Mike

Thanks - we'll try this tomorrow!

Hi Mike,The problem doesn't seem to have been fixed. It's not only the negative pixel numbers that puzzle me, it's that there are only 341 rows in the data, not >1500, as plotted. The x pixels go to >2000 as they're supposed to. This is APO DIS data in the blue channel, if that helps. The wavelength calibration and flux calibration work fine, and the 2D spectra display fine, so there doesn't seem to be a problem with any flipping of +/- pixel direction. I'd be happy to send you any files you think might be helpful in diagnosing this.Thanks,
Karen

Karen,Yes, please send me/post a sample image and a 'dpar' listing of the task parameters along with anything else needed to demonstrate the problem. I may have to punt to Frank if it isn't obvious.Cheers,
-Mike

Mike-Did you get the files I sent yesterday? If not, please let me know the correct e-mail to send them-Thanks!
Karen

Hi Karen,Yes, I got the files but haven't had a chance to look at the problem yet. I also passed them on to Frank.-Mike

Hi again, Mike,Just for your info, I tried doing fitcoords on some old KPNO 2.1m Goldcam data that I did fitcoords on successfully before, but now I see the same problem: there are ~400 rows in the spectrum, but the xy plot shows rows going from zero to ~-2000.Thanks,
Karen

Hi Karen,I've just had a chance to look at the data you sent Mike. If I understand your report, I used the idbd284211.0009b database file, set the parameters you sent in fitcoords_pars.bin, run fitcoords, set the display to be x vs y. I did this on our development system which has the fix that Mike pointed you to and did not see the problem you report about the range of data.From reviewing the exchanges I also believe this is the behavior is exactly what was fixed from the earlier bug report. So it seems to me that we first need to make sure that you indeed got a fixed binary and that you installed it correctly and it is being run.Please forward the results of the following commands:

Hi Frank,Here's what you asked for. I'm at home now, so it's from my laptop, which is also macintel, and has shown the identical problem with spatial fitcoords as my office desktop. I installed the new x_longslit.e on both computers on Nov. 26. I note that for the comparison spectra, fitcoords worked fine to get the 2D transform solution.Thanks,
Karenecl> path noao$bin.macintel
QP6100H9U2R.loca!/scisoft//all/packages/iraf/iraf/noao/bin.macintelecl> dir noao$bin.macintel l+
-t-rwr-r- kkwitter 0 Jan 31 1:29 noao$bin.macintel/NB.MACX.X86
-b-rwr-r- kkwitter 6901531 Apr 19 15:42 noao$bin.macintel/OBJS.arc.Z
-b-rwr-r- kkwitter 38276 Feb 13 1:03 noao$bin.macintel/libasttools.a
-b-rwr-r- kkwitter 218476 Apr 12 13:41 noao$bin.macintel/libsmw.a
xb-rwr-r- kkwitter 1809844 Apr 19 14:56 noao$bin.macintel/x_apextract.e
xb-rwr-r- kkwitter 2196956 Apr 19 14:55 noao$bin.macintel/x_apphot.e
xb-rwr-r- kkwitter 1738312 Apr 19 14:55 noao$bin.macintel/x_artdata.e
xb-rwr-r- kkwitter 1712540 Apr 19 14:55 noao$bin.macintel/x_astcat.e
xb-rwr-r- kkwitter 1732628 Apr 19 14:55 noao$bin.macintel/x_astutil.e
xb-rwr-r- kkwitter 1465336 Apr 19 14:56 noao$bin.macintel/x_bias.e
xb-rwr-r- kkwitter 1957544 Apr 19 14:56 noao$bin.macintel/x_ccdred.e
xb-rwr-r- kkwitter 1528992 Apr 19 14:56 noao$bin.macintel/x_crutil.e
xb-rwr-r- kkwitter 3379028 Apr 19 14:55 noao$bin.macintel/x_daophot.e
xb-rwr-r- kkwitter 1545092 Apr 19 14:56 noao$bin.macintel/x_dtoi.e
xb-rwr-r- kkwitter 1463708 Apr 19 14:56 noao$bin.macintel/x_generic.e
xb-rwr-r- kkwitter 1173740 Apr 19 14:56 noao$bin.macintel/x_irred.e
xb-rwr-r- kkwitter 1721716 Nov 26 22:47 noao$bin.macintel/x_longslit.e
xb-rwr-r- kkwitter 1338108 Apr 19 14:56 noao$bin.macintel/x_mtlocal.e
xb-rwr-r- kkwitter 1115976 Apr 19 14:56 noao$bin.macintel/x_nobsolete.e
xb-rwr-r- kkwitter 1765712 Apr 19 14:56 noao$bin.macintel/x_nproto.e
xb-rwr-r- kkwitter 1888968 Apr 19 14:56 noao$bin.macintel/x_obsutil.e
xb-rwr-r- kkwitter 3283812 Apr 19 14:56 noao$bin.macintel/x_onedspec.e
xb-rwr-r- kkwitter 1075004 Apr 19 14:55 noao$bin.macintel/x_photcal.e
xb-rwr-r- kkwitter 2944704 Apr 19 14:55 noao$bin.macintel/x_ptools.e
xb-rwr-r- kkwitter 1285260 Apr 19 14:56 noao$bin.macintel/x_quad.e
xb-rwr-r- kkwitter 1591820 Apr 19 14:56 noao$bin.macintel/x_quadred.e
xb-rwr-r- kkwitter 2335924 Apr 19 14:56 noao$bin.macintel/x_rv.e
xb-rwr-r- kkwitter 1413132 Apr 19 14:56 noao$bin.macintel/x_scombine.e
xb-rwr-r- kkwitter 1440060 Apr 19 14:56 noao$bin.macintel/x_vtel.e

Hi Karen,I double-checked that the code change for the bug is indeed in the system I used t build the binary, and when I look at the library file the .o file is indeed newer than the source. However, if I rebuild that same .o file, or even the whole executable from scratch, I get files that are a different size. This may mean that something went wrong in the update and the old .o file is still being used.Just to sure I rebuilt the entire binary from scratch and updated the https://iraf.net/ftp/pub/x_longslit.e.MACINTEL binary. Please download this newer version and see whether the bug has disappeared. If that fixes the problem, I'll similarly update the other platform binaries but there's no particular reason to believe they are similarly afflicted. In fact, if you installed the PPC binary and that one does work, that would be good to know.Thanks,
-Mike

Hooray! It works! Thanks so much, Mike and Frank.
I haven't installed the PPC binary recently, so I don't know if the problem is there, too. I will be alert to it next time I use the department machines.Thanks again-
Karen