Sheila, Camilla
The IFO was just relocking at the start of commissioning time today, so we set the ADF back on and the sqz angle servo on. This worked fine, with the phase shifter staying well within it's range (it stayed between 180 and 130 degrees, it's range is 0 -270 degrees).
In the attached screenshot the vertical cursors are both at 25 minutes into the lock. You can see that the SQZ BLRMS and the range behave differently with the servo on, but in both cases they start with a low range and move up slowly. We think that the set point of the squeezing angle servo wasn't set ideally for this time.
In the second screenshot you can see that I changed the SRCL offset and the servo responded to it, taking about 3 minutes to settle.
Rahul, Betsy, Camilla
Attached are some photos of the proposed location of the beamdump that will be placed behind the HAM1 RM3 / PM1 tip-tilt with new D2500101 attached to existing Tip-Tilt DSUB Bracket Holder D1101430. In reality the beamdump will be placed at the mirror image of the photos as the HAM1 beam will be coming the opposite incoming angle.
The Beamdump is made from:
Lockloss right after we got back to OBSERVING with good range.
First impression of cause is that it might be wind related since:
Relocking again now.
Mon Mar 31 10:09:31 2025 INFO: Fill completed in 9min 28secs
FAMIS 31079
The temperature increase noted last week seems to have come back to normal for the most part after a few days.
Jason's RefCav alignment tweak 3 days ago is clearly seen and level has stayed relatively stable since.
PMC Refl hasn't been rising, but perhaps has gotten noisier starting a few days ago.
Last week Corey changed the gains of POP18 because of difficulties locking DRMI. 83540 To avoid having the histories of these POP18 build ups being confusing, I've moved the gain of 2 into the trigger matrix, and in sdf set the locking gains back to 2. (These gains were changed from 1 to 2 when the 50/50 splitter was added to the POP path.)
I've edited line 238 in ISC_DRMI to set the trigger matrix element to 2.
Lockloss after 2 minute lock before reaching observing. No immediate apparent causes.
TITLE: 03/31 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 28mph Gusts, 23mph 3min avg
Primary useism: 0.06 μm/s
Secondary useism: 0.21 μm/s
QUICK SUMMARY:
IFO is LOCKING in LASER_NOISE_SUPPRESSION
Today we have planned comissioning from 8:30 to 11:30 local time.
The last lockloss seems to have been caused by wind and elevated microseism, though neither seem high enough to have necessarily caused a lockloss.
Ibrahim, Oli, Camilla
We had two 30+ minute range drops last night, plot attached. Looks to be mainly under 60Hz from the OMC BLRMs, plot.
Doesn't appear to be sqz, EX ground motion 83233, or CO2 ISS channel 82728 related. Oli also checked this wasn't PI related 82944.
Confirmed not the PIs for either range drop (drop1, drop2). There was a small drop in range a few minutes before the second range drop around the same time as PI31 had a small ringup, but zooming in, the ringup happened multiple minutes before and so doesn't account for that quick drop either(ndscope3).
TITLE: 03/30 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 154Mpc
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY:
Nice shift with H1 running decently even as the weather turned a bit in the evening (w/ 30+mph winds and rain as the sun set....but then calmed down toward the end of the shift). At shift's end, H1's current lock is over 7hrs (with one GW-candidate).
LOG:
We had a BSC3 sensor glitch at 16:39:16 resulting in a single VACSTAT alarm. I restarted the service at 16:50 to clear this alarm.
I also set the FMCS Reverse Osmosis alarm into silent mode so it will only email and not text for the next 24 hours.
Bypass will expire:
Mon Mar 31 04:57:28 PM PDT 2025
For channel(s):
H0:FMC-CS_WS_RO_ALARM
Another BSC3 VACSTAT glitch at 22:40:58. Service was restarted at 22:27 to clear.
TITLE: 03/30 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 153Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY: We've been locked for 1.5 hours. The ground has been doing the tectonic shuffle this morning with a group of earthquakes and aftershocks from Tonga, 7.0, 4.8, 6.1, 4.9, 5.8...
LOG: No log.
The porta potty outside the FCES has also been knocked over, and OSB receiving is blocked by tumbleweeds. (Tagging FMCS)
TITLE: 03/30 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 152Mpc
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 16mph Gusts, 11mph 3min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.15 μm/s
QUICK SUMMARY:
H1 has been at NLN for 1.5+hrs.
There is a CDS Alarm for the RO (reverse osmosis) system. Happened to phone Tyler earlier today with water questions and he mentioned he turned off both RO skids this morning (@943amPDT).
Environmental noise wise, secondary µseism is lower than 24hrs (looks like it's flattened out squarely at the 50th percentile about 7hrs ago). Winds are a little are a touch more breezy than yesterday, but still well under 20mph.
20:34 UTC lockloss, it appears to have been from an ETMX glitch
21:55 UTC observing
TITLE: 03/30 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Earthquake
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
SEI_ENV state: EARTHQUAKE
Wind: 8mph Gusts, 5mph 3min avg
Primary useism: 0.51 μm/s
Secondary useism: 0.16 μm/s
QUICK SUMMARY:
18:16 UTC Observing
I'm looking again at the OSEM estimator we want to try on PR3 - see https://dcc.ligo.org/LIGO-G2402303 for description of that idea.
We want to make a yaw estimator, because that should be the easiest one for which we have a hope of seeing some difference (vertical is probably easier, but you can't measure it). One thing which makes this hard is that the cross coupling from L drive to Y readout is large.
But - a quick comparison (first figure) shows that the L to Y coupling (yellow) does not match the Y to L coupling (purple). If this were a drive from the OSEMs, then this should match. This is actuatually a drive from the ISI, so it is not actually reciprocal - but the ideas are still relevant. For an OSEM drive - we know that mechanical systems are reciprocal, so, to the extent that yellow doesn't match purple, this coupling can not be in the mechanics.
Never-the-less, the similarity of the Length to Length and the Length to Yaw indicates that there is likely a great deal of cross-coupling in the OSEM sensors. We see that the Y response shows a bunch of the L resonances (L to L is the red TF); you drive L, and you see L in the Y signal. This smells of a coupling where the Y sensors see L motion. This is quite plausible if the two L OSEMs on the top mass are not calibrated correctly - because they are very close together, even a small scale-factor error will result in pretty big Y response to L motion.
Next - I did a quick fit (figure 2). I took the Y<-L TF (yellow, measured back in LHO alog 80863) and fit the L<-L TF to it (red), and then subtracted the L<-L component. The fit coefficient which gives the smallest response at the 1.59 Hz peak is about -0.85 rad/meter.
In figure 3, you can see the result in green, which is generally much better. The big peak at 1.59 Hz is much smaller, and the peak at 0.64 is reduced. There is more from the peak at 0.75 (this is related to pitch. Why should the Yaw osems see Pitch motion? maybe transverse motion of the little flags? I don't know, and it's going to be a headache).
The improved Y<-L (green) and the original L<-Y (purple) still don't match, even though they are much closer than the original yellow/purple pair. Hence there is more which could be gained by someone with more cleverness and time than I have right now.
figure 4 - I've plotted just the Y<-Y and Y<-L improved.
Note - The units are wrong - the drive units are all meters or radians not forces and torques, and we know, because of the d-offset in the mounting of the top wires from the suspoint to the top mass, that a L drive of the ISI has first order L and P forces and torques on the top mass. I still need to calculate how much pitch motion we expect to see in the yaw reponse for the mode at 0.75 Hz.
In the meantime - this argues that the yaw motion of PR3 could be reduced quite a bit with a simple update to the SUS large triple model, I suggest a matrix similar to the CPS align in the ISI. I happen to have the PR3 model open right now because I'm trying to add the OSEM estimator parts to it. Look for an ECR in a day or two...
This is run from the code {SUS_SVN}/HLTS/Common/MatlabTools/plotHLTS_ISI_dtttfs_M1_remove_xcouple'
-Brian
ah HA! There is already a SENSALIGN matrix in the model for the M1 OSEMs - this is a great place to implement corrections calculated in the Euler basis. No model changes are needed, thanks Jeff!
If this is a gain error in 1 of the L osems, how big is it? - about 15%.
Move the top mass, let osem #1 measure a distance m1, and osem #2 measure m2.
Give osem #2 a gain error, so it's response is really (1+e) of the true distance.
Translate the top mass by d1 with no rotation, and the two signals will be m1= d1 and m2=d1*(1+e)
L is (m1 + m2)/2 = d1/2 + d1*(1+e)/2 = d1*(1+e/2)
The angle will be (m1 - m2)/s where s is the separation between the osems.
I think that s=0.16 meters for top mass of HLTS (from make_sus_hlts_projections.m in the SUS SVN)
Angle measured is (d1 - d1(1+e))/s = -d1 * e /s
The angle/length for a length drive is
-(d1 * e /s)/ ( d1*(1+e/2)) = 1/s * (-e/(1+e/2)) = -0.85 in this measurement
if e is small, then e is approx = 0.85 * s = 0.85 rad/m * 0.16 m = 0.14
so a 14% gain difference between the rt and lf osems will give you about a 0.85 rad/ meter cross coupling. (actually closer to 15% -
0.15/ (1 + 0.075) = 0.1395, but the approx is pretty good.
15% seem like a lot to me, but that's what I'm seeing.
I'm adding another plot from the set to show vertical-roll coupling.
fig 1 - Here, you see that the vertical to roll cross-couping is large. This is consistent with a miscalibrated vertical sensor causing common-mode vertical motion to appear as roll. Spoiler-alert - Edgard just predicted this to be true, and he thinks that sensor T1 is off by about 15%. He also thinks the right sensor is 15% smaller than the left.
-update-
fig 2- I've also added the Vertical-Pitch plot. Here again we see significant response of the vertical motion in the Pitch DOF. We can compare this with what Edgard finds. This will be a smaller difference becasue the the pitch sensors (T2 and T3, I think) are very close together (9 cm total separation, see below).
Here are the spacings as documented i the SUS_SVN/HLTS/Common/MatlabTools/make_sushlts_projections.m
I was looking at the M1 ---> M1 transfer functions last week to see if I could do some OSEM gain calibration.
The details of the proposed sensor rejiggling is a bit involved, but the basic idea is that the part of the M1-to-M1 transfer function coming from the mechanical plant should be reciprocal (up to the impedances of the ISI). I tried to symmetrize the measured plant by changing the gains of the OSEMs, then later by including the possibility that the OSEMs might be seeing off-axis motion.
Three figures and three findings below:
0) Finding 1: The reciprocity only allows us to find the relative calibrations of the OSEMs, so all of the results below are scaled to the units where the scale of the T1 OSEM is 1. If we want absolute calibrations, we will have to use an independent measurement, like the ISI-->M1 transfer functions. This will be important when we analyze the results below.
1) Figure 1: shows the full 6x6 M1-->M1 transfer function matrix between all of the DOFs in the Euler basis of PR3. The rows represent the output DOF and the columns represent thr input DOF. The dashed lines represent the transpose of the transfer function in question for easier comparison. The transfer matrix is not reciprocal.
2) Finding 2: The diagonal correction (relative to T1) is given by:
I will post more analysis in the Euler basis later.
Here's a view of the Plant model for the HLTS - damping off, motion of M1. These are for reference as we look at which cross-coupling should exist. (spoiler - not many)
First plot is the TF from the ISI to the M1 osems.
L is coupled to P, T & R are coupled, but that's all the coupling we have in the HLTS model for ISI -> M1.
Second plot is the TF from the M1 drives to the M1 osems.
L & P are coupled, T & R are coupled, but that's all the coupling we have in the HLTS model for M1 -> M1.
These plots are Magnitude only, and I've fixed the axes.
For the OSEM to OSEM TFs, the level of the TFs in the blank panels is very small - likely numerical issues. The peaks are at the 1e-12 to 1e-14 level.
@Brian, Edgard -- I wonder if some of this ~10-20% mismatch in OSEM calibration is that we approximate the D0901284-v4 sat amp whitening stage with a compensating filter of z:p = (10:0.4) Hz? (I got on this idea thru modeling the *improvement* to the whitening stage that is already in play at LLO and will be incoming into LHO this summer; E2400330) If you math out the frequency response from the circuit diagram and component values, the response is defined by % Vo R180 % ---- = (-1) * -------------------------------- % Vi Z_{in}^{upper} || Z_{in}^{lower} % % R181 (1 + s * (R180 + R182) * C_total) % = (-1) * ---- * -------------------------------- % R182 (1 + s * (R180) * C_total) So for the D0901284-v4 values of R180 = 750; R182 = 20e3; C150 = 10e-6; C151 = 10e-6; R181 = 20e3; that creates a frequency response of f.zero = 1/(2*pi*(R180+R182)*C_total) = 0.3835 [Hz]; f.pole = 1/(2*pi*R180*C_total) = 10.6103 [Hz]; I attach a plot that shows the ratio of the this "circuit component value ideal" response to approximate response, and the response ratio hits 7.5% by 10 Hz and ~11% by 100 Hz. This is, of course for one OSEM channel's signal chain. I haven't modeled how this systematic error in compensation would stack up with linear combinations of slight variants of this response given component value precision/accuracy, but ... ... I also am quite confident that no one really wants to go through an measure and fit the zero and pole of every OSEM channel's sat amp frequency response, so maybe you're doing the right thing by "just" measuring it with this technique and compensating for it in the SENSALIGN matrix. Or at least measure one sat amp box's worth, and see how consistent the four channels are and whether they're closer to 0.4:10 Hz or 0.3835:10.6103 Hz. Anyways -- I thought it might be useful to be aware of the many steps along the way that we've been lazy about the details in calibrating the OSEMs, and this would be one way to "fix it in hardware."