StepHandler and EventHandler callbacks order

Orekit usage
1

Hi all,

First of all congrats for the release of the new v12! Truly amazing job there!

Recently, I started working on a new application which involves a propagation with constant thrust maneuvers and the use of a fixed step handler to collect the states. To store the state at maneuver time, I am taking advantage of the maneuverTriggered method defined in the ManeuverTriggersResetter interface.

While propagating, I noticed that the order of callbacks functions is not the one I was expecting.
Here is a screenshot:
image

In particular the entry at maneuver time is appearing before the entry at step 2004-01-02T04:15:30.000Z.
This problem doesn’t appear when using a variable step handler.

Attached a simple Java class showing this.
Playground.java (4.4 KB)

I read an old post regarding this and I understood that this part was in fact refactored some time ago to make the callbacks more consistent with the propagation direction.

I am now wondering, is there anything that I am missing or is this the expected behavior?

Thanks a lot for your support,
Mirco

2

This is expected. The post you reference has indeed be implemented to fix these out-of-order calls so they work correctly in all cases… except when fixed steps are used.

The reason is due to the way fixed steps are computed. At the lowest level, the only step handlers the integrator knows about are variable step handlers. There is a StepNormalizer class that implements the general variable step handler interface, uses the interpolator to move within the step and then calls the underlying fixed step handler. This implies this normalizer is placed somewhere between integrator and the user handler, and it has its own idea of what current time is. This breaks the ordering in some cases as the integrator calls the normalizer when the full step is available (which is at the end of the step), but then the called normalizer may see there are several fixed steps within this variable step and it will call the fixed handler several times in a loop, spitting out dates that are all within the range of the variable step, i.e. the step handler will be called “too late” and will display times that are already in the past with respect to the event handler (or in other words the events handler may think it is called too early).

3

Hi @luc,

Thanks for the quick reply.

Following your explanation, I had a more detailed look at the OrekitStepNormalizer class.
Wouldn’t be just a matter of swapping these two lines?

            // prepare next iteration
            nextTime = nextTime.shiftedBy(step);
            nextInStep = forward ^ nextTime.compareTo(interpolator.getCurrentState().getDate()) > 0;

with

            // prepare next iteration
            nextInStep = forward ^ nextTime.compareTo(interpolator.getCurrentState().getDate()) > 0;
            nextTime = nextTime.shiftedBy(step);

I tried this on the develop branch and here is the output:

image

Not sure if this has some impact on other components though.

Thanks,
Mirco

4

No. When we reach this line, we are already in a loop that reads:

        boolean nextInStep = forward ^ nextTime.compareTo(interpolator.getCurrentState().getDate()) > 0;
        while (nextInStep) {
          ...
        }

So the nextInStep boolean is already set to the same value, and the two statements are here to go to the next step, hence we increase time and then check if we are still within step range.

I am more concerned about the handling of lastState, which delays the handling of the step.

It may come from the older API where we had an isLast boolean to identify the last step from the other ones. This boolean has been removed and replaced by a finish method, but the lastState handling may have bee overseen there. Also the isLast boolean seems to still be there in the Hipparchus ODEFixedStepHandler despite it has been removed in Orekit OrekitFixedStepHandler. There is something fishy there.

5

Right, I missed the line before the while loop.

I agree, it seems that in case of an event the handling of the lastState is being delayed until the next step.
Shall I open an issue in the forge?

6

Yes please.