TITLE: 11/13 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Microseism
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: USEISM
    Wind: 3mph Gusts, 0mph 3min avg
    Primary useism: 0.05 μm/s
    Secondary useism: 1.22 μm/s 
QUICK SUMMARY:

Currently in DOWN due to excessively high secondary microseism. We're supposed to have calibration measurements and commissioning today. I'll try for a bit to get us back up, but I doubt we'll get past DRMI since it's worse now than it was last night for Ryan or TJ

The useism continues to grow. I'll keep the IFO in down and see where things are at again in a few hours.

TITLE: 11/13 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Microseism
INCOMING OPERATOR: TJ
SHIFT SUMMARY: H1 was happily observing until mid-shift when the microseism just got too high and caused a lockloss. Haven't been able to make it past DRMI since then due to the ground motion. I'm leaving H1 in 'DOWN' since it's not having any success, but TJ says he'll check on things overnight.
LOG:

• 02:44 - Lockloss - alog88081

Lockloss @ 02:44 UTC - link to lockloss tool

Possibly caused by ground motion, as everything looked to be moving quite a lot at the time, and the secondary microseism band has been rising this evening. Environment plots on the lockloss tool show a quick increase in motion at the time of the lockloss also.

TITLE: 11/13 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 147Mpc
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY: Observing at 140 Mpc and have been Locked for over 16.5 hours. One short drop out of Observing due to the squeezer dropping out, but that relocked automatically and we're been Observing ever since. GRB-Short E617667 came in today at 21:29 UTC
LOG:

15:30UTC Observing and Locked for over 7.5 hours
    15:52 Out of Observing due to SQZ unlock
    15:56 Back into Observing
    21:29 GRB-Short E617667

TITLE: 11/13 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 148Mpc
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: USEISM
    Wind: 5mph Gusts, 3mph 3min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.56 μm/s 
QUICK SUMMARY: H1 has been locked for 16 hours and observing the whole day.

• Wind low, microseism on the rise
• All other systems nominal

Wed Nov 12 10:08:17 2025 INFO: Fill completed in 8min 13secs

Gerardo confirmed a good fill curbside.

Closes FAMIS#27534, last checked 87787

I was supposed to do this last week but I was out, so doing it now. Last time it was done was 10/28, so this is comparing to measurements from two weeks ago.

Nothing of note, everything looks very similar to how it looked a couple weeks ago.

TITLE: 11/12 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 148Mpc
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 3mph Gusts, 1mph 3min avg
    Primary useism: 0.05 μm/s
    Secondary useism: 0.37 μm/s 
QUICK SUMMARY:

Observing at 148 Mpc and have been Locked for over 7.5 hours. Currently in a standdown due to Superevent S251112cm that came in at 11/12 15:19 UTC

TITLE: 11/12 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 150Mpc
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY: A completely uneventful shift with H1 observing throughout. Now been locked for almost 7 hours.

As per WP 12876 I updated the run number server with a new version to allow more testing of the new frame writer (h1daqfw2), without allowing it to modify external state in CDS.

The run number server tracks channel list configuration changes in the frames.  The basic idea is the the frame writers create a checksum/hash of the channel list, send it to the run number server and get a run number to include in the frame.  This is then used by the nds1 server to optimize multi-frame queries (if it knows the configuration hasn't changed some of the structures can be re-used between frames (this has been measured at about a 30% speed-up)).

This update added a new port/interface that the server listens on.  It behaves a little different, it will only return the current run number (or 0 if the hash doesn't match) and will not increment the global state, so it is safe to have a test system use.

Now the new frame writer can automatically query the run number server to get the correct value to put in the frame (previously we had been setting it via a epics variable).  One step closer to the new frame writer being in production.

FAMIS 28431, last checked in alog87986

New data points for all quads this week, measurement trends attached.

TITLE: 11/12 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 149Mpc
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY: Currently Observing at 150 Mpc and have been Locked for just over an hour. Maintenance day was pretty light, but on the way back up there was some testing done with using the ETMY ESD (88065), so it took us a bit longer to get back to Observing. Besides that, getting back up wasn't bad at all.
LOG:

15:30UTC Locked and Out of Observing due to magnetic injections
15:40 Back to Observing
15:45 Out of Observing due to SUS charge measurements
16:01 Back into Observing after SUS charge measurements finished
16:01 Out of Observing to change the OM2 setpoint and unlock the IFO
16:03 I unlocked the IFO for maintenance

19:58 Started relocking
    - initial alignment
    - lockloss from LOWNOISE_COIL_DRIVERS due to commissioning
23:17 NOMINAL_LOW_NOISE
    23:28 Observing                                   

TITLE: 11/12 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 149Mpc
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 8mph Gusts, 5mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.26 μm/s 
QUICK SUMMARY: H1 has been locked for about an hour following Tuesday maintenance day.

• Wind low, microseism steady below 90th percentile
• All other systems nominal

I was able to get some more measurements done for the PRM and SRM estimators, so I'll note them and then summarize the current measurement filenames because there's a lot (previous measurements taken 87801 and 87950)

PRM
DAMP Y gain @ 20%
I was able to finish taking the final few DAMP Y @ 20% gain for H1SUSPRM M1 to M1. 

Settings
- PRM aligned
- DAMP Y gain to 20% (L and P gains nominal)
- CD state to 1
- M1 TEST bank gains all at 1 (nominally P and Y have a gain other than 1)
Measurements
2025-11-11_1700_H1SUSPRM_M1toM1_CDState1_M1YawDampingGain0p1_WhiteNoise_{L,T,V,R,P,Y}_0p02to50Hz.xml r12789
    - I took the measurements for V, R, P, and Y today since Jeff had taken L and T a couple weeks ago for this configuration
    - To try and lessen confusion, I changed date/time of all M1 to M1 PRM DAMP Y gain @ 20% measurements to 2025-11-11_1700 so they're all together. This means the M1 to M1 L and T measurements from a couple weeks ago now have this as the date/time

SRM
DAMP {L,P,Y} gain at 20%
I took HAM5 SUSPOINT to SRM M1 measurements

Settings
- SRM aligned
- DAMP {L,P,Y} gain to 20%
- CD state to 1
Measurements
2025-11-11_1630_H1ISIHAM5_ST1_SRMSusPoint_M1LPYDampingGain0p1_WhiteNoise_{L,T,V,R,P,Y}_0p02to50Hz.xml r12790
    - P and Y don't have very good coherence, but I ran out of time to try larger gains

Big measurement list:
PRM measurements:
DAMP gain LPY @ 20% (-0.1)
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/
    SUSPOINT to M1
    Common/Data/2025-11-04_1800_H1ISIHAM2_ST1_PRMSusPoint_M1LPYDampingGain0p1_WhiteNoise_{L,T,V,R,P,Y}_0p02to50Hz.xml
    M1 to M1
    SAGM1/Data/2025-10-28_H1SUSPRM_M1toM1_CDState1_M1LPYDampingGain0p1_WhiteNoise_{L,T,V,R,P,Y}_0p02to50Hz.xml
    M2 to M1
    SAGM2/Data/2025-10-28_H1SUSPRM_M2toM1_CDState2_M1LPYDampingGain0p1_WhiteNoise_{L,P,Y}_0p02to50Hz.xml
    M3 to M1
    SAGM3/Data/2025-10-28_H1SUSPRM_M3toM1_CDState2_M1LPYDampingGain0p1_WhiteNoise_{L,P,Y}_0p02to50Hz.xml

DAMP gain Y @ 20% (-0.1)
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/
    SUSPOINT to M1
    Common/Data/2025-11-04_1930_H1ISIHAM2_ST1_PRMSusPoint_M1YawDampingGain0p1_WhiteNoise_{L,T,V,R,P,Y}_0p02to50Hz.xml
    M1 to M1
    SAGM1/Data/2025-11-11_1700_H1SUSPRM_M1toM1_CDState1_M1YawDampingGain0p1_WhiteNoise_{L,T,V,R,P,Y}_0p02to50Hz.xml
    M2 to M1
    SAGM2/Data/2025-10-28_H1SUSPRM_M2toM1_CDState2_M1YawDampingGain0p1_WhiteNoise_{L,P,Y}_0p02to50Hz.xml
    M3 to M1
    SAGM3/Data/2025-10-28_H1SUSPRM_M3toM1_CDState2_M1YawDampingGain0p1_WhiteNoise_{L,P,Y}_0p02to50Hz.xml

SRM (so far)
DAMP gain LPY @ 20% (-0.1)
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SRM/
    SUSPOINT to M1
    Common/Data/2025-11-11_1630_H1ISIHAM5_ST1_SRMSusPoint_M1LPYDampingGain0p1_WhiteNoise_{L,T,V,R,P,Y}_0p02to50Hz.xml

Last week (87801) Jeff took a bunch of transfer function measurements for PRM for the PRM L, P, and Y estimators. There were some he wasn't able to take:

- H1ISIHAM2 to H1SUSPRM M1 for all dofs with DAMP L, P, and Y all with 20% gain

- H1ISIHAM2 to H1SUSPRM M1 for all dofs with DAMP Y at 20% gain

- H1SUSPRM M1 to M1 for V, R, P, Y with DAMP Y at 20% gain

Today I was able to get the first two bullet points done

Measurements:

First, I made sure the SUSPOINT matrix had the correct values for driving PRM, which it did. 

First set (L P Y DAMP gain at 20%):

L, P and Y DAMP gains were set to 20% of their nominal values, so they were set to -0.1, and T, V, and R were left at their nominal -0.5 gain values. 

Measurements can be found in 

/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/Common/Data/2025-11-04_1800_H1ISIHAM2_ST1_PRMSusPoint_M1LPYDampingGain0p1_WhiteNoise_*_0p02to50Hz.xml r12766

Second set (Y DAMP gain at 20%):

After those measurements were taken, I set the L and P DAMP gains back to their nominal values of -0.5 and took another set of SUSPOINT measurements with only the Y gain at 20%.

Those measurements can be found in 

/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/Common/Data/2025-11-04_1930_H1ISIHAM2_ST1_PRMSusPoint_M1YawDampingGain0p1_WhiteNoise_*_0p02to50Hz.xml r12767

I ran out of time and wasn't able to finish the four M1 to M1 dofs that were left for the reduced Y damping, so we'll have to get those next week.

I also wasn't able to get in any measurements for SRM, but that's okay since we're not in a rush.

J. Kissel

Gathered H1SUSPRM M3, M2, and M1 Drive to M1 Response TFs to inform the "drive" models for a future H1SUSPRM estimator. I'll post the locations / file names in the comments. Here in the main entry, I discuss the state of the control system for H1 SUS PRM so we understand with how much salt would should take these measurements.

Executive summary :: there are some side quests we can launch -- especially on the actuation side of this suspension -- if we think that these measurements reveal "way too much cross coupling for an estimator to work." The first things I'd attack would be 
    - the frequency-dependent and scalar gain differences *between* the nominal low noise state of the coil drivers and the state we need to characterize the suspension. 
    - the very old coil balancing, which was done *without* first compensating for any frequency-dependent gain differences in the channels at the frequency used to balance the coils (see LHO:9453 for measurement technique.)

Here's the detailed summary of all the relevant things for these measurements:
    - The suspension was ALIGNED, with alignment offsets ON, with slider values (P,Y) = (-1629.783, -59.868) ["urad"] 
        :: ALIGNED is needed (rather than just DAMPED [where the alignment sliders are OFF] or MISALIGNED where extra large alignment offsets are ON; per discussion of how the alignment impacts the calibration in LHO:87102)
        :: the usual caveats about the slider calibration, which is still using the [DAC ct / "urad"] gains from LHO:4563).

    - The M1 damping loop were converted to Level 2.0 loop shaping in Jan 2023; LHO:66859, nominally designed to have an EPICs gain of -1.0. However in Aug 2023, the EPICs gains were lowered to -0.5, and have been that way for most of O4, and remain that way now. For all of these measurements, I set the L, P and Y gains to -0.1; the "20% of nominal" gain mantra we've used for the HLTS estimators. I also gathered *almost* all the measurements again with only the Y gain at -0.1, but ran out of time to complete that set for comparison. 

    - Even though it was maintenance day, when we typically turn site-wide sensor correction OFF, I manually turned ON sensor correction for ISI HAM2 to get better coherence below 1 Hz (using instructions in LHO:87790)

    - The M3 L to M3 P filter (and gain) in the M3 DRIVEALIGN frequency-dependent matrix is OFF, per LHO:87523. 

    - There are (M3 P to M3 L) = 1.7 and (M3 Y to M3 L) = 0.52 scalar gains ON in to off-diagonal elements of the M3 DRIVEALIGN matrix whose purpose is change the center of P and Y actuation to be around where the IFO's beam spot typically is.

    - There is a set of M1 L to M1 P filters, "M1L_M3P" and "invM1P_M3P," in the M1 DRIVEALIGN matrix, with a EPICs gain of -1. I think these came from LHO:42549. The measurements I took aren't impacted by this, as I drove from the M1 TEST bank which does not send excitation through the DRIVEALIGN Matrix. HOWEVER, we'll definitely need to consider this when we model the ISC drive which *does* go through the M1 DRIVEALIGN matrix.

    - All M1, M2, and M3 stages of OSEM PDs sat amp whitening filters have been upgraded with ECR E2400330's filter design, and compensated accordingly. 
        :: M1 stage LHO:85463
        :: M2 & M3 stages LHO:87103

    - All M1, M2, and M3 stages of OSEM PDs have been calibrated via the ISI GS13s, and calibrated in the ALIGNED state (LHO:87231)

    - In order to get decent coherence over the band of interest for the M3, M2, and M1 drives, I had to drive the suspension actuators in their highest range state, which is different from the state the IFO usually needs.
        :: M1 = State 1 "LP OFF" (a Triple TOP Driver)
        :: M2 = State 2 "Acq ON, LP OFF" (An ECR E1400369 Triple Acquisition Driver "TACQ" modified for an extra 10x actuation strength. Modified in Sep 2013 LHO:7630)
        :: M3 = State 2 "Acq ON, LP OFF" (An ECR E1400369 Triple Acquisition Driver "TACQ" modified for an extra 10x actuation strength. Modified in Sep 2014 LHO:13956)

        :: The nominal state for the switches are M1 = State 2 "LP ON," M2 = M3 = State 3 "ACQ OFF, LP ON."

    - No actuator channels have had any precise compensation for their coil driver's frequency response in any state.
        :: M1 state 1 channels are all compensated with (z:p) = (0.9 : 30.9996) Hz
        :: M2 state 2 channels are all compensated with (z:p) = (64.9966 : 13) Hz
        :: M3 state 2 channels are all compensated with (z:p) = (64.9966 : 13) Hz

    - There are scalar "coil balancing" non-unity magnitude gains on each of the M2 and M3 stage channels, but it's the same values that have been in play since Jan 2014 (LHO:9419; so, after the M2 TACQ driver mod, but before the M3 TACQ driver mod). There is no coil balancing gains on the M1 stage, they're all either +/- 1.0.

WP12274

FAMIS28946

We rebooted the h1guardian1 machine today for 3 things:

1. Point the machine back at nds0 as the primary nds server
   • I noticed the other day that the guardian was still defining the chosen nds server as nds1 primary and nds0 as secondary. I'm not entirely sure when this was changed, but maybe 2 years ago (alog66834).
   • This was done by changing the NDSSERVER definition in the /etc/guardian/local-env file
2. Relieve any stale processes that might latch the gps leap second data.
3. Quarterly machine reboot FAMIS task

All 168 nodes came back up and Erik confirmed that nds0 was seeing the traffic after the machine reboot.