Reports of 58188
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.

 

Virgo Runs (ER16)
amagazzu - 16:26 Wednesday 27 March 2024 (63758) Print this report
Operator Report - Morning shift

Upon reaching the site, I found the ITF in LOW_NOISE_3_SQZ and in Science Mode. The lock lasted until 13:14 UTC, where I manually unlocked to allow the planned INJ/SBE activity, carried out by Gosselin, De Rossi and Bulten. The beam was blocked on the Laser Bench at 13:18 UTC.
INJ activity still in progress.

Sub-system reports

ISYS
During the shift, the value of RFC_TRA_DC started to decrease. Experts informed of the issue.

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

As already happened a few weeks ago, #63420, associated with the bad weather conditions of this morning and the large microseismic noise, there was an increased rate of scattered light glitches, best witnessed by LSC_SRCL, and reproduced by the V1:SBE_EIB_GEO_H2_200Hz channel.

Figure 1: spectrogram of a scattered light glitch in LSC_DARM.

Figure 2: Top: spectrogram of several scattered light glitches in LSC_SRCL. Middle: extracted arch frequency and predicted frequency of the scatterer surface according to the equation f_{\text{fringe}} (t)=2n\frac{|v_{sc}(t)|}{\lambda}, with \lambda the laser frequency, v_{sc} the speed of the scatterer, equals to the time derivative of SBE_EIB_GEO_H2_200Hz channel, and n the number of times stray light gets reflected back and forth between the test mass and the scatterer before it joins the main beam arXiv:2007.14876 . Notice that the y-axis is the same for both the reconstructed frequency of the arches and the predicted frequency. In the box, the value of the Pearson correlation coefficient between the two quantities, 80%.  Bottom: time series of SBE_EIB_GEO_H2_200Hz.

We are currently running an extended analysis to find other correlated sensors, using the list of position, speed, and acceleration channels documented in this git issue.

Images attached to this report
Comments to this report:
direnzo, longo - 18:37 Wednesday 27 March 2024 (63764) Print this report

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
AdV-DAQ (Data collection)
masserot, mours - 12:16 Wednesday 27 March 2024 (63759) Print this report
RAW, RAW_FULL and RDS streams data flow

Today, with the ITF in at least  LOW_NOISE_3

  • the RAW stream  data flow is around 42.6 MB/s
  • the RAW_FULL data flow is around 93,2 MB/s
  • see this plot and its zoom for the details. The full details are available in the /virgoData/DAQ/DataFlow directory

Below the evolution of the RAW, RAW_FULL and RDS streams since the 2024-02-23 upto  the 2024-03-27

  • RAW : from 54.8 MB/s  to 42.6 MB/s   for the ITF in LOW_NOISE_3
  • RAW_FULL: from 128 MB/s to 93.4 MB/s for the ITF in LOW_NOISE_3
  • RDS:  from 2.8 MB/s to 2 MB/s for the ITF in LOW_NOISE_3
Images attached to this report
AdV-DAQ (Data Acquisition and Global Control)
bersanetti, boldrini, casanueva, masserot, spinicelli, vardaro - 11:39 Wednesday 27 March 2024 (63757) Print this report
ITF and FDS Acl servers update with v1r23p17

All the Acl servers  (AclISC, AclLC, AclSBE, AclFCoplev, Acl) are running with the v1r23p17 version  since the 2024-03-26-15h20mn-UTC .

The main new features are

  • for the Cm commands use to set the ACL object parameters, the numeric parameters can be sent  as integer or double .
  • the ACL_SINECOMB_CH keyword to define a comb of lines
  • the possibly to to delay the readout of the AclAdcCh objets.

The first trial was done the 2024-03-25  starting at 14H-LT

  • all the Acl servers were restarting the Acl v1r22p17 : operation complete around 17h-LT
  • upgrade of the INJ Acl server configurations
  • Some tuning were done on the NEB and WEB Als servers to avoid missing ADCs sample by adjusting the timing sequence:  the LOOP_DELAY was increased to 6us for NEB and 7us for WEB
  • after the recovery of Injection system  and the ITF alignment,  we faced some troubles with the lock sequence 
    • some Cm messages sent  by the Automation servers with the "load" or "apply'  commands  related to ACL_MATRIX_CH or ACL_SUM_CH objects were all rejected by the Acl servers
    • To relock the ITF, the LSC_Acl, ASC_Acl, NEB_ALS_BPC, WEB_ALS_BPC and the SDB1_LC servers were restarted with the Acl v1r20p17 version .  The ITF was relocked at LN3 . Unfortunatly , the SDB1_OMC server was not updated  and the OMC lock sequence was not correctly achieved
  • To fix the issue the Acl v1r23p17 was created and deployed on all the Acl servers

 

Comments to this report:
gosselin, masserot - 20:26 Wednesday 27 March 2024 (63767) Print this report

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

Detector Characterisation (Broadband noise)
direnzo - 8:18 Wednesday 27 March 2024 (63752) Print this report
Comment to noise in tonight lock (63741)

[For some reason, this message has remained in the Drafts, even if I received the notification that it was added to the Logbook...]

Ignore my previous entry. The highlighted channel is one of those recently added to DET, as reported in this logbook entry: #63738. I'm adding them to the excluded channels from BruCo analysis:

/data/dev/detchar/online/bruco/share/virgo_excluded_channels_Hrec_hoft.txt

EDIT: BruCo daily results for Hrec (link) have correctly excluded this channel from the analysis. Unfortunately, I forgot to edit the corresponding list for DARM, and the coherence results for the last day (link) have been dominated by the new DET channel: ignore this channel from the BruCo results.

Now, I have edited the excluded channel list for DARM too. I've opened this git issue to keep track of the various excluded channel lists and keep them up to date.

Virgo Runs (ER16)
berni - 6:51 Wednesday 27 March 2024 (63756) Print this report
Operator Report - Night shift

ITF found in LN3_SQZ and commissioning activity SQB1 injections and sensitivity  just finished thus I, as requested by Fiodor, I performed the weekly calibration.

  • 22:06 UTC CALIBRATED_DF_SENSITIVITY: error at start,the reload the node canceled the error; completed 22:43 UTC.

  • 22:45 UTC CALIBRATED_DF_PCAL: ITF unlocked as soon as I launched the calibration.

  • 22:46 UTC CALIBRATED_SRNI: completed 23:07 UTC.

  • 23:08 UTC relock in LN1 with NI,WI actuators not open requested from CALI_MAIN;
  • 23:56  CALIBRATED_DF_INtoEND_LN: not clear if completed or failed. The node went in completed at 23:58 UTC.

  • 0:04 ITF in LN3 but Hrec_Range_BNS was very low and it unlocked after few seconds.

  • 0:05 CALIBRATED_DELAY: completed.

  • 00:57 ITF in LN3.

  • 00:58 UTC CALIBRATED_DF_PCAL: completed at 1:32 UTC.

  • 1:33 UTC CALIBRATED_DF_SENSITIVITY: completed at 2:10 UTC

At 2:10 UTC stop of Calibration and start Science mode.

At 2:45 UTC an earthquake unlocked the ITF, the suspensions were excited for about an hour.

Then the ITF kept unlocking CARM/DARM to IR for about 1.5h because green laser very glitchy  (as already happened in the last days) .

Finally at 5:24 UTC the ITF was back in Science mode.

 

Images attached to this report
Comments to this report:
rolland, grimaud, verkindt - 17:05 Wednesday 27 March 2024 (63762) Print this report

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.

 

AdV-SGD (FDS commissioning)
zendri, bonnand, conti, de laurentis, gherardini, vardaro - 0:51 Wednesday 27 March 2024 (63755) Print this report
SQB1 injections and sensitivity
The purpose of the first part of the shift is to measure the effect on the ITF sensitivity of a low frequency (0.1 Hz) line injected on the SQB1 “z” position. The shift begins at 17:15 UTC after the conclusion of the recovery.

17:15-17:49 ITF on LN3_SQZ, SQZ alignment optimized maximizing the 4MHz beat note magnitude on B1 by moving SQB1_LC_X

17:49:09 First configuration: LN3_SQZ and SQZ AA loop open. We start shaking SQB1 at 0.1Hz:
• 17:51:29 line weight=5
• 17:52:29 line weight=10
• 17:54:00 line weight=20
• 17:56:09 line weight=50
• 17:58:08 line weight=100. This line weight correspond to an oscillation of SQB1 on about 60 micrometers pesk to peak (figure1) and its effect is visible on the ITF sensitivity curve (figure2).

18:06:49 Second configuration LN3_SQZ and SQZ AA closed
• 18:07:18 line weight=20
• 18:15:20 line weight=50 (figure3)
• 18:17:41 line weight=100 (figure4)
18:29 Third configuration LN3
• 18:38:50 line weight=20
• 18:42:22 line weight=50
• 18:45:26 line weight=100 (figure5)
At 18:50:54 injection stopped (line weight=0)

The purpose of the second part of the shift is to evaluate the sensitivity of the interferometer with SQZ injected as a function of the angle of the SR mirror
19:00 ITF in LN3
19:24:15 start of the CC phase scan (duration about 1250 sec.). the phase scan results are shown in figure6 ,7. Compared to usual the level of generated squeezing is low and consequently the effects on sensitivity are less evident.
20:23 the ITF automation set in the LN3_SQZ state
20:46:56 the squeezing angle is set at 2.9 rad (change made “by hand” on the VPM and not in the config file)
20:50 ITF unlock.
we decide to interrupt the shift and resume it after restoring the usual squeezing level
Images attached to this report
Virgo Runs (ER16)
gherardini - 22:58 Tuesday 26 March 2024 (63750) Print this report
Operator Report - Afternoon shift
In the first part of this afternoon shift Alain worked to complete the ACL servers update then we started to relock; the relock took a bit of time passing through a period of crisis with the green that caused fails in the CARM/DARM to IR steps and also in the lock of the DRMI the sytuation improved by itself, the ITF was finally locked up to LOW_NOISE_3_SQZ and at 17:00UTC work on squeezing started; ITF unlocked at 20:50UTC (see plot), ITF relocked again with some trouble with the green; commissioning activity completed at the end of the shift.
Images attached to this report
Detector Characterisation (Broadband noise)
direnzo - 19:02 Tuesday 26 March 2024 (63747) Print this report
Comment to noise in tonight lock (63741)

The large broadband noise up to some hundred Hz is highly coherent between Hrec and V1:DET_B1_DC, as a result of a dedicated BruCo run: link (I'm currently rerunning the script to fix the cropped y-scale). In the table, you can find also a bunch of channels coherent with the large peak at 43 Hz.

Figure 1: coherence and noise projection of V1:DET_B1_DC to Hrec.

Images attached to this comment
Detector Characterisation (Broadband noise)
gouaty, masserot - 19:00 Tuesday 26 March 2024 (63749) Print this report
Comment to noise in tonight lock (63741)

The issue was due to the release v1r22p17 of Acl . A Cm command  related to the ACL_SUM_CH  object use to select the error signal was not applied .

Below the messages from the SDB1_OMC logfile

2024-03-25-23h01m05-UTC>WARNING-AcSumChCmSet> OMC1_in1 - missing arguments: cmType "AcSumChSet" -t -d -d -t ... - rtn -1
2024-03-25-23h01m05-UTC>WARNING-AcSumChCmSet> OMC1_in0d5 - missing arguments: cmType "AcSumChSet" -t -d -d -t ... - rtn -1

As a result , the error was not the expected one and as consequence a large correction signal.

Detector Characterisation (Spectral lines)
mwas - 18:45 Tuesday 26 March 2024 (63748) Print this report
Comment to Moving line at ~9kHz (63680)

Figure 1, the change in frequency of the line between March 6 and 7 corresponds also to a change of the SSFS UGF. So the SSFS loop is involved in that oscillation.

Images attached to this comment
Detector Characterisation (Broadband noise)
mwas - 18:15 Tuesday 26 March 2024 (63746) Print this report
Comment to noise in tonight lock (63741)

I have been able to run the noise budget by hand, after changing some of the Pcal channels used that have disappeared in the last two days from the raw data.

Figure 1. Shows that the noise budget thinks the OMC projection is high. Normally it is 2 orders of magnitude below the sensitivity curve.

Figure 2 shows that the OMC error signal spectrum is 3 orders of magnitude higher than usual. The sensing noise is three orders of magnitude higher.

Figure 3. In the lock of ~17:00 UTC the problem is no longer present. Maybe the issue was removed by the restart of the SDB1_OMC process that was done today by Alain around 15:00 UTC.

Images attached to this comment
Search Help
×

Warning

×