This morning's shift was devoted to three different topics; the first part of the shift was unfortunately impacted a lot by the bad weather, with several unlocks of CARM2MC and WARM.

Topic #1: DRMI DoFs diagonalization

The goal of the shift was to move the diagonalisation of the DRMI degrees of freedom from the sensing to the driving. This should reduce the error signals of the DoFs at the correction level and thus help to (potentially marginally) reduce the contribution of the DRMI degrees of freedom to Hrec.

We had three locks in CARM Null 1f in which we wanted to test the diagonalisation on the driving (having the diagonalisation of the sensing off) at the following times:

- 11:05:30 UTC
- 12:22:30 UTC
- 13:12:00 UTC

All three attempts failed due to the weights being too high, which in particular seems to be the case for the PRCL2MICH and PRCL2SRCL values. This is rather puzzling since the algorithm that estimates the coupling is identical for the diagonalisation on the sensing and driving, so switching to the driving should have only been a matter of some signal bookkeeping.

The most likely cause thus seems to be a bug in the code. We will analyse the data and determine if there is an obvious cause.

The process which uses the new algorithm (PyDiagTest) is in the VirgoOnlineTest VPM instance, and it is decoupled from the ITF (it only reads from FbmMain and does not send cm commands); it will be used offline to debug the code, while the usual process is operational as usual. The non-diagonal driving matrix elements have been added to the re-initialization in DOWN.

Topic #2: new SRCL control filter and tuning of UGF servos in LOW_NOISE_*

Today we tested a new optimized SRCL filter SRCL_ctrl5b, with an increased roll-off; it has been tested in nominal LOW_NOISE_3, starting from 16.21.45 UTC; the results are shown in Figures 1 and 2 on the ITF and the model respectively; the two match well and the structures correspond to the expectation.

For some time it has been noticed that in LN3 the DRMI loops gain too much wrt the target UGF. This was due to two main reason: one (already mentioned in some entry in the past) was the roll-off structures of the control filters which are in the injected UGF lines region. This causes a misreading of the unity gain frequencies of the loops causing an increase of gains up to the instability regions. The second reason was partially due to the the misalignment of the SR TY in LN3.

Today profiting of the bad weather in the early part of the shift, we partially fixed this issue by adjusting the setpoint of the loops considering the roll-off structures, in order to have the correct gains in all the high power steps (LN1, LN2 and LN3).

For future reference here are reported the fake UGF set point and the real UGF of the three loops:

In the pictures 3 to 5 are reported the DRMI OLTF with the corresponding 1/f interpolation to obtain the 'fake' UGF setpoints.

After taking 10 minutes of clean data with the new SRCL filter, we launched the LSC noise injection script to compute the new DARM noise budget; GPSs are stored in /virgoData/NoiseInjections/LSC/LSC_injection-1392741356.txt, and the new noise budget is shown in Figure 6.

The new SRCL filter has been added to the automation in LOW_NOISE_3 in place of the old one; in case this needs to be reverted both srcl_filter and srcl_ugf_set must be changed (old ones left, commented).

Topic #3: Automation changes in LOW_NOISE_3

Given that we cannot perform the lock acquisition with SR already misaligned but we are forced to keep the current scheme, we modified how the LOW_NOISE_3 state behaves: now it keeps the DRMI lines on, and the UGF servos as well, while the SR is getting misaligned. Once it detects that SR_TY is within a certain range with respect to the desired setpoint (currently 170 +- 5 Hz) it disengages the DRMI UGF servos and turns off the relevant lines. The GUI will show the process via notifications.

The current scheme is good enough for the commissioning; in view of the Run we may either want to keep this (but flagging with a to-be-created DQ channel when the process is really over) or move everything to ACQUIRE_LOW_NOISE_3, which may have the opposite drawback to keep from Science mode until SR has finished moving. The former solution is a little more confusing and needs a double check (state index and DQ channel) but the latter will reduce the LOW_NOISE_3 duty cycle. This will be discussed during the Run preparation.

Leftovers to be done:

• create the aforementioned DQ channel;
• move everything DARM-related to the 74.4 Hz line and get rid of the 33.7 Hz one;
• devise a new SRCL noise filter more targeted at low frequency for a better OLTF measurement, while the current one (shared with MICH and CARM) is ok for noise budgeting purposes.