ligo-followup-advocate issueshttps://git.ligo.org/emfollow/ligo-followup-advocate/-/issues2024-03-28T20:21:03Zhttps://git.ligo.org/emfollow/ligo-followup-advocate/-/issues/115Don't use uncertainty ellipse if fails2024-03-28T20:21:03ZBrandon PiotrzkowskiDon't use uncertainty ellipse if failsWe've seen a example where the circular failed due to the combined sky map *likely* not being the correct length, which can occur due to https://git.ligo.org/emfollow/gwcelery/-/merge_requests/1347
A fix is to just catch this `ValueErro...We've seen a example where the circular failed due to the combined sky map *likely* not being the correct length, which can occur due to https://git.ligo.org/emfollow/gwcelery/-/merge_requests/1347
A fix is to just catch this `ValueError` if this occurs and proceed to not use this additional info.O4bBrandon PiotrzkowskiBrandon Piotrzkowskihttps://git.ligo.org/emfollow/ligo-followup-advocate/-/issues/113Add citation for RAVEN pipeline2023-12-08T19:29:19ZBrandon PiotrzkowskiAdd citation for RAVEN pipelineO4bBrandon PiotrzkowskiBrandon Piotrzkowskihttps://git.ligo.org/emfollow/ligo-followup-advocate/-/issues/109P_astro from incorrect G-event2023-10-31T18:39:25ZJenne DriggersP_astro from incorrect G-eventp_astro values for circular text for S230806ak seem to have been picked up from G422116, rather than the correct G422114 (noted in [RRT Semi Regular Call on 7 Aug 2023](https://wiki.ligo.org/LSC/JRPComm/SRC20230807AgendaMinutes)).
Circu...p_astro values for circular text for S230806ak seem to have been picked up from G422116, rather than the correct G422114 (noted in [RRT Semi Regular Call on 7 Aug 2023](https://wiki.ligo.org/LSC/JRPComm/SRC20230807AgendaMinutes)).
Circular was hand-edited before being sent.https://git.ligo.org/emfollow/ligo-followup-advocate/-/issues/112Minor updates on initial circular text template (initial-circular.txt)2023-09-29T19:21:24ZBrandon PiotrzkowskiMinor updates on initial circular text template (initial-circular.txt)Copied from https://git.ligo.org/emfollow/gwcelery/-/issues/714 made by @tsawada
In the initial circular text template (initial-circular.txt),
- [x] the reference to GstLAL is now "Tsukada et al. arXiv:2305.06286 (2023) and Ewing et a...Copied from https://git.ligo.org/emfollow/gwcelery/-/issues/714 made by @tsawada
In the initial circular text template (initial-circular.txt),
- [x] the reference to GstLAL is now "Tsukada et al. arXiv:2305.06286 (2023) and Ewing et al. arXiv:2305.05625 (2023)". The former of these has already been published and is better replaced by "Tsukada et al. PRD 108, 043004 (2023)"
- [x] the word "HasMassgap" would be better replaced with "HasMassGap".O4a mid-run releasehttps://git.ligo.org/emfollow/ligo-followup-advocate/-/issues/111Checks of skymap numbers in the circular text2023-09-25T15:05:34ZKeita KawabeChecks of skymap numbers in the circular textMove the following item in the [Temporary Procedure](https://wiki.ligo.org/LSC/JRPComm/RRTTemporaryProcedure) to the Responder Guide:
**Checks of skymap numbers in the circular text**
- Check if the 90% credible region in the Circular te...Move the following item in the [Temporary Procedure](https://wiki.ligo.org/LSC/JRPComm/RRTTemporaryProcedure) to the Responder Guide:
**Checks of skymap numbers in the circular text**
- Check if the 90% credible region in the Circular text agrees with the skymap image on GraceDB.
- If they're the same, good. If not, check if the circular text about sky localization includes "the 90% credible region is well fit by an ellipse with an area of...".
- If the circular text does include that, don't worry. The number in the circular came from an elliptical fit in that case. It's expected to give us a different number.
- If the circular text does NOT include that, call gwcelery experts to discuss how to proceed.Keita KawabeKeita Kawabehttps://git.ligo.org/emfollow/ligo-followup-advocate/-/issues/110Properly include RapidPE P_astro2023-08-24T19:13:04ZBrandon PiotrzkowskiProperly include RapidPE P_astroCurrently there are a few issues when creating circulars (specifically update for now) when including RapidPE. These include
- [x] Citation is not included when displaying p_astro numbers
- [ ] Wording is confusing for p_astro, where it...Currently there are a few issues when creating circulars (specifically update for now) when including RapidPE. These include
- [x] Citation is not included when displaying p_astro numbers
- [ ] Wording is confusing for p_astro, where it is stated that we are assuming the event is astrophysical
Here's a example update example for [S230823a](https://gracedb-playground.ligo.org/superevents/S230823a/view/):
```
SUBJECT: LIGO/Virgo/KAGRA S230823a: Updated Source Classification
The LIGO Scientific Collaboration, the Virgo Collaboration, and the KAGRA Collaboration report:
We have conducted further analysis of the LIGO Hanford Observatory (H1), LIGO Livingston Observatory (L1), and Virgo Observatory (V1) data around the time of the compact binary merger (CBC) candidate S230823a (GCN Circular ***CITE ORIGINAL GCN ID, e.g. 25012***).
Assuming the candidate is astrophysical, the updated parameter estimation based classification of the GW signal, in order of descending probability, is Terrestrial (72%), BBH (27%), NSBH (1%), or BNS (<1%).
For further information about analysis methodology and the contents of this alert, refer to the LIGO/Virgo/KAGRA Public Alerts User Guide https://emfollow.docs.ligo.org/userguide/.
```GWCelery v2.1.8 ReleaseBrandon PiotrzkowskiBrandon Piotrzkowskihttps://git.ligo.org/emfollow/ligo-followup-advocate/-/issues/92ROQ citation to bilby updates2023-08-03T19:30:22ZSoichiro MorisakiROQ citation to bilby updatesFor online bilby, we plan to use ROQ bases I and @rory-smith have developed (IMRPhenomD bases for BNS, IMRPhenomPv2 bases for high-mass BNS - low-mass BBH, and IMRPhenomXPHM bases for BBH). We are wondering if we could add their citation...For online bilby, we plan to use ROQ bases I and @rory-smith have developed (IMRPhenomD bases for BNS, IMRPhenomPv2 bases for high-mass BNS - low-mass BBH, and IMRPhenomXPHM bases for BBH). We are wondering if we could add their citation in GCN circulars, as well as the current bilby citation (Ashton et al. ApJS 241, 27 (2019)). Our plan is to publish them in [zenodo](https://zenodo.org/) in the next few days, and publish a paper describing them in the next month or so. Possible options are
1. Add citation to zenodo as soon as it is available, and update it once we publish a paper in arXiv.
2. Wait for the paper to be published in arXiv, and add its citation once it is available.
I am not sure if the citation to zenodo is allowed in GCN circulars, so I opened this as an issue for now. I also ping lead bilby developers (@gregory.ashton, @colm.talbot, @sylvia.biscoveanu) and PE chairs (@aaron.zimmerman, @patricia-schmidt) to ask if they are happy about this plan.O4a mid-run releasehttps://git.ligo.org/emfollow/ligo-followup-advocate/-/issues/99Don't line wrap paragraphs2023-08-02T17:34:59ZLeo P. SingerDon't line wrap paragraphsThe GCN Circulars style guide no longer recommends wrapping long paragraphs. See https://gcn.nasa.gov/docs/circulars/styleguide#message-content.The GCN Circulars style guide no longer recommends wrapping long paragraphs. See https://gcn.nasa.gov/docs/circulars/styleguide#message-content.O4a mid-run releasehttps://git.ligo.org/emfollow/ligo-followup-advocate/-/issues/108Discrepancy in p-astro values for S230731an2023-08-01T02:03:46ZDeep Chatterjeedeep.chatterjee@ligo.orgDiscrepancy in p-astro values for S230731anThe initial notice for this event reports the correct p-astro values, in this case from [pycbc](https://gracedb.ligo.org/api/superevents/S230731an/files/S230731an-initial.json,0). However, the circular template (and the [circular](https:...The initial notice for this event reports the correct p-astro values, in this case from [pycbc](https://gracedb.ligo.org/api/superevents/S230731an/files/S230731an-initial.json,0). However, the circular template (and the [circular](https://gcn.nasa.gov/circulars/34303)) used p-astro numbers from a previously uploaded p-astro file. For a future release it will be better to create the template from the notice content.
(CC @brandon.piotrzkowski I don't know if this is a duplicate issue. I'm having a vague recollection of something like this. Feel free to merge with the existing issue if it is.)https://git.ligo.org/emfollow/ligo-followup-advocate/-/issues/106Grab values (if possible) from VOEvent2023-08-01T02:03:46ZBrandon PiotrzkowskiGrab values (if possible) from VOEventCurrently we grab certain values from the latest files, include `em_bright` and `p_astro` values. There's a chance these value could differ from the VOEvent for various reasons, so it may be better to just use the values straight from th...Currently we grab certain values from the latest files, include `em_bright` and `p_astro` values. There's a chance these value could differ from the VOEvent for various reasons, so it may be better to just use the values straight from the VOEvent instead.O4bhttps://git.ligo.org/emfollow/ligo-followup-advocate/-/issues/107In SubGRBTargeted joint detection, add external pipeline as authors2023-07-10T18:28:08ZBrandon PiotrzkowskiIn SubGRBTargeted joint detection, add external pipeline as authorsSimilarly to how we currently write joint circulars with IceCube and include them as authors, we also need to add Fermi and Swift as co-authors when we have a coincidence with `search='SubGRBTargeted'`.Similarly to how we currently write joint circulars with IceCube and include them as authors, we also need to add Fermi and Swift as co-authors when we have a coincidence with `search='SubGRBTargeted'`.O4a mid-run releasehttps://git.ligo.org/emfollow/ligo-followup-advocate/-/issues/10331171 deg2 skymap well fit by an ellipse?2023-06-13T18:58:08ZTito Dal Canton31171 deg2 skymap well fit by an ellipse?The [initial circular](https://gcn.nasa.gov/circulars/33889) we released for S230529ay states the following:
> For the bayestar.multiorder.fits,1 sky map, the 90% credible region is well fit by an ellipse with an area of 31171 deg2 desc...The [initial circular](https://gcn.nasa.gov/circulars/33889) we released for S230529ay states the following:
> For the bayestar.multiorder.fits,1 sky map, the 90% credible region is well fit by an ellipse with an area of 31171 deg2 described by the
following DS9 region […]
However S230529ay is a single-detector candidate, whose sky-localization is essentially LLO's antenna pattern: see the [plot](https://gracedb.ligo.org/api/superevents/S230529ay/files/bayestar.png,1) of `bayestar.multiorder.fits,1`. It is hard to imagine that such a distribution would be well fit by an ellipse (even if an ellipse could fit one of the lobes, it would still leave out half of the distribution).
Was this text added by mistake to that particular circular, or is there a bug in `ligo-followup-advocate` that needs fixing?GWCelery v2.1.3 ReleaseBrandon PiotrzkowskiBrandon Piotrzkowskihttps://git.ligo.org/emfollow/ligo-followup-advocate/-/issues/105Two small typos in text of LLAMA circulars2023-06-06T18:04:05ZPeter ShawhanTwo small typos in text of LLAMA circulars* [x] A space should be added after the second `{% endif %}` on line 6 of `llama_track_circular.jinja2`, because otherwise the code produces text like "eventsdetected by IceCube"
* [x] A slash should be added in "LIGO/VirgoKAGRA" one pl...* [x] A space should be added after the second `{% endif %}` on line 6 of `llama_track_circular.jinja2`, because otherwise the code produces text like "eventsdetected by IceCube"
* [x] A slash should be added in "LIGO/VirgoKAGRA" one place in `llama_alert_circular.jinja2`https://git.ligo.org/emfollow/ligo-followup-advocate/-/issues/90Remove FAP requirements for medium-latency circulars2023-06-02T23:43:43ZBrandon PiotrzkowskiRemove FAP requirements for medium-latency circularsCurrently we have limits on whether we should include certain PyGRB and X-pipeline in medium latency circulars:
https://git.ligo.org/emfollow/ligo-followup-advocate/-/blob/8e0a343788af5bc19067010a8d43656e88e035c1/ligo/followup_advocate/...Currently we have limits on whether we should include certain PyGRB and X-pipeline in medium latency circulars:
https://git.ligo.org/emfollow/ligo-followup-advocate/-/blob/8e0a343788af5bc19067010a8d43656e88e035c1/ligo/followup_advocate/__init__.py#L276
https://git.ligo.org/emfollow/ligo-followup-advocate/-/blob/8e0a343788af5bc19067010a8d43656e88e035c1/ligo/followup_advocate/__init__.py#L293
This could lead to an issue where we wish to create a circular for an event that has a FAP just beyond the boundaries set. In general `ligo-followup-advocate` should not make decisions on what is displayed to the public but only check what other pipelines have already chosen.
A solution for this is to give a keyword argument and also check that the appropriate files are present instead.O4a mid-run releaseBrandon PiotrzkowskiBrandon Piotrzkowskihttps://git.ligo.org/emfollow/ligo-followup-advocate/-/issues/97Suggested edits to llama_track_circular.jinja22023-06-02T22:03:37ZPeter ShawhanSuggested edits to llama_track_circular.jinja2* [x] The sentence "The event's properties can be found at..." immediately follows a sentence stating the number of track-like events which were found. That is confusing because they are two different kinds of events, and the GW one has ...* [x] The sentence "The event's properties can be found at..." immediately follows a sentence stating the number of track-like events which were found. That is confusing because they are two different kinds of events, and the GW one has just been referred to as a "candidate". To improve it, change "The event's properties" to "The GW candidate's properties".
* [x] The circular template currently gives a URL like https://gracedb.invalid/events/S2468 . Why does this have "/events" instead of "/superevents" ? Does this circular come into play when there is a G event that did not make a superevent, and/or when there is a G event which DID make a superevent but the superevent did not meet the criteria for issuing a public alert on its own? If this circular should apply in both of those scenarios, some logic may be needed to construct the URL (and if it points to a G event, that needs to be exposed to the public; I am not sure GraceDB is currently able to expose a G event.)
* [x] Near the end of the circular, change "For further information" to "Further information", and remove the angle brackets around the URLs for stylistic consistency.
* [x] The flow of this circular would be better, I think, if it first introduces the GW candidate and the idea of searching for muon neutrino events; then notes that the GW event alone was not significant enough; THEN tells what neutrino candidates have been found. Like this:
```
The LIGO Scientific Collaboration, the Virgo Collaboration, and the
KAGRA Collaboration along with the IceCube Collaboration
(http://icecube.wisc.edu/) report:
Searches have been performed for track-like muon neutrino events
detected by IceCube consistent with the the time and sky localization
of the gravitational-wave (GW) candidate S2468. The GW candidate's
properties can be found at this URL:
https://gracedb.invalid/events/S2468
Based on the analysis of gravitational-wave data alone, this candidate
does not meet LIGO/Virgo/KAGRA criteria for a public alert.
IceCube data was searched in a time range of 1000 seconds [1] centered
on the GW event time (2023-04-30 18:42:52.276 UTC to 2023-04-30
18:59:32.276 UTC). During this time period IceCube was collecting
good quality data. The hypothesis test employed by LLAMA uses a
Bayesian approach to quantify the joint GW + neutrino event
significance. [2] From this analysis, 5 track-like events were found
in spatial and temporal coincidence with the gravitational-wave
candidate S2468. Properties of these potentially coincident neutrinos
together with the p-values associated with the joint observation are
shown below.
```O4a mid-run releaseBrandon PiotrzkowskiBrandon Piotrzkowskihttps://git.ligo.org/emfollow/ligo-followup-advocate/-/issues/98Suggested edits to llama_alert_circular.jinja22023-06-02T22:03:20ZPeter ShawhanSuggested edits to llama_alert_circular.jinja2* [x] To improve the flow of the first main paragraph, add an "s" and move the "been performed" words, like this:
```
A LLAMA search has been performed for LIGO-Virgo-KAGRA
gravitational-wave candidates consistent with the sky localizati...* [x] To improve the flow of the first main paragraph, add an "s" and move the "been performed" words, like this:
```
A LLAMA search has been performed for LIGO-Virgo-KAGRA
gravitational-wave candidates consistent with the sky localization of
IceCube alert IceCubeCascade-230430a (** <add link to notice> **) in a
time range of 1000 seconds [1] centered on the alert event time
(2023-04-30 18:42:52.276 UTC to 2023-04-30 18:42:52.276 UTC).
```
* [x] The second main paragraph is a little garbled. Besides fixing that, I recommend rearranging the words like this:
```
Gravitational-wave candidate S2468 has been identified by this
search. This candidate does not meet the LIGO/Virgo/KAGRA public alert
criteria based on analysis of the gravitational-wave data alone, but
it is found to be in spatial and temporal coincidence with
IceCubeCascade-230430a public alert. The properties of the GW
candidate can be found at this URL:
```
* [x] Finally, near the end of the circular, remove the angle brackets around the URLs for stylistic consistency.O4a mid-run releaseBrandon PiotrzkowskiBrandon Piotrzkowskihttps://git.ligo.org/emfollow/ligo-followup-advocate/-/issues/96Wording suggestions for circular templates (in jinja2 scripts)2023-06-02T22:03:08ZPeter ShawhanWording suggestions for circular templates (in jinja2 scripts)In the early-warning section of initial_body.jinja2:
* [x] Streamline the text by changing `with {% if early_warning_pipelines|length > 1 %}detections{% else %} a detection{% endif %} from the` to simply: `detected by the`
In em_bright...In the early-warning section of initial_body.jinja2:
* [x] Streamline the text by changing `with {% if early_warning_pipelines|length > 1 %}detections{% else %} a detection{% endif %} from the` to simply: `detected by the`
In em_bright.jinja2:
* [x] Change `The probability that any one of the binary components lie between` to `The probability that either of the binary components lies between`
* [x] Change `between 3 to 5 solar mass` --> `between 3 and 5 solar masses`
* [x] A space should be inserted after `is astrophysical in origin,` before the `{% else %}`
In retraction.jinja2:
* [x] I suggest rewriting the core part of the early-warning retraction text to explain more and to explicitly include the words "early-warning", like this:
`This candidate was initially identified by one or more early-warning analyses by matching partial signal templates to the data. Analysis of additional data up to the putative merger time, with full signal templates, did not make a significant detection, indicating that the initial candidate was likely due to transient noise.`
In RAVEN_circular.jinja2, medium_latency_grb_detection_circular.jinja2 and medium_latency_grb_exclusion_circular.jinja2:
* [x] Change `FROM https://gcn.gsfc.nasa.gov/gcn3_archive.html` --> `FROM https://gcn.nasa.gov/circulars`
In userguide_conclusion.jinja2:
* [x] Remove the angle brackets around the userguide URL.
In medium_latency_grb_exclusion_circular.jinja2:
* [x] Change `with the below assumptions` --> `with the assumptions given below`
* [x] Change `E_GW = 10^-2 M_sun` --> `E_GW = 0.01 M_sun`
And finally, in medium_latency_grb_detection_circular.jinja2:
* [x] Personally, I am wary of promising too much in a circular. For this reason, I suggest removing some or all of this text: `Offline analyses are ongoing. Any significant updates will be provided by a new circular.`O4a mid-run releaseBrandon PiotrzkowskiBrandon Piotrzkowskihttps://git.ligo.org/emfollow/ligo-followup-advocate/-/issues/101Typo in EW retraction2023-06-02T18:58:25ZGeoffrey MoTypo in EW retraction"merge time" should be "merger time"
https://git.ligo.org/emfollow/ligo-followup-advocate/-/blob/master/ligo/followup_advocate/templates/retraction.jinja2#L6"merge time" should be "merger time"
https://git.ligo.org/emfollow/ligo-followup-advocate/-/blob/master/ligo/followup_advocate/templates/retraction.jinja2#L6O4a mid-run releasehttps://git.ligo.org/emfollow/ligo-followup-advocate/-/issues/95Bug: latency reported for an early-warning notice with negative latency2023-05-25T19:44:34ZPeter ShawhanBug: latency reported for an early-warning notice with negative latencyIf an early-warning notice was issued with negative latency (as we hope will happen!), the latency of the skymap is being incorrectly described in the circular template as "about a day after the candidate event time." Example: https://gr...If an early-warning notice was issued with negative latency (as we hope will happen!), the latency of the skymap is being incorrectly described in the circular template as "about a day after the candidate event time." Example: https://gracedb-playground.ligo.org/api/superevents/S230516c/files/preliminary-circular.txt . Ideally, the circular would say something like "about 12 seconds before the candidate event time", but the code in initial_body.jinja2 always uses "after", and in fact the `naturaldelta` code in the humanize module (https://python-humanize.readthedocs.io/en/latest/time/) assumes very deeply that the time delta is nonnegative; it simply wasn't written to be able to return something like "-12 seconds". The `naturaltime` method, on the other hand, deals with either positive or negative time deltas, but it looks like it always produces a string with "__ from now" or "__ ago" in it; there isn't an option to change those words. So one way or another -- with `naturaldelta` or `naturaltime` -- some further hoop-jumping is needed to describe a negative latency in the circular. Probably can use code similar to the `beforeafter` in RAVEN_circular.jinja2.O4Brandon PiotrzkowskiBrandon Piotrzkowskihttps://git.ligo.org/emfollow/ligo-followup-advocate/-/issues/102Edits to retraction with early warning2023-05-24T20:50:34ZBrandon PiotrzkowskiEdits to retraction with early warningIn the RRT call there was a request to change wording in a retraction
`merge time` => `merger time`In the RRT call there was a request to change wording in a retraction
`merge time` => `merger time`O4a mid-run release