Re: [Orekit Users] AttitudesSequence with a NumericalPropagator

[Luc Maisonobe <Luc.Maisonobe@c-s.fr>]

Le 06/02/2018 à 16:34, Di Genova Glauco a écrit :
> Hi,

Hi Glauco,

> 
> I'm trying to use an AttitudesSequence with a NumericalPropagator, but
> even a simple modification of the EarthObservation tutorial seems to
> fail (code is attached to this message). There are two
> attitudesSequence.addSwitchingCondition calls. No matter how I swap
> them, the first switching condition is correctly detected within the
> maximum step size horizon of the integrator, with the correct
> AbsoluteDate, but the attitude is immediately switched without waiting
> for the correct epoch. There is no problem for the second switching
> condition. If I add a dummy first switching condition, i.e. 
> 
> attitudesSequence.addSwitchingCondition(nightRestingLaw,
> dayObservationLaw, nightDayEvent, false, false, 10.0,
> AngularDerivativesFilter.USE_R, switchHandler); with false,false, then
> everything works as expected. If I set the maximum stepsize of the
> integrator equal to the master mode stepsize, then again everything
> works. I'm not sure whether this is a bug or I'm missing something
> fundamental here.

I think you hit a limitation of Orekit that is not obvious and
unfortunately that we cannot remove for now. However, there is
probably also an additional bug in Orekit there, see below.

When a propagator has both event detectors and steph handlers, they
are scheduled as follows. For each attempted step, the propagator
looks at the upcoming events, so it is in some way ahead of time.
So suppose the previous step was handled up to t_k = 100s and the
propagator is ready to validate step between tk and t_k+1 = 200s.
If one of the events checked occurs between t_k and t_k+1, say at
150s, the propagator will truncate the step and reset t_k+1 to 150s.

Then the propagator knows everything is finalized and it has to
call both the step handler handleStep method with the step [100, 150]
and the event handler eventOccurred with the event time at 150s.

Here is the problem:
As the event handler eventOccurred method may return Action.STOP to
tell the propagator should stop and no further step will occur, the
eventOccurred method is called *first* and the handleStep is called
*next* with the isLast boolean set to either true or false depending
on the return value from eventOccurred. This is the part we currently
cannot change. It may seem weird from a user point of view since the
end of the step is handled before the step itself.

There is probably a bug in addition to this strange "feature". The
tutorial uses a fixed step, and internally this uses a
OrekitStepNormalizer. I think (I have to check) that the normalizer
in fact precomputes the next step at one call and will output it
later. If an event handler changes the state (which is the case in
this tutorial), the weird step/event out of chronologu calls and
the "precompute next step" in normalization interact badly and
everything is out of order. It seemed we "fixed" this in the tutorial
by sorting the output lines (see the "output" variable, which is a
sorted set. So we generate the output out of order and sort it
before printing it. The result is that you see the effect of the
switch before the switch itself.

What makes me think the culprit is in the step normalizer is
that when you prevent the integrator to use steps larger than
the fixed step, the problem seem to disappear.
So I think we have to look back at the step normalizer.

From a simulation point of view, the propagator itself does
the right thing: the event is triggered at the correct date
and the state changed accordingly. What is not correct is
how the step handler is called here.

As a summary:
  - there is a weird "feature" in Orekit concerning the
    scheduling of calls between step handlers and event handlers,
    which shows up when they interact with each other
  - this is even more complicated when fixed step handlers are
    used, because they are normalized under the hood and
    precomputed from one step to another
  - there is very ugly and probably wrong "fix" in the
    tutorial as the output is sorted after it has been generated

best regards,
Luc

> 
> Thank you - Glauco
> 
>  
> 
> 
> Telespazio S.p.A.
> 
> *Glauco Di Genova*
> Satellite Operations
> 
> Strada 31 Fucino - 67050 Comune di Ortucchio (AQ) - Italy
> Ph: +390863550617 | Fax: +39 06 4099-9594
> glauco.digenova@telespazio.com
> telespazio.com <http://www.telespazio.com>
> 
> 
> -WARNING: This message contains confidential and/or proprietary
> information which may be subject to privilege or immunity and which is
> intended for the use of its addressee only.
> Should you receive this message in error, you are kindly requested to
> inform the sender and to definitively remove it from any paper or
> electronic format.
> Any other use of this e-mail is strictly forbidden. Thank you in advance
> for your cooperation.
> 
> Please consider the environment before printing this e-mail.