Le 05/04/2016 23:22, Hank Grabowski a écrit :
> 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.
No, pure backward propagation does not turns events detectors off.
Events can be detected backaward in time and it is preperly handled.
Even maneuvers can be performeds this way (I just fixed a bug about
this recently).
What should be turned off (events and step handlers) is only when you
call the propagate methods with two arguments (date1 and and date2),
as this means that you really want your propagation for this time
span. IF the propagator is currently not at date1, it first needs
to move to date1 without triggering anything, and then it starts
the "real" propagation.
Isn't it what you observe?
> 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?
As detectors do work backward, I don't really understand.
>
> 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.
We can always do a patch release. We will just have to trigger a vote
as usual on the PMC.
bst regards,
Luc
>
> Thanks!
>
> Hane
>
> On Fri, Apr 1, 2016 at 12:20 PM, Hank Grabowski <hank@applieddefense.com
> <mailto: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.
>
>