Displaying reports 81-100 of 83003.Go to page 1 2 3 4 5 6 7 8 9 10 End
Reports until 16:46, Thursday 26 June 2025
H1 CDS
david.barker@LIGO.ORG - posted 16:46, Thursday 26 June 2025 - last comment - 07:30, Friday 27 June 2025(85373)
HWS camera control code running, EPICS monitoring via MEDM

WP12637 Install HWS Camera Controls

TJ, Camilla, Dave:

I made a slight change to my original Dec 2023 hws_camera_control.py code to use the python epics module to do the cagets directly, and to also use this to add caputs which will try, in a non-blocking way, to send the camera's status to a central EPICS IOC.

The central IOC code is hws_camera_status_ioc.py which runs on cdsioc1 under puppet control.

The camera control code runs every minute in an infinite loop. Each loop it checks the status of H1 using Guardian ISC_LOCK (greater or equal to 600 denotes H1 LOCK). If H1 is locked and the camera is on, it turns the camera off. If H1 is not locked and the camera is off, it turns the camera on.

A mini-overview of the 4 HWS cameras (ITMX, ITMY, ETMX, ETMY) is available on the CDS Overview screen. The block is divided into 4 segments, each camera is shown either in SKYBLUE (camera is enabled, images are being taken) or GREEN (camera is disabled, no noise being created).

Note that the color scheme relates to what is nominal for OBSERVE. Green indicates the cameras have power, but their frame acquisition has been disabled.

Clicking on the HWS block on the CDS Overview opens a detailed screen (see attachment). For each camera this shows if the camera is powered (ETMY is the only one powered down) and if the camera is enabled. The control code also reports its current time, its uptime, its start time and details of where and how it is running.

Second attachment shows the four tmux sessions running the control code, and the arguments used.

Images attached to this report
Comments related to this report
david.barker@LIGO.ORG - 07:30, Friday 27 June 2025 (85384)

Here is the same view when H1 is locked and the cameras have been disabled.

Images attached to this comment
H1 SUS
jeffrey.kissel@LIGO.ORG - posted 16:08, Thursday 26 June 2025 (85368)
Results from applying ECR E2400330 to UK SatAmp S1100173 -- looks good!
J. Kissel, F. Clara
ECR E2400330

Fil modified the UK SatAmp (D0900900 / D0901284) per ECR E2400330, which means "rev'ing" up the D0901284 circuit board inside from -v4 to -v5 (thanks Michael Laxen for the updated drawing!). 

This mod changes the whitening stage frequency response by adjusting the (R180, R181, R182) values from (750,20e3,20e3) to (1.5e3,80.6e3,80.6e3) Ohm, causing the zero:pole pair to move from z:p = (0.384 : 10.6) Hz to z:p = (0.0969 : 5.31) Hz.

I then measured the frequency response with the nearly*** identical procedure as described in LHO:85349. 

The measured results agree with the expected model of z:p = (0.0969 : 5.31) Hz (and a ~7 kHz high-frequency pole) to within +/-1.5% and +/-1.0 [deg], as was the case for the measured results when this same board was at -v4.

I think we're good to go for rev'ing up many of these satamps, and can have excellent confidence in compensating every channel of every satamp with a z:p = (5.31 : 0.0969) Hz digital filter.

***The only difference is that I needed to drop the source voltage from 0.3 V_SRC to 0.2 V_SRC in order to prevent the differential output stage opamps from saturating. Note -- the saturated response was only ~7% different from expectation and only above the frequency-dependent output of the whitening stage exceeded the ~14V that the differential output opamps can push; I got clued in to this subtlety and have a quantitative answer because the ratio between saturated model and measurement sharply kinked up at 6.39 Hz, and rose up to 7% -- consistent across all four channels -- in a non-linear way that couldn't be explained by adding more zeros and poles. #ThreeHoursWasted

Images attached to this report
Non-image files attached to this report
LHO General
ibrahim.abouelfettouh@LIGO.ORG - posted 16:03, Thursday 26 June 2025 (85370)
OPS Eve Shift Start

TITLE: 06/26 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 20mph Gusts, 8mph 3min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.05 μm/s
QUICK SUMMARY:

IFO is LOCKING at ACQUIRE_DRMI_1F

Planning on going straight to observing once locked.

Lockloss during comissioning (not from calibration)

H1 General (Lockloss)
oli.patane@LIGO.ORG - posted 15:32, Thursday 26 June 2025 (85365)
Lockloss

Lockloss at 2025-06-26 22:29 UTC after almost 7 hours

H1 ISC
elenna.capote@LIGO.ORG - posted 15:07, Thursday 26 June 2025 (85363)
Adjusted POP9 phase in full lock, semi-thermalized

Sheila, Elenna

I adjusted the POP9 phase to see if it would improve the coherence of LSC REFL RIN with DARM. In the past, this has been an indication of poor POP9 phasing causing some offset in PRCL.

I tried checking the phase in two ways. First, I engaged the 88 Hz notches in LSC and injected an 88 Hz PRCL line. This result indicated that the POP9 phasing was actually pretty good, in that the signal appeared in I and not Q. The dotted lines in this attachment show this measurement.

Next, I tried a different method, injecting a frequency noise line at 700 Hz. That method showed that there was some signal in Q. I was able to reduce the signal in Q by adjusting the demod phase. The attachment shows the start in dotted blue and red lines, and the end result in solid lines. Overall, this was 2.9 degree change, so not significant.

After that adjustment, I remeasured with the 88 Hz PRCL line and saw a very small difference, shown in the solid lines.

After all that, I am not sure I see a difference in the REFL RIN coherence. Nonetheless, this does seem slightly better, so I SDFed in safe and observe.

I realized after we went to observing that I forgot to unplug the frequency excitation cable. Sorry!

Images attached to this report
H1 CAL
oli.patane@LIGO.ORG - posted 14:50, Thursday 26 June 2025 - last comment - 16:47, Thursday 26 June 2025(85364)
Calibration Measurement June 26, 2025

Calibration suite was run after 5 hours of thermalization. Before the measurement was run, work had been done to update the SRCL offset (85362).

Broadband
Start: 2025-06-26 20:35:38 UTC
End: 2025-06-26 20:40:49 UTC
Data: /ligo/groups/cal/H1/measurements/PCALY2DARM_BB/PCALY2DARM_BB_20250626T203538Z.xml

Simulines
Start: 2025-06-26 20:42:09 UTC
End: 2025-06-26 21:05:29 UTC
Data: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20250626T204210Z.hdf5
          /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20250626T204210Z.hdf5
          /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20250626T204210Z.hdf5
          /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20250626T204210Z.hdf5
          /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20250626T204210Z.hdf5

Current version of the pydarm report can be found at /ligo/groups/cal/H1/reports/20250626T204210Z_prospring/H1_calibration_report_20250626T204210Z.pdf. We are investigating further into why the calibration is so different now.

 

Images attached to this report
Non-image files attached to this report
Comments related to this report
francisco.llamas@LIGO.ORG - 16:47, Thursday 26 June 2025 (85371)

After inspection on the sensing function from the initially generated report, we changed the model to an anti-spring and to start the fit at 8 Hz, to see if we could get a better calibration from this measurement.

First, we set the is_pro_spring parameter in the H1_pydarm.ini file from True to False. We expected this parameter make the model (orange line) fit better to the measurement (green dots). Overall, there was no noticeable change of the sensing model compared to the initial report, as seen in the first figure (CAL_SENSING_MODEL_ANTISPRING_20250626.png). Additionally, the sensing MCMC corner plots were not gaussian (opposite to what is instructed in T2400215 section 2.4.2), as seen in the second figure (CAL_SENSING_MCMC_CORNER_ANTISPRING_20250626.png).

To improve on the sensing model, we decreased the sensing parameter mcmc_fmin from 10 to 8 Hz. Even though the sensing function is slightly worse at low frequencies compared to the initial report (the one from oli's alog), the sensing corner plot shows more of a gaussian behavior. Additionally, the uncertainty is still within our 10% budget (see snippet of the calibration monitor from grafana CAL_MONITOR_GRAFANA_POST_CALMEAS_20250626.png), so we will pause on this investigation for now.

The updated report is attached as a PDF file. The measurement has not been tagged at the time of posting this comment. We have yet to understand why the model is struggling with the fit parameters.

Images attached to this comment
Non-image files attached to this comment
H1 ISC (SQZ)
sheila.dwyer@LIGO.ORG - posted 13:39, Thursday 26 June 2025 - last comment - 15:47, Thursday 26 June 2025(85362)
updating SRCL offset

measured NLG with seed of 14.15, had to adjust temperature

Fitting to SRCL detuning guesses for these last two points would suggest we should update our SRCL offset to -382 counts (was previously -455).  We will do this now, as we are about to run a calibration measurement. 

While we were at 0 SRCL offset, Elenna looked at the impact of SRM alignment, she will alog this.  It does seem to have an impact of FIS, which is small compared to the impact of the SRC length offset. 

Images attached to this report
Comments related to this report
elenna.capote@LIGO.ORG - 15:47, Thursday 26 June 2025 (85367)

I wrote a summary of the SRM alignment moves here: 85366

H1 SQZ
sheila.dwyer@LIGO.ORG - posted 12:09, Thursday 26 June 2025 (85358)
checking on squeezer alignment

scan alignment using anti-squeeze: results final alignment sliders and sqz angle screenshot

scan alignment using squeezing: results final sliders screenshot

The biggest difference between these alignments is 30urad of ZM6 yaw, and almost 4 degrees of squeezing angle.  We've seen before that the demod phase we need to get the best squeezing angle depends on the ZM alignment, although we think this shouldn't be the case since we are using OMC trans RF3 to control the squeezing angle to reduce the impact of higher order modes on the squeezing angle.

The spectrum comparison shows slightly flatter squeezing after we ran the alignment using squeezing than anti-squeezing.  I've left it this way for now. 

After this Elenna and I looked at the SQZ to IFO ASC. We found that AS42 B was sensitive to ZM4 for both pitch and yaw, while AS42 A was sensitive to ZM6.  We set offsets in AS42 PIT and YAW filter banks to close the loops around the location that the SCAN_ALINGMENT guardian gave us, this worked with the settings shown in the two attachments.

I've set the SQZ ASC flag to true, we can see if this works during thermalization next time we relock.

Images attached to this report
LHO VE
david.barker@LIGO.ORG - posted 10:30, Thursday 26 June 2025 (85359)
Thu CP1 Fill

Thu Jun 26 10:13:36 2025 INFO: Fill completed in 13min 32secs

 

Images attached to this report
H1 General (Lockloss)
oli.patane@LIGO.ORG - posted 07:45, Thursday 26 June 2025 - last comment - 08:47, Thursday 26 June 2025(85356)
Lockloss

Lockloss at 2025-06-26 14:38 UTC after 7.5 hours locked due to an ETMX glitch

Images attached to this report
Comments related to this report
oli.patane@LIGO.ORG - 08:47, Thursday 26 June 2025 (85357)

15:40 UTC Back to Nominal Low Noise

H1 General
oli.patane@LIGO.ORG - posted 07:31, Thursday 26 June 2025 (85355)
Ops Day Shift Start

TITLE: 06/26 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 149Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 5mph Gusts, 2mph 3min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.05 μm/s
QUICK SUMMARY:

Observing at 150Mpc and have been Locked for 7.5 hours. Commissioning again today from 15:00 - 21:00 UTC.

H1 General
anthony.sanchez@LIGO.ORG - posted 22:29, Wednesday 25 June 2025 (85354)
Ops EVE Shift End

TITLE: 06/26 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: TJ
SHIFT SUMMARY:
H1 was locked and Observing until ~3:52 UTC when an unknown Lockloss happened.  

Relocking notes:
I let H1 do everything on it's own, It relocked it's self eventually after going through PRMI and making it up to START_TR_CARM and Locklossing all the way back to DOWN.
But I just let it be and it Relocked it self on the next attempt and we made it back to NLN at 5:04 UTC. Observing at 5:07 UTC.

Dropped to Comissioning due to the SQZ-man needing to adjust it's self at 5:19 UTC, then got back to OBSERVING at 5:22 UTC with no intervention.

LOG:
No Log

 

H1 ISC
anthony.sanchez@LIGO.ORG - posted 22:16, Wednesday 25 June 2025 - last comment - 11:38, Thursday 26 June 2025(85352)
Histogram of Time spent in ACQUIRE_DRMI_1F

Using a script called histogram.py which calls statecounter2.0, I was able to determine how many times ISC_LOCK spent more than 60 seconds in ACQUIRE_DRMI_1F using Minute trends.

I broke this up into Pre Vent and Post vent:
Pre Vent:
Jan1st to April 1st 2025
Length of data 601
max Duration 19 Min
Average 3.5640



Post Vent:
June 1st 2025 to now
170 data points
Longest:  24 minutes.
Average: 5.1823 Min



Post vent break down.... break down:

Jun 1st to Jun 16th
Length of data 100
max Duration:  24min
Average 5.04 min


Jun 16th - now
Length of data 70
max Duration 13 Min
Average 5.38571

 

Link to a google sheet with all the exported data, and GPS times.

Images attached to this report
Comments related to this report
jenne.driggers@LIGO.ORG - 11:38, Thursday 26 June 2025 (85360)

I copied Tony's awesome spreadsheet, and replotted the data sets while thinking about what they mean. 

I have the same 4 data sets that Tony has (Jan-April, All of June, and then broken into Early June and Late June, with the divider being the time that I enabled the 'slow let go' of the BS pitch control).  However, I've got all the x-axes fixed to be 0-25 minutes.  I've also set the y-axes to be (0, number lock segments), so that they are roughly normalized.  In the subtitle of the plot I note the percentage of the segments who are 10 mins or longer (actually, from the data set, the percent that have a value of 9 mins or greater).  Since we have a 10 minute timer in the guardian that will flip over to trying PRMI or MICH locking, this percentage should help capture the number of locks that take a long time to acquire DRMI.

Notably, the number of segments that take a long time is about 2x larger after the BS slow let go was enabled, if we look at the percent in late June (48% take a long time) versus the percent in early June (28% take a long time) :(  But, both of these are much higher than the 18% that took a long time before the vent.  

This may mean that the slow letting go of the BS, as currently enabled, is not helpful. 

If the statecounter.py code is able to, it could be interesting to get similar statistics, but have the durations start when we leave state 18 (Arms_off_resonance) and the duration end when we get to state 102 (DRMI_locked_check_ASC).  That would enable us to more accurately see the total length of time it takes during an acquisition sequence.  If we do this, we'd want to count and then exclude from the statistics the number of times we 'give up' and lose lock or do an initial alignment.

Images attached to this comment
H1 General (Lockloss)
anthony.sanchez@LIGO.ORG - posted 21:07, Wednesday 25 June 2025 (85353)
Unknown Lockloss

Unknown Lockloss @ 3:52 UTC

 

Images attached to this report
H1 ISC
elenna.capote@LIGO.ORG - posted 13:02, Wednesday 25 June 2025 - last comment - 15:46, Thursday 26 June 2025(85330)
SRM alignment on POP vs AS72

Today I was able to drive a line on SRM pitch and yaw, aka SRC1 P and Y, in an attempt to understand how the SRM alignment signal appears in various sensors. Our current configuration has SRM alignment controlled via the AS RF72 signal, which is the beat of the 118 MHz and the 45 MHz.

To do this measurement, I engaged the usual 8.125 Hz notches in the ASC loops, and drove at 8.125 Hz at the SRC1 SM exc point. I measured the signals in the I and Q phase on AS RF72, AS RF45, AS RF36 and POP X RF, which is a 45 MHz demod.

First, it is very hard to drive a large enough signal to even see the line in AS RF72 compared to other sensors. We are currently operating with 1 stage of whitening on RF72, for reference. The attachment shows how the signals appeared in the AS WFS as well as the POP WFS for pitch and yaw.

Once I took this measurement, I looked at the time series of the signals. POPX 45 Q pitch has an offset that corresponds to 1.5 urad of SRM pitch offset. I calculated this calibration factor from my injection: 7.37e-5 SRM pitch urad/POPX pit ct. The POPX Q yaw signal also had an offset, but it was much smaller, only 0.24 urad, calibration factor 3.25e-4  SRM yaw urad/ POPX yaw ct

On June 5, the SQZ team adjusted the SRCL digital offset, and when the SRCL digital offset was zero, the POPX Q offsets corresponded to about 0.09 urad of SRM pitch offset and 0.05 urad of SRM yaw offset (sqz alog).

In the past, we have operated with some SRC1 offset, however, that offset is remarkably small compared to even the dark offsets we have applied to the AS RF72 channels. SRC1 p offset was set to -0.042, SRC1 Y to 0.098, while the four segment dark offsets on RF72 Q are -17.8, 0.2, 2.2, 12.9 (medm screenshot).

Overall, I think we should consider a few things:

Sheila has suggested we open the SRC1 loop and try stepping the offset while monitoring the buildups, the effect of the SRCL offset on SQZ, and the overall offsets in AS RF72 and POPX Q.

Whatever effect alignment offsets in the SRC are having on the SRCL detuning seems to be much smaller in yaw than in pitch.

To calibrate the AS RF72 signals into SRM angle, we can use these factors:

0.274 SRM pit urad/ AS RF72 pit ct

0.173 SRM yaw urad/ AS RF72 yaw ct

Images attached to this report
Comments related to this report
elenna.capote@LIGO.ORG - 15:46, Thursday 26 June 2025 (85366)

Today, Sheila and I followed up on this, and the results are a bit confusing, but somewhat promising.

To start, Sheila reran the "brontosaurus plot" measurement, where FIS is injected to help determine the SRCL offset. She reports this work here.

While she changed the SRCL offset, I once again monitored the AS RF72 and POP X signals. As Sheila changed the SRCL offset, the offset in POPX did change the same way as I saw yesterday, which is not that surprising.

Then, when Sheila set the SRCL offset to zero, I tried opening the SRC1 loop and moving SRM around. The first thing I noticed is that the calibration I calculated yesterday seems bad, since I was adjusting the SRM yaw by 11 urad (according to the slider calibration), but the change in the POP X yaw offset corresponded to less than 1 urad (according to my measured calibration from yesterday).

I moved yaw in only one direction, with the goal of seeing if I could reduce the POP X yaw offset. However, I gave up after 11 urad because it didn't seem to be doing much at all except to small effect on POP X yaw.

Next, I tried moving SRM in pitch. I went the positive direction, and Sheila and I immediately saw the buildups get worse, so then I went the other way and the buildups got better! This corresponded to a 20 urad change in SRM pitch, according to the alignment slider. The change in the POP X pitch offset was minimal.

We also saw kappa C increase quite a bit, almost too good to be true, so we didn't trust the value since we had a large SRCL detuning at the time. Sheila did see that the change in the SRM pitch had an effect on the squeezing as well.

However, Sheila then determined a better SRCL offset of -382, so we went there, and the kappa C leveled off to 1.02, which was better than our current nominal value of 1. This seemed to hold. Then, I stepped the SRM pitch offset back to the starting alignment and the buildups decreased and kappa C went back to 1.

Following the buildups, there seems to be a better alignment of the SRM in pitch. At this time it seems like yaw has no effect, but I only moved in one direction. I think that, whatever the SRCL offset is, we should move the SRM around in pitch and yaw and see if there is an improvement to be found in the buildups. My current hypothesis is that the RF72 dark offsets are creating some alignment offset in the SRC. After we find a good SRM alignment position, we can recheck the SRCL offset, hopefully with both a squeezing measurement and a sensing function.

We should also probably check the whitening on RF72, maybe next Tuesday.

These results are making me think that probably POP X Q would not make a good signal for SRC alignment, since it is dominated by the SRCL offset.

The first ndscope attached are showing the behavior of the POP X and RF72 signals while changing SRM alignment. The second shows the buildups and kappa C when changing SRM pitch and SRCL offset from 0 to -382.

Images attached to this comment
H1 TCS (DetChar-Request)
camilla.compton@LIGO.ORG - posted 13:20, Monday 23 June 2025 - last comment - 11:58, Thursday 26 June 2025(85247)
2Hz Comb in DARM from ITMX HWS Camera?

Ansel, Sheila, Camilla

Last week, Ansel noticed that there is a 2Hz comb in DARM since the break, similar to that that we've seen from the HWS camera sync frequency and power supplies and fixed in 75876.  The cabling has not been changed since, the camera sync frequency has been changed.

Our current camera sync frequencies are: ITMX = 2Hz, ITMY = 10Hz. We have typically seen these combs in H1:PEM-CS_MAG_LVEA_OUTPUTOPTICS_Y_DQ. With a 0.0005Hz BW on DTT I can't easily see these combs, see attached.

Images attached to this report
Comments related to this report
evan.goetz@LIGO.ORG - 13:31, Monday 23 June 2025 (85254)DetChar
It may be difficult to see in a standard spectrum, but can be clearly seen in Fscan plots linked off of the summary pages. For the "observing" Fscan, the interactive spectrum plot shows the 2 Hz comb marked automatically. See the attached image of H1:GDS-CALIB_STRAIN_CLEAN
Images attached to this comment
camilla.compton@LIGO.ORG - 17:04, Tuesday 24 June 2025 (85306)

Verifed that the cabling has not changed since 75876.

Next steps we should follow, as listed in 75876 would be to try using a different power supply or lowering the voltage to +12V. Or, there is a note suggesting Fil could make a new cable to power both the camera and CLink's via the external supply (14V is fine for both). 

evan.goetz@LIGO.ORG - 18:30, Tuesday 24 June 2025 (85312)DetChar
Thanks Camilla. If anything can be done more rapidly than waiting another week, it would be very much appreciated. Continuing to collect contaminated data is bad for CW searches.
camilla.compton@LIGO.ORG - 15:11, Wednesday 25 June 2025 (85341)

Matt and I turned down the Voltage supplied from 14V to 12V for each camera at ~22:00UTC when the IFO was relocking. Verified HWS cameras and code still running.

We also will plan to have Dave reimpliemnt the hws_camera_control.py script he wrote in 74951 to turn the HWS's off in Observing until we fix this issue.

kiet.pham@LIGO.ORG - 11:58, Thursday 26 June 2025 (85361)

The 2 Hz comb is still present in H1:GDS-CALIB_STRAIN_CLEAN after the voltage change (before the software update)

Images attached to this comment
H1 ISC
elenna.capote@LIGO.ORG - posted 13:18, Monday 23 June 2025 - last comment - 16:29, Thursday 26 June 2025(85250)
Noise Budget injection inventory

I have been running opportunistic noise budget injections:

So far there seems to be no noise contribution from DC6 P and PRC2 P and Y. CHARD noise contributions are also down significantly with the ISI in place.

 

Comments related to this report
elenna.capote@LIGO.ORG - 16:48, Wednesday 25 June 2025 (85347)

I ran SRCL and MICH injections today as a part of determining if the feedforward is performing well, but I repurposed those injection times in the noise budget templates so now SRCL and MICH are complete as well.

elenna.capote@LIGO.ORG - 16:29, Thursday 26 June 2025 (85372)

After running some PRCL injections to test the feedforward I was also able to update the PRCL noise budget template.

I also reran the jitter noise coupling measurement, since it seemed like the coupling was overestimated at low frequency. The jitter noise had been run very early on in vent recovery, so I am not sure what changed to affect the low frequency coupling (could be the pumps, LSC feedforward, ASC, etc) but now the low frequency coupling is very reduced.

Displaying reports 81-100 of 83003.Go to page 1 2 3 4 5 6 7 8 9 10 End