search

LCOGT / neoexchange

NEO observing portal
GNU General Public License v3.0
7 stars 1 forks source link

Updating comet magnitude parameters from JPL does not update Body attributes #423

Closed talister closed 4 years ago

talister commented 4 years ago

Using the dev site and test DB, I updated the orbital elements for 2I/Borisov from the MPC using update_MPC_orbit. This set Body.abs_mag=16.1 (left over from it's previous ingest as an asteroid) and Body.slope=4.0 (default) since the MPCDB page we pull from doesn't contain this information for this comets. I subsequently ran update_physical_parameters to update the M1/K1 from JPL but this produces duplicate values as shown in the attached screenshot Borisov_incorrect_params and also fails to update the Body.abs_mag and .slope parameters leading to a 5.1 magnitude difference between NEOx's and HORIZONS V magnitude predictions (23.1 vs 18.0)

Link to Body detail page: http://neoexchange-dev.lco.gtn/target/1156/

jchate6 commented 4 years ago

I'll look into this tomorrow

jchate6 commented 4 years ago

Always comets

jchate6 commented 4 years ago

OK, having looked at this a bit more this isn't a bug per se more of a future feature request. The ingest JPL Parameters feature purposefully did not include an update to any body fields. At the time we agreed to postpone this because when @ikosic was writing the ingest code, we didn't have a good feel for whether we wanted to update body fields or eliminate them and decided that in either case plumbing through these changes extended beyond the scope of her current project.

jchate6 commented 4 years ago

I do think this should be a feature in neoexchange, but we should discuss the idea more generally for both asteroids and comets and discuss how we want to handle names as well as physical parameters currently stored redundantly.

talister commented 4 years ago

This is fair enough, it's not actually a worse state than we were in already where objects converting from asteroid->comet would need their M1,K1 updating anyway before sensible magnitudes happened. There was also an issue in the Physical Parameters table for the object where the comet name was getting truncated/mangled ('C/2019/vsC/2019 Q4), see: https://neoexchange-dev.lco.gtn/admin/core/physicalparameters/?q=2I Do you want a new issue for that or is it an easy switch to usesanitize_object_name()`?

jchate6 commented 4 years ago

looks like a job for sanitize_object_name I can look into it on the hackday branch

jchate6 commented 4 years ago

I was wrong here. sanitize_object_name won't help because this is parsing from JPL. JPL apparently changed how they store the names of provisionally named comets from C/Borisov (C/2019 Q4) to C/2019 Q4 (Borisov). This means that we have been ingesting these incorrectly. I can fix the ingest (to make C/2019 Q4 --> Provisional designation, and Borisov --> name, and None --> Number) but I'm not sure if I should fix our display to match JPL's which is basically the opposite from asteroids. Also, even though you can search for 2I (which should really be the 'number' for this object) on JPL it does not output this value anywhere when you download it's designations...

Suggestions?

talister commented 4 years ago

On Mon, Mar 30, 2020 at 10:47 AM Joseph Chatelain notifications@github.com wrote:

I was wrong here. sanitize_object_name won't help because this is parsing from JPL. JPL apparently changed how they store the names of provisionally named comets from C/Borisov (C/2019 Q4) to C/2019 Q4 (Borisov). This means that we have been ingesting these incorrectly. I can fix the ingest (to make C/2019 Q4 --> Provisional designation, and Borisov --> name, and None --> Number) but I'm not sure if I should fix our display to match JPL's which is basically the opposite from asteroids. Also, even though you can search for 2I (which should really be the 'number' for this object) on JPL it does not output this value anywhere when you download it's designations...

Suggestions?

They seem to have "upgraded" this as searching for '2I' didn't use to work. Things we need to check how they behave:

I think once we see what comes back from JPL in these cases, we can see how to make a set of rules of how to stuff the info into our data model

—

You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/LCOGT/neoexchange/issues/423#issuecomment-606144893, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANRU7EKZTXPV3J6ZLFAA43RKDLKFANCNFSM4LT3P2VA .

-- Dr Tim Lister, Staff Astronomer +1 805 880 1989

jchate6 commented 4 years ago

I have done this.

jchate6 commented 4 years ago

With the currently deployed version we parse only 46P, 329P, and 1I successfully.

With the updates I've made (but haven't pushed) we can parse everything BUT 1I.

talister commented 4 years ago

On Mon, Mar 30, 2020 at 11:19 AM Joseph Chatelain notifications@github.com wrote:

With the currently deployed version we parse only 46P, 329P, and 1I successfully.

With the updates I've made (but haven't pushed) we can parse everything BUT 1I.

Damn alien spaceships, breaking our stuff... I guess that since it's not coming back and there's going to be no new data on it, maybe it's OK if this one doesn't work (assuming 3I is labelled differently)

—

You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/LCOGT/neoexchange/issues/423#issuecomment-606160931, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANRU7C4WP6MUHFVDTVGQK3RKDPDBANCNFSM4LT3P2VA .

-- Dr Tim Lister, Staff Astronomer +1 805 880 1989