Thanks.  I'll take a look at this.

Also how far have you been able to test iraf?

:)

it is pretty good Joseph, that's already professionally usable, congrats!

I have been able to remove dark frames, zeroing images and applying flat fielding corrections. The only step missing is having a good WCS header, hence the need of ccmap, to do the final alignement and image stacking. If that work, I think you can sell it to astronomers without doubt (that ccmap may be some upstream bug or some 32bits/64 conversion, I looked a bit but I have no clue).

I have also used ds9 and ximtool for downloading catalogs and images from remote servers, so far so good!

thanks.

I've been able to reproduce and I'll do a deep dive to figure out what is going on.

OK.  It's not a 32/64 bit issue since it happens on 32-bit.  I'll dump out a bunch of things to see where the trouble is.

This is bizzarre

on l186 in gsacptsd.x

                        do i = 0, npts-1 {
                           sum = sum + Memd[bw+i] *
                                XBASIS(bbxptr+i) * YBASIS(bbyptr+i)
                           call printf("")
                        }
                        MATRIX(mindex) = sum

it works if I put in a the call printf, but it stops working if I take it out.

bizarre

You're indeed diving deep :)

Might it be some wild pointer, or simply by adding printf() you are preventing some optimizations to take place that break the code?

It's the optimizer.  What happening is that iraf simulates dynamic memory by creating an array of length one to locate the bottom of the heap, and then performing operations that are out of the array bounds.

Unfortunately, the optimizer sees that the loop is acting on out of bounds memory, and says "if it's out of bounds, the behavior is undefined so I can get rid of the loop altogether."

The solution is to add the option -fno-aggressive-loop-optimizations in the f77.sh wrapper, and to heavily comment why that option is essential.

I'll check in a fix.

well done! that is *good* hunting!!

But if confirmed, the iraf guys need a serious bug report in their face, that is quite an ugly way of progamming and they should fix it upstream. I am amazed that no one complained before :)

My guess is that this may be an issue that is specific to gcc 4.8.

The dynamic memory handling of IRAF is extremely ugly since they go through a lot of nasty tricks to get dynamic memory working with fortran 77.  The trouble is that those tricks are not necessary with fortran 90, but IRAF is stuck with them.

fixed in cauldron

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Hi Joseph,
ok the fits is good for me too now, but there is a problem in updating the header of the image. In the ccmap help, this is the tutorial example 5)

ccmap coords coords.db image=pix results=STDOUT xcol=3 ycol=4  \
    lngcol=1 latcol=2 refpoint=user lngref=13:27:46.9 latref=47:27:16    \
    refsystem=b1950.0 inter- update+

that should update the header of the image to be WCS (refpoint=user lngref=13:27:46.9 latref=47:27:16 refsystem=b1950.0 can be forgotten, the important option is update+).

Now checking the header with

imheader pix l+

should have the following fields:

WCSDIM  =                    2
CTYPE1  = 'RA---TAN'
CTYPE2  = 'DEC--TAN'
CRVAL1  =     202.471969550729
CRVAL2  =     47.1967667056819
CRPIX1  =     250.255619786203
CRPIX2  =     266.308757328719
CD1_1   =  -2.1224568721716E-4
CD1_2   =  -3.8136850875221E-6
CD2_1   =  -3.2384199624421E-6
CD2_2   =  2.12935798198448E-4



On our test case, we get:

WCSDIM  =                    2
CTYPE1  = 'RA---TAN'
CTYPE2  = 'DEC--TAN'
CRVAL1  =  2.100808536427E-312
CRVAL2  =     47.1981766432095
CRPIX2  =     273.980754205693
CDELT1  =                   0.
CDELT2  =  2.12934727219336E-4
CD2_2   =  2.12934727219336E-4

some fields are missing, like CRPIX1, and others are uninitialized, like CRVAL1. It sounds exactly the same kind of bug you fix, but elsewhere in the code. The fit seems good though, so that's coming from some routine making the translation.

I also tried with another task, ccsetwcs using coords.db and it produces also missing and uninitialized fields in the header.

Could you have a look again?

Thanks!
cheers,
chris.

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

OK.  Will look into this.

OK.  I haven't put in a fix but I know what the problem is.

If you have several double assigns in a row, gcc will attempt to optimize it with a streaming double instruction.

The trouble is that for this to work, the doubles have to be aligned on a 16-byte boundary, which is not guaranteed by salloc.

If may take me a bit of time to work out the pointer numerology.

Fix attempted in revision 2.16-8.mga4

For SSE2 to work doubles have to be aligned on 128-bit boundaries so I changed the IRAF memory management so that happens.

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED

Thanks Joseph, tested it on other images as well and works fine, well done!

I can pursue with other tests now, like alignement and stacking.

Cheers,
chris.

FYI, I just uploaded a new iraf in which I set everything to optimization level O2.

Setting things to O3 caused the problems to reappear.