iraf.net

I have just discovered an embarassing bug which will interfere with
using FXCOR on southern hemisphere data such as CTIO. The bug is
in xtools$obsdb.x where the change would be: real ctor() --> int ctor()
double ctod() --> int ctod()I point this out just in case it might be possible to fix this for the
final archive of V2.10. Also should we get something into the newletter?
A bug log will be made.Frank>From valdes Tue Jun 16 16:46:00 1992
Date: Tue, 16 Jun 92 16:45:59 MST
From: valdes (Frank Valdes CCS)
To: sjm@merlin.anu.edu.au
Subject: Re: iraf v2.10 and the obsdb.dat fileHi Stephen,Well, there is a bug in the observatory database code. It is a rather odd
bug which just by chance affects FXCOR for the case of southern hemisphere
entries. The procedure which converts the strings in the database to real
numbers returns an integer giving the number of characters converted.
Unfortunately this routine is declared as real. The error checking is done
by seeing if this returned value is <= 0. There is some funny stuff that
happens which causes the returned value to have the sign of the converted
real value as well as being some arbitrary real number???? Anyway, this
causes the test to fail and gives the error reported. In some of the other
tasks, like SETAIRMASS, which use the database they call a double precision
routine which is also mistyped. By chance it appears that the integer
number of characters when interpreted as a double does not fail the test
(the higher order bytes seem to be set to 60.) so things work. This is an
embarassing bug and I haven't found a workaround. I guess the only
workaround is to turn the world over and change the signs of latitudes and
declinations of the objects. If you don't care about the heliocentric
corrections then I guess the actual observatory is moot.I'm sorry about this and I will make an attempt to get the fix accepted
for the final cut of the network archive (it turns out this has not been
done awaiting addition of system documentation).Yours,
FrankIt just occurs to me and it seems to work that if you add 360 degrees
to the latitude things will be ok. For example a latitude of -35
could also be specified as 325. You can use astutil.rvcorrect to
check things since this routine uses the double precision converter
which works correctly.