Displaying reports 181-200 of 83002.Go to page Start 6 7 8 9 10 11 12 13 14 End
Reports until 06:37, Tuesday 24 June 2025
H1 CDS
erik.vonreis@LIGO.ORG - posted 06:37, Tuesday 24 June 2025 (85268)
Workstations updated

Workstations updated and rebooted.  This was an OS packages update.  Conda packages were not updated.

H1 General (CDS)
thomas.shaffer@LIGO.ORG - posted 00:35, Tuesday 24 June 2025 (85267)
Ops Owl Update

The FC TRANS GR (CAM33) camera looks to have crashed or at least the channels for its controls were no longer accessable. The image was still viewable, at least from the screenshots fom. i restarted the process via the browser interface linked from the camera overview and that did the trick. Back to Observing at 0730UTC.

LHO General
ryan.short@LIGO.ORG - posted 22:05, Monday 23 June 2025 (85266)
Ops Eve Shift Summary

TITLE: 06/24 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: TJ
SHIFT SUMMARY: H1 lost lock due to one or more earthquakes this evening and is still working on relocking. Despite everything running smoothly and automatically on the way back up, there was a lockloss for some reason during MAX_POWER as I type this, so H1 will be trying again on its own.

H1 General (Lockloss, SEI)
ryan.short@LIGO.ORG - posted 20:18, Monday 23 June 2025 (85265)
Lockloss @ 03:03 UTC

Lockloss @ 03:03 UTC after almost 6 hours locked - link to lockloss tool

Several quakes rolling through around this time; hard to say which was the real cause but likely a M5.7 in the Caribbean.

LHO VE (VE)
gerardo.moreno@LIGO.ORG - posted 18:06, Monday 23 June 2025 (85264)
HAM1 Pumpdown Update

(Jordan V., Travis S., Gerardo M.)

Up to this morning the volume of HAM1 was being pumped by a turbo pump and an ion pump, we have removed the turbo pump, we closed its isolation valve, but the system remains on (SS500 cart with scroll pump, and turbo pump are still ON).  The turbo pump was isolated to let the ion pump take over the pumping of HAM1, it took a few hours but the ion pump seems to be doing good managing the internal pressure of HAM1, see attached trend, we did have a small anomaly that can be noted on the same trend data, a little spike, we are looking into it.  If the pressure continues to improve, we'll be able to turn off all other auxiliary systems and decouple everything from the turbo pump tomorrow.

 

Images attached to this report
H1 PSL
ryan.short@LIGO.ORG - posted 16:36, Monday 23 June 2025 (85263)
PSL 10-Day Trends

FAMIS 31091

Nothing major to report; things are looking stable this week.

Images attached to this report
H1 General
oli.patane@LIGO.ORG - posted 16:32, Monday 23 June 2025 (85262)
Ops Day Shift End

TITLE: 06/23 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 148Mpc
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY: Currently Observing at 150Mpc and have been Locked for just over 2 hours. Nothing too out of the ordinary today. We had two locklosses, but relocking was relatively straightforward.
LOG:

14:30 Observing at 140Mpc and have been locked for 11 hours
14:54 Out of Observing due to SQZ unlock
15:00 Staying out of Observing to start Commissioning - went to FIS

17:18 Lockloss (85239)
    - Holding in DOWN for a bit while VAC team closes the pump valve for HAM1
    - Running an initial alignment (accidentally did it before the newly mandated 30-60 BS cooling period but it went okay)
18:52 NOMINAL_LOW_NOISE
19:58 Lockloss (85249)
21:23 NOMINAL_LOW_NOISE
21:25 Observing 

Start Time System Name Location Lazer_Haz Task Time End
14:41 FAC Nellie MY n Tech clean 15:29
14:55 FAC Kim MX n Tech clean 15:49
16:13 PCAL Tony PCAL Lab y(local) Packing up PCAL stuff 17:06
16:52 ISC Sheila LVEA n Plugging in a cable (in 10 mins ago) 16:52
17:21 VAC Jordan, Travis LVEA n Closing out pump valve 17:29
20:21 ISC Keita OpticsLab y(local) ISS array 21:37
20:26 FAC Tyler MX n Bees 20:41
21:09   Mitchell, Jason MY n Verifying some stuff 22:20
H1 ISC (ISC, PSL, SYS)
keita.kawabe@LIGO.ORG - posted 16:20, Monday 23 June 2025 - last comment - 16:34, Monday 23 June 2025(85211)
QPD tilt upgrade for ISS array (JennieW, Rahul, Keita)

We're assembling the first unit that incooporates all upgrades including the QPD tilt and here are minor problems we've stumbled upon. (No ISS array unit with an upgrade to tilt the QPD (E1400231) has been assembled before as far as I see and nobody seems to have cared to update all drawings.)

First picture is an example of the QPD before upgrade. QPD assembly (D1400139) and the cable connector assembly (D1300222) are mounted on the QPD platform by the QPD clamp plate (D1300963-v1, an older version) and a pair of split QPD connector clamps (d1300220). Two pieces of kapton insulation sheets are protecting the QPD assy from getting short-circuited to the platform.

After the upgrade, the QPD assy sits on top of a tilt washer (D1400146, called beveled C-bore washer) that tilts the QPD by 1.41deg in a plane that divides YAW and PIT plane by 45 degrees (2nd picture). The bottom kapton will go between the washer and the QPD platform plate.

Problem 1: Insulation between the QPD clamp and the QPD pins is a bit sketchy.

Titled QPD means that the bottom of the QPD assy is shifted significantly in YAW and PIT. A new asymmetric QPD clamp plate with tilted seating for the screws  (D1300963-v2) has been manufactured to accommodate that. But we have no record of updated kapton insulators, so the center of the clamp bore doesn't agree with the kapton (3rd picture, note that the QPD rotation is incorrect in this picture, which had to be fixed when connecting the cable). Since the tilt washer is not captured by anything (it's just sandwiched between the clamp and the platform plate), it's not impossible to shift the QPD assy such that some of the QPD pins will be grounded to the clamp and thus to the QPD platform plate.

You must check that there's no electrical connection between the QPD assy and the platform each time you adjust the QPD position in the lab.

Problem 2: New QPD connector clamp posts are too long, old ones are too short.

Old posts for the QPD connector are 13/16" long, which is too short for the upgrade because of the tilt washer, see 4th picture where things are in a strange balance. It seems as if it's working OK, but you can wiggle the post a bit so the post slides laterally relative to the clamp and/or the platform, it settles to a different angle and suddnly things become loose. To avoid that, you tighten the screws so hard that they start bending (which may be already starting to happen in this picture).

Also, because the clamp positions are 45 degrees away from the direction of tilt, one clamp goes higher than the other.

To address these, somebody procured 1" and 15/16" posts years ago, but they're just too tall to the point where the clamps are loose. If anything, what we need are probably something like 27/32" and 7/8" (maybe 7/8" works for both).

We ended up using older 13/16" posts, but added washers. Two thin washers for the shorter clamp, two thin plus one thick for the taller one (5th picture). This works OK. Shorter screw is the original, longer screw was too long but it works.

Problem 3: It's easy to set the rotation of the QPD wrong.

When retrofitting the tilt washer and the newer QPD clamp plate, you must do the following.

  1. Completely loosen the connector clamps and the QPD clamp to remove the QPD/connector assy as one unit.
  2. Put the tilt washer on top of the kapton insulation sheet at the bottom. The notch mark on the washer must be pointing the 45deg edge of the platform plate (D1300719-v2), see the 6th picture.
  3. Separate the cable connector from the QPD to free the now-obsolete QPD clamp (-v1) that is captured between the QPD and the connector. I inserted a razor blade between the connector and the QPD assy and pried.
  4. Put the assymmetric QPD clamp (-v2) on the top kapton insulation, paying attention to the direction of the new clamp using the 3rd picture as the reference.
  5. Make sure that the rotation of the QPD assy is the same as before because the pins of the QPD are not symmetric. There's no physical mark on the QPD assy itself.
    1. If you're unsure, rotate the QPD assy such that the QPD pins will go to the right sockets on the connector using picture 7. Remember that QPD surface faces the platform down and the drawing of the connector is viewed from the top.
    2. After checking it several times, tighten the QPD clamp.
    3. Put the connector on. Again use picture 7 to put it on at the correct angle.
    4. After checking it several times, tighten the connector clamps.

I screwed up and put the QPD on the connector at a wrong angle. It's easy to catch the error because no quadrant responds to the laser, but it's better not to make a mistake in the first place. It will help if the QPD assy barrel is marked at the cathode-anode1 corner.

It seems that D1300222 and D1101059 must be updated. Systems people please have a look.

D1300222: A tilt washer (D1400146), a new QPD clamp (D1300963-v2) and two sheets of kapton insulation are missing. Spacers are longer than 13/16".

D1101059: Explicitly state that part #28 (D1300963, QPD clamp) must be D1300963-v2.

Images attached to this report
Comments related to this report
keita.kawabe@LIGO.ORG - 16:34, Monday 23 June 2025 (85261)

I installed the beam dumps (which are two plates of filter glass, probably from Schott?) for the array after cleaning them according to E2100057.

There are marks that look like water spots and/or some fog that couldn't be removed by repeated drag wiping with methanol (see picture).

After installation, I found that these plates are very loosely captured between two metal plates, see the video, this seems to be by design. I don't like it but the same design has been working in chamber for years.

Images attached to this comment
Non-image files attached to this comment
LHO General
ryan.short@LIGO.ORG - posted 16:04, Monday 23 June 2025 (85260)
Ops Eve Shift Start

TITLE: 06/23 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 126Mpc
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 10mph Gusts, 4mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.06 μm/s
QUICK SUMMARY: H1 has been locked for 1.5 hours.

H1 SQZ
camilla.compton@LIGO.ORG - posted 14:26, Monday 23 June 2025 (85258)
OPO Trans setpoint reduced from 95uw to 80uW

Sheila reduced the OPO Trans setpoint from 95uw to 80uW (our nominal from before the break), we hope this will make the SQZ less sensitive to chosen angle. She readjusted OPO temp and measured NLG to still be around 8 to 9. We are not sure why this has dropped since last week but she noticed pump depletion when measuring the NLG when the setpoint was at 95uW.

H1 TCS (DetChar-Request)
camilla.compton@LIGO.ORG - posted 13:20, Monday 23 June 2025 - last comment - 11:58, Thursday 26 June 2025(85247)
2Hz Comb in DARM from ITMX HWS Camera?

Ansel, Sheila, Camilla

Last week, Ansel noticed that there is a 2Hz comb in DARM since the break, similar to that that we've seen from the HWS camera sync frequency and power supplies and fixed in 75876.  The cabling has not been changed since, the camera sync frequency has been changed.

Our current camera sync frequencies are: ITMX = 2Hz, ITMY = 10Hz. We have typically seen these combs in H1:PEM-CS_MAG_LVEA_OUTPUTOPTICS_Y_DQ. With a 0.0005Hz BW on DTT I can't easily see these combs, see attached.

Images attached to this report
Comments related to this report
evan.goetz@LIGO.ORG - 13:31, Monday 23 June 2025 (85254)DetChar
It may be difficult to see in a standard spectrum, but can be clearly seen in Fscan plots linked off of the summary pages. For the "observing" Fscan, the interactive spectrum plot shows the 2 Hz comb marked automatically. See the attached image of H1:GDS-CALIB_STRAIN_CLEAN
Images attached to this comment
camilla.compton@LIGO.ORG - 17:04, Tuesday 24 June 2025 (85306)

Verifed that the cabling has not changed since 75876.

Next steps we should follow, as listed in 75876 would be to try using a different power supply or lowering the voltage to +12V. Or, there is a note suggesting Fil could make a new cable to power both the camera and CLink's via the external supply (14V is fine for both). 

evan.goetz@LIGO.ORG - 18:30, Tuesday 24 June 2025 (85312)DetChar
Thanks Camilla. If anything can be done more rapidly than waiting another week, it would be very much appreciated. Continuing to collect contaminated data is bad for CW searches.
camilla.compton@LIGO.ORG - 15:11, Wednesday 25 June 2025 (85341)

Matt and I turned down the Voltage supplied from 14V to 12V for each camera at ~22:00UTC when the IFO was relocking. Verified HWS cameras and code still running.

We also will plan to have Dave reimpliemnt the hws_camera_control.py script he wrote in 74951 to turn the HWS's off in Observing until we fix this issue.

kiet.pham@LIGO.ORG - 11:58, Thursday 26 June 2025 (85361)

The 2 Hz comb is still present in H1:GDS-CALIB_STRAIN_CLEAN after the voltage change (before the software update)

Images attached to this comment
H1 General (Lockloss)
oli.patane@LIGO.ORG - posted 12:59, Monday 23 June 2025 - last comment - 14:26, Monday 23 June 2025(85249)
Lockloss

Lockloss at 2025-06-23 19:58 UTC. A commissioner was running a jitter noise injection at the time of the lockloss, but doesn't think that was the cause of the lockloss.

Comments related to this report
elenna.capote@LIGO.ORG - 13:24, Monday 23 June 2025 (85253)

The DARM signals look very noisy just before the lockloss because I was injecting jitter noise. I don't think that caused the lockloss. The tool is tagging this as "ETM GLITCH" which I also think is wrong because the extra noise was bringing the DARM signal above threshhold for the glitch checker.

oli.patane@LIGO.ORG - 14:26, Monday 23 June 2025 (85257)

21:25 UTC Back to Observing

H1 ISC
elenna.capote@LIGO.ORG - posted 10:52, Monday 23 June 2025 - last comment - 15:53, Monday 23 June 2025(85246)
20 minutes of X corr data taken

We took 20 minutes of no-squeezing data for a cross correlation measurement today. I ran a script to collect the full 524 kHz data from DCPD A and B. The data is currently saved in 1 second hdf5 frames in /ligo/home/elenna.capote/OMC_DCPD/252306-092558_xcorr_data

Comments related to this report
elenna.capote@LIGO.ORG - 15:53, Monday 23 June 2025 (85259)

I was able to read in each 1 second frame and generate a gwpy timeseries for each DCPD data set that I then saved as a single .gwf file. I also used the gwpy resample function to decimate the data to 64k so there is a smaller version. Both sets of files are saved in the same directory and can be read in with gwpy, which should also include metadata with sample rate, gps start, and channel name.

H1 SQZ
camilla.compton@LIGO.ORG - posted 10:08, Monday 23 June 2025 - last comment - 13:19, Monday 23 June 2025(85237)
SQZ FIS Data set
Sheila, Camilla

After Kevin did some 10kHz SQZ ADF scans, we look some SQZ FIS data. The best ASQZ and SQZ didn't look as good as usual, but we found our NLG was low. We didn't check the NLG first so that we had a direct comparison to Kevin's dataset.

Roughly following 83594 with slightly different data taken.

DTT saved as camilla.compton/Documents/sqz/templates/dtt/20250623_FIS.xml and screenshot attached.

Type Time (UTC) Angle DTT Ref
FIS Mean SQZ 15:53:00 - 15:56:00 N/A ref 1
FIS + Mid SQZ (aimed +7dB @1kHz) 15:58:30 - 16:01:30 (-) 242 ref 2
FIS - Mid SQZ (aimed +7dB @1kHz) 16:03:00 - 16:06:00 (-) 94 ref 3
FIS ASQZ 16:08:30 - 16:11:30 (-) 63 ref 4
FIS SQZ 16:13:30 -16:16:30 (-) 122 ref 5
No SQZ 16:26:00 -  16:46:00 N/A ref 0
 
Checked while in NO SQZ, also adjusted the SHG pump waveplates to reduce the HAM7 rejected power, but I did this less than a week ago:
OPO Setpoint Amplified Max Amplified Min UnAmp Dark NLG OPO Gain Note
95uW 0.001504 6.71 e-5 0.0002828 -2.52e-5 4.9 -8 Without changing OPO temp
95uW 0.002317 8.69e-5 0.0002828 -2.52e-5 7.5 -8 With changing OPO temp

Last week 85000, NLG was measured to be 18.9, now it's measured to be <8. We will look into why is it low.

Ran SCAN_SQZANG_FDS before doing a CO2 step.

Images attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 13:19, Monday 23 June 2025 (85252)

 I measured the NLG with a few different opo pump powers to follow up on Camilla's observation that the NLG was low. 

OPO trans power [uW] maximum minimum nlg
95 2.26e-3 8.195e-5 8.5
80 2.25e-3 8.795e-5 8.2
60 1.902e-3 8.866e-5 6.93

dark level 2e-5, unamplified 2.914e-4

I tried to lower the seed power to see if we have some pump depletion making us underestimate the NLG, but the half wave plate was already set to minimize the seed power.

Since the NLG looks to be about the same with 80 uW as 95uW, I set it to 80 uW for now. 

H1 ISC (GRD)
elenna.capote@LIGO.ORG - posted 16:15, Monday 16 June 2025 - last comment - 14:14, Monday 23 June 2025(85098)
Update to MOVE_SPOTS to speed things up

Ryan S., Elenna

Thge MOVE_SPOTS state is taking 13 minutes (!) to complete, because the YAW3 ADS DOF is very far off and taking a significant time to converge. Both Jenne and I have found that bumping up the YAW3 gain (PRM yaw) slowly helps converge the loops much faster.

Ryan kindly helped me update the state code to slowly increase the gain if the convergence is taking too long. We added a new timer 'ADS', that waits for one minute after the new A2L gains are ramped (so an additional minute after the 2 minute ramp time of the A2L gains). If, after that first minute, there is still no convergence, then the YAW3 gain is doubled. After that, the 'ADS' timer waits 2 minutes, and again doubles the gain. This process can happen up to three times, which should increase the YAW3 gain to a maximum value of 8. Jenne and I have found that the gain can go as high as 10 in this state. The two minute waits give the other ASC, like SRC1 and INP1 Y time to converge as the ADS pulls the PRM in faster. Once the convergence checker returns true, the YAW3 gain is set back to 1.

We will monitor how this proceeds on this locking attempt. I updated the guardian notify statements so it states when the gain is increased.

Comments related to this report
elenna.capote@LIGO.ORG - 16:42, Monday 16 June 2025 (85101)

This was a sucess- this run through took only 7 minutes. I am shortening the 2 minute wait before increasing the gain to 90 seconds. If that still works, maybe we can go to 60 seconds.

elenna.capote@LIGO.ORG - 09:58, Tuesday 17 June 2025 (85119)

To be more specific, the first attempt as described above meant the state took 6 minutes, 50 seconds. I loaded the change to reduce the wait time from 120 to 90 seconds, which only shortened the state length to 6 minutes, 30 seconds. The gain was only ramped to 8 for a very short period of time. I still think we can make this shorter, which we can do by making that wait time 60 seconds, and maybe taking bigger steps in the gain each time. However, we are still in the RCG upgrade, so I will hold off on changes to the guardian for now.

YAW3 is still limiting the length of the state. In this morning's relock, YAW3 convergence took nearly an additional minute more than the other loops. Once we have caught YAW3 up to everything else, we could make the state even shorter by raising the gain of other ADS loops. Two minutes of the state are taken up in the ramp of the A2L gain, so it is taking an additional 4 minutes, 30 seconds to wait for loop convergence.

elenna.capote@LIGO.ORG - 14:14, Monday 23 June 2025 (85256)

Now it seems that PIT3 is taking too much time to converge, so I updated the guardian to also increase the PIT3 gain in the same way.

H1 SUS (SEI, SUS)
edgard.bonilla@LIGO.ORG - posted 12:34, Thursday 22 May 2025 - last comment - 13:50, Monday 23 June 2025(84531)
M1 SR3 OSEM calibration [revisited]

Oli, Edgard, Jeff, Brian

This post is meant to give a clearer explanation of the work in [LHO:84296] and its many comments. We are trying to find a new set of gains for the M1_OSEMINF filter banks for SR3 to calibrate the OSEMs to be in agreement with the HAM5 GS13s.

To do so, we drive the HAM5 ISI in { X , Y , Z } and record the response of the relevant OSEMs between 5 to 15 Hz.  At these frequencies, the M1 stage of the suspension should start to become inertial, and the M1_DAMP / SUSPOINT response of each individual OSEM should asymptote to -1, because the OSEMs would be measuring their support point on the cage [barring internal dynamics of the cage itself].

To increase the accuracy of the calibration, we use the MATLAB model of the HLTS and use the full extent of the 5-15 Hz data instead of only the asymptotic behavior.

I post here the code used to generate these results. The code requires the new Common/MatlabTools/ExportedModels folder from the SusSVN [LHO:84458]. The detailed results of the calibrations mentioned is shown below.

_____

Images attached to this report
Non-image files attached to this report
Comments related to this report
edgard.bonilla@LIGO.ORG - 17:06, Tuesday 27 May 2025 (84605)SUS

Adding hera a few bits of information that were missing from the original post, together with an updated version of the script.

_______________________________________________________________________

To compensate for the OSEM gain changes, we estimate that the H1:SUS-SR3_M1_DAMP loops must be changed by a factors of:
L gain = 0.743 * (old L gain)
T gain = 0.724 * (old T gain)
V gain = 0.549 * (old V gain)
R gain = 0.549 * (old R gain)
P gain = 0.691 * (old P gain)
Y gain = 0.743 * (old Y gain)

The calibration will change the apparent alignment of the suspension as seen by the at the M1 OSEMs
NOTE: The actual alignment of the suspension will NOT change as a result of the calibration process

The changes are computed as (osem2eul) * gain * inv(osem2eul).
Using the alignments from 2025-05-07_0000 (UTC) as a reference, the new apparent alingments are:

DOF    Previous value     New value       Apparent change
---------------------------------------------------------------------------------
L          -4.3 um                 -2.6 um                     +1.7 um
T          -19.7 um              -14.2 um                 +5.4 um
V          -24.0 um              -8.4 um                   +15.6 um
R          -490.6 urad          -219.3 urad          +271.4 urad
P          -300.2 urad          -203.8 urad          +96.5 urad
Y          -569.3 urad          -422.5 urad          +146.8 urad

Non-image files attached to this comment
edgard.bonilla@LIGO.ORG - 18:21, Tuesday 27 May 2025 (84607)SUS

Here I post the coherence and transfer functions between the excitations of HAM5 in X, Y, and Z to the SUSPOINT degrees of freedom.

The band from 5-10 Hz seems to be low enough amplitude that I think we can claim that the drives are clean enough in the SUSPOINT basis to perform the calibration.

Note that the high coherence between L/T and HAM5_ISO X/Y is expected, since the SR3 euler basis does not perfectly align with the cartesian basis of HAM5.

 

 

Images attached to this comment
jeffrey.kissel@LIGO.ORG - 13:50, Monday 23 June 2025 (85255)
J. Kissel (for O. Patane and E. Bonilla)

Also during this barrage of measurements, Oli and Edgard gathered Open Loop Gain (IN1/IN2), Loop Suppression (IN2/EXC), and Closed Loop Gain (IN1/EXC) tfs under the presence of DAMP_EXC. 

Within the templates mentioned below, there're two data sets.
The "New OSEMINF gains" data is with with the above mentioned
    H1:SUS-SR3_M1_OSEMINF_T1_GAIN  3.627
    H1:SUS-SR3_M1_OSEMINF_T2_GAIN  1.396
    H1:SUS-SR3_M1_OSEMINF_T3_GAIN  1.345
    H1:SUS-SR3_M1_OSEMINF_LF_GAIN  1.719
    H1:SUS-SR3_M1_OSEMINF_RT_GAIN  1.490
    H1:SUS-SR3_M1_OSEMINF_SD_GAIN  1.781

The "OG OSEMINF gains" data is with the OSEMINF gains that have been present throughout O4 (as they were reverted post-measurement) 
    H1:SUS-SR3_M1_OSEMINF_T1_GAIN  1.478
    H1:SUS-SR3_M1_OSEMINF_T2_GAIN  0.942
    H1:SUS-SR3_M1_OSEMINF_T3_GAIN  0.952
    H1:SUS-SR3_M1_OSEMINF_LF_GAIN  1.302
    H1:SUS-SR3_M1_OSEMINF_RT_GAIN  1.087
    H1:SUS-SR3_M1_OSEMINF_SD_GAIN  1.29

The raw .xmls for both these data is 
    /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/SAGM1/Data/
        2025-05-21_1800_H1SUSSR3_M1_WhiteNoise_L_0p02to50Hz_OpenLoopGainTF.xml
        2025-05-21_1800_H1SUSSR3_M1_WhiteNoise_P_0p02to50Hz_OpenLoopGainTF.xml
        2025-05-21_1800_H1SUSSR3_M1_WhiteNoise_R_0p02to50Hz_OpenLoopGainTF.xml
        2025-05-21_1800_H1SUSSR3_M1_WhiteNoise_T_0p02to50Hz_OpenLoopGainTF.xml
        2025-05-21_1800_H1SUSSR3_M1_WhiteNoise_V_0p02to50Hz_OpenLoopGainTF.xml
        2025-05-21_1800_H1SUSSR3_M1_WhiteNoise_Y_0p02to50Hz_OpenLoopGainTF.xml

The open loop gain transfer functions (IN1/IN2) have already been exported
    /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/SAGM1/Data/
        2025-05-21_1800_H1SUSSR3_M1_WhiteNoise_?_0p02to50Hz_OpenLoopGainTF_tf.txt     << exports of "OG OSEMINF gains" data

        2025-05-21_2000_H1SUSSR3_M1_WhiteNoise_L_0p02to50Hz_OpenLoopGainTF_tf.txt     << exports of "New OSEMINF gains" data

Also, I've exported the loop suppression of the "OG OSEMINF gains" data as
    /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/SAGM1/Data/
        2025-05-21_1800_H1SUSSR3_M1_WhiteNoise_?_0p02to50Hz_OLGTF_LoopSuppression_tf.txt     << exports of "OG OSEMINF gains" data
H1 SUS (ISC)
evan.hall@LIGO.ORG - posted 17:14, Tuesday 26 July 2022 - last comment - 13:18, Monday 23 June 2025(64152)
New HLTS local damping filters installed & turned on

Elenna, Evan

We installed new damping filters for PR3 and SR3 M1, largely following Jeff's "Level 2" filter designs (G1400151). In general these filters give less sensor noise injection, especially around 10–20 Hz.

For all DOFs, the filters are arranged as follows:

Both configurations use an EPICS gain of −1 in all DOFs. If more damping is needed, the new configurations should be tolerant to a 10 dB gain increase at least, and as a last resort the old configurations can be restored as described above.

OLTFs of the old (gold) and new (red) configurations are shown for PR3. The changes were accepted into SDF for PR3 and SR3.

Step responses showed somewhat less damping than the old design, but no mode seemed egreiously underdamped. Since PR3 and SR3 are not controlled by ISC or ASC, this should not result in any loop stability issues. When doing step responses I noticed glitching whenever I sent signal to the SR3 M1 T1 coil, even with the damping loops off (DAC glitch?).

Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 10:48, Wednesday 27 July 2022 (64173)CSWG, DetChar, ISC
Jeff Kissel loves this. Look at that factor of 40 dB / x100 improvement in yaw at 10 Hz!
I'm also glad to see a bounce / roll filter installed as well; I didn't have that in my model. 
Hopefully these are still tuned to the specific HLTS with work we did in ~2019.

I appreciate that all gains are set to -1.0 per convention. 
Can you cover the details of where you've stuck the per-DOF gain scaling to match the open loop gain of the model? 
Perhaps in the norm_${DOF} bank?
evan.hall@LIGO.ORG - 11:00, Wednesday 27 July 2022 (64174)

The norm filters in FM5 are unchanged. I tried to match the old and new OLTF gains around 3 Hz, which is roughly where we place the upper UGFs. I did this by hand-tuning the overall gain of the rolloff filters in FM1. I kept the dc/ac gains of the boosts equal to unity as best I could, and the dc gains of the elliptic filters equal to unity.

jeffrey.kissel@LIGO.ORG - 13:04, Thursday 15 December 2022 (66389)
I've copied over the templates for these measurements from
    /ligo/home/evan.hall/Desktop/stuff/
to a standard sharable location, committed to the SusSVN,
    /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/PR3/SAGM1/Data/
        2022-07-26_1820_H1SUSPR3_M1_WhiteNoise_L_0p02to50Hz_OpenLoopGainTF.xml
        2022-07-26_1820_H1SUSPR3_M1_WhiteNoise_P_0p02to50Hz_OpenLoopGainTF.xml
        2022-07-26_1820_H1SUSPR3_M1_WhiteNoise_R_0p02to50Hz_OpenLoopGainTF.xml
        2022-07-26_1820_H1SUSPR3_M1_WhiteNoise_T_0p02to50Hz_OpenLoopGainTF.xml
        2022-07-26_1820_H1SUSPR3_M1_WhiteNoise_V_0p02to50Hz_OpenLoopGainTF.xml
        2022-07-26_1820_H1SUSPR3_M1_WhiteNoise_Y_0p02to50Hz_OpenLoopGainTF.xml


Of course, the amplitude and frequency dependence of excitation for this open loop gain style TF depends on the damping filter you're driving through, so I can't speak to how Evan changed this during the measurement; there doesn't seem to be two excitation options in the template. I would guess that the excitation amplitude / frequency dependence saved in the template works for the current (red trace) data, thus driving through the new "Level 2" filters. So, don't assume that the amplitudes / frequency dependence will work through the old filters; the old filters clearly have much more gain at most frequencies, so I would start by reducing the drive amplitude.
jeffrey.kissel@LIGO.ORG - 13:18, Monday 23 June 2025 (85251)
I've exported the loop suppression from this 2022-07-26_1820 data set, they're now committed as
    /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/PR3/SAGM1/Data/
        2022-07-26_1820_H1SUSPR3_M1_WhiteNoise_L_0p02to50Hz_OLGTF_LoopSuppression_tf.txt
        2022-07-26_1820_H1SUSPR3_M1_WhiteNoise_P_0p02to50Hz_OLGTF_LoopSuppression_tf.txt
        2022-07-26_1820_H1SUSPR3_M1_WhiteNoise_R_0p02to50Hz_OLGTF_LoopSuppression_tf.txt
        2022-07-26_1820_H1SUSPR3_M1_WhiteNoise_T_0p02to50Hz_OLGTF_LoopSuppression_tf.txt
        2022-07-26_1820_H1SUSPR3_M1_WhiteNoise_V_0p02to50Hz_OLGTF_LoopSuppression_tf.txt
        2022-07-26_1820_H1SUSPR3_M1_WhiteNoise_Y_0p02to50Hz_OLGTF_LoopSuppression_tf.txt
Displaying reports 181-200 of 83002.Go to page Start 6 7 8 9 10 11 12 13 14 End