J. Kissel Dimensions of Glenair picomotor mightmouse connector for Science.
No obvious cause, looks very fast.
Since the HAM1 vent, I have done a few different measurements of the ASC that provide information on how to calibrate WFS signals from counts to microradians. Here is a summary:
CHARD, INP1 and PRC2 results come from this alog
DHARD results come from this alog
SRM results come from this alog (if you are comparing values, I made a power normalization error in the linked alog)
BS results were taken but never alogged (shame on me)
All of these measurements were taken by notching all ASC loops at 8.125 Hz and injecting an 8.125 Hz line in the desired DoF. The osem wits provide the urad reference.
Unless otherwise specified, the witness channels are the bottom stage osems
| DoF | Input Matrix | Calibration | Notes |
| CHARD P | -1 * REFL A 45 I + 0.6 * REFL B 45 I |
0.0161 urad [ETMY L2] / ct [REFL A 45 I] 0.0109 urad [ETMY L2] / ct [REFL B 45 I] |
measured as ETMY L2 wit, must transform to L3 urad, can also convert to cavity angle coherence near 1 |
| CHARD Y | -1 * REFL A 45 I + 0.8 * REFL B 45 I |
0.0113 urad [ETMY L2] / ct [REFL A 45 I] 0.00965 urad [ETMY L2] / ct [REFL B 45 I] |
measured as ETMY L2 wit, must transform to L3 urad, can also convert to cavity angle coherence near 1 |
| DHARD P | 0.5 * AS A 45 Q - 0.5 * AS B 45 Q |
0.00312 urad [ETMX L2] / ct [AS A 45 Q] 0.00312 urad [ETMX L2] / ct [AS B 45 Q] |
measured as ETMX L2 wit, must transform to L3 urad, can also convert to cavity angle coherence = 0.8, 10 averages |
| DHARD Y | 0.5 * AS A 45 Q - 0.5 * AS B 45 Q |
0.00612 urad [ITMY L2] / ct [AS A 45 Q] 0.02 urad [ITMY L2] / ct [AS B 45 Q] |
measured as ITMY L2 wit, must transform to L3 urad, can also convert to cavity angle coherence = 0.5, 10 averages |
| PRC2 P (PR2) | 1 * POP X RF I | 0.00033 urad / ct | coherence 1 |
| PRC2 Y (PR2) | 1 * POP X RF I | 0.000648 urad / ct | coherence 1 |
| INP1 P (IM4) |
1.5 * REFL A 45 I + 1 * REFL B 45 I |
0.0104 urad / ct [REFL A 45 I] 0.00988 urad / ct [REFL B 45 I] |
coherence 1 |
| INP1 Y (IM4) | 2 * REFL A 45 I + 1 * REFL B 45 I |
0.0141 urad/ct [REFL A 45 I] 0.00608 urad/ct [REFL B 45 I] |
coherence 1 |
| MICH P (BS) | 1 * AS A 36 Q | 0.0161 urad [M2]/ct | measured as BS M2 WIT/AS A 36 Q, must transform into M3 urad, coherence near 1 |
| MICH Y (BS) | 1 * AS A 36 Q | data not taken | |
| SRC1 P (SRM) | 1 * AS A 72 Q | 16.9 urad/ct | coherence near 1 |
| SRC1 Y (SRM) | 1 * AS A 72 Q | 10.6 urad/ct | coherence near 1 |
Here is data for MICH yaw and SRC2:
| DoF | Input Matrix | Calibration | Notes |
| MICH Y | 1 * AS A 36 Q | 0.00248 urad [BS M2] / ct | measured as BS M2 WIT/AS A 36 Q, must transform into M3 urad |
| SRC2 P (SRM + SR2) | 1 * AS_C |
33.4 urad [SR2 M3] / ct 44.7 urad [SRM M3] / ct |
SRC2 drive matrix is a combination of SRM and SR2: -7.6 * SRM + 1 * SR2 |
| SRC2 Y (SRM + SR2) | 1 * AS_C |
20.9 [SR2 M3] / ct 48.8 [SRM M3] /ct |
SRC2 drive matrix is a combination of SRM and SR2: 7.1 * SRM + 1 * SR2 |
Continuing my efforts to check and update the LSC coupling (see 86423 and 86370) I ran yet another bruco, which showed that now the dominant low frequency coherence is coming from SRCL.
In review, I have:
I think we can do better. The main challenge is fitting the <100 Hz coupling while fitting the >100 Hz coupling, or at least not significantly worsening it. I think the fit would be easier if we made use of the parallel SRCLFF banks to fit a low and high frequency feedforward. This would require fitting the low frequency coupling, engaging it, and then remeasuring the high frequency coupling to fit separately.
I have what I think is a better fit to the low frequency coupling, currently saved in FM5 of the SRCLFF1 bank. To test this new filter:
Time permitting, if the new filter works, taking a better measurementing of the coupling from 100 Hz and up while on the new filter would be a useful next step, which may require adjusting the excitation shape or increasing the excitation gain.
To motivate the use of commissioning time on this, I did a very simple coherence based subtraction of the SRCL noise to see what it could get us in range improvement. I used the same time as the bruco I linked above, so this time includes the PRCL and MICH improvements. I copied some of Oli's range compare code to help me generate this nice plot comparing 1 hour of strain with coherence subtraction of the SRCL noise. Even if we can't improve the feedforward above 100 Hz, there is possible a 2 Mpc improvement from below 100 Hz.
Wed Aug 20 10:09:36 2025 INFO: Fill completed in 9min 32secs
Gerardo confirmed a good fill curbside.
While fixing a hydrant on the backside of the OSB/vertex area, fire pump 1 was activate from 1725-1742UTC. Hanford FD pickup truck and our F150 were also back in that area. Their driving to and from that area, as well as some of their work showed up on our ITMY seismometer.
TITLE: 08/20 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 152Mpc
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 3mph Gusts, 1mph 3min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.07 μm/s
QUICK SUMMARY: Locked for 11.5 hours, no alarms, calm environment. Looks like we dropped Observing at 1053-1057UTC because the SQZr lost lock and relocked.
Our range isn't as stable as it has been lately, and the Omicron glitch gram FOM shows some extra SNR around 20-30Hz during those times.
HFD are working on a hydrant, Tyler has requested the fire_pump alarms be bypassed for the next two hours.
Bypass will expire:
Wed Aug 20 12:31:32 PM PDT 2025
For channel(s):
H0:FMC-CS_FIRE_PUMP_1
H0:FMC-CS_FIRE_PUMP_2
TITLE: 08/19 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY:
Shift started out with Elenna & Jenne troubleshooting H1 due to locklosses at DHARD WFS post-Maintenance. Elenna was eventually able to get H1 past the rough DHARD/CARM Offset steps of ISC_LOCK. H1 was then able to get back to Observing (please see Elenna's alog for more info---Elenna mentioned, as she was leaving for the night, that this was an issue similar to what she saw after the recent HAM1 vent.).
Violins were elevated on this lock, but once High Power Damping settings were started, most modes were damped down pretty fast. ETMy M1 was slow, so I helped it out a little (nominal gain is -0.1 for ETMy Mode1, and I have it at -0.2 and will leave it here for the night since it continues to damp this one nicely.
LOG:
This morning the In-Lock SUS Charge Measurements ran. Attached are the plots for all four Test Masses. Closing FAMIS 28419.
We had a 2 second square wave sensor glitch in PT100. Its pressure jumped from 1.7e-07 to 3.7e-07 Torr for 2 seconds and then jumped back.
VACSTAT sent cell phone texts to team-VAC due to this single gauge event, because HAM1 is separated from the rest of the vertex and is therefore exempt from the 2-gauges-in-alarm filter.
VACSTAT was restarted at 21:26 and I took the opportunity to bring MY's PT124B back into the system.
VACSTAT all green again.
After Elenna left (and made a summary alog), H1 made it to OBSERVING. To get here, I ACCEPTED new ASC SDFs (see attached).
Violins are elevated after today's Maintenance, but once DAMPING came on, they are mostly all sharply dropping.
Bi-weekliy stats for a few locking sequences for the bast 14 days.
ALS: max Duration 28 Min
Average 4.79 Min
% above 5 minutes 32.07
Date range: 2025-08-06 02:28:40 to 2025-08-20 02:28:40
DRMI [18-101]: max Duration 57 Min
Average 13.68 Min
% above 5 minutes 54.90
Date range: 2025-08-06 02:29:42 to 2025-08-20 02:29:42
CARM: [120 -428] - max Duration 29 Min
Average 5.28 Min
% above 5 minutes 18.42
Date range: 2025-08-06 02:30:51 to 2025-08-20 02:30:51
Powerup [429-590]: max Duration 46 Min
Average 21.633 Min
% above 30 minutes 63.33
Date range: 2025-08-06 02:32:18 to 2025-08-20 02:32:18
We kept losing lock at DHARD WFS, and Jenne and I spent a lot of time figuring out why. Here are some notes about things that we tried:
How I solved the problem:
Some final notes about minor mistakes I made after:
Apologies for missing this detail in my original alog, but we had run two successful initial alignments. The first was run as usual after the end of the maintenance day. Green alignment converged properly, arm alignment looked good. We ran a second after the early problems with DHARD, thinking that maybe the alignment was poor. Same results, good green convergence, but problems with DHARD.
In general, the alignment of the arms and corners looked very good through this whole process. When I stepped in DHARD P and Y, I was making very small steps overall to correct the alignment, steps on the order of 0.01 or 0.03. In general, the buildups and the camera showed good alignment. The green arms also stayed well aligned when the DHARD signal engaged properly, which is telling me that our initial alignment was doing the correct thing for the ITMS. Is it possible that the CARM offset was too large? I have been wondering this, because if the alignment was decent but the WFS signal was junk because we were too far from resonance that might explain this behavior, and it lines up with the fact that the better fix was reducing the carm offset more before moving to REFL. I'm not sure if that makes sense though.
As a side note, DRMI was mostly locking very quickly throughout the night.
TJ, Ryan S, Elenna
Today we (once again) took some time to try to commission the PRM ASC loop in PRMI ASC.
We locked PRMI, and I engaged the beamsplitter ASC. I was able to see by moving PRM pitch around, and watching the buildups, that the "old" error signal, REFL A RF9 I, was a great error signal and only required a sign flip.
However, PRM yaw was harder. I checked REFL A and B RF9 I and neither signal worked. I checked POP X I next, and saw that the signal worked just fine. This doesn't make a lot of sense, but it works. I updated the guardian accordingly.
To test that the guardian changes work, we brought the ISC_DRMI guardian down, which unlocked PRMI, and re-requested PRMI ASC. We fixed a few guardian errors and tried again. It worked fine.
These are the changes made:
Loaded and tested!
Rereading this, I realized that saying it "didn't work" is very vague.
More words:
I stepped around with the PRM slider, watching both the POP18 and POP90 buildups. While watching the buildups, I looked to see when various signals crossed zero. For PRM pitch, REFL A 9 I clearly had a good zero crossing at the maximized buildup. The difference was the sign flip, which I tested by turning on the loop and seeing the error signal go the wrong direction (away from zero), and then the right direction (towards zero) when the gain sign was flipped. To maintain the gain sign as set by the guardian, I flipped the sign on the input matrix value from positive (pre-vent value) to negative.
For PRM yaw, the REFL signals did not cross zero when the buildups were maximized. However, the POP X RF signal did cross zero. I also watched the POP QPDs, which are sensitive to PRM, but also require some offset. I decided setting some offset and trying to use the REFL WFS was probably a bad idea, so I chose POP X RF yaw as the error signal. I calibrated it by measuring the signal difference in counts compared to the sliders steps I took, which are in urad. I checked the overall sign using the similar loop engagement test I described above.
Leo, Jennie, Camilla
Followed setup instructions from 80010, with 75mW injected in the SEED beam, we had 1mW on OPO_IR_PD_DC slightly lower than last time. Also took SQZ_FC to FC_MISALIGNED. And opened SQZ beam divertor and fast shutter. Have counts of ~60 on ASC-AS_A and B and 7e-4 on ASC-OMC-A and B NSUMs. Jennie took the OMC PZT down to zero to start and then ran a template userapps/../omc/h1/templates/OMC_scan_sqz_beam.xml.
Repeated mode scans with different ZM PSAMs offsets, the DC centering loops could account for the pitch change for PSAMs, for the extreme PSAMS values, I increased the servo limiter from 85 to 95.
Jennie and Leo have the data to analyze.
See the ndscope with the channels we used to monitor attached.
This template is saved in /ligo/home/jennifer.wright/Documents/OMC_scan/20250819_SQZ_beam_scan_with_ZM_changes.yaml
Following up on these OMC scans: attached is the table with all computed mode-mismatch values.
Leo, Jennie W., Camilla
Below is a plot of the OMC scans fitted with a surface polynomial.
The plot is from the presentation in T2500228, so the labels on axes will be different.
This can be plotted on Matlab simply using the following code block (requires Curve Fitting Toolbox to use fit()).
OMCX = [5.5, 4, 2.3, 3, 8.1, 2.3, 2.3, 6, 9.5, 6, 6, 9, 3, 8, 4, 9.5, 9.5];
OMCY = [-0.8, 0.34, 0.2, 0.85, -0.4, -0.1, 0.2, -0.4, -0.6, -4.5, -5.3, 2, 2, -2, -2, -5, -0.6];
OMCdata = [1-4.048/100, 1-3.412/100, 1-3.074/100, 1-3.234/100, 1-5.073/100, ...
1-3.176/100, 1-2.884/100, 1-2.174/100, 1-3.343/100, 1-9.490/100, 1-11.865/100, 1-6.282/100, 1-2.313/100, ...
1-3.013/100, 1-3.021/100, 1-9.179/100, 1-3.243/100];
omc = fit([transpose(OMCX), transpose(OMCY)], transpose(OMCdata), 'poly22');
p = plot(omc);
Summary: I didn't see any conclusive difference that showed we could get an improvement from a change in a particular direction. Since the optical gain moves around so much its hard to see the effect of small or quick changes. It might be worth doing a longer test were we step these offsets in sets of three different values per dof (3*4 steps) and do each for five mins (~ 1 hour).
I orginally was trying to use the results of our last injection (2025-06-16 20:41:15 UTC to2025-06-16 21:01:57 UTC ) to determine how to change the OMC ASC alignment.
Using /ligo/home/jennifer.wright/git/2025/OMC_Alignment/20250116_OMC_Alignment_EXC.xml we injected four low frequency lines into H1:OMC-ASC_{POS,ANG}_{X,Y}_EXC - these channels come after the filter banks (ASC-OMC_A_PIT_OFFSET, then ASC-OMC_B_PIT_OFFSET, then ASC-OMC_A_YAW_OFFSET, then ASC-OMC_B_YAW_OFFSET) where the nominal offsets are set. The injection is at four different frequencies (0.0113, 0.0107, 0.0097 and 0.0103 Hz).
The analysis then involves looking at the 410 Hz line height on the OMC DCPD SUM to interpret the effect on optical gain.
However it is not clear from this plot that the full range of phase space has been looked at - ie we have not changed the offset with a large enough amplitude to check their current position is optimal.
Thus today I stepped ASC-OMC_A_PIT_OFFSET, then ASC-OMC_B_PIT_OFFSET, then ASC-OMC_A_YAW_OFFSET, then ASC-OMC_B_YAW_OFFSET - these filter banks are before the ones used above in the model and are the ones where the offset for the QPDs is set. In the
Towards the last three measurements we realised that we need to do larger changes ~0.04 counts to see a change in kappa C then wait for 3-4 mins. On the long term trend none of these changes seemed to produce any meausurable gain, but it would be good to repeat this measurement with longer times spent at each step and perhaps go in slightly larger steps.
The ndscope template is in /ligo/home/jennifer.wright/git/2025/OMC_Alignment/20250724_change _offsets_by_hand.yaml
Jennie, Elenna,
The other day Elenna noticed some coherence between DARM and the light reflected from the OMC (OMC-REFL_A_LF_OUT_DQ) and wondered if this implies our mode-matching or OMC alignment is bad.
So I took some times from above when one of the offsets was non-nominal and we compared the coherence between these times, since it shows some small change maybe there is still some tuning we could do of these offsets to recover some optical gain.
The measurement is saved in /ligo/home/jennifer.wright/git/2025/OMC_Alignment/Jennie_OMC_offsets.xml
Each was around 3 minutes long apart from the starting measurement which we took from a quiet time before the measurements.
The measurement times are:
nominal settings: 16:29:21 UTC
PITCH A: 17:54:11:UTC
PITCH B: 18:39:57 UTC
YAW A :18:58:10 UTC
YAW B :19:23:20 UTC
