Displaying reports 161-180 of 84278.Go to page Start 5 6 7 8 9 10 11 12 13 End
Reports until 15:01, Tuesday 26 August 2025
H1 SEI
thomas.shaffer@LIGO.ORG - posted 15:01, Tuesday 26 August 2025 (86587)
H1 ISI CPS Noise Spectra Check - Weekly

FAMIS26547

Script reports ETMX_ST1_CPSINF_V2 is high. HAM3 H2 also seems high.

Non-image files attached to this report
H1 General
thomas.shaffer@LIGO.ORG - posted 13:53, Tuesday 26 August 2025 (86584)
LVEA Swept

I unplugged two unused extension chords and I also unplugged what is labeled as the PCALX camera computer, but it is really the the computer to take pictures of ITMX from the spool. The computer is off and not being used, so I unplugged it. I turned the lights off as I left.

H1 SUS
jeffrey.kissel@LIGO.ORG - posted 12:51, Tuesday 26 August 2025 - last comment - 13:37, Tuesday 26 August 2025(86578)
H1 SUS PR3 Pitch and Yaw Estimator: Installed and Run for 1 hour
J. Kissel, E. Bonilla

Thanks to the hard and quick work of the Stanford team overnight designing blend filters and super sensor model filters (LHO:86563), I was able to install everything needed to get the H1SUSPR3's estimator up, running, and functional this morning. After having run it for bit during maintenance (and thus corner-station sensor correction was off), I've turned the "use OSEMs or use Estimator" switch to "use OSEMs" such that the SUS is performing in a functionally equivalent way as "no estimator." We'll run like this until (a) I make some plots analyzing the performance and (b) Until Thursday's commissioning period when we're in nominal low noise, so we can do similar ON vs. OFF comparisons with ASC as our metric.

The P and Y estimators were ON from 2025-08-26 18:05 UTC to 19:00 UTC.

Some extra design points beyond whats made in LHO:86563, with the mind-set of "can we 'just' copy and paste SR3's filters into PR3?"
In short: No.
In long: 
    The existing OSEM-only damping is different -- all SR3's damping loop's overall EPICs gain is -0.5, where PR3's is -1.0. This is demonstrated by LHO:86554, that means the damped M1 drive to M1 response "damped plant" is different. Namely, on resonance, the loop suppression 1/(1+G), is different because G is different, and thus P/(1+G) is different. This has the effect of shifting the fundamental mode frequencies and changing the residual Q. *That* means two things:
    (1) that the OSEM vs. Estimator blend filters -- which are relatively tight notches around resonances -- in principle, should be different. That being said, depending on the performance we end up getting we could *see* if making the blend filters generically wide enough would work. But, for now, we err on the side of "let's make the blend filters specific" because we have the measurements and the person power.
    (2) The "undamped plant" measurements for the estimator -- which are really "lightly damped" plants with whatever loop suppression is left from the broadband OSEM damping that's still always used; an EPICs gain of -0.1 for SR3 and -0.2 for PR3's damping loop controllers -- are different. So, the filters that are modeling that response -- the Sus. Point drive to M1 response filters and the M1 drive to M1 response filters -- will also necessarily be different. However, the differences are almost entirely resonance shifts and Q changes that are proportional to the differences in 1/(1+G) of the light damping (one with scaled with G = -0.1 and one with G=-0.2). Said differently, so far, only the on-diagonal M1 to M1 transfer functions are proving to be needed, and only the P to P, L to P, and Y to Yaw suspension point to M1 transfer functions are needed, and these are almost identical between PR3 and SR3.

I'll put a comparison of the filters and details of the installation in the comments.
Comments related to this report
jeffrey.kissel@LIGO.ORG - 13:08, Tuesday 26 August 2025 (86580)
Here're the comparison between the PR3 and SR3 Suspension Point to M1 response transfer functions.

These we installed using the scripts
/ligo/svncommon/SusSVN/sus/trunk/HLTS/Common/FilterDesign/Estimator/
    make_PR3_pitch_model.m     rev 12622
    make_PR3_yaw_model.m       rev 12622
which push the filters from the saved .mat files 
/ligo/svncommon/SusSVN/sus/trunk/HLTS/Common/FilterDesign/Estimator/
    fits_H1PR3_P_2025-08-19.mat    rev 12622
    fits_H1PR3_Y_2025-08-19.mat    rev 12619
(Most are at rev 12622 because the file names had differing arrangements of underscores and hyphens, so I cleaned that up before running.)

Notably -- we uncovered the oversight of missing L to P filter install in SR3 (LHO:86567) in enough time to make sure the same oversight didn't happen with PR3.

So -- PR3 has 
   - Pitch Estimator P to P, H1:SUS-PR3_M1_EST_P_FUSION_MODL_SUSP_P_2GAP, comparison plot
   - Pitch Estimator L to P, H1:SUS-PR3_M1_EST_L_FUSION_MODL_SUSP_P_2GAP, comparison plot and 
   - Yaw Estimator Y to Y, H1:SUS-PR3_M1_EST_Y_FUSION_MODL_SUSP_Y_2GAP,  comparison plot.

Images attached to this comment
jeffrey.kissel@LIGO.ORG - 13:09, Tuesday 26 August 2025 (86581)
Here's the comparison between the M1 to M1 drive transfer functions. 

These are also installed with the same run of the scripts
/ligo/svncommon/SusSVN/sus/trunk/HLTS/Common/FilterDesign/Estimator/
    make_PR3_pitch_model.m     rev 12622
    make_PR3_yaw_model.m       rev 12622
which push the filters from the saved .mat files 
/ligo/svncommon/SusSVN/sus/trunk/HLTS/Common/FilterDesign/Estimator/
    fits_H1PR3_P_2025-08-19.mat    rev 12622
    fits_H1PR3_Y_2025-08-19.mat    rev 12619
(Most are at rev 12622 because the file names had differing arrangements of underscores and hyphens, so I cleaned that up before running.)

Images attached to this comment
jeffrey.kissel@LIGO.ORG - 13:37, Tuesday 26 August 2025 (86583)
Here's the comparison between the blend filters.

Because I want to have a bit more conversation about this, I show the comparison in detail for each PIT and YAW, and when showing them all together, I show both zoomed in and out in frequency.

Namely: The pitch super sensor blend filter magnitude tops out at 0.9 rather than the traditional 1.0 for a complimentary blend filter. As Brian briefly mentions in his design aLOG (LHO:86510) this because he is mindful of the phase of the sum of this filter and its compliment. The pitch super sensor blend filter was designed to be 
    (SS Blend) = 1 - (OSEM Blend). 
In his design aLOG, he phrases it as "The low-pass [OSEM Blend] is a zero-pole pair so that it levels off to a transmission of 0.1. This is so the gap between the two [0.64 and 0.75 Hz] resonant peaks [which were designed as separate, single z:p pairs] will be well behaved. [The pairs] will cross at about 180 degrees of phase shift and make a sharp zero [between resonances], and [that] deep zero seemed to be causing numerical issues when Oli was implementing the yaw blends. The flat bottom at 0.1 prevents that."
     
    So, if you force the OSEM blend to bottom out at 0.1, then the super-sensor blend will top out at 1 - 0.1 = 0.9.

    This, in effect, sacrifices 10% loop gain for numerical stability.

    Brian says he's working on a -v3 design that might improve this.
    Honestly, I think it's probably fine from an overall loop gain perspective -- I guess this can be rectified by increasing the estimator control filter by 10%, but even if not, 10% less damping is totally fine.

    If loop or numerical stability demands that we can't increase the overall gain can we augment this design such that *well* above the 0.64 and 0.75 Hz resonances -- can we still roll off the OSEM contribution? Say, multiply the whole -v2 OSEM filter by a high-pass at, 10 Hz (and then adjust the SS blend accordingly to keep things complimentary)?
Images attached to this comment
H1 AOS (DetChar)
mirandarose.claypool@LIGO.ORG - posted 12:09, Tuesday 26 August 2025 (86573)
Data Quality Shift Report: LHO 2025-08-18 to 2025-8-24

Link to report here.

Summary:

Apologies for the delay in posting. I was having difficulty loading the aLog website & summary pages yesterday and wanted to follow up on some suggestions from the DetChar call.

H1 ISC
elenna.capote@LIGO.ORG - posted 11:50, Tuesday 26 August 2025 - last comment - 12:21, Tuesday 26 August 2025(86571)
Range diff over last 24 hours

I compared the sensitivity from two segments over the last 24 hours where our range was about 157 Mpc and 162 Mpc each (60 second averages). Looks like a broad improvement from about 30-300 Hz when using the range comparison script.. The 350 Hz SQZ blrms are 0.25 dB better in the higher range time. It's hard to see a large change in the 38-60, 60-100 or 100-450 Hz range blrms. Whether you use a shorter or longer average, the difference between two times is 5 Mpc.

Images attached to this report
Non-image files attached to this report
Comments related to this report
elenna.capote@LIGO.ORG - 12:21, Tuesday 26 August 2025 (86575)

After the period of high range, the sensivity then dropped a few Mpc, which seems to match with the 38-60 Hz blrms getting slightly worse. I nearly had to squint to see it, so here's another range comparison plot with the high range time above, and then a low range time between 6-7 hours ago. This is about a 4 Mpc loss from 20-100 Hz.

Non-image files attached to this comment
H1 PSL
ryan.short@LIGO.ORG - posted 11:12, Tuesday 26 August 2025 (86570)
PSL 10-Day Trends

FAMIS 31100

ISS diffracted power has generally been trending down over the past week, but at least it's starting to settle back at the desired setpoint of 4%. No other major events of note.

Images attached to this report
LHO VE
david.barker@LIGO.ORG - posted 10:41, Tuesday 26 August 2025 (86569)
Tue CP1 Fill

Tue Aug 26 10:07:19 2025 INFO: Fill completed in 7min 15secs

 

Images attached to this report
H1 ISC
daniel.sigg@LIGO.ORG - posted 10:38, Tuesday 26 August 2025 - last comment - 13:21, Tuesday 26 August 2025(86568)
Whitening chassis for ASC-AS_C and OMC-REFL_A changed

This continues work from alog 86442. A new cable, D2500252, was made to replace the old ISC_455 (D2200327) and ISC_39 (standard 25-pin d-sub cable).

The DC offset have been adjusted but not accepte din SDF.

The second anti-whitening filter of OMC-REFL_A is now a normal anti-whitening filter, zpk([10],[1],1,"n"), and not the antiLP, zpk([49.63],[497.5],-0.9995,"n"). However, the filter files are not updated yet.

Comments related to this report
elenna.capote@LIGO.ORG - 12:53, Tuesday 26 August 2025 (86579)

Initial alignment post-maintenance is currently failing at SR2_align because there is no signal on AS_C. We think this change may be the culprit.

daniel.sigg@LIGO.ORG - 13:21, Tuesday 26 August 2025 (86582)

And back to the old board. Seems we have an issue with the new cable...

H1 SUS (SEI)
jeffrey.kissel@LIGO.ORG - posted 10:03, Tuesday 26 August 2025 (86567)
H1 SUS SR3 M1 Pitch and Yaw Estimator: Was missing L to P Sus. Point Input -- now Installed
J. Kissel, E. Bonilla, I. Zhong, B. Lantz, O. Patane

Per LHO:86563, Edgard found/noticed that the H1SUSSR3 M1 Pitch Estimator system wasn't using the Sus Point L to M1 P contribution that had been a part of the design intent. I used 
    /ligo/svncommon/SusSVN/sus/trunk/HLTS/Common/FilterDesign/Estimator/
        make_SR3_pitch_model.m      rev 12618
to install the extra filters into FM1 and FM2 of the H1:SUS-SR3_M1_EST_P_FUSION_MODL_SUSP_L_2GAP filter bank.
The script uses 
    /ligo/svncommon/SusSVN/sus/trunk/HLTS/Common/FilterDesign/Estimator/
        Clean_fits_H1SR3_P_2025-08-05.mat      rev 12594

Steps to install:
(0) From the sitemap, open up the SR3 overview screen, and find the pitch estimator overview screen as well as the Sus Point to M1 filter bank collection.
(1) Open matlab, navigate to the above directory and open the script.
(2) TURN THE ESTIMATOR OFF, by using the the fader switch: H1:SUS-SR3_M1_EST_P_SWITCH_NEXT_CHAN goes from 3.0 to 2.0 (but you can do this with the "Use OSEM" button on the estimator overview screen)
(3) Run the matlab script -- this uses autoquack (LIGO's home brewed matlab-to-foton filter install function) to push the matlab filter to SR3's foton file.
(4) Open up the SR3 GDS_TP screen, where there should now be a "Modified Filter File" message shown on the channel H1:FEC-44_MSG2. Use the !DIFF button -- which pops up a screen showing the diff between what's installed and what you're about to install -- to validate at least that "the only filter bank that's been touched or modified is the new L to P filter" (since it's tough to validate Second Order Sections by eye).
(5) THE ESTIMATOR IS OFF, RIGHT? OK, then hit the "COEFF LOAD" button. The filter names listed below should appear in FM1 and FM2 of the EST_P_FUSION_MODL_SUSP_L_2GAP bank.
(6) THE ESTIMATOR IS OFF, RIGHT? OK, then use the MEDM interface on the EST_P_FUSION_MODL_SUSP_L_2GAP screen to turn on the input, output, FM1 and FM2, and set the gain to 1.0
(7) While the impulse response of the filter settles, set the H1:SUS-SR3_M1_EST_P_FUSION_MODL_SUSP_L_2GAP_STATE_GOOD filter module state checker bit word to match the current state's word H1:SUS-SR3_M1_EST_P_FUSION_MODL_SUSP_L_2GAP_STATE_NOW. Should need a change from 0x2000000 to 0x6000f4.
(8) Turn the estimator back ON. And at least look at the estimator overview screen to confirm that sensor signals are not going bonkers. In fact, they really shouldn't look that different at all.
(9) If you like what you see, go back to the GDS_TP screen and accept the new EPICs settings with this new filter ON in both the safe and observe snap files:
    /opt/rtcds/userapps/release/sus/h1/burtfiles/
        h1sussr3_safe.snap
        h1sussr3_observe.snap
commit these to the userapps svn with the appropriate message when you're done.
(10) Commit the updated foton file to the userapps svn with a similar message
    /opt/rtcds/userapps/release/sus/h1/filterfiles/
        H1SUSSR3.txt
(11) Profit! Start looking at the performance!

Here's the design explicitly:
SR3_M1_EST_P_FUSION_MODL_SUSP_L_2GAP
FM1        "ISI_fit_L"      Fit to (M1 Response / Sus. Point L Excitation) TF, plus calibration from nm to um.
    sos(0.0001142264006754552, 
        [-2.0000000000000009; 1.0000000000000011; 
         -1.999975478282779; 0.99997585128576594; 
         -1.999816005993748; 0.99982977526725314; 
         -1.999982188592295; 0.99998283118601283; 
         -1.999884963247067; 0.9998851520162283; 
         -1.999988292191436; 0.99998835461999513; 
         -2.0001080651245839; 1.0001082464362681; 
         -1.999989760987597; 0.99998984142840619; 
         -2.000082349605993; 1.0000836590827351; 
         -1.9999909890250209; 0.99999272379034698])
FM1        "to_um/nm"       Vestigial Organ; calibration is folded in to FM1's filter these days.
     zpk([],[],1.000000000000000,"n")
Images attached to this report
H1 TCS
matthewrichard.todd@LIGO.ORG - posted 09:27, Tuesday 26 August 2025 - last comment - 14:20, Tuesday 26 August 2025(86566)
Changing TCS-SIM values for surface defocus effects

M. Todd, C. Compton, S. Dwyer


We changed the gain settings in TCS-SIM that convert the powers of each actuator (including self-heating) to surface defocus for calculating the overall radius of curvature of each test mass at a given thermal state.

The motivation for this was that the simulation seems to be largely overestimating the Higher Order Mode spacing. Hopefully, with these new predictions, we will observe better agreement between the simulation and HOM measurements.

We also changed the absorption values using values taken from alog 80714 for the ITMs, and using galaxy for the values for the ETMs.

 

Images attached to this report
Comments related to this report
anthony.sanchez@LIGO.ORG - 14:20, Tuesday 26 August 2025 (86585)

Hey.... these are some SDF's that I think are related to your work.
I accepted them all.

Images attached to this comment
H1 General
anthony.sanchez@LIGO.ORG - posted 07:43, Tuesday 26 August 2025 - last comment - 13:12, Tuesday 26 August 2025(86565)
Tuesday Ops Maintenance Day

TITLE: 08/26 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 15mph Gusts, 9mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.09 μm/s
QUICK SUMMARY:
H1 has been locked for 10+ hours.

Today At 14:21 UTC it appears the Magnetic Injections started.
At 14:40 UTC Back to Observing.
Down to Commissioning again at 14:45 UTC



Expected Tuesday Maintenance Work:
VAC - MX and MY pump install work continuing (booster pumps will be connected)
VAC - BSC1 AIP troubleshooting. Needs LASER SAFE condition.  Postponed
VAC - LN2 delivery: MX (CP5) and MY (CP3)
VAC - FC guage work (pumping)
Randy - North Bay - cleaning of top of eMod
Randy - East Bay - remove C3 cleanroom sock cover over HAM5 & 6
FAC - rock delivery at Staging building
CDS -Daniel - Change the whitening chassis that is currently used for the ASC-AS_C QPD
Fil - HAM5&6 racks - install of BHD stuff
LN2 - MY & MX
Charge meas't ?

 

 

Comments related to this report
anthony.sanchez@LIGO.ORG - 12:29, Tuesday 26 August 2025 (86576)

SNEWS Test @ 16:59 UTC 
Vaccum Mid X Pressure alarm Low 17:53 UTC.
12 Hours ago there was an increase in CER Temps

Expected Tuesday Maintenance Work:
Done - VAC - MX and MY pump install work continuing (booster pumps will be connected)
Postponed ------ VAC - BSC1 AIP troubleshooting. Needs LASER SAFE condition. 
Done - VAC - LN2 delivery: MX (CP5) and MY (CP3)
"Done ....For Now...." ~ Gerardo - VAC - FC guage work (pumping)
Done North Bay - cleaning of top of eMod
Done  East Bay - remove C3 cleanroom sock cover over HAM5 & 6
Done -  FAC - rock delivery at Staging building 
Done - CDS -Daniel - Change the whitening chassis that is currently used for the ASC-AS_C QPD
Done - Fil - HAM5&6 racks - install of BHD stuff
Done - LN2 - MY & MX
Done - SUS Charge meas't ?
Done - Beaver Bark gravel dumps 
Done - Dust Mon Pump Swap
 

CER temps are now dropping

camilla.compton@LIGO.ORG - 13:12, Tuesday 26 August 2025 (86577)OpsInfo, SQZ

Elenna noticed that we dropped from Observing 8 times last night, for around 2 minutes each time, plot. This was mainly due to the OPO loosing lock, reporting "2025-08-26_08:04:01.503798Z SQZ_OPO_LR [LOCKED_CLF_DUAL.run] USERMSG 0: OPO not really locked or maybe locked in a wrong mode" and taking itself to DOWN. I don't see a clear reason why, plot attached.

The OPO PZT was around 100V but we can operate up to 110V and the OPO ISS AOM was at it's central value of 5V. 

There is some OPO TRANS glitches where the power drops by more than 20% but the OPO stays locked, plot attached.

  • 7:10UTC OPO lost lock
  • 7:14UTC OPO lost lock
  • 7:18UTC FC lost lock
  • 8:03UTC OPO lost lock
  • 9:05UTC FC lost lock
  • 10:06UTC ISS LL counter.
    • Message "2025-08-26_10:06:12.261378Z SQZ_OPO_LR [LOCKED_CLF_DUAL.run] USERMSG 0: Disabling pump iss after 10 lockloss counter. Going to through LOCKED_CLF_DUAL_NO_ISS to turn on again."
    • The OPO ISS turned off, we see no reason why, it was at 5V, the middle of it's range, see attached plot.
  • 10:07UTC OPO lost lock
  • 10:15UTC OPO lost lock

Tagging OpsInfo, please check for drops in Observing overnight using the verbal alarms computer and tag the relevant team in your alog it it's obvious what caused the observing drop. For SQZ, there is a ndscope under sitemap > SQZ > SQZ Overview > ! SQZ Scopes > SQZ Guardians that compares the H1:GRD-IFO_OK channels to all SQZ Guardian to see if they were the reason for the observing drop.

Images attached to this comment
H1 SUS (ISC, SEI)
oli.patane@LIGO.ORG - posted 16:55, Monday 25 August 2025 - last comment - 14:22, Tuesday 26 August 2025(86551)
Correction/Update: SR3 Estimator Impact on ASC (plus new OMC and ASC-AS plots)

Jeff, Oli

On Thursday (86507) I alogged the differences we were seeing in the ASC with the SR3 estimator on. The time that I was taking as our 'reference time' for the estimator off, however, doesn't seem like it was a good time showing the lowest the ASC noise could be. You could say this caused us to over estimat(or) the differences.
So I plotted some more times with the estimator off, then with the estimator on, and I found that maybe the SR3 noise is limiting the ASC noise less than shown in 86507. However, I also found that below 0.2 Hz, where we thought that the estimators were elevating the noise, that also seems to have been not related to the estimator, so that is something we might not have to worry about. 
Of course the peaks at 0.6 and 0.7 Hz are elevated in the estimator plots below due to not damping them in the inital blend filter (mentioned in 86507), and this is something that we partially fixed this morning (86544), and will be working on further damping at the next available commissioning time.

There are still times where the estimator on makes the noise better at some frequencies, but there are also other times where the estimator is on, but something else is limiting the noise, so it looks like SR3 isn't limiting the noise very much at all. It will still be interesting to see if adding estimators onto the rest of the SRC give us different results.

In the plots below, I am showing the variation in noise with the estimators off and the estimators on,
The 'bad' time for the estimators OFF is: 2025-08-17 09:00 UTC (green)
The 'good' time for the estimators OFF is: 2025-08-20 18:29 UTC (blue)
For the estimators ON times, they're both 'good' and 'bad' at different frequencies, so I'll just list their times:
2025-08-21 16:35 UTC (red)
2025-08-24 18:18 UTC (gold)

  Pitch Yaw
ASC-DHARD Error
Est OFF Est ON Both Est OFF Est ON Both
Control
Est OFF Est ON Both Est OFF Est ON Both
ASC-MICH Error
Est OFF Est ON Both Est OFF Est ON Both
Control
Est OFF Est ON Both Est OFF Est ON Both
ASC-SRC1 Error
Est OFF Est ON Both Est OFF Est ON Both
Control
Est OFF Est ON Both Est OFF Est ON Both
ASC-SRC2 Error
Est OFF Est ON Both Est OFF Est ON Both
Control
Est OFF Est ON Both Est OFF Est ON Both
ASC-AS_A_DC Control
Est OFF Est ON Both Est OFF Est ON Both
ASC-AS_B_DC Control
Est OFF Est ON Both Est OFF Est ON Both
ASC-OMC_A Control
Est OFF Est ON Both Est OFF Est ON Both
ASC-OMC_B Control
Est OFF Est ON Both Est OFF Est ON Both
OMC-DCPD_SUM_OUT Est Off Est ON Both
OMC-REFL_A_LF_OUT Est Off Est ON Both

 

Images attached to this report
Comments related to this report
edgard.bonilla@LIGO.ORG - 22:02, Monday 25 August 2025 (86562)

Jeff, Oli, this is good to know!

I also noticed that the SUSpoint L to M1 P block of the estimator does not have the corresponding filter fit. For the Pitch degree of freedom, we expect the ISI longitudinal contribution to be relevant enough that it should be modeled. Maybe this explains some of the inconsistent behavior around the length/pitch modes.

I modified 'make_SR3_pitch_model.m' inside sus/trunk/HLTS/Common/FilterDesign/Estimator to ensure that we get the correct fits into this filter bank. This update is current as of SVN revision 12616

In total, autoquack should populate 3 filter banks for the pitch estimator:

SR3_M1_EST_Y_FUSION_MODL_SUSP_L_2GAP
SR3_M1_EST_Y_FUSION_MODL_SUSP_P_2GAP
SR3_M1_EST_Y_FUSION_MODL_DRV_P_2GAP
brian.lantz@LIGO.ORG - 14:22, Tuesday 26 August 2025 (86586)

Wow. Thanks for all the data. One quick clarification. Above it says "Of course the peaks at 0.6 and 0.7 Hz are elevated in the estimator plots below due to not damping them in the inital blend filter" 

To be clear, the first version of the pitch estimator was designed to damp these peaks. But - recall that "estimator" is the blend of the model and the measurements. In the first version, nearly all of the damping signal in the estimator was from the MODEL, whereas the 2 higher frequency peaks (and all 3 yaw peaks) use the MEASUREMENT path from estimator. In version 1, the model path for the estimator wasn't working well. This seems to mean that the model is not correctly predicting the gap motion. We suspect that this is because of an unmodeled drive, which we think is DAC noise.

So we were applying damping with the estimator, but it was not working as expected. Version 2 has updated blend filters which use the osem signals around all 4 peak frequencies, and hopefully this will improve the estimator performance.

H1 ISC
camilla.compton@LIGO.ORG - posted 09:04, Monday 25 August 2025 - last comment - 11:52, Tuesday 26 August 2025(86543)
Elenna's new SRCL FF Fit turned on

In 86481, Elenna proposed using a new FF fit as the bruco showed SRCL coherence, this has improved the low frequency SRCL noise, but moved the bump at 200Hz to 100Hz, overal a small improvement, see plot attached. Saved in ISC_LOCK and safe and observe sdfs.

Images attached to this report
Comments related to this report
camilla.compton@LIGO.ORG - 10:25, Monday 25 August 2025 (86549)

I doubled the amplitude of the injection from 0.04 to 0.08, ran the template and saved as /lsc/h1/scripts/feedforward/SRCL_excitation.xml while FM5 was on, so that in the future we can try to fit a separate >100Hz filter as Elenna suggests in 86481. I didn't measure the pre-shaping as expect we recently have that.

Images attached to this comment
elenna.capote@LIGO.ORG - 11:52, Tuesday 26 August 2025 (86572)

In preparation to create a high frequency SRCL FF based on this data, I copied the SRCLFF1 FM10 highpass into FM10 of SRCLFF2 (not to be confused with a different, older "highpass" in FM1 of SRCLFF2).

Displaying reports 161-180 of 84278.Go to page Start 5 6 7 8 9 10 11 12 13 End