Figure 1. To provide more context, adding also the O4 high noise curve, and one of the measured O3b sensitivity curves to the present B1 photodiode electronic noise.

Figure 2 is a copy of slide 14 of (VIR-0630A-20) which shows the noise level of the B1 photodiodes used during O3b onto the O4 sensivitiy curve. The O3b photodiodes have about 3 times less noise that the ones which are installed right now. Compared to an ideal situation, the O3b photodiodes noise has a minor impact (in that example with technical noises lowering the range from 108 Mpc to 107 Mpc), and a ~5% sensitivity loss at high frequency in the shot noise limited region (assuming 4dB of squeezing).

This morning Walid has suggested a test to understand if the excess of noise could be excited by the HVAC of the injection.

Davide has switched off the in and out fans at 8:07 UTC and the whole system at 9:09 UTC.

No change in the noise see Figure 1.

This change of DAS position might have changed the position in Y of the sidebands wrt carrier in the recycling cavity (see Figure 1).

Figure 2 and 3 shows the same signals in two other locks on Jan 28th and Jan 31st.

In the first case the ITF was already hot (had been locked previously).

In the second case it was cold.

The change in the DAS position done yesterday seems to trigger some change in the Y position of the carrier wrt to sidebands.

As usual the 56 MHz LSB tends to follow the carrier while the other SB's don't.

ITF State: ITF in relocking, ITF Lock request: CARM_NULL_3F, autorelock failsafe engaged.
Quick Summary: all suspension loops closed; all SBEs loops closed; DAQ_Eurotherm not reachable; EERoom temperature below threshold; many red flags for ACS
activity ongoing:OSD calibrations

According to Fiodor one of the goals of this work was to see if it is possible to change the interferometer contrast by changing the DAS position.

The Figure attached to this plot shows that indeed B1p_DC changed by 10% during the shift. For comparison, this is the same amount of change that was obtained this weekend by changing the SR CHRoCC.

The problem is that this change in the dark fringe power does not seem to relate to the changes in the DAS.

There are at least three other changes in the alignment going on at the same time:

1) The alignment of the input beam wrt to the arm cavity is changing as witnessed by the B4 quadrants.

2) There is a new process that changes the relative alignment of the two arms by moving DIFFp offset and BS offset every 5 to 10 minutes

3) Not visible on the plots, but there is also the usual shift of the beam in the laser lab for which we do not have an indipendent monitor

In conclusion, it is not possible to conclude on the effect of the DAS because the alignment is changing too much for other reasons.

By the way, it seems that the new process acting on DIFFp and BS is having a non negligible effect on the erratic changes of the dark fringe and producing regular spikes on COMMp.

The shift was dedicated to the planned TCS activity, Fine tuning of DAS position, carried out by Lumaca with the ISC support of Casanueva. After some unlocks at LOCKING_CARM_NULL_1/3F, we were able to achieve CARM_NULL_1F at 15:26 UTC. Following a period of thermalization, the TCS crew started to adjust the DAS of NI and WI.
Activity concluded at 22:28 UTC, ITF left relocking (after an unlock at 21:54 UTC) with AUTORELOCK_FAILSAFE engaged.

DAQ
The processes FdWRawFull and FdWRawFull1 crashed multiple times during the shift. Processes restarted via VPM.

TCS
At the beginning of the shift the TCS crew reported that they were not able to communicate with their Picomotors. Following Lumaca and Nardecchia instructions, I went to the TCS Room and restarted the drivers at around 15:05 UTC. This operation restored the communication with the motors.

The goal of the shift was to investigate the ITF behavior by moving the CO2 actuators on the ITMs.

As suggested by the commissioning coordinator, after the work performed on the ITMs/YAG alignment of the past days (58580, 58595, 58611), we started by investigating the vertical direction, moving separately the NI DAS first and the WI DAS after. Here are the details:

• 15:27 UTC: CARM NULL 1F

• 17.07 UTC: STEP (1) NI CO2 actuators moved by 5 mm along vertical direction (TX) upward (backward)

• 19.23 UTC: STEP (2) WI CO2 actuators moved by 5 mm along vertical direction (TX) upward (backward)

We observed that (Fig.1):

• B7 and B8 started to separate in between STEP (1) and (2)

• 12 MHz have bumps corresponding to the STEPs done and then stabilized at a level slightly improved wrt the previous one; similar behavior for 112 MHz

• B1p raised a bit up, but the drift was already ongoing before doing STEP (1)

• A small improvement of sidebands/carrier overlap is visible on PosX, starting form STEP (1): 56MHzLSB raised up, together with CAR.

The plot in Fig. 2 shows the evolution of the main figures of merit from the controls point of view. Starting around 18.00 we can see a differential variation of the arms power that doesn't seem related to the TSC activity. Also during the whole lock the SRCL SET and the DCP seem to have a decreasing trend not correlated to the TCS activity. Regarding the sidebands and B1p DC it seems to be a small increase of the power at the same time as the movement of the TCS actuators. It is not clear the effect on the CMRF. 

Overall, the impact of these actions is not very big.

We decided to leave the CO2 actuators in this last alignment position, to further investigate its effect on ITF signals.

At the end of the shift, at 21.46 UTC the CH flip mirrors were opened one per time to raise up the powers, to improve the lock acquisition (issues highlighted here 58631). The following table summarize the changes (bold):

During the N CH power change, the ITF unlocked. We tried some unlucky attempts to relock and then Julia and Magazzu put the ITF in autorelock up to CARM NULL.

During the maintenance I did an upgrade of SIB1 control software for allowing the swap from INJ AA signals to B2 quadrant. I put also the oppurtunity to keep TZ in local control (drift control on INJ AA) separately from the other loops, as it was for TY. The lock is going on in this configuration since the afternoon, with a consistent reduction of noise on B2 and B4 quadrants. One can also notice an increase of noise just above 100 mHz due to a modified seismic activity. PR vertical motion should be the responsible.

Figure 1 shows the dark noise of the B1 photodiodes that are used right now, compared to the O4 low noise curve (115Mpc range) assuming 10mW on the B1 beam (5mW per photodiode)

FIgure 2 show the measured dark noise of these photodiodes that was used as input to figure 1. And an estimate of the flicker noise was added to it. Assuming 200 Ohm resistor for the total resistance load for the Audio channel. The flicker noise is actually negligible, because the resistor load is 10 times smaller than during O3. So with 10 times lower flicker noise, and 3 times higher thermal resistor noise. So the thermal resistor noise is dominating, and easily measured without light on the PD.

In terms of range, keeping the present photodiodes would cost at 15 Mpc in range, if the detector would be at 115Mpc of BNS range. But for 60Mpc of range it cost only 2.5Mpc of less range, and at 40Mpc it cost 0.8Mpc. So replacing the photodiode is motivated from BNS range perspective once we have a range of at least 40 Mpc. Although it could mean as much as 50% less sensitivity in any shot noise limited region of the noise curve.

Looking more closely at the first order mode, it seems that the OMC misalignment is mostly vertical.

At the beginning of yesterday's shift, we tried to stabilize the state of the etalon loop by setting a working point easier to reach (19.038 @ 14.56 UTC). As the loop was not working fast enough we tried a working point even closer to the present one (19.138 @ 17.11 UTC). Since the thermalization was still too slow, we decided to complete the etalon test and change the set point to 19.3 @ 17.59 UTC.

Today during the tests, none frame was lost: there is no grey  period on all the plots only few SMS channels were not collected (see first plot) .

See the logbook 58457 for the tests last week.

On the second plot,  the green rectangle refers to the time period of the tests

• the first one(cyan rectangle) refers to the  "Fault Tolerance resuming" period where none variation is present 
• the second one(red rectangle) refers to  " Fault Tolerance active" period where one can see an increase of the iowait of the olserver53 due to the activity of the PyDAQ servers , which scan the some disk repositories (/virgoLog, ..)

This morning I moved from Tango to VPM the TangoCmLaserAmp server (now called SmNeoL_HP see picture), that was running without problems on Tango since few years. Now all channels are already available on DAQ.

SSFS

For debugging purposes, the SSFS_noise server has been updated to compute the frequency fluctuations based on B4_6MHz_{I,Q}  channels

LSC: new channels

• On MIchal's request, the LSC_Acl_Moni server has been udpated to demodulate the B1p_56MHz_I channel at the following lines
  • SSFS(3345Hz)  : available output channels named LSC_B1p_56MHz_SSFS_LINE_{mag, phi, I, Q}
  • FMOD(1111Hz) : available output channels named LSC_B1p_56MHz_FMOD_LINE_{mag, phi, I, Q}
  • IMC(33Hz) : available output channels named LSC_B1p_56MHz_IMC_LINE_{mag, phi, I, Q}
• On Raffaele's request, the LSC_Acl_Moni server has been updated to demodulated the DARM channel at the following DARM lines
  • DARM(74,4Hz): the output channel is named LSC_DARM_LINE_MAG
  • DARM_LF(176,3Hz): the output channel is named LSC_DARM_LINE_LF_MAG
  • DARM_HF(491,3Hz): the output channel is named LSC_DARM_LINE_HF_MAG

ALS

On request of the ALS team

• the NARM beam channel is now demodulated at the WARM frequency and the WARM beam channels is now demodulated at the NARM frequency
  • the data are acquired but not yet  used by the CEB_ALS server
• the ALS_{N,W}EB_Corr channels at 50KHz have been sent to the CEB_ALS server to be used for noise investigations . The code is almost ready .

This morning Francesco performed a couple of OMC scans with the ITF in single bounce beam. Fig.1 shows the two scans.

The first scan (Fig.2) (10h50 - 11h12 utc) was performed right after Francesco realigned and relocked the cavities, before setting the single bounce. Fig.3 shows a zoom on one FSR:

The power in the carrier TEM00 (52 uW) is only half of what we normally get when the OMC is correctly aligned. The first order mode has 36 uW and the second order mode has 18 uW. Thus the sum of the first and second order mode is higher than the TEM00 power. This indicates a clear misalignment of the OMC. It is probably not possible to make a clear assessment on the mode matching with such a large misalignment.

During the second scan (11h30 - 11h52 utc) (Fig.4) the power in the TEM00 was even smaller, indicating that the misalignment was even worse, probably because of a misalignment of the single bounce beam.

The bottom line is that the OMC needs to be realigned in single bounce. Then another OMC scan should be performed in order to assess the level of the mode matching.

Below the list of the activities communicated in control room during the maintenance shift:

• standard vacuum and cleaning operations; concluded at 11:30 UTC.
• tests by Alain in the lock acquisition.
• CO2 powers check.
• Moved Magnetometers in CB from the TCS terrace to the filter cavity tube.
• Test of main fileserver fs01 performance during HA actions on underlying VMware hypervisor
• check the ropes of the bridge cranes of all buildings; activity concluded.
• from 8:30 UTC test on fiber amplifier noise by PSL team; activity concluded at 14:20 UTC.
• check and refill TCS chiller (Ciardelli).

ITF relocking in progress...

HVAC

from 8:30 UTC to 9:10 UTC UTA INJ in "portata nominale"

DET

• 10:42 UTC I performed the lock of OMC in single bounce
• 10:51 UTC I performed the scan of OMC in single bounce
• 11:52 UTC I performed the scan of OMC in single bounce

This morning, we found the microphone NN_WEB_INF_Z_24 broken and on the floor of the WEB air handling unit.

This morning,  we installed new sensors in the WEB air handling unit room:

• ENV_WEB_UTA_MIC  - microphone inside AHU room
• ENV_WEB_UTA_SUP_ACC - pcb accelerometer on supply air duct 
• ENV_WEB_UTA_RET_N_ACC - meggit accelerometer on North return air duct 

The accelerometer ENV_WEB_UTA_FLOOR was removed and installed on the return air duct.
We reinstalled the accelerometer on the frame of the fun-motor (inside the AHU case): ENV_WEB_MOTOR_ACC.
 

For convenience, a spectrogram showing the operating times is attached (data are valid from 12:00 UTC onward).
With this new position, the 2.24 Hz sidebands of the 50 Hz mains generated by the CEB HALL UTA are again visible.

Using the excitation line of SR the calibration of the error signals have been measured as QPD1/2_h/v/SR_MIR_ty/tx|_exc_line.

the values found are:

qd1h/SR ty= 2.9e-4; qd2h/SR ty = 6.5e-5;

qd1v/SR tx = -3.5e-4 ; qd2v/SR tx = 1.4e-4;

we can then calibrate the offsets between 25MHz QPDs signal and the SR DCP signal, see Figure 1, which is not negligible.

I' m then studying if the combination of the two can give a signal for SR (some tests are needed).

In order to find the reason of some seconds of data loss of last wednesday ( https://logbook.virgo-gw.eu/virgo/?r=58547 )  on olserver52 DAQ framebuilder we performed the same actions on the VMware Fault Tolerance (FT) infrastructure that we did last tuesday and wednesday.

Filesystem affected could be in principle: /olusers, /virgoData, /virgoLog, /virgoApp, /virgoDev.

Chronology - baseline status is with FT paused

9:25 LT: start of Fault Tolerance resuming (a fs01 disk image replica is built transparently)

...  no appreciable effects spotted on nfs clients performance

9:57 LT: Fault Tolerance active (the disk image replica has completed and a standby replica of the fs01 VM is synchronized in lockstep in realtime) ; a glitch occurs on the olserver52 network output flux

...  load on fs01 increases 5 times, olserver53 cpu IOwait increases from 0 to 1.25% , there are no effects on the stolxx writing servers

10:45 LT: Fault Tolerance is paused and left in this state (the fs01 standby VM and disk replica is destroyed); a second glitch appears on the olserver52 network output flux

As requested by Fiodor, this morning we checked the CO2 power actuators switching off/on each actuator one by one.

Here a recap of all settings:

We recovered the power of the WI DAS Outer that was lower  by 5 % wrt the nominal value.

The activity has been concluded at 11.40 UTC.   

Today around 8:10 CET, the ENV_CEB_MAG{N,W,V} magnetometers have been dispaced from their position on the TCS room terrace to the wall behind the filter cavity tube (figure 2), and their acquisition from the TCSroom to the DET electronic lab. The acquisiton is back to  DET_ADC7674 ...Moni1 (ADC #44) Ch: 8,9,10. The improvement in noise is evident (figure 1) in a wide frequency range.

The North magnetometer is under the "wheeled lockers" on their front side, because the in the rear it was saturated by 50Hz.

Figure 1 shows the data in DC read-out from Friday. The CMRF (coupling of SSFS/FMOD lines to DARM), varies around zero, with maybe an offset that is a factor few smaller than the fluctuations. Looking at the spectra of the coupling. There is a visible bump at 6mHz in the coupling. It would be interesting to understand what is fluctuating at that frequency, and try to improve it to make the CMRF more stable in time. Less clearly, but the DARM optical gain also seem to fluctuate at that frequency.

Francesco Di Renzo has worked on making the MONET bilinear analysis more accessible. It is sufficiently simple and well documented to start using it under one hour of learning time. Although the output is still a bit hard to navigate, and relies in many ways on reading a text file.

Analyzing the 1111Hz line, the dominant reason for coupling fluctuations are:

Figure 2 COMMp TX below 250mHz

Figure 3 DIFFp TX between 250mHz and 1Hz

Figure 4 shows all of the bilinear coupling that the analysis is able to explain based on the following channels tried for blinear coupling of 1111Hz x other channel:

V1:ASC_BS_TX
V1:ASC_COMMp_TX
V1:ASC_DIFFp_TX
V1:ASC_PR_TX
V1:ASC_SR_TX
V1:ASC_PR_X_CORR
V1:SDB2_B5_QD2_H

V1:Sc_NI_MIR_X_AA
V1:Sc_NE_MIR_X_AA
V1:Sc_WI_MIR_X_AA
V1:Sc_WE_MIR_X_AA

V1:Sc_BS_MIR_TX_AA
V1:Sc_PR_MIR_X_AA

V1:ASC_BS_TY
V1:ASC_COMMp_TY
V1:ASC_DIFFp_TY
V1:ASC_PR_TY
V1:ASC_SR_TY
V1:ASC_PR_Y_CORR
V1:SDB2_B5_QD2_V

V1:Sc_NI_MIR_Y_AA
V1:Sc_NE_MIR_Y_AA
V1:Sc_WI_MIR_Y_AA
V1:Sc_WE_MIR_Y_AA

V1:Sc_BS_MIR_TY_AA
V1:Sc_PR_MIR_Y_AA 

V1:LSC_DARM
V1:LSC_PRCL
V1:LSC_MICH
V1:LSC_SRCL
V1:SDB1_OMC1_err
 

Figure 5 just confirms the result of MONET using simple coherence between COMMp/DIFFp TX and the LSC_DARM_SSFS_LINE channels. In partiuclar the 6mHz is well visible on COMMp_TX, and coherent.

12 hours of lock on Jan 19th. Arm alignment strategy was different (B4 quadrant in loop). All the other drifts were not too different.