Closes FAMIS#26062, last checked 73432

ETMX did not run this week, so there is no new data point for ETMX.

Like Ryan S had said last week, matplotlib is still acting up. When I was running the coefficientplots.py script, mpl refused to let the plots show at the end, so I ended up needing to add an extra plt.show() right after plotting, go into debug mode, and get the script to pause after generating each plot so I could save them.

TITLE: 10/17 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 161Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 9mph Gusts, 7mph 5min avg
    Primary useism: 0.06 μm/s
    Secondary useism: 0.39 μm/s
QUICK SUMMARY:

Locked for 1.5 hours now. Wind is low and trending downward.

TITLE: 10/17 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 160Mpc
INCOMING OPERATOR: Oli
SHIFT SUMMARY: Maintenance day, with work all around the site. Recovery was straight forward and autonomous, but required an initial alignment.
LOG:

• 1453 Lock loss
• 2151 Observing
• 2216 Out of observing for a quick SQZ measurement
• 2233 Observing

Camilla and I tested going to Observing with no squeezing following the instructions on the Observation With or Without Squeezing Wiki. There were a few edits to the wiki so I'm glad we got the chance to test it. We purposefully did not change the state of H1:GRD-IFO_OK (ie. we didn't actually go into observing), but all nodes reported OK other than SDFs, which are simple to accept in this state.

Going to or from this odd IFO configuration is still not super straight forward. It requires editing the definition of the nominal states of 5 guardian nodes in 5 separate python files, then taking the ISC_LOCK node to manual, requesting the INJECT_SQUEEZING state, then manual back to the NOMINAL_LOW_NOISE state. I can't think of an easy way to make it simpler than this though, and this situation should rarely come up.

Naoki, Vicky, Sheila, Camilla. WP 11470.

OPO Crystal Move

Following last time we moved the OPO crystal 65684, we used the wincam dell laptop and gray E-870 PI shift driver box (stored in LVEA SQZ cabinet) and the OPO crystal cable Daniel attached the the +X HAM7 flange. Adjusted OPO temperature from 31.684 degC to 31.804 degC for co-resonance while scanning rather than stationary. 

To scan the OPO PZT fast enough, we used external function generator and Thorlabs driver at the racks for the OPO PZT to scan over more than 1 FSR (around 1-9V scan). 

We were able to move the OPO crytal over its full range and found 6 spots with red/green co-resonance, attached pdf shows the places we moved. LLO found 10-13 potions which is surprisingly more than us, 73502. 

Through O4 we've been using the 2nd posltion from the right, but left the crystal on the 2nd spot from the Left. 

Photos attached of the PZT scan (yellow trace), OPO IR trans light measured on HD PDA (pink trace), Green trans from CLF path (green trace). The green alignment looked bad at all spots. This could be from misalignment of OPO path or HOMs present in fiber. When we next go into HAM7 we can look at this. 

NLG Measurement

Turn down green pump power with SQZT0 wave plate to 4mW in to stop the OPO lazing. We measured NLG of 14 (OPO_IR_PD_LF_OUTPUT amplified / unamplifed = 0.0136/0.00092). This reduced to NLG of 12 over a few minutes. 

Homodyne Measurement 

We balanced the HD by reducing the seed power and realigned to maximize visibility. At start of measurement visibly was 14 and at the end it NLG was 12. Vicky, Sheila Naoki took Homodyne measurements which were hard with NLG drifting. Measured 4.5dB whihc is less than the 6dB measured last week 73376. But we think we could have offloaded the ASC alignments incorrectly to not see good SQZ on the HD.  

• PDA 98.6% Visibility (Min 10.3mV Max 1.48V) = 2.75% loss (1- Vis^2)
• PDB 98.0% Visibility (Min 14.8mV Max 1.5V) = 3.87% loss

SQZ in IFO

Ended with NLG of 13.5 into IFO. Amplified power of 0.0196, unamplified seed of 0.00149. Though this may be changing quickly. 

Took some no sqz data while TJ tested updates to the Observing with No SQZ wiki. Accepted sdfs to go back into observing. Vicky adjusted OPO tempurature and had to adjust the SQZ angle from 142 to 163, squeezing looks better 4dB+ but we expect the angle and OPO tempurature may need to be adjusted over the next hours...

Jordan, Gerardo

Today, we were able to install one of the new 150 l/s ion pumps on FC-CII, C6 cross. The Ion Pump/Tee/Angle valve assembly was pre-built in the staging building and then pumped down and leak checked. This assembly was stored under vacuum and then brought to the Filter Cavity Enclosure.

We closed FCV-3 (BSC3), FCV-6, FCV-8, and FCV-9 (HAM8) to isolate the C6 cross. Then closed the -Z axis GV on the C6 cross to isolate the ion pump port. We then vented the ion pump assembly with N2 and removed the angle valve/6" zero-length reducer on the cross, and installed the ion pump on the 6" CF port. A genie lift was used to lift/hold the ion pump while the connections were made.

Once installed, we used the leak detector/small turbo to pump down the assembly, and then helium leak tested the one CF connection that was made. There was no detectable signal above the helium background of 9.5E-10 Torr-l/s.

The ion pump was powered on locally, and quickly dropped to ~2mA. The -Z gate valve remains closed, and the rest of the FCT gate valves were reopened once the ion pump was leak checked and powered on. We will continue with the installation of the rest of the pumps in the following weeks.

Fil, Dave, Rahul

Turns out that the fault reported by Jenne (see alog 73447) at the ETMY R0 Test Coil Enable (which went red) was due to a faulty cable connecting Binary Input to the Binary Card in the IO chassis. It took us 3hrs to figure it out after checking the IO chassis and Coil driver - which were working fine. Dave also power cycled the IO chassis to help us figure it out. Fil thought it could be the binary card (at first and IO chassis later) which we replaced (only the binary card - GCRBS96004326) with a new one but no success. In the end we changed the cable and it made the Test coil (channel F1 and F2) working again.

WP 11477 Closed.

WP11462 Run latest Picket Fence code on nuc5

Edgard, Erik, Dave:

Erik upgraded the userapps git checkout of the picket fence code last Friday, I restarted the code on nuc5 this morning. The only change I made was to add the display of the state borders to the map.

WP11469 Testpoint Stress Test h1pemcs

EJ, Joe, Dave:

With the static DAQ DQ list unchanged, I tested how many testpoints could be opened on h1pemcs.

Result: 62 TPs can be opened (get low level DAQ error if 63 are attempted). PEM measurements require 43 accelerometer TPs, which leaves 19 additional TPs which can be used for PEM injection measurements.

Test code is h1pemcs_testpoint_test.py (web_svn) more details of the test can be found in the comment header block.

WP11468, WP11473 Reconfigure h1didivideo[0,1,2] network ports and reboot

Jonathan, Patrick:

The h1digivideo[0-2] machines were made to be dual-homed, giving the camera LAN a separate ethernet connection. As part of this upgrade, the machines were rebooted which cleared the almost full memory.

WP11477 h1susey BIO readback error

Fil, Rahul, Dave:

Fil and Rahul investigated the ETMY reactionary chain BIO readback, showing F1 DAC drive was in test mode. During the investigation the h1susey front end was fenced from Dolphin and power cycled.

The Contec6464 card for the R0 signals was swapped with a spare:

The problem was found to be in the cable connecting the Contec6464 card to its BIO Chassis. This means that the removed card is most probably a good card.

Tue Oct 17 10:11:38 2023 INFO: Fill completed in 11min 35secs

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.

To see if the OM2/beckhoff coupling is a direct electronics coupling or not, we've done A-B-A test while the fast shutter was closed (no meaningful light on the DCPD).

State A (should be quiet): 2023 Oct/10 15:18:30 UTC - 16:48:00 UTC. The same as the last observing mode. No electrical connection from any pin of the Beckhoff cable to the OM2 heater driver chassis. Heater drive voltage is supplied by the portable voltage reference.

State B (might be noisy): 16:50:00 UTC - 18:21:00 UTC. The cable is directly connected to the OM2 heater driver chassis.

State A (should be quiet): 18:23:00- 19:19:30 UTC or so.

DetChar, please directly look at H1:OMC-DCPD_SUM_OUT_DQ to find combs.

It seems that even if the shutter is closed, once in a while very small amount of light reaches DCPDs (green and red arrows in the first attachment). One of them (red arrow) lasted long and we don't know what was going on there. One of the short glitches was caused by BS momentarilly kicked (cyan arrow) and scattered light in HAM6 somehow reached DCPDs, but I couldn't find other glitches that exactly coincided with optics motion or IMC locked/unlocked.

To give you a sense of how bad (or not) these glitches are, 2nd attachment shows the DCPD spectrum of a quiet time in the first State A period (green), strange glitchy period indicated by the red arrow in the first attachment (blue), a quiet time in State B (red) and during the observing time (black, not corrected for the loop).

FYI, right now we're back to State A (should be quiet). Next Tuesday I'll inject something to thermistors in chamber. BTW 785 was moved in front of the HAM6 rack though it's powered off and not connected to anything.

Vicky, Sheila, Camilla, Dorotea, Naoki

We went to SQZT7 this morning with the new homodyne (73241).  In the end we wer able to see decently flat shot noise and decent visibility.  On the way, we ran into some difficulties that caused some confusion:

• There was a cable from the homodyne very close to the seed beam path.
• The beam on homodyne PDA (LO transmitted through BS). 
• There is some seed leakage from the OPO path, even when that path is blocked by the flipper.  This means that the shot noise is very noisy unless the flipper is blocked and the seed is also blocked on SQZT0.
• We were able to improve the visibility by moving the alignment of the lenses.  This gave us better visibilty than we found just by adjusting the alignment of the steering mirrors.
• The half wave plate on the seed path is still in place, it is set to make the polarization vertical (checked with a PBS) which also results in a close to balanced power ratio on the two paths.
• After we were satisfied with our flat shot noise and visibility aroun 98% on each arm of the homodyne, we went to the control room.  Then there was an alignment shift mostly in pitch that badly misaligned the seed beam from the homodyne.  The ZM sliders and PSAMs values hadn't changed.

In the end we have flat shot noise, and a visibility of 98.5% measured on PDA (3.07% loss) and visibility of 97.8% (4.44% loss) measured on PDB.  The nonlinear gain of 11 measured with seed max/ no pump. A comment to this alog will contain the measured sqz/asqz/mean sqz.