Displaying reports 2561-2580 of 77281.Go to page Start 125 126 127 128 129 130 131 132 133 End
Reports until 16:02, Thursday 04 April 2024
LHO General
corey.gray@LIGO.ORG - posted 16:02, Thursday 04 April 2024 (76948)
Thurs DAY Ops Summary

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

H1's been locked for the last 15+hrs and most of today was used for commissioning time and RyanC took us back to Observing at 2300 (:42).  :)

LOG:

H1 General
ryan.crouch@LIGO.ORG - posted 16:00, Thursday 04 April 2024 - last comment - 18:29, Thursday 04 April 2024(76963)
OPS Thursday EVE shift start

TITLE: 04/04 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 11mph Gusts, 8mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.28 μm/s
QUICK SUMMARY:

Comments related to this report
ryan.crouch@LIGO.ORG - 16:01, Thursday 04 April 2024 (76964)

Back into Observing at 23:00 UTC

ryan.crouch@LIGO.ORG - 17:21, Thursday 04 April 2024 (76970)SQZ

SQZ_PMC is giving notifications of "PMC PZT volts low", the node returns this notification if the SQZ-PMC_VOLTS channel is less than 5. Its decayed from 80 to where it is currently, hovering around 5 over the past day.

Images attached to this comment
ryan.crouch@LIGO.ORG - 18:01, Thursday 04 April 2024 (76971)CDS

SQZ unlocked dropping us out of observing at 00:58UTC, I also took the moment to reload SEI_ENV which caused it to lose FAIL/lose connection? I'm going to call Dave

ryan.crouch@LIGO.ORG - 18:29, Thursday 04 April 2024 (76972)CDS, SEI

Dave and I reverted the most recent code changes from Jim and I restarted the node with "guardctrl restart SEI_ENV", the codes changes included some states becoming unrequestable and a few other small changes, none of which made any sense for the "Index error" that the LOG had. Verbal alarms is now constantly throwing a TypeError for SEI_ENV "NoneType is not iterable". I went back into Observing at 01:14 after the SQZer relocked itself and then the MANAGER prompted me to "Return to FDS" so I requested us back to FDS

Images attached to this comment
H1 SQZ
naoki.aritomi@LIGO.ORG - posted 15:59, Thursday 04 April 2024 - last comment - 18:56, Tuesday 09 April 2024(76949)
PSAMS coarse scan trial (2)

Naoki, Eric, Camilla

We continued the PSAMS coarse scan in 76925. Yesterday, IFO was not thermalized, but today IFO is thermalized at least for 7 hours. It seems our nominal 140/90 (strain voltage 7.22/-0.71) would be close to optimal. The detail analysis will follow.

This time, after we moved PSAMS, we compensated the alignment change caused by the PSAMS change by looking at OSEM. This works well for ZM4, but not for ZM5 and we need to touch ZM5 in addition to the compensation. This might be related to the beam miscentering in ZM5 as reported in 75770.

no sqz (10 min)

PDT: 2024-04-04 08:06:30 PDT
UTC: 2024-04-04 15:06:30 UTC
GPS: 1396278408

asqz 200/115 (strain voltage 9.59/-0.702) (5 min)

PDT: 2024-04-04 08:41:34 PDT
UTC: 2024-04-04 15:41:34 UTC
GPS: 1396280512

sqz 200/115 (5 min)

PDT: 2024-04-04 08:49:14 PDT
UTC: 2024-04-04 15:49:14 UTC
GPS: 1396280972

asqz 200/200 (strain voltage: 9.59/2.67) (5 min)

PDT: 2024-04-04 09:28:12 PDT
UTC: 2024-04-04 16:28:12 UTC
GPS: 1396283310

sqz 200/200 (5 min)

PDT: 2024-04-04 09:36:04 PDT
UTC: 2024-04-04 16:36:04 UTC
GPS: 1396283782

asqz 100/200 (strain voltage 6.83/2.72) (5 min)

PDT: 2024-04-04 09:55:09 PDT
UTC: 2024-04-04 16:55:09 UTC
GPS: 1396284927

sqz 100/200 (5 min)

PDT: 2024-04-04 10:02:23 PDT
UTC: 2024-04-04 17:02:23 UTC
GPS: 1396285361

asqz 0/200 (strain voltage 2.2/2.72) (5 min)

PDT: 2024-04-04 10:27:25 PDT
UTC: 2024-04-04 17:27:25 UTC
GPS: 1396286863

sqz 0/200 (5 min)

PDT: 2024-04-04 10:35:27 PDT
UTC: 2024-04-04 17:35:27 UTC
GPS: 1396287345

asqz 140/90 (strain voltage 7.22/-0.71) (5 min)

PDT: 2024-04-04 11:04:22 PDT
UTC: 2024-04-04 18:04:22 UTC
GPS: 1396289080

sqz 140/90 (5 min)

PDT: 2024-04-04 11:12:41 PDT
UTC: 2024-04-04 18:12:41 UTC
GPS: 1396289579

asqz 170/90 (strain voltage 8.80/-0.70) (5 min)

PDT: 2024-04-04 11:55:59 PDT
UTC: 2024-04-04 18:55:59 UTC
GPS: 1396292177

sqz 170/90 (5 min)

PDT: 2024-04-04 12:03:26 PDT
UTC: 2024-04-04 19:03:26 UTC
GPS: 1396292624

asqz 75/90 (strain voltage 5.77/-0.71) (5 min)

PDT: 2024-04-04 12:24:44 PDT
UTC: 2024-04-04 19:24:44 UTC
GPS: 1396293902

sqz 75/90 (5 min)

PDT: 2024-04-04 12:31:39 PDT
UTC: 2024-04-04 19:31:39 UTC
GPS: 1396294317

asqz 130/125 (strain voltage 7.21/0.26) (5 min)

PDT: 2024-04-04 14:58:24 PDT
UTC: 2024-04-04 21:58:24 UTC
GPS: 1396303122

sqz 130/125 (5 min)

PDT: 2024-04-04 15:06:03 PDT
UTC: 2024-04-04 22:06:03 UTC
GPS: 1396303581

asqz 130/83 (strain voltage 7.22/-1.2) (5 min)

PDT: 2024-04-04 15:39:41 PDT
UTC: 2024-04-04 22:39:41 UTC
GPS: 1396305599

sqz 130/83 (5 min)

PDT: 2024-04-04 15:46:36 PDT
UTC: 2024-04-04 22:46:36 UTC
GPS: 1396306014

Comments related to this report
eric.oelker@LIGO.ORG - 16:31, Thursday 04 April 2024 (76960)
Attached are the averaged squeezing and anti-squeezing DARM spectra for each PSAM value we've measured so far.  Based on the course scan, we see that our initial PSAM values (strain voltages of 7.22/-0.71 for ZM4/ZM5) appear to be roughly optimal, giving roughly -5.2 dB of squeezing and 15.6 dB antisqueezing at 2 kHz.  So far we've noticed that any significant movement of the PSAM setting for ZM5 seems to de-optimize things and we are relatively insensitive to changes in ZM4 when ZM5 is held fixed at its initial value.    

Values from yesterday afternoon are also included.
Images attached to this comment
naoki.aritomi@LIGO.ORG - 15:52, Tuesday 09 April 2024 (77065)

On April 9th, we took one more PSAMS data. This PSAMS setting might be better than the nominal 170/95 (strain voltage 8.8/-0.66) as reported in 77074. We may come back to this setting later.

asqz 125/136 (strain voltage 7.5/0.5) (5 min)

PDT: 2024-04-09 15:36:49 PDT
UTC: 2024-04-09 22:36:49 UTC
GPS: 1396737427

sqz 125/136 (5 min)

PDT: 2024-04-09 15:43:59 PDT
UTC: 2024-04-09 22:43:59 UTC
GPS: 1396737857

victoriaa.xu@LIGO.ORG - 18:56, Tuesday 09 April 2024 (77073)

Subtracted SQZ dB's for the various PSAMS settings last week: course trial #1: 76925, and course trial #2: 76949, and the previous optimzations in LHO:76507, which used SQZ ASC to hold alignments when moving PSAMS before ZM alignment scripts 76757.

I sorted the PSAMS tests by positive and negative ZM5 strain gauge voltages.

Some takeaways: hard to interpret what's happening. Could be interesting to try ZM5 strains around 0 - 0.5 V, and scan with e.g. ~0.1 V steps. I wonder if reviving the psams scanning scripts, and doing fine optimizations, would be productive at this point. I'm not sure if there's a tension between good squeezing at 1 kHz vs. 100 Hz. But some settings that give the most kHz squeezing (negative ZM5 strain) don't necessarily show the best 100 Hz squeezing (positive ZM5 strain), and vice-versa. It may just be that the optimal point is narrow, and we're taking big steps?

  • For best SQZ at 1 kHz - we seem to more reliably see this with ZM5 strains between (-0.7 , 0.5) V across a large range of ZM4 settings, even when settings are varied on the same day/lock.
  • For best SQZ at 200 Hz - a bit hard to say, but possibly ZM5 > 0 (positive) gives better 200 Hz SQZ.  
    • Several negative ZM5 traces suggest freq-dep losses below the DARM pole.
    • For positive ZM5 traces, very hard to tell. SQZ looks lossier for ZM5 > 2V.  

Attachment 1 - positive ZM5 strain - potentially more SQZ at 100 Hz, and less sqz at 1 kHz?

  • Some of these traces have flatter SQZ, but this is hard to disentangle from just loss, since many positive ZM5 settings have both less SQZ and less ASQZ.
    • Like as an example, if SQZ-OMC mode-matching was very bad for those settings, squeezing would just look lossier across the whole band, which might cause it look flatter too.
    • But I think the blue (7.2, 0.3) trace is an interesting counter-example: we could infer that there's less generated squeezing (b/c anti-sqz is lower), but the decrease in anti-sqz is not due to loss b/c squeezing is the same.
    • Comparing the blue 4/4 to the pink 3/17 is also interesting - PSAMS settings are very similar, and shape of SQZ is very similar (blue / pink nearly parallel). But, anti-sqz (= NLG + loss) is less on 4/4 than on 3/17, while sqz (~ loss) is basically the same. This could suggest less generated squeezing on 4/4 than 3/17.
  • Higher ZM5 settings far above 1V are not obviously good. In this range, both asqz+sqz look worse.

Attachment 2 - negative ZM5 strain - more kHz SQZ, but kinda looks lossier below the DARM pole at e.g. 100 Hz.

  • Mostly, ZM5 strain is at -0.7V, and ZM4 is varying. 
  • This looks consistent with the FD-SQZ data set on 20 March LHO:76540, which used PSAMS at ZM4/ZM5 = 150 / 90 (8.46V, -1.26 V).
    • Fitting a common sqz model to that 3/20 data suggested there were freq-dep losses below the DARM pole at those settings (plot). There's also evidence for the freq-dep losses at 100 Hz in this 4/4 data.

 

Linking LHO:75749 with the in-chamber beam profiles at various PSAMS settings, as we continue working to reconcile the models and measurements.

Images attached to this comment
H1 AOS
sheila.dwyer@LIGO.ORG - posted 15:47, Thursday 04 April 2024 - last comment - 16:18, Thursday 04 April 2024(76961)
moving input pointing and BS camera set point

Jennie W, Sheila, Gabriele remotely

Summary:  With the ISS second loop open, we were able to move the IMs without loosing lock.  We realized that the BS camera set point is not ideal for power recycling gain, and that is the reason that the IM moves seemed to improve build ups.  After reseting the camera servo set point, we were able to increase power on the ISS array and IM4 by moving IM1 yaw in the opposite direction from past moves ( 76534 and 76607 ). 

Details:

We moved IM1 and 3 with the ISS second loop open (take IMC_LOCK to LOCKED), this allowed us to move the input pointing without loosing lock. 

We believe that the improvements in build ups seen in 76534 and 76607 were due to the spot on the ITMs/BS moving. When Jennie moved the IMs in the same direction as these earlier attempts, the build ups increased in both arms and LSC POP, but once the CAM1 YAW servo converged the build ups where back to where they started (screenshot).  The IM move also decreased the power on the ISS second loop array (in and out of loop sums) and IM4 trans QPD dropped, indicating that this move may have been the wrong direction to reduce any clipping in HAM2.  We then moved the CAM1 YAW set point to where the error signal was at the maximum build up time, and this restored the build ups.  

Jennie moved the IMs back to their starting place, which restored the power on IM4 trans and the ISS array, then we walked the CAM1 YAW offset (BS camera feeds back to PRM) to maximize the POP and arm powers, we found that an offset of -236 counts seemed best.   This is consistent with what Jennie and Camilla found with the stepper scripts in 76770.  In 76695, Camilla looked at how the camera offsets change from lock to lock, when they are set after ADS converges. This gave us a roughly 0.5% more power in the arms. We want to change the guardian to use this set point in every lock, and retune the ITMs A2L gain for this new set point, but we haven't done that today.

Next Jennie moved IM1 yaw in the positive direction, which increased the power on IM4 trans and ISS second loop array PDs screenshot and here.  While she was doing this the sqz team was injecting anti-sqz, but when they were done we had a quick quite time for a DARM comparison, it appears that we might have made the noise worse.  We wll double check as we revert this move after the squeezers are finished.

Images attached to this report
Comments related to this report
jennifer.wright@LIGO.ORG - 16:06, Thursday 04 April 2024 (76965)

We relooked at CAL-DELTAL both with the IM1 move up in yaw still in and with the yaw reverted and the noise was still worse. We may have to optimise A2L gains for the ITMs to work with this camera offset change.

jennifer.wright@LIGO.ORG - 16:18, Thursday 04 April 2024 (76966)

I also measured the jitter coupling with the camera setpoint changed - interleaved between squeezing measurements.

The templates are saved in /ligo/home/jennifer.wright/Documents/Noise_DARM for yaw and pitch.

I will compare these to our previous jitter couplings.

The reference changes are without injecting and the live traces are with an injection into the IMC_PZT pitch or yaw.

Images attached to this comment
H1 SQZ
camilla.compton@LIGO.ORG - posted 14:26, Thursday 04 April 2024 (76962)
1.3kHz SQZ ADF Turned Off

We stopped using the SQZ_ANG_ADJUST in  76742 so no longer need the SQZ 1300Hz ADF line to be on in observing. We're turned it off and accepted in sdf. H1:SQZ-RLF_INTEGRATION_ADFEN

H1 ISC
camilla.compton@LIGO.ORG - posted 13:19, Thursday 04 April 2024 - last comment - 16:38, Thursday 04 April 2024(76958)
New Improved MICH FF on at 19:45UTC

Turned on new MICH FF at 19:45UTC, details and plot in 76956. Updated safe and observe sdf's and ISC_LOCK.

Took SRCL measurements 19:50-20:05UTC.

Comments related to this report
camilla.compton@LIGO.ORG - 16:38, Thursday 04 April 2024 (76967)

Gabriele's last bruco of SRCL from 76927 shows coherence in 15-60Hz range and some 100-200Hz. I'm struggling to fit a better SRCLFF in this 100-200Hz region but have a slightly different filter that's improved 15-60Hz, see attached. This is saved into FM1 (not loaded as in Observing).

Images attached to this comment
H1 AOS
louis.dartez@LIGO.ORG - posted 13:06, Thursday 04 April 2024 - last comment - 13:31, Thursday 04 April 2024(76955)
darm comparison
Gabriele suggested that we rerun Sheila's DARM comparison scripts (76768) to look at time from last night. I used the instructions that Sheila wrote in LHO:76768.

The two times I used are from Gabriele's DARM comparison (listed below), however I just used 600s segments instead of the full 3600s. Also, these plots compare DELTAL_EXTERNAL since we were having nds issues on-site and couldn't fetch GDS-CALIB_STRAIN for a few hours.

O4a GPS 1389058533
ER16 (last night) GPS 1396241443

Attachments:

comparison.png: DARM comparison shared by Gabriele in Mattermost showing that we are almost back down to the O4a level of noise near 100Hz.

compare_darm_spectra.pdf: DARM spectra comparison showing that we're currently pretty much right at late O4a noise levels above 70Hz. Our noise is better from about 18Hz to about 33Hz but our noise floor is higher now 50-70Hz.


compare_darm_range_integrand.pdf: BNS range integrand comparison

compare_cumulative_range.pdf: comparison of the cumulative range at both GPS times. BNS range is matched between the two times below about 18Hz and right at 150Hz (by eye). If I'm interpreting this plot correctly, we're doing better than late O4a now between 20 & 70Hz but slightly worse everywhere else. After talking to Sheila about how to interpret this plot: we are doing better from 20Hz to around 35Hz, then losing range 35Hz to ~70Hz. The improvements are likely from the new DARM offloading but those improvements are being negatively affected by other low frequency noise we're still trying to figure out.
Images attached to this report
Non-image files attached to this report
Comments related to this report
louis.dartez@LIGO.ORG - 13:31, Thursday 04 April 2024 (76959)
Here are the same comparisons but using 3600s of data and comparing GDS-CALIB_STRAIN_CLEAN.


Using a longer integration and the GDS-CALIB_STRAIN_CLEAN channel these comparisons indicate that our range is higher now than it was in January by about 0.2Mpc due to the new low frequency range improvements from the new offloading being dragged down by other low frequency noise. 
Non-image files attached to this comment
LHO General
corey.gray@LIGO.ORG - posted 13:01, Thursday 04 April 2024 (76957)
Mid-ish Shift Summary

H1 has been out of Observing most of the morning for mostly Squeezer measurements; will return to Observing at 4pm local time (or sooner).

H1 ISC (CAL, DAQ, DetChar)
jennifer.wright@LIGO.ORG - posted 11:33, Thursday 04 April 2024 - last comment - 16:34, Thursday 04 April 2024(76953)
Pushed Updated Cleaning

Jennie, Jenne, Sheila

 

I pushed Jenne's updated cleaning but cannot check if this is better or worse until our problems getting data from nds2 are fixed.

I ran the following:

cd /ligo/gitcommon/NoiseCleaning_O4/Frontend_NonSENS/lho-online-cleaning/Jitter/CoeffFilesToWriteToEPICS/

python3 Jitter_writeEPICS.py

I accepted these DIFFS in OAF model in OBSERVE.snap but we might have to revert them before finish of the commissioning period today if we find out the cleaning is worse.

GPS 139627823 - 16 mins quiet time from last night.

11:12:41 UTC - 11:18:38 UTC quiet time just before cleaning implemented.

11:19:55 UTC new cleaning drops.

11:31:30 UTC end of quiet time.

Images attached to this report
Comments related to this report
jennifer.wright@LIGO.ORG - 16:34, Thursday 04 April 2024 (76968)

I took the following jitter comparison measurements

Old Cleaning quiet time: 11:19:55 UTC 0404/2024 light blue

New cleaning quiet time: 13:50:05 UTC 04/04/2024 red

 

Its hard to tell if new cleaning is better and I have reverted the coefficients in OBSERVE.snap to what they were this morning.

 

Images attached to this comment
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 ISC
gabriele.vajente@LIGO.ORG - posted 07:51, Wednesday 27 March 2024 - last comment - 12:47, Thursday 04 April 2024(76736)
Lock losses while moving input beam

All three times we tried to move the input beam (76534, 76607 and yesterday), we caused a lock loss when moving in the yaw direction.

Approximate lock loss times: 1394946678 1395096385 1395535842

All lock losses appear to show the same behavior:

Those lock losses are indeed very fast, and this seems to point to a CARM problem.

Images attached to this report
Comments related to this report
gabriele.vajente@LIGO.ORG - 15:12, Friday 29 March 2024 (76799)

Some smart person suggested t check the ISS loops as the cause of those lock loss. It looks like this is the culprit: the ISS second lop is the first one to go crazy before each of those three lock losses. The error and control signals both go away from their trend value when we see the first jump in IMC transmitted power.

So maybe the ISS second is very marginal now.

Images attached to this comment
sheila.dwyer@LIGO.ORG - 12:47, Thursday 04 April 2024 (76954)

Agreed, here are some more plots, it looks like we are probably saturating the AOM when we unclip the beam going into the second loop ISS array. 

Also, it is interesting that looking at these times the out of loop PD power seems to increase as we move the input pointing (shown in the last plot, but similar for all three of these).

Edit:  Keita suggested looking at indivdual PDs on the ISS, indeed the indivdual PDs are moving in different directions. 

Images attached to this comment
Displaying reports 2561-2580 of 77281.Go to page Start 125 126 127 128 129 130 131 132 133 End