Displaying reports 801-820 of 77255.Go to page Start 37 38 39 40 41 42 43 44 45 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 VE
david.barker@LIGO.ORG - posted 10:22, Saturday 29 June 2024 (78743)
Sat CP1 Fill

Sat Jun 29 10:09:48 2024 INFO: Fill completed in 9min 45secs

Images attached to this report
H1 General
thomas.shaffer@LIGO.ORG - posted 10:08, Saturday 29 June 2024 - last comment - 11:03, Saturday 29 June 2024(78742)
Lock loss 1655 UTC

Lockloss 1403715367

There was ground motion from an earthquake just after the lock loss, but the lock loss itself seemed to be quite sudden. ETMX sees those usual wiggles that we often see.

Robert had just started running HVAC shutdown tests, but this seems very unlikely to be the cause.

Images attached to this report
Comments related to this report
thomas.shaffer@LIGO.ORG - 11:03, Saturday 29 June 2024 (78745)

Back to Observing at 1800UTC

I touched up TMSX P, PRM Y, and a bit pf BS P to speed of acquisition and avoid an initial alignment.

Our ALSX PLL beatnote seems to have gone quite bad ~10 hours ago, getting < -30 dBm. It recovered during this acquisition but I worry we will have more issues with this.

Images attached to this comment
LHO General
thomas.shaffer@LIGO.ORG - posted 07:32, Saturday 29 June 2024 (78740)
Ops Day Shift Start

TITLE: 06/29 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 153Mpc
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 5mph Gusts, 4mph 5min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.06 μm/s
QUICK SUMMARY: Locked for 8 hours, calm environment after the earthquake settled down.

LHO General (SEI)
ryan.short@LIGO.ORG - posted 01:07, Saturday 29 June 2024 (78739)
Ops Eve Shift Summary

TITLE: 06/29 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Observing at 149Mpc
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: Two locklosses this shift and recovery was straightforward in both cases. Earthquakes at the end of the shift shook things up, but ultimately H1 rode through. H1 has now been locked and observing for almost 2 hours.

LOG: No log for this shift.

H1 General (Lockloss)
ryan.short@LIGO.ORG - posted 23:29, Friday 28 June 2024 - last comment - 23:30, Friday 28 June 2024(78737)
Lockloss @ 05:35 UTC

Lockloss @ 05:35 UTC - link to lockloss tool

End of short lock, no obvious cause. I don't see the same ETMX motion as in the previous lockloss.

Comments related to this report
ryan.short@LIGO.ORG - 23:30, Friday 28 June 2024 (78738)

H1 back to observing at 06:29 UTC, fully automatic relock.

H1 General (Lockloss)
ryan.short@LIGO.ORG - posted 20:24, Friday 28 June 2024 - last comment - 21:17, Friday 28 June 2024(78735)
Lockloss @ 03:06 UTC

Lockloss @ 03:06 UTC - link to lockloss tool

ETMX saw a small hit about a half second before the lockloss.

Images attached to this report
Comments related to this report
ryan.short@LIGO.ORG - 21:17, Friday 28 June 2024 (78736)

H1 back to observing at 04:14 UTC. Automatic relock except BS and PRM needed adjusting to lock DRMI.

H1 AOS
robert.schofield@LIGO.ORG - posted 18:47, Friday 28 June 2024 (78734)
Slow changes of ITMY ESD bias during observation

I made slow (ramp time = 120s) changes of the ITMY ESD bias today during observation mode in order to find a minimum in electronics ground noise coupling, using coherence between DARM and a current clamp on a grounding cable as the figure of merit. This project will continue, but I am done for the day and wanted to get today's times into the alog.

 

Start of change (GPS)

End of change (GPS)

ITMX bias at start (V)

ITMX bias at end (V)

ITMY bias at start (V)

ITMY bias at end (V)

1403651100

1403651220

0

0

0

-39

1403653448

1403653569

0

0

-39

170

1403655679

1403655799

0

0

170

-222

1403657640

1403657760

0

0

-222

0

 

 

 

 

 

 

H1 SEI
ryan.short@LIGO.ORG - posted 18:01, Friday 28 June 2024 (78733)
BRS Drift Trends - Monthly

FAMIS 26444, last checked in alog78167

Both BRSs look good. The slight motion of BRS-Y looks to line up with small temperature changes.

Images attached to this report
LHO FMCS (PEM)
ryan.short@LIGO.ORG - posted 17:37, Friday 28 June 2024 (78732)
HVAC Fan Vibrometers Check - Weekly

FAMIS 26313, last checked in alog78597

CS fan 5 had a slight jump up in noise about a week ago, still well within range.

All other fans largely unchanged from last check and within range.

Images attached to this report
LHO General
thomas.shaffer@LIGO.ORG - posted 16:08, Friday 28 June 2024 (78720)
Ops Day Shift End

TITLE: 06/28 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 156Mpc
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY: Two lock reacquisitions, both automated. Robert has been changing some ITM L3 biases while in observing, as approved.
LOG:

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 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 801-820 of 77255.Go to page Start 37 38 39 40 41 42 43 44 45 End