I tried to read the data related to the overflow (K1:FEC-103_DAC_OVERFLOW_1_1 and K1:FEC-104_DAC_OVERFLOW_1_1). Although reading the new channel (K1:FEC-104_DAC_OVERFLOW_1_1) was OK, reading the old channel (K1:FEC-103_DAC_OVERFLOW_1_1) failed for the both time before and after model update.
I guess the the NDS server is keeping the latest channel list and if the channel name isn't included in that list, we can't read the past data via nds server. I don't remember exactly, but I think NDS server was designed so. Is that right?

Due to to the issue reported in klog, we needed to update the script to generate the Segment files and reproduced segment files. After several confirmation with the administractor of the DQSEGDB, we will start the rsync process.

Details

• We changed the channel names to detect the overflow
  • ETMX: K1:FEC-103* --> K1:FEC-104*
  • ETMY: K1:FEC-108* --> K1:FEC-109*
  • IPC glitch: K1:FEC-103_TIME_DIAG --> K1:FEC-104_TIME_DIAG
• The script runs at k1det1 every 15 minutes for the regular segment generation. Sometimes due to the unexpected trouble, it's possible to stop the regular segment generation such as this time. I updated the script to generate and fill the missing segment. This update contributed to the automation of segment file generation very much. We don't need to care much at the recovery from the power outage.
  • The script was pushed to the github.
• By using the updated script, I  reprocuded the segment files on 2025/02/8, 2/9, and 2/10.
• The regular segment generation was already started. The generated segment files are stoped in /users/DET/tools/Segments/Script/Partial . In the morning, these segment files will be copied to /users/DET/Segments and copied to the DQSEGDB. But, I stopped the copy process now. After several confirmation with the administractor of the DQSEGDB, we will start the copy process for the release of the Segment files.
• It was too late to realize that the SEGMENT generation was failing. For the countermeasure next time, I implemented the alert to send Slack's detchar-alert channel when segment generation failed.
• For the segment data at 2025/02/07, we gave up the reproduction because (1) channel names changed during one day, and it requires special handling. (2) The interferometer was down, and it was a maintenance day, so it's low necessity.

I found the bug in the script this morning. It failed to generate the segment for 8:45~9:00 JST due to the bug. I fixed it. I will check the result tomorrow morning.

[Ushiba, Sugimoto]

In some cases, the beat frequency between the PSL and IR (the source of the auxiliary green) was too far from the LO frequency, causing it to fall outside the PFD's operating region and the PLL to fail to lock. To address this issue, we added a "SCAN_TEMP_BIAS" state to the PLL Guardian, which tunes the beat frequency to the PFD's operating region before attempting to lock (Figure 1).
The upper panel of Fig. 2 shows the PLL error signal when the temperature control bias of the IR laser is swept. The highly fluctuating region on the left side is completely outside the operating region, while the area around the transition to the plateau on the right side corresponds to the optimal operating region. We used the 16Hz sampling channel with small fluctuations to determine each state (lower panel of Fig 2).

The sequence of the newly added SCAN_TEMP_BIAS is as follows（Fig3）:

1. The temperature bias (ALS-X/Y_LASER_TEMP_BIAS_OFFSET) is set to the lower limit of -2 over 15 seconds (To avoid mode hops due to overshoot, the change is made gradually).
2. The temperature bias increases in increments of 0.02, with a 0.1 s waiting time after each increment.
3. When the ALS-X/Y_BEAT_ERR_OUT16 value drops below -2, the increment of the temperature bias is reduced to 0.005 for finer adjustments.
4. When the ALS-X/Y_BEAT_ERR_OUT16 value exceeds 0, it is considered that the system has reached the plateau of the operating region, and the sequence proceeds to the next state.

After the above modifications, we confirmed that the lock could be achieved on both the X and Y sides.

Ushiba, Tanaka

## Abstract

When IFO went down, sometimes IMC ASC feedback (K1:IMC-ASC_DOF{1,2,3}_{P,Y}_OUTPUT) values grew the extream value (~1e6) and then IMC could not restore the lock automatically until the extream values are restored. This issue seems to be caused that the ASC loops remain to close although the IMC guardian already went the LSC_LOCKED state and even though the IMC lock lost because the trigers do not work well. To solve this issue, we modified the IMC guardian and the threshold value of the trigger.

## What we did

### The Issue and it's casue

According to Ushiba-san, when IFO went down, sometimes IMC ASC feedback (K1:IMC-ASC_DOF{1,2,3}_{P,Y}_OUTPUT) values grew the extream value (~1e6) and then IMC could not restore the lock automatically until the extream values are restored. 

We found that this issue occured three times within recent 3 month, Feb. 5th, 2025, Dec. 27, 2024, and

I investigated some related signals at the moment when the issue occured on Feb. 5th 2024 (fig.1). I found that the ALS_CARM feed back signals oscillated several minitues before the issue happened. Due to the oscillation, MCE actuator saturated and IMC guardian moved from the PROVIDING_STABLE_LIGHT state (K1:GRD-IMC_STATE_N = 1000) not to the DOWN state (K1:GRD-IMC_STATE_N = 0) but to the LSC_LOCKED (K1:GRD-IMC_STATE_N = 100). This is because the "actuator_check" decolator in the PROVIDING_STABLE_STATE, which monitors whether the K1:VIS_MC{I,O,E} _TM_COILOUTF_OUTPUT values are saturated or not, moves the IMC guardian to the LSC_LOCKED state. In this case, the ASC loops remain to be close even though the IMC lock lost, the K1:IMC-WFS_GAIN value keeps 1 and the null filters in ASC loops are not engaged. Actually, if IMC lock lost, the trigger (K1:IMC-IMC_TRIGGER_MON), which monitors each REFL and TRANS QPDs' SUM value and is triggered when each value get below each threshold, detected the lock loss and open the loops not so as to input the extream value in ASC loops. However, each trigger thresholds were set 0, that is, triggers did not work well. Due to this, IMC ASC loops remain to close even though IMC lock lost and the feedback signals increased to the extream value.

I checked the same channels on Dec. 27th, 2024 (fig.2), and found that the issue occured by the same cause. 

### How to solve it

The most problem is the ASC loops remain to close although the IMC guardian already went the LSC_LOCKED state and even though the IMC lock lost because the trigers do not work well.

So first, I modified the "actuator_check" decorator to move IMC guardian not to 'LSC_LOCKED'  but to 'DOWN' state.

Then, the nominal values of QPD's SUM seem to be from 1000 cnts to 3000 cnts. I set the value of the THRESH_ON to 500, which is the threshold to close the loop and set the value of the THRESH_OFF to 5, which is the threshold to open the loop.

Abstract:

One possible reason of the sensitivity breathing observed at 60–100 Hz is glitches affecting the MN or IM vertical actuators.

Details:

I investigated the cause of the sensitivity breathing at 60–100 Hz, because this frequency range is the most critical for the BNS range.

Fig.1 presents examples of DARM sensitivity spectra taken during two different periods.
The spectra were obtained with an 8-second time span, 75% overlap, and 10 averages.
When a large glitch occurred, several violin modes were excited, as shown in the bottom panel.
Similar glitches, which excite violin modes, were also reported in klog:32506.
Given that violin modes are most easily excited by IM pitch motion, this suggests that the glitch signal was injected into the IM or MN and excited the pitch motion.

Fig.2 provides another set of examples, where the red spectrum is slightly noisier than the blue one.
At the time of the red spectrum, the vertical, pitch, and roll modes of the IM (CuBe resonances), which are excited by the vertical actuators of the MN or IM, also appear to be excited.
Although this relationship is not yet definitive, it is worth further investigation.

With today's upgrade of the DGS system, we expect fewer glitches in the Type-A suspension.
We will soon measure the frequency and amplitude of the breathing to confirm this improvement.

I updated the new forecast algorithm:

• Input 516 coast wave height [Fig. 2]
• Choose the coasts that have enough correlation (> 0.5) with the seismometer data [Fig.3]
• Take 12 clusters from each correlation [Fig. 4]
• Take the first principal components for each cluster [Fig. 5]
• Perform fitting [Fig.6, 7]

I performed a WSK calibration at UToyama.

The results look no problem.

alpha_{WSK/GSK} [V/V] 
front : GSK, back : WSK  -> 0.90975 ± 0.00013
front : WSK, back : GSK  -> 0.91204 ± 0.00016

Detailed report: link

There is some confusion within the klog about the frequencies of violin modes.  In this klog I use temperature difference of ETMX in 2023 to identify the ETMX modes.  The purpose is to set up notches for the ETMX IM drive to try to avoid excitation of the violin modes.  Also to set up active damping of the ETMX violin modes.  The ETMX modes that are identified are 173.15, 178.82, 180.60, 182.88, 184.74Hz.  Modes that may be ETMX modes are at frequencies 168.29 and ,174.25, 181.34 and 181.84Hz.  If there is data of long lock stretches where the ETMX temperature is changing looking for the associated change in violin mode frequency  like 32060 may be a more accurate way to identify violin modes. Same for other test masses if temperature changes occur.

The first attached figure shows a sample of spectral data that was used to identify ETMX modes.  The time periods used were:  ETMX 86K, others 250K - 22/5/2023 14:00 UTC. All ~80K - 22/1/2025 1:45:30UTC. All 250K - 11/12/2024 10:00:00 UTC.  All measurements have measurement BW 0.01Hz, 50 averages, 50% overlap.  The full list of mode frequencies is given in the second attached xls file.  Many ETMX modes do not have the same frequency Δ~0.1Hz now as 1.5 years ago. The average change in mode frequency between 250K and 80K is about 0.15Hz or ~1mHz/K.  There should be 8 violin modes, 2 for each fiber. The splitting into two fiber modes would result from fiber asymetry.  There are no clear doublets like observed at LIGO. If the mode frequencues identified here are indeed some of the 8 fiber modes I think the fiber must deviate from circular by ~1% to explain mode frequencies.

Previous klogs report ETMX violin mode frequencies (klog25876 and klog26113) and klog27845, klog32133(from  klog31977), klog32548.  The fact that there are 3 numbers in common (green) between this measure and previous measures makes me confident these modes have been positively identified.   Generally the previous techniques appears to be to drive broadband noise in L or P in the IM and look for increased DARM noise or the ring down (in DARM I think).  There are multiply identified peaks using the previous technique (marked reds) as reported previously.  I wonder if DARM is leaking back to the ETMs, resulting in excitation of ETM modes and misidentified modes?

ETMX

I now understand that the violin modes may be being excited by DAC glitches due to VIS model overruns. This may have been fixed with the model split. If the violin modes continue to be excited I have set up notches in FM5 of K1:VIS-ETMX_IM_DRIVEALIGN_L2P to determine if notching the L2P drive signals to the IM can reduce mode excitation.  The filter history is always on, has a few second step response and is ramped on over 10 sec. 
I have setup violin mode damping filters in K1:VIS-ETMX_NBDAMP_P4 and K1:VIS-ETMX_NBDAMP_P5. 184Hz is set up (damping gain -40phase +60).  The others will need some careful tuning before use.

Comparing previous violin mode identification.
ITMX

ITMY

ETMY

I discussed with Yokozawa-san and found that the IFO REFL HWP angle didn't seem good for PRMI lock.
It was 178 degrees but the current good HWP angle for PRMI is 164 degrees (klog32467).
So, probably it is the reason why PRMI cpild not be locked on Sunday.

I took the TCam photos for four mirrors at 8:45 ~ 8:53 this morning. At last Friday, Yokozawa-san kindly took the several Tcam photos (klog). But, the TCam photo was not taken due to the Tcam server issue.

I checked the images. We don't need to update the reference positions

I heard that the local dump part would be moved to the NB side, but it appears that the ISC part was actually moved to the DCUID which was used for NB.

Now many scripts and pipelines are unavailable due to the update of Type-A models.
Just ones I am currently aware are as following.
- Online state vector by k1detdq
- Segment file related to overflows
- Lockloss guardian
- DARM calibration scripts

In addition to that, I found some incomplete build as follows.
- Confusion of sender/receiver on ITMX as shown in Fig.1
- Wrong IPC rate for NBDAMP on ITMY as shown in Fig.2
- Remaining old info. about NBDAMP on ETMY as shown in Fig.3
- Mixing of old and new sender info about NBDAMP on ETMY as shown in Fig.4
- Wrong IPC rate for {PF,MN,TM}OPLEVs for all 4 type-As as shown in Fig.5-7
- Remaining old sender info. on CALCS as shown in Fig.8

I'm not sure the control signals can be sent/received among real-time models properly.
The only way to get back reliable IPC communications is to rebuild and restart them after cleaning up K1.ipc.
I think removing these chaos and unreliable situation is the most urgent task in next (a couple of?) weeks.

Since there seems no log related to the change of K1:VIS-BS_IM_OLDAMP_Y_GAIN from 1 to 0.7 and no significant change in spectrum, I reverted the value to 1.

I measured the spectrum of RF17I/Q signals of OMC REFL QPDs for phasing again because I forgot to engage QPD centering loop in previous measurement.
Attached files show the spectra, coherence, and TF of each segment.

For all sengements, Q-phase signals are less than 0.1 of I-phase signals, which means signal loss due to phasing is less than 1%.
So, current RF17 phasing of OMC REFL QPDs seems fine.

Request from Ushiba-san

Separate the Payload model into 16KHz and 2KHz models.

[K1EX1,K1EY1,K1IX1,K1IY1]
model: k1vis{etmx,etmy,itmx,itmy}{p,lsc<New>}
detail:

EPICS Channel Changes
 CHANGE
 K1:VIS-{ETMX,ETMY,ITEMX,ITMY}_HIERSWITCH => K1:VIS-{ETMX,ETMY,ITEMX,ITMY}_HIERSWITCH_L
 Add
 K1:VIS-{ETMX,ETMY,ITEMX,ITMY}_HIERSWITCH_{P,Y}

Model file changes
Separated LSC processing (k1visetmxlsc) and Payload processing (k1visetmxp) at the input of the ADD module for MN, IM, and TM in the Payload model (k1visetmxp).
　Change so that values added only by the Payload model are sent and added on the LSC processing (k1visetmxlsc) side.

The separated Payload model is changed to 2KHZ, and the separated LSC-related processing is changed to 16KHZ.

Combine the NBDAMP model (k1visetmxnb) with the Payload model and delete it.
 Reuse dcuid and specific_cpu used in NBDAMP in the LSC-related model (k1visetmxp). 
 The output of NBDAMP combined with the Payload model was delayed by one sample by adding a unit delay due to the model configuration.
 
HIERSWITCH in the modified EPICS channel was separated into HIERSWITCH_{l,P,Y} from only L before the modification.
 
LOCAL_INF was added before ADD in the LSC model.