Dealing with coincident GW/GRB events

[martinjohndyer]

Right now we process LVC, Fermi and Swift events completely independently. In the case that a GW event had a coincident GRB signal we would process both but in a stupid way, adding both events separately to the ObsDB.

What we could instead do is have the ability to recognise if events might be related.

The first thing to do would be to compare the event times, which handily as of GOTO-OBS/goto-obsdb#29 we store in the database. Whichever comes second, GW or GRB, it would be possible to look into the database and see if there was a previous event with a trigger time within X seconds. The other thing to look at is the localisation of both of the events, and find if they share any tiles.

What would we do with this information? If, say, we've already processed an LVC alert and then a few seconds later we get a Fermi GBM alert? Well the first thing to do is recognise that this should retroactively increase to rank of the GW event. See #28 for the current proposal for ranks for GW events, ranging from 2-5. That's deliberate, because we're leaving rank 1 for GW events with a coincident GRB detection.

The second thing we can do is try combining the skymaps of the two events, and then re-tile based on this new skymap. Now as seen with GW170817 LIGO does this themselves and produces updated skymaps in new notices, but if the GOTO sentinel can do it immediately that might give us a key advantage. Also luckily we do store the skymap link in the database, so the second event can fetch the skymap of the first.

How do we do this in practice? It's complicated by not knowing which will come in first, GW or GRB (obviously astrophysically we get the GW detection first, but we can't guarantee LVC will release their GCN Notice before Fermi). If we always have the GRB first then it's simpler, because when the subsequent GW event is handled it can see the GRB event already there and insert at a higher rank. If the GRB comes second though then what should it do? I think the best idea would be to remove whatever previous entry was in the queue was there and create a new event at rank 1, of type GW+GRB. At this point we can also combine the skymaps to create the new tiling for this event.

There's also the question about what to do if we get later updates which might include a new LVC skymap already accounting for the GRB.

[martinjohndyer]

As for the database parameters discussed in #28, discussing with @ewittmyl we could go for a multi-survey response: one set of tiles at rank 1 to be valid for only one day, and then the rest to be inserted at rank X+10, where X was the initial rank (2-5) of the GW event based on the parameters in #28, starting the next day.

[martinjohndyer]

Worth looking at: https://arxiv.org/pdf/1712.05392.pdf (from @kendallackley). https://emfollow.docs.ligo.org/userguide/analysis/searches.html?highlight=raven#coincident-with-external-trigger-search

[martinjohndyer]

There's also a new type of neutrino alert, AMON_NU_EM_COINC, which alerts coincident events between GRB and neutrion detectors. See https://gcn.gsfc.nasa.gov/amon_nu_em_coinc_events.html and https://gcn.gsfc.nasa.gov/amon.html. At the moment we don't process neutrino events (see #35), but if we do then this would fall under a similar category.

[martinjohndyer]

Extra info on the RAVEN code: https://git.ligo.org/lscsoft/raven.

In particular see https://git.ligo.org/lscsoft/raven/-/blob/master/ligo/raven/search.py#L205-287. We could use this to calculate coincidence ourselves.

And checkout https://emfollow.docs.ligo.org/userguide/content.html: there are additional fields for External coincidence, although I don't know if that is live yet.