Re: [Orekit Developers] Ephemeris Mode & AbstractPropagator

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

On 04/01/2012 01:37 PM, Thomas Neidhart wrote:
> 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.

Actually, I was imprecise in my comment. I was not referring to the
master mode, which already supports to create a customized step handler
to do the things I outlined before.

The thing I was referring to was the EventDetector interface, which in
my understanding, uses fixed step sizes.

Maybe changing the behavior of EventDetector#getMaxCheckInterval could
help in such a case. Or do the other classes (EventState,
BasicStepInterpolator) assume this value to be fixed and not changing
throughout the propagation?

Thomas