Jennie W, Sheila

I noticed yesterday that the power reported as being reflected from the OMC is more than the power reported entering HAM6 (see this alog #87629). This does not affect any controls, but it does affect anyone who is using this channel to do comissioning tests.

Sheila checked this alog for the calibration of OMC-REFL_A PD, alog #65082. It looks like there should be a -20dB switch on in the filter bank when the gain is set to 20dB:

FM7/8 should be the inverse of H1:OMC-REFL_A_DC_GAINSETTING (e.g. enable "-20dB" if the gain is 20dB)

Checking the screen we found the gain setting was set to 0 on the front-end side but the '-20dB filter bank is still turned on. We have turned this filter bank off (see image with relevant parts circled), but the front-end H1:OMC-REFL_A_LF_OUT value still does not match the Beckhoff value, H1:OMC-REFL_A_DC_POWER.

Looking back at our last long lock (when the -20dB filter was still on) you can see that the OMC-REFL_A_LF_OUT16 and OMC-REFL_A_DC_POWER are off by a factor of 100 even though they are both supposed to be in mW. Therefore our switch off of the -20dB filter will not correct this problem and the rest of the calibration of this PD in the front-end filters needs more investigation.

Wed Oct 22 10:08:38 2025 INFO: Fill completed in 8min 34secs

Gerardo confirmed a good fill curbside

Sheila, TJ, Oli, Matt

We reverted the ASC gain changes (87582) setting INP1 P to 1 and CSOFT P to 25 at MAX power (rather than 30).  Most of our locklosses overnight were from states before Max power, so the CSOFT P gain can't have been the problem, but we are undoing it for now just for the sake of reverting recent changes. 

We looked at one of the overnight locklosses, it seems that MICH is ringing up at 4.7 Hz.  Since Oli is sitting at 2W DCreadout to damp violin modes, we measured the MICH OLG there, and we see it is pretty close to unstable at 5Hz, with low coherence there.  We added a factor of 2 gain in LSC MICH2, to bring the UGF to 10 Hz similar to the references, and give us 35 degrees phase margin. 

Next we checked the SRCL UGF, which is also locked on POP45, and it's gain looks low by a factor of 5 compared to the reference.  This loop has a large phase bubble so it's still stable. POP 45 whitening gain and filters seem to be the same as a few days ago, and the POP LF power is the same as it was a few days ago at 2W.  PRCL gain also looks low compared to the reference, but is stable.  

We were able to get to OMC_WHITENING (almost to low noise), but while we were sitting there we had the old ring up.  We tried manually increasing the CSOFT P gain to 30, but the osciallation had already grown large and we lost lock anyway.  I've now put the csoft P gain back to 30 in max power in the guardian.  

TITLE: 10/22 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: USEISM
    Wind: 6mph Gusts, 4mph 3min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.45 μm/s 
QUICK SUMMARY:

Currently in IDLE due to locking issues and high violins from overnight. Going to start relocking and hopefully an LSC expert will be in by the time we make it to the LSC ringup issues.

I've just set H1 Manager and H1 Notify to IDLE.  And I set ISC_LOCK to DOWN so it's sitting in Prep for locking (Since Manager had just requested NLN before I caught it).  

When I woke up and had a look at control room screens, I saw that the violins were *very* high, as a result of our many attempts to lock (which I had suggested Ibrahim do, when he and I talked at midnight).  Anyhow, there's no way the IFO is going to lock itself with these violin ringups, and it's ~2 hours until shift start, so I'm just setting the IFO to DOWN to at least stop making the violin modes worse. 

I hope I've done it correctly, in a way that won't wake Ibrahim up, since he's already been up with the IFO all night (see his many alogs).

Attached is a screenshot of the violins at our last lock attempt.  Certainly these will need to be addresed as we relock in the morning.  I'm not sure if they are part of the reason it's been challening to relock after maintenance - I assume not, but they definitely could be causing trouble even if Ibrahim was able to fix some guardian things (I didn't look carefully at / read about his overnight work yet).

After some digging, I found that this is not a new issue and was commented on briefly earlier today.

Alog 87625 shows a near-identical screenshot to the attached MICH LSC ringup, which Oli was experiencing during their DAY shift and no doubt Ryan C also experienced during EVE.

In this alog Sheila noted: "This change should have made a 5% change in the loop gain, so if this was the reason for the lockloss one of our loops is very close to unstable."

I believe since we've lost lock around here for the fifth time now, with all of them showing this ringup, that one of our loops is probably very close to unstable. 

What's weird is that from the wording of that alog - the power scaling reversion should have fixed this issue - but it didn't?

So either the power scaling change reversion wasn't loaded/done OR this is an entirely seperate issue.

Well, I checked and it seems this was indeed reverted and we're scaling based on IMC_PWR_IN_OUTMON. 

Maybe this is a seperate loop instability issue or a microseism issue or a combination then..

H1 Lockloss Tool is Tagging ADS Excursion on all of these, if it's relevant.

Got called at 11:15 PM (PT) due to IFO unable to lock DRMI. Ryan C had warned me before the end of his shift. The issue doesn't seem to be alignment since Initial Alignment was run 3 times over the course of the EVE shift and flashes look sufficient (if not great) to lock. I touched up the BS and PRM in PRMI to no avail. Requested MICH_FRINGES and we'll see if that helps the PRMI lock.

SEI_CONF is not in its nominal position but that seems intentional since the EY sensor correction was turned off today (alog 87634) due to an unrelated issue that happened during maintenance. 

In terms of microseism, it's high but it's not that high and we've locked at this level with higher winds in the past week. 

I will continue monitoring to see what happens but will resort to the call list if I'm not getting anywhere. I believe we've been unlocked for over 24 hrs now.

TITLE: 10/22 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY: The furthest I've been able to get was MAX_POWER, I had several high state locklosses at different states (REDUCE_RF45, MOVE_SPOTS, MAX_POWER). I minimized the SHG rejected power while relocking as I saw the notification. After the second IA things went pretty well at first, microseism was still at about the same level as earlier. One of our locklosses at ALS had a BRS_GLITCH tag, which are rare. All of the LLs had an ADS_EXCURSION tag and most of the higher state locklosses I saw a ~4.5Hz oscillation in MICH. I started another IA at 21:45 as DRMI is taking a while to lock and it ran through CHECK_MICH on the last aquistion. Microseism has remained elevated and even increased a tiny bit. The IMC is really struggling to relock after INPUT_ALIGN, its been trying for the past 6 minutes as of 05:00.
LOG:                                                                                                                                                        

• 00:21 Going through PRMI didn't help the power but it did improve the beamspot, then in DRMI camera spot looked good after I tapped on SRM a bit but ASC turning on strongly knocked it out.
• 00:45 IA
• 01:44 UTC Lockloss at REDUCE_RF45, ~4.5 Hz ringup seen in MICH and PRCL
• 02:35 UTC MOVE_SPOTS lockloss, same ~4.5Hz ringup 
• 03:24 UTC MAX_POWER lockloss
• 04:20 UTC Earthquake mode

Something happened with BRSY this morning during maintenance that caused it to ring up more than normal and now the damping is not behaving quite as expected. For now, I have paused the ETMY sensor correction guardian with the BRSY out of loop and turned off the output of the BRS so it won't be used for eq mode, should that transition happen.

So far today, I did a bunch of "recapturing frames" in the BRS C# code, which has usually fixed this issue in the past. We also restarted the beckhoff computer, then the plc, C# and epics ioc. This did not recover the BRS either. Marc, Fil and I went to EY and looked at the damping drive in the enclosure and I think it was behaving okay. When the drive came on, the output would reach ~1.8V, then go to 0V when it turned off.

I've contacted UW and we will take a look at this again tomorrow. 

Added an option to the OSEM estimator filters for PR3/SR3 that allows us to get v1 filters.

The v1 filters use the model at the first two L/P resonances of the SR3 and PR3 suspensions. [see images attached for an example of v2 vs v1]

The functions that construct these blends are the same ones posted in [LHO: 87613] and [LHO: 87596]:

blend_{PR3,SR3}_{length,pitch}v2_LP_est.m
The files must be run with the argument 'v1' to get the v1 filters out. For example, blend_PR3_lengthv2_LP_est('v1') will get the v1 filters for H1 PR3 in length.

If you run them with anything else (including no argument), they will get the v2 filters, same as before. However, I suggest running them as blend_PR3_lengthv2_LP_est('v2') in automated code so everything is clean for loading the filters into foton.

These changes have been committed to the SVN under revision 12745.

[Jim, Jonathan, Erik]

BRS EY was restarted to try to damp high amplitude oscillations that started around 08:50 PDT.

We shutd down the processes in this order:

Epics

University of Washington process

TwinCAT PLC software

Then we restarted the server and started the same process in reverse order from desktop icons.

The restart did not have any apparent effect on the oscillations.

M. Todd, S. Dwyer

This morning we were not locked before Tuesday maintanence, so I skipped the HWS transient measurement and started immediately with the IMC and input jitter measurements I had planned. For posterity, the IFO was unlocked but the IMC was locked and input power taken to 62W, and then the ISS was turned on.

I continued attempting to tune injections of the IMC DOFs, but was not able to see any coherence to either the corresponding DOF error signal or the ISS loop, in the bands I was interested in. I think the DOF loop bandwidths are just tooo low for this kind of measurement without saturating the suspensions. I may continue to try some very small bands but nothing above 15 Hz anymore, as I'm just not convinced there is any reasonable coupling to the ISS there. The list of figures shows the injections from this injection set.

I then took some coherence measurements of the various sensors to the IMC ASC/LSC with the ISS loops during a quiet locked time to wrap my head around things better, and noticed a large coherence between the ISS first loop diodes and the ISS second loop witness sensor. I was initially confused by this but after talking with Keita, this is not surprising as there is most likely intensity noise that the 2nd loop is seeing and suppressing and thus imposing that suppression into the first loop sensors (thus the coherence).

Then I did some input jitter excitations, and without actually calculating the transfer functions ( those estimates will come later in a comment using Sheila's excess power code, due to the lack of coherence to ISS ) I don't think the ISS loops are limited by the input jitter at these frequencies. The list of figures shows the plots from this injection set.

List of Figures

1. DOF_1_Y_IN1 during injection , ISS 2nd Loop RIN OUTER during injection
2. DOF 3 P IN1 during injection, ISS 2nd Loop RIN OUTER during injection
3. PZT P OUT during injection, ISS 2nd Loop RIN OUTER during injection
4. PZT Y OUT during injection, ISS 2nd Loop RIN OUTER during injection