TITLE: 06/08 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 11mph Gusts, 8mph 5min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.07 μm/s
QUICK SUMMARY: IFO unlocked about an hour ago and Camilla has been struggling with ALS since. Troubleshooting.

After noticing a "double-spot" on one if the ITMY HWS points on May 26th, Dan suggested turning off the HWS SLED to understand where this scattered light is from. seems to have been there since 08 April ~19:30UTC.

Tonight I turned off the ITMY SLED 7:46 to 8:02UTC and 10:54 to 11:01UTC and the ITMX SLED 10:50 to 10:57UTC. After ALS has been shuttered and with both HWS SLEDs off.

• Scatter pionts on ITMX: (261, 597) , (261, 540)
• Scatter pionts on ITMY: (483, 355 <- WORSE ONE), (467, 380), (450, 354)
  • You can also see a little ITMX SLED leakage on ITMY camera (image with IX SLED on, IY off) but not the revserse.
• Scatter pionts seen on Tuesday 2023/05/09 17:30UTC when PSL input power was 0W, image, but scatter point in a slightly different location. So it isn't PSL light either...

Unsure what this light is. We could try turning down the HWS camera exposure to minimize some of it.

STATE of H1: Lock Acquisition

• Lost lock at 06:53UTC 1370242452- after 2h49 in NLN
  • NLN at 8:20, Observing at 8:22UTC.
• Lost lock at 10:04UTC 1370253889 - after 1h43 at NLN.
  • Due to earthquake. Currently re-locking well at state MAX POWER

H1 range channels and SenseMon are down 70271.

Control room channels H1:CDS-SENSMON_CAL_SNSW_EFFECTIVE_RANGE_MPC and H1:CDS-SENSMON_CLEAN_SNSC_EFFECTIVE_RANGE_MPC have not been reporting correct values since 08:21UTC, see attached.

The SenseMon Range FOM is reporting range fine  is also frozen at time 08:19UTC, see nuc27 screenshot attached. Omicron glitches are not updated as well. 

Noticed that although ISC_LOCK requests CAMERA_SERVO to go to CAMERA_SERVO_ON in state 578 (ADS_TO_CAMERAS), the CAMERA_SERVO gets stuck in DOWN as is returning False unil we are in NLN. The ADS scopes show the dither is on during this time, even if the CAMERA_SERVO guardian doesn't refect that. See attached plot of CAMERA_SERVO staying in DOWN as it's status is not ready.

If we want to go to the camera servo in ADS_TO_CAMERAS we should edit the NLN checker in DOWN, DITHER_ON, TURN_CAMERA_SERVO_ON and CAMERA_SERVO_ON. This will save us ~1 minute to get to Observing if ADS has already converged (happens if we pause to damp violins while locking).

TITLE: 06/08 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 5mph Gusts, 4mph 5min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.08 μm/s
QUICK SUMMARY: Just lost lock at 06:53UTC 1370242452 after 2h49 in NLN. Ryan and I watched CSOFT P ASC control signal ring up before the lockloss, plot attached. Tagging ISC.

VAC, SUS, SEI, CDS, dust monitors all Okay.

TITLE: 06/08 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 133Mpc
SHIFT SUMMARY:

Lock#1

We aquired NLN at 23:00UTC and went into observing at 23:03UTC, we went out of observing at 02:45 due to a lockloss.

Lock#2

Xarm went through increase flashes (~5minutes), then we went through PRMI which locked fairly quickly then DRMI locked.

The lockloss rang up a violins a bit so we had to wait in OMC_WHITENING for them to damp just like in the last lock

NLN at 04:04 UTC, in observing at 04:07UTC

Chris swung by to turn off the water pump from 23:05TUC to 23:15

LOG:                                                                                                                                                                                                                                  

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.

Lost lock at 2107 UTC - 1370207267

No immediate cause for this yet.

I think the recent issues with squeezer pump ISS railing are likely resolved after today's on-table realignments. The green pump AOM was significantly clipping the beam (SQZT0 layout here, "GAOM1"), both reducing the total power after the AOM, and degrading the fiber coupling efficiency due to the clipped+bad mode shape. See GAOM1 sweeps from this morning (before aligning, left) and now (after, right). Along the pump path, we now have better GAOM1 throughput (~90%), comparable diffraction efficiency (~60%), and improved fiber coupling. For 60uW opo trans we've been using, we previously launched 22mW with no buffer (hence iss railed); now we only have to launch 15mW for the same opo transmitted power, with lots of buffers.

GAOM1 typically has ~90% throughput, e.g. previously this was 14.4mW out from 16mW incident. Today I first measured 25mW out for 44mW incident (~57%): this means >30% of power from SHG was clipping on the AOM apeture. After re-aligning GAOM1 using the mount screws, we're back up to 40mW out for 45mW incident, so almost 90% throughput again. I think this could be better, but good enough for now.

Relieving the clipping also significantly improved fiber coupling efficiency, presumably b/c it improves the mode shape, as we are using the 0-th order AOM mode for pump light, and not the nice diffracted order that gets cleaned up in the diffraction. So aom clipping shows up on the beam we are trying to fiber couple.
-- Before, for 20mW into the pump fiber, we had 1.8mW on OPO_REFL_DC_POWER on the other end, with GAOM1 driven at 2-3V (almost no room), and all power on that path going into the fiber (SHG_REJECTED = 0mW).
-- After, for 20mW into the pump fiber, we have 2.9mW on OPO_REFL_DC_POWER (60% higher power), with GAOM1 driven at 4.5V (mid-range), and a healthy buffer of rejected power on the fiber path (SHG_REJECTED = 8mW).

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.