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

Re: [Orekit Developers] STM/Jacobians w.r.t. Keplerian Parameters




"Ward, Evan" <Evan.Ward@nrl.navy.mil> a écrit :

Hi Christophe,


On Thu, 2017-08-10 at 17:59 +0200, Christophe LE BRIS wrote:

Hi,

With PartialDerivativeEquations, STM are given wrt cartesian parameters
only.

If you want to have it wrt Keplerian parameters, you need to compute the
Jacobian "dKep/Cart" with the method computeJacobianMeanWrtCartesian in
the class KeplerianOrbit (on the final state) and then use it to change
of basis of your STM (the STM is a linear transformation).


Thanks for the reply. I tried your suggestion and it worked well, once I made the tolerance a little tighter.

What is PDE actually computing then when orbitType is not Cartesian?

I fear it only computes Jacobians of current Cartesian parameters with
respect to initial Cartesian parameters.

I thought the mapper returned by PartialDerivativeEquations.getMapper() took care of converting orbital element representations since it calls Orbit.getJacobianWrtCaresian() both when setting the initial STM and when retrieving the STM. [1-2] Should I add some documentation warning the user to never use the PDE class with non-Cartesian elements?

Yes, you are rigtht, but internally in PartialDerivativesEquations.computeDerivatives
we clearly use Cartesian only. Also since 9.0, we use a new DSConverter class
to compute more accurately some derivatives (and also take care of the
orbit/attitude coupling we wanted to include since issue #200). This new converter
clearly switches to Cartesian only, this is an oversight (and the classe also
still refers to Jacobians being either 6x6 or 7x7 despite I removed this in 9.0).

So I don't know if the limitation has been introduces in 9.0 with the DSConverter, or if it was there earlier due to PartialDerivativesEquations.computeDerivatives.

This limitation should be removed. I would in fact be happy with a solution
that completely rewrites this class from scratch and dumps it in favor
of a cleaner implementation (well, deprecate it first to help users switch).
I don't like this class and its clumsy API.

Evan, could you look at this? I am still on holidays for one week and really need
a break.

best regards,
Luc


[1] https://www.orekit.org/forge/projects/orekit/repository/revisions/master/entry/src/main/java/org/orekit/propagation/numerical/JacobiansMapper.java#L140 [2] https://www.orekit.org/forge/projects/orekit/repository/revisions/master/entry/src/main/java/org/orekit/propagation/numerical/JacobiansMapper.java#L182

Best Regards,
Evan




Christophe


Le 10/08/2017 à 17:24, Ward, Evan a écrit :


Hi,

I'm trying to compute the State Transition Matrix (STM) for Keplerian
orbit w.r.t. Keplerian parameters. I'm not sure if I'm doing it right
so I thought I'd post my question here. So I'm trying to compute
dx(t)/dx(0) where x = {a, e, i,  arg. of perigee, RAAN, M (mean
anomaly)}. According to Montenbruck & Gill (section 7.1.1 of Satellite
Orbits) the result should be the identity matrix except for the
dM(t)/da(0).  term. In Orekit I've set the orbitType to Keplerian and
the positionAngleType to Mean, but the result looks very different
from what I would expect. I've attached my code and included the
output below. The code is in groovy and it should be able to run if
you want to try it. Am I doing something wrong? Is this a bug?

Initial State
Keplerian parameters: {a: 6678137.0; e: 0.1; i: 50.0; pa: 0.0; raan: 0.0; v: 0.0;}
Final state
Keplerian parameters: {a: 6678137.0; e: 0.1; i: 50.0; pa: 0.0; raan: 0.0; v: 359.9999999999999;}
STM
1.084033316 1048746.583 -1.881271601e-07 338443.1765 217547.0804 689070.0095 8.986475977e-08 -0.4460115259 5.972999872e-14 -0.2344750310 -0.1507176447 -0.5273227631 -5.987960454e-21 1.482147738e-14 1.008352980 -2.359223927e-15 0.003748479827 5.162537065e-15 -1.049794901e-06 19.17181914 -0.009257359011 1.103560184 0.05508206389 -1.305994282 3.388131789e-21 9.503509091e-14 0.01440189399 9.742207041e-15 1.017867705 2.688127498e-14 7.973387020e-09 -23.67118846 1.041684976e-12 -0.8494761263 -0.5460327287 0.9198999327
Expected dM(t)/da(t0)
-1.411288501683835E-6


Best Regards,
Evan