so I’ve only recently noticed something. For the Solar Radiation Pressure calculation, 2 times the number of occulting bodies are stacked to the propagator, for penumbra and umbra respectively. I see that, on the develop branch, @luc is refactoring things around that. Would there be a way to have only one detector per body, to avoid redundant computations? If I understand correctly, they’re only there to reset derivatives because of the piece-wise nature of the force w.r.t. time?
My point is that, with Field propagation for instance, this double detector can actually become the bottleneck of a propagation. More than the actual call to the SRP acceleration or all the non-gravitational terms put together. Thoughts?
I agree this is a strange and stupid-looking design.
What I feared when doing this, though, was to miss events when close to Earth. In these cases, penumbra is a thin layer and if maxCheck is small enough, satellite can go from full light to full umbra in a short time. If we set up a detector that is say positive in light, negative in penumbra and positive again in umbra, we may miss the pair of events light/penumbra penumbra/umbra. Somehow, we would need a third sign.
A big change would be to set up events detection to allow multiple switches and not only switches at zero governed by signs.
I see, thanks for all the info Luc.
It does seem like a big change to start fiddling with the backbone of the detectors.
Would it be possible instead to set up a low fidelity version of SRP, where there is no detectors added to the propagator by the force model? Basically agreeing to have some integration noise due to steps possibly overlapping between shadow and light?
I don’t think a low fidelity SRP would be wise.
I did some experiments recently for navigation purposes and indeed having extremely accurate switch was really important for comparison between different cases. The noise introduced by computing the wrong acceleration at some close times was above the accuracy we wanted (a few centimeters level).
I guess it depends on the application. For instance in GEO, eclipses are rare so the two detectors are running pretty much for nothing. Again, my point is mostly for Field propagation, where any computation can be costly. Actually, a rejected integration step (even due to tolerances of an adaptive scheme) is especially wasteful in that scenario, but that’s kind of another story. At least for SRP, the new getPosition method based solely on StaticTransform would improve things in the next major release, so there’s still that to look forward to.
Maybe I’m out of context but can you not extend SolarRadiationPressure and override getEventDetectors() method with your own set of event detectors, tailored to your needs?
Maybe, I haven’t looked at a possible workaround yet, so thanks for pointing that one out but I tend to avoid local overwrites of dependencies if possible
I just wanted to discuss a potential future native way of improving performance, given that Luc is modifying pretty much everything in Orekit for the next major release
I might have found a reasonable workaround. We could add a constructor where one can pass a specific AdaptableInterval for the two internal detectors. This way the experienced user could tune it for their application.
What do you think?
but I tend to avoid local overwrites of dependencies if possible