This repository was archived by the owner on Oct 14, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Oct 14, 2023. It is now read-only.
Improve validation of planetary reference frames #109
Description
In the early days of poliastro, a question was raised about the reference frames of bodies other than the Earth:
http://physics.stackexchange.com/q/69792/7641
The answer is that these are defined by the IAU Working Group on Cartographic Coordinates and Rotational Elements (WGCCRE).
http://astrogeology.usgs.gov/groups/IAU-WGCCRE
These frames should be taken into account when defining orbits around the bodies.
Activity
astrojuanlu commentedon Jul 6, 2016
The notion of a reference frame within this package is still very unclear and needs careful thought. Postponing this.
astrojuanlu commentedon Sep 12, 2016
In fact, right now the plotting code is the only one that makes use of reference frames, and it's done in a very artificial way.
https://github.com/poliastro/poliastro/blob/93d58de/src/poliastro/plotting.py#L63-L84
astrojuanlu commentedon Feb 26, 2017
See this for a starting point:
https://github.com/astropy/astropy/blob/v1.3/astropy/coordinates/builtin_frames/icrs_cirs_transforms.py#L287-L297
Perhaps this goes to Astropy itself? Note to self: open an issue.
astrojuanlu commentedon Feb 26, 2017
Quoting from the official report:
https://astropedia.astrogeology.usgs.gov/download/Docs/WGCCRE/WGCCRE2009reprint.pdf
With this data, in theory it would be possible to implement inertial, planet-centered reference frames.
astrojuanlu commentedon Mar 22, 2017
We will probably implement this as part of Astropy, see astropy/astropy#5898.
39 remaining items
astrojuanlu commentedon Jan 31, 2019
Removing my assignation from this issue, as someone might want to tackle it in GSOC.
GorgiAstro commentedon Apr 7, 2019
Orekit supports frame translation, rotation or both, and has inertial and body-fixed frames for all planets + the Moon. Using the Python wrapper would enable to integrate Orekit in the test cases without having to rely on hard-coded data from GMAT/STK/etc. If it is of interest, I can start working on it.
This could be used for #451 as well.
astrojuanlu commentedon Apr 7, 2019
Hi @GorgiAstro, thanks for chiming in! In fact I didn't consider Orekit but that was an oversight on my part - it would be great to validate poliastro against it. The great @petrushy maintains the Orekit Python bindings https://gitlab.orekit.org/orekit-labs/python-wrapper, so this is definitely feasible! Could you please add Orekit here https://github.com/poliastro/poliastro/wiki/Validation?
There is an ongoing pull request to address #451 with SPICE, see #602. However, it would be great to have it validated against Orekit as well.
GorgiAstro commentedon Apr 8, 2019
Done.
Okay, I will get started on test cases using Orekit-Python then. Besides, it is a good way for me to get used to working with poliastro. I created a separate ticket #644
astrojuanlu commentedon Jun 21, 2019
After a long silence, I plan to get back to the work @amsuhane and @GorgiAstro did during the (Northern) summer for poliastro 0.14. Before that, I would like to make a big refactor of the
bodiesmodule to remove the rotational elements from there and simplify the class structure, and possibly tackle #703 along the way.astrojuanlu commentedon May 7, 2021
This is finally being addressed in poliastro/validation#24! poliastro is now validated 🚀