Displaying reports 141-160 of 83039.Go to page Start 4 5 6 7 8 9 10 11 12 End
Reports until 16:45, Wednesday 25 June 2025
H1 General
anthony.sanchez@LIGO.ORG - posted 16:45, Wednesday 25 June 2025 (85346)
Wednesday Ops Eve Shift Start

TITLE: 06/25 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 153Mpc
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: EARTHQUAKE
    Wind: 18mph Gusts, 10mph 3min avg
    Primary useism: 0.17 μm/s
    Secondary useism: 0.06 μm/s
QUICK SUMMARY:
H1 is currently Locked, and Observing. We are currently riding out a 6.2 Mag Earthquake from Staint Helena.

 

 

H1 General
oli.patane@LIGO.ORG - posted 16:44, Wednesday 25 June 2025 (85345)
Ops Day Shift End

TITLE: 06/25 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 152Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY:

Currently Observing at 155 Mpc and have been Locked for 1 hour. Two locklosses today during my shift, but each time we were able to relock automatically and in under an hour.


LOG:

14:30 Observing at 145Mpc and have been Locked for almost 2.5 hours
15:00 Dropped out of Observing to start Commissioning
17:52 Lockloss
18:48 NOMINAL_LOW_NOISE
21:05 Observing
21:45 Lockloss                                                                                                                                                                                                                                                                                                                                                                                                   

Start Time System Name Location Lazer_Haz Task Time End
17:28 FAC Tyler High Bay n Looking for a tool 17:31
18:34   Betsy OpticsLab n Putting stuff away 18:54
19:29 FAC Randy EX n Picking up stuff 19:56
20:24   LIGO India Delegation MY n Inventory 22:24
21:16 FAC Tyler XARM n Checking out his faves: the bees 22:16
21:58 HWS Camilla, Matt LVEA n Turning down camera voltage 22:04
H1 General
ryan.short@LIGO.ORG - posted 15:59, Wednesday 25 June 2025 (85343)
Guardian Controlled Camera Exposure Now Working

Since the ISCT6 AS AIR camera (cam16) was moved to its new home on h1digivideo4 in early March (alog83176), Guardian had not been able to update its exposure due to the addition of a "set" button which needs to be pushed after setting the exposure request. I've updated and loaded ISC_LOCK and ALIGN_IFO to correctly write the exposure to the H1:VID-CAM16_EXP_REQ channel, then push the "set" button by writing some change to the H1:VID-CAM16_EXP_SET channel, in all places I could find (like MICH alignment, PREP_FOR_LOCKING, power increase states, and CLOSE_BEAM_DIVERTERS).

I suspect there are other instances where a Guardian node should be updated to correctly update a camera's exposure, but these were the places I immediately thought of.

H1 CAL (CAL)
joseph.betzwieser@LIGO.ORG - posted 15:21, Wednesday 25 June 2025 (85342)
Update of installed pydarm code
I'm followed the pydarm deployment instructions here, to update the LHO pydarm install.

This is the 20250625.0 tag for pydarm (found here), and located at /ligo/groups/cal/pydarm/20250625.0

This is not the default cds conda environment, but the default you get when typing pydarm at a command line, or specifically invoking by running "conda activate /ligo/groups/cal/conda/pydarm".

This release has several fixes and improvements, including broadband pcal vs sweeps plot, as well as some fixes for uncertainty generation for C01.
H1 General (ISC, Lockloss, PEM)
oli.patane@LIGO.ORG - posted 15:03, Wednesday 25 June 2025 (85340)
Lockloss

Lockloss at 2025-06-25 21:45 UTC probably from the wind. Three seconds before the lockloss, we had an EX saturation. Wind jumped up all of a sudden, peakmon jumped up (although from very low to still pretty low but LSC CPSFF was affected), DARM had a bit oscillation, and almost all the ASC channels rang up starting 20-25 seconds before the lockloss

Images attached to this report
H1 SQZ (SQZ)
leendert.schrader@LIGO.ORG - posted 14:52, Wednesday 25 June 2025 (85339)
Theoretical AOIs for ZM4 and ZM5
Leo S, Jennie W, Camilla C 

I am making a mode-matching simulation for the SQZ to OMC beam path. Needed the incidence angles for both ZM4 and ZM5.
Coordinate centers for B:M4, ZM4, ZM5, and C:M1 were obtained via HAM7 CAD model. In (x,y,z) coordinates (units in mm):
B:M4 = (301.05, -117.007, 210.816)
ZM4 = (-781.33, -117.007, 357.778)
ZM5 = (804.875, -117.007, -231.614)
C:M1 = (-391.16, -117.007, 19.558)

Vector arithmetic yields AOIs of 6.327 deg for ZM4 and 4.261 deg for ZM5.
H1 ISC
sheila.dwyer@LIGO.ORG - posted 14:26, Wednesday 25 June 2025 (85338)
no squeezing time

This morning Oli had the IFO in no squeezing from 15:01 UTC until 15:54 UTC

H1 SQZ
camilla.compton@LIGO.ORG - posted 14:18, Wednesday 25 June 2025 (85336)
Adjusted SQZ BLRMS #2 to be 90 to 250Hz

Sheila, Camilla 

After we found that yellow BLRMs wasn't the best measure of the range 84997, I edited SQZ BLRMs #2 to be a 90 - 250Hz BLRMS, see in the attached plot that it is a measure of SQZ angle, but doesn't seem any better than yellow (#3) right now. If we do PSAMs scans in the future, we should look at the orange BLRMs as another measure of low freq range.

Images attached to this report
H1 ISC
elenna.capote@LIGO.ORG - posted 13:02, Wednesday 25 June 2025 - last comment - 15:46, Thursday 26 June 2025(85330)
SRM alignment on POP vs AS72

Today I was able to drive a line on SRM pitch and yaw, aka SRC1 P and Y, in an attempt to understand how the SRM alignment signal appears in various sensors. Our current configuration has SRM alignment controlled via the AS RF72 signal, which is the beat of the 118 MHz and the 45 MHz.

To do this measurement, I engaged the usual 8.125 Hz notches in the ASC loops, and drove at 8.125 Hz at the SRC1 SM exc point. I measured the signals in the I and Q phase on AS RF72, AS RF45, AS RF36 and POP X RF, which is a 45 MHz demod.

First, it is very hard to drive a large enough signal to even see the line in AS RF72 compared to other sensors. We are currently operating with 1 stage of whitening on RF72, for reference. The attachment shows how the signals appeared in the AS WFS as well as the POP WFS for pitch and yaw.

Once I took this measurement, I looked at the time series of the signals. POPX 45 Q pitch has an offset that corresponds to 1.5 urad of SRM pitch offset. I calculated this calibration factor from my injection: 7.37e-5 SRM pitch urad/POPX pit ct. The POPX Q yaw signal also had an offset, but it was much smaller, only 0.24 urad, calibration factor 3.25e-4  SRM yaw urad/ POPX yaw ct

On June 5, the SQZ team adjusted the SRCL digital offset, and when the SRCL digital offset was zero, the POPX Q offsets corresponded to about 0.09 urad of SRM pitch offset and 0.05 urad of SRM yaw offset (sqz alog).

In the past, we have operated with some SRC1 offset, however, that offset is remarkably small compared to even the dark offsets we have applied to the AS RF72 channels. SRC1 p offset was set to -0.042, SRC1 Y to 0.098, while the four segment dark offsets on RF72 Q are -17.8, 0.2, 2.2, 12.9 (medm screenshot).

Overall, I think we should consider a few things:

Sheila has suggested we open the SRC1 loop and try stepping the offset while monitoring the buildups, the effect of the SRCL offset on SQZ, and the overall offsets in AS RF72 and POPX Q.

Whatever effect alignment offsets in the SRC are having on the SRCL detuning seems to be much smaller in yaw than in pitch.

To calibrate the AS RF72 signals into SRM angle, we can use these factors:

0.274 SRM pit urad/ AS RF72 pit ct

0.173 SRM yaw urad/ AS RF72 yaw ct

Images attached to this report
Comments related to this report
elenna.capote@LIGO.ORG - 15:46, Thursday 26 June 2025 (85366)

Today, Sheila and I followed up on this, and the results are a bit confusing, but somewhat promising.

To start, Sheila reran the "brontosaurus plot" measurement, where FIS is injected to help determine the SRCL offset. She reports this work here.

While she changed the SRCL offset, I once again monitored the AS RF72 and POP X signals. As Sheila changed the SRCL offset, the offset in POPX did change the same way as I saw yesterday, which is not that surprising.

Then, when Sheila set the SRCL offset to zero, I tried opening the SRC1 loop and moving SRM around. The first thing I noticed is that the calibration I calculated yesterday seems bad, since I was adjusting the SRM yaw by 11 urad (according to the slider calibration), but the change in the POP X yaw offset corresponded to less than 1 urad (according to my measured calibration from yesterday).

I moved yaw in only one direction, with the goal of seeing if I could reduce the POP X yaw offset. However, I gave up after 11 urad because it didn't seem to be doing much at all except to small effect on POP X yaw.

Next, I tried moving SRM in pitch. I went the positive direction, and Sheila and I immediately saw the buildups get worse, so then I went the other way and the buildups got better! This corresponded to a 20 urad change in SRM pitch, according to the alignment slider. The change in the POP X pitch offset was minimal.

We also saw kappa C increase quite a bit, almost too good to be true, so we didn't trust the value since we had a large SRCL detuning at the time. Sheila did see that the change in the SRM pitch had an effect on the squeezing as well.

However, Sheila then determined a better SRCL offset of -382, so we went there, and the kappa C leveled off to 1.02, which was better than our current nominal value of 1. This seemed to hold. Then, I stepped the SRM pitch offset back to the starting alignment and the buildups decreased and kappa C went back to 1.

Following the buildups, there seems to be a better alignment of the SRM in pitch. At this time it seems like yaw has no effect, but I only moved in one direction. I think that, whatever the SRCL offset is, we should move the SRM around in pitch and yaw and see if there is an improvement to be found in the buildups. My current hypothesis is that the RF72 dark offsets are creating some alignment offset in the SRC. After we find a good SRM alignment position, we can recheck the SRCL offset, hopefully with both a squeezing measurement and a sensing function.

We should also probably check the whitening on RF72, maybe next Tuesday.

These results are making me think that probably POP X Q would not make a good signal for SRC alignment, since it is dominated by the SRCL offset.

The first ndscope attached are showing the behavior of the POP X and RF72 signals while changing SRM alignment. The second shows the buildups and kappa C when changing SRM pitch and SRCL offset from 0 to -382.

Images attached to this comment
H1 SQZ
camilla.compton@LIGO.ORG - posted 12:19, Wednesday 25 June 2025 - last comment - 14:27, Wednesday 25 June 2025(85329)
SQZ HD Dataset

Yesterday 85295 we took HD data just at the nominal 95uW OPO trans setpoint, today we changed the NLG and retook data, saved at /camilla.compton/Documents/sqz/templates/dtt/20250625_HD.xml

Strangely, when I started checking the NLG with 95uW, once the seed was injected, this dropped to 65uW, I then increased injected seed power form 0.5mW to 0.6mW, I also  increased the pump power as we were close to the edge of the AOM range.

Used SQZ_MANAGER SQZ_READY_HD (needed to change LO gain, see sdf).

Type NLG Angle SQZ (@500Hz) DTT Ref
LO shot noise N/A N/A Used as 0dB ref 1
ASQZ 10 (+) 206 14.3dB ref 2
SQZ 10 (-) 112 6.9dB ref 3
Mean SQZ 10 N/A 11.3dB ref 4
ASQZ 18 (+) 210 17.2dB ref 5
SQZ 18 (-) 112 7.3dB ref 6
Mean SQZ 18 N/A 14.1dB ref 7
ASQZ 21 (+) 210 17.5dB ref 8
SQZ 21 (-) 110 7.4dB ref 9
Mean SQZ 21 N/A 14.7dB ref 10
ASQZ 14 (+) 206 15.6dB ref 11
SQZ 14 (-) 113 7.4dB ref 12
Mean SQZ 14 N/A 12.7dB ref 13
 
OPO Setpoint Amplified Max Amplified Min UnAmp Dark NLG OPO Gain
95uW 0.0730506 0.002413 0.006841 8.4e-5 10.81 -8
115uW 0.122166 0.002215     18.08 -8
120uW 0.141799 0.0021763     20.99 -8
105uW 0.0942627 0.0023351     13.95 -8
Comments related to this report
camilla.compton@LIGO.ORG - 12:28, Wednesday 25 June 2025 (85331)

Plot attached, we think that the SQZ is worse at NLG 10 that the other NLGs and we are considering running with NLG = 14.

Images attached to this comment
sheila.dwyer@LIGO.ORG - 12:52, Wednesday 25 June 2025 (85332)

Here's a fit of Camilla's data, it shows that our OPO threshold has increased compared to 83070, and we still have the same efficiency for squeezing, which implies 6% unexplained loss, which hasn't been fixed by moving the crystal. 

This plot was made using this script

Images attached to this comment
camilla.compton@LIGO.ORG - 14:27, Wednesday 25 June 2025 (85337)OpsInfo

We decided that an OPO TRANS setpoint of 105uW for an NLG of 14 gave us slightly better squeezing, see attached BLRMS. Leaving this in.

If the Operators have any issues keeping the OPO locked at this higher output power, they could lower it slightly following the instructions in 70050 to drop it down to 100uW or 95uW.

Images attached to this comment
H1 ISC
sheila.dwyer@LIGO.ORG - posted 11:38, Wednesday 25 June 2025 (85328)
OMC QPD offsets updated

Matt Todd, Sheila Dwyer

We moved the OMC alignment a bit in pitch while watching for a response in kappa C. The attached screenshots show the updated pitch offsets that have been accepted in safe and observe.   The next screenshot shows us stepping this around. 

Overall, we improved the optical gain by something like 0.5 %.  We would like to return to the yaw offsets to see if we can recover the 1% optical gain that we lost during the vent.

Images attached to this report
H1 General (Lockloss)
oli.patane@LIGO.ORG - posted 10:54, Wednesday 25 June 2025 - last comment - 13:47, Wednesday 25 June 2025(85327)
Lockloss

Lockloss during commissioning at 2025-06-25 17:52UTC after over 5.5 hours Locked. Cause not known, but probably not commissioning related.

Comments related to this report
oli.patane@LIGO.ORG - 12:56, Wednesday 25 June 2025 (85334)

18:48 Back to NOMINAL_LOW_NOISE

camilla.compton@LIGO.ORG - 13:47, Wednesday 25 June 2025 (85335)TCS

Within the same ~15 seconds of the lockloss, we turned the CO2 powers down form 1.7W each to 0.9W each. In the hope of doing the thermalization tests we tried last week 85238.

We checked the lockloss today and LSC channels at the time last week we turned the CO2s down and see no glitches corresponding with the CO2 waveplate (out of vac) change, we think the lockloss was unrelated.

H1 GRD (ISC)
elenna.capote@LIGO.ORG - posted 17:38, Tuesday 24 June 2025 - last comment - 17:16, Wednesday 25 June 2025(85309)
Guardian edits to speed up ADS

Ryan S., Elenna

Ryan and I are still trying to speed up the MOVE_SPOTS state. Today, Ryan implemented new code that checks the convergence of the loops and only ramps up the ADS gains of loops that are not yet converged to help them converge faster. This appeared to work well, although the state is still slow. We are now taking the spots to the FINAL spots that the camera servos go to, instead of some old spot, so it's possible that which loops that are far off have changed.

Ryan also pointed out that the ENGAGE_ASC_FOR_FULL_IFO state is taking a while because it is limited by the convergence of the PIT3 ADS. This is likely because the POP A offset used in DRMI ASC is not quite right, so I adjusted it for pitch so the PRM should be closer to the full lock position. SDFed.

Images attached to this report
Comments related to this report
oli.patane@LIGO.ORG - 12:55, Wednesday 25 June 2025 (85333)

With regards to ENGAGE_ASC_FOR_FULL_IFO, the three locks that we've had after the adjustment made yesterday have made the state take an average of 4.5 minutes to get through. Before making this change, it was taking us an average of 8.5 minutes (looking at the four locks before this change), so this has made a big improvement for this state!

However, it looks like the main reason why this state still takes a pretty long time compared to most other states is because it's still needing to wait a long time for the PIT3 and YAW3 ADS to converge (ndscope). Here's the log from this last time that we went through ENGAGE_ASC and you can see that most of the time is waiting for ADS. The actual wait timers in there are only 50 seconds of waiting, so the rest of the wait timers (the one second timers) are just from the convergence checker.

Images attached to this comment
Non-image files attached to this comment
elenna.capote@LIGO.ORG - 17:16, Wednesday 25 June 2025 (85350)

I updated the POP A yaw offset so that PRC1 in DRMI will bring the PRM closer to the full lock point and hopefully make convergence in this state faster.

Images attached to this comment
H1 TCS (DetChar-Request)
camilla.compton@LIGO.ORG - posted 13:20, Monday 23 June 2025 - last comment - 11:58, Thursday 26 June 2025(85247)
2Hz Comb in DARM from ITMX HWS Camera?

Ansel, Sheila, Camilla

Last week, Ansel noticed that there is a 2Hz comb in DARM since the break, similar to that that we've seen from the HWS camera sync frequency and power supplies and fixed in 75876.  The cabling has not been changed since, the camera sync frequency has been changed.

Our current camera sync frequencies are: ITMX = 2Hz, ITMY = 10Hz. We have typically seen these combs in H1:PEM-CS_MAG_LVEA_OUTPUTOPTICS_Y_DQ. With a 0.0005Hz BW on DTT I can't easily see these combs, see attached.

Images attached to this report
Comments related to this report
evan.goetz@LIGO.ORG - 13:31, Monday 23 June 2025 (85254)DetChar
It may be difficult to see in a standard spectrum, but can be clearly seen in Fscan plots linked off of the summary pages. For the "observing" Fscan, the interactive spectrum plot shows the 2 Hz comb marked automatically. See the attached image of H1:GDS-CALIB_STRAIN_CLEAN
Images attached to this comment
camilla.compton@LIGO.ORG - 17:04, Tuesday 24 June 2025 (85306)

Verifed that the cabling has not changed since 75876.

Next steps we should follow, as listed in 75876 would be to try using a different power supply or lowering the voltage to +12V. Or, there is a note suggesting Fil could make a new cable to power both the camera and CLink's via the external supply (14V is fine for both). 

evan.goetz@LIGO.ORG - 18:30, Tuesday 24 June 2025 (85312)DetChar
Thanks Camilla. If anything can be done more rapidly than waiting another week, it would be very much appreciated. Continuing to collect contaminated data is bad for CW searches.
camilla.compton@LIGO.ORG - 15:11, Wednesday 25 June 2025 (85341)

Matt and I turned down the Voltage supplied from 14V to 12V for each camera at ~22:00UTC when the IFO was relocking. Verified HWS cameras and code still running.

We also will plan to have Dave reimpliemnt the hws_camera_control.py script he wrote in 74951 to turn the HWS's off in Observing until we fix this issue.

kiet.pham@LIGO.ORG - 11:58, Thursday 26 June 2025 (85361)

The 2 Hz comb is still present in H1:GDS-CALIB_STRAIN_CLEAN after the voltage change (before the software update)

Images attached to this comment
H1 ISC
elenna.capote@LIGO.ORG - posted 13:18, Monday 23 June 2025 - last comment - 16:29, Thursday 26 June 2025(85250)
Noise Budget injection inventory

I have been running opportunistic noise budget injections:

So far there seems to be no noise contribution from DC6 P and PRC2 P and Y. CHARD noise contributions are also down significantly with the ISI in place.

 

Comments related to this report
elenna.capote@LIGO.ORG - 16:48, Wednesday 25 June 2025 (85347)

I ran SRCL and MICH injections today as a part of determining if the feedforward is performing well, but I repurposed those injection times in the noise budget templates so now SRCL and MICH are complete as well.

elenna.capote@LIGO.ORG - 16:29, Thursday 26 June 2025 (85372)

After running some PRCL injections to test the feedforward I was also able to update the PRCL noise budget template.

I also reran the jitter noise coupling measurement, since it seemed like the coupling was overestimated at low frequency. The jitter noise had been run very early on in vent recovery, so I am not sure what changed to affect the low frequency coupling (could be the pumps, LSC feedforward, ASC, etc) but now the low frequency coupling is very reduced.

H1 ISC
camilla.compton@LIGO.ORG - posted 10:34, Tuesday 10 June 2025 - last comment - 16:59, Wednesday 25 June 2025(84922)
Noticed BS PIT Moved while locking and then drifts in NLN: not new, happened end of O3b but not 1 year ago.

Sheila, Elenna, Camilla

Sheila was questioning if something is drifting for us to need an initial alignment after the majority of relocks. Elenna and I noticed that BS PIT moves a lot both while powering up /moving spots and while in NLN. Unsure from the BS alignment inputs plot what's causing this.

This was also happening before the break (see below) but the operators were similarly needing more regular initial alignments before the break too.  1 year ago this was not happening, plot.

Images attached to this report
Comments related to this report
camilla.compton@LIGO.ORG - 12:44, Tuesday 10 June 2025 (84929)

These large BS PIT changes began 5th to 6th July 2024 (plot). This is the day shift from the time that the first lock like this happened 5th July 2024 19:26UTC (12:26PT): 78877 at the time we were doing PR2 spot moves. There also was a SUS computer restart 78892 but that appeared to be a day after this started happening.

Images attached to this comment
camilla.compton@LIGO.ORG - 09:45, Wednesday 11 June 2025 (84966)ISC, SUS

Sheila, Camilla

This reminded Sheila of when we were heating a SUS in the past and causing the bottom mass to pitch and the ASC to move the top mass to counteract this. Then after lockloss, the bottom mass would slowly go back to it's nominal position.

We do see this on the BS since the PR2 move, see attached (top 2 left plots). See in the green bottom mass oplev trace, when the ASC is turned off on lockloss, the BS moves quickly and then slowly moves again over the next ~30 minutes, do not see simular things on PR3. Attached is the same plot before the PR2 move. And below is a list of other PR2 positions we tried, all the other positions have also made this BS drift. The total PR2 move since the good place is ~3500urad in Yaw.

  • Different time May 21st to 24th 2024:
    • BS Oplev Drift
    • Plot shows 30urad M1 drift
    • PR2 Alignment Sliders P: 1435, Y: 1130
  • Pre July 5th 2024:
    • No BS Oplev Drift
    • Plot shows 5urad M1 drift
    • PR2 Alignment Sliders P: 1565, Y: 3210
  • July 5th 2024 to 6th Feb 2025:
    • BS Oplev Drift
    • Plot shows 50urad M1 drift
    • PR2 Alignment Sliders P: 1535, Y: 2785
  • 6th Feb 2025 to 10th Feb 2025:
    • BS Oplev Drift
    • Plot shows 30urad M1 drift
    • PR2 Alignment Sliders P: 1480, Y: 1195
  • 10th Feb 2025 to now:
    • BS Oplev Drift
    • Plot shows 30-40urad M1 drift
    • PR2 Alignment Sliders P: 1430, Y: -245

To avoid this heating and BS drift, we should move back towards a PR2 YAW of closer to 3200. But, we moved PR2 to avoid the spot clipping on the scrapper baffle, e.g.  77631, 80319, 82722, 82641.

Images attached to this comment
jenne.driggers@LIGO.ORG - 14:38, Thursday 12 June 2025 (85002)

I did a bit of alog archaeology to re-remember what we'd done in the past.

  • In August of 2015, we found that we were struggling with PR3 pitch alignment jumping, then cooling down upon lockloss.  Alog 20268 talks about the implementation of the lock loss compensation, which first appeared in ISC_DRMI guardian in rev 11228.
  • At some point (I didn't dig to find out when precisely), we also implemented the same filters for BS pitch.
  • By Jan 2020, both BS and PRM had the soft ASC turn-off.
  • In Jan 2020, ISC_DRMI rev 20905 we removed this soft ASC turn-off for both PR3 and BS.  The referenced alog 54709 notes that we shouldn't need those anymore, since we had installed wire heating baffles, to prevent the wires from being illuminated and heating up.
  • We haven't had the soft turn-off filters in use since 2020, about 3 months before the end of O3b.  This may be why Camilla saw that we were seeing BS drift at the end of O3b.
  • Perhaps our alignment during O4, until we moved the PR spots in May 2024, was such that we weren't susceptible to this wire heating.
  • I don't think PR3 is seeing the same kind of trouble that it did back in 2015 upon lockloss, so I think its wire heating baffles are working as designed, so no need to make any changes to the PR3 controls.
  • Sheila made the point that because we unclipped some of the +Y side of the beam (without moving the spot on the BS), maybe there is a bit more light that is illuminating the barrel of the BS or getting to the wires.  Or, something?  Without having looked at the actual drawings, I could imagine that the wire heating baffles are working better on PR3 than they are on the BS, because we hit PR3 much closer to normal incidence, whereas with the BS the light could be sneaking around the baffles.  Robert thinks that light could get inside the cage baffle and reflect around and be hitting and heating the wires.
  • All of this seems to say that we should re-implement the soft ASC turn-off for the BS. I had a quick look at the 1/e time for the BS to move after lockloss (it's about 241 seconds), and the 1/e time for the filters (about 240 seconds, despite my quoting in alog 54706 that they were 25 min filters (2*pis are hard!)

To put back the soft turn-off of the BS ASC, I think we need to:

  • Disable the BS M1 ASC lockloss trigger.  Jeff reminded me that this would foil my plans, since it turns off the ASC signals to the EUL2OSEM matrix.  This will mean that neither the Pit nor the Yaw BS M1 signals will be shut off by the lockloss trigger.  To disable, we'll need to set H1:SUS-BS_M1_TRIG_ASC_ENABLE to zero (which means that the ASC signals will always be passed to the EUL2OSEM matrix).  I don't think this is in guardian anywhere, so we should only need to change it and then accept in safe and observe snap files.
  • Change ISC_DRMI around line 66 such that BS pit gain is not set to zero.  Also, have it turn off FM1 in addition to turning off the input.
  • Change ISC_DRMI around line 141 to not hit the BS pit RSET button.

Camilla made the good point that we probably don't want to implement this and then have the first trial of it be overnight.  Maybe I'll put it in sometime Monday (when we again have commissioning time), and if we lose lock we can check that it did all the right things.

jenne.driggers@LIGO.ORG - 09:57, Monday 16 June 2025 (85075)

I've now implemented this soft let-go of BS pit in the ISC_DRMI guardian, and loaded.  We'll be able to watch it throughout the day today, including while we're commissioning, so hopefully we'll be able to see it work properly at least once (eg, from a DRMI lockloss).

jenne.driggers@LIGO.ORG - 17:16, Monday 16 June 2025 (85106)

This 'slow let-go' mode for BS pitch certainly makes the behavior of the BS pit oplev qualitatively different. 

In the attached plots, the sharp spike up and decay down behavior around -8 hours is how it had been looking for a long time (as Camilla notes in previous logs in this thread).  Around -2 hours we lost lock from NomLowNoise, and while we do get a glitch upon lockloss, the BS doesn't seem to move quite as much, and is mostly flattened out after a shorter amount of time.  I also note that this time (-2 hours ago) we didn't need to do an initial alignment (which was done at the -8 hours ago time).  However, as Jeff pointed out, we held at DOWN for a while to reconcile SDFs, it's not quite a fair comparison. 

We'll see how things go, but there's at least a chance that this will help reduce the need for initial alignments.  If needed, we can try to tweak the time constant of the 'soft let-go' to further make the optical lever signal stay more overall flat.

The SUSBS SDF safe.snap file is saved with FM1 off, so that it won't get turned back on in SDF revert.  The PREP_PRMI_ASC and PREP_DRMI_ASC states both re-enable FM1 - I may need to go through and ensure it's on for MICH initial alignment.

Images attached to this comment
jenne.driggers@LIGO.ORG - 16:59, Wednesday 25 June 2025 (85344)

RyanS, Jenne

We've looked at a couple of times that the BS has been let go of slowly, and it seems like the cooldown time is usually about 17 minutes until it's basically done and at where it wants to be for the next acquisition of DRMI.  Attached is one such example.

Alternatively, a day or so ago Tony had to do an initial alignment.  On that day, it seemed like the BS took much longer to get to its quiescent spot.  I'm not yet sure why the behavior is different sometimes.

Tony is working on taking a look at our average reacquisition time, which will help tell us whether we should make another change to further improve the time it takes to get the BS to where it wants to be for acquisition.

Images attached to this comment
Displaying reports 141-160 of 83039.Go to page Start 4 5 6 7 8 9 10 11 12 End