Discussion Improved (Tesseral) Gravity Model

[n72.75]

I've been playing around with the idea of implementing an improved gravity model for orbiter. Currently Orbiter calculates non-spherical gravity perturbations using only the J2-J4 terms. This results in a non-spherical gravitational potential field that varies only with latitude, and not with longitude, and is relatively simple. I have written an implementation of Pines Algorithm in C++, based on matlab code found in this document: https://ntrs.nasa.gov/api/citations/20160011252/downloads/20160011252.pdf

I have a very simple application that demonstrates the functions here: https://github.com/n7275/PinesnormOrbiter

And an attempt to shoehorn it into Orbiter here: https://github.com/n7275/orbiter/tree/tesseralGravity

I think this is a necessary feature. Earth isn't too bad with its dominating J2 term, but lunar gravity in Orbiter is very inaccurate.



Before I spend a whole lot more time on it, I wanted to open it up to discussion. So, please, do your worst, haha.

 

[Urwumpe]

Yeah, that could make the effect of the mascons more pronounced.

 

[N_Molson]

I don't quite nearly understand the equations of the gravitational model... But it makes sense that that model evolves in time. Orbiter is a bit like a science, it makes progress over time. It is quite the core and the whole point of the simulator, so any gain in precision/realism there will be a good thing, I'm all for it. And you're one of the guys beyond NASSP so you are certainly the one that should have a try at it.

 

[Ajaja]

but lunar gravity in Orbiter is very inaccurate

It's true.
I played with orbits around Moon in GMAT. They are crazy, especially LLO.
Even with simplified LP165P model.
There is also grgm900c model - 900 degrees spherical harmonic model with tides.

 

[n72.75]

I haven't touched anything related to tides yet, but I have run a few tests of this function (outside of Orbiter) and was rather impressed to see that I could calculate a vector for a 1400x1400 model in only 35ms on average. Tides in practice are simply variable harmonic coefficients, but I don't understand that well enough to impliment it yet.

My motivation for doing this is very NASSP-centric, @indy91 has a proof-of-concept plugin that wrote for the moon using the Boeing R2 model (used by the AGC). But in addition to NASSP, it would be awesome to get long-term simulation agreement between GMAT and Orbiter.

The form that this is in, is probably not what we'd want eventually. I envision it more like the atmosphere models, which are modules, and are a little easier to work with from a user standpoint. My code also has an ugly <const_cast>, but doing that also changed the least amount of things...

Next goal is to compare Orbiter with this feature against GMAT, under the same initial conditions and integrator settings (or as close as possible).

 

[Ajaja]

And we also need better rotation models for celestial bodies. Maybe like the atmosphere models and/or like an extension of CELBODY class.

 

[Boxx]

My motivation for doing this is very NASSP-centric, @indy91 has a proof-of-concept plugin that wrote for the moon using the Boeing R2 model (used by the AGC). But in addition to NASSP, it would be awesome to get long-term simulation agreement between GMAT and Orbiter.

I don't get the point with GMAT (but I don't know "NASSP", sorry). Is it a question of Moon model or of benchmarking with an external propagator that could receive spherical harmonic models?....

 

[n72.75]

I don't get the point with GMAT (but I don't know "NASSP", sorry). Is it a question of Moon model or of benchmarking with an external propagator that could receive spherical harmonic models?....

The point of verifying with GMAT, is that GMAT is very likely to be right. My code is less likely. If they produce the same results, I'm probably not wrong.

 

[Boxx]

ok, then no need for an agreement.... You only need an access to a propagator and how to implement spherical harmonics. Do you have that?

we also need better rotation models for celestial bodies

complex rotation models for celestial bodies are needed for (very) long term propagation, no?

 

[n72.75]

NASSP is an addon for Orbiter that simulates the Apollo missions and hardware, including an emulation of the AGC/AGS and a bunch of RTCC functions: https://github.com/orbiternassp/NASSP

And yes, you are correct, comparing the results of my non-spherical perturbations against a known, accurate propagator is my goal, not GMAT specifically.

 

[Ajaja]

complex rotation models for celestial bodies are needed for (very) long term propagation, no?

I wouldn't say so.
I did some calculations and compared the current rotation model in Orbiter with IAU and ITRF93 models ( https://www.orbiter-forum.com/threads/orbiter-and-earth-rotation.40260/ ) , and for some celestial bodies it doesn't seem as a good enough approximation even for short terms.

 

[n72.75]

Hey, my 35x32 km Orbit isn't looking quite so 35x32 any more...





Just a teaser. I have a loooooot of testing and polishing left to do.

 

[Ajaja]

How did you implement this changes?
I thought about making minimal changes to the Orbiter core, just interfacing GetPertAcc() to celbody modules through a CELBODY class extension.
But I'm not very good with C++ to propose my changes to the Orbiter core.

 

[n72.75]

How did you implement this changes?
I thought about making minimal changes to the Orbiter core, just interfacing GetPertAcc() to celbody modules through a CELBODY class extension.
But I'm not very good with C++ to propose my changes to the Orbiter core.

That's pretty much how I'm doing it.

Comparing orbitersim:main...n7275:tesseralGravity · orbitersim/orbiter

Open-source repository of Orbiter Space Flight Simulator - Comparing orbitersim:main...n7275:tesseralGravity · orbitersim/orbiter

github.com

 

[n72.75]

After some much-needed help and feedback from my NASSP colleague, the one and only: @indy91

Now we're not violating any conservation of energy rules.



Mind your muls and tmuls, kids, and your right and left-handedness.

This is what 2 days of sitting in an 35x35km orbit, launched on a 90° heading from Brighton Beach looks like. Good rescue-mission potential here.

OrbitMFD looks like it's driving over a bumpy road.

 

[Ajaja]

Looks good. Can you give the scenario file or just initial MJD/RPOS/RVEL? I want to compare this with GMAT.

That's how it looks in GMAT (using LP-165 model) for arbitrary MJD:

Spoiler: Show/Hide

 

[n72.75]

Sure. I was using a a cutoff of 120th order/degree.

 

[Ajaja]

Looks close:

 

[n72.75]

Well that's very promising.

I ran this using the default Orbiter propagators at 100x (variable time step length). So there's probably a lot of RK2 and RK4 errors accumulated here. I can try it again on RK8 with a fixed step length.

 

[Ajaja]

It depends on model. With GRGM900C GMAT shows even a bit slower orbit degrade rate with the same 120th order/degree: