[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orekit Users] Additional States



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.

If anybody does not agree with the design choices explained above, please continue this discussion so we can reach consensus.

best regards,
Luc


cheers

Sylvain





----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.