Sylvain Rouard <sylvain.rouard@astrium.eads.net> a écrit :
Hello all,
Hi Sylvain,
Thanks to recent improvements added on 2013-04-08 to orekit git
repository, the
management of Additional States is much more flexible.
Thanks for these kind words.
These additional states are managed by propagators using either
AdditionalStateProvider for already integrated states or AdditionalEquations
for states driven by differential equations.
Before, during and after propagation, current values of these
additional states
are stored directly inside the SpacecraftState object, which is
very convenient
for use in eventHandlers and stepHandlers.
Right.
However, i can see one drawback to the current implementation:
Let's say you add an additional state to an initialSpacecraftState before
propagation, then you register your initialSpacecraftState to the propagator
and launch propagation.
If you have not added either an AdditionalStateProvider or an
AdditionalEquation to the propagator, you additional state will be
lost during
propagation.
Yes. Currently, the propagator only handle the additional states it
has been asked explicitely to handle, either using
AdditionalStateProvider or using AdditionalEquations to compute the
evolution of these additional states. The additional states for
which no evolution laws have been provided will not be available in
the intermediate states seen by step handlers and event handlers and
will not be available in the final state returned at the end of the
propagation. As you wrote, they are lost in between.
The default behaviour I would expect in this case is to keep the
state constant
during propagation and provide it back to the user at the end of the
propagation.
This could be done by adding a constant getManagedStates to the
propagator when he founds a non-explicitely-managed additional state in its
initial SpacecraftState.
what do you think ?
This is a good point and we will add it. There is however one detail
that bothers me. I don't think considering this state as "managed"
is the way to go. There are two reasons for this. The first reason
is that the corresponding state is not really "managed" by the
propagator, it is only "copied" from initial state to all generated
states, intermediates and finals. The second reason is that this
state is known only during the run of the propagate method, whereas
the other managed states are known as soon as the evolution laws
(i.e. AdditionalStateProvider or AdditionalEquation instances are
registered to the propagator).
So I propose to have the propagator automatically copy the
additional states present in the initial state for one given
propagation run, but never list it as managed i.e. not return it
when the getManagedState is run. The getManagedState will only
return the additional states for which explicit evolution laws are
provided. A side effect of this choice is that user can be aware the
state has merely been copied if it is in the final state but was not
managed.
I'll implement this quickly.