Discussion Improved (Tesseral) Gravity Model

[Ajaja]

It should be recording FlightData.log every ~100 simulated seconds and there were two gaps:

...
 121789.83   170.3096
 121890.15   170.1104
 122111.46   169.8282
 122211.78   169.7923
...
 128134.28   169.9225
 128234.44   169.5184
 128771.03   168.9129
 128879.17   169.1444
...

which seemingly caused the deviation.
Maybe it just "Orbit stabilization" kicked in because of some freezes.
I will try to do more tests turning on/off this option.

 

[n72.75]

Excellent job!
I did some test and compared the new improved gravity model in OpenOrbiter with GMAT's models (even made a script for converting *.tab files to GMAT's *.cof files).
Orbiter and GMAT are very close now.
An orbit around Mars for example:
View attachment 33604


But once, only once, I got a strange issue. And wasn't able to reproduce this:
View attachment 33605

View attachment 33606

I don't know what the hell it was. I made tests in the console mode, no fuel in the ship (the script and FlightData.log in attachments), so it wasn't some misclick. I used jgmro_120f_sha.tab model.
Next test - all ok.
Any idea what it might be?

When I did my tests I locked Orbiter to using:

RK8
Fixed Timesteps at 5 seconds.
Disabled Orbit Stabilization.

Am I reading it correctly that your timesteps were around 100 second long? The right conditions may have been met for a brief moment to enable Orbit Stabilization which might have been the case. I've never seen anything like this.

You are using the 32 bit build right?

 

[Ajaja]

It was "tacc 1000" with 10 Hz in FlightData settings. Without graphics engines it gives relatively small steps < 1s and I didn't expect any problems.
Looks like the step increased due to unknown reasons and that affected precision (just huge step itself or with Orbit Stabilization).
I test both builds, x86 and x64. The problem appeared in x64.

 

[n72.75]

It was "tacc 1000" with 10 Hz in FlightData settings. Without graphics engines it gives relatively small steps < 1s and I didn't expect any problems.
Looks like the step increased due to unknown reasons and that affected precision (just huge step itself or with Orbit Stabilization).
I test both builds, x86 and x64. The problem appeared in x64.

Do you have Phobos and Diemos disabled in your 64bit session?

 

[Ajaja]

No, I use SPICE with x64. BTW, it may be a reason of the freezes. Needs investigation too.

 

[Ajaja]

I wasn't able to find file with spherical harmonic coefficients in correct format for Earth, so I made one from egm96_to360.ascii (EGM96 360x360 model) that is available on the Internet. The file is in the attachment.
Did a comparison with GMAT. Fits perfectly:

 

[n72.75]

I wasn't able to find file with spherical harmonic coefficients in correct format for Earth, so I made one from egm96_to360.ascii (EGM96 360x360 model) that is available on the Internet. The file is in the attachment.
Did a comparison with GMAT. Fits perfectly:
View attachment 33625

I can add that if you'd like, I was going to get around to making one eventually but hadn't found the time yet. Thank you for doing this!

 

[Ajaja]

I conducted more test with different orders/degrees, inclinations, altitudes. Didn't find problems. Simulates definitely much closer to GMAT than with default Orbiters' model based on JCoeffs. For example, a polar orbit with EGM96:

And the default model:

An Impressive difference.

 

[GLS]

Could you also post charts with the delta between Orbiter and GMAT? That would probably show the difference much better than the overlay (which has value, of course).

 

[Ajaja]

@GLS
I can't get the FlightData plugin to write with fixed intervals, so some additional data processing is required to calculate and plot the difference of two datasets with completely different x-values. It's just much easier to plot the data and zoom.

 

[n72.75]

@GLS
I can't get the FlightData plugin to write with fixed intervals, so some additional data processing is required to calculate and plot the difference of two datasets with completely different x-values. It's just much easier to plot the data and zoom.

I can do it in Matlab (Octave) is you send it to me.

 

[Ajaja]

@n72.75
ReportFile1.txt generated by GMAT with e4.script and FlightData.log generated from e4.scn are in the attachments.
It's the polar orbit from the graph above.
Earth atmosphere should be turned off in Orbiter to reproduce FlightData.log. I've used fixed step 1s in Orbiter this time with x1000 and 10 Hz in FlightData.
grav.py is a simple Python script to plot the graphs.

 

[n72.75]

I finally got around to adding a pull request to add this gravity model for Earth. Now all the planets and moons we have good data for have models.

I never got around to, properly calculating downrange residuals, I suspect there is a bit of a butterfly effect going on, if we're seeing sight differences between GMAT and Orbiter. Radial differences have always looked good over long periods, and it's worth noting that Orbiter and GMAT don't agree 100% even when using only point masses.

 

[n72.75]

Vesta has a cute little 20x20 SHADR model. Very fun to fly in.

View attachment 31248

If anyone was curious what this looks like through the lens of OrbitMFD:

I was just having some fun flying around Vesta and thought I'd share. Lower orbits are...interesting and "brief".

 

[Boxx]

What is interesting here is the eccentricity value: it goes down to zero and increases again, then back to zero... i.e. pulsating somehow between a circular and moderately elliptical orbit... I'm also wandering if the "kill rot" is on, because it's hard to interpret the outside view (with x1000 acceleration).

 

[n72.75]

I'm also wandering if the "kill rot" is on, because it's hard to interpret the outside view (with x1000 acceleration).

Nope, free rotation only. Rotation starting and stopping is due to oscillating gravity gradient torque.

 

[misha.physics]

Excuse me, I've just seen the new OpenOrbiter builds on github (released 5 days ago). Do I understand correctly that the ephemirides problem of x64 build isn't solved yet, so ships remain unstable on the surface/orbit of Mars, etc? Or maybe some ideas/work are in progress?

 

[n72.75]

Excuse me, I've just seen the new OpenOrbiter builds on github (released 5 days ago). Do I understand correctly that the ephemirides problem of x64 build isn't solved yet, so ships remain unstable on the surface/orbit of Mars, etc? Or maybe some ideas/work are in progress?

Stick with x86 builds for now. I have an idea on how to fix this, but I will post that in another thread.