SUMMARY:  Back To OBSERVING, but got here after going in a few circles.

H1 had a lockloss before the shift, but when I arrived H1 was at NLN, BUT SQZ had issues. 

I opened up the SQZ Overview screen and could see that the SQZ_SHG guardian node was bonkos (so I had this "all node" up the whole time...it was crazy because it was frantically moving through states to get LOCKED, but could not), BUT also I saw.....

1)  DIAG_MAIN

DIAG_MAIN had notifications flashing which said:  "ISS Pump is off. See alog 70050."  So, this is where I immediately switched focus.

2)  Alog70050:  "What To Do If The SQZ ISS Saturates"

Immediately followed the instructions from alog70050 which were pretty straightforward.  Remember:  H1's not Observing, so I jumped on the alog instructions and wanted to get back to Observing ASAP.)  I took the opo_grTrans_setpoint_uW from 80 to 50, and tried to get SQZ back to FDS, but no go (SQZ Manager stuck....and SQZ_SHG still bonkos!).

At this point, I saw that there were several other sub-entries with updated instructions and notes.  So I went through them and took opo_grTrans_setpoint_uW to 60 (no FDS + SQZ_SHG still crazy), and finally set opo_grTrans_setpoint_uW = 75 (but still no FDS + SQZ_SHG still crazy).

At this point, I'm assuming DIAG_SDF sent me on a wild goose chase.  Soooooo, I focused on the erratic SQZ_SHG......

3)  Alog search:  "SQZ_SHG"   --->   H1:SQZ-SHG_TEC_SETTEMP Taken to 33.9

This did the trick!  And this search took me to early Feb2025 alogs from (1) RyanS alog82599 which sounded what I had and then (2) Ibrahim's alog82581 which laid out instructions for what to do for adjusting the SHG TEC Set Temperature (went from 33.7 to 33.9; see attachment #1).  AND---during these adjustments the infamous SQZ_SHG finally LOCKED!!

After this it was easy and straightforward taking the SQZ Manager to FDS and get H1 back to Observing.

NOTE:  I wanted to see the last time this Set Temperature was adjusted and it was Feb 17, 2025.  Doing an alog search on just "SHG" + tag: SQZ took me to when it was last adjusted:  By ME!  During an OWL wake-up call, I adjusted this set point from ~35.1 to 33.7 on 02172025 at 1521utc/72amPST (see attachment #2).

The only SDF to ACCEPT was the H1:SQZ-SHG_TEC_SETTEMP  = 33.7 (see attachment #3).  BUT:  Remember other changes I made (when I erroneously thought I had to adjust the OPO TEC TEMP which are not in SDF:

• opo_grTrans_setpoint_uW = 75  (was 80)
• H1:SQZ-OPO_TEC_SETTEMP = 30.937  (was 30.941)

Hindsight is 20/20, but if I addressed the "bonkos SQZ_SHG" via instructions from an alog search first, I would have saved some time!  :)

TITLE: 03/07 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 4mph Gusts, 2mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.22 μm/s
QUICK SUMMARY:

H1's just made it to NLN .after a 7.75hr lock overnight (lockloss), but has a SQZ ISS Pump Off issue.  microseism are low and winds are as well. 

TITLE: 03/07 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR:  ->Ryan S.<-
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 14mph Gusts, 8mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.20 μm/s
SHIFT SUMMARY:
H1 was locked for 7 Hours and 17 minutes.
Until a sudden and Unknown lockloss struck at 5:24 UTC, Screenshots of lockloss ndscopes attached.

I took the last half hour of my shift to run an Initial_alignment before the start of Ryans Shift.
H1 is currently just past at CARM_TO_TR.

LOG:                                                                                                                                                                                                                                                                                                                                                         

BRS Dift Trends --Monthly FAMIS 26452

BRSs are not trending beyond their red thresh holds.

I assembled the 45MHz WFS unit in the optics lab. Assembly drawing: D1102002.

BOM:

• 1x Pre-assembled WFS body (D1102004 s/n016 Main Body, sealed & scribed as "S1300637" according to Corey's email)
• 1x Alumina spacer (D1102007)
• 1x Baseplate (D1102003)
• 1x Q3000 QPD
• 1x QPD hood (D1102006)
• 2x SHCS 1/4-20 X .75" 18-8 VENTED for the baseplate
• 2x 1/4" PEEK washer (D1102010) for the baseplate
• 4x SHCS 4-40 X 3/16" 18-8 Vented for the QPD hood (spec is BSHCS but SHCS works fine)

I confirmed that the baseplate and the WFS  body are electrically isolated from each other.

There were many black spots on the WFS body (2nd pic) as well as the aluminum foil used for wrapping (3rd pic). It seems that this is a result of rubbing of aluminum against aluminum. I cannot wipe it off but this should be aluminum powder and not some organic material.

QPD orientation is such that the tab on the can is at 1:30 o'clock position seen from the  front (4th pic). You cannot tell it from the picture but there's a hole punched to the side of the can.

Clean SMP - dirty SMA cables are in a bag inside the other clean room in the optics lab. DB25 interface cable is being made (or was made?) by Fil.

TITLE: 03/07 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 144Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 21mph Gusts, 16mph 3min avg
    Primary useism: 0.06 μm/s
    Secondary useism: 0.25 μm/s
QUICK SUMMARY:

H1 has been locked and Observing for 2 hours and 23 minutes.
All systems are running well, though the range seems a bit low.

TITLE: 03/07 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 146Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Currently Observing at 147 Mpc and have been Locked for 2.5 hours. Relocking after the lockloss during the calibration measurements was fully automatic and went relatively smoothly.
LOG:

20:35UTC Lockloss during calibration measurements

22:07 NOMINAL_LOW_NOISE
22:10 Observing

23:25 Three military jet planes flew overhead at a very low altitude (tagging Detchar)                                                                                                                                                                                                                                

I found evidence of possible scattered light while looking at some data from a lock yesterday. Attached is a whitened spectrogram of 30 minutes of data starting at GPS 1425273749. It looks like the peaks are around 28, 38, and 48 Hz, but they are broad and it's hard to tell the exact frequency and spacing. Sheila thinks this may have appeared after Tuesday maintenance. Tagging detchar request so some tests can be run to help us track down the source!

I ran each chilled water pump at the Mid Stations in order to exercise their seals and bearings since these pumps are currently off for the season. This will cause the temperature trending of the loop water to show an decrease for a brief period. The Mid Stations chillers are currently shut down and will remain off until late Spring. 

F. Clara, D. Barker, J. Kissel, O. Patane, D. Sigg
ECR E1700228

(0) Confirm the analog cabling plan implicit in D0902810-v10 -- see LHO:83168.

(1) Move PR3 optical lever from h1sush2b over to h1sush2a to make room for PM1 on h1sush2b,
    WP 12370
    Front-end Model Prep work: LHO:83194

(2) Add new POP WFS controls path to ASC front-end model for driving PM1,
    WP: 12374
    Front-end Model Prep work: LHO:83195

(3) Add PM1 as an "HSSS_FF_MASTER.mdl" into the h1sushtts.mdl, following the other HTTS in HAM1, RM1 and RM2
    WP: 12375
    Front-end Model Prep work: LHO:83196 and LHO:83211

Note, as Oli mentions in LHO:83196, we'll likely need one more model change to h1sushtts.mdl and the future h1isiham1.mdl model to send up some fresh-and-better ISI feed-forward signals to the RMs and PM1, but this will come in due time.

The goal is to execute all of this prep work and work-permits during upcoming maintenance period, Mar 11 2025 (with a back-up date of Mar 18 2025 if needed).

J. Kissel
ECR E1700228

One last thing in prep for PM1 from the simulink model perspective: in addition to the "controls" model that Oli and I prepped yesterday (LHO:83196, LHO:83194), we need to add the HAM-A coil driver voltage monitors, the "VMONs" to the h1susauxh2 model. Currently the HAM12 wiring diagram D0902810-v10 is in conflict, indicating that these VMON channels are to be piped in 
    (1) on page 12 to "IN25-28" of the SUS-C4 AA chassis at U11,
    (2) on page 14 to "IN25-28" of the SUS-C3 AA chassis at U31
which either way feed into ADC0 of the h1susauxh2 IO chassis/computer. I'm 100% confident that (2) is right, and will redline the drawing.
    
As such, I've populated the new PM1 VMON filters with the ADC0 channels 24-27.

See attached screenshots.

I've tested that the model compiles successfully on the h1build machine.

The updates to the model have been committed to the userapps repo as
    /opt/rtcds/userapps/release/sus/h1/models/
        h1susauxh2.mdl                            rev 30909.

No library parts were used or impacted.

Following the usual Cal meas wiki instructions , I ran a calibration broadband and simulines measurement, but the IFO lost lock near the very end of simulines. All test points were cleared with the script wrapup.

Simulines start:

PST: 2025-03-06 12:12:00.699516 PST
UTC: 2025-03-06 20:12:00.699516 UTC
GPS: 1425327138.699516
 

Simulines output near end:

2025-03-06 20:35:04,501 | INFO | Drive, on DARM_OLGTF, at frequency: 1083.3, and amplitude 1e-09, is finished. G
PS start and end time stamps: 1425328503, 1425328518
2025-03-06 20:35:04,502 | INFO | Scanning frequency 1200.0 in Scan : DARM_OLGTF on PID: 861436
2025-03-06 20:35:04,502 | INFO | Drive, on DARM_OLGTF, at frequency: 1200.0, is now running for 23 seconds.
2025-03-06 20:35:05,621 | INFO | Drive, on L2_SUSETMX_iEXC2DARMTF, at frequency: 43.6, and amplitude 0.40648, is
finished. GPS start and end time stamps: 1425328503, 1425328518
2025-03-06 20:35:05,622 | INFO | Scanning frequency 51.05 in Scan : L2_SUSETMX_iEXC2DARMTF on PID: 861446
2025-03-06 20:35:05,622 | INFO | Drive, on L2_SUSETMX_iEXC2DARMTF, at frequency: 51.05, is now running for 23 se
conds.
2025-03-06 20:35:06,760 | INFO | Drive, on L3_SUSETMX_iEXC2DARMTF, at frequency: 289.84, and amplitude 0.49024,
is finished. GPS start and end time stamps: 1425328503, 1425328518
2025-03-06 20:35:07,271 | INFO | 4 still running.
2025-03-06 20:35:11,138 | INFO | Drive, on PCALY2DARMTF, at frequency: 7.68, and amplitude 16534, is finished. G
PS start and end time stamps: 1425328496, 1425328523
2025-03-06 20:35:11,279 | INFO | 3 still running.
2025-03-06 20:35:11,721 | ERROR | IFO not in Low Noise state, Sending Interrupts to excitations and main thread.
2025-03-06 20:35:11,721 | ERROR | Ramping Down Excitation on channel H1:LSC-DARM1_EXC
2025-03-06 20:35:11,721 | ERROR | Aborting main thread and Data recording, if any. Cleaning up temporary file st
ructure.
Process Process-12:
Traceback (most recent call last):
 File "/var/opt/conda/base/envs/cds/lib/python3.10/multiprocessing/process.py", line 314, in _bootstrap
   self.run()
 File "/var/opt/conda/base/envs/cds/lib/python3.10/multiprocessing/process.py", line 108, in run
   self._target(*self._args, **self._kwargs)
 File "/ligo/groups/cal/src/simulines/simulines/simuLines.py", line 340, in checkIfLocked
   os.kill(pid,signal.SIGINT)
ProcessLookupError: [Errno 3] No such process
2025-03-06 20:35:24,341 | INFO | Drive, on L1_SUSETMX_iEXC2DARMTF, at frequency: 12.86, and amplitude 19.723, is
finished. GPS start and end time stamps: 1425328522, 1425328538
Process Process-9:
Traceback (most recent call last):
 File "/var/opt/conda/base/envs/cds/lib/python3.10/multiprocessing/process.py", line 314, in _bootstrap
   self.run()
 File "/var/opt/conda/base/envs/cds/lib/python3.10/multiprocessing/process.py", line 108, in run
   self._target(*self._args, **self._kwargs)
 File "/ligo/groups/cal/src/simulines/simulines/simuLines.py", line 678, in generateSignalInjection
   results[scan] = tempObj
 File "", line 2, in __setitem__
 File "/var/opt/conda/base/envs/cds/lib/python3.10/multiprocessing/managers.py", line 817, in _callmethod
   conn.send((self._id, methodname, args, kwds))
 File "/var/opt/conda/base/envs/cds/lib/python3.10/multiprocessing/connection.py", line 206, in send
   self._send_bytes(_ForkingPickler.dumps(obj))
 File "/var/opt/conda/base/envs/cds/lib/python3.10/multiprocessing/connection.py", line 411, in _send_bytes
   self._send(header + buf)
 File "/var/opt/conda/base/envs/cds/lib/python3.10/multiprocessing/connection.py", line 368, in _send
   n = write(self._handle, buf)
BrokenPipeError: [Errno 32] Broken pipe
2025-03-06 20:35:30,666 | INFO | Drive, on L2_SUSETMX_iEXC2DARMTF, at frequency: 51.05, and amplitude 0.34489, i
s finished. GPS start and end time stamps: 1425328529, 1425328544
Process Process-10:
Traceback (most recent call last):
 File "/var/opt/conda/base/envs/cds/lib/python3.10/multiprocessing/process.py", line 314, in _bootstrap
   self.run()
 File "/var/opt/conda/base/envs/cds/lib/python3.10/multiprocessing/process.py", line 108, in run
   self._target(*self._args, **self._kwargs)
 File "/ligo/groups/cal/src/simulines/simulines/simuLines.py", line 678, in generateSignalInjection
   results[scan] = tempObj
 File "", line 2, in __setitem__
 File "/var/opt/conda/base/envs/cds/lib/python3.10/multiprocessing/managers.py", line 817, in _callmethod
   conn.send((self._id, methodname, args, kwds))
 File "/var/opt/conda/base/envs/cds/lib/python3.10/multiprocessing/connection.py", line 206, in send
   self._send_bytes(_ForkingPickler.dumps(obj))
 File "/var/opt/conda/base/envs/cds/lib/python3.10/multiprocessing/connection.py", line 411, in _send_bytes
   self._send(header + buf)
 File "/var/opt/conda/base/envs/cds/lib/python3.10/multiprocessing/connection.py", line 368, in _send
   n = write(self._handle, buf)
BrokenPipeError: [Errno 32] Broken pipe
ICE default IO error handler doing an exit(), pid = 861402, errno = 32
PST: 2025-03-06 12:35:30.912878 PST
UTC: 2025-03-06 20:35:30.912878 UTC
GPS: 1425328548.912878
 

Thu Mar 06 10:13:00 2025 INFO: Fill completed in 12min 56secs

1425312692

Just before calibration and commissoining time we lost lock. Just like the lock loss before it, the only sign of anything moving beforehand is a very small wiggle in ETMY output 10's of ms before. This might be nothing, but it's the only thing I've found so far.

Once we get back we will jump straight into unthermalized commissioning followed by a calibration.

TITLE: 03/06 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 149Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 14mph Gusts, 9mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.32 μm/s
QUICK SUMMARY: Currently in a stand down, we've been locked for 5.5 hours. Calm environment, no alarms.

TITLE: 03/06 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 150Mpc
INCOMING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 12mph Gusts, 10mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.29 μm/s
SHIFT SUMMARY:
Once LHO H1 was relocked at the very beginning of my shift, it stayed locked for the next 4 hours and 40 minutes.
Everything has been running well.

LOG:
No Log

I'm looking again at the OSEM estimator we want to try on PR3 - see https://dcc.ligo.org/LIGO-G2402303 for description of that idea.

We want to make a yaw estimator, because that should be the easiest one for which we have a hope of seeing some difference (vertical is probably easier, but you can't measure it). One thing which makes this hard is that the cross coupling from L drive to Y readout is large.

But - a quick comparison (first figure) shows that the L to Y coupling (yellow) does not match the Y to L coupling (purple). If this were a drive from the OSEMs, then this should match. This is actuatually a drive from the ISI, so it is not actually reciprocal - but the ideas are still relevant. For an OSEM drive - we know that mechanical systems are reciprocal, so, to the extent that yellow doesn't match purple, this coupling can not be in the mechanics.

Never-the-less, the similarity of the Length to Length and the Length to Yaw indicates that there is likely a great deal of cross-coupling in the OSEM sensors. We see that the Y response shows a bunch of the L resonances (L to L is the red TF); you drive L, and you see L in the Y signal. This smells of a coupling where the Y sensors see L motion. This is quite plausible if the two L OSEMs on the top mass are not calibrated correctly - because they are very close together, even a small scale-factor error will result in pretty big Y response to L motion.

Next - I did a quick fit (figure 2). I took the Y<-L TF (yellow, measured back in LHO alog 80863) and fit the L<-L TF to it (red), and then subtracted the L<-L component. The fit coefficient which gives the smallest response at the 1.59 Hz peak is about -0.85 rad/meter. 

In figure 3, you can see the result in green, which is generally much better. The big peak at 1.59 Hz is much smaller, and the peak at 0.64 is reduced. There is more from the peak at 0.75 (this is related to pitch. Why should the Yaw osems see Pitch motion? maybe transverse motion of the little flags? I don't know, and it's going to be a headache).

The improved Y<-L (green) and the original L<-Y (purple) still don't match, even though they are much closer than the original yellow/purple pair. Hence there is more which could be gained by someone with more cleverness and time than I have right now.

figure 4 - I've plotted just the Y<-Y and Y<-L improved.

Note - The units are wrong - the drive units are all meters or radians not forces and torques, and we know, because of the d-offset in the mounting of the top wires from the suspoint to the top mass, that a L drive of the ISI has first order L and P forces and torques on the top mass. I still need to calculate how much pitch motion we expect to see in the yaw reponse for the mode at 0.75 Hz.

In the meantime - this argues that the yaw motion of PR3 could be reduced quite a bit with a simple update to the SUS large triple model, I suggest a matrix similar to the CPS align in the ISI. I happen to have the PR3 model open right now because I'm trying to add the OSEM estimator parts to it. Look for an ECR in a day or two...

This is run from the code {SUS_SVN}/HLTS/Common/MatlabTools/plotHLTS_ISI_dtttfs_M1_remove_xcouple'

-Brian

Jeff, Oli

ECR E1700228

More preparation to make way for PM1 - Jeff and I went into the h1sushtts simulink model and added in PM1 and its necessary connections(h1sushtts before). It was basically a copy of the RM1 and RM2 control blocks, with the input ADC channels taking 24 - 27, and channels 8 - 11 on the DAC (h1sushtts after - PM1+output).

We also copied the RMs PCIe inputs, but the channels coming in from the TTL4C on HAM1 are going to be removed for the RMs when the ISI is installed on HAM1 and replaced with the new ISI channels, and so PM1 will never have the HAM1_TTL4C channels. Since we want to be able to compile and test the model before then, I have put in a constant 0 in place of the TTL4C channels for PM1 (h1sushtts after - IPC INP). Once we have the new ISI channels, we can add these connections in using those channels, as well as update the channels for the RMs.

Daniel just added in the new ASC channels for PM1 (83195), so I was able to successfully compile h1sushtts. It has not yet been installed.

The model file can be found in /opt/rtcds/userapps/release/sus/h1/models/, and the changes to h1sushtts.mdl have been committed to the svn as revision 30907.