Sheila, Jennifer W, Oli, TJ

It was decided that the recent changes of the IMs and the PRs might have put us in a bad alignment ( alog76366 and some control room and matter most conversations) . We reverted those to two days ago, scope trend, and then we decided to try to pico the HAM3 pop pico - labeled as ALS/POP beam steering HAM1, motor 8. This didn't make any positive changes in the beatnotes and arm powers together, so we brought them back to their starting positions and decided it was bes to to to ISCT1 to help match our IFO alignment, bring our DIFF beatnote back up, and we could fix some clipping that we've known about on the ALSY path to the PD and camera (alog76287).

Before going on table I ran a green initial alignment, input align, and mich bright. The BS circled in pink on the layout attached was translated to reduce the clipping on that optic. The downstream BSs within the light blue circle then needed to be adjusted to maximize the diff beatnote.

Looking at a  power up (comparing when we get to 60W input as reference time to 40s and 120s later), we can see no evidence of point absorbers on ITMY after 120s and 40s. On ITMX after 120s and  40s can see our known point absorbers 66197.

Attached the spherical power trends of, ITMX changes 118μDiopters, ITMY changes 103μDiopter (double pass). It is expected the ITMX curvature  will change more due to the point absorbers.

TCS SIM current status (sitemap > TCS > SIMULATION):

• Daniel/Aidan added channes for annular CO2 (H1:TCS-SIM_ITMY_SUB_DEFOCUS_CO2_AN) in 71467l.
  • The long term CO2 seems to change more than we measure using the HWS spherical power (compared orange spherical power to yellow TCS-SIM trend in attached plot).
• I updated the TCS-SIM SELF absorbsion values to the values measured in in 71400 475ppb for ITMX and 375ppb for ITMY (Prev done in 26014).
  • H1:TCS-SIM_ITMX_SURF_ABSORPTION Old 3e-07, changed to 4.75e-07
  • H1:TCS-SIM_ITMY_SURF_ABSORPTION Old 3.6e-07, changed to 3.75e-07

D. Barker, J. Kissel, O. Patane, R. Short
ECR E1700387
IIET Ticket 9392
WP 11743

This aLOG that summarizes all the details of the work that went in to upgrading the SUS ETM and SUS TMS watchdog systems this past Tuesday, Mar 12 2024.

Front-end model and MEDM screen infrastructure changes: LHO:76269
    To receive these upgrades, 
    - svn up the following common directories,
        ${userapps}/release/sus/common/models/
        ${userapps}/release/sus/common/medm/quad/
    - svn up the following h1 specific directories and copy what top-level changes that are shown in the above linked aLOG,
        ${userapps}/release/sus/h1/models/
        ${userapps}/release/sus/h1/filterfiles/
        
Dave's summary of the install, and corresponding issues: LHO:76304

Filling out the foton and EPICs infrastructure to get the new WD system functional: LHO:76352
    To receive these upgrades,
    - svn up the following h1 specific directories and copy what filters you see in the OSEMAC_BANDLIM and OSEMAC_RMSLP filter banks
        ${userapps}/release/sus/h1/filterfiles/
      or use the design strings described in LHO:76352.
     
A review of the calibrated BLRMS output vs. thresholds: For ETMs LHO:76343 for TMTS LHO:76347
     - Note, 25 [um_RMS] is still an arbitrary threshold. We've already found that it might behoove us to increase the ETM L2 threshold to 30 [um_RMS], but for many other stages, something lower might suffice. Only time and data will tell.

Surrounding python code underneath MEDM infrastructure: LHO:76389.
    To receive these upgrades (when we've reconciled the issues discussed in this LHO:76389 aLOG)
     - svn up the following common directory,
        ${userapps}/release/sus/common/scripts/

Proposed Schedule of the continued roll-out:
Next week (Mar 19 2024), we hope to upgrade the ITMs and the BS.
The following week (Mar 26 2024), we hope to upgrade the HSTS and HLTS.
The following week (Apr 02 2024), we hope to upgrade the OMCS, HTTS, and HAUX
The following week (Apr 09 2024), we hope to go through the already new WDs and calibrate their RMS signals, and update the thresholds, like we'll have done for the above "older" suspensions along the way.

J. Kissel, O. Patane, R. Short

One last aLOG about Tuesday's upgrade to the ETM and TMS watchdog system -- this time related to the python infrastructure surrounding the watchdog. That means two things:
    (1) The SUS guardian code, which is primarily driven by the code generic to all suspensions,
            /opt/rtcds/userapps/release/sus/common/scripts/
                sustools.py
        has a dictionary in it that defines whether to look for USER DACKILL channels. Since these were removed from EPICs, the ETM and TMS guardians threw connection errors after the model restarts.
        To resolve, we removed the "'USER': 'DACKILL', entries from the quadwd and tmtswd dictionary definitions around lines 1660 to 1670 of rev 23101.

        Unfortunately, because there's some incoming updates from L1 that we don't understand, we can't commit the changes.

    (2) There is python code underneath the hood of the "RESET ALL" button on the WD overview MEDM screens,
            /opt/rtcds/userapps/release/sus/common/scripts/
                wdreset_all.py
        In the old system, that python code pushes the (one) reset button (channel) that untrips all of the user watchdogs, as well as pressing the reset button (channel) on the USER DACKILL. 
            ezca['SUS-' + optic + '_WD_RESET'] = 1

            ezca['SUS-' + optic + '_DACKILL_RESET'] = 1
        Now that there no longer exists a USER DACKILL button to press on the ETMs and TMS, and because the python script is called in the MEDM screen with an ampersand, the call to the script successfully resets the user watchdogs, but then quietly breaks/fails in the background.

        Not good coding in practice, but not an impactful at this point. Indeed, because this is also common code to all suspension MEDM screens, the reset of the DACKILL is still *needed* for any suspensions that haven't yet had this upgrade. So, for now, we leave this ugly thing too.

Dhruva, Naoki, Nutsinee

We had power mysteriously dropped out of PDA multiple times after adjusting the half wave plate on SQZT7 so we went hunting for lose optics. We found a lose beam splitter cube mount on the LO path so we tighten that but it didn't fixed the problem. We accidently discovered that if we pushed PDA we got the power back. We suspect PDA came lose from the circuit board. HD DIFF has been readjusted.

Today's Fringe visibility on 

PDA is 0.986

PDB is 0.985

Trent, Georgia

The new QPD offsets improved the coherence from when the offsets were turned off. However, this new coherence is still lower than coherence from the initial QPD offset values.

See Gabriele's post for more info about the OMC alignment and QPD offsets.

We wanted to look at the coherence between OMC-REFL and DARM with the OMC QPD B offsets on and off. We looked at the coherence between the following channels.

• H1:CAL-DELTAL_EXTERNAL_DQ
• H1:OMC-REFL_A_LF_OUT_DQ

The blue, green, and red curves have less averages because there was not as long of a time between glitches/losing lock as the black curve.

We took the blue and green curves to determine if there was something else that could have caused the coherence to lower besides turning the offsets off. There is not a significant difference between the blue and green curves so we can conclude that the coherence is lower when the offsets are turned off.

The coherence of all the curves is quite low (<0.1).

The red curve is the coherence with the new QPD offsets and we see that the coherence is still lower than the black curve (the initial QPD offsets).

I switched sw-psl-aux and sw-lvea-aux to using lldp instead of cdp.  This is to help with continued documentation and visibility of the network.  At this point with the rebuild of the network CDP gives us less information, so it has been turned off.

M. Barton, J. Kissel. O. Patane

Recall, we'd had issues understanding why the modeled top-mass pitch to pitch transfer function looked so weird (see LHO aLOGs 75787 and 75947).

After 
    - Mark's suggestion of the problem (suggested over email and mentioned on the 2024-02-29 a+ SUS call), and
    - Oli's hard work proving that that *was* the problem (see LHO:76071), 

I've now closed the loop for the bbssopt.m Bigger Beam Splitter Suspension's production model parameter set that best matches the first article data:
    - Added a few more slides to G2400442 conveying the resolution, now at -v2
    - copied over the temporary bbssopt_pendstage2on_d1minus2p5mm_d4minus1p0mm.m parameter set on top of bbssopt.m parameter set,
    - committed bbssopt.m to the SusSVN as of rev 11778.

The screenshot of the comparison shows the differences between the previous rev and the current rev:
    - the pend.stage2 boolean flag is now set to 1.0, which matches that the ds are defined as physical ds, and
    - d1 and d4 are (slightly) adjusted to better match the first article.

To generate transfer functions from this production model parameter set, 
    (1) find a computer with the 
    /ligo/svncommon/SusSVN/sus/trunk/Common/MatlabTools/TripleModel_Production/

folder checked out, 
    (2) open Matlab, 
    (3) Run the following commands:
        >> freq = logspace(-2,2,1000);
        >> buildType = 'bbssopt';
        >> svnDir = '/ligo/svncommon/SusSVN/sus/trunk/';
        >> plotFlag = false;
        >> [bbss,~,~,pend] = generate_Triple_Model_Production(freq,buildType,svnDir,plotFlag);
        >> figure(1);
        >> ll=loglog(freq,abs(squeeze(bbss.f(bbss.out.m3.disp.L,bbss.in.gnd.disp.L,:)))); %%% Chose which DOF you want to plot here
        >> set(ll,'LineWidth',2);
        >> grid on;
        >> title('BBSS Susp. Point. L to Optic L');
        >> xlabel('Frequency [Hz]'); ylabel('Magnitude [m/N]')
        >> shg
which will produce the attached plot.
       

The end station dust monitors are running smoothly. EX needed a slight adjustment. The corner station pump has been turned off. The temp was reading just over 200F. I will swap that pump out after it has cooled down.

List of Commissioning / Locking Activities that the commissioning, ops team and visitors have done so far this week:

• Tuesday 5th March
  • OMC scans 76124
  • Gate values opened 76129
  • Locking up to DARM_TO_RF 76138 76136 76133
• Wednesday 6th March:
  • Locking up to DHARD_WFS 76166 76149
  • OMC ASC 76158 76103
• Thursday 7th March:
  • Locking 76198 76184 nearly to MAX_POWER
  • OMC guardian working 76188
• Friday 8th March:
  • Locking, get to NLN 76207
  • OMC alignment change 76223
  • OMC QPD dark offsets adjusted 76211
  • Opened FC and got 4.5dB of SQZ 76220 76212 76226
  • Sheila's GRD change notes for useful relocking after vent: 76214
• Saturday 9th March:
  • DARM OLG and sensing tfs taken 76229
  • DARM offset steps measured 76231
• Sunday 10th March:
  • No changes in log
• Monday 11th March:
  • Adjusted SR2 during locking 76245
  • Updaetd calibration for CAL_DELTAL_EXTERNAL 76271
  • OMC alignment change 76252
  • ASC WFS picoed 76252
  • OMC-DCPD_MATRIX saved to SDF 76265
  • OMC input and dither matrix adjusted  76274 76243
  • CAL CS LSC actuator filters updated 76261
  • LSC SRCL MICH FF retuned 76279
• Tuesday 12th March:
  • New SQZ CLF VCO (still need to check how this effected SQZ) 76297
  • Slow relock after Tuesday Maintenance, PR3 move 76310
  • IMC and IM alignment changes for IM4 trans - reverted 76291
  • Pico-ed ISS 2nd loop - reverted 76303
  • DHARD Y new filter 76314
  • Check A2L, kept the same 76312
  • New DARM transition 76315
• Wednesday 13th March:
  • Another OMC alignment change 76335
  • New DARM turned on 76365
    • Crossovers measured 76355
    • Filters in L2, L3 adjusted
    • Roll mode rang up
  • IM1/IM3 move 76359 (reverted 14th March)
  • Testing PR3 for ASC sensor 76364
  • ITMY A2L, measured not changed 76363
  • POPAIR calibrations taken 76358
  • Intensity noise measured, not effecting DARM ~100Hz 76323
  • SQZ ZM4/5 adjustments: moved from 100/100 to 150/120
  • No SQZ times 76324
• Thursday 14th March:
  • Alignment changes reverted 76370
  • ISCT1 realignment - ongoing

Thu Mar 14 10:12:31 2024 INFO: Fill completed in 12min 27secs

Gerardo confirmed a good fill curbside.

Pictures of HAM 7 feed throughs D1, D4, D6 and the -Y door as per D1900116 V12. Pictures are in order. First two are D1, three of D4, three of D6.

Pictures of feed throughs on the HAM6 chamber. These reflect the current layout as per D1002877 V14. In order there are three pictures of each D3, D4, D5, D6 and the -Y door.

In addition to and confirming what already reported by Elenna, Camilla and Craig, here's a comparison with a lot of averages of DARM during O4a and now.

[Evan, Swadha]

We are trying to find a way to prevent PR3 angular motion from being impressed onto the test masses by the ASC. We had previosuly attempted unsuccessfully to diagonalize PR3 motion out of the REFL sensing matrix. Since that did not work, we are trying to find a potential error signal for suppressing PR3 motion.

We tried to close a loop around PR3 pitch using POP_A. We took the matlab plant model for HLTS M2 torque to M3 pitch, inverted it, and put it into the PRC1 filter bank (attached for pitch). We then turned on a 1/f filter. Driving M2 with this filter and turning up the gain, we found that the error signal was suppressed but microseism was being impressed onto PR3 as seen in the oplev spectrum (attached). Therefore, POP_A does not seem to be a good sensor.

[Elenna, Gabriele]

We injected broadband DHARD_Y noise and measured the couplig to DARM with different values of the ITMY Y2L gain. As we saw in the past, there are two coupling regimes:

• below 20-30 Hz, steep frequency dependency, changes little with the Y2L gain
• above 30 Hz, flat-ish in frequency, changes signficantly with Y2L

The nominal value of Y2L gain is -1.65, that we found yesterday to be optimal for DHARD_Y to DARM coupling, using a line at 30 Hz.

Today the situation is different, a gain of -0.9 would reduce the coupling above 30 Hz by 20+ dB, at the price of a larger coupling below 30 Hz (where we care for DHARD_Y noise). Between yesterday and today: new OMC alignment, new DARM offloading, new input alignment, so probably it's not a big surprise that the optimal A2L is different.

We left the value to -1.65, since that is the best at frequencies below 30 Hz, where there is still coherence between DHARD_Y and DARM.

Craig, Jennie W.

In order to calibrate POPAIR_RF9 and RF18 PDs in terms of PRG9 and 45, we ran Craig's labutils/mod_depth_up_down_test.

We realised our mod depth up/down test from the other day was changing the gain of the POPAIR diodes to compensate the drop in optical gain as the modulation depths are changed.

We don't want this as it negates the change on the diodes we are trying to measure for our calibration.

Craig commented out these lines in the step_9 and step_45 functions.

We also were overestimating the PRG as the beam on IM4_TRANS PD was not well-centred.

In this log we stepped the alignment in lock to optimise on the IM4 TRANS QPD and the ISS array.

The mod-up-down-test was taken during low frequency measurements of new DARM.

Times RF9 was stepped down are 1394406378 GPS, then back up at 1394406438 GPS.

Times RF45 wa stepped down are 1394406448 GPS, then back up at 1394406508 GPS.

After this test Craig did more optimisation of the input alignment with IM 1 and 3.

Then I waited a bit and took another test. Both were done with a well thermalised IFO of more 10 hours lock.

Times RF9 was stepped down are 1394409674 GPS, then back up at 1394409735 GPS.

Times RF45 wa stepped down are 1394409744 GPS, then back up at  1394409804GPS.

First image is beam diverter that needs unshuttered for this test.

Second image shows the plots from the first test, third image shows the second test.

Jennie, Matt Todd, Craig

TL;DR We restored the alignment from O4a onto the ISS QPD array and IM4 Trans by moving IM1 and IM3
This has recovered the full-lock input-on-the-PRM power from 54.5 W to 57.5 W.
We are probably in a spot where we can trust Keita's IM4 TRANS calibration from alog 62213 again,
meaning we can trust our PRG of 50 W/W.


History
I tried doing this yesterday (alog 76291), but we were worried about changing the input alignment while not in lock.
Later, Sheila tried picoing onto the ISS Array (alog 76303), but undid her changes when they were causing us to fall off the array.

Alignment
Loosely, we wanted to restore the alignment we had at the end of O4a.
Centering on the ISS QPD is not necessarily the best for the alignment onto the actual ISS Array.
Additionally, the ISS QPD dofs are flipped (PIT is YAW, YAW is PIT).

I started moving IM3 and IM4 in conjunction to center the QPDs, but this didn't work because we were moving too much on the ISS QPD and not really moving on IM4 TRANS, to the point where we were falling off the diodes in the array.
So after that, I started moving IM1 and IM3 with much better results, pitching up with IM1 onto IM4 TRANS, then recovering the ISS QPD with pitching down IM3.
We ended up at the below alignments:


Epoch       GPStime         Sensor        Pitch        Yaw
---------------------------------------------------------
O4a      1389013541        ISS QPD        -0.62       0.72
                         IM4 TRANS        -0.44      -0.34

Pre-O4b  1394409800        ISS QPD        -0.54       0.75
                         IM4 TRANS        -0.02      -0.20

No SQZ time taken this morning 15:29UTC to 15:51UTC. There was small glitches at 15:35:37 and 15:41:53. Best stretch of time is 15:42:00 to 15:51:00. Took no sqz time with hot OM2 in 74834 / 74640, Cold OM2 Dec 20th 18:00- 18:18UTC 74935.