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.

During the locks of October 9, Hrec and its new version HrecOS (which uses a new optical reponse model adapted to detuned SR and that includes an optical spring) were running.
Plot1 shows unbiased hrec/hinj values from Hrec. We observe for the modulus a residual bias around +2% at low frequency and around -2% at high frequency (>100 Hz).
During those locks, SR was tuned and plot1 shows that in this configuration, Hrec provides a residual bias that can be improved but that is reasonable (during O4 this residual bias was around 1%).

Plot2 shows a comparison of hrec/hinj at 37, 207 and 407 Hz, between Hrec and HrecOS. We can see that HrecOS provides hrec/hinj modulus closer to 1 and hrec/hinj phase closer to 0. That's an encouraging result. We will see how it behaves when SR is detuned...
Plot3, shows the sensitivity curves from Hrec and HrecOS and check that Hrec and HrecOS provide almost the same sensitivity over all the frequency band.

This afternoon, after recovering CARM NULL 1F, we performed an absorption measurement using HWS-DET.

After approximately one hour of stable lock, the ITF was manually unlocked in gentle configuration, keeping all optics along the HWS-DET optical path aligned, including NE.

• 16:21 UTC: HWS acquisition started (dataset: 20261012T1821).

• 18:26 UTC: Gentle unlock performed (wavefront 9). 

Since this was our last opportunity to perform measurements with HWS-DET before the baffle installation scheduled for next week, I asked to continue the data acquisition for the remaining hour of the shift.

A preliminary comparison with the ANSYS simulation indicates an absorption of approximately 38 mW in the NI mirror (see Fig. 1).

At 12 W, the circulating power was estimated to be around 80 kW. Scaling this to the current input power of 17.5 W gives an estimated circulating power of approximately 116 kW.

Based on an estimated absorbed power of 35 mW, this gives a WI absorption of approximately 0.3 ppm.

After completing the measurement at 19:29 UTC, we switched the CHs back on, and Fabio left the ITF in the arms locked on IR configuration.

The SR+arm double cavity pole (DCP) has been disappointingly low, and the power in the arms increased more than what would expect from looking at the carrier recycling gain. The simple explanation for both effects is that the arm cavity finesse has changed.

The new input mirrors have a transmission of 1.30% https://tds.virgo-gw.eu/?r=21813, while the old mirrors had a transmission of 1.35% https://tds.virgo-gw.eu/?r=11316, a 5.6% change. One would expect the arm cavity finesse to increase by 5.6% and consequently the DCP decrease by 5.6%, about 23Hz. Which would mean that the DCP of ~395Hz is in fact comparable to the ~420Hz we had before changing the input mirrors. 

The effect on arm power is a bit less evident, as the increase in arm finesse increases the ratio between the power in the arms and the power in the power recycling cavity, but it also increases the losses as light circulates more times in the arms. In an example Optickle simulation with 75ppm RTL in the arms the power in the arms increases only by 2% when changing the input mirror transmission from 1.375% to 1.30%, and the power in the PRC decreases by 3.5%. 

In addition the change in arm cavity finesse should also change the MICH->DARM coupling, I would guess reducing it by ~5.6% in amplitude.

The attached plot and its zoom  shows the evolution over 1 week of

• the NARM_BEAT DC and 157MHz magnitude signals
• the WARM_BEAT DC and 154MHz magnitude signals

According to this plot, the NARM_BEAT_DC and 157MHz magnitude values decreased the  2026-10-07-19h08m-UTC 

The standard values have been recovered this morning .

Operations performed between 2026-10-12-07h34m58-UTC and 2026-10-12-07h44m04-UTC 

Below some comments

• it is strange to see the minimum of the BEAT_DC signal close to zero during the tuning phase for NARM 
• raw data plots related to the BPC tuning
  • NARM_BEAT : full BPC tuning sequence, beginning of the BPC tuning, end of the BPC tuning 
  • WARM_BEAT : full BPC tuning sequence, beginning of the BPC tuning, end of the BPC tuning
• maybe some parameters of the BPC BEAT tuning have to be retuned (experts are informed)

ITF found in locked arms IR.

In the first part of the shift Alain performed a relignment of the WE green beam.

After that at around 8:15UTC the ITF was locked in CITF and Ilaria performed the CH tuning.

Then the commissioning team worked at the locking recovery of CARM_NULL_1F, recovery still in progress.

Susp

SR LC opened by the guardian at 7:15 UTC, properly closed.

Today was devoted to CH tuning, as the ITF, when cold, requires several lock acquisition attempts before reaching a stable lock, allowing it to gradually warm up.

The tuning shift started at 10:00 LT to allow Alain to adjust the green beam alignment beforehand.

Initial configuration:

I decided to increase the WI CH power for the following reasons:

1. The WI DAS was tuned to compensate for an absorption level twice that of NI. Therefore, I would expect the WI CH power to be approximately twice that of NI.

2. The plots below, provided by Matthieu, show the evolution of the matching after unlock for both NI and WI. While the NI matching remains relatively stable, the WI matching shows significant variations.

The goal of the tuning  was to maintain the same sideband level in DRMI immediately after an unlock as in DRMI without a preceding ITF lock (see Fig.1).

STEP 1: increase the WI CH by 20 % (completed at 07.18 UTC):

Since the change was in the right direction, I proceeded with a second step in the same direction of STEP 1.

STEP 2: increase the WI CH by further 20 % (completed at 08.45 UTC):

The sideband behaviour during the tuning are shown in Fig. 4

After that, the lock acquisition systematically failed at CARM NULL 3/3. Madda addressed the issue by increasing the DIFFp phases to +0.4 and reducing the DARM gain from 0.014 to 0.01.

Diego and Manuel are currently proceeding with the retuning of the lock acquisition.

During last maintenance, we changed the modulation frequencies ot the WI and NI horizontal accerlerometers to an higher value not multiple of 50 Hz. We fixed the problem. This issues happened in the past but, since the values were not saved in the DSP code file (.hrd file), the wrong ones have been restored after a reboot. 

On Saturday 10 October 2026, 14h17 UTC, I have done a reload config of CALnoise process (while ITF was unlocked) to add three injected permanent calibration lines at 12.9, 13.9 and 14.9 Hz.
They replace the lines previously mentioned at 10.8, 12.8 and 14.8 Hz. The amplitude of the lines are a first estimate that may be updated once the ITF is locked.

Reinspecting this episode for the O4 DetChar paper. Diagnostics at the time were inconclusive/partly diverging (SWEB LC correlation #65647, #65651; PSTAB/Neovan for the loud glitches #65646, #65649), so I redid the analysis with offline Omicron triggers + trends (downsampled to 0.1 Hz), from 20 Oct to 21 Dec 2024.

Figure 1:

• top: hourly rate of Hrec Omicron triggers, 20-80 Hz, SNR > 6.5, analysis-ready time only
• middle: ENV_PSL_AMP_TE (Neovan head), ENV_LL_MAIN_CHILLER_TE
• bottom: SWEB_LC_TY_err_rms
• dashed lines: left to right: main chiller swap 8 Nov ~13:30 UTC (#65502),, onset 17 Nov ~01 UTC (#65553), SWEB power cycle 29 Nov ~12:40 UTC (#65663), Neovan head on dedicated circuit 3 Dec ~10 UTC (#65698), WEB power outage 4 Dec 10:25 UTC (#65707)

Notes:

• Glitches stop within hours after both interventions on the Neovan head cooling:
  • 8 Nov chiller swap: precursor of 6-8 Nov (~0.2/min) ends; AMP_TE 29.8 -> 28.4 °C, rate back to ~0.07/min.
  • 3 Dec dedicated circuit: main episode (2-3/min) ends; AMP_TE 29.1 -> 26.4 °C.
  • Loud glitches (SNR > 100, #65646) stop at the same time.
• SWEB TY_err rms is ~0.3 urad for weeks before/after with no glitches, and ~0.015 urad on 30 Nov - 3 Dec (B8 QDs off after #65663), when the rate is highest (~2.7/min) -> SWEB correlation (#65647) looks incidental.
• Caveats:
  • AMP_TE alone does not discriminate: 3-5 Nov at ~29.2 °C, no excess (chiller water at 17 °C then vs 24 °C after 8 Nov).
  • Glitches back in the lock of 4 Dec 09:35-10:25 UTC (#65712), not in Science, AMP_TE = 26 °C.

=> 20-80 Hz family most likely related to the Neovan thermal state, same as the loud one. (Coupling to Hrec not identified?)

@INJ/PSL: can you confirm? Could a PMC/PSTAB path give low-SNR 20-80 Hz glitches with no clear witness in the PSTAB channels? Anything else changed in the laser lab on 8 Nov / 3 Dec?

Figure 1. Francesco remembered that two years ago we had a line at ~54Hz that had appeared on Aug 2 2024  https://logbook.virgo-gw.eu/virgo/?r=64873

Figure 2 compares the spectrum from Aug 2 in the evening and yesterday. The line we have now is much higher, and a bit broader, and is actually composed of two peaks.

Looking at Samuel's bruco, the smaller peak on the left at 54Hz, seems to be the same as the issue in Aug 2024, as it is coherent with SDB1 suspension accelerometers: https://scientists.virgo-gw.eu/DataAnalysis/DetCharDev/users/salvador/BruCo/Hrec_hoft_1475582418/Sa_OB_BR_LVDT3_500Hz.png, which was also the case of the line in Aug 2024. It would be interesting to look through the logbook how this issue was resolved two years ago, or if it disappeared on its own.

The main bump at 54.8Hz seems to be something else.

ITF found locked at LN3_ALIGNED in COMMISSIONING mode with the planned activity on "LN2 locking (Boldrini Bossilkov)" ongoing.
At 18:09 UTC a big Earthquake located in Panama (Mag. 8.0) unlock ITF and shooke all suspensions.
EARTHQUAKE mode set. End of the activity.

SWEB and SNEB Position loops opened. Properly closed.

ITF left in LOCKED_ARMS_IR.

During this shift we restored the functionalities of the inject_lsc.py script, after testing new values for the noise injections' amplitudes.

Overall, the injected noise level was sensibly increased, with a caveat: we couldn't find an adequate value for hte CARM injection, as coherence remains poor even with a noise amplitude that unlocks the interferometer.

We tested the whole script, setting the duration of each injection to 10 minutes, to gather enought data to revisit the subtraction filters (to be continued offline). While the injections of PRCL and MICH have adequate coherence, SRCL injection caused an unlock. Also the PRCL injection seemed to show cross-coupling with both MICH and SRCL, with a weirdly oscillating coherence. While the data are usable, this behavior has to be better understood.

We also introduced the phases for the SR alignment in the .ini file for ITF_LOCK (69892).

We wanted to test the script one last time, but the shift is cut short by a 7.6 earthquake in Panama.

Earthquake not withstanding, the plan is to leave the ITF in auto-relock to test the acquisition.

The final phases for the SR alignment are:

• CARM_NULL_1F:
  • sr_tx_b1p_dcp_phi0 = 0
  • sr_ty_b1p_dcp_phi0 = -1.09
• LN1:
  • sr_tx_dcp_hf_phi_b1_phi0 = 4.9
  • sr_ty_dcp_hf_phi_b1_phi0 = 1.97

I've ran an instance of BruCo to find coherence among more than 5000 channels with Hrec_hoft_20000Hz.
The results can be consulted here.

Unfortunately, no safe channel was found to be coherent around the bump frequencies.

The latest list of unsafe and unreliable channels can be consulted here.

This morning we have finished to retune the phases for SR alignment

CARM null

SR tx ; error signal ASC_SR_TX_DCP_HF_B1p_I; measurement UTC 9 Oct 7:27 - 7:41 ; initial phase -0.31; new phase 0; Figure 1 

SR ty : error signal ASC_SR_TY_DCP_HF_B1p_I; measurement UTC 9 Oct 7:41 - 8:10 ; initial phase -1.47; new phase -1.2; Figure 2 

LN 2

SRtx : error signal ASC_SR_TX_DCP_HF_phi_B1_I; measurement UTC 8 Oct 8:42- 8:51 ; initial phase 2.2; new phase 3.8; Figure 3

SRty : error signal ASC_SR_TY_DCP_HF_phi_B1_I; measurement UTC 8 Oct 8:25- 8:41 ; initial phase -1.47; new phase -1.6; Figure 4

the phases have not been implemented yet

DCP calibration

the DCP calibration hase been done by injecting DARM broadband noise (ampl 20) and fitted by manuel for different alignment of SR

8:54:25 UTC (120sec ) DCP online = 375Hz DCP fitted = 345Hz

9:15:55 UTC (120sec) DCP online = 290Hz DCP fitted = 260Hz

9:31:55 UTC (120sec) DCP online = 200Hz DCP fitted = 178Hz

ITF found in COMMISSIONING mode and LOCKED_ARMS_IR state.
All times are UTC.
06:04 - 06:57 CEB visit (Bonnand).
06:05-07:10 WEB inspection (Fabozzi).
07:04 ITF in CARM_NULL_1F.
10:41 - 10:43 DAQ: Reconfigure EQB1_DBOX_03 in SQB1_dbox_rack (Masserot, #69885).
10:38 ITF unlocked from LOW_NOISE_3_ALIGNED due to an earthquake close to the site (ML 3.3 at Costa Livornese, INGV). After the unlock DET_MAIN node went in UNKNOWN and was stuck requesting SHUTTER_CLOSE, I restored it requesting INIT state. INJ_MAIN node went in FAULT state, since the INJ input power was not going to 12W I acted on EIBAgilisRot, 'moverel' by 5000, this lowered too much the IMC transmitted power because the automation put the input power back at 12W and the command is sent at some point independently by the state of INJ_MAIN and ITF_LOCK states. The consequencies of this action were the opening of SIB2_SBE (properly close) and the IMC not able to lock. The issue has been solved by manually increase the input power, the IMC locked and the automation has recovered by its own.

ITF left in COMMISSIONING mode and LOW_NOISE_3_ALIGNED state.

This is a quick look at ENV_EPRB_ACC_Y  (I don't know if this is a good witness)
It seems there is no coherence at 54.8 Hz
Maybe there are other sensors to look at.

Today, around 8h37 UTC, we have restarted HrecSR and HrecOR after discovering the error that made the missing data from Hrec
(HrecSR and HrecOR were writing in the same output "shared memory" as Hrec and with the same file name prefixes.
Now HrecSR writes into /dev/shm/VirgoOnline/HRecSRToSt and HrecOS writes into  /dev/shm/VirgoOnline/HRecOSToSt

FbmSt has been restarted also around 8h37 UTC after including in its configuration the two new inputs HRecSRToSt and HRecOSToSt

Figure 1. In the spectrum there is a new bump at 54.8Hz. It has not been there at the beginning of the year, and it isn't one of the dither lines that I am aware off. It is important to identify what is the origin of it.

The only thing that comes to my mind is the new cover of the EPRB bench. In the past there has been issues with a bump at 63Hz related to SPRB/EPRB, when EPRB was open. 

The EQB1_DBOX_03  was found in timing_errorc since 06h48m_UTC (see the attached plot), usually this occurred dutrng each maintenance period . 

The recovery was performed between 2026-10-09-10h41m16-UTC and 2026-10-09-10h43m45-UTC.

Below the details of the procedure to perform to recover the correct running confitions

Fom this VirgoOnline VPM window 

• remove the SQ1_dbox_rack server from the FbsDet server 
• stop the  EQB1_HD_CC server 
• from the SQB1_dbox_rack server
  • re-configure the full EQB1_DBOX_03 dbox board 
    • in the DMS interface, the Daq_EER_DBOX3_timing_error  flag shoud be green but the  EQB1_HD_CC_DAC_ssfs_flags  and the  SQZ_CC_DAC_ssfs_flags are red now
  • then re-configure the  EQB1_HD_CC_DAC  FAST_DAC mezzanine 
• restart the  EQB1_HD_CC server 
  • in the DMS interface, the  EQB1_HD_CC_DAC_ssfs_flags  shoud be green

As there is some signals from the  EQB1_DEMOD_03  demodulation mezzanine sent the SQZ coherent control FAST_DAC mezzanine, this one has to be re-synchronized.

From this VirgoOnline VPM window 

• stop the  SQZ_CC_Ctrl server
• from the SQZ_DBOX_DET_EERoom server
  • re-configure the  SQZ_CC_DAC FAST_DAC mezzanine
• restart the  SQZ_CC_Ctrl server
  • in the DMS interface, the  SQZ_CC_DAC_ssfs_flags  shoud be green
• perform  the reloadConfig of FbsDet server to restore the SMS data collection of the SQB1_dbox_rack server