Add/update GitHub workflows:

• Update conda package workflow to build and test on macOS
• Update conda package workflow to build and test on Windows
• Update conda publishing workflow to build and publish package on macOS
• Update conda publishing workflow to build and publish package on Windows

Worth mentioning that docker run -it moeyensj/thor:latest opens a virtual machine, it doesn't run the thor code yet (for newbies in docker like me step-by-step is pretty useful :)

Duplicate epoch clusters need to be split into different clusters of unique combinations.

Agreeing on time scales is a persistent issue for astronomers: requiring all times to be passed as astropy Time objects should prevent most major issues.

Internally, all orbits should be propagated with the TDB scale, all ephemeris could be returned in UTC.

The default IOD process will iterate through all combinations of three observations until a combination of three meets the reduced chi^2 threshold, this process ignores the number of outliers set by the contamination percentage parameter. As a consequence, for erroneous clusters with many observations, IOD can spend an inordinate amount of time iterating through combinations even though it already tried more combinations than the number of outliers should have allowed.

Given a newer catalogue of orbits and a set of observations, THOR should have the ability to update associations between observations and orbits.

A recent attempt at installing THOR with pip failed due to missing requirements in the setup.cfg (see: B612-Asteroid-Institute/thorctl#34). This calls for a GH workflow to test pip installs. We can pull openorb from conda and then install the rest of the packages with pip.

Add spicepy as alternative to oorb for 2-body propagation.

We will need to create some quality metrics, but we can initially start with using sky-plane residuals and require that the predicted locations are within some astrometric tolerance.

Because we love Python :)

Not all observations will come with the observer's heliocentric location, we need code that can get these position vectors.

Naively, we could use spicepy but to avoid pulling in more dependencies we can also use oorb and generate an ephemeris for a sample asteroid and from there pull the observer's position vector.

We need to re-standardize internal notation before the code gets to a stage where it will be harder to do so.

Propositon (following Milani et al. 2008):
r : heliocentric position vector in AU
q : heliocentric position vector of the observer in AU
rho : target to observer distance vector in AU
t : time in units of MJD

A suffix of _mag appended to a vector indicates the magnitude. A suffix of _hat indicates a unit vector.

We need code to pull a few known minor planets from the MPC's catalogue of known objects. Once we have the input orbits, we need to generate observations for several different observatories.

Once we have the IOD functions working, we need an integration function that drives running IOD on clusters and can handle some of the IO corner cases, particularly, how to deal with partial clusters.

This issue is blocked by #6.

JPL's transition to DE44X has lead to the current iteration of unit tests failing since they rely on data products tied to the DE43X series of planetary ephemerides. Unit tests currently rely heavily on JPL's Horizons service (exposed through astroquery) and so are not static since the underlying JPL data products can change. In terms of reproducibility, unit tests should be upgraded to rely on a static snapshot of the data products provided through the astroquery interface. A second set of tests could be added to test the code as JPL data products are updated to the latest and greatest.

To accomplish this I think we will need to:

• Upgrade the constants class to have versions tied to the DEXXX ephemerides
• Upgrade the spice.py utilties to use the DEXXX class defined by the current constants class

We could also extract constants directly from the ephemeris files via spiceypy.

Pull state vectors from Horizons for a sample population of asteroids, simulated their observations, and use one test orbit per asteroid to recover the orbits. This should be a straightforward and simple test of the major pipeline components.

Gauss' method gives you an estimate of the topocentric distance (distance from minor planet to topocenter) at the time of the second observation. To get the initial orbit we need the velocity at that location. There are a variety of methods, but to begin with lets add the Gibbs and Herrick+Gibbs methods.

Based on the discussion in B612-Asteroid-Institute/precovery#47, the initialization factories that query external services in the THOR orbits class need to be cleaned up and separated from the stateless .from_x class methods.

Need to test how the current implementation performs and make sure it can deal with wrap-around errors.

We should add a constants class that stores all relevant constants as opposed to relying on those provided by astropy.

Installation instructions are currently out of date and need to be updated.

THOR needs a command-line interface that exposes more of its key functions.
Something like python runTHOR.py --task=link --inputs_dir={directory} as suggested by @spenczar .

Where task should probably be some of the following:

• link (run the full pipeline)
• propagate (propagate orbits to a desired time)
• ephemeris (generate ephemerides for an observer)
• iod
• od
• attribution
• test_orbits (find/create test orbits)

This should be fairly simple, but we need testing code that drives this component.

Residuals on the sky-plane should be calculated probabilistically. In the absence of a covariance matrix, a covariance matrix can be created using the RA and Dec sigmas. Once a covariance matrix is calculated, we can then proceed to calculate the Mahalanobis distance and the subsequent probability that two coordinates belong to the same distribution (or same object..).

An implementation of Gauss' method with Herrick+Gibbs or Gibbs to determine the velocity needs to be added so we can validate clusters on the fly.

This also requires quality of fit calculations using ephemeris generation (residuals, chi2, etc..).

ray usage throughout THOR is not heavily tested and likely sub-optimal. With THOR's deployment on GCP we need to identify bottlenecks and areas of improvement so we can fully utilize the cores that are available to us.

mergeLinkages causes nodes on GCP to run out of memory (despite having 128 GB of RAM available) in the presence of orbits that share many observations and contain many observations.

Hey @moeyensj 🙂 It looks like there's maybe a small issue with the logger when generating ephemerides times out?

For reference I am currently using v1.1 of Thor. Here's the most relevant part of the traceback and I'll copy the whole thing below.

File "/astro/users/tomwagg/.conda/envs/neocp/lib/python3.9/site-packages/thor/backend/backend.py", line 61, in ephemeris_worker
    logger.CRITICAL("Ephemeris generation timed out on orbit IDs (showing first 5): {}".format(orbits.ids[:5]))
AttributeError: 'Logger' object has no attribute 'CRITICAL'

Let me know if you need more info. Whole trackback below

---------------------------------------------------------------------------
RemoteTraceback                           Traceback (most recent call last)
RemoteTraceback: 
"""
Traceback (most recent call last):
  File "/astro/users/tomwagg/.conda/envs/neocp/lib/python3.9/site-packages/thor/backend/backend.py", line 59, in ephemeris_worker
    ephemeris = backend._generateEphemeris(orbits, observers)
  File "/astro/users/tomwagg/.conda/envs/neocp/lib/python3.9/site-packages/thor/backend/pyoorb.py", line 463, in _generateEphemeris
    ephemeris, err = oo.pyoorb.oorb_ephemeris_full(
  File "/astro/users/tomwagg/.conda/envs/neocp/lib/python3.9/site-packages/thor/backend/backend.py", line 32, in handle_timeout
    raise TimeoutError(self.error_message)
TimeoutError: Timeout

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/astro/users/tomwagg/.conda/envs/neocp/lib/python3.9/multiprocessing/pool.py", line 125, in worker
    result = (True, func(*args, **kwds))
  File "/astro/users/tomwagg/.conda/envs/neocp/lib/python3.9/multiprocessing/pool.py", line 51, in starmapstar
    return list(itertools.starmap(args[0], args[1]))
  File "/astro/users/tomwagg/.conda/envs/neocp/lib/python3.9/site-packages/thor/backend/backend.py", line 61, in ephemeris_worker
    logger.CRITICAL("Ephemeris generation timed out on orbit IDs (showing first 5): {}".format(orbits.ids[:5]))
AttributeError: 'Logger' object has no attribute 'CRITICAL'
"""

The runTHOR function takes configuration dictionaries for the different pipeline components and then saves those dictionaries into a config.yaml. The config class should ideally be improved to support a toYaml and fromYaml class method, and also support checking for configuration equality.

propagateTestParticle in pyoorb.py is use-case limited and needs to be made more general so that orbits generated by IOD can be propagated to generate ephemerides

THOR should, at the minimum, be made so it can be installed via conda:
conda install -c moeyensj thor

To determine what is the best solution or at least have some metric of solution quality we need to calculate sky-plane residuals (and perhaps, other metrics).

Gauss' method uses only three observations, how do we pick which ones we want to use or iterate over the possible combinations?

Hi!

Congrats for thor! Learned about it from HackerNews, and was surprised by the quality of the code! 👏

I think a .dockerignore file could be helpful, to avoid including unnecessary files in the build context.

Refs:

• https://codefresh.io/blog/not-ignore-dockerignore-2/
• https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#build-an-image-using-a-dockerfile-from-stdin-without-sending-build-context

I tried to quickly run thor using the Docker image, but stopped it when the last layer started downloading 1.3 GB 😅 Will leave it for when I'm connected to $work's network to save my bandwidth.

Cheers
Bruno

Current rotation matrices are hand-coded but should be generated using spicepy or at least given the option to do so.

Astrometric errors are needed for orbit fitting but not all observations should be expected to have them. Adding a kwarg that allows a constant value to be assigned should be a good starting place.

Once potential linkages or potential attributions have been found they need to be submittable to the MPC. This involves writing an ADES converter and curl submission utility.

Keplerian to cartesian and vice versa