search

brandon-rhodes / python-jplephem

Python version of NASA DE4xx ephemerides, the basis for the Astronomical Alamanac
MIT License
111 stars 29 forks source link

Can handle de438t.bsp correctly? #40

Closed pdh0710 closed 4 years ago

pdh0710 commented 4 years ago

(Please excuse my English. This is a question for this project. If there is a better place for this questions, please let me know.)

I found most recent JPL ephemeris DE438t.bsp(SPK file) from ftp://ssd.jpl.nasa.gov/pub/eph/planets/bsp/. jplephem seemed to handle the DE438t.bsp well, opened well and computed heliocentric coordinates of planets well. However I could not know whether jplephem handles DE438t.bsp correctly.

The DE438t ephemeris has 2 differences compared to other JPL ephemeris.

  1. 'TT-TDB' values are integrated. ( ftp://ssd.jpl.nasa.gov/pub/eph/planets/bsp/README.txt )
  2. Uses 576 ephemeris constants, which exceeds the prior maximum number allowed. ( ftp://ssd.jpl.nasa.gov/pub/eph/planets/ascii/de438t/README.txt )

Can jplephem handle DE438t.bsp correctly, despite above two differences?

brandon-rhodes commented 4 years ago

This is an okay place to ask questions if the documentation does not make something clear. Is there somewhere I could update the documentation so you would not have needed to worry about compatibility with the new ephemeris?

If there were any error you would see an exception displayed when the ephemeris were loaded. If the new ephemeris loads without an exception on your system then there is no error.

Note that your item #1 is true of every ephemeris back to "de430" — the note about it in the readme is dated "15 January 2014", six years ago.

pdh0710 commented 4 years ago

( Sorry. I don't know the good place for the documentation)

Oh, that's too good. However, I wish I had more precise information.

As far as I know, DE438 has more ephemeris constants for calculating planet coordinates more accurately. If jplephem ignores some newly added ephemeris constants, the precision of calculation would be reduced. I wonder how jplephem can recognize and use the newly added ephemeris constants correctly, without modifying the source codes.

brandon-rhodes commented 4 years ago

If jplephem ignores some newly added ephemeris constants, the precision of calculation would be reduced.

I don't see how that could be the case. Could you provide an example? Which constant are you thinking of, and how large an effect does it have if ignored?

pdh0710 commented 4 years ago

I don't know DE438t data deeply. I just wish jplephem produce more accurate calculations, if I use more precise ephemeris data.

What I know is that jplephem calculates different coordiantes when using DE430 and DE438t. Unfortunately, I have only 2018 Astronomical Almanac(published 2017). Thus I think my Almanac is not suitable for verifying jplephem calculation using DE438t. Because DE438t ephemeris was posted 2018.03.30. ( ftp://ssd.jpl.nasa.gov/pub/eph/planets/bsp/ )

brandon-rhodes commented 4 years ago

What I know is that jplephem calculates different coordiantes when using DE430 and DE438t.

That might simply be because DE438t is more accurate than DE430. Usually, every new ephemeris produces more accurate numbers, that are a little different from the previous ephemeris.

What number is jplephem producing from DE438t that worries you? How different is it from the number in the Astronomical Almanac? I am surprised that it is producing a number different enough from the Almanac to be noticeable — I had thought that Solar System object positions were now known to within a few hundred meters, and that ephemeris updates were at this point only relevant for missions actually trying to land on planetary surfaces.

I am interested in seeing your numbers. Thanks!

pdh0710 commented 4 years ago

As I read your answer, I realized again the verification of calculation is very important. So I will order Astronomical Almanac 2020. Do you have any recommendation for verifying calculation of heliocentric coordinates of planet?

brandon-rhodes commented 4 years ago

As I read your answer, I realized again the verification of calculation is very important. So I will order Astronomical Almanac 2020.

Instead of ordering the Almanac, you could also try using SpiceyPy which would generate a position using the new ephemeris, and you could compare the numbers directly. Though maybe it's harder to use? https://spiceypy.readthedocs.io/en/master/

Do you have any recommendation for verifying calculation of heliocentric coordinates of planet?

I usually generate numbers using the JPL HORIZONS and compare them to my own program.

I am still interested in seeing the different coordinates you are getting from the old ephemeris and the new one.

pdh0710 commented 4 years ago

I tested JPL HORIZONS and SpiceyPy.

JPL HORIZONS uses DE431 ephemeris. JPL HORIZONS and jplephem with DE431t ephemeris calculate almost same coordinates. So it is not suitable for verifying calculations using DE438t ephemeris.

SpiceyPy and jplephem calculate same coordinates for DE438t ephemeris. However, when I tried SpiceyPy to use DE431t ephemeris for comparison, SpiceyPy made an error. The size of de431t.bsp is about 3.4GB. I think SpiceyPy may have a problem handling a large SPK file.

brandon-rhodes commented 4 years ago

SpiceyPy and jplephem calculate same coordinates for DE438t ephemeris.

Excellent! If jplephem produces the same coordinates as the NASA software, then it is operating as intended. I will close this issue, as your question is now answered. Thank you for using SPICE to do a test.

If you have any further questions about the numbers you are getting back, feel free to comment further.