Determine alert strategy for O4

[martinjohndyer]

This is a general issue to discuss what changes we want to make to the follow-up strategy in advance of O4.

TODO: write a bit about the current system.

[Lyalpha]

The HasRemnant property is probably more relevant than just HasNS for EM prospects.

At the very least ,the Slack notifications should indicate HasRemnant, and if the event rate of HasNS events is significant, we would certainly want to prioritise on HasRemnant (maybe eventually doing lesser follow-up of HasRemnant ~ 0 events.

[bxg682]

Agree with what Joe said above, but I do think we want to have an expection for anything within (say) 200 Mpc (even BBH), since these will be rare opportunities to constrain models. They'll probably have small skymaps too.

[dsteeghs]

Trying to capture what was discussed during the scheduling sessions.

• Probably skip BBH events altogether, these will still get serendipitous coverage from the all-sky survey.
• Focus on NS events using HasNS attribute and ideally a non-zero HasRemnant. Tresholds for these flags and the FAP need to be discussed.
• BNS events highest priority.
• Decide if we want to do the low FAP events at al. regardless of type (probably could be captured under the same strategy as above, jusrt deciding on FAP limit)

Can keep a near/far strategy using distance, though its more about how much sky there is to cover. We can only go deep if the visible area isn't too large. This ideally needs to look at visibility, but that we can deal with later.

[martinjohndyer]

First off, I'll look at adding a new IGNORE "strategy" for GW events we don't care about. In this case do we still want events to: a) be added to the alerts database? (if yes then they could still appear in the marshal cross-matching) b) be sent to Slack? (if no I'd want to turn off the "Sentinel processing" messages which is tricky) I'd be tempted to still say yes to both, perhaps mitigating if I make a priority alerts channel to highlight the interesting ones.

We could chose what to ignore on various factors: BBH (unless they're very close?), or anything with too large a skymap or poor FAR? We could always change our mind if an update alert came in with a better localisation.

---

On actually changing the observing strategy, here are some thoughts / questions to ask at the next telecon:

Under the current system tiles fall in rank as they are observed, and we'd only go back for a second pass iff there are no remaining visible tiles that haven't yet been observed once. In practice we care more about multiple epochs than coverage, so instead we could have the second pointing increase in priority. With a reasonable wait time (1h, 2h?) we'd get though a certain portion of the skymap, but then when the second pass starts becoming visible again they would jump to the top of the queue (assuming they're still visible).

• Q: What time do we want to wait before the second pass becomes valid? This will directly correspond to how much skymap we cover before revisiting (e.g. if the wait time is 1h and it takes 5m per pointing we will be limited to 12 tiles (or 24 with two telescopes sharing the load)
• On that note, do we want to limit the follow-up observation to the same telescope that took the first? Or the opposite?
• One issue with going down this route is that the second pass will be forced to exactly mirror the first, i.e. the same targets in the same order (as each new pointing will become valid exactly X minutes after the previous finished). This might cause oddities if the sequence gets disrupted, and also ignores any tiebreaker or other constraints. Though if some tiles become invalid (setting, too close to the moon) then we'd be interleaving first pass tiles until another second pass came up.
• Another scenario: a skymap is rising above the horizon during the night. We spend an hour observing tiles as they come up, by definition these will be high-airmass observations of the outer low-probability regions. Once that hour is done the first tile observed is now ready for the second pass, so we spend another hour going back over the same tiles. But during this hour more of the skymap will be rising, including the higher probability centre. Is it really better to be re-observing the fringes of the skymap when we could be looking at tiles with a much larger chance of containing the counterpart? Tricky. You could increase the time to get more on the first pass, but then if you switch after say 2h it doesn't really change the coverage.
• Also, having higher priority tiles with a wait time means we could end up with wasted downtime. With the old method the follow-up observations are immediately valid, they're just buried behind the higher-priority first pass observations. If all the visible tiles are covered once within 45 minutes then the second pass can start immediately. Under this new system there would still be 15 minutes until the new observations are valid, so the telescope would go and do some other survey tile. That seems sub-optimal when there's a GW target right there!

Reading that it seems like the initial idea could use some improvement. We want the benefits of the tiebreaker and immediate replacement in the queue while still guaranteeing a second visit. Off the top of my head, how about you reinsert at the same rank but effectively halve the contained probability? I'm thinking of some of the voting systems with variable quotas. It would be more flexible but you'd lose the exact timing. Maybe you'd want a nominal 10 minute wait time just so you're not revising the same position constantly. It would probably need simulations.

[dsteeghs]

I like it indeed if we could still track these but just not insert targeted observations. But yes we would still want to be aware and be able to cross-match in the marshall.

[kwrsema]

I think a key thing is to have a "easy" way to re-insert a previously ignored alert by hand if information comes to light that makes it more interesting a few hours later (e.g. a weak signal in a GRB satellite is reported in a GCN, there is an exciting cluster/galaxy overdensity in the area, or some neutrinos were detected, or we hear informally there's some chance it may actually have a NS, etc). That way we can be more strict with ignoring certain alerts, as long as people are around to stick an alert back in.

[Lyalpha]

Should single-detector (i.e. practically a cut on area_p90) alerts get less-special treatment?

I'm wondering how we could shoot ourselves in the foot if we have a reasonable EM-bright source with a whole-skymap, and the scheduler is trying to be too-clever and repeating the same patch of sky (which isn't too special in terms of probability contained vs. any other area of sky, cf. the case with multiple detector skymaps).

This also impinges on any near-future alerts in that we would have spent the last several days continually scanning the same region, reducing the cadence elsewhere.

Ultimately, do we think we'd be doing a better job vs. the all-sky survey in these cases?

[martinjohndyer]

73 has made more changes including a new decision chart to filter out a lot more of the junk events. This far into O4 it seems we're getting a lot of them, although we do only have two detectors. I'll leave this open for now as we could still change things for instance when Virgo comes back online.

[martinjohndyer]

With O4b about to start I reviewed our responses to alerts from O4a at the meeting today. The main results are shown in the slide below, in short only 11 events of the 1684 we received would be selected for follow-up.

Any tweaks to the strategy will need more discussion, and we'll probably want to wait for O4b to get a way in to see if anything changes. But there's also the question about the 24 events we "missed", see #78.