Displaying reports 2461-2480 of 83266.Go to page Start 120 121 122 123 124 125 126 127 128 End
Reports until 22:09, Wednesday 05 March 2025
H1 General
anthony.sanchez@LIGO.ORG - posted 22:09, Wednesday 05 March 2025 (83205)
Wednesday Eve Shift Sign out report.

TITLE: 03/06 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 150Mpc
INCOMING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 12mph Gusts, 10mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.29 μm/s
SHIFT SUMMARY:
Once LHO H1 was relocked at the very beginning of my shift, it stayed locked for the next 4 hours and 40 minutes.
Everything has been running well.

LOG:
No Log

 

H1 AOS
anthony.sanchez@LIGO.ORG - posted 21:48, Wednesday 05 March 2025 - last comment - 21:49, Wednesday 05 March 2025(83199)
CDS Unifi WAP update notes

https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=83131

The lastest updates for these  UAP-AC-HD  UNIFI WAP can be found here: 
https://ui.com/download/software/uap-ac-hd  

I'm going to update MSR-AP-UNIFI WAP as a test to determine if we wwill run in to issues.
MSR-AP-UNIFI is currently running this version: 
MAC Address    xx:...:c4:04
Model    UAP-AC-HD
Version    5.43.56.12784 

I will be updating to 6.6.77 which is the latest update. 
Update went well, with no Issues.

The Following CDS Unifi WAPS Should also be updated.
CER-UNIFI-AP
EX-UNIFI-AP
EY-UNIFI-AP
FCES-UNIFI-AP
LVEA-UNIFI-AP
MX-UNIFI-AP
MY-UNIFI-AP

Comments related to this report
anthony.sanchez@LIGO.ORG - 21:49, Wednesday 05 March 2025 (83204)

All CDS UNIFI WAPS have been updated without issues.

H1 SUS
oli.patane@LIGO.ORG - posted 18:57, Wednesday 05 March 2025 (83203)
ETMX glitch limiter effect on ETMX L3 MASTER_OUT

Back at the start of February, Jim put a limiter into the ETMX_L3_ESD OSEM filter banks to limit the output, hoping that it would minimize the number of ETMX glitches and subsequently locklosses(82608). To help us figure out if it did anything, I've taken a look at the amplitude distribution of the ETMX glitches that happen during our locks (the ones we don't lose lock during), comparing the amplitude distribution for the glitches we saw with the limiter on versus the ones that happened with it off.

The three time periods I compared are the following (all about 9 days long):

Limiter off:
  • Jan25 14:12UTC - Feb3 16:28UTC
    • ~161 hours locked
    • ~1,000 ETMX glitches seen (6/hour locked)
  • Feb12 22:45UTC - Feb22 01:46UTC
    • ~137 hours locked
    • ~1,000 ETMX glitches seen (7/hour locked)

Limiter on:

  • Feb3 16:28UTC - Feb12 22:45UTC
    • ~152 hours locked
    • ~1,650 ETMX glitches seen (11/hour locked)
 
How I got this data (ignore if you don't care about the convoluted scripts I wrote):
For each stretch of time, I used minute trends of GRD_ISC_LOCK_STATE_N to grab all lock stretches based on whether we were in NLN that entire minute (so excluding the first and last minute of the lock). I then went through the lock stretches while looking at one of the L3 MASTER_OUT channels using second trends and grabbed any time where the min or max went above a reasonably low value, low enough that it would also catch small ETMX glitches. However, this method also catches any other time the OSEM was moving a lot, such as during earthquakes, so I then grabbed the raw data for that channel, and then ran that data plus the two seconds on either side through a high pass filter. This was a method we previously implemented into the lockloss tool to help us find ETMX glitches right before locklosses. Then I looked through the high passed data with scipy's signal.find_peaks and looked for peaks over a certain threshold and at least 25ms apart. Any peaks found were logged into a txt file. In matlab I used the ecdf function to calculate the cumulative distribution and plotted the data from the three stretches of time.
 
Looking at the results:
The plot shows that the two stretches of time where the limiter was off have similar distributions of glitch amplitude probabilities, so that's good to know they line up with each other well. Looking at the data set for when the limiter was on, the distribution differs - there was a higher probability of glitches occurring at all amplitudes as compared to when the limiters were off. This also generally lines up with what we see when we just look at the basic stats for each data stretch - even though all three sets are similar in the amount of hours locked, there were about 50% more ETMX glitches when limiters were on.
 
The limiter was turned back on yesterday (83158), so it'll be interesting to see if we get a similar distribution as before.
Images attached to this report
Non-image files attached to this report
H1 General
anthony.sanchez@LIGO.ORG - posted 17:27, Wednesday 05 March 2025 (83202)
Wednesday Eve Shift Sign in report.

TITLE: 03/06 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 137Mpc
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 13mph Gusts, 10mph 3min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.29 μm/s
QUICK SUMMARY:

Lockloss right at the start of my shift from a small local 3.9M earthquake.
Lockloss page says that it was caused by anthropogenic source but when we lost lock we saw UW's Picket fence ground motion increased and we had an increase in our ground motion on the H1:ISI-GND_STS_ITMY_{X,Y, Z}_BLRMS_{1_3, and 3_10}. BUT we didn't see it on the top of NUC 5. Which is strange.
This lockloss may have been first logged in Ryan C's outro alog.

I started relocking without an Initial_Alignment, H1 requested Find X-Arm by hand. I took X arm to Increase flashes, which worked great! 
PRMI locked on a crazy mushroom shaped mode. I decided to see if it could lock DRIMI like that, and if it was having trouble then i'd just run an Initial Alignment if it failed. But it Actually locked pretty quickly!

Nominal Low Noise reached at 1:23 UTC
Observing Reached at 1:26 UTC

 

H1 General
ryan.crouch@LIGO.ORG - posted 16:30, Wednesday 05 March 2025 (83190)
OPS Wednesday DAY shift summary

TITLE: 03/05 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 152Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY: We lost lock early in the day and struggled to get back up due to ASC issues, we've been locked for ~ 3 hours. Sheila turned off SRC1 & SRC2 in ISC_DRMI.py in ENGAGE_DRMI_ASC to help us lock.
LOG:

Start Time System Name Location Lazer_Haz Task Time End
16:08 FAC Kim Optics lab & Vac prep N Tech clean 16:31
16:11 FAC Nellie H2 N Tech clean 16:32
17:04 ISC Sheila, TJ ISCT1 LOCAL Table checks/adjustments 17:20
17:16 FAC Tyler + contractors VAC prep lab N Heating checks 18:24
17:24 FAC Kim & Nellie MidX N Tech clean 18:24
18:08 FAC Jim, Mitchell Ends n Taking measurements on wind fence 19:29
18:30 FAC Nellie Firepump room N Tech clean 19:20
18:45 VAC Travis, Gerardo EndX MR N Piping, compressor work 19:53
21:41 EE Fil, Marc OSB Recieving N Bring parts from LSB to OSB recieving 21:55
21:55 CAL Tony PCAL lab LOCAL PCAL work 22:06
21:56 EE Fil, Marc MidY N Parts dropoff 22:16

 

Images attached to this report
H1 SUS (SEI)
brian.lantz@LIGO.ORG - posted 16:23, Wednesday 05 March 2025 - last comment - 12:03, Monday 31 March 2025(83200)
cross-coupling and reciprocal plants

I'm looking again at the OSEM estimator we want to try on PR3 - see https://dcc.ligo.org/LIGO-G2402303 for description of that idea.

We want to make a yaw estimator, because that should be the easiest one for which we have a hope of seeing some difference (vertical is probably easier, but you can't measure it). One thing which makes this hard is that the cross coupling from L drive to Y readout is large.

But - a quick comparison (first figure) shows that the L to Y coupling (yellow) does not match the Y to L coupling (purple). If this were a drive from the OSEMs, then this should match. This is actuatually a drive from the ISI, so it is not actually reciprocal - but the ideas are still relevant. For an OSEM drive - we know that mechanical systems are reciprocal, so, to the extent that yellow doesn't match purple, this coupling can not be in the mechanics.

Never-the-less, the similarity of the Length to Length and the Length to Yaw indicates that there is likely a great deal of cross-coupling in the OSEM sensors. We see that the Y response shows a bunch of the L resonances (L to L is the red TF); you drive L, and you see L in the Y signal. This smells of a coupling where the Y sensors see L motion. This is quite plausible if the two L OSEMs on the top mass are not calibrated correctly - because they are very close together, even a small scale-factor error will result in pretty big Y response to L motion.

Next - I did a quick fit (figure 2). I took the Y<-L TF (yellow, measured back in LHO alog 80863) and fit the L<-L TF to it (red), and then subtracted the L<-L component. The fit coefficient which gives the smallest response at the 1.59 Hz peak is about -0.85 rad/meter. 

In figure 3, you can see the result in green, which is generally much better. The big peak at 1.59 Hz is much smaller, and the peak at 0.64 is reduced. There is more from the peak at 0.75 (this is related to pitch. Why should the Yaw osems see Pitch motion? maybe transverse motion of the little flags? I don't know, and it's going to be a headache).

The improved Y<-L (green) and the original L<-Y (purple) still don't match, even though they are much closer than the original yellow/purple pair. Hence there is more which could be gained by someone with more cleverness and time than I have right now.

figure 4 - I've plotted just the Y<-Y and Y<-L improved.

Note - The units are wrong - the drive units are all meters or radians not forces and torques, and we know, because of the d-offset in the mounting of the top wires from the suspoint to the top mass, that a L drive of the ISI has first order L and P forces and torques on the top mass. I still need to calculate how much pitch motion we expect to see in the yaw reponse for the mode at 0.75 Hz.

In the meantime - this argues that the yaw motion of PR3 could be reduced quite a bit with a simple update to the SUS large triple model, I suggest a matrix similar to the CPS align in the ISI. I happen to have the PR3 model open right now because I'm trying to add the OSEM estimator parts to it. Look for an ECR in a day or two...

This is run from the code {SUS_SVN}/HLTS/Common/MatlabTools/plotHLTS_ISI_dtttfs_M1_remove_xcouple'

-Brian

 

Images attached to this report
Comments related to this report
brian.lantz@LIGO.ORG - 11:27, Thursday 06 March 2025 (83209)

ah HA! There is already a SENSALIGN matrix in the model for the M1 OSEMs - this is a great place to implement corrections calculated in the Euler basis. No model changes are needed, thanks Jeff!

brian.lantz@LIGO.ORG - 15:10, Thursday 06 March 2025 (83216)

If this is a gain error in 1 of the L osems, how big is it? - about 15%.


Move the top mass, let osem #1 measure a distance m1, and osem #2 measure m2.

Give osem #2 a gain error, so it's response is really (1+e) of the true distance.
Translate the top mass by d1 with no rotation, and the two signals will be m1= d1 and m2=d1*(1+e)
L is (m1 + m2)/2 = d1/2 + d1*(1+e)/2 = d1*(1+e/2)
The angle will be (m1 - m2)/s where s is the separation between the osems.

I think that s=0.16 meters for top mass of HLTS (from make_sus_hlts_projections.m in the SUS SVN)
Angle measured is (d1 - d1(1+e))/s = -d1 * e /s

The angle/length for a length drive is
-(d1 * e /s)/ ( d1*(1+e/2)) = 1/s * (-e/(1+e/2)) = -0.85 in this measurement
if e is small, then e is approx = 0.85 * s = 0.85 rad/m * 0.16 m = 0.14

so a 14% gain difference between the rt and lf osems will give you about a 0.85 rad/ meter cross coupling. (actually closer to 15% -
0.15/ (1 + 0.075) = 0.1395, but the approx is pretty good.
15% seem like a lot to me, but that's what I'm seeing.

brian.lantz@LIGO.ORG - 09:54, Saturday 22 March 2025 (83489)

I'm adding another plot from the set to show vertical-roll coupling. 

fig 1 - Here, you see that the vertical to roll cross-couping is large. This is consistent with a miscalibrated vertical sensor causing common-mode vertical motion to appear as roll. Spoiler-alert - Edgard just predicted this to be true, and he thinks that sensor T1 is off by about 15%. He also thinks the right sensor is 15% smaller than the left.

-update-

fig 2- I've also added the Vertical-Pitch plot. Here again we see significant response of the vertical motion in the Pitch DOF. We can compare this with what Edgard finds. This will be a smaller difference becasue the the pitch sensors (T2 and T3, I think) are very close together (9 cm total separation, see below).

Here are the spacings as documented i the SUS_SVN/HLTS/Common/MatlabTools/make_sushlts_projections.m

% These distances are defined as magnet-to-magnet, not magnet-to-COM
M1.RollArm = 0.140; % [m]
M1.PitchArm = 0.090; % [m]
M1.YawArm = 0.160; % [m]
Images attached to this comment
edgard.bonilla@LIGO.ORG - 18:10, Monday 24 March 2025 (83539)

I was looking at the M1 ---> M1 transfer functions last week to see if I could do some OSEM gain calibration.

The details of the proposed sensor rejiggling is a bit involved, but the basic idea is that the part of the M1-to-M1 transfer function coming from the mechanical plant should be reciprocal (up to the impedances of the ISI). I tried to symmetrize the measured plant by changing the gains of the OSEMs, then later by including the possibility that the OSEMs might be seeing off-axis motion.

Three figures and three findings below:

0)  Finding 1: The reciprocity only allows us to find the relative calibrations of the OSEMs, so all of the results below are scaled to the units where the scale of the T1 OSEM is 1. If we want absolute calibrations, we will have to use an independent measurement, like the ISI-->M1 transfer functions. This will be important when we analyze the results below.

1) Figure 1:  shows the full 6x6 M1-->M1 transfer function matrix between all of the DOFs in the Euler basis of PR3. The rows represent the output DOF and the columns represent thr input DOF. The dashed lines represent the transpose of the transfer function in question for easier comparison. The transfer matrix is not reciprocal.

2) Finding 2: The diagonal correction (relative to T1) is given by:

            T1         T2          T3          LF          RT         SD
            1            0            0            0            0            0      T1
            0         0.89          0            0            0            0      T2
            0            0         0.84          0            0            0      T3
            0            0            0         0.86          0            0      LF
            0            0            0            0            1            0      RT
            0            0            0            0            0         0.84    SD
 
This shows the 14% difference between RT and LF that Brian saw (leading to L-Y coupling in the ISI-to-M1 transfer functions)
This also shows the 10-16% difference between T2/T3 and T1 that leads to the V-R coupling that  Brian posted in the comment above.
Since we normalized by T1, the most likely explanation for the discrepancies is that T1 and RT are both 14% ish low compared to the other 4 sensors. 
 
3) Figure 2:  shows the 6x6 M1-->M1 transfer function matrix, after applying the scaling factors.
The main difference is in the Length-to-Yaw and the Vertical-to-Roll degrees of freedom, as mentioned before. Note that the rescaling was made only to make the responses more symmetric, the decoupling of the dofs a welcome bonus.
 
4) Finding 3: We can go one step further and allow the sensors to be sensitive to other directions. In this case, the matrix below is mathematically moving the sensors to where the actuators are, in an attempt to collocate them as much as possible.
            T1            T2            T3              LF             RT             SD
                1         0.03         0.03        -0.001       -0.006        0.038      T1
        0.085        0.807        0.042       0.005        0.006        0.006      T2
        0.096        0.077        0.723       0.013        0.002         0.03       T3
       -0.036        0.025        -0.02        0.696        0.012        0.006      LF
       -0.004       -0.018        0.045       0.016        0.809       -0.004     RT
       -0.035        0.026         0.02        0.004       -0.008        0.815      SD
I haven't yet found a good interpretation for these numbers, beyond the idea that they mean the sensors and actuators are not collocated.
Three reasons come to mind:
a) The flags and the magnets are a bit off from each other and we are able to pick it up the difference.
b) The OSEMs are sensing sideways motion of the flag.
c) The actuators are pushing (or torquing) the suspension in other ways than their intended direction.
 
The interesting observation comes when observing Figure 3 .
After we apply this correction to the sensor side of the transfer function, we see a dramatic change in the symmetry and the amplitude of the transfer matrix. Particularly, the Transverse degree of freedom is much less coupled to both Vertical and Longitudinal. Similarly, the Pitch to Vertical also improves a bit.
This is to say, by trying to make the plant more reciprocal, we also end up decoupling the degrees of freedom. We can conclude that there's either miscollocation of the sensor/actuator parts of the OSEM, or, more likely, that the OSEMs are reading side motions of the flag, because we are able to better see the decoupled plant by just assuming this miscalibration.

I will post more analysis in the Euler basis later.

Non-image files attached to this comment
brian.lantz@LIGO.ORG - 15:06, Tuesday 25 March 2025 (83555)

Here's a view of the Plant model for the HLTS - damping off, motion of M1. These are for reference as we look at which cross-coupling should exist. (spoiler - not many)

First plot is the TF from the ISI to the M1 osems.
L is coupled to P, T & R are coupled, but that's all the coupling we have in the HLTS model for ISI -> M1.

Second plot is the TF from the M1 drives to the M1 osems.
L & P are coupled, T & R are coupled, but that's all the coupling we have in the HLTS model for M1 -> M1.

These plots are Magnitude only, and I've fixed the axes.

For the OSEM to OSEM TFs, the level of the TFs in the blank panels is very small - likely numerical issues. The peaks are at the 1e-12 to 1e-14 level.

Images attached to this comment
Non-image files attached to this comment
jeffrey.kissel@LIGO.ORG - 12:03, Monday 31 March 2025 (83662)CSWG, SUS
@Brian, Edgard -- I wonder if some of this ~10-20% mismatch in OSEM calibration is that we approximate the D0901284-v4 sat amp whitening stage with a compensating filter of z:p = (10:0.4) Hz?
(I got on this idea thru modeling the *improvement* to the whitening stage that is already in play at LLO and will be incoming into LHO this summer; E2400330)

If you math out the frequency response from the circuit diagram and component values, the response is defined by 
    %  Vo                         R180
    % ---- = (-1) * --------------------------------
    %  Vi           Z_{in}^{upper} || Z_{in}^{lower}
    %
    %               R181   (1 + s * (R180 + R182) * C_total)
    %      = (-1) * ---- * --------------------------------
    %               R182      (1 + s * (R180) * C_total)
So for the D0901284-v4 values of 
    R180 = 750;
    R182 = 20e3;
    C150 = 10e-6;
    C151 = 10e-6;

    R181 = 20e3;

that creates a frequency response of 
    f.zero = 1/(2*pi*(R180+R182)*C_total) = 0.3835 [Hz]; 
    f.pole = 1/(2*pi*R180*C_total) = 10.6103 [Hz];


I attach a plot that shows the ratio of the this "circuit component value ideal" response to approximate response, and the response ratio hits 7.5% by 10 Hz and ~11% by 100 Hz.

This is, of course for one OSEM channel's signal chain. 

I haven't modeled how this systematic error in compensation would stack up with linear combinations of slight variants of this response given component value precision/accuracy, but ...

... I also am quite confident that no one really wants to go through an measure and fit the zero and pole of every OSEM channel's sat amp frequency response, so maybe you're doing the right thing by "just" measuring it with this technique and compensating for it in the SENSALIGN matrix. Or at least measure one sat amp box's worth, and see how consistent the four channels are and whether they're closer to 0.4:10 Hz or 0.3835:10.6103 Hz.

Anyways -- I thought it might be useful to be aware of the many steps along the way that we've been lazy about the details in calibrating the OSEMs, and this would be one way to "fix it in hardware."
Non-image files attached to this comment
H1 General
ryan.crouch@LIGO.ORG - posted 16:22, Wednesday 05 March 2025 (83201)
00:20 UTC lockloss

00:20 UTC lockloss, LSC_PR_GAIN got noisy ~20 seconds before the lockloss.

H1 SUS (AOS, CDS)
oli.patane@LIGO.ORG - posted 13:40, Wednesday 05 March 2025 - last comment - 13:59, Thursday 06 March 2025(83196)
Addition of PM1 to h1sushtts simulink model

Jeff, Oli

ECR E1700228

More preparation to make way for PM1 - Jeff and I went into the h1sushtts simulink model and added in PM1 and its necessary connections(h1sushtts before). It was basically a copy of the RM1 and RM2 control blocks, with the input ADC channels taking 24 - 27, and channels 8 - 11 on the DAC (h1sushtts after - PM1+output).

We also copied the RMs PCIe inputs, but the channels coming in from the TTL4C on HAM1 are going to be removed for the RMs when the ISI is installed on HAM1 and replaced with the new ISI channels, and so PM1 will never have the HAM1_TTL4C channels. Since we want to be able to compile and test the model before then, I have put in a constant 0 in place of the TTL4C channels for PM1 (h1sushtts after - IPC INP). Once we have the new ISI channels, we can add these connections in using those channels, as well as update the channels for the RMs.

Daniel just added in the new ASC channels for PM1 (83195), so I was able to successfully compile h1sushtts. It has not yet been installed.

The model file can be found in /opt/rtcds/userapps/release/sus/h1/models/, and the changes to h1sushtts.mdl have been committed to the svn as revision 30907.

Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 13:59, Thursday 06 March 2025 (83212)CDS
Just few "slept on it, and remembered we should" things to add:

(1) Attached is the DAQ channel list that comes with the installation of PM1. We didn't cover it explicitly above because it comes standard with the 
    /opt/rtcds/userapps/release/sus/common/models/
        HSSS_FF_MASTER.mdl
library part, but as it is new (small) weight on the DAQ, it's worth calling out. 4x new channels stored at 512 Hz, and 13x at 256 Hz.

(2) Also, the oft-forgotten coil driver output voltage monitor channels, the so-called VMONs needed to be absorbed by the h1susauxh2 front-end too, so we've now done the model prep that as well -- see LHO:83211.
Images attached to this comment
H1 General
ryan.crouch@LIGO.ORG - posted 13:13, Wednesday 05 March 2025 (83198)
OPS Update

21:12 UTC we have recovered Observing after a long struggle with ASC, I had to accept a bunch of OFFSET SDF diffs from the dark offset script earlier.

Images attached to this report
H1 General
jim.warner@LIGO.ORG - posted 12:41, Wednesday 05 March 2025 (83197)
Monthly wind fence inspection FAMIS Request ID:24812

Inspected the wind fences today. The southmost panel at EY continues to degrade, might even save us the work of coming down on its own before the vent, when we plan to replace it. The rest of EY looks fine. EX also seems stable, unsure of when we plan to repair it, but we have replacement panels and are starting to order hardware. First pic is EX, second is EY.

Images attached to this report
H1 AOS
daniel.sigg@LIGO.ORG - posted 12:31, Wednesday 05 March 2025 (83195)
ASC Model Update

Preparing for an upgrade of the ASC model to add PM1 auto-centering. This includes new filter modules PM1_PIT and PM1_YAW, and IPC senders H1:ASC_PM1_PIT_SUSHTTS and H1:ASC_PM1_YAW_SUSHTTS.

For now the old auto-centering driving the MCL PZTs has been left in place.

Buttons for the the new PM1 filter modules were added to the ASC medm screen as well.

H1 SUS (AOS, CDS)
oli.patane@LIGO.ORG - posted 12:21, Wednesday 05 March 2025 (83194)
Simulink Model Prep for PR3 Optical Lever Cable Move

Jeff, Oli

WP 12370

ECR E1700228

In a continuation of preparing for the addition of PM1 (83168), Jeff and I have made the necessary model changes for the PR3 OpLev. As outlined in 83168, the stuff that needed to be changed in the model (to match with the physical changes) was to move the PR3 OpLev channels. They were originally located in the top level of h1susim.mdl and sent via IPC to PR3, but we moved them over to the h1suspr3.mdl model. This means that the outgoing IPC connection from h1susim going into h1suspr3 has been removed(h1susim before, h1susim after), and the PR3 oplev channels have been directly connected from ADC1(h1suspr3 before, h1suspr3 after).

Both models were compiled successfully but  have not yet been installed.

Model files can be found in /opt/rtcds/userapps/release/sus/h1/models/, and changes to h1susim.mdl and h1suspr3.mdl have been committed to the svn as revision 30905.

Images attached to this report
LHO VE
david.barker@LIGO.ORG - posted 11:39, Wednesday 05 March 2025 (83193)
Wed CP1 Fill

Wed Mar 05 10:11:50 2025 INFO: Fill completed in 11min 46secs

Gerardo confirmed a good fill curbside.

Images attached to this report
H1 ISC (OpsInfo)
ryan.short@LIGO.ORG - posted 11:09, Wednesday 05 March 2025 - last comment - 11:22, Wednesday 05 March 2025(83191)
Dark Offsets Updated

After a lockloss while attempting to relock this morning, I ran the dark offset script (/opt/rtcds/userapps/release/isc/h1/scripts/dark_offsets/dark_offsets_exe.py) after taking the IMC offline and shuttering ALS with the hope of fixing some of our ASC troubles.

I've attached a text file of the script output showing what all was changed, as well as screenshots of these being accepted in SDF safe.snap tables (TJ has more that he will add in a comment). These will likely need further accepting once we eventually reach NLN.

Images attached to this report
Non-image files attached to this report
Comments related to this report
thomas.shaffer@LIGO.ORG - 11:22, Wednesday 05 March 2025 (83192)

More SDF shots.

Images attached to this comment
H1 PEM
ryan.crouch@LIGO.ORG - posted 09:26, Wednesday 05 March 2025 (83189)
Dust monitor trend monthly - FAMIS

Closes FAMIS 37250, the first of this new task. All of the dust monitors look to be working as expected and are seeing counts, aside from LAB2 which is known.

Images attached to this report
H1 General
ryan.crouch@LIGO.ORG - posted 07:32, Wednesday 05 March 2025 - last comment - 08:50, Wednesday 05 March 2025(83185)
OPS Wednesday DAY shift start

TITLE: 03/05 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 119Mpc
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 5mph Gusts, 3mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.31 μm/s
QUICK SUMMARY:

Comments related to this report
ryan.crouch@LIGO.ORG - 08:22, Wednesday 05 March 2025 (83187)CDS

H1 Glitches (Omicron) plot isn't updating

ryan.crouch@LIGO.ORG - 08:50, Wednesday 05 March 2025 (83188)GRD

In some more camera fallout we found ISC_LOCK sets CAM18s exposure during PREP and CLOSE_BD (H1:VID-CAM18_EXP) which does not exist anymore, ISC_LOCK turned "blood red" for a few seconds complaining it couldn't connect then just it moved on and went back to normal?

Those 2 lines have since been edited and loaded.

Displaying reports 2461-2480 of 83266.Go to page Start 120 121 122 123 124 125 126 127 128 End