Reports 1-1 of 1 Clear search Modify search
Virgo Runs (O3)
Cleva, Kefelian - 9:48 Wednesday 14 August 2019 (46663) Print this report

# Unlock at 6H49MN47SEC_UTC

I (Fred)  am responsible for  this unlock while we were in the atrium for locking the master laser frequency monitor (MLFM). Beside this light intervention I went at the rear of the master laser crate in order to plug a hole in the wooden box of the MLFM with some tape. IIt maybe that I have hit the fiber which bring the ML to the LB (stainless steel shield) although I pay attention to not hit it...

the plot show a raising oscillation on EOM_corr (4 kHz) which ends up in saturation and unlock

The signals ML_FREQ_I_MONIT / ML_FREQ_Q_MONIT refer to the ML frequency noise for frequency below 150 Hz and aboce 150 Hz, (see next entry for the releavant calibrations)




Images attached to this report
Comments to this report:
Cleva, Minazzoli - 16:28 Wednesday 21 August 2019 (46728) Print this report

Likely a coincidence but since the unlock triggered by myself on the 14/08/19 at ~6H40 UTC (46667), we did not notice any fast EOM glitches anymore, as defined in the dedicated monitoring script.

Such a script was developped by David Cohen/ Olivier Minazzoli/ Nicolas Arnaud points towards the events for which EOM_CORR overpasses 0.9 V, in science mode, while IMC_REFL_I_PRE and POST go above 2 V within less than 25 us. Leading to a fast unlock or not.

The script and the associated algorithm are under construction and tests for validation. But still we have noticed a sudden decrease of the so-called "Fast EOM glitches" events since the 14/08 13h56 UTC (fast EOM glitches are the source of fast unlocks when too strong in amplitude).

It is appealing to make the connection of the fast unlocks occurence decrease and the fiber I may have hit (46663).

--> it is worth to better isolate the rolls of the fiber behind the ML crate with some more rigid foam and "rigidly" clamp it on the crate side.

rem.: the reading of the trend of EOM_CORR does not give the same picture, but in there all events are considered, even when not in science mode. Still it seems the peaks density is reduced after the 14/08


Images attached to this comment
minazzoli - 17:01 Tuesday 27 August 2019 (46782) Print this report

Summary: The unlock triggered by Fred on the 14/08/19 at ~6H40 UTC (46667) does not seem to be related to the decrease of the rate of fast EOM glitches, as the decrease seems to have occured before, perhaps between August 4th and 6th.

In the fig. 1, I plot an histrogram of glitches in EOM_CORR(_raw_FS) (while ITF in Science mode) since the beginning of our investigations with David, Nicolas and Fred. Clearly, the rate seems to have decreased before the unlock triggered by Fred.

In the fig.2 and 3, I plot a normalized cumulative distribution of glitches in EOM_CORR with tresholds at 85 and 90% respectively. This gives a rough idea of the moment when the rate of glitches in EOM_CORR started to (dramatically) decrease.

Conclusion: It may be worth investigating what may have happened between August 4th and 6th that could be related to this decrease.

Note: the algorithm used to find the EOM glitches in raw_full is still under validation.


Images attached to this comment
minazzoli - 14:12 Friday 30 August 2019 (46808) Print this report

Upon further investigation, it seems that the last "true" fast EOM glitch (according to a characterization we are still working on) happened on August 9th, at 01:10:00 (GPS = 1249348218).

Moreover, this glitch also corresponds to an unlock (fast unlock), as documented in

INJ people already in the loop.

Fig 1 & 2 show the glitch in Datadisplay. One can see that EOM_CORR is very glitchee, as often before a fast EOM glitch, see e.g.

Images attached to this comment
minazzoli - 15:30 Saturday 31 August 2019 (46814) Print this report

I diplayed the wrong glitch in my previous logbook, which was about 18 second before the glitch that actually led to the unlock.

Fig 1 and 2 show the glitch that led to the unlock.

The comments remain more or less the the same: EOM_CORR is very glitchee prior to the main glitch, with several strong glitches in IMC_REFL -- corresponding to EOM_CORR saturations -- before the final one. This is very common for fast EOM glitches and fast unlocks.

Images attached to this comment
Search Help