Variable cadence for JPL Horizons queries

[rachel3834]

This need not necessarily be an issue to fix, just a behaviour to be aware of, and ideally to have a catch in the software for.

For my project, I'm generating space parallaxes for long baseline lightcurves (~400d). PyLIMA calls JPL Horizons to generate the required positional data. The time step size used in the call to JPL Horizons is hardwired to "60m". Naturally, for long time baselines, this generates a very large table of output.

Apparently this triggers JPL Horizons to paginate the output, but the function microlparallax.produce_horizons_ephem doesn't parse this.

[This can be demonstrated by dumping the data parameter to file at line 586 of microlparallax.py, after the code parsing the output. The same test also triggers the "Wrong number of fields" error, because the last line of output on the first page of the table is
"�[7m < Scroll & Page: space, , ack, OR arrow keys. ends display. > 91%�[m�[K" instead of a table entry or an end-of-table marker. "]

The result is that produce_horizons_ephem returns an incomplete, shortened table, without the positional data for later timestamps. Since it produces a valid table, the code doesn't fail here - instead it fails at microlparallax.py line 371, when the space_parallax function tries to interpolate for timestamps that are out of range of the input table.

The simplest way to solve this might be to give the user optional control over the time step size that is given to JPLHorizons. By requesting larger timesteps, they can then shorten the table. But it would be better if this issue didn't crash the code, so adding a catch when the "Wrong number of fields" error occurs to warn the user to change their requested dates would also be a good idea.

[ebachelet]

I agree on this in principle, but now that users can provide their own JPL tables, I am wondering if this is high priority.

[rachel3834]

I think that we should still handle this. The primary problem is that the code crashes due to the shortened table, which would lead a user to conclude the problem lies with pyLIMA, rather than informing them that its a limitation with the JPL Horizons output. At minimum, we should add a catch for this error case which explains that the user can work around this limitation by using their own JPL table.