Handle integration of asteroids that are already included as perturbers

[mjuric]

End-users may sometime use ASSIST to compute ephemerides for all or some objects in well known catalogs (e.g., MPCORB). These sets may contain objects which are already included in the JPL-computed ephemerides files (either the perturbers or DEs, for Pluto). There should be a way to either a) detect this situation and warn the user or b) provide an API to request the list of object designations included with the ephemerides files or c) an API to get a state vector for those objects.

This issue is here so we don't forget about it.

[mschwamb]

Adding my comment from a previous slack conversation here: For a) I don't think there's a good way to transparently identify the perturbers I think. Someone could clone them and have slight differences in orbit from the ones we have set and it would not get detected Likely option b/c is easier to implement

[mjuric]

A way to do a) is to test for exceptionally close encounters (collision, in effect) on the very first time step of the simulation, and emit a warning.

[hannorein]

I agree with @mschwamb, I don't think there is a clean way to do that. The ephemeris from some catalogue might not be very close at all, depending on how good the catalogue is.

[akoumjian]

Option b should be almost possible with the suggested implementation in #107 , or at least returning the list of NAIF integer target codes.

Option c is almost possible in Python using the names listed in ASSIST_BODY_IDS and ephem.get_particle(). The asteroids SPICE kernel lookup would have to include calculating the velocity. This could be done by taking the new assist_spk_calc_planets in #107 and using it for both the N16 asteroids as well as the planets.