[Orekit Developers] changing raw angular parameter in numerical propagation implementation

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

Hi,

As some of you may have noticed, some of the ongoing improvements in
Orekit concern numerical propagation. One of the changes is the ability
to use either equinoctial parameters or Cartesian parameters (up to 5.0,
numerical propagation was only in equinoctial parameters). This ability
will soon be extended to Keplerian parameters and circular parameters,
hence allowing numerical propagation with all supported types.

Another change is the new feature allowing propagation of the state
Jacobians matrices alongside with the state itself (see Véronique latest
blog entry about the paper she presented on this feature at ISSFD).

For now, these two changes are disconnected and propagating Jacobians
can be done only in Cartesian parameters. In order to allow both
features to be used together, we need to add some intermediate orbit
Jacobians between equinoctial/Keplerian/circular parameters and
Cartesian parameters. Another future use of these Jacobians will be
orbit determination.

Orbits Jacobians are often computed using the mean version of spacecraft
position angle (i.e. mean anomaly for Keplerian parameters, mean
latitude argument for circular parameters, mean longitude argument for
equinoctial parameters). However the current numerical propagation uses
the true longitude argument rather than the mean longitude argument in
the state.

This observation leads to the central point of this message: either we
decide to compute Jacobians with respect to the true angle or we change
the state vector mapping in the numerical propagation. So I would like
to present you my current ideas and let you comment on it.

Computing the Jacobians with respect to the true angle implies adding a
few non-standard equations. They are simple to establish for Keplerian
parameters, but more difficult to get for the other types. Also once
they have been implemented, they can be validated only by finite
differences as the reference libraries we can compare against do not use
these true angles but rather stick to the classical mean angles.

Changing the state vector mapping in the numerical propagation to switch
to mean angles is quite easy with the current development version. This
is due to the fact the mapping is delegated to dedicated classes and is
not as tightly bound to the numerical propagator as it was before. The
classes that would need changes are the implementations of the
StateMapper and TimeDerivativesEquations interfaces (see
<https://www.orekit.org/forge/projects/orekit/repository/revisions/master/entry/src/main/java/org/orekit/propagation/numerical/StateMapperEquinoctial.java>
and
<https://www.orekit.org/forge/projects/orekit/repository/revisions/master/entry/src/main/java/org/orekit/propagation/numerical/TimeDerivativesEquationsEquinoctial.java>).
Only the implementation of these classes should be updated, there would
be no API change.

We expect very small numerical differences in reference test results due
to this change, at the level of the last few digits. Propagating in mean
angle also implies that pure Kepler motion (i.e. with only the central
attraction) would become exact as the mean angles evolve linearly and
linear functions are integrated exactly by numerical integrators. With
the current implementation using true angles, we have a polynomial
approximation of v(t) which can never be exact since v is transcendental.

So I lean towards changing the mapping, providing the Jacobians using
mean angles and perhaps providing additional conversion methods for the
Jacobians if someone really needs a Jacobian in true angle (but these
conversion methods would not be used by Orekit numerical propagator).

I'm not sure this message is clear enough, so don't hesitate to ask for
explanations. This list is here to discuss about the changes in Orekit.
If nobody complains, We will most probably implement the change.

What do you think ?
Luc