Re: [Orekit Developers] Ephemeris Mode & AbstractPropagator

[Thomas Neidhart <thomas.neidhart@gmail.com>]

On 04/01/2012 11:29 AM, MAISONOBE Luc wrote:
> Thomas Neidhart <thomas.neidhart@gmail.com> a écrit :
> 
>> Hi,
> 
> Hello Thomas,
> 
> Yes, except if the method is overriden by a concrete class.
> 
> The rationale behind this strange behaviour is related to performances.
> For numerical propagators, performing a complete propagation may be CPU
> internsive. In this case, we save the intermediate state in an ephemeris
> that is built on the fly and we reuse it later. It is a trade-off
> between computation time and memory consumption. In this case, the
> computation comes first and the ephemeris is a by-product. For
> analytical propagators, the reverse is true. Computation is very cheap
> so there is really no need to waste memory by storing results, it is
> more efficient to recompute everything. In this case there are no
> differences between propagation and ephemeride use.
> 
> However, it seems important to let the user still have all these
> features available regardless of the underlying propagator. So user may
> select either a numerical or an analytical propagator and use either
> direct computation (mainly if he wants to do a single pass from start to
> end) or ephemeris (mainly if he needs to go back to some dates or
> navigate back and forth, for example in a search algorithm).
> 
> The boundaries betwwen these two modes is blurred in the case of DSST
> which is a semianalytical model. If I remember well, Pascal did set up a
> smart mechanism to build ephemeris as propagation goes on, and reuse it
> at the same time. this means that if you propagate from t0 to t2 it
> builds an internal ephemeris, then if you go back to t1 (between t0 and
> t2) it will see it already has the required data and will use its
> ephemeris, and if you then go to t3 it will jump to t2, then propagate
> to t3 storing the results at the same time.
> 
> From user point of view, all propagators provide the same features, and
> all of them are as fast as they can be.

ok thanks, this really helped improve my understanding.

I have another question related to the master mode. When trying to
detect certain events for which I roughly know when they will occur,
e.g. a visibility, is there a neat way to provide an adaptive step handler?

Right now, there is only a fixed step size, so when propagating several
days into the future, it can take a while if you have a small step size
(in order to detect also short visibilities). It would be great to have
a possibility for a step handler to provide a "hint" to the propagator
to when it should be called again.

I have done something like this in a manual way, switching from slave to
master mode when appropriate, but it would be nice if this could be
supported via the StepHandler interface. Default behavior would be like
now, e.g. fixed steps, but a StepHandler can override something like a
nextStep method that returns a time reference.

What do you think?

Thomas