TITLE: 03/29 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 153Mpc
INCOMING OPERATOR: None
SHIFT SUMMARY: We've been locked for 7:30. The LVEA is still in HAZARD, Robert has 3 viewports still open but they're covered with foil, DIAG_MAIN was flashing PSL_ISS diff power is low.
22:45 UTC Relock #1 -- We reached NLN at 23:26 UTC, after Robert wrapped up his measurements we went into Observing at 23:45 at ~150Mpc
05:52 UTC SEI transition backed to WINDY from MICROSEISM
LOG:
Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
---|---|---|---|---|---|---|
23:30 | PEM | Robert | LVEA | Y | Take apart stuff, quick measurement | 23:45 |
We've been locked for 3:50 and been in observing since 23:45UTC, cleaned range has been hovering just under 160.
I looked at Jennie's and Camilla's spot position test (76770) to check if the movements had an effect on the sensitivity. In brief: yes, they do.
The largest effect is at low frequency (<30 Hz, see spectra and ratio to nominal values) and most evident with CAM_YAW2_OFFSET, and to a smaller extent with CAM_PIT2_OFFSET. Those changes are probably what was driving the change in range: I believe they're due to the fact tha by changing the spot position one changes the optimal A2L coefficients that are used on ITMY to minimize the coupling of CHARD and DHARD. So my guess is that one should ignore those changes since they are likely recoverable by tuning ITMY A2L.
The most intersting changes are at high frequency (>500 Hz, see spectra and ratio to nominal values). Moving CAM_YAW2_OFFSET has a small (3%) but noticeable effect on the sensitivity at high frequency. Not sure what's causing this: I don't think the change in power is large enough to account for a shot noise improvement, nor is the optical gain change. I think this is worth move investigation.
Analysis code attached.
Jennie W, Sheila, Francisco
11:30 am - ish
After many previous efforts we are trying again to move input yaw pointing in the IMC (via IM1 and IM3) and measure if this has any effect on our jitter coupling.
See first image for where the sliders were before we made changes.
We orginally started by taking a reference jitter coupling measurement, brown traces in the two attached graphs, first one is pitch, second is yaw.
The graphs show the DARM spectra on the top left, the coherence with two jitter witness channels on the top middle and right, and the transfer functions of these witness channels to DARM on the bottom row of graphs.
IM 1 and 3 were stepped in yaw down by 20 and we waited for IM4 and PRM motion to level off before moving again to make sure the IFO stayed lock.
We did three steps to go down a total of 60 counts where we took the green traces in the attached graphs.
After this we reverted the alignment changes.
I then took this ndscope screenshot showing the steps down and then back up.
It is not clear to me that the build-ups are better.
2pm -ish
We took another reference for jitter before moving. This is coloured blue.
We made more steps on IM1 and IM3 till we had gone twice as far as earlier (ie. down by 120 counts on IM1 and IM3). This made the build-ups noticeably bigger as the change is easier to see when we are thermalised.
We took another jitter measurement shown in red.
We are not sure why the PSL-ISS_SECONDLOOP_PDSUMOUTER chnages as we change the input pointing but we could be clipping somewhere between IM4 and ISS array.
We left the IMs where they were and then lost lock a couple of minutes after, probably due to wind (60mph!) The IFO still relocked with these yaw changes.
Earlier this week there was a HAM1 HEPI trip at LHO, not sure why. Robert was working near HAM3, that was the only activity. WD says the actuators saturated, but I can't find any evidence of it.
It looks like a one point there were 6 total actuator saturations, but they must have happened too fast to show up in the 512hz MASTER_OUT channels? Attached plot shows the time when the ACT SAT COUNT channel (16hz) (bottom right) went from 0 to 6. The corner 2 L4Cs see something, there is a burst of something in the actuators (top 2 plots on the left column), but they don't seem to get anywhere near saturating. Something like this happens again less than an hour later and trips the HEPI, breaking the lock.
Second image is the same channels, from before the first act saturations to after the trip. Still no evidence of actuator saturations anywhere in this data. The only way I can make sense of this is somehow we had actuator saturations that were too fast to be recorded in the 512hz MASTER OUT channels, but whatever caused them, don't seem to show up in the 3d l4c channels on the L4Cs on the floor under the chamber.
We changed the PSAMS from 150/90 to 100/100 and ran the SCAN_ALIGNMENT with sqz-optimized. We will leave this PSAMS setting tonight. The result of SCAN_ALIGNMENT is here.
https://lhocds.ligo-wa.caltech.edu/exports/SQZ/GRD/ZM_SCAN/240328143140/
We ran the SCAN_ALIGNMENT with asqz-optimized. The result is here.
https://lhocds.ligo-wa.caltech.edu/exports/SQZ/GRD/ZM_SCAN/240329140112/
The quiet asqz time for 100/100 is as follows.
PDT: 2024/3/29 14:11:30-14:21:30
UTC: 2024/3/29 21:11:30-21:21:30
GPS: 1395781908-1395782508
Naoki, Vicky, Sheila, Camilla
To scan the sqz angle to optimize the squeezing in the bucket, we copied the SCAN_SQZANG state in SQZ_MANAGER guardian in LLO. This state will find the optimal sqz angle to minimize the BLRMS3 at 350 Hz. We replaced the 0.1 Hz LP with 1 Hz LP for BLRMS3. We will test this state tomorrow.
We tested the SCAN_SQZANG state and it seems to work. The result is saved here.
https://lhocds.ligo-wa.caltech.edu/exports/SQZ/GRD/SQZANG_SCAN/
TITLE: 03/28 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Wind
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
SEI_ENV state: USEISM
Wind: 10mph Gusts, 7mph 5min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.54 μm/s
QUICK SUMMARY:
Into Observing at 23:45UTC
MC1 and MC3 cameras went offline between 11:00 and 12:00 Thursday morning. I cannot ping the cameras (h1cam07, h1cam12). I powercycled the network switch ports for these cameras, with no change. Looks like these cameras are disconnected from the ethernet.
TITLE: 03/28 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:
Most of today was for Commissioning and then PEM Injection prep/measurements.
H1 was locked for a good part of the shift, with (2) locklosses. Able to relock after 20+hr lock without needing an alignment (but definitely needed to correct lots of pitch misalignment.
Had a high winds storm pass through during the last hour of the shift, highest wind value from our wind sensors was 57mph from the Corner Station (see attached).
LOG:
Kevin and Vicky helped to get the old range comparison plots from the noise budget working with some updates to the noise budget. The first plots show the spectra, range integand and the cumulative range for a comparison between O4a and a few days ago. This is range calculated by gwinc, the sensmon range is shown in the legend.
Looking at the darm spectra and the range difference plot here, you can see that we gained about 15Mpc of range from low frequency improvements including DARM offloading. Above 40Hz our recent sensitivity has been worse, we lose 15 Mpc from the decreased sensitivity beween 40-100 Hz and another 7 or so from the worse sensitivity above 100Hz.
Last night we had slightly better BNS range after the squeezer alignment work 76757 , the same comparison of O4a to last night shows that we are loosing less range from 65-300 Hz, as shown in this plot as well.
I've also made this comparison for no squeezing, using times from 76537 and 76540: here. This shows that without squeezing the mid frequency sensitivity (30-70Hz) has gotten worse which is costing roughly 10Mpc of range.
Elenna's sensitivity comparison from a few weeks ago contains helpful links to recent changes: 76449
first of all, apologies that the axis labels were switched in the above plots.
Second, instructions if you'd like to make these plots yourself for your own times:
cd /ligo/gitcommon/NoiseBudget/aligoNB/production_code/
conda activate aligoNB
open gps_reference_times.yml and either chooose some times from the list or add your own time dictonary. If you add a time, please add it below the LHO and LHO_NO_SQZ entries (those are the ones that the noise budget uses), and add a helpful comment describing your time.
open H1/darm_integral_compare.py and edit lines 85 and 91 (after_gps_dict = gps_dict['LHO_ER16_April4'] and b4_gps_dict = gps_dict['LHO_O4a_postvent']) so that it will plot your chosen tmes.
python H1/darm_intergal_compare.py
Your plots will be saved in /ligo/gitcommon/NoiseBudget/aligoNB/out/H1/darm_intergal_compare/
Adding a 20dB attenuator at the output of the ADF CLF reduced the ADF signal strength by approximately a factor of 10.
Camilla, Jennie W
Camilla and I reran the camera offset tests yesterday while in observing. There is a clear effect from yaw offset changes in the build-ups but not so clear with pitch changes.
See this image for the CAM2 servo steps and this image for the CAM1 servo steps.
CAM 2 YAW
The lowest yaw offset gives highest circulating power and highest power on POP A, B and REFL A PDs and the highest yaw offset gives the lowest power values. The lowest offsets give a dip in the range, as does the highest yaw offset. The best offsets for range seem to be close to nominal, the second highest offset step (-414 counts).
KAPPA C is highest at the lowest yaw offset, which makes sense as this is when we have the best build-ups.
CAM 2 PITCH
For the pitch as mentioned above the steps are not obvious in the circulating power plot or the POP A/B / REFL A plots. There is maybe a correlation between the lowest offset and the lowest power build-up, and the second highest offset and the highest power build-up but no clear correlation with the range or KAPPA C.
CAM1
This has similar trends to CAM2 however I think thye pitch is correlated the opposite way from 1 whihc makes me think that the motion the pitch causes is just some swaying f the alignment as the camera offsets change and it doesn't particularly matter which way we change them in pitch. The yaw offset change though shows peaks at lowest offset, troughs at highest offset and best range near nominal offset and highest KAPPA C (optical gain) at highest yaw offset.
Thu Mar 28 10:13:28 2024 INFO: Fill completed in 13min 23secs
Gerardo confirmed a good fill curbside.
Vicky, Naoki, Nutsinee
To scan the ZM alignment, we copied the SCAN_ALIGNMENT state in SQZ_MANAGER guardian in LLO. After some debugging, we successfully ran this state. The result is saved in here.
https://lhocds.ligo-wa.caltech.edu/exports/SQZ/GRD/ZM_SCAN/
This state scans the ZM4/ZM6 COM and DIF P/Y. We need the proper diagonalization to define the COM and DIF, but we have not done it today. The state fits the BLRMS6 at 1.7kHz and finds the optimal ZM slider value for minimizing the BLRMS6 as shown in the first attachment. After each ZM scan, the SQZ angle is also scanned and the optimal SQZ angle is found as shown in the second attachment.
The third attachment shows the BLRMS. The T1 cursor shows when the sqz-optimized scan was done. After the scan, the BLRMS6 looked good, but the BLRMS3 (yellow) was not so good and the BNS range was below 150 Mpc. So we tweaked the sqz angle and the BNS range reached more than 150 Mpc.
The original SCAN_ALIGNMENT tries to find the minimum of squeezing, but we modified it so that it can also try to find the maximum of anti squeezing. The T2 cursor in the third attachment shows when the asqz-optimized scan was done. The result is saved here.
sqz-optimized: https://lhocds.ligo-wa.caltech.edu/exports/SQZ/GRD/ZM_SCAN/240327132206/
asqz-optimized: https://lhocds.ligo-wa.caltech.edu/exports/SQZ/GRD/ZM_SCAN/240327144407/
The fourth attachment shows the ZM slider after the sqz-optimized and asqz-optimized scan. The ZM4 Y is almost the same, but other ZM alignment is different by 10-20 counts between the sqz-optimized and asqz-optimized scan. The proper diagonalization of ZM4/6 would resolve it.
Since the SCAN_ALIGNMENT touches the TRAMP of ZM slider, we reverted it after the scan as shown in the fifth attachment.
Screenshot of the SCAN_ALIGNMENT_FDS (105) guardian state maximizing anti-sqz, just like Masayuki's LLO:64903. This update to SQZ_MANAGER is committed to svn revision 27339.
It looks like this tuning improved the noise in the bucket. Maybe reducing the misterious excess broadband noise?
This also reduces the "excess noise" as estimated using Artem's method (computing the difference between the PSD now and in O4a).
F. Clara, M. Pirello, R. Schofield
We systematically verified the cabling from the VEA to the Electronics racks of all 7 accelerometers currently in service. We replaced channel 5 on the new Accelerometer Power Conditioner for further testing, the new channel 5 is performing correclty. Then we went through and tested the accelerometers vs the signals in NDSCOPE / DIAGGUI. We found a fault in the EY_EBAY_Z cable and replaced it. We corrected the cabling to match the system drawing D1300773 , while verifying the signals, we found an unlabeled cable that was not documented. We determined that this cable was patch done before O4 to fix a bad accelerometer cable on BSC10_X, this cable was routed correclty and is now documented. Final complete order of the cabling is as follows:
SignalName <= ADC# <= CBL# <= SLOT# <= AccelerometerName(path)
EY_OPLEV_X <= ADC7 <= CBL1 <= SLOT1 <= EY_OPLEV_X
EY_BSC10_X <= ADC8 <= CBL2 <= SLOT2 <= Black Patch Cable <= Patch Panel #3<= White Accelerometer Cable <= EY_BSC10_X
EY_BSC10_Y <= ADC9 <= CBL3 <= SLOT3 <= EY_BSC10_Y
EY_BSC10_Z <= ADC10 <= CBL4 <= SLOT4 <= EY_BSC10_Z
EY_TABLE_X <= ADC11 <= CBL5 <= SLOT5 <= EY_TABLE_X
EY_VEAFLOOR_Z <= ADC12 <= CBL6 <= SLOT6 <= EY_VEA_FLOOR
EY_EBAY_Z <= ADC13 <= CBL7 <= SLOT7 <= EY_EBAY_Z
The patched cable is a temporary solution, a permanent solution should be considered here.
This morning I took the OPLEV charge measurements on both ETMX and ETMY suspensions. I will post the results below after processing the data.
Both the suspensions were restored to their nominal state after the measurements were complete.
Later, Jeff flipped the sign on ETMX ESD bias voltage once the above measurements were done.
H1 SUS ETMX L3 ESD Bias was held at +430 [V_ESD] in order to mitigate the charge build up identified in LHO:76326 for ~1 hr today, 2024-03-26, between 17:46 and 18:46 UTC. Attached is a trend of the ESD bias offset (calibrated in [V_DAC] rather that [V_ESD]) throughout today's maintenance.
I processed the measurement, ETMYs charge appears low and doesn't have any major trends, ETMXs charge is around 40 [V] on most DOFs and appears to have a slight upward trend.
In addition to the BSC10 accelerometer, the amount of floor motion also increases over the past 6 weeks, though not in a sudden fashion.
This does not correspond to the time of the most recent fan swap, judging by fan accelerometers.
New EX and EY Accelerometer Power Conditioners were installed 30 January 2024. This is roughly the same time as some of these jumps in the trend. The EY BSC 10 accelerometer cable had a questionable connector but still functioned so I believe we left it, it may need to be replaced.
https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=75592
We replaced the loose connector but did not see any effect on the signal. While down there we looked at the output and found that channel 5 output was very noisy, and looking back at the notes in my prior ALOG, channel 5 = PEM EY BSC ACC X and back then it did not register as an accelerometer. I assume this accelerometer is not functional or the cabling is not correct. We plan to go back on Tuesday and track down the issue with this accelerometer and possibly repair the channel in the power conditioner chassis.
Other notes
The INPUT to CH3 on the power conditioner is "TBL-Y" accelerometer cable. When unplugged this affected "BSC-Y" signal plot.
The INPUT to CH4 on the power conditioner is "BSC-Z" accelerometer cable. When unplugged this affected "BSC-Z" signal plot. (this one was correct)
Looking back at my analysis of the drawings in the linked ALOG, the above note matches the drawings in the DCC D1300773. I propose we assume the cables are swapped incorrectly but labeled correctly, and we rearrange the cables to match the drawing.
Marc, Fil, Gerardo, Janos
Refer to LHO:76728.
Naoki, Daniel, Nutsinee
Today we increased RF6 from -22dBm to -13 dBm and 8 dBm. We saw excess noise at 8 dBm above 300Hz but no excess noise at -13dBm. REF 12 is the squeezing at -22dB before we started the test. Using the time from alog76553. REF9 and REF10 both show squeezing at -13dBm RF6 at different squeeze angle where one has a better sensitivity at low frequency bucket. REF13 shows squeezing at 8dBm RF6. The excess noise above 300Hz cannot be improved with squeeze angle. Investigation is required.
We turned off ADF sqz angle servo during the test. We readjusted the ADF squeeze angle demod phase and accepted the new value in the SDF.
We are parking RF6 at -12dBm. Since Daniel didn't like the unlucky number 13.
Loop | Was (-22dBm RF6) | Now (-12 dBm RF6) |
CLF gain | 10 | 0 |
LO gain | -7 | -12 |
FC LSC gain | -2.6 | -0.86 |
FC ASC gain | 0.1 | 0.03 |
The -22dBm, -12dBm, 8dBm RF6 correspond to 9 uW, 28 uW, 420 uW CLF REFL power.
We rechecked the FDS -22dBm time as the time in the above plot wasn't sqz opitmized to the bucket. Can see in attached plot, CLF at -22dBm and -13dBm have the same SQZ in the bucket, as expected.
Looking back at the past data it seems we may not have adjusted the CLF ISS gain properly during the test causing our sqz level to be stuck at 3dB at kHz region. CLF_REFL_DC was oscillating when RF6 was at -13 dBm and at 8 dBm. This looks like an easy fix and we should try again at some point.
Daniel Nutsinee
Reducing the gain didn't seem to fix the oscillation. We cranked up the CLF power so the RF6 read 6dBm and went out to look at the signal on the scope. We saw 60kHz beat note on the OPO refl and a crooked 105kHz sinewave on the CLF refl. We don't know where the 60kHz beat on the OPO refl came from. We couldn't make any improvement by changing the CLF ISS gain.
After some investigation we realized the oscillation disappeared when we unplugged the RLF. The oscillation came back when the RLF was plugged back in. The oscillation associated with the RLF seemed obvious only when we operated at high power. Next time we try high CLF power again we should attenuate the RLF RF output to the AOM.
The funny thing was PMC refl saw this oscillation as well. We hope this was just an electronics cross talk.
For even higher CLF power with +6dBm at the RF6 demod, we set the CLF servo IN2 gain to-18dB (from 0dB), the CLF ISS gain to 0dB (from 17dB), and the ISS input set point to 2.037 (from 0.347).