All NCals have been restarted around 9:23 UTC at their nominal frequencies: around 36 Hz in h(t).

The afternoon shift was spent testing BS alignment loop and locking LOW_NOISE_3_ALIGNED (#69881 Bersanetti, Ruggi) and reactivating CALnoise configuration lines (#69880 Verkindt)

The data losses observed on Hrec stopped around 15:00 UTC.

ITF left in LOCKED_ARMS_IR for the night.

Guard Tour 18:30 UTC

To we worked on the BS alignment loop; the idea is to move from the current control scheme to a new one, based on the new B1s_QD1_50MHz signals.

The current control scheme is:

• TX: BS_BL_B4_6MHz: blending between B1p_QD1_50MHz_I (low-passed) at low frequency and B4_QD1_6MHz_I at high frequency (high-passed)
• TY: B1p_QD2_50MHz_I (low frequency), which is sent to the DSP where the blending with the OpLev at high frequency happens.

This is the sequence of the tests we made, in different locks, all on the TX DoF, since it is the less robust one and the one most easily tweakable:

1. we replaced the whole signal with B1s_QD1_50MHz, intercalibrated at low frequency with the low frequency weight (sensing weight = 0.207) (we didn't use it, but for reference the weight for TY is 0.11): at 14:29:15 UTC we made the handoff in drift control, around 14:38 (briefly) and then again 14:30:30 we tested in full bandwidth, but we unlocked; not because of the 1.2 Hz oscillation, but some other disturbance, that could be also seen by PR_TX
2. we used the usual signal, but increasing the blending frequency by increasing the gain of the low frequency branch: 15:28:52 UTC B1p gain 2x in drift control, 15:29:23 UTC full bandwidth, shortly followed by the unlock;
3. we replaced only the low frequency branch with B1s_QD1_50MHz with the overall same calibration as B1p_QD1_50Hz: full bandwidth test just before 16:22 UTC, quickly reverted before unlocking.

All data will be analyzed offline, but in all tests the coupling with PR_TX looks the one thing which is the most impacting the full bandwidth loop.

After that, several lock acquisitions were tested, undisturbed both in terms of acquisition and steady state; we also moved to LOW_NOISE_3_ALIGNED without having to change anything (same power as in the past, just reduction of lines and noise there). The locks do not last much, and they sometimes look very glitchy, at least by looking at Hrec. In any case, Hrec itself looked glitchy and some data was missing. Also in this case, we will look at data offline.

Regarding the recent automation of the input power increase, that worked very well, but we gained one case to study: after an unlock, INJ_MAIN went into the INJ_FAULT state around 18:51 UTC.

Today around 17h15 UTC, I have reactivated in CALnoise configuration the lines BS_MIR_permline1, WE_MIR_permline1, NE_MIR_permline1
with the new frequencies 10.8, 12.8 and 14.8 Hz. Those new calibration lines will be used by the new Hrec to get periodically the parameters of the Optical Spring
to be included into the Optical Response Model.

Also, around 13h UTC, I have started two new Hrec processes (HrecOS and HrecSR) that run in parallel to Hrec.

- Hrec:  /virgoApp/Hrec/v5r15 uses the same configuration as in O4 with an Optical Response model that has only one pole

- HrecSR: /virgoApp/Hrec/v6r01  uses a configuration where the Optical Response model contains one simple zero a double pole and no Optical Spring

- HrecOS: /virgoApp/Hrec/v6r01  uses a configuration with same OR model as HrecSR but with also an Optical Spring at low frequency (currently 5 Hz).

Around 17h00 UTC, I have stopped temporarily HrecSR and HrecOS because I suspected that they may be the origin of some data loss in Hrec. I will investigate this tomorrow.

The tuning of the SR tx and ty demodulation phase is quite hard since it is a very noisy and slow signal.

This time I tried a different approach.

I opened the SR TX loop, I made some steps in the alignment and then I found the demodulation phase that best reconstructed the I signal as:

I_tuned = A*(I_initial*(cos(phi))-Q_initial*(sin(phi))+offset

the outcome of the analysis is shown in figure 1 and the phase has been tuned to be 3.4 rad

lets see if this approach is reliable enough

ITF found in locked_arms IR.

After a manual prealignmet of PR/SR and a couple of failed attempts the ITF reached LN2 at 8:01 UTC; Maddalena started working at the locking.

The ITF unlocked at 9:06 UTC.

From 9:12 UTC to 10:15 UTC the following activities were carried out:

• PC camera realignment (Matteo);
• Inspection at WE (Elian, Lorenzo);

From 10:16 UTC to 10:19 UTC ITF in single_bounce_NI; from 10:20 UTC to 10:22 UTC ITF in single_bounce_NI with PR TY misaligned -60urad; see phase camera alignment check.

After that Diego worked on the automation, activity still in progress.

SUSP

Sa MC COIL H1 reset by Paolo.

The new code is online since roughly 12:00 CEST; a couple of full acquistions were done and they were successful but please report any issue, as I expect some corner case.

For about a week now, the lock acquisition starts with 12 W of input power, then when reaching CARM Null the power gets increased up to around 17.5 W, profiting of the several gain servos to cope with such increase for most of the main control loops.

Today the automation of the procedure has been written and saved in the nodes files: it involves both INJ_MAIN and ITF_LOCK, but this is still offline and the nodes should not be loaded yet.

This new procedure involves no new states, but just internal logic and a new file, INJ_MAIN.set (ITF_LOCK.set will follow shortly, for different topics but the same philosophy), which takes inspiration from a similar concept used in the SQZ_FLT node. The main point is two-fold:

• configuration files like we use them can be written by the nodes, but this can be dangerous if one has the file open and re-saves it, if the editor doesn't prompt quickly enough that the file has changed on disk; additionally, writing them from the nodes the way we do completely wipes out comments, which can be very annoying;
• global variables in the automation are reverted to the default declaration value when the node is loaded, as they are read back from their definition that can be out of the states; this can be annoying for state flags that need to be remembered from lock to lock; additionally, they now get to be visible in a file at all times, instead of being hidden in the code running online in RAM.

Therefore, the idea is to use INJ_MAIN.set only for parameters written by the automation itself (or to debug it or to force a specific behaviour), and not for general parameters like the ones in the .ini files. The one related to the power increase is inj_power_state ([POWER] section): given that we plan to increase the power in two big steps (and then a finer open loop tuning), such flag can be 0, 1 or 2, depending if we are respectively at low power (12 W), intermediate power (only one coarse increase) or full power (two coarse increases, the finer tuning is not important here).

Here is what happens:

• when we unlock, INJ_MAIN will go to DOWN and check such flag: if 0, nothing will happen (we should be at low power already); if 1 or 2, the node will perform 1 or 2 coarse reductions of power (5000 steps each), each time updating the parameter in the file; then, the INPUT_POWER_TUNING state will deal with the fine tuning down (or up) to 12 W, as usual but with a new logic;
• ITF_LOCK: towards the end of LOCKING_CARM_NULL_1F, in two distinct places separated by at least 15 s, two coarse increases of power will happen (-5000 and -4500 steps respectively), the inj_power_state variable will be updated, and then the fine tuning to the target power (17.5 W) will happen, by having ITF_LOCK asking INJ_MAIN to use the same INPUT_POWER_TUNING state but in a very different place of the acquisition: the new logic of the state acknowledges the power state and either targets the lower power (when it reads 0) or the higher one (when it reads 2); the same check will condition using one or the other set of parameters; to avoid killing the lock, the number of maximum attempts to tune the power in CARM Null is much higher than the one we use in DOWN.

The new logic will start to be tested tomorrow.

Most of the work of today was devoted to the continuation of the recovery, that ended up previously in DC readout, systematically unlocking afterwards when trying to go to LOW_NOISE_2 (I remind that, mirror actuators-wise, we skip altogether LowNoise1 and move directly from HighPower to LowNoise2).

It was found that a DC correction of several Volts was left on the NE actuator, most probably during the mode matching measurements. After removing that, we could go flawlessly to LOW_NOISE_2, getting in this way the sensitivity curve back; in Figure 1 the comparison with the very last we had briefly on 10 April.

We initially had around 27 Mpc, slowly rising up to 30 Mpc in the second lock of the afternoon. It is not that bad, considering that: in LOW_NOISE_2 a lot of lines are up and high, we have no subtractions working on DARM, SR is aligned and we have no diaphragm installed on the SRM, new IMs, a new optical configuration and no calibration measurements yet.

While staying in LOW_NOISE_2, we immediately noticed a new comb of peaks around 413 Hz, whose amplitude started to grow over time. By looking into it with some more resolution, we observed eight main peaks, with minor ones around them. Our conclusion is that these are the violin modes of the new IMs, which are considerably lower than the ones we were used to have (~ 440 Hz).

Given that we could not adjust the current notches to cover the whole band, we started the development of a new notch filter, to be used in parallel to the old one, which now covers only the EMs; we tried to have a reasonable amount of depth in the transfer function, trying to find the best tradeoff in terms of modification of the DARM response that the new filter would induce. While the magnitude is not that big of a concern, the dephasing it induces could be instead: with the filter we left in operation (Figure 2), we had around 0.2 rad of dephasing at 491.3 Hz, which can possibly have an impact on everything that is computed with the DARM_HF line, namely: double-cavity pole estimator, SR alignment signals, optical gain estimator, OMC figures of merit, etc..

In particular we observed the SR alignment during the next lock, starting from CARM_NULL_1F and then LOW_NOISE_2 (Figure 3, zoom for just CARM_Null in Figure 4): the absolute starting value of the DCP looks a little lower, and the trend during the lock (when SR gets more aligned) shows a decrease of the pole frequency, which may be an hint that the error signals need to be checked.

Afterwards, we could see new peaks around the ones we identified for the violin modes (Figure 5); some of them were spaced by peculiar amounts, like exactly 3.3 Hz, which is the frequency of the DIFFp TX line, which is clearly very strong in DARM (Figure 6). Maybe the fact that we are working decentered increases the coupling, to be verified. In the last lock we reduced such line (and the TY one) by a factor of 2, improving the situation (Figure 7). More work is needed on this topic.

Other topics:

• in the first lock in LOW_NOISE_2, we engaged the BS alignment loops in full bandwidth, with the old B1p-based strategy; while TY could be closed with no issues, closing the TX loop caused the infamous 1.2 Hz oscillation to show up and eventually kill the lock;
• the OMC lock showed some difficulty (entry 69871), as the threshold to correctly find the good mode to lock onto was not crossed, either because the DARM offset was too low or the DARM_HF line was too low; being the latter more unlikely, given the amplitude of the line, the working theory is that the DARM offset on the RF signal is smaller than in the past in terms of meters; we then modified the lock acquisition, in order to use a higher offset at the beginning (-0.26 online, -0.3 set up for the next trials, instead of the usual -0.2), then allow the OMC to lock, then go back to the usual offset before the DARM handoff to B1_PD3, so not to modify the DC readout acquisition at all; we tried it once and it worked as expected, and this is now automated.

ITF found in LN2 in COMMISSIONING mode with planned activity on "LN2 locking/tuning (Pinto Bersanetti)" in prigress.
It went on without major problems till the unlock around 18:51 UTC due to a thunder.

BAD_WEATHER mode set.
At 19:00 UTC an IPS black-out occurred in CB, WE, NE. All UPS systems worked properly waiting for the generators to turn on.
At 19:30 all systems went back in standard state: IPS ON, gaenerators OFF.

ITF left in LOCKED_ARMS_IR.

Air Conditioning
ACS cooling system in failure during the black-out.
HVAC..MCB_1_COLD_TE and HVAC..MCB_2_COLD_TE stuck
Upon recovered the IPS the ACS machine restarted automatically.

Other
(07-10-2026 19:00 - ) Automation - Do not LOAD ITF_LOCK and INJ_MAIN !!!

Air Conditioning
(07-10-2026 19:00 - 07-10-2026 19:30) From remote
Status: Ended
Description: ACS cooling system in failure during the black-out.
HVAC..MCB_1_COLD_TE and HVAC..MCB_2_COLD_TE stuck
Upon recovered the IPS the ACS machine restarted automatically.
Actions undertaken: No intervention needed

The DMS reported some timing errors for the following DBoxes

• CEB_DBOX_ALS, CEB_DBOX_LNFS and CEB_DBOX_SSFS 
• EQB2_DBOX_01, EQB2_DBOX_02 and  SQB2_DBOX_SBE

The ITF locked in LOCKED_ARMS_IR  stare was put in DOWN 

They were reconfigured to recover the correct working conditions: operations performed between 2026-10-07-19h18m26-UTC and 2026-10-07-19h26m19-UTC . 

ITF successfully relocked at   LOCKED_ARMS_IR  after

ITF found in COMMISSIONING Mode and LOCKED_ARMS_IR State.
All times are UTC.
06:36 ITF in CARM_NULL_1F after CITF manual pre-alignment and manual increase of input power upt to 18W once reached the CARM_NULL_1F state.
07:08 - 08:31 Investigation on LOW_NOISE_1 unlocks (Mantovani, Bersanetti).
09:28 - 11:09 ITF in CARM_NULL_1F state for PC realignment (Tacca).
When trying to reach LOCKED_DC_READOUT the OMC did not locked, in order to prevent possible damages to the OMC I manually unlocked the ITF because the temperature was rising too much. I informed Gouaty about this issue and he will try to lock the OMC manually once the ITF will be in CARM_NULL_1F state. DET expert was able to lock the OMC by lowering from 1500 to 1000 the threshold on B1x_DC_DARM_norm_prod (#69871).
12:48:27 ITF in LOW_NOISE_2 since March 25, 2026, and for a short time on April 10, 2026. 

ITF left in LOW_NOISE_2 state and COMMISSIONING Mode.

Lorenzo noticed that during the OMC scan of 11h10-11h20 utc the OMC did not lock on the TEM00 resonance. This is due to the fact that the threshold of 1500 set on the B1x_DC_DARM_norm_prod signal was not reached. During the next attempt it happened again (Fig.1). Therefore I decreased the threshold from 1500 to 1000 and in this way the OMC could be locked (Fig.2). When the reaching DC readout the computed optical gain was about 0.9, which means that the OMC alignment seems to be good. Therefore the problem is rather related to a too low DARM line or to a too low DARM offset.

I think that the reduction of the B1x_DC_DARM_norm_prod can only be a temporary patch, but it is not a good solution as there are other modes that may be close to reaching this threshold (see for example the mode reaching 800 on Fig.1). I noticed that the power on B1_PD3 is now very small (order of 1uW). Therefore I would suggest to increase the DARM offset used to acquire the OMC lock. Once the OMC is locked the DARM offset can be reduced to its current value to reach DC readout.

One more issue has been observed concerning the local damper of PR vertical mode at 11.6 Hz, in addition to the permanent excitation due to the noisy sensor. As shown in fig 1, sometimes a fast glitch affects the sensor, inducing a strong reaction of the loop. The effect on PRCL is large and sometimes in can determine a lock loss (fig 2).

After the successful attempt to open the damper in a stable lock, reported in the previous entry, an attempt to acquire the lock keeping the damper always off was performed, but again the bouncing mode appeared to be unstable during some phase of the lock acquisition (fig 3).

Yesterday we decided to implement the correct strategy, profiting of the maintenance. In CARM NULL a much better sensor of PR vertical motion is available: this is the quadrant used to control the beam jitter. It has been used in the past to slowly control PR vertical position and it is still named 'ASC_PR_Y_INPUT'. Its signal to noise ratio at the resonance is about a factor of 1000 higher and the response to the actuation has the same shape. It was already available in PR DSP and it was just matter to implement a logic able to swap from the local sensor to the quadrant as soon as the second one is ready for the use. It happens at the beginning of CARM NULL and the switch already used to close the beam jitter control can be used also for the swap of the damper.

The implementation was quite straightforward, but the first attemp to use it after the maintenance failed because of a stupid error. In the following locks it worked fine and the advantages are quite evident (fig 4, 5, 6, 7).

The commissioning activity was carried on through the afternoon: #69867 and #69866 (Boldrini, Bossilkov, Bersanetti, Gouaty, Was)

At the end of the activity, the ITF was left in LOCKED_ARMS_IR

Guard Tours

18:00

20:35

While the ITF was locked in DC readout this afternoon, we enabled the computation of the B1 DARM dither signal and engaged the B1 DARM beam drift control of SDB1 (Fig.1). This has the effect of increasing the optical gain by almost a factor 2, while the bench alignment changed by almost 10 urad in TX and by 1 or 2 urad in TY.

Accordingly after the unlock, the B5 QD2 offsets were updated (H=+40 and V=+200).

We recovered the DC_READOUT state, after a few hiccups. We realized that the unlocks when attempting the hand-off to B1_DC were due to a "slow" oscillation on DARM that, when compounded with the high 491 Hz line, would trip the threshold of the fast shutter.

To cope with this, we restored the change of DARM_GAIN in the LOCKING_OMC_DARM_B1_PD3 state (line 5199) and prepared a gian in the ini file that was a bit higher than the one set up by the servo before this step. This allowed to acquire the DC_READOUT state, but the DARM servo further increased the gain substantially. We set a gain close to this final number in the ini file and tested the lock acquisition, successfully.

Before proceeding with the B1s hand-off, we allowed Gouaty to re-enable SDB1 drift control, which increased DARM OG substantially (Fig.1). DARM servo adjusted the gain of the loop to 0.074 after this change, therefore we corrected the corresponding parameter in the .ini file to a value closer to this (0.064), to leave some margin for further evolution during this state.

After that Gouaty opened the shutters for B1s_QDs and we measured the transfer function at low frequency between B1p and B1s and tested the hand-off with these commands:

• ASC.BS_TY_INPUT.AcMatrixChSet(5.0, 0.0, "B1p_QD1_50MHz_H_I", -0.065, "B1s_QD1_50MHz_H_I")
• ASC.BS_TX_INPUT.AcMatrixChSet(5.0, 0.0, "B1p_QD1_50MHz_V_I", 0.31, "B1s_QD1_50MHz_V_I")

The hand-off worked without issue, although the BS alignment is still on drift control so this test is not indicative of the final performance of the loop wih this new error signal.

The lock was disrupted by an earthquake, after the shock passed we attempted another lock acquisition, succesfully, but the ITF unlocked again while attempting to engage LN2.

The recovery of this state is postponed to tomorrow.

We leave the ITF with the arms locked.

This morning we performed some tests of the OMC slow shutter in order to investigate the issue faced yesterday afternoon.

Francesco put the ITF in single bounce mode. We put DET_MAIN in pause and tried to act on the OMC shutter from the SDB1_Rot process using the MOVELIMIT command. The first attempts of opening the shutter in this way failed. We also tried to close the shutter (in case the sign in the command was wrong), but this did not open the shutter neither.

Then we opened the shutter using the relative movement of 45000 steps. After this was done, we clicked on "Stop movement". After this, we tried to close the shutter using again the MOVELIMIT command, and this time it worked. We then performed a few cycles of opening/closing the shutter with MOVELIMIT which all worked fine.

We updated the DET_MAIN.py file in order to use the MOVELIMIT command instead of the relative motion. We put DET_MAIN back in exec and reloaded the node. We tested a couple of cycles of opening/closing using DET_MAIN and it worked fine.

We also updated the opening and closing durations set in the DET_MAIN.ini file, as the motion with the MOVELIMIT command is faster. Looking at an example of opening sequence (Fig.1) we can see that the opening takes between 25 and 30s. Therefore we set the opening duration to 45 s (we leave at least 15s of margin). For the closing (Fig.2), the duration is about 35 s. We set the closing time to 60s.

For the record previous values for the opening and closing durations were 80 and 100 s respectively.

These durations could be optimized further when we have more statistics.

This morning we received an alarm because the water level of the main chiller was low. By better looking at the signal we realized that since the 30/09, the water level started to oscillates with a period of about 1 minute (figure 1)
We went in chiller to refill it and see if it has some effects. It did not. (figure 2)
This oscillation can not be seen in the main INJ PSL signals. (figure 3)
The flow sensor that senses the water going out of the chiller do not see that oscillation, the temperature sensor instead sees it (figure 4). And what we see is that when the level is increasing, the temperature of the water in the tank is decreasing. This may indicates that the flow between the cooling system and the tank is oscillating.... But, the oscillation on the temperature sensor was already present before the level sensor started to oscillates... (figure 5) This is not clear, we will monitor the situation in the coming days. 

For recall this chiller is cooling the SL electronics and head as well as beam dumps for PMC REFL, IPC 1, IMC REFL. 

ITF found in locked arms IR.

At 6:00 UTC ITF in maintenance mode, below the list of the activities communicated in control room:

• TCS thermo camera reference images (operator);
• TCS chiller refill (Nicola);
• TCS powers check (Diana from remote)
• SAT: change of modulation frequency for accelerometers (Boschi, no other informatio received);
• OLTF verification with IMC_REFL variation;
• OMC slow shutter now being used in MOVELIMIT mode ;
• INF: HYMO maintenance at WEB (fabozzi)
• cleaning operatons of the experimental areas;
• vacuum activities;

The cryotrap refill was delayed and the maintenance was completed at 11:34 UTC; after that the ITF was relocked at CARM_NULL_1F after the CITFmanual prealignment. 

At around 13:00 UTC started the planned commissioning activity of DC read-out locking.

Today we verified the best comprise in terms of OLTF for the power at 18W and 12W with different values for the IMC_REFL_DC power.

For this, we measured the OLTF after varying the REFL power with the IPC1 rotator from remote. 

We had the following results at 18 W:

• with REFL at 0.85W -> OLTF 142 kHz and 9 deg phase margin;
• with REFL at 0.73W -> OLTF 114 kHz and 19 deg phase margin;
• with REFL at 0.68W -> OLTF 96 kHz and 24 deg phase margin;

From 0.73 of IMC_REFL_DC we descrease the power of IMC_TRA from 18W to 12W and remeasured the OLTF (the corresponding value of IMC_REFL_DC at 12W is 0.64W):

• with REFL at 0.64W -> OLTF at 65 kHz and 28 deg phase margin;
• with REFL at 0.6W -> OLTF at 53 kHz and 18.3 deg phase margin.

Analyzing the data, we decided to choose the best compromise for the REFL_DC value, which is 0.73W of REFL for 18W, corresponding to 0.64W of REFL for 12W. Figs. 1 and 2 show respectively the OLTF for these two configurations. 

For the 12W OLTF there is apparently some noise structure very close to the UGF (also present for 18W but farther away from the UGF). Looking closely at it (Fig. 3), we can see that it corresponds to some excitation lines with unknown origin. This doesn't seem to generate control issues. 

Moreover we have commented the BS full bandwidth in low noise (line 6094 and 6095)

Low B1x_DC_DARM_norm_prod is a sign of poor OMC alignment (or that the DARM 491.3Hz is lower than during O4 at the same stage of the lock acquisition).

Figure 1. Looking at the previous lock where a few minutes where spent with B1 PD1/PD2 open, LSC_B1_DARM_OG looks anti-correlated with SDB1_LC_TX, with the gain higher when SDB1_LC_TX is lower. I have adjusted the B5 QD2 V offset from 350 to 300 this morning, as during the alignment yesterday the two looked equally good, but with an alignment signal which was a DC power fluctuating by a factor 10, so with very large error bars. 

It would be useful to also enable the computation of the OMC dither error signals. In the automation these are computed only during the  LN2 lock acquistion:

            cm_send('SDB1_LC','AcRelayChTranSet','LC_B1_DARM_compute',1)

because each low noise actuator transition creates a large glitch in the computation of the error signal which takes several minutes to die down, as the signals are heavily low passed. Enabling the error signal computation for a few minutes once B1 PD1/PD2 are open without having any low noise transition after the computation starts could help finding if there is indeed an OMC misalignment or not.

Enabling the drift control loop at the same time as enabling the error signal computation, could also be a simple and efficient way of checking that, but with that loop closed the OMC alignment will be kicked if there is an actuator low noise transition            cm_send('SDB1_LC','AcRelayChTranSet','LC_B1_DARM_enbl',1)
 

ITF found in COMMISSIONING Mode and LOCKING_ARMS_BEAT_DRMI_1F State.
All times are UTC.
At the beginning of the shift the activity on DC read-out locking was ongoing and wnet on up to 20:01 (Mantovani, Bersanetti, Spinicelli, Gouaty, #69857, #69856).
19:57 ITF reached LOCKED_DC_READOUT state.
20:07 - 20:59 Test lock acquisition to LOW_NOISE_2 state, power increased when ITF reached CARM_NULL_1F state, ITF unlocked in ACQUIRE_LOW_NOISE_1 state at 20:59:38. As instructed by the experts after the unlock I manually set INJ power to 12 W and re-initated INJ_MAIN Metatron node.
ITF left in COMMISSIONING Mode and LOCKED_ARMS_IR State.

Guard tours:
17:57, 20:31