Ran a BB measurement followed by Simulines:

    - bb measurements: 1382296233 - 1382296559 (2023-10-25 19:10:15 - 19:15:41)
    - simulines measurements: 1382296585 - 1382297917 (2023-10-25 19:16:09 - 19:38:19)

Output files:

BB:
/ligo/groups/cal/H1/measurements/PCALY2DARM_BB/PCALY2DARM_BB_20231025T191015Z.xml

Simulines:
/ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20231025T191609Z.hdf5
/ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20231025T191609Z.hdf5
/ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20231025T191609Z.hdf5
/ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20231025T191609Z.hdf5
/ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20231025T191609Z.hdf5

Today we tested the effect on DARM of additional resonant gains at 2.8 and 3.4 Hz, as described in 73698.

DARM RMS was reduced as expected from 1.6e-9 to 1.2e-9.

Looking at DARM spectrograms, there is no evident difference in the level of non-stationary noise.

Comapring the DARM PSD during two times, there seems to be a small improvement, but that might be a fluctuation.

In summary: the resonant gains improve the DARM RMS, but we don't see a clear improvement in noise; they don't hurt though 

In a follow-up to what TJ did yesterday(73685), I alternated the CARM gains (H1:LSC-REFL_SERVO_IN{1, 2}GAIN) between 6 (what it was nominally at) and 12 every two minutes.

Times when we were at each gain setting (in UTC):

   12: 20:08:17 - 20:10:17
    6: 20:10:29 - 20:12:29
   12: 20:12:44 - 20:14:44
    6: 20:14:58 - 20:16:58

Attached is an ndscope over this timeframe looking at the CARM gain and SQZ BLRMS channels (same as the channels that TJ and Camilla had been looking at yesterday(73682)).

Here is a list of the _known_ corrections to the systematic error that need to be accounted for when regenerating the O4a uncertainty budgets.



Issue
Start
End
Status

3.2 kHz ESD Driver Pole in CAL-CS Model (LHO:72043)
2023/04/26 (ER15)
2023/08/08 00:15 UTC
Rough fit exists. LHO:71787

 
Spoiled TDCFs due to noise in Kappa_UIM (LHO:71790, LHO:71846)
 
2023/07/20
 
2023/08/03
 
In progress. Pending correction file.
 

 
Thermalization effects seen in sensing function at 75W
 
ER15
 
2023/06/21
 
In progress by Cal group.
 
 
Thermalization effects seen in sensing function at 60W
 
2023/06/21
 
Now
 
In progress by Cal group.
 


There may be other corrections that are needed by additional unmodeled effects including OM2 hot/cold, drifting Kappa_T, and Pcal error that hasn't been accounted for (if any).

Useful reference: Record of Real-time Calibration Pipeline Parameter Changes: O4 (and ER15) -- H1 (DCC T2300297)

Observing at 157Mpc and Locked for 16.5hours.

We're right about to start some Commissioning for the next four hours.

I measured the optical modes moving in the OMC-DCPD-SUM signal where, with A LOT of averaging (when the optical modes are pseudo stable), the optical high order mode (HOM) spacing can be observed as its changing through a lock stretch.
I look at the spectrum visible in the 5.2kHz range; and the spectrum visible in the 80.3 kHz range.
There are 2 sets of optical modes easily visible. Currently I assume the one I need to worry about is the higher one that is substantially closer to 80297 kHz of the PI.

The 2 two times plotted correspond to:

• [Red] 14 Hours locking as of end of Tuesday Maintenance
• [Black] 28 locking as of the end of the lock just before Tuesday Maintenance

This should, in principle, correspond to 2*FSRx + HOM_spacing, but there is a slight discrepancy at both LLO and LHO (roughly 4 Hz by my estimates), which may be related to the small Gouy phase impact of the PRC, but I'm not sure exactly how.

For these measurements, the difference in frequency is 75047.61 Hz
For completeness,  2*FSRx = 75051.87 Hz (X-arm length is 3994.4704 m)

This is relevant to being able to track how far away we are in terms of optical mode spacing, from the mechanical mode Frequency in a DQ channel for post processing.

Wed Oct 25 10:17:16 2023 INFO: Fill completed in 17min 11secs

Jordan confirmed a good fill curbside. Note TCs only just cleared the trip level, outside temp was 45F at time of fill.

A follow up on the two new IFO range channels which were added to the DMT2EPICS_IOC and the DAQ yesterday.

Attachment shows a new MEDM I created which shows all four range channels, along with their GPS. This MEDM can be opened from SITEMAP -> OPS -> H1 IFO RANGES.

The ndscope second-trend plot shows that CAL has the largest range, HOFT the lowest, CLEAN and NOLINES are inbetween and are phase shifted versions of the same channel.

TITLE: 10/25 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 159Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 10mph Gusts, 7mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.20 μm/s
QUICK SUMMARY:

In Observing and Locked for 12.5 hours.

I ran a set of BruCos for several ASC and ISC signals, to look for what is contributing to the low frequency RMS of those loops. Here are the links:

DARM
SRCL
PRCL
MICH

DHARD_P
DHARD_Y
CHARD_P
CHARD_Y
DSOFT_P
DSOFT_Y
CSOFT_P
CSOFT_Y

TITLE: 10/25 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 163Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY:
Since the mid shift report not much happened, pretty quiet night.
The Violins are heading in the right direction and have come down a lot, since the legend spire spike at ~500hz  turned up at the begining of the lock.

Ey and EX temps have settled back down to a reasonable and stable temp.
H0:FMC-EY_VEA_AVTEMP_DEGF = 64.47 currently. 

LOG:

Took ISC_LOCK to INITIAL_ALINMENT and found almost no light on both arms.
I then Exited INITIAL_ALIGNMENT, and went to Manual Green Arms.
Set Increase flashes on Y and Manualed X all the way up to 80%
Increase flashes couldn't get above 55ish% on Yarm so I then touched up Y arm and got it to 1.
Sent ISC_LOCK back to I.A.
Once Initial Alignment completed the lock went well up until ISC_LOCK got to  
PREP_DC_READOUT_TRANSITION where we got stuck due to a change in the OMC settings which were resolved by Vlad and Jenne. See comment 73720 https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=73718

We continued up to POWER_10W and caught a lockloss.
https://ldas-jobs.ligo-wa.caltech.edu/~lockloss/index.cgi?event=1382229688
picture taken before 17:45

Relocking had another lockloss at Find IR.

01:10 UTC EY temp is still high but the slope of the temp trend seems to be trying to turn around.
H0:FMC-EY_VEA_AVTEMP_DEGF = 65.50
2:26 UTc Vicky Gets back to us and says that the SQZr Looks good.

Used the following command to mananged the blends under SEI_CONF
cdsutils write H1:GRD-ISI_ITMY_ST1_BLND_MANAGER SEI_CONF
cdsutils write H1:GRD-ISI_ETMX_ST1_BLND_MANAGER SEI_CONF

Finally got into NOMINAL_LOW_NOISE at 2:34 UTC and started sorting through SDF Diffs, then went to NLN_CAL_MEAS to run the following command at 2:42 UTC :
hwinj detchar safety --run
and back to NOMINAL_LOW_NOISE And OBSERVING at 2:51 UTC

Followed the instruction found here:
https://docs.google.com/document/d/1AXIOEC6XkT9Mp47Ny4aEZu0ucMTprHV0lA-Bu1KJnvk/edit
and ran the following command @ 2:42 UTC and got the following output:


anthony.sanchez@cdsws13: hwinj detchar safety --run
ifo: H1
waveform root: /ligo/groups/cal/H1/hwinj
config file: /ligo/groups/cal/H1/hwinj/hwinj.yaml
GraceDB url: https://gracedb-playground.ligo.org/api/
GraceDB group: Test
GraceDB pipeline: HardwareInjection
excitation channel: H1:CAL-INJ_TRANSIENT_EXC
injection group: detchar
injection name: safety
reading waveform file...
injection waveform file: /ligo/groups/cal/H1/hwinj/detchar/detchar-hwinj-schedule_LIGO-T1900555-PROPOSED_H1_INJECTIONS.txt
injection waveform sample rate: 16384
injection waveform length: 390.0 seconds
reading log file...
injection log file: /ligo/groups/cal/H1/hwinj/detchar/detchar-hwinj-schedule_LIGO-T1900555-PROPOSED_H1_INJECTIONS_log.csv
injection log entries: 75
initiating ligo_proxy_init for GraceDB access...
injection start GPS: 1382236977.6
H1:CAL-INJ_TINJ_TYPE => 3
H1:CAL-INJ_TINJ_TYPE => 3
H1:CAL-INJ_TRANSIENT_SW2 => 1024
H1:CAL-INJ_TRANSIENT_SW2 => 1024
H1::CAL-INJ_TRANSIENT => ON: OUTPUT
H1::CAL-INJ_TRANSIENT => ON: OUTPUT
=== EXECUTING AWG INJECTION ===
this will wait until the injection is nearly complete...
ndshosts: h1daqnds1 and h1daqnds0
getting host by name: h1daqnds1
found host
testpoint_client 1.0.0
found version 4 or newer test point interface
H1:CAL-INJ_TRANSIENT_SW2 => 1024
H1:CAL-INJ_TRANSIENT_SW2 => 1024
H1::CAL-INJ_TRANSIENT => OFF: OUTPUT
H1::CAL-INJ_TRANSIENT => OFF: OUTPUT
H1:CAL-INJ_TINJ_TYPE => 0
H1:CAL-INJ_TINJ_TYPE => 0
=== INJECTION COMPLETE ===
creating injection events in GraceDB...
creating event: Detchar_HW_INJ_H1_1382236987.6.json
creating event: Detchar_HW_INJ_H1_1382236992.6.json
creating event: Detchar_HW_INJ_H1_1382236997.6.json
creating event: Detchar_HW_INJ_H1_1382237002.6.json
creating event: Detchar_HW_INJ_H1_1382237007.6.json
creating event: Detchar_HW_INJ_H1_1382237012.6.json
creating event: Detchar_HW_INJ_H1_1382237017.6.json
creating event: Detchar_HW_INJ_H1_1382237022.6.json
creating event: Detchar_HW_INJ_H1_1382237027.6.json
creating event: Detchar_HW_INJ_H1_1382237032.6.json
creating event: Detchar_HW_INJ_H1_1382237037.6.json
creating event: Detchar_HW_INJ_H1_1382237042.6.json
creating event: Detchar_HW_INJ_H1_1382237047.6.json
creating event: Detchar_HW_INJ_H1_1382237052.6.json
creating event: Detchar_HW_INJ_H1_1382237057.6.json
creating event: Detchar_HW_INJ_H1_1382237062.6.json
creating event: Detchar_HW_INJ_H1_1382237067.6.json
creating event: Detchar_HW_INJ_H1_1382237072.6.json
creating event: Detchar_HW_INJ_H1_1382237077.6.json
creating event: Detchar_HW_INJ_H1_1382237082.6.json
creating event: Detchar_HW_INJ_H1_1382237087.6.json
creating event: Detchar_HW_INJ_H1_1382237092.6.json
creating event: Detchar_HW_INJ_H1_1382237097.6.json
creating event: Detchar_HW_INJ_H1_1382237102.6.json
creating event: Detchar_HW_INJ_H1_1382237107.6.json
creating event: Detchar_HW_INJ_H1_1382237112.6.json
creating event: Detchar_HW_INJ_H1_1382237117.6.json
creating event: Detchar_HW_INJ_H1_1382237122.6.json
creating event: Detchar_HW_INJ_H1_1382237127.6.json
creating event: Detchar_HW_INJ_H1_1382237132.6.json
creating event: Detchar_HW_INJ_H1_1382237137.6.json
creating event: Detchar_HW_INJ_H1_1382237142.6.json
creating event: Detchar_HW_INJ_H1_1382237147.6.json
creating event: Detchar_HW_INJ_H1_1382237152.6.json
creating event: Detchar_HW_INJ_H1_1382237157.6.json
creating event: Detchar_HW_INJ_H1_1382237162.6.json
creating event: Detchar_HW_INJ_H1_1382237167.6.json
creating event: Detchar_HW_INJ_H1_1382237172.6.json
creating event: Detchar_HW_INJ_H1_1382237177.6.json
creating event: Detchar_HW_INJ_H1_1382237182.6.json
creating event: Detchar_HW_INJ_H1_1382237187.6.json
creating event: Detchar_HW_INJ_H1_1382237192.6.json
creating event: Detchar_HW_INJ_H1_1382237197.6.json
creating event: Detchar_HW_INJ_H1_1382237202.6.json
creating event: Detchar_HW_INJ_H1_1382237207.6.json
creating event: Detchar_HW_INJ_H1_1382237212.6.json
creating event: Detchar_HW_INJ_H1_1382237217.6.json
creating event: Detchar_HW_INJ_H1_1382237222.6.json
creating event: Detchar_HW_INJ_H1_1382237227.6.json
creating event: Detchar_HW_INJ_H1_1382237232.6.json
creating event: Detchar_HW_INJ_H1_1382237237.6.json
creating event: Detchar_HW_INJ_H1_1382237242.6.json
creating event: Detchar_HW_INJ_H1_1382237247.6.json
creating event: Detchar_HW_INJ_H1_1382237252.6.json
creating event: Detchar_HW_INJ_H1_1382237257.6.json
creating event: Detchar_HW_INJ_H1_1382237262.6.json
creating event: Detchar_HW_INJ_H1_1382237267.6.json
creating event: Detchar_HW_INJ_H1_1382237272.6.json
creating event: Detchar_HW_INJ_H1_1382237277.6.json
creating event: Detchar_HW_INJ_H1_1382237282.6.json
creating event: Detchar_HW_INJ_H1_1382237287.6.json
creating event: Detchar_HW_INJ_H1_1382237292.6.json
creating event: Detchar_HW_INJ_H1_1382237297.6.json
creating event: Detchar_HW_INJ_H1_1382237302.6.json
creating event: Detchar_HW_INJ_H1_1382237307.6.json
creating event: Detchar_HW_INJ_H1_1382237312.6.json
creating event: Detchar_HW_INJ_H1_1382237317.6.json
creating event: Detchar_HW_INJ_H1_1382237322.6.json
creating event: Detchar_HW_INJ_H1_1382237327.6.json
creating event: Detchar_HW_INJ_H1_1382237332.6.json
creating event: Detchar_HW_INJ_H1_1382237337.6.json
creating event: Detchar_HW_INJ_H1_1382237342.6.json
creating event: Detchar_HW_INJ_H1_1382237347.6.json
creating event: Detchar_HW_INJ_H1_1382237352.6.json
creating event: Detchar_HW_INJ_H1_1382237357.6.json
uploads complete.
anthony.sanchez@cdsws13:

TJ, Camilla. WP #11483.

Uninstalled the "new" S&K HWS laser (TSOP M1900163) from the ALS table, stored it in it's case in the LVEA TCS cabinets. Removed fiber and fiber launcher.  This was installed in 62089.

Reinstalled the "old"  diode source M530F2 (eye safe). Using M92L02 20um multi-mode fiber and original D1800125 fiber launcher. Reduced length of the tube of D1800125 fiber launcher as we thought we need to bring the F=125mm lens closer to the launcher.  

Realigned the path to get a retro-reflected beam off ETMX and checked this by mis-aligning ETMX. Took new references on EX, and ITMs at 00:08UTC.

Photos before and after attached. Decision made to swap back to original source in T2300336. Will update FRS 14310 with Aidan. 

Summary - Camilla and I removed the running TCSX chiller and replaced it with a new ThermoFlex 1400 SN#1153600201231003.

We've been having some issues with the TCSX laser relocking itself during Observing (ex: alog73331). This seems to be due to inconsistent water temperature from two of our three chilers, causing the temperature of the laser to shift slightly. We've swapped out SN#0110193301120813 for the new chiller and sent off the spare chiller for service. We input the settings from the CO2Y chiller and it the new chiller fired right up and seems to be outputing correct flow and pressure. We'll keep an eye on it the next few days.

Summary - Jim fixed it with a little shake.

We cycled through the various ISI state controls. The 1Hz line would start appearing when stage 1 is isolated. In any states below this point, we can clearly see the difference in the 'sensor response' of the local H1 L4C wrt T240 or CPS. While Jim was taking an olg measurement, the ISI tripped, which seem to have changed the response of the H1 L4C back to the nominal response, see the first pdf attached, showing the L4C/T240 local TF, before (p1) vs after (p2) the ISI trip. The 2nd pdf attached shows the ISI spectra in the isolated state before (p1) vs after (p2) the shake, no other changes.
We've had sticky L4Cs in the past and solved it in a similar way (see alog 38939), but the symptoms were much more obvious than a slight change in resonant frequency as we are seeing here.

Timeline of tests :

16:04 - 16:12 UTC ETMX ISI/HEPI OFFLINE
16:15 - 16:30 UTC HEPI ON / ETMX ISI OFFLINE
16:31 - 16:37 UTC HEPI ON /ETMX DAMPED
16:38 - 16:44 UTC HEPI ON / ETMX ST1 ISO - We can see the giant ~1Hz line
16:45 - 16:48 UTC HEPI ON/ ETMX ST1 ISO - H1 L4C gain 0.5 - sym filter off - ~1Hz line goes down
16:50 - 16:52 UTC HEPION/ETMX ST1/ST2 ISO - H1 L4C gain 0.5 - sym filter off
16:55 - 17:07 UTC Back to nominal
17:25 - Jim changing stage 1 Rz blend to noL4C
17:38 - Jim changing stage 1 Y blend to noL4C
18:00 - Jim measuring Rz olgf

Ref alog 73625

I prepared a new filter module with resonant gains at 2.8 Hz and 3.4 Hz. This can be tried tomorrow (on during some commissioning time) to reduce the DARM RMS and see if it helps the non-stationary noise.

The new FM is loaded into DARM2 FM1 "RG2.8-3.4". It is not engaged now.

For future reference, here are the FMs that are used during lock acquisition:

DARM1: FM1 FM2 FM3 FM4 FM7 FM9 FM10

DARM2: FM3 FM4 FM5 FM6 FM7 FM8 FM9 FM10

leaving DARM1 FM5,6,8 and DARM2 FM1,2 unused

Naoki, Sheila

Summary:  We have repeated the test from 73400, with our higher level of squeezing after the crystal move, and with the ASC off for squeezing angles other than squeezing.  This seems to generally reproduce the results in that alog, convincing us that most of the rotation we are seeing is from the mode matching change not an alignment shift.  

We have saved references in userapps/sqz/h1/Templates/dtt/DARM/PSAMS_tests_Oct202023.xml.  This is a copy of PSAMS_tests_Oct112023.xml, with the references saved there and shown in alog 73400  The times written below are minimum times, for many of these references there is actually more time.  

times (PSAMs 200/200):

• no sqz 10/20/2023 20:19-20:32 UTC (large glitch at around 20:22, starting at 20:23) (reference 10)
• after some ASC troubles and temperature adjustment, resetting AS42, start FDS time at 21:19:33 300 seconds demod 162.95 (ref 11)
• turned off AS42, and FC ASC, anti sqz 21:33:34 300 seconds demod 228.64 (ref 12)
• + mid sqz 21:43:16 300 seconds demod 193.56 (ref 13) (until 21:50:50, big glitch near end of time)
• - mid sqz 21:53:17-21:59:57 300 seconds demod 30.48 (ref 14)

set sqz angle back to sqz, turned AS42 and FC ASC, set PSAMs to 120/120 with 30 second ramp

times (PSAMS 120/120):

• sqz 22:07:33 300 seconds demod 162.95 (ref 15)  Note: while Naoki was tuning the sqz angle here, he found that for a few degrees different demod phase the high frequency squeezing could be better than what is shown here, but the 400Hz squeezing was worse.  Here we are just using the same demod phase as for 200/200 psams, but this isn't the best high frequency demod phase.  
• turned off ASC for AS 42 and FC
• asqz 22:17:33-22:23:30 360 seconds demod 228.64 (ref 16) (a big glitch around 22:21:30) (ref 16)
• + mid sqz 22:24:27 300 seconds demod angle 193.56 (ref 17)
• - mid sqz 22:33:33 300 seconds demod angle 30.48 (ref 18)

Naoki, Vicky, Sheila, Camilla. WP 11470.

OPO Crystal Move

Following last time we moved the OPO crystal 65684, we used the wincam dell laptop and gray E-870 PI shift driver box (stored in LVEA SQZ cabinet) and the OPO crystal cable Daniel attached the the +X HAM7 flange. Adjusted OPO temperature from 31.684 degC to 31.804 degC for co-resonance while scanning rather than stationary. 

To scan the OPO PZT fast enough, we used external function generator and Thorlabs driver at the racks for the OPO PZT to scan over more than 1 FSR (around 1-9V scan). 

We were able to move the OPO crytal over its full range and found 6 spots with red/green co-resonance, attached pdf shows the places we moved. LLO found 10-13 potions which is surprisingly more than us, 73502. 

Through O4 we've been using the 2nd posltion from the right, but left the crystal on the 2nd spot from the Left. 

Photos attached of the PZT scan (yellow trace), OPO IR trans light measured on HD PDA (pink trace), Green trans from CLF path (green trace). The green alignment looked bad at all spots. This could be from misalignment of OPO path or HOMs present in fiber. When we next go into HAM7 we can look at this. 

NLG Measurement

Turn down green pump power with SQZT0 wave plate to 4mW in to stop the OPO lazing. We measured NLG of 14 (OPO_IR_PD_LF_OUTPUT amplified / unamplifed = 0.0136/0.00092). This reduced to NLG of 12 over a few minutes. 

Homodyne Measurement 

We balanced the HD by reducing the seed power and realigned to maximize visibility. At start of measurement visibly was 14 and at the end it NLG was 12. Vicky, Sheila Naoki took Homodyne measurements which were hard with NLG drifting. Measured 4.5dB whihc is less than the 6dB measured last week 73376. But we think we could have offloaded the ASC alignments incorrectly to not see good SQZ on the HD.  

• PDA 98.6% Visibility (Min 10.3mV Max 1.48V) = 2.75% loss (1- Vis^2)
• PDB 98.0% Visibility (Min 14.8mV Max 1.5V) = 3.87% loss

SQZ in IFO

Ended with NLG of 13.5 into IFO. Amplified power of 0.0196, unamplified seed of 0.00149. Though this may be changing quickly. 

Took some no sqz data while TJ tested updates to the Observing with No SQZ wiki. Accepted sdfs to go back into observing. Vicky adjusted OPO tempurature and had to adjust the SQZ angle from 142 to 163, squeezing looks better 4dB+ but we expect the angle and OPO tempurature may need to be adjusted over the next hours...