I have been working lately with IRAF/daophot with the PyRAF environment in a 32bit machine and everything is smooth except for the fact that it takes many hours to finish the run in each field I examine. As I would like to finish this analysis as soon as possible I opted to use a 64bit machine (with a larger number of more powerful processors). But still, the daophot task was failing, in particular during the psf task of daophot (when it needs to plot the stars from which you select the stars to create the psf model). The error message was the following:
ERROR (851, “Cannot restore graphics world coordinate systems”)
The same error was raised in both 64bit machines I used (a. PyRAF 2.1.3 and IRAF 2.16.1 in Debian 8, b. PyRAF 2.1.7 and IRAF 2.16.1 in CentOS 7.2), and actually regardless if I used the pyraf or the native cl environment. So the most probable cause should be somehow connected with the 64bit architecture (even though one possibility could be a typo in the iraf/unix/hlib/extpkg.cl file [1], but this is not the case for these PyRAF versions).
After asking this very question in iraf.net forum [2] I got an answer from fitz that
The problem happens because in the 64-bit v2.15 port the size of the WCS graphics structure was changed, and a corresponding change was required in pyraf (which is responsible for the graphics the same way the CL is). This bug was fixed in pyraf but apparently only for the 32-bit version
The proposed workaround is to download the 32bit version of daophot (at [3]) and put it under iraf$noao/bin.linux64 directory. If this is under /iraf (under root) then you need root permissions to copy there and make it executable, preferably as chmod +x x_daophot.e, to make it available for all users in the same machine.
So, we have to keep in mind that the 32bit versions could be the replacement for other non-working tasks as well. Let’s hope that there will be finally future releases of PyRAF [4].
[1] STScI / PyRAF FAQ #1.5
[2] iraf.net/forum: “PyRAF and DAOPHOT – ERROR 851”
[3] ftp://iraf.noao.edu/iraf/v216/support/linux/x_daophot.e
[4] 0. Support Status : “Due to reduced budgets for HST, we can only provide minimal pyraf support. If you have a problem that cannot be solved quickly by our first tier support, we may be unable to help. This is unfortunate, but it is the best we can do with the resources available. “,
STScI / PyRAF FAQ #0, accessed 15 March 2016
Hi, I am the Debian/Ubuntu maintainer of IRAF, and I am going through the problems IRAF currently has so see how I can help fixing them…
I am a bit confused: You say this happens regardless whether you use pyraf or ecl, but the bug shall be in pyraf anyway?
Could you make a minimal self-consistent example that shows the problem?
Thanks, Ole
Hi Ole.
I do not think that the problem lies specifically on pyraf. Since the official answer (and solution) is that the task x_daophot.e should be copied under the directory of 64 bit libraries (within the installation of iraf itself) I presume it does not matter whether you use pyraf or ecl. It could make sense perhaps to make a link for this task, so as the one under the 64 bit library looks directly the 32 bit version.
I think it is easy to replicate it:
— load the daophot packages (noao>digiphot>daophot)
— open (epar) the daofind task, and use any (reasonable) kind of image (e.g. a field of stars) – keep the default parameters since you do not care about the results (I hope it will not crash for any other reason)
— use then phot to make the initial photometry from the output list created by daofind
— pstselect will select the best candidate stars for photometry
— and psf task should create the model psf to use later on – there it should crash
If this approach doesn’t work you can find a small example with a part of an image and a script that you can run easily. I hope it helps!
Grigoris
link to example files: http://maravelias.info/wp-content/uploads/daophot-example_files.tar.gz