WP 11173
Issues reported with EY temperature channel H1:PEM-Y_EBAY_RACK2_TEMPERATURE. With fence work ongoing this morning, we swapped cabling for Rack1 and Rack2 sensors on the EtherCAT End Link Chassis. This will help us determine if issue stays with Beckhoff channel or sensor. I did note that the M12 connector threads on port 1 seems to striped. Connector will need to be replaced.
Time cables were swapped: 10-10:30 am
J. Kissel, R. Savage After Rick and I conversed about the systems level compromises in play (see LHO:69175) when placing the newer 410.2 Hz PCALX line near the 410.3 Hz PCALY line for comparisons like that in LHO:69290, we agree to push forward with the plans discussed in LHO:69175: (1) Move the PCALX 410.2 Hz PCALXY comparison line further away from the pre-existing PCALY 410.3 Hz TDCF line. Joe, for entirely different reasons, recommends 0.5 Hz separation instead of 0.1 Hz. THIS ALOG The new frequency is H1:CAL-PCALX_PCALOSC2_OSC_FREQ = 409.8 Hz. (2) Update the "DARM Model transfer function values at calibration line frequencies" EPICs records for the PCALX 410.2 Hz line, NOT YET DONE, SEE BELOW (3) Revert all DEMOD the band-passes to have a pass band that's +/- 0.1 Hz wide (what we had in O3) DONE ALREADY, and now for 410.3 Hz: see LHO:69265 and THIS ALOG (4) Revert all DEMOD I & Q low passes to a 10 second time constant, or 0.1 Hz corner frequency DONE ALREADY, and now for 410.3 Hz: see LHO:69265 and THIS ALOG (5) Change COH_STRIDE back to 10 seconds to match the low pass, and Change the BUFFER_SIZE back to 13.0 in order to preserve the rolling average of 2 minutes. DONE ALREADY, and now for 410.3 Hz: see LHO:69265 and THIS ALOG I've also modified the three band-pass filters in the SIG banks of the special segregated PCALX DEMOD for the PCALXY comparison (i.e. H1:CAL-CS_TDEP_PCAL_X_COMPARE_PCAL_DEMOD_SIG, _EXT_DEMOD_SIG, _ERR_DEMOD_SIG). These had had a pass pand with of 0.01 Hz, so I've created a new band pass for 409.8, butter("BandPass",6,409.79,409.81). It lives in FM1, and I've copied the old band for 410.2 Hz pass over to FM2. In order to have *all* of our ducks in a row with the line move, we still need to do: (2) Update the "DARM Model transfer function values at calibration line frequencies" EPICs records for the PCALX 410.2 Hz line, but that also means we need to do a step not listed above (0) Update the pydarm_H1.ini file to reflect that the pcalx comparison line is now at 409.8 Hz, and (6) Let the GDS team know that there's a calibration line frequency change and they need to update the GDS line subtraction pipeline. This line frequency change is in play as of 2023-05-04 00:20 UTC. Stay tuned! Here's the latest list of calibration lines: Freq (Hz) Actuator Purpose Channel that defines Freq Since O3 15.6 ETMX UIM (L1) SUS \kappa_UIM excitation H1:SUS-ETMY_L1_CAL_LINE_FREQ Amplitude Change on Apr 2023 (LHO:68289) 16.4 ETMX PUM (L2) SUS \kappa_PUM excitation H1:SUS-ETMY_L2_CAL_LINE_FREQ Amplitude Change on Apr 2023 (LHO:68289) 17.1 PCALY actuator kappa reference H1:CAL-PCALY_PCALOSC1_OSC_FREQ Amplitude Change on Apr 2023 (LHO:68289) 17.6 ETMX TST (L3) SUS \kappa_TST excitation H1:SUS-ETMY_L3_CAL_LINE_FREQ Amplitude Change on Apr 2023 (LHO:68289) 33.43 PCALX Systematic error lines H1:CAL-PCALX_PCALOSC4_OSC_FREQ New since Jul 2022 (LHO:64214, LHO:66268) 53.67 | | H1:CAL-PCALX_PCALOSC5_OSC_FREQ Frequency Change on Apr 2023 (LHO:68289) 77.73 | | H1:CAL-PCALX_PCALOSC6_OSC_FREQ New since Jul 2022 (LHO:64214, LHO:66268) 102.13 | | H1:CAL-PCALX_PCALOSC7_OSC_FREQ | 283.91 V V H1:CAL-PCALX_PCALOSC8_OSC_FREQ V 409.8 PCALX PCALXY comparison H1:CAL-PCALX_PCALOSC2_OSC_FREQ New since Jan 2023, Frequency Change THIS ALOG 410.3 PCALY f_cc and kappa_C H1:CAL-PCALY_PCALOSC2_OSC_FREQ No Change 1083.7 PCALY f_cc and kappa_C monitor H1:CAL-PCALY_PCALOSC3_OSC_FREQ No Change n*500+1.3 PCALX Systematic error lines H1:CAL-PCALX_PCALOSC1_OSC_FREQ No Change (n=[2,3,4,5,6,7,8])
As of git hash ac191a90, I've changed the pydarm_H1.ini pydarm parameter file in order to make this change. - LINE 512 cal_line_cmp_pcalx_frequency = 410.2 + LINE 512 cal_line_cmp_pcalx_frequency = 409.8 This takes care of item (0) above.
We just had another PI lockloss from ETMX mode 24, at 10.431 kHz, at Hour 1:36 in the lock. This occured as the HOMs were thermalized through the PI forest there. I have now reverted + loaded SUS_PI guardian changes from LHO:69219, when I raised the RMS monitor damping thresholds by 2-5x. RMS monitors to trigger damping are now back to their "normal" low values. GRD changes have not yet been SVN'd.
I tried to manually damp mode 24 after it had rung up that high, but I didn't stumble onto any phases or increased/decreased damping gains that brought the mode down in time. Elenna tried to turn omc_whitening off to buy us more time for pi-damping, which I think helped but it was likely too late. I'm not sure why we can't damp the rung up 10.4kHz mode, but for now I am lowering the RMS thresholds to engage PI damping to what they were before, when we had mitigated PI locklosses for quite a while.
Thu May 04 10:05:14 2023 INFO: Fill completed in 5min 14secs
Gerardo confirmed a good fill curbside.
We are experimenting with filling in the morning before the sun has had time to heat up the outside dewar and raise the head pressure (which increases the LN2 spill and lowers the thermocouples starting temperatures). For example, TC-A starting temperature yesterday was -67C and today is -42C.
To make the SDF Diff number stand out from its neighbouring Test Point Counts, I have changed its colour scheme on the CDS Overview.
Following TJ's suggestions, the SDF DIFF colours differ between safe.snap and OBSERVE.snap references.
| zero diffs | black text, grey background |
| non-zero diffs, safe.snap | black text, light blue background |
| non-zero diffs, OBSERVE.snap | white text, red backgound |
On EJ's suggestion, I have also removed the FPU block from the overview. I am continuing to "calm" the FPU block on the GDS_TP screens, changing its colour from red to blue.
TITLE: 05/04 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 9mph Gusts, 7mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.19 μm/s
QUICK SUMMARY:
- IFO has been locked for 0:25 minutes upon arrival
- Switched to COMMISSIONING mode due to a few SDF observe differences - seem to be all SQZ related - Tagging SQZ, Screenshots below
- Noticed the FC2 M3 SUS is railed, later diagnosed to have come from SQZ_FC tryng to FIND_IR
- CDS/SEI/DMs ok
I have re-enabled the FC2 M3 SUS saturations checkers in the SQZ_FC filter cavity guardian. Changes committed to SVN. SQZ_FC now checks for saturations on H1:FEC-166_DAC_OUTPUT_1_{4,5,6,7} in FIND_IR, and clears the slowcontrols vco servo integrator in "IDLE" (this latter move is preventative, and may be unnecessary, I may remove this last part soon). I'll monitor in the next relockings.
TITLE: 05/04 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Locking
SHIFT SUMMARY: Spent most of the eveving with the IFO locked, did some OMC alignment and Louis did Calibration work. Lost lock from CSOFT ring up and IFO is currently locking at AQUIRE_PRMI
LOG: Louis may do more calibration if we get back to NLN.
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 22:30 | PEM | Fil | near CER | n | PEM coil cable check | 00:00? |
| 22:30 | EE | Marc | cer | n | power supply inventory | 23:15 |
| 23:13 | CAL | Jeff | CR | N | Calibration | 01:13 |
| 01:16 | COMM | Vicky, Camilla | CR | N | OMC Offsets alog 69307 | 04:00 |
| 04:30 | CAL | Louis | Remote | N | Calibration Suite | 06:05 |
Camilla, Vicky
Walking OMC ASC QPD offsets as before in LHO:67994, now that TCS and IFO has settled more, and the junk light level going from IFO --> OMC has changed (down to ~1.7mW from 5mW LHO:68177).
Starting from Koji's saved values from then:
caget H1:OMC-ASC_QPD_{A,B}_{PIT,YAW}_OFFSET:
H1:OMC-ASC_QPD_A_PIT_OFFSET -0.285
H1:OMC-ASC_QPD_A_YAW_OFFSET -0.145
H1:OMC-ASC_QPD_B_PIT_OFFSET -0.17
H1:OMC-ASC_QPD_B_YAW_OFFSET -0.05
We walked OMC ASC QPD offsets in the same range as Koji did before, looking at his offsets table, and saw similar %-level changes in the optical gain, mianly reductions. This is expected if our alignment is the same.
Camilla was hopeful (attached trend) that the below settings were an improvement but after holding for 20 minutes at these and then reverting to the above nominal settings, the difference is <0.5% (see attached plot) so no changes have been saved.
H1:OMC-ASC_QPD_A_PIT_OFFSET -0.265
H1:OMC-ASC_QPD_A_YAW_OFFSET -0.145
H1:OMC-ASC_QPD_B_PIT_OFFSET -0.145
H1:OMC-ASC_QPD_B_YAW_OFFSET -0.1
IFO has been locked for 3h45. Calibration team has done some measurements and I am currently slowly adjusting OMC alignment (repeat of Koji's alog67994).
Naoki, Patrick, Jenne
On last Sunday, the ETMX camera was restarted and its exposure was changed from 500 to 10000 by the ini file, which caused the camera servo issue. To avoid this, we changed the ETMX/ETMY camera exposure in the ini files. The BS camera exposure in the ini file is good for camera servo.
The ini files for ETMX/ETMY/BS camera are stored in following place.
ETMX: /opt/rtcds/ifo/lho-pylon-camera-config/H1-VID-CAM-ETMX.ini
ETMY: /ligo/cds/lho/h1/camera/H1-VID-CAM27.ini
BS: /ligo/cds/lho/h1/camera/H1-VID-CAM26.ini
The camera exposure we set in the ini file is as follows. The original exposure in the ini file was 10000.
ETMX: 500
ETMY: 3500
BS: 10000
To load the updated ini file, the camera needs to be restarted. We should restart ETMX/ETMY camera when the camera servo is OFF.
Jennie, Jenne, Vicky
As part of a larger suite of optimisations today, the interferometer was taken out of observing and we tried to optimise the H1:LSC-SRCL1_OFFSET to remove the SRC detuning (optical spring).
I took these measurements yesterday, and as a result Jenne agreed that the higher we could push the OFFSET to negative side, the better.
But, that this is not possible for stable operation as it will not give us enough control range before the photodiode readout saturates (at 32000 counts).
I noted yesterday that our largest offset gave us a huge reading on the POP REFL 45 PD ( H1:LSC-POP_A_RF45_I_INMON ) ~ 27 000 cts.
Therefore we will aim to push no further than 22 000 counts for either H1:LSC-POP_A_RF45_I_INMON (in phase PD readout) or H1:LSC-POP_A_RF45_Q_INMON (quadrature phase PD readout).
| SRCL1 OFFSET | DARM Inj Start Time | PCAL > DARM Inj Start Time | DARM Measurement Folder | PCAL > DARM Measurement Folder | Data Folder | Figure Folder |
|---|---|---|---|---|---|---|
| -200 | 1367177285 | 1367177493 | /ligo/gitcommon/noise_recorder/data/darm_noise/202305031227/darm_noise_srcl_src1_-200cts_DARM_offset_tuning-6_50_6_50_Hz_gps_start_1367177285.hdf5 |
/ligo/gitcommon/noise_recorder/data/darm_noise/202305031231/darm_noise_srcl_src1_-200cts_DARM_offset_tuning-6_50_6_50_Hz_gps_start_1367177493.hdf5 |
/ligo/gitcommon/noise_recorder/data/darm_noise/202305031227/ | /ligo/gitcommon/noise_recorder/figures/darm_noise/202305031227/ |
| -165 | 1367178977 | 1367179163 | /ligo/gitcommon/noise_recorder/data/darm_noise/202305031255/darm_noise_srcl_src1_-165cts_DARM_offset_tuning-6_50_6_50_Hz_gps_start_1367178977.hdf5 | /ligo/gitcommon/noise_recorder/data/darm_noise/202305031259/pcaly_srcl_src1_-165cts_DARM_offset_tuning-6_50_6_50_Hz_gps_start_1367179163.hdf5 |
/ligo/gitcommon/noise_recorder/data/darm_noise/202305031255/ | /ligo/gitcommon/noise_recorder/figures/darm_noise/202305031255/ |
Changing the SRCL1 offset to -200 gives us a reading on the photodiode of around -22761 cts for the in phase readout and -5499 cts for the quadrature phase readout.
The first pdf attached shows the results for the -200 count SRCL1 offset, and the second one for the previously used SRCL1 offset value of -165 counts.
It can be seen from the ssensing function plot (last image in both pdfs) that the -200 count measurement appears flatter at low frequency.
After this point I handed over to Vicky to optimise squeezing.
The following measurements were taken after the DARM offset was changed from 20mA to 40mA. And the same set of graphs is attached below for each.
| SRCL1 OFFSET | DARM Inj Start Time | PCAL > DARM Inj Start Time | DARM Measurement Folder | PCAL > DARM Measurement Folder | Data Folder | Figure Folder |
|---|---|---|---|---|---|---|
| -200 | 1367180967 | 1367181204 | /ligo/gitcommon/noise_recorder/data/darm_noise/202305031329/darm_noise_srcl_src1_-200cts_higher_DARM_offset_-6_50_6_50_Hz_gps_start_1367180967.hdf5 |
/ligo/gitcommon/noise_recorder/data/darm_noise/202305031333/pcaly_srcl_src1_-200cts_higher_DARM_offset_-6_50_6_50_Hz_gps_start_1367181204.hdf5 |
/ligo/gitcommon/noise_recorder/data/darm_noise/202305031329/ | /ligo/gitcommon/noise_recorder/figures/darm_noise/202305031329/ |
| -165 | 1367181539 | 1367181751 | /ligo/gitcommon/noise_recorder/data/darm_noise/202305031338/darm_noise_srcl_src1_-165cts_Higher_DARM_offset_-6_50_6_50_Hz_gps_start_1367181539.hdf5 | /ligo/gitcommon/noise_recorder/data/darm_noise/202305031342/pcaly_srcl_src1_-165cts_Higher_DARM_offset_-6_50_6_50_Hz_gps_start_1367181751.hdf5 |
/ligo/gitcommon/noise_recorder/data/darm_noise/202305031338/ | /ligo/gitcommon/noise_recorder/figures/darm_noise/202305031338 |
SRCL1 offset is now -200 counts.
We just had a lockloss after 20.5 hours of lock that appears to be from the ASC, specifically CSOFT P. The oscillation was at about 0.45 Hz and the ring up occurred within the last two minutes of lock. The oscillation appears in other ASC signals, such as INP1, DHARD, and MICH.
I am suprised to see this kind of lockloss so long into the lock, so I am not exactly sure what action to take. I have increased the DSOFT P and CSOFT P gain to give more bandwidth to the loops. I also think we should try to get an OLG of CSOFT P at this higher power (the last OLG was taken at 60W, 67539). OLGs of all arm ASC loops at 430 kW of power would be ideal, but take time.
Accepted in DSOFT, CSOFT sdf, see attached.
Camilla noted another CSOFT P ringup last night. I decided to run another sensing matrix measurement at the REFL port to see if any optical gains or phases changed. I have attached the old sensing matrix measurement at 2W (on which our current sensing matrix is based), and the sensing matrix I took at 76W with the new SRCL offset. (Just a note, I forgot to open the POP beam diverter before taking this measurement, so I have no data of the sensing in POPX at 76W).
As a reminder, our current pitch input matrix is as follows:
| REFL A RF9 | REFL A RF45 | REFL B RF9 | REFL B RF45 | |
| CHARD P | 0.175 | 1.337 | 0.232 | 1.356 |
| INP1 P | 0 | 2.4 | 0 | -2.4 |
| PRC2 P | 0.056 | 0 | 0.034 | 0 |
It appears that the INP1 P signal has flipped sign in REFL WFS A RF45. Assuming that INP1 P and CSOFT P are cross coupled, that is likely the culprit. INP1 P also did ring up in the locklosses. Hopefully, the fix will be as simple as flipping the sign of the INP1 P sensing in A RF45. We will test this on the next lock.
At 2W I changed the sensing matrix for INP1 P slighty to be 1.74 of REFL A 45 and -2.93 of REFL B 45. I obtained these values by inverting the sensing matrix I measured at 76W. This uses the recommended ratio of A and B 45 suggested by the matrix, rescaled to match the gain of the loop. I also checked that the phase of INP1 is correct. I injected CHARD and PRC2 lines and saw that there was minimal coupling of those two loops into the new INP1 signal. This is a relatively small change. If we still have problems in full lock, we probably need to update the CHARD and PRC2 sensing to ensure the subtraction of the INP1 signal is correct. I will update the guardian with the new INP1 values.
Austin, Betsy, Karla, Rahul
We have finished bonding fused sillica Ears to ETM12 using Hydroxide Catalysis Bonding (HCB) technique, please see pictures attached below for reference. The ear-test mass bond layer has few air bubbles within our tolerance (less than 50 sq mm of the total bond area). We can confirm that the position of both the ears on the two flat surface of the mirror are within the required +-0.1mm.
ETM12 (also see galaxy page for details on the optic) is a our spare test mass mirror between the two sites. The details of the ear and test mass mirror is given below,
- Ear s/n 30077403-04 (Q2300015) is bonded to the flat side S3.
- Ear s/n 30077403-05 (Q2300016) is bonded to the flat side S4.
Both the ears were 22.3 grams heavy (measured using a calibrated scale in a clean room).
The fiducial line measurements on the optic was performed at CIT and the details are posted in E2200356_v1.
I have uploaded the latest version V27 of Jig settings calculation on the DCC.
We still need to measure the total weight of the optic and apply First contact to clean the HR side.
This afternoon Karla and I applied First Contact on the HR side of ETM12 to clean the speckles. See the picture attached below. Later we removed it when it was dry. We then inspected the HR surface and it looks cleaner than before.
Today we measured the mass of ETM12 and it was found to be 39606 grams (Jig + ETM12 =46602grams, Jig= 6996grams).
The humidity in the lab was 40% and temperature was 20.2 degree C (measured using ThermPro borrowed from Rick's PCAL stuff).
Jennie, Camilla, Vicky
I used Craig and Camilla's code in /ligo/gitcommon/noise_recorder to measure the DARM OLG and the PCAL to DARM TF in order to look at the SRC detuning over thermalisation and whether we can change it.
To measure the DARM TF use:
darm_noise_injection_caller.py
but change the common_name_prefix to reflect your specific measurement (ie. SRCL1 offset).
pcal_noise_injection_caller.py
but change the common_name_prefix to reflect your specific measurement (ie. SRCL1 offset).
darm_sensing_function_processor.py
make sure the .hdf5 filenames for the pcal and darm measurements are correct, and make sure you have updated date_str to reflect the correct date and label_prefix to reflect the common name label of the two measurements. Also copy across the PCAL measurement to the DARM measurement folder as these will have been saved separately due to different time stamps. Then change date_dir_str to the name of the DARM measurement directory. I just made a new process_sensing_function_measurement() function in the script for each measurement I had to do.
|
SRCL1 OFFSET |
Time Into Lock | DARM Injection Start | PCAL > DARM Injection Start | DARM Measurement hdf5 file | PCAL Measurement hdf5 file | Processed Data Folder (.txt) |
Figures Folder (.pdf) |
| -165 | 3 mins | 1367105753 | 1367105978 | /ligo/gitcommon/noise_recorder/data/darm_noise/202305021635/darm_noise_srcl_-165_src1_p_-6_50_6_50_Hz_gps_start_1367105753.hdf5 | /ligo/gitcommon/noise_recorder/data/darm_noise/202305021639/pcaly_srcl_-165_src1_p_-6_50_6_50_Hz_gps_start_1367105978.hdf5 | /ligo/gitcommon/noise_recorder/data/darm_noise/ | /ligo/gitcommon/noise_recorder/figures/darm_noise/ |
| -165 | 24 mins | 1367107033 | 1367107233 | Processing file 1/1 /ligo/gitcommon/noise_recorder/data/darm_noise/202305021656/darm_noise_srcl_-165_src1_p_-6_50_6_50_Hz_gps_start_1367107033.hdf5 |
/ligo/gitcommon/noise_recorder/data/darm_noise/202305021656/pcaly_srcl_-165_src1_p_-6_50_6_50_Hz_gps_start_1367107233.hdf5
|
Stitched TF file saved at /ligo/gitcommon/noise_recorder/data/darm_noise/202305021656/ |
/ligo/gitcommon/noise_recorder/figures/darm_noise/202305021656/ |
| 0 | 11 mins | 1367112023 | 1367112223 | /ligo/gitcommon/noise_recorder/data/darm_noise/202305021820/darm_noise_srcl_0_src1_p_-6_50_6_50_Hz_gps_start_1367112023.hdf5 |
/ligo/gitcommon/noise_recorder/data/darm_noise/202305021823/pcaly_srcl_0_src1_p_-6_50_6_50_Hz_gps_start_1367112223.hdf5 | /ligo/gitcommon/noise_recorder/data/darm_noise/202305021820/ | /ligo/gitcommon/noise_recorder/figures/darm_noise/202305021820/ |
| +100 | 28 | 1367112998 | 1367113217 | /ligo/gitcommon/noise_recorder/data/darm_noise/202305021836/darm_noise_srcl_+100_src1_p_-6_50_6_50_Hz_gps_start_1367112998.hdf5 | /ligo/gitcommon/noise_recorder/data/darm_noise/202305021839/pcaly_srcl_+100_src1_p_-6_50_6_50_Hz_gps_start_1367113217.hdf5 | /ligo/gitcommon/noise_recorder/data/darm_noise/202305021836/ | /ligo/gitcommon/noise_recorder/figures/darm_noise/202305021836/ |
| 0 | 56 | 1367114970 | 1367115221 | Data file saved at /ligo/gitcommon/noise_recorder/data/darm_noise/202305021909/darm_noise_srcl_0_src1_1hr_in_p_-6_50_6_50_Hz_gps_start_1367114970.hdf5 |
/ligo/gitcommon/noise_recorder/data/darm_noise/202305021913/pcaly_srcl_0_src1_1hr_in_p_-6_50_6_50_Hz_gps_start_1367115221.hdf5 | /ligo/gitcommon/noise_recorder/data/darm_noise/202305021909 | /ligo/gitcommon/noise_recorder/figures/darm_noise/202305021909 |
| -180 | 1.5hrs | 1367116767 | 1367116962 | /ligo/gitcommon/noise_recorder/data/darm_noise/202305021939/darm_noise_srcl_-180_src1_1-5hr_in_p_-6_50_6_50_Hz_gps_start_1367116767.hdf5 | /ligo/gitcommon/noise_recorder/data/darm_noise/202305021942/pcaly_srcl_-180_src1_1-5hr_in_p_-6_50_6_50_Hz_gps_start_1367116962.hdf5 | /ligo/gitcommon/noise_recorder/data/darm_noise/202305021939 | /ligo/gitcommon/noise_recorder/figures/darm_noise/202305021939 |
| -200 | 1hr 50 mins | 1367117947 | 1367118143 | /ligo/gitcommon/noise_recorder/data/darm_noise/202305021958/darm_noise_srcl_-200_src1_1hr48_in_p_-6_50_6_50_Hz_gps_start_1367117947.hdf5 | /ligo/gitcommon/noise_recorder/data/darm_noise/202305022002/pcaly_srcl_-200_src1_1hr48_in_p_-6_50_6_50_Hz_gps_start_1367118143.hdf5 | /ligo/gitcommon/noise_recorder/data/darm_noise/202305021958 | /ligo/gitcommon/noise_recorder/figures/darm_noise/202305021958 |
| -220 | 2 hrs 16 mins into lock | 1367119477 | 1367119682 | /ligo/gitcommon/noise_recorder/data/darm_noise/202305022024/darm_noise_srcl_-220_src1_2hr14_in_p_-6_50_6_50_Hz_gps_start_1367119477.hdf5 | /ligo/gitcommon/noise_recorder/data/darm_noise/202305022027/pcaly_srcl_-220_src1_2hr14_in_p_-6_50_6_50_Hz_gps_start_1367119682.hdf5 | /ligo/gitcommon/noise_recorder/data/darm_noise/202305022024/ | /ligo/gitcommon/noise_recorder/figures/darm_noise/202305022024 |
| -240 | 2 hrs 42 mins into lock | 1367121055 | 1367121265 | /ligo/gitcommon/noise_recorder/data/darm_noise/202305022050/darm_noise_srcl_-240_src1_2hr40_in_p_-6_50_6_50_Hz_gps_start_1367121055.hdf5 | Data file saved at /ligo/gitcommon/noise_recorder/data/darm_noise/202305022054/pcaly_srcl_-240_src1_2hr40_in_p_-6_50_6_50_Hz_gps_start_1367121265.hdf5 |
/ligo/gitcommon/noise_recorder/data/darm_noise/202305022050/ | /ligo/gitcommon/noise_recorder/figures/darm_noise/202305022050 |
| -165 | 3 hrs 3 mins into lock | 1367122300 | 1367122491 | /ligo/gitcommon/noise_recorder/data/darm_noise/202305022111/darm_noise_srcl_-165_src1_3hr3_in_p_-6_50_6_50_Hz_gps_start_1367122300.hdf5 | /ligo/gitcommon/noise_recorder/data/darm_noise/202305022114/pcaly_srcl_-165_src1_3hr3_in_p_-6_50_6_50_Hz_gps_start_1367122491.hdf5 | /ligo/gitcommon/noise_recorder/data/darm_noise/202305022111 | /ligo/gitcommon/noise_recorder/figures/darm_noise/ |
Posting this now to show measurements taken. Will comment tomorrow with all graphs on one plot.
Attached to the report are the compiled plots from both measurements, which are in the data folders listed in the table.
Based on this test, and more measurements of the sensing function today, we have determined that -200 is a better SRCL offset. We don't want to increase much beyond this, to leave enough ADC range on LSC POP 45. I have changed the SRCL offset in the guardian (lownoise length control).
J. Kissel As a result of our improved sensitivity below 30 Hz since O3, and recently exposed deleterious bi-linear coupling between these calibration lines and excess QUAD reaction chain motion at 3.4 Hz (LHO:68003), I've reduced the amplitude of the 15-17 Hz calibration lines. Channel that defines the amplitude Former Now Reduction Factor H1:SUS-ETMX_L1_CAL_LINE_CLKGAIN 75.0 20.0 3.75x H1:SUS-ETMX_L2_CAL_LINE_CLKGAIN 120.0 35.0 3.42x H1:SUS-ETMX_L3_CAL_LINE_CLKGAIN 1.0 0.3 3.33x H1:CAL-PCALY_PCALOSC1_OSC_SINGAIN 1000.0 250.0 4.00x The metric I used to judge by how much I could decrease the amplitude is the front-end computed coherence-based uncertainty in the transfer function between each line excitation and DARM_ERR. Prior to this change, the uncertainty had been hovering around 0.001 or below, i.e. 0.1% or below. We don't need *that* amazing of uncertainty. Recall, when we set the line heights during O3, we were shooting for a compromise between "the uncertainty on the time dependent correction factors derived from the calibration lines should be around 0.2% such that their uncertainty is negligible w.r.t. the uncertainty in the rest of the full response function systematic error budget" and "don't drive any harder than you need to; these loud lines cause bilinear coupling that degrades the sensitivity." The first attachment shows a trend of the coherence, individual line uncertainty, TDCF uncertainty, and calibration line amplitude during the tuning. Note that as I began to close out my tuning, we began experiencing a mild earthquake, which is also useful information. Indeed, during that earthquake, the uncertainty didn't really get worse that 0.4%, which is fine. Also, as a result of recent review of the frequencies of the new PCALX calibration lines which constantly monitor the systematic error (LHO:68139), I've changed the frequency of the 56.39 Hz line to 53.67 Hz, squarely in the middle of the non-vetoed region between [51.59, 54.69) Hz. All of these changes have been in place since Mar 30 2023 18:00:00 UTC (GPS 1364234418, Mar 30 2023 11:00:00 PDT). Here's the new list of calibration lines: Freq (Hz) Actuator Purpose Channel that defines Freq Since O3 15.6 ETMX UIM (L1) SUS \kappa_UIM excitation H1:SUS-ETMY_L1_CAL_LINE_FREQ No Frequency Change, Reduced Amplitude 16.4 ETMX PUM (L2) SUS \kappa_PUM excitation H1:SUS-ETMY_L2_CAL_LINE_FREQ No Frequency Change, Reduced Amplitude 17.1 PCALY actuator kappa reference H1:CAL-PCALY_PCALOSC1_OSC_FREQ No Frequency Change, Reduced Amplitude 17.6 ETMX TST (L3) SUS \kappa_TST excitation H1:SUS-ETMY_L3_CAL_LINE_FREQ No Frequency Change, Reduced Amplitude 33.43 PCALX Systematic error lines H1:CAL-PCALX_PCALOSC4_OSC_FREQ New since Jul 2022 (LHO:64214, LHO:66268) 53.67 | | H1:CAL-PCALX_PCALOSC5_OSC_FREQ Updated as of this aLOG 77.73 | | H1:CAL-PCALX_PCALOSC6_OSC_FREQ New since Jul 2022 (LHO:64214, LHO:66268) 102.13 | | H1:CAL-PCALX_PCALOSC7_OSC_FREQ | 283.91 V V H1:CAL-PCALX_PCALOSC8_OSC_FREQ V 410.2 PCALX PCALXY comparison H1:CAL-PCALX_PCALOSC2_OSC_FREQ New since Jan 2023 (LHO:66967) 410.3 PCALY f_cc and kappa_C H1:CAL-PCALY_PCALOSC2_OSC_FREQ No Change 1083.7 PCALY f_cc and kappa_C monitor H1:CAL-PCALY_PCALOSC3_OSC_FREQ No Change n*500+1.3 PCALX Systematic error lines H1:CAL-PCALX_PCALOSC1_OSC_FREQ No Change (n=[2,3,4,5,6,7,8])
E. Capote, J. Kissel
We discovered today that the ETMX SUS calibration lines were at their old loud amplitudes. Tracing down the issue, we found, and were reminded that, the ISC_LOCK guardian forces these values to be some amplitude upon entering the NOMINAL_LOW_NOISE state. It's a lovely challenge to find, but the values at which they get set to happens in
/opt/rtcds/userapps/release/isc/h1/guardian/ISC_GEN_STATES.py
lines 260 thjough 263,
for g in ['CLK','SIN','COS']:
ezca['SUS-ETMX_L3_CAL_LINE_%sGAIN'%(g)] = [value]
ezca['SUS-ETMX_L2_CAL_LINE_%sGAIN'%(g)] = [value]
ezca['SUS-ETMX_L1_CAL_LINE_%sGAIN'%(g)] = [value]
These have now been changed to be the new lower amplitude values
for g in ['CLK','SIN','COS']:
ezca['SUS-ETMX_L3_CAL_LINE_%sGAIN'%(g)] = 0.3
ezca['SUS-ETMX_L2_CAL_LINE_%sGAIN'%(g)] = 35
ezca['SUS-ETMX_L1_CAL_LINE_%sGAIN'%(g)] = 20
Sorry team.
While watching the locking, I noted that the L3 line was higher than the others for a time. ISC_LOCK, in Transition_from_etmx turns that line off, then back on later. When it turns it back on, it comes on at the old value of 1.0. Then, as Jeff fixed the other day, in NomLowNoise it gets turned down to the new nominal value of 0.3.
I have set the val in Lownoise_esd_etmx to the new value of 0.3. The better thing that someone (from Cal?) should do is move these values to lscparams so that one doesn't have to ctrl-F to find them all.
Another thing that I have just left alone for now, but also needs fixing: In the main part of Prep_for_locking, all 3 sus cal lines are turned off with a comment indicating that they are supposed to be off for the whole locking sequence. Then in the run state, they are all turned back on. This is additional to the L3 line being turned off then back on later. This logic should be cleaned up (although it's not urgent, since clearly we're able to lock nicely even with this spaghetti code).
The above list is now out of date as of 2023-05-03. See LHO:69303 for the latest list.