iraf-v216 · Code · Issues (50) · Pull requests (81)
iraf.net Issue #73
WCS inconsistent between IRAF builds
closed olebole opened this issue on 2017-05-19 · 1 comments
olebole commented on 2017-05-19
One of the tests in the test procedure is Coordinate systems within IRAF. This however shows some inconsistencies:
When running with the binary (linux64) version, or the version compiled on Ubuntu 12.04 one gets the expected output:
cl> listpix dev$wpix[16:20,5:6] wcs=world format="%H %h"
13:28:05.1 47:24:01.4 41.
13:28:05.1 47:24:01.4 38.
13:28:05.0 47:24:01.4 41.
13:28:04.9 47:24:01.4 42.
13:28:04.8 47:24:01.4 40.
13:28:05.1 47:24:02.1 38.
13:28:05.1 47:24:02.2 38.
13:28:05.0 47:24:02.2 38.
13:28:04.9 47:24:02.2 39.
13:28:04.8 47:24:02.2 38.
These numbers are also obtained with versions compiled on Debian Squeeze and Wheezy (gcc 4.7.2), and they are verified by using wcslib.
When running on a version compiled (exactly the same source, same environment, with exactly the same settings) on Ubuntu 14.04, the output is different:
cl> listpix dev$wpix[16:20,5:6] wcs=world format="%H %h"
Warning: setting CD2_2 to 1.
13:27:50.0 -29:49:49.8 41.
13:27:50.0 -29:49:49.8 38.
13:27:50.0 -29:49:49.8 41.
13:27:50.0 -29:49:49.8 42.
13:27:50.0 -29:49:49.8 40.
13:27:50.0 -29:46:54.7 38.
13:27:50.0 -29:46:54.7 38.
13:27:50.0 -29:46:54.7 38.
13:27:50.0 -29:46:54.7 39.
13:27:50.0 -29:46:54.7 38.
This is clearly wrong, and looks like another problem with newer gcc. The same problem is on Debian Jessie (gcc-4.9.2) and Stretch (both 32 and 64 bit tested).
olebole commented on 2017-05-24
For reference: the problem appears in sys/mwcs/iwewcs.x. The max() calculation is done only once for the first array member (which is zero in the second row of a diagonal matrix):
do j = 1, ndim
maxval = max (maxval, abs(IW_CD(iw,i,j)))
This happens for gcc version 4.8 and later; clang (MacOS) seems not to be affected. Cause is that IW_CD will be translated into the Mem common block, and this was wrongly declared to have only one member, which allows such an optimization (fixed now in e5f8b2cf).
Fixed in #60
Last updated on 2017-05-24