REMOVE SEARCH FILTER
SEARCH AGAIN
Search criteria
Section: H2
Task: SEI
I was alerted to an issue by H1 MANAGER at midnight. One of the DACs failed at ETMX and took down ETMX and TMSX, and tripped the SEI software watchdog. I called Dave and he tried restarting the computer, but it didn't work. Richard said to try calling Fil and if he didn't answer, to wait until morning, and Fil didn't answer, so I'll try again at 6am to get him on the phone to see what can be done. For now, I've put ISC_LOCK in IDLE, and I've bypassed the software watchdog to restore the ISI and HEPI to their nominal states
Edgard, Ivey
This Tuesday Oli ran into issues installing the new blend filters and new SR3 Yaw transfer function fits for the OSEM estimator (see LHO: 86319). An error from the cplxpair function, which pairs complex conjugates, appeared only when converting the fit from zpk into state space. Somehow, this would introduce a small but significant difference between any two complex pairs, which would cause the computer to reject it as a complex pair. To resolve this issue, we ran a function to average each complex pair. We tested it with our mock PR3 model in the lab, and this seemed to fix the error cplxpair was encountering.
We were not able to reproduce the error that Oli noticed with the blend filters in our lab, but we will look more into this, and hopefully the issue will be fixed by next Tuesday when Oli tests the estimator again with the new fits.
The new cleaned SR3 yaw fits were added to SusSVN and can be found here '~/SusSVN/sus/trunk/HLTS/Common/FilterDesign/Estimator/fits_H1SR3_Y_2025-08-05.mat'. More on the fits LHO: 86233.
The new blend filter with updated fits can be found here '~/SusSVN/sus/trunk/HLTS/Common/FilterDesign/Estimator/Estimator_blend_skinnynotch_SR3yaw_20250723.mat'. More on the blend filter LHO: 86265.
Ivey, Edgard, and Brian have created new estimator fits (86233) and blend filters (86265) for the SR3 Y estimator, and we have new rate channels (86080), so we were excited to be able to take new estimator measurements (last time 85615).
Unfortunately, there were issues with installing the new filters, so I had to make do with the old filters: for the for the estimator filters, I used the fits from fits_H1SR3_2025-06-30.mat, and the blend filters are from Estimator_blend_doublenotch_SR3yaw.m, aka the DBL_notch filter and not the new skinny notch. These are the same filters used in the testing from 85615.
So the only difference between the last estimator test and this one is that the last test had the generic satamp compensation filters (85471), and this measurement has the more precise 'best possible' compensation filters (85746). Good for us to see how much of a difference the generic vs best possible compensation filters make.
Unfortunately, due to the filter installation issues as well as still trying to re set up the estimator channels following the channel name changes, I also didn't have much time to run the tests, resulting in the actual test with the estimator being only 5 minutes. Hopefully this is okay enough for at least a preliminary view of how it's working and then next week we can run a full test with the more recent filters. Like last time, the transition between the OSEM damping and the estimator damping was very smooth and the noise out of the estimator was visibly smaller than with the regular damping (ndscope1).
Measurement times
SR3 Y damp -0.1
2025-08-12 18:28:00 - 18:44:00 UTC
SR3 Y damp -0.1, OSEM damp -0.4
2025-08-12 18:46:46 - 19:03:41 UTC
SR3 Y damp -0.1, Estimator damp -0.4
2025-08-12 19:09:00 - 19:16:51 UTC
Attached below are plots of the OSEM yaw signal, the M3 yaw optical lever witness sensor signal, and the drive request from light damping, full damping (current setting), and estimator damping modes from Oli's recent estimator test.
The blue trace is the light damping mode, the red trace is the full damping mode, and the yellow trace is the estimator damping.
The first plot is of the OSEM signal. The spectrum is dominated by OSEM noise. The blue, light damping trace shows where the suspension resonances are (around 1, 2, and 3 Hz). Under estimator damping, the resonances don't show up as expected.
This second plot is of the OPLEV signal. It is much more obvious from this plot that the estimator is damping at the resonances as expected. Between the first and second, as well as the second and third peaks, the yellow trace of the estimator damping mode is below the red trace of the full damping mode. This is good because it is expected that the estimator damping is better than the current full damping mode between the peaks. There is some estimator noise between 3 and 4 Hz from the estimator. The light damping trace also sees a noticeable amount of excess noise between 10 to 15 Hz. We suspect this is due to ground motion from maintenance: third, fourth, and fifth plots show comparisons between ground motion in July (when the light damping trace was 'normal') and August. There is excess noise in X, Y, and Z in August when compared to July.
The sixth plot is of the drive requests. This data was pulled from a newly installed 512 samples/sec channel, while the previous analysis for a test in July (see: LHO: 85745) was done using a channel that was sampling at 16 samples/sec. The low frequency full damping drive request differs significantly between July and August, likely because aliasing effects caused the July data to be unreliable. Otherwise, the estimator is requesting less drive above 5 Hz as expected. We note that the estimator rolls off sharply above 10 Hz.
The last plot is of the theoretical drive requests overlaid onto the empirical drive requests. We see that the major features of the estimator drive request are accounted for, as expected.
Oli intends to install the filter and the new, clean fits (see LHO: 86366) next Tuesday to test the yaw estimator once more. Hopefully the installation is smooth!
J. Kissel
I took some pictures of the SPI pathfinder's (QTY 4) IXM100.C2-VC (right-handed) and (QTY 2) IXM100.C2L-VC (left-handed) mounts in their "raw" pre-assembled clean state since
(1) it's my first time dealing with Siskiyou mounts,
(2) the "assembly procedure" D1100362-v1 thus far is only an exploded view of numbered-but-not-labeled and out-dated parts for am unspecified, but left-handed mount,
(3) they come out of the clean-and-back process quite disassembled but maybe in the same bag,
(4) it's always useful to show what each company's convention of "right" vs. "left" handed optics mounts so you can tell them apart, when you've got lots of unlabeled clean mounts in front, and
(5) "right" and "left" are perspective-dependent descriptions of convention, and so it's useful to unambiguously specify.
So -- to determine if they're right- or left- handed -- orient the optic holder with the optic (back) side towards you, and the adjustment knobs (back) side away from you. Rotate the mount such that the optic-securing #8-32 set screw hole is up. Hold up your trusty left-o-meter -- your left hand formed into a capital L shape with your index finger and and thumb (palm facing away from you). If it matches what you see, it's a left-handed IXM100.C2L mount with the "opening" to your upper right from the described perspective. If it doesn't match, it's an IXM100.C2 with the "opening" to your upper left from the described perspective.
First picture is both mounts side-by-side; four right-handed IXM100.C2's on the left and two IXM100.C2L's on the right.
The second-thru-fourth pictures are various views of the IXM100.C2 right-handed mount. In the second picture I'm making the American sign language letter R.
The fifth-thru-seventh pictures are various views of the IXM100.C2L left-handed mount. In the fifth picture I'm making the American sign language letter L.
Edgard, Ivey
A few weeks ago, Oli ran some tests on the SR3 Yaw estimator (see LHO: 85745 for results). Edgard and I did some math to see if the OSEM estimator is requesting drive as expected by theory (we want our theoretical plot to align with the yellow trace in the third plot in the pdf below).
Attached below are images of the theoretical drive estimates compared against the empirical drive requests (yellow trace). The "old" theoretical drive estimate is made with the old blend filters (see LHO: 84004), and the "new" theoretical drive estimate is made with the new blend filters (see LHO: 86265).
A few notes on how we calculated the theoretical drive estimate: Because OSEM noise dominates, except at the resonances where suspoint motion dominates, we only considered OSEM noise when generating our theoretical drive estimate. We multiplied the theoretical plot by 1/3, which we eyeballed. The difference of a factor of 3 is likely an error in our math, which we can easily check. The theoretical plot deviates significantly from the empirical results below 0.6 Hz because the OSEM noise data we are using is not ideal (see the first plot in the pdf for a more accurate depiction of OSEM noise). However, the main concern is to show that the general shape is accounted for.
What the theoretical drive estimate plots show:
The "old" plot shows that the peak at 2 Hz is expected. This peak is likely not noise as we had originally believed, but a part of a larger peak that consists of the peak at 2 Hz and its adjacent peak. For the yellow trace, the dip between the two peaks is a result of the suspoint motion dipping below OSEM noise. For the black trace, the dip between the two peaks is a result of not including suspoint motion in our math. The same can be said about the peak at around 3 Hz.
An objective of the new blend filters was to damp the 2nd and 3rd peaks, as well as make the peaks more symmetrical. The "new" plot shows the peaks are successful at request less drive, but the symmetry of the peaks has not changed significantly.
Overall, the theoretical drive plot shows that the major characteristics from Oli's test are accounted for by the theory, and the estimator is working as expected!
I've updated the blend filter for the SR3 yaw estimator, v2 is called "skinnynotch". v1 was "doublenotch". I have not yet updated the installation scripts for it. It's based on the yaw fits by Ivey at the end of July. There are more recent fits, but they seem very similar, so I'm going to post this and let folks use if for the prediction calculations.
The new blend is a based on putting a simple notch in the model path at each lightly-damped resonance, and then rolling off the model at low frequency. The goal is to use the OSEM signal at the resonance and for the position info. (NOTE - The damping loop is AC coupled, so the estimator probably doesn't need the real OSEM signal at DC, but for now I'm leaving it in place so that the OSEM signal and the estimator signal will be as similar as possible for comparison reasons.)
Figure 1 shows the MODEL path of the blend vs. the plant model. The dashed lines are at the plant resonances. The notch width is chosen by-eye. The minimum notch transmission is 0.2, so we would expect 0.2 of the signal from the model, and 0.8 from the OSEM. However - note the phase at the botom of the third notch is about 15 deg, instead of 0. This means, see later, that the peak of the complimentary OSEM signal is slightly shifted. For -v3 I think we should try to make peaks for the OSEMs instead of notches for the models, because I think this will be better. Ivey and Edgard have some math to look at the performance
Figure 2 and 3 show the complementary filters, figure 3 is a zoom around the resonances
Figure 4 compares the plant model with the OSEM path.
I've also attached a pdf of the four plots.
Design script: Estimator_blend_skinnynotch_SR3yaw_20250723.m
in the SUS_svn at .../HLTS/Common/FilterDesign/Estimator/ (revision 12586)
The first blend and its installation are described in LHO log 84004.
Ivey,
I finished the yaw-to-yaw transfer functions for the OSEM estimator using the corrected measurements that Oli took for SR3 yesterday [see LHO: 86202].
The fits were added to the Sus SVN and live inside '~/SusSVN/sus/trunk/HLTS/Common/FilterDesign/Estimator/fits_H1SR3_2025-08-05.mat'. They are already calibrated to work on the filter banks for the estimator and can be installed using 'make_SR3_yaw_model.m', which is in the same folder.
Attached below are two images of the fits for the estimator.
The first attachment shows the Suspoint Y to M1 DAMP Y fit. The zpk for this fit is
'zpk([0,0,-0.027+20.489i,-0.064+11.458i,-0.027-20.489i,-0.064-11.458i],[-0.072+6.395i,-0.072-6.395i,-0.096+14.454i,-0.096-14.454i,-0.062+21.267i,-0.062-21.267i],-0.001)'
The first attachment shows the Suspoint Y to M1 DAMP Y fit. The zpk for this fit is
'zpk([-0.002+19.224i,-0.007+8.31i,-0.002-19.224i,-0.007-8.31i],[-0.06+6.398i,-0.06-6.398i,-0.091+14.439i,-0.091-14.439i,-0.074+21.29i,-0.074-21.29i],12.184)'
Oli, Ivey, Edgard.
We used Oli's measurements from [LHO: 86204] to do an OSEM calibration for the PR3 M1 OSEMs. Here are the outputs of the calibration script.
_______________________________________
OSEM calibration of H1:SUS-PR3
Stage: M1
2025-08-05_1700 (UTC).
The suggested (calibrated) M1 OSEMINF gains are
(new T1) = 1.770 * (old T1) = 2.055
(new T2) = 1.547 * (old T2) = 1.544
(new T3) = 1.443 * (old T3) = 1.511
(new LF) = 1.590 * (old LF) = 1.862
(new RT) = 1.774 * (old RT) = 2.063
(new SD) = 1.543 * (old SD) = 1.639
To compensate for the OSEM gain changes, we estimate that the H1:SUS-PR3_M1_DAMP loops must be changed by factors of:
L gain = 0.596 * (old L gain)
T gain = 0.648 * (old T gain)
V gain = 0.617 * (old V gain)
R gain = 0.617 * (old R gain)
P gain = 0.670 * (old P gain)
Y gain = 0.596 * (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-08-05_1700 (UTC) as a reference, the new apparent alingments are:
DOF Previous value New value Apparent change
---------------------------------------------------------------------------------
L -57.1 um -33.6 um +23.5 um
T -101.3 um -65.6 um +35.7 um
V 62.4 um 36.6 um -25.8 um
R 433.5 urad 225.7 urad -207.8 urad
P -631.8 urad -406.5 urad +225.2 urad
Y -166.7 urad -76.1 urad +90.5 urad
We have estimated a OSEM calibration of H1 PR3 M1 using HAM2 ST1 drives from 2025-05-21_0000 (UTC).
We fit the response M1_DAMP/HAM2_SUSPOINT between 5 and 15 Hz to get a calibration in [OSEM m]/[GS13 m]
This message was generated automatically by OSEM_calibration_SR3.py on 2025-08-06 01:07:57.985744+00:00 UTC
%%%%%%%%%%%%%%%%%%%%%%%%%%%%
EXTRA INFORMATION
The H1:SUS-PR3_M1_OSEMINF gains at the time of measurement were:
(old) T1: 1.161
(old) T2: 0.998
(old) T3: 1.047
(old) LF: 1.171
(old) RT: 1.163
(old) SD: 1.062
The matrix to convert from the old Euler dofs to the (calibrated) new Euler dofs is:
+0.596 -0.0 +0.0 -0.0 +0.0 -0.003
+0.0 +0.648 -0.0 +0.0 +0.0 -0.0
-0.0 +0.0 +0.617 -0.004 +0.001 +0.0
+0.0 +0.0 -0.748 +0.617 -0.007 -0.0
+0.0 +0.0 +0.517 -0.036 +0.67 -0.0
-0.407 +0.0 -0.0 +0.0 -0.0 +0.596
The matrix is used as (M) * (old EUL dof) = (new EUL dof)
The dof ordering is ('L', 'T', 'V', 'R', 'P', 'Y')
Ivey, Edgard.
Ivey made even newer fits for the M1 SR3 in "Yaw using the measurements that Oli took in [LHO: 86075].
These fits are pretty similar to the last set we got in [LHO: 85446]. However, this time, Ivey used vectfit3 for both of the fits directly. She only manually ensured that the zeros were all in the left-hand-plane, and that there were no additional zeros in the M1 to M1 transfer function, even if the measurements show a bit extra phase loss compared to the fit.
These are the fits obtained [see figures for an eye-test of the goodness of fit]:
For the ISI to M1 transfer function:
'zpk([0,0,-0.027+20.489i,-0.064+11.458i,-0.027-20.489i,-0.064-11.458i],[-0.072+6.395i,-0.072-6.395i,-0.096+14.454i,-0.096-14.454i,-0.062+21.267i,-0.062-21.267i],-0.001)'
The M1 to M1 transfer function:
'zpk([-0.002+19.246i,-0.005+8.312i,-0.002-19.246i,-0.005-8.312i],[-0.065+6.392i,-0.065-6.392i,-0.076+14.442i,-0.076-14.442i,-0.055+21.272i,-0.055-21.272i],12.085)'
The fits were added to the Sus SVN and live inside '/ligo/svncommon/SusSVN/sus/trunk/HLTS/Common/FilterDesign/Estimator/fits_H1SR3_2025-07-29.mat' .
The filters can be installed using 'make_SR3_yaw_model.m', which lives in the same folder [for reference, see LHO: 84041, where Oli got the fits running for a test]. This last script, as well as 'make_SR3_yaw_blend.m' were updated to work with the new naming convention for the estimator block.
Hopefully we will get to test the estimator again soon!
Plot of 3 months of Bit switching.
There are certainly bits switching on all of the channels.
Marked nad noticable increase in bit switching on May 22nd for ETMY which I believe is a known issue.
TITLE: 08/01 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 149Mpc
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 21mph Gusts, 14mph 3min avg
Primary useism: 0.07 μm/s
Secondary useism: 0.05 μm/s
QUICK SUMMARY:
Observing reached at 23:43:12 UTC But only after spending 13 min trying to determine why there is are SEI SDF Diffs.
We, (TJ, Oli, Me) decided to just accept them and hope for the best.
I reverted all of these SDF's for the SEI GS13 on HAM 2, 3, 4, & 5 once we lost lock because Mr. Crouch said that those are older version of the filters.
Lockloss at 2025-08-01 22:02 UTC after 3 minutes in NLN. We couldn't go into Observing because of SPM differences causing SDF diffs in the guardians for ISIHAM2/3/4/5. Last time we had this, I asked Jim what to do and he said to just INIT the guardians, and it caused a glitch, but we did not lose lock, and he said INITing them should not cause glitches or locklosses (85809). Today, I did the same thing and went to INIT the guardians, but when doing it for the first one, ISIHAM2, it caused a glitch and we lost lock from it.
I don't see anything fishy going on on the guardian side of things here. When the ISI_HAM2 node had rerun the HIGH_ISOLATED state, after running through INIT, it changed a bunch of the GS13INF gains. See the end of the guardian log for the ISI_HAM2 and SEI_HAM2 nodes in the attached txt file. We then saw these changes later as well in SDF (alog84140), so the large earthquake script button might be conflicting with this.
I have updated the MEDM screens for the OSEM Estimator and committed them to Userapps. This captures the name changes made to the models for SR3 and PR3 at LHO. These name changes just make the names more sensible, and do not change any functionality. LLO can pull the updates and it will make no difference because nothing at LLO uses these screens.
userapps/trunk/sus/common/medm$ svn ci -m"Mods to estimator screens to match name update in the estimator models, BTL"
Sending estim/CONTROL_6.adl
Sending estim/ESTIMATOR_OVERVIEW.adl
Sending estim/FADE_CONTROL.adl
Sending hxts/SUS_CUST_HLTS_OVERVIEW_W_EST.adl
Transmitting file data ....done
Committing transaction...
Committed revision 32544.
Note - the indicator lights for the filters on the Estimator Overview screen are not working correctly, and I plan to fix this in the next few days. the indicators in the control_6 screen have been fixed.
(They should be grey=output off, green = output on, settings as expected, red = output on, settings not correct.)
There are many settings to capture in the SDF file. Most of these are the filter settings. Those will come up in the OFF setting, and that is good, and fine to capture.
A few things do need to be updated. These include:
In the Estimator Overview screen
set the ramp time to what it was before - 5 seconds is fine
set the Initial channel to 1 (this is OFF)
set the next channel to 1 (this is also off, and it should match the initial channel. This channel will change during operation, so maybe you don't want to monitor it?)
click the OSEM select and then set the correct channel to 1 (the 'hint' at the bottom says which one it is. for Yaw estimator, pick yaw and for pitch estimator, choose pitch)
Both BRS x & y are within their nominal regions and mostly flat over the last couple months. CLOSING FAMIS 26457.
OSEM calibration of H1:SUS-SR3
Stage: M1
2025-07-22_1530 (UTC).
The suggested (calibrated) M1 OSEMINF gains are
(new T1) = 2.174 * (old T1) = 3.213
(new T2) = 1.610 * (old T2) = 1.517
(new T3) = 1.569 * (old T3) = 1.494
(new LF) = 1.331 * (old LF) = 1.733
(new RT) = 1.374 * (old RT) = 1.494
(new SD) = 1.390 * (old SD) = 1.793
To compensate for the OSEM gain changes, we estimate that the H1:SUS-SR3_M1_DAMP loops must be changed by factors of:
L gain = 0.740 * (old L gain)
T gain = 0.719 * (old T gain)
V gain = 0.545 * (old V gain)
R gain = 0.545 * (old R gain)
P gain = 0.629 * (old P gain)
Y gain = 0.740 * (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-07-22_1530 (UTC) as a reference, the new apparent alingments are:
DOF Previous value New value Apparent change
---------------------------------------------------------------------------------
L -5.0 um -3.1 um +1.8 um
T -21.6 um -15.5 um +6.1 um
V 11.8 um 9.8 um -2.0 um
R -576.3 urad -327.5 urad +248.9 urad
P -266.5 urad -158.3 urad +108.2 urad
Y -585.0 urad -431.9 urad +153.1 urad
We have estimated a OSEM calibration of H1 SR3 M1 using HAM5 ST1 drives from 2025-05-21_0000 (UTC).
We fit the response M1_DAMP/HAM5_SUSPOINT between 5 and 15 Hz to get a calibration in [OSEM m]/[GS13 m]
This message was generated automatically by OSEM_calibration_SR3.py on 2025-07-22 16:24:05.000267+00:00 UTC
%%%%%%%%%%%%%%%%%%%%%%%%%%%%
EXTRA INFORMATION
The H1:SUS-SR3_M1_OSEMINF gains at the time of measurement were:
(old) T1: 1.478
(old) T2: 0.942
(old) T3: 0.952
(old) LF: 1.302
(old) RT: 1.087
(old) SD: 1.290
The matrix to convert from the old Euler dofs to the (calibrated) new Euler dofs is:
+0.74 -0.0 +0.0 -0.0 +0.0 -0.001
+0.0 +0.719 -0.0 +0.0 +0.0 -0.0
-0.0 +0.0 +0.545 -0.006 +0.0 +0.0
+0.0 +0.0 -1.209 +0.545 -0.003 -0.0
+0.0 +0.0 +0.18 -0.013 +0.629 -0.0
-0.148 +0.0 -0.0 +0.0 -0.0 +0.74
The matrix is used as (M) * (old EUL dof) = (new EUL dof)
The dof ordering is ('L', 'T', 'V', 'R', 'P', 'Y')
Please see the attached images of before calibrating and after calibrating.
Comparing these new OSEMINF gains to the gains we got last time we did this (84367) (before the satamp swap), they are pretty similar:
| OSEM | Previous Calculated OSEMINF gains (84367) | New Calculated OSEMINF gains (85907) | Percent difference (%) |
| T1 | 3.627 | 3.213 | 12.1 |
| T2 | 1.396 | 1.517 | 8.3 |
| T3 | 1.345 | 1.494 | 10.4 |
| LF | 1.719 | 1.733 | 0.8 |
| RT | 1.490 | 1.494 | 0.2 |
| SD | 1.781 | 1.793 | 0.6 |
So that's another indicator that the sat amp swap did not have much of an effect on the suspension response to suspoint excitations
@ 02:08:55 UTC Known Lockloss caused by a 6.5M Earthquake. I'm using the GEOFON site because USGS took ~ 10 min to report the quake.
Earthquake mode was activated, then less than 30 seconds later we were unlocked.
No earthquake was listed as incoming, Picket fence was lit up and had active ground motion.
12:01 GRD called, we got hit by 2 large semi close earthquake from the eastern Russian penisula, a 6.7 then a 7.4. A few ISIs and suspensions tripped, it'll be a few hours till the ground motion comes down enough to relock. We were going through DRMI_ASC at the time of the earthquakes.
Closes FAMIS 26052. Last checked in alog 85627.
"BSC high freq noise is elevated for these sensor(s)!!!
ITMY_ST1_CPSINF_H3"
By eye, BS_ST2 had elevated counts compared to last week. Otherwise, signals are either comparable or lower.
TITLE: 07/16 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Earthquake
INCOMING OPERATOR: Oli
SHIFT SUMMARY: We stayed lock for most of the shift, a large earthquake struck soon after losing lock. We're still ringing down as of 23:30UTC.
LOG:
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 14:39 | FIT | Camilla, IPA members | Yarm | N | Walk/Jog started at 14:00 | 15:22 |
| 16:41 | FAC | Kim | Optics lab | N | Swiftin' | 16:59 |
| 21:05 | VAC | Travis, Gerardo | LVEA | Y | VAC work | 21:20 |
| 21:06 | SAF | LVEA IS LASER HAZARD | LVEA | Y | LVEA IS LASER HAZARD | 07:06 |
Ivey, When fitting transfer functions for the OSEM estimator, I tested several transfer function fitting programs to find one that is both accurate and efficient. A brief side note: In the 6/24 M1-to-M1 dataset that Oli took, we observed an unexpected right-hand zero near 1.2 Hz (see attached plot), where we had expected a left-hand zero. After comparing with the 4/15 and 4/18 datasets, we found no corresponding right-hand zero, suggesting the 6/24 zero is likely due to noise. I wrote a document highlighting the pros and cons of each of the fitting programs here: TF Fitting Comparison (Google Doc) The programs include: Vectfit3 (I recommend using this with strong inverse weighting): Uses vector fitting. Created by Bjorn Gustavsen. Not built into MATLAB. Performs nearly identically to Vectfit4, but has more documentation. Rational: Built-in MATLAB function. Uses the AAA algorithm. Spectrumest: Built-in MATLAB function. Chooses an internal algorithm based on the data. Rationalfit: Built-in MATLAB function. Uses vector fitting. Generally, these programs fit poles and end behavior well, but often compromise the accuracy of the fit in the zero regions. In these cases, we often have to manually refine the fit in the zero regions. However, Vectfit3 performs very well on the 6/24 M1-to-M1 and SusPoint-to-M1 datasets when used with strong inverse weighting. We were able to produce better fits than manual methods, and expect this approach to be more efficient for future use. Example plots are available here: Plot Comparison Slides (Google Slides) Attached is the MATLAB code used for the M1-to-M1 fits. To use vectfit3, you must download the package here. All other functions used are built into MATLAB's toolboxes. Measurement file paths:/ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/Common/Data/2025-06-24_1700_H1ISIHAM5_ST1_WhiteNoise_SR3SusPoint_L_to_Y_0p02to50Hz.xml/ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/SAGM1/Data/2025-06-24_1900_H1SUSSR3_M1_WhiteNoise_L_to_Y_0p02to50Hz.xml
