"HIGH_PROFILE" logic implementation in gwcelery

changed milestone to %O4

changed iteration to LL grp iterations Apr 17, 2023 - Apr 23, 2023

The logic would be

If RAVEN_ALERT label is there, it's HIGH_PROFILE.
If the lowest-FAR event in the S-event is an un-modelled burst, it's HIGH_PROFILE.
- Note: It doesn't matter if the un-modelled burst event is preferred or not.
- Note: cWB BBH is not un-modelled.
If p_terr<0.5 AND (p_BNS>0.1 OR p_NSBH>0.1 OR HasRemnant>0.1 OR 90%area<100deg^2), it's HIGH_PROFILE.
Otherwise it's not HIGH_PROFILE.

The above should be evaluated each time a preliminary notice is sent out. This will ensure that pastro, embright and skymap are available at the time the bullet point 3 above is checked. (@sushant.sharma-chaudhary @cody.messick and @deep.chatterjee, is early warning notice also considered preliminary notice?)

Each time the evaluation happens, a log message must be left on GraceDB to say e.g. "Sxxxxxx (preferred event Gxxxxxs) is High Profile" or "Sxxxxxx (preferred event Gxxxxxs) is NOT High Profile".

It's possible that an event which got HIGH_PROFILE label after an earlier preliminary notice is considered NOT HIGH_PROFILE upon issuing another preliminary notice later. I propose that HIGH_PROFILE label is NOT removed in this case, at least for now. People will find from the log what happened, and will discuss how to proceed.

@keita.kawabe We have now implemented a logic that there will be a "Final Preliminary" around 5 minutes after the nominal time of the trigger. I think it would be wise to do this check at that time. The first preliminary may be sent with just 1-Gevent or just for an early warning. Is it essential to gain order 4 minutes in applying the label? Another question: it is possible that the preferred event does not match criteria 3 but an other G-event does. That S-event should be considered high-profile ? Following L2100046 that would not be the case.

@roberto.depietri

We have now implemented a logic that there will be a "Final Preliminary" around 5 minutes after the nominal time of the trigger. I think it would be wise to do this check at that time. The first preliminary may be sent with just 1-Gevent or just for an early warning. Is it essential to gain order 4 minutes in applying the label?

HIGH_PROFILE label is used to call Level 2 RRT members automatically via twillio. If something could be truly High Profile, 4 minutes is a big latency, isn't it? If it turns out that it's not High Profile after all, people will go back to bed and Level 0 will continue processing alone.

Another question: it is possible that the preferred event does not match criteria 3 but an other G-event does. That S-event should be considered high-profile ? Following L2100046 that would not be the case.

It's a valid question, but the intent was that the S-event won't be High Profile.

If it's preferable to make such cases also High Profile, that could be done, though that means that Level 2 members will be called more. Note, the point 3. has been there for months, presented multiple times at OpsDiv (and at March LVK too) without getting any complaint. @peter-shawhan what do you think?

Anyway, to make sure that we share the same view about what happens with the current policy L2100046, suppose that the preferred CBC event doesn't satisfy condition 3. but there are two CBC events that do.

This event is handled as either more likely terrestrial, or more likely astrophysical but likely BBH. Initial Notice/Circular will be sent without too much latency.

It's on the shoulder of experts to say "wait, this could be a BNS because one G event says pBNS=0.9, another one says pBNS=0.2, but can we justify changing preferred event and send updates?", and if they think that they have a case, they will contact Level 0 to interrupt Level 0 workflow (4.2 of L2100046). They can decide to manually coll for Level 2 discussion.

The HIGH_PROFILE idea arose from thinking about how "exciting" an event candidate would appear to astronomers. We want prompt RRT Lv2 action on those cases so we can be more confident about the quality of the event, or else find that it has problems and retract it before much time has elapsed, so that astronomers don't waste telescope time. With that in mind, I think that the HIGH_PROFILE label should be closely coupled with the information that is sent out in the alert(s), i.e. based on the preferred event, not on the other G events in the superevent. And I would say that the "high profile" logic should be evaluated around the time of each public alert that goes out, ideally. That is, run it at the time of the first Preliminary alert, and then again at the time of each subsequent alert. Any time it is evaluated it can add the HIGH_PROFILE label to the superevent (but will never REMOVE that label).