Uploaded image for project: 'GMAT'
  1. GMAT
  2. GMT-5762

Improper leap second handling in Code500 ephemeris

    Details

      Description

      It looks like there might be a problem with the Code500 writer across leap seconds. A GMAT Code500 ephem I created is failing FDF's “ephemeris verify” utility when crossing a leap second.

      As background - A Code500 ephemeris file is supposed to skip/ignore the leap second record. Across a positive leap second, the following UTC epochs occur:

      23:59:58 *
      23:59:59 *
      23:59:60
      00:00:00 *
      00:00:01 *
      00:00:02 *

      Only the records marked with an asterisk should appear in the ephemeris file. The 23:59:60 record should be silently dropped. Of course, there will be an extra second of actual spacecraft flight between 23:59:59 and 00:00:00 and this would be apparent if you differenced the vectors. It looks like GMAT may be trying to jam the 23:59:60 vector in the ephem. In addition, there are leap second flags in the ephemeris header that should be set.

      I guess it would be good to also make sure it handles a leap second in the other direction which would be:

      23:59:57 *
      23:59:58 *
      00:00:00 *
      00:00:01 *
      00:00:02 *

      No vector at 23:59:59.

        Gliffy Diagrams

          Attachments

            Activity

            Hide
            djcinsb Darrel Conway added a comment -

            This sounds like we are hitting the precision of an IEEE double here. We only have a 52-bit mantissa here, and 2^52 = 4.503599627370496×10¹⁵, so we can't accurately represent a 16 9's number in an IEEE double. (see https://en.wikipedia.org/wiki/Double-precision_floating-point_format)

            Isn't the value stored as a binary? Does the compare tool compare binary data, or does it first convert to a string and then compare?

            Show
            djcinsb Darrel Conway added a comment - This sounds like we are hitting the precision of an IEEE double here. We only have a 52-bit mantissa here, and 2^52 = 4.503599627370496×10¹⁵, so we can't accurately represent a 16 9's number in an IEEE double. (see https://en.wikipedia.org/wiki/Double-precision_floating-point_format ) Isn't the value stored as a binary? Does the compare tool compare binary data, or does it first convert to a string and then compare?
            Hide
            sslojkowski Steven Slojkowski added a comment -

            I'm pretty sure the comparison must be binary. Is Linda's fix from yesterday going in the next build? If so, I'll give it a run and see what I get.

            Show
            sslojkowski Steven Slojkowski added a comment - I'm pretty sure the comparison must be binary. Is Linda's fix from yesterday going in the next build? If so, I'll give it a run and see what I get.
            Hide
            dcooley Steve Cooley added a comment - - edited

            Linda changed to 9.999999999999999e15.

            Show
            dcooley Steve Cooley added a comment - - edited Linda changed to 9.999999999999999e15.
            Hide
            dcooley Steve Cooley added a comment -

            Today's build is finished. Passing to SES for testing.

            Show
            dcooley Steve Cooley added a comment - Today's build is finished. Passing to SES for testing.
            Hide
            sslojkowski Steven Slojkowski added a comment -

            Current build still fails ephemver, but

            • STK ephems have the same problem and we have not encountered any issues using STK Code500 ephems in operations
            • This issue only occurs when the last ephemeris block is exactly full
            • Any application could only trip on the sentinel when trying to read past the end of an ephemeris, which is an error anyway
            • The general consensus is that ephemver is too strict in evaluating the sentinel

            The general recommendation seems to be to accept Linda's current fix of 9.999999999999999e15 and proceed with SOHO IOC testing. Passing back to DSC for approval of this recommendation and closure.

            Show
            sslojkowski Steven Slojkowski added a comment - Current build still fails ephemver, but STK ephems have the same problem and we have not encountered any issues using STK Code500 ephems in operations This issue only occurs when the last ephemeris block is exactly full Any application could only trip on the sentinel when trying to read past the end of an ephemeris, which is an error anyway The general consensus is that ephemver is too strict in evaluating the sentinel The general recommendation seems to be to accept Linda's current fix of 9.999999999999999e15 and proceed with SOHO IOC testing. Passing back to DSC for approval of this recommendation and closure.

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: