[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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





> Date: Mon, 14 Mar 2011 18:09:30 +0100
> From: Luc.Maisonobe@c-s.fr
> To: orekit-developers@orekit.org
> Subject: [Orekit Developers] changing raw angular parameter in numerical propagation implementation
>
> 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

I agree with your reasoning, many references (Vallado, Battin, Montenbruck) include closed form solutions
for mean angle state transformations and their Jacobians. Making it much easier to precisely switch between orbital state representations.
Although I'm not sure of the integration issues. I also find that some state representations have better numeric stability than others, Cartesian seems the most universal (pardon the pun;-).