ITF found in LOW_NOISE_3_SQZ and in Science Mode, it kept the lock for the whole shift.
ITF found in LOW_NOISE_3_SQZ and in Science Mode, it kept the lock for the whole shift.
given that the past injections performed on CARM SLOW loop through the automatic script in /virgoDev/Automation/scripts/LSC/inject_lsc.py were not sufficiently accurate (fig.1), today we increased of a factor 5 the noise amplitude. If this noise amplitude is not enough, we could increase it even further, there should be margin, see fig.2 and 3.
Looking at the ISC_Fb logfile, one can find these 2 messages:
According to these 2 messages, as the frame building is done at 5Hz, it seems that
This plot at its zoom show the LSC_PR_Z_CORR and Sc_PR_MIZ_LSC_CORR for the 2024-04-26-02h22m33 event where
Related the 2024-04-13-19h35m32 Sc_PR event
ISC_Fb logfile report
This plot show the LSC_PR_Z_CORR, Sc_PR_MIZ_LSC_CORR and others Sc_PR channel for this event where
Errata corridge: the plot of the squeezing level and the BLRMS of the first CC scan (t_start = 16:52 UTC) was erroneously equal to the one of the second CC scan. I attach the correct plot.
ITF found in Science mode.
The ITF unlocked at 2:22 UTC and the unlock seems to be correlated to a problem of DAQ/PR; see attached plot and the log file of ISC_Fb:
2024-04-26-02h22m33-UTC>ERROR..-[TfbSource::StoreData] producer Sc_PR: overflow at GPS 1398133371.999912050 (received 2021 / expected 2000) (1323 times)
This kind of behaviour is something similar to what already reported in the entry: 63958.
At the next relock the lock of the CITF took more than 30 minutes (I also performed the manual prealignment twice); once the CITF was locked LN3_SQZ was achieved at the first attempt and Science mode was set 3:58 UTC.
Gurad tours (time in UTC)
From 21:30 to 22:00; from 23:30 to 0:00; from 1:30 to 2:00; from 3:15 to 3:34.
The ITF kept the lock all the shift, science mode stopped from 16:00UTC to 18:45UTC for calibration.
- guard tours(UTC):
13:01 --> 13:44
15:06 --> 15:34
17:50 --> 18:20
19:51 --> 10:22
Calibration
- 16:01UTC: Measurement of checkHrec, NE,WE,BS,PR,SR optical responses, and sensitivity (CALIBRATED_DF_SENSITIVITY);
- 17:48UTC: Measurement of actuators response for NE,WE actuators and NI,WI,BS marionettes (CALIBRATED_DF_PCAL);
DAQ
VPM stopped to work at 15:38UTC, process restarted.
A question is if the optical gain for differential signals created inside the CITF is different from the DARM optical gain as a function of SR alignment. The 56MHz optical gain which involves being recycled by SR is not affected by the SR misaligment, because the ~1.5urad SR misalignment is small compared to the ~12m length of the CITF, and the CITF is marginally stable. Is it the same for differential perturbations created by the BS?
Figure 1 shows a lock acqusition, with SR aligned at the beginning (pole at 400Hz) and then 10 minutes later misaligned (pole at 200Hz)
Figure 2 shows three times, 21:10 UTC with SR still aligned (purple), 21:20 UTC with SR misaligned (red), 21:30 UTC with SR aligned (blue)
Figure 3 zooms on the BS drum mode (1872Hz VIR-0476A-16 https://tds.virgo-gw.eu/?content=3&r=12696). It is decreasing over the 10 minutes of SR misalignment, but then in the following 10 minutes is decreases again by the same fraction in h(t). Hence this decrease is not a change in optical gain, but just the drum mode damping. Meanwhile on B1 the first step is clearly larger, as the optical gain at high frequency changes due to the SR misalignment. So it seems the optical gain evolves the same way as the DARM gain. And there is no strange effect that the SR recycling work differently for perturbations created in the CITF and perturbations created in the arms.
Shift in Progress
ITF found in LOW_NOISE_3_SQZ and in Science Mode, it kept the lock for the whole shift.
Guard tour (UTC):
7:02 - 7:29
9:01 - 9:27
11:01 - 11:28
DAQ
During the shift the VPM stopped working three times (9:19 UTC, 9:57 UTC, 10:52 UTC). In all cases, it was possible to restart the VPM following the procedure provided by Pacaud.
I attach the plots for the two CC phase scans performed during the shift of yesterday. I was not able to produce the BNS range plot for the second scan, which is anyway visible in Fig.4.
The second scan started at 18:11 UTC, with the same duration times of shot and CC scan as of the first one.
I found ITF in SCIENCE; It remained locked for the whole shift.
ITF found in Science mode, LN3.
At 15:30 UTC ITF in Calibration mode for the planned daily calibration.
At 15:43 UTC ITF in Commissioning for the SQZ_INJ vs CC phase scan activity; after this activity the ITF has been locked in LN3_SQZ.
At 19:23 UTC ITF in Science mode.
Software
FbmMainusers restared at 17:05 after a crash.
VirgoOnline vpm instance became unreachable at 14:52 UTC; restarted by Emmanuel.
HVAC
new transformer (220V-->24V DC) of the DET AHU installed today, see 64093
Guard tours (time in UTC)
from 17:50 to 18:20; from 20:20 to 20:50.
SHIFT GOAL:
The goal was to perform several CC scan at different SR angle. Nevertheless, due the not optimum condition of the MZ and OPA (waiting for the retuning) we decid to perform a couple of scan without changing the SR angle to check the SQZ alignment-
SHIFT activity:
We started at 16:00 UTC and to not interfere with the ITF and risk to unlock, we manually injected the SQZ.
System initial status: ITF LOW NOISE 3; SQZ_MAIN @SQZ_Locked_NO_FC
16:10:39 EQB1 fast shutter opened (process: SQZ_ctrl/shutter ‘open’)
After that the CC_loop was engaged and then the AA (process: SQZ_PLL_AA/ Matrix and Filter ‘AA dither enable’).
started a CC 4MHz phase scan @ 16:52.
time per point = 6 s
- initial phase = 20 degree
- final phase = 230 degree
- phase steps = 1 degree
- random phase = False
- Closed shutter sleep time = 120 s
- AA closed on dither = False
- cc loop gain = 75000.0
N.B: No glitch during the scan, it was just before and after (see plot)
In meantime Henning checked the MZ and changed lowered again the offset at 0.035 V due to the humidity misalignment that spoiled the contrast and induced the set point near the actuator saturation. After the Henning action we redid the scan.
We stopped at 19.25 after that some data have been collected at the CC phase value corresponding to the SQZ and ASQZ, or better to the minimum and maximum values in the BRMS range @210 MHz and in other ranges.
Further data and plot in the following comments.
I attach the plots for the two CC phase scans performed during the shift of yesterday. I was not able to produce the BNS range plot for the second scan, which is anyway visible in Fig.4.
The second scan started at 18:11 UTC, with the same duration times of shot and CC scan as of the first one.
Errata corridge: the plot of the squeezing level and the BLRMS of the first CC scan (t_start = 16:52 UTC) was erroneously equal to the one of the second CC scan. I attach the correct plot.
The ITF kept science mode all the shift.
Sub-system reportsDAQ
at around 8:33UTC the VPM stopped to work and became unreachable over the net, restarted thanks to Emmanuel (#64088).
it occured a second time . VPM server restared at 2024-04-24-10h25m59-UTC
This morning, the VirgoOnline vpm instance became unreachable. This is another occurence of a known issue: https://git.ligo.org/virgo/virgoapp/VirgoProcessMonitoring/-/issues/29 .
I have restarted the instance at 2024-04-24-08h54m25-UTC .
it occured a second time . VPM server restared at 2024-04-24-10h25m59-UTC
On the 17th of April at 18:40 UTF the phase of the new signal for the DIFFp tx/ty set point, which optimize the DARM response, has been tuned.
I've used all the LN3 data since that date to evaluate the effect of this out of loop signal vs the NI and WI temperature, to check if the optimal wp for etalon corresponds also to the optical wp in which the minimum of B1p DC corresponds to the best response of DARM (considering that the DIFFp wp is tuned to minimize B1p DC, servo on the set point). The largest correlation is for TX and NI.
in figures 1 and 2 it is visible the behavior of the out of loop signal wrt the NI and WI temperatures, and it is visible that the 0 value is more or less similar to the best working point for etalon (VIR-0359A-24).
Moreover figures 3 and 4 show the behavior of BNS range and OG wrt these signal and a small offset is present (i.e. the maximum does not correspond to the 0 value, to be understood).
Tonight I found ITF relocking, 21:22 UTC ITF locked and back in SCIENCE for the whole shift.
Today after the work at UTA in DET (# 64079) the squeezed unlocked due to the change of th ehumidity condition (FIG1). I waited for humidity condition recovery to check and try to relock the MZ. It happened at about 10 UtC. I started to check about at 20:13.
Nevertheless on the signal it was and it is present an oscillation with for me not understood origin (FIG2) un. I tried to check the origin but I was not able to find it and understand. I leave the system with the MZ unlocked and tomorrow morning I will contact Henning to check.
Note that the ITF unlock happend when I put in pause the SQZ MAIN automation to work on SQZ system. Maybe it is my fault (FIG3)
ITF found locked in LN3; the Squeezing was not working for temperature transient started in the morning due to the planned work at the UTA.
ITF was in Science but the GWISTAT page was displaying VIRGO in down; at the daily meeting it was discovered that it was due to a bug introduced by Hrec connected on FbmFE.
At 13:45 UTC Hrec process was restarted by CAL team with the previous version; this fixed the issue.
At 14:00 UTC ITF in Calibration to perform the daily calibration.
At 14:14 UTC ITF in Commissioning mode for New filters for marionette reallocation; activity concluded at 18:39 UTC.
At 18:39 UTC ITF in Science mode in LN3; because of the thermal transient in in progress in DET LAB the Squeezing could not be engaged.
At 20:30 UTC the ITF unlocked; relock in progress.
DET
At 16:10 UTC DET_Main went in unknown state after an unlock; the ITF was put in NI single bounce for safety and then the situation recovered with the procedure provided by Romain.
HVAC
The work at the HVAC DET was completed around 17:30 UTC; temperature and humidity inside the standard values.
QNR
Martina tried to recover the Squeezing but she was not able to do it; investigation is in progress.
Software
At 16:48 UTC BACnetServer restarted because it was not providing data.
Today, first of all, we made a test moving the lock from ITMs marionettes to ETMs marionettes. It worked as expected (a better balancing would be required), but it unlocked with the usual 1.8 Hz oscillation when the old filters for MIR/MAR splitting were engaged. Since this fact exclude that the oscillation depends on some strange coupling with DRMI dofs, we checked again other possibilities ad we found an oscillation of CARM SLOW (fig 1). We had excluded this possibility because the first time the problem was observed, CARM SLOW appeared stable. Probably we were wrong since the beginning and the right thing to do was to work on CARM SLOW loop. Anyway, it is not clear at all why a change of actuators - supposed to be transparent in terms of loop gain - should make CARM SLOW unstable. We decided to postpone an activity on that loop, because we need more time to understand better this issue and because we should also have a look on its noise projection.
For the moment, we improved the current reallocation strategy implementing a new High-Pass filter, which is a bit more efficient everywhere and shows no issue at 1.8 Hz (fig 2). We also validated the direct transition to LN2, gaining a factor of 2 in distance from saturation during the lock acquisition. This transition is currently used by default.
This morning, from 7h00 utc to 8h10 utc, we have added the channels slow_shutter_OMC1_T1_slow and slow_shutter_OMC1_T1_fast in the SDB1_OMC process. They will be used from now to monitor the state of the OMC slow shutter.
The channel slow_shutter_OMC1_T1_fast monitors the closing of the fast shutter (see Fig.1) which is presently done with the "MOVETOLIMIT" command at a speed of 1700 steps/s. The RMS of this channel is now used as observable in DetMoni to check if the shutter motor has stopped after the closing which is supposed to take place only when the ITF is DOWN in standard operations. Thus, if the ITF_LOCK index is above 1 and if the RMS of slow_shutter_OMC1_T1_fast indicates that the shutter is still running, a red flag will be triggered in the DMS.
The channel slow_shutter_OMC1_T1_slow monitors the opening of the fast shutter (see Fig.2) which is presently done with the "MOVEREL" command at a speed of 666 steps/s. The RMS of this channel is now used as observable in DetMoni to check if the shutter motor has stopped after the opening which is supposed to take place only at index 109 of ITF_LOCK. Thus, if the ITF_LOCK index is above 109 and if the RMS of slow_shutter_OMC1_T1_slow indicates that the shutter is still running, a red flag will be triggered in the DMS.
Since we had to start/stop the SDB1_OMC process several times for these operations, we verified at the end of the activity that the demodulation phase of the OMC locking signal was still correctly tuned (Fig.3).