KeyError when loading comet

Unsure if this is related to #707 but I’ve not run my comet code since then and noticed today I’m getting a KeyError when referring to a comet name. Here is sample code:

#!/usr/bin/env python3
# -*- coding: utf-8 -*-


from skyfield.api import load
from skyfield.constants import GM_SUN_Pitjeva_2005_km3_s2 as GM_SUN
from skyfield.data import mpc


url = "file://./CometEls.txt" 
# url = mpc.COMET_URL # Same result

with load.open( url ) as f:
    comets = mpc.load_comets_dataframe( f) 
    # comets = mpc.load_comets_dataframe_slow( f) # Same result

print( len( comets ), "comets loaded" )

ts = load.timescale()
ephemeris = load( "de421.bsp" )
sun, earth = ephemeris[ "sun" ], ephemeris[ "earth" ]

row = comets.loc[ "1P/Halley" ] # KeyError: '1P/Halley'
comet = sun + mpc.comet_orbit( row, ts, GM_SUN )
t = ts.utc( 2022, 5, 31 )
ra, dec, distance = earth.at( t ).observe( comet ).radec()
print( ra )
print( dec )

I get KeyError: '1P/Halley' at the line when extracting the row.

I have run pip3 install --upgrade jplephem numpy pandas skyfield and those packages are at version:

Package                Version
---------------------- --------------------
jplephem               2.17
numpy                  1.23.1
pandas                 1.4.3
skyfield               1.43.1

Running on Ubuntu 20.04.

[brandon-rhodes]

While your guess about the ‘most recent orbit’ logic is a good one, I think the actual trigger for that was a September 2020 episode in which comet NEOWISE had, temporarily, two entries in the comets data file, as mentioned in this comment:

https://github.com/skyfielders/python-skyfield/issues/449

Since we have never yet observed the MPC accidentally adding two entries for the same minor planet to the minor-planets file, the Skyfield example code doesn’t have a workaround for it. Maybe someday we could move to having a one-sized-fits-all approach where all data files get the same treatment. But in the interests of simplest-possible (and thus fastest-possible) code, the approach so far has been to apply fixes to only the files that have proved historically to have needed those fixes at least once in their history.

[Bernmeister]

One thing which has bothered me is the difference in which the dataframes between comets and minor planets are treated (prior to being calculated). This is entirely due to my inexperience of pandas/numpy which I’d not met until I started my journey from PyEpehem to Skyfield. Through sheer brute force, I am overly familiar with the file formats for each of comets and minor planets from the Minor Planet Center and have found issues with data for example which you’ve highlighted in the Skyfield documentation (for example #449).

In the documentation I’m comparing, rightly or wrongly, the comets and minor planets in terms of writing Python. I guess coming from PyEphem, I’m used to one function which takes the comet or minor planet data file and spits out the answer. I have screened (XEphem formatted) data to remove lines containing ‘****’ (#503) and missing the absolute magnitude component.

If at some stage you will put the Kepler orbit documentation page back on on the blocks, some questions which you might consider are:

• Why is printing comets, print( len( comets ), 'comets loaded' ) different to printing minor planets, print( minor_planets.shape[ 0 ], 'minor planets loaded' )?
• It took me some time to register that designation in minor_planets = minor_planets.set_index( 'designation', drop=False ) referred to mpc._MPCORB_COLUMNS. When I see these things now it is obvious; perhaps a one liner (either a comment in the example or an explicit line of text) mentioning the reference to the column names and where to find them?
• In the comets section, you mention keeping only the most recent orbit. I presumed that one line (in CometEls.txt) corresponded to one orbit and if that is the case, I’ve not seen more than one line per comet. Does (should) this also apply then for minor planets? Further to this point, in the code comets = ( comets.sort_values( 'reference' ).groupby( 'designation', as_index = False ).last().set_index( 'designation', drop = False ) ), why sort by reference rather than designation? EDIT: I’ve since understood the logic behind “most recent orbit”. Take for example comet 332P (Ikeya-Murakami). This comet comprises several fragments, each with its own entry in the data file. I can now see why you sought to eliminate all but the most recent “orbit”, although, I’m unsure why you used the ‘reference’ field to sort rather than say ‘designation’ and take the first (as it might/should be the brightest).