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

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





On Fri, 2017-08-11 at 09:50 +0200, MAISONOBE Luc wrote:
"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).

OK, good to know.

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.

I tried with Orekit 8.0 and observed the same behavior, so it doesn't appear to be a regression.

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.

Enjoy your holiday. Either I or Chris will take a look at it. Another workaround I found is to use FieldNumericalPropagator with orbitType set to Keplerian. It is apparently able to compute the Keplerian STM with much less noise than method Christophe suggested.

Best Regards,
Evan

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

Attachment: smime.p7s
Description: S/MIME cryptographic signature