[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orekit Developers] Backwards Propagation redundant calculations



Hi Hank,

I like the idea. (I've thought of that a little bit in the past.) I have a couple thoughts on it.

Making a non-contiguous propagation behave like a contiguous propagation is tricky because force models and event detectors are allowed to be stateful (e.g. ConstantThrustManeuver).

Another way might be to concatenate BoundedPropagators and then make a helper method somewhere (possibly in Propagator) to propagate backwards, propagate forwards and then combine the results. I think there is already a way to concatenate the integrator steps used in the integrator ephemeris output.

Best Regards,
Evan

On 04/01/2016 12:20 PM, Hank Grabowski wrote:
Looking at the AbstractIntegratedPropagator, if I have my initial state in the middle of the propagation interval (from start to finish) then it backwards propagates to the start time (without triggers) before forward propagating to and through the initial state and all the way to the end.  If I'm running this just for ephemeris generation this is not only doubling the work for the first half of the interval but it is potentially inducing additional error into the second half of the propagation than if I had just propagated the two intervals separately.  Do we want a mechanism for toggling a behavior where it just strictly back propagates (and stores) to the start time and then forward propagates (and stores) from the middle point to the end time?  Right now i'm probably going to end up breaking the propagation into two pieces to get around the currently coded behavior.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature