poliastro / validation

Validation of poliastro against external software.
Apache License 2.0
11 stars 6 forks source link

Maneuvers validation againts Orekit #15

Closed jorgepiloto closed 3 years ago

jorgepiloto commented 3 years ago

This PR solves for gh-10. By adding a apply_maneuver method to the actual OrekitOrbit class (same API as poliastro), it is possible to apply impulsive maneuvers to any instance of the object. However, some problems were found when implementing this:

I guess it can be something related with frames, since vectors were introduced in the TNW. Hopefully, studying those will be helpful not only for this issue but also when validating planetary reference frames.

jorgepiloto commented 3 years ago

After asking in the official Orekit forum, see this link, I was able to learn how to use the proper frame to define the local velocity impulses. However, the current Orekit based API does not match results predicted by GMAT while poliastro does.

Here is the GMAT2020a script which serves as expected results source:

https://gist.github.com/jorgepiloto/9ba39b782f0623537511d238c6c04463

The orbit starts near perigee but still needs to reach this positions. The reason behind this is just to make sure that triggers do not introduce additional undesired behaviour. For example, if an orbit in GMAT starts at periapsis (let us say you do not now initial position) and you force it to propagate to periapsis (so you can be sure where it is going to be before starting the maneuver), it will introduce +1 revolution, that is tof = tof_maneuver + 1 period.

Same reason applies for the extra 1 hour propagation. GMAT does not supply final orbit elements until you have crossed orbit's apoapsis.

jorgepiloto commented 3 years ago

I am suspecting now about the fact that final orbit is circular. This can affect Orekit propagators, see this lines from the ApsideDetector event detector:

Beware that apside detection will fail for almost circular orbits. If for example an apside detector is used to trigger an ImpulseManeuver and the maneuver change the orbit shape to circular, then the detector may completely fail just after the maneuver has been performed!

jorgepiloto commented 3 years ago

I decided to use an EventLogger() in order to know at which epoch were the at_periapsis and at_apoapsis events being detected. Obtained results show those are not being executed at the right epochs. In addition, the introduction of an EventLogger() seems to affect final results by several orders of magnitude. This is becoming really weird...

jorgepiloto commented 3 years ago

In the latest push, I added two new files: test_maneuvers.py and test_raw_hohmann.py. The reason behind this is as follows: although the same code flow is being run through the usage of custom OrekitManeuver and OrekitOrbit classes, final result is not the same as the one coming from a raw usage of the Orekit wrapper. I've checked line by line, even forcing again vectors to be in the orbit frame and still did not found why final result does not approach the one in test_raw_hohmann.py.

jorgepiloto commented 3 years ago

After discussing with @astrojuanlu, we decided to change the current validation approach, that is, without making use of a custom API relying on Orekit.

Therefore, I am closing this as in the next hours a new PR will be opened to propose a reformat on all mother code. I already made some changes locally and must say that everything got super clean and simple. In addition, code seems to be more stable as no random errors and no-sense results were raised.

astrojuanlu commented 3 years ago

Great to know @jorgepiloto , thanks for the update and all the detailed discussion and links! Looking forward to reviewing that PR