Hi all,
I have recently encountered a problem with event detection that I don’t understand.
This occurs while generating measurements when some satellites have attitude switches.
Measurements generation uses PropagatorParallelizer and I indeed have several satellites involved. The underlying propagators are either ephemerides when the various orbits are imported from external data or numerical propagators when the orbits are generated. On top of these orbits, I set up attitude sequence simulation with a rather complicated graph with several switches depending on various conditions (ground stations visibility, eclipses…).
When using numerical propagators, the attitude switch events are set up to generate Action.RESET_STATE as the dynamics changes when the satellites are re-oriented. This does not work with ephemerides as state is not resettable there, so I had to adapt the event handler depending on the type of propagator. I tried to use Action.CONTINUE and Action.RESET_EVENT when using ephemerides. With both types of actions, I get random exceptions in the ephemerides case. As the exceptions change on different runs, I guess they are related to multi-threading problems. I either get null pointer exceptions on the t0 date in the EventState that manages event occurrence, or I get failure in root finding (despite the boundaries shown in the exception message are clearly opposite signs). I think my event detectors and propagators are all fully independent from each other. The only shared data seems to be thread-safe to me (ground stations, Sun, frames…). The exceptions occur at each run, and always in the EventState class.
What is strange is that if I run the test under debugger just where the exception is about to be thrown, I see for example the ta argument to EventState.findRoot being null, and if I look up one frame in the debugger, I see this ta parameter comes from the t0 field in the EventState class (it is the call from tryAdvance) and t0 is is not null! I think ta is a reference, not a copy, so even if some thread had overwritten some fields in the EventState class, both should have been affected. I don’t understand what happens. I also could not trace from the EventState up to the initial Propagator from the parallelizer. May be the up frame is evaluateStep rather than tryAdvance, but this is not what the debugger displays in the call stack.
Did someone encounter such behaviour?