Displaying reports 9301-9320 of 88197.Go to page Start 462 463 464 465 466 467 468 469 470 End
Reports until 11:04, Wednesday 13 November 2024
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
H1 CDS
david.barker@LIGO.ORG - posted 10:49, Wednesday 13 November 2024 (81249)
Showing lock state on CDS Overview MEDM

Redesigned Range/Lock section in lower left corner of the CDS Overview shows the lock_state as a horizontal bar widget below the range LED display.

Images attached to this report
LHO VE
david.barker@LIGO.ORG - posted 10:30, Wednesday 13 November 2024 (81248)
Wed CP1 Fill

Wed Nov 13 10:16:03 2024 INFO: Fill completed in 15min 59secs

Jordan confirmed a good fill curbside. Note TC-B started at almost 0C, hence the additional decades in the y-axis log scale.

Images attached to this report
H1 General
thomas.shaffer@LIGO.ORG - posted 09:00, Wednesday 13 November 2024 (81243)
Observing 1658 UTC

After a few lock losses this morning from low noise, some FSS instability, and the IMC struggling to stay locked, we are now back to Observing.

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
LHO General
corey.gray@LIGO.ORG - posted 22:00, Tuesday 12 November 2024 (81233)
Tues EVE Ops Summary

TITLE: 11/13 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
INCOMING OPERATOR: Oli
SHIFT SUMMARY:

Slow start to locking at the beginning of the shift, but once PSL work was done, ran an alignment and returned to locking (had one lockloss due to PSL/IMC), then made it to NLN/Observing and had a "normal lockloss" (i.e. NOT PSL/IMC).

Probably old news, but it feels like after locklosses DRMI/PRMI have been pretty misaligned.  Sometimes fixed by CHECK MICH FRINGES/PRMI, but sometimes a full INITIAL ALIGNMENT is required.  (Running 2nd Initial Alignnment of the shift before the end of the shift.)

Microseism is still high but winds calmed during this shift.
LOG:

LHO General
corey.gray@LIGO.ORG - posted 21:26, Tuesday 12 November 2024 (81239)
LVEA Swept & CARM Sensor Injection Cable Unplugged After Lockloss

E.Capote, C.Gray

With the recent lockloss, Elenna and I went out to do the LVEA Sweep, which also included unplugging the Freq Noise Injection cable they plugged in yesterday.

H1 General
corey.gray@LIGO.ORG - posted 20:26, Tuesday 12 November 2024 - last comment - 20:59, Tuesday 12 November 2024(81235)
Shift Update: H1 Observing Now (Had PSL/IMC Glitch Lockloss Earlier)

Long Maintenance/Preventative-Maintenance Day Today

Once Jason & RyanS finished their PSL work on the floor (and some observing of the IMC for glitches in the Control Room), went for locking at about 515pm PST---with an INITIAL ALIGNMENT which completed with no major hitches.  For locking, we continue to get Locklosses before/at LOCKING ARMS GREEN (so held at READY for a bit....but we had to wait a few minutes for the IMC to lock).  Once we got past this, went for our first lock of the night. 

[µseism is still very high, but winds dropped from 30mph down to 10mph]

Lock #1:  LOCKLOSS for H1 at TRANSITION FROM ETMX[557] (which is noteworthy because Elenna was wanting to see if the lowered T-Ramp (alog81224) at LOWNOISE ESD ETMX [558] and we didn't get to see this.  Vicky looked at this lockloss and sadly this LOCKLOSS was one of our infamous PSL/IMC Glitches.

Lock #2:  After the lockloss above, DRMI looked pretty bad, so I took it to PRMI (but it also needed CHECK MICH FRINGES).  After that, H1 went all the way to NLN automatically.  The Violins were high (~500Hz peak was at around 1e-15), so we had to stay at OMC WHITENING for 20min before going to NLN.  Then there were a list of SDFs which were all ACCEPTED (see below and attached).  H1 to OBSERVING at 0340utc with a range hovering just under 160Mpc.

Maintenance Day Notes:

SDF Diffs That Were ACCEPTED: (see attached)

Images attached to this report
Comments related to this report
corey.gray@LIGO.ORG - 20:44, Tuesday 12 November 2024 (81236)

Lockloss at 0442utc after about 1hr of Observing.

BUT---Vicky was saying this was a "normal" (i.e. not PSL/IMC glitch lockloss).

victoriaa.xu@LIGO.ORG - 20:55, Tuesday 12 November 2024 (81237)

Lockloss #1 @ 1415499897 - likely PSL/IMC.

Standard PSL trends show FSS glitch, IMC, and IFO lockloss all at the same time (< 16kHz). Trends including SQZ not illuminating; see SQZ FSS glitch same time as PSL glitch (same time as lockloss), but not more info.

Images attached to this comment
victoriaa.xu@LIGO.ORG - 20:59, Tuesday 12 November 2024 (81238)

Lockloss #2 @ 1415508172 - NOT PSL/IMC! Looks like a "standard" (?) lockloss.

Standard PSL trends show that IFO and AS port see the lockloss ~200ms before the IMC loses lock. This was the typical lockloss before IMC/PSL issues. SQZ trends are normal; SQZ TTFSS and signals lose it when PSL FSS loses lock (again, ~200ms after arms see the lockloss), as expected.

Images attached to this comment
H1 CDS
david.barker@LIGO.ORG - posted 19:48, Tuesday 12 November 2024 - last comment - 11:22, Wednesday 13 November 2024(81234)
VACSTAT BSC3 single sensor glitch, no alarm issued to VAC team

At 19:27:26 PST a PT132_MOD2 glitch caused a single-sensor VACSTAT glitch. The new code requires two chambers to glitch before alarming the VAC team, so in this case no cell phone alarms were sent.

The glitch lasted 4 seconds, and as before it was DeltaP which tripped, exceeded its trip level of 1.0e-08Torr  (see attached).

I restarted vacstat_ioc.service on cdsioc0 to reset the system.

Images attached to this report
Comments related to this report
david.barker@LIGO.ORG - 11:22, Wednesday 13 November 2024 (81252)

Attached trend shows the increase in sensitity for BSC2's slope and deltap following the BSC3 glitch detection. All trip levels were later restored following a restart of vacstat_ioc.

Images attached to this comment
LHO General
corey.gray@LIGO.ORG - posted 16:49, Tuesday 12 November 2024 (81232)
Tues EVE Ops Transition

TITLE: 11/13 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: MAINTENANCE
    Wind: 26mph Gusts, 19mph 3min avg
    Primary useism: 0.67 μm/s
    Secondary useism: 0.77 μm/s
QUICK SUMMARY:

Long Maintenance Day, high microseism, high winds, M5.0 Mexico earthquake.....but the IMC was just locked in the last few minutes!

H1 General
anthony.sanchez@LIGO.ORG - posted 16:45, Tuesday 12 November 2024 (81231)
Tuesday Maintance Ops Shift End

TITLE: 11/13 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
INCOMING OPERATOR: Corey
SHIFT SUMMARY:
H1 was held in IDLE all day while we had a long maintenance day with a focus on the PSL's TTFSS repair.

The PSL Crew is still in the PSL room, re-installing the TTFSS.
Secondary microseism is still elevated wind is still elevated as well.  

Beckhoff updates were done today at 4PM as well.


LOG:

Start Time System Name Location Lazer_Haz Task Time End
21:41 SAF Laser LVEA YES LVEA is laser HAZARD 08:21
15:32 FAC Karen Optics & VAC Prep Labs N Technical cleaninng 15:42
15:42 FAC Karen EY n Technical Cleaning. 17:01
15:55 FAC Nelli HAM Shaq N Technical Cleaning 16:41
15:56 FAC Kim EX N Technical Cleaning 17:21
16:30 SEI Neil, Jim, Fil LVEA Beirgarden yes Installing GeoPhone Seimometer 19:23
16:46 3IFO Tyler LVEA Yes 3 IFO Checks 17:22
16:57 PSL Jason & Ryan S PSL Room Yes Working on PSL, PMC,  TTFSS 18:41
17:11 SUS Rahul EY & EX N SUS Measurements 18:39
17:13 CDS Richard CER N Maximizing the window for Maintenance 17:16
17:15 N2 NorCo Y arm N N2 fill, another Nor Cal Truck also went down the Y arm 19:15
17:22 FAC Tyler Mid Stations N 3 IFO checks 19:22
17:39 pSL Daniel PSL racks Yes Removing power from old PSL rack equipmnt 19:39
17:45 VAC Travis & Janos EY & MX N Checking vac pump status in Recieving areas 19:39
17:51 FAC Kim & Karen LVEA YES Technical Cleaning Karen out early 19:04
18:30 SEI Neil D. LVEA Yes Taping a GeoPhone to the Floor. 18:50
18:57 SEI Neil CER N Turning on a switch in the CER 19:14
19:05 FAC Kim High bay n Tech clean 20:03
20:08 VAC Janos EY, MX N Vac Hardware check. 22:08
20:58 PSL Daniel LVEA PSL Racks Yes Checking on the FSS 21:51
21:14 FAC Erik Tyler Mid Y N Handling the Air , Tyler back early 22:36
21:41 ISC Christina EY, MX n Inventory 22:16
21:47 PSL Ryan S & Jason PSL Yes Replacing the TTFSS 01:48
22:01 VAC Travis MX N Vac systems check 22:20
22:07 EE Fil CER N Turning on High Voltage 22:17
23:22 VAC Janos Mid X N Measuring Vac system equipment. 23:34
23:47 SEI Jim CER N checking cables 23:52
23:54 CDS Erik CER N Getting a laptop 00:00

 

H1 ISC
elenna.capote@LIGO.ORG - posted 10:27, Monday 11 November 2024 - last comment - 16:28, Tuesday 12 November 2024(81194)
One CARM Sensor Injections

Sheila and I went out to the floor to plug in the cable to run frequency noise injections (AO2).

I switched us to REFL B (79037) only to run the injections. I first ran the frequency noise injection template. Then, I disenaged the 10 Hz pole and engaged the digital gain to run the ISS injections (low, medium, and high frequency). I was fiddling with the IMC WFS pitch injection template to get it to higher frequency for a jitter injection when we lost lock.

Next step is to at least use the intensity and frequency measurements to determine how the noises are coupling to DARM (would be nice to have jitter too, but we'll see).

Comments related to this report
victoriaa.xu@LIGO.ORG - 13:15, Tuesday 12 November 2024 (81226)

Commit 464b5256 in aligoNB git repo.

elenna.capote@LIGO.ORG - 16:28, Tuesday 12 November 2024 (81230)

These results show that above 3 kHz, some of the intensity noise couples through frequency noise. There is no measurable intensity noise coupling through frequency noise at mid or low frequency.

The frequency noise projection and coupling in this plot are divided by rt2 to account for the fact that frequency noise is measured on one sensor here, but usually is controlled on two REFL sensors. This may not be correct for high frequency (roughly above 4 kHz), where CARM is gain limited.

code lives in /ligo/gitcommon/NoiseBudget/simplepyNB/Laser_noise_projections.ipynb

Images attached to this comment
X1 SUS
oli.patane@LIGO.ORG - posted 16:03, Tuesday 05 November 2024 - last comment - 12:05, Wednesday 13 November 2024(81075)
10/31 BBSS M1 Transfer function measurements

Following the raising of the entire BBSS by 5mm (80931), we took transfer function measurements and compared them to the previous measurements from October 11th(80711), where the M1 blade height was the same but the BBSS had not yet been moved up by the 5mm. They are looking pretty similar to the previoius measurements, but there are extra peaks in V2V that line up with the peaks in pitch.

The data for these measurements can be found in:

/ligo/svncommon/SusSVN/sus/trunk/BBSS/X1/BS/SAGM1/Data/2024-10-31_2300_tfs/

The results for these measurements can be found in:

/ligo/svncommon/SusSVN/sus/trunk/BBSS/X1/BS/SAGM1/Results/2024-10-31_2300_tfs/

The results comparing the October 11th measurements to the October 31st measurements can be found in:

/ligo/svncommon/SusSVN/sus/trunk/BBSS/Common/Data/allbbss_2024-Oct11-Oct31_X1SUSBS_M1/

Non-image files attached to this report
Comments related to this report
ibrahim.abouelfettouh@LIGO.ORG - 12:05, Wednesday 13 November 2024 (81253)

BBSS Status of Drift since moving whole BBSS up from the Top Stage to compensate for TM blades moving down (alog 809391)

Plots:

BBSSF1DriftPUMDoFsCurrentConfig: 6 day trend of LPY micron counts for the PUM.

  • There seems to be a ~80 micron +YAW movement.
  • Minimal (20 micron) drift in L.
  • No P drift.
  • There is no previous PUM screenshot because the flags were too low in the BOSEMs to be considered accurately sensing (which is one of the main reasons we raised the BBSS from the Top Stages to begin with).

BBSSF1DriftTMDoFsCurrentConfig: 6 day trend of LTVRPY micron counts for the Top Mass.

  • There seems to be a ~80 micron in +YAW movement.
  • Minimal (+40 micron) drift in P amounting to 6.77 micron/day of drift. No other drift.

BBSSF1DriftTMDoFsPreviousConfig: 18 day trend of LTPRPY micron counts for Top Mass.

  • No drift observed. The 57 micron displacement in P amounts to 3.17micron/day of drift, which is neglibible.

BBSSF1DriftTMBOSEMssPreviousConfig: 18 day trend of BOSEM counts for Top Mass.

  • No drift observed. The 196ct displacement in F1 amounts to 10.89ct/day of drift, which is neglibible.

BBSSF1DriftTMBOSEMsCurrentConfig: 6 day trend of BOSEM counts for Top Mass.

  • Minimal drift observed in F1. The  micron displacement in P amounts to 60ct/day of drift, which is slightly worse than prev. In general, this is about 6x more drift than the previous config, but 1/3 the drift of our past more drifty configs.

First Look Findings:

  • There is a YAW drift in the current config compared with previous, which is somewhat understandable since blade movements at the top stage risk YAW displacement but why is it drifting and not just an offset?
  • There is slightly more F1/P drift in the current config than the previous, but I would consider it largely minimal compared to the general amount of drift we've seen in other configurations.
Images attached to this comment
Displaying reports 9301-9320 of 88197.Go to page Start 462 463 464 465 466 467 468 469 470 End