[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Orekit Developers] Ephemeris Object Extrapolation
- To: orekit-developers@orekit.org
- Subject: Re: [Orekit Developers] Ephemeris Object Extrapolation
- From: MAISONOBE Luc <luc.maisonobe@c-s.fr>
- Date: Fri, 24 Oct 2014 09:56:44 +0200
- In-reply-to: <CAP2my4ZpHykkt81Jrdsbhnm63AwKcwX=DCHJaPyVBwnerc7W7A@mail.gmail.com>
- References: <CAP2my4ZpHykkt81Jrdsbhnm63AwKcwX=DCHJaPyVBwnerc7W7A@mail.gmail.com>
- User-agent: Internet Messaging Program (IMP) H3 (4.3.9)
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.