ISC_LOCK LOWNOISE_ASC
ISC_DRMI
CAMERA_SERVO
I updated the beam mode model prevously generated in alogs 30126-30130 (20160930) and alog 39706 (20171208).
It includes arm optics changes, as well as and output path model based on alog 84089 (20250425). With Kevin's help, I checked it aganst the default FInesse model. The models are reasonably close, although this mo9del does not include a) astigmatism, and b) thick otpics.
The model is available here:
/ligo/home/controls/sballmer/20250603/beamCalc.m
Some conclusions:
- In the cold state the SRC eigenmode has a beam size on the ITM of about 6.3cm (the arm mode is 5.3cm).
- To get to the matched "HOT" state, the ITMs need a 25uD lens.
- To match a thermal lens twice as big (50uD), the SR2-SR3 distance would have to shrink 8mm. None of tf the existing mode actuators can get us there.
- I haven't looked whether the PRC needs a simlar fix. I also didn't check whether out sidebands could accomodate this shift with a simple single-optic move.
https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=39706
https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=30126
https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=84089
This study looks at the effects of differential ITM/ETM RoC change, common ITM/ETM RoC change, and differential ITEM lenses change on the DARM sensing function as we track several quantities such as the mismatch between the ARM cavities, ARMs-SRC mismatch, and the beam spot size on TMs.
FINESSE results suggest that the mismatch between the arms through the ITMs (both RoC and lenses) has the biggest effect on the sensing function.
In all of these cases, we start with a minimized mismatch between all cavities to less than 0.01% by changing the RoC of several optics until the mismatches are minimized. All mismatches are calculated with the “model.cavity_mismatches_table()” function in FINESSE .
Steps to generate these plots:
For the RoC, the 3rd line is always the minimized mismatches case. Maximum mismatch I created was ~0.9%
Case1: Differential ITMs RoC
Starting with the case of differential ITMs RoC changes by ±2%. ITMX RoC increases while ITMY RoC decreases. The mismatch between the ARMs and the SRC also changes, but that is smaller than the mismatches between the ARMs themselves.
This has a strong effect on the sensing function shape at low frequencies. It seems that there is a stronger optical spring as the mismatch between the arms increases. The label on the plots show the ITMs RoC in diopters calculated as 2/RoC.
Changing which RoC increases and which decreases results in the same sensing functions.
The plot attached shows that result. And a table (attached as .png) shows the mismatches, diopters and more.
Case2: Differential ITM lenses focal lengths
Similarly, I change ITM lenses' focal lengths. Since, as defined in FINESSE at least, ITMXlens is negative and ITMYlens is positive, a differential change means that ITMXlens diverges the beam stronger every time (becomes less negative. e.g -3*10^5 m instead of -5*10^5) , and ITMYlens converges less, meaning it becomes a bigger positive number. Diopters in this case are calculated as 1/f
This creates a differential mismatch between the ARM cavities. The result is very similar to that of differential ITMs RoC changes.
The plot and the table attached show the sensing functions.
Case3: Differential ETM RoC
This also creates a mismatch between the arms that is bigger between the ARMs and the SRC. This will only affect the carrier’s mode, but not the sidebands, like the ITMs do.
This case does not have a big effect on the sensing function, as the ITMs (RoC and lenses). The sensing function plot and table are attached.
Case4: Common ITM RoC
Now, I keep the ARMs mode matched to each other but I mismatch the ARMs to the SRC by changing the ITMs RoC. This has a bigger effect on the DARM sensing function compared to ETMs but smaller than the ITM. Interestingly, this is the only case that shows a pro-spring behavior
The sensing function plot and table are attached.
From this investigation, it seems that the mismatch between the ARM cavities has the biggest effect on the sensing function, rather than the mismatch between the ARM cavities and the SRC.
Qualitatively, this suggests that the sensing function’s shape is an indicator of how well the arms are mode-matched to each other.
Elenna, Georgia, Craig, Stefan, Oli
We saw a very strange oscillation that appears to be beamsplitter related during the engagement of DRMI ASC. I tried turning down various DRMI ASC gains: SRC1, SRC2, MICH P, and it made no difference. We were getting BS saturation warnings. Finally, I just moved from"engage drmi asc" to "turn on BS stage 2" and the oscillations appeared to reduced. We saw large peaks with harmonics in the corner LSC signals starting near 18 Hz. We are wondering if it's an errant beamsplitter bounce mode?
Seems to be the SRCL1 offset change from 800 cts to zero counts. The ringup frequency is 16.2 Hz and is seen in every loop very strongly, especially MICH. I thought the MICH2 BR0604 filters might have something to do with this, but those are focused more along 17.8 Hz. Elenna points out that the 16.2 Hz ringing is present in all LSC prior to to the SRLC1 offset change. It is clear that the SRCL1 offset change makes things 100 times worse over a period of around 5 seconds. We could consider slowing down the offset change, as it currently happens in only one second. We could also investigate these bounce roll notches to ensure they are at the correct frequency for the BS. We could check the DRMI LSC OLGs at acquisition as well, as one may be on the edge of stability during a messy acquisition.
This has caused another DRMI lockloss but it was too fast to determine where it was coming from.
We haven't been able to lock DRMI since this particular lockloss, so we haven't had a chance to measure OLGs to see if it's a loop instability.
TITLE: 06/03 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: Oli
SHIFT SUMMARY:
IFO is in PLANNED ENGINEERING and LOCKING
Productive light maintenance tuesdays in which most of the work was done checking annulus pumps (VAC) and doing cable work on ISCT1 (EE). After this, we begun locking again.
There was also some GC/CDS work done with the internet, which has concluded. Other than that, normal Tues Maint. activities such as tumbleweed removal and NORCO took place.
We were able to sit at MAX_POWER for quite a while, before comissioner-caused lockloss.
DRMI ASC now works but more work needs to be done on PRMI ASC. This means that after a manual initial alignment, we can get to MAX_POWER automatically.
The majority of the work now is being done fixing an issue thought to be mainly with ADS (and soft loops that engage during and after POWER_UP.
The plan for then night can be found in Oli's alog 84765
LOG:
Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
---|---|---|---|---|---|---|
15:30 | LASER | LASER HAZARD | LVEA | LASER HAZARD | LVEA IS LASER HAZARD (\u2310\u25a0_\u25a0) | 07:26 |
14:37 | FAC | Randy | Mech Room | N | Moving things with forklift | 16:20 |
14:38 | FAC | Chris | EY | N | Tumbleweed Removal | 15:46 |
14:49 | FAC | Richard | X/Y Arms | N | Key Search | 16:29 |
15:29 | EE | Fil | LVEA | YES | Cable work | 17:06 |
15:47 | FAC | Chris + Pest Guys | LVEA | YES | Check Traps | 16:57 |
15:54 | VAC | Gerardo, Jordan | LVEA | YES | HAM1 Annulus Pumping | 17:17 |
16:11 | AOS | Camilla, Matt | Optics Lab | Local | Fiber pans | 17:16 |
16:12 | AOS | Jeff | Optics Lab | Local | Fiber collimating | 18:42 |
16:14 | EE | Marc | LVEA | YES | Cable Work | 17:06 |
16:17 | FAC | Ken | Mechanical Room | N | Electrical work | 19:17 |
16:54 | FAC | Matt, Bin | LVEA | YES | Tour | 17:21 |
16:58 | FAC | Chris | LVEA | YES | FAMIS Tasks | 17:16 |
17:00 | OPS | TJ, Ryan S, Betsy | LVEA | YES | Sweep | 17:52 |
17:16 | FAC | Kim | EX/EY | N | Technical cleaning | 18:19 |
17:17 | FAC | Chris | Yarm | N | Tumbleweed Work | 18:17 |
17:22 | EE | Marc, Josh | MY | N | Part Search | 17:52 |
18:32 | FAC | Chris | MX, MY, EX, EY | N | FAMIS TASKS | 19:14 |
18:57 | VAC | Jordan, Gerardo | LVEA | YES | Ion Pump Work | 19:18 |
19:57 | SUS | Randy | MY, MX | N | Looking for small ISI tables | 21:25 |
20:21 | AOS | Keita | Optics Lab | Local | ISS Part Search | 21:14 |
TITLE: 06/03 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 12mph Gusts, 6mph 3min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.22 μm/s
QUICK SUMMARY:
We lost lock from LOWNOISE_LENGTH_CONTROL a bit ago, so we are working on relocking. Plan for the rest of the day:
Today at ~11:10 am, IP3 (LVEA 2x 1250 l/s IP) failed leading to a slight pressure rise in the corner. Seen on all LVEA pressure gauges (BSC2, HAM6, etc.). Attached snapshot shows the two pumps behavior at the time of failure, pump ion current on left column, output voltage on right.
Gerardo and I went to the mechanical room to diagnose the controller, upon arrival both channels on the Dual Vac controller had tripped off. We reset the high voltage and powered on the IP. Channel 1 (corresponding to Pump A in CDS) would only reach 300 V and then would trip the controller. Channel 2 (Pump B would reach 7kV no issue but would trip when Channel 1 tripped). We then swapped to a Gamma MPC controller to test if the controller was the problem. We saw the same exact behavior where Pump A would only reach 300V and Pump B was ok at 7kV.
We then swapped back to the DualVac controller after confirming it was not the issue, but with only Pump B connected and powered on. We are continuing to monitor to make sure Pump B remains steady. In parallel, Travis and Mark are testing the HV cable to the pump to see if there are any shorts. Results to follow.
If the cable is not the culprit we will HiPot the pump to see if there are any shorts, pump will be isolated from main volume during this test. To be continued.
Using the Agilent FieldFox N9912A we measured the cable length with the following parameters:
Mode = DTF (VSWR), F_Start = 2.0MHz, F_Stop = 450.0MHz, Points 801, Resolution 261mm
Start Distance 5.0m, Stop Distance 170.0m
The cable end was detected at 80.79m from the start of the launch cable, launch cable was about 1m.
The cable measurement was similar to the other cables measured.
When measured with the DMM, this cable measured open, but when the connector was moved, it displayed ~6M ohms, this would normally not be an issue, but due to the high voltage in this location it may be an issue, recommend hipot.
M. Pirello, F. Clara, G. Morenao, T. Sadecki, J. Vanosky
Problem solved, see in aLog 84826
I changed that way that the SQZ_MANAGER SCAN_SQZANG gen state worked to now take a brms_channel argument. Nominally for SCAN_SQZANG_FDS this is SQZ-DCPD_RATIO_3_DB_MON which tunes the squeezing around the 350Hz BLRMS to give the max IFO range. This is not yet tested, changes in SQZ_MANAGER.py svn.
I added a new state SCAN_SQZANG_KHZ (state number 85) from FIS that uses SQZ-DCPD_RATIO_6_DB_MON to maximize sqz at high frequency ~1700Hz. It makes sure ASC is off before scanning angle and can be be used when we take a sqz data set with SRCL offset steps e.g. 83569 to make 83572 brontosaurus plots.
To take SRCL offset FIS dataset (e.g. 83569):
Take NLG back to nominal ~11, once done.
As a part of trying to diagnose what could be wrong with CHARD Y, I checked the ITMY A2L gains, in case they were so far off that it was responsible for some of the instabilities we've seen. Just based on the magnitude of the changes, I don't think it has been causing any problems.
While we sat at 25 W, after the move spots was completed, I drove a pitch and yaw dither on ITMY using the DOF2 paths in the ADS bank. The pitch line was driven at 19.125 Hz with a magnitude of 5000 and the yaw line at 21.287 Hz with a magnitude of 3000.
I made steps of 0.2 in both the pitch and yaw gains in both directions, and watched the line heights change. I was able to make the lines both higher and lower, so I am convinced that I am at least close to, if not at the minimum. Overall, the change in the gains is not that significant, so I think that it wasn't causing us any problems.
In the screenshot below, cursors mark the location of each line on the red trace.
Sheila Ryan and I phased LSC-REFL_B while we were sitting at 25W after move spots. We used the template in /opt/rtcds/userapps/release/lsc/h1/templates/CARM/check_refl_a_9_phase.xml and adjusted the phase which you can find in the LSC electronics overview. Screenshots of the 200Hz excitation after phasing and the sdf screenshot attached.
Daniel, Kevin, (Erik, Dave), Vicky
Kevin is interested in taking ADF sweeps around the second higher order mode arm resonance near 10.4 kHz.
We (Daniel) made model changes in h1ioplsc0 and h1omcpi that should enable higher freq ADF demods. Daniel built the models successfully. Then Dave also built these models successfully for the custom RCG running on h1omcpi for the variable duotone. We put in a WP to boot in these changes to h1ioplsc0 and h1omcpi next Tuesday 6/10.
From h1ioplsc0, we added 2 new PCIe channels to write the digital ADF LO oscillator out to PCIe. These are H1:IOP-PCI_ADF_VCXO_{COS,SIN} in screenshot 1. We also changed a rogue limiter such that the ADF should be able to scan +/-1 MHz according to the PLL.
In h1omcpi, we use the fast 64 kHz OMC PI user model to do a fast digital demodulation of the OMC_DCPD_SUM signal using the above ADF-LO PCIe channels. This is beating the fast dcpd output signal (H1:OMC-PI_DCPD_64KHZ_AHF), against the ADF LO's cosine and sine components from PCIe (H1:IOP-PCI_ADF_VCXO_{COS,SIN}), to get the demodulated ADF I/Q signals. The demod signals will have names like H1:OMC-PI_ADF_DEMOD_{I,Q}. Screenshots 2-4.
Operationally nothing should change for the ADF or for OMC-based fast PI damping. We are just using PCI to send 2 IPC channels from an IOP model to a user model on a different computer at ~65kHz, and doing the demod in a 64kHz user model (but the demod does not go anywhere, it is just used for squeezer diagnostics).
Model change summary:
h1ioplsc0
+2 IPC senders to H1.ipc
+2 slow channels to DAQ
h1omcpi
(+2 IPC receivers)
+33 slow channels to DAQ
Model changes today seem relatively successful. No way to verify in hardware (yet), but the ADF PLL claims it successfully locks at -11kHz from carrier, so at least the limiter fix in h1ioplsc0 seems to work; in principle the ADF sweep limiter is now set at +/- 1 MHz.
I added a quick ADF demod of the 64kHz OMC DCPD SUM channel into the normal ADF screen, screenshot attached, see the very bottom. New filter banks initialized with values and filters as in the other adf demod chains. Also tried to clean it up in SDF: channels are initialized, gains and phase are monitored, and saved into sdf (h1omcpi model).
Sheila, Elenna, Caroline, Julia
We tested and reconfigured the DRMI ASC, and now we can run all of the DRMI ASC!
I trended the POP A offset yesterday to determine what the new values should be based on the alignment of the PRM once we are in full lock. I set those so we can use the PRC1 ASC loop (attachment 1 and attachment 2).
Then, we sat with DRMI locked and Sheila and I tried moving around PR2, IM4 and PRM to check if the error signals made sense. PRM uses POP A QPD, IM4 and PR2 use REFL A and B 9 MHz signals. We found that the PR2 and IM4 error signals seemed flipped, so we checked all of the REFL WFS signals and even thge POPX signals to see what might be the best new sensing matrix. Eventually, we chose to remain on REFL 9 I, but we flipped the sensing.
We were able to engage all the SRC ASC, except that after a minute or two og engagement, we saw an oscillation in the SRC signals. We eventually turned down the SRC1 P and Y gains, and the SRC2 P gain.
I tried moving the PRM to confirm the PRC1 error signal was ok, and I found that the pitch offset I chose was good, but the yaw offset was not good. So instead I moved the PRM yaw to maximize the buildups, and then reset the the POP A yaw offset (attachment 3).
Then, Sheila and I tried engaging the PRC2 and INP1 yaw ASC, but used the wrong sign for PRC2 Y and caused the DRMI lockloss. Luckily, we quickly recovered, and changed the sign and reengaged. We followed a similar procedure for the pitch ASC, but I stepped PR2 a few times to ensure the sign of the input matrix was correct.
We were then able to engage all the DRMI ASC, using lower SRC1 and SRC2 gains to prevent ringing. Sheila updated the ISC DRMI guardian to use these new input matrix values.
Except for some overall magnitude, the DRMI INP1 and PRC2 sensing has had this change in both pitch and yaw:
old sensing: INP1 = + REFL 9I A - REFL 9I B and PRC2 = +REFL 9I A + REFL 9I B
new sensing: INP1 = +REFL 9I A + REFL 9I B and PRC2 = -REFL 9I A + REFL 9I B
With the ASC engaged, we were able to raise the SRC1 pitch and yaw gains back to their nominal values (updated again in guardian). The SRC2 P loop still has a lower gain.
We've gone back and forth on the correct POP A yaw offset today, and Georgia had changed it again in this alog. However, we just tried to run the DRMI ASC and had a lockloss, so we think my offset was better, so I have again set the POP A yaw offset to be 0.352 and SDFed.
DRMI ASC engaged much better with my offset. I don't know why the full IFO alignment offset is bad for DRMI.
After attention was called to the uneven trending in the temperature of Zone 2A, I checked the heating coil and found that while the automation system was calling for 100% heating, the unit was not heating at all. I found that one of the 40 amp line voltage fuses had blown. This fuse also supplies line voltage to the control transformer which powers the control board, meaning the entire duct heater was down. Further troubleshooting is needed to find the cause of the blown 40 amp fuse, which will likely involve replacing heating elements.
I updated the POP_A P and Y offsets so the DRMI ASC will take us closer to where the full IFO ASC will take us
DOF | Old | New |
P | 0.09 | 0.1 |
Y | 0.35 | 0.15 |
This was reverted - the DRMI alignment and full IFO alignment are not the same. Maybe related to the ITMX P2L gain change we put in which adjusts the pitch of the PRM in 2W full lock?
HAM1 annulus system appears to have issues pumping down, currently its annulus ion pump is railed 10 mA, and the pump cart pumping on this system is sitting at 6.04x10-05 Torr, see attached photo.
Process thus far:
I plan to visit HAM1 to check the rest of the bolts on -Y door and +Y door.
HAM1 internal pressure is doing good, see attached photo of the pressure at the SS-500 pump cart pumping on HAM1. Second attachment is a 5.5 day plot of the pressure internal to HAM1, the large step noted on the plot is due to the introduction of HAM1 ion pump.
(Jordan V., Gerardo M.)
Today we went and performed the following on the annulus system for HAM1:
Now we wait to see the results of today's changes overnight.
TJ, Camilla, Sheila
TJ and Camilla got the HWSs working, and now we turned on the SR3 heater at 15:54 UTC, 2W requested power. This is to do a check of the SR3 heater calibration and range similar to 27262
SR3 heating up can be seen on the HWS signals but is not particulatly clear, see attached.
Looking at when this test was done at LLO, the lens changing happened over a period of three hours and the lens power increased in the same direction on both HWS, so its possible our HWS are not a good witness for the SR3 curvature change.
Aidan calculated 2.45 uD/W at LLO, and we get 9.44 uD/W (from the H1:TCS-ITM{Y,X}_HWS_PROBE_SPHERICAL_POWER trends with an estimated noise of 4.48e-12uD/W.
Looked closer at these HWS signals during SR3 heater heat up and cool down. In all these plots, the two t-cursors are used as the reference and shown HWS live image.
Some strange things:
With the numbers from ITMY HWS only, and looking at the 3hr 11 m cooldown in Camilla's photo, the lens change is 6.68e-6 Dioptres/W taking into account that the HWS beam passes twice through SR3.
After talking with Camilla, she reminded me the change in RoC (delta R) =/= 2/(delta D),
where D is defocus (1/focal length).
but instead delta R = 2/(2/R + delta D) - R
Where R=36.013m is given in https://git.ligo.org/IFOsim/ligo-commissioning-modeling/-/blob/main/LHO/yaml/lho_O4.yaml?ref_type=heads
delta R comes out as 4.3mm +/- 0.18 mm (which is the same order of magnitude as the change Aidan measured in alog #27262 at LLO).
The error was estimated from looking at the noise on the spherical power and propagating through the calculation of delta R.
This morning we changed the demod phase of the POP 9 sensor. The overall summary is that this has a very similar impact to adding a PRCL offset, reducing the PRCL to REFL RIN coupling, and slightly increaing power in the PRC, but not changing the coupling of PRCL noise to DARM. I've turned off the offset, added a new phasing, and updated the PRCL to SRCL subtraction in the LSC input matrix.
More details:
I used a 702.1 Hz frequency noise injection, (template found in userapps/lsc/h1/templates/phase_LSC_sensors_frequency_exc.xml) and adjusted the POP9 phase to reduce the appearance of the frequency injection in Q (screenshot shows initial to final settings change in Q peak). I used Elenna's template to make a PRCL injection and measure the coupling to RELF RIN and DARM during this move, see screenshot. Adjusting the phase reduced the PRCL to REFL RIN coupling in a way that's similar to what Elenna has seen by adjusting the PRCL offset (see 79989 for example). Also similar to what Elenna has seen with the PRCL offset, this has very little impact on the PRCL to DARM coupling. The ndscope screenshot shows how this impacted REFL and POP powers, you can compare the time when I turned off the offset to the time when I tried reverting the phase to the original setting after finding the new setting, the two things have a simlar impact on the reflected power and the power in the PRC.
One interesting observation is that the phase that minimized the PRCL to REFL RIN coupling (as shown by the sign flip in the transfer function), is different from the phase that minimzed the frequency injection coupling to POP 9Q, by 2 degrees. I've left this at the phase that minimizes REFL RIN coupling. The impact on the power build ups is small enough that this two degree difference can't be evaluated using them.
Another observation is that the change in phasing doesn't seem to have an impact on the PRCL spectrum, spectrum screenshot.
Lastly, I did another PRCL excitation to measure the coupling to POP 45 and POP9 I, using the template in userapps/lsc/h1/templates/SRCL/SRCL/SRCL_input_matrix_git_rid_of_PRCL.xml (excuse the typo). I used this measurment to try to zero the PRCL coupling to SRCL ((POP45/PRCL)*MTRX_5_3 + (POP9I/PRCL)*MTRX_5_1 = 0, and found that this matrix element needed to be updated from 0.1185 to 0.1408. This was last updated by Jenne Driggers in 70919. The update reduced the SRCL to PRCL coupling by about 20dB, shown here.
Lastly we edited the guardian to not use the PRCL offset, and update the PRCL to SRCL input matrix element, and accepted the new matrix and phasing in SDF (in the observe file, and now also in the safe file).
Craig killed the lock by changing the POP A 9 phasing rotation by 5 degrees in one go.
Do not do this, instead use some cds step or script to change the rotation by a small amount over some time.
WRT the ISC_DRMI guardian changes, I also implemented the use_DRMI_ASC dictionary into DRMI_LOCKED_CHECK_ASC and OFFLOAD_DRMI_ASC in ISC_LOCK.
Now if we ever need to turn the convergence checker loops off for only some loops, we'll only need to edit lscparams instead of multiple different states inside two different guardians.