Weird residuals in DAOPHOT PSF
jthorstensen wrote on Dec 05, 2008
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
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
Mike Fitzpatrick wrote on Dec 05, 2008
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 http://iraf.net/ftp/pub/fitz/x_daophot.e.LNUX.STATIC and let me know if it works).
Hope this helps.
Cheers,
-Mike
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 http://iraf.net/ftp/pub/fitz/x_daophot.e.LNUX.STATIC and let me know if it works).
Hope this helps.
Cheers,
-Mike
jthorstensen wrote on Dec 05, 2008
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
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
Mike Fitzpatrick wrote on Dec 05, 2008
Hi John,
I think I've been able to reproduce the problem, e.g. does the following plot look familiar?
[img:5bc8535fd5]http://iraf.net/ftp/pub/thorpsf.png[/img:5bc8535fd5]
The problem is, this plot was generated on a 32bit Mac OSX system and looks the same as the plot on the 64bit machine.
What I did was take your (well-prepared!) directory of files, display the image and start PSF by accepting all the parameter prompts. I typed 'a' on a few stars, 'f' to fit it, and then 'r' to review to get the plot.
I haven't looked at this closely enough to say whether there may be some parameter changes that could be made or what's causing the two bands, but I wanted to verify we were both looking at the same thing.
Cheers,
-Mike
[/img]
I think I've been able to reproduce the problem, e.g. does the following plot look familiar?
[img:5bc8535fd5]http://iraf.net/ftp/pub/thorpsf.png[/img:5bc8535fd5]
The problem is, this plot was generated on a 32bit Mac OSX system and looks the same as the plot on the 64bit machine.
What I did was take your (well-prepared!) directory of files, display the image and start PSF by accepting all the parameter prompts. I typed 'a' on a few stars, 'f' to fit it, and then 'r' to review to get the plot.
I haven't looked at this closely enough to say whether there may be some parameter changes that could be made or what's causing the two bands, but I wanted to verify we were both looking at the same thing.
Cheers,
-Mike
[/img]
jthorstensen wrote on Dec 05, 2008
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
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
Last post on Dec 05, 2008