I prepared a new filter module with resonant gains at 2.8 Hz and 3.4 Hz. This can be tried tomorrow (on during some commissioning time) to reduce the DARM RMS and see if it helps the non-stationary noise.

The new FM is loaded into DARM2 FM1 "RG2.8-3.4". It is not engaged now.

For future reference, here are the FMs that are used during lock acquisition:

DARM1: FM1 FM2 FM3 FM4 FM7 FM9 FM10

DARM2: FM3 FM4 FM5 FM6 FM7 FM8 FM9 FM10

leaving DARM1 FM5,6,8 and DARM2 FM1,2 unused

I have made alterations to the signal path for the 80.3 kHz PI ("MODE28").

In the PLL block I have made all the requisite changes to exactly replicate my LLO implementation.
This should get applied to all PLLs, but in the interest of not making changes to signal paths that LHO currectly depends on to stay locked, I don't want to change other MODE's feedback settings.

I have altered the H1:SUS-ETMX_PI_UPCONV_UC3_SIG bank's bandpass filter, to steeply roll off.
This is motivated by the work in this LLO aLog. I have implemented the exact same filters here.
Again, I only make this change in the signal flow of MODE28, so as not to perturb other already functioning, and depended upon, systems.

Vlad, Naoki

Yesterday I observed PI MODE24 ring up a large number of occasions. This was caused because the PI Guardian was falsely perceiving that the amplitude of PI was rising, inferred that the phase was "bad" and changed the phase to an actually bad phase.

In the time it took to finally find the "good" phase again, the amplitude rang up, and the saving grace was actually the hard-coded limit on the PLL outputs (which I am re-implementing to be soft-coded), which meant that while the PI phase was slewing from bad to terrible and back to good, the actuation was not exponentially increasing.
I have increased the RMS threshold for which the guardian will infer that the mode is "going up" from 3->4.

Another issue is that the first time this triggers for any mode, it reads out the RMS in the last 5 seconds and considers whether that is larger than the last time it makes that check. But the these "last times" had an initialisation value of 0: so it would always change the phase (to a now "bad" one).
The fix for this we think is to initialise these thresholds to the triggering thresholds for each of the modes being damped. This will at least prevent the guaranteed change on the first trigger.

Dust monitor pumps are running smoothly.

Fil, Daniel

We installed a common mode board, a dual demodulator chassis and replaced the single delay line phase shifter with a dual. This delay line is used by the filter cavity green locking. We also installed the new feedthrough panels on SQZT0.

WP #11489, and #11492 (not marked as Tuesday Maintinence as LHO apparently doesn't track that).

I have altered the h1susprocpi model in the follownig ways:

• Removed hard-coded amplitude limit of 10 (and the addition of a pre-limit amplitude offset and a post-limit amplitude offset)
• Added a filter bank AMP_FINAL in its place. This will serve as the output signal filtering/offsetting/limiting.
• Restored the PLL_SEL_MTRX size to 3 and reinstated the option to bypass PLL completely, linked to the input to the PLL blocks. Now you can use raw signals in the damping loop once again if you are having difficulties with the PLL locking.

These changes affected libraries:

• PLL_MASTER/PLL (first 2 changes)
• PI_MASTER_V2/PLL_BY_MODE (last change)

Changes will come in when the model is restarted on the h1oaf0 and the DAQ is restarted, as the new filter block adds channels.

As per WP 11488 the opslogin system was turned off.  This was an older Debian 9 system that was kept around when we transitioned to Debian 10+ in case we needed access to older tools.  At this point the system is not being used and causes confusion when people login onto opslogin instead of opslogin0 (the current system to use).

The band limited RMS (BLRMS) (H1:OMC-BLRMS_32_BAND#_BP for #={1 to 7}) bands that monitor DARM (Actually OMC DCPD A) frequencies in the range 2.5 kHz through to 32 kHz were being used in the lockloss monitoring tools to assess if a lockloss was due to PI.

These were not working correctly, so I poked my head in this morning.

The BLRMS used Elliptical filters, which have a flat response down the DC, and we were seeing a large DC value in the outputs that was "saturating" any high frequency signal we might care about.

These BLRMS have been altered to use Butterworth filters instead of Elliptical. Butterworth filters have the highly valuable property of actually being AC coupled so that should do the trick.

The alog was rebooted as part of regular maintenance.  This is a test of the system.

At 15:02:30UTC I turned up annular CO2X and CO2X from 1.7W in to ~4W in to see the alignment of the beams, see attached CO2 and compared to IFO beams. The alignment doesn't look bad but we should overlay the images to check. Looked at cold CO2 alignment in 73553.

I turned the CO2s off from 15:07 to 15:09UTC and swapped the masks over, IFO didn't glitch as it did in 73357. We can conclude the glitches were caused by the CO2 beam being quickly blocked rather than any electronics issue.

As in 73357, our DARM high frequency noise changed, plot. Increased with more annular CO2 and then decreased, purple 4.6kHz trace in plot attached, the decrease was more likely due to the TJ's 73683 CARM gain changes than the time with no CO2s.

IFO was in observing when I started (whoops) so we should have been in commissioning 15:02:30UTC to 15:05:00 (Tagging Detchar). I've monitored H1:TCS-ITM{X,Y}_CO2_LASERPOWER_POWER_REQUEST in observe.snap so this doesn't happen again.

This morning I remotely tweaked the beam alignment into the PMC.  With the ISS OFF (note, the diffracted power % was ~3.1%, a little high, so I adjusted this later), I started with PMC Trans of ~108.8 W and PMC Refl of ~16.1 W.  Using the picomotor-controlled mounts I tweaked the alignment to max the PMC Trans and minimize PMC Refl.  Once done, still with the ISS OFF, we now have a PMC Trans of ~109.0 W and a PMC Refl of ~15.7 W.  I turned the ISS back ON and, seeing the higher than normal diffracted power % noted earlier, I adjusted the ISS RefSignal to get the diffracted power % back to ~2.5%; this necessitated a RefSignal change from -1.97 V to -1.99 V.  With the ISS ON we now have a PMC Trans of ~109.4 W and a PMC Refl of ~15.7 W (moving between 15.7 W and 15.8 W).

While I was hoping for move improvement in PMC Trans and Refl, I was only expecting the small change I was able to achieve.  To my mind this means it's getting close to time to adjust the operating currents of the amplifier pump diodes.  Will continue to monitor.

Following instructions from Sheila, I stepped the CARM gains (H1:LSC-REFL_SERVO_IN{1, 2}GAIN) by 1 about every minute starting at 15:11:30 UTC. I started at a gain of 8 and we lost lock as soon as I got to 20. We lost lock at 15:24 UTC.

TITLE: 10/24 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 158Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 8mph Gusts, 7mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.20 μm/s
QUICK SUMMARY:

Have been Locked for  28.5 hours. SUS Charge measurements finished and Camilla is blasting the CO2s. Long maintenance day today.

Workstations updated and rebooted.  This was an update to OS packages.  Coinda packages were not changed.

TITLE: 10/23 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 165Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY:

H1 continues with a lock approaching 20.5hrs.  Winds have died down since "lunch".
LOG:

• ~0045-0024 PCal Lab work (Tony)
• (2) EQ triggered EARTHQUAKE Mode, but H1 rode through.

H1's running on a 16.5hr lock and range around 165Mpc.  Rode through a M4.6 Tongan earthquake and now the chilly breezes are picking up (with gusts peaking above 30mph recently).

Below are the steps for a (failed) attempt at running a broadband + simmulines calibration mesaurement w/ H1 was locked for 3+hrs and with L1 still in recovery from a power outtage:

• Following instructions (link)
• Screenshot of Cailbratoin Monitor medm taken (see attached)
• 2332 Out of OBSERVING and ISC LOCK to NLN_CAL_MEAS
• 2333 in a terminal started broadband calibration meas: pydarm measure --run-headless bb
  • 2339 this ended with:  ICE default IO error handler doing an exit(), pid = 99711, errno = 32
  • (Listing last few lines from this measurement below)
• 2340 Assuming this was the "end" of the broadband measurement, so I next ran simmulines measurement (in same terminal, per instructions):  gpstime;python /ligo/groups/cal/src/simulines/simulines/simuLines.py -i /ligo/groups/cal/src/simulines/simulines/settings_h1.ini;gpstime 
  • This had a similar error after 2-min.  Here are the last few lines from the terminal:

2023-10-22 23:42:28,941 | INFO | Drive, on L3_SUSETMX_iEXC2DARMTF, at frequency: 544.99, is now running for 23 seconds.
2023-10-22 23:42:35,388 | INFO | Drive, on PCALY2DARMTF, at frequency: 8.69, is finished. GPS start and end time stamps: 1382053346, 1382053370
2023-10-22 23:42:35,389 | INFO | Scanning frequency 8.99 in Scan : PCALY2DARMTF on PID: 106437
2023-10-22 23:42:35,389 | INFO | Drive, on PCALY2DARMTF, at frequency: 8.99, is now running for 31 seconds.
^C2023-10-22 23:42:40,347 | ERROR | Ramping Down Excitation on channel H1:SUS-ETMX_L1_CAL_EXC
2023-10-22 23:42:40,347 | ERROR | Ramping Down Excitation on channel H1:SUS-ETMX_L3_CAL_EXC
2023-10-22 23:42:40,347 | ERROR | Ramping Down Excitation on channel H1:SUS-ETMX_L2_CAL_EXC
2023-10-22 23:42:40,347 | INFO | Ending lockloss monitor. This is either due to having completed the measurement, and this functionality being terminated; or because the whole process was aborted.
2023-10-22 23:42:40,348 | ERROR | Ramping Down Excitation on channel H1:LSC-DARM1_EXC
2023-10-22 23:42:40,348 | ERROR | Aborting main thread and Data recording, if any. Cleaning up temporary file structure.
2023-10-22 23:42:40,348 | ERROR | Ramping Down Excitation on channel H1:CAL-PCALY_SWEPT_SINE_EXC
ICE default IO error handler doing an exit(), pid = 106373, errno = 32
PDT: 2023-10-22 16:42:44.751376 PDT
UTC: 2023-10-22 23:42:44.751376 UTC
GPS: 1382053382.751376

• 2351 After ligo.chat with Jenne, decided to stop Calibration Measurements (she mentioned possibly the dolphin crash from Fri night could be a possible culprit?)
• 2351 OBSERVING (and I restored H1 Manager to MANAGED)

Here were the last few lines at the end of the broadband measurement:

notification: new test result
notification: new test result
notification: new test result
notification: end of measurement
notification: end of test
diag> save /ligo/groups/cal/H1/measurements/PCALY2DARM_BB/PCALY2DARM_BB_20231022T233325Z.xml
/ligo/groups/cal/H1/measurements/PCALY2DARM_BB/PCALY2DARM_BB_20231022T233325Z.xml saved
diag> quit
EXIT KERNEL

INFO | bb measurement complete.
INFO | bb output: /ligo/groups/cal/H1/measurements/PCALY2DARM_BB/PCALY2DARM_BB_20231022T233325Z.xml
INFO | all measurements complete.
ICE default IO error handler doing an exit(), pid = 99711, errno = 32

Using two periods of quiet time during the last couple of days (1381575618 + 3600s, 1381550418 + 3600s) I computed the usual coherences:

https://ldas-jobs.ligo-wa.caltech.edu/~gabriele.vajente/bruco_STRAIN_1381550418/
https://ldas-jobs.ligo-wa.caltech.edu/~gabriele.vajente/bruco_STRAIN_1381575618/

The most interesting observation is that, for the first time as far as I can remember, there is no coherence above threshold with any channels for wide bands in the low frequency range, notably between 20 and 30 Hz, and also for many bands above 50 Hz. I'll assume for now that most of the noise above ~50 Hz is explained by thermal noise and quantum noise, and focus on the low frequency range (<50 Hz).

Looking at the PSDs for the two hour-long times, the noise belowe 50 Hz seems to be quite repeatable, and follows closely a 1/f^4 slope. Looking at a spectrogram (especially when whitened with the median), one can see that there is still some non-stationary noise, although not very large. So it seems to me that the noise below ~50 Hz is made up o some stationary 1/f^4 unknown noise (not coherent with any of the 4000+ auxiliary channels we record) and some non-stationary noise. This is not hard evidence, but an interesting observation.

Concerning the non-stationary noise, I think there is evidence that it's correlated with the DARM low frequency RMS. I computed the GDS-CALIB RMS between 20 and 50 Hz (whitened to the median to weight equally the frequency bins even though the PSD has a steep slope), and the LSC_DARM_IN1 RMS between 2.5 and 3.5 Hz (I tried a few different bands and this is the best). There is a clear correlation between the two RMS, as shown in a scatter plot, where every dot is the RMS computed over 5 seconds of data, using a spectrogram.

I turned up CO2X 15:05 to 15:12 UTC to see if we could put noise into DARM, plot attached.

• Yellow - Nominal CO2 settings, CO2X and CO2Y 1.7W Annular @ 15:02:00 (after SUS_CHARGE stopped)
• Blue - CO2X Annular 6.6W in @ 15:05:45UTC
  • High frequency noise higher, not sure this is physical, only expect low frequency noise. 
• Red - CO2X No Mask 13.7W in @ 15:08:55
  • Lines appear at 20Hz, 28.5Hz, 32.5Hz, more low frequency noise. 
• Back to nominal @ 15:12:00 UTC
  • 20Hz, 28.5Hz, 32.5Hz lines stay and start reducing
  • Lower high frequency noise! DARM plot attached and HOM. We are trying to reduce high frequency noise using ring heaters in 73308.

We got DARM glitches when raised and lowered the annular mask, see t-cursors attached. This is surprising. We should check that this is from the CO2 laser being blocked while the mask  (on a flipper mount) passes through the beam, rather than any electronics issue. Can do this by turning off CO2 laser and then raising and lowering the mask. 

Still want to redo 72981 line driving once we understand which PD to use for readback.