Re: [Orekit Users] Additional States

[MAISONOBE Luc <luc.maisonobe@c-s.fr>]

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.