H1 Manager called because it couldn't get ALSY to lock in initial alignment. The flashes were barely below being able to catch. I paused INIT_ALIGN and touched ALSY in yaw and we were able to lock green and are on our way back up.
TITLE: 04/27 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 150Mpc
INCOMING OPERATOR: Oli
SHIFT SUMMARY:
H1 is locked and Observing for 4 Hour now.
Relatively quiet night.
LOG:
No log
FAMIS 26297
H0:VAC-MX_FAN1_370_2_ACC_INCHSEC has a very Strange looking reoccuring ingrease in its noise.
It looks like this fan wasn't being used until about 100 days ago. 100 days ago it seemed to be fairly noisy as well, but this is strange looking and very different.
it seems like the fan is noisy for 12-16 ish hour and quiet for 8-16 hours. Maybe this particular fan isnt on for 8 hours,
It's likely it turns on at 1Pm and turns Off at 9-10 pm.
I think this is a new noticable development since the last time I checked on the Vibrometers.
TITLE: 04/27 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 152Mpc
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 4mph Gusts, 2mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.17 μm/s
QUICK SUMMARY:
00:52 UTC Intentional Drop from Observing to adjust squeeze angle.
Requested SQZ_MANGER to go to SCAN_SQZANG saw the phase slider move around a bit and it created https://lhocds.ligo-wa.caltech.edu/exports/SQZ/GRD/SQZANG_SCAN/SQZANG_SCAN_240426175458.png
00:56 UTC Back to Observing
2:04 UTC Lockloss https://ldas-jobs.ligo-wa.caltech.edu/~lockloss/index.cgi?event=1398218686
Unknown cause but ETMY L2 Master out starts to change behaivor about a second before the lockloss.
---Relocking--
Increase flashes ran for YARM
Happened automatically without any input from me.
Nominal_Low_Noise reached at 3:01 UTC
Observing reached at 3:04 UTC
Ibrahim A, Oli P, Mark B, Betsy W
Context:
M3 on the beam splitter has secondary prisms that are placed along the barrel below the primary prisms. These secondary prisms are placed at a location below the primary prism, and if placed in the correct spot, act as a clamp, damping the oscillations moving down the wire loop into the optic. We've been working on finding the optimal secondary prism position for the BBSS.
Experiment:
The experiment for determining this position was developed for the BSFM in 2011(T1100086), and we used a similar setup for our three (successful) runs for the BBSS. This is basically how the experiment is set up to work:
Results + Commentary:
Note: Mark has an upcoming alog about the run of data and issues that we took when he was here, but in LESS IMPORTANT Auxiliary Investigations we will be focusing on the data from the second and third runs, but here in the results will still be showing the data we got with him.
The plot attached shows the attenuation measured versus the position (positive distance relative to the mass’ centerline) of the secondary prism. Each color is a separate run, and the more negative the attenuation, the quieter the reading was, so we are looking for a location with the lowest values where the secondary prism would do the most damping.
We found that there is a region between ~29.00mm and ~31.5mm below the horizontal center of the mass where the amplitude is minimized. There are approximately three anomalous data points in between, with one confirmed being due to cross-coupling of above wire. As of now, we’re still working on understanding this data and have spoken to Mark B and Jeff K about how we can go about accurately interpreting the raw data (including essential questions about the calibration and setup. See below.)
LESS IMPORTANT Auxiliary Investigations - Details, Details, Details
Read for Clues/Hints (things we noticed, changed etc.):
TITLE: 04/26 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 150Mpc
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
SEI_ENV state: SEISMON_ALERT
Wind: 9mph Gusts, 6mph 5min avg
Primary useism: 0.04 μm/s
Secondary useism: 0.19 μm/s
QUICK SUMMARY:
H1 is locked for 2 hour 52 minutes.
When H1 has been locked for 4-5 hours I will follow the instructions out lined by Sheila's Alog 77447 to adjust the SQZ angle after the IFO has been thermalized.
The will take us out of Observing for a short time.
TITLE: 04/26 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 150Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Commissioning for most of the morning which ended in a lockloss. Relocked easily and have been observing for the afternoon.
LOG:
Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
---|---|---|---|---|---|---|
15:48 | SQZ | Terry, Kar Meng | Opt Lab | Local | SHG work | 16:52 |
16:04 | PEM | Robert | LVEA, EX | - | Pack up equipment | 17:52 |
17:46 | VAC | Janos | EX | - | CP dewar jacket pumping | 18:39 |
17:52 | SQZ | Terry, Kar Meng | Opt Lab | Local | SHG work | 20:17 |
18:49 | PEM | Robert | EX | - | Shutting down PEM setup | 19:38 |
20:21 | PEM | Robert | CER | - | Retreive cable | 20:32 |
21:36 | SQZ | Terry, Kar Meng | Opt Lab | Local | SHG work | 23:36 |
After the changes in our output arm this week (77427) we took some time to check the level of backscatter from the AS port, as a way to check the health of the OFI.
I tried to reproduce Camilla and Eleonora's excitation from 71354, using a 0.65 Hz excitation on OMC L, and adjusted the amplitude until I saw about 12um peak to peak motion of the OMC (peak to peak amplitude measured by OMC M1 DAMP IN1, in um, are listed in the legend.)
Comparing this plot to 71354, the amplitude of reflected light does seem higher now by about a factor of 2. We didn't repeat this measurement after the OMC was swapped, before the apparent changes in the OFI.
Thanks to Elenna for the instructions!
The BRUCO can be found here and ran on 400s seconds starting at 1398159599.
Analysis in progress.
Elenna's bruco instructions are at /ligo/home/elenna.capote/bruco_instructions.txt
(I've attached a copy here as well)
I've just retuned the SQZ angle with a freshly locked IFO, which will not be well tuned once the IFO is thermalized. Once we have been locked for ~4-5 hours, it would be good for the operator to re run this so that the squeezing angle is set for a thermalized IFO.
Please, go out of observing, from sqz manager select SCAN_SQZANG. This will create a folder (named by the time you run it) https://lhocds.ligo-wa.caltech.edu/exports/SQZ/GRD/SQZANG_SCAN/
The plot should look something like this, with a minumum of squeezing at some CLF phase, which should now be where H1:SQZ-CLF_REFL_RF6_PHASE_PHASEDEG is set to.
There had been a suggestion (passed to me by Sheila) that we should measure the beam positions on SRM and SR2 after the big move that we made this week (which is summarized in alog 77427).
We don't have a premade script to do this like we have for the test masses, so I just did it by hand. One at a time, I put in a line using the ADS screen to SR2 or SRM pit or yaw, then changed the corresponding A2L element to minimize the line height in CAL-DELTAL_EXTERNAL. I was also watching SRCL_IN1 and SRCL_OUT, but the lines disappeared in the SRCL signals before they disappeared in the DARM signal, so I just used DARM.
All A2L values for SR2 and SRM had been 0.0, so I'm not going to bother putting in a 'before' column in the table below since they were all the same value of zreo.
After finding those values, I ran /opt/rtcds/userapps/release/isc/common/scripts/decoup/BeamPosition/CalcSpotPos.py to get from A2L coefficient to beam spot. This script had been made for IMC optics, but since SRM and SR2 are the same style, the calculation should be the same. Reminder of where this calc comes from (it's referenced in the script): alog 31402.
We don't have any 'before' measurements to compare to, but at least we now have some amount of information of where we are on these optics after the big move.
I'm pretty sure that these new A2L values can only be good, so I've accepted them in both safe and observe snaps for SR2 and SRM (see first and second attachments, only 2 rows per SDF table are accepted). These A2L gains for non-test mass suspensions are not under guardian control, so this should be good enough to keep them in place.
In the table below, the Cal-Deltal line reduction factor ends up really just being the ratio of the peak height in DARM before I started doing anything to that dof, and the noise level. To do a better job of measuring this, I would have had to increase my excitation amplitude, but that didn't seem important enough to do given the limited commissioning time we had.
ampl [counts] of line at 30.5 Hz | A2L gain step size when minimizing | CAL-DELTAL line reduction factor | Final A2L gain | Inferred spot position [mm] | |
SR2 P2L | 0.1 | 0.1 | 50x | +5.5 | 11.1 |
SR2 Y2L | 0.1 | 0.3 | 45x | -4.5 | -9.1 |
SRM P2L | 0.7 | 0.1 | 100x | -3.4 | -6.8 |
SRM Y2L | 0.7 | 0.1 | 50x | +3.6 | 7.2 |
I don't have time right now to think through the whole left-vs-right sign convention (it's discussed in alog 31402), but it does look like we're rather 'diagonal' in the SRC now, since the signs of the spot positions are opposite for SR2 vs SRM (eg one positive P2L and one negative P2L means the beam is on opposite sides of center).
First I ran SCAN_SQZANG from SQZ_MANAGER, result is here
Then switched to anti squeezing by flipping sign on CLF servo and adjusting sqz angle to 98 (roughly watching the DTT template), and ran SCAN_ALIGNMENT_FDS. Results are here: https://lhocds.ligo-wa.caltech.edu/exports/SQZ/GRD/ZM_SCAN/240426111805/
In that scan it looked like some of the degrees of freedom didn't end at the place that was really maximizing anti-squeezing, perhaps because the best alignment was at the edge of the scan range. I manually moved AM4 + ZM6 to try to increase the anti-squeezing based on these plots (and watching in dtt). I also noticed during this that a lot of time in SCAN_SQZ_ALIGNMENT is taken up with scanning the squeezing angle, which is necessary if we are using squeezing to align, but seems like it will be less necessary for anti-squeezing. I looked at the sqz angle the script was choosing, and indeed it wasn't changing much at each alignment step. I've added logic to the state that it does this sqz angle scans if the fom is sqz, but skips it for asqz. This cuts the time that the script takes in half, so it now takes 5 minutes.
Re-running the script (without scanning sqz angle) produced this set of plots: 240426115056/ which show that we seem to have maximized anti-squeezing for differential alignment, but the plots for common seem like noise. We may need to make a larger scan for common.
We lost lock right as this scan finished, but don't think that the scan was the cause of the lockloss. We will need to retune the sqz angle when we relock, and may also need to retune it after the IFO has thermalized.
Lockloss @ 18:55 UTC - link to online lockloss tool
This was at the tail-end of commissioning time, but commissioning activities happening at the time don't seem to be the cause. At this point, no obvious cause.
H1 back to observing as of 20:34 UTC.
In alog77427, Sheila notes that our optical gain and power at the AS port PDs dropped 4% Monday night. On Wednesday after we moved SR3, SR2 to recover the throughput into HAM6, in a full lock our AS port PDs are now 12% lower than out last good lock Monday night before the optical gain drop. This number might be confusing with an alignment change, getting more or less 45Mhz down into HAM6. Another good comparison is from a no SQZ single bounce that Jennie Wright did in alog77204 a few weeks ago, compared to just after Jenne moved SR3, SR2 (alog77395).
PSL single bounce comparision
PD | 2024-04-16 16:23 UTC | 2024-04-24 20:50 UTC | % diff |
---|---|---|---|
AS_A sum | 1867 | 1850 | 0.91% |
AS_B sum | 1900 | 1878 | 1.16% |
AS_C sum | 0.0228 | 0.0225 | 1.32% |
started scan of OMC alignment started with no squeezing: April 26th 2024 16:36:47 ended at 17:30 UTC
We've asked Tony to try locking the IFO with SR3 and SR2 in these very different positions. With these optic positions, we don't want the AS_C offsets in place that we used to get locked yesterday. So, I have now accepted in safe.snap for the ASC model that the AS_C offsets are off (but I've left the numerical values).
If we're unable to lock, then the plan is to ask Tony to revert SR2 and SR3 and turn back on those offsets. Since the offset switches are part of SDF revert, to turn them on the plan should be to go Sitemap -> ASC -> Overview -> AS_C (bottom left) -> Turn on the offsets and save the diff in SDF.
First attachment is my saving the safe.snap file with the offsets off. Second attachment is where the offset buttons are.
We've gotten as far as PRMI locked (with arms held off resonance with ALS, as usual), and at some point as soon as PRMI ASC comes on MICH Yaw gets a 2.2 Hz wiggle.
EDIT to add that a thing to try could be to turn off the ASC during PRMI (set lines 737 and 738 of ISC_DRMI.py to False). If we have similar problems in DRMI ASC, also set lines 1026-1031 to False. Save, then reload ISC_DRMI guardian.
EDIT EDIT: I just set line 737 to False. It may be beneficial to tune up the alignment by hand.
EDIT EDIT EDIT: We're still getting wobbles, even though the guardian had turned off the MICH ASC, and I had by-hand turned off the PRC1 ASC.
EDIT EDIT EDIT EDIT : I also set PRC1 to False on line 738 and loaded. I have to go now though, so good luck Tony!
We had an almost 30 hour lock, but probably we want PRMI ASC to work again now that we're relocking. RyanS and I have just set lines 737 and 738 back to True to enable PRMI ASC.
We're still working to understand why we've got problems, but we've at least found *an* alignment of SR3 and SR2 that seems to prevent clipping at the AS port when we're centered on AS_C. To get here, I had to move SR3 and SR2 by very large amounts, much more than they ever drift. In order to more accurately see changes in power levels on the AS WFS, I had the DC centering loops engaged in this single bounce off of ITMY configuration.
In the attached plot, the bottom row is the slider values for SR2 yaw and SR3 yaw (so, in microradians). As a reminder, folks have been checking all day and there is no indication from suspension sliders, OSEMs, or where applicable oplevs, that any of our optics have moved nearly this much, so this should not have been necessary. That said, we've often found that (normally at least) we have lots of leeway clipping-wise when chosing SR3 and SR2 positions. There's no reason a priori that I can think of that would prevent us from locking with these SR2 and SR3 positions, but TJ and Camilla point out that having moved SR3 this much may make it challenging to also have the HWS paths aligned. These moves are basically my moving SR3, then moving SR2 to re-center on AS_C.
The top row of the attached plot is the centering on AS_C. So, we would like to only evaluate the amount of power on AS_A or AS_C (middle row) when the beam is centered on AS_C. It turns out that it's the low-ish part of the power curves that are the values when AS_C is centered.
I have highlighted using a blue line on the AS_A curve (middle row right side) roughly the trend. When we started (at about -42 mins) the power on AS_A when AS_C is centered is at about 1.64 units on this y-axis, and as we move SR3 and SR2 in yaw, I can increase the power on AS_A to about 1.85 units. Jennie found that a time of equivalent single bounce configuration from a week ago, we had 1.87 units on this y-axis. (This y-axis is just AS_A_NSUM * 0.001). I didn't take the time to go to the 'other side', but the trend of power on AS_A seems to show that we're into the plateau region, and at the same time the AS AIR camera looked much more normal and unclipped.
EDIT to note that part of the reason it's helpful to wait to evaluate AS_A power until AS_C was centered, is that that also gave time for the DC centering loops to catch up to my big SR3 moves. I think that the reason AS_A sometimes is higher than the blue marker curve, is that the beam was clipping on AS_A while the DC centering loops were catching up.
slider changes: