GraceDB Server issueshttps://git.ligo.org/computing/gracedb/server/-/issues2019-11-15T19:24:58Zhttps://git.ligo.org/computing/gracedb/server/-/issues/182Ongoing problem of missing notifications from GraceDB2019-11-15T19:24:58ZLeo P. SingerOngoing problem of missing notifications from GraceDBSee original issue, [emfollow/O3break#32](https://git.ligo.org/emfollow/o3break/issues/32).See original issue, [emfollow/O3break#32](https://git.ligo.org/emfollow/o3break/issues/32).https://git.ligo.org/computing/gracedb/server/-/issues/181Inconsistent URLs for logs, tags, and voevents, for events and superevents2019-11-15T00:56:19ZLeo P. SingerInconsistent URLs for logs, tags, and voevents, for events and supereventsEvents and superevents have inconsistent URLs for tags and logs. This is confusing and reduces the opportunities for code reuse in client code.
Events use `log`, `tag`, and `voevent`, **singular**:
* `https://gracedb-test.ligo.org/api/...Events and superevents have inconsistent URLs for tags and logs. This is confusing and reduces the opportunities for code reuse in client code.
Events use `log`, `tag`, and `voevent`, **singular**:
* `https://gracedb-test.ligo.org/api/events/{graceid}/log/`
* `https://gracedb-test.ligo.org/api/events/{graceid}/log/{N}/tag/`
* `https://gracedb-test.ligo.org/api/events/{graceid}/voevent/`
Whereas superevents use `logs`, `tags`, and `voevents`, **plural**:
* `https://gracedb-test.ligo.org/api/superevents/{superevent_id}/logs/{N}`
* `https://gracedb-test.ligo.org/api/superevents/{superevent_id}/logs/{N}/tags/`
* `"https://gracedb-test.ligo.org/api/superevents/{superevent_id}/voevents/`https://git.ligo.org/computing/gracedb/server/-/issues/180Collect better usage statistics2019-10-28T17:00:42ZAlexander PaceCollect better usage statisticsI had a request from Chad if it was reasonable to collect better usage statistics from gracedb and lvalert. This seems totally doable, but would just require some parsing/archiving from the gunicorn access logs. The archiving schema is c...I had a request from Chad if it was reasonable to collect better usage statistics from gracedb and lvalert. This seems totally doable, but would just require some parsing/archiving from the gunicorn access logs. The archiving schema is changing with the new deployment, but it shouldn't be that hard to implement after docker-swarm comes up and running.
Note that this ticket has some overlap with #176, so maybe this can be a "two-birds" thing once I get it running.Alexander PaceAlexander Pacehttps://git.ligo.org/computing/gracedb/server/-/issues/179Remove Classification and Inference sections for burst VOEvents2019-10-25T13:49:19ZLeo P. SingerRemove Classification and Inference sections for burst VOEventsSee emfollow/gwcelery#246.See emfollow/gwcelery#246.https://git.ligo.org/computing/gracedb/server/-/issues/178Implement server-side copying and linking.2019-10-04T17:49:45ZAlexander PaceImplement server-side copying and linking.## Description of feature request
Currently the workflow for adding files (such as skymaps) from `G` events to superevents involves downloading the file from GraceDB, and then re-uploading it to the superevent. This workflow evolved out ...## Description of feature request
Currently the workflow for adding files (such as skymaps) from `G` events to superevents involves downloading the file from GraceDB, and then re-uploading it to the superevent. This workflow evolved out of the inability make items attached to G-events public. Short of drastically changing the server permissions infrastructure, it would be a lot easier to make the copy on the server-side. This might involve symlinking to the existing file, since they're the same anyway? I'll dig into that.
## Use cases
These files are copied by the orchestrator from the preferred event into the superevent before the preliminary GCN is sent out.
## Benefits
This reduces the network traffic back-and-forth between GWCelery and GraceDB. It also reduces the overall number of API calls to GraceDB.
## Drawbacks
I have to be vigilant about respecting GraceDB's versioning system. I also wonder how, if I implement symlinking whether or not the access controls will be respected. GWCelery needs to decide on a filename scheme (like including the gid in filenames in the case where identical files are copied from different events).
## Suggested solutions
After discussing with the group, I think the implementation should look something like:
```
gracedb.migrateFiles(origin_id, destination_id, file_list)
* origin_id (string) - the event or superevent ID of the file origin
* desination_id (string)- the event or superevent ID of the file destination
* origin_filename (tuple or list of tuples) - tuple of strings where the format is (orgin_file_name.ext,version , destination_file_name.ext)
```
Other things to keep in mind:
* there should be logging on the side of the destination event that says the filename (with version), and the origin event.
* there should be logging on the origin event like, "file XXXX copied to SXXXXX"
* This should use GraceDB's existing file ingestion mechanism so the current versioning
This is (obviously) going to require a corresponding change to the API. Also make sure that LVAlerts are sent out for file copies. There should be an LVAlert sent out for the sending/receiving events to the corresponding (event/superevent) nodes. Alexander PaceAlexander Pacehttps://git.ligo.org/computing/gracedb/server/-/issues/177Add superevent fields for RAVEN2019-12-18T03:31:27ZAlexander PaceAdd superevent fields for RAVEN## Description of feature request
This came as a result of the face-to-face discussion at MIT during the week of October 1-4, 2019.
For implementing RAVEN's logic, it was decided to add two new data fields to superevents:
| name | dat...## Description of feature request
This came as a result of the face-to-face discussion at MIT during the week of October 1-4, 2019.
For implementing RAVEN's logic, it was decided to add two new data fields to superevents:
| name | data type | default |
| ------ | ------ | ------ |
| `coinc_far` | float | `null` |
| `em_type` | string | `null` |
## Use cases
RAVEN uses these values for tracking and assigning significance for external (`E`) events.
## Benefits
By explicitly defining the `em_type` it resolves the question as to which `E` event to choose as a "preferred" external event.
## Drawbacks
There's no logic in GraceDB for choosing the preferred external event, or how to choose the `coinc_far` (by design). So this requires additional bookkeeping in RAVEN.
## Suggested solutions
This should be a doable change, but it requires a few changes:
* Add the new data field on the server side
* Add a migration to alter the database for past superevents. (Should there be a script to back-populate this value?
* Modify the [updateSUperevent API call](https://ligo-gracedb.readthedocs.io/en/gracedb-2.4.0/api.html#ligo.gracedb.rest.GraceDb.updateSuperevent) to take in the additional fields.
* Ensure that that [update LVALert](https://gracedb.ligo.org/documentation/lvalert.html#superevent-alerts) gets sent out when these fields are modified.Alexander PaceAlexander Pacehttps://git.ligo.org/computing/gracedb/server/-/issues/176performance page doesn't work on aws2022-08-04T01:53:07ZAlexander Paceperformance page doesn't work on aws## Description of problem
The GraceDB performance page (https://gracedb.ligo.org/performance/) doesn't appear to be working on the AWS implementations (production, test). The tables are there, but they're not being populated with any num...## Description of problem
The GraceDB performance page (https://gracedb.ligo.org/performance/) doesn't appear to be working on the AWS implementations (production, test). The tables are there, but they're not being populated with any numbers. I just noticed this through casual browsing of the website.
## Expected behavior
The table should be populated with values, which it isn't on AWS.
Update: It looks like it's broken on `gracedb-dev2`. I think it's a python3 thing.
## Steps to reproduce
go to https://gracedb.ligo.org/performance/Alexander PaceAlexander Pacehttps://git.ligo.org/computing/gracedb/server/-/issues/175Include psd as part of coinc.xml upload2022-08-04T01:48:31ZAlexander PaceInclude psd as part of coinc.xml upload## Description of feature request
Include a psd as part of the initial event upload (in the `coinc.xml` upload).
## Use cases
The goal would be to reduce the overall time to issue an alert. A few notes:
* @kipp.cannon specifically ...## Description of feature request
Include a psd as part of the initial event upload (in the `coinc.xml` upload).
## Use cases
The goal would be to reduce the overall time to issue an alert. A few notes:
* @kipp.cannon specifically did not include the psd with the initial upload in order to reduce the overall size and thus reduce the latency of the initial trigger.
* @leo-singer noted that the psd is needed to make a skymap, which is needed to to send a GCN.
## Benefits
The advantage would be to reduce the number of transactions with GraceDB, potentially improving reliability and latency. Of course I would want to test this. For reference in this ticket, I am looking at [this event](https://gracedb.ligo.org/events/G351976/view/). The respective sizes of the `coinc.xml` and `psd.xml` files are:
```
-rw-r--r--@ 1 alexander.pace staff 152K Sep 30 09:26 psd.xml.gz
-rw-r--r--@ 1 alexander.pace staff 53K Sep 30 09:25 coinc.xml
```
## Drawbacks
What could we be missing here? I'm brain-dumping questions here:
* Where does this psd information get stored?
* Should there be a new database entry to hold psds?
* Are there size limitations to entries in MySQL/ Amazon Relational Database? Are there different rules for text vs binary?
* What would database performance and reliability be when GstLAL is hitting it with 100kb database entries across 100 different events at the same time.
## Suggested solutions
Another brain-dump:
* Should there be another entry in the `coinc.xml` file along the lines of `has_psd`? This would:
* Give GraceDB's input parser a head's up to read and parse a psd and add it to the database. Absence of this flag would tell GraceDB not to read/ingest the psd, and retain backwards compatibility for older events.
* Have this flag be part of the event info that gets sent out via LVAlert for follow-up processes to check for.
* Should there be a size cap for these? I'm worried about the database ballooning out of control in the long run. Let's have this discussion.
Also pinging @chad-hannaAlexander PaceAlexander Pacehttps://git.ligo.org/computing/gracedb/server/-/issues/174Potential character set issue2019-09-20T15:35:58ZTanner PrestegardPotential character set issueThe development and playground databases should have the correct character sets and collations due to how they were created by Puppet. But the production database was created so long ago that it looks like it has the `latin1` character ...The development and playground databases should have the correct character sets and collations due to how they were created by Puppet. But the production database was created so long ago that it looks like it has the `latin1` character set by default.
It's not posing a problem at present since we have a migration which manually sets the `auth_user` table to use utf8, but I think it would be a good idea to set the database default character set and collation when an opportunity arises.
We'll have to get MySQL command-line access to the production database, then run:
```
ALTER DATABASE <dbname> CHARACTER SET utf8 COLLATE utf8_general_ci;
```
Might be worth testing this (I haven't) and taking a snapshot before doing so.https://git.ligo.org/computing/gracedb/server/-/issues/173Problems handling special characters in Python 32019-09-20T15:33:13ZTanner PrestegardProblems handling special characters in Python 3# Python 2
What we get from the LDAP:
```
sn = 'Budzy\xc5\x84ski'
```
What we pass to the database to be saved:
```
>>> unicode(sn, 'utf-8')
u'Budzy\u0144ski'
```
The contents saved in the MySQL database (table uses UTF-8 encoding):...# Python 2
What we get from the LDAP:
```
sn = 'Budzy\xc5\x84ski'
```
What we pass to the database to be saved:
```
>>> unicode(sn, 'utf-8')
u'Budzy\u0144ski'
```
The contents saved in the MySQL database (table uses UTF-8 encoding):
```
Budzyński
```
# Python 3
What we get from the LDAP:
```
sn = b'Budzy\xc5\x84ski'
```
What we pass to the database to be saved:
```
>>> sn.decode('utf-8')
'Budzyński'
```
The contents saved in the MySQL database (table uses UTF-8 encoding):
```
Budzy?ski
```https://git.ligo.org/computing/gracedb/server/-/issues/172Remove `skymap_type` for VOEvents2019-09-18T17:51:14ZTanner PrestegardRemove `skymap_type` for VOEventsThe `python3` branch includes a few minor changes to the VOEvent file format, including the fact that there won't be any need for the `skymap_type` any longer. We should remove it from the API endpoints for creating VOEvents. I'm not s...The `python3` branch includes a few minor changes to the VOEvent file format, including the fact that there won't be any need for the `skymap_type` any longer. We should remove it from the API endpoints for creating VOEvents. I'm not sure if you want to remove it from the `VOEvent` models - that would remove it for past VOEvents, which might be non-ideal. At least put a comment on the model noting that it's a legacy field.https://git.ligo.org/computing/gracedb/server/-/issues/171Bad file versioning for event replacement2019-09-18T15:28:42ZTanner PrestegardBad file versioning for event replacementWhen replacing an event, there a few problems with file versioning:
* The file version is *not* passed from the API view (`api.v1.events.EventList.put`) to `events.translator.handle_uploaded_data` (see [here](https://git.ligo.org/lscsof...When replacing an event, there a few problems with file versioning:
* The file version is *not* passed from the API view (`api.v1.events.EventList.put`) to `events.translator.handle_uploaded_data` (see [here](https://git.ligo.org/lscsoft/gracedb/blob/master/gracedb/api/v1/events/views.py#L622)). This isn't a problem **only** if the new event file has a different filename.
* `handle_uploaded_data` assumes a file version of 0 for both the new event file **and** the generated files (`event.log`, `coinc.xml`), which is just plain wrong - version 0 of these files was already generated when the event was initially created.https://git.ligo.org/computing/gracedb/server/-/issues/170Remove EMBB event log model2022-08-04T01:46:15ZTanner PrestegardRemove EMBB event log modelThis is a really old data model which I think was at one time a competing model for EM observations? There are literally only 31 of these in the production database, created only between November 11, 2014, and April 20, 2015, and half o...This is a really old data model which I think was at one time a competing model for EM observations? There are literally only 31 of these in the production database, created only between November 11, 2014, and April 20, 2015, and half of them are associated with Test events.
This might also allow us to remove a bunch of noise from the API root, like wavebands and so on.https://git.ligo.org/computing/gracedb/server/-/issues/169firefox fails to download S180814bv bayestar.fits.gz, but OK with bayestar.fi...2019-08-15T19:31:16ZKeita Kawabefirefox fails to download S180814bv bayestar.fits.gz, but OK with bayestar.fits.gz,1I cannot imagine that astronomers are using firefox for followup purposes so this might not be an urgent issue, but I'd appreciate if somebody could investigate.
During RRT for S190814bv, I reported that the size of bayestar.fits.gz VS ...I cannot imagine that astronomers are using firefox for followup purposes so this might not be an urgent issue, but I'd appreciate if somebody could investigate.
During RRT for S190814bv, I reported that the size of bayestar.fits.gz VS bayestar.fits.gz,1 were totally different, and Geoffrey Mo concurred.
After one day the problem still persists for me, but it seems like firefox just fails to download the whole bayestar.fits.gz (it can download bayestar.fits.gz,1).
wget, curl and chrome all worked fine.
The symptom is that using firefox,
https://gracedb.ligo.org/api/superevents/S190814bv/files/bayestar.fits.gz
gives me a smaller file than it should be.
When I restart firefox and download again the file size changes a bit, but it's always ~710000 bytes when the files downloaded by curl, wget or chrome are all identical and are 4563601 bytes.
Combinations of restarting firefox, clearing browser cache, making a new user profile, going into private browser mode, deleting ./mozilla folder and using different computers (one osx, one linux) didn't help.
In the example below, 'Bayestar (1).fits.gz' was downloaded by chrome, everything else was downloaded using firefox. I can read bayestar.fits.gz,1 and 'bayestar (1).fits.gz' using astropy.
```
(base) ~/Downloads$ ls -l bayestar*
-rw-r--r--@ 1 keita.kawabe staff 4563601 Aug 15 11:03 bayestar (1).fits.gz
-rw-rw-rw-@ 1 keita.kawabe staff 711742 Aug 15 11:02 bayestar.fits(1).gz
-rw-rw-rw-@ 1 keita.kawabe staff 711742 Aug 15 11:04 bayestar.fits(2).gz
-rw-rw-rw-@ 1 keita.kawabe staff 711870 Aug 15 11:05 bayestar.fits(3).gz
-rw-rw-rw-@ 1 keita.kawabe staff 711772 Aug 15 11:07 bayestar.fits(4).gz
-rw-rw-rw-@ 1 keita.kawabe staff 711698 Aug 15 11:29 bayestar.fits(5).gz
-rw-rw-rw-@ 1 keita.kawabe staff 711698 Aug 15 11:30 bayestar.fits(6).gz
-rw-rw-rw-@ 1 keita.kawabe staff 711771 Aug 15 11:31 bayestar.fits(7).gz
-rw-rw-rw-@ 1 keita.kawabe staff 711731 Aug 15 08:50 bayestar.fits.gz
-rw-rw-rw-@ 1 keita.kawabe staff 4563601 Aug 15 08:51 bayestar.fits.gz,1
(base) ~/Downloads$ diff bayestar.fits.gz,1 bayestar\ \(1\).fits.gz
(base) ~/Downloads$
```https://git.ligo.org/computing/gracedb/server/-/issues/168Problem establishing secure connection: [SSL: SSLV3_ALERT_BAD_CERTIFICATE] ss...2019-08-01T20:47:56ZMarek SzczepanczykProblem establishing secure connection: [SSL: SSLV3_ALERT_BAD_CERTIFICATE] sslv3 alert bad certificate (_ssl.c:618)I cannot connect to gracedb through python.
- I tried pcdev2, pcdev3, pcdev4, pcdev5.
- I tried ligo-proxy-init with and without '-p' option.
- I tried python2.7 and python3
- It works fine for me on my laptop, but not in CIT
Anybody ...I cannot connect to gracedb through python.
- I tried pcdev2, pcdev3, pcdev4, pcdev5.
- I tried ligo-proxy-init with and without '-p' option.
- I tried python2.7 and python3
- It works fine for me on my laptop, but not in CIT
Anybody could help?
```
[marek.szczepanczyk@ldas-pcdev5 ~]$ ligo-proxy-init marek.szczepanczyk
Your identity: marek.szczepanczyk@LIGO.ORG
Enter pass phrase for this identity:
Creating proxy .................................... Done
Your proxy is valid until: Aug 11 07:29:36 2019 GMT
[marek.szczepanczyk@ldas-pcdev5 ~]$ grid-proxy-info
subject : /DC=org/DC=cilogon/C=US/O=LIGO/CN=Marek Szczepanczyk marek.szczepanczyk@ligo.org
issuer : /DC=org/DC=cilogon/C=US/O=CILogon/CN=CILogon Basic CA 1
identity : /DC=org/DC=cilogon/C=US/O=LIGO/CN=Marek Szczepanczyk marek.szczepanczyk@ligo.org
type : end entity credential
strength : 2048 bits
path : /tmp/x509up_p2847529.file859K3H.1
timeleft : 275:59:58 (11.5 days)
[marek.szczepanczyk@ldas-pcdev5 ~]$ ipython
Python 2.7.5 (default, Jun 20 2019, 16:11:37)
Type "copyright", "credits" or "license" for more information.
IPython 3.2.1 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help -> Python's own help system.
object? -> Details about 'object', use 'object??' for extra details.
In [1]: from ligo.gracedb.rest import GraceDb
In [2]: client = GraceDb()
In [3]: response = client.event('G1234')
---------------------------------------------------------------------------
RuntimeError Traceback (most recent call last)
<ipython-input-3-71dcac91ab4a> in <module>()
----> 1 response = client.event('G1234'
2 )
/usr/lib/python2.7/site-packages/ligo/gracedb/rest.pyc in event(self, graceid)
813 """
814 return self.get(
--> 815 self.templates['event-detail-template'].format(graceid=graceid))
816
817 def events(self, query=None, orderby=None, count=None, columns=None,
/usr/lib/python2.7/site-packages/ligo/gracedb/rest.pyc in templates(self)
610 @property
611 def templates(self):
--> 612 return self.service_info.get('templates')
613
614 @property
/usr/lib/python2.7/site-packages/ligo/gracedb/rest.pyc in service_info(self)
570 # checks whether that version is available on the server
571 try:
--> 572 r = self.request("GET", self._versioned_service_url)
573 except HTTPError as e:
574 # If we get a 404 error, that means that the versioned
/usr/lib/python2.7/site-packages/ligo/gracedb/rest.pyc in request(self, method, url, body, headers, priming_url)
670 priming_url = self._service_url
671 return super(GraceDb, self).request(method, url, body, headers,
--> 672 priming_url)
673
674 def _getCode(self, input_value, code_dict):
/usr/lib/python2.7/site-packages/ligo/gracedb/rest.pyc in request(self, method, url, body, headers, priming_url)
392 response = response.read()
393
--> 394 self.make_request(conn, method, url, body, headers or {})
395 response = self.get_response(conn)
396
/usr/lib/python2.7/site-packages/ligo/gracedb/rest.pyc in make_request(self, conn, *args, **kwargs)
357 msg = "\nERROR \n\n"
358 msg += "Problem establishing secure connection: %s \n\n" % str(e)
--> 359 self.output_and_die(msg)
360
361 def request(self, method, url, body=None, headers=None, priming_url=None):
/usr/lib/python2.7/site-packages/ligo/gracedb/rest.pyc in output_and_die(cls, msg)
473 @classmethod
474 def output_and_die(cls, msg):
--> 475 raise RuntimeError(msg)
476
477 # Given an HTTPResponse object, try to read its content and interpret as
RuntimeError:
ERROR
Problem establishing secure connection: [SSL: SSLV3_ALERT_BAD_CERTIFICATE] sslv3 alert bad certificate (_ssl.c:618)
```https://git.ligo.org/computing/gracedb/server/-/issues/167Add RAVEN fields to VOEvent2020-07-15T18:43:05ZBrandon PiotrzkowskiAdd RAVEN fields to VOEvent## Description of feature request
<!--
--> RAVEN is being approved to send alerts, so we need to add some additional fields to the existing VOEvent to properly communicate with astronomers. These fields are described in https://git.ligo....## Description of feature request
<!--
--> RAVEN is being approved to send alerts, so we need to add some additional fields to the existing VOEvent to properly communicate with astronomers. These fields are described in https://git.ligo.org/emfollow/userguide/merge_requests/65. There are seven additional fields.
`External GCN Notice ID`, `External Alert Type`, and `External Search` are essential and should be required. `Time and Sky Position Coincidence FAR`, `Combined Sky Map`, and `Time Difference` are optional and should be included only if the values are available. `Time Coincidence FAR` needs to be included if the search field of the external event is `GRB` or `SubGRB`, but not if the search is `SNEWS` since that value won't be calculated in that case. If that isn't possible then `Time Coincidence FAR` could be made optional in general. Note that if `Time and Sky Position Coincidence FAR` is available, `Time Coincidence FAR` will alway be available as well.
I can't see any default values that could be set that wouldn't cause confusion.
## Use cases
This template should be used whenever we are creating a VOEvent and `EM_COINC` is present in the superevent's labels.https://git.ligo.org/computing/gracedb/server/-/issues/166Some notifications missing for S190718y2019-07-23T00:46:37ZNicolas ArnaudSome notifications missing for S190718yHi @tanner.prestegard
I made a quick poll this morning during the weekly Virgo DetChar meeting about the receiving of S190718y notifications. There were about 15 people attending that meeting. The results are
* Almost nobody received a...Hi @tanner.prestegard
I made a quick poll this morning during the weekly Virgo DetChar meeting about the receiving of S190718y notifications. There were about 15 people attending that meeting. The results are
* Almost nobody received an e-mail notification.
* About half of the people did not receive the call/text notification they had subscribed to.
Thanks in advance for investigating that issue -- I don't think we had this problem earlier in the run.
Nicolashttps://git.ligo.org/computing/gracedb/server/-/issues/165Add source frame masses and redshift2019-07-15T14:47:51ZPatrick BradyAdd source frame masses and redshift## Description of feature request
<!--
Describe your feature request!
Is it a web interface change? Some underlying feature? An API resource?
The more detail you can provide, the better.
-->
Albert Lazzarini asked: Is it possible to add ...## Description of feature request
<!--
Describe your feature request!
Is it a web interface change? Some underlying feature? An API resource?
The more detail you can provide, the better.
-->
Albert Lazzarini asked: Is it possible to add information to the internal graceDB pages? The additional information that would be helpful is to clearly indicate that the masses listed are in the DETECTOR frame (see screen shot. Also, using the Standard Model, the redshift Z associated with the luminosity distance could also be provided.
## Use cases
<!-- List some specific cases where this feature will be useful -->
Would be useful in both superevents and regular events
## Benefits
<!-- Describe the benefits of adding this feature -->
Would make it easier to know source frame masses now that we are seeing mergers to cosmological distances.
## Drawbacks
<!--
Are there any drawbacks to adding this feature?
Can you think of any ways in which this will negatively affect the service for any set of users?
-->
Needs reasonable parameter estimation.
## Suggested solutions
<!-- Do you have any ideas for how to implement this feature? -->https://git.ligo.org/computing/gracedb/server/-/issues/164Inconsistent HTTP status codes for removing nonexistent labels from 'E' events2019-08-27T15:36:27ZLeo P. SingerInconsistent HTTP status codes for removing nonexistent labels from 'E' eventsIf you try to remove a label that does not exist from an 'E' event, you get a 400 error. If you try to perform this operation on other kinds of events, you get a 404 error, which I think is the correct behavior.
See https://sentry.io/or...If you try to remove a label that does not exist from an 'E' event, you get a 400 error. If you try to perform this operation on other kinds of events, you get a 404 error, which I think is the correct behavior.
See https://sentry.io/organizations/ligo-caltech/issues/1018090875.https://git.ligo.org/computing/gracedb/server/-/issues/163What's on? - Most viewed / trending event page2019-07-10T01:54:43ZNicola De Lillonicola.delillo@ligo.orgWhat's on? - Most viewed / trending event page## Description of feature request
Add a page (with a tab to reach that in the tab-bar) that shows a list of every gravitational wave events detected, but sorted by visualisation (i.e. every time a user logs to the event page). The page c...## Description of feature request
Add a page (with a tab to reach that in the tab-bar) that shows a list of every gravitational wave events detected, but sorted by visualisation (i.e. every time a user logs to the event page). The page could look like a list with simple and clean entries that might be of interested of less regular visitors:
SUPEREVENT_ID PREFERRED_EVENT DATE_TIME FAR MASS1 MASS2 VISUALIZED
Of course one must implement a visualisation counter to produce the VISUALIZED Column
It would be also nice if this page can have a switch button at the top of the the list, between "MOST VISUALIZED" and "TRENDING" event. While "MOST VISUALIZED" would refer to the above list, "TRENDING" list would show the most visualized event at the moment (might be in the last 1 week or 1 mont, two months or 6 months - even better if one can select this for option to shape the list).
The tab name to redirect to this page could be any. At the moment I can suggest "What's on" , "Hall of fame", "Most viewed". But further research and ideas could come later.
## Use cases
Not everybody want to follow or receive all of the alerts. The DB could appear overwhelming for people outside the collaboration of the GW field. Some scientists (both outside and inside the gravitational wave field) might only be interested casually in what is going on with detections. This way they can now follow which one were the most interested events ever or which ones get all the hype in some specific period.
## Benefits
It would keep hyped people inside and outside the gravitational wave field and make the GraceDB more user-friendly and appealing for casual visitors.
## Drawbacks
Not anyone at the moment I can think of
## Acknowledgement
Thank you to Jennifer Wright, trending event idea was from her.