Julianna Lewis, TonyS, RickS This morning we moved the upper (inner) Pcal beam at X-end back to center, then horiztonal by 5 mm at the entrance aperture of the Pcal Rx sensor to test the impact on the calibration of the Pcal system at X-end. This work is a continuance from the previous movement on August 8th 2023. See the following alog, Alog from August 8th, 2023

We expect that the impact on the calibration of the Xend Pcal will be given by the dot product of the Pcal and IFO displacement vectors on the ETM.

The work proceeded as follows:

1. Disabled all excitations for the Xend Pcal system.
2. Blocked the lower (outer) beam in the transmitter module.
3. Installed a target at the entrance aperture of the Rx sensor and adjusted the roll angle so that the rows of holes in the target were aligned with the vertical and horizontal directions 
4. Increased the Pcal AOM offset in the OFS servo from 3.33 to 5.0. (GPS time 1376154600)
5. Adjusted the inner beam back to its nominal location and the Rx sensor output level increased to about 0.301 W from about 0.300 W. (GPS time 1376155600) 
6. We moved the beam horizonal to the left hole on the target  Rx sensor level was 0.312 W (GPS time 1376156390)
7. We were concerned the Rx sensor output is increased by 1 percent. After waiting, the Rx sensor droped from 0.312 W to 0.309 W. (GPS time 1376158470)
8. Removed the target from the Rx sensor. Rx sensor level 0.3326 W. With OFS offset at 5.0. (GPS time 1376158650)
9. Unblocked lower (outer) beam Rx sensor with OFS offset still at 5.0, Rx sensor 0.6679 W (GPS time 1376158845)
10. Changed OFS offset back to 3.33, Rx sensor 0.4432 W (GPS 1376149180)
11. We expect that this horizontal beam movement will change the unintended rotation of the test mass. 

We will gather data for the following 7 days and observe any changes in the X/Y comparison. 

J. Kissel

Executive Summary: Driving TMSX in YAW from the top mass (M1) OSEM coils, and using the same stage M1 OSEM sensors as my response channels -- thus far, I can only report null results for finding any excitable mechanical features 102.12833 Hz. I found a feature at 103.585 +/- 0.004 Hz, but it's only a single feature, so I suspect it's the M1, "lower" blade bending mode rather than any evidence for violin modes. But, given the arrangement of sensors, actuators, and the wires on the transmon, I retrospectively am not surprised to not have found violin modes.

I'm looking to confirm whether the frequency that the IFO has been ringing up recently, 102.12833 Hz, is a violin mode of TMSX, as is currently "the most likely suspect" for what this giant feature is that rings up for the first ~3 hours of a lock stretch, after "apparently" being "rung up" by the turn on process for the LSC feed-forward (see, among others, LHO aLOG 72064, 72214, 72221).

Recall the TMTS is a double suspension -- see D0901880 for top-level assembly drawing.
Recall that TMSX is a "production" TMS, rather than a "First Article" TMS, but I can't find a single source link that tells us the difference clearly and concisely.
   - From the ISI, there are two blades (no drawing! Only an excel spreadsheet of characterization under D1200116), and two wires suspending the top mass (M1). 
   - From M1, there are also two blades (no drawing! Only an excel spreadsheet of characterization under D1200117), and *four* wires suspending the optical bench and telescope assembly. The TMS is unique in that it's the only 4-wire suspension clamped from 2 blade tips (see D1101163).

So, if we drive the M1 stage (the only place we can), and with no IFO all we have are M1 stage sensors, then we would hope to see 
   - two violin modes from the Sus. Point to M1 "upper" wires, *maybe* each split into two orthogonal DOFs if the Q is high enough and the bending points move asymmetrically enough
   - four violin modes from the M1 to M2 "lower" wires, again, *maybe* split into eight.
T1300876, table 3.11 for the "production" TMTS predicts a single violin mode frequency from first principles, the properties of the wires, and the load on the wires, to be 
   - Upper -- 331.7 Hz
   - Lower -- 104.2 Hz

Looking at the OSEM arrangement for the TMTS (see E1200045) -- which is *like* the QUAD, but rotated 90 deg such that only one SD OSEM senses / actuates in Longitudinal -- I chose to start the exploration for violin modes by driving in Yaw around 100-110 Hz using awggui, and measuring the responses, transfer functions, and coherence simultaneously in DTT. I slowly narrowed in my 6th order elliptic band pass on the region, such that I could drive more and more power. I had plenty enough SNR in the M1 OSEM to M1 OSEM transfer function at these frequencies that I could get coherent transfer functions.

I did find a feature at 103.585 +/- 0.002 Hz, but since it's only one feature rather than four (or eight), I can't claim that "this is *the* violin mode(s)" but I guess instead that it's a blade bending mode of the "lower" M1 to M2 blades. Why? 
    :: These TMTS M1-to-M2 blades are much like the QUAD's M0-to-L1 and L1-to-L2 blades -- copies and pastes of the UIM blades -- which have bending modes at around ~110 Hz (see analysis for the QUAD blade conditions in T1300595).
    :: while I expect energy is getting into the violin modes from the M1 Yaw drive, I guess I'm not surprised that the energy of those violin modes does not couple back through the blade clamps, the blades, and the M1 mass to the OSEM flags enough to see above the OSEM sensor noise.

Here's some of the data:
    - 1st attachment: The transfer function between M1 Y drive to M1 Yaw and Transverse OSEM response, with an FFT length of 128 seconds for a frequency resolution of 1/128 = 0.0078125 Hz (and an effective noise bin width of (1/128)*1.5 = 0.01171875 Hz given that I'm using the default Hanning window, which has a NENBW of 1.5 bins). This was the first clue that I wouldn't find anything at 102.129 Hz, and that there was something at 103.585 Hz.
    - 2nd attachment: Yaw Drive with a tighter band-pass filter from 102 to 103 Hz, and measured with the same 0.0078 mHz resolution, we see nothing in this band.
    - 3rd attachment: Yaw Drive with a higher frequency 1 Hz band pass, from 103 to 104 Hz, and measured with a much higher frequency resolution -- FFT length of 512 seconds, for a resolution of 1.95 mHz, and effective noise binwidth of 2.92 mHz.

Maintenance concluded around 1pm PT, we are relocking now and testing some new ALS automation code along the way.

WP 11367

Yesterday morning a new fiber run was pulled from the MSR to General Computing (RM163). Fiber bundle is a MTP with 24 fiber pairs. Ryan Short noted start and end times in alog 72192. Work required lifting of tiles in the MSR/Control Room/Computer Users Room/General Computing Room. We spend some time pulling out many unused/damaged fibers and cables.

A Bernal, F. Clara

As a followup of alog 72061, a batter-operated voltage reference was connected to the OM2 heater chassis. Beckhoff cable was disconnected for now.

Please check if the 1.66Hz comb is still there.

Arianna, Derek

We noticed that the calibration line subtraction pipeline is often not correctly subtracting the calibration lines at the start of lock segments.

A particularly egregious case is on July 13, where the calibration lines are still present in the NOLINES data for ~4 minutes into the observing mode segment but then quickly switch to being subtracted. This on-to-off behavior can be seen in this spectrogram of H1 NOLINES data from July 13, where red lines at the calibration frequencies disappear at 1:10 UTC. Comparing the H1 spectrum at 1:06 UTC and 1:16 UTC shows that the H1:GDS-CALIB_STRAIN spectrum is not changed, but the H1:GDS-CALIB_STRAIN_NOLINES spectrum has calibration lines in the 1:06 UTC spectrum and no lines in the 1:16 UTC spectrum. This demonstrates that the problem is with the subtraction rather than the actual calibration lines. 

This problem is still ongoing for recent locks. The most recent lock on August 15 has the same problem. The calibration lines "turn off" at 4:46 UTC as seen in the attached spectrogram. 

The on-to-off behavior of the subtraction is particularly problematic for data analysis pipelines as the quickly changing line amplitude can result in the data being over- or under-whitened.   

WP 11373

Recent power glitches have tripped HEPI at both end stations. SEI group requested the Beckhoff electronics for the HEPI pumps be placed on a UPS to help ride through the power glitches. This morning HEPI was taken offline. The Beckhoff computer was remotely powered down. Cabling was pulled in from the vacuum rack (24V, power supply on UPS) to the mechanical room. The dedicated HEPI power supply was disconnected and new 24V terminated. After code was restarted, the pump panel was power cycled. Work was done at both end stations.

F. Clara, T. Shaffer, P. Thomas, J. Warner

Dave mentions in his summary below, HAM1 HPI model was restarted this morning so I could add some temporary DQ channels to the frames for the ground to HPI feedforward I'm working on at that chamber. These channels are meant to be temporary until we decide if the FF is going to be permanent or not, but having in the frames right now will make commissioning the ff easier. These channels are: 

 0$ check_model_daq_configuration h1hpiham1
--------------------- file times ----------------------
Mon Aug 14 13:52:54 2023 = Model build time

Tue Aug  8 11:32:55 2023 = Current configuration load time

DAQ configuration is changed, processing...

++: fast channel H1:HPI-HAM1_3DL4CINF_A_X_IN1_DQ added to the DAQ
++: fast channel H1:HPI-HAM1_3DL4CINF_A_Z_IN1_DQ added to the DAQ
++: fast channel H1:HPI-HAM1_3DL4CINF_B_X_IN1_DQ added to the DAQ
++: fast channel H1:HPI-HAM1_3DL4CINF_B_Z_IN1_DQ added to the DAQ
++: fast channel H1:HPI-HAM1_3DL4C_FF_X_IN1_DQ added to the DAQ
++: fast channel H1:HPI-HAM1_3DL4C_FF_Y_IN1_DQ added to the DAQ
++: fast channel H1:HPI-HAM1_3DL4C_FF_Z_IN1_DQ added to the DAQ
Total number of DAQ changes = 7
(7 additions, 0 deletions)

The A_X, A_Z, B_X and B_Z channels are the uncalibrated individual adc channels that I connected to the 3dl4c ff path. A_X and B_X don't currently have any sensors attached, but I hope to do something about that soon. The FF_X, FF_Y and FF_Z channels are the calibrated cartesian basis channels that get filtered and summed into the cart drives drives. FF_Z is the only channel that has any real data on it at the moment. No real changes to the model to do this, but I did have to make a custom library part to add the channels to the table. Added channels are in the screen shot.

WP11361 TW1 raw minute trend files offload

Dave:

I have started the file copy from h1daqtw1's SSD-RAID (93% full) over to h1ldasgw1 SATABOY HDD storage.

The first step was to get TW1 to write trends to a new empty directory, freeing up the full directory for file copy. This required a temporary change to h1daqnds1's daqdrc file and a daqd restart. The restart was incorporated into the main DAQ restart of h1hpiham1 model change.

The file copy was started at 11:50 and is expected to take about 2 days.

WP11364 Signal reordering in h1oaf model

Jenne, Dave:

Jenne created a new h1oaf.mdl which was installed this morning. No DAQ restart was needed.

WP11369 Temporary addition of 1kHz DQ channels to DAQ for h1hpiham1

Jim, Dave:

A new h1hpiham1 model was installed, which adds seven 1kHz DQ channels to the DAQ. DAQ restart was needed

DAQ Restart

Dave, Jonathan, EJ:

The DAQ was restarted for the h1hpiham1 model change and the new NDS1 daqdrc configuration.

This was a messy restart. On the plus side, neither GDS0 nor GDS1 needed a second restart.

When the h1oaf model was restarted, FW0 took about 21 seconds longer to write the full frame it was in the process of writing. FW1 did not show this behaviour.

I started the 1-leg first, waited for about 5 minutes and then started the 0-leg. As was seen two weeks ago, while FW0 was coming back, FW1 spontaneously restarted itself, resulting in two frame files not written by either frame writer.

Cao's new HWS cleaning code is running on EY HWS. hws-server/-/tree/fix/python3 The code works for python3 that we currently only have at ETMY. We should soon get all HWS computers running with python3 and then can use this code on all optics.

This doens't effect any of the old HWS code but adds new channels, see 68748. This code adds functionalities to estimate wavefront centers (H1:TCS-{OPTIC}_HWS_CENTER_ESTIMATE_{X,Y}) rather than relying on the those set by the user (H1:TCS-{OPTIC}_HWS_ORIGIN_{X,Y} ), and filters unusually large gradients to update center and spherical powers for clean channels.

Tue Aug 15 10:09:42 2023 INFO: Fill completed in 9min 38secs

Closes FAMIS 19671, last check alog72031

BSC:

ITMX_ST2_CPSINF_H1 high freq noise is high!

ITMY_ST2_CPSINF_H2 high freq noise has reduced

HAM:

Looks good.

J. Kissel, J. Driggers

I was brainstorming why LOWNOISE_LENGTH_CONTROL would be ringing up a Transmon M1 to M2 wire violin mode (modeled to be at 104.2 Hz for a "production" TMTS; see table 3.11 of T1300876) for the first time on Aug 4 2023 (see current investigation recapped in LHO:72214), and I remembered "TMS tracking..."

In short: we found that ETMX M0 L OSEM damping error signal has been fed directly to TMSX M1 L path global control path, without filtering, since Sep 28 2021. Yuck!

On Aug 30 2021, I resolved the discrepancies between L1 and H1 end-station SUS front-end models -- see LHO:59772. Included in that work, I cleaned up the Tidal path, cleaned up the "R0 tracking" path (where QUAD L2 gets fed to QUAD R0), and installed the "TMS tracking" path as per ECR E2000186 / LLO:53224. In short, "TMS tracking" couples the ETM M0 longitudinal OSEM error signal to the TMS M1 longitudinal "input to the drivealign bank" global control path, with the intent of matching the velocity of the two top masses to reduce scattered light.

On Aug 31 2021, the model changes were installed during an upgrade to the RCG -- see LHO:59797, and we've confirmed that I turned both TMSX and TMSY paths OFF, "to be commissioned later, when we have an IFO, if we need it" at
    Tuesday -- Aug 31 2021 21:22 UTC (14:22 PDT) 

However, 28 days later,
    Tuesday -- Sept 28 2021 22:16 UTC (15:16 PDT)
the TMSX filter bank got turned back on, and must have been blindly SDF saved as such -- with no filter in place -- after an EX IO chassis upgrade -- see LHO:60058. At the time, that RCG 4.2.0 still had the infamous "turn on a new filter with its input ON, output ON, and a gain of 1.0" feature, that has been since resolved with RCG 5.1.1. So ... maybe, somehow, even though the filter was already installed on Aug 31 2021, the IO chassis upgrade rebuild, reinstall, and restart of the h1sustmsx.mdl front end model re-registered the filter as new? Unclear. Regardless this direct ETMX M0 L to TMSX M1 L path has been on, without filtering, since Sep 28 2021. Yuck!

Jenne confirms the early 2021 timeline in the first attachment here.
She also confirms via a ~2 year trend of the H1:SUS-TMSY_M1_FF_L filter bank's SWSTAT, that no filter module has *ever* been turned on, confirmed that there's *never* been filtering.

Whether this *is* the source of 102.1288 Hz problems and that that frequency is the TMSX transmon violin mode is still unclear. Brief investigations thus far include
    - Jenne briefly gathered ASDs of ETMX M0 L (H1:SUS-ETMX_M0_DAMP_L_IN_DQ) and TMSX M1 L OSEMs' error signal (H1:SUS-TMSX_M1_DAMP_L_IN1_DQ) around the time of Oli's LOWNOISE_LENGTH_CONTROL time, but found that at 100 Hz, the OSEMs are limited by their own sensor noise and don't see anything.
    - She also looked through the MASTER_OUT DAC requests (), in hopes that the requested control signal would show something more or different, but found nothing suspicious around 100 Hz there either.
    - We HAVE NOT, but could look at H1:SUS-TMSX_M1_DRIVEALIGN_L_OUT_DQ since this FF control filter should be the only control signal going through that path. I'll post a comment with this.

Regardless, having this path on with no filter is clearly wrong, so we've turned off the input, output, and gain accepted the filter as OFF, OFF, and OFF in the SDF system (for TMSX, the safe.snap is the same as the observe.snap).

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.