search

genghisken / ps1

Pan-STARRS and ATLAS code
3 stars 0 forks source link

Moon Matching #126

Closed thespacedoctor closed 5 years ago

thespacedoctor commented 6 years ago

After some experimentation I quickly found that PyEphem is terrible at predicting the locations of moons (it's not trivial to generating ephemerides for perturbed bodies).

JPL Horizons contains all planetary satellites, so you can generate an ephemeris for each of them. Below is an ephemeris of Mimas at the time of these ATLAS detections; as you can see they're spatially coincident.

I think a good solution to the moon matching problem is to generate an ephemeris grid of all major planets and their moons (and pluto for good measure); a total of 184 bodies. I've created a list of bodies here.

If we generate a 15 year grid (2012-2027) containing the positions of all these bodies at a resolution of 1/day that's a table of 1x10^6 entries. For any detection just lookup the positions of the bodies at the closest epoch and try and find a match.

I already have some code to grab the ephemerides relatively quickly from JPL. After that I would just need to get them into a database table with HTMIDs assigned etc.

If you think this is a viable solution I can generate the grid for you.

genghisken commented 6 years ago

Yes - this is excellent. All I'd need is the table (earth-centric) with name, ra, dec, htm16ID values generated. Then it's just a very simple crossmatch! A million rows is peanuts! All I need to do is add this as an extra crossmatch in my local algorithm (like the Kepler K2 stuff).

smarttgit commented 6 years ago

Looks like great solution - go for it.

thespacedoctor commented 5 years ago

I wrote this script to use rockFinder to generate one CSV file per objects in the solar-system bodies list. Each CSV file contains one line of ra, dec (decimal degrees), mjd and apparent magnitude for each day between 2012-01-01 and 2027-01-01 (5479 lines). The full set of grids can be downloaded from here.

You good to go from here Ken?

Footnotes

genghisken commented 5 years ago

This is great! Can't wait to test it on one of the Uranus satellites, which popped up again the other day.

https://star.pst.qub.ac.uk/sne/atlas4/candidate/1014623151102449500/

I'm fairly sure that running with a single MJD per line won't be enough for the Jovian satellites, so we might need to increase the sampling density for these.

thespacedoctor commented 5 years ago

You're right - even for Uranus' moons there can be a ~150 arcsec movement in 24hrs. If I increase the temporal resolution by 100 (100 positions/day) thats a MySQL table of ~10 million rows. You ok with that?

genghisken commented 5 years ago

Even 100 million would be fine!

thespacedoctor commented 5 years ago

Ok resolution is now bumped up to 0.1 days - hopefully that's fine enough. Here's the link again:

https://www.dropbox.com/s/2l1kgdkndarl445/moon_ephemerides.tgz?dl=1

genghisken commented 5 years ago

Wonderful! Works like a charm. Here's a very nice example - satellite of Uranus.

https://star.pst.qub.ac.uk/sne/atlas4/candidate/1014623151102449500/ detected on 58503.29. The match is less than one arcsec from the predicted location.

./ConeSearchSimple kws "" panstarrs1 localhost full tcs_cat_satellites 01:46:23.18 10:24:49.8 1
id  name    mjd ra_deg  dec_deg apparent_mag    htm10ID htm13ID htm16ID separation
7422414 Oberon 704  58503.3 26.5967768  10.4139237  14.21   16367967    1047549907  67043194063 0.758329

Even better, I can now exclude Pluto immediately without having to go to MPC.

I'll run a few more tests on some Jovian satellites, which will move much more over 0.1 days.

Some of the files failed to load so I need to figure out why. Otherwise, I'll implement in the next few days in the post ingest crossmatch code.

genghisken commented 5 years ago

OK... The 4 files that failed were:

cupid_727.csv
daphnis_635.csv
mab_726.csv
perdita_725.csv

There are a bunch of NOT FOUND lines at the end of most of the files, so once deleted they were OK, with the exception of:

daphnis_635.csv

The NOT FOUND messages truncated the file. Can you regenerate ephemerides for daphnis? It's truncated half way through, and the ephemerides are all in the past.

thespacedoctor commented 5 years ago

Hi ken, see the footnotes in this comment ...

For Daphnis, Cupid, Mab and Perdita JPL only supply ephemerides up to a given epoch and display a warning like:

Solution is to just remove the 'NOT FOUND' lines and ingest the ephemerides that could be generated. Not entirely sure why JPL can't predict where these moons will be ... too great an uncertainty possibly.

genghisken commented 5 years ago

Have started testing spatial and temporal crossmatching on the Attic and Good lists in ATLAS, and already found 4 rogue objects in the good list. (3 are Jovian satellites and one is Neptunian.)

https://star.pst.qub.ac.uk/sne/atlas4/candidate/1143840500140702200/ (Carme 511) https://star.pst.qub.ac.uk/sne/atlas4/candidate/1143842380140723100/ (Carme 511) https://star.pst.qub.ac.uk/sne/atlas4/candidate/1144151020141219500/ (Himalia 506) https://star.pst.qub.ac.uk/sne/atlas4/candidate/1230250420071055000/ (Nereid 802)

There are also 110 objects that match in the Attic. Most are Pluto (and of course all the Pluto satellites match), but a few Uranus moons in there as well.

Just scaling up now to multithreading and will build into the normal checking. And for Pluto, I should just stop checking the satellites.

genghisken commented 5 years ago

Multiprocessing code is now implemented to check for solar system satellites as soon as the local MPC check is done. Objects will be tagged with 'mover' label. They are not currently moved automatically out of the eyeball list, but even if accidentally promoted to the good list, they will NOT be reported to TNS.

genghisken commented 5 years ago

Note that the 4 objects in the good list have been moved to the attic. I have also sent comments to TNS to deprecate the three reports that were submitted (the other was never sent to TNS).