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.
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.
Sat Jun 29 10:09:48 2024 INFO: Fill completed in 9min 45secs
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.
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.
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.
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.
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.
H1 back to observing at 06:29 UTC, fully automatic relock.
Lockloss @ 03:06 UTC - link to lockloss tool
ETMX saw a small hit about a half second before the lockloss.
H1 back to observing at 04:14 UTC. Automatic relock except BS and PRM needed adjusting to lock DRMI.
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 |
|
|
|
|
|
|
FAMIS 26444, last checked in alog78167
Both BRSs look good. The slight motion of BRS-Y looks to line up with small temperature changes.
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.
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:
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.
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
Fri Jun 28 10:09:37 2024 INFO: Fill completed in 9min 33secs
Jordan confirmed a good fill curbside.
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.
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.
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).
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):
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/
(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.
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.
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
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).