ApsideTrigger Order Dependency in config.yaml

Orekit Python Wrapper usage
1

Hello dear forum members,

I have created a configuration file (config.yaml) where the triggers for ImpulseManeuver are defined. During the initialization of DateTrigger maneuvers, everything works perfectly. However, strange things sometimes happen when trying to integrate ApsideTrigger into the simulation. The issue is that the order of apoapsis and periapsis triggers in the config.yaml currently matters. In my understanding, the order in which the triggers are defined should not matter during initialization, when the program reads the data from the YAML file.

For example, in the following case, two ApsideManeuvers occur at the apogee at the same time:

          - type: peri
            event_num: 3
          - type: apo
            event_num: 5
          - type: apo
            event_num: 6

On the other hand, if the maneuvers are defined in the wrong chronological order, everything works:

          - type: apo
            event_num: 5
          - type: peri
            event_num: 3
          - type: apo
            event_num: 6

I would be very grateful for any insights or suggestions on how to resolve this issue. Maybe there are already known cases of such discontinuities during initialization?
Thank you in advance for your help!

Best regards, Max

2

Hi @max_gze,

Are you sure this comes from initialization ?
Apside detectors are a bit tricky with maneuvers because the maneuver itself can change the apsides location on the orbit, and thus undesired events may be triggered.
I don’t know if it is what you experience. Could you maybe share a bit of your code ?
Also, you could you print the apogee/perigee detection and dates by adding a handler to the apside detector, that will help you understand what is exactly happening.

Hope this helps,
Maxime

3

I am certain that the issue stems from the initialization process, as I have not changed anything except the order of entries in the config.yaml file. Additionally, I am working with weak maneuvers, so an excessively low eccentricity can also be ruled out as the cause. This scenario can be further excluded by the fact that defining the ApsideManeuvers in the wrong chronological order actually results in a correct simulation.

I also generated a table listing the exact maneuver timings. In the case of the chronologically correct order, the following apsides are output, where apogee #5 and #6 are executed at the same time:

2025-02-17 04:06:53.412279+00:00,perigee
2025-02-17 04:53:30.536714+00:00,apogee
2025-02-17 05:39:48.630589+00:00,perigee
2025-02-17 06:26:25.622188+00:00,apogee
2025-02-17 07:12:43.331846+00:00,perigee
2025-02-17 08:00:13.951649+00:00,apogee
2025-02-17 08:47:32.160905+00:00,perigee
2025-02-17 09:35:02.797270+00:00,apogee
2025-02-17 10:22:20.812361+00:00,perigee
2025-02-17 11:09:51.372164+00:00,apogee
2025-02-17 11:09:51.372164+00:00,perigee
2025-02-17 11:09:51.372164+00:00,apogee
2025-02-17 11:58:40.725631+00:00,perigee
2025-02-17 12:48:24.931019+00:00,apogee

Apogee 5 and 6 are executed at the same time.

4

Ok @max_gze thanks for the clarifications.

Hard to say what’s happening without the code. Could you maybe reproduce the bug with a minimalist code example ?

Cheers,
Maxime

5

Hi

What is this ApsideTrigger you’re talking about? Is it from the tutorials or your own code?
Anyway, is your orbit quasi circular or are the maneuvers big? Because it could happen than applying the deltaV flips your perigee and apogee, causing multiple detections in a row.
If you want fine control on your maneuvers, I encourage you to look at ImpulseVectorProvider. What version of Orekit do you use?

Cheers,
Romain.