Numerical issue in CartesianOrbit shifteby

Orekit development
1

Bonjour,
According to version log, 11.3.2 brought a numerical correction to method CartesianOrbit.shiftedBy.

However, when computing the following:
pv2 = new CartesianOrbit(pv1, frame, date, mu).getPVCoordinates(date, frame),
A discrepancy between pv2 and pv1 is found (order of 1e-10 in position), because the elliptical shiftedby does not test if duration is 0, and thus introduces a discrepancy through keplerian transformations.

  • is this problem related to the above mentioned correction in 11.3.2 ?
  • Is the omission of the duration==0 test voluntary ?
  • when duration is very small, I suppose the error still stands ?

Thank you !

2
  • I think the problem existed before, but did not test, just looked at the file history.
  • The omission of a test for 0 duration is not voluntary, but I think it is acceptable for the reason in next point.
  • the error will stand with small duration, but in fact duration = 0 will be continuous with duration = epsilon, whereas testing specifically for 0 will indeed introduce a discontinuity.

The error is small and corresponds to numerical noise 10^-10 for positions in the range of 10^6 m, it is the last bit of IEEE754 double precision.

3

Thank you Luc for your reply. I totally agree to the importance of having a continuous result.
In this case, and probably in many others, it goes against a general concern I usually find important in coding: an operation with 0 modification should lead to an output equal to the input. Has there been a general discussion among Orekit developers about such a choice ?

4

I don’t remember any discussion about this.
Put in other words and completely removing the Δt parameter (even not setting it to 0), I guess what you observe is linked to the numerical noise when converting from Cartesian to Keplerian and then back to Cartesian. Could you check the level of discrepancy you get in this case?

5

Thanks again for your reply.
You were right in your whole previous post: 1e-10 of discrepancy in cartesian position, which is normal, and it obviously comes from the transformation Cartesian->Keplerian->Cartesian.