Long Execution Time From propagateOrbit

Hello, I was wondering how to use the propagateOrbit function correctly.

I changed the model to two-body-keplerian expecting the propagation to be very fast.

Using:

[positions,velocities] = propagateOrbit(time,rEpoch,vEpoch,PropModel="two-body-keplerian")

After using "run and time", an overwhelming amount of the time is spent in:

NumericalPropagatorOptions.localSetSpaceWeatherDataFile

About a factor or 100 over the keplerian propagation call.

But my understanding from the documentation is that two-body-keplerian should not access NumericalPropagatorOptions (nor is this option passed).

How can I skip this "localSetSpaceWeatherDataFile" call?

Thanks

Answer 1

[Rahul]

Hi Kevin,

I understand that you are trying to propagate the orbit using a 'two-body-keplerian' model for faster simulation, but you are noticing significant time being spent in the 'NumericalPropagatorOptions.localSetSpaceWeatherDataFile' call.

When executing the 'propagateOrbit' function with the 'PropModel' argument set to 'two-body-keplerian', as shown below:

[positions, velocities] = propagateOrbit(time, rEpoch, vEpoch, PropModel="two-body-keplerian");

the specified input configuration operates as an analytical propagator. It is based solely on the two-body problem, assuming a point-mass gravity field for the central body with no perturbations. In this configuration, 'NumericalPropagatorOptions' is not utilized, as it is only relevant when the propagation model is explicitly set to 'numerical'.

The call to 'localSetSpaceWeatherDataFile' that is observed in this case, is being triggered during the object construction of 'NumericalPropagatorOptions':

numPropOptions = Aero.spacecraft.NumericalPropagatorOptions;

This initialization takes place internally, even though it is not relevant to the Keplerian propagation itself. While 'localSetSpaceWeatherDataFile' is called, the resulting object is not actually used during the 'two-body-keplerian' propagation. Thus, the space weather data file setup is executed, but it does not affect the actual propagation process.

If this initialization is introducing performance bottlenecks, it is due to the creation of the 'NumericalPropagatorOptions' object and not the propagation itself. Furthermore, even if you were to use the numerical propagator 'PropModel="numerical"', disabling the space weather data file using the command shown below, it would still not have any effect unless 'IncludeAtmosDrag' parameter is explicitly set to 'true':

numPropOptions.UseSpaceWeatherDataFile = false;

If your use case allows for a numerical propagation model while still maintaining the simplicity of a point-mass gravity model, it is possible to configure the propagator explicitly as follows:

numPropOptions = Aero.spacecraft.NumericalPropagatorOptions(GravitationalPotentialModel="point-mass");
[positions, velocities] = propagateOrbit(time, rEpoch, vEpoch, PropModel="numerical", NumericalPropagatorOptions=numPropOptions);

This setup allows you to use a numerical model restricted to a point-mass gravity assumption, offering finer control over initialization and potentially avoiding the observed bottleneck.

Hope this helps!