• Each value is estimated based on JGW-L2314903.
• Estimated values by Pcal and Free-swing are consistent with each other at approximately 3%.
• Previous full measurement which is the reference of comparison is klog#34033.
• There is no significant change in all parameters.
• Numbers in parentheses indicate a number of engaged de-whitening filters.
  • Low-frequency (<1Hz) zero/pole in disengaged de-whitening filters (see also klog#33874) are compensated based on circuit measurement only for ETMX in klog#34229 and klog#34244.
  • So this effect must be considered for other suspensions.

We accepted SDFs related to the cal measurement (klog#34412) in observation.snap, down.snap, and safe.snap (k1calcs).
K1:CAL-MEAS_{CURRENT, LATEST}

with Dan, YamaT, SawadaT

We performed full measurements for the IFO calibration.
The analysis results will be posted at a later date.

Notes:

The DARM-related measurements were conducted after adjusting the feedforward gains (see klog#34410).
Following the same method as klog#34040 and klog#34033, we performed measurements to observe the changes in DC caused by differences in the number of whitening filter stages for ITMX-TM and BS-TM.

Measurement files (`/users/CAL/current/measurements/2025/0603/0920_*`):
0920_BS_TM_PRCL.xml   : Whitening = 1 stage
0920_BS_TM_PRCL-1.xml  : Whitening = 0 stage
0920_ITMX_TM_DARM_PRFPMI_WFOFF.xml : Whitening = 0 stage
0920_ITMX_TM_DARM_PRFPMI_WFON.xml  : Whitening = 3 stages

Here is a update of the 8 blasting between 2025/06/18 03:22:49 UTC and 2025/06/26 13:59:52 UTC. The plots are available at DAC wiki.

• 6 times: lockloss occurred from OBSERVATION state
  • The the amplitude of the seismic motion was large enough to make the lockloss.
  • Even though the bomb size was 6.2 kg (which is relatively small), the lockloss occurred. I guess this is because the blasting point is approaching to the KGRA tunnel.
• 2 times: interferometer was in down state or during lock acquisition.

Operators name: Takaaki Yokozawa, Hiroshi Takaba, Dan Chen
Shift time: 9-17 (JST)
Check Items:

• VAC: No issues were found.
• CRY cooler: Temperature of EX 50_REFBRT went down by 6K between 6/29 16:00 and 6/30 10:00. No other movement.
• Compressor: No issues were found.

IFO was used by CAL group during the day.
After their works, the state was set to be CALIB NOT READY. 

[Dan, Hido, Sawada, Yamamoto, Ushiba]

Abstract:

Gain tuning of MICH2DARM, MICH2PRCL, and PRCL2DARM FF were performed.
All update seems fine.

Detail:

First, calibration team measured the actuator efficiency ratio of MICH2PRCL/PRM2PRCL.
The new value was 0.03675 and FM10 of LSC_MICHFF2 filter bank was updated.
Figure 1 and 2 show the filters before and after the update, respectively.

Then, I measured MICH2DARM coupling with several FF gain to tune the MICH2DARM FF gain (fig3).
MICH FF performance seems better when MICH FF gain is 0.98, so I implemented the gain of 0.98 at FM10 of LSC_MICHFF1 filter bank.
Figure4 and 5 show the filters before and after the update, respectively

After that, I measured PRCL2DARM coupling with several FF gain (fig6).
Though the low frequency performance is worse than before, the best gain seems 0.8, so I update FM1 of LSC_PRCLFF1 filter bank.
Figure 7 and 8 show the filters before and after the update, respectively.
For further tuning of PRCL2DARM FF, we may need to modify the filter shape and it takes a time, so I didn't performit today.
Since current PRCL2DARM noise budget cased on the today's measurement is low enough (fig9), the current situation should be fine.

Since all updates are done by overwriting current FF filters, no SDF change happens.

5 days have passed since the last recovery. No problem has happened until now. So, the heat up inside the 19-inch rack could be the reason.

The cryocooler 1st head temperature for the BRT side finally started decreasing as shown in Fig.1. So the temperature of BRT1,2,3,4 also started decreasing.

Operators name: Ikeda, Hirose
Shift time: 9-17 (JST)

Summary:

Check Items:
* VAC: no problem
* CRY: no problem
 => As reported in klog34404, Ikeda-san wrote a script to compare the temperature at AM10:00 with that at PM4:00 of the previous day as related to klog34401.
* TEMP: no problem
 => Data of K1:PEM-TEMPERATURE_FIELD_EXA_IR was no value.

IFO state (JST):

09:00 The shift was started. This status was OBSERVING.

10:00 LockLoss due to the earthquake
Result from check_IFO_status.py:
 Large earthquake arrived within 3 hours.
 Please check IFO status again after 30 minutes.

10:30 Result from check_IFO_status.py:
 Large earthquake arrived within 1 hours.
 Please check IFO status again after 30 minutes.

11:00 Result from check_IFO_status.py:
 Large earthquake arrived within 1 hours.
 Please check IFO status again after 30 minutes.

11:17 OBSERVING

11:42 LockLoss due to the earthquake
Result from check_IFO_status.py:
 Large earthquake arrived within 1 hours.
 Please check IFO status again after 30 minutes.

12:09 OBSERVING

16:17 LockLoss due to the earthquake
Result from check_IFO_status.py:
 Large earthquake arrived within 1 hours.
 Please check IFO status again after 30 minutes.

16:47 Result from check_IFO_status.py:
 Large earthquake arrived within 1 hours.
 Please check IFO status again after 30 minutes.

17:00 This shift was finished. The status was "LOCKING".

Since comparing the "cooler unit temperature changes" between 16:00 the previous day and 10:00 the current day was time-consuming, we added a script to perform the check automatically.

/users/OBS/O4c/script/check_regular_CRY.py

Sitemap　- Commissioning Dock → OPERATOR → Beside CRY → Regular check at 10:00 and 16:00 (Fig-1)

When the terminal opens, an image like Fig-2 is displayed.
The numbers in parentheses indicate the temperature change, and if the change exceeds 10 K, it is displayed in red text (this is expected behavior, though not yet confirmed).

You can open it at any time, but only the most recent data from 10:00 or 16:00 will be displayed.
Please make sure to open it after 10:00 or 16:00 when performing the check.

A reference image has been attached in the "1029 O4C Check Items during Shift" document.
 

Operators name: Hirose, Ikeda
Shift time: 9-17 (JST)

Summary:

Check Items:
* VAC: no problem
* CRY: no problem
 => Data from the previous day was not available, so NDSCOPE was used to research the data.
* TEMP: no problem

IFO state (JST):
09:00 LockLoss due to the earthquake
09:14 OBSERVING
11:19 LockLoss due to the earthquake
12:04 OBSERVING
15:12 LockLoss
 Result from  check_IFO_status.py: 
  IFO is stable enough (duty cycle for the past 3 hours is 98%).
  Please check IFO status again after 30 minutes.
  19.923444271087646
15:42 Check after 30 min.
 Result from  check_IFO_status.py: 
  IFO is stable enough (duty cycle for the past 3 hours is 83%).
  Please check IFO status again after 30 minutes.
  2.8863821029663086
15:44 OBSERVING
17:00 OBSERVING

Other Work
K-Log#34401 
 => Added ndscope template for the purpose of checking values since the previous day's values were not captured.

Ikeda, Hirose

During the observation shift, there is a “Cryocooler Temperature Change” item in the dairycheck items.
The task is to record the temperature of the cryocooler at AM10:00 and PM4:00 during the Saturday and Sunday shifts, and to compare it at AM10:00 with the previous day's PM4:00, and at PM4:00 with the same day's AM10:00.
However, in the case of the AM10:00 check on Saturday, we need to compare the temperature of the cryocooler unit with the temperature at PM4:00 on Friday.
We created ndscope templates to see the temperature changes of cryocoolers and set it to medmscreen.(FIG1)

OPERATOR_O4c.adl->the side part of "CRY"->"ARM/BRT/BS HEAD(FIG2)", "ARM/BRT/BS BAR(FIG3)", "REF1,2,3,4 50K HEAD(FIG4)", "REF1,2,3,4 50K BAR(FIG5)", "REF1,2,3,4 4K HEAD(FIG6)", "REF1,2,3,4 4K BAR(FIG7)"

Time stamp of the visitors(27+2 pepole) who entered center preroom and xarm.
(Monitored with Ikeda-san.)

15:00? center preroom
15:22 center parking area
15:24 Xarm in
15:30 Xarm out
15:30 out of mine
15:40 Mine shutter closed
 

We turned ON the OBS INTENT flag around 18:49 JST, June 27, 2025 after the approval of Ushiba-san.

CAL group

We did the calibration measurements.

Estimated parameters taken while visitors were present are as follows.
 H_etmxtm = 3.850142293e-14 @10Hz ( 0.52% from previous measurements)
 H_etmxim = 1.621508136e-14 @10Hz  ( 3.2% from previous measurements)
 Optical_gain =  2.126800024e12         ( 0.63% from previous measurements)
 Cavity_pole = 18.183601559 Hz            ( -0.16% from previous measurements)

Previous values are listed in klog#34310.

Fig. 2 and Fig.4 shows the ratio of the sensing functions estimated.

Post-tour measurement results (inside the mine) are as follows.
 H_etmxtm = -3.830386471e-14 @10Hz ( -0.51% from above measurements)
 H_etmxim = -1.565605347e-14 @10Hz ( -3.44% from above measurements)
 Optical_gain = 2.127919074e12           ( 0.05% from above measurements)
 Cavity_pole = 18.267333924 Hz            ( 0.46% from above measurements)

The parameters were updated based on the results from `0627/1606`.
From the current results, it is assumed that the influence of visitors is minimal (at least, no variations larger than the weekly fluctuations were observed).

All detected changes are coming from the planned commissioning activities.
- Changes in foton Fig.1 are related to klog#34393 (k1calcs) and klog#34386 (k1omc).
- Changes in guardian (Fig.2) are related to klog#34386 (k1omc).
- Changes in SDF tables shown in Fig.3 are related to klog#34393 (k1calcs), klog#34386 (k1omc), and klog#34391 (k1calex, k1caley).
- No changes in the model (Fig.4).

As a result of our discussion in the CAL group, we decided not to update the line tracking parameters this time.
This line tracking is for online use only and does not affect the LL.

Finally, I raised CFC_LACTCH and IFO guardian moved from CALIB_NOT_READY to READY.

We accepted SDFs related to the weekly cal measurement.

CALCS

K1:CAL-MEAS_{CURRENT, LATEST}

We accepted the SDFs reported on klog34391.

CALEX, CALEY

K1:CAL-PCAL_{EX,EY}_TCAM_{MAIN,PATH1,PATH2}_{X,Y}

A CAL Tcam session was performed to obtain beam position information necessary for Pcal. The parameters have already been updated, and SDF is expected to be accepted.

Operator: Shingo Hido, Dan Chen

Update Time: 2025/06/27 15:07:49

Update Time: 2025/06/27 15:08:24

Update Time: 2025/06/27 15:09:03

Update Time: 2025/06/27 15:09:35

Abstract

In klog#34162, ~5% difference around 100Hz between online and low-latency h(t) was pointed out.
So I checked validity of this fact and it seems to come from the incompleteness of online calibration.
This fact suggests that actual sensitivity is slightly better than one shown in control room by using online h(t).
 

Details

Major and known factors of incompleteness of online calibration are 1) digital AAs for 65kHz->32kHz and 32kHz->16kHz 2) compensation of whitening filter on DCPD preamp board and 3) timing mismatch between error signal and feedback signal. Response of these effects are shown in Fig.1 and Fig.2 (zoom up around 0dB).

Because 1) is a super-Nyquist effect (zero/pole above Nyquist frequency), they cannot be compensated by using foton filters which are IIR filters based on bilinear transform. So this effect can be compensated only on low-latency and/or offline h(t). Only phase delay is compensated also on online h(t) as an approximant as time delay.

2) comes from the mismatch between the best estimation of circuit response of DCPD preamp whitening and digital dewhitening on FM10 of K1:OMC-TRANS_DC_{A,B}. By updating digital dewhitening filters, accuracy of online h(t) can be improved. But this update makes a change of open loop gain around UGF. So the DARM servo filter is also update at the same time. Because phase around 7-70Hz is also changed, we should check that there is no problem also on GR and RF lock.

3) comes from the accuracy of timing (phase) adjustment between error signal and feedback signals. In low-latency calibration, arbitrary time delay is compensated. On the other hand on online calibration, time delay compensation is done as a integer multiple of the sampling rate. The best estimation of timing mismatch between two signals is ~7.8 samples in 16kHz (=476us). Current timing compensation of online h(t) is 7 samples. So there is 0.8 samples mismatch. Compensation can be update as 8 sample and mismatch can be reduced 0.2 samples even online calibration. For doing it, model or foton filter updates are required.

As shown in Fig.2, total bias coming from these effect is ~0.45dB (=~5%) which is consistent with a mismatch between low-latency and online. This fact suggest low-latency h(t) is more close to the actual sensitivity and actual sensitivity is slightly better than one shown in control room.

Fig.3 and Fig.4 (just zoom up around 0dB) show the possible accuracy of online h(t) when all compensations mentioned above will be adopted. Accuracy of online h(t) can be improved from blue (current) to orange (best effort). By the way, bad accuracy above 1kHz comes from digital AA effect. In KAGRA, OMC model is running as 32kHz model. For this reason, two digital AAs which cannot be compensated on online h(t) contaminates accuracy. If we can change OMC model as 16kHz, additional improvement (orange -> black) will be available. Of course, they can be compensated in low-latency h(t). So it's not a problem on search groups.