The FdWRawBack server configuration has been updated to use the 117TB of disks available for the RAW_BCK online stream on the stol02 host
Operation perfromed at 2026-08-04 08h31m44 UTC
The FdWRawBack server configuration has been updated to use the 117TB of disks available for the RAW_BCK online stream on the stol02 host
Operation perfromed at 2026-08-04 08h31m44 UTC
Yesterday, I put the sensors back in place and restarted the data acquisition
Yesterday, I put the sensors back in place and restarted the data acquisition.
Today we continued the work on the recovery of the lock. Just to put some context also here, during the limited time of these couple of weeks we are relocking on purpose without any TCS actuators, because of commissioning plan and forthcoming hardware interventions. The purpose is to restore things as much as possible, given that we've not been locking for four months, and we ancitipate not being able to go much farther than the beginning of the CARM offset reduction part of the lock acquisition.
We proceeded with the lock of the ALS system, that started already on Friday; today, thanks also to the increased stability of the WI actuation, we could move from the standalone arms to the beating signals and close the CARM and DARM control loops (same controllers as before, new improved ones that can profit of the ALS recent improvements will be developed later).
Then we moved to the CARM offset step, and then the realignment and lock of the DRMI:
We spent some time to check gains and phases (given that the optical configuration is different w.r.t. April): we did not find anything out of the ordinary with the exception of SRCL, which has half the gain of before; we then moved to the DRMI with 3f signals, and we could do the handoff with no problems. This configuration has a bigger deviation from the past: the 169MHz demodulation phase for MICH/SRCL has changed, and the gains of both loops needed some tuning. Nothing relevant for the PRC instead.
We took the occasion also to close the floating setpoints servo of the SDB1 local controls.
We saved the new parameters of the lock acquistion (labeled in the .ini files) and we left the DRMI locked with 3f signals.
The following report has been submitted to the On-call interface.
On-call events -> Air Conditioning
Title: Water Leak from the Autoclave System
Author(s): andreazzoli
| Called at: 21:00, 03-08-2026, by: Other colleague |
| Remote intervention: Started: ; Ended: |
| On-site intervention: Started: 21:22, 03-08-2026; Ended: 21:55, 03-08-2026 |
| Status: Resolved |
| Operator when issue resolved: None |
Details:
Following a report from the RSPP regarding a water leak from the pressure tank system, I conducted an inspection.
The water leak was attributable to the operation of the water treatment system. The system was left in normal operation.
* Note that any files attached to this report are available in the On-call interface.
The swap of the two LNFS done on July 15th has been done without exchanging the eth address of the devices. As a consequence, while restarting the automation, it was trying to communicate with the old address, thus inverting the {6, 8, 56 }MHz signals with the {22, 81}MHz. We stucked at the Fmoderr state of the INJ node, untill we swapped the ethernet cables of the two LNFS (to be noted: it seems there is the possibility to swap the ports directly into the configuration file of the LNFS server.
Because of this, we found a peculiar corner case of the FmodErr loop: after the exchange of address, the LNFS_FREQ_3 was not anymore setted on 56MHz (was instead the old 81). The check of the Fmod, however, is based on a 56MHz demodulated channel, that gave 0 correction to the loop. Eventually, no change (both MC_Z or LNFS) has been requested, and the 8Mhz frequency has not been changed (and so the 6 and 56, which are automatically updated once the 8 changes).
As a result, this morning we didn't have any modulation at 56MHz. The problem has been solved applied a reset of the 8MHz.
The Fmod loop will be updated consequently.
In order to better center the corrections for the Etalon control in the actuator dynamics we have changed in a 4 days ramp
NI to 20.1 and WI to 19.6
we report on additional results of the analysis:
About the acoustic bump at 19 Hz - we made two additional observations that support the hypothesis that is is an acousting mode of the INJ lab room (aka, laser lab bench room):
About acoustic peaks associated to the INJ and DET HVAC fans: 24 Hz and 27 Hz
About the acoustic peak at 12 Hz - this peak is associated to the main hall, it could be an acoustic mode of the hall
Sound transmission measurement (a rough look) - we injected white noise with one loudspeaker in DET terrace while all HVACs were off.
ITF found DOWN and IN UPGRADING Mode with only the north arm locked.
All times are UTC.
08:04 ALS arms realign (Boldrini, Lagabbe, Spinicelli).
10:30 ALS Recovered, Automation put back in operation, test to lock arms IR & Green via ITF_LOCK ongoing.
The automation has been restarted (#69477);
The recovery of the ITF is ongoing.
ITF left in COMMISSIONING Mode and DOWN State.
Today I re-enabled the etalon loops, using setpoints just slightly above the current temperatures, just to monitor the corrections:
These setpoints were changed online, and also in the configuration file.
Between yesterday and today we put back in operation most of the automation:
We tested up to LOCKED_ARMS_IR_ALS, we'll continue the recovery in the usual way from now on.
I received notification of WE PCal error via the DMS. The power on the Rx sphere is very unstable and goes close to 0. This must be related to the alignment of the WE mirror, which results in the PCal reflected beam going outside the sphere input port.
I have switched off the Pcal beam so the beam does not move around on the Rx bench. We will switch it on later (probably only on Monday, not being available in the next two days).
The following information summarizes the directory structure and file naming convention for the measurements performed on the NI and WI instrumented baffles.
*** NI instrumented baffle ***
where
# is the measurement (SIG) number reported in the action list;ch1 = mono-axial reference accelerometer;ch2 = triaxial accelerometer, x-axis;ch3 = triaxial accelerometer, y-axis;ch4 = triaxial accelerometer, z-axis.*** WI instrumented baffle ***
The same file naming convention described above applies to the WI measurements.
An example MATLAB script (ReadInstrumentedBaffleData) is attached to show how to read the time-series data.
Plots showing the result of WI MIR actuation cheks are attached. If a voltage is generated by UL DAC (seen by the monitor inside the board), no effect is visible on the mirror orientation (fig 1). If the same is done with one of the other DACs, the rotation is well visible (fig 2).
Pcal NE switched on on July 31 at 7:55 utc.
On July 30 afternoon, we went to the laser lab to realign the ALS laser beam on EIB. We used the CEB_PD_GREEN_MONI photodiode as reference for alignement. The mirrors before the green generator cristal (EIB_ALS_M4 and 5) were realigned to it maximize the power in that photodiode. Then the mirrors EIB_ALS_M6 and 7 were realigned with the IR fiber, using the IR power send to WEB and NEB as reference.
For a reason we still don't understand, CEB_PD_GREEN_MONI photodiode cease to work from 15h to 16h. But it started to work again after we disconnected and reconnected the power supply and Vbias cable.
We recalibrated the CEB_PD_GREEN_MONI photodiode gain and offset in the DAQ so it estimates the total green laser power on EIB. And we changed the threshold values on the DMS for the photodiodes CEB_PD_GREEN_MONI and CEB_PD_IR_MONI.
The green beam was also realigned with the fiber photodiodes CEB_NARM_BEAT and CEB_WARM_BEAT, but this alignment can still be improved by playing with the pico-motors EIB_ALS_pico1 and 2.
The up-left coil looking from the rear side has an issue with the shielding of its cable https://logbook.virgo-gw.eu/virgo/?r=69386
Is that the same coil-magnet pair which is not responding to DAC actuation? Electrical checks should be done as a priority in any case, but if the up-left coil-magnet pair is the issue, then it makes it more likely that this is an electrical problem.
Yesterday and today we worked on the realignment and the relock of the two arms. We spent many hours in finding the alignment again, for both arms.
In the end we managed with a mix of procedures:
After a pause this afternoon to allow other activities, in the evening we managed to finally get some flashes.
We then started to work on the relock:
We leave the two arms locked, in standalone, using the single arms lock nodes.
The up-left coil looking from the rear side has an issue with the shielding of its cable https://logbook.virgo-gw.eu/virgo/?r=69386
Is that the same coil-magnet pair which is not responding to DAC actuation? Electrical checks should be done as a priority in any case, but if the up-left coil-magnet pair is the issue, then it makes it more likely that this is an electrical problem.
Plots showing the result of WI MIR actuation cheks are attached. If a voltage is generated by UL DAC (seen by the monitor inside the board), no effect is visible on the mirror orientation (fig 1). If the same is done with one of the other DACs, the rotation is well visible (fig 2).
ITF in UPGRADING - DOWN
Today's activities:
Arms recovery (Bersanetti, Boldrini, Majorana, Ruggi, Spinicelli, Was)
TCS auxiliary cooling system cabling - new data channels (Cavalieri)
ALS recovery (Lagabbe, Spinicelli)