Cometary designations cannot be packed

[mkelley]

Cometary designations are not fully supported:

In [22]: Names.to_packed("73P")
---------------------------------------------------------------------------
TargetNameParseError                      Traceback (most recent call last)
Cell In[22], line 1
----> 1 Names.to_packed("73P")

File /disks/data0/astro/Projects/sbpy/sbpy/data/names.py:194, in Names.to_packed(s)
    190             raise TargetNameParseError(
    191                 ('{} cannot be turned into a '
    192                  'packed number or designation').format(s))
    193 else:
--> 194     raise TargetNameParseError(
    195         ('{} cannot be turned into a '
    196          'packed number or designation').format(s))

TargetNameParseError: 73P cannot be turned into a packed number or designation

In [23]: Names.to_packed("P/2004 A1")
---------------------------------------------------------------------------
TargetNameParseError                      Traceback (most recent call last)
Cell In[23], line 1
----> 1 Names.to_packed("P/2004 A1")

File /disks/data0/astro/Projects/sbpy/sbpy/data/names.py:194, in Names.to_packed(s)
    190             raise TargetNameParseError(
    191                 ('{} cannot be turned into a '
    192                  'packed number or designation').format(s))
    193 else:
--> 194     raise TargetNameParseError(
    195         ('{} cannot be turned into a '
    196          'packed number or designation').format(s))

TargetNameParseError: P/2004 A1 cannot be turned into a packed number or designation

In [24]: Names.to_packed("C/2013 US10")
---------------------------------------------------------------------------
TargetNameParseError                      Traceback (most recent call last)
Cell In[24], line 1
----> 1 Names.to_packed("C/2013 US10")

File /disks/data0/astro/Projects/sbpy/sbpy/data/names.py:194, in Names.to_packed(s)
    190             raise TargetNameParseError(
    191                 ('{} cannot be turned into a '
    192                  'packed number or designation').format(s))
    193 else:
--> 194     raise TargetNameParseError(
    195         ('{} cannot be turned into a '
    196          'packed number or designation').format(s))

TargetNameParseError: C/2013 US10 cannot be turned into a packed number or designation

These examples should use the 12-character format at:

https://www.minorplanetcenter.net/iau/info/PackedDes.html

Take care to account for two characters in a comet fragment designation, at least for numbered periodic comets. The MPC's comet orbit table file packs 73P-BA into "0073P ba":

https://www.minorplanetcenter.net/iau/MPCORB/CometEls.txt

However, the packed format description doesn't account for two-character fragment specifiers, and following the 73P rule (fragment in columns 11 and 12) will not work for a provisional designation, which needs to use the 11th character. For this latter case, should we raise an error or make it a 13-character string and raise a warning?

[hhsieh00]

Was going to open a new issue, but decide to add it here since it seems related and better to fix these all in one go (but can split off into a different issue if you prefer, @mkelley). In any case, in the category of known bugs (i.e., already recognized and specified in the documentation), asteroid_or_comet() and parse_comet() in names.py will not recognize provisional comet designations unless they are preceded by P/, C/, D/, or X/, even if the rest of the designation follows the comet format of year-single letter-number. e.g., 2024 A1, which resolves to C/2024 A1 in the JPL SBDB query form; where Names.asteroid_or_comet('2024 A1') outputs 'asteroid'.

So, the extra task would be to correct this behavior by checking for comet-like designations without requiring P/, C/, D/, or X/ at the beginning. This is probably needed to implement the improvement suggested in the discussion of PR 417 to use asteroid_or_comet() calls for code branching to produce packed designations of asteroids and comets instead of testing specific string indices.

I think this should be a matter of updating the lists of acceptable and unacceptable comet and asteroid designation patterns in parse_asteroid() and parse_comet(). @mkelley, thoughts on whether to work on this now, or save for later, since as you said, PR 417 solves the problem for now?

[mkelley]

I think that this would break our current behavior for A/ objects, which have cometary-style provisional designations, but are phenomenologically asteroids. I think it is important to keep this behavior, since it is aligned with Horizons. I searched for a comet named A/2017 U1 with no matches, but an asteroid name correctly found `Oumuamua:

Horizons> COMNAM=A/2017 U1
 
>EXACT< name search [SPACE sensitive]:
 COMNAM = A/2017 U1;
Continue [ <cr>=yes, n=no, ? ] : 
*******************************************************************************
JPL/DASTCOM                Small-body Search Results       2024-Nov-12 05:52:53

 >EXACT< name search [SPACE sensitive]:                                  
    COMNAM = A/2017 U1;

 Matching small-bodies: 
    No matches found.
*******************************************************************************
 Select ... [F]tp, [M]ail, [R]edisplay, ?, <cr>: ASTNAM=A/2017 U1
 
>EXACT< name search [SPACE sensitive]:
 ASTNAM = A/2017 U1;
Continue [ <cr>=yes, n=no, ? ] : 
*******************************************************************************
JPL/HORIZONS              1I/'Oumuamua (A/2017 U1)         2024-Nov-12 05:53:02
Rec #:50425582 (+COV) Soln.date: 2018-Jun-26_12:17:57    # obs: 207 (2017-2018)
...

Perhaps cometary-style provisional designations without the [ACDPX]/ prefix should warn the user or raise an exception? If they are useful, we can also add new methods that ignore the prefix: cometary_style and asteroid_style.