First I copied Matlab 2016b from k1nfs0.
After activating the license, I found that Matlab takes a long time to start.
I could not solve this problem, so I decided to start Matlab by specifying the license file directly.
I also copied k1export.m and startup.m files from the current k1boot.
When I opened the RT model file, I noticed that the link to the CDS parts was broken.
Previously CDS parts are installed in /opt/rtcds/rtscore, but in the new k1boot it is installed in /usr/share/advligorts.
So I cannot use the files via NFS.
Since advligorts can now be installed with apt, I will install this library directly in WS.
Overview
After starting the Picomotor and Steppermotor scripts, the EPICS channel is displayed very slowly, so the EPICS channel is always displayed and the communication part with the motor driver is changed to an on/off mechanism.
Operation
Please reopen sitemap first.
Otherwise, the old MEDM will be displayed.
In case of Picomotor
Press the blue OFF/ON button to start communication.
If it turns ON, the motor can be operated as before.
If communication fails, it turns OFF.
In this case, reboot with the rebooter and turn it ON in the same way.
Please turn it OFF after use.
In case of Steppermotor
Turn on the BIO and press the blue OFF/ON button to start communication.
If it turns ON, the motor can be operated as before.
If communication fails, it will turn OFF. In this case, turn BIO back on.
Please turn OFF after use.
Maintenance of k1script*
Changed IP address of k1script1's Pico network and connected k1script0 to Pico network.
DGS side is not changed.
k1script0: .250
k1script1: .250->.251
The address of the k1script in the authorized_keys file on the k1hwp* side of the HWP was also changed to reflect this change.
DGS Regular maintenance day(2/3)
Stepper motor
[Checked]
Check if the power supply can be controlled by BIO
Check if the script can be started
Checked that the limit switches installed are green.
[Check result]
PR0(PRM_GAS,PR3_GAS):NG
=> Network SW was abnormal. Recovered.
Release Sensor
[Checked the Release Sensor.]
Checked that Release Sensor is 0, 1: Seated.
[Check result]
ETMX, ETMY, ITMX, ITMY : No problem
Picomotor
[Confirmation]
PingTest is performed.
[Result]
Only known
NG:
MCI,STM1,
POS_POM,POM1
=> Confirmation only, no recovery operation was performed.
OK:
ETMX,ETMY,ITMX,ITMY
BS(IM,BF),SRM(IM,BF),SR2(IM,BF),SR3(IM,BF,STM)
PRM(IM,BF),PR2(IM,BF),PR3(IM,BF)
MCE,IMMT1,IMMT2,OMMT1,OMMT2,OSTM
REFL_WFS,POP,POP2,POS,POS2,POP_WFS,AS_WFS
POP_POM, MCF(MCO,MCI)
PCAL(EX1,EX2,EY1,EY2):Not checked because it is ON only when used
Temperature controller
[Checked]
Is the temperature acquisition working properly?
[Check result]
Is the temperature acquisition working properly?
=> No problem
Precision air Processer
[Check Contents]
Is the temperature acquisition working properly?
[Result]
No problem
FunctionGenerator
(Confirmation)
Is there a ping response?
Are all EPICS channels alive?
[sitemap]-[Commissioning]-[ALS FG]-[Xarm],[Yarm].
[Check result]
X and Y PLLs are working properly.
HWP control PC
(Confirmation)
Check if it is possible to login to the control PC.
(Result)
Both k1hwp0, 1 and 2 are OK.
When:
3rd/Feb./2023
Workers:
N. Kimura
H. Yasui
Task:
We performed a vacuum leak test for OMMT and OMC fter leak repair (https://klog.icrr.u-tokyo.ac.jp/osl/?r=23775) using a helium leak detector and helium gas.
The tests were performed on the area on the AS area side (+X side of OMC) of the OMC and others.
The test was conducted with a test sensitivity of ~1 x 10^-12 Pam^3/s, confirming that there was no leakage > ~1 x 10^-11 Pam^3/s .
Helium background during the test ranged aroud ~1.55 x 10^-10 Pam^3/s.
We conclud there are no leakeage on OMMT and OMC lager than ~1 x 10^-11 Pam^3/s, and can open the gate valve between SRM and OMMT.
When:
3rd/Feb./2023
Workers:
N. Kimura
H. Yasui
Task:
We started up the air compressor installed in the passage next to the computer room used to open and close the gate valve installed between SRM and OMMT.
After startup, we inspected the piping connections for leaks and found a leak in the threaded part of the fitting.
(See attached photo)
To repair the leak, we replaced the seal at the threaded part.
Currently, the air compressor is in operation and compressed air for driving the gate valve is supplied to the gate valve.
Abstract:
We checked the operational status of the activated ion pumps of IXV and IYV.
See below for comfirmed status. The activated ion pumps of IXV and IYV are in normal operation.
Workers:
N. Kimura
H. Yasui
Center area:
IXV (Position: Center 2F):
Status: Activated, evacuated by Ion Pump
11:26, 3/Feb./2023
The pressure displayed on the pressure gage: 4.4 x 10^-6 Pa
The pressure displayed on the Ion pump power supply: 2.4 x 10^-6 Pa
The anode voltage and current displayed on the Ion pump power supply: 6.2 kV and 363 x 10^-6 A
IYV (Position: Center 2F):
Status: Activated, evacuated by Ion Pump
11:27, 3/Feb./2023
The pressure displayed on the pressure gage :not confirmed
The pressure displayed on the Ion pump power supply: 2.5 x 10^-6 Pa
The anode voltage and current displayed on the Ion pump power supply: 6.1 kV and 372 x 10^-6 A
[Ushiba-san, Yokozawa-san, Takase-san, Hirata]
We tried to set windshield duct between PR2 flange and POP table wall. Unfortunately, the lenght is still little bit long. It can be installed by disassembling windshield itself, but it's annoying. So we decided to modify length, and try installing again next week.
Detail:
Currently, error signals of PRCL, MICH, and DARM was fractuated at low frequency in the current PRFPMI_RF_LOCKED state, so we need to modified control loops to supress the residual motion of each DoFs.
Figure 1, 2 and 3 show the new OLTF of PRCL, MICH, and DARM control, respectively.
Figure 4, 5, and 6 show the error signals of PRCL, MICH, DARM, when changing filters from old one to new ones.
T cursor chows the timing when engaging filters.
Error signals of PRL, MICH, and DARM becomes smaller and the loop seems stable enough.
So, I will try to switch TRAS signals to OMC DC for the next step.
By the way, is this transmission power of OMC consistent? Maybe yes as follows, but please someone check it precisely:
- IMC output around 2.2 W
- PRM reduces it 1/10, so it becomes 220 mW.
- Before reaching OMC, the beam passes BS twice, so 1/2*1/2 = 1/4, meaning 55 mW.
Detail:
First, I implemented OMMT2T centering loop to OMMT1, which is reported in klog23728.
Then, We tested ADSs of OMMT2 and OSTM for fine alignment to OMC.
Since the OMC QPD loop is currently stable (it was not stable during O3 due to glitch problems), we feedback ADS signals to the setpoint of QPD loops.
Followings are the detail of setting of ADSs:
Dither frequency: 15 Hz, 16 Hz, 17 Hz, and 18 Hz for OMMT2P, OMMT2Y, OSTMY, and OSTMP, respectively.
Dither amplitude: 200 cnts for pitch and 600 cnts for yaw.
INF filter: FM1 (BandPass filter)
OUTF filter: FM1 (LP1), FM2 (comb15), FM3 (comb1), FM9 (integrator)
Figure 1 shows the time series of ADS feedback and OMC output.
Transmission power increases from 34 to 50, and ADSs seem working well.
I implemnted the ADSs in INITIAL_ALIGNMENT guardian but maybe it is better to move it some other guardian like OMC_ASC.
Note:
During the work, OMC_ASC guardian moved OMMT1 and kicked the suspension because it was used for OMMT2T QPD centering.
Since OMMT1 doesn't use OMC alignment, I removed the request to OMMT1 from OMC_ASC guardian not to conflict the alignment control.
Also, we faced some bugs of OMC_ASC guardian.
Figure 2 shows the log around the bug.
It seems new thread is called withouut killing the existing thread, so it needs to be fixed.
In the middle of the work, the OMC_ASC guardian threw an error on python-threading and die, and we spent a great deal of time working around it; not resolved yet but we just somehow "omit" it now. It appears to be due to a conflict among an already-existing thread and newly started one.
Although this happened today largely due to an unfortunate coincidence or other factors (like some unexpected lines in the OMC_LSC guardian, so we modified them then), nevertheless, it means that there is an error mixed in with the paths that could be taken, so one should do modify it.
The message is
Now waiting RMS < 10: TM_OLDAMP_P TM_OLDAMP_Y
So, temporary I added the number to opticalign
K1:VIS-IMMT2_TM_OPTICALIGN_P_OFFSET = -1300
K1:VIS-IMMT2_TM_OPTICALIGN_Y_OFFSET = -3600
Do we need the offload by pico motor?
Following 23811 and 23790, I checked coherence among DARM and NAB PDs in the wider frequency band when PRFPMI locked today (23816).
- EXA NAB PD seems not working.
- IYA NAB PD seems somehow unstable in high frequency. Time series signal might show glitchy feature, but I have no idea now.
- Within this frequency range, the highest frequency having coherence seems no more than 10 Hz.
So far 2.8Hz? feature would have high coherence. This might be due to alignment flcutuation of certain mirrors might be converted to intra-cavity power or so. Further check with transmission power or TRX/Y or Oplevs might be helpful. Anyway it is out of the observation band.
[Akutsu (remote), Ushiba]
Abstract:
We engaged ADSs to OMMT2 and OSTM for fine alignment to OMC.
It seems working well and transmitted power is increased by a factor of 1.3.
Detail will be posted tomorrow.
Note:
During this work, we reduced laser power as already repoted in klog23814.
During the work, we modified OMC_ASC and OMC_LSC guardian slightly.
It doesn't affect the OMC lock but if you find any porblems, please let us know.
In the middle of the work, the OMC_ASC guardian threw an error on python-threading and die, and we spent a great deal of time working around it; not resolved yet but we just somehow "omit" it now. It appears to be due to a conflict among an already-existing thread and newly started one.
Although this happened today largely due to an unfortunate coincidence or other factors (like some unexpected lines in the OMC_LSC guardian, so we modified them then), nevertheless, it means that there is an error mixed in with the paths that could be taken, so one should do modify it.
Detail:
First, I implemented OMMT2T centering loop to OMMT1, which is reported in klog23728.
Then, We tested ADSs of OMMT2 and OSTM for fine alignment to OMC.
Since the OMC QPD loop is currently stable (it was not stable during O3 due to glitch problems), we feedback ADS signals to the setpoint of QPD loops.
Followings are the detail of setting of ADSs:
Dither frequency: 15 Hz, 16 Hz, 17 Hz, and 18 Hz for OMMT2P, OMMT2Y, OSTMY, and OSTMP, respectively.
Dither amplitude: 200 cnts for pitch and 600 cnts for yaw.
INF filter: FM1 (BandPass filter)
OUTF filter: FM1 (LP1), FM2 (comb15), FM3 (comb1), FM9 (integrator)
Figure 1 shows the time series of ADS feedback and OMC output.
Transmission power increases from 34 to 50, and ADSs seem working well.
I implemnted the ADSs in INITIAL_ALIGNMENT guardian but maybe it is better to move it some other guardian like OMC_ASC.
Note:
During the work, OMC_ASC guardian moved OMMT1 and kicked the suspension because it was used for OMMT2T QPD centering.
Since OMMT1 doesn't use OMC alignment, I removed the request to OMMT1 from OMC_ASC guardian not to conflict the alignment control.
Also, we faced some bugs of OMC_ASC guardian.
Figure 2 shows the log around the bug.
It seems new thread is called withouut killing the existing thread, so it needs to be fixed.
By the way, is this transmission power of OMC consistent? Maybe yes as follows, but please someone check it precisely:
- IMC output around 2.2 W
- PRM reduces it 1/10, so it becomes 220 mW.
- Before reaching OMC, the beam passes BS twice, so 1/2*1/2 = 1/4, meaning 55 mW.
[Akutsu (remote), Ushiba]
Abstract:
We modified filter shape of PRCL, MICH, and DARM for handover TRAS signals to OMC.
The new filters seem working well, so we will try DC readout soon.
Detail will be posted tomorrow.
Detail:
Currently, error signals of PRCL, MICH, and DARM was fractuated at low frequency in the current PRFPMI_RF_LOCKED state, so we need to modified control loops to supress the residual motion of each DoFs.
Figure 1, 2 and 3 show the new OLTF of PRCL, MICH, and DARM control, respectively.
Figure 4, 5, and 6 show the error signals of PRCL, MICH, DARM, when changing filters from old one to new ones.
T cursor chows the timing when engaging filters.
Error signals of PRL, MICH, and DARM becomes smaller and the loop seems stable enough.
So, I will try to switch TRAS signals to OMC DC for the next step.
Since the OMC output power is close to 60 mW when OMC alignment is good, I reduced PSL output power by rotating PSL HWP.
Now, PSL output power is about 2.2 W while it was 2.8 W before rotating HWP.
Since signals used for LSC except for CARM is normalized by IMC trans power, it doesn't affect the lock of FPMI (though CARM gain was reduced slightly but robust enough).
I'm not sure single arm lock is stable now (I hope it is also fine though), so if single arm lock is unstable please increase the laser power or adjust the gain of CARM CMS.
1) I tried to match the values of power spectra measured by the accelerometers and the geophones (nemed ETMX_IP_ACCINF and ETMX_IP_FLDACC).
2) I tried to match the values of power spectra measured by the accelerometers and the geophones (nemed ETMX_IP_ACCBLEND_ACCL, T, Y and ETMX_IP_FLDACC_FLDACCL, T, Y)
I tried to match the values of power spectra measured by the accelerometer and the geophones (nemed ETMX_IP_ACCINF and ETMX_IP_FLDACC).
To do this, I changed the servo filter named ETMX IP FLDACCINF FILTER.
The picture of results was attached.
I tried to match the values of power spectra measured by the accelerometer and the geophones (nemed ETMX_IP_ACCBLEND_ACCL, T, Y and ETMX_IP_FLDACC_FLDACCL, T, Y).
To do this, I changed the matrix named ETMX IP FLDACCALIGN MATRIX.
The picture of results was attached.
Following 23790, I checked some NAB PDs and found that one at EXA seemed strange. Are they turned on???
This is because the ASD of the strain channel differs greatly between low and high frequencies.
This difference is even greater at PRFPMI and needs to handle.
I compared the strain plotted in the following three settings.
1. FFT length 4s
2. FFT length 60s
3. FFT length 4s + high pass filter 10Hz
The data used are the following times:
LSC_LOCK guardian state : PRFPMI_RF_LOCKED
GPS time : 1359200000 - 1359200600
The attached files are the strain of each setting.
2 and 3 improve the strain by a few tens of Hz.
Therefore, I choose setting 3 for SummaryPage.
Abstract:
I measured spectra of ALS signals when FPMI was locked and compared the spectra with and without PNCs.
large peaks at low frequency in ALS_DARM signals are completely disappeared while ALS_CARM still has a peak at 0.46 Hz.
Since the peak in ALS_CARM and PR2 TML OpLev has a large coherence, it comes from PR2 motion.
Detail:
Figure 1 shows the spectra of ALS signals when FPMI was locked.
Reference are the signals without PNC and current values are the signals with PNC.
Large peaks at 0.38 Hz and 0.43 Hz are completely disappeared from ALS signals by engaging PNC.
However, ALS_CARM signals still have a peak at 0.46 Hz while ALS_DARM signals don't have.
The fact that ALS_DARM doesn't have a peak implies that the source of this peak is coming from IR path.
So, I checked the coherence of ALS_CARM signals and PR2 TML OpLev (right bottom graph in the fig1).
There is a large coherence around 0.46 Hz, so we ned to damp 0.46 Hz longitudinal mode of PR2 to improve further.
First I created /opt/rtcds/userapps/release directory to put model files.
Also created /opt/rtcds/userapps/release/etc/userapps-user-env.sh file to set the path of RT models to the RCG_LIB_PATH parameter.
I found that the directory structure was different from the current KAGRA DGS at this time.
This is because of my misunderstanding of facter and hiera so I modified "site" parameter to KAMIOKA.
The build command now works, but an error has occurred so I will fix this.
This is a report of the health check in the OMMT1/2/OSTM suspensions after the pump-down.
The measured transfer functions look healthy. There are some deviations from the optimal position of OSEM.
OMMT1 H3: horizontal
OMMT1 H4: axial, horizontal
OMMT2 H1: axial, horizontal
OMMT2 H3: axial
OSTM H1: axial
OSTM H2: axial, horizontal
When:
2nd/Feb./2023
Workers:
N. Kimura
H. Yasui
M. Takahashi
Task:
We performed a vacuum leak test for OMMT and OMC fter leak repair (https://klog.icrr.u-tokyo.ac.jp/osl/?r=23775) using a helium leak detector and helium gas.
The tests were performed on all flange connections except the top flange of the OMMT and OMC and the area on the ASC side of the OMC.
The test was conducted with a test sensitivity of ~1 x 10^-12 Pam^3/s, confirming that there was no leakage > ~1 x 10^-11 Pam^3/s .
Helium background during the test ranged from 8.5x 10^-10 Pam^3/s to 1 x 10^-10 Pam^3/s.
Leakage testing of the flanges in the area on the ASC side is scheduled for 3rd/Feb..
When:
3rd/Feb./2023
Workers:
N. Kimura
H. Yasui
Task:
We performed a vacuum leak test for OMMT and OMC fter leak repair (https://klog.icrr.u-tokyo.ac.jp/osl/?r=23775) using a helium leak detector and helium gas.
The tests were performed on the area on the AS area side (+X side of OMC) of the OMC and others.
The test was conducted with a test sensitivity of ~1 x 10^-12 Pam^3/s, confirming that there was no leakage > ~1 x 10^-11 Pam^3/s .
Helium background during the test ranged aroud ~1.55 x 10^-10 Pam^3/s.
We conclud there are no leakeage on OMMT and OMC lager than ~1 x 10^-11 Pam^3/s, and can open the gate valve between SRM and OMMT.