TITLE: 08/20 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 151Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY: Locked for 1 hour after a fast lock loss (alog86483). Reacquisition was straight forward but I did need to run an initial alignment.
LOG:

• 1725-1742 Fire pump 1 on due to hydrant work
• 1745 HDF offsite
• 2055 Lock loss
• 2233 Observing

TITLE: 08/20 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 150Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 14mph Gusts, 7mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.10 μm/s
QUICK SUMMARY:

H1's been locked almost an hr (and TJ reported reacquisition was straightforward---good to know after yesterday's post-Maintenance locking issues!).  Winds low, microseism is low (below 50th percentile' here's to smooth sailing!

J. Kissel

Dimensions of Glenair picomotor mightmouse connector for Science.

1439758519

No obvious cause, looks very fast.

Since the HAM1 vent, I have done a few different measurements of the ASC that provide information on how to calibrate WFS signals from counts to microradians. Here is a summary:

CHARD, INP1 and PRC2 results come from this alog

DHARD results come from this alog

SRM results come from this alog (if you are comparing values, I made a power normalization error in the linked alog)

BS results were taken but never alogged (shame on me)

All of these measurements were taken by notching all ASC loops at 8.125 Hz and injecting an 8.125 Hz line in the desired DoF. The osem wits provide the urad reference.

Unless otherwise specified, the witness channels are the bottom stage osems

Continuing my efforts to check and update the LSC coupling (see 86423 and 86370) I ran yet another bruco, which showed that now the dominant low frequency coherence is coming from SRCL.

In review, I have:

• updated PRCL feedforward, which has greatly reduced the remaining coherence
• updated MICH feedforward, again reducing coherence
• and I did a minimal update to SRCL, which has not really done much (see linked SRCL coherence above)

I think we can do better. The main challenge is fitting the <100 Hz coupling while fitting the >100 Hz coupling, or at least not significantly worsening it. I think the fit would be easier if we made use of the parallel SRCLFF banks to fit a low and high frequency feedforward. This would require fitting the low frequency coupling, engaging it, and then remeasuring the high frequency coupling to fit separately.

I have what I think is a better fit to the low frequency coupling, currently saved in FM5 of the SRCLFF1 bank. To test this new filter:

• take SRCL1FF gain to zero
• turn off FM6 (current) and turn on FM5
• ramp SRCL1FF gain back to 1
• run SRCL injection template and compare with the reference (best practice would be getting a same day injection first on FM6 to compare with)
  • use SRCL_excitation_20240824.xml saved in /opt/rtcds/userapps/release/lsc/h1/scripts/feedforward/
• if the filter performs better, change the guardian code in LOWNOISE_LENGTH_CONTROL to use FM5 and update SDF

Time permitting, if the new filter works, taking a better measurementing of the coupling from 100 Hz and up while on the new filter would be a useful next step, which may require adjusting the excitation shape or increasing the excitation gain.

To motivate the use of commissioning time on this, I did a very simple coherence based subtraction of the SRCL noise to see what it could get us in range improvement. I used the same time as the bruco I linked above, so this time includes the PRCL and MICH improvements. I copied some of Oli's range compare code to help me generate this nice plot comparing 1 hour of strain with coherence subtraction of the SRCL noise. Even if we can't improve the feedforward above 100 Hz, there is possible a 2 Mpc improvement from below 100 Hz.

Wed Aug 20 10:09:36 2025 INFO: Fill completed in 9min 32secs

Gerardo confirmed a good fill curbside.

While fixing a hydrant on the backside of the OSB/vertex area, fire pump 1 was activate from 1725-1742UTC. Hanford FD pickup truck and our F150 were also back in that area. Their driving to and from that area, as well as some of their work showed up on our ITMY seismometer.

TITLE: 08/20 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 152Mpc
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 3mph Gusts, 1mph 3min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.07 μm/s
QUICK SUMMARY: Locked for 11.5 hours, no alarms, calm environment. Looks like we dropped Observing at 1053-1057UTC because the SQZr lost lock and relocked.

Our range isn't as stable as it has been lately, and the Omicron glitch gram FOM shows some extra SNR around 20-30Hz during those times.

TITLE: 08/19 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY:

Shift started out with Elenna & Jenne troubleshooting H1 due to locklosses at DHARD WFS post-Maintenance.  Elenna was eventually able to get H1 past the rough DHARD/CARM Offset steps of ISC_LOCK.  H1 was then able to get back to Observing (please see Elenna's alog for more info---Elenna mentioned, as she was leaving for the night, that this was an issue similar to what she saw after the recent HAM1 vent.).

Violins were elevated on this lock, but once High Power Damping settings were started, most modes were damped down pretty fast.  ETMy M1 was slow, so I helped it out a little (nominal gain is -0.1 for ETMy Mode1, and I have it at -0.2 and will leave it here for the night since it continues to damp this one nicely.
LOG:

• 23:37 PCal Crew out of lab (rick, dripta, tony)
• 00:05-00:23 Initial Alignment (successful)
  • Have been getting to DARM to RF fairly repeatedly.  Made it to CARM to REFL so far
    • This has required trying new DHARD P&Y gains
    • Elenna would later carefully navigate various states before finally making it to  ENGAGE ASC FOR FULL IFO.
    • See Elenna's alog!!  
• 00:15-00:35 MX mech room & FCES mech room visits (janos)
• 02:51 H1 back to NLN, 02:55 H1 back to Observing!
• 04:23  Dave teamspeaked in to let me know there was a non-real VAC STAT glitch and that he would need to do a restart to clear it.

This morning the In-Lock SUS Charge Measurements ran.  Attached are the plots for all four Test Masses.  Closing FAMIS 28419.

We had a 2 second square wave sensor glitch in PT100. Its pressure jumped from 1.7e-07 to 3.7e-07 Torr for 2 seconds and then jumped back.

VACSTAT sent cell phone texts to team-VAC due to this single gauge event, because HAM1 is separated from the rest of the vertex and is therefore exempt from the 2-gauges-in-alarm filter.

VACSTAT was restarted at 21:26 and I took the opportunity to bring MY's PT124B back into the system.

After Elenna left (and made a summary alog), H1 made it to OBSERVING.  To get here, I ACCEPTED new ASC SDFs (see attached).

Violins are elevated after today's Maintenance, but once DAMPING came on, they are mostly all sharply dropping.

Bi-weekliy stats for a few locking sequences for the bast 14 days.
ALS: max Duration 28 Min
Average 4.79 Min
% above 5 minutes 32.07
Date range: 2025-08-06 02:28:40 to 2025-08-20 02:28:40

DRMI [18-101]: max Duration 57 Min
Average 13.68 Min
% above 5 minutes 54.90
Date range: 2025-08-06 02:29:42  to  2025-08-20 02:29:42

CARM: [120 -428] - max Duration 29 Min
Average 5.28 Min
% above 5 minutes 18.42
Date range: 2025-08-06 02:30:51  to 2025-08-20 02:30:51

Powerup [429-590]: max Duration 46 Min
Average 21.633 Min
% above 30 minutes 63.33
Date range: 2025-08-06 02:32:18  to  2025-08-20 02:32:18

We kept losing lock at DHARD WFS, and Jenne and I spent a lot of time figuring out why. Here are some notes about things that we tried:

• We tried going to RF DARM, and running the DHARD WFS engagement by hand
• It seemed like turning on the small negative gains for DHARD (normal for the state) was bad
• we tried positive gains instead, and they seemed ok for the engagement
• this is REALLY WEIRD, we didn't do anything to DHARD or AS WFS today that would cause this
• we tried walking DHARD around a bit to see if we were very far off in the alignment, but that didn't seem to be a problem
  • error signals were close to zero and the AS camera looked good
• We also held in down for a bit to check the AS dark offsets in case they had somehow changed significantly
  • Corey SDFed these changes in observe here, and I SDFed them in safe
  • they were not largely different, so we realized that couldn't be the issue
• We tried keeping DHARD with a flipped sign and proceeding with locking
• we then lost lock a few times next at CARM OFFSET REDUCTION- it looked like the DHARD error signals got very big very fast in this state causing a lockloss
  • as a note, we were skipping over the shutter ALS states so we could use the green alignment as another witness for what was going on
  • we were worried the green alignment was very bad somehow
• This led us to think that maybe the DHARD signal before CARM OFFSET REDUCTION was just junk, maybe the offset was too big for the signal to be meaningful, and the sign flip was just an indication of that
• then we tried NOT engaging DHARD, and just going to CARM OFFSET REDUCTION, which is scary because the camera gets very wobbly, but it didn't necessarily cause a lockloss
• I then tried moving DHARD by hand again
• I found that we could then engage DHARD with the correct gain sign, so that seemed promising
• we moved on and started losing lock at CARM TO REFL
  • at this point Jenne had to leave
• I eventually figured out that the lockloss occurred after the ramp from TR CARM to REFL9.
  • essentially the buildups would get very noisy as we ramped and then the suspensions would saturate shortly after
• This reminded me of the exact same problem that Jenne and I had to solve previously. I couldn't find an alog, so either we didn't write one (boo) or I forgot the correct search terms to find it

How I solved the problem:

• I ran through CARM to REFL by hand
  • essentially, I set the LSC-TR_REFLAIR9_OFFSET by hand based on LSC-TR_REFLAIR9_INMON (inmon was about 0.17 so I made the offset -0.17)
  • then the state sets up some filters and the ramping input matrix, just dropped those lines of code into the guardian shell
• I found that ramping partway made the buildups a bit fuzzy but less fuzzy (I vaguely remembered trying halfway ramps with Jenne the last time we had this problem)
  • by "partway" I mean that the TR CARM intrix value is 1, and the final REFL9 value needs to be 2, so I ramped TR CARM to 0.75 and REFL9 to 0.5
• Then, I remembered that we needed to reduce the offset I set above by hand
  • essentially, we think that whatever that offset is, it is too far away from where we think we are in the carm offset space, so we make it smaller and bring the arms closer to resonance
• The offset was set to be -0.17 to cancel out the inmon signal
  • I stepped down towards zero in 0.01 steps
  • each time, I saw the PRG increase accordingly, and the buildups got less fuzzy
  • then I ramped another bit, so TR CARM to 0.5 and REFL9 to 1
  • reduced the offset a little more, ramped TR CARM to 0.25 and REFL9 to 1.5
  • reduced the offset a little more and then finished the ramp
  • by the time I did the final ramp, the offset was down to -0.1
• Then I was able to complete the rest of the carm to analog procedure by letting the guardian run

Some final notes about minor mistakes I made after:

• after running ENGAGE ASC FOR FULL IFO, I manualed to PARK ALS VCO and SHUTTER ALS, then manualed to SOFT LOOPS
• I forgot that we go to DARM OFFSET after full IFO ASC, so the OMC guardian couldn't lock the OMC and we stalled in PREP DC READOUT
• manualed to DARM OFFSET and then back to PREP DC READOUT

TJ, Ryan S, Elenna

Today we (once again) took some time to try to commission the PRM ASC loop in PRMI ASC.

We locked PRMI, and I engaged the beamsplitter ASC. I was able to see by moving PRM pitch around, and watching the buildups, that the "old" error signal, REFL A RF9 I, was a great error signal and only required a sign flip.

However, PRM yaw was harder. I checked REFL A and B RF9 I and neither signal worked. I checked POP X I next, and saw that the signal worked just fine. This doesn't make a lot of sense, but it works. I updated the guardian accordingly.

To test that the guardian changes work, we brought the ISC_DRMI guardian down, which unlocked PRMI, and re-requested PRMI ASC. We fixed a few guardian errors and tried again. It worked fine.

These are the changes made:

• edited the input matrix for PRC1 pitch and yaw as stated above
• edited the PREP PRMI state to engaged DC centering on POP (DC6)
• edited LSCparams to have PRC1 set to True in PRMI ASC

Loaded and tested!

Leo, Jennie, Camilla

Followed setup instructions from 80010, with 75mW injected in the SEED beam, we had 1mW on OPO_IR_PD_DC slightly lower than last time. Also took SQZ_FC to FC_MISALIGNED.  And opened SQZ beam divertor and fast shutter. Have counts of ~60 on ASC-AS_A and B and 7e-4 on ASC-OMC-A and B NSUMs. Jennie took the OMC PZT down to zero to start and then ran a template userapps/../omc/h1/templates/OMC_scan_sqz_beam.xml.

Repeated mode scans with different ZM PSAMs offsets, the DC centering loops could account for the pitch change for PSAMs, for the extreme PSAMS values, I increased the servo limiter from 85 to 95. 

• nominal: ZM4 6.0V strain, ZM5 -0.4V strain. 
• ZM4 9.5V strain, ZM5 -0.6V strain. 
• ZM4 6.0V strain, ZM5 -4.5V strain. Note that the OMC Pitch QPDs were off around -0.1
• ZM4 6.0V strain, ZM5 -5.3V strain. Note that the OMC Pitch QPDs were off around -0.1
• ZM4 9.0V strain, ZM5 2.0V strain
• ZM4 3.0V strain, ZM5 2.0V strain
• ZM4 8.0V strain, ZM5 -2.0V strain. Note that the OMC Pitch QPDs were off around -0.1
• ZM4 4.0V strain, ZM5 -2.0V strain. 
• ZM4 9.5V strain, ZM5 -5.0V strain. Realized OMC ASC had been off before this measurement (we had turned it on but them changed OMC GRD which turned it off again)
• Repeat of ZM4 9.5V strain, ZM5 -0.6V strain with OMC ASC on.

Jennie and Leo have the data to analyze.