Re: [Orekit Developers] Ephemeris Object Extrapolation

That does sound like a neat idea. Let me think about that sort of an implementation because I was currently struggling with whether I wanted to do a state propagation from the last point or a literal extrapolation. With that sort of an implementation I could write extrapolation functions for both and users could inject their own methods if it suited them.

Unfortunately I did not solve the mismatch problem. For what I needed the difference in my final results weren't affected by it. I would like to go back to it eventually though.

On Fri, Oct 24, 2014 at 3:56 AM, MAISONOBE Luc <luc.maisonobe@c-s.fr> wrote:

Hank Grabowski <hank@applieddefense.com> a écrit :

I have often run into a problem, especially during some propagation, where
the Ephemeris propagator doesn't have quite enough data to allow the
underlying event detector sampler to get to where it needs to go. It
doesn't happen often, but it's happened enough that I've considered looking
at letting users of the library construct an Ephemeris object that has the
option to allow extrapolation at the boundaries. My thought is that the
default behavior would be to keep it exactly as it is now. I was going to
add two additional constructors, one that simply has the flag that enables
extrapolation and then another than allows the user to provide bounds on
how much extrapolation on either side that is allowed. This way a user
can't accidentally sample way outside of the ephemeris range but they can
avoid an exception for a near in sampling.

Before confirming the add I was going to create test cases for LEO, HEO and
GEO orbits and was going to see how fast the extrapolation degrades in
accuracy for these standard orbits. Assuming that:

1. The default behavior stays the same
2. There is a rigorous unit test for the additional cases
3. User options are as defined above

Is this something that the community would like to have committed back to
the main distribution?

Definitely.

I wonder if we could also set up some hook where the user could provide a function to extend the ephemeris if needed? This means the ephemeris data is not immutable anymore (which is bad) but may be an improvement. Some similar feature exists for example in the JPL celestial bodies classes, as each body loads only 50 or 100 days chunk at a time, and reloads a new chunk as needed. IT was done to avoid loading 300 years of ephemerides when only a few days were needed, but could perhaps be generalized. It is also completely hidden in the implementation, and not based on a user hook.

Even if we don't go all this way, your patch with the flag is already a good thing to commit.

By the way, did you solve the mismatch between Orekit and HORIZON?

best regards,
Luc

Hank

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.