GraceDB instance for lockloss events
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.