GraceDB Server issueshttps://git.ligo.org/computing/gracedb/server/-/issues2023-05-31T11:35:52Zhttps://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/30Filenames truncated on upload2022-08-03T18:22:34ZTanner PrestegardFilenames truncated on uploadAdded by Chad Hanna on February 28, 2017. Copied from redmine (https://bugs.ligo.org/redmine/issues/5236)
Hi,
I am not exactly sure where things are going wrong, but I have found that I cannot upload a long filename without it being tr...Added by Chad Hanna on February 28, 2017. Copied from redmine (https://bugs.ligo.org/redmine/issues/5236)
Hi,
I am not exactly sure where things are going wrong, but I have found that I cannot upload a long filename without it being truncated. See e.g.,
https://gracedb.ligo.org/events/view/G275744
in the log entry where it tries to point to:
https://gracedb.ligo.org/apiweb/events/G275744/files/H1L1V1-GSTLAL_INSPIRAL_PLOTSUMMARY_ALL_LLOID_COMBINED_02_mchirp_acc_frac_scatter_SpinTaylorT4threePo,1
which doesn't exist.https://git.ligo.org/computing/gracedb/server/-/issues/212Metadata for triggers and candidate events2022-03-22T13:38:22ZAlexander PaceMetadata for triggers and candidate eventsThe [charge](https://dcc.ligo.org/LIGO-T2100502) for O4 data product management states:
> Metadata: We define metadata as a set of lightweight data products or links to data products
associated with a given trigger. For example, lightwe...The [charge](https://dcc.ligo.org/LIGO-T2100502) for O4 data product management states:
> Metadata: We define metadata as a set of lightweight data products or links to data products
associated with a given trigger. For example, lightweight data products such as the FAR and SNR or
paths links to parameter estimation posteriors.
I think this can be accomplished with a new table that's linked with a 1:1 foreign key to a g-event. Also from the charge, a proposed format the metadata is below. Inserted as a screenshot since copy/paste from pdf totally gnarled up the formatting.
![Screen_Shot_2022-02-28_at_9.29.27_PM](/uploads/92a3e044fab88bcb533741c5f9604d15/Screen_Shot_2022-02-28_at_9.29.27_PM.png)
I think a first cut would involve taking advantage of postgres' [json datatype](https://www.postgresql.org/docs/9.4/datatype-json.html).
Querying for metadata would have to be implemented too.O4 CBC Improvementshttps://git.ligo.org/computing/gracedb/server/-/issues/140Add VOEvent columns2019-07-11T13:22:52ZTanner PrestegardAdd VOEvent columnsThere are a variety of VOEvent attributes which are required from the user to create a VOEvent and are included in the resulting files, but are **not** saved in the VOEvent database table.
We should
a) Fix this by adding the columns
b)...There are a variety of VOEvent attributes which are required from the user to create a VOEvent and are included in the resulting files, but are **not** saved in the VOEvent database table.
We should
a) Fix this by adding the columns
b) Try to retroactively update VOEvents from their corresponding files