Creating a Numerical Propagator using a Propagator Builder

[scrawfordLM]

Hi all,

I noticed that Orekit setups up the Gravitational Parameter differently depending on if the propagator was created via the Numerical Propagator Builder or just created directly. When using Orekit to set up a propagator directly, I usually create the NumericalPropagator object directly. When setting up an estimator to perform orbit determination, I have to create and pass in a NumericalPropagatorBuilder. I’ve noticed that the gravitational parameter for NewtonianAttraction depends on the initial SpacecraftState and Orbit passed into the propagator when not using the builder. However, when I use the builder, the gravitational parameter is overriden to match the one passed in when I create a HolmesFeatherstoneAttractionModel.

I’ve attached the following script as an example:

TestOrekitPropagators.java (5.7 KB)

It should print out the GM from the initial spacecraft state, holmes featherstone model, and newtonian attraction model for each way of setting up the propagator. When I run this on my machine, the logs show…

INFO:
        Propagator Set up Directly:
        SpacecraftState GM: 398600435507022.750000
        Gravity Field GM: 398600441500000.000000
        Newtonian Attraction GM: 398600435507022.750000
INFO:
        Propagator Set up via Builder:
        SpacecraftState GM: 398600435507022.750000
        Gravity Field GM: 398600441500000.000000
        Newtonian Attraction GM: 398600441500000.000000

…as far as I’m aware, I set up the force models exactly the same way both times, the only difference was using a propagator builder. I would’ve expected the Newtonian Attraction GM to be the same as the SpacecraftState GM in both cases.

I have several questions:

1. Is this intended behavior?
2. If #1 is yes, is it recommended to make sure that my gravitational parameters match up amongst my initial Orbit and all of my force models?
3. If #2 is also yes, how can I override the GM in my propagator builder to make sure it matches up with the GM in my potential coefficients file?

[Vincent]

Hello @scrawfordLM and sorry for the delay,

@scrawfordLM

Is this intended behavior?

Honestly i cannot answer for sure but looking at how it is implemented, i would say yes.

@scrawfordLM

If #1 is yes, is it recommended to make sure that my gravitational parameters match up amongst my initial Orbit and all of my force models?

Yes, for consistency.

@scrawfordLM

If #2 is also yes, how can I override the GM in my propagator builder to make sure it matches up with the GM in my potential coefficients file?

I would say it is the other way around, the GM in your potential coefficients file will override the one in your propagator builder. In fact, you should make sure the GM used in your orbit definition is the same as the GM in your potential coefficients file.

Another note on this, you wrote your thread a day after i encountered this behaviour with DSSTThirdBody added to a DSSTPropagatorBuilder so watch out for each force which require the central body GM and not only for HolmesFeatherstoneAttractionModel.

Someone else must be more relevant than me on the subject but i hope this helps.

Cheers,
Vincent

[scrawfordLM]

Thanks for the response; all seems reasonable to me.

Would it be beneficial to have Orekit log some sort of validation warning if it detects Earth GM inconsistencies when propagating? It’s not particularly easy to find this error if you don’t know what you’re looking for.