dragozzine / multimoon

fit solar system small body multiple systems with non-Keplerian orbits including quadrupole shapes
MIT License
4 stars 0 forks source link

Query too long #7

Closed benp175 closed 3 years ago

benp175 commented 4 years ago

https://github.com/dragozzine/multimoon/blob/3acf688c425ce8e285612b3a36f1399f824843d1/src/mm_make_geo_pos.py#L7

In this function, I get an error about the query being too long. I don't know if this is specific to my version of astroquery (which is the most up to date version avaliable). I think this will be easily solved by retrieving the ephemerides of the KBO one at a time, rather than all at once. This shouldn't be hard to implement since it really just involves looping over each observation time.

dallinspencer commented 4 years ago

Here;s some documentation from the JPL Horizons page.

Keep Queries Short Keep in mind that queries are sent as URIs to the Horizons server. If you query a large number of epochs (in the form of a list), this list might be truncated as URIs are typically expected to be shorter than 2,000 symbols and your results might be compromised. If your query URI is longer than this limit, a warning is given. In that case, please try using a range of dates instead of a list of individual dates.

How many epochs were included in your list of synthetic data? I'm guessing if it's more than 50, then they ask for a range instead of a list, which we can build in, but may not be conducive to our observations, in which case doing a look could work, it just might be slow, which is fine since it's a code that should only need to run once.

benp175 commented 4 years ago

I only had a few epochs in there (I was using the Keck 2005 data with ~5 datapoints). But I was getting the warning that the query was too long. Even when querying for our largest datasets, it should only be about 30 iterations, which should take too long. Even if it does take a few minutes, that's small compared to how long running MultiMoon takes.