Summarizing some thoughts regarding the sqz levels at LHO going into O4. Best-case, we've observed up to 4.5dB DARM noise reduction with squeezing at 50W and 60W. Ignoring phase noise, this 4.5dB sqz is about 30-35% total sqz losses (~19% known, ~15% mystery). At 76W at start of O4, we've typically seen 3-3.5 dB at high frequencies, and almost up to 4dB once (we can hopefully recover this after fixing on-table alignments). Some of the major questions that I'm thinking about, towards more squeezing at LHO:

1. IFO output losses – is shot-noise-limited displacement sensitivity consistent w/circulating arm power? (LHO:67610)
   • ~13% known SQZ output losses (sqz budget)
   • Model suggests ~20-30% total IFO output losses (i.e., reconcile quantum noise calculation for no-sqz DARM with arm power). How do IFO+SQZ output losses relate?
   • LHO:69707, measures only 82% ham6 carrier throughput. Seems relatively consistent w/previous measurements ~20% output losses.
     - new thoughts on the losses this time-- a lossy OMC (92% throughput?)    
     → updates known total sqz losses to ~19%.  if only these known losses + good phase noise, we could see up to 6dB sqz (nearly what L1 sees).
     - still leaves ~7% excess ham6 ifo loss    (could this be ifo-omc mode-matching? TSAMS?)
     - in principle, SQZ-OMC could have different mode-matching than IFO-OMC, so output losses like this could be different between sqz / ifo (unlike omc losses, which would be common).
   • To-do: precisely measure OMC finesse? Is it worse now? Could tsams help? Is this ifo power dependent?
      
2. IFO technical noise – how shot-noise-limited is DARM? 
   • SQZ can reduce quantum noise, which only helps up to the next limiting noise source. That is, if there's no quantum noise (or infinite squeezing of it), DARM will simply be limited by the next thing.
   • 76W H1 noise budget suggests only shot-noise-limited by about 3-6x @ 1kHz?  
     • 69767, this level of classical noise can look like an effective 5-10% sqz loss.
     • Comparison: L1 noise budget shot-noise-limited by >10-fold @ 2kHz, with sqz (a lot more clearance)
        
3. SQZ losses – what are excess sqzer losses, and does sqz introduce its own technical noise?
   • ~7% known sqz injection losses (w/o mode-matching)  (sqz budget)
     • In addition, homodyne sees < 10% excess mystery sqz loss 67219 (so total in-chamber losses < 17% (from e.g. clipping), much of this loss is likely related to HD and not ham7)
   • CLF can introduce sqz technical noise, projected at ~5-10x below DARM, 68991
   • Phase noise? can re-measure loops
   • To-do: can we directly measure sqz losses (vary gen sqz, more NLG sweeps on darm)? use absolute calibration of the ADF line to measure sqz losses? optimize sqz alignment? Psams? sqz loops/phase noise? Fc backscatter (could contribute to #4)? Recover homodyne to check sqz? Can we even observe changes in sqz level given the large losses + drifty technical noise? Helps to have stable ifo for sqz commissioning. And there's probably more thinking to be done re: what are good measurements to make.
      
4. Is there residual noise ~50-200 Hz related to the squeezer? Is it worse at higher power? Related to RPN or backscatter (e.g. LLO:64968, 65120)? Can we make it better? How? This noise is not obviously quantum noise (started analysis previously, w/some evidence of it), but need to compare it no-sqz vs. sqz with the quantum subbudget to confirm
   • To-do: more modeling of high + low power scenarios to learn what various knobs do, more commissioning, etc, but not sure yet..

I've turned off some empty filters modules that were engaged following LHO70179 for some violins modes (ETMY9, ETMY19, ITMY18, ITMY19), damping (SUSETMY) and monitoring (SUSPROC) filters. I've accepted the following in SAFE and OBSERVE.

STATE of H1: Lock Aquisition

In observing at 23:03UTC out at 02:45UTC from the lockloss

We had a fast lockloss at 02:45UTC, DCPC saturated right beforehand. No obvious reason for the lockloss.

J. Kissel

There's an on-going debate whether we prefer 76 W (now 75W) PSL input power vs. 60 W PSL power, because we think that we had better noise performance at 60 W. It's a great debate, and I'm all for it. One thing I want to make super clear -- the lack of duty cycle during the engineering run and through the start of O4 has *NOT* been because of the increase in power from 60W to 76W. We've had one heck of a couple of months in terms of 
    (1) An insidiously slow drift in yaw on all of our HAM ISIs due to an innocent oversight of a foton-induced copy-and-paste error in ISI RZ blend filters (now fixed)
    (2) Literally every Tuesday for the past 4 Tuesdays, we've had a 1 deg C (~1-2 deg F) rapid temperature excursion in the LVEA, and some not even on Teusdays
    (3) A particularly earthquake full couple of months
    (4) We've had 3 or 4 inadvertent, system-wide, inter-computer communication "dolphin" crashes, sometimes causing a day of confusion from settings lost
    (5) Several electronics chassis fail all inadvertently

Further, (1) and (2) caused all sorts of apparent trouble that we interpreted as PR3 alignment / ISCT1 alignment troubles, and thus there may be some residual noise knock-on effects as a result.

Indeed, though I don't yet have the quantitative evidence to prove it, I think our issues with (1) and (2) drove us to move PR3 into a different position -- which in turn pushed the arm cavity spots to a different position onto a different point absorber/ acoustic mode situation -- which in turn caused our problems with "a new PI" at the start of the run -- and drove the choice to decrease the ETMX Ring Heater power -- which then drove us to decrease the power from 76W to 75W.

All of these issues cropped up right around the increase in power, and have continued through the start of the run, so I think some -- including myself -- had gathered an incorrect impression that H1's low duty cycle at the start of the run has been because of the power increase. With the trends in this aLOG, I argue it has not.

Check out the attached past 3 months worth of trends, in both relative time axis and absolute UTC time axis. 

Remember, the observing run starts -15 days ago, or on May 24 2023 at 15:00 UTC.

1st panel: IMC input power, in Watts, showing the transition from 60W to 76W

2nd panel: residual HAM-ISI position in RZ, in nanoradians, showing the 10-20 urad drift of the tables due to (1)

3rd and 4th panel: temperature zones in the LVEA, in deg C and deg F, respectively, showing the last 4 Teusday's worth of temperature excursions

5th panel: all test mass ring heater power level settings, in Watts showing the early explorations of ring heater settings after power up, and the ETMX reduction during the HAM ISI alignment excursion (the upper half is shown, but both upper and lower halves are set equally each time)
 
6th panel: 0.03 - 0.1 Hz BLRMS of the ground motion at each of the three buildings, showing the "earthquake and wind" band, highlighting (3)

7th panel: PR3's yaw alignment slider, indicating that we've been steering PR3 around all over the place only in the past 4 weeks, likely a result of the ISI yaw drifts (1) and temperature excursions (2).

There have again been a few instances of the 4.05 Hz harmonics that were tracked to scattered light from the ETMX cryobaffle (alog 69578) and mitigated by making changes to the fans (alog 69635). They appear slightly different on the summary pages now because they now use cleaned h(t) which makes the harmonic at 16 Hz visible. The spectrum looks otherwise the same.

TITLE: 06/07 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing
SHIFT SUMMARY: Just got back to NLN from a lock loss. Recovery today has been mostly hands off. The lock losses today are still unknown and need more people to keep looking at them.

• Lost lock at 1635 - lock loss 1370190932
  • Reacquired fully automated
  • Observing 1749 UTC
• Lost lock at 2107 UTC - 1370207267
  • Reacquiring DRMI wouldn't catch even though it had what looked like good flashes. The camera showed some yaw misalignment, even after PRMI was run. It lost lock, and then after it came back to this point it eventually caught after running another PRMI. I was impatient and tried to move SRM before PRMI ran this time, but made it worse and reverted. These two lock attempts were slowed down by ALS. It wouldn't catch on either arm, despite decent flashes, so increase flashes was run for both arms. We might need to look into speeding this up.
  • Observing 2303 UTC

LOG:

J. Kissel

E.J. identified recently that there were some filter modules which were requested to be ON, but had no filter in them -- see LHO:70179.

Between lock stretches, I reviewed the H1OAF filter banks,
Front-end    Filter Bank                   Module        Function
h1oaf :      'OAF-CAL_SUM_DARM_L1',        'FM3',        An old, very much defunct, uncommissioned, and unused version of the DARM calibration
             'OAF-CAL_SUM_DARM_L1',        'FM6', 

             'OAF-CAL_SUM_DARM_L3',        'FM3'

h1calcs :    'CAL-CS_DARM_ANALOG_ETMY_L1', 'FM4'         An unused, out-of-date filter bank for calibrating ETMY's UIM stage (which is not currently out DARM actuator)


And found that they can be safely turned off without issue.

I've turned these filter requests OFF and accepted that "offness" in SDF to reduce confusion.
Both h1oaf and h1calcs are one of those front-ends whose OBSERVE and safe.snaps are the same, so accepting is good enough preserve this setting.

Vicky and I have been looking into how the 80 kHz PI29 dampens or leads to a locklosses recently (alog 70161) .

I looked between 05/24/23 to 06/06/23 and recorded the few dates that this channel witnessed instability and either dampened or did not dampen the issue.

DAMPENED, 600 NLN, May 27 2023 02:41:18, PI managed to keep the detector from losing lock, this lasted about 6 minutes 19s

DAMPENED, 600 NLN, May 28 2023 04:02:31, PI managed to keep the detector from losing lock, this lasted about 5 min 45s

LOCKLOSS, 600 NLN, May 29 2023 07:42:54, PI did not manage to dampen the mode and the IFO lost lock, this lasted about 2 min 30s (power was changed from 76 W to 75 W after this date)

LOCKLOSS, 600 NLN, June 02 2023 20:13:27, PI did not manage to dampen the mode and the IFO lost lock, this lasted about 3 min 48s

DAMPENED, 600 NLN, June 02 2023 23:55:58, PI managed to keep the detector from losing lock, this lasted about 6 min 8s

Images for reference.

edit:

comparing the two cases that were near eachother on 06/02/23, it seems the first one at 20:13:27 which lost lock the IFO was at NLN and observing for about 2 hours and the second case at 06/02/23 23:55:58 which kept lock the IFO was at NLN and observing for just a bit over an hour only, both had similar power ranges. (image 3).

TITLE: 06/07 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 13mph Gusts, 8mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.10 μm/s
QUICK SUMMARY:

• Taking over form TJ
• Currently relocking at OMC_WHITENING while the violins damp down a bit
• CDS/Wind/Dust looks good

J. Kissel

E.J. identified recently that there were some filter modules which were requested to be ON, but had no filter in them -- see LHO:70179.

Between lock stretches, I reviewed the H1HPIETMX filter banks,
h1hpietmx :
    ('HPI-ETMX_3DL4CINF_A_X', 'FM1'),    A bank screenshot
    ('HPI-ETMX_3DL4CINF_A_Y', 'FM1'), 
    ('HPI-ETMX_3DL4CINF_A_Z', 'FM1'), 

    ('HPI-ETMX_3DL4CINF_B_X', 'FM1'),    B bank screenshot
    ('HPI-ETMX_3DL4CINF_B_Y', 'FM1'), 
    ('HPI-ETMX_3DL4CINF_B_Z', 'FM1'),

    ('HPI-ETMX_3DL4CINF_C_X', 'FM1'),    C bank screenshot
    ('HPI-ETMX_3DL4CINF_C_Y', 'FM1'), 
    ('HPI-ETMX_3DL4CINF_C_Z', 'FM1')  
which are all generic *infrastructure* for spare, unused, analog inputs to HPI (named after an old idea, a 3D L4C, I had for a cheaper, better-at-10 Hz, ground-to-HEPI feed-forward sensor I had in 2011 that never got implemented). In the case of ETMX, this infrastructure can be confirmed to be spare and definitely unused, given that the inputs to the bank are connected to "electrical ground" at the top level of the front-end model which is advrts simulink code for digital zero.

These *must* have been turned on by mistake, or left on from some test (and then blindly accepted in the SDF as such).

I've turned these FM1 filter requests OFF and accepted that "offness" in SDF to reduce confusion.
They've been accepted as such in both the OBSERVE.snap and safe.snap files.

In addition, you can see in the B bank screenshot that there's an "Unknown" filter in the Y DOF's FM2. This is foton code for "the user didn't name this filter." Taking a look at the design of the filter in foton, it's an unnamed gain of 4.46. Who knows. I deleted the unused unnamed filter and re-loaded the coefficient file to clear it out to again reduce confusion.

There's a peak in DARM around 52 Hz (with a second bump just below 50 Hz) that has come and gone in DARM the last few days.

There's a noise source in the input optics mic that is in a similar frequency range. The noise in DARM could maybe be sidebands of the peak in the mic. The noise appears and disappears at some of the same times as in DARM, though the association is not that close.

J. Kissel

E.J. identified recently that there were some filter modules which were requested to be ON, but had no filter in them -- see LHO:70179.

Between lock stretches, I reviewed the H1SUSZM1 and H1SUSZM2 filters,
Bank                              Filter Module          Bank Function
SUS-ZM1_M1_WD_OSEMAC_RMSLP_LL     FM6                    To low-pass the 0.1 to 10 Hz band-limited RMS signal 
                                                         of the top mass OSEMs. Only one filter is needed, and 
                                                         by convention that "10s" filter is in FM1
SUS-ZM2_M1_LOCK_L                 FM6                    The *infrastructure* is there generically for longitudinal 
                                                         ISC control for cavity locking, but ZM2 is only a steering
                                                         mirror, not a part of any cavity.
and found that these *must* have been turned on by mistake (and then blindly accepted in the SDF as such).

I've turned these FM6 filter requests OFF and accepted that "offness" in SDF to reduce confusion.
Note that both of these suspensions' channels live in the h1sussqzin model, so it's the same SDF file. 
Further, the h1sussqzin model is one of those models where the safe.snap and OBSERVE.snap are the same file,
so accepting the changes in the "safe.snap" from the SDF GUI interface accepts it in the OBSERVE.snap as well.

Importantly, having these filters mistakenly ON has no, zero, nada, zilch impact on anything. I merely turn them off for peace of mind and preservation of sanity.

In addition to turning off ZM2_M1_LOCK_L bank's FM6, I've also turned off the bank's input, since it's physically impossible for anything but zero to be fed into this bank -- the input is connected only to a "electrical ground" symbol in the front-end model, which is the advligo rts symbol for a fixed value of "0.0."

We ran the functionality test on the main turbopumps in the corner during Tuesday Maintenance (6/6/23). The scroll pump is started to take pressure down to low 10^-02 Torr, at which time the turbo pump is started, the system reaches low 10^-08 Torr after a few minutes, then the turbo pump system is left ON for about 1 hour, after the hour the system goes through a shut down sequence.
No issues were encountered while performing the functionality test on this 3 stations.

Output Tube Turbo: Note: The flex hose connecting the turbo exhaust to the WTCB1 header line has been physically disconnected.

Bearing Life:100%

Turbo Hours: 5613

Scroll Pump Hours: 5555

XBM Turbo: Note: The flex hose connecting the turbo exhaust to the WTCB1 header line has been physically disconnected.

Bearing Life:100%

Turbo Hours: 777.4

Scroll Pump Hours: 778

YBM Turbo:

Bearing Life:100%

Turbo Hours: 596

Scroll Pump Hours: 1872

Lost lock at 2107 UTC - 1370207267

No immediate cause for this yet.

There are a number of models with filters in modules that have been engaged but no filter has been defined for that stage. This causes some confusion when scanning for unresponsive filter stages, as these will clutter the results. 
Attached is an example of what this looks like on the medm screen. FM2 is enabled, but nothing is loaded in that stage so the 2nd box never turns green. 

My guess is that these stages used to have a filter defined for them, but were removed. The solution is to finish the removal of these stages, buy disabling the stage and saving the new state with SDF. 

Full listing of filters/stages that are enabled but don't have the enabled stage defined in the filter file. 

h1susetmy : [('SUS-ETMY_L2_DAMP_MODE19', 'FM1'), ('SUS-ETMY_L2_DAMP_MODE9', 'FM4')],

h1sussqzin : [('SUS-ZM1_M1_WD_OSEMAC_RMSLP_LL', 'FM6'), ('SUS-ZM2_M1_LOCK_L', 'FM6')]

h1hpietmx : [('HPI-ETMX_3DL4CINF_C_Z', 'FM1'), ('HPI-ETMX_3DL4CINF_C_Y', 'FM1'), ('HPI-ETMX_3DL4CINF_C_X', 'FM1'), ('HPI-ETMX_3DL4CINF_B_Z', 'FM1'), ('HPI-ETMX_3DL4CINF_B_Y', 'FM1'), ('HPI-ETMX_3DL4CINF_B_X', 'FM1'), ('HPI-ETMX_3DL4CINF_A_Z', 'FM1'), ('HPI-ETMX_3DL4CINF_A_Y', 'FM1'), ('HPI-ETMX_3DL4CINF_A_X', 'FM1')]

h1lsc : [('LSC-EXTRA_AI_2', 'FM2')]

h1lscaux : [('LSC-LOCKIN_1_DEMOD_9_I', 'FM1'), ('LSC-LOCKIN_1_DEMOD_9_Q', 'FM1')]

h1oaf : [('OAF-CAL_SUM_DARM_L1', 'FM3'), ('OAF-CAL_SUM_DARM_L1', 'FM6'), ('OAF-CAL_SUM_DARM_L3', 'FM3')]

h1calcs : [('CAL-CS_DARM_ANALOG_ETMY_L1', 'FM4')]

h1susproc : [('SUS-ETMY_L2_DAMP_MODE19_BL', 'FM1'), ('SUS-ITMY_L2_DAMP_MODE18_BL', 'FM1'), ('SUS-ITMY_L2_DAMP_MODE19_BL', 'FM1')]

Edited to remove any filter stages under local control.