I have heavily modified the way I was implementing the gravitational model (EGM96 and 2008). It turns out that all the static models (in which the coefficients do not change with time) use the very same equations. Hence, now the interface is very generic and all the static models described by the gfc files in ICGEM can, theoretically, be used (see the function parse_gfc).
To simplify the usage, I decided to add the three most common models used in orbit propagators: EGM96, JGM3, and JGM2 (I did not add the EGM2008 because the full coefficients files have more than 50 MiB!). I simulated some scenarios in the online calculator at ICGEM and the gravity acceleration computation between the online tool and SatelliteToolbox.jl was matched with absolute tolerance of 5e-8 m/s^2.
Here is how you can compute gravitational acceleration in SatelliteToolbox.jl:
Now I have a question: the SatelliteToolbox.jl have now the geomagnetic field model IGRF, the atmospheric model NRLMSISE-00, and the gravity models. I am not entirely sure if this is the right thing to do, but what if I split those algorithms to something like EarthModels.jl ? What are the pros and cons?
Very nice, thank you, you have added a lot in a short time to the SatelliteToolbox.
I think that the tools/models presently available in the package all have to do with satellite orbits around the Earth, and a good name might be EarthOrbits,jl. For interplanetary missions, planning flybys etc., one would need quite different tools, if ever implemented in Julia, this could live in a separate package.
The gravity, magnetic field, and air density models are needed for some of the satellite orbit tools, but are also used in different contexts, not always related to satellites. They share methods like spherical harmonics expansion, so I recommend they could be in a separate package, perhaps GeophysicsModels.jl. And by the way, would you be interested in adding the international reference ionosphere (Index of /IRI-2016)? It is a bit similar as the NRLMSIS, probably you could do it more efficiently than anyone else.
A âSatellite Toolboxâ would, I think, eventually include stuff like SPIS (http://dev.spis.org/projects/spine/home/spis), thermal modeling etc, things a bit different from orbit calculations. Therefore I suggest a name change for the present toolbox âSatelliteToolboxâ â âEarthOrbitsâ, sorry about this.
Thanks for the suggestions! I will look those models you showed. The SatelliteToolbox will include a lot of more things designed for satellite simulations. Hence, it does not need renaming, since there will be a lot of functionality here, but maybe I need to create more packages and move functionalities to them.
GeophysicsModels is indeed a good name. I will gather some more advices (because there is some downsides of splitting packages), and then I will decide what to do
Hi,
Having the magnetic and gravity models as a separate package would be nice, I think, but GeophysicsModels has a quite broad meaning name. There are many other things (seismic for instance) that fit in there as well. Likely not for the atmospheric model but the gravity and magnetic have a classical name in Geophysics, which is potential models (because they can be derived from a potential via Laplace equation). Perhaps GravMagHarmonics?
Seismic models do share to some extend the numerical/mathematical methods of the gravity, magnetic, and atmosphere/ionosphere models. Also conceptually, recent and upcoming high precision satellite measurements (SWARM, GRACE-FO) will sooner or later allow for connecting gravity, seismic, and crustal magnetic field modeling. Therefore I recommend to have a GeophysicsModels package open for also particularly seismic models, faciliting any potentail future interdisciplinary work.
About naming an implementation of spherical harmonics should really go to something more generic such as PotentialModels since such tools are also used in other area of physics (eg quantum physicsâŚ).
All the static models (for all the planets) use the spherical harmonic expansion, only the data is different so I donât see the point of hardcoding the models. The user could specify a file to load the coefficients from. For example you can find here a file for a Mercury gravity model:
This is great, you have been on a roll with this package.
As you know already, I am in favor of breaking out these models into separate packages. The idea of an EarthModels.jl is nice in that it makes sense for astrodynamics-focused people to group things in this way, but as others have mentioned, Iâm worried this may be too broad. The thing that makes the most sense to me is separate packages: a GeopotentialModels.jl, NRLMSISE00.jl and IGRF.jl.
May I ask what exactly you mean by gravity models? I am reading a book on the Apollo programme at th emoment, specifically the Apollo 11 mission. It refers to mass concentrations (mascons) in the Moon which make orbits deviate from what a perfectly uniform body would produce. The missions which went before 11, orbiting the moon etc. were necessary stepping stones because they helped mass the mascons. Also I suppose the unmanned missions from the US and USSR also helped.
Also going off topic here⌠I am from the UK and that nation is being denied the high precision signal from Galileo, come Brexit. It was of course the UK which brought in the âno non-EU nation will joinâ rule⌠DooohâŚ
I would very much guess that the gravity model for the Earth must be mapped such that the orbits of Galileo, GPS, Glonass satellites can be predicted properly? In laymans terms I suppose if they orbit over a mass concentration the orbit goes wonky!
Good argument, a package for each model would have advantages, I think. With the Queryverse as the role model, metapackages like Geophysics.jl would just pull all tools together, that a user wanting to do something in this field might need.
Important is perhaps that there is a good interface to Julia specific features. E.g. how can we iterate over the data that we use? I learned from this nice tutorial that all iterable named tuples can be fed into that system.
So if the SateliiteToolbox, GeopotentialModels ⌠packages allow to convert data and models input/output into such data structrure, it would be great. Perhaps some standardization of names is important? For example, instead of latitude use
geocentric_latitude as used in the gravity and magnetic field models;
geodetic_latitude as used in mapping tools;
qdip_latitude and aacgm_latitude for magnetic latitudes (indirect output of magnetic field models);
when creating named data structures (like named tuples) that go in and out of the packages. This is only an example. Not sure what really needs coordination, how and who.
I think that trying to get these things consistent and working seamlessly can deliver one of the main benefits that integrating all this in principle already existing software into a language like Julia has.
After talking to some Julia devs, I received a strong suggestion to does not split the package in a bunch of very small packages. This will make maintenance harder. However, I agree that having everything in one package is not good also. Hence, I decided that a GeophysiscsModels.jl would be fine for now. If this starts to grow with many models, then we can think what to do
People from the (Space) Geophysis area of my institute liked the idea. They mentioned that many models have intersections between them, and having all of it in one place is good.
I will try to split the package today and submit to METADATA.
Guys, I will do a pause in splitting this package as per @StefanKarpinski advice. When trying to do this, it became clear that a more careful analysis must be done. For example, IGRF depends on a function that converts Geocentric to Geodetic coordinates. Hence, creating the SpaceGeophysicsPackage will lead to a circular dependency.
I decide to let everything in SatelliteToolbox and, once all the things get implemented, we can have a good picture of what we should split. In fact, it takes some work to do those things and I prefer to focus on development first.
However, we created a new org that, if everything works, would merge a lot of packages related to Space in Julia. This was called JuliaSpace. I am transfering SatelliteToolbox and ReferenceFrameRotations to it. Feel free to add more packages
Celestial bodies do not have uniform densities and the usual method to deal with this fact is to model the gravity potential field using Spherical Harmonics.
However for bodies which have large non uniformities in density (such as the âmass concentrationsâ on the Moon), the spherical harmonics model needs to have high degree and order to be useful (sufficiently accurate). At the time of Appollo mission, it was certainly not possible to implement high degree and order spherical harmonics on a computer (and not enough observation time to determine the 1000s of coefficients). However if you can figure out where the mass concentrations are, you can also build a âmasconâ model which is just a set of point- or uniform disk shaped- masses that can model the mass concentrations. The best approach is probably to build a spherical harmonics model to modest degree and order and add a mascon model on top to adjust for the high spatial frequency variations.
Well, it is done! SatelliteToolbox is now part of the newly created JuliaSpace organization. I would like to propose everyone that have space related models to submit a package Letâs make Julia a wonderful language for space applications!
@StefanKarpinski gave me a very good advice. I will start to create submodules inside the SatelliteToolbox, looking for common applications that can reside in their own packages. Once we do this, it will be much easier to decide how can we split the functionality. If you can help trying to design such division, I will appreciate
Iâd be happy to provide input. I believe I have Discourse set up to ping me whenever there is a post in the Astro/Space category, but feel free to also ping me directly either here or on the Slack (or Gitter). If I get a chance, Iâll put any thoughts I have on the Github issue.
As for JuliaSpace, I think that is a good idea, except that JuliaAstrodynamics already exists, and Iâm worried about duplication/ambiguity/other problems associated with having two different organizations associated with the same subtopic. Maybe @helgee has some thoughts about this (I believe he started JuliaAstrodynamics).
As a matter of fact, it was @helgee who proposed to merge the organizations. We came up with this name JuliaSpace because it makes sense for packages that have a lot of things related to Astrodynamics (JuliaAstrodynamics), satellites, Geophysics (NRLMSISE-00. IGRF, Gravity models) and so on.
