TITLE: 12/08 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Microseism
INCOMING OPERATOR: Oli
SHIFT SUMMARY:

IFO is DOWN due to MICROSEISM/ENVIRONMENT since 22:09 UTC

First 6-7 hrs of shift were very calm and we were in OBSERVING for majority of the time.

• We lost lock during a particularly high gust of wind and as the microseism went beyond 2 um/s and haven't been able to lock since. LL alog 81667.
• Successfully ran through today's planned calibration sweep. alog 81666.

The plan is to stay in DOWN and intermittently try to lock but the last few attempts have resulted in 6 pre-DRMI LLs with 0 DRMI acquisitions. Overall, microseism is just very high.

LOG:                                                                                                                                                                       

TITLE: 12/08 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Microseism
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: SEISMON_ALERT_USEISM
    Wind: 15mph Gusts, 9mph 3min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.78 μm/s
QUICK SUMMARY:

Currently in DOWN and trying to wait out the microseism a bit. Thankfully wind has gone back down

Trying to gather more info about the nature of these M3 SRM WD trips in light of OWL Ops being called (at least twice in recent weeks) to press one button.

• Since 10/16/2024, there have been 10 instances where M3 WD trips during SRC align during initial alignment, which have caused a total loss of 1hr and 49 mins of locking time. While this isn't a lot, the trending WD trips for SRM shows that this is a more recent occurrence.
• Out of the 31 total M3 SRM WD trips since start of O4b (and not counting vent), 12 happened in the last 5 weeks, with 10 of these being during initial alignment (i.e. this type of trip).
• Since the rise of this issue, we have gone through a total of 112 initial alignments, meaning it's occurred in 9% of initial alignments. Doesn't sound like a lot but if guardian has an initial alignment during an OWL shift, this suggests a 1/10 chance of being woken up just to press "untrip".
• Sometimes, M3 is too rung up in this state that untripping takes 20 mins but other times it only takes 1-2 mins.
• FRS Ticket

Relevant Alogs:

Part 1 of this investigation: 81476

Tony OWL Call: alog 81661

TJ OWL Call: alog 81455

TJ OWL Call: alog 81325

It's mentioned in some more OPS alogs but no new info.

Next Steps:

• The possible cause per a last convo with TJ was that guardian thinks that SRC is aligned when actually it is locked to the wrong mode, causing the SRM controls to go awry when re-misaligning during initial alignment - so just rehash that conversation when possible.
• Find out what proportion of initial alignments this has happened to since 10/16.

Lockloss @ 12/07 22:09 UTC. Possibly due to a gust of  wind since at EY it had jumped up from lower 20s to almost 30mph the same minute of the lockloss? A possible contributer could also be the secondary microseism - it has been quickly rising over the last several hours and is now up to 2 um/s.

Calibration sweep done using the usual wiki.

Broadband Start Time: 1417641408

Broadband End Time: 1417641702

Simulines Start Time: 1417641868

Simulines End Time: 1417643246

Files Saved:

2024-12-07 21:47:09,491 | INFO | Commencing data processing.
2024-12-07 21:47:09,491 | 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.
2024-12-07 21:47:46,184 | INFO | File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20241207T212404Z.hdf5
2024-12-07 21:47:46,191 | INFO | File written out to: /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20241207T212404Z.hdf5
2024-12-07 21:47:46,196 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20241207T212404Z.hdf5
2024-12-07 21:47:46,200 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20241207T212404Z.hdf5
2024-12-07 21:47:46,205 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20241207T212404Z.hdf5
ICE default IO error handler doing an exit(), pid = 2104592, errno = 32
PST: 2024-12-07 13:47:46.270025 PST
UTC: 2024-12-07 21:47:46.270025 UTC
GPS: 1417643284.270025

Sat Dec 07 10:09:18 2024 INFO: Fill completed in 9min 15secs

TITLE: 12/07 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 157Mpc
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 6mph Gusts, 2mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.44 μm/s
QUICK SUMMARY:

IFO is in NLN and OBSERVING as of 11:47 UTC (4 hrs)

There was one lockloss last night and a known issue where SUS SRM WD trips during initial alignment. OWL was called (alog 81661) to untrip it.

TITLE: 12/07 Owl Shift: 0600-1530 UTC (2200-0730 PST), all times posted in UTC
STATE of H1: Aligning
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 9mph Gusts, 5mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.28 μm/s
QUICK SUMMARY:

IFO stuck in initial alignment because SRM watchdog H1:SUS-SRM_M3_WDMON_STATE trip.
Watch dog tripped while we were in Initial alignmnet not before, and was not due to ground motion.

I logged in discovered the trip. Reset the watchdog and reselected myself for Remote OWL notifications.
 

TITLE: 12/07 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 158Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Currently Observing at 160 Mpc and have been Locked for 16.5 hours. Quiet shift where nothing happened and we were just Observing the entire time.
LOG:

00:30 Observing and have been Locked for 11 hours

Currently observing at 155 Mpc and have been Locked for 14.5 hours. Quiet evening with nothing to report

J. Freed, 

Update on Double Mixer Progress 81593, Proceded through step 2a of the double mixer test plan T2400327. Initial results are sugesting a possible noise improvemnt compaired to the other options in the area of interest for SPI.

DM_PN1.pdf Shows the phase noise test run in step 2a of the Double Mixer Test plan. While not a true 1-to-1 comparison of the phase noise performance of the double mixer compered to other options (step 2b is for that), it shows that adding the double mixer into this system (except for the peaks) improves phase noise performance by a factor of 2-5 from 100 Hz to 20 kHz. Of note, there is a large peak are centered around the 4096 Hz that is of interest to SPI. As there was only a cursory attept to properly phase match the signals in the internals of the double mixer for this initial test, the 4096 Hz sideband was not properly removed. 

A possible cause of this phase miss match is our phase delayer inside the double mixer (ZMSCQ-2-90B) causes a phase delay of about 89.82 degrees at 80MHz and not the 90 degrees we are expecting.

Possible fixes

• Try noodling the digital phases of the 4096 Hz Sin and Cos to see if that makes a difference
• In analog, replace 90 deg splitter with normal splitter and try to create the 90 phase shift in a different way
  • A 90 deg phase delay component tuned specifically for 80 MHz
  • A high-pass filter / low-pass / band-pass filter that has 90 deg phase at 80 MHz.
  • Create a tunable phase shifter.

The very low frequency (<0.05Hz) contains DC noise caused by the external phase mismatch of the double mixer and the reference source for the phase noise measurments. It is not an indication of double mixer drift and there has not been yet investigations in drift.

TITLE: 12/07 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 158Mpc
INCOMING OPERATOR: Oli
SHIFT SUMMARY:

IFO is in NLN and OBSERVING as of 14:14 UTC (11 hr lock).

Of note:

• SQZ dropped us out of OBSERVING and relocked automatically
• During the drop, we took the time to reinstate some of the cleared SDFs that Tony accepted, and then accepted those. All-in-all, I reloaded ALS_XARM, ALS_YARM and ISC_LOCK guardians. We also made the changes in the SDF screenshotted below.
• Hanford authorities informed Tyler (who informed me) that they will be conducting their military loud exercises. Robert confirmed that these would not hurt our observing data.

LOG:                                                                                                                                                                                                                                   

TITLE: 12/07 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 160Mpc
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 6mph Gusts, 4mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.23 μm/s
QUICK SUMMARY:

We're Observing and have been Locked for 11 hours. Winds are low and secondary microseism is not too bad.

Closes FAMIS#26345, last checked 81548

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

Outbuilding Fans (attachment2)
- MY FAN1 accelerometer 1 has become a little more chaotic looking the past three days, but is still well within range. All other fans are looking normal and are within range.

The way that I used to run bruco didn't work for me today.  With help from Elenna and Camilla I was able to run it, so here is what I did:

ssh into ssh.ligo.org, select 4 for LHO cluster and c for ldas.pcdev1

made a fresh clone of https://git.ligo.org/gabriele-vajente/bruco in a directory called new_bruco

cd /home/sheila.dwyer/new_bruco/bruco

python -m bruco --ifo=H1 --channel=GDS-CALIB_STRAIN_CLEAN --gpsb=1417500178 --length=400 --outfs=4096 --fres=0.1 --dir=/home/sheila.dwyer/public_html/brucos/GDS_1417500178 --top=100 --webtop=20 --plot=html --nproc=20 --xlim=7:2000 --excluded=share/lho_excluded_channels_O4.txt

The bruco now appears at: https://ldas-jobs.ligo-wa.caltech.edu/~sheila.dwyer/brucos/GDS_1417500178/

This is for a quiet time overnight last night.

Input jitter does have a contribution, as Robert suspected based on looking at the DARM spectrum.  Jenne looked at cleaning, and plans to try out a new cleaning during Monday's commissoning window.

Note to Operators: During the CP1 fill (which starts daily at 10am) the CDS ALARM system shows RED because the LN2 Liquid Level Control Valve (LLCV) is ramped up to 100% open. The alarm system puts this channel into alarm when its value exceeds 50%. This alarm should clear within 1 minute of the end of the fill.

TITLE: 12/06 Owl Shift: 0600-1530 UTC (2200-0730 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY:
LOG:
H1 called me to help with SDF issues.
SUS ETMX and ITMX SDFs

These seemed like they were changed randomly in the night but also seemed like that may have unlocked the IFO if reverted so I accepted them.
But now that i'm looking back at Francisco's Alog I think some may have been intentional.
 

More than 1 IFO H1 call tonight:
H1 Called me earlier in the night and I slept though the calls because I did not realise my phone was not properly set up for this owl shift before I went to sleep.
 

Ansel reported that a peak in DARM that interfered with the sensitivity of the Crab pulsar followed a similar time frequency path as a peak in the beam splitter microphone signal. I found that this was also the case on a shorter time scale and took advantage of the long down times last weekend to use  a movable microphone to find the source of the peak. Microphone signals don’t usually show coherence with DARM even when they are causing noise, probably because the coherence length of the sound is smaller than the spacing between the coupling sites and the microphones, hence the importance of precise time-frequency paths.

Figure 1 shows DARM and the problematic peak in microphone signals. The second page of Figure 1 shows the portable microphone signal at a location by the staging building and a location near the TCS chillers. I used accelerometers to confirm the microphone identification of the TCS chillers, and to distinguish between the two chillers (Figure 2).

I was surprised that the acoustic signal was so strong that I could see it at the staging building - when I found the signal outside, I assumed it was coming from some external HVAC component and spent quite a bit of time searching outside. I think that this may be because the suspended mezzanine (see photos on second page of Figure 2) acts as a sort of soundboard, helping couple the chiller vibrations to the air. 

Any direct vibrational coupling can be solved by vibrationally isolating the chillers. This may even help with acoustic coupling if the soundboard theory is correct. We might try this first. However, the safest solution is to either try to change the load to move the peaks to a different frequency, or put the chillers on vibration isolation in the hallway of the cinder-block HVAC housing so that the stiff room blocks the low-frequency sound. 

Reducing the coupling is another mitigation route. Vibrational coupling has apparently increased, so I think we should check jitter coupling at the DCPDs in case recent damage has made them more sensitive to beam spot position.

For next generation detectors, it might be a good idea to make the mechanical room of cinder blocks or equivalent to reduce acoustic coupling of the low frequency sources.