JPL Ephemerides

[jenniferyee]

The current system of downloading and interpolating JPL Horizons tables is clunky. There are packages for this:

https://docs.astropy.org/en/stable/coordinates/solarsystem.html https://pypi.org/project/jplephem/

maybe we should implement them!

[rpoleski]

Specific link to JPL Horizons package: https://astroquery.readthedocs.io/en/latest/jplhorizons/jplhorizons.html

[jenniferyee]

Relatedly, I would like a way to easily extract the projected separation between Earth and the satellite at a particular time. Currently requires creating a satellite_skycoord object, passing it to Trajectory, calculating _delta_N_E, and then retrieving _delta_N_E. I would like

get_projected_separation(time, satellite or ephemerides_file, coords)

I propose to make this a method of satellite_skycoord.py

[jenniferyee]

Having tried to implement this, I found that there are two downsides to the jplhorizons package:

1. It only accepts a finite number of times (I had to set a maximum of 75 epochs).
2. It requires an internet connection and the query time is slow.

Because of these two reasons, I think our current system of downloading the Horizons file following our instructions is superior. (also, the jplhorizons package returns different information, and I haven't figured out how to use it to calculate microlens parallax correctly, yet.)

For these reasons, I propose we abandon the idea of implementing jplhorizons as too much effort with little gain. @rpoleski Do you agree?

[ketozhang]

@jenniferyee Have you tried passing in a range of epochs. See example in this link

Passing in a list of epochs is problematic since how jplhorizons work is a HTTPS GET query which has a bit size limit. https://astroquery.readthedocs.io/en/latest/jplhorizons/jplhorizons.html#keep-queries-short

---

I have connections from folks working on astroquery, so I can ask if the slow download behavior is a limitation. It's also a large community who'd be happy to get this feedback.

[rpoleski]

Yes, we should not use a list, but a define a range via parameters, e.g., epochs={'start':'2010-01-01', 'stop':'2010-03-01', 'step':'10d'}.

When it comes to requiring internet connection and execution time, the obvious approach would be to cache the results.

[jenniferyee]

The problem is choosing the 'step' intelligently given that orbital periods may vary for a given spacecraft. A fixed value won't work and choosing an arbitrarily small value results in increased run times and/or exceeding hard limits. So far, I haven't been able to find a way to extract a useful period for an arbitrary satellite.

The JPL documentation says that period is a "concept from the 16th century" and "orbital elements are now primarily used as a way to encode the object’s position and velocity at a single instant". So, for example, the reported period for HST might be some value up to hundreds of days, when we know that the relevant period is ~45 minutes.

[jenniferyee]

Fixing this violates our transparency principle: Anything that requires detailed specification (in this case, epochs and time steps) is the responsibility of the user. We want to avoid trying to be "helpful" if it can lead to cases with non-obvious bad outcomes.