GraceDB Server issueshttps://git.ligo.org/computing/gracedb/server/-/issues2022-09-12T10:34:28Zhttps://git.ligo.org/computing/gracedb/server/-/issues/1Numerical superevent parameters returned as strings2022-09-12T10:34:28ZTanner PrestegardNumerical superevent parameters returned as strings```
{u'created': u'2018-04-06 20:26:52 UTC',
u'em_events': [],
u'gw_events': [u'T0066', u'T0064', u'T0063', u'T0059'],
u'labels': [u'LUMIN_NO', u'EM_READY', u'H1OPS', u'EM_Throttled'],
u'links': {u'emobservations': u'TBD',
u'events...```
{u'created': u'2018-04-06 20:26:52 UTC',
u'em_events': [],
u'gw_events': [u'T0066', u'T0064', u'T0063', u'T0059'],
u'labels': [u'LUMIN_NO', u'EM_READY', u'H1OPS', u'EM_Throttled'],
u'links': {u'emobservations': u'TBD',
u'events': u'https://gracedb-dev1.ligo.org/api/superevents/S0001/events/',
u'files': u'https://gracedb-dev1.ligo.org/api/superevents/S0001/files/',
u'labels': u'https://gracedb-dev1.ligo.org/api/superevents/S0001/labels/',
u'logs': u'https://gracedb-dev1.ligo.org/api/superevents/S0001/logs/',
u'self': u'https://gracedb-dev1.ligo.org/api/superevents/S0001/',
u'voevents': u'https://gracedb-dev1.ligo.org/api/superevents/S0001/voevents/'},
u'preferred_event': u'T0063',
u'submitter': u'tanner.prestegard@LIGO.ORG',
u'superevent_id': u'S0001',
u't_0': u'12.000000',
u't_end': u'23.234354',
u't_start': u'56.000000'}
```https://git.ligo.org/computing/gracedb/server/-/issues/2Superevent queries2022-09-12T10:34:28ZTanner PrestegardSuperevent queriesThis issue is created to get some feedback on what attributes would be most useful for querying for superevents, as well as which attributes should be added to event queries. Here's what I came up with off the top of my head.
### Super...This issue is created to get some feedback on what attributes would be most useful for querying for superevents, as well as which attributes should be added to event queries. Here's what I came up with off the top of my head.
### Superevents
* Search by superevent ID (date-based)
* Superevent submitter
* Ranges of `t_start`, `t_0`, `t_end` (GPS times)
* Whether an alert has been sent out for the superevent
* Whether the superevent is confirmed as a GW
* Preferred event graceid (possibly a range of graceids)
* Event graceids
* Labels
* Do we need the ability to find superevents based on attributes of their preferred events? Ex: find all superevents with a preferred event which was identified by the CWB pipeline. If this seems useful, which attributes?
### Events
* Find all events which are preferred events for superevents
* Find all events which are part of a particular superevent
* Find all events which are part of any superevent (or are NOT part of any superevent)
If there are other filters which would be useful, or if any of these don't seem useful, please comment!https://git.ligo.org/computing/gracedb/server/-/issues/3Date-based IDs for superevents2023-05-11T16:31:37ZTanner PrestegardDate-based IDs for supereventsBased on notes from the March 2018 LVC meeting and discussions with Patrick and Deep, I've developed a strategy for implementing date-based IDs for superevents. An example is given below to demonstrate how this will work, but please ask ...Based on notes from the March 2018 LVC meeting and discussions with Patrick and Deep, I've developed a strategy for implementing date-based IDs for superevents. An example is given below to demonstrate how this will work, but please ask any clarifying questions that are needed since it's a bit confusing to walk through.
## Example
1. A superevent is identified for May 13, 2018. (The date is determined from the initial value of `t_0` assigned to the superevent)
* Initial date-based ID assigned: S180513
2. A second superevent is identified for May 13, 2018.
* Initial date-based ID assigned: S180513b
* A letter suffix is added to the first superevent: S180513 -> S180513a. Hyperlinks and API calls which use either S180513 or S180513a will both point to this superevent, but S180513a will now be displayed as the ID throughout GraceDB.
3. An alert is sent out about S180513b.
* Its prefix is upgraded to "GWA", so its official ID is now GWA180513b. The letter suffix is inherited from its previous ID. Hyperlinks and API calls which use either ID (S180513b or GWA180513b) will both point to this superevent, but GWA180513b will be displayed as the ID throughout GraceDB.
4. GWA180513b is confirmed as a GW.
* Its prefix is upgraded to "GW" and a new letter suffix is determined based on confirmed GWs for this date.
* Resulting ID: GW180513. As before, hyperlinks and API calls using S180513b or GWA180513b will still work, but GW180513 will be generally displayed as the ID.
5. An alert is sent out about S180513a.
* ID changed from S180513a -> GWA180513a, hyperlinks still work for both IDs (and the initial, suffixless ID), etc.
6. GWA180513a is confirmed as a GW.
* ID changed: GWA180513a -> GW180513B. Hyperlinks and API calls still work for all past IDs, etc.
* GW180513 has a letter suffix added: GW180513 -> GW180513A. Hyperlinks and API calls still work for all past IDs, etc.
## Questions
1. Should the intermediate state (GWA prefix) exist or is a two-state arrangement sufficient?
2. If so, should the GWA state have its own letter prefix and not just inherit it from the S state?
3. Is the current strategy for handling the letter suffix for the first superevent on a given date acceptable (i.e., first superevent has no letter suffix until a second superevent is found for that date)? Or should the first superevent always have a letter suffix? Access to the superevent in GraceDB will be unaffected, but there could be confusion in certain cases. Example: offline searches find a second GW on a given date, which adds a letter suffix to the first GW's ID after a paper is already published about the first)
4. Same question as above for the first superevent confirmed as a GW on a given date.
5. Capital or lowercase letter suffixes for confirmed GWs?https://git.ligo.org/computing/gracedb/server/-/issues/4Removing an event from a superevent does not unset it as the preferred event2018-06-13T23:13:13ZTanner PrestegardRemoving an event from a superevent does not unset it as the preferred eventSee original post at https://git.ligo.org/lscsoft/gracedb-client/issues/4.See original post at https://git.ligo.org/lscsoft/gracedb-client/issues/4.https://git.ligo.org/computing/gracedb/server/-/issues/5superevents() query not returning complete set of superevents2018-06-28T12:22:14ZTanner Prestegardsuperevents() query not returning complete set of supereventsSee original post at https://git.ligo.org/lscsoft/gracedb-client/issues/6See original post at https://git.ligo.org/lscsoft/gracedb-client/issues/6https://git.ligo.org/computing/gracedb/server/-/issues/6Superevent lvalert messages must contain valued value for "self" field2018-06-14T15:34:38ZLeo P. SingerSuperevent lvalert messages must contain valued value for "self" fieldSince we multiplex traffic from several different GraceDb servers to the single LVAlert server `lvalert-test.cgca.uwm.edu`, it is necessary for all LVAlert messages to identify the GraceDb server of origin. I have been using the `self` a...Since we multiplex traffic from several different GraceDb servers to the single LVAlert server `lvalert-test.cgca.uwm.edu`, it is necessary for all LVAlert messages to identify the GraceDb server of origin. I have been using the `self` attribute for this purpose. However, `superevent` LVAlert messages set this attribute to `null`. They need to set this attribute to a valid URL. This is a prerequisite of emfollow/gwcelery#21.
```
{
"object": {
"comment": "Set as preferred event for superevent: S180613bw",
"file_version": null,
"tag_names": [
],
"file": null,
"created": "2018-06-13T17:53:37.431668+00:00",
"self": null,
"issuer": "emfollow",
"filename": "",
"tags": null,
"N": 6
},
"uid": "M3404",
"labels": [
],
"alert_type": "update",
"file": "",
"description": "LOG: Set as preferred event for superevent: S180613bw"
}
```
CC @tanner.prestegard.https://git.ligo.org/computing/gracedb/server/-/issues/7Superevent 'new' and 'update' LVAlert messages have inconsistent structure2018-06-25T15:19:38ZLeo P. SingerSuperevent 'new' and 'update' LVAlert messages have inconsistent structureThe `new` and `update` LVAlert messages have very different structures. For the `new` message, the `uid` is the GraceDb ID of the superevent, whereas for the `update` message the `did` is the GraceDb ID of the subevent.
In fact, the upd...The `new` and `update` LVAlert messages have very different structures. For the `new` message, the `uid` is the GraceDb ID of the superevent, whereas for the `update` message the `did` is the GraceDb ID of the subevent.
In fact, the update messages do not even contain the superevent ID in a machine-friendly field; it is only present in the English comment field (e.g. `Set as preferred event for superevent: S180613bw`).
It would make it easier to deal with this LVAlert messages if they shared the same structure: the superevent ID and the preferred event ID should always be found in the same machine-friendly fields.
## New superevent
```json
{
"object": {
"superevent_id": "S180613bw",
"created": "2018-06-13 17:53:37 UTC",
"submitter": "emfollow",
"preferred_event": "M3404",
"t_start": 1212947423.09,
"t_0": 1212947433.09,
"t_end": 1212947443.09,
"gw_events": [
"M3404"
],
"em_events": [
],
"labels": [
],
"links": {
"files": "/apibasic/superevents/S180613bw/files/",
"logs": "/apibasic/superevents/S180613bw/logs/",
"self": "/apibasic/superevents/S180613bw/",
"labels": "/apibasic/superevents/S180613bw/labels/",
"voevents": "/apibasic/superevents/S180613bw/voevents/",
"emobservations": "/apibasic/superevents/S180613bw/emobservations/",
"events": "/apibasic/superevents/S180613bw/events/"
}
},
"uid": "S180613bw",
"labels": [
],
"alert_type": "new",
"file": "",
"description": "NEW: superevent S180613bw"
}
```
## Updated superevent
```json
{
"object": {
"comment": "Set as preferred event for superevent: S180613bw",
"file_version": null,
"tag_names": [
],
"file": null,
"created": "2018-06-13T17:53:37.431668+00:00",
"self": null,
"issuer": "emfollow",
"filename": "",
"tags": null,
"N": 6
},
"uid": "M3404",
"labels": [
],
"alert_type": "update",
"file": "",
"description": "LOG: Set as preferred event for superevent: S180613bw"
}
```
CC @tanner.prestegard.https://git.ligo.org/computing/gracedb/server/-/issues/8Reworking LVAlert types and contents2018-09-21T19:18:37ZTanner PrestegardReworking LVAlert types and contentsThere is a need to add more finely divided categories for LVAlerts and possibly change the type of serialized objects which are included with them. Should more/different information be added as well?
# Current status
## Contents of al...There is a need to add more finely divided categories for LVAlerts and possibly change the type of serialized objects which are included with them. Should more/different information be added as well?
# Current status
## Contents of alert JSON packet
Currently, LVAlert JSON packets include the following keys:
* object: dict representation of a database row; typically an event, superevent, or log object. Note that these should be identical to the representation of these object available from the API.
* description: text description of the action which triggered the alert
* uid: event graceid or superevent id
* alert_type: either "new", "label", "update", or "signoff"
* labels: list of label names attached to the event or superevent
* file: filename string (optional and relative)
## Actions for which GraceDB issues alerts
GraceDB issues LVAlerts when the following actions are taken:
### Events
Constants:
* uid: always the related event's graceid
* labels: always a list of the related event's labels
| Action | alert_type | object | file | description |
| ------ | ---------- | ------ | ---- | ----------- |
| Event creation | "new" | event | Link to initial event file | "" |
| Event log creation (no file) | "update" | log | "" | "LOG: comment" |
| Event log creation (with file) | "update" | log | filename | "UPLOAD: 'filename' comment" |
| Label added to event | "label" | Not included in dict | "" | H1OK |
| Label removed from event | "update" | Not included in dict | "" | "Label H1OK removed" |
| VOEvent created for event | "update" | voevent | G0001-3-Update.xml | "VOEVENT: G0001-3-Update.xml" |
| EM observation created for event | "update" | emobservation | "" | "New EMBB observation record." |
| EMBB event log created for event | "update" | embb event log | "" | "New EMBB event log entry." |
| Event added to superevent | "update" | log | "" | "LOG: Added to superevent S180614b" |
| Event removed from superevent | "update" | log | "" | "LOG: Removed from superevent S180614b" |
| Event selected as preferred event for superevent | "update" | log | "" | "LOG: Set as preferred event for superevent: S180614b" |
| Event removed as preferred event for superevent | "update" | log | "" | "LOG: Removed a preferred event for superevent: S180614b" |
| Operator or advocate signoff (initial or update) on event | "signoff" | signoff | "" | "OK" or "NO" |
### Superevents
Constants:
* uid: always the related superevent's superevent_id
* labels: always a list of the related superevent's labels
| Action | alert_type | object | file | description |
| ------ | ---------- | ------ | ---- | ----------- |
| Superevent creation | "new" | superevent | "" | "NEW: superevent S180614a" |
| Superevent update (preferred event, t_start, t_0, t_end) | "update" | log | "" | "LOG: Updated superevent parameters: t_0: 1 -> 2, preferred_event: G0001 -> G0002" |
| Log creation (no file) | "update" | log | "" | "LOG: comment" |
| Log creation (with file) | "update" | log | filename | "UPLOAD: 'filename' comment" |
| Event added to superevent | "update" | log | "" | "LOG: Added event: G0001" |
| Event removed from superevent | "update" | log | "" | "LOG: Removed event: G0001" |
| Label added to superevent | "label" | Not included in dict | "" | "LABEL: H1OK" |
| Label removed from superevent | "update" | Not included in dict | "" | "UPDATE: H1OK removed" |
| Confirm superevent as GW | "update" | log | "" | LOG: Confirmed as a gravitational wave." |
| Create VOEvent for superevent | "update" | voevent | S180614b-3-Update.xml | "VOEVENT: S180614b-3-Update.xml" |
| Create EMObservation for superevent | "update" | emobservation | "" | "New EMBB observation record for DESGW." |
| Operator or advocate signoff (initial or update) on superevent | "signoff" | signoff | "" | "OK" or "NO" |
| Operator or advocate signoff deleted | "update" | log | "" | "LOG: operator signoff for H1 deleted: H1OK removed and H1OPS reapplied" |
Note that there are no EMBB event logs for superevents since they seem to have fallen out of use (there were only ever 31 of them created and the last one was applied for events in ~2015).
## Actions for which GraceDB does not issue alerts
LVAlerts are *not* issued when the following actions occur:
* Event created with labels attached ("new" alert goes out but no "label" alert; this probably should happen)
* Note that superevents created with labels first issue "new" alerts and then "label" alerts
* Event "replaced" with new event file (should probably send an "update" alert)
* An event signoff is deleted.
* An event log or superevent log has a tag applied or removed (I don't think anyone wants to get this alert)
* A log message is generated to document the above action (I don't think anyone wants to get this alert)
# Development action items
We want to do the following:
* Define some new alert_type categories and what actions they should be used for.
* Add alerts for some of the actions listed above.
* Change what type of serialized object is included with certain alerts
* Add documentation of alert contents and actions which trigger them
We might want to:
* Add entirely new information to alerts (i.e., new dict key(s) and value(s))Readiness for second OPA testhttps://git.ligo.org/computing/gracedb/server/-/issues/9sub-second time strings dropping leading zeros2018-07-03T16:44:01ZPeter Couvaressub-second time strings dropping leading zerosAs Jacob Lange reports on the CBC list, the event time in the event.log on Gracedb is wrong for 170818/G298171. The event time should be 1187058327.0815086 but the event.log says 1187058327.815086. It looks like the leading zero of the ...As Jacob Lange reports on the CBC list, the event time in the event.log on Gracedb is wrong for 170818/G298171. The event time should be 1187058327.0815086 but the event.log says 1187058327.815086. It looks like the leading zero of the sub-second string is being dropped somewhere.https://git.ligo.org/computing/gracedb/server/-/issues/10Some floats cast as strings in LVAlerts and response JSONs2018-06-26T21:46:26ZTanner PrestegardSome floats cast as strings in LVAlerts and response JSONsAs reported in https://git.ligo.org/emfollow/gwcelery/merge_requests/94, there are situations in which certain float variables are being sent as strings in LVAlert JSONs and even in some response JSONs from gracedb-client.
I believe thi...As reported in https://git.ligo.org/emfollow/gwcelery/merge_requests/94, there are situations in which certain float variables are being sent as strings in LVAlert JSONs and even in some response JSONs from gracedb-client.
I believe this is happening because in some of the old code in the events API, the event is converted to a dictionary BEFORE it is saved in the database. Thus, some variables which are extracted from the event file (as strings) are still in memory as strings. If we did the save first, that would cast those variables to the correct type.
I will submit some test events for the active pipelines (gstlal, gstlal-spiir, pycbc, mbtaonline, cwb, lib, swift, fermi, and snews) and check the LVAlert content, as well as the response in gracedb-client.https://git.ligo.org/computing/gracedb/server/-/issues/11use lal routines for GPS time handling2022-08-03T18:03:23ZPeter Couvaresuse lal routines for GPS time handlingAs @kipp.cannon [suggests](https://sympa.ligo.org/wws/arc/cbc/2018-06/msg00357.html), although the specific issue in #9 is fixed, using [LAL](https://git.ligo.org/lscsoft/lalsuite) for gps time handling is probably a more robust solution...As @kipp.cannon [suggests](https://sympa.ligo.org/wws/arc/cbc/2018-06/msg00357.html), although the specific issue in #9 is fixed, using [LAL](https://git.ligo.org/lscsoft/lalsuite) for gps time handling is probably a more robust solution long-term to avoid future problems.https://git.ligo.org/computing/gracedb/server/-/issues/12Broken sky map image links on superevent pages (followup from !8)2018-06-28T17:45:09ZLeo P. SingerBroken sky map image links on superevent pages (followup from !8)Images in superevent pages are showing up with the URL `"undefined"`, so the links and `<img>` tags are broken. See, for example:
https://gracedb-playground.ligo.org/superevents/S180628r/view/Images in superevent pages are showing up with the URL `"undefined"`, so the links and `<img>` tags are broken. See, for example:
https://gracedb-playground.ligo.org/superevents/S180628r/view/https://git.ligo.org/computing/gracedb/server/-/issues/13createVOEvent() no longer returns the VOEvent text2018-06-28T12:21:23ZLeo P. SingercreateVOEvent() no longer returns the VOEvent textOn gracedb.ligo.org, the `createVOEvent()` method returns a JSON data structure that includes a key called `text` whose value is the contents of the VOEvent. This is gone on gracedb-playground.ligo.org.On gracedb.ligo.org, the `createVOEvent()` method returns a JSON data structure that includes a key called `text` whose value is the contents of the VOEvent. This is gone on gracedb-playground.ligo.org.https://git.ligo.org/computing/gracedb/server/-/issues/14LVAlert messages for labels do not have a self link2018-07-11T18:28:43ZLeo P. SingerLVAlert messages for labels do not have a self link@deep.chatterjee found this one:
```
[2018-06-29 13:07:17,894: ERROR/ForkPoolWorker-1] gwcelery.tasks.lvalert.listen[5f526064-5919-425a-b17c-029b20cb5b72]: LVAlert message does not contain an API URL: {'labels': ['SKYMAP_READY'], 'alert...@deep.chatterjee found this one:
```
[2018-06-29 13:07:17,894: ERROR/ForkPoolWorker-1] gwcelery.tasks.lvalert.listen[5f526064-5919-425a-b17c-029b20cb5b72]: LVAlert message does not contain an API URL: {'labels': ['SKYMAP_READY'], 'alert_type': 'label', 'uid': 'S180629cb', 'file': '', 'description': 'LABEL: SKYMAP_READY added'}
```
@tanner.prestegard, would you please take a look?https://git.ligo.org/computing/gracedb/server/-/issues/15Rework permissions structure2018-09-21T19:22:21ZTanner PrestegardRework permissions structureWe need to define a permissions structure for controlling superevent actions, as well as upgrade the old one for events. Here is a proposal for how to define this structure going forward.
**Update** (6 Sept 2018): this issue is no long...We need to define a permissions structure for controlling superevent actions, as well as upgrade the old one for events. Here is a proposal for how to define this structure going forward.
**Update** (6 Sept 2018): this issue is no longer going to cover redoing the events permission structure; it will only focus on creating the superevents permission structure.
# Creation
| Action | Allowed users | Comments |
| ------ | ------------- | -------- |
| create event | Specific LVK users only | Currently allowed for pipeline accounts and specific users; remove individual users? |
| create test event | All LVK users | |
| create superevent | emfollow/superevent manager | |
| create test superevent | All LVK users | |
| create MDC superevent | emfollow/superevent manager | |
# Updates
| Action | Allowed users | Comments |
| ------ | ------------- | -------- |
| update/replace event | Only the user who originally submitted the event | Or should it be anyone who is allowed to submit events for the given pipeline? |
| update/replace test event | All LVK users | |
| update superevent | emfollow/superevent manager | Applies to production and MDC superevents |
| update test superevent | All LVK users | |
| add/remove event from superevent | emfollow/superevent manager | Production and MDC |
| add/remove event from test superevent | All LVK users | |
| confirm superevent as gw | Some special people | Should emfollow/superevent manager be on this list? |
| confirm test superevent as gw | All LVK members | |
| confirm mdc superevent as gw | emfollow/superevent manager | |
# Annotations
| Action | Allowed users | Comments |
| ------ | ------------- | -------- |
| add log message/file | All LVK (all events/superevents); LV-EM (only exposed events/superevents) | Not allowed for public users (?) |
| tag log message/file | All LVK (all event/superevent logs) | Not allowed for LV-EM or public |
| untag log message/file | All LVK (all event/superevent logs) | Not allowed for LV-EM or public |
| add label | Specific LVK members can add specific labels | Needs some thought and a finalized list of labels to define this |
| remove label | Specific LVK members can remove the same specific labels | |
| create voevent | emfollow | Are others needed? |
| create emobservation | All LVK (all events/superevents) and all LV-EM (all exposed events/superevents) | This is a little weird because as far as I know, only LV-EM people should be uploading EM observations |
| add/update/remove operator signoff | LVK members in control rooms | Control room groups controlled by IP address |
| add/update/remove advocate signoff | LVK members in em_advocates group | |
# Viewing
| Action | Allowed users | Comments |
| ------ | ------------- | -------- |
| view event | All LVK (all events/superevents); LV-EM/Public (exposed events/superevents? Or just superevents?) | Applies equally to production and test events. Note to self: need to consider event subtypes and permissions on those as well |
| view logs | All LVK (all event/superevent logs); LV-EM/Public (exposed logs only) | Logs will be exposed via a tag ('lv-em' or 'public'); files associated with exposed logs will also be exposed | |
| view voevents | All LVK (all voevents); not sure about LV-EM or public | Currently, all VOEvents are viewable to anyone who can view the event|
| view emobservations | All LVK (all emobservations); not sure about LV-EM or public | Currently, all EMObservations are viewable to anyone who can view the event |
# Main questions
1. Who can add/remove which labels? Or should all LVK users be able to add/remove all labels?
2. Who can expose/hide events and superevents?
3. Who can expose/hide logs with the 'lv-em' and 'public' tags?
4. Does exposing a superevent to external users mean that we should expose all of the individual events as well?
5. Who can confirm superevents as GWs?Move superevents branch onto production GraceDBhttps://git.ligo.org/computing/gracedb/server/-/issues/18Change pipeline names for LIB and gstlal-spiir2018-09-19T15:13:53ZTanner PrestegardChange pipeline names for LIB and gstlal-spiirRequest from Reed Essick on January 20, 2017 (from https://bugs.ligo.org/redmine/issues/5043)
> In all our publications and internal documents, the pipeline is referred to as "oLIB." Therefore, it is the name "oLIB" that should be assoc...Request from Reed Essick on January 20, 2017 (from https://bugs.ligo.org/redmine/issues/5043)
> In all our publications and internal documents, the pipeline is referred to as "oLIB." Therefore, it is the name "oLIB" that should be associated with significance estimates and be allowed to create events in GraceDb. The name "LIB" commonly refers to the parameter estimation follow-up done for all burst events. While oLIB uses the LIB pipeline, they are nonetheless separate concepts. LIB PE results do not contain significance estimates in the same way that LALInference PE results do not.
>
> To minimize/mitigate possible confusion (which appears to be common), we propose changing the pipeline name in GraceDb. However, this will have many repercussions which we should carefully consider. An incomplete list includes
>
> * the need to update all historical events in GraceDb to follow the new nomenclature
> * the need to update all LVAlert nodes so they follow the new nomenclature
> * the need to update all follow-up processes so they listen to the new LVAlert nodes
>
> This change will almost certainly have to wait until a break between observing runs.
Request from Qi Chu on July 9, 2018 (from https://bugs.ligo.org/redmine/issues/6191)
> Dear Tanner,
>
> I would like to request the name for the SPIIR pipeline on the gracedb to be changed to "spiir" in order to remove the possible confusion that triggers from this pipeline are dependent on the that of gstlal pipeline. The connection with the gstlal pipeline is that the code of this pipeline is packed in the gstlal dev packages.
>
> Cheers!Readiness for second OPA testhttps://git.ligo.org/computing/gracedb/server/-/issues/20Flip between images that have the same tag2024-01-30T16:51:24ZTanner PrestegardFlip between images that have the same tagStarted in 2014. Copied from redmine (https://bugs.ligo.org/redmine/issues/1156)
> Hi Branson,
>
> I have two feature requests for the lightboxes that are displayed in GraceDb for uploaded images. See <https://gracedb.ligo.org/events/...Started in 2014. Copied from redmine (https://bugs.ligo.org/redmine/issues/1156)
> Hi Branson,
>
> I have two feature requests for the lightboxes that are displayed in GraceDb for uploaded images. See <https://gracedb.ligo.org/events/view/T81925>.
>
> The first request is for the pop-up to have an opaque white background, to improve readability. The transparent backgrounds make it difficult to read the text on the png sky maps.
>
> The second request is to add the ability to flip between images that belong to the same tag or group. This event has two sky maps, one from BAYESTAR and one from the full MCMC. It would be very handy if it was possible to flip between them when inside the popup.
>
> Thank you!
> Leohttps://git.ligo.org/computing/gracedb/server/-/issues/26Visualization issues with EMBB2019-04-01T14:32:47ZTanner PrestegardVisualization issues with EMBBStarted on April 21, 2016. Copied from redmine (https://bugs.ligo.org/redmine/issues/4053)
I (Alex) received a report from Peter Shawan (pshawhan@umd.edu) regarding visualization issues with the EM Bulletin Board:
> I see what you mean...Started on April 21, 2016. Copied from redmine (https://bugs.ligo.org/redmine/issues/4053)
I (Alex) received a report from Peter Shawan (pshawhan@umd.edu) regarding visualization issues with the EM Bulletin Board:
> I see what you mean about Skymap Viewer: it seems to display a different set of tiles when I select the GOTO box; whatever the previously displayed set was, I think. For instance, if I view the most recent (top) skymap from https://gracedb.ligo.org/events/view/G211117 and Show Bulletin Board, then de-select GOTO, de-select the last LOFAR-TKSP, and then select GOTO, it displays the tiles from that LOFAR-TKSP set. That's not the only problem, though. The selection box for the last EWE set actually displays the tiles from the middle LOFAR-TKSP set. My hunch is that this is a bug activated by the EWE entry with N_regions=0, but that is just a hunch.
I was able to reproduce the problem by following the steps below:
* Alternating the last two checkboxes in the bulletin board appear to turn on/off the same visualization layer. The color-coding for the layers is definitely incorrect, though I don't know (at first glance) which dataset is being rendered incorrectly.
* As of this posting, I have not observed the bug in other events so I need to determine the commonality in other events.
* Also, users have reported in the same email thread that visualization is slow to render.
I have uploaded the email thread to this ticket and will update it as new reports come in.[Re__GOTO_team_observations_with_SWASP_in_GraceDB.rtf](/uploads/9a517fab2354420f746f362a694883dc/Re__GOTO_team_observations_with_SWASP_in_GraceDB.rtf)https://git.ligo.org/computing/gracedb/server/-/issues/27Cannot load gracedb in iframe2022-08-03T18:19:37ZTanner PrestegardCannot load gracedb in iframeCreated by Chad Hanna on September 30, 2016. Copied from redmine ()
There is probably a good reason for this, but I see:
Refused to display 'https://gracedb.ligo.org/latest/?query=gstlal' in a frame because an ancestor violates the fol...Created by Chad Hanna on September 30, 2016. Copied from redmine ()
There is probably a good reason for this, but I see:
Refused to display 'https://gracedb.ligo.org/latest/?query=gstlal' in a frame because an ancestor violates the following Content Security Policy directive: "frame-ancestors 'none'" in one of my local pages. I would like to embed gracedb with a fixed set of queries into another site. If it is possible to change the Security Policy directive to allow this, that would be swell.https://git.ligo.org/computing/gracedb/server/-/issues/28Images attached to GraceDb pages are not cached2022-03-22T18:22:35ZTanner PrestegardImages attached to GraceDb pages are not cachedCreated January 6, 2017 by Leo Singer. Copied from redmine (https://bugs.ligo.org/redmine/issues/4984)
I noticed that none of the images attached to a GraceDb are cached. Since they are versioned and have unique and permanent filenames,...Created January 6, 2017 by Leo Singer. Copied from redmine (https://bugs.ligo.org/redmine/issues/4984)
I noticed that none of the images attached to a GraceDb are cached. Since they are versioned and have unique and permanent filenames, there is no reason not to let the user's browser cache them. This would reduce bandwidth by a lot for frequently viewed events. For example, the event page for GW170104 pulls down almost 40 MB of resources! Most of those should be cached.