Re: [Orekit Users] Fwd: Problem with additional equations

[MAISONOBE Luc <luc.maisonobe@c-s.fr>]

MAISONOBE Luc <luc.maisonobe@c-s.fr> a écrit :


> For the sake of separation of concerns, I would prefer to have realy  
> the primary
> equations completely computed by one part of the code, and secondary  
> equations
> by another part and not messing with the primary. So if you remove  
> the secondary
> equations, you only don't get the secondary state they compute, but  
> you do not change
> at all the premary equations. When the secondary equations do change  
> the primary
> derivatives, they are not secondary anymore: they are needed to compute the
> primary state.

Well, I wrote the previous looking almost only at Hipparchus and Apache
Common Math and not at Orekit. And i see that we indeed explicitly
allowed what you intend to do in the Orekit AdditionalEquations interface
which reads:

    /** Compute the derivatives related to the additional state parameters.
     * <p>
     * When this method is called, the spacecraft state contains the main
     * state (orbit, attitude and mass), all the states provided through
     * the {@link org.orekit.propagation.AdditionalStateProvider additional
     * state providers} registered to the propagator, and the additional state
     * integrated using this equation. It does <em>not</em> contains any other
     * states to be integrated alongside during the same propagation.
     * </p>
     * @param s current state information: date, kinematics, attitude, and
     * additional state
     * @param pDot placeholder where the derivatives of the  
additional parameters
     * should be put
     * @return cumulative effect of the equations on the main state  
(may be null if
     * equations do not change main state at all)
     * @exception OrekitException if some specific error occurs
     */
    double[] computeDerivatives(SpacecraftState s,  double[] pDot)
        throws OrekitException;

So the return value was foreseen as a way to change the primary state. I now
consider this a bad design decision, but its a decision we (and probably me)
did some time ago :-(

So we indeed have to fix this. I'll look if this is possible without modifying
Hipparchus and allowing users to return values both as a returned array
and by modifying an argument array.

Could you open a bug report on the Orekit forge?

best regards,
Luc