Update asteroid data automatically and regularly

[jchate6]

For each non-MPC target:

• [x] once per day fetch new orbit from MPC
• [x] once per day fetch new obs from MPC

Less frequently:

• [x] update taxonomy
• [x] update spectra

[jchate6]

views.refit_with_findorb --> refit orbit with findorb

• do we overwrite recent MPC orbits?

views.update_MPC_orbit --> use updated orbit from MPC

• include random delay
• do not overwrite unless new
• should this only be run if newer orbits than findorb available?

views.update_MPC_obs --> get new obs from MPC

• Make sure to only get new obs
• include random delay

core.management.commands.update_taxonomy_data --> pulls down PDS and searches for new data to update

• consider downloading PDS, and occasionally searching for PDS update
• if PDS downloaded, search for target when target added.
• find way to index document

core.management.commands.update_external_spectroscopy_data --> Pull down MANOS tables, SMASS tables to search for new spectra.

[jchate6]

When running FindOrb, ran into the following issue:

Didn't find observer V01
Observation(s) will be excluded and treated as
geocentric. You can fix this by downloading the
current list of MPC stations at

http://www.minorplanetcenter.net/iau/lists/ObsCodes.html

and saving it to the folder in which Find_Orb runs.```

[talister]

This is a new observing site which is not in the file. I am somewhat confused why it's not as Bill Gray updated that part of the file at the end of November and we have rebuilt the Docker image since then. Have a look in the /root/.find_orb/ObsCodes.htm inside the Docker container and see if V01 is in there. If this is easily catchable after invoking find_orb, we could just add in something to refetch the ObsCodes list with wget/curl/requests and re-run find_orb

[jchate6]

New Findorb complaint:

The file 'ps_1996.dat' is missing.  Without it,
planetary positions will be of low accuracy.  Either
get the file,  or set up JPL ephemerides.  See
https://www.projectpluto.com/find_orb.htm#de_eph
for details on how to do this.

Seems to be present for objects with new A Observations. What are A Observations?

[jchate6]

2018 EB INFO Previously recorded 239 of 233 total MPC obs Seems problematic

[jchate6]

2018 DB1 Previously recorded 58 of 45 total MPC obs

However this happens, we will not check for any new obs until they outnumber the measurements we have recorded...

[jchate6]

1627 findorb appears to hang indefinitely. There are 6559 MPC obs for the target, and it gave the following warning: 2 observations match in date and observatory code, but not in other regards. They will be ignored.

Should probably put a kill switch in if Findorb hangs for more than 10 min...

[jchate6]

For 16 we only record 2438 observations from 2522 "useful" observations.

[talister]

(16) Psyche has a bunch of measurements from the 1850's with column 15 (where 'C' for CCD normally goes) which have code 'M' which I've never seen before but apparently means 'Micrometer' (https://www.minorplanetcenter.net/iau/info/OpticalObs.html). Don't know what sort of residuals those have and whether they are worth including

[jchate6]

WARNING:astrometrics.ephem_subs:Unexpected number of chunks in header line2 (10)

[talister]

Can you post header ? I have seen this happen sometimes when it's not picking up the config or starting in the wrong place

[jchate6]

for 16 Codes not included that we do not explicitly skip:

M
N

T
E
H

[jchate6]

Solved the number of obs issue with 16. Sometimes Satellite observations were recorded in reverse order. Resulting in no-frame being created. Now a Frame is created regardless of order, but a source is only recorded when S obs detected. Only a single frame will be created though. It can just be created from either s or S obs, then edited if found by the other type for the same time/observatory.

[jchate6]

Header for previous error:

Date (UTC) HH:MM   RA              Dec         delta   r     elong   '/hr    PA  

[19/Feb/2019 22:55:19] WARNING Unexpected number of chunks in header line2 (10)
WARNING:astrometrics.ephem_subs:Unexpected number of chunks in header line2 (10)

[jchate6]

Looks like for some reason for 16 fo does not put out mag, ", or sig.

[talister]

That doesn't seem to be the behavior of the console interactive version: ephemeri.txt elements.txt Seems to have read and used most of the data (2958 of 3369 observations 1957 Mar. 21-2018 Sept. 22). Invoking fo ~/Asteroids/16.dat -z -C Z21 -e ~/.find_orb/new.ephem produces the same thing for me

[jchate6]

Mine produces the normal columns as well when I run it from the command line. But I still produce the following output:

Processing 1 objects
Process count 0
1: (16)
The file 'ps_1996.dat' is missing.  Without it,
planetary positions will be of low accuracy.  Either
get the file,  or set up JPL ephemerides.  See
https://www.projectpluto.com/find_orb.htm#de_eph
for details on how to do this.
; a=2.928, e=0.134, i=3  1582 /  3369 obs; 1852 Mar. 17-2018 Sept. 22
Process 0 is done

[jchate6]

Feature added and deployed with branch issue-266