Asteroid 2013 TX68 March 5, 2016 close approach, and calculating with Skyfield

This NASA webpage describes the close approach of asteroid 2013 TX68 on March 5, 2016 and shows a probability distribution of the point of closest approach based on the only data available at this moment - three or four days of measurements in October of 2013.

Screenshot (Feb 5, 2016) from [http://ssd.jpl.nasa.gov/sbdb.cgi?sstr=2013%20TX68;orb=1] which I found here.

I tried to load DE431 into Skyfield out of curiosity to see if I can learn how to use these kinds of solutions (which can include substantial uncertainty sometimes) but I was stopped immediately by an error shown below.

Question: How to handle this error? And, more broadly, how to start using orbital solutions of asteroids in Skyfield?

>>> data421 = load('de421.bsp')  # this worked
>>> data431 = load('de431.bsp')  # few seconds delay, and then:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Users/yournamehere/anaconda2/anaconda/envs/myenv/lib/python2.7/site-packages/skyfield/iokit.py", line 43, in load
raise IOError('cannot get {1} because {2}'.format(url, e))
IndexError: tuple index out of range

• The error indicates that the data is not in a format expected by the program. So you'd have to find out what data format Skyfield expects. – Hobbes Feb 6 '16 at 11:42
• @Hobbes Skyfield reads many NASA ephemerides (DExxx) but not this one which surprised me, and that's only the first part of the question. – uhoh Feb 6 '16 at 11:49
• You can try pinging Brandon on github (github.com/skyfielders/python-skyfield) he's pretty good at responding. Obvious suggestions: 1) what happens if you load JUST de431.bsp without de421.bsp first? The only de431.bsp I have is in two parts. Are you using a combined version? Is your de431.bsp the right size, fully downloaded, etc? – user7073 Feb 6 '16 at 16:02
• Thanks @barrycarter - same error even if I try de431 first. I poked around and found DE431 is quite large, there may have been a space issue I'll check that. The "two parts" sounds like it might be what the error message is talking about. I'll try to ping him (I'm not active there, will have to remember how) so far he seems to find my questions sooner or later. Maybe this is a case where I should try to use the Horizons system. – uhoh Feb 6 '16 at 16:32
• If you just need positions at fixed times, Horizons is the way to go. If you want to actually compute a trajectory, I'm not sure DE431 would have this, but you could combine it with asteroid data perhaps. Feel free to ping me directly (see profile) and then post the results here if we find anything. – user7073 Feb 6 '16 at 17:13

Although the universe does revolve around me, I'm assuming you meant the barycentric celestial reference system :)

HORIZONS will give you these elements if you use these settings:

• Excellent! I will give these a try and update. Thanks!! – uhoh Feb 7 '16 at 3:14

Asteroid TX 68 2013 will pass near the earth on March 5 , 2016

• I like your video, thank you for the link! Is that using NASA solar system dynamics? Maybe you could post a link that opens ssd with the asteroid loaded? Also, is that "lens flair" above the earth at 1:54? And watching from 1:57 to 1:59, the asteroid path (white line) on the left side of the screen changes to a strange shape - sort of folds over the earth orbit. Is it real? What is happening? – uhoh Feb 7 '16 at 17:22

The error IndexError: tuple index out of range is simply because I mistyped the two indexes in the error message in that source file. Python is zero-indexes so I ought to have typed:

IOError('cannot get {0} because {1}'.format(url, e))


Instead, as you can see, I seem to have produced the utterly wrong:

IOError('cannot get {1} because {2}'.format(url, e))


This fix will be in the next version of Skyfield (and thanks for pointing out the problem you ran into!). You can edit the source file by hand for now if you want to see the error message which your code is trying to print, which is:

OSError: cannot get ftp://ssd.jpl.nasa.gov/pub/eph/planets/bsp/de431.bsp ...


The problem is that no de431.bsp exists in that directory:

ftp://ssd.jpl.nasa.gov/pub/eph/planets/bsp/

Maybe you intended to name the de431t.bsp file? (In which case you must have more disk space free than I do — it’s 3.4 GB in size!)

Given that the asteroid approach is in 2016, you can use the much smaller DE430 ephemeris. And unless you are trying to predict its location to within, say, 1 meter, you should be able to use the much smaller ephemerides DE421 or DE405 without any problem.

Do you have a source for an ephemeris for the asteroid? Or will you be wanting to produce one from orbital elements?

• Thanks for stopping by! Yes it took me a day to realize that - for practical purposes of 10's of km - the choice of ephemeris is not connected to the asteroid's orbital elements. I'm one of those people who practically lives in python, so I'd like to either auto-load or just copy/paste the orbital elements into a skyfield script and use either tx68.at(jd).position.km for (x, y, z) coordinates of tx68 in BCRS, or here.at(jd).observe(tx68).apparent().altaz() to get apparent position in the sky. – uhoh Feb 8 '16 at 7:35
• And indeed I would have hit the disk space limit as well had it started! – uhoh Feb 8 '16 at 7:45