iraf.net

Hello Everyone,We have a strange problem with the PSF fitting in DAOPHOT. Has anyone else run into this?We are selecting stars manually and looking at their radial profiles -- they're fine. But when we hit f to fit the residuals, the RMS is much higher than it should be -- like 0.3 instead of 0.03. The residuals are grossly systematic, with two bad columns, one on each side of the star -- these stick out by several hundred counts in the negative direction. When we run allstar and look at the .sub.1.fits image, each star looks like it has a little slit around it -- a bright bar on either side.Now, here's the really weird part. This only shows up on a relatively new machine with a 64-bit processor. If we run the same data on a 32-bit machine, it doesn't happen -- we've meticulously checked all the DAOPHOT parameters (datapars, photpars, centerpars, daopars, parameters of psf, and so on) and they are the same on both machines. The daophot on the problematic machine is being served centrally -- do we need to get special binaries for the 64-bit machine, or something? IRAF and all other tasks do run fine on the 64-bit machine. All ya'll know, I'm not a newbie -- I've been using the IRAF DAOPHOT for more than a decade, never seen this problem before.Cheers -- John Thorstensen and Julie Skinner

Welcome John, I trust your experience and my first guess without seeing the data myself is that this is some sort of precision problem being triggered by the 64-bit CPU. In the past we've seen slight differences in results when comparing e.g. space and x86 CPU and I wouldn't be at all surprised if some bit of fitting or interpolation code was now more sensitive to a special condition. If you could send me a URL/post the data and your parameters I'll try to reproduce it and have a closer look at the code. For the moment, there aren't 64-bit binaries to be had although we're discussing a 64-bit port within the next year. Assuming I could reproduce the problem, some of the first tests I'd try are changing things like the fit radius or noise model to see if it changes the behavior. Another thing we might try is a statically linked 32-bit binary to avoid using the dynamic libc/libm. You don't say whether this is a linux machine, but if so I could provide this binary pretty easily if you'd like to give it a try (in fact, try https://iraf.net/ftp/pub/fitz/x_daophot.e.LNUX.STATIC and let me know if it works). Hope this helps.Cheers,
-Mike

Mike,Thanks for posting the statically-linked code, but when I use it the PSF task fails with a segmentation fault. I tried it on the data we were using and also on another image from the same instrument. I'll see if I can bundle up some data and parameter files to send you to see if you can reproduce the problem. Thanks, John

Hi John,I [b:5bc8535fd5]think[/b:5bc8535fd5] I've been able to reproduce the problem, e.g. does the following plot look familiar?

Mike, Yes -- that looks exactly what we were seeing! The urgency has gone out of this since we're proceeding on another machine (older 32-bit Athlon processor, red hat enterprise 3) where the problem isn't happening. But it would still be enlightening to know why this happens!Thanks,
John