moeyensj / thor Goto Github PK
View Code? Open in Web Editor NEWTracklet-less Heliocentric Orbit Recovery
License: BSD 3-Clause "New" or "Revised" License
Tracklet-less Heliocentric Orbit Recovery
License: BSD 3-Clause "New" or "Revised" License
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:
We could also extract constants directly from the ephemeris files via spiceypy
.
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.
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:
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
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.
Need to test how the current implementation performs and make sure it can deal with wrap-around errors.
Line 40 in eebc1ee
Duplicate epoch clusters need to be split into different clusters of unique combinations.
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.
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.
This should be fairly simple, but we need testing code that drives this component.
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:
THOR should, at the minimum, be made so it can be installed via conda
:
conda install -c moeyensj thor
Add/update GitHub workflows:
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.
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.
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.
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.
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..).
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.
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'
"""
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 :)
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.
Installation instructions are currently out of date and need to be updated.
Gauss' method uses only three observations, how do we pick which ones we want to use or iterate over the possible combinations?
Line 282 in 6e6cada
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
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.
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.
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.
Given a newer catalogue of orbits and a set of observations, THOR should have the ability to update associations between observations and orbits.
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).
We should add a constants class that stores all relevant constants as opposed to relying on those provided by astropy
.
Add spicepy
as alternative to oorb for 2-body propagation.
Because we love Python :)
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..).
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.
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.
Current rotation matrices are hand-coded but should be generated using spicepy
or at least given the option to do so.
Keplerian to cartesian and vice versa
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.