Add Mass-Gap as new category for EM-Bright

The decision to move mass-gap classifier from the source-classification to the source-properties was postponed to O4. New classifier needs to be generated after conducting the injection campaign with injections in the gap.

Mass gap definition: 3.0 M_sun <= M <= 5.0 M_sun

[CBC chairs request from O3: @jolien-creighton @chad-hanna @ed.porter]

changed the description

FWIW, I would like to see any motivation in the astrophysics literature for treating 'MassGap' objects differently from BH for the purpose of EM followup. Otherwise there may not be a justification for spending FTE on providing this.

@thomas-dent I do not actually remember the original reason why mass-gap classification was included in the first place in pastro. @jolien-creighton can answer that science question better. However, from the point of view of FTE, it is trivial. We will be training the new classifier using the MDC anyway... The mass gap is just one extra classifier, which does not include much work.

It is extra work to communicate, justify, document and explain to the followup community, even if the code is straightforward.

Since we have basically the entire science yield of a run using the MassGap concept to look back on now, I think we can reasonably ask for evidence of whether it has been considered important or useful by EM observers.

As for historical context, I think that what happened was that Shasvath was looking into whether one could make a statistical statement of whether the MG was populated using FGMC methods (mostly thinking about confusion between astrophysical categories here). Then, at some EMFollow call, someone must have mentioned "oh, and we can add a MG category if people want" since we had it, and the astronomers wanted. So I think it was largely without a whole lot of consideration at the time.

During O3, during the break, we wanted the MG p-astro category dropped as it was causing problems, but since we had already been promising MG somehow we thought it would be best to move it to a "property" rather than a "classification" (i.e., along with EMBright and HasNS, so you would also have HasMG). This would partially disambiguate the three types of MG (NSMG = HasNS+HasMG, {MGMG, MGBH} = ~HasNS+HasMG).

But if we have a clean slate for O4, the simple fact is I don't see why we would want to say much about MG. It is true that NSMG would be more likely than NSBH to be EM bright, but we have the EMBright property anyway. In fact, one could imagine bringing things back to only the barest essentials: 2d skymaps (I doubt distance is all that important since the luminosity is orders of magnitude uncertain), p_astro/p_terr (perhaps computed with multicomponent FGMC, but only reporting p-astro), and EMBright and HasNS (which are our best measures of how important it is to follow up: more conservative - EMBright > HasNS > everything - less conservative). That way people aren't going to be trying to reverse engineer populations, cosmology, etc., but it will be basically as good for EM followup.

@jolien-creighton I doubt that 3D localization will be changed back to 2D ones, but I agree that the distance estimation are not something observers will probably give too much importance in low-latency. The movement to the p-astro/p-terr classification instead of the current p(BNS), p(NSBH), p(BBH) should probably be trivial for the pipelines to implement. Would you mind bringing this up in the next all-sky call?

And based on this discussion, we can close the mass-gap inclusion issue from source properties.

I can bring up the p-category -> p-astro if you like, but I go back and forth on that one. One thing that has come up is whether this "classification" should be improved with subsequent PE, which certainly has more fidelity amongst signal categories but has difficulty with the p-terrestrial category. Part of my thinking about potentially dropping the MultiFGMC p-category in favor of just p-astro is that there would be no need for further discussion about updating p-category based on followup PE. (Another part of my thinking is that I believe the astronomers over-emphasized the importance of p-category for their observing strategies when they should have been focusing more on HasNS and EMBright instead since those more closely address their need.) But another possibility would be to simply declare that all further PE updates only apply to "properties" which, by definition, are conditioned on detection. That is, PE can update the ML inference of HasNS and EMBright, but would not be used to update p-category. Also, I suppose that there is information added in having p-bns and p-nsbh values that are not degenerate with HasNS and EMBright. That is, observers might value knowing that something is a BNS rather than just knowing that it HasNS and is EMBright. (As I say, I go back and forth on making the p-category part of the LL products.)

@jolien-creighton PE updates addressing source properties is actually always the safe thing to do in my opinion because the the p(Terr) value is difficult to update. The HasNS and HasRemnant updates are already done from the PE. So, we can continue to do that. Does this kinda addresses the question about what PE will provide in medium latency?

I think we agree here. I still flip-flop on whether it is a good idea to report the values of p-bns, p-nsbh, and p-bbh computed by the pipelines (rather than just p-astro) even if they are not to be updated based on subsequent PE. Astronomers may like knowing whether it is more likely a BNS or an NSBH when EM bright, and if it is clear that the "categories" are understood to be pipeline-level products then I'm not sure there is much down-side in providing them.

@thomas-dent also this thread in the Userguide is relevant. I am tagging this here for reference.