[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Orekit Users] R: -Commercial: Re: AttitudesSequence with a NumericalPropagator
Hi Luc,
thank you for the very clear and detailed information. What still puzzles me is the fact that adding a first dummy switching condition seems to fix the problem. Anyway, for the time being I will set the maximum integration step equal to the fixed step in master mode.
Best regards - Glauco
-----Messaggio originale-----
Da: orekit-users-request@orekit.org [mailto:orekit-users-request@orekit.org] Per conto di Luc Maisonobe
Inviato: martedì 6 febbraio 2018 18:28
A: orekit-users@orekit.org
Oggetto: -Commercial: Re: [Orekit Users] AttitudesSequence with a NumericalPropagator
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.
[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.