Displaying reports 521-540 of 84421.Go to page Start 23 24 25 26 27 28 29 30 31 End
Reports until 13:05, Thursday 14 August 2025
H1 AOS (DetChar)
riley.mcneil@LIGO.ORG - posted 13:05, Thursday 14 August 2025 (86368)
DQ Shift August 4-10

DQ shifters: Riley McNeil and Emil Lofquist-Fabris

See full report here: https://wiki.ligo.org/DetChar/DataQuality/DQShiftLHO20250804

H1 SEI (ISC)
jim.warner@LIGO.ORG - posted 11:46, Thursday 14 August 2025 - last comment - 12:28, Tuesday 19 August 2025(86364)
Good test of the high asc gain earthquake state this morning

This morning a 6.2 magnitude earthquake near Vanuatu happened during the commissioning window, so we tested the asc gain reversion scripts Elenna came up with in this alog. It took a little longer than I would have liked to get the scripts working, so we didn't actually transition until basically the peak ground velocities, but the transition went pretty smoothly. I think this eq is tied for the biggest  we stayed locked through for all of O4.

Attached image shows ground velocities on the top row (both peakmon and the ITMY Z STS 30-100mhz blrms, second row is the ISC_LOCK state, third and fourth show channels related to the asc transition. Fourth row is the first gain changed by the script CHARD Y, the third row is the SRCL FF gain, which is the last thing changed in the script. The dashed white vertical lines on the CHARD trace and the top row ground traces show the time the transition took to complete.

Even if the transition was a little late I think that this test likely still saved the lock, I have often seen on eqs like this that the IFO stays locked through the peak ground motion, but loses lock some time shortly after, while the eq is still ringing down.

There is still a lot of work to be done as the transition is currently handled by a couple of scripts on the ISI_CONFIG overview medm and the transition will knock us out of Observe, still unclear what the best way to automate this would be, but still a pretty good test.

Images attached to this report
Comments related to this report
jenne.driggers@LIGO.ORG - 15:22, Thursday 14 August 2025 (86369)

It's been remarkable and wonderful to see how well we've been surviving earthquakes lately!

This is such a big win, that I suggest we not worry too much about if this pops us out of Observing.  If we're able to automate saving the lock, and then going back to Observe when the ground motion is compatible with our usual loops, that's already a huge leap forward on improving our duty cycle.  

elenna.capote@LIGO.ORG - 12:28, Tuesday 19 August 2025 (86449)

I have updated ISC LOCK guardian and LSCPARAMS to have the gains for the lownoise ASC and length feedforwards as parameters in LSCPARAMS. Then, TJ helped me figure out how to import LSCPARAMS into these two scripts so it draws those gains from the parameters instead of having them hardcoded. This way, if we decide to update a feedforward or ASC gain, it will also be updated for the earthquake script.

This script also changes ASC filters, but an update to have those filters as parameters in LSCPARAMS is a much more involved change to ISC_LOCK, so I have to think about that one a bit. That means if we change ASC filters, we have to remember to update this script, for now.

LHO VE
david.barker@LIGO.ORG - posted 10:46, Thursday 14 August 2025 (86362)
Thu CP1 Fill

Thu Aug 14 10:08:28 2025 INFO: Fill completed in 8min 24secs

 

Images attached to this report
H1 SQZ
camilla.compton@LIGO.ORG - posted 10:08, Thursday 14 August 2025 - last comment - 13:03, Thursday 14 August 2025(86361)
Mid SQZ Data for 5kHz HOM Spacing with ZM4 Yaw alignment changes
Sheila, Camilla
 
We saved  H1:OMC-DCPD_524K_A2_IN1 data with the PD sum after Sheila changed the matrix as in 85937. DTT saved as /ligo/home/camilla.compton/Documents/sqz/templates/dtt/20250814higher_order_modes.xml screenshot attached.
Interestingly we could reduce the size of the 5kHz modes by changing ZM4 YAW alignment, at the nominal alignment and the alignment that reduced the 5kHz modes most, we also took mean sqz data, the nominal alignment had a slightly better mean SQZ.
 
Starting angle is (-)133, took SQZ_ANG SERVO to DOWN. After each step of ZM, we changed SQZ angle to get level back to 4dB ASQZ, as our 5kHz modes look clearest here.
To get mean sqz, pause SQZ_MANAGER, SQZ_LO_LR to DOWN and ADF off. Should have misaligned the FC but we didn't.
 
Type Time (UTC) Angle DTT Ref Notes
SQZ 15:54:00 - 15:59:00 (-)133 ref 0 While taking CAL measurements
FDS Mid - SQZ 16:01:30 - 16:04:00 (-)105 ref 1  
FDS Mid SQZ, -50urad pit +3deg 16:07:30 - 16:09:30 (-)109 ref 2  
FDS Mid - SQZ 16:10:30- 16:12:30 (-)111 ref 3 Redid at 4dB ASQZ
FDS Mid SQZ, -50urad yaw 16:14:30 - 16:16:30 (-)114 ref 4  
FDS Mid SQZ, +50urad yaw 16:17:45 - 16:19:45 (-)109 ref 5  
FDS Mid SQZ, +100urad yaw 16:21:30 - 16:23:30 (-)106 ref 6  
FDS Mean SQZ, +100urad yaw 16:26:00 - 16:28:00 N/A ref 7  
FDS Mean SQZ, 16:29:00 - 16:31:00 N/A ref 8  
No SQZ
16:37:00 - 16:57:00
N/A
ref 9
took 1500 avg (~10mins)
 
Took above data at NLG of 16.4, checked the NLG 76542, it's a lot better since we adjusted the pump alignment on Tuesday 86323. Then increased NLG to 37 to see if this will improve SQZ.
OPO Setpoint Amplified Max Amplified Min UnAmp Dark NLG Note
80 0.1121155 0.001849 0.0068192 -1.16e-5 16.4 Without Optimizing Temp
90 0.257827 0.001813     37.7  
Images attached to this report
Comments related to this report
camilla.compton@LIGO.ORG - 13:03, Thursday 14 August 2025 (86363)
Sheila, Elenna, Camilla
 
Tested if SQZ was any better with the higher NLG, see attached, it wasn't although we did have good ASQZ of 19dB. We will revert OPO setpoint to 80uW
 
Type Time (UTC) Angle DTT Ref SQZ
No SQZ
16:37:00 - 16:57:00
N/A
ref 0
 
ASQZ NLG 37 17:43:30-17:46:30 (-)81 ref 1, 10 19dB
SQZ NLG 37 17:51:00-17:54:00 (-)141 ref 2, 11 -4.5dB

 Took more 5kHz/10kHz data with the NLG at 37 (effects of HOM easier to see). DTT saved as /ligo/home/camilla.compton/Documents/sqz/templates/dtt/20250814higher_order_modes.xml

In the first set of data, Elenna added an offset to DHARD, we didn't see a change at 5kHz but there was a change at 10kHz that was debatably repeatable.
In the second set of data, Sheila added an offset to SRCL1, we saw a big change at 5kHz but no change at 10kHz, see attached at 5kHz and 10kHz.
 
Type Time (UTC) Angle DTT Ref Notes
No SQZ
16:37:00 - 16:57:00
N/A
ref 0
 
ASQZ NLG 37 17:43:30-17:46:30 (-)81 ref 1, 10  
SQZ NLG 37 17:51:00-17:54:00 (-)141 ref 2, 11  
Mid SQZ 18:00:30 - 18:02:30 (-)118 ref 12  
Mid SQZ +4cts DHARD PIT 18:06:30 - 18:08:30 (-)118 ref 13 Difference only at 10k? Repeat
Mid SQZ 18:09:30 - 18:11:30 (-)118 ref 14  
Mid SQZ +4cts DHARD PIT 18:12:30 - 18:14:30 (-)118 ref 15  
Mid SQZ -4cts DHARD PIT 18:15:45- 18:17:45 (-)118 ref 16  
Mid SQZ +4cts DHARD YAW 18:19:30 - 18:21:30 (-)118 ref 17 No difference seen
Mid SQZ SRM YAW 1urad (offset 0.3) 18:28:00 - 18:30:00 (-)120 ref 18 Big difference at 5kHz, none at 10kHz
Mid SQZ SRM YAW -1urad (offset -0.3) 18:33:30 - 18:35:50 (-)114 ref 19 Got better
Mid SQZ SRM YAW -2urad (offset -0.6) 18:41:30 - 18:43:30 (-)108 ref 20 Overshot, got worse, mode didn't flip
Mid SQZ SRM YAW -1.5urad (offset -0.45) 18:46:30 - 18:48:30 (-)108 ref 21  
Mid SQZ 18:52:00 - 18:52:00 (-)118 ref 22 Back to nominal
 
Took OPO setpoint back to 80uW and remeasured NLG to be 22.4. It is interesting that before the SQZT0 pump alignment 86323 we had much worse NLG even with the same OPO trans setpoint and spot on the crystal. This doesn't make sense to us.
OPO Setpoint Amplified Max Amplified Min UnAmp Dark NLG Note
80 0.153078 0.002067 0.0068192 -1.16e-5 22.4 With Optimizing Temp
Images attached to this comment
H1 CAL
thomas.shaffer@LIGO.ORG - posted 09:18, Thursday 14 August 2025 (86359)
Calibration Sweep 1530 UTC

Running another calibration measurement today following the usual broadband and simulines.

Simulines Start:

PDT: 2025-08-14 08:36:33.095985 PDT
UTC: 2025-08-14 15:36:33.095985 UTC
GPS: 1439221011.095985

Simulines End:

PDT: 2025-08-14 08:59:53.303431 PDT
UTC: 2025-08-14 15:59:53.303431 UTC
GPS: 1439222411.303431
 

Files:

2025-08-14 15:59:53,136 | INFO | File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DAR
MOLG_SS_20250814T153633Z.hdf5
2025-08-14 15:59:53,145 | INFO | File written out to: /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/
PCALY2DARM_SS_20250814T153633Z.hdf5
2025-08-14 15:59:53,150 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/
SUSETMX_L1_SS_20250814T153633Z.hdf5
2025-08-14 15:59:53,156 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/
SUSETMX_L2_SS_20250814T153633Z.hdf5
2025-08-14 15:59:53,161 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/
SUSETMX_L3_SS_20250814T153633Z.hdf5
 

Images attached to this report
Non-image files attached to this report
LHO General
thomas.shaffer@LIGO.ORG - posted 07:38, Thursday 14 August 2025 (86358)
Ops Day Shift Start

TITLE: 08/14 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 153Mpc
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 2mph Gusts, 0mph 3min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.10 μm/s
QUICK SUMMARY: Observing for 4 hours, automated relock. Environment is calm. The only active alarm is the known vacuum PT242B pressure. Planned calibration and commissioning time today 1530-1930 UTC.

LHO General
ryan.short@LIGO.ORG - posted 22:03, Wednesday 13 August 2025 (86357)
Ops Eve Shift Summary

TITLE: 08/14 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 153Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Very quiet shift with H1 observing throughout, despite a couple hours of high winds blowing through with gusts briefly over 40mph. There's a M5.6 quake inbound from the South Pacific, but the EQ response tool just places it in the lower bound of the "earthquake" region. H1 has now been locked for 14.5 hours.

X1 SEI (ISC)
jeffrey.kissel@LIGO.ORG - posted 18:50, Wednesday 13 August 2025 (86350)
SPI In-vac SuK Fiber Collimator Beam Profile Before vs. After Bake
J. Kissel

Recall the SPI pathfinder is pathfinding more than just the future fully assembled sensor array's roll in improving seismic isolation, but also -- at a low-level -- pathfinding some new individual types optomechanical components for LIGO. This aLOG covers the latest in the path for the Schaefter + Kirchhoff (SuK) fiber collimators.

The first of SPI's Schaefter + Kirchhoff (SuK) fiber collimators (DCC:S0272502, ICS:S0272502) is now Class B clean after having gone through one round of massaging with isopropyl alcohol and air-baking (see CNB:2187), at the planned time and levels for the future Class-A vacuum-bake (peak temp 85 [deg C]; ramp up 6 hours, hold for 48 hours, ramp down for 6 hours).

The first open question was "will the lens remain intact and undamaged through the bake." the definitive answer: YES -- the lens remained whole and, at least visually, without defect.
While I didn't use a optical fiber microscope, the lens appears very much intact with no obvious cracks or glinting. See the attached Visual Inspection.

Next up was to check it's optical performance as (hopefully) a more quantitative measure of performance change (hopefully not peformance degradation).
Prior to the bake, I'd set the lens position on the collimator to achieve some level of collimation, and characterized the beam profile -- see LHO:84825.
After the bake, I used the same characterization setup -- augmented only to keep the now Class-B fiber collimator clean (see LHO:86299) -- to remeasure the beam profile to see if the collimator still projected the same beam quantitatively. 

The beam remains as I had collimated it, with the waist within 100 [cm] of the prebake position.
I did *not* adjust the tuned "before" pre-bake lens position at all prior to taking the "after" data.

Check out the 2025-08-07_spifc_S0272502_beamprofile_fit.pdf attachment. 
    - First page compares the two data sets, X axis (parallel to the optical table surface plane) on the top panel, and Y-axis (perpendicular to the optical table plane) on the bottom panel. You can see that the change in waist position / size is 
        Using Delta = (2025-08-06)' - (2025-06-03), and % Diff = [(2025-08-06)' - (2025-06-03)]/(2025-06-03)

        z0x' - z0x = +0.0544 [m] (+4% difference)
        z0y' - z0y = -0.1103 [m] (-8% difference)

        w0x' - w0x = -12.14 [um] (1.3% difference)
        w0y' - w0y = -10.17 [um] (1.1% difference)
Excellent. 

Because the X waist position moved in +Z, and the Y waist position moved in -Z, the beam has become a bit more astigmatic. This is evident in the "Far Field" projection of the model on pages 3 and 5. But, given that the measurement setup is limited with the furthest data point being z(meas_max) - z0 ~ 5.41 [m] - 1.4 [m] ~ 4.0 [m] away from the waist, I wouldn't claim that the measurements perfectly constrain the far-field behavior. Recall we *want* the waist to be at z=0, at the fiber collimator and this collimator's lens position was *not* tuned to that simply because of user error. I'm fully confident I *can* set the lens position such that the waist *is* at the fiber collimator, and after doing so the 5.41 [m] NanoScan position will get a bit more "in to" the far field, which will hopefully better constrain the model, and thus get a better handle on how astigmatic the beam gets after baking (or even *if* it gets consistently astigmatic).

If we define the dimensionless astigmatism parameter, A, as the (zRx - zRy) difference in Rayleigh range, divided by the (zRx + zRy) sum (with the Rayleigh range defined by the fit waist, zR = pi * w0^2 / lambda), then the change (% Difference) in astigmatism is only
    2025-06-03    A  = +2.3983
    2025-08-06    A' = +2.3409 

    (A' - A)/A       = 0.02494 = 2.5%
which seems totally tolerable from pre- to post-bake. Regardless, for the remaining to collimators that we've yet to bake, we'll be setting the collimation (lens position) post-bake anyways, so how it changes across a bake is moot.
Whether the absolute value of A ~ +2.35 is tolerable an open question, that we'll work to answer in the mean time.

Pages 2 and 4 show the model zoomed in to the data between z = 0 and 6 [m]. Here you can also see that the fit doesn't *perfectly* match the data their either, so there's another systematic grain of salt to take with the assessment of change.

Minor note: I was not consistent with the orientation of the collimator w.r.t. to the optical table surface; I oriented the collimator 90-deg from the 2025-06-03 vs 2025-08-06 data (because I found out / rediscovered that the 2025-08-06 position is how you align the p-pol transmission with the optical table; see Figure 5 of T2400413). I've flip-flopped the X and Y axes data for the waist size in the 2025-06-03 data to account for this (which is why the careful reader would notice a difference between this entry's version of the 2025-06-03 results from that in LHO:86342).

But -- all in all -- this looks good enough! 

I've taken these results to indicate that we can move forward with the full Class-A clean-and-bake. 

All three collimators, (S0272502, S0272503, S0272504) in the queue now -- see CNB:2243.
Non-image files attached to this report
H1 SQZ (ISC, OpsInfo, SQZ)
ryan.short@LIGO.ORG - posted 18:45, Wednesday 13 August 2025 - last comment - 12:09, Thursday 14 August 2025(86356)
Removed NO_SQUEEZING Requests from ISC_LOCK and Added "ignore_SQZ" Flag

In consultation with Sheila, I've added a new flag in lscparams.py called "ignore_sqz" (currently set to False) which when True, removes SQZ_MANAGER from ISC_LOCK's managed nodes list and sets up ISC_LOCK such that no requests are made of SQZ_MANAGER. I've additionally removed all instances of ISC_LOCK requesting SQZ_MANAGER to 'NO_SQUEEZING.'

The motivation for this stems from an issue encountered earlier this week (alluded to in Monday's shift summary) where after H1 dropped observing from the SQZ PMC having to relock, SQZ_MANAGER eventually stalled (which is not unexpected) and ISC_LOCK then requested it to 'NO_SQUEEZING' for a then-not-well-understood reason. After looking into the frequently used "unstall nodes" decorator in ISC_LOCK, I learned that the revive function it calls simply requests the stalled subordinate node to whatever its last requested state was. The catch here is that the last requested state refers only to what the manager's last request was to the subordinate, not whatever request a user, other node, or standalone script may have made, as the manager node has no way of knowing about requests outside of its own. A discrepancy between a manager node's last request to a subordinate and a different request to that subordinate can be seen with a notification on the manager saying the subordinate's request changed.

My understanding of the sequence of events that led to the confusion on Monday is that commissioners had been working with the squeezer and wanted its Guardian manager node to remain in 'NO_SQUEEZING' while H1 was relocking following their work. In its design at the time, in a few different states such as 'INJECT_SQUEEZING', ISC_LOCK would check the status of SQZ_MANAGER, and if it was in 'NO_SQUEEZING', move on with the state and re-request SQZ_MANAGER to 'NO_SQUEEZING'. This makes SQZ_MANAGER's manager's last request 'NO_SQUEEZING', so when SQZ_MANAGER later stalled, it was requested back to 'NO_SQUEEZING' even though a user had set SQZ_MANAGER to its nominal state sometime later. This is why I've removed requests to 'NO_SQUEEZING' in ISC_LOCK; I believe it's a sound assumption that if SQZ_MANAGER is in 'NO_SQUEEZING', someone wants it there and Guardian should just move on. Further, this makes it so that the only request ISC_LOCK ever makes to SQZ_MANAGER is its nominal state (except in 'DOWN', of course, which would then later get updated to the nominal), meaning there should be no confusion as to what its last request was.

Changes have been saved and committed to svn, but ISC_LOCK has not yet been loaded. This should be done at the next drop from observing.

Comments related to this report
thomas.shaffer@LIGO.ORG - 12:09, Thursday 14 August 2025 (86367)OpsInfo

We loaded this and tested going to and from ISC_LOCK's Inject_Squeezing state with the SQZ manager in No_Squeezing and FREQ_DEP_SQZ. All worked well.

If we ever need to go to observing without squeezing, we should keep this in mind as I'm not 100% confident we won't get some manager confusion depending on when we do the transition. We'll cross that bridge when we get to it though.

H1 General (DetChar)
oli.patane@LIGO.ORG - posted 16:38, Wednesday 13 August 2025 (86355)
Ops Day Shift End

TITLE: 08/13 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 152Mpc
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY: Observing at 151 Mpc and have been Locked for over 9 hours. Nothing really happened today besides the calibration commissioning from earlier.

We don't think it affected anything, but at 20:48 UTC, we had a staff member in a car drive up to the LVEA receiving door, idle there for 5 minutes, and then drive away at 20:53UTC, so I'm tagging detchar in case we see anything weird in the data during that time.
LOG:

14:30UTC Just got to NOMINAL_LOW_NOISE
    14:32 Observing
    15:30 Out of Observing for calibration measurements
    15:30 NLN_CAL_MEAS
    16:01 NOMINAL_LOW_NOISE
    16:12 NLN_CAL_MEAS
    16:43 NOMINAL_LOW_NOISE
    17:41 NLN_CAL_MEAS
    18:12 NOMINAL_LOW_NOISE
    18:20 NLN_CAL_MEAS
    18:30 NOMINAL_LOW_NOISE
    18:31 Observing
    20:48 Staff member in car driving up to receiving and idling
    20:53 Car drove away from receiving

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

Start Time System Name Location Lazer_Haz Task Time End
  LASER LVEA is LASER HAZARD LVEA YES LVEA IS LASER HAZARD  
16:10 VAC Travis MY n Checking on pump status 17:16
16:46   Christina, Nichole MY n 3IFO inventorying 20:10
17:16 VAC Travis, Anna MY n Leak checking 18:30
21:02 SPI Tony PCAL Lab y(local) SPIing 22:32
21:57 FAC Tyler MX, EX n Inventory 23:27
23:32   Betsy OpticsLab n   23:47
LHO General
ryan.short@LIGO.ORG - posted 16:00, Wednesday 13 August 2025 (86353)
Ops Eve Shift Start

TITLE: 08/13 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 150Mpc
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 22mph Gusts, 11mph 3min avg
    Primary useism: 0.05 μm/s
    Secondary useism: 0.11 μm/s
QUICK SUMMARY: Windy, smokey, and hot afternoon on site, but so far H1 has been locked for 8.5 hours following commissioning time this morning.

X1 SUS (SUS)
rahul.kumar@LIGO.ORG - posted 15:44, Wednesday 13 August 2025 (86347)
PSAMS (for HxDS with a Piezo-SAMS payload) assembly and characterization at CIT for O5

Camille Makarem (CIT), Rahul

Last week at CIT we assembled and tested four units of PSAMS (Piezo-SAMS payload - Piezo-deformable Mirrors for Active Mode Matching). These four fully assembled PSAMS are shown in attachment01 and attachment02 and they will be shipped to LLO for O5 HPDS assembly and installation in HAM6. Given below are the test results of the PSAMS payload - PZT actuation and the desired radius of curvature of the mirror at 100V.

1. Optic  E2100053, Type A2, s/n - 02 - PZT voltage tested from 0 to 200V, Pre-load set to 32 in. lbs at 100V DC, RoC = 2.42 m

2. Optic E2100053, Type A1, s/n - 01 - PZT voltage tested from 0 to 200V, Pre-load set to 32 in. lbs at 100V DC, RoC = 5.76 m

3. Optic E2100053, Type B2, s/n - 01 - PZT voltage tested from 0 to 200V, Pre-load set to 30 in. lbs at 100V DC, RoC = 2.41 m

4. Optic E2100053, Type B1, s/n - 03 - PZT voltage tested from 0 to 200V, Pre-load set to 28 in. lbs at 100V DC, RoC = 5.63 m

The Strain gauge readout results will be posted later on. 

PSAMS assembly details and issues (faced) are discussed below,

a.  Attachment03 shows the PZT with five lead wires. We looked into the vendor data to identify + HV PZT (the side which has been marked with dots) and PZT ground (non dotted side). The other 3 leads belong to the Strain Gauge (SG). We crimped pins to all five leads - as shown in attachment04. The wire pins were then pushed into the 7 pin Glenair might mouse connector (MM 803-003-02M6-7PN-598A) - as shown in attachment05. We also used a PEEK zip tie to secure the wires on the PZT stack. We followed D2000383 for the wiring chain diagram.  

b. During the assembly we did not have vendor data to identify the leads for the strain gauge, hence we connected the wires based on the spare units at CIT (which lead to some confusion as the two spare units internal wiring contradicted each other). As per D2000382, the bridge excitation should be connected to pin 1 on the might mouse connector and GND should be at pin 3, strain signal on pin 6. In reality we connected the GND to pin1, strain signal to pin6 and +V bridge excitation to pin 3 (basically pin 1 and pin 3 are inverted).  Later (post assembly), Camille acquired the vendor data for identifying the leads for the strain gauge, which is shown here. After discussing this with Jeff Kissel and Daniel, we concluded that this should not affect the working of the SG - however for future assembly we should use the latest vendor data.

c. The PZTs, washers and the deformable mirror were all stacked vertically (as per T2400260) and torqued as per specification - see pictures for reference here - attachment05, attachment06, attachment07attachment08 and full assembly shown in attachment09.

d. Electrical testing - we followed E2100371 to confirm the electrical connections for the PZT voltage and strain gauge readout - test set up shown in attachment10 and attachment11.

e. RoC measurement on ZYGO interferometer - after successfully testing and confirming the working of the PZT actuation we started measuring the Radius of Curvature (RoC) of the optic on the ZYGO interferometer - see attachment12, attachment13 and attachment14 for details of the setup - fringes observed as shown here, as an example. The final numbers (pre-load and the RoC for each mirror) are posted above.

We wanted to capture few things which we faced during the assembly and testing and this will help for assembling future units. These are listed below,

1. Tangless helicoils for mirror mounting - we used tanged helicoils for mirror mounting, however breaking the tang after the assembly was very unsafe for the mirror. Hence, we had to unmount the mirror from the flexure mirror holder, break the tangs and then re-mount the mirror (which involves heating and cooling them). Hence, we would recommend to use tangless helicoils only.

2. We struggled to attach D1900097 to D1900123 since the threads were bad on D1900097. Don got us a 1''-32 size tap from McMaster to chase the threads, however I could only chase a few of them - enough to assemble four units. The threads on the other 6 units (D1900097) at CIT were extremely difficult to chase hence we included it in our future to-do list of things (might have to be made dirty again for proper chasing).

3. PEEK zip tie for wire lacing inside the PSAMS - the old PSAMS used viton ring to lace the PZT electrical leads, this has now been replaced with PEEK zip tie. We were not very convinced with this, as the viton ring felt easier to use and more secure for the wires.

4.  We spent a lot of time trying to understand and interpret the correct wiring diagram - initially Fabrice's FDR and Luis's document contradicted each other. To add to the confusion, the already built unit at CIT (two spare psams, with two different cables and might mouse connections) wiring also contradicted each other. However (long story short), after talking to Fil and Marc at LHO we were able to sort it. We had to change the 18V power supply to the PZT driver D2000555, since the exciting one was faulty. Also, Dean (at CIT) made some quick checks on the PZT driver to confirm that it was healthy. However the most important thing to note over here is as follows - the two spare units at CIT, ZM2 and ZM5 (from the previous build) have wiring diagrams different from the design (I think for ZM2), hence this needs to be checked before future use. 

Camille as noted down the serial number of the parts used during this assembly and they are listed here.

Images attached to this report
H1 ISC
anthony.sanchez@LIGO.ORG - posted 15:05, Wednesday 13 August 2025 (86349)
DRMI locking histograms Pre & Post ReflAir changes

5 day increments.
I chose 5 days before June 16th because on June 16th there was a ReflAir Phase change, and 5 days later there was another change to ReflAir phasing.
So given a window of 5 days in between 2 changes I chose 5 days before, 5 days between changes, and DRMI after the last change for 5 days.

Images attached to this report
H1 SQZ
camilla.compton@LIGO.ORG - posted 14:49, Wednesday 13 August 2025 (86352)
ZM4 Strain Gauge Minimum Value Slightly Drifting

Leo, Camilla

Leo noticed when comparing the data we took in July 85917 to last years OMC scans with different ZM curvature settings 80010, that the minimum value ZM4 can reach has changed. Over ~ an hour or so, the strain gauge can drift around 0.1V, their total ranges are 7.7V so maybe these changes of 0.2/7.7=2.5% are not too surprising.

H1 CAL (ISC)
elenna.capote@LIGO.ORG - posted 11:50, Wednesday 13 August 2025 - last comment - 16:42, Wednesday 13 August 2025(86344)
Calibration measurements at three ESD biases

Today, we measured the calibration at three different ESD biases. First, we measured at the current bias of 269 V, and then our O4 standard bias of 136 V. Then, I stepped up to a higher bias of 409 V.

ESDAMON value Bias Offset L3 Drivealign gain Calibration report Notes
269 V 6.0542453 88.28457

alog: 86337

report: 20250813T153848Z

only 1 hour thermalized at measurement time

current operating bias

136 V 3.25 198.6643

alog: 86339

report: 20250813T162026Z

nominal O4 bias, calibration model fit at this bias
409 V 8.89 57.587

alog: 86341

report: 20250813T174921Z

ESD saturation warnings while at this bias

Took 5 minutes of quiet time, cal lines on, at this new bias

start: 18:12:54 UTC

end: 18:18:00 UTC

The attached plot compares the three broadband measurements at each ESD bias. It seems like the overall systematic error decreases as we increase the ESD bias.

To step up the ESD bias, I used guardian code that Sheila attached to this alog. Another relevant alog comparing simulines results at different biases is here.

Images attached to this report
Comments related to this report
francisco.llamas@LIGO.ORG - 14:25, Wednesday 13 August 2025 (86346)

Attaching figures comparing the sensing function, the actuation function, and the open loop gain (olg). All the figures are formatted in the same way, where the left side shows the bode plot from each report and the right shows the bode plot from of each measurement ratio to a reference. I used the latest exported calibration measurement "20250719T225835Z" as a reference. From 10 Hz to 1 kHz the sensing and the actuation function residuals are within 5%. The OLG is within 10% with one outlier at 410 Hz.

Images attached to this comment
elenna.capote@LIGO.ORG - 16:42, Wednesday 13 August 2025 (86354)

We are trying to understand how the systematic error is changing at each bias voltage, even though we think we are correcting the drivealign gain to account for the actuation change.

Francisco and I made some plots of how the modeled error changes. First, we pulled the model from the 20250719T225835Z report, since that is our current calibration model. Then, we pulled the kappas at the time of the lowest bias voltage measurement, since that is the bias voltage that our model is based on. We applied the kappas from that measurement time, and then calculated a new response function assuming an additional TST actuation change, ranging from no change (0%) to 1.5% change. Then, we compared each of these response functions to the kappa-corrected model.

To be clear, we are calculating the new response function as:

R = 1/C_model + (error_factor*TST_model + PUM_model + UIM_model) * D_model

The "model" in this case also has the kappa-corrected values applied, which are:

{'c': 0.98335475,
 'f_c': 447.65558,
 'uim': 1.0052187,
 'pum': 1.0012773,
 'tst': 1.0183398}

Looking at our results side-by-side with the broadband pcal measurement, we see some similarites. However, it's not exactly the same, since the frequency dependence appears slightly different in the measurement than the model.

There are some other comparisons to be made, but we can start with these. The script I used to make this plot is saved in /ligo/groups/cal/H1/ifo/scripts/compare_models_tst_err.py

Images attached to this comment
LHO VE (DetChar, VE)
travis.sadecki@LIGO.ORG - posted 11:50, Wednesday 13 August 2025 - last comment - 10:16, Thursday 28 August 2025(86345)
BTRP adapter flange and GV installed at MY

Similar to alog 86227, the BTRP adapter flange and GV were installed on Tuesday at the MY station.  Leak checking was completed today with no signal seen above the ~e-12 torrL/s background of the leak detector.  

Pumping on this volume will continue until next Tuesday, so some additional noise may be seen by DetChar.  This volume is valved out of the main volume, so the pressure readings from the PT-243 gauges can be ignored until further notice.  

Comments related to this report
anna.iudintseva@LIGO.ORG - 14:04, Wednesday 13 August 2025 (86351)
Here are the first and the last pictures of the leak detector values.
The max was 3.5 * 10-12. 90% of the time it stayed at <1 *10-12.
Images attached to this comment
travis.sadecki@LIGO.ORG - 13:30, Tuesday 19 August 2025 (86453)

As of Tuesday, August 19, the pumps have been shut off and removed from this system, and the gauge tree valved back in to the main volume.  Noise/vibration and pressure monitoring at MY should be back to nominal.

janos.csizmazia@LIGO.ORG - 15:33, Tuesday 19 August 2025 (86462)
The pumping cart was switched off, and the dead volume was valved back in to the main volume. The pressure dropped rapidly to ~5E-9 within a few minutes, and it continues to drop.

Also, we (Travis & Janos) added some more parts (an 8" CF to 6" CF tee; CF to ISO adapters, and an ISO valve) to the assembly, and also added a Unistrut support to the tee; see attached photo. Next step is to add the booster pump itself, and anchor it to the ground.
Images attached to this comment
janos.csizmazia@LIGO.ORG - 08:27, Thursday 28 August 2025 (86606)
LOTO was applied now both to the handlers of the hand angle valve and the hand Gate Valve.
Images attached to this comment
H1 AOS
camilla.compton@LIGO.ORG - posted 12:33, Tuesday 22 July 2025 - last comment - 13:11, Friday 22 August 2025(85917)
SQZT7 Beam Profiling with different ZM4 and ZM5 PSAMS Settings

Leo, Jennie, Camilla, WP 12694

Jennie followed instructions for set up in 85775. We removed the SQZ beam iris at the bottom of the LPM (added for alignment capture during OFI vent work). Then took beam profiles in this SQZ path of the SEED beam with various PSAMS settings, adjusted PSAMS settings as in 85775 and used the servo for nominal settings. All data is attached. Jennie then reverted settings back to nominal.

Non-image files attached to this report
Comments related to this report
leendert.schrader@LIGO.ORG - 12:01, Thursday 14 August 2025 (86365)
Leo, Jennie W., Camilla

The attached pdf contains all the beam q parameters fitted to the collected beam width data. Only the 13.5% data was fitted, as the D4S data was too inconsistent to obtain confident q values.

Fitting was performed with the a la mode beamPath.fitBeamWidth function. 
The attached q parameters were individually plotted using a la mode and verified for their data-fitting accuracy.

As mentioned in the document, all q parameters are located immediately after the interaction with ZM5 (through the view of BM4 -> ZM4 -> ZM5 beam travel).
Non-image files attached to this comment
leendert.schrader@LIGO.ORG - 13:11, Friday 22 August 2025 (86519)
Leo, Jennie W., Camilla

Attached is a plot of the q manifold from the q parameter data, which allows for characterizing the beam smoothly with respect to ZM4/5 strain gauge voltage values.
The image is taken from the presentation uploaded to T2500228. The real plot will likely have slightly different labels to axes.

Link to git code for plotting: https://git.ligo.org/leendert.schrader/alm-beam-simulation-for-sqz/-/tree/main

Images attached to this comment
Displaying reports 521-540 of 84421.Go to page Start 23 24 25 26 27 28 29 30 31 End