Ops Day Shift Start

TITLE: 05/07 Day Shift: 14:30-23:30 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 15mph Gusts, 9mph 5min avg
    Primary useism: 0.05 μm/s
    Secondary useism: 0.17 μm/s
QUICK SUMMARY: A few issues on arrival. OMC_LOCK isn't able to find a carrier, it actually cant find any peaks at all. SEI_ENV guardian node is in error, which Ibrahim noticed as well. It looks like it can't grab data for some reason. Now that I type this out I'm thinking that there's an issue with Guardian nodes getting data, this would explain why OMC_LOCK sees 0 peaks in its scan, theres an empty peak list if theres an empty data list.

Maintenance can start early, I'll bring the IFO down as soon as I finish some quick investigations.

 

workstations updated

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

OPS Eve Shift Summary

TITLE: 05/07 Eve Shift: 23:00-08:00 UTC (16:00-01:00 PST), all times posted in UTC
STATE of H1: Observing at 149Mpc
INCOMING OPERATOR: Oli
SHIFT SUMMARY:

IFO is in NLN and OBSERVING as of 02:14 UTC (5 hr 58 min lock)

When the wind died down, I was able to successfully relock with an initial alignment. SDF Diff Screenshots attached.

Other:

Guardian SEI_ENV node in error keeps happening (3 times now after hitting load). It seems that the issue happens when CONF runs through an 1800s (30 min) checking loop - Jim on leave so didn't contact. There was an E_X saturation a few mins before it happened for the first time though (tenuous link and I do not think it is connected). Screenshot 3 shows the error log.

Had some trouble restarting Nuc5 (was going into it to get channel names). The startup code looks like its running but is taking a while to display anything (still the case after more than 5 mins as shift is ending).
 

LOG:

Start Time	System	Name	Location	Lazer_Haz	Task	Time End
01:34	VAC	Janos	CP3, MX	N	Pump transport	02:05

OPS Eve Midshift Update

IFO is in NLN and OBSERVING as of 2:14 UTC (1hr 21 min lock)

• Wind has calmed down significantly
• I had to adjust SQZ angle slightly to optimize range - will adjust again once H1 thermalizes.

First look at damping triples' bounce and roll modes

Sheila and Jeff have been looking at the idea of trying to damp some of the triples' bounce and roll modes (mostly the bounce modes), since we seem to be seeing some of them in DARM.  The alog thread with notes and candidate IDs for some of the modes starts with alog 77182.  While we may not end up wanting to actually damp these modes during Observing (especially if it broadens them), we would at least like to know which modes are associated with a suspension, since other modes could be associated with environmental factors (like HVAC fans).

After chatting with Sheila this morning, I interleaved some attempts at actuating on some of those modes with other work that was going on during this morning's commissioning time. The initial idea was to use a length signal (eg DARM) that we already have access to (via the LSC output matrix) and try to actuate on a triple suspension that is not used for length locking. I ran into some hiccups, but then at least tried something.  I think we'll need some model changes in order to try much more.

The challenges:

• The LSC output matrix does not have rows (at least on the medm screen) for actuating on either PR3 or SR3.  That makes sense, since we never envisioned using them for length locking.  But, it does mean that we can't use the LSC output matrix to send signals to those suspensions.
• The LSC output matrix does not have the ability to send DARM to any optic other than the quads.  Again, this makes sense because we didn't envision using it that way, but it again means that even for testing with PR2 or SR2 we can't use DARM as the length signal for damping the bounce / roll modes.

The successes:

• I think I've got filters in place in PR3 to try damping the 28.2 Hz bounce mode, once we have an error signal for it. These filters (a bandpass, as well as a +60 deg and a -60 deg filter) are in the M2 drivealign matrix of filter banks, in the L2L, L2P, and L2Y filter banks. I chose PR3 and this mode since it seemed nice and loud, but also less susceptible to the confusion of which mode is from which optic that may be happenning in the 27 Hz modes. But, after I put the filters in, I realized that I didn't have a way to send a length signal there. All the filters are loaded, but everything in the PR3 suspension is reverted to what was in the Observe.snap SDF file (which is basically no signals going anywhere).
• I think I've got filters in place in PR2 to try damping the 40.9 Hz roll mode.  This is the only roll mode (or, peak that could be a triple roll mode) that seems to be prominant in DARM.  It's not clear which optic it is from, but since it's louder in PRCL than in SRCL, I started with PR2 (and didn't get to SR2).  There didn't seem to be any obvious PR2 bounce modes in Jeff's plots in alog 77184, which is part of why I started with the roll mode.
  • Again these filters are a bandpass (this time around 40.9 Hz, with a magnitude of 1 in the pass band), and a +60 deg and a -60 deg filter (at 40.9 Hz).  They are in the M2 drivealign L2L, L2P, and L2Y filter banks.
  • I first checked that the gain of the M2 L2L, L2P, L2Y outputs were zero, and that there was no way I could actuate in length on PR2's M3 or M1 stages (the switch after the M3 LOCK_L bank is set to OFF, and the gain in the M1 LOCK_L bank is zero or one of the switches is set to off.). 
  • I then set the LSC output matrix to have a non-zero value in the PRCL -> PR2 element.  I started with something very small, but ended up with a 1 there.
  • I made sure that the M3 ISCINF_L filter bank was letting signal through, and also that the M3 LOCK_L filter bank was letting signal through, and that the M2 LOCK_L filter bank was letting signal through, and I turned off all frequency dependent filters in those banks.  The gains on all of these filter banks was 1.
  • I had on my bandpass in the M2 L2L filter bank, and no other filters (so no phase filters), and slowly increased the output gain until I started seeing signal going through to the M2 coil actuators. 
    • With a gain of +30, I could ring up the 40.9 Hz mode (this was a few to a few tens of counts on PR2's M2 coil master outs).  The mode seemed to be growing, as I'd expect if I had correctly identified it (albeit with a lot of luck on my first try).
    • With a gain of -30 I could ring it down again. -100 was still okay, but a gain of -200 caused the mode to start growing again.
    • When I was increasing the mode, I saw it grow in both PRCL and DARM outs.  When I was decreasing it, I could make it pretty much disappear in PRCL_OUT, but it never really got smaller than the ambient level in DARM.
• At this point it was nearing the end of the commissioning window, so I left all my new filters in place (but off and unused), and otherwise reverted everything in PR2 (PR3 had already been reverted).

Some thoughts:

• Sheila pointed out that, since I was using a PRCL signal to actuate on a PRC optic, it's possible that the mode is not on PR2, but that I was just cancelling it out on PR2.  So, today's test isn't necessarily definitive that I've identified a mode on PR2.
• PeterF asked the interesting question of how much these modes are showing up in DARM, relative to their expected levels from thermal fluctuations.  This is going to require some math to figure out.
• In order to test more things, the next step is probably to create pathways for PR2, PR3, SR2 and SR3 to be actuated by DARM.  It's likely to be challenging to use the infrastructure we have right now to do much more.

Monday Ops Eve Shift End

TITLE: 05/06 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 24mph Gusts, 16mph 5min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.14 μm/s
QUICK SUMMARY:

We are back to trying to lock, as the wind speed has gone down slightly.
 

OPS Eve Shift Start

TITLE: 05/06 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1:  Lock Acquistion
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 19mph Gusts, 14mph 5min avg
    Primary useism: 0.05 μm/s
    Secondary useism: 0.14 μm/s
QUICK SUMMARY:

IFO is in LOCKING and in CHECK_MICH_FRINGES

Been quite the windy day - just got debrief from Tony about status off IFO problems that we've been experiencing.

Atomic Clock Resynchronized to timing system 1PPS

WP11850 Resync Atomic Clock

Daniel, Fil, Dave:

13:32 PDT: Daniel resynchronized the MSR Atomic Clock  to the timing system's 1PPS to clear the timing error.

The procedure was:

Connect a Windows laptop (Daniel's surface) to the RS232 port on the rear of the Symmetricom 4310 Cesium Frequency Standard unit (located in MSR Rack02 U26-27). We used a DB9 null-modem and serial/USB converter cable to connect the RS232 connector to a USB-A port on the laptop.

Daniel ran his monitor code, setting up the serial port for 9600 Baud. We verified the error string as "16,07,00,00,00" which, as before alog70401, means 0x16 Reboot Alert, 0x07 CBT Signal Degradation.

Daniel ran a short 50Ohm coax BNC cable from the SYNC port on the rear of the Atomic Clock to port 8 of the comparitor (the first output 1PPS port). He then ran the resync command which cleared the error.

Monday Mid Shift Update

TITLE: 05/06 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 151Mpc
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 29mph Gusts, 19mph 5min avg 
    Primary useism: 0.08 μm/s
    Secondary useism: 0.15 μm/s
QUICK SUMMARY:

After a lockloss while holding ISC_LOCK at LOWNOISE_ASC to fix the TRANISTION_FROM_ETMX issue, we shifted focus to fixing the PRCL1 issue we were having with DRMI, so we were holding in DRMI for a bit. Once that was fixed we went back to holding in LOWNOISE_ASC. after that Commissioning was started.

• Change PSAMS from 7.5/0.55 to 8.8/-0.67
• Edits to SQZ alignment GRD
• Camilla/Erik troubleshooting ITM charge measurement injections
• Jitter injections
• NB injections
• SRCL FF gain adjustment
• PRCL injections
• HRTS injections?

We were able to get back to NOMINAL_LOW_NOISE at 16:50 UTC and got back into OBSERVING after Commissioners were done with their Commish wish list at 18:36 UTC.
H1 has now been Locked for 3 hours.  
Just unlock....

SRCL FF gain adjusted again

There was again coherence between DARM and SRCL in last night's lock, so I ran a SRCL injection and adjusted the gain of the FF. (FF attached)

I changed the gain from 1.15 to 1.12.  77570 and 77492 are other times this gain has been adjusted in the last few weeks.

The coherence of SRCL to DARM is low at the frequencies that we care most about for this injection (20-50Hz), but the noise in DARM is well above the ambient DARM noise.

Attaching SDF screenshot for both the SRCL and PRCL changes here.

Edit: the SRCL excitation was on from 18:18:57-18:22:00 UTC May 6 2024. 

PRCL injections, with PRCL offset on and off

Attached is a screenshot showing a PRCL injection with and without the PRCL offset of -62 in PRCL1. 

PRCL offset off: 6/5/2024 17:19:13 UTC

PRCL offset on: 6/5/2024 17:09:19 UTC 

The PRCL offset doesn't make much of a difference to the DARM coupling, it may be a little worse with the offset off below 17Hz but a little better above 30 Hz. 

I've edited the guardian to no longer have this offset on, because there doesn't seem to be a strong motivation for it and we'd preffer not to have these digital offsets in.

New ESD bias settings for ITMX (0 V), ITMY (-222 V), and ETMY (200 V) to minimize electronics ground noise coupling

Anamaria, Sheila, Robert

We scanned the biases for three test masses to find the coupling minimum for currents that we injected onto the building ground. The optimal ETMY bias was 115 V in January of 2023, 170 V in Aug. (72308) and 200 V now.  With ITMX at 0V, the optimal for ITMY was 60 V in March of 2023 (68053) and -222 V now, The figure shows some of the bias scans.

Two un-identified stray beams in HAM3, one measuring more than 20 mW

Anamaria, Robert

We photographed, from a second angle, the beamspot of a stray beam that I noticed last visit (76969 - Fig. 3 ). The photos (Figure 1) confirm that there is indeed a bright stray beam hitting, at a grazing angle, the bellows and other parts of the spool piece between HAM3 and the IMC tube.

I also wanted to measure the power of the stray beam that had been producing a large 48 Hz peak in DARM during early O3, in order to improve my scattering coupling calculations. This is the beam that reflects off of the PR2 scraper baffle and hits the illuminator viewport on HAM3, which we mitigated by inserting a black-glass viewport cover (52184). We were surprised by how bright the beam is, reaching 20 mW on the power meter (see Figure 2), even though we could not fit the whole beam on the meter. We estimate that the beam may reach 60  mW.

Finally, we made movies as we swept the ITMY compensation plate, hoping to see some indication of where the ghost beams are hitting, but did not. We will have to wait until Alena gives us the likely position of the CP ghost beams based on the angles that Anamaria showed us how to measure.

OMC Scans to investigate possible OFI bad throughput

Jennie W, Sheila

 

Today we took OMC scans to help diagnose what is going on with our alignment through the OFI - that is, what is the mode-matching at our the old alignment (as of Monday 22nd) and our new alignment (as of this morning).

 

Sheila turned off the sidebands before the test and we had the ETMs and the ITMX mis-aligned initially for single bounce configuration.

 

Old alignment: SR3 M1 YAW OFFSET = -125 microradians

SR3 M1 PIT OFFSET = -437 microradians

SR2 M1 YAW OFFSET = -421 microradians

SR2 M1 PIT OFFSET = -64 microradians

 

Due to PEM measurements we switched from single bounce off ITMY to single bounce off ITMX.

 

Locked time = 1 minute from GPS 1398534847

Unlocked time = 1 minute from GPS 1398534984

Scan = 200 s starting at 1398535070 GPS

 

New alignment: SR3 M1 YAW OFFSET =  120.2 microradians

SR3 M1 PIT OFFSET = 437.9 microradians

SR2 M1 YAW OFFSET = 2061.7 microradians

SR2 M1 PIT OFFSET = -5.5 microradians

 

Locked time = 1 minute from 1398538330 GPS

Unlocked time = 1 minute from 1398538461 GPS

Scan = 200 s starting at 1398537927 GPS

Dark time with IMC offline and fast shutter closed = 1398538774 GPS

 

Mode mis-match measurments pending...

 

OMC Scan with SQZ beam yesterday

Naoki, Vicky, Jennie W

 

Naoki followed the directions in to set up the SQZ beam OMC scan.

We had a problem with the DC centering loops. After we switched them on they saturated the OM1 and OM2 suspensions.

We got around this by switching each of the 4 degrees of freedom on first - ie. DC3 Y, DC3 P, DC4 Y, DC4 P.

Then we engaged OMC ASC and this seemed to work ok.

When we tried to manually lock the OMC length loop we had problems as when we switched the gain of 1 on it would lose lock, even when on a TM00 mode of the expected height (0.6mA on DCPD_SUM).

Vicky got around this this using a lower gain and not engaging the BOOST filter in the servo filter bank.

Then she had to touch up the alignment in lock with OM3.

locked quiet time 1397329970 GPS 1 min:

OMC-REFL_A_LF_OUT16 = 0.0930255 mW

OMC-DCPD_SUM_OUTPUT = 0.652156 mA

 

unlocked quiet time 1397330106 GPS 1 minute:

OMC-REFL_A_LF_OUT16  = 1.04825 mW

OMC-DCPD_SUM_OUTPUT = -0.00133668 mA

 

dark measurement 1397330625 GPS 1 minute:

OMC-REFL_A_LF_OUT16  = -0.0133655 mW

OMC-DCPD_SUM_OUTPUT = -0.00133668 mA

 

I noticed after I took the dark measurement that OM1 and 2 were staurating again and need to clear history twice on OM1 to remove this.

Reverted OM1 and 2, 3 OMC sliders at 8:33 am (local time) on the 16th April.

Data is saved as REf 3, 4 and 5 in /ligo/home/jennifer.wright/Documents/OMC_scan/2024_04_16_OMC_scan.xml. Where 3 is the scan channel OMC-DCPD_SUM_OUT_DQ on the bottom right plot, 4 is the PZT excitation channel OMC-PZT2_EXC on the bottom left plot, and 5 is the monitor of the actual PZT output voltage OMC-PZT2_MON_DC_OUT_DQ on the top right plot.

OMC Scan with PSL beam

Jennie W, Sheila,

 

We turned off the 9 and 45 MHZ sideband EOMs and unplugged the 118 MHz modulation at the PSL racks. See this alog for how to do this.

 

We locked the IMC and mis-aligned ITMX.

 

DC centering loops 3 and 4 were turned on.

 

Sheila took the OMC lock guardian to PREP OMC scan and turned on the OMC ASC.

We waited for this to converge then turned it off.

 

We turned input power up to 10W from 2W and then locked the OMC in length manually by using the PZT offset slider to search for a high peak ~ 15mA.

After finding it we turned on the locking with a gain of 24 and the boost and int filters on (we checked the settings we needed in the guardian as we couldn't get the OMC guardian to lock it for us).

 

Then we turned off the OMC ASC.

 

We tuned up the OM3 and OMC alignment slightly to maximise the power on OMC-DCPD_SUM_OUTPUT and minimise it on OMC-REFL_A_LF_OUT16.

OM3 was moved down in yaw only from -108 to -117 and OMC was moved down in yaw from 210.5 to 195.5 and down in pitch from 350.4 to 340.4. The final values for the sliders are here.

 

Quiet time locked after aligning 16:21:03 UTC - 16:24:13 UTC

OMC-REFL_A_LF_OUT16 = 0.652644 mW

OMC-DCPD_SUM_OUTPUT = 15.6162 mA

 

Quiet time unlocked 16:25:31 UTC -16:27:35 UTC

OMC-REFL_A_LF_OUT16 = 30.106 mW

OMC-DCPD_SUM_OUTPUT = 0.000456763 mA

 

We took the IMC guardian offline and shuttered the green light going into both arms at the ISC tables, and with ISC_LOCK guardian in idle so it wouldn't keep trying to relock IMC.

Quiet time dark measurement 16:43:38 - 14:46:19 UTC

OMC-REFL_A_LF_OUT16 = -0.0132979 mW

OMC-DCPD_SUM_OUTPUT = -0.00106226 mA

 

The scan template is saved as /ligo/home/jennifer.wright/Documents/OMC_scan/2024_04_16_OMC_scan.xml

With the references for the time series of the three pertinent channels as:

Ref 0 OMC-DCPD_SUM_OUT_DQ

Ref 1 OMC-PZT2_EXC

Ref 2 OMC-PZT2_MON_DC_OUT_DQ