search

genghisken / ps1

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

good SN sent to garbage #173

Open djones1040 opened 4 years ago

djones1040 commented 4 years ago

Hi Ken, just keeping you apprised when we find some good stuff that's been sent to garbage. Here is 2020nbo, a beautiful SN that looks like it was flagged as a ghost?

https://star.pst.qub.ac.uk/sne/ps1yse/psdb/candidate/1155814151180610300/

djones1040 commented 4 years ago

one more for you, 2020nis:

https://star.pst.qub.ac.uk/sne/ps1yse/psdb/candidate/1151151600111100600/

djones1040 commented 4 years ago

hi Ken, tried to do this a little more systematically with a YSE_PZ query for things in our fields that we've never found in QUB. There look to be 72 of them in the last three months, so a fair number (~20% of our discoveries? though not all are great) are getting tossed. Not sure if there's an easy solution here, but figured I'd at least post the list. Thanks!

https://ziggy.ucolick.org/yse/explorer/116/ https://ziggy.ucolick.org/yse/transient_summary/YSE_transients_no_qub

djones1040 commented 4 years ago

OK, last comment - we've changed the status of most of those 72 objects but there are a few transients without a QUB page (2020ken, 2020lzk, 2020njo, 2020out, 2020pft), and a few others where we can’t change the status on the QUB page (2020nis, 2020nlo, 2020nxl, 2020ore). Is it possible to fix those?

genghisken commented 4 years ago

It looks like PS20exv had been thrown away by a human. The TF threshold is set at 0.413.

FYI - "ghosts". I have code that maps the objects back onto the original GPC1 chip position. Some of the chips or subcells can produce excessive numbers of transients in any one night. If the object is in a "hot" subcell you'll see a comment like:

"Suspected bad OTA or OTA cell (OTA XY46 cell 44)."

I implemented this code a few months ago mostly for the benefit of the all sky survey.

The "ghost" flag just indicates that the code ran. We don't throw ghosts away anymore. (We did previously but that was before YSE.)

genghisken commented 4 years ago

The ones without a QUB page I can't do much about. Maybe they were movers or fast faders or fell in a chip gap?

The ones like 202nis are worrying. I need to investigate further and test the cuts on the individual objects. No idea why this particular one wasn't promoted! The reason you can't change the status is that the object was never promoted & therefore never given an internal followup ID. We need a "force promote" button. I have an SQL script that does exactly this, but it would be useful to have a button on the pages so you can do it yourselves.

genghisken commented 4 years ago

I've added this to the Urgent column - we need to know why objects are not being promoted.

genghisken commented 4 years ago

OK. It looks like objects like 2020nis that never got promoted is because we had a zero tolerance policy of the ON_GHOST flag. 2020nis has 2 detections with this flag set. I need raise the tolerance - maybe to > 2 ghosts. Also we need to look at later and if the later data looks like it has no ghosts, promote the object.

djones1040 commented 4 years ago

thanks Ken, makes sense

genghisken commented 4 years ago

I've increased the threshold to > 2 crosstalk detections now. I may end up removing this check altogether. (I need to be a bit more intelligent about how we reject ghosts, but also need to display the relevant flags - ongoing.) So some previously unflagged objects might appear in the eyeball list.