Displaying reports 3561-3580 of 83100.Go to page Start 175 176 177 178 179 180 181 182 183 End
Reports until 11:51, Thursday 19 December 2024
H1 GRD (ISC, OpsInfo, SUS)
oli.patane@LIGO.ORG - posted 11:51, Thursday 19 December 2024 (81909)
SUS_PI guardian now increases ETMY ESD bias to help damp PI24

Since we've been having issues with PI24 ringing up lately we decided to change the SUS_PI guardian code to increase the bias offset on ETMY L3 LOCK. That bias offset value is normally -4.9, and we noticed that when damping PI24, we typically start hitting our damping limit when PI24 RMSMON exceeds a value of 10. I have turned the PI_DAMPING state into a generator function so it can now make two different states, PI_DAMPING and EXTREME_PI_DAMPING. When in PI_DAMPING, pi24 will be damped with our normal bias until we reach an RMSMON average value of 20. Once that happens, the guardian will jump to a state called INCREASE_BIAS (what it does is self-explanatory), and then goes into XTREME_PI_DAMPING, where it continues damping and changing phase as needed until we are back under an RMSMON value of 4(pi24 script logic). Once we are good the guardian will take us through DECREASE_BIAS (guess what that does) and then back into PI_DAMPING(node graph, states list).

Because the nominal state for Observing is PI_DAMPING, when we move into one of these other states we will be taken out of Observing (tagging OPS). Once we are back in PI_DAMPING we will automatically go back into Observing as long as we are in AUTOMATIC.

Occasionally we do get small quick ringups that go up above 20 that are capable of being damped by regular damping and just changing the phase - ndscope1(versus the slower ringups that cannot - ndscope2), so with these script changes, when these happen we will be taken out of Observing as the SUS_PI guardian jumps to up the bias and damp harder. These don't happen very often so we are okay for now, but a future to-do is to edit the script to keep it from increasing the bias at least until it's tried all phase changes.

Images attached to this report
H1 SQZ
camilla.compton@LIGO.ORG - posted 11:42, Thursday 19 December 2024 - last comment - 14:35, Thursday 19 December 2024(81908)
SCAN_PSAMS.py script ran, PSAMS changed by looking at OAF-RANGE_BAND2 and Range

Camilla, Sheila, Following on from 81852.

Today I re-ran the sqz/h1/scripts/SCAN_PSAMS.py script, with SQZ_MANAGER guardian paused (so it's not forcing the ADF servo on). The script worked as expected (setup by turning off ADF servo and increasing SQZ ASC gain to speed up, then changed ZM PSAMS, waited 120s for ASC to coverage, turned off ASC, scanned sqz angle and saved data and then repeated) and took ~3m30 per step.

The results are attached (heatmap, scans)  but didn't show an obvious direction to move in. Maybe the steps were too small but are already larger than those use at LLO LLO#72749: 0.3V vs 0.1V per step.

Our initial ZM4/5 PSAMs values were 5.6V, -1.1V and looking at the attached data, we took them to 5.2V, -1.5V. We then decided ther range looked better when the PSAMs were higher to went to 6.0V, -0.4Vthis seemed to gain improve the range ~5MPc, we checked by going back to 5.2V, -1.5V and the range again dropped, main change appears to be in orange BAND_2 OMC BLRMs which is 20-34Hz, the places with glitches in OAF BLRMS are noisy times from Robert's injections. Then went further in this direction to 6.5V, 0.0V, this didn't help the range so we are staying at 6.0V, -0.4V, sdf's attached. This seemed to be a repeat-able change that gave us a few MPc's in range! Success for PSAMS: zoomed out and zoomed in plots attached.

Future work: we could run the SCAN_PSAMS.py script with small 0.1V changes as LLO does.

Images attached to this report
Comments related to this report
camilla.compton@LIGO.ORG - 14:35, Thursday 19 December 2024 (81913)

Vicky asked to check the HOM plot and wide plot, don't see a big difference, if anything it's worse with larger HOM peaks after the PSAMS change. We can see that the 20-35Hz in DARM looks a little better,  though this does drift throughout the lock as Sheila showed in 81843.

Images attached to this comment
LHO VE
david.barker@LIGO.ORG - posted 10:27, Thursday 19 December 2024 (81907)
Thu CP1 Fill, issues with Thermocouple-B

Thu Dec 19 10:15:29 2024 INFO: Fill completed in 15min 25secs

Gerardo confirmed a good fill curbside.

TC-B suddenly jumped up in temperature at 04:16 this morning by +15C. Gerardo took a look, both TCs are currently encased in ice (see photo).

TC-mins for today's fill (trip temp = -65C) TC-A = -116C, TC-B = -56C. Which means only TC-A was able to stop the fill by exceeding the trip temp.

Images attached to this report
H1 CAL
thomas.shaffer@LIGO.ORG - posted 09:02, Thursday 19 December 2024 (81906)
Calibration Sweep 1630 UTC

Following the new instructions but on the usual wiki, I ran a broad band and then a new version of simulines like Corey did last week (alog81828).

Simulines start:

PST: 2024-12-19 08:37:18.337770 PST
UTC: 2024-12-19 16:37:18.337770 UTC
GPS: 1418661456.337770

End:

PST: 2024-12-19 09:01:04.771446 PST
UTC: 2024-12-19 17:01:04.771446 UTC
GPS: 1418662882.771446

Files:

2024-12-19 17:01:04,693 | INFO | File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_2024
1219T163719Z.hdf5
2024-12-19 17:01:04,700 | INFO | File written out to: /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_S
S_20241219T163719Z.hdf5
2024-12-19 17:01:04,704 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_S
S_20241219T163719Z.hdf5
2024-12-19 17:01:04,708 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_S
S_20241219T163719Z.hdf5
2024-12-19 17:01:04,712 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_S
S_20241219T163719Z.hdf5
 

H1 CDS
david.barker@LIGO.ORG - posted 07:36, Thursday 19 December 2024 (81904)
VACSTAT BSC3 sensor glitch reset

VACSTAT detected another BSC3 PT132 sensor glitch at 00:53 Thu 19dec2024. I reset vacstat_ioc.service on cdsioc0 at 07:32 to clear it.

Images attached to this report
LHO General
thomas.shaffer@LIGO.ORG - posted 07:34, Thursday 19 December 2024 (81903)
Ops Day Shift Start

TITLE: 12/19 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 157Mpc
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 9mph Gusts, 7mph 3min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.35 μm/s
QUICK SUMMARY: Locked for 17.5 hours, range stable, environment calm. Planned calibration and commissioning today starting at 0830PT (1630UTC).

H1 General
anthony.sanchez@LIGO.ORG - posted 22:12, Wednesday 18 December 2024 (81901)
Wednesday Eve shift End

TITLE: 12/19 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 157Mpc
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY:
H1 has been locked all shift!
A few small earthquakes rolled though and we survived.
Other wise it's been a quiet night.
 

LHO VE (VE)
gerardo.moreno@LIGO.ORG - posted 16:20, Wednesday 18 December 2024 (81900)
Temperature Fluctuations Noted by Vacuum Pressure

Just an FYI, the vacuum pressure is affected by the temperature fluctuations inside the VEA, probably due to warm day(s), see attached plot.  Noted on both Mids.

Images attached to this report
H1 General
anthony.sanchez@LIGO.ORG - posted 16:00, Wednesday 18 December 2024 (81898)
Wednesday Eve shift start

TITLE: 12/18 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 156Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 6mph Gusts, 4mph 3min avg
    Primary useism: 0.06 μm/s
    Secondary useism: 0.38 μm/s
QUICK SUMMARY:
Locked And Observing for 8 minutes.

Notes about IFO config:
EY Ring heater is bumped up 0.1Watts/sec so we have a chance of surviving a a 10K PI ring up. Alog about this: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=81891

 

LHO General
thomas.shaffer@LIGO.ORG - posted 15:54, Wednesday 18 December 2024 (81894)
Ops Day Shift End

TITLE: 12/18 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 155Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Strong wind this morning with gusts into the 50s slowed down locking, but we made it up around the middle of the day. We are running with the EY ring heaters at 1.2W vs their usual 1.1W to avoid PIs. The LVEA was transitioned to laser hazard so Robert could go back out to the floor and check on some beam spots. Relocking was automatic, we've now been locked for 2 hours.

LOG:

Start Time System Name Location Lazer_Haz Task Time End
16:53 SAF LVEA LVEA YES LVEA IS LASER HAZARD 00:38
17:15 PEM Robert LVEA n Moving test setup 17:20
17:39 SAF Oli LVEA n->YES LVEA laser hazard transition 18:04
17:44 PEM Robert LVEA YES Beam spot investigation 19:47
18:06 FAC Tyler, Richard, MacMiller MY, EY n Chiller inspections 18:31
19:48 PCAL Francisco, Dripta PCAL lab local PCAL meas 22:36
H1 General
thomas.shaffer@LIGO.ORG - posted 14:06, Wednesday 18 December 2024 (81897)
Observing 2157UTC

The wind has calmed down and we were able to relock automatically.

We have a new ETMY ring heater setting, so we'll see if PI24 is a problem this time.

H1 CDS
david.barker@LIGO.ORG - posted 12:26, Wednesday 18 December 2024 (81896)
Pico Motor Control MEDMs, motor selection buttons invisible when controller is busy

FRS32910

In alog_81849 Sheila and Camilla found a bug in the picomotor controller code, whereby if the motor to be controlled is changed while the controller is busy with the current move command, the motor change is not accepted resulting in the wrong motor being driven during subsequent commands.

As a quick work around until such time as the code can be fixed, I've made a change to the MEDMs which hides the motor selection buttons when the controller is busy.

Attached screenshots show a test case, left shows the normal situation where the controller is not busy and the selection buttons are all visible. The right screen shows a simulation of the controller being busy (INUSE=1), the selection buttons are replaced by rectangular blocks.

Images attached to this report
LHO VE
david.barker@LIGO.ORG - posted 10:18, Wednesday 18 December 2024 (81893)
Wed CP1 Fill

Wed Dec 18 10:12:11 2024 INFO: Fill completed in 12min 7secs

Today we had low TC mins [-156C,-155C] because of an unusually warm outside air temp of 56F, 14C.

Images attached to this report
H1 ISC (OpsInfo, TCS)
thomas.shaffer@LIGO.ORG - posted 09:11, Wednesday 18 December 2024 (81891)
EY ring heater bumped from 1.1W to 1.2W

To hopefully help combat our recent bouts of PI24 ring ups (alog81890), we've bummped the ETMY ring heater power from 1.1W per segment to 1.2W. The safe.snap and observe.snap are updated.

We also have a plan to update the PI guardian to temporarily increase the ETM bias to hopefully give us more range to damp the PI. We will need to be out of Observing for this, but we could hopefully save the lock. TBD.

Images attached to this report
H1 ISC (Lockloss, SUS)
camilla.compton@LIGO.ORG - posted 09:10, Wednesday 18 December 2024 - last comment - 15:58, Wednesday 18 December 2024(81890)
Three locklosses since 9th Dec from PI24 Ringup

Sheila, TJ, Camilla

We've had 3 locklosses since 9th Dec from PI24 ringing up (10.4kHz on ETMY): last night 81883, Tuesday AM 81862 and the 9th Dec, plot of all.

We had locklosses like this in September after the vent, Oli has a timeline in 80299. We increased the ETMY RH on September 26th 80320 and didn't have any PI locklosses since.

We normally damp this PI during the start of thermalization and successfully damped this after a 13 hours locked on 10th Dec, plot.

We can see a 25Hz wiggle in DARM just before the lockloss, e.g. 81862. The lockloss tool isn't tagging these as DCPD Saturation so we should implement LLO's PI code: Locklost Issue #198

Images attached to this report
Comments related to this report
camilla.compton@LIGO.ORG - 10:46, Wednesday 18 December 2024 (81892)

Plotted is the location of the arm higher order modes around 10kHz. They have moved so that the central frequency is the same as the spikes around 10.4kHz, this excites the PI's more.

  • In the first plot we see that since November and the start of December, the center of the lower HOM peak has drifted down in frequency to be underneath the 10.kHz PI modes: compare black (now) to red and brown.
    • I tried to check more times to see exactly when this change happened in the 4th attached plot but this is tricky as the location and shape of the HOM depends on how warm the IFO is (i.e. was it DOWN a logn time before locking as in ref 7: Cold IFO). It sees like the change started 6th/7th Dec and was done by 10th Dec.
  • In the second plot we see what happened in September when we increased the ETMY Ring Heater (as we repeated today 81891), both HOM peaks moved up in frequency, which is the direction we want.

Maybe an unrelated point is that since the start of October, the circulating arm power has drifted down ~4kW (~1%) from 389 to 285kW when thermalized, plot attached. It's hard to know what's caused this, the IM4 TRANS drifted ~2% but was misaligned so would see alignment shifts 81735, the POP also drifted ~1% before it was recentered 81329. Input power measured by IMC_PWR_IN remained constant.

Images attached to this comment
vladimir.bossilkov@LIGO.ORG - 10:48, Wednesday 18 December 2024 (81895)

You cannot just use L1's lockloss code for the tagging universally [should work for the 10kHz PI though].

Because of the way LHO changed their readouts for the OMC, digging into the simulink model will reveal the PI is reading in only the first 32kHz band, for the RMS calculations

You simply have no aliasing down of the full band to utilise it in the way we do; and it will never see 80kHz PI.
Also your scaling is using calibrated DARM units by the look of things; while we use a counts scale; so the numbers in the RMS readouts are different many orders of magnitude.

thomas.shaffer@LIGO.ORG - 15:58, Wednesday 18 December 2024 (81899)

Very quick shot of the 10.4k homs 2 hours into the first lock with the EY ring heater bumped up to 1.2W from 1.1W. This will need to be checked again later, but it's promising so far.

Images attached to this comment
H1 TCS
camilla.compton@LIGO.ORG - posted 10:29, Tuesday 17 December 2024 - last comment - 10:52, Wednesday 08 January 2025(81863)
CO2 Lasers Spectrum Locked vs Unlocked

Looked at the spectum of th 50W CO2 lasers on the fast VIGO PVM 10.6 ISS detectors when the CO2 is locked (using the laser's PZT) and unlocked/ free running: time series attached. Small differences <6Hz, see spectrum attached. 

The filter banks suggest that the _OUT signals used have been converted from counts to volts and de-whitened. Looking at the spectrum 50Hz -1kHz and using the DC level of 7e-3, we get  a RIN of 4.5e-9 / 7e-3 = 6 x 10-7.
This is better than the L5L free running RIN of 10-5 at 100Hz and 10-6 at 1kHz measured in CIT#389
Images attached to this report
Comments related to this report
camilla.compton@LIGO.ORG - 12:20, Wednesday 18 December 2024 (81868)

Gabriele, Camilla.

We are not sure if this measurement makes sense. 

Attached is the same spectrum with the CO2X laser turned off to see the dark noise. It appears that measurement is limited to dark noise of the diode above 40Hz. The ITMX_CO2_ISS_IN_AC channel dark noise is actually above the level when the laser is on, this doesn't make sense to me. 

  • Is there anything strange happening in models or chassis? No.
    • The filters in the DC _OUT channels include a CountstoVolts gain(0.000610352) and UndoGain gain(0.00196078) which is 1/510 from the PD electronics D1201111 as expected
    • The AC _OUT channel includes a CountstoVolts gain(0.000610352) and de-whiten zpk([20], [0.01], 0.011322, "n").
    • There is nothing else in the h1hsccs model.
    • Looking at the TCS block diagram E1100892, the ISS PD outputs go though the TCS ISS and Interface Chassis D1300649 (D1300015 shows there nothing happening to the signals inside this chassis), before going to the ADC. So the model should see the signals as if they were coming straight from the PD DB9 output + counts to volts gain. 
  • Does DC value of 7e-3 V make sense? Yes.
    • In CIT#389 saw saw -1V (DCMON so gain of 255) for 60mW of laser power (can jump ~by a factor of 2 dependent on wavelength/polarization/how the laser is feeling). From this, expect 1mV from diode (before electronics gain) is 15mW of laser power. So that the DC value measured of 7e-3 V would be around 100mW of power on the PD (within a factor of 2 is 50mW to 200mW). This makes sense as we would expect around 250mW on the ISS PD (50W out of laser x 99/1 BS x 50/50 BS).
  • Does Dark noise value make sense: Unsure.
    • In CIT#541, Gabriele shows DC dark noise values of 4e-7 /rHz, this is straight out of the diode (DCMON so x gain of 255) so the comparable value to our _OUT channels would be 1.5e-9 /rHz. This is a factor of 3 different from the 5e-9/rHz dark value we measure at LHO on the DC OUT.
    • Debatable math: The power noise of the diode is 1e-8 W/rHz (from Keita's computations attached to CIT#549). So the RIN should be noise-limited to 1e-8 W/rHz / 0.250W = 4e-8 /rHz. We are measuring down to 5e-9/rHz on the DC channel which is a factor of 10 lower than expected possible
Images attached to this comment
camilla.compton@LIGO.ORG - 10:52, Wednesday 08 January 2025 (82181)

Gabriele and I checked that the H1:TCS-ITM{X,Y}_CO2_ISS_{IN/OUT}_AC filter: de-whiten zpk([20], [0.01], 0.011322, "n"), is as expected from the PD electronics D1201111, undoing the gain of 105dB with the turning point around 20Hz, foton bode plot attached.

This means that both the AC and DC outputs should be the voltage out of the photodetector before the electronics, where the PD shunt resistance was measured to be 66 Ohms.

Images attached to this comment
H1 PEM (DetChar, PEM, TCS)
robert.schofield@LIGO.ORG - posted 18:06, Thursday 14 November 2024 - last comment - 10:19, Thursday 19 December 2024(81246)
TCS-Y chiller is likely hurting Crab sensitivity

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.

Non-image files attached to this report
Comments related to this report
camilla.compton@LIGO.ORG - 14:12, Monday 25 November 2024 (81472)DetChar, TCS

This afternoon TJ and I placed pieces of damping and elastic foam under the wheels of both CO2X and CO2Y TCS chillers. We placed thicker foam under CO2Y but this did make the chiller wobbly so we placed thinner foam under CO2X.

Images attached to this comment
keith.riles@LIGO.ORG - 08:10, Thursday 28 November 2024 (81525)DetChar
Unfortunately, I'm not seeing any improvement of the Crab contamination in the strain spectra this week, following the foam insertion.

Attached are ASD zoom-ins (daily and cumulative) from Nov 24, 25, 26 and 27.
Images attached to this comment
camilla.compton@LIGO.ORG - 15:02, Tuesday 03 December 2024 (81598)DetChar, TCS

This morning at 17:00UTC we turned the CO2X and CO2Y TCS chiller off and then on again, hoping this might change the frequency they are injecting into DARM. We do not expect it to effect it much we had the chillers off for a ling period 25th October 80882 when we flushed the chiller line and the issue was seen before this date.

Opened FRS 32812.

There were no expilcit changes to the TCS chillers bettween O4a and O4b although we swapped a chiller for a spare chiller in October 2023 73704

camilla.compton@LIGO.ORG - 11:27, Thursday 05 December 2024 (81634)TCS

Between 19:11 and 19:21 UTC, Robert and I swapped the foam from under CO2Y chiller (it was flattened and not providing any damping now) to new, thicker foam and 4 layers of rubber. Photo's attached. 

Images attached to this comment
keith.riles@LIGO.ORG - 06:04, Saturday 07 December 2024 (81663)
Thanks for the interventions, but I'm still not seeing improvement in the Crab region. Attached are daily snapshots from UTC Monday to Friday (Dec 2-6).
Images attached to this comment
thomas.shaffer@LIGO.ORG - 15:53, Tuesday 10 December 2024 (81745)TCS

I changed the flow of the TCSY chiller from 4.0gpm to 3.7gpm.

These Thermoflex1400 chillers have their flow rate adjusted by opening or closing a 3 way valve at the back of the chiller. for both X and Y chillers, these have been in the full open position, with the lever pointed straight up. The Y chiller has been running with 4.0gpm, so our only change was a lower flow rate. The X chiller has been at 3.7gpm already, and the manual states that these chillers shouldn't be ran below 3.8gpm. Though this was a small note in the manual and could be easily missed. Since the flow couldn't be increased via the 3 way valve on back, I didn't want to lower it further and left it as is.

Two questions came from this:

  1. Why are we running so close to the 3.8gpm minimum?
  2. Why is the flow rate for the X chiller so low?

The flow rate has been consistent for the last year+, so I don't suspect that the pumps are getting worn out. As far back as I can trend they have been around 4.0 and 3.7, with some brief periods above or below.

Images attached to this comment
keith.riles@LIGO.ORG - 07:52, Friday 13 December 2024 (81806)
Thanks for the latest intervention. It does appear to have shifted the frequency up just enough to clear the Crab band. Can it be nudged any farther, to reduce spectral leakage into the Crab? 

Attached are sample spectra from before the intervention (Dec 7 and 10) and afterward (Dec 11 and 12). Spectra from Dec 8-9 are too noisy to be helpful here.



Images attached to this comment
camilla.compton@LIGO.ORG - 11:34, Tuesday 17 December 2024 (81866)TCS

TJ touched the CO2 flow on Dec 12th around 19:45UTC 81791 so the flowrate further reduced to 3.55 GPM. Plot attached.

Images attached to this comment
thomas.shaffer@LIGO.ORG - 14:16, Tuesday 17 December 2024 (81875)

The flow of the TCSY chiller was further reduced to 3.3gpm. This should push the chiller peak lower in frequency and further away from the crab nebula.

keith.riles@LIGO.ORG - 10:19, Thursday 19 December 2024 (81902)
The further reduced flow rate seems to have given the Crab band more isolation from nearby peaks, although I'm not sure I understand the improvement in detail. Attached is a spectrum from yesterday's data in the usual form. Since the zoomed-in plots suggest (unexpectedly) that lowering flow rate moves an offending peak up in frequency, I tried broadening the band and looking at data from December 7 (before 1st flow reduction), December 16 (before most recent flow reduction) and December 18 (after most recent flow reduction). If I look at one of the accelerometer channels Robert highlighted, I do see a large peak indeed move to lower frequencies, as expected.

Attachments:
1) Usual daily h(t) spectral zoom near Crab band - December 18
2) Zoom-out for December 7, 16 and 18 overlain
3) Zoom-out for December 7, 16 and 18 overlain but with vertical offsets
4) Accelerometer spectrum for December 7 (sample starting at 18:00 UTC)
5) Accelerometer spectrum for December 16
6) Accelerometer spectrum for December 18 
Images attached to this comment
Displaying reports 3561-3580 of 83100.Go to page Start 175 176 177 178 179 180 181 182 183 End