Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New ellipsoids : Proposal #176

Closed
MarkWieczorek opened this issue Mar 28, 2024 · 0 comments · Fixed by #180
Closed

New ellipsoids : Proposal #176

MarkWieczorek opened this issue Mar 28, 2024 · 0 comments · Fixed by #180
Labels
enhancement Idea or request for a new feature

Comments

@MarkWieczorek
Copy link
Contributor

I would like to add a large number of ellipsoids to Boule. These would include: Mercury, Venus, Moon, Mars, Ceres, Vesta, Eros, Io, Europa, Ganymede, Callisto, Enceladus and Titan. Some of these would update the ones already present in Boule. The number of ellipsoids will likely increase over time, and many of the ellipsoids will be updated by future measurements. The current manner that Boule deals with ellipsoid realizations in not adapted to this large increase in number.

There are two issues: How do we store and organize these in Boule, and what do we call them?

Organization

In order to make it easy to find the raw ellipsoid declarations, I propose that we convert the file _realizations.py into several: one for each planet, the Moon, and asteroids

  • _mercury.py
  • _venus.py
  • _earth.py
  • _moon.py (this could maybe incorporated into earth)
  • _mars.py
  • _asteroids.py
  • _jupiter.py (all moons of Jupiter)
  • _saturn.py (all moons of Saturn)

(more to be added as necessary...)

The realizations in these files would then be imported into a module called "ellipsoids" (i.e., boule.ellipsoids). Initially, I think that we can just import them all into one space. However, if we start adding a large number of small moons of the outer planets, or if we start getting a lot of versions for a single body, we might want to consider organizing them into submodules, like ellipsoids.Jupiter.Ganymede.

A question is whether we should put all these files in the top level directory, or put them in a subdirectory.

Naming scheme

It is important to have some kind of "version control" for the ellipsoids that we propose. The parameters might change slightly over the years with improved ephemerides, or we might get new data from spacecraft. It is imortant that we don't change the values in an ellipsoids without telling people!

I propose a simple naming scheme that is just the body name, and the year that we defined the ellipsoid. If two ellipsoids are generated in the same year, we could add "a", "b, "c", For example Mercury2015, Mercury2024, Mercury2024b.

For the case where there are well defined previously published ellispoids, we could break with this convention: WGS84, EGM2008, etc. The only other body where there was an ellipsoid published was Mars: Ardalan et al. 2010. For this case, I would probably just call it Mars2010.

Referencing

The new ellipsoids require several parameters (GM, a, f, omega), and thus we might have separate references for each of these values. I propose to just put them all into a long reference string like

"a, f: some reference 2010; GM: another reference 2009; omega: and yet another reference 2000"

Are you willing to help implement and maintain this feature?

@MarkWieczorek MarkWieczorek added the enhancement Idea or request for a new feature label Mar 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Idea or request for a new feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant