General Question Quality of planet orbits with EllipticOrbit = FALSE

[Linguofreak]

First off, do config file questions belong in the SDK forum?

Secondly, how precise can I count on planet trajectories being with EllipticOrbit = FALSE, and is there anything I can do to improve accuracy?

I'm trying to implement a system I created with GravitySimulator in Orbiter. The System consists of a 5 Jupiter mass object at 1 AU from a star identical to the Sun with two 1 earth mass objects in tadpole orbits around either of its trojan points. The leading Trojan oscillates around its point by about 10 degrees toward the Jovian and 15 degrees away, and the trailing Trojan by about 25 degrees toward the Jovian and 35 or 40 degrees away from it. I ran the system for a bit more than a million orbits in GravitySimulator to be sure of its stability. At the epoch I'm implementing in Orbiter, both Trojans are heading away from the Jovian and continue until they are separated from each other by around 175 degrees, at which point they both start drifting back towards it. About two years after the epoch the leading Trojan is about 55 degrees ahead of the Jovian and the trailing Trojan is 65 degrees behind it. In Orbiter, however, the Trojans overshoot the points at which they turn around in GravitySimulator (this was tested at 100000x time accel in Orbiter), and by two years after the epoch they're separated from the Jovian and each other by roughly 120 degrees and the Orbit of the leading Trojan is still shrinking while that of the trailing Trojan is widening (so there's no sign that they'll start closing on the Jovian any time soon).

Do I have any chance at getting the Trojans to oscillate around their Trojan points with EllipticOrbits = FALSE, or will I have to write a module?

Config file for the Jovian:

Name = Jovian
EllipticOrbit = TRUE
HasElements = TRUE
ErrorLimit = 1e-8
SamplingInterval = 79

Mass = 9.4109208e+27
Size = 7.5993e+7
JCoeff = 0.01475
AlbedoRGB = 2.02 1.99 1.86

Epoch = 2013
SemiMajorAxis = 149117727716
Eccentricity = 0.014305781741446
Inclination = 1.37129793e-5
LongAscNod = 4.70275839
LongPerihelion = 2.13317055
MeanLongitude = 6.16310709

LAN = 0
LAN_MJD = 51544.5
Obliquity = 0.05443758224
SidRotPeriod = 13500.3
SidRotOffset = 2.547801285

AtmPressure0 = 201.4e4
AtmDensity0 = 1.3293
AtmGasConstant = 194.92
AtmGamma = 1.3333
AtmColor0 = 0.37 0.35 0.39
AtmHazeColor = 0.21 0.1 0.1
AtmHazeDensity = 0.09
AtmHazeExtent = 0.055
AtmHazeShift = 0.009

CloudAlt = 480e3
CloudRotPeriod = 35727.3
CloudShadowDepth = 0.8
CloudMicrotextureAlt = 1535e3 6440e3

MaxPatchResolution = 7
MinCloudResolution = 1
MaxCloudResolution = 7

The config files for the Trojans are identical to the stock Earth config file, except for the lines shown here.

Config for the trailing Trojan:

; === Configuration file for planet Earth ===

Name = Terr1

EllipticOrbit = FALSE

HasElements = TRUE

ErrorLimit = 1e-12

SamplingInterval = 79          ; interpolation sampling interval [s]

                               ; (interpolation error ~0.1m)

; === Physical Parameters ===

Mass = 5.973698968e+24

;Size = 6.378165e6             ; equatorial radius

Size = 6.37101e6               ; mean radius

JCoeff = 1082.6269e-6 -2.51e-6 -1.60e-6 -0.15e-6

                               ; harmonic coefficients for shape description

AlbedoRGB = 0.7 0.85 1.0



Epoch = 2013

SemiMajorAxis = 151666908317

Eccentricity = 0.055527958474648

Inclination = 0.0135932433

LongAscNode = 4.89449553

LongPerihelion = 1.56514019

MeanLongitude = 4.59806802

Config file for the leading Trojan:

; === Configuration file for planet Earth ===

Name = Terr2

EllipticOrbit = FALSE

HasElements = TRUE

ErrorLimit = 1e-12

SamplingInterval = 79          ; interpolation sampling interval [s]

                               ; (interpolation error ~0.1m)

; === Physical Parameters ===

Mass = 5.973698968e+24

;Size = 6.378165e6             ; equatorial radius

Size = 6.37101e6               ; mean radius

JCoeff = 1082.6269e-6 -2.51e-6 -1.60e-6 -0.15e-6

                               ; harmonic coefficients for shape description

AlbedoRGB = 0.7 0.85 1.0



Epoch = 2013

SemiMajorAxis = 147958168248

Eccentricity = 0.065617383576729

Inclination = 0.00514650812

LongAscNode = 3.66597131

LongPerihelion = 2.02585275

MeanLongitude = 1.05634252

Gsim file for the system in GravitySimulator:

<GrAVITY>

<Distance Boxes>

</Distance Boxes>

<Orbit Boxes>

 

 3045 

 2385 

Terrestrial 8

Object 1

 3 

 1 

</Orbit Boxes>

<SData>

 1.15610199438884E-09 

 33250860475915.5 

 1 

 3.00285301173073E-11 

-4.32725037507886E-12 

 1 

 4 

False

False

 0 

-10000 

E:\DeadEmaine\Program Files\Gravsim\simulations\doubletrojan.gsim

True

 31389811.5011919 

True

 0 

 2 

-60 

-60 

 24120 

 12960 

True

False

 1 

 1 

True

False

True

True

E:\DeadEmaine\Program Files\Gravsim\simulations

E:\DeadEmaine\Program Files\Gravsim\simulations\doubletrojan.gsim

False

 0 

 0 

 0 

 0 

False

 119.3333 

 16777215 

 16 

 408 

</SData>

<Command Buttons>

 690 

 0 

 1350 

 0 

 2010 

 0 

 2670 

 0 

 3330 

 0 

</Command Buttons>

<Captions>



MS Sans Serif

 12 

 16711680 

False

False

False

False

 0 

 0 

 1 

 1 



MS Sans Serif

 13.5 

 255 

False

False

False

False

 0 

 0 

 1 

 1 



MS Sans Serif

 8.25 

 65280 

False

False

False

False

 0 

 0 

 1 

 1 



MS Sans Serif

 8.25 

 16711680 

False

False

False

False

 0 

 0 

 1 

 1 

</captions>

<Thrust Box>

</Thrust Box>

<Objects>

 

Floating

 0 



 0 

 0 

-48398442931005 

 5491501356101.79 

-1549333677.1444 

-1.46228472708215 

 0.165917290433236 

-4.68107410006768E-05 

-1048576 

-128 

 0 

 0served for future use

Reserved for future use

Reserved for future use

Reserved for future use

 

Object 1

 332983.460559796 



 65535 

 1392000000 

 3.64074573429517E-02 

-5.24646383959209E-03 

 3.66581650849023E-07 

 1.40028720232041E-03 

-2.01784780088946E-04 

 1.40993054642991E-08 

 0 

 0 

 0 

 0served for future use

Reserved for future use

Reserved for future use

Reserved for future use

 

Jovian

 1575.41864202491 

Object 1

 16711935 

 120110633.238052 

 148943463300.899 

-21471672307.1378 

 2045200.42937539 

 3905.43514532538 

 29373.6917620559 

 4.96732941648823E-02 

 0 

 0 

 0 

 0served for future use

Reserved for future use

Reserved for future use

Reserved for future use

 

Terrestrial 8

 1 

Object 1

 65280 

 12600000 

-16621544525.7325 

-159176478813.551 

-614096625.803131 

 27820.4455190058 

-3069.06731031546 

 364.382562354402 

 0 

 0 

 0 

 0

Reserved for future use

Reserved for future use

Reserved for future use

 

Terrestrial 9

 1 

Object 1

 16744448 

 12600000 

 84086135667.4852 

 115583102155.101 

-298257986.5914 

-26041.1399342542 

 16791.9516665965 

-141.91035644207 

 0 

 0 

 0 

 0

Reserved for future use

Reserved for future use

Reserved for future use

</Objects>

<Auto Pilot>

 0 

</Auto Pilot>

</GrAVITY>

 

[jedidia]

Secondly, how precise can I count on planet trajectories being with EllipticOrbit = FALSE, and is there anything I can do to improve accuracy?

The problem is that they are treated as dynamic bodies, if I'm not mistaken. Which means they'll probably be pretty stable at norm-time, but long periods of high time acceleration can seriously mess them up.

You could write a module for them, but I never worked with that particular aspect of Orbiter, so I can't give you any help there.

 

[Linguofreak]

The problem is that they are treated as dynamic bodies, if I'm not mistaken.

Yes, that's the intention.

Which means they'll probably be pretty stable at norm-time, but long periods of high time acceleration can seriously mess them up.

I hadn't thought it would be a huge issue given that even 100000x time accel in Orbiter is generally a smaller timestep than I was using to test for stability in GS.

 

[martins]

One of the problems of dynamic state propagation of celestial bodies is that the orbital elements need to be mapped from the reference epoch to the simulation start time. This is not done by numerical integration at the moment. The elements are mapped to the simulation start time simply with a 2-body approach (i.e. only the mean anomaly changes). This means that the elements will become less accurate the further the simulation start time is away from the element reference time, in particular if the orbits are strongly perturbed. Realistically, you need to start the simulation at the reference time and then fast forward to your intended simulation start.

I haven't used dynamic celestial body updates in the standard orbiter distribution for quite a long time for that reason. So it's possible that bugs have crept in. Let me know if you come across problems.

 

[Linguofreak]

One of the problems of dynamic state propagation of celestial bodies is that the orbital elements need to be mapped from the reference epoch to the simulation start time. This is not done by numerical integration at the moment. The elements are mapped to the simulation start time simply with a 2-body approach (i.e. only the mean anomaly changes). This means that the elements will become less accurate the further the simulation start time is away from the element reference time, in particular if the orbits are strongly perturbed. Realistically, you need to start the simulation at the reference time and then fast forward to your intended simulation start.

I was pretty sure that was the case, so I set my scenario to start at my epoch (Jan 1 2013). The planets are all in the correct positions at the beginning of the scenario, but their subsequent movement doesn't match what I'm seeing in GS.

I haven't used dynamic celestial body updates in the standard orbiter distribution for quite a long time for that reason. So it's possible that bugs have crept in. Let me know if you come across problems.

Why not ditch in-sim dynamic updates entirely and replace them with a tool that does an n-body simulation for a couple hundred/thousand/million orbits and uses it to generate an ephemeris module? If such a tool existed I wouldn't be trying to use dynamic updates. (Actually, it would probably be simpler to write a single module that would take a file with ephemeris data as input than to have your tool generating a dll every time you run it, but the general concept is the same).

 

[martins]

Why not ditch in-sim dynamic updates entirely and replace them with a tool that does an n-body simulation for a couple hundred/thousand/million orbits and uses it to generate an ephemeris module? If such a tool existed I wouldn't be trying to use dynamic updates. (Actually, it would probably be simpler to write a single module that would take a file with ephemeris data as input than to have your tool generating a dll every time you run it, but the general concept is the same).

Actually that's a good idea. I've been thinking about the same thing for some time but never got around to work on it. Have a standalone numerical simulator for celestial body orbit calculation as a forward model, and use it to fit the coefficients of a semi-analytic solution (e.g. a power series expansion of the state vectors). The coefficients could then be read by a generic celestial body dll (similar to the current setup for VSOP87 bodies) to drive the state updates.

The only problem with this is that "interesting" (i.e. heavily perturbed) orbits will require a very high order expansion and will work only for a very limited period of time before diverging.

Still, it's an interesting project, and if some volunteer could be found to work on this, I would be very grateful. It's unlikely that I will be able to work on this anytime soon. Any takers? What about it, Linguofreak?

 

[Linguofreak]

Actually that's a good idea. I've been thinking about the same thing for some time but never got around to work on it. Have a standalone numerical simulator for celestial body orbit calculation as a forward model, and use it to fit the coefficients of a semi-analytic solution (e.g. a power series expansion of the state vectors). The coefficients could then be read by a generic celestial body dll (similar to the current setup for VSOP87 bodies) to drive the state updates.

The only problem with this is that "interesting" (i.e. heavily perturbed) orbits will require a very high order expansion and will work only for a very limited period of time before diverging.

One thing that strikes me is that most scenarios set in any given system will likely be within a few hundred years of each other. so it might be workable just to make a 500 year recording of a simulator run, then have a module that plays such recordings back.

Still, it's an interesting project, and if some volunteer could be found to work on this, I would be very grateful. It's unlikely that I will be able to work on this anytime soon. Any takers? What about it, Linguofreak?

I doubt I have the mathematical knowledge required. I'm fairly certain I could gain said knowledge, but now is not really a good time for me to do so.