aLIGO LHO Logbook

H1 General - Ops EVE Shift End

oli.patane@ligo.org — Fri, 19 Apr 2024 00:00:18 -0700

Author: oli.patane@ligo.org

Report ID: 77280

TITLE: 04/19 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 157Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Currently Observing and have been Locked for 36 minutes.
Two unknown locklosses during my shift. The lockloss tool flagged the first one as windy, but since the wind went just above 20mph 4.5 minutes before we lost lock, I don't think that is the reason. The second lockloss had a set of small glitches in the 300ms before the LL(attachment).
LOG:

23:00 Detector Observing and Locked for 6 hours

01:02 Lockloss
- Relocking
- Couldn't get past DRMI so I took us to DOWN to run an initial alignment
01:23 Initial alignment start
01:41 Initial alignment done, relocking
02:21 NOMINAL_LOW_NOISE
02:23 Observing

04:56 Lockloss
- Relocking
05:16 Lost lock at TRANSITION_DRMI_TO_3F, starting initial alignment
05:37 Initial alignment done
06:20 NOMINAL_LOW_NOISE
06:23 Observing

Start Time	System	Name	Location	Lazer_Haz	Task	Time End
00:18	PCAL	Francisco	PCAL Lab	y(local)	PCALin	00:54

Images attached to this report

H1 General - Comment to Lockloss

oli.patane@ligo.org — Thu, 18 Apr 2024 23:23:44 -0700

Author: oli.patane@ligo.org

Report ID: 77279

06:23 Observing

H1 General - Lockloss

oli.patane@ligo.org — Thu, 18 Apr 2024 21:58:16 -0700

Author: oli.patane@ligo.org

Report ID: 77278

Lockloss 2024/04/19 04:56utc

Lockloss

H1 CAL - CAL kappa value increases

oli.patane@ligo.org — Thu, 18 Apr 2024 20:59:40 -0700

Author: oli.patane@ligo.org

Report ID: 77277

Between yesterday 2024/04/17 16:48utc and today's lockloss at 2024/04/18 15:25utc, there were three sets of times where the calibration kappa values were suddenly louder than normal. Attachment1 and attachment2 show the three lock stretches (labeled 1, 2, and 3) over which this was seen, as well as showing kappa ranges from other locked times. The white dotted lines give an idea of the boundaries that the majority of kappa values fall within. The first time this showed up was 2024/04/17 16:48utc(stretch1), where we were locked in NOMINAL_LOW_NOISE and commissioning. The kappa values had flatlined for three minutes before then coming back larger than normal. Stretch2 and stretch3 were over the entirety of the next two locks. However, the lock following those two starting at 2024/04/18 17:26utc, the values seemed to be back to normal.
I mentioned this increase to Louis last night and he said "I think we need to increase the calibration line amplitudes". I'm not sure if something was done about this today between locks that brought the values back to what they were previously.

Images attached to this report

H1 General - Comment to Lockloss

oli.patane@ligo.org — Thu, 18 Apr 2024 19:26:09 -0700

Author: oli.patane@ligo.org

Report ID: 77276

02:23 Observing

H1 General - Lockloss

oli.patane@ligo.org — Thu, 18 Apr 2024 18:03:54 -0700

Author: oli.patane@ligo.org

Report ID: 77275

Lockloss 04:19 01:02UTC from unknown cause

Lockloss

H1 General - Ops EVE Shift Start

oli.patane@ligo.org — Thu, 18 Apr 2024 16:36:27 -0700

Author: oli.patane@ligo.org

Report ID: 77274

TITLE: 04/18 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 152Mpc
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 12mph Gusts, 8mph 5min avg
    Primary useism: 0.05 μm/s
    Secondary useism: 0.12 μm/s
QUICK SUMMARY:

Observing and have been locked for 6 hours.

LHO General - Thurs DAY Ops Summary

corey.gray@ligo.org — Thu, 18 Apr 2024 16:24:13 -0700

Author: corey.gray@ligo.org

Report ID: 77265

TITLE: 04/18 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Oli
SHIFT SUMMARY:

The day started out with plans of coordinated-Commissioning but that soon changed after another earthquake took H1 down (so coordinated-commissioning was shifted to later in the morning) and a return to Observing in the afternoon.
LOG:

1502 Out Of Observing: Fix H1 + 8-11amLocal Commissioning
1502-1508 Transitioned to NO Squeezing & then back to FD Squeezing---this got the range up to almost 140Mpc.
1509 A2L measurement (sheila)
1522 Needed to reposition Picket Fences on nuc5
1524 Lockloss due to M5.6 earthquake in the Gulf of Mexico
1538 Rolling a big speaker across the LVEA + overall Injection set-up. Will be in/out. (Robert)
1624-1645 Initial Alignment (since PRMI looked bad)
1625-1639 Technical cleaning at H2 room (kim)
1705-1720 Amber tour
1725 Commissioning II
1837-1848 Robert Frost 5th grader tour (Cassidy, Maggie)
1928-1956 Pcal lab work (francisco)
1942 Test/Practice phone call received for a Test "Take Cover" received & stand down at 2011
2015 Pcal Lab work (tony)
2034 Back to OBSERVING
2118 MR Mezzanine for TCS rack photos (fil)
22:30 Ops Meeting!

H1 SEI - H1 ISI CPS Noise Spectra Check - Weekly

thomas.shaffer@ligo.org — Thu, 18 Apr 2024 15:15:12 -0700

Author: thomas.shaffer@ligo.org

Report ID: 77273

FAMIS25987

All plots looks good to me. Jim happened to be next to me while I ran this and said that there may have been an earthquake during the time this uses, but it seems to have only raised the low frequency up and not changed the high frequency that we care about for these CPS checks. All good.

Non-image files attached to this report

CPS_spectra_15:07-04_18_2024.pdf

H1 ISC - There may be a bit more Jitter Cleaning to do

jenne.driggers@ligo.org — Thu, 18 Apr 2024 14:55:07 -0700

Author: jenne.driggers@ligo.org

Report ID: 77272

Now that Sheila and Jennie have done lots of work to get our arm pointing and A2L couplings improved, there may be a small amount of jitter cleaning improvement that can be gained.

In the attached image, red and blue are from today after the commissioning time. Green and brown are from a week ago when we had ~165 Mpc cleaned range. Red and Green are pre-cleaning, and Blue and Brown are after line subtraction and cleaning. In the area between 100-200 Hz, it looks like the blue current trace is perhaps not quite as flat as the brown trace, so maybe there is a teeny bit more that an updated cleaning coefficient set could eeek out. Once the cleaned trace is flat, if there is an overall level change, that probably wouldn't be able to be cleaned out.

I'll try to look at some Observing time from tonight, to see if there is an improved candidate set of coefficients we can try. As a reminder, the jitter coupling is still quite close to what it was in O4a, and the cleaning coefficients are currently the same as they have been since Fall 2023.

Images attached to this report

H1 ISC - A2L decoupling, depends on thermalization

sheila.dwyer@ligo.org — Thu, 18 Apr 2024 13:41:29 -0700

Author: sheila.dwyer@ligo.org

Report ID: 77269

Jennie W, Sheila

Summary: We spent some time today resetting A2L gains, which make a large impact on our range. We are leaving the gains set in guardian to be the ones that we've found for 3 hours into the lock, but this will probably cost us about 5Mpc of range early in the lock.

Overnight, our our low range was partially because the angle to length decoupling was poor (and partly because the squeezing angle was poor). We were running the angle to legnth decoupling script this morning when an EQ unlocked the IFO, and now we have re-run it with a not thermalized IFO.

I manually changed the amplitudes for the A2L script again on a per optic bassis to get each A2L set in a first round, there was still significant CHARD P coherence. I've edited the run_all_a2L.sh script so that some degrees of freedom are run with amplitudes of 1, 3 or 10 counts excitations, this has now run and suceeded in tuning A2L for each DOF on each optic, this second round seems to have improved the sensitivity. We may need to tune these amplitudes each time we run a2L for now.

After our second round of A2L, the ASC coherences were actually worse than after only one round. We tried some manual tuning using DHARD and CHARD injections, but that didn't work well probably because we took steps that were too large.

After the IFO had been locked and at high power for ~3 hours, we re-ran the A2L script again, which again set all 4 A2L gains, and impoved the range by ~5Mpc compared to the A2L settings early in the lock (see screenshot). I've accepted these in SDF and added them to LSCparams:

        'FINAL':{
            'P2L':{'ITMX':-0.9598, #+1.0,
                   'ITMY':-0.3693, #+1.0,
                   'ETMX':4.1126,
                   'ETMY':4.2506}, #+1.0},
            'Y2L':{'ITMX':2.8428, #+1.0,
                   'ITMY':-2.2665, #+1.0,
                   'ETMX':4.9016,
                   'ETMY':2.9922 },#+1.0}

This means that the A2L probably won't be well tuned for early in the locks when we relock, which may cost us range early in the locks. In O4a we werw also using the camera servo, not ADS, and since we set the camera servo offsets to match ADS alignment early in the locks, we probably had less than optimal decoupling late in the lock stretches. This probably had less of an impact on range since these noises are contributing in the same frequency range as the ESD noise was in O4a.

Images attached to this report

H1 SQZ - PSAMS revert

naoki.aritomi@ligo.org — Thu, 18 Apr 2024 13:39:11 -0700

Author: naoki.aritomi@ligo.org

Report ID: 77268

Naoki, Camilla

We reverted PSAMS from 7.5/0.55 to 8.8/-0.67, which was done last Friday in 77133. Before and after PSAMS change, we ran SCAN_ALIGNMENT and took 5+5 min asqz/sqz data. The attached figure shows that 8.8/-0.67 is better than 7.5/0.55. In parallel, A2L tuning was ongoing so the noise below 100 Hz in SQZ should be due to A2L.

asqz 120/137 (strain voltage 7.5/0.55) (5 min)

PDT: 2024-04-18 10:59:48 PDT
UTC: 2024-04-18 17:59:48 UTC
GPS: 1397498406

sqz 120/137 (strain voltage 7.5/0.55) (5 min)

PDT: 2024-04-18 11:06:29 PDT
UTC: 2024-04-18 18:06:29 UTC
GPS: 1397498807

asqz 170/95 (strain voltage 8.8/-0.67) (5 min)

PDT: 2024-04-18 12:01:57 PDT
UTC: 2024-04-18 19:01:57 UTC
GPS: 1397502135

sqz 170/95 (strain voltage 8.8/-0.67) (5 min)

PDT: 2024-04-18 13:35:01 PDT
UTC: 2024-04-18 20:35:01 UTC
GPS: 1397507719

Images attached to this report

H1 ISC - Comment to New HAM1 FF

gabriele.vajente@ligo.org — Thu, 18 Apr 2024 12:27:18 -0700

Author: gabriele.vajente@ligo.org

Report ID: 77271

I looked at the attempt of engaging the HAM1 yaw FF:
1) the filter that were loaded were correct, meaning they were what I expected
2) retraining with a time when the HAM1 pitch FF were on yields yaw filters that are similar to what was tried, so it doesn't look like it's a pitch / yaw interaction (Jennie also pointed to some evidence of this in the alog)

I suspect there might be cross coupling between the various yaw dofs. I would suggest that we upload the newly trained filters (attached) and try to engage the yaw FF one by one, starting from CHARD that is the one we care most

Images attached to this report

Non-image files attached to this report

HAM1_FF_2024_04_18.txt

LHO VE - Thu CP1 Fill

david.barker@ligo.org — Thu, 18 Apr 2024 10:16:59 -0700

Author: david.barker@ligo.org

Report ID: 77267

Thu Apr 18 10:06:27 2024 INFO: Fill completed in 6min 23secs

Jordan confirmed a good fill curbside.

Images attached to this report

H1 SQZ - Comment to SCAN_SQZANG added to nominal SQZ path

camilla.compton@ligo.org — Thu, 18 Apr 2024 09:13:33 -0700

Author: camilla.compton@ligo.org

Report ID: 77266

I have removed this change of path by removing thew weighting as we can see last night SCAN_SQZANG at the start of the lock took us to a bad squeezing once thermalized.

We weren't seeing this changing angular dependence as much before 77133 with the older PSAMS settings (8.8V,-0.7V) or (7.2V, -0.72V). Current (7.5V,0.5V). We think we should revert to the older setting.

Images attached to this report

H1 General - Thurs DAY Ops Transition

corey.gray@ligo.org — Thu, 18 Apr 2024 08:12:21 -0700

Author: corey.gray@ligo.org

Report ID: 77264

TITLE: 04/18 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 117Mpc
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 7mph Gusts, 6mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.10 μm/s
QUICK SUMMARY:

H1's had range hovering between 150-155Mpc 24hrs ago. After the EQs last night, H1 made it back UP. but seems a bit off with a range down near 110Mpc. Sheila has just walked in and mentioned Commissioning time is planned from 8-11am this morning and she is jumping in on that---so we are out of OBSERVING. Heard Sheila mentioned angular coupling and tried No Squeezing and is now looking at A2L (but we are at the very beginning of investigations and commissioning).

The togglingof No Squeezing to Freq Dep Squeezing helped with the range already. And Sheila is currently running an A2L. And it looks like L1 is also joining us with commissioning.

H1 SUS - SUS SDF Diffs Accepted

anthony.sanchez@ligo.org — Thu, 18 Apr 2024 02:54:26 -0700

Author: anthony.sanchez@ligo.org

Report ID: 77263

I accepted these P2L spot gain SDF Diffs to get into Observing.

Images attached to this report

H1 DetChar - DQ shift report for week from 2024-04-08 to 2024-04-14

manasadevi.thirugnanasambandam@ligo.org — Thu, 18 Apr 2024 02:41:11 -0700

Author: manasadevi.thirugnanasambandam@ligo.org

Report ID: 77262

Summary highlights of DQ shift the week from 2024-04-08 to 2024-04-14

The IFO was in observing mode for 74% avg. (lower during the first half of the week and better during the second half)
LHO was observing at a range of 158 Mpc with some dip in range to 134Mpc on the first 2 days of the week (8th and 9th).
For most of the week, whenever the IFO transitioned to observing from a lockloss, the strain h(t) showed noise in the lower frequency regions 10-50Hz and also broadband high frequency noise (above 500Hz) which reduced with time. On some days, these features lasted for more than a couple of hours.
Violin modes at 500Hz and its harmonics were strong at the beginning of observation time after lock loss but dampened after a couple of hours.
Most of the high SNR omicron glitches were centered at ~ 40Hz
The dominant channels in Hveto were usually
- H1:PEM-EX_VMON_ETMX_ESDPOWER48_DQ
- H1:ASC-CHARD_Y_OUT_DQ
Fscan lines have been on the higher side in the range of 600 to 700 on most days this week.

Full DQ shift report with daily observations can be found in the wiki page here: https://wiki.ligo.org/DetChar/DataQuality/DQShiftLHO20240408

DetChar

H1 SEI - Owl Shift update.

anthony.sanchez@ligo.org — Thu, 18 Apr 2024 01:04:52 -0700

Author: anthony.sanchez@ligo.org

Report ID: 77261

TITLE: 04/18 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Aligning
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: USEISM_EARTHQUAKE
    Wind: 3mph Gusts, 1mph 5min avg
    Primary useism: 0.97 μm/s
    Secondary useism: 1.28 μm/s
QUICK SUMMARY:

Starting the Shift Oli and I noticed that the IFO was still relocking and needed an initial_alignment.
Since then Initial_alignment had stalled and been restarted. Possibly because the IMC was unlocked. I'm usure if Oli had done that or not.

Once that completed Another earthquake hit but was not announced over verbals.
M 5.3 - 60 km WSW of Pozo Dulce, Mexico 2024-04-18 07:39:45 (UTC)26.546°N 110.267°W10.0 km depth
So I'm just waiting on the earthquake to pass.

H1 General - Ops EVE Shift End

oli.patane@ligo.org — Thu, 18 Apr 2024 00:10:24 -0700

Author: oli.patane@ligo.org

Report ID: 77260

TITLE: 04/18 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Quiet night most of the night, but had a local earthquake knock us out close to the end of my shift. Currently running an initial alignment with the help of H1 MANAGER running an initial alignment and Tony watching H1 MANAGER run the initial alignment to make sure H1 MANAGER gets us locking once that's done.
LOG:

23:00 Detector Observing and Locked for over 15 hours

06:08 Earthquake mode activated
06:11 Lockloss due to local earthquake
- ALS flashed were really low and took a while to get up
07:03 Started an Initial Alignment

H1 General - Lockloss

oli.patane@ligo.org — Wed, 17 Apr 2024 23:12:35 -0700

Author: oli.patane@ligo.org

Report ID: 77259

Lockloss 04/18 06:11UTC due to local earthquake :( We were locked for 22.5 hours

Lockloss

H1 General - Ops Eve Midshift Status

oli.patane@ligo.org — Wed, 17 Apr 2024 20:45:30 -0700

Author: oli.patane@ligo.org

Report ID: 77258

Observing at 155Mpc and locked for 20 hours exactly. Calm evening with low wind

H1 SQZ - OMC Scan with SQZ beam yesterday

jennifer.wright@ligo.org — Wed, 17 Apr 2024 17:12:12 -0700

Author: jennifer.wright@ligo.org

Report ID: 77213

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.

ISC, SQZ

Images attached to this report

H1 TCS - CO2Y and CO2X Beam Scan

camilla.compton@ligo.org — Wed, 17 Apr 2024 16:29:44 -0700

Author: camilla.compton@ligo.org

Report ID: 77255

TJ, Camilla. WP 11811

Yesterday, we repeated the 76715 CO2 beam scan using a razor blade on a 25mm transition stage while measuring the power transmitted to our PD (channel H1:TCS-ITMX/Y_CO2_LSRPWR_MTR_OUTPUT).

We realized that some of the blocked beam was transmitted through a hole in the razor blade in our first set of measurements (changed radius measurement ~1mm) so the CO2X 76715 are not as trusted.

All data taken for CO2X and CO2Y attached and summarized below:

Position Downstream of CO2Y Annular Mask [mm] Downstream = (+), Upstream = (-)	Beam Raduis [mm]	Prev. measured with hole in razor
- 238	11.39	12.34
0	N/A	11.27 (think hole was covered)
+143	10.77	11.17
+194	10.61	11.39

Position Downstream of CO2X Annular Mask [mm] Downstream = (+), Upstream = (-)	Beam Raduis [mm]
+ 32	9.85
+ 133	10.01
+184	10.49

Non-image files attached to this report

CO2Y_16April24_beanscans.pdf

CO2X_16April24_beanscans.pdf

LHO General - OPS Day Shift Summary

ibrahim.abouelfettouh@ligo.org — Wed, 17 Apr 2024 16:00:52 -0700

Author: ibrahim.abouelfettouh@ligo.org

Report ID: 77256

TITLE: 04/17 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 126Mpc
INCOMING OPERATOR: Oli
SHIFT SUMMARY:

IFO is in NLN and OBSERVING

Comissioning today went well. We survived a few high magntitude earthquakes.

LOG:

Start Time	System	Name	Location	Lazer_Haz	Task	Time End
15:14	FAC	Karen	Optics, Vac Prep Labs	N	Technical Cleaning	15:43
15:43	FAC	Ken	FC Enclosure	N	Electrical maintenance	16:43
15:44	FAC	Karen	MY	N	Technical Cleaning	16:44
17:17	FAC	Fil	CS Recieving Door	N	Roll up recieving door	18:17
21:16	SQZ	Andrei, Sheila	Optics Lab	N	Tour	22:16

H1 General - Ops EVE Shift Start

oli.patane@ligo.org — Wed, 17 Apr 2024 16:00:02 -0700

Author: oli.patane@ligo.org

Report ID: 77257

TITLE: 04/17 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 146Mpc
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 16mph Gusts, 12mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.10 μm/s
QUICK SUMMARY:

We're Observing and have been Locked for over 15 hours.

H1 ISC - New HAM1 FF

jim.warner@ligo.org — Wed, 17 Apr 2024 14:34:14 -0700

Author: jim.warner@ligo.org

Report ID: 77254

Jennie, Jim

We tried Gabriele's newest version of the HAM1 ASC feedforward. New filters were installed last week, but we ran out of time during the commissioning window. It seems like we can still only get good subtraction from the pitch degrees of freedom, we got a lot of 10-ish hz injection when we engaged the yaw degrees of freedom.

To start we turned off the HAM1 ff, by setting H1:HPI-HAM1_TTL4C_FF_INF_{RX,RY,Z,X)}_GAIN to zero, then shutting off the H1:HPI-HAM1_TTL4C_FF_OUTSW. While collecting that data we switched to the new filters, and zerod the gains for all of the individual H1:HPI-HAM1_TTL4C_FF_CART2ASC{P,Y}_{DOF}_{DOF}_GAIN filter banks. We then tried turning on all of the pitch feedforward first, by ramping the gains in a couple of steps from 0 to 1. It seemed like it worked well, but I don't think we actually got to full gain of 1. We then tried turning on the yaw FF, but that pretty quickly started injecting noise around 10hz, first attached spectra, red traces are with the new ff, blue are with ff off.

Second image are trends where Jennie tries to reconstruct the timeline, which is how we found the first pitch test wasn't complete. Sheila ran an A2L measurement, then we tried the pitch ff again, spectra in the third plot. All of the red traces are new P ff (1397415884), blue is the old (1397407980), green is with the ff off (1397405754). This worked well, we got some slight improvements around 15hz, new chard p gets rid of some noise injection around 2hz. We didn't see the pitch ff affect the yaw dofs.

We left the new pitch filters running, and accepted in the Observe SDF. The yaw filters were left off.

SEI

Images attached to this report

H1 TCS - TCS Chiller Water Level Top-Off (Bi-Weekly, FAMIS #27787)

ibrahim.abouelfettouh@ligo.org — Wed, 17 Apr 2024 13:09:03 -0700

Author: ibrahim.abouelfettouh@ligo.org

Report ID: 77253

TCS Chiller Water Level Top-Off (Bi-Weekly, FAMIS #27787)

TCSx Chiller: Had level of 31cm. Added 235 to get to 39 (over-filled slightly beyond ruler)
TCSy Chiller: Had level of 11cm cm. Added 185 to get to 17 (over-filled slightly beyond ruler)
There was no water in the small cup under the slow leak.

Closes FAMIS 27787

TCS

H1 ISC - PRCL exctitation

sheila.dwyer@ligo.org — Wed, 17 Apr 2024 13:06:48 -0700

Author: sheila.dwyer@ligo.org

Report ID: 77252

We wanted to check the PRCL offset during our commissoning time this morning, we ended up not having much time for that but did re-run Elenna's template from 76814. It looks like the PRCL to REFL RIN transfer function is much the same as at that time. It seems as though there was a change in the PRCL to DARM transfer function, but that measurement has low coherence at most frequencies.

Images attached to this report

H1 INJ - Stochastic injection ran with LLO

thomas.shaffer@ligo.org — Wed, 17 Apr 2024 12:59:53 -0700

Author: thomas.shaffer@ligo.org

Report ID: 77248

Joe B from LLO and I ran the short and long stochastic injections with the commands below starting at 19:08UTC. Both ran successfully, back to Observing at 1955UTC

hwinj stochastic short --time 1397416098 --run

ifo: H1
waveform root: /ligo/groups/cal/H1/hwinj
config file: /ligo/groups/cal/H1/hwinj/hwinj.yaml
GraceDB url: https://gracedb.ligo.org/api/
GraceDB group: Detchar
GraceDB pipeline: HardwareInjection
excitation channel: H1:CAL-INJ_TRANSIENT_EXC
injection group: stochastic
injection name: short
reading waveform file...
injection waveform file: /ligo/groups/cal/H1/hwinj/stochastic/SB_ER15HLShort_H1.txt
injection waveform sample rate: 16384
injection waveform length: 780.0 seconds

injection start GPS: 1397416098.0

hwinj stochastic long --time 1397417118 --run

ifo: H1
waveform root: /ligo/groups/cal/H1/hwinj
config file: /ligo/groups/cal/H1/hwinj/hwinj.yaml
GraceDB url: https://gracedb.ligo.org/api/
GraceDB group: Detchar
GraceDB pipeline: HardwareInjection
excitation channel: H1:CAL-INJ_TRANSIENT_EXC
injection group: stochastic
injection name: long
reading waveform file...
injection waveform file: /ligo/groups/cal/H1/hwinj/stochastic/SB_ER15HLLong_H1.txt
injection waveform sample rate: 16384
injection waveform length: 1800.0 seconds
injection start GPS: 1397417118.0

LHO General - OPS Day Midshift Update

ibrahim.abouelfettouh@ligo.org — Wed, 17 Apr 2024 12:59:26 -0700

Author: ibrahim.abouelfettouh@ligo.org

Report ID: 77251

H1 is now finished with comissioning and IFO is now OBSERVING

H1 CAL - Comment to h1calcs, cal_hash_ioc and DAQ restarts

louis.dartez@ligo.org — Wed, 17 Apr 2024 12:56:56 -0700

Author: louis.dartez@ligo.org

Report ID: 77250

N.B. that changes to the channels H1:CAL-CALIB_REPORT_HASH_INT and H1:CAL-CALIB_REPORT_ID_INT will appear on the CDS SDF screen, *not the H1CALCS* screen. They get automatically re-populated each time pydarm export is used to update the calibration in the control room (which should be considered to happen atomically with GDS restarts). So, when updating the calibration both the H1CALCS and the H1CDS SDF screens need to be checked.

H1 CDS - Comment to SPI Pick-off Fiber Length

jeffrey.kissel@ligo.org — Wed, 17 Apr 2024 12:35:35 -0700

Author: jeffrey.kissel@ligo.org

Report ID: 77249

Upon discussion with the SPI team, we want to minimize the number of "patch panel" "fiber feedthrough" connections in order to minimize loss and polarization distortion. As such, we prefer to go directly from the "SPI pick-off in the PSL" fiber collimator directly to the Laser Prep Chassis in SUS-R2. That being said purchase all of the above fiber lengths, such that we can re-create a "fiber feedthrough patch panel full" system as contingency plan. So, for the baseline plan, we'll take the "original, now contingency plan" PSL-R2 to SUS-R2, 100 ft fiber run and use that to directly connect the "SPI pick-off in the PSL" fiber collimator directly to the Laser Prep Chassis in SUS-R2. I spoke with Fil and confirmed that 100 ft is plenty enough to make that run (from SPI pick-off in PSL to SUS-R2).SEI, SYS

H1 ISC - Comment to Update on Fast Shutter Timing

jeffrey.kissel@ligo.org — Wed, 17 Apr 2024 12:19:50 -0700

Author: jeffrey.kissel@ligo.org

Report ID: 77247

Ah HA! Thanks Camilla! Camilla's comment is only tangentially related, but is fruitful anyways! The O3B study she points to is researching lock losses that are dubbed "Fast lock losses" by the collaboration because they happen in under 1 [msec], but as the plots on page two of her linked study show, light "disappears" from the interferometer because the IMC is unlocking, NOT because the fast shutter has triggered. Camilla thought they were related to my aLOG about the fast shutter because of conversations with Rana suggesting that "if these fast locklosses release all of their energy to the dark port prior to the fast shutter firing, then we need to know, and make the fast shutter faster!" HOWEVER, this pointer reminds me of two more channels, [2048 Hz] H1:ASC_A_DC_NSUM_OUT_DQ The "DC" or "QPD" component of WFS A (down-stream of the fast shutter, but upstream of the OMC) [2048 Hz] H1:ASC_B_DC_NSUM_OUT_DQ The "DC" or "QPD" component of WFS B (down-stream of the fast shutter, but upstream of the OMC) Apparently, whatever's going on with the OMC QPDs and the OMC DCPDs (also downstream of the fast shutter) which seem to take a lot longer for light to dissipate, *doesn't* happen with the AS WFSs. So, these channels much more clearly show the cut-off of light. That being said, they corroborate well with the HAM6 ISI GS13s. The uncertainty still remains, though, on when the shutter gets the firing signal -- i.e. when does the shutter's trigger PD get enough voltage above threshold to trigger the shutter. For this we still only have the 16 Hz "SYS-MOTION" channels. And thus my conclusions about timing remain. Anyone know of a faster channel of the trigger PD?

Images attached to this report

H1 ISC - camera offsets set

sheila.dwyer@ligo.org — Wed, 17 Apr 2024 12:15:54 -0700

Author: sheila.dwyer@ligo.org

Report ID: 77243

Following up on 77139, we set the camera offsets to those found, and added these to lscparams.py:

cam_offsets = {'PIT':{'1':-233,
            '2':-173,
            '3':-230},
        'YAW':{
             '1':-236,
             '2':-422,
             '3':-349.5},}

This increased the power in the X arm by 5kW, the Y arm by 6 kW, as the screenshot shows. After this we re-ran the A2L script, starting with much lower amplitudes for ETMX yaw. It seems that with the A2L as badly tuned as this, we need to adjust the amplitude of the excitations for each test mass and each DOF separately

optic, dof	amplitude	starting A2L gain	final A2L gain
ETMX, Y	0.3	4.9315	5.3477
ETMY, Y	3	3.061	0.8592
ITMX P	3	-0.9709	-1.0603
ITMY P	10	-0.3830	-0.3660
ETMX P	1	4.1183	3.10708
ETMY P	0.3	4.6013	4.46241
ITMX Y	1	2.7837	2.82803
ITMY Y	1	-2.3962	-2.38278

I edited the my_a2l.py script in userapps/isc/h1/scripts to round the A2L gains that it sets, to make it easier to deal with these values in SDF.

Editing to add, we found that there was still angular coherence so re-ran the script for all DOFs with an amplitude of 1. This made changed gains for ITMX, ITMY, ETMX, Y2L gains, ETMX and ETMY P2L gain, not ETMY Y2L gain, or ITMX , ITMY P2L. The end result is fairly high CHARD P coherence, which is limiting our range right now (see attached screenshot).

Images attached to this report

H1 ISC - Comment to Update on Fast Shutter Timing

camilla.compton@ligo.org — Wed, 17 Apr 2024 10:51:53 -0700

Author: camilla.compton@ligo.org

Report ID: 77246

In G2201762 > O3a_O3b_summary.pdf Niko and I showed in O3b, there was a subset of ~25 locklosses where the light fell off H1:ASC-AS_C_NSUM_OUT_DQ on the order of 1ms, where this usually takes ~30ms. There was none of these locklosses in O3a and although the analysis is not currently online, I haven't noticed any of these 1ms fast lcoklosses in O4.

These O3b "Fast" locklosses often had the light fall off POPAIR (shutter now closed in NLN) and IMC_TRANS in the same 1ms period, sometimes with the FSS signals oscillated beforehand, showing these locklosses may have been correlated to issues with the PSL system that were resolved after O3.

LHO VE - Wed CP1 Fill

david.barker@ligo.org — Wed, 17 Apr 2024 10:32:08 -0700

Author: david.barker@ligo.org

Report ID: 77245

Wed Apr 17 10:10:07 2024 INFO: Fill completed in 10min 3secs

Jordan confirmed a good fill curbside.

Images attached to this report

H1 ISC - Update on Fast Shutter Timing

jeffrey.kissel@ligo.org — Wed, 17 Apr 2024 10:31:09 -0700

Author: jeffrey.kissel@ligo.org

Report ID: 77242

J. Kissel During today's Systems Call, it came up that there was scant documentation on the timing performance of the existing fast shutter system. A quick look through the aLOG showed some results from the 2016 era including examples like LHO aLOGs 29062, 28958, and 26263 . Koji's LHO:29062 is probably the most conclusive, quoting (repeated here for convenience): "The fast mechanical shutter start blocking the beam at 1.7ms, reaches half blocking at 1.85ms, complete block at 2.0ms." Here, I take some modern data with what digital signals stored in the frames: [65 kHz] H1:OMC-PI_DCPD_64KHZ_AHF_DQ OMC DCPDs (down stream of the OMC Cavity) [4096 Hz] H1:ISI-HAM6_BLND_GS13Z_DQ Vertical GS13s on the HAM6 ISI (nominally calibrated into 1 nm/s, but I've scaled it to arbitrarily show up demonstratively on the OMC DCPD plot) [2048 Hz] H1:ASC-OMC_A_NSUM_OUT_DQ OMC QPD A SUM (up-stream of the OMC Cavity, but still down-stream from the fast shutter) [2048 Hz] H1:ASC-OMC_B_NSUM_OUT_DQ OMC QPD B SUM (""") [2048 Hz] H1:ASC-AS_C_NSUM_OUT_DQ AS_C QPD SUM (up-stream of the fast shutter) [16 Hz] H1:SYS-MOTION_C_FASTSHUTTER_A_STATE Slow-channel record of the logical state of the shutter [16 Hz] H1:YSY-MOTION_C_SHUTTER_G_TRIGGER_VOLTS Slow-channel record of the trigger PD voltage (which is AS_C) With these channels, I show three recent lock-losses. It seems like all of the photo-diode signals show a very long "turn off time," (of order ~1 [sec]) and are pretty un-reliable at precision estimates of shutter timing. This is likely a linear combination of - For the OMC DCPDs at least, there's an *additional* hardware "shutter" where the cavity's length actuator -- the OMC PZT -- are quickly railed to unlock the cavity after a lock-loss trigger, - For the OMC DCPDs at least, there's a non-negligible cavity ring-down time, - For OMC DCPDs and all the QPDs, impulse response of the photo-diode's readout electronics and anti-aliasing filters, and/or the However, the "clunk" of the shutter on the HAM6-ISI is quite obvious and precise, so I use the start of the impulse (a few samples after the transition from "no motion" to "large fast negative start of the clunk's ring-down") that as an upper-bound estimate of when the shutter is completely closed. But, with the imprecision of the [16 Hz] channels -- 62 ms -- it's tough to get anywhere. In short -- what's stored in the frames are a pretty bad metrics for precision timing of the fast shutter system. But anyways -- the upper limit of the time between the change of the logical state of the trigger and the HAM6 ISI GS13s registering a large kick is - 08:23:20 UTC :: 0.3125 (+/-0.0625) and 0.341064 (+/-0.000244) = 0.02856 [sec] = 28.5 [ms]. - 13:01:26 UTC :: 0.125 and 0.1604 = 0.0354 [sec] = 35.4 [msec] - 23:39:28 UTC :: 0.3125 and 0.328857 = 0.016357 [sec] = 16.4 [msec] I'll keep looking for better ways to increase the precision on this statement, but for now, we should still role with Koji's results from LHO:29062CDS, ISC, Lockloss, SEI, SYS

Images attached to this report

LHO VE - LN2 Dewar Inspection 4/16/24 and Vacuum Jacket Pressures

jordan.vanosky@ligo.org — Wed, 17 Apr 2024 09:53:50 -0700

Author: jordan.vanosky@ligo.org

Report ID: 77241

During yesterday's (4/16) maintenance period, a Norco tech came to the site to inspect the 8 LN2 dewars that feed the cryopumps. Inspection report will be posted to Q2000008 once received.

The vacuum jacket pressures were also measured during inspection:

Dewar	Pressure (micron/mtorr)
CP1	68 (gauge fluctuated may need replacing, lowest value recorded)
CP2	26
CP3	68
CP4 (not in service)	110
CP5	9
CP6	33
CP7	48
CP8	77 (gauge fluctuated may need replacing, lowest value recorded)

H1 ISC - Comment to Why is it so hard to fit a good SRCL FF?

camilla.compton@ligo.org — Wed, 17 Apr 2024 09:40:40 -0700

Author: camilla.compton@ligo.org

Report ID: 77240

Gabriele, Camilla. This ETMY_L2_DRIVEALIGN_L2L filter is used while locking in TRANSISTION_FROM_ETMX (when we control DARM on EY) and then again when the LSC FF is turned on in LOW_NOISE_LENGTH_CONTORL, plot attached. To not need to change the sensitive TRANSISTION_FROM_ETMX state we should turn the filter off with ISC_LOCK before turning the LSC FF's on. Will need to retune the LSC FF's (from scratch starting with both MICH and SRCL FF off, and adjusting the excitation to take this L2L3LP filter into account).

Images attached to this report

H1 SQZ - SCAN_SQZANG added to nominal SQZ path

camilla.compton@ligo.org — Wed, 17 Apr 2024 09:20:42 -0700

Author: camilla.compton@ligo.org

Report ID: 77238

Sheila, Naoki, Vicky, Camilla

As we continue to see the nominal SQZ angle change lock-to-lock (attached BLRMs). We edited SQZ_MANAGER to scan sqz angle (takes 120s) every time the SQZ locks, i.e. every time we go into NLN.

In SQZ_MANAGER we have:

Added a state FC_WAIT_FDS after SQZ ASC, which asks the FC to lock and waits up to 5 minutes (this used to be done in nominal state FDS).
Changed the next nominal state to SCAN_SQZANG (120s scan to get best squeezing at 350Hz BLRMs, may still need improvements).
- This can be bypassed if we don't like this addition be removing the weighting from '('FC_WAIT_FDS', 'FREQ_DEP_SQZ', 3)'
I added an LO_checker_FDS() to FC_WAIT_FDS and FDS to come back to FDS_READY_IFO if the LO unlocks to avoid copy-pasting code everywhere.
SCAN_SQZANG still has paths to/from FDS so we can still request it whenever.
Old and new graphs attached. svn commit 27520.

We tested this taking SQZ_MANAGER down and back up, it went though SCAN_SQZANG as expected and improved the SQZ by 1dB, range improved by ~10MPc.

We'll want to monitor that the change as SCAN_SQZANG may not give us the best angle at the start of the lock when SQZ is very variable. We expect this won't delay us going into observing as only added 120s and ISC_LOCK is often still waiting for ADS to converge during this time.

OpsInfo

Images attached to this report

H1 CAL - Calibration Sweep

ibrahim.abouelfettouh@ligo.org — Wed, 17 Apr 2024 09:07:32 -0700

Author: ibrahim.abouelfettouh@ligo.org

Report ID: 77239

Ran a broadband and simulines calibration sweep at 15:30 UTC and successfully finished at 16:01 UTC.

Now going into planned Wednesday comissioning.

Start:

PDT: 2024-04-17 08:39:27.631946 PDT

UTC: 2024-04-17 15:39:27.631946 UTC

GPS: 1397403585.631946

End:

PDT: 2024-04-17 09:00:59.127599 PDT

UTC: 2024-04-17 16:00:59.127599 UTC

GPS: 1397404877.127599

2024-04-17 16:00:59,060 | INFO | File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20240417T153928Z.hdf5

2024-04-17 16:00:59,066 | INFO | File written out to: /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20240417T153928Z.hdf5

2024-04-17 16:00:59,071 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20240417T153928Z.hdf5

2024-04-17 16:00:59,075 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20240417T153928Z.hdf5

2024-04-17 16:00:59,079 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20240417T153928Z.hdf5

ICE default IO error handler doing an exit(), pid = 685800, errno = 32

Images attached to this report

LHO General - OPS Day Shift Start

ibrahim.abouelfettouh@ligo.org — Wed, 17 Apr 2024 08:13:05 -0700

Author: ibrahim.abouelfettouh@ligo.org

Report ID: 77237

TITLE: 04/17 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 146Mpc
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: EARTHQUAKE
    Wind: 11mph Gusts, 7mph 5min avg
    Primary useism: 0.30 μm/s
    Secondary useism: 0.12 μm/s
QUICK SUMMARY:

IFO is in NLN and OBSERVING

H1 ISC - Comment to Why is it so hard to fit a good SRCL FF?

gabriele.vajente@ligo.org — Wed, 17 Apr 2024 07:28:17 -0700

Author: gabriele.vajente@ligo.org

Report ID: 77236

Maybe mistery solved...

The ETMY L2 DRIVEALIGN L filter bank has a "L2L3LP" filter engaged, whiel the corresponding ETMX L2 DRIVEALIGN L filter bank does not. This filter seems to be the origin of the phase rotation. At least it explains part of the phase rotation.

Anybody knows why this filter is engaged in ETMY? Should be turn it off and retune the LSC FF?

We should turn this filter off when we engage the FF (assuming it's needed some time during lock acquistion, to be checked) and retune the LSC FF. When we do that, we should reduce the excitation amplitude and reshape it, taking into account the filter we turned off.

Images attached to this report

H1 General - Ops EVE Shift End

oli.patane@ligo.org — Wed, 17 Apr 2024 00:07:16 -0700

Author: oli.patane@ligo.org

Report ID: 77235

TITLE: 04/17 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Aligning
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY: The wind was really bad during my shift and caused the time between the 23:39 LL and NOMINAL_LOW_NOISE to be 3.75 hours. We had a second lockloss at 06:44UTC and just finished an initial alignment.
LOG:

23:00 Detector in NOMINAL_LOW_NOISE and troubleshooting going on wrt sqz

23:34 Into Observing

23:39 Lockloss

- Relocking -
23:57 Lockloss from AQUIRE_PRMI
23:59 Lockloss from LOCKING_ALS
00:00 Started Inital Alignment

00:20 DIAG_MAIN message that ALSY polarization is above 20%
- I using Camilla's instructions(58773) to find the right screen, and went to follow the instructions there, but all I did was press ON and then press Restore like it said, but just by clicking those the ALSY polarization value went down to 7% and ALSX up to 12%, so without needing to adjust anything I pressed OFF.

00:22 Initial Alignment completed
00:40 Lockloss from ACQUIRE_DRMI_1F
00:43 Lockloss from FIND_IR
00:48 Lockloss from LOCKING_ALS
00:51 Lockloss from FIND_IR
   - Sitting in DOWN for a bit
01:00 Trying relocking again
01:07 Lockloss from ACQUIRE_DRMI_1F
01:10 Lockloss from LOCKING_ALS
   - Sitting in DOWN for a bit again
02:00 Trying to relock again again
   - Wind still > 30mph
02:14 Started another Initial Alignment
   - Went through CHECK_MICH_FRINGES and then ifo wanted to do CHECK_MICH_FRINGES again
02:40 Initial Alignment done
- Done relocking -

03:23 NOMINAL_LOW_NOISE
03:26 Observing

06:22 Lockloss

- Relocking -
06:44 I took us to initial alignment because we couldn't get past ACQUIRE_PRMI
07:00 Initial alignment done

H1 General - Comment to Lockloss

oli.patane@ligo.org — Tue, 16 Apr 2024 23:48:17 -0700

Author: oli.patane@ligo.org

Report ID: 77234

During this lockloss(attachment1), the QUAD L2 MASTER_OUTs had a sudden increase in amplitude ~3.5s before DARM and ETMX L3 MASTER_OUT started losing control, then the ifo seemed to regain control, only for the lockloss to happen 0.8s later.

Images attached to this report

H1 General - Lockloss

oli.patane@ligo.org — Tue, 16 Apr 2024 23:23:31 -0700

Author: oli.patane@ligo.org

Report ID: 77233

Lockloss 04/17 06:22 for unknown reasons

Lockloss

H1 General - Comment to Lockloss

oli.patane@ligo.org — Tue, 16 Apr 2024 20:27:05 -0700

Author: oli.patane@ligo.org

Report ID: 77232

04/17 03:26 Observing

H1 General - Comment to Ops Eve Midshift Status

oli.patane@ligo.org — Tue, 16 Apr 2024 20:27:00 -0700

Author: oli.patane@ligo.org

Report ID: 77231

04/17 03:26 Observing

H1 General - Ops Eve Midshift Status

oli.patane@ligo.org — Tue, 16 Apr 2024 20:11:03 -0700

Author: oli.patane@ligo.org

Report ID: 77230

After three hours of not being able to get past ACQUIRE_DRMI due to the high wind, we finally are making it up and are currently at MAX_POWER.

LHO FMCS - HVAC Fan Vibrometers Check - FAMIS

oli.patane@ligo.org — Tue, 16 Apr 2024 19:06:00 -0700

Author: oli.patane@ligo.org

Report ID: 77229

Closes FAMIS#26292, last checked 77145

Corner Station Fans (attachment1)
All fans are looking normal and within range.

Outbuilding Fans (attachment2)
MX_FAN1_370_1 is still jumping in noise like it's been doing for the last few weeks. These jumps in noise are still well within range.
All other fans are looking normal and are within range.

PEM

Images attached to this report

H1 SQZ - Comment to Trouble locking SQZ FC again. Checking on FC SUS

oli.patane@ligo.org — Tue, 16 Apr 2024 17:43:05 -0700

Author: oli.patane@ligo.org

Report ID: 77227

SDFs that were accepted for observing w/ sqz

Images attached to this report

H1 SQZ - Comment to Trouble locking SQZ FC again. Checking on FC SUS

jim.warner@ligo.org — Tue, 16 Apr 2024 17:10:05 -0700

Author: jim.warner@ligo.org

Report ID: 77226

Seems like another broken GS13 on HAM8, this time a horizontal sensor. I took some driven measurements looking at the l2l cps to gs13 transfer functions and the H1 cps to gs13 tfs is lower than the other 2 sensors by about 2x, see first attached image. This affects the stability of the blend cross-over, which changes the gain peaking in the blends. I've compensated for now with a digital gain, but this may not work for long.

I tried compensating with a digital gain in the calibration INF filters for the ISI, this seems to have improved things, shown in the second image. Top subplot is the M3 pit witness for FC2, second line is the gain I adjusted, third line are LOG BLRMS for the X, RZ and RX GS13s on HAM8. X and RX don't improve much, but the RZ motion improves a bit after changing the gain. Fourth line is the RZ cps residual, which is much quieter after increasing the gain to compensate for the suspected low response of the H1 GS13.

To add to Vicki's comment, the peaks behavior seems complicated, it started at .6hz in January, then some time around March it moved down to its current frequency ~.37hz. Lots of days missing from the summary pages in that time, so it's hard to track. The transience of the peak is also consistent with broken seismometers we've seen in the past. The gain tweak I put in may not be a stable fix.

SEI

Images attached to this report

H1 SQZ - Comment to Trouble locking SQZ FC again. Checking on FC SUS

victoriaa.xu@ligo.org — Tue, 16 Apr 2024 16:49:02 -0700

Author: victoriaa.xu@ligo.org

Report ID: 77225

From HAM8 summary pages, I don't see this 0.36 Hz peak between Dec15 - Jan15. Peak is basically exactly where FC2_L is oscillating in yesterday's screenshot. Since Jan 15 2024, the peak looks intermittently there or gone, pretty variable. Maybe exciting this peak is related to wind? Or maybe this is all totally unrelated to wind.. I don't think this was an issue in O4a, maybe something changed after Jan 15.

Images attached to this report

H1 General - Lockloss

oli.patane@ligo.org — Tue, 16 Apr 2024 16:41:57 -0700

Author: oli.patane@ligo.org

Report ID: 77224

Lockloss 04/16 23:39UTC - IX saturation at lockloss

Lockloss

H1 CDS - CAL HASH SDF updates and IOC restart test

david.barker@ligo.org — Tue, 16 Apr 2024 16:41:46 -0700

Author: david.barker@ligo.org

Report ID: 77223

The HASH_INT channel was updated at 16:00 and its new value was accepted into CDS SDF. These two channels were removed from h1calcs SDF by hand editing the snap file.

As a test that the cal_hash_ioc restores it values on startup, we restarted it at 16:30. CDS SDF didn't notice it had gone, the EDC connected channel counter dropped by 5 for about 15 seconds.

H1 SQZ - Comment to Trouble locking SQZ FC again. Checking on FC SUS

camilla.compton@ligo.org — Tue, 16 Apr 2024 16:39:32 -0700

Author: camilla.compton@ligo.org

Report ID: 77221

Jim found that the HAM8 ISI has a resonance at the same place as FC2, peak at 0.375Hz see attached. He edited a gain and the motion seemed to improve enough to lock the FC.

During this time Ibrahim, Oli and I had followed ObservationWithOrWithoutSqueezing wiki and edited all the SQZ guardian code nominal states and accepted no squeezing sdfs. We then reverted these changes once the FC locked.

Images attached to this report

H1 CDS - Comment to h1calcs, cal_hash_ioc and DAQ restarts

oli.patane@ligo.org — Tue, 16 Apr 2024 16:16:44 -0700

Author: oli.patane@ligo.org

Report ID: 77222

SDF for CAL-CALIB_REPORT_HASH_INT accepted

Images attached to this report

H1 General - Ops EVE Shift Start

oli.patane@ligo.org — Tue, 16 Apr 2024 16:07:14 -0700

Author: oli.patane@ligo.org

Report ID: 77220

TITLE: 04/16 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 25mph Gusts, 19mph 5min avg
    Primary useism: 0.15 μm/s
    Secondary useism: 0.14 μm/s
QUICK SUMMARY:

Locked for almost 2 hours, Jim is doing some last minute tests and sqz team is trying to last minute troubleshoot the sqzer before we go into observing without sqz

H1 AOS - FARO Progress Update, 4/16/2024

jason.oberling@ligo.org — Tue, 16 Apr 2024 16:01:40 -0700

Author: jason.oberling@ligo.org

Report ID: 77216

J. Oberling, T. Guidry, R. Crouch

Progress since our last update.

When we ended last, we had large Z axis deviations for our PSI monuments that we speculated was due to the fit being unable to pick up on the tilt of the X axis in our global coordinate system, since the height marks we were using for Z axis alignment were all in a line along the Y axis. To test this, we decided to try aligning the FARO in the local LVEA coordinate system, then translating that alignment to our global coordinate system. We first tried this on 4/9/2024, then again with a slightly different method today, 4/16/2124.

4/9/2024

We first tried assuming the LVEA is perfectly flat; in other words, we used the same Z axis coordinate for all PSI monuments. With a new Z axis coordinate for BTVE-1 (-1060.3 mm) that we tied back to BSC2 Z=0, and our differential height measurement from alog 75669, we calculated a new Z axis coordinate for PSI-1 of -1885.4 mm. We then used this Z axis coordinate for PSI-2 and PSI-6 to give us a very rough Z axis alignment. We then followed the same method we used in alog 76889 to align the FARO, except we did not convert the Z axis coordinates to our global coordinate system, we left them in LVEA local. In the end, we were using BTVE-1, PSI-1, PSI-2, and PSI-6 for X and Y axis alignment, and BTVE-1, 901, 902, and 903 for Z axis alignment. At first we thought this looked pretty good, but then we noticed that we had some significant deviations in X axis coordinates for 901, 902, and 903 that were not there before we finalized the alignment. Turns out that excluding PSI-2 from the Z axis alignment drags everything off in X by several mm, and the alignment is still incapable of accurately resolving a Z coordinate for PSI-2 (16.3 mm deviation!). It's almost like the PolyWorks alignment algorithm thinks PSI-2 is rotated/tilted somehow w.r.t. the other monuments, we really don't have an explanation for it. This can be seen in the 1st 2 attached pictures. Regardless, it seems like this isn't the route to go down, so we ended the day at this point. Also, the maintenance window was almost over so we had to shut things down anyway.

Before completely shutting down, we did try converting from the local coordinate system to the global one. PolyWorks allows the user to set a new coordinate system by several methods, most importantly to us by translation and rotation about known axes. In other words, we can set a new Cartesian coordinate system, and translate and rotate it however we need. This is good for our purposes, as we can enter the rotation of our X and Y axes that converts from LVEA local to site global. Recall that, if you are sitting at the origin of the IFO's coordinate system, the global X axis is tilted down by 619.5 µrad w.r.t. the local LVEA X axis and the global Y axis is tilted up by 12.5 µrad w.r.t. the local LVEA Y axis. PolyWorks uses axis tilt as a roll of the axis, so we enter the Y axis tilt as an X axis roll and the X axis tilt as a Y axis roll (we don't translate the axes at all, the origins are supposed to be the same spot). This all seemed to go smoothly, but left a few things that we didn't have time to dig into: It looked like the rotation of the X and Y axes also induced a rotation of the Z axis, even though that is supposed to be held constant, and it looked like it was rotating too much (our Z axis coordinates changed more than we expected). More to look into for next time.

Speaking of next time...

4/16/2024

Today we essentially did a repeat of last week, except we did not assume the LVEA was perfectly level. Since we had the previous differential height measurements and the new BTVE-1 local Z axis coordinate, we used the differential height measurement data to calculate new LVEA local Z axis coordinates for PSI-1, PSI-2, and PSI-6. It should be noted that we weren't really in love with way we had to do the differential height measurement for PSI-6, due to line of sight issues, so we entered that as a placeholder only, it was not included in any alignments. To keep things consistent we used sphere features for BTVE-1, PSI-1, PSI-2, and PSI-6; this means we also included the correction for the sphere-fit rod, which measures the bottom of the monument punch and not the monument surface that the coordinate is registered to. The new LVEA local Z axis coordiantes we used today, properly corrected for punch depth, are:

BTVE-1: -1061.1 mm
PSI-1: -1886.5 mm
PSI-2: -1887.3 mm
PSI-6: -1881.9 mm (placeholder only!)

Since these Z axis coordinates for PSI-1 and PSI-2 are ones we directly measured with the FARO, via differential height measurement w.r.t. BTVE-1, and have tied back to BSC2 Z=0, via our water tube level survey and differential height measurements, we also included them in the alignment routine; as stated previously PSI-6 was excluded from the alignment routine as we do not trust that number. Following the same method previously used, we measured the X and Y coordinates for height marks 901, 902, and 903, and used our previously-measured Z axis coordinates from our water level survey. The results of the final alignment routine are shown in the 3rd attachment; this is in the LVEA local coordinate system. This is the closest we've yet been to something that looks like a good alignment to one of our coordinate systems (LVEA local in this case). One thing we immediately notice, the measured X axis coordinate for BTVE-1 is reported as off by -1.2 mm. At this point in time we really have no way to know if this is a true error in the placement of BTVE-1 or an error in our alignment routine. It could be a result of the sphere fit rod, as we don't really trust its repeatability; probing method and who operates the rod has a large impact in the measurement, but we have no other way to probe BTVE-1 due to its dome shape.

We also took another shot at converting from the LVEA local coordinate system to our site global coordinate system. We did this in the same was previously, setting up a new coordinate system and rotating the X and Y axes by our known rotations. We immediately saw that, again, it appeared to be over-rotating. I didn't get a picture, but using height mark 901 as an example. It has an LVEA local Z axis coordinate of -55.2 mm, which, when using the listed X and Y coordinates for this mark, translates to a site global Z axis coordinate of -55.7 mm.¹ The new coordinate system kept putting the gloabl Z axis coordinate for 901 at -56.0 mm, 0.3mm below where it should be. We were a little puzzled by this, and were initially thinking that PolyWorks was rounding up to the displayed number of digits after the decimal point, and not using the axis tilts as we entered them (for example, Y axis tilt in degrees is 0.000716, which the PolyWorks display rounds up to 0.001). We set the display to 7 digits after the decimal and our entered angles were display properly, so this was not the cause. Turns out it was a sign issue. We had been told by PolyWorks support, back in 2022, that we needed to enter the opposite sign of our actual axis tilt due to the way PolyWorks references tilts w.r.t. the FARO. We checked the Properties of the new coordinate system and noticed the IJK unit vectors for the Z axis did not have the correct signs. In fact, it had both X and Y rotations listed as negative, when they should be opposite. Correcting the signs the displayed the correct global Z axis coordinates; shown in the final attachment. We still have the issue of the new coordinate system also rotating about the Z axis when it shouldn't. This is best seen by looking at the nominal X axis coordinate for BTVE-1. In the 3rd attachment, in LVEA local, BTVE-1 X is properly listed as 0.0. In the final attachment, in site global, the nominal X for BTVE-1 is now -0.657mm. In looking at the direction cosines for the LHO Corner Station as listed in T980044, there is a small rotation from global Z to local Z, which we did not implement. Will test and see if implementing this small rotation corrects this.

We like this alignment, it's the best we've seen to date. So, next steps are to start moving the FARO through the LVEA and measuring known points while setting up a volume of alignment monuments, in hopes that we can get enough monuments so we can set the FARO anywhere in the LVEA and be able to align it. This will continue on Tuesdays as our schedules allow, until we are done.

1) Keeping this here for posterity, as it was my thinking as we were on the floor, but this is incorrect. In writing this alog I realized that I got my direction cosine signs flipped when we were setting up the coordinate system transform in the PolyWorks software this morning. *facepalm* The proper global Z for 901 based on the X and Y axis coordinates listed in the referenced picture is -54.7 mm, not -55.7 mm. This also means that we then flipped the signs for both direction cosines when we "corrected" the incorrect signs we initially saw with the new coordinate system. I'm going to take a look tomorrow and see about correcting this, pretty sure we can do that "offline" without a FARO connected. Will post any update as a comment to this alog.

Images attached to this report

LHO General - OPS Day Shift Summary

ibrahim.abouelfettouh@ligo.org — Tue, 16 Apr 2024 16:00:25 -0700

Author: ibrahim.abouelfettouh@ligo.org

Report ID: 77219

TITLE: 04/16 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Oli
SHIFT SUMMARY:

IFO is in NLN and COMISSONING - the squeezer is having lock issues and a team of comissioners, fellows and other staff are in the control room and working on fixing it.

19:29 UTC: Began Locking (No initial alignment)

20:15 UTC: Began Initial Alignment (after 3 IR_COMM based locklosses)

IR COMM Weirdness:

Once we started locking, ALS locked fine but IR_COMM was not found, prompting a troubleshoot of this part. There was extremely noise behavior in the relevant channel (H1:LSC-TR_X_NORM_INMON) where the usually normalized (to 1) values were showing up bizarrely high. (Screenshot 1). After initial alignment, this issue was resolved.

20:36 UTC: Initial Alignment Complete

21:21 UTC: Reached NLN

21:24 UTC: H1 is OBSERVING

21:36 UTC: Dropped out of observing due to squeezer lockloss - a team of commissioners are on the case.

22:55 UTC: Trying to get into OBSERVING without squeezing while we troubleshoot the squeezer.

LOG:

Start Time	System	Name	Location	Lazer_Haz	Task	Time End
15:02	FAC	Ken	FCES	N	Electronics work	20:00
15:03	CAL	Dave	remote	n	WP11812 h1calcs cal_hash_ioc chan move	17:31
15:04	DAQ	Dave	Remote	n	DAQ Restart for cal work	17:31
15:10	VAC	Jordan, Norco	EY, Corner, EX	N	Nitrogen tank inspection	19:22
15:18	ISC	Jennie	LVEA	N	Turning off PSL Sidebands	15:23
15:19	FAC	Kim, Karen	FCES	N	Technical Cleaning	15:53
15:19	ISC	Camilla	LVEA	N	Laser Hazard Transition	15:26
15:39	TCS	Camilla,. TJ	LVEA	YES	TCS Table Work	18:49
15:39	OMC	Jennie, Sheila	Ctrl Rm	N	Aligning OMC	17:38
15:40	FAC	Christina	OSB Patio	N	Transporting pallets and moving tables	17:38
15:41	OMC	Sheila	LVEA	YES	Turning off PSL sidebands	16:40
15:45	FAC	Ace Portapotty	End Stations	N	End Station Portapotty Inspection	16:45
15:45	IAS	Jason, Tyler, Ryan C	LVEA	YES	IAS Alignment Work	18:42
15:46	LVEA	HAZARD	LVEA	YES	LVEA IS LASER HAZARD	19:11
15:53	FAC	Kim	EX	N	Technical Cleaning	16:53
15:53	FAC	Karen	EY	N	Technical Cleaning	16:39
15:54	EE	Fil	LVEA	YES	Cable tray inspection	16:23
16:08	SEI	Jim	FCES	N	HAM7 Dissassembly of CPS Cards	17:39
16:42	PEM	Marc	EX	N	Accelerometer chassis	18:50
16:48	EE	Fil	LVEA	YES	Table Tray Inspection	17:14
16:53	FAC	Kim	Hi-Bay	N	Technical Cleaning	17:34
17:09	OMC	Sheila	LVEA	YES	Turning sidebands back on	17:59
17:14	EE	Fil	EX, EY	N	Equipment Inventory	19:20
17:34	FAC	Karen, Kim	LVEA	YES	Technical Cleaning	18:44
18:49	OPS	Camilla	LVEA	YES	Detransitioning to LASER SAFE	19:19
18:54	FAC	Nolan	Y-Arm	N	Y-End Ecology Check	21:54
18:54	IAS	Jason	Optics Lab	N	Finishing up optics work	19:00
19:05	OPS	TJ	LVEA	YES	Maintenance End Sweep	19:16
20:07	FAC	Ken	FCES	N	Bolting	21:07

Images attached to this report

H1 SQZ - Trouble locking SQZ FC again. Checking on FC SUS

camilla.compton@ligo.org — Tue, 16 Apr 2024 15:35:34 -0700

Author: camilla.compton@ligo.org

Report ID: 77218

Shiela, Naoki, Rahul, Kar Meng, Terry

Same as yesterday (77188), we are again today having trouble locking the FC. Wind is again constant at 0-20mph. Can get green flashes but no locking, even with FC feedback turned off, VCO locking also fails.

Rahul changed the M1 coil driver state on FC1 and FC2 from state 1 (usually only used in TFs) to state 2: IFO nominal for other triples. State 2 contains a low pass filter.

Rahul took FC2 P and L transfer functions, look healthy and same as 66414.

Rahul took FC2 OSEMINF spectrums and checked ther health, as previously had issues with FC1 BOSEMS (72563). Can see the 0.3 to 0.4Hz peak, Rahul's not worried about it but we could check old data for this peak.

SUS

Images attached to this report

H1 PEM - EX Accelerometer Conditioner Repaired

marc.pirello@ligo.org — Tue, 16 Apr 2024 15:07:47 -0700

Author: marc.pirello@ligo.org

Report ID: 77217

I pulled EX Accelerometer Power Conditoiner S2300070 per WP11813 to investigate a bad channel and the restult was that the input resistor had blown on that channel. The symptom was that the channel was completely off, no LED activity on the front panel for that channel. The current draw per channel at 24V is < 63mA, the 10 ohm resistor is rated at 1/4 watt which gives us an upper limit of 160mA current. It could have been inrush current that blew this resistor as they have only been tested on bench and not with kepkos' higher current rating. This is part of the low pass filter for these accelerometer channels. I replaced the 10 ohm 1/4 watt resistor with a 5W resistor. I will keep an eye on these, if this becomes an issue, we might consider replacing the resistors with higher wattage versions as there is space on the board for it.

Channel Order
CH1 - Cable 7 - AA7 - OPLEV-Y
CH2 - Cable 8 - AA8 - BSC9_X
CH3 - BLK_NL - U2_9 - Manifold1
CH4 - Cable 10 - AA10 - BSC9_Z
CH5 - Cable 11 - AA11 - TableX
CH6 - Cable 12 - AA12 - BSC_Floor
CH7 - Cable 13 - AA13 - Ebay_Floor
CH8 - BLK-NL - U2_11 - Manifold2
CH9 - empty - empty (ready to replace the Meggit single channel device)

PEM

H1 ISC - Comment to Why is it so hard to fit a good SRCL FF?

gabriele.vajente@ligo.org — Tue, 16 Apr 2024 14:35:18 -0700

Author: gabriele.vajente@ligo.org

Report ID: 77215

This is a comparison of the LHO LSC FF and LLO LSC FF. The difference in the absolute scale might eb due to normalizations, but the SRCL FF does not show the large phase advanced visible at LHO

Images attached to this report

H1 SUS - Comment to H1 SUS IM Alignment Sliders now Calibrated into microradians

jeffrey.kissel@ligo.org — Tue, 16 Apr 2024 14:17:26 -0700

Author: jeffrey.kissel@ligo.org

Report ID: 77214

As a result of this work, I have accepted the new OPTICALIGN slider calibration gains, which are "monitored" in the h1susim_safe.snap. As is tradition, the OPTICALIGN slider offsets are *NOT* monitored, so I made sure to go to the "full table" and force accept the offsets as well. Finally, I've also committed the update to the /opt/rtcds/userapps/release/sus/common/medm/haux/ SUS_CUST_HAUX_M1_OPTICALIGN.adl because these values (a) are not too terribly different than the previous +/- 2500 ["urad"] range that was there, and (b) I expect the L1 HAUX to have similar calibration, when they get to it.

H1 SQZ - OMC Scan with PSL beam

jennifer.wright@ligo.org — Tue, 16 Apr 2024 14:10:31 -0700

Author: jennifer.wright@ligo.org

Report ID: 77204

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

ISC, SQZ

Images attached to this report

H1 SUS - H1 SUS IM Alignment Sliders now Calibrated into microradians

jeffrey.kissel@ligo.org — Tue, 16 Apr 2024 14:09:26 -0700

Author: jeffrey.kissel@ligo.org

Report ID: 77211

J. Kissel EXECUTIVE SUMMARY After having visited the calibration of the HAUX alignment sliders since 2016 (see LHO:30010), it's time to re-measure and recalculate what these gains should be, as we've lost confidence in their accuracy. I've recalibrated the IM1, IM2, IM3, IM4 alignment sliders today, such that one count offset in [pitch, yaw] produces 1 microradian in [pitch, yaw] according to the OSEMs. To correct from the previous incorrect calibration, slider values would have needed to be multiplied by factors of 20 to 30 [urad/"urad"]. METHODS AND RESULTS In order get something in play quickly, I've used the OSEMs as my absolute angle reference, having been calibrated into microns [um] for years and cast into PITCH and YAW through trusted OSEM2EUL matrices to produce pitch and yaw in microradians [urad]. Recall the goal is to calibrate the output of the OPTICALIGN banks, which are nominally in Euler basis DAC counts [DAC ct] such that when you request the slider to move in your desired physical unit (in this case, [urad]) then the output of the bank requests the appropriate amount from the DAC. Thus, we need a gain, H where slider offset [urad] * H [DAC ct / urad] = DAC output [DAC ct] (1) In short, the method is: (i) Set the OPTICALIGN gain to 1.0 so there's no confusion during the measurement. (ii) Request the slider offset to be a range of values (I arbitrarily chose [-10000, -5000, -1000, 1000, 5000, 10000]; six data points such that a linear regression had plenty to grab on to) (iii) At each requested value, record the OSEM values. (iv) Fit a line to a plot of OSEM value vs. slider value, i.e. (slope * slider value + offset). The slope will be in units of [urad / DAC ct]. (V) Invert the slope to obtain the slider calibration gain in units of [DAC ct / urad]. I used an ipython session interactively to do so for all IMs at the same time via for loops, while the IMC was unlocked and misaligned. Here're the results in units of [DAC ct / urad] (rounded to the nearest 4th decimal place): PIT YAW IM1 9.9093 5.3457 IM2 10.1124 5.4868 IM3 12.5623 6.8758 IM4 10.9005 5.6289 Note that the results are not insignificantly different from suspension to suspension, even though every HAUX actuation chain should be the same. So, I've elected to install these suspension specific gains (like we have with other suspensions that have had recent attention), rather than a generic gain for suspension type based on a model of the actuation strength. The first two pages of 2024-04-16_H1SUSIM_AlignmentSlider_Recalibration_GainFitPlots.pdf shows the plots of data, and their fits. As an aside, because I drove the slider requests programmatically via ipython, it was easy to measure both the pitch and yaw OSEM values during the other DOF's slider changes. As such, I also gathered the amount of cross-coupling between pitch drive and yaw response and vice versa, yaw drive and pitch response, in units of [urad / DAC ct]. This is shown on the last two pages. The good news is that the off-diagonal cross-coupling is an order of magnitude or two less than the expected diagonal coupling (I think auto-y-axis-scaling dataviewer or ndscope sessions have scared us for years). That being said, IM3 is the worst offender. After I installed the new calibration, I've made sure to set the *actually* [urad] value to reproduce the same [DAC ct] output that had been requested with the previous incorrect ["urad"] values (generated with the incorrect [DAC ct / "urad"] gain, G). The method for doing so is revealed through a quick algebra exercise, slider offset [urad] * H [DAC ct / urad] = DAC output [DAC ct] (1) bad slider offset ["urad"] * G [DAC ct / "urad"] = DAC output' [DAC ct'] (2) want DAC output [DAC ct] = DAC output' [DAC ct'], so slider offset [urad] * H [DAC ct / urad] = bad slider offser ["urad"] * G [DAC ct / "urad"] slider offset [urad] = bad slider offset ["urad"] * G [DAC ct / "urad"] / H [DAC ct / urad] (3) or, in words, multiply the old bad offsets by the ratio of (old gain / new gain) to get the new well-calibrated offsets. In addition to calibrating the offsets, I also updated the visual representation of the available range on the MEDM screen. In this case, given that the HAUX are driven with 18-bit DACs, then each OSEM can drive 2^17 - counts. The EUL2OSEM matrix elements for conversion of pitch and yaw to each of the four OSEMs is +/-8.594 [um / urad], so that means that a Euler basis pitch and yaw [DAC ct] drive cannot exceed 2^17 / 8.594 = 15251 [Eul DAC ct]. After dividing by the above calibration for each, that takes the slider limits to (roughly, taking the lowest range -- IM3 -- as the limiter) +/- 1200 [urad] for pitch and +/- 2200 [urad] for yaw. 2024-04-16_H1SUSIM_AlignmentSlider_Recalibation_OPTICALIGN_Screens_after_correctunits.png shows the final product after all of these changes, - the new slider gain values, - the new slider offset values to reproduce the same DAC output, and - the updated range of values. Operators be aware: the amount of nudging you need to do on IM4 during initial alignment will need to change as a result of this re-calibration. Using the same math as Eq. (3) above, [1, 10, 100, 1000] "urad" nudges now are actually, roughly [0.05, 0.5, 5. , 50] "urad" nudges. 2024-04-16_H1SUSIM_AlignmentSlider_Recalibration_Notes.txt are my very rough notes from the morning's work, including all mistakes, as well as ipython code snippets to take actions, store information, and make plots. Could be cleaner for future users, but alas.ISC, OpsInfo

Images attached to this report

Non-image files attached to this report

2024-04-16_H1SUSIM_AlignmentSlider_Recalibration_GainFitPlots.pdf

2024-04-16_H1SUSIM_AlignmentSlider_Recalibration_Notes.txt

H1 CDS - Comment to h1calcs, cal_hash_ioc and DAQ restarts

david.barker@ligo.org — Tue, 16 Apr 2024 13:31:06 -0700

Author: david.barker@ligo.org

Report ID: 77212

Tue16Apr2024
LOC TIME HOSTNAME MODEL/REBOOT
10:04:52 h1oaf0 h1calcs <<< Model change to remove channels
10:07:51 h1susauxb123 h1edc[DAQ] <<< EDC has the new channels
10:08:43 h1daqdc0 [DAQ] <<< 0-leg restart, no issues
10:08:55 h1daqfw0 [DAQ]
10:08:55 h1daqnds0 [DAQ]
10:08:55 h1daqtw0 [DAQ]
10:09:03 h1daqgds0 [DAQ]
10:11:55 h1daqdc1 [DAQ] <<< 1-leg restart, no issues
10:12:06 h1daqfw1 [DAQ]
10:12:07 h1daqtw1 [DAQ]
10:12:08 h1daqnds1 [DAQ]
10:12:16 h1daqgds1 [DAQ]

H1 General - LVEA Swept

thomas.shaffer@ligo.org — Tue, 16 Apr 2024 12:25:41 -0700

Author: thomas.shaffer@ligo.org

Report ID: 77210

Swept the LVEA at the end of maintenance. All of the usual checks on T1500386 were done, the only thing I noticed was that there were some cables plugged into the SQZT0 table that were not connect to anything else. These are for the hymodyne delta DC, PD1 DC, and PD2 DC according to their labels.

The items mentioned from last week's sweep (alog77058) are still there - pem setups, FARO, etc. as expected for the near future.

SQZ

LHO General - OPS Day Midshift Update

ibrahim.abouelfettouh@ligo.org — Tue, 16 Apr 2024 12:02:11 -0700

Author: ibrahim.abouelfettouh@ligo.org

Report ID: 77209

IFO is in IDLE for TUESDAY MAINTENANCE

Maintenance work is wrapping up, Camilla is detransitioning our LVEA Hazard state and we will being locking as soon as maintenance activities end.

H1 AOS - CAL HASH channels added to CDS SDF

david.barker@ligo.org — Tue, 16 Apr 2024 11:05:03 -0700

Author: david.barker@ligo.org

Report ID: 77208

New channels have been added to the CDS SDF, and h1cdssdf was restarted on h1ecatmon0. Current values have been accepted and are being monitored.

H1 CDS - h1calcs, cal_hash_ioc and DAQ restarts

david.barker@ligo.org — Tue, 16 Apr 2024 10:39:08 -0700

Author: david.barker@ligo.org

Report ID: 77207

WP11812

Jamie, Jonathan, Erik, Dave:

The two CAL HASH channels (H1:CAL-CALIB_REPORT_HASH_INT and H1:CAL-CALIB_REPORT_ID_INT) were moved from the h1calcs model, where they were being acquired as single-precision floats, to a new custom EPICS IOC called cal_hash_ioc, where they are acquired as signed 32bit integers.

The h1calcs.mdl model was modified to remove the EPICS-INPUT parts for these channels. The model was then restarted.

The IOC, which was being tested with H3 channels, was modifed and rstarted to serve the H1 channels as integers.

The EDC was modified to add H1EPICS_CALHASH.ini to its master list. This added 5 channels the the DAQ, the two hash channels and three IOC status channels.

The EDC was restarted, followed in short order by a DAQ restart.

LHO VE - Tue CP1 Fill

david.barker@ligo.org — Tue, 16 Apr 2024 10:21:25 -0700

Author: david.barker@ligo.org

Report ID: 77206

Tue Apr 16 10:12:16 2024 INFO: Fill completed in 12min 11secs

Jordan confirmed a good fill curbside. Plot looks strange because the DAQ was being restarted during the fill.

Images attached to this report

H1 IOO - IM4 QPD centered with pico

sheila.dwyer@ligo.org — Tue, 16 Apr 2024 10:08:41 -0700

Author: sheila.dwyer@ligo.org

Report ID: 77205

I used the IM4 pico to center the beam on the QPD with 2W into the mode cleaner this morning (screenshot attached). We had some shifts of input alignment during the vent and difficulty recovering (see 76359 76291). Now our range is 165 and locking seems reliable, so we are resetting the IM4 QPD to zero here so that we can use this as a reference in the future. LLO tells us that they realign IM3 to this QPD every few months.

This increased the sum of IM4. Since this sum is used to normalize our PRG channel, this will need a recalibration.

Images attached to this report

LHO General - Comment to Mon EVE Ops Transition

ryan.crouch@ligo.org — Tue, 16 Apr 2024 08:37:06 -0700

Author: ryan.crouch@ligo.org

Report ID: 77203

Forgot my log

Start Time	System	Name	Location	Lazer_Haz	Task	Time End
15:20	FAC	Chris	FCES	N	Move snorkle lift to FCES	16:20
16:03	FAC	Kim	MidX	n	Tech clean	17:03
18:04	EE	Fil	MidY	n	Parts search	19:04
17:10	CAL	Francisco	PCAL lab	LOCAL	PCAL work	20:10
18:18	FAC	Tyler	AHU	N	AHU1 fan	18:35

H1 ISC - Why is it so hard to fit a good SRCL FF?

gabriele.vajente@ligo.org — Tue, 16 Apr 2024 08:25:32 -0700

Author: gabriele.vajente@ligo.org

Report ID: 77201

Lately it's been very difficult to fit an efficient SRCL feedforward filter, as reported many times by Camilla et al. (76993). Here I'm trying to figure out why. Spoiler alert: I don't have an answer yet.

The main problem with the SRCL FF filter (see first plot), is that the transfer function to fit has a large phase rotation, that looks basically like a phase advance (the opposite of a delay) of about 2 ms. This is very large, and being an advance, it can't be realized in a precise and simple wasy digitally.

First observation: we can fit a pretty good SRCL FF if we allow for unstable poles, i.e. poles with positive real parts (see second plot) Of course this is not something that can be implemented in the real time system. The fit ends up having a unstable complex pole at about 420 Hz and about 5 Hz. I have no intepretation for the origin of those poles, and they might very well be only a way to reproduce a phase advance (think of the Padé approximation for phase delays).

So the question is: what is the origin of this large phase rotation? It's not seen at LLO, for example see 70548

Second observation: this phase advance appeared after we switched the LSC FF from ETMX (full chain) to ETMY PUM. The third plot compares the MICH and SRCL feedforward to be fit in two cases: an old measurement when the FF was going to ETMX, and a more recent measurement with the FF going to ETMY PUM only. For both MICH and SRCL the orange traces (FF to ETMY) show a phase advanced with respect to the blue traces (FF to ETMX). For some reasons I don't fully understand, this rotation is more problematic for SRCL than for MICH, although fitting MICH has also been more difficult and the MICH FF is relevant at lower frequencies than SRCL, so maybe the phase advanced isn't that problematic.

Looking at the measurement of the MICHFF to DARM and SRCLFF to DARM, one can see that there seems to be an additional phase delay in the FF path through ETMY PUM with respect to the FF path through ETMX full chain. Since this transfer function is at the denominator when computing the ratio SRCLtoDARM/SRCLFFtoDARM that gives use the LSC FF to fit, this seems to explain the additional phase advance we observe.

The ETMY PUM L2 lock filter bank contains a "QPrime" filter module that compensates partially the additional 1/f^2 due to the actuation from L2 instead of L3. This filter however doesn't seem able to explain this additonal phase delay.

I'm now suspicious that there might be something wrong or mistuned in the ETMY L2 drive, maybe a whitening filter missing or not functioning properly or not properly compensated?

It would be worth doing a quick test in the next commissioning time with full IFO locked: inject some white noise on ETMX L2 L and ETMY L2 L and comapre the two transfer functions to DARM. In theory they should be equal, except for a sign difference. If they're not, then there must be something wrong with ETMY, since we're using ETMX L2 to lock without issues.

Images attached to this report

LHO General - OPS Day Shift Start

ibrahim.abouelfettouh@ligo.org — Tue, 16 Apr 2024 08:14:10 -0700

Author: ibrahim.abouelfettouh@ligo.org

Report ID: 77202

TITLE: 04/16 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 12mph Gusts, 7mph 5min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.13 μm/s
QUICK SUMMARY:

IFO was unlocked upon entry - now staying down for Planned Tuesday Maintenance

H1 General - Comment to OWL Operator intervention

thomas.shaffer@ligo.org — Tue, 16 Apr 2024 07:42:27 -0700

Author: thomas.shaffer@ligo.org

Report ID: 77200

SRC wouldn't lock, but flashes looked good. Somehow, it looks like the changes I made switching from POP_A to AS_C got reverted (<a href="https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=77113">alog77113</a>). As soon as I switched back to using AS_C with 0.005 and 0.004 thresholds it locked right up.

I'll also have to check on why this was reverted when I get in.

H1 General - OWL Operator intervention

thomas.shaffer@ligo.org — Tue, 16 Apr 2024 07:23:56 -0700

Author: thomas.shaffer@ligo.org

Report ID: 77199

A lock loss this morning from unknown reasons had the IFO running an initial alignment after it struggled to lock in the main locking. I was alerted after it timed out locking green in initial alignment. By the time I logged in and accidentally restarted green locking, increase flashed had fixed it and it have moved on in the initial alignment sequence. I'll let it finish with the hopes that it will help maintance recover slightly quicker, but not start locking again since maintenance is about to start.

I'm not sure why green was struggling so much this morning, I'll have to dive deeper into it later it. It doesn't normally time out if it can lock this easily.

H1 CDS - Workstations updated

erik.vonreis@ligo.org — Tue, 16 Apr 2024 07:01:50 -0700

Author: erik.vonreis@ligo.org

Report ID: 77198

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

H1 SQZ - Comment to SQZ issue

victoriaa.xu@ligo.org — Tue, 16 Apr 2024 06:32:28 -0700

Author: victoriaa.xu@ligo.org

Report ID: 77197

See LHO:77188 - these FC locking issues seem correlated with >30-40 mph winds, likely moving FC2 SUS too much to hold lock. We had seen the FCGS trans beam (on SQZT8 in FCES) moving a lot on the camera, which suggested the FC cavity axis was moving a lot. This is why we disabled FC ASC this night. If that helped, it's b/c FC2 SUS, aka the FC cavity axis, was moving due to winds. We traced this down the following night 77188 when higher winds prevented even FC green VCO locking, and we saw the FCGS control signal was railing and correlated with FC2 SUS motion with no control signal.

Both nights (this and following one) - FC locked overnight once winds calmed down, see screenshot.

H1 SQZ - Comment to SQZ OMC mode scan with cold OM2

victoriaa.xu@ligo.org — Tue, 16 Apr 2024 06:22:53 -0700

Author: victoriaa.xu@ligo.org

Report ID: 77183

Looking at this SQZ-OMC mode scan (data, mode scan), and running the same scripts as before (e.g. LHO:70866), this loss estimate based on OMC visibility using the squeezer beam doesn't really make sense. Hopefully PSL scans will make more sense. May be worth re-taking this squeezer measurement sometime.

Mode-matching and visibility make sense: Single-bounce SQZ-OMC mode mismatch ~ 4% based on TEM02/20 is consistent with Jennie's peak fitting, HOM content ~ 9-12%, and OMC locked/unlocked visibility = 1-locked/unlocked ~ 90%.

Loss estimate does not make sense: the inferred OMC transmission is ~72%, and if we ignore mode mismatch (ie assume 100% matching) this corresponds to an OMC transmission of 81%. But ~20% omc loss is ruled out by observed squeezing levels.

5.4 dB SQZ corresponds to a total loss of 20-25%, see params below including 12.3% expected sqz losses. This limits OMC losses < 10-15%, if assuming no mode-mismtch. With mode-mismatch, squeezing suggests OMC losses << 10%. This is not saying much, except this measurement is off.

5.4 dB of kHz squeezing, e.g. LHO:77073
5 - 25 mrad phase noise (Nutsinee's < 5mrad recent estimate from in-loop noises LHO:77124 & O4a 20-25 mrad phase noise from DARM NLG sweep LHO:74318)
NLG ~ 17.2 (many measurements @ 80 uW green trans)
~12.3% known SQZ losses, excluding OMC losses and mode mismatch. This is known sqz injection losses of 7.3% + known readout losses, excluding OMC losses, of 5.4%.
---> 1 - (1-.073)*(1-.054) = 12.3% sqz loss, excluding OMC losses and all mode-mismatch ( O4 SQZ wiki, gsheet )

So squeezing rules out the ~20% omc losses inferred from this sqz-omc visibility measurement. I'm not sure what is exactly is wrong, but in the mode scan, there was considerable TEM01/10 misalignment despite running OMC ASC + manual alignment. Unsure if alignment is the issue, or maybe something wasn't right with the squeezer beam, such that alignment couldn't improve (worth checking the beam round-ness on sqzt7?).

Script output below (code in git). Running this and Sheila's script in LHO:70866, I get the same output. So, the script seems OK, but something else is wrong with this measurement.

--------------- er16 sqz ------------------

processing measurement for er16 sqz

P_Refl_on_res*1e3 = 0.12831 mA 
P_Refl_off_res*1e3 = 1.00626 mA
Trans_A*1e3 = 0.62987 mA  (I assume OMC-DCPD_SUM_OUTPUT is calibrated into mA with the new OMC, I did not check this calibration.)
removed trans blocked of -0.00332 mA

Power on refl diode when cavity is off-resonance: 1.006 mW
Power on refl diode when cavity is on-resonance: 0.128 mW
Trans power when cavity is on-resonance: 0.734 mW 
Incident power on OMC breadboard (before QPD pickoff): 1.026 mW
Measured efficiency (DCPD current/responsivity if QE=1)/ incident power on OMC breadboard: 71.546 %

Using 4.0% mode-mismatch from Jennie peak fitting, visibiilty_00*100 = 90.885%

assumed QE: 100 %
power in transmission (for this QE) 0.734 mW
HOM content infered (like mode matching):  11.964 % 
Cavity transmission infered:  82.057 % 
predicted efficiency () (R_inputBS * mode_matching * cavity_transmission * QE): 71.546 %

omc efficency for 00 mode (incl R_inBS * cavity_transmission * QE, no mm): 81.270 %
round trip loss: 1606 (ppm)
Finesse: 372.613

Non-image files attached to this report

2024April09_er16sqz_timeseries.pdf

2024April09_er16sqz_modescans.pdf

H1 SQZ - FC locking issues from wind

victoriaa.xu@ligo.org — Tue, 16 Apr 2024 06:18:17 -0700

Author: victoriaa.xu@ligo.org

Report ID: 77188

Naoki, Corey, Vicky

~~Corey is taking it to OBSERVE without squeezing tonight.~~

We traced down an issue to FC2 0.3-0.5 Hz oscillations, which maybe is worse right now due to wind. We think this excess FC2 motion is preventing FC from locking.

FC2 0.3-0.5 Hz oscillations screenshot - see the FC Green VCO control signal trying to lock and failing - at the same time, we can see the FC2_M1_L oscillations around 0.4 Hz, even with no control signals sent to FC2 SUS. So, seems like FCGS VCO is trying to track the FC2 L oscillations, but the real FC2 motion is too much for the FCGS VCO to hold lock, and this prevents further locking. Corey says perhaps this FC2 motion is extra bad right now due to the wind. I don't remember this issue in O4a. Without FC2 L motion calming down a bit, I don't think we can hold a stable FC lock.

~~So, we decided to go to Observe without SQZ tonight, at least until the wind calms down. Maybe could try SQZ later if wind calms down.~~

Edit: It seems FC has been struggling to lock with winds > 30-40 MPH these last couple days, see screenshot with FC locking and wind speeds.

OpsInfo, SEI, SUS

Images attached to this report

LHO General - Mon EVE Ops Summary

corey.gray@ligo.org — Mon, 15 Apr 2024 23:59:39 -0700

Author: corey.gray@ligo.org

Report ID: 77186

TITLE: 04/15 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 161Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY:

With another 4hr wind storm, Squeezing wasn't possible due to a noisy HAM8 & an FC2 mirror oscillating at 0.35Hz. This wind storm also caused a lockloss. Initial Alignment was run (skipping SRC). Winds calmed, and made it to Observing w/ Squeezing due to quieter conditions. Overall about 5hrs of downtime due to winds preventing Squeezing and causing a lockloss.
LOG:

2335 SQZ_FC takes Out of OBSERVING
- 2339 Back to Observing after, SQZ_FC relocks....but....
- 2340 SQZ_FC unlocks again. Staying down as Naoki investigates FC's ASC
- In thoughts of prepping for operating with No Squeezing, I did svn commits to all SQZ files which were M-odified. But we ended up not making changes since the wind storm died.
2348 Received Dust Monitor PSL Major alarm (~120counts @300nm)
0022-0144 PCal Lab work (francisco)
0230 Lockloss due to Wind gust
0344 Initial Alignment (skipping SRC)
0454 OBSERVING w/ Squeezing (since winds dropped around 0430)

H1 General - Back To Observing With Squeezing -knock on wood-

corey.gray@ligo.org — Mon, 15 Apr 2024 22:01:16 -0700

Author: corey.gray@ligo.org

Report ID: 77196

Similar to yesterday, we had a 4hr wind storm. This caused issues with the Squeezer during the last lock and then eventually had gusts that rumbled the detector for a lockloss! Reacquisition was tough, so optedfor a "partial" Initial Alignment (skipping SRC since SRY doesn't acquire). After an IA, H1 locked on its first attempt.

Aaaaaand, we also have Squeezing....BECAUSE...30min ago the wind storm calmed down! (and I was all ready to make changes to SQZ nominal states for guardian nodes!)

I believe SQZ_FC now has the ASC "on" from Naoki's earlier work, so I ACCEPTED the SDF diffs for this (attached).

SQZ

Images attached to this report

H1 SQZ - Comment to Observing without squeezing tonight

rahul.kumar@ligo.org — Mon, 15 Apr 2024 21:16:43 -0700

Author: rahul.kumar@ligo.org

Report ID: 77195

I have switched ON the osem input filters after they were found to be OFF on SUSFC2 (HAM8) and have also accepted them in the SDF.

Images attached to this report

LHO General - Mid-Shift Status: Mon EVE

corey.gray@ligo.org — Mon, 15 Apr 2024 19:59:57 -0700

Author: corey.gray@ligo.org

Report ID: 77192

H1 just had a lockloss (after 10.5hr lock) due to a big wind gust (coincident with an audible "creak" in the Control Room). Prior to this, coincident with the beginning of this current wind storm about 3.5hrs ago, the Squeezer unlocked taking us out of Observe (similar to last night when wind storm occurred). Naoki & Vicky spent a bit of time trying to get the squeezer back, but I overheard them talking about lots of motion on SQZ optics).

Was getting ready to transition H1 to a No Squeezing state for the night, but the Squeezer locked back up (see Naoki/Rahul alog). But it only lasted 30min until winds increased.

Here we are after the H1 lockloss. By default, will see if Squeezing is possible, but if we run into the same issues & it's windy, will transition H1 for No-Squeezing operations for the night.

H1 SQZ - Comment to Observing without squeezing tonight

corey.gray@ligo.org — Mon, 15 Apr 2024 19:34:49 -0700

Author: corey.gray@ligo.org

Report ID: 77191

And just like that, H1 had a lockloss.....about 5-sec prior to the lockloss I heard a loud creak in the Control Room/building which I'm assuming is due to a big wind gust. :( (see attached for a look at the winds---it's windier than last night! And last night at around this time is when the winds increased and the SQZ started having issues during a 4hr wind storm)

I still have NOT made the changes to SQZ guardians for NO SQUEEZING.

Images attached to this report

H1 SQZ - Comment to Observing without squeezing tonight

corey.gray@ligo.org — Mon, 15 Apr 2024 19:28:48 -0700

Author: corey.gray@ligo.org

Report ID: 77190

As I was getting ready to change H1 configuration for NLN w/ NO Squeezing, Rahul mentioned the input filters for the FC2. So, before I changed anything, we halted No-Squeezing and decided to try for Squeezing---Naoki was able to get us there fairly quick. And then we went to Observing.....but this only lasted about 30min before the FC unlocked again. (this also happened to coincide with winds increasing again with gusts touching 40mph)

So we may still have an issue with FC2/HAM8 isi shaking (I believe Naoki & Jim were saying the noise is around 0.3Hz.)

I will return to following the procedure for No-Squeezing as Vicky posted originally.

H1 SQZ - Comment to Observing without squeezing tonight

naoki.aritomi@ligo.org — Mon, 15 Apr 2024 18:57:15 -0700

Author: naoki.aritomi@ligo.org

Report ID: 77189

Rahul, Corey, Naoki

Rahul found that FC2 M1 OSEM OFFSET were OFF, which should be ON. He will report the detail later. After we turned on the offset, FDS was recovered. So we went to observing with squeezing.

H1 CDS - New SUS OPLEV Overview MEDM with links to Control Screens

david.barker@ligo.org — Mon, 15 Apr 2024 16:14:10 -0700

Author: david.barker@ligo.org

Report ID: 77187

Fernando, Dave:

We have released a new SUS Oplev Overview MEDM in which the BSC oplevs have CONTROL buttons to open Fernando's control screens.

I took the opportunity to macrotize the overview, with the oveview opening two MICRO MEDMs: H1SUS_OPLEV_MICRO.adl is opened directly for the HLTSs, and H1SUS_OPLEV_WCTRL_MICRO.adl is opened for the BSCs. The latter in turn opens H1SUS_OPLEV_MICRO.adl and adds the CONTROL button. The control adl file resides in the SYS/H1/MEDM directory and is called H1SYS_OPLEV_CONTROL.adl.

The new Oplev Overview was created in the SUS/H1/MEDM directory, the original remains in the SUS/COMMON/MEDM directory and has not been modified.

To see the new Oplev MEDM you will need to start a new SITEMAP.

Attachment shows the Overview MEDM, with ETMY's Control MEDM superimposed.

Images attached to this report

LHO General - Mon EVE Ops Transition

corey.gray@ligo.org — Mon, 15 Apr 2024 16:10:59 -0700

Author: corey.gray@ligo.org

Report ID: 77185

TITLE: 04/15 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 154Mpc
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
    SEI_ENV state: SEISMON_ALERT
    Wind: 10mph Gusts, 5mph 5min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.15 μm/s
QUICK SUMMARY:

Nicely Observing H1 handed off by RyanC. He mentioned, same issue with SRC for alignment and needing to skip it (that's atleast 3x in a row). He also mentioned a drop out of Observing due to SQZ_FC as observed last night (and tweaks Naoki made for this). Currently, waiting for a M5.9 S.Korea earthquake to roll through with its R-wave in 10min.

H1 ISC - Comment to signals to consider for damping triple bounce modes

jeffrey.kissel@ligo.org — Mon, 15 Apr 2024 16:07:03 -0700

Author: jeffrey.kissel@ligo.org

Report ID: 77184

"Yes and..." Here're some plots that demonstrate the coupling between these modes and ISC channels - at higher resolution, - separated into ASC and LSC signals, and - with the individual optics called out as per their ID in LHO:49643 In addition to the region that Sheila focuses on, 27 Hz and 28.5 Hz to isolate the highest vertical modes of the recycling cavity HSTS and HLTSs, I also show the 40-42 Hz region to show the highest roll modes of the recycling cavity HSTSs. (Note, I looked around ~45 Hz for the highest HLTS vertical modes, but they did not appear in DARM, nor any of these other sensors.) This should help us pick the error signals, and/or how much damping we should expect to get, if we don't want to use DARM_CTRL as our error signal (due to concerns about parasitic loops, or needed to account for it inn the DARM calibration, etc.).

Images attached to this report

H1 General - OPS Monday day shift summary

ryan.crouch@ligo.org — Mon, 15 Apr 2024 16:01:24 -0700

Author: ryan.crouch@ligo.org

Report ID: 77177

TITLE: 04/15 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 154Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY: We stayed locked the whole shift after locking.

The wind started to pickup in the early afternoon, gust over 30mph

Lock#1

Found the IFO in IA, stuck at SRY. I adjusted SRM to maximise the spot on AS AIR then got out of IA and was able to lock. It took a few tries, ALS was getting knocked out by the wind possibly.

16:10 - 19:27 UTC Observing
- We dropped observing briefly when the FC lost lock, it relocked itself
19:29 - 21:36 UTC Observing
- Naoki adjusted the SQZ angle to maximize squeezing, alog77180
- The SQZer lost lock again, returned to OBS after it relocked itself
21:38 - 23:00 UTC Observing

LOG:

H1 ISC - signals to consider for damping triple bounce modes

sheila.dwyer@ligo.org — Mon, 15 Apr 2024 14:44:31 -0700

Author: sheila.dwyer@ligo.org

Report ID: 77182

Jeff K, Sheila D

We are interested in which signals we can use to try to damp triple bounce and roll modes, since these are probably responsible for some of the peaks in our forest of peaks around 25-35Hz (77109 and 76505). Jeff is preparing to implement a damping path on the HSTSs so that we can try to damp these.

We looked at signals (in addition to DARM) that we may want as options for damping.

27.42 Hz - REFL A 9I PIT
27.5 Hz -nothing other than DARM
27.6 Hz - REFL A 45I yaw (plus several LSC signals, PRCL, SRCL, REFL45 I, POP9Q)
27.72 Hz nothing but DARM
28.2 Hz PRCL, LSC REFL45 I, ASC REFL A 9I pit, ASC REFL A 45 I yaw

Dtt template is at /ligo/home/sheila.dwyer/SUS/HSTS_damping_signals_checks.xml

Images attached to this report

H1 CAL - Pcal X/Y comparison excitation amplitudes and SNRs

richard.savage@ligo.org — Mon, 15 Apr 2024 14:17:40 -0700

Author: richard.savage@ligo.org

Report ID: 77181

FranciscoL, RickS

On April 4, 2024 we used DTT to measure the amplitudes of the Pcal lines used in the Pcal X/Y calibration comparison in both the Pcal end station Rx sensor outputs and the DARM_ERR signal. The attached plots shows the peaks in the spectra measured with 0.001 Hz requested BW, 50% overlap, 10 averages during a long lock stretch. The second image is a page from Francisco's lab book.

The SNRs for the lines from the Pcal Rx sensors is about 5e-5 and

the SNRs of the lines in the DARM_ERR signal are about 1350.

CAL

Non-image files attached to this report

XYcompare04032024bRot.pdf

FLlabBook.pdf

H1 SQZ - SQZ angle tuning during observing

naoki.aritomi@ligo.org — Mon, 15 Apr 2024 13:50:16 -0700

Author: naoki.aritomi@ligo.org

Report ID: 77180

Since the sqz angle seemed not optimized and range was below 160 Mpc in this lock, I tuned the sqz angle during observing after 4 hours into lock. The attachment shows that sqz and range improved with sqz angle at 200. The previous sqz angle was 192 and it was set just after the lock in 77144.

Images attached to this report

H1 General - Comment to OPS Monday day shift update

ryan.crouch@ligo.org — Mon, 15 Apr 2024 12:28:57 -0700

Author: ryan.crouch@ligo.org

Report ID: 77179

The SQZ_FC lost lock and dropped us from observing at 19:27UTC, back at 19:29

SQZ

H1 General - Comment to OPS Monday day shift start

david.barker@ligo.org — Mon, 15 Apr 2024 12:26:34 -0700

Author: david.barker@ligo.org

Report ID: 77178

I powercycled ITMY camera (h1cam23) and restarted its server process on h1digivideo2. All looks good now, the camera went down at 04:33 Sun 14th PDT.

H1 General - OPS Monday day shift update

ryan.crouch@ligo.org — Mon, 15 Apr 2024 12:10:51 -0700

Author: ryan.crouch@ligo.org

Report ID: 77169

We've been locked for 3 hours, in observing since 16:10 UTC. SQZing has been getting better as we thermalize.