We were in NLN but couldn't go into Observing due to some SDF diffs that I had been warned about. I accepted the diffs and we went right into Observing!

TITLE: 02/21 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 148Mpc
INCOMING OPERATOR: Oli
SHIFT SUMMARY:

IFO is in NLN and OBSERVING as of 22:01 UTC (12 hr lock!)

Extremely calm shift with no loklosses. Of note:

• violin modes IY5_6 have both been steadily going down for the last 7 hours
• PI24 still ringing up every few minutes

LOG:

None

TJ, Oli

Starting around 02/20 at 11:30 UTC, the range had a step down, where it stayed for the rest of the lock. After this step down, the range was also much noisier than it had been before the step (ndscope1). Jane Glanzer ran Lasso for us during this lock stretch (lasso), and the top channel that came back with the highest correlation to this range drop was H1:SUS-PI_PROC_COMPUTE_MODE8_NORMLOG10RMSMON, with the other channels all having much lower correlation coefficients. This was weird to us because we bandpass and downconvert to monitor mode 8 but we don't monitor or damp it, and we don't even turn on its PLL. When you plot the correlated channel along with related PLL channels (SUS-PI_PROC_COMPUTE_MODE8_PLL_AMP_FILT_OUTPUT, SUS-PI_PROC_COMPUTE_MODE8_PLL_LOCK_ST, and SUS-PI_PROC_COMPUTE_MODE8_PLL_ERROR_SIG), you can see there was some weird noise in multiple of these channels that started when the range dropped (ndscope2).

I tried plotting a series of PI_PROC_COMPUTE_MODE channels for every mode (there are 32 in total), and out of all of them, only mode 8 and mode 24 showed any change in any of their respective channels around the time of the range drop(ndscope3). It only being these two channels is very interesting. PI mode 8 comes from the TRX QPD and has a bandpass between 10 and 10.8 kHz. Like I mentioned earlier, we do not actively do anything to this channel. Mode 24 on the other hand, we definitely monitor and are damping it a lot of the time. Mode 24 is read in from the DCPDs and has a bandpass of, and the PI is centered around 10.431 kHz. It is damped by using the ESD on ETMY. Mode 24 actually has more channels that correlate better and have larger amplitudes than mode 8, but Mode 8 NORMLOG10RMSMON correlated better with lasso over the entire lock stretch.

Zooming into when the range drop started yesterday, we actually see that the large drop in range happened about 12 minutes before we see the huge error signals in the mode 24 PLL, and it is at the very beginning of the rise in mode 8 and 24 NORMLOG10RMSMON (ndscope4).

Zooming out, this excess noise in those PI channels seems to have started early on February 5th, aka after relocking after the February 4th maintenance day(ndscope5). On other days, the range doesn't seem to have been affected by this noise though, at least nowhere near the amount that it was affected yesterday. Sometimes during these periods of noise, the range won't be very good (below 155), but other times we'll see this noise in modes 8 and 24 and still be right around or above 160.

Since it looks like the range drop yesterday started before the PI channels really started changing, we're pretty sure the issue is somewhere else and is just bleeding into these two downconverted channels. Because these two PI channels go through bandpasses in the 10kHz regime, there might be something in that frequency range. It is interesting though that although another PI channel we actively monitor, Mode 31, is also in the same frequency area (centered at 10.428 kHz), is read from the OMC DCPDs, and is damped using ETMY, all just like PI24, there doesn't seem to be any coupling into its channels.

Either way, pretty good leads were made this morning towards finding the actual cause of this range drop. TJ and Camilla looked into the many glitches that appeared then at 60 and 48 Hz, as well as noting that the line at 46.1 Hz had grown, which is a known PR3 roll mode (82924).

TITLE: 02/21 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 156Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 8mph Gusts, 5mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.31 μm/s
QUICK SUMMARY:

IFO is in NLN and OBSERVING as of 18:02 UTC (6hr 20 min lock)

EY 5_6 Violins are still elevated. Rahul is trying out new settings.

TITLE: 02/21 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 156Mpc
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY: Lock loss at the start of the shift again, this one caused but  , followed by a commissioning period and a calibration measurement. ITMY modes 5&6 rang up slowly overnight and continue to be an issue to damp (82940). As of right now, I'm not sure we've found a setting that is actually damping these modes. We've been locked for 6.5 hours, observing for 2.5 of those.
LOG:

• 2004 Observing
• 2129-2201 Out of observing to run calibration measurement                                                                                                                                          

FAMIS27809

I didn't add any water to either chiller as they both looked near the max. Both filters looked good and the leak detection Dixie cup was dry. The T2200289 was updated.

Matthew Sheila

I ran a2l measurements using TJ and Sheila's a2l_min code, and I've attached the new settings below.

I've also attached plots of the coherence checks with lsc and asc channels and darm.

Results of the A2L measurement

Matthew Mayank Sheila

We went out to ISCT1 to measure the power coming to the POP AIR port, components are labeled in Sheila's alog. It seems the 50/50 beamsplitter is acting appropriately.

2025-02-20 10:28:11.348428 PST:
  H1:ASC-POP_X_DC_NSUM_OUT16 = 1.1193946024467205
  H1:LSC-POP_A_LP_OUT16 = 39.499373468859446

BS9010 power: 3.6 mW
POPX power: 1.8 mW

2025-02-20 10:35:24.229534 PST
  H1:ASC-POP_X_DC_NSUM_OUT16 = 1.1307608842849726
  H1:LSC-POP_A_LP_OUT16 = 39.88992869059245

These average power measurements were taken using

TJ, Rahul

ITMY mode 05 and mode 06 have been rung-up since morning and TJ and I have tried several settings to bring them down. The settings which is currently working is listed below in bold font,

New settings for ITMY 05/06 (not yet committed to lscparams file):-

FM5 + FM6 + FM10 Gain 0.01 (phase -60 degrees)

The other settings which I unsuccessfully tried as follows,

-60deg phase -0.01 gain - increase

zero phase -0.01 gain - increase

+30degree phase -0.01 gain - increase

Similarly TJ efforts (from morning to noon) are also given below,

Ran a calibration measurement using an older version of simulines that the CAL group updated in the wiki. We were locked for about 3.5 hours when I started the broad band.

Simulines start:

PST: 2025-02-20 13:36:12.224035 PST
UTC: 2025-02-20 21:36:12.224035 UTC
GPS: 1424122590.224035
 

Simulines end:
PST: 2025-02-20 14:00:14.443589 PST
UTC: 2025-02-20 22:00:14.443589 UTC
GPS: 1424124032.443589

Files:

2025-02-20 22:00:14,365 | INFO | File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20250220
T213613Z.hdf5
2025-02-20 22:00:14,373 | INFO | File written out to: /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20
250220T213613Z.hdf5
2025-02-20 22:00:14,378 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20
250220T213613Z.hdf5
2025-02-20 22:00:14,383 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20
250220T213613Z.hdf5
2025-02-20 22:00:14,388 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20
250220T213613Z.hdf5

Jennie W, Sheila

Today I got a chance to redo some of my output chain measurements (alog #82555) that gave us a confusing result when we were heating up and cooling down the OM2 heater. The confusiong was that our optical gain got better for cold OM2 compared to hot, but the loss through HAM6 predicted by stepping the DARM offset and comparing it to the power at the anitsymmetric port predicted that the loss was worse with cold OM2 and gave us unreasonably low (~65 %) throughput estimate for the fundamental TM00 mode through HAM6. We realised that the OM3 and OMC alignment are being changed by the ASC during this time so that could be affecting the comparison.

Steps:

Turn off OMC ASC at 18:43:00 UTC.

Run auto_darm_offset_step.py from /ligo/gitcommon/labutils/darm_offset_step at 18:45:01 UTC.

Results: P_AS = 62.996 mW + 1.162 * P_DCPD

This makes the throughput estimate for the TM00 mode through HAM6 to the DCPDs to be 86.0 % of the power at the AS port. Which seems more reasonable than the 65% we got last time. We need to do this measurements again when we have improved kappa C somehow to check it gives us the same loss estimate between two times.

We were then going to purposely change kappa C as a comparison to the estimate the DARM offset step gives us, byt changing the QPD offsets based on this measurement 82383(I got the sign wrong last time I did this).

I turned the OMC ASC back on before doing this, however when I changed the H1:ASC-OMC_A_PIT_OFFSET to 0.45 this saturated the OM3 suspension so this was set back to nominal.

I think I got signs wrong yet again so we will try what we now think are the correct ones another commissioning period but maybe do it slowly so as not to cause saturations.

[Vlad, Louis, Jeff, Joe B]
So while exercising the latest pydarm code with an eye towards correcting the issues noted in LHO alog 82804, we ran into a few issues which we are still trying to resolve.

First, Vlad was able to recover all but the last data point from the simulines run on Feb 15th, which lost lock at the very end of the sweeps.  See his LHO alog 82904 on that process.

I updated the pydarm_H1.ini file to account for the current drive align gains and point at the current L1SUSETMX foton file (saved in the calibration svn as /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/H1CalFilterArchive/h1susetmx/H1SUSETMX_1421694933.txt ).  However, I had to also merge some changes for it submitted from offsite.  Specifically https://git.ligo.org/Calibration/ifo/H1/-/commit/05c153b1f8dc7234ec4d710bd23eed425cfe4d95, which is associated with MR 10 which was intended to add some improvements to the FIR filter generation.

Next, Louis updated the pydarm install at LHO from tag 20240821.0 to tag 202502220.0.

We then generated the report and associated GDS FIR filters.  This is /ligo/groups/cal/H1/reports/20250215T193653Z.  The report and fits to the sweeps looked reasonable, however, the FIR generation did not look good.  The combination of the newly updated pydarm and ini changes was producing some nonsensical filter fits.  This is the first attachment.

We reverted the .ini file changes, and this helped to recover more expected GDS filters, however, there's still a bit of a small ~1% change visible around 10 Hz (instead of being a flat 1.0 ratio) in the filter response using the new pydarm tag versus the old pydarm tag which we don't understand quite yet, and would like to before updating the calibration.  I'm hoping we can do this in the next day or two after going through the code changes between the versions.

Given the measured ~6 Hz SRC detuning spring frequency (as seen in the reports), we will need to include that effect in the calcs front end to eliminate a non-trivial error when we do get around to updating the calibration.  I created a quick plot based off the 20250215T193653Z measured parameters, comparing the full model over a model without the SRC detuning included.  This is the attached New_over_nosrc.png image.

Attached is the DARM BLRMS before and after some filters were edited and added to remove some lines, all changes are attached apart form another adjustment to RBP_2 notch 33.375Hz.

Back to observing at 2004 after a lock loss and commissioning period. We are not thermalized yet, so we will have to run a calibration measurement later.

Matt Jennie Mayank TJ Sheila

We wanted to estimate whether we were clipping on the scraper baffle of PR2 so we moved the PR3 YAW sliders during single bounce quite a bit to get an idea of when were clipping, using the AS_C_NSUM to gauge whether we were starting to clip.

Most of the steps are the same in Sheila's previous alog, expect we are in single bounce and we are therefore not looking for the ALS beatnotes, instead we are looking at the AS_C_NSUM value. You want to take ISC_Lock to PR2_SPOT_MOVE so that the guardian will adjust the IM4, PR2 yaw sliders while you adjust PR3 sliders so that most everything stays aligned. You will have to adjust the pitch every once in awhile due to the cross couplings in IM4 and PR2.

Steps taken in this measurement:

1. Turned ISC_Lock to PR2_SPOT_MOVE
2. Move PR3 yaw using the slider (steps of 10 urad seemed to work for me) or using

       We think the yaw offset value that puts the spot on the center of PR2 is around -230 urad (we started here around 09:00 PST)

      3. By going in steps to -900 in yaw offset, while pitching PR3 every so often to keep everything centered, we were able to move across PR2 to the left edge of the baffle, clipping about 10% of the power at the ASC-AS_C QPD (finished 09:45 PST).
      4. Then we reset the sliders to their starting values and follwed the above steps going to the right (we stopped at +440 yaw offset). Here we recorded around a 10% loss on the right edge of the baffle (finished 10:44 PST).

Mayank has some plots he will comment analyzing the results of this.

Useful ndscopes

Due to so much SQZ strangeness over the weekend, Sheila set the sqzparams.py use_sqz_ang_servo to False and I changed the  SQZ_ANG_ADJUST nominal state to DOWN and reloaded SQZ_MANAGER and SQZ_ANG_ADJUST.

We set the H1:SQZ-CLF_REFL_RF6_PHASE_PHASEDEG to a normal good value of 190. If the operator thinks the SQZ is bad and wants to change this to maximize the range AFTER we've been locked 2+ hours, they can. Tagging OpsInfo.

I reviewed the weekend lockloss where lock was lost during the calibration sweep on Saturday.

I've compared the calibration injections and what DARM_IN1 is seeing [ndscopes], relative to the last successful injection [ndscopes].
Looks pretty much the same but DARM_IN1 is even a bit lower because I've excluded the last frequency point in the DARM injection which sees the least loop suppression.

It looks like this time the lockloss was a coincidence. BUT. We desperately need to get a successful sweep to update the calibration.
I'll be reverting the cal sweep INI file, in the wiki, to what was used for the last successful injection (even though it includes that last point which I suspected caused the last 2 locklosses), out of abundance of caution and hoping the cause of locklosses is something more subtle that I'm not yet catching.