TITLE: 07/22 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY:
Every thing was locked and humming along until the sudden lockloss from the 6.5M Earthquake off coast of Russia.
Held in Down for ~2.5 hours while the Earth rang down.
Ran an Initial Alignment and H1 is currently at CARM_OffSET reduction.
Wind is vey low, ground motion has dropped should be a good night of locked IFO.
LOG:
No Log

@ 02:08:55 UTC Known Lockloss caused by a 6.5M Earthquake. I'm using the GEOFON site because USGS took ~ 10 min to report the quake.
Earthquake mode was activated, then less than 30 seconds later we were unlocked.
No earthquake was listed as incoming, Picket fence was lit up and had active ground motion.
 

After last week's satamp changes (85770), the compensation filters found in the OSEMINF filter bank for MC2, PR2, TMSX, and ETMX M0/R0/L1 were all updated to a generic compensation filter of 5.31:0.0969. I have now updated those filters based on the experimental measurements Jeff got for each satamp's channel (the same as what I did in 85746).

To update the compensation filters, I used the newest version of my script satampswap_bestpossible_filterupdate_ECR_E2400330.py, svn revision r12475. This newest version of the code allows you to specify which stage you want to update, if you aren't wanting to update every stage listed in the txt files. Here is a txt file of my inputs and the corresponding outputs for the lines of code that I ran.

I have loaded these more accurate filters in for these suspension/stages.

TITLE: 07/21 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 15mph Gusts, 12mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.06 μm/s
QUICK SUMMARY:
H1 is currently Locking at Move.
Secondary microseism looks to be falling.
All systems look great.

Brushfire look out was done by Oli today, who said... "No fires today."
Roof pictures attached.

TITLE: 07/21 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 145Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY:

Started with a locked H1, and then started Monday Commissioning for 4-hours (15-19utc/8-noonPDT).  Had a lockloss at the beginning of commissioning and it took 2hrs to get back to NLN (mostly let ISC_LOCK acquire on its own...it just took a bit.).

Lockloss in the afternoon looked a bit odd with the alignment not looking great.  Tried to not run an Initial Alignment (i.e. run CMFringes + PRMI), but alignment looked bad.  After 45min of acquiring, went for an Initial Alignment (which wasn't trivial due to a finicky IMC--see below), and after the IA, H1's alignment looked much better.   It's all a question of when to run/not run an alignment due to the BS cooling down after locklosses.

EQs continued to rumble for most of the morning (many from Japan).
LOG:

• 1435-1529 MX chiller yard checks (randy)
• 1503 Commissioning Begins
• 1504-1632 MY technical cleaning (nellie)
  • 1632 MX technical cleaning (nellie)
• 1515 LOCKLOSS
  • It was hard, but tried to not touch H1 for locking (since last night and most of the weekend reacquisition was fairly automated), but I did move the BS a few clicks during the 1st DRMI 20min acquisition (no lock).  Went automatically to PRMI for the 1st time, but after about 11min, I intentionally went to CHECK MICH FRINGES.  Then for 2nd PRMI I did touch PRM a few clicks, but restored it....and it finally acquired after 11min on its own.  DRMI's 2nd attempt (after Check Mich Fringes + PRMI) had decent POP18/90 flashes, but the camera did show some yaw misalignment but it eventually locked after about 7min.....and then a lockloss at START TR CARM  :(
  • 1717 H1 back to Observing for Commissioning
• 1634 Grabbing extra power supply for HAM6 HV (in prep for swap for tomorrow's Maintenance) (fil)
• 1733-1802 MX, EX Mechanical Room visits to check HVAC air filters (chris)
• 1902 Back to Observing
• 1957-2015 EY trip to pick up nitrogen air cyllinders (chris)
  • 2025-2050 Cyllinders not there, so went to EX (chris)
• 2053-2241 TCS work at the Triples Lab in Staging (camilla, tony)
• 2133 LOCKLOSS (after 4.25 hr lock)
  • Summary:  Although, locking was good overnight with no Alignments needed, this one looked bad, and so ultimately decided to run an Initial Alignment (after locking for 45min).
  • ALSx had 2 locklosses at the beginning after Offloading and the ITM Camera signal was dropping along with ARM transmission before the lockloss.
  • For 1st DRMI locking, alignment was very bad (from camera and flashes).  Guardian took DRMI to PRMI within 3minutes!  But I went to Check Mich Fringes.  And for PRMI, it locked but ASC didn't really do much for PRMI.  
  • 2216 Started an Initial Alignment.....but the IMC took over 10min to lock (eventually locked perhaps due to taking IMC_LOCK to DOWN a few times).  DRMI locked in just over 4min.....but then there was an accidental user error lockloss.   But not an issue, because for the next lock, DRMI acquired in under 5min again.  This is what I'm handing off to Tony.
• 2150-2155 Looking at Power Supply in CER (richard)
• 2241-2255 PCal measurements (francisco)

Elenna noticed that pimon that we run on nuc25 hadn't been consistently saving data. There were large periods of time that didn't have anything recorded. I first verified that it would still write log and npz files, then I redirected them to /ligo/data/pimon/locklosses/ where it will now put all of the npz files. Elenna also asked that the script saves the time series and not the PSDs, so I made that change as well. I'm not sure the file size difference, the PSDs were about 3.6Mb, so we should keep an eye on that and get rid of old ones.

Operators, please verify that pimon is running on nuc25, and restart it if necessary. The normal launch script will start it up.

The calibration lines still appear in DHARD P and Y to varying degrees. Here is a higher resolution spectrum of DHARD P and Y, with OMC DCPD sum for reference. DHARD P shows all four calibration lines (L1 15.6 Hz, L2 16.4 Hz, L3 17.6 Hz and PCAL 17.1 Hz) between 15-18 Hz, while DHARD Y only seems to show the 16.4 Hz line in L2.

Today, Sheila and I also looked at the phasing of AS A/B 45 WFS. Our thinking was that a DARM line could be phased to be mainly in Q for each segment. The segments all show the calibration lines prominently, so they can be used as a phasing reference. It was immediately apparently that for all segments of both WFS, the DARM line is at least a factor of 2 higher in I than in Q. We decided not to make any phasing changes at this time, since rephasing these lines into Q would change the sign dramatically and may impact locking when we put DARM on RF.

Instead of redesigned the MICH ASC loops, I just updated the lowpasses to be at 12 Hz instead of 15 Hz, which should reduce the gain by 15 dB between 10-20 Hz for both pitch and yaw. I tested them today with no issues, so I adjusted the MICH ASC engagement in ISC_DRMI guardian, and updated SDF (accidentally overwrote the screenshot with my screenshot of the filter).

Elenna and I checked the FC detuning by taking it slowly from nominal -26 to -50, where we could clearly see low freq DARM was worse, and then stepping to -15 (any lower unlocked the FC in 85886) using ezcastep H1:IOP-LSC0_RLF_FREQ_OFS -s 30 '+1,35', see attached plot. The best de-tuning is close to where we already are, leaving it at -27.

Mon Jul 21 10:08:47 2025 INFO: Fill completed in 8min 44secs

First I tried taking H1:IOP-LSC0_RLF_FREQ_OFS down towards zero but we lost FC lock at  H1:IOP-LSC0_RLF_FREQ_OFS = -8. FC would not re-lock until I brought it back to -15.

Wanted to scan FC de-tuning from -15 to -60 but the command didn't seem to work with negative steps.

Then 5s after moving FC detuning from -15 to -60, the IFO lost lock, 1437146099. The lockloss appears unrelated to the FC detuning change as the FC lost lock after we see  ETMX_L3 start to be unstable, plot. There was slightly increased noise at low frequency but not enough scatter to cause a lockloss.

Ideally would have ran ezcastep H1:IOP-LSC0_RLF_FREQ_OFS -s 30 '+1,45' to get 30sec steps from -60 to -15. We've been at -44 before with no issues, 83526, but wanted to make the low frequency noise worse to be able to fit to the best place.

I'm followed the pydarm deployment instructions here, to update the LHO pydarm install.

This is the 20250721.0 tag for pydarm, which includes a bug fix for high frequency roam line handling, letting us indicate the correct reference model in the pydarm_H1.ini file.

This is not the default cds conda environment, but the default you get when typing pydarm at a command line, or specifically invoking by running "conda activate /ligo/groups/cal/conda/pydarm".

TITLE: 07/21 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 113Mpc
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 13mph Gusts, 9mph 3min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.06 μm/s
QUICK SUMMARY:

Arriving to a Dust Alarm in the PSL over the last hr (there have been winds around the corner station the last 2hrs but only about 15mph).

For H1 over the last 12 hrs we have had 4 locks (current one is 90min) where 2 (of3) locklosses were ETMx Glitches, and it looks like all reacquisition was automatic overnight.

H1 is scheduled for Commissioning from 15-19utc (8-noonPDT).

Prompted by me noticing on-off behaviors in the daily strain spectrogram for today at around 20.2 Hz, I've done some additional investigations into the source and behavior of this line: 

The 20.2 Hz line, which is currently prominent in DARM, first appeared in accelerometer and microphone data from the corner station on June 9. The first appearance of this line that I found was in the PSL mics, as shown in this spectrogram. This line then appeared in DARM in the first post-vent locks a few days later. The summary of work from June 9 does not show anything obvious to me that would be the source of this new noise.

This feature also turns off and on multiple times during the day. An example from today can be seen in this spectrogram. Most corner station microphones and accelerometers exhibit this feature, but it is most pronounced visually in the PSL microphone spectrograms. I was unable to identify any other non-PEM channels that showed the same on-off behavior, but this does reveal many change points that should aid in tracking down the source. Almost every day, this line exhibits abrupt on-off features at different times of the day and for varying durations. Based on my initial review, these change points appear to be more likely during the local daytime (although not at any specific time).  When the line first appeared, it was usually in the "off" state and then turned on for short periods. However, this has slowly changed, so that now the line is generally in the "on" state and turns off for brief periods. 

Jennie, Rahul

On Tuesday Rahul and I took the measurements for the horizontal coupling in the ISS array currently on the optical table.

The QPD read 9500 e-7 W.

The X position was 5.26 V, the Y position was -4.98 V.

After thinking about this data I realise we need to retake it as we should record the mean value for the DC coupled measurements. This was with a 78V signal applied from the PZT driver and an input dither signal of 2 Vpp at 100Hz on the oscilloscope and I think 150 mA pump current on the laser.

Sheila, Camilla

We ran a couple of squeezing angle scans to check the settings of the ADF servo. 

One thing that we realized is that the ADF Q demod signal is divided by H1:SQZ-ADF_OMC_TRANS_Q_NORM rather than mulitplied which is what we had thought.  We changed the coefficent from 0.18 to 5.8. The first png attachment shows that this transforms the blue ellipse into the orange one.  It would be a bit better if we first adjusted the demod phase to maximize the Q signal, so that the ellipse would be aligned along the axis, and the rescaled version would be more like a circle.  However you can see in the right side plot that this gives us a reasonably linear readback of sqz angle as we change the RF6 demod angle (which is actually cabled up to RF3 phase) about 150 degrees where our best squeezing is.

Camilla turned the servo back on in sqzparams. 

For future reference, a slightly better way to do this would be to move the demod phase to maximize Q, do a scan and set H1:SQZ-ADF_OMC_TRANS_Q_NORM to the ratio (max of Q)/ (max of I).  Then you can do a smaller scan around the point with the best squeezing, and in sqzparams set sqz_ang_adjust_ang to the readback angle that you think is best.

I previously noted a glitch about 30 seconds before lockloss in LOWNOISE ASC, 85685. However, we had two more locklosses from this state last night and I do not see such a glitch so that is a random coincidence. One of those locklosses appears to be caused by an earthquake. However, since 6/11, we have had 9 locklosses in this state that occurred exactly 47 seconds into the state, which seems suspicious, one of those occurred last night, and the lockloss with the glitch was the same.

This seems to be coincident with the engagement of a few DHARD P filters:

2025-07-14_14:26:54.641531Z ISC_LOCK executing state: LOWNOISE_ASC (522)
2025-07-14_14:26:54.642230Z ISC_LOCK [LOWNOISE_ASC.enter]
2025-07-14_14:26:54.655894Z ISC_LOCK [LOWNOISE_ASC.main] ezca: H1:ASC-ADS_PIT3_OSC_CLKGAIN => 300
2025-07-14_14:26:54.656325Z ISC_LOCK [LOWNOISE_ASC.main] ezca: H1:ASC-ADS_PIT4_OSC_CLKGAIN => 300
2025-07-14_14:26:54.656732Z ISC_LOCK [LOWNOISE_ASC.main] ezca: H1:ASC-ADS_PIT5_OSC_CLKGAIN => 300
2025-07-14_14:26:54.657043Z ISC_LOCK [LOWNOISE_ASC.main] ezca: H1:ASC-ADS_YAW3_OSC_CLKGAIN => 300
2025-07-14_14:26:54.657438Z ISC_LOCK [LOWNOISE_ASC.main] ezca: H1:ASC-ADS_YAW4_OSC_CLKGAIN => 300
2025-07-14_14:26:54.657892Z ISC_LOCK [LOWNOISE_ASC.main] ezca: H1:ASC-ADS_YAW5_OSC_CLKGAIN => 300
2025-07-14_14:26:54.658134Z ISC_LOCK [LOWNOISE_ASC.main] timer['LoopShapeRamp'] = 5
2025-07-14_14:26:54.658367Z ISC_LOCK [LOWNOISE_ASC.main] timer['pwr'] = 0.125
2025-07-14_14:26:54.783581Z ISC_LOCK [LOWNOISE_ASC.run] timer['pwr'] done
2025-07-14_14:26:59.658298Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] done
2025-07-14_14:26:59.719537Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_Y_GAIN => 200
2025-07-14_14:26:59.720456Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_Y_SW1 => 256
2025-07-14_14:26:59.846249Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_Y_SW2 => 20
2025-07-14_14:26:59.971686Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_Y => ON: FM3, FM8, FM9
2025-07-14_14:26:59.972384Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DHARD_Y_SW1 => 5392
2025-07-14_14:27:00.098073Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DHARD_Y_SW2 => 4
2025-07-14_14:27:00.223528Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DHARD_Y => ON: FM1, FM3, FM4, FM5, FM8
2025-07-14_14:27:00.224135Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CSOFT_P_SMOOTH_ENABLE => 0
2025-07-14_14:27:00.224497Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CSOFT_Y_SMOOTH_ENABLE => 0
2025-07-14_14:27:00.224868Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DSOFT_P_SMOOTH_ENABLE => 0
2025-07-14_14:27:00.225188Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DSOFT_Y_SMOOTH_ENABLE => 0
2025-07-14_14:27:00.225433Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] = 10
2025-07-14_14:27:10.225728Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] done
2025-07-14_14:27:10.281803Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_P_TRAMP => 5
2025-07-14_14:27:10.408120Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_P_SW2 => 16
2025-07-14_14:27:10.533563Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_P => OFF: FM9
2025-07-14_14:27:10.534285Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_P_SW1 => 256
2025-07-14_14:27:10.660088Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_P_SW2 => 4
2025-07-14_14:27:10.785453Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_P => ON: FM3, FM8
2025-07-14_14:27:10.786315Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_P_GAIN => 208
2025-07-14_14:27:10.786535Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] = 5
2025-07-14_14:27:15.786858Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] done
2025-07-14_14:27:15.847152Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DSOFT_Y_TRAMP => 5
2025-07-14_14:27:15.847580Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DSOFT_Y_GAIN => 5
2025-07-14_14:27:15.848666Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DSOFT_P_GAIN => 5
2025-07-14_14:27:15.848917Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] = 5
2025-07-14_14:27:20.849050Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] done
2025-07-14_14:27:20.906577Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-ITMX_M0_DAMP_Y_TRAMP => 10
2025-07-14_14:27:20.907206Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-ETMX_M0_DAMP_Y_TRAMP => 10
2025-07-14_14:27:20.907700Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-ITMY_M0_DAMP_Y_TRAMP => 10
2025-07-14_14:27:20.908422Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-ITMX_M0_DAMP_Y_GAIN => -0.5
2025-07-14_14:27:20.908830Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-ETMX_M0_DAMP_Y_GAIN => -0.5
2025-07-14_14:27:20.909148Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-ITMY_M0_DAMP_Y_GAIN => -0.5
2025-07-14_14:27:20.909562Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-ETMY_M0_DAMP_Y_GAIN => -0.5
2025-07-14_14:27:20.909789Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] = 10
2025-07-14_14:27:30.910055Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] done
2025-07-14_14:27:30.968166Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-SR2_M1_DAMP_P_GAIN => -0.2
2025-07-14_14:27:30.968527Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-SR2_M1_DAMP_Y_GAIN => -0.2
2025-07-14_14:27:30.968806Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-SR2_M1_DAMP_L_GAIN => -0.2
2025-07-14_14:27:30.969073Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-SR2_M1_DAMP_R_GAIN => -0.2
2025-07-14_14:27:30.969343Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-SR2_M1_DAMP_T_GAIN => -0.2
2025-07-14_14:27:30.969606Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-SR2_M1_DAMP_V_GAIN => -0.2
2025-07-14_14:27:30.969838Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] = 10
2025-07-14_14:27:40.970003Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] done
2025-07-14_14:27:40.972085Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DHARD_P_SW1 => 1024
2025-07-14_14:27:41.097962Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DHARD_P_SW2 => 4
2025-07-14_14:27:41.223313Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DHARD_P => ON: FM4, FM8
2025-07-14_14:27:41.223637Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] = 10
2025-07-14_14:27:41.593743Z ISC_LOCK [LOWNOISE_ASC.run] Unstalling IMC_LOCK
2025-07-14_14:27:41.765955Z ISC_LOCK JUMP target: LOCKLOSS

I will take a look and see if there is anything unstable about these filters. Whatever is occurring seems to be too fast to be seen in the ASC signals themselves, and at first glance I don't see anything strange in the suspension channels either.

DHARD FM4 is engaged with a 10 second ramp- this is a change I made on 6/11: 84973 because we had lost lock on that day twice in the same spot. Two of the locklosses at 47 seconds occurred before that change. Then, later that day on 6/11 I reengaged a boost in DHARD P, which only has a 5 second ramp, 84980. Engaging that boost shouldn't be unstable, but maybe something bas occurrs when they ramp at different times. I'm lengthing the ramp to 10 seconds.

Jennie W, Rahul

Yesterday we made some measurements to calibrate the spot size on the QPD as we scan the beam position across it.

We used a connector Fil made us to plug in the OT301 QPD amplifier into a DC power supply after checking it contained voltage regulators that could cope with a voltage between 12 and 19 V ( as the unit says it expects DC supply but the previous one we were using was AC with a 100mA current rating and was getting too hot so we assume that was the incorrect one). We hooked it up at 16V (this draws about 150mA of current). The QPD readout looks normal and does not have any of the strange sawtooth we saw with the original power cable.

We moved the M2MS beam measurement system out of the way of the translation stage.

To calibrate the QPD we need to change the lateral position of the M1 mirror and lens to change the yaw positioning on the QPD and measure the X and Y voltages from the QPD.

We need to check we are centred first. The QPD bullseye readout shows the beam is off a tiny bit in yaw but this was as good as we could get at centering the beam when we moved the QPD. All 8 PDs are reading about 4.6 V so this means the beam is well centred in the array plane.

We measure 11000 counts on the bullseye qpd readout at this M1 position.

I plotted the data from lowest reading on the translation stage to highest and fitted the linear region using Calibrate_QPD.m which is attached.

Data is shown in attached pdf.

The slop of the linear region in V/inch is 112 V/inch. Which means to if the beam moved 8.93 e-3 inches on the QPD in yaw, the yaw readout would change by 1 Volt.

Ibrahim, Rahul

The first round of B&K test results for BBSS & HRTS were posted in LHO alog 84654 . Now were are presenting the second round of test results after making the following improvements on BBSS - (a) added four side dampers (D1101299), two on each side, (b) two lower structure Y-brace strut - D1900589. Please see figure (IMG_2926) for reference. We have also removed the four optical posts which were earlier attached to the HRTS. Finally we attached four Vibration Absorbers (D1002424) to BBSS.

The B&K test results are attached below as a pdf document. We have taken 9 measurements with different boundary conditions, each of which is explained below. For each case the tri-axis accelerometer was mounted on the BBSS frame (marked as position P1 or P2 here) - X axis is along the longitudinal side of the BBSS, Y axis is the vertical and Z is transverse. For HRTS, it's shown in page 9 of the pdf document.

Test 1a (see page 2): case - BBSS (without HRTS) and no side dampers or Y-brace attached to BBSS, Accelerometer position P1.

Test 1b (see page 3): case - BBSS & HRTS and no side dampers or Y-brace attached to BBSS, Accelerometer position P1.

Next ,side dampers and Y-brace attached.

Test 2a (see page 5): case - BBSS & HRTS with side dampers and Y-brace attached to BBSS (No Vibration Absorbers), Accelerometer position P1. Hammer hits on the center of the structure.

Test 2b (see page 6): case - BBSS & HRTS with side dampers and Y-brace attached to BBSS (No Vibration Absorbers), Accelerometer position P2. Hammer hits on the center of the structure.

Test 3 (see page 7): case - BBSS & HRTS with side dampers and Y-brace attached to BBSS (No Vibration Absorbers), Accelerometer position P1. Hammer hits on the side of the structure (left or right).

Test 4 (see page 8): case - BBSS & HRTS with side dampers and Y-brace attached to BBSS (No Vibration Absorbers), Accelerometer position P2. Hammer hits on the side of the structure (left or right).

Test 5 (see page 9): case - BBSS & HRTS with side dampers and Y-brace attached to BBSS (No Vibration Absorbers), Accelerometer attached to HRTS. Hammer hits on HRTS.

Next ,side dampers Y-brace and Vibration Absorbers attached.

Test 6a (see page 11): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P1. Hammer hits on the center of the structure (X axis or longitudinal direction).

Test 6b (see page 12): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P1. Hammer hits on the center of the structure (Y axis or vertical direction).

Test 6c (see page 13): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P1. Hammer hits on the center of the structure (Z axis or transverse direction).

Test 7a (see page 14): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P1. Hammer hits on the side of the structure (X axis or longitudinal direction).

Test 7b (see page 15): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P1. Hammer hits on the side of the structure (Y axis or vertical direction).

Test 7c (see page 16): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P1. Hammer hits on the side of the structure (Z axis or transverse direction).

Test 8a (see page 17): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P2. Hammer hits on the center of the structure (X axis or longitudinal direction).

Test 8b (see page 18): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P2. Hammer hits on the center of the structure (Y axis or vertical direction).

Test 8c (see page 19): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P2. Hammer hits on the center of the structure (Z axis or transverse direction).

Test 9a (see page 20): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P2. Hammer hits on the side of the structure (X axis or longitudinal direction).

Test 9b (see page 21): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P2. Hammer hits on the side of the structure (Y axis or vertical direction).

Test 9c (see page 22): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P2. Hammer hits on the side of the structure (Z axis or transverse direction).

The raw data (.csv files) generated by the B&K software are stored at the following location,

/ligo/home/rahul.kumar/Desktop/scripts/bnk_csv_files