Displaying reports 701-720 of 81821.Go to page Start 32 33 34 35 36 37 38 39 40 End
Reports until 11:01, Monday 24 March 2025
LHO FMCS (VE)
gerardo.moreno@LIGO.ORG - posted 11:01, Monday 24 March 2025 (83527)
Y-Mid Station VEA Temperature Affecting VE Pressure

Noted that there was a out of nominal rise on the Y-Arm pressure plot (see first attachment), handy tool, so I started looking into it.  Noted that the temperature in the VEA for the Y mid station has gone up from an nice oscillation of 63~65 °F up to a rising temperature, currently at 68 °F, maybe we are adding heat to the Y-Mid??, all pressure gauges, including the annuli ones noted the pressure rise.  No attention required, but it would be nice if the temperature stopped at a nominal value.

Images attached to this report
H1 SEI
jim.warner@LIGO.ORG - posted 10:56, Monday 24 March 2025 - last comment - 14:10, Monday 24 March 2025(83528)
H2 CPS on HAM3 noisy since last Tuesday

RyanS reported getting HAM3 CPS noise notifications on DIAG_MAIN. Looking at the log, there have been several periods where the blrms noise monitors have been going over threshold. Digging in to HAM3's performance this morning, CPS noise seems to be affection mostly RZ, but the other horizontal dofs are affected. as well. First attached image, is comparision with HAM2. Top asds are the rotational dofs, bottom are the X/Y/Z dofs. HAM3 RX/RY/Z vertical dofs are all mostly similar to HAM2, but the cyan trace vs the pink trace on the top plot shows HAM3 RZ is moving much more that HAM2 RZ.

Second image shows asds of the individual sensors, the blue trace on the top plot is H2 CPS, which has a higher noise floor than the other sensors, so I suspect this sensor is the root cause of the HAM3s problems. All of the other senors seem more or less healthy. If I get a chance or the ISI becomes unstable, I would like to go to the floor or CER to power cycle some stuff. Otherwise, I can wait till tomorrow.

Images attached to this report
Comments related to this report
jim.warner@LIGO.ORG - 11:21, Monday 24 March 2025 (83529)

This trend shows when the H2 CPS started misbehaving. Top two plots are the 1-3hz log blrms for the RZ GS13s HAM2 is pretty steady, but something happens at ~10:30am pst on the 18th. Bottom plot shows the horizontal CPS during this time, H1 and H3 stay more or less the same, but H2 shows an increase in noise that has persisted until now. 

Images attached to this comment
jim.warner@LIGO.ORG - 14:10, Monday 24 March 2025 (83534)

Got permission from Sheila to try addressing this because locking is not going well. Powered off the CPS racks for ~10 secs and noise was gone when the signals came back up. Will keep monitoring. 

H1 SQZ
jennifer.wright@LIGO.ORG - posted 10:52, Monday 24 March 2025 (83526)
Squeeze angle scan and filter cavity detuning change

Jennie W, Camilla

 

Today during commissioning at 16:29:41 UTC I ran the SCAN_SQZANG_FDS guardian state and it changed the squeeze angle from 170.94 degrees to 163.08 degrees.

Then Camilla and I changed the filter cavity detuning from the nominal value of -32 Hz, measured DARM between 20 to 30 Hz atr each step. This was following this entry by Vicky and Camilla. The lowest value we tried was -44 Hz and the highest was -26 Hz. The optimal seemed to be between -38 Hz and -32 Hz, eventually we chose -36 Hz as it was better 30 and 46 Hz, and among the best between 60 and 70 Hz. Above 70 Hz it is hard to see the difference between traces.

We accepted the new value for H1:IOP-LSC0_RLF_FREQ_OFS in the OBSERVE.snap file in sdf.

Images attached to this report
LHO VE
david.barker@LIGO.ORG - posted 10:46, Monday 24 March 2025 (83525)
Mon CP1 Fill

Mon Mar 24 10:10:42 2025 INFO: Fill completed in 10min 38secs

Gerardo confirmed a good fill curbside, audio only, no line to sight due to tumbleweed.

Images attached to this report
H1 OpsInfo (ISC)
jeffrey.kissel@LIGO.ORG - posted 10:35, Monday 24 March 2025 (83523)
OMC DCPD Electronics Measurement Equipment Left Set Up but Unplugged Slightly -Y of HAM6 ISC Racks
J. Kissel

One step closer to driving an analog signal into the OMC DCPD test chain at ~10 kHz (see other prep aLOG discussion in LHO:83466 and LHO:83468), I set up the SR785, SR785 accessory box, and at the necessary cabling by ISC-R5 rack on the -Y side of the -Y side of HAM6, tucked up against the mini clean room that's there. Other commissioning activities broke the lock just as I was about to plug the setup into the wall and power on. So -- we'll try again Thursday 03/27.
All in-rack cabling is the same as is typically is for all of O4, I hadn't gotten to disconnecting the ISC_444 injection port cable yet.

Was in the LVEA for a mere 6 minutes from 2025-03-24 17:07 UTC to 17:13 UTC.

Attached is a picture of the unplugged and powered off equipment as I left it.
Images attached to this report
H1 CDS
david.barker@LIGO.ORG - posted 10:16, Monday 24 March 2025 - last comment - 14:52, Monday 24 March 2025(83522)
BSC3 sensor glitch caused multiple VACSTAT alarms with new trip levels

This morning at 09:04:42 Mon 24mar2025 we had a BSC3 sensor gitch, which VACSTAT normally logs as a single gauge event and does not send alarms. Today however many LVEA gauges also tripped and alarms were sent to the Vacuum Team.

The reason is that on 13mar2025 we had a lock-loss due to an LVEA vacuum event which was below VACSTAT's nominal trip level. To counter this some LVEA slope trip levels were reduced from 1.0e-10 to 3.0e-12 (https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=83366)

Fast forward to today and the sequence was:

09:04:42 standard BSC3 sensor glitch, num_glitched = 1, all other gauges set to sensitive mode, meaning 3.0e-13 for most LVEA gauges

09:05:03 2nd LVEA sensor glitched on noise while in sensitive mode, num_glitched = 2, Alarms sent to Vacuum Team

09:11:07 3rd LVEA sensor glitched on noise while in sensitive mode

09:12:37 4th LVEA sensor glitched on noise while in sensitive mode

09:18:35 5th LVEA sensor glitched on noise while in sensitive mode

 

Images attached to this report
Comments related to this report
david.barker@LIGO.ORG - 10:42, Monday 24 March 2025 (83524)
david.barker@LIGO.ORG - 14:52, Monday 24 March 2025 (83535)

Vacstat code was changed to permit a sensitivity multiplier to be applied on a gauge-by-gauge basis. The multiplier for those LVEA gauges which have a 3.0e-12 slope trip was set to 1.0 (i.e. no additional sensitivity following a BSC3 trip). The increased sensitivity for the Delta-P trip level was retained.

prod.yaml

---
ifo: H1
glitch_monitor:
  lookback_times: [60, 300, 600]
  proc_period_secs: 10
  vacuum_gauges:
    default:
      glitch_press_rate: [1.0e-10, 1.0e-10, 1.0e-10]
      glitch_delta_press: [1.0e-08, 1.0e-08, 1.0e-08]
      valid_value_min: 1.0e-10
      valid_value_max: 1.0e-04
      sensitivity_press_multiplier: 10.0
      sensitivity_deltap_multiplier: 10.0
    H0:VAC-LY_X0_PT100B_PRESS_TORR:
      description: "Corner Station HAM1"
    H0:VAC-LY_Y1_PT120B_PRESS_TORR:
      description: "Corner Station BSC2"
      glitch_press_rate: [3.0e-12, 3.0e-12, 3.0e-12]
      sensitivity_press_multiplier: 1.0
    H0:VAC-LX_Y8_PT132_MOD2_PRESS_TORR:
      description: "Corner Station BSC3"
    H0:VAC-LX_Y0_PT110_MOD1_PRESS_TORR:
      description: "Corner Station HAM6"
    H0:VAC-LY_Y3_PT114B_PRESS_TORR:
      description: "Corner Station CP1"
      glitch_press_rate: [3.0e-12, 3.0e-12, 3.0e-12]
      sensitivity_press_multiplier: 1.0
    H0:VAC-LX_X3_PT134B_PRESS_TORR:
      description: "Corner Station CP2"
      glitch_press_rate: [3.0e-12, 3.0e-12, 3.0e-12]
      sensitivity_press_multiplier: 1.0
    H0:VAC-LY_Y4_PT124B_PRESS_TORR:
      description: "Corner Station Y-Arm"
      glitch_press_rate: [3.0e-12, 3.0e-12, 3.0e-12]
      sensitivity_press_multiplier: 1.0
    H0:VAC-LX_X4_PT144B_PRESS_TORR:
      description: "Corner Station X-Arm"
      glitch_press_rate: [3.0e-12, 3.0e-12, 3.0e-12]
      sensitivity_press_multiplier: 1.0
    H0:VAC-MY_Y1_PT243B_PRESS_TORR:
      description: "Mid-Y Y1 Beam Tube"
    H0:VAC-MY_Y5_PT246B_PRESS_TORR:
      description: "Mid-Y Y2 Beam Tube"
    H0:VAC-EY_Y6_PT427_MOD1_PRESS_TORR:
      description: "End-Y Y6 BT Ion Pump"
    H0:VAC-EY_Y1_PT423B_PRESS_TORR:
      description: "End-Y Beam Tube"
    H0:VAC-EY_Y3_PT410B_PRESS_TORR:
      description: "End-Y BSC10"
    H0:VAC-MX_X1_PT343B_PRESS_TORR:
      description: "Mid-X X1 Beam Tube"
    H0:VAC-MX_X5_PT346B_PRESS_TORR:
      description: "Mid-X X2 Beam Tube"
    H0:VAC-EX_X6_PT527_MOD1_PRESS_TORR:
      description: "End-X X6 BT Ion Pump"
    H0:VAC-EX_X1_PT523B_PRESS_TORR:
      description: "End-X Beam Tube"
    H0:VAC-EX_X3_PT510B_PRESS_TORR:
      description: "End-X BSC9"
 

H1 PSL
ryan.short@LIGO.ORG - posted 08:11, Monday 24 March 2025 (83520)
PSL 10-Day Trends

FAMIS 31078

There seems to have been a slight temperature increase in the laser, diode, and anterooms of just under 1 degF over the past day which perhaps correlates with some changes in laser performance. The NPRO output power increased while outputs of both amplifiers decreased all by small amounts, with some of their pump diodes both increasing and decreasing in output (see laser trends). This change also perhaps made the signal as read by the PMC_TRANS and FSS TPDs a bit noisier. The cooling trends look unchanged over this time period. PMC_REFL has also slightly risen over the past several days, starting before this temperature change, which I am yet unsure of the cause.

Images attached to this report
LHO General
ryan.short@LIGO.ORG - posted 07:37, Monday 24 March 2025 (83519)
Ops Day Shift Start

TITLE: 03/24 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 151Mpc
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 8mph Gusts, 3mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.27 μm/s
QUICK SUMMARY: Looks like the winds finally died down enough for H1 to lock early this morning and has now been observing for 2 hours. Commissioning time planned to start at 15:30.

H1 General
ibrahim.abouelfettouh@LIGO.ORG - posted 01:20, Monday 24 March 2025 - last comment - 03:17, Monday 24 March 2025(83517)
OPS OWL Shift Summary

IFO is LOCKING and WINDY

I was called when the H1 Notify Guardian reached its 2hr threshold. Lock re-acquisition is taking time understandably due to gusts as high as 50mph (attached pic), and there's nothing that can be done about this until wind speeds decline. Since the wind is forecast to wind down over the next 2/3 hours, I've set guardian to keep trying to lock and reset myself as OWL ops. Hopefully, we can get locked by then.

Images attached to this report
Comments related to this report
ibrahim.abouelfettouh@LIGO.ORG - 03:17, Monday 24 March 2025 (83518)

Call 2: IFO is LOCKING in ENVIRONMENT (WIND)

H1 called again due to wind same reason as before. The wind has decreased but not sufficiently for lock reacquisition. I again just reset the OWL. If I get called a third time, I will stay in IDLE due to WIND.

LHO General
corey.gray@LIGO.ORG - posted 21:59, Sunday 23 March 2025 (83514)
Sun EVE Ops Summary

TITLE: 03/23 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Wind
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY:

W I N D

Most of this shift (and the end of Ryan S' shift were dominated with a wind storm with winds which were in the 30+mph range for going on 9hrs.
LOG:

Images attached to this report
H1 General
corey.gray@LIGO.ORG - posted 19:46, Sunday 23 March 2025 (83516)
H1 Locking Status: Not Locking...because of high winds

At about 7hrs of winds above 30mph (and half the time over 40mph at the Corner along with 50mph gusts).  Attached is winds screenshot.

H1 continues to be in IDLE, and hourly, I have been setting a 1hr timer to assess winds to see if it is worth it to try an Initial Alignment.  Since the forecast show no let-up, also sent Ibrahim (owl shift) a heads up of status.

Images attached to this report
LHO General
corey.gray@LIGO.ORG - posted 18:06, Sunday 23 March 2025 (83515)
Road Access & Wind Fence Status During Current Wind Storm

As of about 530pm Local time on Sunday evening:

Images attached to this report
LHO General
corey.gray@LIGO.ORG - posted 16:46, Sunday 23 March 2025 (83513)
Sun EVE Ops Transition

TITLE: 03/23 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Wind
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 37mph Gusts, 28mph 3min avg
    Primary useism: 0.08 μm/s
    Secondary useism: 0.25 μm/s
QUICK SUMMARY:

H1's in IDLE & been down 3.5+ hrs due to WIND as RyanS has noted---the forecast he showed me looks scary!.  My game plan is to monitor the winds and keep H1 in IDLE until the winds drop down closer to 30mph....but we'll see how it goes. 

(H1 is currently holding at about 44mph winds for almost 5min!!  I was also in the LSB earlier and it was fairly loud with the winds rattling internal doors in their frames!)

LHO General
ryan.short@LIGO.ORG - posted 16:41, Sunday 23 March 2025 (83512)
Ops Day Shift Summary

TITLE: 03/23 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Wind
INCOMING OPERATOR: Corey
SHIFT SUMMARY: Two very different halves of the shift today. H1 was locked all morning until the wind picked up this afternoon causing a lockloss and making H1 impossible to lock. Unfortunately the forecast still doesn't look like the winds will die down anytime soon.

H1 General (Lockloss)
ryan.short@LIGO.ORG - posted 13:13, Sunday 23 March 2025 (83511)
Lockloss @ 19:56 UTC

Lockloss @ 19:56 UTC - link to lockloss tool

Ends lock stretch at just over 15 hours and looks to be caused by the wind. Gusts just recently spiked up to over 35mph and some 10Hz motion can be seen in ETMX and DARM leading up to the lockloss, along with the PRG getting "glitchier" starting several minutes prior.

Unfortunately, the forecast doesn't show gusts calming down completely until almost tomorrow morning, but they should start to lessen late this evening. I'll attempt to relock H1, but may wait in DOWN if unsuccessful until conditions improve.

Images attached to this report
H1 General
ryan.short@LIGO.ORG - posted 12:10, Sunday 23 March 2025 (83510)
Ops Day Mid Shift Report

State of H1: Observing at 148Mpc

Easy morning for H1 quietly observing; now been locked for 14.5 hours.

LHO VE
david.barker@LIGO.ORG - posted 10:10, Sunday 23 March 2025 (83509)
Sun CP1 Fill

Sun Mar 23 10:07:22 2025 INFO: Fill completed in 7min 19secs

 

Images attached to this report
H1 SEI (ISC, SUS, SYS)
jeffrey.kissel@LIGO.ORG - posted 14:32, Thursday 20 March 2025 - last comment - 11:28, Monday 24 March 2025(83470)
Current Performance of H1 ISI BS Projected to the SusPoint of H1 SUS BS
J. Kissel

Oli and I are beginning the process for designing damping loops for the A+ O5 BBSS. We're running through the same process that I've been running through for over a decade designing suspension damping loops, in which I build up a noise budget for the optic displacement in all DOFs using input noises for seismic noise, DAC noise, and OSEM sensor noise filtered through said damping loops, all propagated thru the matlab dynamical model of the suspension.
 
The first step along that journey is revisiting all the input noise sources, and making sure we have good model for those. 
OSEM noise and DAC noise models have recently been validated and updated when I revisited the HLTS damping loop design (see LHO:65687).
However, I haven't worked on damping loops for suspensions suspended from a BSC-ISI since 2013, see G1300537 for the QUAD, G1300561 for the BSFM, and G1300621 for the TMTS.
In those, I used the 2015 update to the 2005 requirement curve from T1500122 as the input motion.
Now, after a decade worth of commissioning and improvements, I figure it's time to show that work here and use it in modeling future SUS damping loops where the SUS is mounted from a BSC-ISI.

One of the biggest things we've learned over the decades is that the seismic noise input to the suspension at its "Suspension Point" motion for a given suspension can be the (quadrature) sum of many of the ISI's cartesian degrees of freedom, and depends on where and in what orientation it is on the optical table (see T1100617). As such, we installed front-end infrastructure to calculate the calibrate the lowest stage sensors -- the GS13 inertial sensors -- into both the Cartesian and Euler basis (see E1600028). In this aLOG, I do as I did for the HAM-ISI LHO:65639, I show the Cartesian contributions to each of the Beam Splitter's SUS point motion, by multiplying the Cartesian channels by the coefficients in the CART2EUL matrix for the beam splitter.

The time I used for this performance of the H1 ISI BS was 0.01 Hz binwidth (128 sec FFT), 10 average, 50% overlap data set starting at 2025-03-19 14:00 UTC.
    - This was a late night local set, with no wind and 0.1 [um_BLRMS] level microseism (between 0.1-0.3 Hz)
    - GND to ST1 Sensor correction is ON, including the DIFF and COMM inputs.
        - Here at H1, the corner station does NOT have beam rotation sensors to improve the GND T240 sensor correction signal. But, both end stations have a BRS.
        - The wind was low at this measurement time, but it's worth saying that each end-stations wind fences are in dis-repair at the moment, too be fixed soon.
    - ST1 Z drive to ST1 RZ T240 decoupling is ON with a "pele_rz" filter
    - Off diagonal ST1 dispalign matrices are in play, 
         X to RX & RY = -1e-4 & 1e-4, 
         Y to RX = -7e-4, 
         Z to RX & RY = 3.5e-3 & 2.5e-3 
    - ST1 Blend Filters:
        - X & Y = nol4cQuite_250
        - Z = 45mHz_cps
        - RX & RY = Quite_250_cps
        - RZ = nol4cQuite_250.
    - As far as I can tell, there's NO ST1 to ST2 sensor correction on the ST2 CPS, nor is there and ST1 to ST2 FF to the ST2 actuators.
    - ST2 Blend Filters:
        - X & Y = 250mhz
        - Z = 250mhz
        - RX & RY = tilt_800b
        - RZ = 250mhz

These will be used to make updates to 
    /ligo/svncommon/SusSVN/sus/trunk/Common/MatlabTools/
        seisBSC.m or 
        seisBSC2.m
which are toy models of the BSC-ISI performance, used so you don't have to carry around some giant .mat file of performance and you can per-interpolate on to an arbitrary frequency vector, much like I did for seisHAM.m in CSWG:11236.

I've committed the .xmls and .pngs in the following SeiSVN directory:
/ligo/svncommon/SeiSVN/seismic/BSC-ISI/H1/BS/Data/Spectra/Isolated/ASD_20250319/

Images attached to this report
Comments related to this report
brian.lantz@LIGO.ORG - 17:01, Thursday 20 March 2025 (83473)

Dear Oli,

It may be useful to remember that when Jeff says that the "input to the suspension at its "Suspension Point" motion for a given suspension can be the (quadrature) sum of many of the ISI's cartesian degrees of freedom" - what he means is that, if you want to make a Statistical model (which you do), and if the DOFs are independant (which maybe they are, and maybe they are not), then using the quadruture sum of the ASDs is a reasonable thing to do. In fact, the SUSpoint in reality, and the calculation of the SUSpoint, are done with a linear combination, NOT a quadrature sum. This means that if you grab some data from the cart basis sensors, take the ASDs (where you lose the phase), and add them in quadrature you will NOT get the ASD of the measured suspoint. I think this difference is not going to impact any of your calculations, but maybe it will help you avoid aggravation if you try to do some double checking.

-Brian

jeffrey.kissel@LIGO.ORG - 10:03, Monday 24 March 2025 (83521)
The Cartesian performance ASDs of the ISI BS to be used in the statistical model (in the way that Brian cautions in LHO:83473 above) have been exported to 
    /ligo/svncommon/SeiSVN/seismic/BSC-ISI/H1/BS/Data/Spectra/Isolated/ASD_20250319/
        2025-03-19_1400UTC_H1SUSBS_CART_XYZRXRYRZ_ASD.txt
(in the DOF order mentioned in the filename.)

In the same directory, I also export the ASD of live, projected, coherent linear sum computed by the front-end
        2025-03-19_1400UTC_H1SUSBS_EUL_LTVRPY_ASD.txt
(in the DOF order mentioned in the filename.)

If someone wants to race me, they can use this data and the CART2EUL matrix from the screenshot in LHO:83470, or if you want it programmatically, use 
    /opt/rtcds/userapps/release/isc/common/projections/
        ISI2SUS_projection_file.mat

and running the following in the matlab command line,
    >> load /opt/rtcds/userapps/release/isc/common/projections/ISI2SUS_projection_file.mat
    >> ISI2SUSprojections.h1.bs.CART2EUL
    ans =
      -0.7071       0.7071      -0.2738            0       0.1572       0.1572
      -0.7071      -0.7071      -0.0173            0      -0.1572       0.1572
            0            0            0            1      -0.2058       0.1814
            0            0            0            0      -0.7071       0.7071
            0            0            0            0      -0.7071      -0.7071
            0            0            1            0            0            0

... but if I win the race, this plot will be a good by-product of the updates to seisBSC.m, which I'll likely post to the CSWG aLOG, like I did for seisHAM.m in CSWG:11236.
jeffrey.kissel@LIGO.ORG - 11:28, Monday 24 March 2025 (83530)
Jim reminds me of the following:
- This BSC-ISI, ISIB2 has been performing poorly since ~2020. For some yet-to-be-identified reason, after years of physical, electronic, and data analysis investigations by Jim -- see IIET:15234 -- his best guess is some sort of mechanical "rubbing," i.e. mechanical interference / shorting of the seismic isolation, typically by cables.
- He points is finger at the H2 corner (use T1000388 to reminder yourself of where that is on BSC2).

- You can use the "Network" summary pages (https://ldas-jobs.ligo.caltech.edu/~detchar/summary/) and navigate to "Today" > "SEI" tab > "Summary [X]" or "Summary [Y]" or "Summary [Z]" pages, and look at the bottom row of plots to see how the ISIBS compares against other ISIs at LHO (left plot) and LLO (right plot). Here's a direct link to the plots including 2025-03-19 at 14:00 UTC, with the with the "SEI Quiet" time restriction mode ON.

- Also, remember that the MICH lock-acquisition drive from the M2 OSEMs on the SUSBS causes back-reaction on the cage, which messes with the ISI controls, the ISIBS's isolation state guardian is regularly in the FULLY_ISOLATED_SO_ST2_BOOST state, which leaves the FM8 "Boost_3" off until after the ISC_LOCK guardian requests SEI_BS to FULLY_ISOLATED. Because I took data during nominal low noise, the ISI was fully isolated. However, the summary pages above -- even in SEI Quiet mode -- don't filter for whether the ISI is in FULLY_ISOLATED, so you'll that the ISIBS is consistently performing worse. *This* is not a fair comparison or show of how the ISIBS performs worse that the other BSC-ISIs, so take the plots with a big grain of salt.

Also, another point of configuration notes:
- This ISI, like all ISIs at LHO have their CPS synchronized to the timing system.
Displaying reports 701-720 of 81821.Go to page Start 32 33 34 35 36 37 38 39 40 End