Re: [Orekit Developers] AbsoluteDate Precision

[Luc Maisonobe <Luc.Maisonobe@c-s.fr>]

Hi Derek,

Le 20/02/2013 19:01, dmsurka@gmail.com a écrit :
> The AbsoluteDate constructor inputs seconds as a double. Is the resulting
> AbsoluteDate stored to full precision in seconds? I'm looking for
> sub-millisecond precision when storing dates and want to ensure that
> information isn't being truncated or lost along the way.

Great care has been taken on AbsoluteDate accuracy. Internally, it is
split as a long integer containing a whole number of seconds since a
reference and a double containing the remaining fractional part. The
double is guaranteed to always be between 0.0 and 1.0, which implies the
least significant bit is always about 10^-16 seconds (2^-53).
This corresponds to the ultimate accuracy you can achieve.

Dates are often built iteratively, using loops like:

  for (AbsoluteDate t = t0; t.compareTo(t1) < 0; t = t.shiftedBy(h)) {
     // do something
  }

In this case, the inital date will have the accuracy at which t0 was
built, and as the loop iterates t will be subject to errors due to the
successive calls to shiftedBy with step h. This is handled extremely
carefully using dedicated algorithms to avoid losing accuracy. We do
*not* do a simple addition but apply the Møller-Knuth TwoSum algorithm
to preserve accuracy as much as possible.

The test cases we have performed have shown that in difficult cases (for
example with step h = 0.1s, since 0.1 cannot be represented exactly as a
double), we will accumulate error, between -0.5ULP and -3ULP at each
iteration, due to h representation error. If however
the step h can be represented as a double (like h = 0.125s), then the
result will be exact, even after 10000 iterations. So we will still have
about femtosecond accuracy.

These results are checked on a regular basis as they belong to the unit
test harness (look at testIterationAccuracy in AbsoluteDateTest.java)

> 
> In your experience, what level of precision do you think is necessary for times
> associated with orbital states, particularly for low-level encounters such as
> the docking maneuvers that you have worked with?

As a basic rule, time accuracy can be deduced from position accuracy
needs. If you compute your close approaches by absolute motion
differences (i.e. not by direct relative motion), then you will consider
the absolute position accuracy and the absolute velocity. Say for
example you want 1m accuracy on low Earth orbit where absolute velocity
is about 7000m/s. Then you will need time accuracy of 1/7000 seconds,
which is 0.14 milliseconds.

Orekit AbsoluteDate are 10 to 12 orders of magnitude more accurate than
this, so they should be sufficient for your needs.

We know about other projects that needed nanosecond precision and which
have validated that Orekit dates where much more accurate than their needs.

Hope this helps,
Luc

> 
> Thanks,
> Derek
>