Here is a comparison of DRMI and CHARD control signal spectra from July 11th to this afternoon, after Elenna's new HAM1FF. 

The control room FOM seems to indicate that there is some huge excess noise in our DRMI signals, but this comparison shows that isn't the case.  Also, the CHARD control signals are largely similar, with an improvement in pitch which is likely from the HAM1 FF tuning.

Robert, Sheila

Robert and I went to ISCT1 before the beam diverters closed in this morning's lock acquisition.  We saw that there was a beam from a POP path beam splitter that was dumped on a razor blade dump that was hitting the top of the dump, so that a small part of the beam was visible on the ALSX camera.  We adjusted the beam dump to fully catch the beam.  Once the beam divereters are closed this beam isn't there, so this shouldn't have been a noise issue in nominal low noise. 

Robert has seen coherence between an accelerometer on this table and DARM in observing, we tried closing the ALS light pipe and Robert saw that didn't change the coherence, so he opened the light pipe again.

We did a 10 minute on/off HAM1 FF test today. I determined from that test that improvement could be made to the feedforward to CHARD P and INP1 P, so I used that off time to train new filters (time here: 79792).

I took a screenshot of the DTT results. The golden traces represent the various loop spectra with the feedforward OFF. Blue represents the previous feedforward, and red represents the new feedforward I fit today. First, look at the top and bottom plots on the left, showing CHARD P and INP1 P. You can see that the old feedforward was having minimal benefit (gold to blue), and the new feedforward is performing much better (gold to red).

Next, look at the middle plot on the left showing CHARD Y. This plot shows that the feedforward is making CHARD Y WORSE (blue worse than gold). Therefore, I just turned it off. I am not yet happy with the fitting results for CHARD Y, so I will continue to work on them.

You can also see in the middle right plot, PRC2 P current feedforward is performing well (gold to blue), so I made no change, red still matches blue.

Note! This means the significant change here must be related to RF45- PRC2 is only sensed on RF9, while INP1 and CHARD use RF45.

Finally, DARM on the right hand side shows improvement from blue to red. It looks like HAM1 FF off is better below 15 Hz, maybe due to CHARD Y.

The new CHARD P and INP1 P filters are all saved in FM9 of their respective banks. I SDFed the new filters, and the CHARD Y gains to zero, second screenshot.

I made one mistake which is that I did not SDF these changes in SAFE, only in OBSERVE, which means that needs to be done before an SDF revert, since they are not guardian controlled!

Naoki, Sheila

We changed SRCL offset to see if it can improve the bucket sensitivity. Every time we changed the SRCL offset, we ran SCAN_SQZANG. We modified the SCAN_SQZANG to optimize the BLRMS6 at 2 kHz instead of BLRMS3 at 350 Hz. We reverted it after the measurement.

The attachment shows the DARM with different SRCL offset. The nominal SRCL offset is -175. The SRCL offset of -100 is worse than nominal in the bucket, but others are similar. So we left the SRCL offset at nominal value. Compared to O4b start, squeezing is good above 1kHz, but worse below 1kHz.

I did a quick check of the jitter cleaning, and it looks like we indeed have more jitter peaks right now than we used to (before the vent).  Since it looked like some could be subtracted out, I updated the jitter cleaning coefficients (training on last nights nice long lock).

In the attached figure, the bottom panel shows the cleaning improvement (red is lower than blue, which is good) that we had during last night's long lock (and we've had since the vent).  These are the same cleaning coefficients that we've been using for a long time.  The data in this lower panel is from 10+ hours into a lock/

The top panel shows the cleaning improvement (red lower than blue is good) after I updated the cleaning coefficients.  This data is from about 1.5 hours into a lock, but the coefficents were trained on the data from the lower panel, so its possible it will get a bit better with time.

It didn't do as much as I'd hoped, which maybe means that some of the jitter is not well witnessed by the one IMC WFS diode (pit and yaw of WFS A) that we have in the subtraction system.

I ran the a2l_min_multi.py script, again not with a thermalized IFO though (Monday same story alog79714). This time there were some changes to ISC_library.py that made it so I was running into an import error with cdslib. I temporarily removed the dependence on cdslib by commenting it out, and I'll figure out how to get around this later. I did all quads and both dofs at the same time, ETMX P having the largest change of -0.14 but the rest were similar. I ended up unmonitoring all of these gains since they are saved in guardianl I updated lscparams.py with these new values, but I have no loaded ISC_LOCK yet.

RESULTS
*************************************************
         ETMX P
Initial:  3.13
Final:    2.99
Diff:     -0.14

         ETMX Y
Initial:  4.87
Final:    4.9
Diff:     0.03

         ETMY P
Initial:  4.48
Final:    4.48
Diff:     0.0

         ETMY Y
Initial:  1.13
Final:    1.13
Diff:     0.0

         ITMX P
Initial:  -0.98
Final:    -1.0
Diff:     -0.02

         ITMX Y
Initial:  2.87
Final:    2.87
Diff:     0.0

         ITMY P
Initial:  -0.37
Final:    -0.39
Diff:     -0.02

         ITMY Y
Initial:  -2.48
Final:    -2.45
Diff:     0.03
 

A few changes to the CDS cell phone alarm system:

• uncommented vac gauge PT110 (was removed for vent) and reset its alarm level
• moved all the vacuum alarms together in the VAC section of the xml config file 
• added CDS HW STAT alarm

Adding the CDS HW channel caused the alarm system to go unstable (sorry for all the restart messages this caused). Problem was due to the CDS IOC not supporting the VAL, STAT and SEVR fields. The alarm code permits a bypass of these checks with the "fields=0" directive, which I have applied to this channel. 

We've been seeing the OMC trans camera spot shaking with some lower frequency motion (<100Hz) since the vent. It doesn't seem to be in any IFO signals that we've found so far though, but there's only been a few eyes on this issue (see Jenne's alog79748 for one quick investigation). Looking at the lock from overnight, it seems that the camera was much more stable than previous locks. Yesterday seemed to be some of the worst motion so far (5 day trend and 1 day trend). Trending the OMC QPDs and the OMC ASC I see no difference between the good and the shakey times. (attachment 3). I also would say that it doesn't seem to be affecting our range (attachment 4 and attachment 5). Also nothing seen in other ASC, LSC, or HAM6 CPSs, PEM acc. at HAM6 signals (the other attachments). Next steps would be to take a spectra and start trying to match the frequencies.

Find below range comparison screenshots between a low-range lock from 08/29/2024 after our emergency vent and a high-range lock from 06/17/2024.

Files live in:

 /ligo/gitcommon/NoiseBudget/aligoNB/out/H1/darm_intergal_compare/compare_darm_spectra_OM2_hot_vs_cold_no_sqz.svg
 /ligo/gitcommon/NoiseBudget/aligoNB/out/H1/darm_intergal_compare/compare_darm_range_integrand_OM2_hot_vs_cold_no_sqz.svg
 /ligo/gitcommon/NoiseBudget/aligoNB/out/H1/darm_intergal_compare/compare_cumulative_range_OM2_hot_vs_cold_no_sqz.svg
 /ligo/gitcommon/NoiseBudget/aligoNB/out/H1/darm_intergal_compare/cumulative_range_big_OM2_hot_vs_cold_no_sqz.svg

Plots were done using instructions from alog 76935 (+ help from TJ)

Closes FAMIS26324#, last checked 79642

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

Outbuilding Fans (attachment2)
- All fans are looking normal and within range.

H1 was thermalized and in NLN Cal Meas. for this sweep.

Simulines:

Start: 1408981310

End: 1408982722

/ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20240829T154133Z.hdf5

/ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20240829T154133Z.hdf5

/ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20240829T154133Z.hdf5

/ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20240829T154133Z.hdf5

/ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20240829T154133Z.hdf5

Broadband:

/ligo/groups/cal/H1/measurements/PCALY2DARM_BB/PCALY2DARM_BB_20240829T153209Z.xml

Thu Aug 29 08:10:55 2024 INFO: Fill completed in 10min 51secs

TITLE: 08/29 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 144Mpc
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 2mph Gusts, 1mph 5min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.10 μm/s
QUICK SUMMARY:

IFO is OBSERVING since 23:56 UTC Aug 28 (14 hr lock!)

TITLE: 08/29 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Observing at 140Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY: Stayed locked the entire shift, just over 5 hours as of 05:00UTC, calm wind.

• 22:22 UTC lock loss from an Earthquake
• 23:56 UTC Observing, automated aquisition after waiting out the ground motion
  • Running the low range check showed high PRCL coherence at low frequency
  • Elevated low frequency noise below ~50 Hz

LOG:                                                                                                                                                                                                                                                                                                

I've added a change into the H1_MANAGER Guardian that starts a one hour timer when we reach OMC_WHITENING to allow for violin modes to damp down if needed before moving to NLN. While waiting in OMC_WHITENING, the already existing two hour timer to reach NLN once the locking process starts is ignored as violin modes should be damping without the need for intervention. However, once the one hour timer expires, if ISC_LOCK has still not moved to NLN, H1_MANAGER will move to ASSISTANCE_REQ and initiate a call.

I've also removed some lines in the IFO_NOTIFY Guardian which I had added last year (alog72160) that allowed for an additional time after reaching NLN for ADS to converge and switch to camera servos before calling for help. Since the switch from ADS to cameras now happens before reaching NLN, this code is irrelevant.

All of these changes have been saved and loaded.

Just lost lock from a 6.0 in El Salvador. We will begin relocking as soon as it settles down a bit.