[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Orekit Developers] Fix for end point exceptions on Ephemeris propagator
- To: orekit-developers@orekit.org
- Subject: Re: [Orekit Developers] Fix for end point exceptions on Ephemeris propagator
- From: Luc Maisonobe <Luc.Maisonobe@c-s.fr>
- Date: Tue, 17 Jan 2017 09:34:43 +0100
- In-reply-to: <CAP2my4b=tJOcxZtW7xNvGjT2CetED68ufyAUQjYCiGRzBe9oPA@mail.gmail.com>
- References: <CAP2my4b=tJOcxZtW7xNvGjT2CetED68ufyAUQjYCiGRzBe9oPA@mail.gmail.com>
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0
Le 16/01/2017 à 22:53, Hank Grabowski a écrit :
> Hello all,
>
> I'm surprised I haven't run into this before but on a project I'm
> starting to see exceptions with the Ephemeris propagator when I'm doing
> event detection. If the event straddles an end point then the
> ImmutableTimestampedCache is asked to return points just outside of the
> data bounds. It looks like the EventState.evaluateStep is sometimes
> taking the final state and slightly perturbing it forward beyond the
> ephemeris bounds (it doesn't know it's the final state of the ephemeris
> obviously). We are getting around this by backing off the propagation
> window by a second but it'd be ideal if we could do something like:
>
> -load ephemeris
> -get ephemeris start date
> -get ephemeris stop date
> -set up event detectors
> -propagator from the start date to the stop date
> -collect the detected dates
>
> I'd change Ephemeris.basicPropagate to first check if the requested date
> is within the bounds or not. If it is outside the bounds it will get
> the "interpolatedState" by doing the SpacecraftState.shiftedBy operator
> rather than trying to interpolate. My thought is that if it is within a
> certain tolerance (like 1e-6 or something) then we just do it but if the
> requested date is outside of that range then it checks a user
> configurable field a user can set allowing/forbidding extrapolation.
>
> Thoughts?
This is fine with me. This is exactly what shiftedBy is intended for:
small time offsets to allow fine tuning in the neighborhood of an
already known state.
>
> I'd like to get this into Orekit 9.0 if everyone agrees.
Sure. Anyway, we will again be late for 9.0. Hipparchus 1.1 is still
not published.
best regards,
Luc