B. Gateley, T. Guidry

The well pump was running both Wednesday (8/2) and Thursday (8/3) from approximately 8am to 12pm to replenish the fire water tank.

TITLE: 08/03 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Commissioning
SHIFT SUMMARY:

Arrived to H1 almost done with NOMINAL LOW NOISE and finishing out COMMISSIOING time by Louis.  

Random lockloss 2hrs into the shift.

Relocked with no issues, exept the SUSETMx had calibration line related diffs (see earlier alogs).
LOG:

• Came in with H1 waiting for ADS lines to converge and Louis doing commissioning work for Calibration lines
  • See earlier alogs for issues with SDF diffs for SUSETMX
  • We hope for the next lock these issues were addressed.  If not, please look at what values should be used from Louis' alogs.
• 0003 Went to OBSERVING
• 0058 LOCKLOSS (there was an earthquake alert, but I did not see anything obvious EQ-wise around the lockloss nothing on tidal scope, picketfence or seis_blrms])
• 0249 OBSERVING

We've only had one short (2hr) lock stretch since it was loaded, but it looks like Gabriele's adjustment to the MICH FF filter (LHO:71934) improved the noise in the UIM Kappa (screenshot attached).

L. Dartez

I reduced the amplitudes of the SUS-ETMX calibration lines between 15-17.6Hz. These line amplitudes hadn't yet been adjusted for the reduced noise level at low frequencies (LHO:71200). As such, they were significantly higher than necessary to maintain an uncertainty of 0.5%. N.B. The threshold itself is rather arbitrary. This is discussed further in LHO:69555.


Moreover, there was evidence that the high SNR lines were causing excess noise (LHO:71149) and repeated on/off tests with and without the calibration lines active showed an improvement when the lines were off (LHO:71296).

The new values, as compared to their old settings set in LHO:69555, are shown below.

Channel                                                             Old Gain            New Gain            Reduction Factor
=================                                     =========        ===========        ===========
H1:SUS-ETMX_L1_CAL_LINE_CLKGAIN          35                   6.6                              5.3
H1:SUS-ETMX_L2_CAL_LINE_CLKGAIN          50                   9                                 5.55
H1:SUS-ETMX_L3_CAL_LINE_CLKGAIN           0.3                 0.085                          3.529


The third attachment shows a short trend of the uncertainty calculations after changing the line amplitudes. They are all hovering between 0.4% and 0.5%. It's worth noting that the IFO was thermalizing during this activity; we had just relocked when I got started.

I didn't have time to visit reducing the amplitude of the PCALY line at 17.1Hz before the end of the allotted commissioning time. 

TITLE: 08/03 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Commissioning
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 8mph Gusts, 5mph 5min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.04 μm/s
QUICK SUMMARY:

H1 just completed getting to NLN (after ADS converged)--post power glitch (thanks for quick recovery, RC!).  During this time, Louis has been working on "shrinking cal lines".  Once he's done, Sheila has a 20min ESD bias test.  Then we can go for OBSERVING.

TITLE: 08/03 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
SHIFT SUMMARY: Some commissioning was done until we lost lock from a power glitch at 20:54. We relocked and have resumed commissioning as of 23:00UTC. Hnading off to COrey

Lock#1:

• We dropped from Observing by mistake at 17:21:51UTC and went back in at 17:23:03UTC.
• We rode through a 5.7 from Alaska at 19:40UTC (9.37 linear velocity)
• We started commissioning work and dropped out of Observing at 20:16UTC starting with Sheila ESD bias test, The new HAM1FF was also turned off.
• Lockloss @ 20:54 from a power glitch, it took out the ETM HEPIs and ISIs, Jim drove down to the Ends to reset the VFD panels and brought back the HEPIs.

Lock#2:

• We started relocking at 21:48 after the HEPIs were back to nominal, Jim ran a quick HAM7 transfer function while we were low in the locking process.
• The violins got a little rung up from the lockloss, the ETMs in particular as expected, so we had to wait in CHECK_VIOLINS for a few minutes.
• All the Picket-Fence seismometers are down? as of 22:50UTC
• Back to NLN at 22:46UTC

LOG:                                                                                                                                           

I started to change the ESD bias and adjust the gain to compensate it.  The goal of this is to see if there is any change to the DARM noise, bicoherence, or coherence with EX power monitors for the full bias, and we were also planning to revisit the excess noise seen at -125V ESD bias back in Feb. 

We lost lock due to a site power glitch, so I'm just recording here the settings to be used to change the ESD bias and keep the DARM OLG and calibration the same. The second set of three references (positive biases) are settings found today, while the negative biases are settings found in Jan (66751), apparently the DARM loop has changed in the meantime. 

To do the test we intended today (get 20 minutes of quiet time at full positive bias), we would do:

• in a guardian terminal (type for example guardian -i ISC_LOCK)

ezca['SUS-ETMX_L3_DRIVEALIGN_L2L_TRAMP'] = 60
ezca['SUS-ETMX_L3_LOCK_BIAS_TRAMP'] = 60

• wait a second

ezca['SUS-ETMX_L3_DRIVEALIGN_L2L_GAIN'] = 47.22
ezca['SUS-ETMX_L3_LOCK_BIAS_GAIN'] = 2.85

• this will ramp the ESD bias up for 60 seconds and compensate the DARM loop.   We'd wait here for 20 minutes to get some time.  Then we'd restore to the nomial configuration by typing:

ezca['SUS-ETMX_L3_DRIVEALIGN_L2L_GAIN'] = 184.65
ezca['SUS-ETMX_L3_LOCK_BIAS_GAIN'] = 1

this will ramp the bias back to it's normal 125V value over 60seconds.  Then we can clear the SDF for the TRAMP:

ezca['SUS-ETMX_L3_DRIVEALIGN_L2L_TRAMP'] = 10
then we should be able to go back to observe.

The lights flickered in the control room then we lost lock, and the ETMs HEPI and ISI watchdogs dripped

0.125 Hz bandwidth: https://ldas-jobs.ligo-wa.caltech.edu/~gabriele.vajente/bruco_STRAIN_1375096943/
0.031 Hz bandwidth: https://ldas-jobs.ligo-wa.caltech.edu/~gabriele.vajente/bruco_STRAIN_1375096943_highres/

Some highlights:

• MICH and SRCL FF could use a retune. Also, the 15.6 Hz peak that is injecting noise in Kappa_UIM line is due to a misplaced sharp feature in the MICH FF (see 71790)
• Unfortunately CHARD_Y is now closer to DARM. This is not a surprise since new filter has higher noise injection. Some of this coherence might be due to HAM1 motion, so maybe it's time to revisit the HAM1 FF to CHARD? Maybe HAM1 is again coupling through CHARD_P, tthat has large coherence with HAM1 motion now.
• DHARD_Y is now showing up with some coherence, so we should keep an eye on it

In summary, the low frequency noise is improved and more stationary with the new CHARD_Y higher gain controller and reduced test mass damping gain in yaw. Also, the glitch rate is largely reduced.

Effect of new CHARD_Y controller

A new controller was designed based on the previous measurement of the CHARD_Y plant. This controller is implemented in FM9 (as an additional module that can be switched on with the other modeles). This can be engaged with the nominal gain of 60, and then the gain can be increased up to a factor 3 to 180. After a few tests I found that a gain of 100 seems ok, higher gain increase the amplification of a 3.4 Hz narrow peak. The amplification is expected due to a broad gain peaking of the new controller. However, the peak itself is already there and not related to the CHARD_Y controller. If we manage to track down the origin of this peak and improve it, we could increase the CHARD_Y gain even more. As it is now, more gain doesn't improve much the CHARD_Y RMS because of this 3.4 Hz peak.

With this new configuration, the CHARD_Y RMS is significantly reduced around 1 Hz (no more gain peaking) and 2-3 Hz (more suppression).

Effect of reducing the test mass damping gain

With the new controller in place, I repeated the old test of reducing the test mass damping gain in yaw. I realized that the 1 Hz oscillation I saw in my previous attempt was due to the CHARD_Y gain peaking at 1 Hz getting worse. the new controller solved this problem. Indeed, I could reduce all test mass damping gains from -1.0 to -0.5 without problems. This improves a bit the CHARD_Y motion, and improves significantly the DHARD_Y motion. So it's a good change to have.

I also tried to reduce the PR3 M1 yaw damping gain, since CHARD_Y was coherent with PR3 damping, but I did not see much of an improvement.

Noise improvements

Those changes were left overnight, and the noise was much better. On average, the DARM noise below a few tens of Hz is lower. The main difference is the disappearence of most of the non-stationay noise, as visible in a spectrogram. Comparing the omicron glitch plots from before and after the change, the number of glitches in the 20-50 Hz region is much lower.

Next steps

I suggest we leave the new CHARD_Y controller with a gain of 100 as the default configuration. I also suggest that we run with reduced test mass yaw damping. I would leave the PR3 damping at -1. I would also keep the current value of -1.50 for ITMY Y2L gain.

Next things to check:

• Compare the CHARD_Y plant with the reduced damping gain with the one with nominal gain. I noticed that the 1 Hz peak is increasing, so there might be a change in the CHARD_Y plant due to the change in damping  gain. This is expected. We might want to re-measure carefully the CHARD_Y and DHARD_Y plants and further improve the controllers with reduced test mass damping.
• Find the origin of the 3.4 Hz peak that would be limiting the CHARD_Y RMS wiht higher gain. Also, maybe worth trying to increase CHARD_Y gain all the way to 180 and see if things are better or worse
• Look into the Y2L decoupling. More details in another alog entry, but it is evident that there are two coupling paths from CHARD_Y to DARM: one with a steep frequency dependency below 20 Hz, and one flat-ish above 20 Hz. Changing ITMY Y2L coefficient changes the two paths in opposite directions

Kappa_UIM has seen a huge increase in noise starting ~8 days ago (screenshot attached). It's not clear to me what is causing this yet.

This is also shown on the summary pages: https://ldas-jobs.ligo-wa.caltech.edu/~detchar/summary/day/20230728/cal/time_varying_factors/

The UIM Kappa line value started to show noisy activity at GPS 1373905226.2881477.