# DiscussionImproved (Tesseral) Gravity Model

#### n72.75

Tutorial Publisher
Donator
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

##### Not funny anymore
Donator
Yeah, that could make the effect of the mascons more pronounced.

#### N_Molson

Donator
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

##### Active member
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

Tutorial Publisher
Donator
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

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

#### Boxx

Donator
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

Tutorial Publisher
Donator
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

Donator
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

Tutorial Publisher
Donator
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.

#### n72.75

Tutorial Publisher
Donator
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

##### Active member
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.

Last edited:

#### n72.75

Tutorial Publisher
Donator
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.

#### n72.75

Tutorial Publisher
Donator
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.

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

##### Active member
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:

Last edited:

#### n72.75

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

#### Attachments

• Test.scn.txt
3.1 KB · Views: 4

Looks close:

#### n72.75

Tutorial Publisher
Donator
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

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

Replies
0
Views
207
Replies
0
Views
291
Replies
11
Views
867
Replies
11
Views
1K
Replies
180
Views
8K