Reports of 32036
OBS (General)
takafumi.ushiba - 19:30 Friday 18 July 2025 (34602) Print this report
Comment to Set observing bit (34099)

We turned on the OBS INTENT around 19:29 JST after the weekly calibration work.

OBS (SDF)
takahiro.yamamoto - 19:14 Friday 18 July 2025 (34599) Print this report
Comment to Changes of observation.snap during O4c (34169)

K1CALCS

Channels in JGW-L2314962

It's related to klog#34597
They were updated based on the latest value of optical gain of DARM and ETMX actuator efficiencies in klog#34601.

Changes were accepted on observation.snap (Fig.1), down.snap (Fig.2), and safe.snap (Fig.3).
Finally, numerical rounding errors were reverted after re-loading observation.snap as shown in Fig.4.

Images attached to this comment
OBS (SDF)
dan.chen - 18:59 Friday 18 July 2025 (34598) Print this report
Comment to Changes of observation.snap during O4c (34169)

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

Images attached to this comment
CAL (General)
dan.chen - 18:48 Friday 18 July 2025 (34597) Print this report
Weekly calibration on 7/18

CAL group
We did the calibration measurements and updated the parameters.

This time we needed to change the fiting limit in parameters_fit.py
Original: m.limits["H_c"] = (self.H_c * 0.95 * 1e-12, self.H_c * 1.05 * 1e-12)
New: m.limits["H_c"] = (self.H_c * 0.90 * 1e-12, self.H_c * 1.10 * 1e-12)

Estimated parameters in the Pre-maintenance measurements are as follows.
 H_etmxtm = 3.831118314e-14 @10Hz ( -0.67% from previous measurements)
 H_etmxim = 1.549324464e-14 @10Hz  ( -3.40% from previous measurements)
 Optical_gain = 2.057370638e+12   ( -0.86% from previous measurements)
 Cavity_pole = 18.205397988 Hz  ( 0.44% from previous measurements)

Previous values are listed in klog#34533.

Estimated parameters in the Post-maintenance measurements are as follows.
 H_etmxtm = 3.845556852e-14 @10Hz ( 0.38% from pre-maintenance measurements)
 H_etmxim = 1.502986128e-14 @10Hz  ( -2.99% from pre-maintenance measurements)
 Optical_gain = 2.043225053e+12   ( -0.69% from pre-maintenance measurements)
 Cavity_pole = 18.072043623 Hz  ( -0.73% from pre-maintenance measurements)

Fig.1 and Fig.2 show the fitting results.
Fig.3 and Fig.4 show the ratio of the sensing functions

Images attached to this report
DetChar (General)
takahiro.yamamoto - 17:28 Friday 18 July 2025 (34596) Print this report
Comment to Duplication in the recent cache files at Kashiwa cluster (34595)
How about a delay on transition from IDLE to RUN of condor queue list?

Though I don't remember an detailed implementation the executed script probably decides the time span when it should analyze at the beginning of the script. This is done after transiting from IDLE to RUN. So if waiting time in IDLE is longer than the job submission interval and multiple makeCache jobs spooled on the queue list transit to RUN at the same time, duplication can be occurred.
OBS (Summary)
takashi.uchiyama - 17:01 Friday 18 July 2025 (34586) Print this report
Operation shift summary
2025/07/18
Operator's name: Uchiyama, Takahashi
Shift time: 9-17 (JST)
*Maintenance day

Check Items:
VAC: No issues were found.
CRY cooler: No issues were found.
Compressor: No issues were found.
GAS filter output: No issues were found.

IFO state (JST):
08:00 "OBSERVING" -> The OBS INTENT was OFF for the calibration work.
09:00 The shift started. The first half of the calibration work.
Maintenance work
17:00 This shift finished.



DetChar (General)
hirotaka.yuzurihara - 16:11 Friday 18 July 2025 (34595) Print this report
Duplication in the recent cache files at Kashiwa cluster

[Hido, Yuzurihara]

Hido-san reported that there was a duplication in the recent cache files at the kmst-2 (Kashiwa cluster). The time of the duplication are summarized in the attached txt file. I checked several thing, but I'm not sure the critical cause. It's better to perform the countermeasure.

Details

  • As I checked the history of condor submission, the job to produce the cache file finished without errors.
  • I found many job were running around the time of the duplication.
    • To separate the cause of the duplication, I tried to run many jobs to occupy the cpu resources and to run the job in the detchar account. The last submitted job run at the dedicated cpu. So, the many jobs are not direct cause.
    • Note that the job to produce the cache file is running at the dedicated cpu since 2025/05/07 (see klog33698).
  • I reproduced the cache files for 14359, 14360, 14366 directories. The cache files including the duplication are stored in /home/detchar/work/20250718_HTcondor 
  • We will need to reproduce the segment files for these time, after several checks.
  • As a countermeasure, it's better to update the script to remove the duplications in the cache file (such as using uniq). Before running the script regularly, I will test the script.
Non-image files attached to this report
Comments to this report:
takahiro.yamamoto - 17:28 Friday 18 July 2025 (34596) Print this report
How about a delay on transition from IDLE to RUN of condor queue list?

Though I don't remember an detailed implementation the executed script probably decides the time span when it should analyze at the beginning of the script. This is done after transiting from IDLE to RUN. So if waiting time in IDLE is longer than the job submission interval and multiple makeCache jobs spooled on the queue list transit to RUN at the same time, duplication can be occurred.
OBS (SDF)
dan.chen - 15:32 Friday 18 July 2025 (34594) Print this report
Comment to Changes of observation.snap during O4c (34169)

We accepted Pcal beam position related SDF diffs as reported klog34593.

Images attached to this comment
CAL (Pcal general)
dan.chen - 15:30 Friday 18 July 2025 (34593) Print this report
Pcal Parameter Update Report

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

Operator: Nagisa Sembo, Shingo Hido, Dan Chen

Update Time: 2025/07/18 15:22:18

EPICS Key Before [mm] After [mm] Δ (After - Before) [mm]
K1:CAL-PCAL_EX_TCAM_PATH1_X 3.09398 mm 3.33656 mm +0.24258 mm
K1:CAL-PCAL_EX_TCAM_PATH1_Y 62.75985 mm 62.50185 mm -0.25800 mm
K1:CAL-PCAL_EX_TCAM_PATH2_X -0.53956 mm -0.44882 mm +0.09074 mm
K1:CAL-PCAL_EX_TCAM_PATH2_Y -63.27941 mm -63.30321 mm -0.02380 mm

Update Time: 2025/07/18 15:22:54

EPICS Key Before [mm] After [mm] Δ (After - Before) [mm]
K1:CAL-PCAL_EX_TCAM_MAIN_X 3.40552 mm 3.49668 mm +0.09117 mm
K1:CAL-PCAL_EX_TCAM_MAIN_Y 12.50792 mm 12.35540 mm -0.15252 mm

Update Time: 2025/07/18 15:23:28

EPICS Key Before [mm] After [mm] Δ (After - Before) [mm]
K1:CAL-PCAL_EY_TCAM_PATH1_X 1.61036 mm 1.14779 mm -0.46257 mm
K1:CAL-PCAL_EY_TCAM_PATH1_Y 64.98976 mm 64.88813 mm -0.10163 mm
K1:CAL-PCAL_EY_TCAM_PATH2_X -0.03740 mm -0.18395 mm -0.14655 mm
K1:CAL-PCAL_EY_TCAM_PATH2_Y -70.08737 mm -69.77199 mm +0.31538 mm

Update Time: 2025/07/18 15:23:59

EPICS Key Before [mm] After [mm] Δ (After - Before) [mm]
K1:CAL-PCAL_EY_TCAM_MAIN_X 9.21496 mm 9.00371 mm -0.21126 mm
K1:CAL-PCAL_EY_TCAM_MAIN_Y -3.34477 mm -3.00069 mm +0.34408 mm

 

DGS (General)
shoichi.oshino - 14:07 Friday 18 July 2025 (34592) Print this report
Exchange k1tw1 SSD
[Ikeda, Oshino]

We exchanged k1tw1 SSD for the new one.
The data recorded on the previous SSD is currently being copied to the NFS server.
The data from the last six months is being temporarily loaded from an external disk. We plan to switch to a NAS storage space next week.
DGS (General)
shoichi.oshino - 14:06 Friday 18 July 2025 (34591) Print this report
Comment to Exchange k1tw0 SSD (34516)
After finishing the data copy to the storage, I changed the path to read minute_raw data and restarted daqd process on k1nds0.
OBS (SDF)
dan.chen - 10:12 Friday 18 July 2025 (34589) Print this report
Comment to Changes of observation.snap during O4c (34169)

We accepted Pcal beam position related SDF diffs as reported klog34588.

Images attached to this comment
CAL (Pcal general)
dan.chen - 10:10 Friday 18 July 2025 (34588) Print this report
Pcal Parameter Update Report

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

Operator: Shingo Hido, Nagisa Sembo, Dan Chen

Update Time: 2025/07/18 09:57:04

EPICS Key Before [mm] After [mm] Δ (After - Before) [mm]
K1:CAL-PCAL_EX_TCAM_PATH1_X 3.26692 mm 3.09398 mm -0.17294 mm
K1:CAL-PCAL_EX_TCAM_PATH1_Y 62.67463 mm 62.75985 mm +0.08522 mm
K1:CAL-PCAL_EX_TCAM_PATH2_X -0.12804 mm -0.53956 mm -0.41152 mm
K1:CAL-PCAL_EX_TCAM_PATH2_Y -63.39445 mm -63.27941 mm +0.11504 mm

Update Time: 2025/07/18 09:58:03

EPICS Key Before [mm] After [mm] Δ (After - Before) [mm]
K1:CAL-PCAL_EX_TCAM_MAIN_X 3.38665 mm 3.40552 mm +0.01887 mm
K1:CAL-PCAL_EX_TCAM_MAIN_Y 12.36073 mm 12.50792 mm +0.14719 mm

Update Time: 2025/07/18 09:58:50

EPICS Key Before [mm] After [mm] Δ (After - Before) [mm]
K1:CAL-PCAL_EY_TCAM_PATH1_X 1.51586 mm 1.61036 mm +0.09450 mm
K1:CAL-PCAL_EY_TCAM_PATH1_Y 63.81734 mm 64.98976 mm +1.17242 mm
K1:CAL-PCAL_EY_TCAM_PATH2_X -0.45437 mm -0.03740 mm +0.41697 mm
K1:CAL-PCAL_EY_TCAM_PATH2_Y -70.58075 mm -70.08737 mm +0.49338 mm

Update Time: 2025/07/18 09:59:14

EPICS Key Before [mm] After [mm] Δ (After - Before) [mm]
K1:CAL-PCAL_EY_TCAM_MAIN_X 8.41675 mm 9.21496 mm +0.79822 mm
K1:CAL-PCAL_EY_TCAM_MAIN_Y -4.09518 mm -3.34477 mm +0.75041 mm

[1]+ Done emacs pcal_update_report.html

CAL (General)
hirotaka.yuzurihara - 10:00 Friday 18 July 2025 (34587) Print this report
TCam photo session 20250718

I took the TCam photos for four mirrors at 9:37 ~ 9:42 this morning. The previous work is klog34514.

  • ETMY
  • For these mirrors, I updated the reference positions. I also re-draw the yellow line shown at the k1mon4. For the other mirrors, we don't need to update the reference positions.
OBS (General)
shinji.miyoki - 8:01 Friday 18 July 2025 (34585) Print this report
Comment to Set observing bit (34099)

We turned off the OBS INTENT around 08:00 JST for CAL work.

OBS (Summary)
shinji.miyoki - 7:13 Friday 18 July 2025 (34584) Print this report
Comment to Operation shift summary (34547)

EY_4K_REF3_50K temp continues decreasing, but it was slow.

Images attached to this comment
CRY (Cryostat IX)
shinji.miyoki - 7:12 Friday 18 July 2025 (34583) Print this report
Comment to IX REF1 cooler mulfunction (34569)

Both IX_REF1_50K/4K_HEAD temperatures recovered as in Fig.1.

Images attached to this comment
MIF (Noise Budget)
kentaro.komori - 23:06 Thursday 17 July 2025 (34582) Print this report
Estimating coil driver noises of type-A tower actuators

[Ushiba, Komori]

Abstract:

We measured the transfer functions from the BF GAS, BF damper, and F3 GAS to DARM and performed a noise budget analysis for the corresponding coil driver noises.
All were found to be negligible.

Detail:

In a previous study, we observed a significant improvement in DARM sensitivity upon enabling the dewhitening filters for the type-A tower suspensions (klog:33197).
This raised the possibility that coil driver noise from these suspensions might be limiting the current DARM sensitivity.
To assess this, we measured the transfer functions from selected type-A suspensions to DARM and evaluated the associated noise contributions.

We selected three suspensions—BF GAS, BF damper, and F3 GAS—since they are located closest to the cryopayload, and thus expected to have the largest potential impact.

First, we estimated the coil driver noises of the BF damper and F3 GAS to be negligible.
The nominal coil driver noise levels are 3.3e-5 cnt/√Hz at each SUMOUT port (klog:33428).
Even when injecting white noise of 1e-2 cnt/√Hz at 5-100 Hz, no significant coherence with DARM was observed.
An example is shown in Fig. 1, where the left bottom panel shows no coherence between DARM and IY BF_V3, despite the noise injection of 1e-2 cnt/√Hz (right middle panel).

Next, we injected white noise at the SUMOUT ports of the BF GAS actuators with amplitudes of 1e-2 cnt/√Hz for EX, EY, and IX, and 3e-2 cnt/√Hz for IY.
This resulted in observable coherence in the 15-45 Hz range (Figs. 2-5).
The projected noise contributions can be roughly estimated by scaling the excited spectra by the ratio of the nominal noise to the injection level: 3.3e-5/1e-2 = 3.3e-3 for EX, EY, IX and 3.3e-5/3e-2 = 1.1e-3 for IY.
These projections are shown in Fig. 7 and confirm that even the coil driver noise from the BF GAS is negligible.

Discussion:

Figure 6 compares the nominal DARM spectrum with those obtained during noise injection into the BF GAS actuators.
While we observed an increase in DARM noise by a factor of a few or an order of magnitude in the 15-45 Hz range, we also saw a clear degradation of sensitivity in the 60-100 Hz band.
This suggests that a nonlinear noise source—possibly related to the observed coherence—is close to the current sensitivity limit, as also suggested by klog:34571.

In Fig.8, we compare the SUMOUT noise spectra of the BF GAS actuators during nominal interferometer operation.
The noise in IY GAS is consistently below the coil driver noise level of 3e-5 cnt/√Hz, whereas other suspensions exceed this threshold at certain frequencies.
The broad 2e-4 cnt/√Hz noise observed at IX may be explained by numerical errors in diaggui due to large DC offsets.
The excess noise below 20 Hz at EX and EY might be reduced by implementing more aggressive low-pass filter at the control stage.

Finally, this result can be inconsistent with the prior observation that enabling the dewhitening filters improved the DARM sensitivity.
The DAC noise without dewhitening is at most 4e-4 cnt/√Hz, which still seems too small to explain the observed sensitivity limitation.
Further investigation is needed—such as turning off the dewhitening filters one by one and monitoring the impact on sensitivity—to resolve this discrepancy.

Images attached to this report
OBS (Summary)
takashi.uchiyama - 17:00 Thursday 17 July 2025 (34575) Print this report
Operation shift summary
2025/07/17
Operator's name: Uchiyama, Takahashi
Shift time: 9-17 (JST)
*Commissioning day

Check Items:
VAC: No issues were found.
CRY cooler: No issues were found. (Temperature of "IX: 4K_REF1_50K_HEAD" and "IX: 4K_REF1_50K_BAR" was down to 84K and 105K at 10 AM, respectively. )
Compressor: No issues were found.
GAS filter output: No issues were found.

IFO state (JST):
05:38 M7.3 Earthquake at Arushan Islands
09:00 The shift started. The status was "LOCKING".
10:56 "OBSERVING" -> The OBS INTENT was OFF for the commissioning work.
COMMISSIONING
15:35 The OBS intent has been turned on. -> "OBSERVING"
16:28 Lock lost
17:00 This shift finished. "LOCKING"
MIF (General)
takafumi.ushiba - 16:59 Thursday 17 July 2025 (34581) Print this report
Non-linear coupling evaluation with low-freuency injections

Abstract:

We injected sine excitation at 6.125Hz to increase the RMS of OMC transmission.
Though RMS was increased by a factor of 5.7, no significant excess can be seen around 60-100Hz, so low frequency RMS doesn't seem problematic.
I also estimated the siderobe due to the low frequency spectrum and it seems negligible as well.

Detail:

We measured the spectrum of calibrated DARM displacement and OMC trans power by injecting the sine signals from DARM error point.
Excitation frequency was 6.125 and amplitudes are 10e-6, 20e-6, 30e-6, 40e-6, and 50e-6 cnts.
Figure 1 shows the measured spectra (excitation amplitude is written in the legend and blue lines are the spectrum without excitation for the reference).
Even though the RMS was increased by a factor of 5.7, no significant excess can be seen around 60-100Hz.
So, DARM non-linear coupling due to low-frequency RMS doesn't seem to contaminate the sensitivity around 60-100Hz.

In addition, we evaluated the siderobe of low frequency spectrum.
When we injected the line at 6.125Hz, 50.875Hz peak was appeared in OMC trans spectrum, which generated due to non-linear coupling between 44.75Hz peak and 6.125Hz peak (see fig2).
According to the peak height at 50.875Hz, sideband peak height was propotional to the peak height at 6.125Hz, so we can evaluate the siderobe of 44.75Hz peak from the OMC trans spectrum.
Figure 3 shows the estimated siderobe generated due to 44.75Hz.

Though the noise floor is low enough, some peaks are very close to the current sensitivity.
So, damping/supressing the peaks aroun 20Hz and 40Hz seems effective to mitigate the sensitivity degradation when suspension resonances are kicked.
In addition, each peak should have a similar effect, so the summation of siderobe would be contaminate the sensitivity even during steady state.

So, it would be worth trying to damp/supress the resonant peaks.

Images attached to this report
OBS (General)
takahiro.yamamoto - 15:47 Thursday 17 July 2025 (34579) Print this report
Interface improvement for OBS operations

To prevent unfortunate accidents such as klog#34539, I added some indicators on the MEDM screens.

1) Calibration measurements must be in CALIB_NOT_READY or READY because measured TFs are not ensured to be same as ones in OBSERVING if measurements are done in LOCKED state. So I added an indicator to notify that IFO guardian is LOCKED or below at a side of a "start meas." button as shown in Fig.1. Start measurement after confirming that IFO guardian is in CALIB_NOT_READY or READY. (BTW, we request OBSERVATION_WITHOUT_LINES to IFO guardian for our measurements. So IFO guardian falls down LOCKED state soon after starting measurement. This behavior is no problem.)

2) OBSERVING is always requested to IFO guardian in a normal case. But someone may request another state by mistakes. Though only OBSERVING was set as a requestable state, it was actually occurred. So it's difficult to avoid this issue completely. So I added information about STATE_S and REQUEST_S of IFO guardian on the OBS_INTENT interface as a plan-B (see also Fig.2). PM, RC, or CL can probably notice it on this interface even if someone accidentally requests other states to IFO guardian.

When we will raise OBS_INTENT bit,
- a requested state to IFO guardian must be OBSERVING.
- a current state of IFO guardian should be READY (Basically it must be READY. But when we confirmed that IFO can reach READY and we couldn't wait IFO came back to READY such as EQs occurring just before 22:00, it might be allowed to raise OBS_INTENT without IFO in READY?).

Images attached to this report
OBS (General)
takafumi.ushiba - 15:37 Thursday 17 July 2025 (34580) Print this report
Comment to Set observing bit (34099)

We turned on the OBS INTENT around 15:35 JST after the commissioning work today.

DMG (Data transfer & archiving)
nobuyuki.kanda - 12:14 Thursday 17 July 2025 (34578) Print this report
Comment to Data transfer during network disconnection (34440)
We add gif files that reproduced by CAL group on main server.
Now these files are copied in
kmst2-0[1,2]:/data/LVK/low-latency/ll_merged/K1_NoGap/
DetChar (General)
takahiro.yamamoto - 10:43 Thursday 17 July 2025 (34576) Print this report
Activity evaluation during OBS_INTENT==OFF
Duty factor in O4a and O3GK took into account periodical maintenance time, down time by some trouble, and trouble shooting time. On the other hand we have also commissioning time during the observing period in O4c. Though taking into account also commissioning time is suitable as the duty factor during O4c run, it's slightly unfair on the comparison with past observing runs as the operational duty factor of the Interferometer. So I tried to separate "periodical maintenance time", "down time by some trouble" and "commissioning time" by the information on klog and other activity logs because there is no dedicated flags for each activities (all activities out of observing mode were done just with retracting OBS_INTENT).

According to the evaluation until Jul. 16th, a time period of retracting OBS_INTENT is ~35% of total observing period. Maintenance time, trouble shooting time, and commissioning time are 12%, 6%, and 17% of total period, respectively (34%, 16%, and 49% of OBS_INTENT==OFF period, respectively). More details can be found in JGW-G2516753.

These activities periods are being served as Segment information in /users/OBS/O4c/segments/obs_intent_off/*.xml which contain
K1:DET-OBS_INTENT_OFF:1
K1:OBS_INTENT_RETRACT_MAINTENANCE:1
K1:OBS_INTENT_RETRACT_TROUBLE:1
K1:OBS_INTENT_RETRACT_COMMISSIONING:1
.
Because they have a different purpose than the science mode subdivisions, so the file paths are separated from those uploaded to DQSEGDB.
DGS (General)
Hiroshi Takaba - 10:22 Thursday 17 July 2025 (34577) Print this report
Comment to EY TCam server seems to be unreachable (34542)
We removed the UPS battery and found it was a third-party product that had likely been replaced once.
The battery was physically broken, and only put out 3V of voltage.
We replaced with a genuine battery, an automatic check was performed and it worked normally.
However, the lifespan of the UPS itself is seven years in an environment of 25°C, and eight years had passed since it was manufactured in April 2017, so we decided to replace it with a new UPS.
Images attached to this comment
Search Help
×

Warning

×