Displaying reports 2661-2680 of 77288.Go to page Start 130 131 132 133 134 135 136 137 138 End
Reports until 16:52, Monday 01 April 2024
H1 ISC
jenne.driggers@LIGO.ORG - posted 16:52, Monday 01 April 2024 (76861)
Prepared updated Jitter cleaning

With apologies that this is so delayed, I have prepared updated jitter cleaning.  Since we're already in Observing, and the IFO isn't yet all the way thermalized, I'll push these and see how they do sometime tomorrow.

To do this, I:

LHO General
ibrahim.abouelfettouh@LIGO.ORG - posted 16:11, Monday 01 April 2024 (76857)
OPS Eve Shift Start

TITLE: 04/01 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 147Mpc
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 8mph Gusts, 5mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.19 μm/s
QUICK SUMMARY:

IFO is in NLN and OBSERVING as of 23:00 UTC (45 min lock)

Other:

H1:PEM-CS_DUST_PSL101                    Error: data set contains 'not-a-number' (NaN) entries

 

H1 General (Lockloss)
anthony.sanchez@LIGO.ORG - posted 16:08, Monday 01 April 2024 - last comment - 17:06, Monday 01 April 2024(76855)
Monday Ops Day Shift End

TITLE: 04/01 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 149Mpc
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY:

H1 Is currently Locked for 44 Min and Observing for 8 Min.  
The Myster H0:CDS-VID_CAM_REQ Button was pushed by a button pusher.

In unrelate news:
Unknown Lockloss 21:22 https://ldas-jobs.ligo-wa.caltech.edu/~lockloss/index.cgi?event=1396041753

Relocked with out an Initial Alignment
The SQZ_FC Gaurdian got stuck for 10 minutes, Vicky jumped on TeamSpeak and helped us out. 
Nominal_Low_Noise 22:24 UTC


LOG:

 

Start Time System Name Location Lazer_Haz Task Time End
17:26 OPS LVEA corner YES LVEA is Laser HAZARD !!!! Alog 76834 15:24
14:58 PEM Robert LVEA/CtrlRm N Shaking Input arm injections 16:00
16:02 LSC Camilla CtrlRm N Retune the LSC FF. 16:32
16:06 PEM Robert EX N power on EX Shaker, not inject yet 17:06
16:40 FAC Chris EX N Cleaning up debris from the road way. 18:40
17:10 FAC Karen Optics Lab N Tecnical Cleaning 19:10
17:14 CDS Dave, Erik Remote N Troubleshooting Dolphin issues 19:14
20:55 PCAL Francisco PCAL Lab Yes Taking Pictures 21:13
23:03 PEM Robert LVEA & EX Yes Shutting Down movers and shakers. 23:33
23:07 HWC Jenne W EY N Running the Arms and Checking out the Wildlife. 00:07

Comments related to this report
victoriaa.xu@LIGO.ORG - 17:06, Monday 01 April 2024 (76862)SQZ

Screenshot showing the issue - the SQZ_FC state "FIND_IR" had over run its execution time by like 10 minutes. I suspect what happened is that in FIND_IR's call to find_min(), the find_min() function called cdu.getdata(), which got stuck in the data grab and overran the time.

I manualed SQZ_FC to "GR_LOCKED", then set it back to being MANAGED by SQZ_MANAGER. Then it automatically went up to FDS without intervention.

Images attached to this comment
H1 SUS
anthony.sanchez@LIGO.ORG - posted 15:50, Monday 01 April 2024 - last comment - 15:53, Monday 01 April 2024(76851)
SUS SDFs Accepted into Safe.snap

SUS SDF changes saved to Safe.snap.
IM
IM1,2,3,4 Pitch
IM1,2,3,4 Yaw

OMC, OFI, OM1, 2, 3

Images attached to this report
Comments related to this report
oli.patane@LIGO.ORG - 15:53, Monday 01 April 2024 (76852)

The other updated OPTICALIGN offset values as updated through my script 76606 . Very fast and easy to use if you are updating safe.snap to current values!

Images attached to this comment
anthony.sanchez@LIGO.ORG - 15:51, Monday 01 April 2024 (76853)

Please see Jeff's alog about these changes https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=76850

H1 SUS (CDS, ISC, SQZ, SUS)
jeffrey.kissel@LIGO.ORG - posted 15:29, Monday 01 April 2024 - last comment - 10:04, Tuesday 02 April 2024(76850)
Model Prep for HAM Doubles and Singles Watchdog Upgrade Complete
J. Kissel
ECR E1700387
IIET 9392
WP 11743

Here, this week we tackle the last of the suspension types that need suspension watchdog upgrades after having finished the End Station, Corner BSC, and HAM Triple suspensions this past month (LHO:76269, LHO:76545, and LHO:76712, respectively).

WP 11797
While doing so, I'm also going to address the OMC ASC routing bugs found in the h1susifoout top-level model and its OMCS_MASTER library part (which used to live in h1susomc.mdl), and fix those too.

As such, I'm doing a linear combination of the following changes:
    (1) In library part, removed sending watchdog out to top level
    (2) In library part, removed ODC parts from DAMP and LOCK banks
    (3) In library part, removed never-usered software shutter system
    (4) In library part, upgraded watchdog trigger generator to actual functional RMS
    (5) At top level, removed USER DACKILL
    (6) At top level, removed wires to ground (i.e. things never used) at top-level for WD, SHUTTER, and ODC outputs and SHUTTER input
    (7) At top level, cleaned up receiving of ISC ASC signals (see discussion in LHO:76842)

Below is the list of models, their respective library parts, and the optics in that model that this impacts, followed by a call out of which of the above changes happened
h1susim       HSSS_MASTER    IM1, IM2, IM3, IM4      (1), (2), (4), (5), (6)
h1sushtts     HSSS_FF_MASTER RM1, RM2                (1), (2), (3), (4), (6)
h1susifoout   OMCS_MASTER    OMC                     (1), (2), (4), (5), (6), (7)
              OFIS_MASTER    OFI                     (1), (2), (4), (6)
              HSSS_MASTER    OM1, OM2, OM3           (1), (2), (4), (5), (6)
h1sussqzout   HSSS_MASTER    ZM4, ZM5, ZM6           (1), (2), (4), (5), (6)
h1sussqzin    HDDS_MASTER    ZM1, ZM3                (1), (4)
              OPOS_MASTER    OPO                     (1), (2), (4), (6)
              HSSS_MASTER    ZM2                     (1), (2), (4), (5), (6)

I've test-compiled all of the above listed models, so they're ready for re-compile, install, and restart of the front-end process tomorrow morning.
All model changes have been committed to the userapps repo, either under
    /opt/rtcds/userapps/release/sus/h1/models/
    /opt/rtcds/userapps/release/sus/common/models/
where the above mentioned models live.

Screenshots describing the changes will be posted in the comments.
Comments related to this report
jeffrey.kissel@LIGO.ORG - 16:19, Monday 01 April 2024 (76856)CDS, ISC, SUS
To address the removal of the transverse, vertical, and roll possibility and removing the "bad route" of the L, P, and Y OMC ASC control, I've done the following:
    (1) At the top level of the h1susifoout model, I've removed the ingestion of the T, V, and R IPCs. These still get send out into the dolphin IPC fabric from the h1omc model, because I didn't want to mess with that model. This means that if someone ever tries to use the OMC-ASC_DOF2TT matrix elements for "SUS V, SUS R or SUS T", the output of those elements of that matrix will go into nothing, essentially terminated.

        See before vs. after screenshots of the bottom left corner of the h1susifoout.mdl top level IPC area.
 
    (2) I've modified the OMCS_MASTER model to completely delete the "OMC_M1_ASC" bank, and removed all simulink inputs that landed in that bank from the top level h1susifoout model, to the top level of the OMCS_MASTER model, to the M1 stage of the OMCS_MASTER.

        See before vs. after area surrounding the call to the OMCS_MASTER.mdl in the h1susifoout.mdl top level model, 

        And then drilling down into the OMCS_MASTER library part, see
            (i) before and after, the top level of the OMCS_MASTER library part.

            (ii) before vs. after, the M1 stage of the OMCS_MASTER library part.

    (3) Because the OMC ASC alignment input channels are stored inthe frames at 256, I had to update the DAQ channel list to switch to using the M1_LOCK banks rather than the M1_ASC banks. Note, there are therefore 3 less channels stored in the frames.

         This is seen in (2)(i) before vs. after cited above.

    (4) While there, I also deleted other never-used / impossible to use infrastructure that I installed early on in the 2010s because it was easier to copy and past than to customize. Now that we've gone through 4 observing runs, and there's no hardware to support it, I'm deleting the infrastructure to clean things up (lest it gets copied forward again by some future me). This includes
        (a) The "LKIN" parts, which are originally designed for demodulating an angular dither signal in order to diagonalize angular drive. But, there are only two OSEMs for both pitch and yaw on the OMCS's OSEM configuration, so the "coil balancing" methods, using the lock-in just will not work, since we can't drive "pringle." DELETED.
        (b) Many other SUS that have right-cylinders for optics, which have a center of rotational actuation that we're trying to align to a geometric rotational center in order to minimize angle to length coupling by "dithering." Sometimes you might hear the gains applied to the actuation basis called the "A2L" gains. For the OMCS, the beam is coming in at the edge of a square breadboard that's suspended beneath the actuators, of which again, there're only two. This, like the LKIN system, the DITHER system just doesn't make any physical sense.
     Because of the reasons outlined in (a) and (b), the inputs to the M1 stage of the OMCS_MASTER library part have always been terminated. That means that the inputs from ISC don't even appear at the top level. So, I've ripped both of these out.
   
         This is seen in (2)(ii) before vs. after cited above.
    
Images attached to this comment
jeffrey.kissel@LIGO.ORG - 10:04, Tuesday 02 April 2024 (76876)
J. Kissel, D. Barker, P. Fritschel

Model changes described above in LHO:76856 now covered under (fast-track approved) ECR E2400116 and IIET Ticket 30863, escalated to such formality because the SUS-OMC_M1_ASC_[LTVRPY]_IN1 channels *were* in the GDS broadcaster frames which is under strict ECR control. They're now replaced by OMC_M1_LOCK_[LPY]_IN1 (i.e. three less channels because TVR don't exist).

After making these changes, the impacted model and library have been committed to the userapps SVN under
    /opt/rtcds/userapps/release/sus/h1/models/h1susifoout.mdl            rev 27374
    /opt/rtcds/userapps/release/sus/common/models/OMCS_MASTER.mdl        rev 27375
H1 AOS
robert.schofield@LIGO.ORG - posted 14:57, Monday 01 April 2024 - last comment - 15:00, Monday 01 April 2024(76847)
Scattering noise from input arm vibration injections minimized with new setting of IRMY yaw offset

While studying the improvement made by stray light modifications over the break (summary alog soon), I found that the coupling was minimized by changing ITMY R0 yaw offset from -300 to -250. We want to change the settings before my alog, hence this mini-alog.

Comments related to this report
jenne.driggers@LIGO.ORG - 15:00, Monday 01 April 2024 (76848)

I have set and saved that value of -250 for the IY reaction mass yaw offset in both the safe and observe SDF files.  I did this right around when DRMI had just caught lock during this acquisition, so it seems fine (as we'd expect) for locking with this very slightly different offset.  Attached are the safe and observe snap screenshots of my accepting the new value.

Images attached to this comment
H1 General (SEI)
anthony.sanchez@LIGO.ORG - posted 14:22, Monday 01 April 2024 (76846)
SDF Accepted to get into Observing

SDF Diff accepted.
H1:IOP-SEI_HAM6_DK_BYPASS_TIME

Images attached to this report
H1 ISC
naoki.aritomi@LIGO.ORG - posted 13:55, Monday 01 April 2024 (76844)
Unmonitored camera servo offset in safe.snap

Since the camera servo offset was monitored by SDF in safe.snap, everytime we lose lock, the camera servo offset was set to the values in safe.snap which are kind of random. So I unmonitored the camera servo offset in safe.snap. This will make it easy to look back the camera servo offset in different locks.

Images attached to this report
H1 General
anthony.sanchez@LIGO.ORG - posted 13:02, Monday 01 April 2024 (76843)
Monday Ops Mid Day Shift Report


TITLE: 04/01 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    SEI_ENV state: SEISMON_ALERT
    Wind: 8mph Gusts, 5mph 5min avg
    Primary useism: 0.08 μm/s
    Secondary useism: 0.24 μm/s
QUICK SUMMARY:
Some Commissioning was being done until the 16:23 UTC Dophin Crash.
Took all SUS to SAFE
Took all SEI to ISI_DAMPED_HEPI_OFFLINE
Took HAM1 HEPI to MASTERSWITCH_OFF
CDS started restarting DAQs at 16:53 UTC ish

The FC SUS kept trying to put itself into aligned everytime we went into prep for locking even though ISC_LOCK was in IDLE.
I then Manualed ISC_LOCK to IDLE then took SQZ_MAN to Down, then Paused SQZ_MAN and finally I took FC to SAFE for good.

17:33 UTC Took all the SUS back to Aligned.
Then took ISI's & HEPI's back to ISOLATED.
Then took SEI_ENV back to Calm
Started Initial_Alignment 17:53 UTC
Increase_Flashes ran for both arms

IA could not get passed Input align due to IMC unlocking issues seen on friday's Alog 76793

Once the Issue was Identified I took all sliders except for SQZ to 1395811454 ( tail end of the last Initial Alignment) 

Y arm looked bad so I took Yarm sliders only to 1396030446 (Tail end of Increase Flashes)  to get good Y arm Values in Green arms Manual.

INITIAL_Alignment started again and completed near 19:07 UTC.

NOMINAL_LOW NOISE has been reached 19:49 UTC.

H1 SUS
jeffrey.kissel@LIGO.ORG - posted 12:37, Monday 01 April 2024 - last comment - 10:02, Tuesday 02 April 2024(76842)
OMC ASC Inputs to H1 SUS OMC Drive Path Has Been Doing it Wrong For Years. We Can Fix it Tomorrow.
J. Kissel, [Corroborated by J. Wright and J. Driggers]
WP 11797

While upgrading the OMCS_MASTER.mdl library part for the OMC Suspension (which now lives in the h1susifoout.mdl top-level model), I found two distressing things:
    (1) The OMC ASC signals that are sent from the h1omc.mdl model -- running at 2kHz -- are not anti-imaged at all before being sent to the OMC SUS DAC -- running at 16 kHz. So, we're sending unnecessary imaging noise to the SUS DAC.
    (2) The OMC ASC L, P, amd Y signals are being sent through a filter bank that does NOT past through the DRIVEALIN matrix, rendering 2019's attempt at diagonalization (LHO:47488) unused.

These bugs have been long standing.
I see it now as I touch the h1susifoout.mdl and the OMCS_MASTER library part for watchdog upgrades, but I'd previously identified the issue when 
 - I was upgrading the front-end models for O4 (i.e. when the OMC SUS transitioned from the h1susomc.mdl to the h1susifoout.mdl) in 2021 (LHO:59652), and
 - When we were identifying which SUS models used the broken "TrueRMS" bloick -- there's a preceding note in the simulink model that suggests this has been around since 2015 or earlier.

We can fix this tomorrow, with *only* a change to the h1susifoout.mdl and OMCS_MASTER.mdl models, and we're already doing that anyways for the SUS watchdog upgrade.


Attached are several series of screenshots showing:
    (1) The signal path from the h1omc.mdl model where the OMC ASC control signals begin, to where they land in the OMC SUS driving in the EULER basis (again WITHOUT going through the DRIVEALIGN MATRIX)
    (2) MEDM Screens showing that in practice we only drive L, P, and Y (as one should for an ASC signal) and we don't use T, V, or R drive and likely never will.
    (3) The existing filters that will need to be copied over, and the DRIVEALIGN gain values that will likely need to be re-addressed -- since effectively we've NOT been using them.

Note -- I checked on how this is done at LLO, and they *do* drive through the LOCK banks and DRIVALIGN banks (BUT they don't have any anti-imaging filters in pace either, even though their ISCINF FM1 banks are ON... whoops)...
So, when we change the OMCS_MASTER library part, this won't affect them.
Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 15:05, Monday 01 April 2024 (76845)ISC
The ASC P and Y filters in play during nominal low noise are as follows:
     Bank            Module     Name         Design String
     OMC_M1_ASC_P    FM0        SUSinvert    zpk([0.12+i*3.85;0.12-i*3.85;0.12+i*2.18;0.12-i*2.18],[0.3+i*1.75;0.3-i*1.75],1,"n")
                     FM10       LP8          zpk([],[2.58028+i*3.68676;2.58028-i*3.68676;1+i*7.93725;1-i*7.93725],1,"n")

     OMC_M1_ASC_Y    FM0        FM1          zpk([0.033+i*0.54;0.033-i*0.54;0.25+i*3.95;0.25-i*3.95],[1.6;1.6],1,"n")
                     FM10       LP8          zpk([],[2.58028+i*3.68676;2.58028-i*3.68676;1+i*7.93725;1-i*7.93725],1,"n")

These might be from 2015 -- the only aLOG I can find that even vaguely discusses these filters is LHO:16402.
(Note, these are distinctly separate from the primary OMC ASC control filters that were simiplified by Dan Brown and Evan Hall in 2022; LHO:65861).

Attached are bode plots of these two filters and their products for PITCH (in RED, on the left) and for YAW (in BLUE, on the right).
Note, the FM0 plant inversion filters resolve to have notches at
    Notch Freq     1st (Hz)  2nd (Hz)
       P DOF          2.21     3.84
       Y DOF          0.54     3.94


For comparison, I plotted the M1 [PIT,YAW] to M2 [PIT,YAW] transfer functions from the latest dynamical model from 2021 when I improved the damping loops (LHO:60049) and I get resonances at 
    Notch Freq     1st (Hz)  2nd (Hz)
       P DOF          1.92     3.98
       Y DOF          0.46     4.13


So ... maybe when we fix the infrastructrure, we should also update the plant inversion...
Images attached to this comment
Non-image files attached to this comment
jeffrey.kissel@LIGO.ORG - 16:20, Monday 01 April 2024 (76858)ISC, SYS
LHO aLOG 76856 describes the model prep for fixes made to the h1susifoout.mdl top level part and OMCS_MASTER.mdl library part in order to fix this bug.
jeffrey.kissel@LIGO.ORG - 10:02, Tuesday 02 April 2024 (76875)
J. Kissel, D. Barker, P. Fritschel

Model changes described above in LHO:76856 now covered under (fast-track approved) ECR E2400116 and IIET Ticket 30863, escalated to such formality because the SUS-OMC_M1_ASC_[LTVRPY]_IN1 channels *were* in the GDS broadcaster frames which is under strict ECR control. They're now replaced by OMC_M1_LOCK_[LPY]_IN1 (i.e. three less channels because TVR don't exist).

After making these changes, the impacted model and library have been committed to the userapps SVN under
    /opt/rtcds/userapps/release/sus/h1/models/h1susifoout.mdl            rev 27374
    /opt/rtcds/userapps/release/sus/common/models/OMCS_MASTER.mdl        rev 27375
H1 ISC
camilla.compton@LIGO.ORG - posted 09:33, Monday 01 April 2024 - last comment - 13:00, Thursday 04 April 2024(76838)
Measured MICH LSC feedforward
Followed /lsc/h1/scripts/feedforward/README.txt 
Last done March 16th: 76460, suggestion to refit in 76766.
Measured for MICH but we lost lock during SRCL injections. Plan to refit for MICH, current FF attached, it's worse than March 16th fit in 10-35Hz region.
Images attached to this report
Comments related to this report
camilla.compton@LIGO.ORG - 16:26, Monday 01 April 2024 (76859)

I saved an improved fit into FM6 as "04-01-24" but have not yet loaded coefficients. Plan to test it tomorrow.

Images attached to this comment
camilla.compton@LIGO.ORG - 13:00, Thursday 04 April 2024 (76956)

Tested this new FM6 once IFO had been locked 12 hours. New FF looked better, plot attached. Leaving it on from 19:45UTC.

Images attached to this comment
H1 General (SQZ)
anthony.sanchez@LIGO.ORG - posted 16:07, Sunday 31 March 2024 - last comment - 16:52, Monday 01 April 2024(76832)
Sunday Ops Day Shift End

TITLE: 03/31 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY:
LOG:
H1 now Locked for 24 hours , and Observing as of 23:00 UTC.
It's been really quiet day for Robert to do PEM injections all day.

SQZers requested a few minutes of SQZ_MANAGER taken to SCAN_SQZANG  which happened at 21:23 UTC                                                                                                                                                                        

Start Time System Name Location Lazer_Haz Task Time End
17:26 ops LVEA corner YES LVEA is Laser HAZARD !!!! 15:24
16:07 PEM Robert LVEA YES Shaking injections on the Input arm 23:03
Comments related to this report
victoriaa.xu@LIGO.ORG - 16:52, Monday 01 April 2024 (76860)

Screenshot of the SCAN_SQZANG state (76776) - it scans SQZ CLF RF6 demod phase to scan the sqz angle, and optimizes squeezing at 350 Hz by minimizng the yellow BLRMS3.

Here it changed the CLF_RF6 demod phase by +19 degrees. That was a squeezing improvement of 1.4dB for 350 Hz yellow BLRMS 3, and improvement of about 3dB for the 1.7 kHz blue BLRMS 5.

Images attached to this comment
H1 TCS
camilla.compton@LIGO.ORG - posted 13:22, Tuesday 26 March 2024 - last comment - 15:19, Monday 01 April 2024(76715)
CO2X Beam Scan

TJ, Camilla, WP 11746, LLO did in LLO#14419

We blocked the beam path going into vaccunm (downstream of the BS) and the FLIR path. Photo during set A,B and C attached. 
Mounted a razor blade to a 25mm transition stage.
At 1mm increments we measured the power transmitted to our PD (channel H1:TCS-ITMX_CO2_LSRPWR_MTR_OUTPUT). 
 
We repeated this 3 times:
Data attached, still to be analyzed - use Matlab code from LLO#14419.
 
Data set A and B:
BS to Razor 8”
Razor to center of annular mask: 2 3/8”
Razor to center of center mask: 3 1/2”
Annular Mask to Mirror: 18 3/8“
 
Data set C:
BS to annular Mask = 10”
Razor to annular Mask = 10 7/8”
Razor to central Mask = 9 1/2”
Rasor to mirror = 5 1/2”
 
We attempted to use the Wincam beamscanner (as in 74914) to measure the beam before the periscope, setup in attached photo. the beam was too large so we need to shorten our beam path. Left in the two downstream mirrors and left the FLIR path blocked so we can continue this work on a future Tuesday. 
Images attached to this report
Non-image files attached to this report
Comments related to this report
camilla.compton@LIGO.ORG - 15:19, Monday 01 April 2024 (76849)

Using Matlab code from LLO#14419 with edit to parameter x = 4:1:26

  • Data set A plot: No mask. Razor blade 2 3/8" (60mm) downstream of the center of the annular mask: beam radius = 10.28mm 
  • Data set C plot: No mask. Razor blade 10 7/8” (275mm) upstream of the center of the annular mask: beam radius =  10.81mm
Images attached to this comment
H1 ISC
jennifer.wright@LIGO.ORG - posted 17:45, Monday 25 March 2024 - last comment - 15:59, Monday 01 April 2024(76694)
Changing Modulation Depth

Sheila, Jennie W

At around 21:49 UTC we used the step_45MHz.py in userapps/isc/h1/scripts to step the modulation depth in steps of 1dB down from 21dBm to 18dBm. This script adjusts the loop gains to compensate for a drop in power on the RF45 PDs.

Its also important to open the POP beam diverter to monitor what is happening to the RF 45 PD signals.

This is to check that the noise does not decrease with decreasing modulation depth which would imply that the modulator was imposing noise on the carrier through the ISS loop.

At around 22:18 UTC we put the modulation depth down by 3 dB we saw a 4% increase in the DARM broadband noise (measured the level at 2kHz with cursors) which is the green trace in the second image. The level of KAPPA C (shown in first image on bottom plot) only decreased by around 1% over this time, so we suspect some other cause other than a change in optical gain being responsible for this.

When we stepped the modulation depth up by 3dB (third image) we saw no change in the noise from the nominal state (purple trace on second image). Kappa C (bottom plot) looks almost the same as the nominal also.

In the fourth image it can be seen that f_C does not change much either.

Images attached to this report
Comments related to this report
jennifer.wright@LIGO.ORG - 15:59, Monday 01 April 2024 (76854)

After we did this test Daniel commented that we should check what the PCAL lines did as we stepped down and up the 45 MHz modulation depth.

To do this I used the spectra we took and measured the height of the 410.3 Hz line (PCAL Y) in DARM in m.

Our nominal level was 1.35370 e-19 m

The line height decreased by 1.1% when we decreased the modulation depth by 3dB. I think this is consistent with our optical gain decreasing by 1%. I am therefore not sure why lowering the mod depth causes a 4% increase in DARM.

The line height increased by 0.04 % when we increased the mnodulation depth by 3dB. I think this is consistent with us not seeing much decrease in the DARM noise when we increase the modulation depth.

Images attached to this comment
Displaying reports 2661-2680 of 77288.Go to page Start 130 131 132 133 134 135 136 137 138 End