Since the A2L script that measures a transfer function isn't quite minimizing our ASC noise in DARM, Sheila suggested re-finding the old A2L script that we used to use, which just looks at the height of the peak in DARM.

I think I've found it, in /opt/rtcds/userapps/release/isc/common/scripts/decoup/al2_min_LHO.py .  I made sure that it, and other scripts in that directory, were checked in to svn (they were last modified somewhere between 2018 and 2019, depending on the script).

The script (as wrtitten) uses the ADS to actuate each of the quads, and uses the demods to find the size of the signal (it does a sum of the squares of the I and Q of the demodulated signal).  The script just guess-and-checks several A2L gain values for each optic, makes a step, and checks again.  Once it's finished, it does a linear fit to find the A2L value at which the peak height is expected to be zero.  The script runs 8 dither lines (pit and yaw from each quad) around 20 Hz, so that it can do this guess-and-check for all the optics at the same time. 

The values in the script are out of date (we've slightly modified the frequencies we use for ADS while locking), so those values and the filter numbers for the matching bandpasses need to be checked.  Also, the excitation amplitude in the script is probably higher than we need (they are set to be 300 counts, but we use 30 counts at full power right now, but we may want a little better SNR so we might want to find a value that is between those two.

Also, we may find that we want to instead do the optics one at a time, at 30 Hz, where the coupling of ASC to DARM is more important to our range.

We can try this out during one of our commissioning windows later this week, to see how it goes.

TITLE: 05/07 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 147Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY: Lighter maintenance today but we managed to do some more SR3/2 moving to investigate our recent required alignment shift. On the relock we had some lock losses that had to be fixed with some filter changes (alog77698). Violins have also come up during these relocks, but they are damping nicely. We are now observing for almost an hour.
LOG:

2240 Observing                                                                                              

Jenne D, Ryan S, Camilla C, TJ S

Today in a single bounce 10W configuration we set SR2 to center AS_C with the SRC2 ASC loops via the ALIGN_IFO guardian in the SR2_ALIGN state, then moved SR3 in steps to see how our AS_C power would change in different positions. We found that there is an area, or spot, that we lose significant throughput to AS_C, but moving around this spot in any direction recovers our nominal single bounce power. This is followup from Jenne Driggers SR3/2 move (alog77388) to bring back our power at the AS port on April 24th, and Jennie Wright, Minhyo, and Sheila's efforts searching in yaw to find where we are losing the power (alog77513). This time we went further than Jennie W and team went and managed to get back almost all of the AS_C sum back. Almost all because just before we got there we starting running into a different, perhaps clipping, issue that changed the shape of the AS air camera in a much different way than when around this spot.

More details:

We started out by reverting the alignment to a time during DRMI locking from the Tuesday morning of April 23. We then brought up tried to move SR2 and SR3 as was done previously, then Jenne suggested that we turn on SRC2 to have SR2 follow our SR3 moves and keep AS_C centered. This worked great along with a little extra SRC2 gain to help move things along faster. Moving in pitch in either direction yielded fairly quick power gains (trends SR3 -P move & SR3 +P move). Jenne suggested that we try to go further in yaw than the Jennie W. team did to see if it ever improves, and we were able to get AS_C almost back after ~550urad in SR3 (trend SR3 -Y move today, and SR3 +Y move April 24 ). If I had the time I'd love to make a nice graphic to show where we can't go but we'll have to deal with this table for now.

TITLE: 05/07 Eve Shift: 23:00-08:00 UTC (16:00-01:00 PST), all times posted in UTC
STATE of H1: Observing at 66Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 16mph Gusts, 12mph 5min avg
    Primary useism: 0.08 μm/s
    Secondary useism: 0.22 μm/s
QUICK SUMMARY:

TJ has H1 back to observing w/ a range just under 150Mpc and passed on some changes to keep an eye on for next-locks.  Will also keep an eye on the rung up violins we have been dealing with the last few days. 

It's a bit breezy, with gusts just touching 25mph (so hopefully not an issue).  useism has slowly been ramping up from the 50th percentile for the last ~18hrs.

Maintenance recovered, back to Observing at 2240 UTC.

We struggled with a handful of lock losses at inconsistent spots and two lock losses just after Transition_from_ETMX. Jenne and Ryan S tracked this down to some changes made yesterday and changed a filter (alog77698), then we made it through one time. Unsure if this will be ok net relock or if it will interfere with locking though.

As a part of an effort to better streamline the FIND_IR step in the lock acquisition process, I put together a quick histogram of the DIFF offsets that have successfully locked DIFF IR since the start of O4b (April 10th). Clearly, there are two main regions where the offset needs to be in order to lock DIFF IR, so it may be beneficial to change how the IR search works to start by doing a narrow scan around these two regions, then expanding the search from there if need be.

I may expand this to also check the values from O4a and the COMM IR offsets if we find that useful.

Sheila asked a good question the other day of, Did SR2 alignment change between the beginning of O4b (when things were still good) and when we had the bad losses through the OFI (when things were bad, before the big shift).  The answer: no, I don't think SR2 moved very much (according to its top mass osems) when the the losses through the OFI showed up. It did move about 10 urad in yaw (see table below), which I plan to look into further.

I looked at several times throughout the last few weeks when ALIGN_IFO guardian had just finished up state 58, SR2_ALIGN at 10 W, which it now does every time initial alignment is automatically run.  These should all be single bounce off of ITMY, with the beam centered on AS_C by adjusting the SR2 sliders, for some given SR3 slider position (nothing automatic touches the SR3 sliders). 

In the table, I summarize the SR3 and SR2 top mass osems.  I've got 3 categories of times for the IFO situation:

• (1) Well before the large losses in the output arm,
• (2) With big losses in the output arm, but SR3 in its old position, and
• (3) After SR3 and SR2 moved to steer around the bad spot in the OFI (just for comparison).

Note that this table is not chronological, since I've grouped rows by IFO situation rather than time.  The SR2 and SR3 osem values that are in bold are the ones to compare amongst each other.  There does seem to be a 10 urad shift in SR2 yaw between the April 21st and April 23rd times.  There are no other run-throughs of the SR2_ALIGN state of ALIGN_IFO between these times to check.  This SR2 yaw shift (which is consistent even when we revert sliders to the 'pre shift' values and run SR2_ALIGN) is notable, but not nearly as large as what we ended up using for steering around the spot in the OFI.

DriptaB, RickS, FranciscoL

On Tuesday, May 7, we changed the following EPICS variables:

H1:CAL-PCALX_XY_COMPARE_CORR_FACT from 0.9979 to 0.9991
H1:CAL-PCALY_XY_COMPARE_CORR_FACT from 1.0013 to 1.0005

Which corresponds to a change of 0.12% for X-End and -0.08% for Y-End in the calibration of the fiduciail displacement factors.

The reason we changed these factors is due to an error in our previous calculation, see alog 77386, which led to a value that was 0.20% off from what we expected.

We will evaluate our changes once the interferometer acquires lock.

Functionality test was done on the corner station turbo pumps, see notes below:

Output mode cleaner tube turbo station;
     Scroll pump hours: 5904.7
     Turbo pump hours: 5966
     Crash bearing life is at 100%

X beam manifold turbo station;
     Scroll pump hours: 1948.0
     Turbo pump hours: 1952
     Crash bearing life is at 100%

Y beam manifold turbo station;
     Scroll pump hours: 2280.8
     Turbo pump hours: 953
     Crash bearing life is at 100%

FAMIS tasks 23530, 23602 and 23650.

WP 11846

Repaired Laser Locking Fiber Beat Note Chassis installed in SQZT0. Unit was uninstalled and repaired, see alog 77418. Removed unit S2300259 is a working unit, part of H1 spares.

Installed Chassis S2300258
Removed Chassis S2300259

F. Clara, C. Compton

DriptaB, RickS, FranciscoL

On Tuesday, May 7, we turned off the pcal excitations for both end stations for a duration of 30 minutes. We want to record a timeseries of the laser power without any excitations.

GPS times:

Start - 1399131000
End - 1399132800

The channels that were *manually* turned off (and on) are:

H1:CAL-PCALX_SWEPT_SINE_ON
H1:CAL-PCALY_SWEPT_SINE_ON
H1:CAL-INJ_MASTER_SW

The guardian idle state turns off the following channels automatically on the 'PREP_FOR_LOCKING' mode (these channels were not turned back on after the time window):

H1:CAL-PCALX_OSC_SUM_ON
H1:CAL-PCALY_OSC_SUM_ON

A screenshot with Rx and Tx timeseries is attached. Further analysis is pending.

Maintenance activities have finsihed for the day, we are starting to relock now.

I checked the Kepco power supplies located at the end and mid stations.

EY - Temps < 72F, Rack C1 17-19 (PCAL +/- 18V irregular vibration noted, low draw <1A per rail)
EX - Temps < 72F, no vibrations
MY - Temps < 72F, no vibrations
MX - Temps < 72F, no vibrations

Recommend replacing fans on EY PCAL +/- 18V supplies due to irregular vibrations.

J. Kissel, J. Freed

We took a walk-about into the LVEA this morning and confirmed that the systems drawings for the HAM3 and HAM4 chamber feedthroughs (feedthrus, viewports) flange layouts -- D1002874 and D1002875, respectively -- are correct in that the top feedthrus are current not used, and have blanks installed. Pictures attached.

20240507_WHAM3_D8.jpg WHAM3 D8 (what we plan to use for HAM23 SPI Pathfinder [and CRS] optical fiber).

20240507_WHAM4_D8.jpg WHAM4 D8 (if a future HAM54 SPI link comes to fruition)

Jonathan, Erik, Dave:

h1daqnds1, which is the default NDS for workstations and guardian, started reporting a full /run file system at 00:55 PDT Tue 07may2024. This caused daqd and nds processes to stop serving data.

Jonathan restarted the rts-nds service at 08:13 PDT which cleared out the /run/nds/jobs directory, freeing up the disk space.

We noted that nds0 had 1.2GB of nds jobs files, 5% of the 26GB. Jonathan pruned this down to 1% usage.

I have added a check to my hourly cds_report to warn if the nds /run file systems exceed 50% usage.

Sheila, Camilla.

After this morning's windy lockloss from TRANSISITON _FROM_ETMX, we continued previous 77366 troubleshooting.

Sheila manually stepped though TRANSISITON _FROM_ETMX:

• We found that only the L1 history was cleared, giving unwanted outputs when we turned on L2 and L1 gains.
  • Sheila added a line to clear L2 history (line 5115: ezca['SUS-ETMX_L2_LOCK_L_RSET']=2).
• We then lost lock when turning off two DARM1 filters  (ezca.switch('LSC-DARM1', 'FM1', 'FM2', 'OFF')). This seems the cause of our glitch, attached shows this DARM1_SWSTAT change at the same time as the glitch on a successful lock.
  • FM1 "8^2:2^2" has a 20dB gain at low frequency and 10s ramp, but FM2 "MadHatter" has a 40dB gain and 0.09s ramp so is probably to blame.
  • Sheila notes that "MadHatter" used to be left on during the transition (74798, 75451). To check this, I see that FM2 was kept on though a successful transition from 75631, plot attached.
  • Sheila edited ISC_LOCK to leave DARM1 FM2 on during TRANSISITON _FROM_ETMX but turn it off during the next state:  LOWNOISE_ESD_ETMX, once we are already on NewDarm and effect of this low frequency filter is suppressed.
• After these changes, our locking was successful with no glitches: plot attached.

This may already be known, but in case it is not I am posting it in the aLOG again. In Fscan spectra, we can see the 960 Hz and 961 Hz DuoTone signal in h(t). I don't recall seeing this in previous observing run data. Is the DuoTone signal expected to be seen in h(t)? It is hard to see on the summary pages, but it can be seen in the Fscan plots or interactive spectrum. I attach a zoom from the interactive plots from May 1, but this can also be seen as far back as the start of O4a. It is also seen at L1.

The previous timing master which was again running out of range on the voltage to the OCXO, see alogs 68000 and  61988, has been retuned using the mechanical adjustment of the OCXO.

Today's readback voltage is at +3.88V. We will keep it running over the next few months to see, if it eventually settles.