outs1der
commented
3 years ago As @kendallackley pointed out this skymap replacement should be quite similar to what is done for the LIGO skymaps, so hopefully not too much additional coding
Closed ewittmyl closed 1 year ago
outs1der
commented
3 years ago As @kendallackley pointed out this skymap replacement should be quite similar to what is done for the LIGO skymaps, so hopefully not too much additional coding
martinjohndyer
commented
3 years ago @ewittmyl, @kahoTT and I had a meeting todat to discuss improvements to the GRB followup system, based on the findings from Travis's paper. We identified 4 points:
The previous simple system wasn't getting enough data immediately after the detection, in the cases when we got on it soon enough. However the changes in #52 already address this, by adding two different strategies depending on the time since the burst. That was only added fairly recently so maybe could use adjusting, but for now there's no further work needed.
At the moment we use a value of 3.71* for the systematic error when creating Gaussian skymaps, as shown below. Figure 10 in Travis's paper shows that this seems to be underestimating the size of the error when compared to real skymaps, and a value of 5.6 degrees would be optimal. This would be a trivially easy thing to change.
(* Incidentally I'm not sure why the code uses 3.71 instead of 3.61 given in the paper, it has always been that since systematic error was added in https://github.com/GOTO-OBS/goto-alert/commit/85d5b5059eb7fd096a8cbd9ce9dda3abc58807ce).
Right now the strategy for GRBs has a limit of 5 tiles for Swift and Fermi long bursts, and 8 for Fermi short bursts (@Lyalpha added the lower limit for short bursts in https://github.com/GOTO-OBS/goto-alert/commit/df7ca6608919b33f8c2d12ab247d90450659f260). Likewise the probability limits are fairly high: 5% for the first two types, 0.5% for the latter. These could do we some reviewing, especially the tile limits for Fermi skymaps. It would be better to raise the limit and instead rely on the skymap contours as we do for GW events (they still have a limit but it's set at 200 tiles per event). As it happens I'm in the middle of rewriting the tile contour code for GOTO-tile, which should also improve the selection of tiles for relatively small skymaps (which Fermi events are, at least compared to GW skymaps!).
The big change, and the one that this issue is technically about. The annoying thing about Fermi is that they do produce skymaps for their events, but they are only available ~10 minutes after the GCN is sent. Right now that means the skymap file usually won't exist at the point that we're processing the alert, so we fallback to creating our own Gaussuan skymaps.
First there's an annoying issue with actually finding the link to the skymap. In the VOEvents they don't actually include the URL for the FITS file, instead they link to a PNG image for some reason.
However it's possible to reverse-engineer the link to the PNG image to get the FITS link (e.g. https://heasarc.gsfc.nasa.gov/FTP/fermi/data/gbm/triggers/2020/bn201016019/quicklook/glg_healpix_all_bn201016019.fit), and we try and do that since https://github.com/GOTO-OBS/goto-alert/commit/b70546a1dcf2e69d59e093409131f3d52388c6a2 as shown below
Unfortunately at some point they changed the filename format, so that code needs updating.
Now the Gaussian skymap works as an approximation, but when the real skymap is available it would be better to use it. The problem is that, unlike LIGO/Virgo, Fermi don't release an update alert when the skymap is available. That means we will need to have some sort of thread that monitors the skymap link for when the FITS file is actually available. The logical place for this is the G-TeCS sentinel (which again should be moved to this repository as in https://github.com/GOTO-OBS/g-tecs/issues/492). When a Fermi event is processed the sentinel will have to spawn a new thread that checks the skymap URL every, say, 30 seconds for the new file to exist. Then once it does we will have to create a new Event class and pass that to the event handler. We'll have to be careful to "trick" the event handler by creating a new IVORN, otherwise it will run afoul of this check in the database code (ref https://github.com/GOTO-OBS/goto-obsdb/issues/53 which would rework the need for this):
If the sentinel can create this new event and add it to it's internal queue then hopefully everything should flow through just as it does for LVC updates. There's the question about if we should update the tile counts to account for previous observations, but even if we got onto this event immediately after the alert came in this will only be ~10 minutes later, so at most we'd have only finished 1-2 pointings.
Between those four points only the last one requires a significant amount of, and @kahoTT is going to have a look at implementing it. Once they are all in place, in combination with #52, we should have a much-improved follow-up system for GRB events.
We are currently using the skymap created on our own to tile the GRB region. The reason behind this is to avoid the delay of official skymap released by Fermi. However, in most of the cases, GOTO cannot respond to the trigger immediately. We should set up a listener to Fermi skymap to see if the official skymap is released before or after our follow-up. For the former case, we can use the official skymap and overwrite the one we created.