GraceDB Server issueshttps://git.ligo.org/computing/gracedb/server/-/issues2022-08-03T19:00:09Zhttps://git.ligo.org/computing/gracedb/server/-/issues/68GraceDB instance for lockloss events2022-08-03T19:00:09ZTanner PrestegardGraceDB instance for lockloss eventsCreated on July 3, 2018. Copied from redmine (https://bugs.ligo.org/redmine/issues/6187)
Jamie Rollins is interested in setting up a gracedb instance for tracking lockloss events. Here's a transcript of an email:
> On Thu, Jun 14 2018,...Created on July 3, 2018. Copied from redmine (https://bugs.ligo.org/redmine/issues/6187)
Jamie Rollins is interested in setting up a gracedb instance for tracking lockloss events. Here's a transcript of an email:
> On Thu, Jun 14 2018, Tanner Prestegard <tanner.prestegard@ligo.org> wrote:
>
> > Here's a bit of a brain dump of information and some code links. The actual code is a bit confusing and pretty messy, so I don't know how helpful it will be. In general, for an event, there is a base Event class which has attributes that are present for all events, and then a "sub-event" class which has a different type and additional attributes, depending on the pipeline that submitted it.
>
> Hey, Tanner, thank you very much for this info. This is great.
>
> > Here's a link to the base event class: https://git.ligo.org/lscsoft/gracedb/blob/master/gracedb/events/models.py#L86-147. Each line which assigns something like "Field" or "ForeignKey" is a column in the database for the Event table.
>
> > For LIB events, here's a link to the "sub-event" class: https://git.ligo.org/lscsoft/gracedb/blob/master/gracedb/events/models.py#L890-902.
>
> > Here's an oLIB event json: https://gracedb.ligo.org/apiweb/events/G299534/files/1187734908.99-0.0.json,0. Some additional information, like data analysis group, pipeline, etc. is provided from the method for creating events in gracedb-client.
>
> This looks good. Submitting a json with the existing gracedb client
> would be great.
>
> > Maybe we can create a new "sub-event" type for lockloss events? Off the top of my head, that seems like it might be the easiest solution to leverage the current infrastructure.
>
> Yeah this seems like a reasonable place to start. In the long run it
> might be nice to be able to specify the schemas in a config file, rather
> than being baked in, so that you don't have to patch upstream for
> different schemas.
>
> > Hopefully this is somewhat helpful. If you can come up with some initial ideas for the following, that would be helpful:
>
> * Which attributes a lockloss event should include
> * What type (float, int, char, datetime, foreign key to another object, etc.) each attribute should be
> Here's a brain dump of all the stuff I can think of right now that we
> would want to at least initially track for lock loss events:
>
> * initial event time (float (assuming GPS))
> * refined event time (float (assuming GPS))
> * lock loss state index (int)
> * lock loss state string (str)
> * previous state index (int)
> * previous state string (str)
> In addition to these it would be really great to add arbitrary tags to
> an event that would then be searchable (i.e. query "tag=foo tag=bar").
>
> I'm sure we'll realize that there are other attributes we want to track
> down the line, but we may be able to mostly cover that kind of thing
> with tags for a while.
>
> > *Whether the full picture will include more class definitions than just that of lockloss events
> I'm pretty sure that if we had a database for detector related stuff
> then we would find other things we would want to track with it.
> Glitches are the big thing I can think of now. But at least initially I
> don't want to hamstring getting a lock loss database running by adding
> additional complexity right now. We can add a new event schema down the
> line if need be, yes?
>
> > We'll have to iterate some, but this would be a good start. Take your time on this because I have no time at all to spend on this before the OPA test in 2 weeks.
>
> Yeah this is really great Tanner. Thank you very much. If we can get a
> prototype thing running for us to test that would be truly awesome.
> Please let me know what exactly I can do to help, like contributing
> code.
>
> jamie.