Figure 1. Comparing the spectrum of yesterday to the beginning of the year, the noise level of SRCL, PRCL, MICH is a factor few higher than before. Especially on PRCL. This is also the case of noise on the SSFS quadrature. 

The question is what it is and where it comes from. The noise is likely to be present on the laser frequency, and then polluting all LSC channels. It may be related to the higher noise level of the LNFS.

Figure 2 The more structured noise that is visible in SRCL between 300Hz and 3kHz is very coherent with the excess noise in the LNFS. So that part is clearly due to the more noisy LNFS. For the excess noise in PRCL, and the excess noise in SRCL below 300Hz it is less plausiable. As there is no coherence with the LNFS phase noise, and the LNFS broaband noise below 300Hz is the same as it was at the beginning of the year.

Figure 3 shows yesterday in purple, Friday last week in red, and the beginning of the year in blue. Some version of the pole at 500Hz noise is back, it is clearly visible on SIB2 RFC 8MHz I, the level doesn't appear to be stable as it is different on Friday last week and yesterday, and the changes in noise level of PRCL and SSFS quadrature are correlated with those pole at 500Hz noise changes visible on RFC 8MHz I. 

Figure 4 Looking at data of various nights with arms locked, the pole at 500Hz noise seems to have appeared on October 7. It would be important to look at that more precisely to see at what time the extra noise appeared. One hardware activity on that day was the realignment of the phase camera, and maybe a change in the splitters for the local oscillator of the phase camera https://logbook.virgo-gw.eu/virgo/?r=69877

Figure 5. Searching more precisely it looks like the problem started around 19:00 UTC, there was an interferometer unlock from LN2 at that time.

WIth the SR tower under venting, we setup the automation in the following way:

• DET_MAIN in SHUTTER_CLOSED, then paused;
• SUS_PR in MISALIGNED, then paused;
• SUS_SR in MISALIGNED, then paused;
• DRMI_LOCK in MISALIGNED_PR_SR, then paused;
• ITF_LOCK in DOWN, then paused;
• OMC_LOCK in TEMP_CONTROLLED, then manual;
• INJ_MAIN in IMC_RESTORED, then manual;
• ARMS_LOCK in LOCKED_ARMS_IR, then manual;
• all other nodes unchanged.

ITF found in locked arms ir.

At 7:00 UTC started the planned SR venitng; operations performed:

• SR suspension loops opened
• DET main in pause in SHUTTER_CLOSED; 
• SDB2_SBE, SDB2_LC, SDB1_LC opened.

In parallel other two activities were carried out:

• squeezing recovery in standalone; still in progress.
• arm astigmatism measuremet; completed.

HVAC

Under request of Davide:

• I enabled the PyHVAC INJ servo at from 7:56 UTC to 8:53 UTC;
• at 12:21 UTC I switched off the PyHVAC server.

A line around 54.7 Hz is visible in the accelerometers installed in the NEB experimental hall, including those along the tower and on the flange, as well as in the acoustic sensors, some of the NN array geophones, and all its microphones, including those located in the technical area behind the building.

The line is not visible in the velocimeter (Guralp) installed beneath the stairs.

This frequency appears to be close to the 9th harmonic of the belt frequency associated with the AHU fan-motor system (~6.15 Hz). The line is also clearly visible in the accelerometer installed on the AHU box (*UTA_BOX_ACC).

It is worth mentioning this observation, although the frequency correspondence could simply be a coincidence.

This entry presents the measurement made in the arm this morning. The aim of the shift is to measure the orientation of astigmatism within the arm cavities. The method is similar to the one attempt in (68385). The NE and WE mirrors are misaligned during the scan, but instead of scanning the full FSR, only the frequency range of the first fundamental mode and first order mode is scanned. After half an hour, the arms are aligned using the automation loop before starting a new scan series. 

Below is the list of scans performed during the shift with the associated misalignments

- scan n°1: 10h07 TX+=0.3 urad, TY+=0.0 urad

- scan n°2: 10h07 TX+=0.0 urad, TY+=0.3 urad

- scan n°3: 10h07 TX+=0.29 urad, TY+=0.08 urad

- scan n°4: 10h07 TX+= -0.08 urad, TY+=0.29 urad

The arms have been realigned using the automation loops

-scan n°5: 10h52 TX+=-0.15 urad, TY+=0.26 urad

-scan n°6: 11h01 TX+=-0.26 urad, TY+=0.15 urad

-scan n°7: 11h11 TX+=0.21urad, TY+=0.21 urad

-scan n°8: 11h19 TX=-0.21uradn, TY+=0.21urad

The arms have been realigned using the automation loops

-scan n°9: 11h34 TX=0.15urad, TY+=0.26urad

-scan n°10: 11h44 TX+=-0.26urad, TY+=0.15urad

-scan n°11: 11h54 TX+=0.08urad, TY+=0.29urad

-scan n°12: 12h03 TX+=-0.29, TY+=0.08urad

The arms have been realigned using the automation loops

-scan n°13: 12h18 TX+=0urad TY+=0.3urad

-scan n°14: 12h26 TX+=-0.3urad TY+=0.0urad

Profiting of the scans of yesterday evening on the SRCL set, I ve tried to check which is the best error signal.

the comparison is between the DCP and the DCP phi (ASC_DCP_HF_B1_phi_FS_mean found by Michal already in the past)

the two error signals have been built as:

Err = 0.1892*DCP -85.16;
Err1 = -125.8*DCP_phi +237.1;

in figure 1 the comparison is shown and the last seems a good error signal for the SRCL detuing

This morning around 7:00 UTC I adjusted the alignment of the MZI inside the squeezer box on EQB1. The contrast increased substantially, see first plot. 

Witn Marco's support I also checked the OPA alignment, and I found it was already good, see second plot. 

Added LSC_WE_CORR_SHAPED and LSC_NE_CORR_SHAPED to the BruCo unsafe-channel list: /data/dev/detchar/online/bruco/share/virgo_excluded_channels_Hrec_hoft.txt. These correspond to the unsafe Sc_{WE,NE}_MIR_Z_CORR channels (see logbook entry #67154), which in recent runs were dominating the observed coherences.

ITF found locked at LN2 in COMMISSIONING mode, with the planning ISC activity (Pinto Mantovani) in progress.

At 19:00 UTC the ISC activity concluded and I.Nardecchia switched off the SR RH at 19:14 UTC.

ITF left locked on LOCKED_ARMS_IR.

The SR RH was switched off at 19:14 UTC.

The morning shift started by relocking the interferometer, which had no issue on that front for the whole shift.

The idea of the shift was to start studying again the SRC longitudinal detuning. Before starting that, and also because we are now working decentering, a very basic set of angular noise injections was done (DIFFp, PR). The log file is in /virgoData/NoiseInjections/ASC/ASC_injection-1476000002.txt

After that, the tests on the SR detuning started; the first few tests were done naively by changing the setpoint of the SRCL_SET loop, which in the past did not give very good results, as the signal was not carrying enough information to drive it properly in the intended way (higher frequency for the optical spring). This happened in LOW_NOISE_3_ALIGNED.

Here the recap of the tests done in this way:

08:14:10 UTC : SRCL_SET_SET = 0.5 -> 5.0 in 300 s, then 480 s of clean data;
08:27:30 UTC : SRCL_SET_SET = 5.0 -> 10.0 in 300 s, then 600 s of clean data.

Around 8:31 UTC we observed some bursts of noise in the MICH loop (and, fainter, in the SRCL one) at around 3.6 Hz. Given that in that state the UGF servo loops are not operational anymore (with the exception of the DARM one), the gains of both of them were raised around 8:35:30 UTC. We unlocked at 8:38:52 UTC.

In the following lock, that started at 09:16:53 UTC:
09:27:42 UTC: SRCL_SET_SET = 0.5 -> 10.0 in 600 s
09:46:39 UTC: unlock

There were a couple of unattended tests during the lunch break, which look very similar and probably do not carry more information.

Later, we verifired offline from the tests that the OS signal moved back to a more manual approach: LOW_NOISE_2 state, SRCL_SET loop technically close but in reality frozen in place (LSC_SRCL_SET_CAL = 0), then LSC_SRCL_SET moved manually as a static offset.

Test #1:
12:29:00 UTC: start of LOW_NOISE_2
12:33:00 UTC: SRCL_SET loop frozen (value of _SET_TOT at the time ~ -8.3)
12:33:52 UTC: SRCL_SET = 0 -> -5 in 300 s
12:41:00 UTC: SRCL_SET = -5 -> -10 in 300 s
Noise injection on DARM (and clean data): logfile in /virgoData/NoiseInjections/LSC/LSC_injection-1476017575.txt
13:01 UTC: SRCL_SET = -10 -> -15 in 300 s
13:20 Noise injection on DARM (and clean data): logfile in /virgoData/NoiseInjections/LSC/LSC_injection-1476019008.txt
13:29:21 UTC: unlock
We continued to change the SRCL set at step LN2 (in order to have all the servo for the gains active) and we took :

- DARM OLTF measurements to fit the OS for different SRCL set

- Angular noise coupling (DIFFp) to see if the coupling could change with the SRCL set

the gps are:

SRCL set @ -10 gpsDARM=utc2gps(2026,10,14,14,32,45); dur DARM=120;

SRCL set @ -20 gpsDARM2=utc2gps(2026,10,14,14,47,50); dur DARM2=120;

            gpsDptx=utc2gps(2026,10,14,14,57,00); dur Dptx=120;

            gpsDpty=utc2gps(2026,10,14,15,04,10); dur Dpty=120;

It is visible that the -20 configuration shows a lower coupling of DIFFp TX (Figure 1)

After that we tried a SRCL set up to -30 but it failed the LN3 aligned state transition (a 3.5 Hz oscillation on MICH - most probably low gain, which is surprising since we let the servos to adjust the gain in the SRCL set increase and to stabilize).

We have then reached the LN3 aligned configuration and performed a SRCL detune to check the sensitivity (to be able to compare with the one that will be achieved with the diaphragm)

RECAP

the overall changes in the violins notches are the following: 4 notches for the first violins modes in the region 412-415 Hz.

we removed an old second order mode notch at 882.17 Hz, moved down to the  2nd order frequency mode of the new violin: 827.1 Hz, Q ratio=100.

The overall effect on DARM OLTF are negligible for the bandwidth; loss of less than 2 deg at 150 Hz; change of ~12.5 deg at 491 Hz, (already considered during the notch design) compensated by retuning the SR alignment phase. See fig.1 and 2 where the overall phase of the new notches is shown. 

Just two possible hints:

The first is an old entry (... too old) dating 2011 which mentions one 54.8 Hz mechanical mode of WI payload: https://logbook.virgo-gw.eu/virgo/?r=30230. Indeed, most of the payload has changed since than, so I guess this must be just an unlucky concidence (!)

The second observation concens the attached plot. I picked some of the signals for which the BruCo found a coherence at the little one at 53.92 Hz. Couriously, these signals, which belonng to the SDB1 (OB) suspension have a peak at 54.7x Hz which appear to match closely to the main Hrec one... but no coherence on this. I do not have an interpretation for this.  

In preparation for the SR tower opening, I switched off the HWS-DET SLED at 09:25 UTC:

• 2026-10-14 09h25m18 UTC    ilaria 'EDB_DAC:TSC DET SLED [Constant value=0,Ramp time=1]' sent to EDB

Both HWS-DET and HWS-INJ SLEDs are now switched off (see HWS CCD images in Figs. 1 and 2).

ITF found in COMMISSIONING mode and CARM_NULL_1F state.
All times are UTC.
14:08 ITF back in LOW_NOISE_3_ALIGNED after the earthquake, and ready for calibration activity. The lock lasted few minutes and violin modes around 400 Hz and its harmonics were visibile in the sensitivity with high SNR, the cause of this excitation has to be identified. After the unlock the injected power was lowered too much by the automation (9W on INJ_IMC_TRA_DC) and the direct consequence was the RFC not able to lock, issue fixed by manually increase the injected power.
14:30 - 15:00: Inspection at WEB entrance for water leakage (Fabozzi with external company).
15:16 - 16:06 CALI: IM/EM actuator calibration (Verkindt, Rolland). Interrupted by the operator when CALIBRATED_DF_PCAL where completed.
16:07: Manual unlock in order to perform OMC scan in CARM_NULL_1F state.
16:49 - 18:14 DET: CARM NULL OMC SCAN in CARM_NULL_SCAN_ON state (Gouaty, #69915).
18:29 - 19:45 ISC: ITF in LOW_NOISE_3_ALIGNED, LSC/ASC noise budget (Boldrini Bossilkov, #69916).
20:40 Manual unlock. Requested LOCKED_ARMS_IR.

ITF left in COMMISSIONING mode and LOCKED_ARMS_IR state.

Guard tours:
- 20:41;

We supported the activity of DET/CAL and, at the end of the shift, adjusted the amplitudes for the SRCL and DARM injections in the inject_lsc.py script.

We started an injection of 10 mins tranches for each dof + clean data before leaving.

During the afternoon shift, we performed a scan of the OMC in CARM_NULL.

The scan was started at 16h49 utc, after the end of the 10 min timer of ITF_LOCK. We manually interrupted the scan at 18h14 utc. See attached figure.

Taking into account the thermal transient of 1 hour after reaching CARM_NULL, the best data to look at for this scan is between 17h40 and 18h14 utc.

we made it so

2:00 UTC A signal of possible failure from a HVAC INJ chiller or boiler was registered (see pic). It was not a failure and the explanation is the following: HVAC control loops are slow to avoid fluctuations, the night was colder than usual and the heating loop started compensating with a time scale much bigger than the day-night one. Heating power was temporarily increased to catch up with the gradient (Romboli, Soldani) 

06:00 UTC ITF found in LOCKED_ARM_IR state COMMISSIONING mode, set to DOWN state MAINTENANCE mode

Activities performed during maintenance:

• TCS power checks and TCS thermal camera procedure (Cantini, Galoppini, Zaza)
• CEB, clean rooms and filter cavity area cleaning (external company)
• WE Hymo maintenance (external company, Ciardelli, Fabozzi)
• TCS chiller refill (Menzione)
• Nitrogen refill (VAC group)
• INJ OMI chiller level sensor troubleshooting (Cantini, Galoppini, Melo, Zaza)
• WI DSP resynchronization (Boschi)

10:36 UTC ITF in  LOCKED_ARMS_IR after realigning the mirrors
12:22 UTC CITF alignment interrupted by the earthquake
12:23 UTC Earthquake 6.5 Mwp off the coast of Liberia (Atlantic Ocean), ITF set to EARTHQUAKE mode
13:34 UTC ITF in COMMISSIONING mode, arms locked
13:40 UTC ITF in LOCKED_ARMS_BEAT_DRMI_3F, beginning of commissioning activity

I ve checked again the SR demodulation phases for LN2 

the SR ty is correctly 1.96 (in the entry there was a problem of copy and paste of the initial phase but the delta was correct)

for SR tx the phase should be reverted back to 3.8 as written in the entry  69889

Attached to this entry,  the details of the TolmFrameBuilder servers and the Imaging servers related to this event .

• all the TolmFrameBuilder servers running with a frame dt of 0.2s complains to not be able to sent theirs frames to the FbmFFE  server running on olserver52
  • the FbmFFE server reports to not receive any input frame during 21s
  • Most of the TolmFrameBuilder servers succeeded to return in theur standard running conditions, except the SUSP_Fb one where some actions were mandatory
• all the Imaging servers and the TolmFrameBuilder servers running with a frame dt of 1s complained to not be able to sent theirs frames to the FbmMain  server running on olserver52
  • the FbmMain server  reports to not receive any input frame during 26s

It's difficult to distantly if the issue is due to the network or a temporary overload of the main DAQ host, olserver52

Figure 1 compare the position of the order 2 mode as seen on B1 between before and after the change in input mirrors and EM RH retuning. The spread of the peaks of frequency noise coupling due to the order 2 mode are similar to what they were in the past, but the exact shape is different, which is not surprising. A 100Hz decrease in frequency correspond to a 2m decrease in mirror radius of curvature. This means that the two arm cavities are still within +/-2 meters of each of each other, with differences most probably due to astigmatism.  It may still be possible to decrease further the order 2 mode by RH tuning, if we are lucky and the astigmatism in the two arms happen to be the same. During the large steps of EM RH during the initial tuning the B1p went through a minimum, and that minimum is ~20% lower than the current B1p power, but there is no guarantee as the B1p power also depends on other thigns (etalon, alignment, etc) than just the EM RH tuning.

There is also an average translation by ~100Hz towards lower frequency, which would mean that on average there is 2m less radius of curvature in the two arms.

https://logbook.virgo-gw.eu/virgo/?r=66937

Today we took the spare OMI chiller that was in the Optics Lab to the Chiller Room in CEB. The idea was to swap the chillers but the spare didn't work as expected (the chiller couldn't reach the setpoint temperature) and we decided to leave the current chiller running as it was. 

We performed two tests: 

- We put the level sensor in another water container in order to investigate the oscillation observed since 30/09 (Fig. 1). During the test period (red zone in the figure), we can see that the oscillation is not present, so our conclusion is that probably the sensor is mechanically interfering with the temperature sensor inside the water container of the OMI chiller and creates this oscillation.
The oscillation on the level signal is correlated to the oscillation on the temperature signal (Fig. 2)

- The second test was to verify the pH of the water inside the OMI chiller. The background measurement was a pH and chloride test on ultra pure water just poured from the filtering system: pH 5.5, no chloride detected (Cl- < 0.1 ppm). The water that has been running inside the OMI chiller and into the utilities had a pH of 6.7 and Cl- < 0.1 ppm. This is a further proof of chemical reactions happening (corrosion, for example). It could explain the debris we find in untreated ultra pure water cooling systems.