Here is an investigation that might give us insight into the PRCL/CHARD/DARM coherences.

Today, we ran a PRCL injection for the feedforward where we injected directly into the PRCL loop. I took this injection time and looked at how the CHARD P and Y error signals changed, as well as their respective coherences to PRCL and DARM (figure). When injecting about 15x above ambient in PRCL from 10-100 Hz, there is a 2x increase in the CHARD P error signal and 4x increase in the CHARD Y error signal. The coherences of CHARD P and Y to PRCL increase as well, and the coherences of CHARD P and Y to DARM also increase. This injection allows us to measure a well-defined CHARD/PRCL transfer function. In the attached screenshot of this measurement, all the reference traces are from the injection time, and all the live traces are during a quiet time.

Meanwhile, I looked back at the last time we injected into CHARD P and Y for the noise budget, on June 20. In both cases, injecting close to 100x above ambient in CHARD P and Y did not change either the CHARD/PRCL coherence or PRCL/DARM coherence. There is some change in the PRCL error signal, but it is small. Again, in the attachments, reference traces are injection time and live traces are quiet time. CHARD P figure and CHARD Y figure.

I think that this is enough to say that the PRCL/DARM coupling is likely mostly through CHARD P and Y. This would also make sense with the failure of the PRCL feedforward today (79806). However, we may want to repeat the CHARD injections since there have been many IFO changes since June 20.

TITLE: 08/29 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 142Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY:

IFO is in NLN and OBSERVING as of 19:03 UTC (with some small drop-outs to reload ISC lock and test some filters)

We only had one lockloss today and it was during our 9-12 PST comissioning. Lock acquisition was fully automatic.

Other than this, comissioning went well. Some highlights:

• Thermalized Calibration Sweep - alog 79786
• New HAM1 FF for CHARD P and INP1 P - Improvement - alog 79799
• Jitter Cleaning Coefficients Update - alog 79797
• A2L Scripts for all QUADs - alog 79796

LOG:

TITLE: 08/29 Eve Shift: 2300-0500 UTC (1600-2200 PST), all times posted in UTC
STATE of H1: Observing at 141Mpc
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 7mph Gusts, 5mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.10 μm/s
QUICK SUMMARY:

H1 has been locked 5.5+hrs, with range hovering under 150Mpc.  Environmentally we are really quiet.

There has been mention of taking H1 down briefly for a PRCL FF test/change (ElennaC).

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

I was able to new SRCL and MICH feedforward using the iterative method. Measurements were taken in alog 79693.

The current MICH FF is performing well except for below 30 Hz, so that's where I targeted in my fit. SRCL needed some improvement everywhere.

The new MICH filter is saved and loaded in FM8 and the new SRCL filter is saved and loaded in FM5. They are both labeled with the date '8-27-24'.

To compare how these filters are performing, I would use the templates Oli saved in the above alog, but first save the live trace as a reference to compare against.

I have not yet done the PRCL fit because I want to see how SRCL performs, and maybe redo the PRCL injections before trying the fit.