search

genghisken / ps1

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

SN2018cnw - very young Ia but ZTF got it. Let's investigate why we didn't (we have very early detection) #111

Closed smarttgit closed 6 years ago

smarttgit commented 6 years ago

SN2018cnw = ATLAS18qpy = ZTF18abauprj

Very early Ia - which we should probably have registered before ZTF

ATLAS first point : 58284.466 = 2018-06-15 11:11:02.4 UTC Flag Date: June 16, 2018 Registered on TNS = 2018-06-16 20:26:01 UTC

ZTF first point = 58284.259 = 2018-06-15 06:12:57 UTC Registered on TNS = 2018-06-16 01:25:14 UTC

So ZTF did have an image before us (by 5hrs), but they registered it after we should have. From ATLS detection to TNS registration took 33hrs.

We had big delay between ATLAS image and registration. The detection time at 11:11 UT on Friday 15th June, meant it should have been perfect for our day time discovery. Can we trace back to why it was not flagged on Friday ? And see what we can do. I thought we now download within ~hr of data ?

Let's keep forcing down this time delay ... where are the bottlenecks.

genghisken commented 6 years ago

The problem here was that Robert informed me that he needed to reboot psdb3 on Friday (fault with boot SSD). (See my earlier warning about this to the SN mailing list.) In order to allow him to do this, I stopped all the jobs to leave the machine in a quiescent state so that we could shut down the database cleanly. However I ended up in numerous meetings on Friday and we didn't manage to connect to get the machine rebooted. Hence when I got home from Edinburgh late on Friday, I restarted all the jobs and we ended up having to swallow the whole day's data in one go. Hence the delay. (I'm fairly sure it was me that registered that object as well.)

We've now deferred the machine restart until Monday. Hence a repeat performance of a possible delay. However, since I'm around all day, there should be very little delay between reboot and restarting ingest jobs.