Due to the DARM coherence with REFL RIN (76766) and measured PRCL/REFL RIN coupling (76805), I tried changing the PRCL offset to see if that would reduce this coupling.

I first began this test very early in the lock, so the coupling to REFL RIN was increasing with time due to thermalization. However, I was able to make a consistent improvement with the coupling by changing the PRCL offset. The improvement held an hour later as well. I found a minimum to the PRCL/REFL RIN coupling. This change also slightly improved PRCL coupling to DARM, and PRCL coupling to PRC2 Y and CHARD Y.

I changed the PRCL1 offset with a 30 second ramp, and started small. I was able to work up to making 10 ct step changes at a time with the long ramp. I also made sure to monitor the POP9 inputs to be sure I wasn't saturating the PD.

A positive PRCL offset made the PRCL/REFL_RIN coupling worse. To confirm I wasn't getting fooled by thermalization, I chopped this a few times. A +10 ct PRCL1 offset made the coupling worse even with the changes from thermalization.

Next, I took negative steps in the PRCL offset. I was able to see the phase flip sign between -60 and -70 ct. I narrowed this down to between -62 and -65 ct. This lines up with Gabriele's prediction from alog 76810.

See final plot of PRCL/RIN and PRCL/DARM here

Plots of PRCL/CHARD Y, PRC2 Y, SRCL and MICH here

I set the offset to -62 ct, and then chopped on and off a few times. PRCL/REFL_RIN coupling reduced by 33 dB. PRCL/PRC2 Y and PRCL/CHARD Y reduced by 7 dB. PRCL/DARM reduced by a few dB below 20 Hz. There was no significant change in the PRCL/MICH or PRCL/SRCL coupling.

I took two sets of quiet time for comparison:

1395862735 -62ct offset ON

1395863349 -62ct offset OFF

1395863966 -62ct offset ON

Gabriele and I do not see any change in DARM with this new offset. However, I think we should check how this has changed CARM at low frequency. Time pending, I'd like to rerun the frequency noise injections and see if there is any change at low frequency.

Other notes: when I first went to run quiet time, I noticed large peaks around 45 Hz in DARM. I checked the PRCL OLG to be sure everything was ok with the new offset. The peaks ended up being HAM3 scattered light from a beam dump Robert had removed. However, I noticed the PRCL UGF was low. Top of the phase bubble is 26 deg phase and around 30 Hz. I increased the PRCL2 gain by 30% to move the UGF from 22.5 Hz to 30 Hz. This is more in line with Evan's measurement, 76605. Plot here

Based on the PRCL injections I performed yesterday, alog 76805, I decided to try making adjustments of the PRM L2A gains to see if I could make changes to the PRCL/CHARD Y coupling. For the test, I adjusted the gain in the PRM M3 L2Y drivealign bank. I used a ramp time of 30 seconds and started small to avoid locklosses.

Generally, a positive L2Y gain made the PRCL/DARM coupling worse above 10 Hz. I tried gains of 0.01, 0.03, and 0.1. I saw the PRCL/DARM transfer function increase above 15 Hz at gains of 0.03 and 0.1 (no visible change at 0.01). There was no appreciable change in the PRCL/CHARD Y transfer function, but the coherence decreased as the gain increased. To confirm I wasn't being fooled by thermalization (we were locked for 4.5 hours during these tests), I went back to zero gain to confirm the transfer functions were still the same.

I then tried the negative direction. Gains of -0.03 and -0.1 reduced the PRCL/DARM transfer function above 15 Hz, but with the -0.1 gain I noticed an increase in the coupling below 10 Hz. Again, little change in the PRCL/CHARD transfer function, but a reduction in coherence with increasing negative gain. While I was thinking about what this means, there was a lockloss from ETM saturations. It appears the changing L2A gain caused the lockloss. There was a ring up in the DARM control signal at about 1 Hz. The increased coupling at low frequency is probably to blame.

A comparison of CHARD/PRCL and DARM/PRCL at 0, 0.1 and -0.1 PRM L2Y gain is shown here.

Also to note, during these tests I saw no change in the PRCL/MICH and PRCL/SRCL coupling.

Given that the PRCL/CHARD coupling is not changing appreciably, but the PRCL/DARM coupling is changing is probably a sign that we are incorrectly compensating for some other problem.

Sat Mar 30 10:09:46 2024 INFO: Fill completed in 9min 42secs

The Server we usually use for teamspeak is: 
teamspeak.ligo.org ,  which I believe is a server hosted offsite, possibly at MIT, that is ping-able but teamspeak service is no longer working.
LLO's Operators Cannot Log in to this server either.

I reached out to Dave this morning about this, and he mentioned something right before he hung up to investigate that made me want look at the passwords page for another server name and password.
On the passwords pageI found another teamspeak server:  teamspeak3.ligo.org . Which uses the same password as the old server!
I logged in and sent a link to Elenna to see if she could log in. Dave, Elenna, and I all met in there at effectively the same time and confirmed that it works.

Current issue with this is that there is not an LHO Control Room Channel, And I dont have the Credentials to make a permanent one.
I am Currently Hanging out in the LHO COMM/OPS MEETING ROOM.
If you have any questions about this please call the Operator at the LHO Control room @ (509) 372-8204
LLO has confirmed that they are also in this new Teamspeak server.

TITLE: 03/30 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 153Mpc
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 13mph Gusts, 10mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.21 μm/s
QUICK SUMMARY:
When I arrived H1 was locked  for 4 hours but not observing.
I have since taken the Observatory mode to Observing until a comissioner decides to  start running tests.

Team Speak is not working, I'm getting a Failed to Connect to server error.  I'm restarting the verbals computer now.
Please call 509 372 8204 to reach the the control room until I can figure out how to fix teamspeak.

Everything else looks pretty good. 

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

IFO is in NLN and OBSERVING as of 06:08 UTC (56 min lock)

Lock Acquisition and Issues with PRMI Locking - Part 2

Check Midshift Update (alog 76807) for Part 1

The same weird brief PRMI behavior happened and it just couldn’t lock. I let guardian do its automation thing through MICH Fringes, but after PRMI unlocked 4 more times and couldn’t even recover PRMI from Down like last lock, I ran an initial alignment. While it was a slow initial alignment, it seemed to fix something because locking was extremely smooth (DRMI locked without PRMI).

It is worth mentioning that throughout my two lock acquisitions today, DRMI could not lock following PRMI/MICH - either DRMI locked immediately or we lost lock/got stuck some time after trying to lock PRMI.

LOG:

03:42 UTC - DRMI Unlocked, cause unknown

03:56 UTC - Lockloss at ENGAGE_DRMI_ASC after getting DRMI locked

04:52 UTC - Running initial alignment - locking getting nowhere and failing at PRMI, showing the same strange noisy trace

05:23 UTC - Initial Alignment complete - took an uncharacteristic 35 minutes

06:04 UTC - NLN Reached (41 mins from down!)

06:08 UTC - H1 is OBSERVING

TITLE: 03/29 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Locking
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 11mph Gusts, 8mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.26 μm/s
QUICK SUMMARY:

IFO is LOCKING - planning to go into ovserving as soon as we get to NLN

Other:

1 Dust monitor not working properly - H1:PEM-CS_DUST_PSL101                    Error: data set contains 'not-a-number' (NaN) entries

IFO is in NLN and OBSERVING since 00:46 UTC (2 hr 25 min lock)

Lock Acquisition and Issues with PRMI Locking

While locking, we would only lock PRMI for a 5-10 seconds before it would lose lock (not complete lock, just PRMI). Interestingly, the same wiggly behavior was seen in the multiple PRMI locklosses (Screenshot 1). Trending LSC loops more generally (there was mention of movement before our last lockloss), there seens to have been motion in PRCL and MICH 5 seconds before the PRMI lockloss. In the 9s that this particular screenshot’s PRMI lock held, there was an oscillation seen in MICH OUTand more strongly in PRCL IN (screenshot 2). No clue if this is relevant but it seems to have happened before the PRMI lockloss so may have caused it.

Seeing that the input channels had notably more fluctuation in the signal, I checked the SRCL INand MICH IN and noticed that the LSC MICH IN signal was the loudest, getting a strange kick that seems to have led into the PRMI lock but got worse as time passed. Screenshot 3 illustrates this.

After 10 or so locklosses in PRMI, we lost total lock and interestingly, upon re-locking, this issue did NOT occur. I trended the LSC behavior during the DRMI lock (which was quickly successful and didn’t actually go through PRMI) and no LSC kicks were present. This leads me to think that there may be something exacerbating the PRMI locking and relocking (in the LSC loops) that does not affect the DRMI locking maybe?

Or maybe this is just a red herring and these loops always run for PRMI locking only but were a tad more aggressive in this alignment configuration so needed a total lockloss to “try again”.

SDF Diffs

Per Jennie’s direction, accepted SDF diffs that corrected previously accepted incorrect sdf diffs (screenshot 4).

Log:

00:39 UTC - Reached NLN

00:46 UTC - IFO is OBSERVING

[Elenna, Gabriele]

Elenna did two PRCL noise injections, at times separated by about 1h40m. We measured the transfer function to the other LSC loops and to REFL_RIN, since we observed coherence of DARM with RIN and DARM with PRCL.

The most striking observations are:

1. most transfer functions are very smooth with 1/f or 1/f^2 shape
2. they changed significantly between the two measurements

The transfer function PRCL_IN1 / PRCL_OUT should be a good measurement of the optical gain. The gain measured the second time is ~0.75 the gain measured the first time. So we're losing PRCL optical gain over time. Not a new story. Probably thermal effects.

PRCL to MICH and SRCL coupling got smaller.

PRCL to CHARD_P got smaller, but PRCL to CHARD_Y got larger (by a factor 3-4, depending on frequency). This might be explained if the beam spot is moving on the PRM over time, in yaw, to increase the length to angle coupling. It's interesting that this is happening in yaw and we know we have a yaw alignment problem in the PRC.

Another interesting coupling is from PRCL to REFL_RIN. Ideally we should not have any linear coupling from PRCL to REFL power. This could happen if PRCL or CARM were locked off resonance. The fact that the coupling RIN / PRCL is getting larger (by a factor 2) might indicate that the PRCL (or CARM) offset is changing over time. Probably thermal effects? Maybe also related to the change in optical gain?

TITLE: 03/29 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY:
Nominal_Low_Noise Reached at 20:03 UTC
The Following comissioning tasks were attempted:
    Robert
    Elenna PRCL (current doing 20mins)
    Naoki 100/100 ASQZ
    Jennie CMB OLG measure at 1h30 in NLN
    Naoki 125/125 ASQZ (20mins) until 2:50pm
    Robert (20mins) until 3:10pm
    Elenna PRCL (~10mins) until 3:30pm
    Robert (20mins)
    Camilla FF injections (maybe- could wait until we're better thermalzied Monday)
last 2 did not finish.

Lockloss at 23:00 UTC
Unknown source of lockloss, but there was a PEM group member in the LVEA "unplugging stuff" when the lockloss happened. More investigations needed.
ScreenShots attached.
LOG:                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

Jenne, Jennie

As we were about to go to Observing today, we noticed two DIFFs in observe in EYISC model.

Looking through the alog Jenne noticed that Ryan accepted these diffs the other day, but they showed up the opposite way round as diffs today meaning the guardian changed them back as we locked. Therefore the evening operator should accept these diffs to be

2 for COMBOOST and 6 for IN1GAIN.

We took 10 minutes no sqz time.

PDT: 2024-03-29 15:41:17-15:51:17 
UTC: 2024-03-29 22:41:17-22:51:17
GPS: 1395787295-1395787895

Camilla, Jennie W

Camilla and I measured the CARM loop after restarting the SR785 earlier.

We followed instructions here.

The OLG seems similar to two days ago after Sheila decreased the gain.

Our measurement was done about 1 hr and 17 mins into lock so while we were thermalising.

The measurement Sheila did was done about 2 hrs and 19 mins into lock.

Maybe we should measure this again during a well-thermalised lock so we will aim to do this on Monday.

Naoki, Nutsinee

We changed the PSAMS from 100/100 to 125/125. We ran the SCAN_ALIGNMENT with asqz-optimized. The result is here.

https://lhocds.ligo-wa.caltech.edu/exports/SQZ/GRD/ZM_SCAN/240329142738/

The asqz and sqz time for 125/125 PSAMS is as follows.

asqz
PDT: 2024-03-29 14:37:25-14:42:25
UTC: 2024-03-29 21:37:25-21:42:25
GPS: 1395783463-1395783763

sqz
PDT: 2024-03-29 14:47:30-14:52:30
UTC: 2024-03-29 21:47:30-21:52:30
GPS: 1395784068-1395784368

Naoki, Vicky, Sheila, Camilla

To scan the sqz angle to optimize the squeezing in the bucket, we copied the SCAN_SQZANG state in SQZ_MANAGER guardian in LLO. This state will find the optimal sqz angle to minimize the BLRMS3 at 350 Hz. We replaced the 0.1 Hz LP with 1 Hz LP for BLRMS3. We will test this state tomorrow.

Vicky, Naoki, Nutsinee

To scan the ZM alignment, we copied the SCAN_ALIGNMENT state in SQZ_MANAGER guardian in LLO. After some debugging, we successfully ran this state. The result is saved in here.

https://lhocds.ligo-wa.caltech.edu/exports/SQZ/GRD/ZM_SCAN/

This state scans the ZM4/ZM6 COM and DIF P/Y. We need the proper diagonalization to define the COM and DIF, but we have not done it today. The state fits the BLRMS6 at 1.7kHz and finds the optimal ZM slider value for minimizing the BLRMS6 as shown in the first attachment. After each ZM scan, the SQZ angle is also scanned and the optimal SQZ angle is found as shown in the second attachment.

The third attachment shows the BLRMS. The T1 cursor shows when the sqz-optimized scan was done. After the scan, the BLRMS6 looked good, but the BLRMS3 (yellow) was not so good and the BNS range was below 150 Mpc. So we tweaked the sqz angle and the BNS range reached more than 150 Mpc.

The original SCAN_ALIGNMENT tries to find the minimum of squeezing, but we modified it so that it can also try to find the maximum of anti squeezing. The T2 cursor in the third attachment shows when the asqz-optimized scan was done. The result is saved here.

sqz-optimized: https://lhocds.ligo-wa.caltech.edu/exports/SQZ/GRD/ZM_SCAN/240327132206/

asqz-optimized: https://lhocds.ligo-wa.caltech.edu/exports/SQZ/GRD/ZM_SCAN/240327144407/

The fourth attachment shows the ZM slider after the sqz-optimized and asqz-optimized scan. The ZM4 Y is almost the same, but other ZM alignment is different by 10-20 counts between the sqz-optimized and asqz-optimized scan. The proper diagonalization of ZM4/6 would resolve it.

Since the SCAN_ALIGNMENT touches the TRAMP of ZM slider, we reverted it after the scan as shown in the fifth attachment.

Artem, Jennie W., Gabriele

Following up on alog 76516.

We compared DARM for following configurations:
* No squeezing O4a, 12/20/2023 18:10-18:20
* With squeezing O4a, 01/12/2024 01:35:15-01:45:15 
* No squeezing now, 03/17/2024 04:45:31-04:55:31
* With squeezing now, 03/17/2024 08:18:46-08:28:46

Specifically, following ASDs were calculated: sqrt(abs(no_sqeezing_now^2 - no_squeezing_o4a^2)), and sqrt(abs(squeezing_now^2 - squeezing_o4a^2)). These are shown as blue and red traces on the attached plot. The original DARM traces are shown in gray.

Our preliminary conclusion from this is that it appears that excess noise is ~same with and without squeezing.

We'll make this plot with longer time series and do some more tests.

Jupyter notebook is available here.