DSST mean & osculating elements from same integration

Hi,

I’m new to using the DSST :slight_smile: Is there a way to get a generated ephemeris in mean and osculating elements from the same propagation? I would like to be able to set up some event detectors based on mean elements and some based on osculating states without redoing the integration.

Best Regards,
Evan

Hi @evan.ward

What you want to do is very interesting. However, I don’t think it will be possible in a simple way :slight_smile:

To generate the ephemeris in mean and osculating elements, what you can do is running a DSST propagation in mean elements with a fixed step handler that will perform the mean to osculating transformation at each step while preserving the mean DSST propagation. Therefore, I think you could be able to write two different ephemeris using the same orbit propagation.

For event detection, because the propagation type is configured at DSST propagator initialization, I don’t think it is possible to have both event detectors based on mean elements and osculating elements. What you try is performing the orbit propagation in osculating elements and for the event detectors based on mean elements, converting the input osculating state in the g function, convert it in mean elements, and call a custom gMean function inside the event detector.
It is a “DIY” solution, not really interesting and it will probably increase considerably the calculation time.

Best regards,
Bryan

Hi Bryan,

Thanks for the tips! I’ll try making a wrapping event detector that does a mean to osculating conversion before calling the g function.

Looking at how getGeneratedEphemeris() is implemented there seems to be just the PropagationType enum that is passed internally that determines if the output is mean or osculating. Could we add a getGeneratedEphemeris(PropagationType type) method to change the value that is passed to the constructor of IntegratedEphemeris? Or would that conflict with the math of the DSST in some way? Perhaps this is a better discussion for the developer list at this point…

Best Regards,
Evan

Note that converting between mean and osculating is computationally intensive.
We discussed with Bryan yesterday and thought we should add a feature to DDST so it stores the sum of all short period terms at time t when it generates a SpacecraftState (because it already computes them when propagating in osculating elements). These terms would be stored as additional state parameters.

With such a change, it would be possible in step handlers and events detectors to go back and forth between mean and osculating with a very small overhead.