GraceDB Server issueshttps://git.ligo.org/computing/gracedb/server/-/issues2023-07-18T08:53:16Zhttps://git.ligo.org/computing/gracedb/server/-/issues/292Improve ingestion of Burst cWB upload. (ingest chirp mass)2023-07-18T08:53:16ZRoberto DePietriImprove ingestion of Burst cWB upload. (ingest chirp mass)Ingest from cWB the additional information:
SOLVED BY MERGE REQUEST: https://git.ligo.org/computing/gracedb/server/-/merge_requests/134
- new database variable for MultiBurst [strain,mchirp,hoft,code]
- update the translator to fix the...Ingest from cWB the additional information:
SOLVED BY MERGE REQUEST: https://git.ligo.org/computing/gracedb/server/-/merge_requests/134
- new database variable for MultiBurst [strain,mchirp,hoft,code]
- update the translator to fix the ingestion problems
- update dictionary return by the api
- update visualization
Provieded trigger examples:
* BBH: [G1064199](https://gracedb-playground.ligo.org/events/G1064199/view/), event_time=segment\[0\]+chirp\[7\]=1369177046.0+156.851562=1369177202.851562
* AllSky: [G1064211](https://gracedb-playground.ligo.org/events/G1064211/view/), event_time=time\[0\]=1369177488.7303
Roberto: The format it is ok, and the injection of new and legacy triggers works.
============. ORIGINAL REQUEST ==========
- “**chirp mass**”
- change the definition of “event time” of Burst-cWB-BBH
- "**hoft version**" to ingest the channel provided in "trigger.txt"
- instead of the d
-instead of the "**#significance based on the last day**" we should use "**#significance based on the last week**"
We should add the label additional labels: **cWB_XP** and **cWB_2G**.
cWB is providing trigger.txt file with the parameters of the reconstructed event.
Each string in this file is describing a parameter or an array of parameters.
For example, the chirp string has an array of 9 parameters chirp[0:8], where
- chirp[1] is the reconstructed chirp mass
- chirp[7] is the CBC merger time [s] relative to the start of the analysis segment
which is segment[0] in the corresponding segment string in trigger.txt
The array time[0:1] gives the peak time of the event in L1 (time[0]) and H1 (time[1])
The difference between these two gives the measured time-of-flight between the detectors.[Example_description__CWB.rtf](/uploads/6e76da959e6a7b7f2899bead30c09129/Example_description__CWB.rtf)
Currently, time[0], which is the peak time of the event, is used by GWcelery as the “Event time”.
I think it will be wrong to hack the trigger.txt file changing the definition of time[0] to
be the merger time for cWB BBH search. Instead, GWcelery should use
BBH search
- “event time” = segment[0]+chirp[7]
- “peak time" = time[0]
- “**chirp mass**” = chirp[1]
All-sky search
- “event time” = time[0]
- “peak time" = time[0]
- “**chirp mass**” = 0 (not defined for all-sky search)
RELATED issue: https://git.ligo.org/emfollow/gwcelery/-/issues/579https://git.ligo.org/computing/gracedb/server/-/issues/254"Cannot resolve keyword..." query error2023-07-17T15:17:28ZAlexander Pace"Cannot resolve keyword..." query errorA user this afternoon repeatedly attempted to query events using `gracedb-client` for (what I assume was supposed to be) `FAR > 1e-20 gpstime: 899999000.0 .. 999999999.9`, but accidentally (?) put the `gpstime: ....` query in the `orderb...A user this afternoon repeatedly attempted to query events using `gracedb-client` for (what I assume was supposed to be) `FAR > 1e-20 gpstime: 899999000.0 .. 999999999.9`, but accidentally (?) put the `gpstime: ....` query in the `orderby=` keyword argument. I'll paste the traceback at the end of this post.
Turns out if i put any value in the `orderby=` field that doesn't correspond to a valid db column, then it throws up an error. We should add some error trapping to catch that and return a 400 error.
```
Internal Server Error: /api/events/
FieldError at /api/events/
Cannot resolve keyword 'gpstime: 899999000.0 .. 999999999.9' into field. Choices are: coincinspiralevent, created, embbeventlog, emobservation, eventlog, far, gpstime, graceid, grbevent, group, group_id, id, instruments, labelling, labels, lalinferenceburstevent, likelihood, mlyburstevent, multiburstevent, nevents, offline, perms, pipeline, pipeline_id, pipeline_preferred, pipeline_preferred_id, reporting_latency, search, search_id, signoff, siminspiralevent, singleinspiral, submitter, submitter_id, superevent, superevent_id, superevent_preferred_for, voevent
Request Method: GET
Request URL: http://gracedb-dev1.ligo.org/api/events/?query=FAR+%3E+1e-20&sort=gpstime%3A+899999000.0+..+999999999.9
Django Version: 3.2.16
Python Executable: /usr/bin/python3
Python Version: 3.7.3
Python Path: ['/usr/local/bin', '/usr/local/lib/python3.7/dist-packages', '/app/gracedb_project', '/usr/lib/python37.zip', '/usr/lib/python3.7', '/usr/lib/python3.7/lib-dynload', '/usr/lib/python3/dist-packages', '/app/gracedb_project', '/app/gracedb_project/gracedb', '/usr/local/lib/python3.7/dist-packages/IPython/extensions']
Server time: Wed, 15 Feb 2023 21:07:00 +0000
Installed Applications:
['django.contrib.auth',
'django.contrib.admin',
'django_ses',
'django.contrib.contenttypes',
'user_sessions',
'django.contrib.sites',
'django.contrib.staticfiles',
'django.contrib.messages',
'alerts',
'annotations',
'api',
'core',
'events',
'ligoauth',
'search',
'superevents',
'rest_framework',
'guardian',
'django_twilio',
'django_extensions',
'django.contrib.sessions',
'computedfields',
'django_postgres_vacuum']
Installed Middleware:
['django.middleware.cache.UpdateCacheMiddleware',
'core.middleware.maintenance.MaintenanceModeMiddleware',
'events.middleware.PerformanceMiddleware',
'core.middleware.accept.AcceptMiddleware',
'core.middleware.api.ClientVersionMiddleware',
'core.middleware.api.CliExceptionMiddleware',
'django.middleware.common.CommonMiddleware',
'core.middleware.proxy.XForwardedForMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'user_sessions.middleware.SessionMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'ligoauth.middleware.ShibbolethWebAuthMiddleware',
'ligoauth.middleware.ControlRoomMiddleware',
'django.middleware.cache.FetchFromCacheMiddleware']
Traceback (most recent call last):
File "/usr/local/lib/python3.7/dist-packages/django/core/handlers/exception.py", line 47, in inner
response = get_response(request)
File "/usr/local/lib/python3.7/dist-packages/django/core/handlers/base.py", line 181, in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/usr/local/lib/python3.7/dist-packages/django/views/decorators/cache.py", line 44, in _wrapped_view_func
response = view_func(request, *args, **kwargs)
File "/usr/local/lib/python3.7/dist-packages/django/views/decorators/csrf.py", line 54, in wrapped_view
return view_func(*args, **kwargs)
File "/usr/local/lib/python3.7/dist-packages/django/views/generic/base.py", line 70, in view
return self.dispatch(request, *args, **kwargs)
File "/usr/local/lib/python3.7/dist-packages/rest_framework/views.py", line 509, in dispatch
response = self.handle_exception(exc)
File "/usr/local/lib/python3.7/dist-packages/rest_framework/views.py", line 469, in handle_exception
self.raise_uncaught_exception(exc)
File "/usr/local/lib/python3.7/dist-packages/rest_framework/views.py", line 480, in raise_uncaught_exception
raise exc
File "/usr/local/lib/python3.7/dist-packages/rest_framework/views.py", line 506, in dispatch
response = handler(request, *args, **kwargs)
File "/app/gracedb_project/gracedb/api/v1/events/views.py", line 402, in get
events = events.order_by(sort).select_subclasses()
File "/usr/local/lib/python3.7/dist-packages/django/db/models/query.py", line 1149, in order_by
obj.query.add_ordering(*field_names)
File "/usr/local/lib/python3.7/dist-packages/django/db/models/sql/query.py", line 2016, in add_ordering
self.names_to_path(item.split(LOOKUP_SEP), self.model._meta)
File "/usr/local/lib/python3.7/dist-packages/django/db/models/sql/query.py", line 1563, in names_to_path
"Choices are: %s" % (name, ", ".join(available)))
Exception Type: FieldError at /api/events/
Exception Value: Cannot resolve keyword 'gpstime: 899999000.0 .. 999999999.9' into field. Choices are: coincinspiralevent, created, embbeventlog, emobservation, eventlog, far, gpstime, graceid, grbevent, group, group_id, id, instruments, labelling, labels, lalinferenceburstevent, likelihood, mlyburstevent, multiburstevent, nevents, offline, perms, pipeline, pipeline_id, pipeline_preferred, pipeline_preferred_id, reporting_latency, search, search_id, signoff, siminspiralevent, singleinspiral, submitter, submitter_id, superevent, superevent_id, superevent_preferred_for, voevent
Request information:
USER: lorena.magana-zertuche@ligo.org
GET:
query = 'FAR > 1e-20'
sort = 'gpstime: 899999000.0 .. 999999999.9'
POST: No POST data
FILES: No FILES data
```
Note I changed gracedb--> gracedb-dev1 to prevent error emails if someone clicks the link.
**Edit:** in the client code, the kwarg is `orderby=`, but when the form is submitted, it's `sort=` and that's the variable on the server-side.O4 Debugging and Improvementshttps://git.ligo.org/computing/gracedb/server/-/issues/319Fermi, Swift external triggers not being received from IGWN alerts2023-07-10T16:33:09ZKeith ThorneFermi, Swift external triggers not being received from IGWN alerts## Description of problem
Both Livingston and Hanford control-rooms are using the the igwn-alerts through scimma to get alerts for IFO stand down, etc.
We are getting events from gracedb.superevent and gracedb.test_snews. But we are no...## Description of problem
Both Livingston and Hanford control-rooms are using the the igwn-alerts through scimma to get alerts for IFO stand down, etc.
We are getting events from gracedb.superevent and gracedb.test_snews. But we are not receiving any Fermi and Swift events (from gracedb.external_fermi, gracedb.external_swift streams)
## Expected behavior
Fermi and Swift events that are retrieved by polling the GraceDB database are not seen as events from igwn-alert
## Context/environment
Using igwn-alert conda environment with scimma credentialshttps://git.ligo.org/computing/gracedb/server/-/issues/317Document meaning of "coherence"2023-07-04T14:53:10ZJacopo TissinoDocument meaning of "coherence"I was looking at the coherence report in the superevent page; as far as I can tell there is no reference to somewhere this quantity is defined; I've looked in the gracedb page, the gracedb docs, the ligo.skymap docs.
The closest thing I ...I was looking at the coherence report in the superevent page; as far as I can tell there is no reference to somewhere this quantity is defined; I've looked in the gracedb page, the gracedb docs, the ligo.skymap docs.
The closest thing I found was in the docs for [`ligo-skymap-stats`](https://lscsoft.docs.ligo.org/ligo.skymap/tool/ligo_skymap_stats.html),
where however it's only stated that `log_bci` is the "natural log Bayes factor, coherent vs. incoherent".
From the perspective of a new user, there seems to be no way to find out what "coherence" means in this context besides asking someone.
Therefore, I think it would be useful to have somewhere a reference to section V.C in [Veitch and Vecchio 2010](http://arxiv.org/abs/0911.3820) or a page with a summarized discussion of its contents.
I'm opening this issue here since I think that the GraceDB page is the obvious candidate for where to include this information, but feel free to redirect me if this is not the case.https://git.ligo.org/computing/gracedb/server/-/issues/316actually disable error emails for 429 rate limits2023-06-28T19:46:56ZAlexander Paceactually disable error emails for 429 rate limitshttps://git.ligo.org/computing/gracedb/server/-/issues/311There is no migration that create EARLYWARNING label2023-06-23T17:43:50ZRoberto DePietriThere is no migration that create EARLYWARNING labelA restart of gracedb from an empty database does not create the EarlyWarning label.A restart of gracedb from an empty database does not create the EarlyWarning label.https://git.ligo.org/computing/gracedb/server/-/issues/314Typo in "preferred event information" panel2023-06-21T14:35:04ZJacopo TissinoTypo in "preferred event information" panelThere is a typo in the "Preferred Event Information" panel: "Chirp" is misspelled as "Chrip".
![Screenshot_from_2023-06-21_16-11-02](/uploads/e68aceb59fe21daae4cc4546be9cf3ac/Screenshot_from_2023-06-21_16-11-02.png)
I hope this is the ...There is a typo in the "Preferred Event Information" panel: "Chirp" is misspelled as "Chrip".
![Screenshot_from_2023-06-21_16-11-02](/uploads/e68aceb59fe21daae4cc4546be9cf3ac/Screenshot_from_2023-06-21_16-11-02.png)
I hope this is the right repository to make this issue, apologies otherwise.https://git.ligo.org/computing/gracedb/server/-/issues/231Request for information needed to compute fluence in IGWN-Alerts2023-06-13T16:36:33ZCody MessickRequest for information needed to compute fluence in IGWN-AlertsThe fluence for burst alerts is currently computed using information in the event file here: https://git.ligo.org/computing/gracedb/server/-/blob/master/gracedb/annotations/voevent_utils.py#L574-643
Would it be possible to either comput...The fluence for burst alerts is currently computed using information in the event file here: https://git.ligo.org/computing/gracedb/server/-/blob/master/gracedb/annotations/voevent_utils.py#L574-643
Would it be possible to either compute the fluence on the server side and include it in burst igwn-alerts or to include the information needed to compute fluence? I'm not sure if there's a reason to go with one over the other.
This is needed for emfollow/gwcelery!857.Critical Path O4 Developmenthttps://git.ligo.org/computing/gracedb/server/-/issues/308Restrict source probability column to pSource on run summary page2023-06-02T18:07:27ZThomas DentRestrict source probability column to pSource on run summary pageCurrently the O4 public event display https://gracedb.ligo.org/superevents/public/#O4 includes 'HasMassGap' as a source probability if nonzero. However, there is no longer a 'MassGap' source class or category, and 'HasMassGap' is a poss...Currently the O4 public event display https://gracedb.ligo.org/superevents/public/#O4 includes 'HasMassGap' as a source probability if nonzero. However, there is no longer a 'MassGap' source class or category, and 'HasMassGap' is a possible _property_ of a source if the source has one or more BH components. The calculation for HasMassGap is quite different from the previous O3 p(MG) calculation, and if HasMassGap is >0 then the total probability will add up to more than 100% including the current source types/classes (BNS, NSBH, BBH, Terr), since events in the NSBH and BBH classes can have MassGap components.
Request is to show only the pBNS, pNSBH, pBBH and pTerr probabilities, which together now add up to 100%, in the 'possible source (probability)' column.publish the new public alerts pageAlexander PaceAlexander Pacehttps://git.ligo.org/computing/gracedb/server/-/issues/309burst superevent skymaps on the public alerts page2023-06-02T15:04:31ZAlexander Paceburst superevent skymaps on the public alerts page@roberto.depietri: for the case of burst events (olib, cwb), is the skymap image always going to be `{olib, cwb}.png` AND tagged as `sky_loc`?
And is that the nomenclature for O3, ER15, and O4?@roberto.depietri: for the case of burst events (olib, cwb), is the skymap image always going to be `{olib, cwb}.png` AND tagged as `sky_loc`?
And is that the nomenclature for O3, ER15, and O4?publish the new public alerts pageAlexander PaceAlexander Pacehttps://git.ligo.org/computing/gracedb/server/-/issues/303Make it easier to distinguish significant from low-significance alerts on the...2023-06-02T15:04:30ZViola SordiniMake it easier to distinguish significant from low-significance alerts on the gracedb public page## Description of feature request
I was wondering if it would be possible and interesting to make it easier visually to distinguish significant from low-significance alerts on the gracedb public alerts page.
## Use cases
It can be us...## Description of feature request
I was wondering if it would be possible and interesting to make it easier visually to distinguish significant from low-significance alerts on the gracedb public alerts page.
## Use cases
It can be useful to easily determine which alerts are significant, especially given that the page will be crowded.
## Benefits
<!-- Describe the benefits of adding this feature -->
## Drawbacks
## Suggested solutions
We could have the category appear somehow, or have two separate list, or different colors..publish the new public alerts pageAlexander PaceAlexander Pacehttps://git.ligo.org/computing/gracedb/server/-/issues/216Superevents: show preferred event(s) by pipeline2023-05-31T11:35:52ZAlexander PaceSuperevents: show preferred event(s) by pipelinevia the [AllSky LVK session](https://docs.google.com/document/d/1_EJWjWSsVbSG-ayvUGh61o0ITH0E-QCjdiwN_g6zU90/edit#heading=h.u1fpy3azpe8y):
> Pipelines must be able to identify a single preferred trigger if multiple have been uploaded to...via the [AllSky LVK session](https://docs.google.com/document/d/1_EJWjWSsVbSG-ayvUGh61o0ITH0E-QCjdiwN_g6zU90/edit#heading=h.u1fpy3azpe8y):
> Pipelines must be able to identify a single preferred trigger if multiple have been uploaded to GraceDB
This could be as simple as having a table on a superevent landing page that scrapes the min-far/snr candidate for each pipeline and gives a link.
Alternatively, there could be a dedicated db table (`superevent_pipelinepreferred` or something like that) where each pipeline has its row with a foreign key entry that links to a pipeline's event. I think this is a valid approach that I can implement, as it would also return preferred events in igwn-alerts and API responses. The question there is, how does that table get populated?
For reference, there is no internal logic for defining a preferred event _in GraceDB_. `GWCelery` picks the preferred event.
1) Should the responsibility for defining a pipeline's preferred event be part of the pipeline? So at upload time, there could be an extra API call... `client.set_as_pipeline_preferred(superevent_id, pipeline, event_id`. The issue for doing this would be defining new groups and permissions. Or, if a user/robot has permission to populate a pipeline, then they can choose preferred events.
2) Have `GWCelery` (who is receiving alerts and filtering events already) by FAR/SNR and pipeline define it. This could be part of the superevent manager's logic. This kind of seems to be the natural choice to me.
3) Have `GraceDB` pick it. This requires more logic and selection criteria to be implemented and updated as the subject to the CBC and low-latency group's caprice. Then external groups need to define what the individual preferred selection criteria.
Personally I'm in favor of #2 (having the superevent manager choose the pipeline preferred event) as it is most parallel with what is being done currently.
Tagging some relevant parties:
@ian-harry, @erik-katsavounidis, @shaon.ghosh, @roberto.depietriCritical Path O4 DevelopmentAlexander PaceAlexander Pacehttps://git.ligo.org/computing/gracedb/server/-/issues/304(minor) Pipelines tab in gracedb still mentions O32023-05-23T14:53:53ZViola Sordini(minor) Pipelines tab in gracedb still mentions O3The Pipelines tab of the gracedb page for logged in users is still quoting O3 in "The EM advocate schedule for O3 is here" - although the link to the roster is correctly pointing to the RRT google sheet (modulo the discussions about usin...The Pipelines tab of the gracedb page for logged in users is still quoting O3 in "The EM advocate schedule for O3 is here" - although the link to the roster is correctly pointing to the RRT google sheet (modulo the discussions about using google docs). I realise this is really minor, but I noticed it so I thought I would report it.https://git.ligo.org/computing/gracedb/server/-/issues/294RRT Table: "S" vs "GW" in GCN Circular Link2023-05-22T19:45:41ZAlexander PaceRRT Table: "S" vs "GW" in GCN Circular Link@keita.kawabe @sushant.sharma-chaudhary
I was fixing GraceDB's [public alerts page](https://gracedb.ligo.org/superevents/public/O3/) for O4 and I noticed a discrepancy between the link URL for GCN Circulars between the public alerts pag...@keita.kawabe @sushant.sharma-chaudhary
I was fixing GraceDB's [public alerts page](https://gracedb.ligo.org/superevents/public/O3/) for O4 and I noticed a discrepancy between the link URL for GCN Circulars between the public alerts page and the RRT table.
Both links have the same URL prefix (`https://gcn.gsfc.nasa.gov/other/`). However on the public alerts page, the circular file name has the `GW` prefix, while it begins with `S` for the RRT table.
Example: for [S200316bj](https://gracedb.ligo.org/superevents/S200316bj/view/), the circular URL is correctly [`https://gcn.gsfc.nasa.gov/other/GW200316bj.gcn3`](https://gcn.gsfc.nasa.gov/other/GW200316bj.gcn3).
The RRT Table shows the circular URL for [S230502m](https://gracedb-test.ligo.org/superevents/S230502m/view/) as `https://gcn.gsfc.nasa.gov/other/S230502m.gcn3`.
Is this an oversight in the RRT table or a change for O4 that I need to reflect in the public alerts page?Critical Path O4 Developmenthttps://git.ligo.org/computing/gracedb/server/-/issues/305Detector State for active instruments2023-05-22T18:18:50ZBrian O'ReillyDetector State for active instruments![Screenshot_2023-05-22_at_12.30.37_PM](/uploads/081e7473df43e2433e3ab08e6dc937fc/Screenshot_2023-05-22_at_12.30.37_PM.png)
The "Overall state of all detectors" being shown as "bad" has already led to some questions. This line should be...![Screenshot_2023-05-22_at_12.30.37_PM](/uploads/081e7473df43e2433e3ab08e6dc937fc/Screenshot_2023-05-22_at_12.30.37_PM.png)
The "Overall state of all detectors" being shown as "bad" has already led to some questions. This line should be removed or at least the wording should be changed, especially given that it will just be L1 and H1 for a few months.https://git.ligo.org/computing/gracedb/server/-/issues/299RRT view should include t_0, not t_end2023-05-22T13:09:43ZPeter ShawhanRRT view should include t_0, not t_endI noticed last night that the RRT view includes the `t_end` value for the superevent. However, `t_end` is **not** the time of the GW signal; it is the ending time of the superevent's time window, which is typically 1 second after the GW ...I noticed last night that the RRT view includes the `t_end` value for the superevent. However, `t_end` is **not** the time of the GW signal; it is the ending time of the superevent's time window, which is typically 1 second after the GW signal time (for CBC events). The RRT view should be changed to display `t_0` (*) instead of `t_end`. I will email Sushant to alert him to this directly; I can't seem to get his user ID to pop up here using `@<name>`.
(*) In fact, `t_0` is not guaranteed to be the time of the preferred event either, it seems; I think it is set for the first preferred event and not updated if some other event becomes the preferred event. I say this based on some recent examples on gracedb-playground: https://gracedb-playground.ligo.org/superevents/S230516ea/view/, https://gracedb-playground.ligo.org/superevents/S230516ep/view/ . But the time differences are typically at the milliseconds level, so `t_0` should normally be good enough.https://git.ligo.org/computing/gracedb/server/-/issues/300navbar css breaks for alert and pipeline management pages2023-05-22T13:09:33ZAlexander Pacenavbar css breaks for alert and pipeline management pages![Screen_Shot_2023-05-18_at_7.57.12_AM](/uploads/8f43bb5c865d37eff88d195de08fb795/Screen_Shot_2023-05-18_at_7.57.12_AM.png)
the css for the `btn-sm` buttons further down on the page is taking priority for some reason. fixed by https://g...![Screen_Shot_2023-05-18_at_7.57.12_AM](/uploads/8f43bb5c865d37eff88d195de08fb795/Screen_Shot_2023-05-18_at_7.57.12_AM.png)
the css for the `btn-sm` buttons further down on the page is taking priority for some reason. fixed by https://git.ligo.org/computing/gracedb/server/-/commit/38ac7269494411fe3488dd4cdcdaad6e0329bca7https://git.ligo.org/computing/gracedb/server/-/issues/296All links/versions of `initial.data` external VOEvent file point to original ...2023-05-17T11:46:48ZBrandon PiotrzkowskiAll links/versions of `initial.data` external VOEvent file point to original file## Description of problem
Currently all links of the VOEvent files `initial.data` point to the original file, regardless of which file or log being referenced
![Screenshot_2023-05-10_at_2.53.08_PM](/uploads/43c17fc38586596217bef9c956c78...## Description of problem
Currently all links of the VOEvent files `initial.data` point to the original file, regardless of which file or log being referenced
![Screenshot_2023-05-10_at_2.53.08_PM](/uploads/43c17fc38586596217bef9c956c7809a/Screenshot_2023-05-10_at_2.53.08_PM.png)
From: https://gracedb.ligo.org/events/E406825/files/
This prevents us from checking and downloading any of the files, except for the first one.
## Expected behavior
We expect these to be versioned properly as all other files are
## Steps to reproduce
Upload external event via `create_event` and then append using `replace_event`.
## Context/environment
All instances of gracedb/gwcelery
## Suggested solutions
Keep track of versions and fix links to use the correct version.O4 Debugging and Improvementshttps://git.ligo.org/computing/gracedb/server/-/issues/268Public and private facing information in per-pipeline preferred event table2023-05-12T17:42:44ZRyan MageePublic 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](https://git.ligo.org/cbc/action_items/-/issues/40#note_663222) from the LVK ...## 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](https://git.ligo.org/cbc/action_items/-/issues/40#note_663222) 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.Critical Path O4 Developmenthttps://git.ligo.org/computing/gracedb/server/-/issues/284RRT view: cWB BBH is displayed as unmodelled burst2023-05-11T21:21:29ZKeita KawabeRRT view: cWB BBH is displayed as unmodelled burstAs of April/21/2023 on gracedb-playground, cWB BBH search is displayed as "burst (unmodelled)" in the RRT view while the expected behavior is that cWB BBH events are displayed in the same row as CBC events. It's OK to leave it as is for ...As of April/21/2023 on gracedb-playground, cWB BBH search is displayed as "burst (unmodelled)" in the RRT view while the expected behavior is that cWB BBH events are displayed in the same row as CBC events. It's OK to leave it as is for ER15, but this needs to be fixed for O4.
I don't know if cWB BBH search group is changed to CBC in the future, but until/unless it's done this will continue to be an issue.
For example, in https://gracedb-playground.ligo.org/superevents/S230421em/view/ the preferred event G1016967 is cWB BBH, but it's in "burst (unmodelled)" row.
![Screenshot_2023-04-21_071208](/uploads/5b692441331238d82c3e3bf3719a4216/Screenshot_2023-04-21_071208.png)
![image](/uploads/8b6c5da31e2de3ae48dce465bb67c9cf/image.png)O4 Debugging and Improvements