General Question How to get planet position at certian time

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
This is going a little off-topic, but anyway, I made DE405 ephemeris implementation about 8 years ago and I checked it against JPL-Horizon web service and they are exact match. So, maybe we could place an other moon up there and see how much they deviate. One problem is that DE405 uses ICRF-J2000 reference frame which is a little off from the EME-J2000. Unfortunately the conversion between ICRF and EME goes over my head. I guess it wouldn't hurt to have oapi call for the conversion. Also, I need to find out if the DE405 data files can be redistributed.

Would this be a valid approach ?

Yes, this might provide a good validation. The VSOP87 and ELP82 solutions are a bit dated now (and in some cases I am even truncating the series early in the interest of performance), so it would be interesting to see how it stands up to a more modern solution.

One of the advantages of VSOP is its speed, which is important in a time-critical application where potentially a large number of bodies need to be processed. So ultimately we might need to find the best tradeoff between accuracy and performance.

Do you think you could write an alternative Moon.dll using the DE405 solution for comparison?
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,605
Reaction score
2,327
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
It would make things little more interesting not knowing for sure if the vessel really is where a nav-computer thinks it is and getting too close to a planet by surprise as result. :lol: I just don't know how to implement one without braking a lot of things in a process.

Well, too much restrictions on what an add-on module can know could also become contra-productive. Without some easy to use framework to get such knowledge into an add-on (like the Orbiter API is in such cases), we would have quite many add-on projects failing because too much knowledge is expected from the developer.

Of course, it would also encourage cooperation of various experts, ideally in open-source projects. But I would right now prefer it to be voluntarily, not mandatory. :tiphat:
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,666
Reaction score
795
Points
128
Do you think you could write an alternative Moon.dll using the DE405 solution for comparison?

Yes, I already wrote a generic module that should work with all planets. At-least, it seems to be working fine with the Moon. When comparing the DE405 implementation to DE431 from JPL Horizon, the position seems to be accurate within 10m where as the VSOP is drifting off by 40km. Velocity error of 0.1 m/s is common between the two.

I noticed some anomalies where the velocity difference spiked up to 7 m/s and distance deviation of 10e6 meters. Scenario restart cleared the anomaly.
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
I did a quick check and it seems that by default the ELP82 solution for the moon doesn't use all terms of the series expansion. You could try to edit Config\Moon.cfg and reduce the "ErrorLimit" parameter from 1e-5 to 1e-8 (which I think is the maximum) and see if that makes any difference to the deviation from your results.

I guess these days PCs running orbiter can be expected to be powerful enough to cope with computing the full series, so I should probably remove the early truncations for all planets and moons.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,666
Reaction score
795
Points
128
You could try to edit Config\Moon.cfg and reduce the "ErrorLimit" parameter from 1e-5 to 1e-8 (which I think is the maximum) and see if that makes any difference to the deviation from your results.

If the error limit is reduced to 1e-4 then the error will increase by 300%
If the error limit is increased to 1e-8 or above the deviation is only reduced down to 80% so practically it has no effect.

Evaluation of position and velocity for the Moon using DE405 takes about 1.6us @ 3.2GHz and that's the heaviest one to compute. I don't know how the Orbiter works but LTMFD assumes a linear movement for distant bodies during an integration of a time step. So, no performance problems there. I don't know how long the ELP82 takes to compute.

---------- Post added 10-03-17 at 01:07 ---------- Previous post was 09-03-17 at 23:36 ----------

I hooked a performance timer to a low level routine in LTMFD to measure the execution time of clbkEphemeris and here are the results. MoonX is the one run by DE405, others are using the default ephemerides at default ErrorLimit.

Code:
Ver=2 EphemTime = 33.202us, body=Sun
Ver=2 EphemTime = 10.860us, body=Mercury
Ver=2 EphemTime = 10.860us, body=Mercury
Ver=2 EphemTime = 5.895us, body=Venus
Ver=2 EphemTime = 5.585us, body=Venus
Ver=2 EphemTime = 150.806us, body=Earth
Ver=2 EphemTime = 150.496us, body=Earth
Ver=2 EphemTime = 12.722us, body=Moon
Ver=2 EphemTime = 1.551us, body=MoonX
Ver=2 EphemTime = 12.722us, body=Moon
Ver=2 EphemTime = 1.552us, body=MoonX
Ver=2 EphemTime = 13.033us, body=Moon
Ver=2 EphemTime = 12.102us, body=Moon
Ver=2 EphemTime = 1.241us, body=MoonX
Ver=2 EphemTime = 0.931us, body=MoonX
Ver=2 EphemTime = 55.543us, body=Mars
Ver=2 EphemTime = 24.824us, body=Mars
Ver=1 EphemTime = 4.034us, body=0xF4A1860
Ver=1 EphemTime = 2.482us, body=0xF4A1860
Ver=1 EphemTime = 2.793us, body=0xF4A1900
Ver=1 EphemTime = 2.793us, body=0xF4A1900
Ver=2 EphemTime = 98.365us, body=Jupiter
Ver=2 EphemTime = 97.434us, body=Jupiter
Ver=2 EphemTime = 6.516us, body=Io
Ver=2 EphemTime = 5.896us, body=Io
Ver=2 EphemTime = 8.378us, body=Europa
Ver=2 EphemTime = 8.378us, body=Europa
Ver=2 EphemTime = 10.550us, body=Ganymede
Ver=2 EphemTime = 9.930us, body=Ganymede
Ver=2 EphemTime = 12.102us, body=Callisto
Ver=2 EphemTime = 12.102us, body=Callisto
Ver=2 EphemTime = 174.699us, body=Saturn
Ver=2 EphemTime = 173.147us, body=Saturn
Ver=2 EphemTime = 1.241us, body=Mimas
Ver=2 EphemTime = 13.964us, body=Mimas
Ver=2 EphemTime = 0.931us, body=Enceladus
Ver=2 EphemTime = 9.930us, body=Enceladus
Ver=2 EphemTime = 0.931us, body=Tethys
Ver=2 EphemTime = 11.792us, body=Tethys
Ver=2 EphemTime = 0.620us, body=Dione
Ver=2 EphemTime = 10.550us, body=Dione
Ver=2 EphemTime = 0.621us, body=Rhea
Ver=2 EphemTime = 10.861us, body=Rhea
Ver=2 EphemTime = 0.621us, body=Titan
Ver=2 EphemTime = 12.413us, body=Titan
Ver=2 EphemTime = 0.931us, body=Iapetus
Ver=2 EphemTime = 37.546us, body=Iapetus
Ver=2 EphemTime = 107.674us, body=Uranus
Ver=2 EphemTime = 108.294us, body=Uranus
 
Last edited:

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,666
Reaction score
795
Points
128
I made one more test regarding the ephemeris issue with the IMFD. I set two different scenarios leading to pro- and retrograde lunar flyby and tested them with the ELP82 and DE405 moon data. The propagated flight time was 60h from predicted fly-by to actual fly-by.

a) With DE405 the deviation was 300m in both test scenarios, this is obviously the limit of IMFD.
b) With the ELP82 enabled at 1-e5 the deviation was 6km and 8km
c) With the ELP82 enabled at 1-e8 the deviation was 300m :cheers:

So, obviously the ErrorLimit effects in stability of pos/vel pair making trajectory predictions more stable even if the position is still 40km off from the DE405 position.
 

wisaac407

New member
Joined
Jan 4, 2017
Messages
4
Reaction score
0
Points
0
I'd understand it as a feature that answers the question "where do I point a torchship at if travel time to Mars is 2 weeks?" or something along that line.

Yes, that's exactly what it's used for

Dr Keith Gelling described a 4th Order Symplectic Integrator to do just such a calaculation, and I am currently working on an app (Lagrange MFD) that implements this code. You are welcome (with attribution to both Keith and me) to look at the current alpha source in www.github.com/ADSWNJ and clone what you need. (Or ... wait a few weeks for the v1.0 version and then you'll have a stable platform to work from.)

Thank you! Is the relavent code loacated in Lagrange/LagrangeUniverse.cpp?
 

wisaac407

New member
Joined
Jan 4, 2017
Messages
4
Reaction score
0
Points
0
Thanks for all the replies everyone! Sorry for the late response, I've been pretty busy.
You are welcome (with attribution to both Keith and me) to look at the current alpha source in www.github.com/ADSWNJ and clone what you need. (Or ... wait a few weeks for the v1.0 version and then you'll have a stable platform to work from.)

Thank you! Were should I start? Lagrange/Lagrange_Universe.cpp?

Try the KOST library, which performs a 2-body calculation:

Is that good enough to predict the position of the moon? (or any moon for that matter)

I'd understand it as a feature that answers the question "where do I point a torchship at if travel time to Mars is 2 weeks?" or something along that line.

Yes, that's exactly what it's for :)
 
Top