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 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 ?
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?
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.