Displaying reports 1401-1420 of 83068.Go to page Start 67 68 69 70 71 72 73 74 75 End
Reports until 14:25, Wednesday 23 April 2025
H1 ISC
daniel.sigg@LIGO.ORG - posted 14:25, Wednesday 23 April 2025 (84092)
ISC Cabling HAM1/ISCT1 and Field Racks

Marc Fil Daniel

We finished the cabling work for the ISC cables between HAM1, ISCT1, and ISC-R1/2/4. This includes re-labeling of all cables that had no or misleading labels.

H1 General (DetChar)
preeti.sharma@LIGO.ORG - posted 14:01, Wednesday 23 April 2025 (84090)
Duty Cycle in O3 and O4 winters vs microseismic ground motion

Preeti, Gaby, Tabata, Debasmita

Summary:

We calculated the duty-cycle of L1 and H1 in O3, O4a and O4b winters (Nov, Dec, and Jan) on each day and plotted with the median of microseismic ground motion in 0.1-0.3 Hz and 0.3-1.0 Hz. The duty-cycle was modified by removing earthquake times (ground motion in the 0.03-0.1 Hz band above 150 nm/sec) from lock duration and day duration.

Conclusion:

Images attached to this report
H1 SUS
oli.patane@LIGO.ORG - posted 12:55, Wednesday 23 April 2025 (84083)
ITMY M0 TF comparison with ISI in Fully Isolated

After the ITMY transfer functions I posted Monday(84031), there was some discussion by Edgard and Brian about an extra zero on M0 between L and P ~0.27Hz that maybe seems like it's there when the ISI is isolated and now there when the ISI is in Damped (although he later decided that maybe that didn't make much sense 84068). I took some ITMY M0 transfer functions yesterday afternoon with the ISI in Isolated, to check out any possible correlations there.

Looking at the comparison between Monday and yesterday's measurements(pg 13-14), where the only difference was the ISI in Damped vs Fully Isolated, respectively, that difference alone doesn't seem to account for the disappearence of the extra zero. This further backs up the conclusion Edgard came to this morning.

Data (/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ITMY/SAGM0/Data/)
2025-04-22_2300_H1SUSITMY_M0_Mono_WhiteNoise_{L,T,V,R,P,Y}_0p01to50Hz.xml
In SVN as r12271

Results (/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ITMY/SAGM0/Results/)
2025-04-22_2300_H1SUSITMY_M0_ALL_TFs.pdf
In SVN as r12272

Comparison (/ligo/svncommon/SusSVN/sus/trunk/QUAD/Common/Data/)
allquads_2025-04-23_ISI-DampedvFullyIso_Apr212025vApr222025_ALLM0_TFs.pdf
allquads_2025-04-23_ISI-DampedvFullyIso_Apr212025vApr222025_ALLM0_ZOOMED_TFs.pdf

In SVN as r12274

Non-image files attached to this report
LHO VE
david.barker@LIGO.ORG - posted 11:48, Wednesday 23 April 2025 (84086)
Wed CP1 Fill

Wed Apr 23 10:08:22 2025 INFO: Fill completed in 8min 19secs

 

Images attached to this report
H1 AOS (SEI)
jason.oberling@LIGO.ORG - posted 11:45, Wednesday 23 April 2025 (84085)
WHAM1 ISI Alignment Complete

J. Warner, R. Crouch, J. Oberling

Took another look at WHAM1 ISI alignment this morning after the HEPI actuators were attached yesterday.

The total station occupied monument LV25 and we used LV26 as the backsight.  The autolevel was placed sighting 171.9 mm on the scale we attached to height mark 600, placing it +100.0 mm above the ISI target z-axis position.  Measurements and calculations done as detailed in alog 84057.

We initially found the ISI a little off level, it was high on the -X side, so Jim did a small correction for that (it has to be small since there is much less range in HEPI with the actuators attached).  Final positional deviations from the ISI target of [-22726.7, 0.0, -201.9] mm are:

Tolerances for position are +/- 3.0 mm in all axes (reusing tolerances from aLIGO install); I don't find a yaw tolerance in my aLIGO install notes so we tried to minimize it while making other adjustments, I'd say <100 µrad is pretty good.  Jim says the level is good, so this ends IAS for the WHAM1 ISI for now.  IAS equipment has been taken down, although we still have it in the general area should there be a need to take another look at the ISI before the chamber is closed.

Based on the above deviations, the WHAM1 ISI coordinates in the LHO global coordinate frame are [-22725.9, +1.9, -201.75] mm.

Data and Calculations

Data and calculations for the above results.

X-axis Position and Yaw:

Y-axis Position:

Z-axis Position and Level:

LHO VE
jordan.vanosky@LIGO.ORG - posted 10:30, Wednesday 23 April 2025 (84082)
Morning Purge Air Checks 4-23-25

Morning dry air skid checks, water pump, kobelco, drying towers all nominal.

Dew point measurement at HAM1 , approx. -42C

Images attached to this report
H1 PSL
ryan.short@LIGO.ORG - posted 09:55, Wednesday 23 April 2025 (84081)
PSL First Amplifier Pump Diode Currents Increased

We noticed following the power outage a couple weeks ago that we set the pump diode currents 0.1A lower than they should have been, so this morning I bumped them up from 8.7A to 8.8A each (with the ISS off). This caused a ~1W increase of power out of both amplifiers, and a ~0.5W increase in both PMC transmitted and reflected power. Trends attached.

Images attached to this report
H1 TCS
matthewrichard.todd@LIGO.ORG - posted 09:41, Wednesday 23 April 2025 - last comment - 09:41, Wednesday 23 April 2025(84069)
Using HOM spacing to estimate surface defocus from self heating and ring heater power

M. Todd, C. Compton, S. Dwyer


This is a continuation of the last alog discussing how we can estimate thermal actuator contributions to the surface curvature to the test masses. In this I tried to layout the problem with a little more detail.


Essentially, with a few different ring heater powers and their corresponding HOM spacing measurements from OMC data, we can estimate the coupling factor of ring heater power to test mass surface defocus [D/W]. The assumption is that the cavity g-factor is linear with this ring-heater power dependence, and higher order terms are assumed to be small enough to ignore.

This fit to a premlinary dataset (one HOM data point per ring-heater power_) yields a ring-heater coupling value of 0.6483 uD/W -- note: the HOM spacing has been observed to change during the same ring heater powers over time, and these should be included in the dataset.

This value is about 65% of what we think it to be, from TCS - SIM.


We can also constrain the HOM spacing shift from self-heating alone using the intercept of this curve -- this is estimated to be about 153 Hz (from 5166Hz to 5319Hz), compared to the predicted 411Hz change.

The plots and derivations are attached in the notes pdf

Non-image files attached to this report
Comments related to this report
matthewrichard.todd@LIGO.ORG - 09:05, Wednesday 23 April 2025 (84080)

For posterities sake, I'm adding links to the values of the parameters that we assume.

 

ITMY cold RoC : galaxy (line 96) and dcc (page 7), there is a ~1m discrepancy, but probably not a huge deal

ETMY cold RoC: galaxy (line 50) and dcc (page 5)

Arm Length:  dcc

LHO General
ibrahim.abouelfettouh@LIGO.ORG - posted 08:16, Wednesday 23 April 2025 (84078)
OPS Day Shift Start

TITLE: 04/23 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    SEI_ENV state: MAINTENANCE
    Wind: 2mph Gusts, 0mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.17 μm/s
QUICK SUMMARY:

IFO is in MAINTENANCE for the VENT

Planned tasks today and rest of the week:

Work safe!

H1 CDS
david.barker@LIGO.ORG - posted 06:57, Wednesday 23 April 2025 - last comment - 07:31, Wednesday 23 April 2025(84076)
CDS Maintenace Summary: Tuesday 22nd April 2025

WP12463 PSL ON/OFF boolean controls

Keita, Jonathan, Dave:

Keita generated new h1pslpmc and h1pslfss models by modifying the common pslpmc.mdl and pslfss.mdl model files to convert integer EPICS inputs to binary input parts. Some internal changes were made to make full use of the boolean signals. Filtermodules which were no longer needed were kept in the models to preserve their DAQ channels, the parts were just parked by the side with grounded inputs. MEDM and Guardian code changes were required. DAQ restart was required.

see alog84044 for details

also FRS5861

WP12466 PM1 HAM1 SWWD

Dave:

The PM1 suspension was added to HAM1's SWWD. h1iopsush2b was modified to add this part, all the models on h1sush2b were restarted as part of this work. DAQ restart was required.

Please see alog84060 for details.

WP12477 Fix miswired MADC parts in h1iopseih16

Dave:

To prevent interruption of HAM1 seismic work the new h1iopseih16 model was not installed today, deferred until later.

WP12472 ASC and LSC changes for POP_X and LSC_REFL_B

Daniel, Dave:

Daniel installed new h1lsc and h1asc models. Because these did not require a DAQ restart this was done on Monday.

See alog84026 for details.

h1seih16 model start reordering

Erik, Dave:

The model start order for the models in h1seih16 was changed to conform to the other HAM seismic frontends. This also reordered them on the CDS overview.

Please see alog84047 for details

Fix of ETMX Beckhoff baffle photodiode readouts following power outage

Fil, Dave:

Fil found a power supply issue at ETMX and restored the baffle PDs.

Please see alog84052 for details

Add EPICS outputs to PSL models to fix "missing ADCs" on MEDMs

Dave:

I took the opportunity during the PSL model and DAQ restarts to put in EPICS OUTPUT parts in PSL models to make their RCG generated ADC MEDM files complete.

Changes were made to h1pslpmc, h1pslfss and h1psldbb. DAQ restart was required.

WP12473 Beckhoff slow controls HAM1 upgrade.

Daniel, Dave:

Daniel created a new h1ecatisccs PLC which added JAC channels to its DAQ INI file. This was completed at the end of the maintenance period, so it was decided to defer the DAQ restart to another day.

Please see alog84055 for details.

Testing new frame writer h1daqfw2

Jonathan, Dave:

Jonathan installed a test frame writer h1daqfw2 to the DAQ system (hardware is a repurposed h1digivideo3). It connects to h1daqnds0 via a private gigabit ethernet link.

DAQ Restart

Dave, Jonathan:

The DAQ was restarted for the above model changes (not an EDC restart). This was a clean and unremarkable restart.

As Keita noted in his PSL alog, because the data type of the PSL on/off PVs changed from float to an integer representation of a boolean, if you trend these channels back before 22apr2025 zero is still zero, but non-zero is an arbitrary number.

Channels this applies to are:

H1:PSL-PMC_ALIGNRAMP_ON datatype change from 4 to 2
H1:PSL-PMC_BLANKING datatype change from 4 to 2
H1:PSL-PMC_BOOST datatype change from 4 to 2
 H1:PSL-PMC_LOCK_ON datatype change from 4 to 2
 H1:PSL-PMC_RAMP_ON datatype change from 4 to 2
H1:PSL-PMC_TF_IN_ON datatype change from 4 to 2
H1:PSL-FSS_TEMP_LOOP_ON_REQUEST datatype change from 4 to 2
H1:PSL-FSS_AUTOLOCK_ON datatype change from 4 to 2
H1:PSL-FSS_TEST1_ON datatype change from 4 to 2
H1:PSL-FSS_TEST2_ON datatype change from 4 to 2
 

Comments related to this report
david.barker@LIGO.ORG - 07:31, Wednesday 23 April 2025 (84077)

Tue22Apr2025
LOC TIME HOSTNAME     MODEL/REBOOT
09:18:02 h1psl0       h1pslpmc    <<< boolean on/off and missing-adc
09:18:25 h1psl0       h1pslfss    <<< boolean on/off and missing-adc
09:18:48 h1psl0       h1psldbb    <<< missing adc
09:20:56 h1sush2b     h1iopsush2b <<< PM1 in SWWD
09:21:10 h1sush2b     h1susim     <<< iop restart
09:21:24 h1sush2b     h1sushtts   <<< iop restart
09:23:53 h1daqdc0     [DAQ] <<< 0-leg
09:24:04 h1daqfw0     [DAQ]
09:24:04 h1daqtw0     [DAQ]
09:24:05 h1daqnds0    [DAQ]
09:24:13 h1daqgds0    [DAQ]
09:28:08 h1daqdc1     [DAQ] <<< 1-leg
09:28:21 h1daqfw1     [DAQ]
09:28:21 h1daqtw1     [DAQ]
09:28:22 h1daqnds1    [DAQ]
09:28:31 h1daqgds1    [DAQ]
 

 
Mon21Apr2025
LOC TIME HOSTNAME     MODEL/REBOOT
12:50:18 h1lsc0       h1lsc       <<< POP_X and LSC_REFL_B
12:53:33 h1asc0       h1asc       <<< POP_X and LSC_REFL_B

H1 CAL
anthony.sanchez@LIGO.ORG - posted 18:43, Tuesday 22 April 2025 (84075)
PCAL TX Module Maintence @ EX

Rick and I went down to End X to try and tune up the X End TX module. DCC T1600436-V12
We found the OFS offset to be set at 3.85V before we arrived.
A number of our measurements were made with the OFS Offset set to 7.7 V which is 100% of our useable OFS functionality. All of our low power measurments were done this way,  and perhaps we should have dialed that back to 95%  which may explain why some of our number look a little higher than last year's.
The Integrating sphere Apature target was put on the RX sensor.
The AOM position was adjusted, but resulted in no noticable difference in power.
The Beam spot on the TX PD was touched up, as it was not centered.
The Temperature and current for the Pumping Diode on the CrystaLaser Power supply was touched up to try and get some more performance out of it. 
And the spot on the internal spectralon shell of the RX sensor was blown out with some compressed air. Spot is now gone.
 

Date April-22-2025
Laser Shutter Check Pass
Max OFS Offset 7.7V
95% OFS Offset 7.315
Operating OFS Offset 3.6575
Laser Output Power 1.7
After-Laser Rejected Power                      34.6mW
AOM Input Power 1.65W
Max Diffracted Power 1.14W
Un-Diffracted Power                        0.307W
AOM Diffraction Efficiency 0.69
After-AOM Rejected Power                      15.2mW
TxPD Power                      11.9mW
OFSPD Power                        5.7mW
Outer Beam Power 0.536
Inner Beam Power 0.526
Output Beam Power Ratio 0.9813
OFS Gain 39.6
OFS Phase Margin 42.1
   
Images attached to this report
Non-image files attached to this report
H1 General
richard.savage@LIGO.ORG - posted 17:54, Tuesday 22 April 2025 - last comment - 07:00, Thursday 24 April 2025(84073)
Ladder section along X-arm access road between mid- and end-station

There is a ladder section along the X-arm access road between the mid- and end-stations.

The second attached photo was taken looking toward the mid-station from the direction of the end-station.

Images attached to this report
Comments related to this report
christopher.soike@LIGO.ORG - 07:00, Thursday 24 April 2025 (84100)
Thank you Rick. Facilities is aware of the ladder. It was there for easier access during "Tumblegeddon" a couple years back. It got buried at some point during that time. I just recently found it again while tumbleweed mulching recently. We will do something with it ASAP. Thank you for the reminder.
H1 PSL (PSL)
keita.kawabe@LIGO.ORG - posted 17:15, Tuesday 22 April 2025 - last comment - 17:15, Tuesday 22 April 2025(84044)
Change in PSLFSS and PSLPMC (Keita, Dave)

WP 12463: This will close this FRS: https://services1.ligo-la.caltech.edu/FRS/show_bug.cgi?id=5861

We changed PSLFSS and PSLPMC model and related MEDM screens and confirmed that the PMC and FSS relocked right away before RyanS started his work in the PSL room. Guardian was modified to accomodate this. Safe SDF for PMC and FSS were updated.

(FYI, the motivation for this ancient ticket was to kill the habit of using arbitrary number for ON/OFF status, which was really bad in all PSL models. Depending on who wrote what, sometimes 1 means ON, sometimes -1, some other times -30000, and these status were cdsEpicsInput which are floating point. Now they're cdsEpicsBinIn, which is binary, ON is 1, OFF is 0.)

Model changes:

I pulled pslfss and pslpmc model from svn to close the FRS above. We'll have to keep some local modifications unique to LHO at least until the end of the run. Due to local changes, the models will not be committed to SVN upstream.

Changed models: ${userapps}/release/psl/common/models/pslfss.mdl, ${userapps}/release/psl/common/models/pslpmc.adl, ${userapps}/release/psl/h1/models/h1pslfss.mdl.

See the first two screen shots.

Local modifications 1: Adding back CALI filters.

These filters are not used any more from this point on. However, removing these from DAQ means that we cannot trend the data of these back without using NDS2 and specifying epoch, which is not a great thing to do in the middle of the run.

  1. Added back PSL-FSS_TEST1_ON_CALI and PSL_FSS_TEST2_ON_CALI filters to pslfss common model, but grounded all of them.
  2. Added back PSL-PMC_TF_IN_ON_CALI, PSL-PMC_LOCK_ON_CALI, RAMP_ON_CALI, BLANKING_CALI, BOOST_CALI filters to pslpmc common model, but grounded all of them.

See the first and second screen shot (red in the left panel).

Local modifications 2: Move NPRO_TEMP_OUT out of the common model and into the H1 model.

Dave originally added NPRO_TEMP_OUT channel to DAQ at 256Hz locally to the common FSS model in May 2023. However, he moved it to h1pslfss.

Local modifications 3: Don't change binary to DAC count and convert it back to binary

There was such a block in the common PMC model in the SVN (1st screen shot, right panel, green), which was eliminated in the local common model for the sake of simplicity.

Local modifications 4 (cosmetic): Define a constant representing DAC count that will produce +10V in the model.

Blue in the first two screen shots.

Dave thinks that this needs to be in the top level of local models (not in the common model) right before the signal goes to DAC in the future. That way, when we upgrade the DAC we can just change the constant.

MEDM changes:

Manually changed: ${userapps}/release/psl/common/medm/PSL_PMC.adl as the file on SVN still uses the old logic.

Pulled from SVN: ${userapps}/release/psl/common/medm/PSL_FSS.adl and ${userapps}/release/psl/common/medm/FSS/MAN.adl (and other things in FSS directory).

Guardian changes:

In isc_library.py,
L200    if ezca['PSL-PMC_LOCK_ON'] != -30000:
was changed to
L200    if ezca['PSL-PMC_LOCK_ON'] == 0:

In LASER_POWER.py,
L157            elif self.timer['wait_for_busy'] and ezca['PSL-ROTATIONSTAGE_STATE_BUSY'] == 0 and ezca['PSL-PMC_LOCK_ON'] == -30000:
L161            elif self.timer['wait_for_busy'] and ezca['PSL-ROTATIONSTAGE_STATE_BUSY'] == 1 and ezca['PSL-PMC_LOCK_ON'] == -30000:
were changed to
L157            elif self.timer['wait_for_busy'] and ezca['PSL-ROTATIONSTAGE_STATE_BUSY'] == 0 and ezca['PSL-PMC_LOCK_ON'] == 1:
L161            elif self.timer['wait_for_busy'] and ezca['PSL-ROTATIONSTAGE_STATE_BUSY'] == 1 and ezca['PSL-PMC_LOCK_ON'] == 1:
 

SDF changes:

See screen shots 3 and 4. (You can see that the old setpoints were float and the new setpoints are binary.)

It's not shown in the last screen shot but I accepted H1:PSL-FSS_AUTOLOCK_ON in the afternoon after RyanS locked the FSS again.

Images attached to this report
Comments related to this report
keita.kawabe@LIGO.ORG - 14:54, Tuesday 22 April 2025 (84064)

Caution about trending logic channels I changed today.

H1:PSL-PMC_LOCK_ON, H1:PSL-PMC_TF_IN_ON, H1:PSL-PMC_RAMP_ONI, H1:PSL-PMC_ALIGNRAMP_ON, H1:PSL-PMC_BOOST, H1:PSL-PMC_BLANKING, H1:PSL-FSS_AUTOLOCK_ON, H1:PSL-FSS_TEST1_ON, H1:PSL-FSS_TEMP_LOOP_ON_REQUEST

For these channels, 0 (zero) means OFF, and non-zero means ON. This doesn't change. It's just that many numbers like -1 and 1 and -30000 used to be used as "non-zero" depending on who wrote what,  but from this point "non-zero" can only mean 1.

However, due to the change from float to integer, if you trend these channels, non-zero value for the data older than 10AM-ish Pacific on Apr/22/2025 is not displayed correctly. Fortunately zero is still zero (Jonathan confirmed), so if you trend the data to see if something was ON, check that the channel was not zero, i.e. H1:PMC-TF_IN_ON != 0 rather than H1:PMC-TF_IN_ON == -30000.

H1:PSL-FSS_TEST2_ON

Semantics of this signal changed. It used to be that ON=0 (zero) and OFF=1 to compensate the inverted logic in the hardware, but now ON=1, OFF=0 as the logic inversion is in the model.

The same caveat about float to integer applies. If you want to trend this channel, check H1:PSL-FSS_TEST2_ON ~=0 rather than H1:PSL-FSS_TEST2_ON == 1, and then you have to be aware that H1:PSL-FSS_TEST2_ON ~=0 means OFF for data older than 10AM-ish Pacific on Apr/22/2025, but the same thing means ON for newer data.

H1 ISC
daniel.sigg@LIGO.ORG - posted 15:05, Tuesday 22 April 2025 - last comment - 14:05, Wednesday 23 April 2025(84065)
Issue with ISC_RF25-B/3

Marc Daniel

One of the coax cables shows a discontinuity at the feedthrough, ISC_RF25-B/3. This is the coax for ASC-REFL_B 9MHz chn 4 (Q4 RF Low). This is feedthrough D1-1D1. We can see the signal going though the pig-tail but terminating at the feedthrough. This could be an issue of the in-air pig-tail or the in-vac cable at the  feedthrough side.


Typical In-vacuum RFPD ASC Wiring Chain for aLIGO: https://dcc.ligo.org/LIGO-D1300467
O5 ISC/SQZ Wiring Diagram: https://dcc.ligo.org/LIGO-D1900511

Comments related to this report
marc.pirello@LIGO.ORG - 15:36, Tuesday 22 April 2025 (84067)

TDR Plot of the cables analyzed.

Images attached to this comment
filiberto.clara@LIGO.ORG - 14:05, Wednesday 23 April 2025 (84091)

Found faulty pin on one of the Accu-Glass 5-way coaxial pigtails. Pin 3 seems to have been improperly crimped/seated/damaged. See attached picture. The Pigtail cable was replaced. Initial testing shows all pins are now correct lengths. The cable with issue was ISC-RF25-B/3.

Images attached to this comment
LHO VE
janos.csizmazia@LIGO.ORG - posted 18:31, Monday 21 April 2025 - last comment - 08:10, Wednesday 23 April 2025(84042)
2025 April vent - VAC diary
4-21 (Monday) activities:

- The aux carts from the annuli of GV5 and HAM4 were valved out; after a little hesitation, both IPs turned over, so now all AIPs are in good shape, without external support
- The pumpdown of the corner continues, with the corner being at 1.51E-6 Torr, and HAM6 is at 1.49E-6 Torr. There is a ~17% increase in pumping speed relatively to the last pumpdown in 2024 August. The details will be summarized soon.
- The pressure in the soft-closed GV7's actuator was increased from 10 to 15 psig, in preparation of opening GV2 tomorrow
- The flanges of the recently installed HAM6 turbo and HAM6 gauge was leak checked, no leaks were found, with the background of <1.0E-10 He
- All the welding seams on the X-manifold have been leak checked, no leaks were found, with the background changing between 2.6-3.0E-10 He. The welds have been individually bagged, see attached pic
Images attached to this report
Comments related to this report
corey.gray@LIGO.ORG - 08:10, Wednesday 23 April 2025 (84079)EPO

Tagging this unique photo for EPO since these sorts of leak checks (on welds) you don't see everyday.  :)

H1 SUS
oli.patane@LIGO.ORG - posted 14:31, Monday 21 April 2025 - last comment - 11:31, Wednesday 23 April 2025(84031)
ITMY Health Checks In Vacuum

Took transfer functions for ITMY M0 and R0 now that we are in a good enough vacuum. The ones I had taken in air before doors were put on are here: 83876.

M0
Data (/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ITMY/SAGM0/Data/)
2025-04-21_1700_H1SUSITMY_M0_Mono_WhiteNoise_{L,T,V,R,P,Y}_0p01to50Hz.xml
Results (/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ITMY/SAGM0/Results/)
2025-04-21_1700_H1SUSITMY_M0_ALL_TFs.pdf
2025-04-21_1700_H1SUSITMY_M0_DTTTF.mat

Committed to svn as r12261 for both Data and Results

R0
Data
(/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ITMY/SAGR0/Data/)
2025-04-21_1800_H1SUSITMY_R0_WhiteNoise_{L,T,V,R,P,Y}_0p01to50Hz.xml
Committed to svn as r12259
Results (/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ITMY/SAGR0/Results/)
2025-04-21_1800_H1SUSITMY_R0_ALL_TFs.pdf
2025-04-21_1800_H1SUSITMY_R0_DTTTF.mat

Committed to svn as r12260

I wanted to compare these measurements with old ones, and on the first try I tried comparing these measurements to the last time that ITMY measurements in vac were taken, which was a measurements set from 2018-05-22_2119 and 2018-06-08_1608 for M0 and R0 respectively. However, comparing these two measurements to the ones I just took, there are multiple differences in some of the cross-coupling traces, so I then decided to also compare my measurements to the last full set that was taken (which was in air), 2021-08-10_2115 and 2021-08-11_2242 for M0 and R0. These measurements line up well with the current measurements, so ITMY is looking good!

Comparison between May/June 2018 In-Vac vs Aug 2021 In-Air vs April 2025 In-Vac (/ligo/svncommon/SusSVN/sus/trunk/QUAD/Common/Data/)
allquads_InVacComparison_MayJun2018vAug2021vApr2025_ALLM0_TFs.pdf
allquads_InVacComparison_MayJun2018vAug2021vApr2025_ALLM0_ZOOMED_TFs.pdf
allquads_InVacComparison_MayJun2018vAug2021vApr2025_ALLR0_TFs.pdf
allquads_InVacComparison_MayJun2018vAug2021vApr2025_ALLR0_ZOOMED_TFs.pdf
allquads_InVacComparison_MayJun2018vAug2021vApr2025_ALL_TFs.pdf
allquads_InVacComparison_MayJun2018vAug2021vApr2025_ALL_ZOOMED_TFs.pdf

Committed to svn as r12263

Non-image files attached to this report
Comments related to this report
edgard.bonilla@LIGO.ORG - 13:06, Tuesday 22 April 2025 (84058)SUS

Adding a comment to talk about the L2P coupling in page 20. It appears as if we have a non-minimum phase zero that appears and dissappears between measurements [see page 20 of the original post above].

While I don't have a full explanation for this behavior, I remember seeing these shenanigans when I was testing the ISI feedforward many years ago. I was too young to make any coherent argument about it, but I remember seeing that the state of the ISI seemed correlated with the behavior. If the ISI is ISOLATED we have normal behavior, if it is DAMPED then we have the non-minimum phase behavior.

Here is a comparison between the last few years of successful ITMY  M0 to M0 transfer functions, with the ISI states retrieved from plotallquad_dtttfs.m. The color coding is selected to separate the situations with the ISI in 'ISO', and with the ISI in any other state. in pseudocode:

switch ISI-STATE
    case 'Isolated'
        color='blue';
    case 'Damped'
        color='red';
    case 'Locked'
        color='black';
    otherwise
        color='magenta';
end
 
I note that with this small sample size, we indeed see that all of the cases with the ISI in ISOLATED look the same, with the correct zero behavior that the MATLAB QUAD model would have as well. As for the DAMPED state, there is one outlier, and it is the measurement from 2017-12-20. The reason for the discrepancy is unclear to me. I will try to get a larger sample size by looking at other QUADs later. Stay tuned!
Images attached to this comment
edgard.bonilla@LIGO.ORG - 10:38, Wednesday 23 April 2025 (84068)

I got the same comparison done for ITMX and the ISI backreaction theory really does not seem to hold water.

There are two main regimes, same as ITMY. This time, the more recent ITMX TFs (after 2017-10-31) look more similar to the old (prior to 2021) ITMY TFs.

I am at a loss of what is making the change happen. Brian suggested it might be related to the vertical position of the suspension, maybe this is the next thing to test.

Images attached to this comment
oli.patane@LIGO.ORG - 11:31, Wednesday 23 April 2025 (84084)

To back up Edgard's conclusion, I took measurments with the ISI in Fully Isolated and we didn't get the extra zero back 84083

H1 SUS (SEI)
brian.lantz@LIGO.ORG - posted 12:07, Saturday 19 April 2025 - last comment - 12:35, Wednesday 23 April 2025(84012)
OSEM estimator summary

Here's a quick summary of the Estimator installation from this week (Edgard, Oli, Jeff K, Brian L)

slides with basic info: T2500082 
FRS ticket 32526

Installation alogs
Infrastructure installed on HAM2/PR3 and HAM5/SR3, style updates to model, MEDM linked to sitemap - alog 83906

Tools installed in Estimator folder in the SUS SVN alog 83922

We updated the OSEM 10:0.4 calibration filters, but only on SR3 and PR3. alog 83913

Damping filters installed - alog 83926

Tested the fader switch - alog 83982

Designed and installed a blend for SR3 Yaw (DBL_notch in the first filter bank) - alog 84004

Created a new OSEM calibration script - alog 84005
(Edgard is thinking about a general version of this using Python, that is still TBD)

Fitting is well underway, but isn't done yet.

We made much more progress than we expected - thanks Oli and Jeff for all the help. It's not quite ready to go, we need to install the TF fits for the model.

We might have actually been able to test, except the temperature changes from the pumpdown were causing the SR3 optic to move, and the TFs were not very stable. Edgard is working on a log to document this. We have good fits for SR3 yaw taken Friday morning, and we might just try these remotely with Oli's help. We do plan to get a clean set of TFs in a few days when things have stabilized.

-- notes for next steps, thanks to Sheila for this --

We plan to leave the SR3 overall yaw damping gain at -0.5. This means we'll set the 'light damping' to -0.1  and the gain in the estimator to -0.4. Edgard used -0.1 for the fitting, but he notes that the Q's are pretty high so we may need to revisit this.

SR3 oplev channels are : H1:SUS-SR3_M3_OPLEV_{PIT,YAW}_OUT_DQ

Some interesting alogs about the impact of changes to SR damping: alog 72106 and 72130  

Elenna's PR3 coherence plots: alog 65495

 

Comments related to this report
brian.lantz@LIGO.ORG - 15:00, Monday 21 April 2025 (84029)

I've attached a quick spectrum of SR3 yaw and pitch on M3 as seen by the optical lever. It's odd - the yaw looks very lightly damped - but the IFO was in observe. You can not see real motion above the 3.4 ish Hz yaw mode (it should be falling faster that 1/f^6). You might be seeing real motion between the peaks though - and we can use that (peaks at 1, 2.3, 3.4).

(environment was pretty quiet - BLRMS - EQ is 40-100 nm/sec, microseism is 200-400 nm/sec, wind speed below 1 m/s, anthropogenic is 20-30 nm/sec. It's 3 pm Saturday afternoon, local time. )

I've added 2 more plots. The first is to check that the Y damping is on, and it seems to be. This is a spectrum of the Y osem signal. Ignoring seismic input (which is completely fair), the signal here should just be yaw_osem_noise * (1/1-G) (the minus sign assumes you get all the loop gain signs directly from the control). You can see dips at the resonances, so the loop is on, and has some gain, but not much at the 1 Hz mode, more at 3.4 ish Hz. I've also added my yaw noise reference from G2002065 - you can see here that the noise is a bit larger than my estimate above 1 Hz.

LDVW shows that the gain on the M1_DAMP_Y control was already turned down to -0.5 at this time.

Images attached to this comment
Non-image files attached to this comment
edgard.bonilla@LIGO.ORG - 12:35, Wednesday 23 April 2025 (84087)

Here is a comparison of the spectra of three channels that can be used to monitor the performance of the estimator. We compare the motion when the M0 Yaw damping loop gain is at -0.5, versus when it is at the -0.1 (which is what we are aiming for with the estimator). The equivalent estimator plots should look somewhere in between the purple and blue curves in the images attached.

- The first one is the OPLEV on SR3. If the estimator works, we should be able to see a difference on the mode Qs. The oplev should see that we are able to damp (or control) the modes to the same level as the -0.5 damping.

- The second one is the M1 OSEM spectrum. The closed loop spectrum dips at the resonances of the plant at -0.5 gain (because of the sensitivity function), so we should be able to see that the sensitivity (as seen by the OSEM) is different, but the OPLEV sees good control of the modes.

- The third one is the total drive on M1. We should see that the total drive around the resonances is similar to the drive we get with the -0.5 gain, but the total drive should decrease rapidly above 3 or so Hz. We will need a faster channel than the one shown in the last attachment.

 

The plan is to make a full list of channels to monitor in conversation with Oli and Jeff, then run a pilot test with the fits from 84041 later in the week.

Images attached to this comment
Displaying reports 1401-1420 of 83068.Go to page Start 67 68 69 70 71 72 73 74 75 End