[daip] CL2HF/SN2HF bug: variable DATUTC

[Craig Walker]

It seems the geodesy folks have found a problem.  It doesn't
sound like the fix will be terribly difficult (changing some
declarations), although I don't know if there might be some
other ramifications.

Craig




----- Begin Included Message -----

>From del at gyro.harvard.edu Fri Sep 28 17:22 MDT 2001
Date: Fri, 28 Sep 2001 19:22:53 -0400 (EDT)
From: del at cfa.harvard.edu
To: dgg at leo.gsfc.nasa.gov
Subject: CL2HF/SN2HF bug: variable DATUTC
Cc: cwalker at zia.aoc.NRAO.EDU
From: "Daniel E. Lebach" <dlebach at cfa.harvard.edu>
Content-Type: text
Status: RO


Hi David (and Craig),

Very recently SN2HF (my version of CL2HF) gave me a strange fatal
error that I hadn't encountered before.  Eventually I traced the
problem back to the definition of the DATUTC variable.  Throughout
the SN2HF code, DATUTC is defined as REAL, while in fact it should be
defined as DOUBLE PRECISION.  I write because the bug is in CL2HF as
well, at least in the version of CL2HF in the 31DEC01 AIPS currently
being distributed.  In fact the bug has exisited in the CL2HF code
since the earliest version of CL2HF that I have on record (from
January 1996, which was before SN2HF, which is a derivative of CL2HF,
was even contemplated).

I think the bug has escaped notice because it is only in recent
data sets that DATUTC, which is loaded from the AN table, has been
nonzero.  (To check this, use PRTAB, not PRTAN, which, at least until
recently, seems to write out the value of UT1UTC where it claims to
be writing out DATUTC.)  The earliest experiment I have with nonzero
DATUTC was for observations on 2000 Aug 7.  The next earliest
experiment I have, which was for observations on on 2000 May 15,
still had a DATUTC value of 0 in the AN table.

The bug can affect the time range over which visibilities are loaded
by SN2HF.  If DATUTC, when wrongly read as REAL, is > ~10^7 (normally
it should be < 1 ), then roundoff errors can occur when computing
the time range.  In my fatal case, the time range had zero width
because of the bug.  This condition may well be the only problem the
bug can cause.  That is, I think the code with the bug will either
give correct results or crash because of a time range of zero width
when loading visibilities.  That would be a good thing (since no
crash = no effect due to bug, meaning you don't have to worry about
anything already processed successfully).

Dan



----- End Included Message -----


----- Begin Included Message -----

>From del at gyro.harvard.edu Fri Sep 28 17:44 MDT 2001
Date: Fri, 28 Sep 2001 19:44:33 -0400 (EDT)
From: del at cfa.harvard.edu
To: dgg at leo.gsfc.nasa.gov
Subject: Follow-up, re: CL2HF/SN2HF bug: variable DATUTC
Cc: cwalker at zia.aoc.NRAO.EDU
From: "Daniel E. Lebach" <dlebach at cfa.harvard.edu>
Content-Type: text
Status: RO


Hi again,

I wrote in my last e-mail that:
> 
> ...  That is, I think the code with the bug will either
> give correct results or crash because of a time range of zero width
> when loading visibilities.
>
Unfortunately, I made that statement in haste (or out of wishful
thinking).  A more careful look at the code reveals (I think) that the
bug could have more insiduous effects.  So beware...

Dan



----- End Included Message -----