J. Kissel

Betsy asked me to put together a prioritized list of 18-bit DACs that could be upgraded to 20-bit DACs during the upcoming Jan / Feb 2024 commissioning break in order to close out IIET:13232 and IIET:20828. We don't think we'll have time to do *all* the DAC upgrades during the break, and thus we again find ourselves asking the priority DACs / IO chassis to hit first.

I note that in IIET:13232, the last comment *attempted* to create this list what remaining "pum" stages needed upgrade based on what was *not* mentioned in LHO:66836, but the story is incomplete because IIET:20828 says that "we just need to upgrade them all."

So, here's the prioritized list of the 31x 20-bitDAC cards remaining to upgrade, granulated into 3x to 5x card swaps.
	(a) [2x] Close out [1] and upgrade PRM M2/M3, and PR2 M2/M3. 
		DAC5 (Slot 8, card_num = 5) on h1sush2a for PRM
		DAC4 (Slot 7, card_num = 4) on h1sush34 for PR2
	(b) [2x] Upgrade PR3/SR3 M2/M3 DACs
		DAC6 (Slot 9, card_num = 6) on h1sush2a for PR3
		DAC3 (Slot 6, card_num = 3) on h1sush56 for SR3
	(c) [1x] Upgrade ITMX and ITMY UIM DACs
		DAC4 (Slot 8, card_num = 4) on h1susb123
	(d) [3x] Finish out susex IO chassis upgrades (which is ETMX M0 / R0 and TMSX M1)
		DAC0, DAC1, DAC2 on h1susex
	(e) [3x] Finish out susey IO chassis upgrades (which is ETMY M0 / R0 and TMSY M1)
		DAC0, DAC1, DAC2 on h1susey
	(f) [5x] Finish out susb123 IO chassis upgrade (which is ITMX M0/R0, ITMY M0/R0, and BS M1)
		DAC0, DAC1, DAC4, DAC5, DAC9 on h1susb123
	(g) [3x] MC2 M2/M3, MC1 M2/M3, MC3 M2/M3
		DAC3 (Slot 7, card_num = 3) on h1sush34 for MC2
		DAC3 (Slot 6, card_num = 3) on h1sush2a for MC1
		DAC4 (Slot 7, card_num = 4) on h1sush2a for MC3
	(i) [3x] MC1/MC3/PRM/PR3 top masses
		DAC0 (Slot 2, card_num = 1) in h1sush2a for MC1/MC3 M1
		DAC1 (Slot 4, card_num = 1) in h1sush2a for MC3/PRM M1
		DAC2 (Slot 5, card_num = 2) in h1sush2a for PRM/PR3 M1
	(j) [3x] MC2/PR2/SR2 top masses
		DAC0 (Slot 2, card_num = 0) in h1sush34 for MC2/PR2 M1 
		DAC1 (Slot 4, card_num = 1) in h1sush34 for PR2/SR2 M1
		DAC2 (Slot 5, card_num = 2) in h1sush34 for SR2 M1
	(k) [4x] SRM/SR3/OMC top masses
		DAC0, DAC1, DAC2, DAC3 in h1sush56
	(l) [2x] IMs
		DAC0, DAC1 in h1sush2b

Of course, you can group the lower priority stuff in larger chunks, if you like and/or if you don't want to drag out the upgrade across many days.

Or if it's easier to replace an entire IO chassis DAC cards, rather than think about / risk the mistake of replacing the wrong card, you can do that too (this is what LLO did in the end).

If you want to do it by IO chassis, here's a prioritized list for that instead:
	(b) h1sush2a (to get the PRM, PR3 M2/M3's up to 20-bit DACs, you'll get all the less important MC1 / MC3 M2/M3 stages and top-masses with this "for free")
	(c) h1sush34 (to get PR2's M2/M3 up to 20-bit DACs, you'll get all of MC2 and the rest of SR2 upgrades "for free")
	(d) h1sush56 (to get SR3's M2/M3 up to 20-bit DACs, you'll get the top-masses of SRM and SR3 "for free")
	(a) h1susb123 (to get the ITM UIMs up to 20-bit DACs, you'll get the ITMX, ITMY, BS top masses "for free")
	(e) h1susetmx (to finally get all the end-station top masses done)
	(f) h1susetmy (to finally get all the end-station top masses done)
	(g) h1sush2b (to get the IMs)

Note that there's a few discrepant documents out there quotes a total count of 
    - "29x," (Keith's Mar 2023 inventory, E2300281) 
    - "30x," (Fil's re-inventory in Sep 2023, as a part of the A+ O5 review E2300309) 
    - and here I quote 31x cards.
I would guess that this discrepancy results from folks missing a DAC or two here or there; could be, for example, that the IMs were overlooked.
If we don't have the cards for the IMs, that would be the first set of 2x 20-bit DACs that I would suggest we convert to 1x 16-bit DACs (and change the AI chasis, accordingly).

Maintenance has completed, we will begin relocking.

Work done by Patrick Thomas and Jonathan Hanks

WP11473 was completed.  We adjusted the network setup of the h1digivideo0-2 machines to match h1digivideo3.  Now all 4 systems are dual homed, with one interface on the workstation subnet and on the aux/camera network.  This allows for a simpler multicasting network setup (and matches LLOs setup better).  This is done as a preparation step for eventual replacing the core network switch in CDS (with a simpler multicast setup).

We updated the DNS to move h1digivideo[0-2] to the 10.22... network and added h1digivideo[0-3]-cam entries to reference the 10.106... network entries for the systems.

WP11468 was to reboot the h1digivideo0-2 machines.  We did this as part of our check that things where working after the network changes.  The idea was to restart the system to clear up some long running memory leaks.

As the FSS RefCav TPD has been trending down and a remote alignment did not improve it, I went into the PSL enclosure this morning to tweak the beam alignment on the table.  All work was done with the ISS ON unless otherwise noted; I had to increase the ISS RefSignal from -2.00V to -1.98V to keep the ISS stable with the enclosure environmental controls ON.  In addition, the IMC was OFFLINE for the duration of my time in the enclosure.

I started by taking a power budget of the FSS path:

• FSS In: 290.9 mW
• AOM In: 289.9 mW
• AOM Out, Single-pass: 175.0 mW
  • Single-pass diffraction efficiency: 60.4%
• AOM Out, Double-pass: 125.7 mW
  • Double-pass diffraction efficiency: 71.8%
• EOM Out: 125.7 mW

Seeing the single-pass diffraction efficiency low, I adjusted the AOM alignment to improve it; the AOM had to be moved DOWN.  This resulted in the single-pass AOM output at 216.9 mW and a single-pass diffraction efficiency of 74.8%.  The double-pass AOM output was then measured at 155.4 mW, so I adjusted mirror M21 to see if I could improve it.  This resulted in the double-pass AOM output at 160.1 mW and a double-pass diffraction efficiency of 73.8%.  Much better.

I then double checked the beam centering on the EOM, which was good so I relocked the RefCav.  I needed to adjust mirror M23 slightly in pitch to get the RefCav REFL beam in roughly the same place on the REFL camera, then the RefCav autolocker locked it with no issues.  I used the picomotor mounts to tweak the RefCav alignment to max the TPD; this gave a TPD of 0.99 V.  Very good.  To finish I unlocked the RefCav, tweaked the beam alignment on the RFPD, then locked the RefCav again and measured the visibility:

• Unlocked: 1.326 V
• Locked: 0.225 V
• Visibility: 83.0%

Job done, I left the enclosure.  During my time in there the PMC Refl power had increased from ~16.1 W to ~17.9 W (this increase is normal with enclosure incursions), so I turned the ISS OFF while the PSL enclosure and PMC returned to thermal equilibrium.  At the time of this writing the PMC Refl power has dropped back to ~16.8 W, so I will continue to monitor it over the remaining maintenance time and turn the ISS back on once it gets closer to its normal value.  Also at the time of writing the IMC has been relocked; with the IMC locked the FSS TPD is ~0.96 V (the change with the IMC locked is normal).  This completes WP 11474.

Following alog 73227, reduced  H1:SQZ-SHG_FIBR_REJECTED_DC_POWER from saturated value of 0.7mW to 0.04mW.

TITLE: 10/17 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: MAINTENANCE
    Wind: 4mph Gusts, 3mph 5min avg
    Primary useism: 0.06 μm/s
    Secondary useism: 0.41 μm/s
QUICK SUMMARY: Lost lock as I was typing out this log ending a 24.5 hour lock. Unsure of the cause. Primary and secondary useism are high, hopefully this is a non-issue for relocking after maintenance.

TITLE: 10/16 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 162Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY:

- EX saturation @ 5:17

- 5:29 - inc 5.5 EQ from Iran

• 6:17 - EQ mode activated, back to CALM @ 6:27

- Violins have been stable over the course of the night after the ring heater changes from earlier today

- "PSL FSS TPD transmission low" notification has been popping up sporadically throughout the night - Tagging PSL
LOG:

No log for this shift.

H1 is still in observing, currently locked for 12.5 hours. Detector appears to be stable, ground motion is low, and the wind seems to be slowly going down (currently hovering ~15-20 mph).

TITLE: 10/16 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 152Mpc
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 27mph Gusts, 23mph 5min avg
    Primary useism: 0.08 μm/s
    Secondary useism: 0.38 μm/s
QUICK SUMMARY:

- H1 has been locked for 8.5 hours

- CDS/DMs/SEI ok

- Wind is picking up, right around 35 mph gusts - will monitor throughout the night

TITLE: 10/16 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 149Mpc
INCOMING OPERATOR: Austin
SHIFT SUMMARY:

We dropped out of Observing to reverse the previously (last week, alog73445) done ring heater changes in 2 steps 2 hours apart, first step was done from 20:39:51 - 20:40:23UTC, the second was from 22:41:46 - 22:24:19UTC. alog73503

The wind has started to pick up over the past 2 hours, gusts up to 35mph which is probably what's degrading our range over the same timeframe, and microseism remains slightly elevated.

LOG:                                                                                                  

Ryan informed me at 20:48 UTC (13:48 PDT) that he was getting a PSL Chiller alarm, a likely indication that the level was low.  I had to watch the chiller for several minutes as the level slowly moved up and down with the regular flow of water in and out of the reservoir, but sure enough the water dipped just below the threshold and the chiller threw a Low Water Level alarm.  I added 150mL to get the reservoir to the Max line and the alarm went away.

We are averaging ~180mL of water added every 6 weeks, this has been fairly constant since late-April 2023.  I'll be in the enclosure tomorrow so will be able to do our customary leak check (a habit that's developed since we don't go into the enclosure unless necessary); I don't expect any leaks since the amount of water being added has not accelerated, but it's good practice to check while I'm in there.

To see if the range changes seen when we turned up the ETM RH from 1.0W/segment to 1.2W/segment in 73445 were real, this afternoon we are reversing this change.

At 20:40UTC, Ryan took us out of Observing to reduce both H1:TCS-ETM{X,Y}_RH_SET{UPPER,LOWER}POWER to 1.1W, we'll plan to reduce all the way to 1.0W in 2 hours.

The corner station dust monitor pump has failed. I am waiting for a quote for rebuild kits. The service kits we have on site are for the end stations only.

Closes FAMIS 26213
Laser Status:
    NPRO output power is 1.819W (nominal ~2W)
    AMP1 output power is 67.79W (nominal ~70W)
    AMP2 output power is 135.4W (nominal 135-140W)
    NPRO watchdog is GREEN
    AMP1 watchdog is GREEN
    AMP2 watchdog is GREEN

PMC:
    It has been locked 24 days, 4 hr 23 minutes
    Reflected power = 16.32W
    Transmitted power = 109.2W
    PowerSum = 125.5W

FSS:
    It has been locked for 0 days 6 hr and 52 min
    TPD[V] = 0.7082V

ISS:
    The diffracted power is around 2.3%
    Last saturation event was 0 days 6 hours and 55 minutes ago

Possible Issues: None

[Vicky, Regina, Dorotea, Sheila]

The attached plot shows the ratio of green light transmitted vs reflected through the OPO over the past year to see how green OPO cavity losses have changed.

We last moved the OPO crystal in Nov. 2022 (see relevant alog). Shortly after moving the crystal, the ratio was around 5% and degraded to around 4% within the first week; it has since settled between 2-3% for most of the past year.

We think the discontinuity around 23/04/16 was due to rejecting power away from the refl PD, which was done around that time because the PD was being saturated. If we look at the refl power alone we can see clear saturation occurring on the PD in the time before the power was lowered. We think the loss curve would be fairly continuous if not for the saturation, but can't exactly compensate since we don't know how much power is being lost. The plot shows only times from when the detector was "stable", but stability was calculated fairly naively, leading to some outlier points remaining from when the detector wasn't actually locked; however, the general trend seems pretty consistent.