J. Kissel, O. Patane, S. Dwyer, E. Capote

Given the assessment of from LHO:84585, and its comment LHO:84587, I've reduced the gain of the RM1 and RM2 damping loops by a factor of 1.4x and 1.7x, by multiplying the ''gain_[DOF]'' filters by 0.75x and 0.6x, respectively. We intend to remeasure the open loop gain TFs and loop-suppressed plant measurements as the opportunity arises between lock acquisitions.

Here's the diff of the filter file design string, which has been now committed to the userapps svn as of the following commit rev:
    /opt/rtcds/userapps/release/sus/h1/filterfiles$ svn diff H1SUSHTTS.txt | grep DESIGN | grep -B 1 +#
    -# DESIGN   RM1_M1_DAMP_L 3 gain(0.01)gain(70)
    +# DESIGN   RM1_M1_DAMP_L 3 gain(0.01)gain(70)gain(0.75)
    --
    -# DESIGN   RM1_M1_DAMP_P 3 gain(2e-05)gain(70)
    +# DESIGN   RM1_M1_DAMP_P 3 gain(2e-05)gain(70)gain(0.75)
    --
    -# DESIGN   RM1_M1_DAMP_Y 3 gain(5e-06)gain(70)
    +# DESIGN   RM1_M1_DAMP_Y 3 gain(5e-06)gain(70)gain(0.75)
    --
    -# DESIGN   RM2_M1_DAMP_L 3 gain(0.01)gain(70)
    +# DESIGN   RM2_M1_DAMP_L 3 gain(0.01)gain(70)gain(0.6)
    --
    -# DESIGN   RM2_M1_DAMP_P 3 gain(2e-05)gain(70)
    +# DESIGN   RM2_M1_DAMP_P 3 gain(2e-05)gain(70)gain(0.6)
    --
    -# DESIGN   RM2_M1_DAMP_Y 3 gain(5e-06)gain(70)
    +# DESIGN   RM2_M1_DAMP_Y 3 gain(5e-06)gain(70)gain(0.6)
    /opt/rtcds/userapps/release/sus/h1/filterfiles$ svn commit -m "Adjusted RM damping loop gain to account for increase in plant TF magnitude after Apr-Jun 2025 vent. See LHO aLOGs 84585, 84587, and 84590." H1SUSHTTS.txt 
    Sending        H1SUSHTTS.txt
    Transmitting file data .done
    Committing transaction...
    Committed revision 31533.

I then
- turned OFF the damping loops' output switch,
- loaded the coefficients
- turned ON the damping loops' output switch.
all while the DC centering loop alignment integrator's DAC request was still in place. That DAC request was in the 100s of Euler Basis DAC counts (the outputs of the LOCK banks), and the damping loops' DAC request was in the 1s of Euler basis DAC counts (the outputs of the DAMP banks). The damping loops request a trivial amount of DAC range.

Monthly Hanford Alert test Expect Sirens at 20 UTC (1PM local).

The monthly no-flow fire pump test was conducted this morning from ~10:30 to 11:00.

J. Kissel, O. Patane

Hearing hints that ''issues'' still remain with the RM damping loops, we continue to dig in the list of actions from LHO:84462. Here, we report the current status of the damping loop open loop gain transfer functions (and corresponding loop suppression). We several things:

(0) The open loop gain transfer functions (OLG TF, or just  G) confirm that the damping loops are stable, and regardless of the individual sign quirks of the sensors and/or actuators in the current analog / digital configuration (currently the same as described in LHO:84462).

(1) The OLG TF magnitudes have larger overall scale magnitude in all DOFs for both RM1 and RM2. Could be expected, as we completely removed the OSEMs and re-centered them during the Apr - Jun 2025 vent (see LHO:84178).

(2) Around the UGFs, between 1 - 3 Hz, the OLG TF's frequency response has changed dramatically. I'm attributing this to the dramatic change in magnitude of the cross-coupling between DOFs -- see pages 4 thru 9 of RM1 and RM1 ''health check'' undamped plant transfer functions, P, from LHO:84543. Also expected because we completely removed the OSEMs and re-centered them. In hopes to investigate the magnet polarity in the actuator, we also grabbed the flag/magnet system and tried to remove those; so it's also quite possible that the also changed position / alignment of the flag/magnet changed too (even though they couldn't completely remove it), augmenting the cross-coupling.

For suspensions "so simple" we usually try our hardest to ignore that the plant is a full 3x3 matrix. Since the beginning of time, we treat the damping loop plants as a diagonal matrix such that we can treat each DOF as a SISO loop and use an independent controller for each DOF. But clearly there is MIMO action going on here, as the diagonal TFs linked from those same plots of LHO:84543.

(3) Both (1) and (2) means that (the phase margins of G) and/or (the loop suppression transfer functions [1/ (1+G)]) have changed for the worse. If you want to quantify it with gain peaking alone, both RM1 and RM2's P to P loop suppression are the worst, increasing from magnitudes of ~1.5x to 3.5x. But, don't do that. Look at the plots. 

Because the frequency response of G and [1/(1+G)] has changed ''just'' changing the overall loop gain won't return the frequency response to the expected value. It'll likely be ''good enough'' for the RM damping loops, but ...

(4) ... given that the damping loop's loop-suppression is dramatically different in the 1-3 Hz region, that also means that frequency response of the loop-suppressed plan, P/(1+G) -- which serves as the plant, P', for any *other* loops wrapped around it -- has changed. *That* could very well be the ''issues'' with the REFL WFS detector's DC centering loops -- which may have UGFs in the 1-3 Hz region.

More to come!

Jenne, Camilla

After Ryan re-calibrated the PSL rotation stage in 84553, we still weren't getting the correct IMC_IN power. This morning Jenne and I checked this and it seemed that our original powers were too low and the bootstrapping brought it too high.  We re-calibrated, results attached. SDFs accepted.

After testing the power seems to be a lot better, we expect that it wa just far off enough when Ryan initially calibrated that it needed a second iteration.

We tested going to 2W and 10W from powers below and above and see a little hysteritis in the measured power. However, as we normally are increasing powers by increasing angle, this hysteresis shouldn't be an issue as this is the direction we calibrate in.

The chiller systems at the mid stations were started this morning for the season. 

Tue May 27 10:09:04 2025 INFO: Fill completed in 9min 0secs

Attached is the analysis of the TDR and delay measurements for the REFL and POP RF sensors.

The 2 columns labeled "phase TDR" and "correction phase" are the calculated phase shifts from the TDR and phase measurements, respectively. A longer cable between the RF sensor and the demodulator will make this phase shift more negative (modulo 360°).

If I got the signs correct, this number needs to be subtracted from the current phase shift values. This is indicate in the highlighted column labeled "new Phase". If not, one can try the column "wrong Phase".

Matt, Camilla, Sheila

Once the X and Y green arms were locked, Matt and I measured their powers on ISCT1, straight after the prism.  Sheila took H1:ALS-{X,Y}_REFL_LOCK_TRANSPDNORMTHRESH from 0.8 to 0 so that we the arms would stay locked while we blocked the beams. Measured:

• 1.25mW on ALSX
• 1.75mW on ALSY

TITLE: 05/27 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 6mph Gusts, 4mph 3min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.10 μm/s
QUICK SUMMARY:
The goal is to start locking and follow the steps outlined in the commissioning document https://docs.google.com/document/d/1P6JXVV_bhdN2M5k2PLoa0tu-AmY-PiC98zZ0nzBIJ2I/edit?tab=t.0
H1 Is currently going through a manual Initial alignment " Without Green Cameras".

 

We are down to two temporary EPICS IOCs running on opslogin0 which need to be restarted following reboot of opslogin0:

digivideo_dummy_ioc: We moved some critical cameras to the new server, but found that they needed image masking so they were returned to h1digivideo2, but the DAQ is expecting the new server's channels. This IOC provides the missing channels.

vac_ham1_pressure_converter_ioc: The Beckhoff calibration for HAM1 pressure is off by two orders of magnitude, this IOC creates a H1 HAM1 Torr channel, calculating the pressure from the gauge's raw voltage reading.

Workstations updated and rebooted.  This was an OS packages update.  Conda packages were not updated.

Mon May 26 10:11:15 2025 INFO: Fill completed in 11min 11secs

Sun May 25 10:12:57 2025 INFO: Fill completed in 12min 53secs

Sat May 24 10:16:47 2025 INFO: Fill completed in 16min 43secs

TITLE: 05/24 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY:

IFO is in ENGINEERING and DRMI has Locked! IFO is in DOWN until Tues.

The relock acquisition today was a success! While the expectation was to get through ALS before facing issues, we managed to lock DRMI and get all the way to CARM_TO_REFL (state 409).

Of note is that the BS is slightly off in that when we do lock DRMI, the AS camera shakes for a bit and the POP90 trace gets very noisy emulating the jitter almost. I can see as this is happening, F2 and F3 OSEMs are saturating indicating something off in the MICH length loop. Elenna lowered the gain slightly and while this allowed us to get past the DRMI state, it came back upon passing that state 409. As the PR_GAIN is ramping up, the trace either jitters before losing lock or it just loses lock very instantly. The current hypothesis is that this is something to do with the BS particularly in the MICH Length Loop.

For some reason, in our most recent lock attempt, the issue did not happen with the only configuration difference being that the WFs centering was turned on and correct. However, we still had that sudden lockloss at CARM_TO_REFL so the issues may not be related.

See Elenna's alog 84569 for details on tonight's recovery and lock reacquisition.

Other:

DC centering loops on the input matrix for the REFL WFs were flipped and oddly saturating RM2. Elenna discovered this after some troubleshooting and unflipped it - they were SDF accepted s well.

LOG:

None

Ibrahim, Elenna

In summary, we can make it to CARM to REFL!

Here are some notes about recovering lock. I am bolding the ones that I think are urgent/should be read by anybody who next attempts to lock this IFO.

• Before we even started this process, I set all DRMI and PRMI ASC to false except MICH ASC.
• Locking green arms is a very "smooth" process (read: ALSY sucks a normal amount)
• Locking ALS proceeded without any hitch, as well as the find and check IR states.
• I first had problems with acquiring DRMI, even though at first glance the POPAIR flashes looked good. I tried PRMI, with good flashes, still no luck. I eventually had to go through MICH fringes, even though we had just run a successful initial alignment.
• Any state where the power needs to change requires manualing in one or more guardians- the laser power guardian stalls because it gets stuck in some "10W idle" state.
  • This is likely due to miscalibration in the rotation stage. If you get stuck, just manual to the power you need!
• After MICH fringes I went back to PRMI, and moved the PRM endlessly with no luck until I nudged the beamsplitter and everything immediately locked. Puzzling, because we had run at least two different MICH alignments at this point.
• Even with PRC1 disabled in PRMI ASC, the guardian still runs WFS centering on ALL WFS, which means it will error because the WFS centering isn't working well on the REFL WFS right now. I again had to manual around the WFS centering stage so it could offload MICH alignment.
  • this ended up being an SDF error which I fixed, see further notes
• Manualing around in ISC_DRMI seemed to stall things out, and since I was playing fast and loose with the guardian, caused a lockloss when I clicked "init" (I was trying to remanage guardians).
• Next lock went fine and I went straight to DRMI lock. (no need for PRMI or MICH fringes)
• when DRMI caught lock, the AS AIR camera started shaking. Ibrahim saw that it was the beamsplitter, specifically F2 and F3 osems seemed to briefly saturate. I averted this problem by turning the LSC MICH gain down by 10% (MICH2 gain from 1 to 0.9).
• Guardian got stuck in acquire DRMI 1f because the WFS centering on REFL failed again. I manualed over again to avoid it.
• Everything proceeded very well, the alignment looked great, I ran all the way to "CARM to REFL" and something started shaking.
  • At lockloss, there was a beamsplitter saturation warning, so I think something is funky in either the MICH LSC or ASC loop.
• Next two lock attempts still required reduction of MICH LSC gain to get through DRMI.
• However, through the CARM offset reduction, Ibrahim and I could see a small oscillation in POP90. It seemed to go away when I put the LSC MICH gain back up to nominal. However, still a lockloss at CARM to REFL, but much faster this time.
• The FSS got stuck in an oscillation again and I toggled the autolock to get out of it.
• The WFS centering keeps saturating the RMs and I am not sure why. I tried to move the RMs to center on REFL A and B but got saturation warnings as I got the beam closer to center on the diodes.
  • This turned out to be because the input matrix values were flipped! Keita had changed the DC1 and DC2 input matrix values about two weeks ago, since REFL A and REFL B had been flipped in the electronics.
  • However, it appears this was never SDFed, and got reverted. Once I re-flipped the matrix, the WFS centering worked perfectly. SDF screenshot attached
• When relocking DRMI after I fixed the WFS centering problem, there was no more MICH LSC oscillation. The reason for this is not immediately obvious to me, since the WFS centering only effects the REFL WFS (not in loop at this time)
• One more time, I tried going through CARM to REFL. I stepped through the state by hand and found that the lockloss occurs at the last step, where the input matrix is loaded
  • # Transition between TRXY and REFLAIR

    ISC_library.intrix['REFLBIAS', 'TR_REFL9'] = 2.0 #put back from 3.0 to 2.0 on 09/10/2018

    ISC_library.intrix['REFLBIAS', 'TR_CARM'] = 0.0

    ezca['LSC-PD_DOF_MTRX_TRAMP'] = 0.2

    time.sleep(0.1)

    ISC_library.intrix.load()