State transition matrix parametrization

Hello,

I am propagating the covariance matrix making use of the state transition matrix derived from the MatricesHarvester.
I just would like to make sure that the following is true:

  • If KeplerianPropagator / EcksteinHechlerPropagator → the state transition matrix is in cartesian parametrization;
  • if NumericalPropagator → the state transition matrix parametrization is function of the setOrbitType and setPositionAngleType methods;
  • if DSSTPropagator → the state transition matrix is in equinoctial / mean anomaly parametrization.

Since I need to implement a general purpose code where the input covariance may be expressed in any parametrization, do I need therefore to transform the input covariance in the correct parametrization (depending on the propagator, through the getJacobianWrt___ methods), propagate it, and then transform it back? Is there any other simpler way to do this?

Thank you!

Hi @MarcoTosato

We recently implemented a class for that. It is currently available in the development version of Orekit and will be officially released in the 11.3 version.
This class is StateCovarianceMatrixProvider.java. It can be used with different orbit propagators (DSST, numerical, Eckstein-Hechler, Brouwer-Lyddane, SGP4, and Keplerian) and it can provide the covariance in different frames and orbit types.

You can find examples in the test class of this function: StateCovarianceMatrixProviderTest.java

Best regards,
Bryan

Hi @bcazabonne and thank you!

I’ll make use of that class then, as soon as it is available. Just for my understanding, is anyway true what I said?

Thank you.

True

By default it is equinoctial / true anomaly but yes you can update it using setOrbitType(OrbitType) and setPositionAngleType(PositionAngle) methods.

True

When computing the propagated covariance, the initial one must be indeed in the same orbit type than the state transition matrix. For the orbit type transformation, you can look the implementations of the changeCovarianceType method in StateCovarianceMatrixProvider.
So, if your state transition matrix is computed in cartesian elements but your input covariance uses keplerian elements, you need:

  1. Transform the input covariance Cov_t0 in cartesian
  2. Compute the propagated covariance using Cov_tk = STM * Cov_t0 * STM^T
  3. Transform the propagated covariance Cov_tk in keplerian

Bryan

Thank you!

Hi,
I just have a last question…
I am trying to propagate using a DSST propagator. As soon as I invoke the method

MatricesHarvester matricesHarvester = dsstPropagator.setupMatricesComputation("stm", null, null);

the propagation does not work anymore.
Am I not supposed to extract the MatricesHarvester (needed for stm retrieval) in this way when propagating with a DSST propagator?

Thank you

Hi,

Could you try this:

    final DSSTHarvester harvester = (DSSTHarvester) propagator.setupMatricesComputation(stmName, null, null);
    harvester.initializeFieldShortPeriodTerms(initialState);

Best regards,
Bryan

Thank you @bcazabonne,

this actually works, but it really takes too long if setting some dsst force models besides the newtonian attraction. Isn’t there any other alternative to this initializeFieldShortPeriodTerms?

Thank you!

What is your integration step?

Unfortunately no… I’m thinking about a solution.

Bryan

I am using a classical Runge Kutta with step 0.5 and I am propagating the orbit for more or less one hour.
If there is no alternative, I’ll just use a numerical propagator then. Thank you!

Marco

Ok, using DSST you can increase the integration step because in DSST theory, the integrated elements are the mean orbital elements. Typically, the integration step can be equal to several orbital periods.

Bryan

Hi,

I am confused by your answer here @bcazabonne. In my understanding, the variables propagated by an instance of KeplerianPropagator are the ones of the underlying initial state (via its Orbit and the corresponding shiftedBy method). So I assumed that the STM would be using the same coordinates. But you’re saying that it is always Cartesian?

Cheers,
Romain.

Hi Romain,

For analytical orbit propagators the type of the STM is defined in the AbstractAnalyticalMatricesHarvester class. If you look at the implementation of the setReferenceState method you will see that we use the cartesian derivatives.

We decided to use cartesian parameters for two reasons : (1) consistency between propagators (Keplerian propagator uses keplerian elements, Eckstein-Hechler uses the cartesian ones and Brouwer-Lyddane uses keplerian) and (2) to avoid possible singularities.

Now, based on your comment, what could be interesting is to add a method getOrbitType() and getPositionAngle() in the MatricesHarvester interface to help users knowing the type used.

Best regards,
Bryan

Hi Bryan,

thank you for the clarification. I would indeed appreciate some getters as I find this behaviour a bit counter-intuitive.
However, you confused me even more by stating that a Keplerian propagator uses Keplerian elements!!!
Again, I thought it used the shiftedBy method of the underlying Orbit, so if it is a CartesianOrbit, it uses shiftPVElliptic for non-hyperbolic cases.

Best,
Romain.

The main problem is that we don’t have getOrbitType() and/or getPositionAngle() methods for analytical orbit propagators. So we had to make a choice and we opted for the Cartesian for the two previous reasons.

I’ll create an issue for adding the getter. It will only be applicable for the next major version because MatricesHarvester is an interface and having default implementations is not a good idea for these methods.

Right! I thought the return type of the propgateOrbit() method was a KeplerianOrbit. But it is indeed an Orbit, so there is no imposed type as for the Eckstein-Hechler or Brouwer-Lyddane propagators which return a CartesianOrbit or a KeplerianOrbit respectively.
My apologies.

Best regards,
Bryan

No worries. And to be clear, I appreciate that the architecture of Orekit is not a trivial problem and that you guys are tackling it as best as you can. This is a great library! Thanks for the amazing work.

Romain.