I stole the filter that Huyen used for her HAM1 feedforward test, and tried it on the LHO HAM1, with a gain tweak of 17% (ie I multiplied by a gain of 1.17 vs LLO ) to match my measurements and it seems to work well. I was having difficulty with my hand fits with excess low frequency noise or gain peaking where I tried to roll my filters off.  First plot shows the on/ off asds for the HAM2 sts and the HAM1 Z HEPI l4cs. I don't know if I quite believe the improvement below 1 hz is due to the feedforward, but Huyen said she got improvement kind of 1-70hz and that seems to be the case here as well. I'm leaving this filter on overnight, to get good low frequency data.

Second image compares one of my filters(red) with the (green) LLO filter. One thing I still don't understand is that my filters have often caused broad low frequency noise, but the LLO filter doesn't seem to. We don't currently have a noise model for HEPI that allows modeling the ff performance, that would help a lot.

I ran a calibration measurement at the behest of Louis this afternoon, starting with the broadband:

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

Then the simulines:

GPS start: 1376862014.581911

GPS end: 1376863342.763444

2023-08-23 22:02:04,350 | INFO | File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20230823T213958Z.hdf5
2023-08-23 22:02:04,374 | INFO | File written out to: /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20230823T213958Z.hdf5
2023-08-23 22:02:04,387 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20230823T213958Z.hdf5
2023-08-23 22:02:04,402 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20230823T213958Z.hdf5
2023-08-23 22:02:04,417 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20230823T213958Z.hdf5

Wed Aug 23 10:11:14 2023 INFO: Fill completed in 11min 10secs

DCPD saturation then lockloss

TITLE: 08/23 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 147Mpc
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: SEISMON_ALERT
    Wind: 3mph Gusts, 2mph 5min avg
    Primary useism: 0.07 μm/s
    Secondary useism: 0.18 μm/s
QUICK SUMMARY:

• We've been locked for 17:35, In observing since 08:43, we dropped out for a minute at 08:42 from the previous segment starting at 21:45UTC on the 22nd
• CDS/Dust/SEI/SUS/VAC looks good
• We're riding through a 6.2 EQ from Argentina

TITLE: 08/23 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 150Mpc
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY: Uneventful and quiet night. Detector in Observing and Locked for 9hrs 40mins. Dust is finally settling down in the PSL, and our range is creeping back up as compared to the start of my shift.

23:00UTC Start of shift - detector in Observing and Locked for 1.5 hours

23:03 Superevent S230822bm

LOG:

Previously done in 72264

Closes FAMIS#25080

No In-Lock SUS Charge measurements were made this morning due to the SUS_CHARGE Guardian having been in the DOWN state since last Tuesday 8/15 15:29UTC. TJ had fixed up some errors in the SUS_CHARGE code (72219) and had placed it in DOWN for Tuesday Maintainance but had forgotten it there.

At 3:56UTC I put the Guardian back into the correct WAITING state by selecting INJECTIONS_COMPLETE, as done in 71067.

We are still in Observing and have been Locked for 5hrs 40mins now.

All the dust monitors that have had high dust counts from Tuesday Maintainance are going down, with the exception of both the >300um and >500um counts in the PSL Laser Room, of which the >300um counts is at the second highest it's been in 7ish years (highest it's been in the last ~7 years was two weeks ago). This rise in dust looks like it could be related to the wind at the corner station, so I'll keep an eye on it and hopefully it'll come down as the wind dies down.

TITLE: 08/22 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 141Mpc
INCOMING OPERATOR: Oli
SHIFT SUMMARY:

• We tried to hold the lock through some of the maintenance activities but we had to unlock at 15:46 in order for the PCAL team to get a good measurement.
• EX VAC pressure red alarm at 16:55UTC, H0:VAC-EX_X2_PT524B_PRESS_TORR
• PSL anteroom dust counts have remained high, EX and Optics lab dust alarms off and on throughout the afternoon.

Lock#1:

Yarm locked at a low power (~75%, lower power than XARm) and oscillating, no flashes at DRMI or PRMI, CHECK_MICH lockloss. There was a few more LL at FIND_IR and LOCKING ALS so I did an Initial Alignment, which went well untill we got to SRC where it tried for a while then eventually gave me a message "find by hand" where I tapped on SRM in Pitch maybe 10 microradians to maximize the signal and it was enough to push it onwords and finish IA.

Yarm looked better after the IA but was still oscillating, during these troubles the Norco liquid nitrogen truck was filling CP1 but we weren't seeing any extra motion on the CS accelerometers that we looked at.

Reached NLN at 21:25UTC, I had some sus SDF diffs pop up, they were all TRAMPs so I accepted them on SUSTMSX & SUSETMX. The 102Hz peak was noticable at the start of the lock.

In Observing at 21:45UTC, our range is lower now this lock

LOG:                                                                            

TITLE: 08/22 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 139Mpc
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 23mph Gusts, 19mph 5min avg
    Primary useism: 0.09 μm/s
    Secondary useism: 0.11 μm/s
QUICK SUMMARY:

Detector is in Observing and has been Locked for an hour and a half. Decently windy outside.

WP11361 TW1 raw minute trend file offload

Jonathan, Dave:

Last week the files were copied from the almost full SSD on h1daqtw1 to archive spinning media on h1ldasgw1. This morning I completed the transfer by reconfiguring nds1 to use the archive location, and then deleted the files from h1daqtw1's SSD RAID, reducing its usage from 97% to 4%. Jonathan made the nds1 configuration change permanent in puppet.

cdslogin reboot

Jonathan, Dave:

Jonathan rebooted cdslogin at 13:48. The CDS alarm and alert systems came back online with no problems.

WP 11383
alog 66730

Cable clean-up of the VMON channels for monitoring the ESD 18V and 48V power lines. Signals tied to the power lines through BNC bulkheads on the junction box (top of rack). Voltage divider boxes are installed in series. Signal routed through PEM test panel to AA chassis. See attached pictures. Will work with PEM group to see how we want to isolate the divider boxes and route cables.

While Ryan and I were testing out some ALS crystal frequency code, we noticed that if an ALS arm node goes into the Increase_Flashes state, it won't leave even if there are faults. I think I remember not putting in our usual fault checking decorators here because we want to make sure that we restore the offsets before leaving the state, and not just jump straight to the Fault state.

I ended up adding the general fault decorator the main method, since this will be before we set any of the offsets. I then just added a conditional in run to look for faults and then notify and wait. I chose to just wait rather than restore and then jump to Fault because the Beckhoff automation will often fix itself after some time and we don't want to be jumping in and out of this state. If we don't ever get out of this state, then IFO_NOTIFY will alert an operator and they can then intervene. This has been loaded into both ALS nodes.

WP 11349

Spare port on the CPS Fanout Chassis (SUS-R3) was used to synchronize the HAM7 CPS field chassis. Field cable was terminated with 100 ohm resistors across pins 1&6, 2&7. Temporary timing cable from HAM5 field box was disconnected.

Maintenance activities have finished and we are going to start relocking and do a quick ALS automation code test while relocking green arms.

Both Jeff and Stuart Aston separately noticed that the quad R0 alignment offsets are not engaged or disengaged via the guardian. This seems like an oversight and has created a bit of confusion (LLO FRS27877). I've added to the engage_align_offsets to also switch R0 offsets if R0 is present in the levels() list. I tested this out on a quad (ETMY) and a non-quad (PRM), both worked as expected.

def engage_align_offsets(onoff):
+    stages = [susobj.levels()[0]]
+    # Do R0 at the same time for quads
+    if 'R0' in susobj.levels():
+        stages += ['R0']
    log('Ramping ALIGNMENT offsets %s' % (onoff))
-    susobj.alignOffsetSwitchWrite(onoff, levels=[susobj.levels()[0]])
+    susobj.alignOffsetSwitchWrite(onoff, levels=stages)

I reloaded all suspension nodes and committed this change to the svn. I'll pass this on to Stuart to do at LLO when they get the chance.

Naoki and I unmonitored  H1:SQZ-FIBR_SERVO_COMGAIN and H1:SQZ-FIBR_SERVO_FASTGAIN from syscssqz observe.snap. They have been regularly  taking us out of observing (72171) by changing when the TTFSS isn't really unlocking, see 71652. If the TTFSS really unlocks there will be other sdf diffs and the sqz guardians will unlock. 

We still plan to investigate this further tomorrow. We can monitor if it keeps happening using the channels.