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

Re: [Orekit Developers] Backwards Propagation redundant calculations



I like that idea of faking out with the bounded propagators.  Because the backwards propagation always turns off event detectors I'm guessing there is a really good reason why and that it would be difficult to do with stuff like maneuvers or a state change that requires that.  Maybe something like this should go into a utility library so that it is very explicit that it is just for pure state propagation and that users don't trip over themselves using it. If eventually we got detectors working forwards and backwards then that utility could call into it directly and maybe eventually be deprecated and removed.  However that's a lot more work than I was originally envisioning, so utility library sounds good.  Is there a package namespace that's preferred for that?

On a related note, this system is baseline on Orekit 6.1 and they can't migrate to Orekit 7.  Is there a process for making an unofficial patch release (let's say 6.1.1 or 6.1_patch1) and committing that back to the main repository or will I need to do the 6.1 stuff in a local copy and only push changes to the master branch?  Sorry if this is covered in the rules and I'm forgetting the details.

Thanks!

Hane

On Fri, Apr 1, 2016 at 12:20 PM, Hank Grabowski <hank@applieddefense.com> 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.