TITLE: 06/20 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 148Mpc
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY:

Today's main activity was supposed to be a Commissioning Time (from 8am-2pm (PDT) [1500-2100utc]), but with a lockloss near the start, much of the commissioing time was focused on troubleshooting for locking issues with DRMI and also ALS (some commissioning tasks happened at the beginning & end of today's Commissioning Period of 8am-2pm (PDT) [1500-2100utc].

ALSO A New NOTE for Operators: 

1. It looks like we can now run the usual INITIAL_ALIGNMENT (vs MANUAL_ALIGNMENT), because for IFO_ALIGN, the PRC_ALIGN_OFFLOADED state now looks good (see Elenna's alog85200).  However, Sheila noted, we should be mindful of the BS heating (Camilla's alog84922).  In other words, we should run alignments about 30min after a lockloss (or even 60min)---to allow the BS time to cool down and return to its "nominal" pointing at the beginning of locks.
2. Elenna has some changes in ISC_LOCK, so after the next lockloss, we'll need to run a LOAD of ISC_LOCK and ACCEPT the SDF Diffs which come up (see Elenna's alog85207).

VAC Note:  There were hopes we could turn OFF the HAM1 Pump, but there is a pressure we need to get below before we can do this, and we were not there today.  Travis mentioned it will have to wait until Monday.
LOG:

• 1510 Commmissioning begins (sheila)
  • Sheila starts with running Jennie's DARM offset step script.  Then Keith Kuns@MIT and Sheila will run a measurement using the Squeezer to check H1 mode matching via the ADF (Audio Diagnostic Field).
• 1528 LOCKLOSS (this was just after Keith started his SQZ measurement--which we don't think was the reason for the lockloss; bad timing H1)
• LOCKING notes:  Letting H1 try to lock on its own
  • Y-arm did a Scan Alignment
  • DRMI didn't look great, so I went for CHECK FRINGES + PRMI
  • 1602-1622  Manual Initial Alignment (PRM tweaked to get AS_A up to 1.32 (from 1.28))
  • For DRMI, it looked better post-alignment, BUT after 11min, GRD took to PRMI.
    • 1640 Sheila running a check at PRMI_ASC but no change made; after this DRMI locked, but had lockloss at ENGAGE ASC as the PR Gain rung up before the lockloss.
  • For next locking attempt hold at DRMI LOCKED PREP ASC
    • Although the X-arm was locked above 1, it was taken to a SCAN ALIGNMENT which was odd.
• 1617-1629 H2 Room cleaning (kim, nellie)
• 1625 Setting up measurement in PCal Lab (francisco)
• 1630 Receiving roll-up opened (for cardboard) (kim)
• 1708-1714 Connecting cable to CM board at racks (sheila, matt)
• 1802-1819 Parts check in lvea (mitch)
• 1804 3IFO checks (betsy, suresh, LIGO visitors)
• 1820-1837 Running another Manual Alignment 
  • PRC ALIGN OFFLOADED  looks it works---Elenna checked it out during this alignment:  So we should be able to run the standard INITIAL_ALIGNMENT
• MORE Locking Notes:  Had several more locklosses during the commissioining time---due to ALS & ENGAGE ASC for FULL IFO.  Focus switched to troubleshooting the ALS locking, DRMI locking, and getting through ENGAGE ASC. 
  • 2046 H1 finally back to NOMINAL LOW NOISE.  Elenna was able run a measurement once we were back to NLN & once she was done, she disconnected the SR560 out on the floor and disconnected it from the racks and then turned out the LVEA lights.
• 1930 ISS array work in the optics lab (keita, rahul)
• 1957-2005 Checking shutters in Pcal Lab (francisco)
• 2115 Back to OBSERVING

TITLE: 06/20 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 141Mpc
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 28mph Gusts, 14mph 3min avg
    Primary useism: 0.05 μm/s
    Secondary useism: 0.09 μm/s
QUICK SUMMARY: H1 has been locked for over 2 hours.

• Will load ISC_LOCK when next out of observing - alog85207
• Wind speeds have been rising, microseism low
• All other systems nominal

FAMIS 26395, last checked in alog85021

All fans look largely unchanged compared to last week and are all within noise thresholds.

Sheila measured the CARM gain during vent recovery at a thermalized time (84944), and it seemed low, so today we plugged in the SR785 and measured the CARM OLG at the start of lock.

Right at the beginning of lock, the UGF was 14.4 Hz, which is fine except that we will lose gain from thermalization. I bumped up the gain by 1 dB on each REFL A and B slider ("H1:LSC-REFL_SUM_{A,B}_IN2GAIN") and remeasured, and the UGF was about 14.3 Hz. Then, I increased the gain another 2 dB each on each slider and remeasured, 16 kHz. This is where we want to be, although I imagine it will decay more as we thermalize.

This means that in NLN, we want our CARM gain settings to be 15 dB on each slider, which I accepted in SDF. However, I have not yet put them in the guardian because I am trying to figure out where that actually should be adjusted.

I have attached the three measurements I took. The title of the first one is misleading since I used the wrong template, but the time stamps on all are accurate.

First measurement

Second measurement, both gains up +1 dB

Third measurement, both gains up +2 dB more

SDF in observe

Procedural notes for future me to measure the OLG and plot the measurement:

> cd ligo/gitcommon/psl_measurements/templates

> conda activate psl

> python ../code/SRmeasure.py carm_olg_template.yml

> python ../code/quick_tf_plot.py ../data/carm_olg/[filename]

I unplugged the SR785 before observing.

After today's commissioning and trouble shooting work we had a list of SDFs to address.  Elenna and I both addressed these. 

Elenna will add a comment to this alog with the SDFs she addressed.

I took care of the SDF Diff for  SQZ ADF.  Kevin Kuns noticed this channel was not restored to its  OBSERVING value; he took it to 320, but SDF flagged this because it should actually be 322, so I REVERTed this channel (H1:SQZ-ADF_VCXO_CONTROLS_SETFREQUENCYOFFSET) to 322 (see attached).

We have been having large glitches and sometimes locklosses from ENGAGE ASC FOR FULL IFO. I have tracked the problem down to the CHARD P gain coming on at full gain at the start of the state. This is an error that we made when trying to recover from the vent- we commented out a 30 dB gain filter in the late part of the state, and then set the new full gain at teh gain that engages at the start of the state. I have now edited the guardian to engage CHARD P with a gain that is 30 dB less than the final gain ('ENGAGE_ASC_FOR_FULL_IFO_initial'), and then the final gain is ramped at the end of the state (ENGAGE_ASC_FOR_FULL_IFO_final). These gains are set in lscparams.

Also, we put back the ITMX spot position to center in pitch, instead of the strange offset we added during vent recovery.

Corey, Elenna, Sheila

Recently we have been having trouble locking DRMI even when the flashes seem good.  We stopped to check some DRMI phasing, similar to what we've done for PRMI in 85080 and 84630. 

The first screenshot shows the PRCL OLG, which has a large wiggle from 20-40 Hz before we started (REFL AIR 9 phase -21).  We ran the template in userapps/lsc/h1/templates/phase_REFLAIR.xml to send a 300 count excitation to PRM M3 at 132 Hz, and phased this into I for REFLAIR 45 (to reduce PRCL cross coupling to the MICH loop), and into I for REFLAIR 9.  Then we checked the TF of PRM to both I sigal to estimate the matrix element we should use to cancel the PRM coupling to the SRCL error signal, and updated this from -1.8 to -1.7. 

These three things have reduced the wiggle.  We are hoping this will help with DRMI acquisition, our first two attempts have gone well but we will wait to collect some statistics.

J. Kissel

I'm building up some controls design documentation for the derivations of the OSEM2EUL / EUL2OSEM matrices for existing suspension types (see G2402388), in prep for deriving new ones for e.g. the HRTS and if we upgrade any SUS to use the 2-DOF AuSEMs.

In doing so, I re-remembered that the HLTS, HSTS, OMC controls arrangement poster (E1100109), defining the now-called "6HT" OSEM arrangement in T2400265 calls out two possible positions for the transverse sensor, the "side" and "opposite side," which I'll abbreviate as SD and OS, respectively from here on.

If the transverse sensor is mounted in the SD position, then as the suspension moves in +T, the OSEM further occults the LED beam, creating a more negative ADC signal. Thus, the OSEM2EUL matrix's SD to T element should be -1.0.
If the transverse sensor is mounted in the OS position, then as the suspension moves in +T, the OSEM opens up revealing more LED beam, creating a more positive ADC signal. Thus, the OSEM2EUL matrix's SD to T element should be +1.0.

Not *actually* remembering that the HLTSs PR3, SR3, and two of the 9 HSTSs, SR2 and SRM use OS as their transverse sensor yesterday, and missing the note from Betsy in the abstract of E1100109 to look at the each SUS' Systems Level SolidWorks assembly for transverse sensor location assignment (prior to this morning it was not in red, nor did it call which suspension explicitly have their transverse sensor mounted in the OS position), I was worried that we'd missed this when defining the sign of *all* HLTS / HSTS / OMCS OSEM2EUL / EUL2OSEM matrices, and assumed they were all installed as SD OSEMs with -1.0 OSEM2EUL and EUL2OSEM matrix elements.

Below, I inventory the status with 
    - suspension name, 
    - a reference to picture of the transverse OSEM (or the corresponding flag w/o the OSEM), 
    - confirming SW drawing does match the picture, 
    - the current value / sign of the OSEM2EUL / EUL2OSEM matrix element (H1:SUS-${OPTIC}_M1_OSEM2EUL_2_6 or H1:SUS-${OPTIC}_M1_EUL2OSEM_6_2)
    - a conclusion of "all good" or what's wrong.


Optic	T Sensor	aLOG pic	SW check	OSEM2EUL	Conclusion
	Mount				value		/EUL2OSEM
MC1     SD              LHO:6014        D0901088 g      -1.0            all good
MC3     SD              LHO:39098       D0901089 g      -1.0            all good
PRM     SD              LHO:39682       D0901090 g      -1.0            all good
PR3     OS              LHO:39682       D0901086 g      +1.0            all good

MC2     SD              LHO:85195       D0901099 g      -1.0            all good
PR2     SD              LHO:85195       D0901098 g      -1.0            all good

SR2     OS              LHO:41768       D0901128 g      +1.0            all good

SRM     OS              LHO:60515       D0901133 g      -1.0		OSEM2EUL/EUL2OSEM wrong!
SR3     OS              LHO:60515       D0901132 g      +1.0            all good

FC1     SD              LHO:61710       D1900364 g      -1.0            all good
FC2     SD              LHO:65530       D1900368 g      -1.0            all good

OMC     SD              LHO:75529       D1300240 g      -1.0            all good (see also G1300086)


So, as the title of this aLOG states, we've got the sign wrong on SRM.

Shouldn't we have discovered this with the "health check TFs?"
Why doesn't this show as a difference in the "plant" ("health check") transfer functions when comparing against other SUS that have the sign right?
Why *don't* we need a different sign on SRM's transverse damping loop? 

Because the sign in the EUL2OSEM drive and OSEM2EUL sensed motion is self consistent:

When SRM EUL2OSEM matrix requests to drive in +T as though it had an OSEM coil in the "SD" position, it's actually driving in -T because the OSEM coil is in the OS position. 
On the other side, the OSEM2EUL matrix corrects for a "SD" OSEM, with "more negative when moves in +T", and and has the (incorrect) -1.0 in the OSEM2EUL matrix. But since the SUS is actually moving in -T, making the flag occult more of the OS OSEM LED beam, yielding a more negative ADC signal, the -T is reported +T in the DAMP bank because of minus sign in "SD" OSEM2EUL matrix. 
So the phase between DAMP OUT and DAMP IN at DC is still zero, as though "everything was normal," because requested physical drive +T is sensed as +T.

Thus the Sensor / Drive phase is zero at DC like every other HSTS, we can use the same feedback -1.0 sign like every other DOF and every other HSTS.

Does this matter for the IFO?
No. This sensor is only used to damp transverse, i.e. transverse to the main IFO beam. If there're no defects on the SRM optic HR surface, and the transverse displacement doesn't span a large fraction of the beam width, then there should be no coupling into L, P or Y which are the DOFs to which the IFO should be sensitive. 
This is corroborated by Josh recent work where he measured the coupling of the "SD" OSEM drive (actually in the OS position, driving -T) and found it to be negligible; see LHO:83277, specifically this SRM plot.
Not only is the IFO not sensitive to the transverse drive from the OSEM, but also the absolute sign of whether it's +T or -T doesn't matter since there's no *other* sensors that measure this DOF that we'd have to worry about comparing signs against.

Should we fix it?
I vote yes, but with a low priority, perhaps during maintenance when we have the time to gather a "post transverse sensor sign change fix" set of transfer functions.

While Corey ran an initial alignment, I went to PREP_PRC_ALIGN to check the WFS error signal for that state. Both pitch and yaw looked good, I confirmed the signals cross zero when expected, and so I turned on the PRC ALIGN state and the initial alignment engaged and offloaded properly. Seems like we can use PRC align now!

I tagged OpsInfo so operators know. I recommend that the operators just pay attention during PRC Align over the next few days just to ensure nothing is going wrong (watch build ups as the ASC engages and confirm it's going in the right direction).

Fri Jun 20 10:07:53 2025 INFO: Fill completed in 7min 49secs

Corey and I ran the DARM offset stepping script using Jennie Wright's instructions from 85136.

Writing data to  data/darm_offset_steps_2025_Jun_20_15_11_46_UTC.txt  Moving DARM offset H1:OMC-READOUT_X0_OFFSET to 4 at 2025 Jun 20 15:11:46 UTC UTC (GPS 1434467524)

We lost lock 2 minutes after this script finished.  Kevin was running an ADF sweep at the time, but that was not doing anything at the time of the lockloss, so this seems like an unrelated lockloss. 

This is for FAMIS #26427.
Laser Status:
    NPRO output power is 1.844W
    AMP1 output power is 70.07W
    AMP2 output power is 140.3W
    NPRO watchdog is GREEN
    AMP1 watchdog is GREEN
    AMP2 watchdog is GREEN
    PDWD watchdog is GREEN

PMC:
    It has been locked 3 days, 0 hr 25 minutes
    Reflected power = 23.23W
    Transmitted power = 105.5W
    PowerSum = 128.7W

FSS:
    It has been locked for 0 days 0 hr and 5 min
    TPD[V] = 0.8216V

ISS:
    The diffracted power is around 4.0%
    Last saturation event was 0 days 0 hours and 32 minutes ago

Possible Issues:
    PMC reflected power is high

TITLE: 06/20 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 148Mpc
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 14mph Gusts, 5mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.11 μm/s
QUICK SUMMARY:

H1's been locked 8.75hrs with no Owl shift notifications and a fairly quiet environmental conditions (breezes picking up a little (just over 10mph).

After the lockloss Oli notes at the end of their shift, H1 relocked fine without a need for another alignment.

Commissioning is also scheduled from 8-2PDT today.

TITLE: 06/20 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: Currently relocking and in FIND_IR.

We've been having short locks all day, two of them being during my shift, despite the locklosses seemingly being caused by different or unknown causes. None of them seem to be caused by anything environmental, as wind and ground motion have been low (secondary useism was a bit elevated, but has been coming down and is nowhere near the amoount that we would typically be having problems with it). We've also now had two locklosses during the last two relock attempts from ENGAGE_ASC_FOR_FULL_IFO, from the spot where we've been having that glitchiness in the PR gain since coming back from the vent. Also, like Ibrahim mentioned in his end of shift alog (85186), DRMI has been taking a really long time to catch even though the flashes have been great. It's been taking us down to CHECK_MICH multiple times, and each time the alilgnment looks great.

During the relock following the 2025-06-20 00:09 UTC lockloss (85188), once we got back up to NLN, the squeezer was still working on trying to relock. It wasn't able to lock the OPO and was giving the messages "Scan timeout. Check trigger level" and "Cannot lock OPO. Check pump light on SQZT0". However, I just tried re-requesting LOCKED_CLF_DUAL on the OPO guardian, and it locked fine first try. So I guess that wasn't actually a problem? tagging sqz anyway?

LOG:

23:30 Relocking
23:59 NOMINAL_LOW_NOISE
    00:01 Observing
00:09 Lockloss
    - Running a manual initial alignment
    - Lockloss at ENGAGE_ASC_FOR_FULL_IFO
    - Lockloss from CARM_TO_TR
02:05 NOMINAL_LOW_NOISE
    02:11 Observing
03:32 Lockloss
    - Running a manual initial alignment
    - Lockloss at ENGAGE_ASC_FOR_FULL_IFO
   

Lockloss at 2025-06-20 03:32 UTC after 1.5 hours locked. Not sure why we're having all these short locks today

Headless Start: 1434382652

2025-06-19 08:42:24,391 bb measurement complete.
2025-06-19 08:42:24,391 bb output: /ligo/groups/cal/H1/measurements/PCALY2DARM_BB/PCALY2DARM_BB_20250619T153714Z.xml
2025-06-19 08:42:24,392 all measurements complete.
Headless End: 1434382962

Simulines Start: 1434383042

2025-06-19 15:55:14,510 | INFO | Drive, on L3_SUSETMX_iEXC2DARMTF, at frequency: 8.99, and amplitude 0.53965, is finished. GPS start and end time stamps: 1434383704, 1434383727
2025-06-19 15:55:14,510 | INFO | Scanning frequency 10.11 in Scan : L3_SUSETMX_iEXC2DARMTF on PID: 2067315
2025-06-19 15:55:14,511 | INFO | Drive, on L3_SUSETMX_iEXC2DARMTF, at frequency: 10.11, is now running for 28 seconds.
2025-06-19 15:55:17,845 | ERROR | IFO not in Low Noise state, Sending Interrupts to excitations and main thread.
2025-06-19 15:55:17,846 | ERROR | Ramping Down Excitation on channel H1:LSC-DARM1_EXC
2025-06-19 15:55:17,846 | ERROR | Ramping Down Excitation on channel H1:SUS-ETMX_L2_CAL_EXC
2025-06-19 15:55:17,846 | ERROR | Ramping Down Excitation on channel H1:SUS-ETMX_L3_CAL_EXC
2025-06-19 15:55:17,846 | ERROR | Ramping Down Excitation on channel H1:CAL-PCALY_SWEPT_SINE_EXC
2025-06-19 15:55:17,846 | ERROR | Ramping Down Excitation on channel H1:SUS-ETMX_L1_CAL_EXC
2025-06-19 15:55:17,846 | ERROR | Aborting main thread and Data recording, if any. Cleaning up temporary file structure.
PDT: 2025-06-19 08:55:22.252424 PDT
UTC: 2025-06-19 15:55:22.252424 UTC
Simulines End GPS: 1434383740.252424

Could not generate a report using the wiki instructions (probably due to incomplete sweep).

J. Kissel, S. Pai

Siddhesh and I B&K Hammer'ed the new MC2 and PR2 Scrapper Baffles, SR2 Cage, and of Primary/Final/Large? in-vac TCS Steering Mirrors in BSC2. More details, pictures, and results to follow.

Notes for myself later: 
- SR2 cage accelerometer was oriented with X Y Z aligned with the IFO global coordinates. 
- All other measurements had acc Y aligned with IFO Y, and acc Z aligned with IFO X.