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.