C. Compton, J. Kissel

Fil and I are pushing forward with the expanded scope of ECR E2400330 to upgrade the whitening stages of the OSEM PD satamps for the top masses of the filter cavity HSTS. More details on the actual upgrade once installed, but I figure a separate instructional aLOG is warranted for the prep we did since the SQZ system and these kind of "once in a blue moon" activities for the filter cavity are still relatively new to folks.

(1) Offloaded SQZ WFS DC alignment request to FC1, FC2, and ZM3 to their respective alignment sliders.
    - assume that the overall SQZ_MANAGER is already in DOWN.
    - open the SQZ_FC sub-manager guardian log
    - open ndscope of top mass OSEMs to check that over alignment of the SUS *doesn't* end up changning
        $ ndscope H1:SUS-{FC1,FC2,ZM3}_M1_DAMP_{P,Y}_IN1_DQ
    - request SQZ_FC's goto state FC_ASC_OFFLOADED, watch SQZ_FC guardian log and ndscope trend to confirm expected behavior
    - once done, request SQZ_FC to go back to DOWN.

    We found that this state did exactly as expected -- pushed the static output of the M1 LOCK banks to the (correctly calibrated) alignment slider OPTICALIGN OFFSET, and while there was a minor blip in top mass OSEM record of physical alignment during the transition, the SUS did not move.

(2) Brought FC1 and FC2 to SAFE with their SUS_{FC1,FC2} guardians.

(3) Bypassed the use of OSEM readbacks for the IOP software watchdog (SWWD).
    - from the sitemap, opened the "SWWD" overview screen from the "WD" dropdown in the far bottom left corner
    - opened each HAM7 and HAM8 SWWD screens
    - made sure the bypass time, H1:IOP-SUS_{FC1,FC2}_DK_BYPASS_TIME, was set to some long amount of time (e.g. 12000 [seconds]).
    - hit BYPASS, H1:IOP-SUS_{FC1,FC2}_DACKILL_BPSET

Seismon was restarted.

J. Oberling, R. Short

At the start of maintenance this morning, Jason and I touched up alignment into the PMC and RefCav remotely using the picomotor controlled-mirrors on-table. With the IMC and ISS off, we started with PMC alignment. Ultimately, we could only get maybe 0.1W of improvement in both transmitted and reflected power; see first screenshot with T-cursors for before and after power levels.

We then turned the ISS back on and moved on to RefCav alignment. Here we were able to get about 0.025V of improvement on the TPD signal, mostly in pitch; see second screenshot for before and after comparison.

Neither of these adjustments yielded the gains we were hoping for, and the camera spots certainly still show some apparent misalignments. This means we again may need to do some on-table alignment in the future, but for now, this should be passable.

Following the discovery that the testpoint monitor IOC had stopped updating some time ago I have promoted the TESTPOINT button on the CDS Overview from a blue Related-Display to a full System button.

The button has been moved from the related display grid to the system column, and PICKET FENCE has been moved left to make room (see attachment).

The TESTPOINT button will turn MAGENTA if its GPS time stops updating. If there are no testpoints open, the button is LIGHT-GREEN, otherwise it is GREEN.

As before, clicking on the TESTPOINT button will open the CDS_TPMON_OVERVIEW.adl MEDM.

TITLE: 08/05 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 152Mpc
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 12mph Gusts, 6mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.09 μm/s
QUICK SUMMARY: H1 has been locked for 17 hours, but looks like there were three brief drops from observing between 11:33 and 11:40 UTC (I'm assuming SQZ-related, but will look into it). Magnetic injections are running and in-lock charge measurements will happen right after before maintenance begins at 15:00 UTC.

• Wind and ground motion low
• All other systems nominal

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

TITLE: 08/05 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 149Mpc
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY:
H1 Stayed Locked  and observing the entire shift.
No SQZ issues, Pi's, wind, barely even an eath_quake! It was a very quite night without any super events once again.

All systems running as expected.

GRB-Short E586884 at 23:08:34 UTC

LOG:

No Log

Using Vibration Sensors To Gauge Health Of HVAC Fans Site Wide Famis 26413

 

Ivey, Edgard.

Ivey made even newer fits for the M1 SR3 in "Yaw using the measurements that Oli took in [LHO: 86075].

These fits are pretty similar to the last set we got in [LHO: 85446]. However, this time, Ivey used vectfit3 for both of the fits directly. She only manually ensured that the zeros were all in the left-hand-plane, and that there were no additional zeros in the M1 to M1 transfer function, even if the measurements show a bit extra phase loss compared to the fit.

These are the fits obtained [see figures for an eye-test of the goodness of fit]:

For the ISI to M1 transfer function:
'zpk([0,0,-0.027+20.489i,-0.064+11.458i,-0.027-20.489i,-0.064-11.458i],[-0.072+6.395i,-0.072-6.395i,-0.096+14.454i,-0.096-14.454i,-0.062+21.267i,-0.062-21.267i],-0.001)'

The M1 to M1 transfer function:
'zpk([-0.002+19.246i,-0.005+8.312i,-0.002-19.246i,-0.005-8.312i],[-0.065+6.392i,-0.065-6.392i,-0.076+14.442i,-0.076-14.442i,-0.055+21.272i,-0.055-21.272i],12.085)'

The fits were added to the Sus SVN and live inside '/ligo/svncommon/SusSVN/sus/trunk/HLTS/Common/FilterDesign/Estimator/fits_H1SR3_2025-07-29.mat' .

The filters can be installed using 'make_SR3_yaw_model.m', which lives in the same folder [for reference, see LHO: 84041, where Oli got the fits running for a test]. This last script, as well as 'make_SR3_yaw_blend.m' were updated to work with the new naming convention for the estimator block.

Hopefully we will get to test the estimator again soon!

TITLE: 08/04 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 146Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 19mph Gusts, 13mph 3min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.09 μm/s
QUICK SUMMARY:
H1 has been locked and Observing for just over 2 hours. 

I've got a and Alarm from the CDS screen about H0:VAC-MX_X1_PT343B_PRESS_TOR, but after speaking to Janos this is in preparation for tomorrow's maintence Tuesday VAC team activities.

So other than that everything seems to be humming along.

Jennie W, Camilla C

A while ago we heated up then cooled down the SR3 heater (alog #84749).

As part of measurements using this data I calculated the curvature change, following the approach at LLO by Aidan given iin alog #27262. Matlab code is below.

%calculate SR3 spherical lens

Pin = 2;%W

double_pass = 2;

SR3_t = (3*3600) + (11*60); % Time for cooldown in s.

delta_ITMY = -2.67e-5;% decrease in defocus of ITMY according to Hartmann sensor.

D_ITMY = delta_ITMY./double_pass;% defocus change in Dioptres

D_ITMY_error = 5e-6;% error on defocus in Dioptres.

R_SR3 = 36.013;% cold radius of curvature in m

delta_R = (2./((2/R_SR3)+D_ITMY))-R_SR3; % change in curvature during cooldown in m/

delta_delta_R = D_ITMY_error.*(2./((2./R_SR3)+D_ITMY)); % error on curvature change.

This means the rate of defocus change is 6.6750uD per Watt.

The final curvature change is + 0.0087 m +/- 0.0002 m as the mirror becomes less curved due to cooldown.

TITLE: 08/04 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 150Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Commissioning started the shift with one lock loss and a longer recovery. After we finally got back up we have been observing now for 2 hours.
LOG:

• 1530 Out of Observing to start planned commissioning
• 1754 Lock loss
  • See alog86180 for more relocking details
• 2138 Observing
• 2308 GRB short E586884

While PT343 gauge is valved out and reading a higher pressure than normal for the next day or so several changes have been made to the alert/alarm systems:

VACSTAT: PT343 is Disabled, it cannot cause vacstat glitch detection events (right side of attachment).

ALARM: PT343 has been bypassed, meaning it says in alarm but no cell phone texts are sent (lower part in attachment). Bypass time:

Bypass will expire:
Wed Aug  6 01:08:03 PM PDT 2025
For channel(s):
    H0:VAC-MX_X1_PT343B_PRESS_TORR
 

Jennie W, Sheila D

Summary: tried to use ETMX injection to tag light coming from the arms at the REFL port as we step the darm offset, didn't get a full measurement as we lost lock - seems unrelated.

During the commissioning period and while Robert as doing shaker i jections, I tuned a line at 74.37 Hz on the SUS-ETMX_L3_CAL_EXC. This is the same point at which the ETMX CAL line input goes in (where the calibration exc for ETMX is injected into the DRIVEALIGN matrix). The psds shown were measured about a minute before lost lock and it can be seen that the rms motion in the upper left of the ETMX bottom mass is not reaching its limit.

The settings I used in AWG are shown in this photo.

After checking the height of the line in DARM, OMC REFL and the rms on the upper left ESD readout, I tried to take a darm offsert step measurement using autodarmpoffsetstep.py (using the ETMX line instead of the PCAL lines to readout the optical gain). To do this I comment out the setup_pcal_for_darm_offset_step and restore_pcal functions in autodarmoffsetstep.py before running it.

I had to the stop the measurement twice to trurn off the OMC ASC and put the X0 offset back to what it was before the measurement. One step into this measurement set we then lost lock (around 2 minutes into the final attempted DARM offset measurement). We can't see any evidence so far as this was the causer of lockloss as the line had been running for 40 minutes or so without breaking the lock.

Data is saved in an xml in /ligo/gitcommon/jennifer.wright/git/DARM_OFFSET

Plot of 3 months of Bit switching.
There are certainly bits switching on all of the channels.
Marked nad noticable increase in bit switching on May 22nd for ETMY which I believe is a known issue.

1438365262

No obvious cause yet. Commissioning was going on at that time, but no activity seems suspect.

Lockloss at 2025-08-01 22:02 UTC after 3 minutes in NLN. We couldn't go into Observing because of SPM differences causing SDF diffs in the guardians for ISIHAM2/3/4/5. Last time we had this, I asked Jim what to do and he said to just INIT the guardians, and it caused a glitch, but we did not lose lock, and he said INITing them should not cause glitches or locklosses (85809). Today, I did the same thing and went to INIT the guardians, but when doing it for the first one, ISIHAM2, it caused a glitch and we lost lock from it.

I actually started this a long time ago, but got swamped with other work and buried by snow. Our seismon code does not seem to give an accurate prediction of ground velocities. Attached plot compares the timeseries .03-.1hz rms ground velocity measured by the ITMY STS in Z (solid blue line) and the seismon predicted ground velocities for 5000 minutes of data from this month. Each dot represents the predicted velocity and arrival time for each earthquake seismon found over this time period (seismon can give up to five active predictions, eq chan 1,2 & 3 are the first 3 predictions, typically the "live" ones if seismon has given us early warning). The numbers by each prediction point are the magnitude and distance in 1000km of the earthquake (so 5.8, 10 is a 5.8 magnitude earthquake 10,000 km away). The earthquake at 4000 minutes actually has a  arrival time prediction , but the predicted velocity is up around 60 micron/s, which made the rest of the plot hard to see, so I cut it off.

I would expect that if seismon was accurately predicting ground velocities, the dots would follow the blue line in some way. If there is a systematic relationship between the dots and the line, I don't see it.

The good new is that for other time periods when there were large earthquakes, seismon usually gave us early warning, which is the primary goal. But it would help deciding what the response to a notification should be if we could get a believable prediction of the velocities.