Per WP12079 we started measurements to compare directly the 20 bit DAC driving the ESD and L3 to our LD32. 

Comparing ESD Driving Signals
Test 1 - LD32 bank 1 (ch 0-7) attached to 0-7 on the PEM ADC ; 20 bit DAC ESD signal attached to 8-15 on the PEM ADC

Comparing L3 Driving Signals
Test 2 - 20 bit DAC L3 attached to 0-7 PEM ADC : LD32 bank 2 (ch 8-15) attached to 8-15 on the PEM ADC

After analysis of the data, we measured about ~14us delay in the LD32 which is accounted for by the Anti Imaging filter on the FPGA.  We also determined the gain should be ~275.65 to achieve the same calibration between both DACs.

Driving the ESD and L3 with the LD32 will be postponed until next week.

daniel sigg, dave barker, marc pirello

WP 12067
CDS Front-end IO Chassis As-Built Drawings D1301004

A new ADC was installed in h1iscey. Part of PEM upgrades. With h1iscey down, we did some troubleshooting of the Front End (FE) computer not booting with second Adnaco card connected to the FE, alog 62840.

Steps in debugging:

1. The second Adnaco card was replaced in the IO chassis
2. All ADC and DAC cards in Adnaco 3 were moved to Adnaco 2
3. New PEM ADC installed in Adnaco 3, slot 1
4. Fibers for Adnaco 2 reconnected at FE computer (slot 7)
5. Computer would not reboot
6. Fibers from Adnaco 4 (computer slot 4) disconnected and Adnaco 2 connected
7. Computer booted
8. Adnaco adapter card (computer slot 7) replaced
9. Fibers for Adnaco 2 reconnected (computer slot 7)
10. Computer would not boot

Issues with Slot 7 on the FE computer. Fibers rearranged at computer as follows:

1. Computer slot 1 - Empty
2. Computer slot 2 - Adnaco 1
3. Computer slot 3 - Adnaco 2
4. Computer slot 4 - Adnaco 3
5. Computer slot 5 - Emtpy
6. Computer slot 6 - RFM
7. Computer slot 7 - Empty (BAD)

Adnaco 4 fibers left disconnected. Computer will be replaced.

D. Barker, F. Clara, E. Von Reis

Vicky, Camilla

Repeated 66946 PSAMs changes with SQZ-OMC scans with a new method of dithering the PZT around the TEM02 mode and minimizing it. With this we improved the mode mismatch from 4% to 3%. It will interesting to see if these settings are still better in full lock. Plots of OMC scan attached and same plot zoomed on peaks attached.

• Increased SEED power from 0.7 to 75mW. SQZ_OPO_LR to LOCKED_SEED_DITHER. Started with 0.07mW on OPO_IR_PD but we're misaligned on SQZT7. This increased to 1.25mW when we move the ZM4/5 alignment. Will need to fix table alignment to match IFO alignment when we're happy.
• Took IMC to OFFLINE (mis-aligns MC2), aligned SRM, misaligned SR2.
• Note, that we should have (but didn't) misalign the ITMs to make the REFL signal cleaner.
• When we bring ZMs back to IFO alignment, SQZ beam is on AS_AIR (a little high).
• Turned on DC 3/4 centering loops and then OMC ASC. Have power on AS_A/B/C. 70 counts on A/B_DC_SUM.
• Locked OMC with SQZ beam: OMC_LOCK guardian to DOWN. Changed H1:OMC-LSC_LOCK_TRIGGER_THRESHOLD from 1.0 to 0.3. Manually scanned using  H1:OMC-PZT2_OFFSET. Watched OMC-DCPD_SUM_OUT_DQ and OMC TRANS camera (exposure increased). Autolocker off. When we found the resonance, turned H1:OMC-LSC_SERVO ON, gain to 1, INT and BOOST on.
• Sending in 1.25mW, expect 70% reflected off SRM would be ~0.9mW, get 0.95mW on AS_C_NSUM, get 0.64mW transmitted though OMC.

Took OMC scans using tempalte /sqz/h1/Templates/dtt/OMC_SCANS/Sept10_2024_PSAMS_OMC_scan_coldOM2.xml  Unlock OMC and H1:OMC-PZT2_OFFSET to -50 (nominal is-17) before starting scan.

Over 1V and under -1V on ZM5 is bad at most ZM4 strains (tested at 4.0V ZM4). For each step we adjusted ZM4 and then fine adjusted ZM5.

I took the opportunity to center the IMC WFS this morning since we've been getting the notification on DIAG_MAIN for some time. The process was as follows:

1. Offload IMC WFS by taking IMC_LOCK to 'MCWFS_OFFLOADED'
2. Take IMC_LOCK to 'OFFLINE'
3. Using the MCWFS centering scope and picomotors on the IMC overview screen, center the signal on each WFS (scope screenshot attached)
4. Accept IMC PZT offset SDFs from the previous offloading (attached)

In preparation for WP 12079, I prepared ESDOUTF (L3) and COILOUTF (L1, L2) filters to make up the calibration difference between 18-bit and the new 32-bit DACs. This is similar to what was done in LHO:64274 to adjust from 18-bit DACs to 20-bit DACs. Similarly, I placed new '32bitDAC' gains in CALCS-ETMX. In CAL-CS, the new gains are intended to replace the gains of '4'. 

I have not yet loaded the filter coefficients, but they have been saved in the filter files. 

FAMIS27776

For the most part the chillers lines look good, nothing new showed up. To redocument a few items with pictures:

• TCSY tubing has numerous cuts that look like are from the table enclosure and moving it through the feedthrough, aka shape hole in enclosure wall with rage stuffed around it - attachment 1
• Between BSC2 and HAM4 there is an outlet that is blocked by some of the TCS lines. It looks like someone has pushed them out of the way in the past, causing the lines to flex and not run straight. - attachment 2 , attachment 3 , attachment 4 , attachment 5
• Some deep straches on a return pipe between HAM4 and 5 - attachment 6
• The pipes go from a 2x2 configuration to a 1x4 then back to a 2x2 when going up and onto the pipe bridge, this causes some flexing in the lines. - attachment 7 and attachment 8

Both sock filters were replaced and gunk found in the water reservoirs.

I noticed the other month that the sock filters were starting to look green. I was hesitant to replace them while we were observing, so I waited for a maintenance day that I was available. Well, we should have replaced them sooner. The TCSY sock had gunk on the inside of the sock and the outside (attachment 9), TCSX was similar but not as bad (attachment 10). The big issue is that there was chunks of gunk suspended in the reservoirs (TCSY res. & TCSX). I'm not sure if this gunk is making it around our sock filters* or if it's just working its way through. The latter possible since I saw some gunk on the outside of the TCSY sock.

It looks like the last time that we replaced these filters was Aug 2023 (alog72253), so we should set up a famis to remind us to do this sooner. The manual recommends replacing them every 3-4 months or so. While I don't recall ever replacing them that frequently in the past, perhaps it's time to start.

*Years ago we decided that not pushing the sock's gasket fully into its seat and instead angling it toward the flow of the water, but allowing an air gap on the far side, gave us more accurate reservoir level readings and still had almost all of the water go into the sock.

Tue Sep 10 08:12:19 2024 INFO: Fill completed in 12min 15secs

Gerardo confirmed a good fill curbside.

TITLE: 09/10 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Calibration
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 3mph Gusts, 1mph 3min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.08 μm/s
QUICK SUMMARY:

IFO is in NLN and CALIBRATION for automatic PEM Injections and In-Lock SUS Charge measurements, since we're locked (and have been for near 15 hours!)

Planning to head into Planned Tuesday Maintenance once those are done running, which should be at 8AM.

As per WP 12069 I will be switching to the backup CDS router.

After discussion with the operator we will do this at 8am localtime.  This will temporarily break the link between the CDS network and the rest of the world.  It will not interrupt the IFO or control room work that stays within the CDS network.

The procedure to do this switchover for the current setup is documented in LIGO-T2300212.

Workstations were updated and rebooted.  This was an OS packages updated.  Conda packages were not updated.

TITLE: 09/10 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 149Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY: We've been locked for just over 5 hours, the range has been just under 160, and the wind has calmed back down.

23:54 UTC Observing

TITLE: 09/09 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: Currently relocking and at ENGAGE_ASC_FOR_FULL_IFO. One lockloss today (79991) but not much to report. Relocking is taking a while because of changes in the ISC_LOCK code and not because of IFO issues.
LOG:

14:30UTC Observing and Locked for 4:50 hours
15:31 Out of Observing for Commissioning
18:31 Back into Observing
20:01 Out of Observing due to SQZer unlock
20:12 Lockloss
    21:45 Lockloss from LASER_NOISE_SUPPRESSION (probably user error/people on floor)
    22:41 Lockloss from ADS_TO_CAMERAS 

TITLE: 09/09 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 23mph Gusts, 16mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.06 μm/s
QUICK SUMMARY:

• Relocked following 2 high state relocking locklosses, LASER_NOISE_SUP & ADS_TO_CAMERAS from comissioning related issues
• The wind is picking up a little bit

A while ago Oli found that some earthquakes cause IMC splitmon saturations, possibly causing locklosses. I asked Daniel this with respect to the tidal system to see if we could improve the offloading some. After some digging we found that some of the gains in the IMC get lowered to -32db at high power, greatly reducing the effective range of the IMC SPLITMON. He and Sheila decided that the best place to recover this gain was during the LASER_NOISE_SUPPRESSION state (575) so Sheila added some code to that state to redistribute some the gain (lines 5778 -5788): 

            self.gain_increase_counter = 0
        if self.counter ==5 and self.timer['wait']:
            if self.gain_increase_counter <7:  #icrease the imc fast gain by this many dB
                #redistribute gain in IMC servo so that we don't saturate splitmon in earth quakes, JW DS SED
                ezca['IMC-REFL_SERVO_IN1GAIN'] -= 1
                ezca['IMC-REFL_SERVO_IN2GAIN'] -= 1
                ezca['IMC-REFL_SERVO_FASTGAIN'] += 1
                time.sleep(0.1)
                self.gain_increase_counter +=1
            else:
                self.counter +=1

We tried running this, but an error in the code broke the lock. That's fixed now, the lines are commented out in ISC_LOCK and we'll try again in some other day.

[Elenna, Gabriele]

I did another test of the PRCL offset today, mirroring previous tests (76814). The motivation for this test is first the large coherence of DARM with LSC REFL RIN, indicating that we are locked with some offset in PRCL. Next, there is large coherence of PRCL and CHARD Y to DARM, and previous tests have shown some PRCL is coupling through CHARD Y, and that coupling can be reduced by adding a digital offset to PRCL, which counteracts whatever locking offset is present in PRCL.

Once again, a PRCL offset is shown to reduce PRCL/REFL RIN coupling, and PRCL to CHARD Y coupling. The minimum occurs with an offset of about -58 (compare to April's best offset of -62). This coupling indicates an offset somewhere between 25 pm and 50 pm (quoting Gabriele 76810). The digital offset reduces REFL RIN/PRCL coupling by 40 dB. PRCL and LSC REFL RIN coupling plot

The offset reduces the noise in CHARD Y by reducing the PRCL coupling by a factor of 10. PRCL and CHARD Y coupling plot, and noise reduction in CHARD Y, CHARD Y noise

The PRCL to CHARD P coupling does not change, PRCL and CHARD P coupling plot (I was lazy and did not properly label this plot, but each trace is a different offset count similar to the other plots). However, the offset worsens the noise in CHARD P, because the offset effectively changes the amount of HAM1 noise coupling into CHARD P, CHARD P noise. We only checked CHARD P, but it likely changes the noise in INP1 P and PRC2 P as well. With this PRCL offset, I ran a HAM1 FF off time, so we could get data to retune the feedforward. (start: 1409940778, stop: 1409941096).

I think that with this PRCL offset, and with an updated feedforward, we will see some improvement in the low frequency noise. The last time we did this test, we did not check the effect on the feedforward, and this is possibly why the sensitivity did not get better, even though we are seeing the exact same reduction in CHARD Y noise as before.

Overall, we can convince ourselves that this result makes sense because the offset is changing the amount of 00 mode present at the REFL WFS.

We have made no changes yet, but I will fit new feedforward so that we can retest this offset + new HAM1 FF at the next commissioning time.

TJ, Vicky, Naoki, Sheila

Since the vent we haven't fully checked some of the usual offsets and settings that we might need to adjust, I started with some of them this morning. 

I started with stepping the BS camera pitch offset, which I'd started in 79663 but wasn't able to finish at that time because of a lockloss.  We gained a little more than 1 kW of circulating power in the arms by adjusting the offset from 233 to 230, see first attachment, this has been added and loaded in lscparams.  The improvement on POP A + B may be because of an alignment shift, we are probably clipping on both of those.

Went to no squeezing and ran OMC alingment offset scan: went to no squeezing and copied Jennie's dtt template from 78616.  This scan saturated the OMC pitch actuator, so I reduced the OMC ANG Y amplitude from 3 to 1 and restarted the scan at 15:53:07-16:16:29 UTC.  TJ and I noticed that the strange flashing behavoir of the OMC camera was coming and going while this scan was happening. 

Following up on 79719 I used the template sheila.dwyer/OMC/OMC_fringe_wrapping.xml and reduced the amplitude to 600 as Naoki did to adjust the OFI temperature. We found that the fringe wrapping shelf amplitude was reduced by increasing the temperature, we went up to 37.5C and the amplitude of the shelf dropped by a factor 3 (second screenshot attached).  We didn't go hotter than this because we weren't sure how hot we would want to operate.   This change in OFI temperature doesn't seem to have changed the optical gain, shown in the 3rd attachment.  (template in sheila.dwyer/OMC/OMC_fringe_wrapping_after_OFI_repair.xml, ref 38 25C, ref 39 28.5C, 40 29.5C, ref 41 30.5, ref 42 31.5C, ref 42 31.5C, ref 43 32.5C, ref 45 34.5C, ref 46 35.5C, ref 47 36.5C, ref 48 37.5C. )

Vicky, Naoki and I started some alignment scans for 4 squeezer DOF (ZM5+6 P+Y) with different frequencies (similar to the OMC offsets), at 17:10 UTC- 17:34:20 UTC. (We continued OFI temperature adjustments while this was happening).