iraf.net

I get the following segmentation fault with ccfind when using it on an image with a ZPN projection:Input File: obj.coords Output File: new.coords
Image: wcstest2.fits Wcs:
Insystem: j2000 Coordinates: equatorial FK5
Equinox: J2000.000 Epoch: J2000.00000000 MJD: 51544.50000
Refsystem: wcstest2.fits logical Projection: ZPN Ra/Dec axes: 1/2
Coordinates: equatorial FK5 Equinox: J2000.000
Epoch: J2000.00000000 MJD: 51544.50000
ERROR: segmentation violationThis is IRAF 2.14 (+jan 14 fix), since it has just been installed to work with ZPN projection WCS. It segfaults both on Mac Intel & Scientific Linux.
I haven't been able to trace the error down completely (ie, minimise the header/image to only the important keywords, and fiddle with those). Oddly, on occasions it seems to work when I fiddle with the header keywords, but when I try the same header keyword fiddling on another image, it segfaults again. I guess that's typically bug behaviour.
The data I've been using are UKIRT-WFCAM images; I can make them available if wanted, or an artifical image with the copied header from the WFCAM image (since they the WFCAM images are quite big).Let me know if anyone can confirm this, or knows what the solution is.
Thanks for any help. Evert
evert.rol@star.le.ac.uk

I believe I've find out what I can do with the 'header keyword fiddling': change the ctype1 keyword to 'RA---TAN', *while leaving* the dec keyword at 'DEC--ZPN'. This will *not* crash ccfind.
I'm not sure if that helps identifying the problem, or that it merely indicates that IRAF ignores the Dec projection once it has found an RA projection. Or perhaps it just confuses the problem.Cheers, Evert

It would help if I could use your test data and coords files to reproduce the problem locally. If you don't mind, you can either email me the files (or a URL) or put them in the anonftp at ftp://iraf.noao.edu/pub It's not clear whether this is a problem in the task or the ZPN projection code, but I'll get back to you with a workaround or new binaries.Thanks,
-Mike

Thanks Mike!I've put the data at http://www.star.le.ac.uk/~er45/ccfind/
wcstest2.fits is the image I've been most playing with. It contains two objects, whose wcs coordinates are in 'obj.coords' (I messed up a bit with mkobjects and the objects are not very stellar, but still detectable by ccfind when using a TAN projection).
The w0156.fits file is the WFCAM image that started it all (well, it's one of the 4 chips). I've used the w0156.fits header for wcstest2.fits (in mkobjects) and then removed most non-wcs stuff.For the record, my parameter settings for ccfind are:
[code:1:ea1d210f82]input = obj.coords The list input celestial coordinate files
output = STDOUT The output matched coordinates files
images = wcstest2.fits The input images
(lngcolu= 1) Column containing the ra / longitude
(latcolu= 2) Column containing the dec / latitude
(lngunit= hours) Input ra / longitude units
(latunit= hours) Input dec / latitude units
(insyste= j2000) Input celestial coordinate system
(usewcs = yes) Locate objects using the existing image wcs [/code:1:ea1d210f82]
and the other parameters at their default setting.Hope this is what you need. Evert

Thanks for the data and the report. This wasn't so much a bug as a bad interaction of interfaces. The task opens the image and saves the WCS descriptor for later use. The ZPN driver tries to reference the image in the wcs descritor to get the PV matrix keywords, however the procedure that created that descriptor also closed the image and so the image reference was invalid. This is outlined in more detail in Buglog #560 (see https://iraf.net/article.php/20080123160033255).I've put patched binaries for the two platforms you mention at:https://iraf.net/ftp/pub/x_images.e.RHUX
https://iraf.net/ftp/pub/x_images.e.MACINTELWrite back and I can send you the code change and build instructions if you prefer.Cheers,
-Mike

Thanks Mike, that appears to fix it indeed.
I've assumed I just needed to replace x_images.e with the corresponding patch (and change the permissions to executable where necessary).Two notes:
- I cannot download the Redhat binary: '403 permission denied' (probably a world permission setting gone wrong).
- I noticed the Mac-intel binary is about 1MB larger than the original x_images.e. I assume that's just something to do with the original being stripped/otherwise optimised (unless you managed to add 1 MB of compiled code in just a few hours, which seems quite a large patch).Thanks again for the quick fix. Evert

Oops, the redhat permissions should be fixed. And yes, I think the original macintel binary was stripped.Cheers,
-Mike