[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