Skip to content

Adding check for fast LOCKLOSS_DRMI -> ACQUIRE_DRMI_1F -> LOCKLOSS transitions

Added some extra conditionals to the history plugin that will check if ISC_LOCK_STATE went from the lockloss state we're interested in (generally between 103-202) to LOCKLOSS_DRMI, then up briefly to ACQUIRE_DRMI_1F before LOCKLOSS. In order to create the refined time plot correctly, the history followup moved before the refine followup in execution order. Additionally, I added a setter to change transition_index to the new values (I also removed the assertions, because they would cause an error whenever this condition was met).

The history plot now checks if the lockloss state was ACQUIRE_DRMI_1F, if the duration in that state was for less than a second, and if the previous state was LOCKLOSS_DRMI. Does not run for LLO as they don't use the LOCKLOSS_DRMI state.

Here is an example of a mislabeled lockloss: https://ldas-jobs.ligo-wa.caltech.edu/~lockloss/index.cgi?event=1263654000

Here is that same lockloss, relabeled: https://ldas-jobs.ligo-wa.caltech.edu/~yannick.lecoeuche/index.cgi?event=1263654000

This should reduce the amount of locklosses with incorrect lockloss states, and will be helpful in properly assessing which states need work with the lockloss summary plots.

Closes #150 (closed)

Edited by Yannick Lecoeuche

Merge request reports

Loading