Error when opening de405.bsp

[astrojuanlu]

I wanted to cross-check the results with the ones that the web interface of HORIZONS provides, but I am unable to open the file with jplephem:

>>> from jplephem.spk import SPK
>>> SPK.open("/home/juanlu/.poliastro/de405.bsp")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/juanlu/.miniconda3/envs/gtoc8/lib/python2.7/site-packages/jplephem/spk.py", line 46, in open
    return cls(open(path, 'rb'))
  File "/home/juanlu/.miniconda3/envs/gtoc8/lib/python2.7/site-packages/jplephem/spk.py", line 39, in __init__
    self.daf = DAF(file_object)
  File "/home/juanlu/.miniconda3/envs/gtoc8/lib/python2.7/site-packages/jplephem/daf.py", line 30, in __init__
    .format(self.locidw, b'DAF/'))
ValueError: file starts with 'NAIF/DAF', not the 4 bytes 'NAIF/DAF'

By the way, it is totally unrelated but I tried to checksum the file and did not found that info online. Are you aware of a public checksum list for SPK files?

[astrojuanlu]

Plus, there is a typo in the line:

raise ValueError('file starts with {0!r}, not the 4 bytes {0!r}'

should be

raise ValueError('file starts with {0!r}, not the 4 bytes {1!r}'

[brandon-rhodes]

Interesting! I have never tried to open an old 1990s ephemeris before. I have done a bit of digging, and it does look like that NAIF/DAF code at the beginning of the file was indeed the magic number for an old version of one of these ephemerides:

http://naif.jpl.nasa.gov/pub/naif/toolkit_docs/C/req/kernel.html#SPICE Kernel Type Identification

I wonder if the old data will still be recognized and processed? I will try it out!

[brandon-rhodes]

I tried asking jplephem to read the file anyway, but it does not seem to know where to find any of the binary data inside that would help it understand what segments the DAF file is composed of, or how to access them.

If you can find documentation for this old kernel, I would welcome some help in figuring out how to get the binary format parsed and interpreted!

[astrojuanlu]

Oh, too bad! Perhaps it is a 4 byte offset, as the magic number is longer?

Still, if I manage to find further information I will get back to you!

[astrojuanlu]

Forget that, I see that you are checking just the beginning.

[astrojuanlu]

Perhaps this is useful? http://sourceforge.net/p/timeephem/timeephem/ci/f7bf6b78dc80c181a9867f70bec72f64f51d8a12/

[astrojuanlu]

(Warning: LGPLv2, in case it matters)

[brandon-rhodes]

There — I think that fixes it! If you would like to try out the code before I release the next version, just:

pip install https://github.com/brandon-rhodes/python-jplephem/archive/master.zip

and then try the following code:

from jplephem.spk import SPK
from jplephem.daf import NAIF_DAF

kernel = SPK(NAIF_DAF(open('de405.bsp', 'rb')))
print(kernel)
position = kernel[0,4].compute(2457061.5)
print(position)

If you do get the chance to try it out, let me know if it worked. Thanks!

[astrojuanlu]

Sure I will, thanks a lot! I will send you my feedback tomorrow.

[astrojuanlu]

Perfect! Now I was able to open DE405 ephemeris too. For the record, I cross-checked the results with HORIZONS but found some differences; here is the explanation:

http://astronomy.stackexchange.com/a/10548/179

[brandon-rhodes]

Great, I will go ahead and release. And feel free to take a look at Skyfield if you want to see how I myself take these jplephem results and turn them into an RA and Dec that agrees with HORIZONS.

[brandon-rhodes]

By the way, I have decided that making you use an alternative class and constructor was bad API design. I have just released version 2.3 which auto-detects which kind of SPK file you are opening and auto-adapts. Enjoy!

[astrojuanlu]

Oh, much better now, thanks! I will upload the corresponding conda package today.