Public and private facing information in per-pipeline preferred event table

Description of feature request

The per-pipeline preferred event table has had lots of discussion, but should be more or less final. One of the open actions from the LVK was to fix the information exposed internally and externally. The information currently visible. Can you confirm that the information below will already be exposed in the appropriate public/private facing tables? If not, please consider this a feature request.

Internal table: Anything goes, keep SNRs in there but maybe add the extra information below as well.

External table: FAR, pastro, source classification and EMbright information (and gpstime I suppose @viola.sordini).

Use cases

Helping astronomers parse alerts.

Good point for the GPS time. And for bookkeeping here is the RODA with agreement on displayed quantities.

@ryan.magee

External table: FAR, pastro, source classification

In constructing the current public alerts table, gracedb parses p_astro from a superevent's voevent in order to construct source classifications. For the headings you listed for the external table:

1. what event parameter(s) or data products are used to calculate source classifications?
2. is that redundant with p_astro?

Thanks, @alexander.pace. Yes, it is redundant - I guess the point is just that source names and probabilities should be visible (e.g. instead of just saying pastro = 1-pterr). I'd imagine showing it the same way as in the public alerts table is fine.

mentioned in commit sushant.sharma-chaudhary/server@432c591c

mentioned in commit sushant.sharma-chaudhary/server@8047cfa2

mentioned in merge request !129 (merged)

According to https://dcc.ligo.org/DocDB/0183/M2200164/007/RODA_alerts_content.pdf the to-be-public quantities should include

FAR, p-astro (Terrestrial, BBH, BNS, and NSBH, where NS is an object with mass less than 3 solar mass), and EM-Bright (HasNS and HasRemnant, the results are marginalized over EoS models). The pipelines that provide EM-Bright should provide HasMassGap probability within EM-Bright (mass-gap objects have mass between 3 to 5 solar mass)

Internally visible quantities should also include network SNR. I have no views on whether GPS time is to be displayed to the public, but logically if the 'preferred event' GPS time is displayed then the per-pipeline ones should also be, and we expect GPS times to be very similar between pipelines for real signals.

As per multiple LL/CBC discussions the RODA is not yet in effect concerning public visibility, it will be put into effect during O4a, conditional on CBC all-sky search chairs providing scientific context for its inclusion based on information gathered at the start of O4.

In any case, it seems reasonable that the internally visible table should include everything requested.

As and when the RODA is put into effect, the publicly visible table should include the quoted information. (Hopefully this aspect can be tested before it actually becomes public ...)

@ryan.magee @viola.sordini @thomas-dent

The table now has gpstime, p_astro, em_bright.

Of the following quantities that are on the internally-facing table:

• graceid
• group
• pipeline
• gpstime
• far
• snr
• p_astro
• em_bright

Could you confirm what values should face the public?

Also, for clarity, I can add the option for p_astro and em_bright not to list values that are zero. Advantage: the table cell is generally cleaner. Disadvantage: the user doesn't know at first glance if the value is zero, or not included in the file. Let me know what you'd prefer.

I'm going to get another pre-O4 release by Friday (May 12), so please comment on this ticket before then so I can get it out.

IMO it is not within our (or at least) authority to confirm this, I can only point to what is in the RODA.

LL group can consult with Operations chairs to confirm if the RODA has been read correctly. (E.g. can per-pipeline information be meaningfully provided without making the pipeline name public?)

Concerning GPS times it seems this is an omission from previous decision making. IMO in the first instance Ops chairs should be consulted.

LL group should determine which of the other quantities, if not covered by the RODA, make any sense to be publicly visible. (E.g. can graceid be used for anything by non-LVK members?)

If you want an opinion on the table display, it may easily be confusing for zero probabilities to be made invisible - they should be no less informative than nonzero ones, and omitting them may lead to doubts that the probability was calculated or was present in the GraceDB entry.

IMO the cell will look nicer if you put a newline between the different probabilities.

changed milestone to %Critical Path O4 Development

@ryan.magee:

external table: FAR, pastro, source classification and EMbright information (and gpstime I suppose

What i'm hearing is everything but SNR?

@thomas-dent:

If you want an opinion on the table display, it may easily be confusing for zero probabilities to be made invisible - they should be no less informative than nonzero ones, and omitting them may lead to doubts that the probability was calculated or was present in the GraceDB entry.

IMO the cell will look nicer if you put a newline between the different probabilities.

Agree, so here is the internal table with the newlines:

omitting them may lead to doubts that the probability was calculated or was present in the GraceDB entry.

That being said, I don't think a member of the public would give that much thought as to what quantities may or may not have been calculated for a given pipeline, for a given superevent. For cleanliness' sake i omitted zero values for p_astro and em_bright:

But feel free to overrule me @viola.sordini @ryan.magee.

edit: this values in that table example were arbitrarily pulled from different test events, so don't try and gleam any scientific insight from it

We are talking about astronomers who may be deciding on continuing with event followup. They will want to know p_HasBNS and p_HasRemnant values, it may be crucial whether these are zero or nonzero, looking at this table they will not see those values and atm we don't propose to put a visible note that values not displayed are zero. The RODA says that the values will be displayed, so please make them visible by default until there is a clear decision otherwise.

(NB, the em_bright probabilities are in general independent of each other and certainly don't add up to 1.)

!129 (640abf61)

@viola.sordini @ryan.magee @patrick-brady

is there anything stopping this from being deployed in a gracedb-server release next week?

closed with merge request !129 (merged)