I’m opening this thread following the 12.2 release and the merge of develop-13 into develop.
testLeoFieldPropagation test (inside the RadiationPressureModelTest class) is failing because of a relative position difference of about 1.3m after 10 days of propagation. After investigating, i found the following issue :
Inconsistent definition of Umbra/Penumbra detectors with their field equivalent (they seem to be reversed) → However that does not fix the issue
Switching to anything but Complex field class fixes the issue → the main difference occurs during the following operation (only with Complex): FastMath.acos((c - x) / b) inside getLightingRatio implementation of ConicallyShadowedLightFluxModel.
1st iteration :
Standard code : FastMath.acos((c - x) / b) = 0.004213746902486649
Field version : FastMath.acos((c.subtract(x)).divide(b)) = (0.004213746902491138, -0.0)
Error is then building up from there, subtlety impacting the acceleration and thus, the relative position.
Should we open an issue and switch to Binary64 for the time being while this is not fixed ?
I think so.
In fact, I think we should not use Complex at all for such tests. Complex behavior is really different from other fields, and it was added as a field only after lots of discussions and awkward choices. I am personally not a big fan of Complex belonging to this hierarchy.
Thanks for your investigation.
I actually don’t really like testing with Binary64, cause they’re very (too) similar to double. In my opinion it’s better to use classes used in practise in Orekit for automatic differentiation (namely the Derivative interface) but: UnivariateDerivative1 has a very long name and Gradient requires the definition of a dimension which is arbitrary for a unit test. This is why I usually prefer Complex. Let’s remember that complex numbers can be used for finite differences and are better than the classical schemes because they don’t suffer as much from rounding errors.
See this reference for example:
LANTOINE, Gregory, RUSSELL, Ryan P., et DARGENT, Thierry. Using multicomplex variables for automatic computation of high-order derivatives. ACM Transactions on Mathematical Software (TOMS), 2012, vol. 38, no 3, p. 1-21.
That being said, I have also seen in the past non negligible numerical differences between real and complex functions, in particular the trigonometric ones, leading to failed tests and I had to use something else.
So what I would propose is the following: implement in the test folder an inheritor of CalculusFieldElement, that would basically do the same as UnivariateDerivative1 but with minimal code. It’s actually better from a development point of view I think because then the coverage and validation depend on less things from Hipparchus, whilst still doing their job. Thoughts?