Reports of 58200
AdV-ISC (Commissioning up to first full interferometer lock)
mantovani, spinicelli - 16:32 Friday 29 March 2024 (63788) Print this report
Start of long etalon 2D scan

This afternoon, at 15.24UTC we started the 2D etalon scan which will take 1 week long.

As previously indicated, we had to initially tune the phase for the WI scan.

The final values used are the following:

amplitude 0.4

duration 604800 s

sin phase -pi/4

AdV-DAQ (Data collection)
cortese, kraja - 15:10 Friday 29 March 2024 (63786) Print this report
Comment to 20 second missing data period, from GPS1395725958 to GPS1395725978 (63783)

Today from 6:38:34 to 6:38:54 LT the volume of the fs01 fileserver had a temporary problem causing the NFS filesystems /virgoLog, /virgoData, /virgoApp, /virgoDev, /olusers to suffer of an increased latency (up to 5 times in writing).

No errors/warnings have been registered by the rtpcs OS, but evidently the delay has been enough to overflow the DAQ transmit buffers.

The root cause of the volume access glitch is currently not yet understood.

Virgo Runs (ER16)
menzione - 15:00 Friday 29 March 2024 (63781) Print this report
Operator Report - Morning shift

Upon arrival I found ITF locked at LN3.
After the intervention from remote on SQZ crew, Vardaro asked me to engage the SQZ but the effect was not the desired (no improvement in sensitivity) Experts at work...
At 07:17 UTC ITF unlocked due to an Earthquake with Mag 5.8 in Greece (pict1). The unlock opened SNEB and SIB2 Loops. Properly closed via VPM.

Lock acquisition restarted immediatly. ITF back in in LN3_SQZ at second attempt at 08:44 UTC but it unlocked at 08:52 UTC due to a PR trip (plot1), Boschi alerted and he will investigate next tuesday. 

Upon relocked, according with commissioners and Sorrentino, Zendri from remote performed a SQZ scan.

Science Mode again at 11:20 UTC. ITF unlocked at 12:45 UTC, again for a PR trip (plot2).
Science Mode again at 13:36 UTC.

Images attached to this report
AdV-SGD (FDS commissioning)
zendri - 14:53 Friday 29 March 2024 (63785) Print this report
SQZ phase scan
This morning a CC angle phase scan was launched to verify that the squeezing angle is in the optimal position.
phase scan:
initial time=1395745088 s
duration-1260 s
shot noise reference
initial time=1395744368
duration= 700 s

Unfortunately, as visible in the two figures, the results were a bit distorted by a glitch occured at about 230 s. from the beginning of the scan. The optimal angle seems to range between 3.7 and 3.8 radians which is the current value. Therefore I did not change the squeezer setting.

Images attached to this report
AdV-ISC (Alignment control scheme conceptual design)
mantovani - 14:02 Friday 29 March 2024 (63784) Print this report
Comment to Effect of DIFFp tx and ty set point servo not active @ LN3 on Detection peaks amplitude (63782)

The servo has been re-engaged @ LN3 (and now it is in the automation)

It is visbile that the SDB2 structures disappear or reduced with the servo on, figure 1 purple servo off blue servo on.

Images attached to this comment
AdV-DAQ (Data collection)
masserot, mours - 11:39 Friday 29 March 2024 (63783) Print this report
20 second missing data period, from GPS1395725958 to GPS1395725978

Today at 05h39m-UTC

  • all the TolmFrameBuidler servers reports that they were unable to transmit theirs frames built at 5Hz  to FbmFFE frame mergers
    • ALS_CEB_Fb: 2024-03-29-05h39m01-UTC>ERROR..-frame 1395725958 not send to FbmFFE: sending queue is full
    • ALS_NEB_Fb: 2024-03-29-05h39m04-UTC>ERROR..-frame 1395725961 not send to FbmFFE: sending queue is full
    • ALS_WEB_Fb: :2024-03-29-05h39m04-UTC>ERROR..-frame 1395725961 not send to FbmFFE: sending queue is full
    • INJ_Fb: 2024-03-29-05h39m03-UTC>ERROR..-frame 1395725961 not send to FbmFFE: sending queue is full
    • ISC_Fb: 2024-03-29-05h39m03-UTC>ERROR..-frame 1395725961 not send to FbmFFE: sending queue is full
    • SDB2_Fb: 2024-03-29-05h39m03-UTC>ERROR..-frame 1395725961 not send to FbmFFE: sending queue is full
    • SDB_EDB_Fb: 2024-03-29-05h39m03-UTC>ERROR..-frame 1395725961 not send to FbmFFE: sending queue is full
    • SIB2_Fb: 2024-03-29-05h39m03-UTC>ERROR..-frame 1395725961 not send to FbmFFE: sending queue is full
    • SNEB_Fb: 2024-03-29-05h39m03-UTC>ERROR..-frame 1395725961 not send to FbmFFE: sending queue is full
    • SPRB_Fb: 2024-03-29-05h39m03-UTC>ERROR..-frame 1395725961 not send to FbmFFE: sending queue is full
    • SQB1_Fb: :2024-03-29-05h39m03-UTC>ERROR..-frame 1395725961 not send to FbmFFE: sending queue is full
    • SQB2_Fb: 2024-03-29-05h39m05-UTC>ERROR..-frame 1395725958 not send to FbmFFE: sending queue is full
    • SQZ_Fb: 2024-03-29-05h39m01-UTC>ERROR..-frame 1395725958 not send to FbmFFE: sending queue is full
    • SSFS_Fb: 2024-03-29-05h39m04-UTC>ERROR..-frame 1395725961 not send to FbmFFE: sending queue is full
    • SUSP_Fb: 2024-03-29-05h39m03-UTC>ERROR..-frame 1395725961 not send to FbmFFE: sending queue is full
    • SWEB_Fb: 2024-03-29-05h39m03-UTC>ERROR..-frame 1395725961 not send to FbmFFE: sending queue is full
    • and that they flushed their queues of 20 frames with a dt of 0.2 s : meaning that 10s of date have been lost
      • output queue to FbmFFE has been flushed; Sending frame 1395725968
  • All the Front End DAQ  *_50Hz servers reports
    • 2024-03-29-05h39m16-UTC>WARNING-FdIOPutFrame: miss 11.8 seconds between 1395725961.8 and 1395725973.6
  •  The FDS_Img_Fb and Imaging servers reports that they were unable to transmit theirs frames built at 1Hz to FbmFE frame mergers
    • FDS_Img_Fb: 2024-03-29-05h39m02-UTC>ERROR..-frame 1395725959 not send to FbmFE: sending queue is full
    • DET_Img_CEB: 2024-03-29-05h39m07-UTC>ERROR..-Could not output frame at GPS=1395725965.000 iFr=4 listIn=1241424 0x7fdd3d4774f0
    • DET_Img_End: 2024-03-29-05h39m08-UTC>ERROR..-Could not output frame at GPS=1395725966.000 iFr=7 listIn=1241457 0x7ff338004dc0
    • FDS_Img: 2024-03-29-05h39m08-UTC>ERROR..-Could not output frame at GPS=1395725966.001 iFr=2 listIn=1441382 0x7fdcf8005010
    • INJ_Img: 2024-03-29-05h39m07-UTC>ERROR..-Could not output frame at GPS=1395725965.002 iFr=4 listIn=853654 0x7f8628bcf9f0
    • PAY_Img_50Hz::2024-03-29-05h39m08-UTC>ERROR..-Could not output frame at GPS=1395725966.002 iFr=5 listIn=1441435 0x7f7a40159e00
    • PAY_Img: 2024-03-29-05h39m08-UTC>ERROR..-Could not output frame at GPS=1395725966.002 iFr=4 listIn=1441454 0x7fa00c004680
  • The Frame File monitor servers  reports
    • FmStol01:  20s of missing data

      2024-03-29-05h40m43-UTC>ERROR..-CHANNEL> At Mar29,24-05:39:12 1395725970, V1:SDB2_B1p_PD1_Blended missing 20, V1:SDB2_B1p_PD2_Blended missing 20, V1:SDB2_B1_PD1_Blended missing 20, V1:SDB2_B1_PD2_Blended missing 20, V1:SNEB_B7_DC missing 20, V1:SWEB_B8_DC missing 20, V1:SPRB_B4_56MHz_Q missing 20, V1:SIB2_B2_8MHz_I missing 20, V1:CAL_NE_MIR_Z_NOISE missing 20, V1:CAL_WE_MIR_Z_NOISE missing 20, V1:Sc_BS_MIR_Z_CORR missing 20, V1:Sc_PR_MIR_Z_CORR missing 20, V1:Sc_NI_MIR_Z_CORR missing 20, V1:Sc_WI_MIR_Z_CORR missing 20, V1:Sc_NE_MIR_Z_CORR missing 20, V1:Sc_WE_MIR_Z_CORR missing 20, V1:Sc_BS_MAR_Z_CORR missing 20, V1:Sc_PR_MAR_Z_CORR missing 20, V1:Sc_NI_MAR_Z_CORR missing 20, V1:Sc_WI_MAR_Z_CORR missing 20, V1:Sc_NE_MAR_Z_CORR missing 20, V1:Sc_WE_MAR_Z_CORR missing 20,  are back

  • FmStol02: 20s of missing data

    2024-03-29-05h40m55-UTC>ERROR..-CHANNEL> At Mar29,24-05:39:12 1395725970, V1:SDB2_B1p_PD1_Blended missing 20, V1:SDB2_B1p_PD2_Blended missing 20, V1:SDB2_B1_PD1_Blended missing 20, V1:SDB2_B1_PD2_Blended missing 20, V1:SNEB_B7_DC missing 20, V1:SWEB_B8_DC missing 20, V1:SPRB_B4_56MHz_Q missing 20, V1:SIB2_B2_8MHz_I missing 20, V1:CAL_NE_MIR_Z_NOISE missing 20, V1:CAL_WE_MIR_Z_NOISE missing 20, V1:Sc_BS_MIR_Z_CORR missing 20, V1:Sc_PR_MIR_Z_CORR missing 20, V1:Sc_NI_MIR_Z_CORR missing 20, V1:Sc_WI_MIR_Z_CORR missing 20, V1:Sc_NE_MIR_Z_CORR missing 20, V1:Sc_WE_MIR_Z_CORR missing 20, V1:Sc_BS_MAR_Z_CORR missing 20, V1:Sc_PR_MAR_Z_CORR missing 20, V1:Sc_NI_MAR_Z_CORR missing 20, V1:Sc_WI_MAR_Z_CORR missing 20, V1:Sc_NE_MAR_Z_CORR missing 20, V1:Sc_WE_MAR_Z_CORR missing 20,  are back

 

The origin of the 20 second missing data period, from GPS1395725958 to GPS1395725978, is not obvious: investigations in progress

Comments to this report:
cortese, kraja - 15:10 Friday 29 March 2024 (63786) Print this report

Today from 6:38:34 to 6:38:54 LT the volume of the fs01 fileserver had a temporary problem causing the NFS filesystems /virgoLog, /virgoData, /virgoApp, /virgoDev, /olusers to suffer of an increased latency (up to 5 times in writing).

No errors/warnings have been registered by the rtpcs OS, but evidently the delay has been enough to overflow the DAQ transmit buffers.

The root cause of the volume access glitch is currently not yet understood.

AdV-ISC (Alignment control scheme conceptual design)
mantovani - 9:34 Friday 29 March 2024 (63782) Print this report
Effect of DIFFp tx and ty set point servo not active @ LN3 on Detection peaks amplitude

It has been observed that the servo for the set point of DIFFp tx and ty is not active at low noise 3 (to minimize the B1p DC) and this has always had an impact on the structure on the detection bench caused by diffused ligth.

For this reason I' ve analyzed the last 20 days of LN3 locks and I' ve taken sets of 600 sec in which the correlation between the DIFFp TX and TY inputs and B1p DC are evaluated with a linear fit.

It is visible (for the tx dof) that the higher correlation (higher slope of the fit, which correspond to the set point far from the optimal one) corresponds to a larger amplitude of the peaks (in DARM).

This analysis is to stress the fact that we need to re-engage the servo @ LN3.

Images attached to this report
Comments to this report:
mantovani - 14:02 Friday 29 March 2024 (63784) Print this report

The servo has been re-engaged @ LN3 (and now it is in the automation)

It is visbile that the SDB2 structures disappear or reduced with the servo on, figure 1 purple servo off blue servo on.

Images attached to this comment
On-call intervention (General)
Oncall-system - 8:20 Friday 29 March 2024 (63780) Print this report
On-call intervention

The following report has been submitted to the On-call interface.

On-call events -> Interferometer Sensing & Control

Title: ITF not locking

Author(s): mantovani

Called at: 20:00, 28-03-2024, by: Magazzu
Remote intervention: Started: 20:00, 28-03-2024; Ended: 20:50, 28-03-2024
On-site intervention: Started: ; Ended:
Status: Resolved
Operator when issue resolved: Magazzu

Details:

I've been called since the ITF was unlocking at Carm null, pointing towards failure of SSFS.
I've checked a lock acquisition and everything went fine.

* Note that any files attached to this report are available in the On-call interface.

Virgo Runs (ER16)
vardaro - 7:20 Friday 29 March 2024 (63779) Print this report
Comment to Operator Report (63778)

After the tuning of the source performed by Henning yesterday morning, the SQZ source was in a state in which was not possibile to engage it directly using automation. I locked it by hand now it is possible to inject SQZ again.

Next week I will add two lines in the automation to overcame this problem 

Virgo Runs (ER16)
gherardini - 6:53 Friday 29 March 2024 (63778) Print this report
Operator Report
The relock was a bit difficult with fails in almost all the steps of the lock acquisition, here the calibration at LOW_NOISE_3:

- 00:47UTC: Measurement of actuators response for NI,WI mirrors (CALIBRATED_DF_INtoEND_LN);
- 01:41UTC: Measurement of actuators response for NE,WE actuators and NI,WI,BS marionettes (CALIBRATED_DF_PCAL);
- 02:14UTC: Measurement of checkHrec, NE,WE,BS,PR,SR optical responses, and sensitivity (CALIBRATED_DF_SENSITIVITY);

it was not possible to engage the squeezing with the SQZ_MAIN metatron node stuck in SQZ_LOCKING_NO_FC state (experts informed by mail), science mode started at 3:00UTC


- guard tours (UTC):
4:14 --> 4:44
Images attached to this report
Comments to this report:
vardaro - 7:20 Friday 29 March 2024 (63779) Print this report

After the tuning of the source performed by Henning yesterday morning, the SQZ source was in a state in which was not possibile to engage it directly using automation. I locked it by hand now it is possible to inject SQZ again.

Next week I will add two lines in the automation to overcame this problem 

Virgo Runs (ER16)
amagazzu - 23:08 Thursday 28 March 2024 (63777) Print this report
Operator Report - Afternoon shift

Upon reaching the site, I found the ITF in LOCKED_ARMS_BEAT_DRMI_1F, with Gouaty investigating on the B1p_QD1 issue. After the problem was solved (see report #63776) we attempted to relock, but due to the strong weather condition, it was not possible to reach CARM_NULL_1F stably. The wind intensity slowly decreased, but the ITF kept systematically unlocking at LOCKING_CARM_NULL_3F or LOCKING_CARM_NULL_1F. At 19:00 UTC I contacted the ISC Oncall (Mantovani) but, at the following attempt and without adjustments, we were able to reach LOW_NOISE_3 at 19:55 UTC. I tried to reach LOW_NOISE_3_SQZ, but SQZ_MAIN was stuck in SQZ_LOCKED_NO_FC.
At 20:42 I set the ITF Mode in CALIBRATION and started the planned Calibrations.

20:43 UTC - Measurement of actuators response for NE,WE actuators and NI,WI,BS marionnettes, interrupted at 21:05 UTC due to an unlock;
21:06 UTC - Measurement of the TF between CAL and Sc channels, completed;
21:15 UTC - Measurement of actuators response for PR and BS mirrors;

Calibrations in progress.

Guard Tour
18:06 UTC - 18:50 UTC
20:01 UTC - 20:31 UTC

Oncall events

ISC
(28-03-2024 19:00 - 28-03-2024 19:50) From remote
Status: Ended
Description: During the shift, the ITF kept unlocking systematically at LOCKING_CARM_NULL_3F or LOCKING_CARM_NULL_1F.
Actions undertaken: I contacted the ISC Oncall (Mantovani), the ITF locked without further input at the following attempt.

Images attached to this report
AdV-COM (AdV commissioning (1st part) )
casanueva, masserot - 19:23 Thursday 28 March 2024 (63774) Print this report
Patch for the ALS glitches by clipping the DARM_FREQ signal

Looking at some ALS events of the 2024-03-27 night

A possible simple patch is to clip the DARM_FREQ signal in a given range when the signal is centered on zero .

This has been implemented in the CEB_ALS server and automated in the ARMS_LOCK metatron node

  • the clipping is set to +/-150000Hz  at  the DOWN state of the ARMs_LOCK metatron node
  • and it is set to +/-200 at the  state 44 of the ARMs_LOCK metatron node
  • this plot and its zoom show the  locking sequence

This plot show the trend of 2 lock sequences, before the automation of this patch

  • in green the period with the clipping set  to +/-200
  • in red without clipping

There is the glitches on the NArm_ BEAT_dFreq signal during these periods, none on the WArm_BEAT:

  • For the period where the clipping is applied, this allows to reduce  the glitches on the mirror correction signals without losing  the lock
  • without the clipping, the glitches on the mirror correction signals are greater as expected

Let see if this patch will allow to improve the lock acquistion .

A possible improvement would be to clip the glitches at the  Arms frequency channels (NArm_BEAT_dFreq and WArm_BEAT_dFreq) to reduce the glitches on the CARM and DARM frequency signals

Images attached to this report
On-call intervention (General)
gouaty - 17:27 Thursday 28 March 2024 (63776) Print this report
Comment to B1p QD1 galvo not closing (63773)

After performing another -200 steps with B1p_M2_V we were able to maintain the galvo loops of B1p_QD1 engaged while the B5 drift control of SDB1 was engaged. It was than possible to reach CARM_NULL_1F (see attached figure).

The value of the vertical correction of B1p_QD1 galvo is still a bit large when we lock the CITF (around -7V). We will monitor this to understand if a further tuning is needed.

Images attached to this comment
AdV-DAQ (Calibration)
verkindt, rolland - 17:24 Thursday 28 March 2024 (63775) Print this report
Sign of h(t)

Using the PCal injected permanent lines, we have checked that h(t) has the correct sign, as defined in common by LIGO and Virgo.
  The definition of the strain is : h = ( L_North -  L_West ) / L0.

On NE, when PCal power increases, the signal PCAL_NE_Rx_PD1 increases.
Since the PCal injected line is at a frequency above the pendulum resonance (0.6 Hz) and since the PCal beam pushes the NE mirror from ITF beam side,
when PCal power increases, the arm length L_North decreases, thus the strain h decreases.
The phase of the TF between hoft_raw and PCAL_NE_Rx_PD1 must be around pi.  That is what we observe on the attached plot.

Same deduction on WE mirror allows to conclude that when PCal WE power increases, PCal_WE_Rx_PD1 increases, L_West decreases, thus h increases.
The phase of the TF between hoft_raw and PCAL_WE_Rx_PD1 must be around 0.  That's what we observe on the attached plot.

Images attached to this report
Virgo Runs (ER16)
menzione - 15:00 Thursday 28 March 2024 (63772) Print this report
Operator Report - Morning shift

Upon arrival I found ITF in Science Mode (LN3_SQZ). Unfortunately ITF unlocked due to the bad weather conditions.
After several attempts ITF has been left locked on CITF for the whole shift and, according with Sorrentino, we decided to profit of this situation to fix the strenght of ALS Green with Casanueva and Van de Walle from remote.
During a relock attempt the B1p_QD1_Galvo remained opened. I tried few times to closed it but it reopened sistematically. I asked Gouaty to check on it. Troubleshooting in progress...

Oncall events

DET
(28-03-2024 11:00 - 28-03-2024 13:00) From remote
Status: Ended
Description: B1p_QD1_Galvo remained opened

Images attached to this report
On-call intervention (General)
gouaty - 14:24 Thursday 28 March 2024 (63773) Print this report
B1p QD1 galvo not closing

This morning I was contacted by the operator because the galvo loops of B1p_QD1 were opening in LOCKED_ARMS_BEAT_DRMI_3F and it was not possible to close them back.

As shown on the attached figure, the corrections of the B1p_QD1 galvo are indeed much larger (in the negative direction) than what they were yesterday. So we suspect that the ITF is not in its standard alignment working point. This is also corroborated by the observation that the B1p beam on the B1p camera was quite off-centered (at the bottom of the camera).

Putting the SDB1 bench in fixed setpoints (when ITF was in DOWN),  was enough to recenter the beam on the B1p camera. Then the galvo loops are engaging correctly when reaching LOCKED_ARMS_BEAT_DRMI_1F. But the problem reappears as soons as we reach LOCKED_ARMS_BEAT_DRMI_3F because of the engagement of the SDB1 B5 beam drift control. We disabled by hand the SDB1 B5 beam drift control and then it was possible to close the galvo loops of B1p_QD1 even in LOCKED_ARMS_BEAT_DRMI_3F. It was not possible to lock the ITF at further steps due to the high wind activity.

Since we suspect a wrong alignment of the ITF mirrors, we only made minor changes to the SDB2 QPD centering (B1p M2 V: -200, B5 M1 H: -200, B5 M2 V: -200). This is probably not yet enough to lock the ITF, so the proposed procedure will be to disable the SDB1 B5 drift control when arriving in LOCKED_ARMS_BEAT_DRMI_3F, restore the B1p QD1 galvo loops, and then try to go on with the lock acquisition up to the point the mirrors alignment loops are correcting the alignment. When it should be possible to restore the SDB1 drift control and then the floating setpoints.

Images attached to this report
Comments to this report:
gouaty - 17:27 Thursday 28 March 2024 (63776) Print this report

After performing another -200 steps with B1p_M2_V we were able to maintain the galvo loops of B1p_QD1 engaged while the B5 drift control of SDB1 was engaged. It was than possible to reach CARM_NULL_1F (see attached figure).

The value of the vertical correction of B1p_QD1 galvo is still a bit large when we lock the CITF (around -7V). We will monitor this to understand if a further tuning is needed.

Images attached to this comment
On-call intervention (General)
Oncall-system - 8:44 Thursday 28 March 2024 (63770) Print this report
On-call intervention

The following report has been submitted to the On-call interface.

On-call events -> Interferometer Sensing & Control

Title: ITF not locking

Author(s): mantovani

Called at: 22:45, 27-03-2024, by: Gherardini
Remote intervention: Started: 22:45, 27-03-2024; Ended: 23:45, 27-03-2024
On-site intervention: Started: ; Ended:
Status: Resolved
Operator when issue resolved: Berni

Details:

The interferometer was not locking and even if the weather condition were bad (but not clearly bad to obviously explain the fact that the lock could not be achieved) with Fabio and Francesco we decide to check a lock acquisition to spot other possibile issues.
There were no particular issues apart from the moving suspensions that made the lock not robust. We have locked by misaligning at carm 0 1f the SR ty of +0.8 urad to lower the fringe (since the fringe was really instable and we would like to avoid the shutter closing).
Fabio and Francesco proposed the idea we should find a certain level of wather condition for which we can say that the ITF lock could not work and so the on-call intervention is useless. I think this is a very reasonable request.

* Note that any files attached to this report are available in the On-call interface.

Virgo Runs (ER16)
berni - 6:56 Thursday 28 March 2024 (63769) Print this report
Operator Report - Night shift

The shift started with Maddalena connected to investigate at the locking troubles; she verified that the ISC loops ere working properly and that the oscillations were due to the high sea activity and wind activity.

At 22:42 UTC we reached LN3 performing the "trick of the SR" in CARM_NULL_1F; then I started the calibrations:

  • 22:44 UTC CALIBRATED_DF_SENSITIVITY, completed at 23:22 UTC;
  • 23:24 UTC CALIBRATED_DF_PCAL, completed at 23:58 UTC;

At this point considering the difficulties in relocking, the wind was increasing, and also the fact that the two LIGO interferometers were already in Science I did not manually unlock the ITF to complete the calibration but instead I asked to go in LN3_SQZ to set then Science mode.

It was not possible to inject the Squeezing: the SQZ node was complaining about the 4Mhz signal (experts informed by mail) so I went back in LN3 and at 00:00 UTC I set Science mode; unfurtunately the ITF unlocked shortly after because of a sudden increase of the wind.

With the ITF in down I completed the calibartions foressen with the ITF in this state:

  • 0:18 UTC CALIBRATED_DELAY, completed.
  • 0:23 UTC CALIBRATED_SRNI, failed

At this point I asked to relock; in the meantime Marco fixed the problem of the squeezing.

After one failed attempt LN3_SQZ was reached at 1:56 UTC, Science mode at 1:57 UTC; still in Science at the end of the shift.

 

 

Images attached to this report
Virgo Runs (ER16)
gherardini - 22:59 Wednesday 27 March 2024 (63760) Print this report
Operator Report - Afternoon shift

This afternoon the commissioning work focused on the injection system (#63765, #63767), activity completed at 18:00UTC; ITF relocked up to LOW_NOISE_3_SQZ at the first attempt, it unlocked after after 12min most probably because of the work on NCAL; in the meantime Diego worked to cleanup the automation,
in the evening the lock become quite difficult with an increasing of wind and microseismic now we are still trying to relock...

Sub-system reports

ISC
- 20.19UTC: NI etalon set from 20.35 to 20.2 C (64800sec ramp time).

Images attached to this report
AdV-COM (automation)
bersanetti - 21:10 Wednesday 27 March 2024 (63768) Print this report
Automation cleanup

Today I continued the cleanup of the automation nodes; I removed several excessive logging issues, removed commented and outdated code, both old and backed up from the recent ISC cleanup. Also configuration files received a substantial cleanup.

The nodes of interest are: ALS_NARM, ALS_WARM, ARMS_LOCK, DRMI_LOCK, INJ_MAIN and ITF_LOCK (up to CARM_NULL_1F so far).

Several lock acquisitions have been performed already, and the clean up will continue on the remaining states of ITF_LOCK and the other ISC nodes left, and also TCS and SUS.

Unmentioned nodes will be left to the respective maintainers.

AdV-DAQ (Data Acquisition and Global Control)
gosselin, masserot - 20:26 Wednesday 27 March 2024 (63767) Print this report
Comment to ITF and FDS Acl servers update with v1r23p17 (63757)

All the INJ_rtpc (rtpc19) Acl servers have been started with the Acl v1r23p17 between 2024-03-27-17h24m10-UTC and 2024-03-27-17h25m06-UTC

Virgo Runs (ER16)
narnaud - 19:22 Wednesday 27 March 2024 (63766) Print this report
ER16: summary of first week

Summary of the first week of ER16.

 

Images attached to this report
Injection system (General activities)
gosselin, derossi - 18:57 Wednesday 27 March 2024 (63765) Print this report
INJ recovery and removed of the set up to inject laser phase noise

Today we blocked the beam on the LB to allow HJ. Bulten to work on the control of EIB (details in another entry)
We took advantage of having INJ in down to remove the set up that we added few weeks ago with Walid to be able to inject laser phase noise. We were indeed suspecting that it could be the responsible for the loss of phase margin of the IMC loop that has been seen these last days.
When HJ finished, we try to relock the injection but it was not relocking. After multiple tests we eventually noticed that the BPC was locked on the reference values which were quite far from the ones it had before putting INJ in down.
The alignment of the whole system had indeed drifted away during the long lock of the night+day.to follow the ITF.

After having relocked we blocked the beam again to allow Alain to do the restart of rtpc19.

Then everyting relocked correctly.

We measured the OLTF of the IMC with the attenuation of 20 dB (10+10) we had an UGF of 100 kHz and 14 degrees of phase margin
We added few dB of attenuation 22 (20+2) and we had an UGF of 93 kHz with 16.5 degrees of phase margin (see figure).
It is better than what we had few days ago but still not at the level of what we add when we measured it on the 04/03.

Images attached to this report
Detector Characterisation (Glitches)
direnzo, longo - 18:37 Wednesday 27 March 2024 (63764) Print this report
Comment to Scattered light glitches and larger noise at low frequency due to bad weather conditions (63761)

We have analysed all the raw channels with units of position, speed and acceleration, transforming them to reproduce the frequencies of the arches. The results confirm the V1:SBE_EIB_GEO_* family as the channels that reproduce best the frequency of the arches in LSC_SRCL. Speed and acceleration channels are not good predictors of these arches.

In the attachments, three text files with the most correlated position channels (truncated to Pearson correlation values larger than 0.1), speed and acceleration channels (truncated to 0.04).

Non-image files attached to this comment
Virgo Runs (ER16)
rolland, grimaud, verkindt - 17:05 Wednesday 27 March 2024 (63762) Print this report
Comment to Operator Report - Night shift (63756)

Analysing the calibration data from last night, we found that most of the injections failed. This was the consequence of two different modifications: 1/ the preparation of hardware injection, with a change in a channel name that was not fully propagated to the python scripts ; 2/ the improvement of the injection level for pcal to NI,WI measurements, adding a reference noise curve for "darkFringe_LN1" configuration, but forgetting a check of the config given as input in the script where we did not add this new name. As a consequence, some scripts were either not injecting the signal during the period of injection (check hrec, optical response, sensitivity measurements...), either failing directly when started (Pcal to IN configuration).

During the checks, one other modification has been done today around 14h45 UTC: change the name of the internal channel sent from CALnoise to the NE and WE PCal. CALnoise and the NE and WE Acl processes have been stopped and restarted to take this into account.

All the CALI_O4 python injection scripts have been quickly tested between 14h30 and 16h UTC today, and the lines or noise could be seen in the expected noise channels.

 

Search Help
×

Warning

×