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

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

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,