search

thespacedoctor / sherlock

The QUB Transient Classifier
GNU General Public License v3.0
11 stars 5 forks source link

Differences in catalogued host in Sherlock instances #147

Closed smarttgit closed 2 years ago

smarttgit commented 2 years ago

Iair spotted that ZTF21acoruyj = ATLAS21bmox = AT2021aexp ha different classification in new Lasair-IRIS (SN) compared with all other Sherlock instances (NT)

The reason is that in old Lasair, the transient is associated with the position of the GALEX source GALEXASCJ013811.96-294205.1 The reference position used to calculate the offset of the transient from the host core is that from GALEX.

In new Lasair, Sherlock recognises that the host is also a Pan-STARRS detected galaxy. and uses the Pan-STARRS central coordinates as the reference.

The GALEX and Pan-STARRS positions differ slightly - hence the offset (and classification differ). The Pan-STARRS galaxy coords should be more accurate, so would trust result from new Lasair more.

Was the full Pan-STARRS catalogue included in Sherlock during the move to new Lasair ?

In the PESSTO marshall, and ATLAS webpages, the Pan-STARRS source is not selected as primary association, only the GALEX.

genghisken commented 2 years ago

All the catalogues should be identical on all the Sherlock deployments, though this is not entirely true. It should be noted that there are 23 million more objects in the lasair-iris version of Sherlock's tcs_view_galaxy_ned_stream (where the GALEX object lives) than on the old deployment. However, this doesn't explain the difference, since the object is present in BOTH deployments of that NED view.

Additionally I can confirm that the PS1 catalogue exists on all deployments, even the oldest one. The only thing I need to check is whether a legacy algorithm is running on old Lasair, in place of the default one now deployed with the latest version of Sherlock. All Sherlock versions are the same, but if the algorithm has accidentally been left in place on one machine, it might explain the slight difference. Likewise I will run a simple position test to check that all Sherlocks return the same context.

thespacedoctor commented 2 years ago

Almost certainly due to slightly different mean coordinates used initial Sherlock search. Will have a thorough look tomorrow.

thespacedoctor commented 2 years ago
Platform Coordinates Sherlock Report Association
Lasair IRIS 24.549800, -29.701162 Classified as SN, at 1.21 arcsec PS1 72350245495518382
Lasair Old 24.549800, -29.701162 Classified as NT at distance 0.90 arcsec GALEXASCJ013811.96-294205.1

I have run the mean coordinates of this transient against the latest version of Sherlock and match the GALEXASCJ013811.96-294205.1 source (as NT). The transient currently has 3 detections and I ran Sherlock against all 3 coordinate sets ... all match GALEXASCJ013811.96-294205.1, so not a coordinate issue unless the coordinates are being truncated somehow on Lasair IRIS.

Investigations are ongoing.

thespacedoctor commented 2 years ago

I'm officially stumped on this one. I cannot get Sherlock to report the (less correct) PS1 72350245495518382 SN classification across any system (QUB, Mac, ROE, IRIS). The only thing I can now think of is a precision issue in the sherlock_wrapper scripts used by the Lasair team.

I imagine if it has happened once it will happen again.

thespacedoctor commented 2 years ago

The issue is now pinpointed. A few weeks back Lasair IRIS was having network issues that were throttling Sherlock's processing speeds. The Lasair team chose to bypass this issue by tunnelling through to an old instance of Sherlock's database at ROE which has an outdated version of the NED table and hence the Galex source was not matched.

Once Lasair is deployed on the new hardware (in the new year) this discrepancy will disappear.