good SN sent to garbage

[djones1040]

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]

one more for you, 2020nis:

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

[djones1040]

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]

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]

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]

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]

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

[genghisken]

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]

thanks Ken, makes sense

[genghisken]

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.