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.

I ran a PRCL feedforward injection since the PRCL to DARM coherence has increased. Indeed, the injection showed the PRCL feedforward was doing worse around 30 Hz. I found that by increasing gain of the feedforward from 0.6 to 0.9 this improved the subtraction again.

You will notice that below about 15 Hz, PRCL coupling is still not great. That would probably require a more "invasive" adjustment of the feedforward fit, but maybe it's not worth it since it doesn't seem that it's causing much noise.

In the first attachment, blue trace shows and old coupling measurement with no feedforward, green was the "as found" previous feedforward fit measurement. Brown was the measurement today before I started adjusting the gain and red is what I got after increasing the feedforward gain. Second attachment shows the SDF accept. I also updated the gain in lscparams.

Thu Feb 20 10:07:47 2025 INFO: Fill completed in 7min 43secs

Gerardo confirmed a good fill curbside. TCmins [-51C, -50C] OAT (0C, 32F) DeltaTempTime 10:07:47

Closes FAMIS#, last checked 82369
 
HEPI pump trends looking as expected. The lines 23 days ago in all the plots are from a DAQ restart done during Tuesday Maintenance on January 28th(82498).

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.