Planet improvements

[taldcroft]

Description

This includes a few improvements related to handling planets.

• Allow computing light travel from Chandra not Earth
• Make n_times arg in get_planet_chandra_horizons be actual number of times. Previously the returned table had n_times + 1 rows.
• Add get_planet_angular_sep() function. This will be useful in starcheck and potentially sparkles if we add planet checks.
• Always plot planets if near FOV and add legend.

The most evident is the change in plotting to always show planets if they are in the FOV. For instance the sparkles plot for 23368 in JUL1921 prelim looks like below. Sparkles does not have an obs duration so this just reflects the start time, but still this makes noticing a planet much easier.

Testing

• [x] Passes unit tests on MacOS (including new unit tests)
• [x] Functional testing

  Functional testing

As shown in plot above, ran sparkles on a load with a planet and saw expected result.

Also this script demonstrates plotting a star field where Venus is in the FOV. This is not a realistic observation.

from chandra_aca.plot import plot_stars
from chandra_aca.transform import *
from chandra_aca.plot import *
%matplotlib
from chandra_aca.planets import *
eci = get_planet_chandra('venus', '2020:001')
ra, dec = eci_to_radec(eci)
plot_stars(starcat_time='2020:001', duration=10000, attitude=[ra, dec, 0])

[jeanconn]

I think this is great, but I was under the impression from our previous discussion that we had concerns (speed and internet access) about putting planet lookups in the code that might be running on the matlab side. I'm not sure when/if the plot calls are run in nominal planning.

[taldcroft]

I don't believe that any of this code is run from MATLAB tools. In particular the plotting code is not called AFAIK because @jskrist (perhaps wisely!) chose to mostly ignore all the HTML-generating code in sparkles and do everything natively in MATLAB using only the ACA review table object.

[jeanconn]

RIght, I just thought they popped up a plot when they did that look at sparkles review output or for roll suggestions.

[taldcroft]

It is also worth noting that plotting does not use the internet (Horizons) but only cheta to get the ephemeris. I suspect that the time to make a plot is not substantially changed by a call to this routine since matplotlib is generally quite slow. It looks like less than 30 msec for the key call, which happens only if the planet is within 2 deg.

In [5]: times = CxoTime('2020:001') + np.arange(20) * u.hr                                                  

In [6]: %timeit pos = get_planet_chandra('jupiter', times)                                                  
26.3 ms ± 1.34 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

In [11]: %timeit get_planet_angular_sep('jupiter', ra=0, dec=0, time='2020:001') 
1.42 ms ± 29.7 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)                           

If the planner is doing a roll optimization, then a 100 ms is not going to be noticed.

My recollection was that MATLAB never uses the Python plotting or reporting, but I might be wrong on that. I guess it might be worth a try/except on the cheta ephemeris fetch and doing something graceful if that fails. A normal FOT laptop won't have cheta ephemeris data, but it will have internet access to falling through to the slower horizons interface is an option.

[jeanconn]

I wasn't really concerned about the timing as much as trying to figure out if there was a set of args/options to not do the planet plotting and if we needed one.

[jeanconn]

And the new labels for the "just using DE432s" seem fine