I am trying to implement a basic battery model, but the problem can be generalized.
The battery energy is stored in an additional state which evolves according to differential equations (implementing AdditionalEquations interface).
The battery energy decreases when a consumer is ON.
When the battery reached a limit, 70%, the consumer turns OFF. A detector is used for that. The consumer handles the event and notifies the battery model to stop consumption.
The problem is that the detector depends on the model which is updated when the detector detects an event… then the progator get lost and loop infinitely.
So far we found a workaround by setting the derivative to -1e-10 instead of 0 when there is no consumption, which break the infinite loop.
I think it’s an architecture problem in our implementation, and the solution might be to break the dependence loop. Have any of you got the same kind of problem ? Is there a proper way of implementing this kind of mechanism ?
I have isolated the code showing the problem in the following file.
The way you’ve written it it should work. My initial guess is that the g function of ValueDetector gets stuck at exactly zero for a long time, which causes something to break in the event detection code. All of the existing test cases are for g functions that cross zero, not ones that stay there. If this is the case it is certainly an issue with Orekit/Hipparchus. Could you create an issue on our bug tracker with the file you attached? [1] A stacktrace would be nice too. Thanks for breaking the code and finding this!
Hello, thank you for the answer, I think that the stop at zero is the main problem. Once the g functions reach 0, it does not evolve. I will create the issue
The issue is created here : https://gitlab.orekit.org/orekit/orekit/issues/524
The main problem was on architecture with the same level to start and stop the contribution : using 2 detectors with one level to start and a different one to stop fixes the behaviour.