BUG: Issue with orbit and sgp4 defaults

[rstoneback]

Describe the bug If a user attempts to iterate by orbit using sgp4, with added quasi-dipole coordinates, to get orbits by local time, then things get wonky with default values.

The issue is pysat's filtering of orbit breaks. The sgp4 values and additional coordinates look ok.

To Reproduce Steps to reproduce the behavior:

1. 
   # Define on-the-fly orbit breakdown input. Note that `mlt` variable will be added by custom function.
   orbit_info = {"kind": "lt", "index": "mlt"}
   # Instantiate satellite propagator. Note that `inclination` and `alt_periapsis` are keywords defined by
   # `missions_sgp4` module, not pysat itself.
   inst = pysat.Instrument("missions", "sgp4", orbit_info=orbit_info)
   inst.custom_attach(
   pysatMissions.methods.magcoord.add_quasi_dipole_coordinates,
   kwargs={
       "glat_label": "geod_latitude",
       "glong_label": "geod_longitude",
       "alt_label": "geod_altitude",
   },
   )
   inst.load(2019, 2, use_header=True)

inst.orbits.next()

5. Orbit breakdown is all weird and wrong.

**Expected behavior**
Normal orbit iteration.

**Screenshots**
If applicable, add screenshots to help explain your problem.

**Desktop (please complete the following information):**
 - OS: MacOS
 - Version Python 3.9
 - Other details about your setup that could be relevant

**Additional context**
I think the gradient in `mlt` is too low compared to pysat orbit defaults. We need to expose those parameters, and have optional and consistent orbit filtering across orbit types. This is really a pysat problem that is exposed via pysatMissions.

[JonathonMSmith]

when you say "Note that mlt variable will be added by custom function." can you provide way you're adding mlt?

[rstoneback]

I updated the comment. Pasted from terminal. Anyway, changing the latitude of the orbit does get orbits working more as expected.

[rstoneback]

The first orbit that loads isn't the first orbit that we should get.

[jklenzing]

I don't have a working version of apexpy at the moment, but here's an slt version:

import pysat
orbit_info = {"kind": "lt", "index": "slt"}
inst = pysat.Instrument("missions", "sgp4", orbit_info=orbit_info)
inst.custom_attach(pysat.utils.coords.calc_solar_local_time, kwargs={'lon_name': 'geod_longitude'})
inst.load(2019, 2, use_header=True)

to check:

import matplotlib.pyplot as plt
plt.ion()
plt.plot(inst['slt'])
inst.orbits.next()
plt.plot(inst['slt'])

The data loads correctly, but the first orbit is actually the first orbit from the previous day. Is this what you're seeing @rstoneback? If I continue to iterate, the orbits eventually match up.

From the terminal feedback, when I first run the orbits command, it does load the previous and successive days correctly, but grabs the first complete orbit of the previous day rather than the first complete orbit that includes the desired day.

[jklenzing]

Update: this holds true for a variety of inclinations (up to 50 deg), using both geod_longitude and longitude as the input to the slt function. The test instrument from pysat works fine, the only difference I see in the data is that the test instrument looks like a linear increase with time, whereas the sgp4 wobbles a bit.

[jklenzing]

It does correctly identify an orbit breakdown by longitude with the same setup as above for sgp4. This is strange, since SLT is just calculated from longitude.

[rstoneback]

The orbit breaks are determined based on the presence of a sufficiently negative gradient. Since longitudes drop by 360, but mlt or slt only drops by 24, longitude orbits may work over a larger range. Opening up the input options as part of the greater orbit generalization, including the size of the gradient trigger, should make more configurations reliable.