Displaying reports 6961-6980 of 83403.Go to page Start 345 346 347 348 349 350 351 352 353 End
Reports until 11:21, Saturday 29 June 2024
H1 SQZ
andrei.danilin@LIGO.ORG - posted 11:21, Saturday 29 June 2024 - last comment - 11:21, Saturday 29 June 2024(78726)
Transfer Function from the FC control signal counts to displacement in μm

Andrei, Naoki, Sheila

For the upcoming measurement of the FC backscattering, we need to calibrate the length change of the FC. To do this, we calculated the transfer function from the GS_SL FC control signal [Hz] to FC2 displacement [μm]. We followed the steps in Diagram.png to get to result. The plot bode_all_datasets.png contains all the used datasets.

The resulting transfer function is presented here: Tranfer_func.png (where Result curve is the transfer function). The result was exported to frequency/magnitude/phase dataset and can be found in result_data.txt. The remaining .txt files contain all the used datasets for this calculation.

Assuming that the frequency of the FC resonance shift Δf equal to c/2L corresponds to the FC length change ΔL equal to λ/2. (λ = 532 nm, L = 300 m), then Δf/ΔL = c/(L * λ) = 1.88*1012  [Hz/m] = 1.88*106  [Hz/μm]. Multiplying Transfer function by this coefficient will get us the open loop unity gain frequency of 39.4 Hz. Open-loop gain plot (after multiplication) can be found in the following figure: openloop_gain.png.

Images attached to this report
Non-image files attached to this report
Comments related to this report
naoki.aritomi@LIGO.ORG - 13:17, Friday 28 June 2024 (78728)

For FC2 suspension plant, we used sus_um in H1:CAL-CS_SUM_PRCL_PRM filter bank. The sus_um is the PRM suspension plant in the unit of um/count. Although the FC2 and PRM are the same HSTS suspensions, FC2/PRM M2 and M3 actuation strength is different by 0.326/2.83 according to the suspensions control design summary table on the door of control room as shown in the attachment (TACQ for FC2, TACQ*** for PRM). So we added this factor for FC2 M3 path.

Images attached to this comment
LHO General
ryan.short@LIGO.ORG - posted 16:00, Friday 28 June 2024 (78731)
Ops Eve Shift Start

TITLE: 06/28 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Observing at 152Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 8mph Gusts, 5mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.06 μm/s
QUICK SUMMARY: H1 has been locked and observing for over 4 hours.

H1 OpsInfo
thomas.shaffer@LIGO.ORG - posted 15:08, Friday 28 June 2024 (78729)
Temporarily unmonitored some SDF settings for ITM L3 BIAS

For Robert's tests of changing the ITM L3 bias, I unmonitored a few things to allow him to make changes while we are in observing as approved. These will need to be remonitored at the end of teh weekend. I made the changes while in observing, which didn't knock us out of observing, but I failed to notice that the offset switch was monitored and when Robert changed it we did go out of Observing. Good to know that we can unmonitor channels while in observing.

Unmonitored:

H1:SUS-{ITMX, ITMY}_L3_LOCK_BIAS_{GAIN, TRAMP, OFFSET}

H1:SUS-{ITMX, ITMY}_L3_LOCK_INBIAS

Images attached to this report
LHO VE
david.barker@LIGO.ORG - posted 10:20, Friday 28 June 2024 (78725)
Fri CP1 Fill

Fri Jun 28 10:09:37 2024 INFO: Fill completed in 9min 33secs

Jordan confirmed a good fill curbside.

Images attached to this report
H1 CDS
david.barker@LIGO.ORG - posted 10:19, Friday 28 June 2024 (78724)
Heads up, it is GPS leap seconds time of the year again

While restarting an IOC on cdsioc0 this morning I ran into the IETF GPS leap seconds missing web page issue (reported a year ago in alog71075)

   RuntimeError: Error loading leap file: https://www.ietf.org/timezones/data/leap-seconds.list

The local leapsconds file is managed by the tzdata package, after upgrading this on cdsioc0 the problem was resolved. I checked the leapsecond files are correct on workstations and h1guardian1, it looks like cdsioc0 slipped through.

H1 General
thomas.shaffer@LIGO.ORG - posted 10:08, Friday 28 June 2024 (78723)
Lock loss 1656 UTC

A rather short lock, no immediate cause. This lock loss (1403628990) did NOT see the DARM wiggle that we have been seeing frequently, but rather it looks like all of the quads start to move before DARM.

Images attached to this report
H1 General
thomas.shaffer@LIGO.ORG - posted 09:02, Friday 28 June 2024 (78721)
Observing 1601UTC

After a night of earthquakes, we are back to Observing. Fully auto from me after I requested an initial alignment.

LHO General
thomas.shaffer@LIGO.ORG - posted 07:34, Friday 28 June 2024 (78718)
Ops Day Shift Start

TITLE: 06/28 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Earthquake
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 2mph Gusts, 1mph 5min avg
    Primary useism: 0.05 μm/s
    Secondary useism: 0.06 μm/s
QUICK SUMMARY: Ground just getting calm after the 5.7 Tonga earthquake, which followed a 7.0 from Peru. I'll start initial alingment now.

H1 General (SEI)
anthony.sanchez@LIGO.ORG - posted 01:08, Friday 28 June 2024 (78717)
Thursday Eve Shift End

TITLE: 06/28 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Earthquake
INCOMING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: EARTHQUAKE
    Wind: 13mph Gusts, 10mph 5min avg
    Primary useism: 0.46 μm/s
    Secondary useism: 0.06 μm/s
SHIFT SUMMARY:
H1 was locked for 6 + hours before a 7.2 Mag eathquake unlocked the IFO.
When the 7.2 Mag quake hit the ITMY ISI's tripped.  I was able to simply untrip them with out any issue.
Ive been sitting in Idle for a while and it seems like the IFO needs more time to allow the shaking to stop.

ISC_Lock is currently in Initial_alignment.

LOG:

 

H1 SEI (PEM, SEI)
anthony.sanchez@LIGO.ORG - posted 22:54, Thursday 27 June 2024 (78716)
Incoming 7.0 Mag from Peru

TITLE: 06/28 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Earthquake
CURRENT ENVIRONMENT:
    SEI_ENV state: EARTHQUAKE
    Wind: 23mph Gusts, 18mph 5min avg
    Primary useism: 0.95 μm/s
    Secondary useism: 0.48 μm/s
QUICK SUMMARY:

Incoming Earthquake 7.0 mag from Peru.
Lockloss at 5:48 UTC ended the 6 hour 45 minute lock we had.
Holding in ISC_Lock in IDLE  for a while.

Images attached to this report
H1 SQZ (SQZ)
karmeng.kwan@LIGO.ORG - posted 22:29, Thursday 27 June 2024 (78715)
SHG1 Sinc Mt. Stuart Curve

Repeat the same measurement (as 78686) on SHG1, all the phase matching curve was measured in cavity.

The measurement was done twice, the mode matching was 85% for the first measurement and 93% for the second measurement. The alignment optimization does not affect the curve.

Next: remove one of the cavity mirror and measure the phase matching curve in single pass setup.

 

 

Images attached to this report
H1 General
oli.patane@LIGO.ORG - posted 16:31, Thursday 27 June 2024 (78713)
Ops Day Shift End

TITLE: 06/27 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 150Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Currently Observing and have been Locked for 21 minutes. Lots of issues with ALSX PLL today (78703), as a continuation/extension of the problems we have been having with ALSX the past few days. After troubleshooting and multiple hours down after the 17:08 lockloss, we seemed to be clear of the PLL unlocking issue after I noticed that the PLL had managed to stay locked for 25 minutes, and then relocking went just like normal.
LOG:

14:30 Detector Observing at 155Mpc and has been Locked for almost 5 hours

15:32 Out of Observing for calibration measurements (78699) and commissioning
    15:39 bb done
    16:01 Simulines done
16:03 Lockloss right at beginning of commissioning
16:04 Started an initial alignment
    - had to touch up ALSY because increase flashes couldn't catch it
16:41 Initial alignment done, going to sit in DOWN for commissioning test
17:08 Starting relocking
    - Lockloss from LOCKING_ARMS_GREEN x2
    - earthquake starts rolling through
    - Lockloss from ACQUIRE_PRMI
    - Held in GREEN_ARMS_MANUAL to check for issues with ALSX PLL
    - Lockloss from FIND_IR x3
18:06 I started another initial alignment, skipping over green GREEN_ARMS_MANUAL
18:19 Initial alignment done, relocking
    - CHECK_CRYSTAL_FREQUENCY for ALSX
    - lockloss from LOCKING_ALS
    - CHECK_CRYSTAL_FREQUENCY for ALSX
    - Lockloss from FIND_IR x 2
- Sitting in GREEN_ARMS_MANUAL due to ALSX PLL unable to stay locked, even when ALSX is in the UNLOCKED state 

20:03 Trying relocking after I saw that the last PLL error was from 25 minutes ago
    - Everything worked perfectly
20:45 NOMINAL_LOW_NOISE
20:48 Observing

21:45 Lockloss
21:48 Initial alignment
22:09 IA done, relocking
23:01 NOMINAL_LOW_NOISE
23:04 Observing                                                                                                                                                                                                                                                                                                                                                               

Start Time System Name Location Lazer_Haz Task Time End
14:55 PCAL Rick PCAL Lab y(local) Grab stuff for LLO 15:07
15:41 FAC Karen WS/FirePump n Tech clean 17:03
15:42 SAF Camilla, Iain LVEA n Transitioning to laser hazard 15:56
16:08 SAF LVEA LVEA YES LVEA IS LASER HAZARD 10:08
16:46 PEM Robert LVEA YES Viewport scattering commissioning 20:24
16:54 ISC Jenni CR n Commissioning test 17:52
16:58 SQZ Kar Meng Optics Lab y(local) Working on SHG 19:11
17:03 FAC Karen VacPrep n Tech clean 17:13
17:58 PCAL Francisco, Rick PCAL Lab y(local) Lab upgrades 21:00
18:11 FIT Jenni, Camilla, Isaiah MY n Running really slow 18:51
21:12 SQZ Kar Meng, Terry Optics Lab y(local) SHG (Terry out 21:28) ongoing
21:16 SAF Richard, Fil XARM n Looking for exposed ALS cable 21:00
21:16 EE Fil MY n Dropping off parts 21:50
21:51 PCAL Francisco PCAL Lab y(local) Upgrading lab 22:30
21:57 VAC Janos CER n Putting things away 22:27
H1 General
anthony.sanchez@LIGO.ORG - posted 16:31, Thursday 27 June 2024 (78714)
Thursday Eve Shift start

TITLE: 06/27 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Observing at 149Mpc
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 11mph Gusts, 8mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.07 μm/s
QUICK SUMMARY:

H1 is currently observing and every thing seems to be functioning as expected.
 

X1 SUS (SUS)
rahul.kumar@LIGO.ORG - posted 15:37, Thursday 27 June 2024 (78711)
Comparison of transfer function measurements of five fully assembled A+ HRTS (Freestanding version).

RyanC, Oli, Rahul

As reported before (LHO alog 78574 and 76635) we have assembled and characterized in total five A+ HRTS Freestanding version for O5. In this alog I am posting a comparison plot of all five suspensions (assembly S/N 03, 08, 01, 02, 11 ) for their transfer function measurements, please find them attached below (the second file is the zoomed-in version of the first. Looking at their resonant peaks, shapes and magnitude, I think all five suspensions are very much on top of each other. These results also ties up very well with the model (blue trace). The Y_dof for suspension assembly SN 11 (green trace - see page 6) has slightly higher magnitude above 3Hz. I am still investigation what could be the reason for that.

Non-image files attached to this report
H1 General (Lockloss)
oli.patane@LIGO.ORG - posted 14:49, Thursday 27 June 2024 - last comment - 16:06, Thursday 27 June 2024(78709)
Lockloss

Lockloss 06/27 @ 21:45UTC

Comments related to this report
oli.patane@LIGO.ORG - 14:54, Thursday 27 June 2024 (78710)
Images attached to this comment
oli.patane@LIGO.ORG - 16:06, Thursday 27 June 2024 (78712)

23:04 Observing

H1 ISC
sheila.dwyer@LIGO.ORG - posted 12:08, Thursday 27 June 2024 - last comment - 08:46, Friday 28 June 2024(78703)
ALS PLL not staying locked

Oli, Sheila, Jim, Camilla

We've been having trouble keeping the ALS X arm locked, so Oli put the request for the X arm guardian to "UNLOCKED" which means that it asks the PLL to lock and nothing else.  We've been sitting here for 15 minutes and see that the PLL can't stay locked in this configuration where the ground motion doesn't matter and the laser should easily stay locked.

The second two attachments show how much the fiber beatnote depends on outdoor temperature, it is now varying by more than 20dBm, while last summer with similar temperature swings it would only vary by 4dBm.  This year the problem seems to be coming and going, for about a week at a time the temperature dependence seems to go away. 

We won't be able to lock the IFO while the PLL is not staying locked like this, this problem seems to be coming and going recently, so it may explain a lot of IFO downtime.

Images attached to this report
Comments related to this report
oli.patane@LIGO.ORG - 13:52, Thursday 27 June 2024 (78705)

At 20:03 I noticed that the PLL hadn't unlocked in 25 minutes, so I tried relocking the ifo and was able to get through to where we stop using ALS

20:45 UTC NOMINAL_LOW_NOISE

20:48 UTC Observing

oli.patane@LIGO.ORG - 14:49, Thursday 27 June 2024 (78708)
sheila.dwyer@LIGO.ORG - 08:46, Friday 28 June 2024 (78719)

TJ, Sheila

We looked at the PLL logic.  When we are in observing, the PLL is requested to be locked.  We see times when the logic stops trying to lock it, with H1:ALS-X_FIBR_LOCK_ERROR_CODE = 262144 = 2^18. 

Looking at the attached medm screen, counting the error codes starting with 0, the 18th one is beatnote strength.  This checks out because the beatnote momentarily dipped below -10dBm at this time, and the limit is -10dBm.  TJ looked and the Y arm limit is -20dBm, so TJ changed the X arm limit to match and accepted that in SDF. 

There is still an issue with the fiber beatnote having this strong temperature dependence that needs investigation, but this will stop it from preventing locking when it is on the edge for now.

Images attached to this comment
H1 ISC
jennifer.wright@LIGO.ORG - posted 10:25, Thursday 27 June 2024 - last comment - 13:06, Friday 28 June 2024(78701)
OMC with hot OM2

Jennie W, Sheila

We want to do an OMC scan after unlocked today so we can estimate the mode-matching into the OMC with a hot OM2.

 

Set SRM, ITMX and ETMs to mis-aligned, IMC locked in guardian.

Ran DC centering loops 3 and 4 to centre on AS_A and AS_B QPDs, then ran OMC ASC to align into OMC_A and OMC_B QPDs. Waited for this to converge spots in centre of QPDs with current nominal QPD offsets.

Made sure that OMC guardian was paused then moved PZT2 slider to bottom of its range on ther OMC_Control screen and ran scan with template:

Did scan but sidebands are still on so can't do visibility measurement easily.

Ref 12-14 are today's scan measurements saved in /ligo/home/jennifer.wright/Documents/OMC_scan/2024_06_27_OMC_scan.xml.

Analysis ongoing.

Images attached to this report
Comments related to this report
jennifer.wright@LIGO.ORG - 13:06, Friday 28 June 2024 (78727)

See attached the spectra with identified peaks, corrected for the non-linearity of the PZT.

See also the fit to the double peak of the carrier 02 mode (can't distinguish the two peaks with the current OMC but a double peak fit still seems to work better than a single peak).

From the fitted height of the C02 and C20 we can estimate the mode-matching.

(0.11086 + 0.11086)/(0.11086 + 0.11086 + 3.13)

gives us 6.62 % mode-mismatch.

The fitted background light level when no modes are on the PDs was 9.13 e-3 mA (not quite the dark offset as labelled in the pdf) as light could still be scattering onto the DCPDs when the OMC is off-resonance.

The fitted halfwidth at half-maximum power is 0.330 MHz and the transverse mode spacing between horizontal and vertical is at most 0.195 MHz.

According to the design document (see table 20 of LIGO-T1500060-v1), this current OMC (001) has a half-width of 0.327 MHz and a transverse mode spacing between horizontal and vertical modes of 0.109 MHz.

This is consistent with the attached fit.

Analysis code is in OMCscan_nosidebands14.py and fit_two_peaks_no_sidebands14.py in /gitcommon/labutils/omc_scan/figures/2024-06-06 on the /dev branch (ie. it will not be on the workstation branch as this is the master branch).

Non-image files attached to this comment
H1 ISC
sheila.dwyer@LIGO.ORG - posted 21:56, Tuesday 25 June 2024 - last comment - 09:48, Thursday 11 July 2024(78652)
OM2 impact on low frequency sensitivity and optical gain

The first attachment shows spectra (GDS CALIB STRAIN clean, so with calibration corrections and jitter cleaning updated and SRCL FF retuned) with OM2 hot vs cold this week, without squeezing injected.  The shot noise is slightly worse with OM2 hot, while the noise from 20-50Hz does seem slightly better with OM2 hot.  This is not as large of a low frequency improvement as was seen in December.  The next attachment shows the same no squeezing times, but with coherences between PRCL and SRCL and CAL DELTAL.  MICH is not plotted since it's coherence was low in both cases.  This suggests that some of the low frequency noise with OM2 cold could be due to PRCL coherence. 

The optical gain is 0.3% worse with OM2 hot than it was cold (3rd attachment), before the OMC swap we saw a 2% decrease in optical gain when heating OM2 in Decmeber 74916 and last July 71087.  This seems to suggest that there has been a change in the OMC mode matching situation since last time we did this test. 

The last attachment shows our sensitivity (GDS CALIB STRAIN CLEAN) with squeezing injected.  The worse range with OM2 hot can largely be attributed to worse squeezing, the time shown here was right after the PSAMs change this morning 78636 which seems to have improved the range to roughly 155Mpc with cleaning; it's possible that more psams tuning would improve the squeezing further. 

Times used for these comparisons (from Camilla):

Images attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 11:43, Friday 28 June 2024 (78722)

Side point about some confusion caused by a glitch:

The first attachment shows something that caused me some confusion, I'm sharing what the confusion was in case this comes up again.  It is a spectrum of the hot no sqz time listed above, comparing the spectrum produced by dtt with 50 averages, 50% overlap, and BW 0.1 Hz (which requires 4 minutes at 15 seconds of data), compared to a spectrum produced by the noise budget code at the same time. The noise budget uses a default resolution of 0.1Hz and 50% overlap, and the number of averages is set by the duration of data we give it which is most often 10 minutes.  The second screenshot shows that there was a glitch 4 minutes and 40 seconds into this data stretch, so that the spectrum produced by the noise budget shows elevated noise compared to the one produced by dtt. The third attachment shows the same spectra comparison, where the noise budget span is set to 280 seconds so the glitch is not included and the two spectra agree. 

Comparison of sensitivity with OM2 hot and cold wihtout squeezing:

The next two attachments show spectra comparisons for no sqz times with OM2 hot and cold, (same times as above), the first shows a comparison of the DARM spectrum, and the second shows the range accumating as a function of frequency.  In both plots, the bottom panel shows the difference in accumulated range, so this curve has a positive slope where the sensitivity of OM2 hot is better than OM2 cold, and a negative slope where OM2 hot is worse.  The small improvement in sensitivity between 20-35 Hz improves the range by almost 5Mpc, then there is a new broad peak at 33Hz with OM2 hot which comes and goes, and again a benefit of about 4Mpc due to the small improvement in sensitivity from 40-50 Hz. 

From 90-200 Hz the sensitivity is slightly worse with OM2 hot.  The coupled cavity pole dropped from 440Hz to 424Hz while OM2 warmed up, we can try tuning the offsets in AS72 to improve this as Jennie and Keita did a few weeks ago: 78415

Comparison of with squeezing:

Our range has been mostly lower than 160 Mpc with OM2 hot, which was also true in the few days before we heated it up.  I've picked a time when the range just hit 160Mpc after thermalization, 27/6/2024 13:44 UTC to make the comparison of our best sensititivites with OM2 hot vs cold. This is a time without the 33Hz peak, we gain roughly 7 Mpc from 30-55 Hz, (spectra and accumulated range comparisons) and loose nearly all of that benefit from 55-200 Hz.  We hope that we may be able to gain back some mid frequency sensitivty by optimizing the PSAMs for OM2 hot, and by adjusting SRM alignment.  This is why we are staying with this configuration for now, hoping to have some more time to evaluate if we can improve the squeezing enough here.  

There is a BRUCO running for the 160Mpc time with OM2 hot, started with the command:

python -m bruco --ifo=H1 --channel=GDS-CALIB_STRAIN_CLEAN --gpsb=1403531058 --length=400 --outfs=4096 --fres=0.1 --dir=/home/sheila.dwyer/public_html/brucos/GDS_CLEAN_1403531058 --top=100 --webtop=20 --plot=html --nproc=20 --xlim=7:2000 --excluded=/home/elenna.capote/bruco-excluded/lho_excluded_O3_and_oaf.txt

It should appear here when finished: https://ldas-jobs.ligo.caltech.edu/~sheila.dwyer/brucos/GDS_CLEAN_1403531058/

 

 

Images attached to this comment
gerardo.moreno@LIGO.ORG - 15:59, Wednesday 10 July 2024 (78829)VE

(Jenne, Jordan, Gerardo)

On Monday June 24, I noticed an increase on pressure at HAM6 pressure gauge only.  Jordan and I tried to correlate the rise on pressure to other events but we found nothing, we looked at RGA data, but nothing was found, then Jenne pointed us to the OM2 thermistor.

I looked at the event on question, and one other event related to changing the temperature of OM2, and the last time the temperature was modified was back on October 10, 2022.

Two events attached.

Images attached to this comment
camilla.compton@LIGO.ORG - 09:48, Thursday 11 July 2024 (79026)

Some more analysis on pressure vs OM2 temperature in alog 78886: this recent pressure rise was smaller than the first time we heated OM2 after the start of O4 pumpdown.

H1 ISC
jennifer.wright@LIGO.ORG - posted 14:25, Thursday 06 June 2024 - last comment - 15:30, Friday 28 June 2024(78282)
Measured OMC Scan before Moving spot in OFI Today

At the start of commissioning today, before we got to NLN and were having trouble locking the OMC, I took an OMC mode scan when we were locked at 10W.

We manually move the OMC_PZT2_OFFSET to its lowest slider value then run the template which does two 100s ramps of this PZT.

Posting for posterity.

Time of Scan = 15:23:43 UTC

200s length. See template in /ligo/home/jennifer.wright/Documents/OMC_scan/2024_06_06_OMC_Scan_15-23UTC.xml

Images attached to this report
Comments related to this report
jennifer.wright@LIGO.ORG - 15:30, Friday 28 June 2024 (78730)

Analysed mode scan and C02 mode for this full-lock scan but since we have mainly been doing single bounce to look at losses and all the sidebands were on, just posting it here for posterity. The mode-matching calculation has to take into account all the sidebands I think.

Analysis code is In OMCscan_nosidebands13.py and fit_two_peaks_no_sidebands13.py in /gitcommon/labutils/omc_scan/figures/2024-06-06 on the /dev branch (ie. it will not be on the workstation branch as this is the master branch).

Non-image files attached to this comment
Displaying reports 6961-6980 of 83403.Go to page Start 345 346 347 348 349 350 351 352 353 End