Displaying reports 9281-9300 of 88198.Go to page Start 461 462 463 464 465 466 467 468 469 End
Reports until 21:59, Wednesday 13 November 2024
LHO General (TCS)
corey.gray@LIGO.ORG - posted 21:59, Wednesday 13 November 2024 (81270)
Wed EVE Ops Summary

TITLE: 11/14 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 161Mpc
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY:

Had a nice 5hr lock for H1.  Running an IMC-only lock overnight to see if there are any FSS/IMC glitches.
LOG:

H1 ISC (OpsInfo, PSL)
corey.gray@LIGO.ORG - posted 21:55, Wednesday 13 November 2024 - last comment - 22:02, Wednesday 13 November 2024(81273)
H1 Lockloss at 2100utc (9pm PT) After 5hr Lock.....Now What....Leaning To IMC-only Overnight.....

The plan for tonight's shift was to see how locking would go for H1.  Well....TJ handed over a locked H1, and then it stayed locked for 5hrs of the 6hr Eve shift!  

Vicky mentioned that the Lockloss at 0459utc looked like possible FSS glitch, but it looked "different".  She is going to post her plot about that.

Comments related to this report
victoriaa.xu@LIGO.ORG - 22:02, Wednesday 13 November 2024 (81274)

This lockloss (1415595557, 2024-11-13 20:58:59 PT) looks related to IMC (/FSS /ISS / PSL)... 10-15 seconds before LL, FSS starts to see some glitches, then more glitches starting ~5 sec before LL. ~30 second trends here.

Then zooming in ~100ms before LL (plot), maybe a small glitch is seen on ISS second loop PDs, and then the IMC loses lock. At the same time that the IMC loses lock, then lockloss pulse and AS port and LSC_REFL see the lock loss. So it seems like an IMC lockloss with some FSS glitching beforehand.

Images attached to this comment
H1 TCS
corey.gray@LIGO.ORG - posted 17:47, Wednesday 13 November 2024 - last comment - 10:52, Monday 18 November 2024(81271)
TCSy Laser Unlocks & Relocks, Dropping H1 From Observing Briefly

H1 was dropped out of OBSERVING due to the TCS ITMy CO2 laser unlocking at 0118utc.  The TCS_ITMY_CO2 guardian relocked the 2min.

It was hard to see the reason why at first (there were no SDF Diffs, but eventually saw a User Message via GRD IFO (on Ops Overview) pointing to something wrong with TCS_ITMY_CO2.  Oli was also here and they mentioned seeing this, along with Camilla, on Oct9th (alog)---this was the known issue of the TCSy laser nearing the end of its life.  It was replaced a few weeks later on  Oct22nd (alog).

Here are some of the lines from the LOG:

2024-11-13_19:43:31.583249Z TCS_ITMY_CO2 executing state: LASER_UP (10)
2024-11-14_01:18:56.880404Z TCS_ITMY_CO2 [LASER_UP.run] laser unlocked. jumping to find new locking point

.

.
2024-11-14_01:20:12.130794Z TCS_ITMY_CO2 [RESET_PZT_VOLTAGE.run] ezca: H1:TCS-ITMY_CO2_PZT_SET_POINT_OFFSET => 35.109375
2024-11-14_01:20:12.196990Z TCS_ITMY_CO2 [RESET_PZT_VOLTAGE.run] ezca: H1:TCS-ITMY_CO2_PZT_SET_POINT_OFFSET => 35.0
2024-11-14_01:20:12.297890Z TCS_ITMY_CO2 [RESET_PZT_VOLTAGE.run] timer['wait'] done
2024-11-14_01:20:12.379861Z TCS_ITMY_CO2 EDGE: RESET_PZT_VOLTAGE->ENGAGE_CHILLER_SERVO
2024-11-14_01:20:12.379861Z TCS_ITMY_CO2 calculating path: ENGAGE_CHILLER_SERVO->LASER_UP
2024-11-14_01:20:12.379861Z TCS_ITMY_CO2 new target: LASER_UP

Comments related to this report
camilla.compton@LIGO.ORG - 10:52, Monday 18 November 2024 (81334)

CO2Y has only unlocked/relocked once since we power cycled the chassis on Thursday 14th (t-cursor in attached plot).

Images attached to this comment
corey.gray@LIGO.ORG - 17:48, Wednesday 13 November 2024 (81272)TCS

0142:  ~30min later had another OBSERVING-drop due to CO2y laser unlock.

thomas.shaffer@LIGO.ORG - 09:21, Thursday 14 November 2024 (81276)

While it is normal for the CO2 lasers to unlock from time to time, whether it's from running out of range of their PZT or just generically losing lock, this is happening more frequently than normal. The PZT doesn't seem to be running out of range, but it does seem to be running away for some reason. Looking back, it's unlocking itself ~2 times a day, but we haven't noticed since we haven't had a locked IFO for long enough lately.

We aren't really sure why this would be the case, chiller and laser signals all look as they usually do. Just to try the classic "turn it off and on again", Camilla went out to the LVEA and power cycled the control chassis. We'll keep an eye on it today and if it happens again, and we have the time to look further into it, we'll see what else we can do.

Images attached to this comment
LHO General
corey.gray@LIGO.ORG - posted 16:43, Wednesday 13 November 2024 (81269)
Wed EVE Ops Transition

TITLE: 11/14 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 161Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: USEISM
    Wind: 13mph Gusts, 10mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.50 μm/s
QUICK SUMMARY:

TJ was taking H1 to OBSERVING as I arrived!  Plan for tonight is to keep H1 NLN as much as possible---if H1 goes down and locking is tough toward the end of the shift, will redirect and focus on only the IMC and keeping it locked overnight to log time to monitor for any glitches.  If this happens, will set ISC_LOCK to IDLE and take IMC_LOCK to from MANAGED to AUTO.

Environmentally it is less breezy than 24hrs ago.  µseism is about the same as 24hrs ago (it rose a little but came back down).  

LHO General
thomas.shaffer@LIGO.ORG - posted 16:26, Wednesday 13 November 2024 (81242)
Ops Day Shift End

TITLE: 11/14 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 148Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY: We took 4 or so hours out today to troubleshoot the laser glitches that we've been having. After that we were able to relock quickly and test out some longer ramp times for te ETMX transition state.
LOG:

Start Time System Name Location Lazer_Haz Task Time End
21:41 SAF Laser LVEA YES LVEA is laser HAZARD 08:21
16:36 FAC Karen Opt lab n Tech clean 17:01
17:01 FAC Karen Wood shop/Fire pump rm N Tech clean 17:32
19:32 PSL/CDS Jason, Marc LVEA yes FSS transfer function 20:06
20:25 SEI Jim, Neil LVEA yes Bier garten huddle test meas. 21:21
20:43 VAC Janos MidX N Mech room checks and measurements 21:23
21:48 ISC/CDS Sheila, Marc LVEA yes IMC OLG TF meas. 22:13
22:07 SEI Neil CER yes Checking on cabling 22:44
22:44 SEI Jim, Neil LVEA yes Removing bier garten measurement 23:03
22:48 VAC Janos MX n Mech room checks and meas 23:04
H1 General
thomas.shaffer@LIGO.ORG - posted 16:09, Wednesday 13 November 2024 (81267)
Observing 0002 UTC

We paused locking for just over 4 hours today to try and troubleshoot the glitching that we've been having. After that was wrapped up we relocked without an initial alignment, but I did help DRMI lock by touching SRM and a little BS. Once at low noise there were 3 SDF diffs related to the new TRAMPS for the transition from ETMX state.

Images attached to this report
H1 OpsInfo
thomas.shaffer@LIGO.ORG - posted 15:49, Wednesday 13 November 2024 - last comment - 15:49, Tuesday 26 November 2024(81263)
Bumped up timers in H1_MANAGER and IFO_NOTIFY

Until we figure out these laser glitches, I've increased all of the timers in H1_MANGER and IFO_NOTIFY by 50%. This will hopefully help avoid the late night notifications that resulted in no actual interventions.

I added a laser_fudge = 1.5 to both nodes, and then multipled the defined timers in H1_MANAGER lines 149-152  and IFO_NOTIFY lines 30-35.

Comments related to this report
ryan.short@LIGO.ORG - 15:49, Tuesday 26 November 2024 (81502)OpsInfo

I've undone this timer increase in both H1_MANAGER and IFO_NOTIFY by changing laser_fudge from 1.5 to 1.0 since the IMC seems to have been behaving itself since the NPRO swap last week. Both nodes have been loaded.

H1 ISC
sheila.dwyer@LIGO.ORG - posted 15:44, Wednesday 13 November 2024 - last comment - 16:07, Wednesday 13 November 2024(81262)
fast lockloss investigations today, plan for tonight

Today TJ had the IMC locked without the IFO (with the ISS first loop) from 18:45- 22:45, without the IMC losing lock.  This might suggest that the change of the FSS EOM path op amp yesterday 81247 did indeed solve the issue that was making the IMC unstable even without the interferometer locking, but more time would make this a more definitive test. 

During the 4 hours Jason and Marc also went to the floor and measured the FSS OLG, 81254, which showed some places where there are mulitple places where it came close to unity gain.  They lowered the gain by 0.75 dB.  Later, Marc and I went and measured the IMC OLG, and we tried lowering the gain by 3dB (common gain of 12dB), to give the FSS OLG more clearance from unity gain, we measured the IMC OLG before and after this change 81259

We decided to try locking tonight with the FSS gain at 12dB.  If the interferometer is not stable through the evening shift, Corey will set the IFO to down and leave the IMC locked overnight so that we can get more time for the test of IMC stability on it's own. 

 

Comments related to this report
thomas.shaffer@LIGO.ORG - 16:07, Wednesday 13 November 2024 (81266)

Here's a screenshot of the FSS diff in the safe.snap. There was no diff in the Observe so we must not monitor it. Perhaps something we should change?

Images attached to this comment
H1 ISC
camilla.compton@LIGO.ORG - posted 15:38, Wednesday 13 November 2024 - last comment - 13:35, Monday 18 November 2024(81250)
IMC TRANS power changes up to 1% once we get to NLN and are thermalizing

While looking at locklosses today, Vicky and I noticed that after we reach NLN, the MC2/IM4 TRANS power increases 0.1 to 0.5%.  

Daniel helped look at this and we expect the ISS to change to keep the power out of the IMC constant, but the power after the IMC on IM4 TRANS (not centered) changes ~1% too. Everything downstream of the ISS AOM sees this change plot, something is seeing a slow ~1hour thermalization.

The same signals at LLO are show a similar amount of noise (slightly more in the MC2_TRANS) but no thermalization drift, but LLO has a lot less IFO thermalization.

Images attached to this report
Comments related to this report
camilla.compton@LIGO.ORG - 13:35, Monday 18 November 2024 (81337)

Elenna and Craig noted this in 68370 too. 

LHO General
tyler.guidry@LIGO.ORG - posted 15:37, Wednesday 13 November 2024 (81261)
DGR Storage Building Progress
A majority of the forms for the stem wall have been built, and the concrete has been poured. Those forms are now stripped and a good portion of the stem wall is back-filled. The final stem wall form was being built today and will be poured likely this week. Back-fill will follow and the finish floor pour will be shortly behind - likely to begin next week.
Images attached to this report
H1 AOS
neil.doerksen@LIGO.ORG - posted 15:37, Wednesday 13 November 2024 - last comment - 08:12, Friday 22 November 2024(81257)
NN Seismic Array HS-1 Install

2024 Nov 12

Neil, Fil, and Jim installed an HS-1 geophone in the biergarten (image attached). HS-1 is threaded to plate and plate is double-sided taped to the floor. Signal given was non-existent. Must install pre-amplifier to boost signal.

2024 Nov 13

Neil and Jim installed an amplifier (SR560) to boost HS-1 signal (images attached). Circuitry checked to ensure signal makes it to the racks. However, when left alone there is no signal coming through (image attached, see blue line labelled ADC_5_29). We suspect the HS-1 is dead. HS-1 and amplifier are now out of LVEA, HS-1's baseplate is still installed. We can check one or two more things, or wait for more HS-1s to compare.

Images attached to this report
Comments related to this report
jim.warner@LIGO.ORG - 16:45, Tuesday 19 November 2024 (81367)SEI

Fil and I tried again today, we couldn't get this sensor to work. We started from the PEM rack in the CER, plugging the HS1 through the SR560 into the L4C interface chassis, confirming the HS1 would see something when we tapped it. We then moved out to the PEM bulkhead by HAM4, again confirmed the HS1/SR560 combo still showed signal when tapping the HS1. Then we moved to the biergaren and plugged in the HS1/SR560 right next to the other seismometers. While watching the readout in the DAQ of the HS1 and one of the Guralps I have connected to the PEM AA, we could see that both sensors could see when I slapped the ground near the seismometers, but the signal was barely above what looks like electronics noise on the HS1, while the Guralp showed lots of signal that looked like ground motion. We tried gains from 50-200 on the SR560, none of them really seemed to improve the snr of the HS1. The HS1 is still plugged in over night, but I don't think this particular sensor is going to measure much ground motion.

brian.lantz@LIGO.ORG - 08:12, Friday 22 November 2024 (81413)

One check for broken sensors - A useful check is to be sure you can feel the mass moving when the HS-1 is in the correct orientation. A gentle shake in the vertical, inverted, and horizontal orientations will quickly reveal which orientation is correct.

H1 ISC
elenna.capote@LIGO.ORG - posted 15:11, Wednesday 13 November 2024 - last comment - 16:11, Wednesday 13 November 2024(81260)
ETMX transition still a problem

Unfortunately, changing the ramp time in the IX L3 to EX L3 transition to 2 seconds (from 10 seconds), seems to overall have made things worse. The first lock attempt through this state was successful, but there were four locklosses last night in state 558, each with 1 second state duration and none tagged as IMC.

Sheila and I changed the ramp time to 20 seconds, to test if ramping slower is better. Besides that, it seems like we should measure the loops before and after the transition on the way up to check the stability of the DARM loop.

Comments related to this report
elenna.capote@LIGO.ORG - 15:59, Wednesday 13 November 2024 (81264)

The 20 second ramp appears to have worked. Still an oscillation, but with a much lower amplitude.

Images attached to this comment
elenna.capote@LIGO.ORG - 16:11, Wednesday 13 November 2024 (81268)

We tried to make an OLG measurement before and after the transition, but the template we used before the transition caused a big wiggle in the buildups so we didn't actually get any data. We ran the template after the transition and noticed the gain was low by about 15%.

Attached screenshot shows two OLG measurements because I forgot to add the most recent measurement as a reference. Upper left red measurement was taken Jun 20, 2024. Lower right red measurement was today.

Images attached to this comment
X1 SUS (SUS)
rahul.kumar@LIGO.ORG - posted 13:56, Wednesday 13 November 2024 (81258)
A+ O5 assembly report - Fully assembled HRTS (suspended) mounted on BBSS to perform fit check

Last week I mounted the fully assembled HRTS (suspended configuration) on the BBSS to perform a check-fit and adjustment mechanism test. I am attaching few pictures for reference. The BBSS still needs sheer plates and Y-brackets to be installed, following which we will perform B&K measurements and look for any unwanted peaks below 100Hz region. Once the BBSS is fully assembled and tested, we will perform the final fit check with HRTS.

Images attached to this report
H1 PSL
jason.oberling@LIGO.ORG - posted 11:04, Wednesday 13 November 2024 - last comment - 14:36, Wednesday 13 November 2024(81247)
PSL Maintenace Day Work (WP12187)

J. Oberling, R. Short, M. Pirello, F. Clara

Several PSL items during yesterday's maintenance day:

Summary

Details

To start we took PMC, ISS, and FSS transfer functions.  The PMC and ISS (1st and 2nd attachments, respsectively) look as we had set them at the end of the NPRO swap.  The FSS looked as left after lowering the Common gain to 13dB on Nov 1st, with the marker on the 1.68MHz peak (3rd attachment); we raised the Common gain to 15dB and saw the peak raise by 2dB, as we expect.  I didn't get a picture of it, but we also lowered the Common gain by 2dB to 11dB and saw the 1.68MHz peak also lower by 2dB, also as we expect.

Next we wired the Amp2 power monitor PD to an EPICS channel with a faster data rate; we used the old High Power Laser (HPL) channel from the HPO days, which was still alive and well (and already had a fitting name).  We ran a cable to the Lemo tee used to wire the PD to the PSL Sensor Interface Chassis, and plugged this cable into the HPL DC port of the PSL Monitoring Fieldbox.  We then recalibrated this channel to match the power reading from PSL Beckhoff, this required a change in the channel gain from 0.0160515 to 0.047732.  The full channel name is H1:PSL-PWR_HPL_DC_OUT_DQ and the data rate is 16kHz.

Next we checked the ISS AOM RF connection after a suggestion from Tony (he said they had seen weird AOM glitches in PCal in the past, and when this happened they found the RF cable had managed to work itself loose by upwards of half a turn).  The ISS was turned OFF, the ISS AOM driver was turned OFF, the PMC unlocked, and the PSL external shutter closed.  Using an SMA torque wrench I attempted to tighten the SMA connection to the ISS AOM; I found it loose by ~3/4 of a turn.  I hadn't considered checking this connection before, but after this we will check all of our SMA connections regularly to make sure they are tight (PSL EOM, ISS AOM, LO and PD inputs on the TTFSS box).  At this time I also noted new component locations on the PSL table as a result of the NPRO swap (FI replacement, new mode matching solution, etc.) so I can update the As-Built PSL table drawing.  We also took the opportunity to re-center the Bullseye PD (uses the leakage beam from M10, the first mirror after the ISS AOM), as we had forgot to do this at the end of the NPRO swap.

We then removed the in-service TTFSS box, SN LHO01, for testing/characterization in the EE shop.  Once Fil turned off the high voltage we removed the TTFSS box and took it to the lab, where Marc started testing the individual signal paths.  Both the Common and PZT paths of the TTFSS looked as expected based on Marc's modeling of the TTFSS circuit, but the higher frequency portion of the EOM path looked completely wrong.  Marc has all of this data that he can post once he has it in a readable format.  The EOM path features 2 op amps in parallel that drive the EOM, an AD829 and a PA85.  Marc checked the AD829 path and all looked good there, so it looked like the PA85 had gone dodgy.  I recall in the past when the PA85 blew the FSS either went completely unstable with wall-to-wall oscillations in the PZT path that could not be cured (as noted the last time a PA85 blew in 2019) or would not lock the RefCav at all; this is completely different behavior than what we have been seeing, so we did not suspect the PA85 until Marc took a TF of the TTFSS EOM path.  We then began a hunt for a spare PA85 and eventually found 3 of them.  We swapped the dodgy PA85 with one of the spares (we now have 2 left) and Marc took the EOM path TF again; now all looked as expected based on the models, so Marc continued characterizing the in-service TTFSS.

While Marc continued characterizing TTFSS SN LHO01, we took the Rev B spare unit, SN LHO03, and installed it to see if it could lock the RefCav.  Recall that the last time this unit was tested the RefCav would lock but had very large PZT oscillations that never went away; Marc subsequently found multiple resistors that were the wrong values (as per the circuit documentation), which would cause gain issues and likely instability in the control loop.  Now that Marc had fixed these issues we wanted to test the unit again.  With Fil helping with the high voltage we installed unit LHO03 and attempted to lock the RefCav.  The cavity immediately locked, and immediately begain large oscillations in the PZT.  However, unlike the last test, after about 2 minutes or so the oscillations quit and the RefCav seemed mostly happy (we had to pause the FSS guardian so it would stop yanking the gains around, and we set them at -10dB and waited).  We did have one moment where the RefCav lost lock for no apparent reason, and once it relocked it had the PZT oscillations again.  This time they did not clear on their own, so we unlocked the and relocked the cavity.  The oscillations started again, but this time they did clear after about 2 minutes with the gains at -10dB.  Now with a seemingly happily locked RefCav, we took a TF to set the UGF and measured the crossover.  The 5th attachment shows the TF with a UGF of ~439kHz; to get this we needed to raise the Common gain from 13dB to 22dB, so this box apparently still has lower gain than SN LHO01.  The 6th attachment shows the crossover measurement for setting the Fast gain, this picture taken with a Fast gain of 10dB.  We let it sit and watched for several minutes and the RefCav stayed locked and the loop didn't go into oscillation again.  So it seems we have a mostly-working spare unit now, with the caveat that the gains still aren't the same and the unit takes some time settle out once the RefCav is locked.  The test mostly successful, we removed unit LHO03 and went back to the EE shop.

At this point Marc had finished characterizing unit LHO01, and indeed he found that the unit had more gain than LHO03.  The PZT path was mostly the same, with a couple dB more gain in unit LHO01 vs LHO03, but the EOM path at lower frequencies was roughly 20dB different (with unit LHO01 having more gain than LHO03).  This fit with our observations from our locking test with unit LHO03.  Since we wanted to test if unit LHO01, with the now-fixed PA85, would be better behaved, we tuned the notches in the unit.  The EOM notch was moved from ~1.77MHz to ~1.68MHz, and we moved the PZT notch from ~36kHz (where we found it) to ~32.7kHz (to hopefully squash the new peak we see at ~32.7kHz).  This done we took unit LHO01 out to the enclosure and reinstalled it, with Fil once again helping out with the high voltage power supply.  The RefCav locked almost immediately and had no PZT oscillations upon locking, so we took a TF to set the UGF and measured the crossover.  The 7th attachment shows the TF with a UGF of ~458kHz and a phase margin of 65.4°.  The peak previously seen at ~1.68MHz is now completely gone, so the EOM notch tuning was successful.  There is still that feature around 750kHz, but that has been there and not problematic since April 2015, when notches targeting it were removed.  The peakiness previously seen around 500kHz seemed less than observed back on Nov 1st, so we left the Common gain at 15dB (we can always lower it by a dB or two should we suspect the gain increase is causing instability, with the knowledge this will lower the UGF significantly (2dB causes the UGF to be around 320kHz)).  Looking at the crossover (final attachment), we decided to leave it at 5dB as the hump around 20kHz looked better here.  It should be noted, however, that we did not see much change in the hump with small, 1dB changes in the Fast gain; we didn't start seeing a clear peak at the crossover until the Fast gain got to around 7dB+.  It should also be noted that the peak at ~32.7kHz is still present.  This indicates either our notch isn't deep enough to remove the peak, or the peak is from something other than a PZT resonance.  At this point I suspect it's something other than a PZT resonance, as we see a 2nd and 3rd harmonic of this peak in the IN1 spectrum (2nd harmonic at ~65.5kHz, 3rd at ~98kHz); I realized after we had left the LVEA that I didn't get a picture of the IN1 spectrum at the full span of the SR785 that shows these harmonics.  This done, we cleaned up and left the enclosure.

Back in the Control Room we relocked the ISS and Tony relocked the IMC.  There was some IMC instability seen, but we chalked it up to ground motion from a recent earthquake.  Marc mentioned that moving the PZT notch lowered the overall gain in the PZT path slightly, so we raised the Fast gain to 6dB, since we had seen a 1dB gain change not have a large effect on the crossover.  Eventually, once the environment had calmed down (Corey was on the Eve shift at this point), the relocking process began.  The IMC lost lock during expected points in the initial alignment process, so we weren't too worried about it.  However, there was one IMC lockloss during the relock (I think during Find IR?), and it took the IMC many minutes to relock.  There were no PSL oscillations or glitches going on while we were waiting for the IMC to relock, so not sure what the issue was; it completely refused to grab lock, and when it would look like it was going to grab it the IMC Trans image swung away quickly.  Elenna did question why MC2 was apparently swinging around so much (the IMC Trans camera image was moving all over the place, hinting at MC2 being pushed hard), so this behavior was not exactly normal.  Eventually the IMC relocked and the locking process continued.  At this point we called it a day, hoping that things would be more stable overnight.  Turns out they were not, so we're still not sure where the problem is.  Investigations will continue.

This closes WP12187.

Images attached to this report
Comments related to this report
marc.pirello@LIGO.ORG - 13:04, Wednesday 13 November 2024 (81254)

Plot of the old common gain position vs new common gain position.  Note the old position UGF at -10dB crosses twice.  Also note these were with IMC locked.  Added Raw Data for Long Scan.

Non-image files attached to this comment
jason.oberling@LIGO.ORG - 12:38, Wednesday 13 November 2024 (81255)

For a little context, Marc and I went out to the LVEA to take a higher resolution TF of the FSS.  The IMC was locked and we decided to leave it locked since this is a normal operating condition.  While out there we decided to take a high resolution scan around the FSS UGF, which is the first plot that Marc posted above (FSSScans11-13-2024.pdf).  At a Common gain of 15 we found a second UGF crossing just beyond the first one that was not seen in the lower resolution scan from yesterday; this is the light blue trace on the plot.  To avoid this second crossing we lowered the Common gain from 15dB to 14.75dB, the results are shown in the dark blue trace.  We currently do not know what is causing the step-like behavior in the TF.

marc.pirello@LIGO.ORG - 14:36, Wednesday 13 November 2024 (81259)

We did a quick scan of the IMC while shifting FSS common gain from 12 to 15.  Plots and data below.

Non-image files attached to this comment
LHO General
thomas.shaffer@LIGO.ORG - posted 07:45, Wednesday 13 November 2024 - last comment - 16:07, Wednesday 13 November 2024(81240)
Ops Day Shift Start

TITLE: 11/13 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Aligning
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: USEISM
    Wind: 16mph Gusts, 11mph 3min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.65 μm/s
QUICK SUMMARY: Looks like H1 made it up to low noise two times in the last 3 hours, but lost lock immediately. useism is still quite high, and some wind overnight didn't help. The IMC is now struggling to stay locked after a few failed DRMI attempts, but a successful PRMI. Starting initial alignment now.

 

Comments related to this report
camilla.compton@LIGO.ORG - 09:17, Wednesday 13 November 2024 (81241)PSL

Two of the 4 locklosses over the night have FSS_OSCILATION tags and two have the IMC tag. The lockloss tool and attached trend show more glitches in the H1:PSL-FSS_FAST_MON_OUT_DQ channel before these locklosses. Maybe from the changes yesterday: TTFSS changed and "PSL FSS:  Common Gain increased from 13 to 15.  Fast Gain increased from 5 to 6" 81235

NLN locklosses last night:

Time (gps) Time (UTC) Time in NLN Tags Notes Zoomed in plot
1415545894 2024-11-13 15:11:15 UTC 0:02:06 FSS_OSCILLATION, OMC_DCPD FSS channel gitches start and grow before lockloss, but not an IMC lockloss  plot zoomed plot
1415542310 2024-11-13 14:11:32 UTC 0:00:06 IMC, FSS_OSCILLATION, OMC_DCPD FSS channel has lots of glitches before lockloss that get more frequent, IMC lockloss plot zoomed plot
1415537275 2024-11-13 12:47:36 UTC 2:37:46 IMC, OMC_DCPD FSS channel normal, but IMC caused lockloss plot zoomed plot
1415508173 2024-11-13 04:42:34 UTC 1:07:00 OMC_DCPD Normal lockloss, no FSS glitches, not caused by IMC  
Images attached to this comment
jason.oberling@LIGO.ORG - 09:08, Wednesday 13 November 2024 (81244)

Increasing the gains should not have caused more oscillations.  I'm writing an alog covering the entirety of our work yesterday right now, but we raised the gains due to finding a bad component in the in-service TTFSS (the PA-85 high voltage op-amp in the EOM path) whose replacement removed reduced the observed zero crossings around 500kHz noted by Sheila et al here and corrected anomolies Marc observed in the EOM path TF (he has the data for this).  We also correctly tuned the EOM notch to remove the 1.685MHz peak also seen in the linked alog.  Raising the common gain put the FSS UGF back in its normal range (400kHz - 500kHz), and we raised the Fast gain by 1dB to compensate for a slight loss of gain in the PZT path caused by our moving the PZT notch from ~35.7kHz to ~32.7kHz.  The TF and crossover measurement showed all should be well with the FSS after these fixes, so it's still unclear why these IMC locklosses continue.

Edit: Upon closer inspection of the TF, the peakiness around 500kHz is still present but apparently less, yet still close to a zero crossing.  We could lower the Common gain by 1dB (to 14dB) to better clear the zero crossing if we suspect this is causing instability.

camilla.compton@LIGO.ORG - 09:27, Wednesday 13 November 2024 (81245)

At 17:18UTC had another lockloss where the FSS_FAST_MON and FSS_PC_MON grow before the lockloss, IMC caused. Plot, zoomed plot shows there isn't explicit glitches but the FSS_FAST_MON channel just gets more noisy.

Images attached to this comment
victoriaa.xu@LIGO.ORG - 16:07, Wednesday 13 November 2024 (81251)

Zoom out comparing Camilla's Lockloss 1 (tagged "FSS" + "IMC") vs. Lockloss 2 (tagged "FSS").

LL1 1415545894 sees lots of FSS glitches before FSS and IMC lose lock, then IFO loses lock. LL2 1415542310 sees noise related to FSS grow slowly before lockloss.

For lockloss 2, tagged "FSS" with a slow oscillation growing before lockloss, Daniel and I then compared the FSS and OMC_DCPD fast (64k) spectra before losing lock here (where H1:PSL-FSS_FAST_MON_OUT_DQ has been calibrated with zpk = ([], [10], [1.3e6]) to get Hz/rtHz.

After PSL swap (cyan and pink traces) - laser noise looks as Daniel expected with ~100 Hz/rtHz at 100 Hz. Before PSL swap, black trace looked lower than expected, unclear.  From lho81210, LLO engages this zpk filter in their filter bank to get the output of H1:PSL-FSS_FAST_MON_OUT_DQ in Hz/rtHz ; LHO has it in the filter bank but does not engage it.

We see more broadband extra noise in FSS (not in OMC DCPD) before losing lock, but no big peaks / features otherwise.

Images attached to this comment
Displaying reports 9281-9300 of 88198.Go to page Start 461 462 463 464 465 466 467 468 469 End