In March, Louis and Gabriele found an AS_A yaw offset that reduced the coupling of DHARD Y to DARM (76407) We've been running with this offset since.
Today I quickly checked that this is still the offset that minimizes the coupling, it still is close to the right offset.
Thu May 09 10:10:18 2024 INFO: Fill completed in 10min 14secs
Jordan confirmed a good fill curbside.
Gabriele looked at the nonstationarity of the SRCL coupling in 77666, and proposed DHARD P as a degree of freedom that could be responsible.
This morning I measured the SRCL to DARM transfer function with and without a small offset in the DHARD P error point. I chose an offset of 10 counts which is about the rms of the DHARD P error signal (spectrum attached). This changed the coupling from SRCL to DARM (with the feedforward on) by 20%. So indeed it seems that we need to reduce the RMS of the DHARD P loop to have a stationary SRCL coupling.
Excitation with offset on: 5/9/24 16:16:52 UTC - 16:20:39 UTC with offset off we took a longer stretch of data in case it is useful to look at: 16:21:47-16:34:18 UTC.
Out from 1600-1900UTC (9-12PT).
Back to Observing at 1858UTC.
TITLE: 05/09 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 155Mpc
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 8mph Gusts, 5mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.13 μm/s
QUICK SUMMARY: Observing for 4.5 hours. The relock was full auto, but lost lock at DRMI 3 times before it finally worked.
TITLE: 05/08 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY:
Random lockloss just before shift and one in the 2nd half of shift. Reacquisition for both was straightforward.
LOG:
Much different evening from last night. After the lockloss before the shift, H1 was able to get all the way back up to NLN without an alignment (just tinkering for ALS/PRMI alignments). H1's been locked for 4hrs and all is well.
Attached are monthly TCS trends for CO2 laser and HWS. Nothing notable of note in the trends.
TITLE: 05/08 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Corey
SHIFT SUMMARY: Locked for 10.5 hours before a sudden lock loss just happened. There was some commissioning time this morning which bumped our range up a bit, so hopefully when Corey gets it back up we will be back above 160 again.
LOG:
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 16:06 | VAC | Janos, Jordan | MX | n | CP dewar pumping | 16:51 |
| 16:07 | SUS | Camilla, Erik | remote | n | ITMX awg testing | 16:51 |
| 16:07 | SQZ | Sheila, Andrei | CR | n | SQZ meas. | 19:14 |
| 16:52 | FAC | Tyler, Eric | EX | n | Chiller yard alarm investigation | 17:11 |
| 21:38 | SQZ | Terry, Kar Meng | Opt Lab | local | SHG work | 23:32 |
| 23:30 | vac | jordan.janos | mx | n | turning off cp5 pump | 01:00 |
We lost lock, and took that as a chance to go back to our SR3/SR2 alignments from before April 23rd. The attached screenshots are of the AS camera once we went back to the old alignment, and then after we moved SR2 to center the beam on AS_C. You can see that the beam has fringes when centered on AS_C.
In order to center on AS_C we had to move -54 urad in pitch, (which would move the beam on SRM upwards), and -27 urad in yaw (moving the beam in the -X direction on SRM)
This is a larger shift than what is suggested by Jenne's look at times when we ran AS_C centering in 77690 .
TITLE: 05/08 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 17mph Gusts, 12mph 5min avg
Primary useism: 0.04 μm/s
Secondary useism: 0.16 μm/s
QUICK SUMMARY:
H1 just had a lockloss as I arrived and Sheila/TJ were investigating alignment into/around the OFI. Winds are lighter than yesterday thus far. Microseism also turned down from the step up 24hrs ago (now hovering just above the 50th percentile).
22:48 UTC Lockloss. There was a 5-6 Hz oscillation in DARM and a little wiggle 10 ms before the lockloss.
Alena Anayeva has been working on some zeemax modeling to help us understand what happened when our output arm seems to have changed on April 22/23rd.
She has been using shifts in alignment based on slider numbers as reported in 77388, but the shifts that this is giving her are too large.
This is a quick look at the slider calibrations. There is a discrepancy for SR2, the slider calibration agrees with the M2+M3 osems, M1 osems are reporting a 62% smaller shift. For SR3, the sliders and osems agree to within 10%.
After the large shift we have been falling off the SR3 optical lever, so that is not a useful comparison.
Back to Observing after planned commissioning and calibration.
Locked for 7 hours.
Andrei, Sheila
This morning we are taking the commissioning time to get a sqz data set similar to 77133 with longer averaging time and no other changes to the IFO happening in parrallel.
Data times:
After this data collection, we ran SCAN_SQZANG, which resulted in a demod phase of 184.35
In the attached screenshots the units are different in the top and bottom plots, I filed a dtt bug because the plot disappears if I try to change the units on the bottom plot: 403
Late post of the subtracted quantum noises (FIS (+FDAS) and FDS).
While differences in dB look big on those plots, see these comparisons of just the quantum noise models relative to the total noise (FIS and FDS) -- below 100 Hz, these are really marginal / small differences in the quantum noise, which by 100 Hz is order 2-5 times below total DARM noise. So inferring low-frequency (<100 Hz) quantum noise paramters does require quiet glitch-free (rejected) long averaging times to nail down. So, this helps appreciate why figuring out low-freq quantum noise models is kinda tricky, given we can only measure the total noise in different sqz configurations. So far this analysis code is here.
Note due to the glitch in the no-sqz time, median averaging is required, or else we need to truncate to before the glitch (e.g. 400 seconds vs the full 600). Updating the noise budget environment to run median averaging, which requires the updated (but not fully updated) version of scipy, is underway so noise budget code can use median averaging.
I think several things related to quantum noise budgeting have changed since this sqz dataset in May 2024 (i.e. post-vent, including srcl detuning & fc detuning lho79929 amongst many other things) - so likely another sqz dataset in this vein is needed for more accurate quantum noise budgeting in O4b.
The parameters here in the figure titles are what was used to produce the quantum noise trace. It is rather "simple" at this stage, it does not yet include mode-mismatch, etc. The models do not match measurements well below 40-60 Hz, in part because noisy measurements (note the short 10-min measurement times).
Notably anti-squeezing does not match models well below 80 Hz, see anti-sqz vs. models after subtracting classical noise here. Including mode-mismatches may be able to resolve some of the discrepancies, but so far kinda unclear.
Wed May 08 10:11:08 2024 INFO: Fill completed in 11min 5secs
Gerardo confirmed a good fill curbside.
Erik, TJ, Camilla. 16:00UTC to 16:45UTC
Continued troubleshooting awg issues in ITM in-lock charge measurements 77059. Erik had new code to monitor awg and we took ESD_EXC_ITMX to COMPLETE with amplitude of excitation 1000 smaller (so it will not effect SQZ data taking).
First time the excitation didn't come though, Erik suggested restarting the GRD code 'guardctrl restart ESD_EXC_ITMX'. After this, it worked fine. Tested with both the production awg (tested on ITMY) and Erik's awg version (tested on ITMX).
Unsure why we didn't have this issue on ETMs. Had to take the nodes back to manged when complete by taking SUS_CHARGE though INIT. Reverted amplitudes to nominal values.
h1susitmx and itmy were restarted on April 9 because of a Dolphin crash see https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=77040
h1susetmy and h1susetmx didn't need to be restarted, so have been running since March 12. I think if a Guardian node opens an excitation on a model that's been restarted, the node must also be restarted.
There's one bit of confusing evidence: Last tuesday the excitation status bit for h1susitmx was set during the charge measurement and cleared after, even though excitation output was zero (see attached image). This is inconsistent with a guardian node merely needing a restart, in which case the excitation bit isn't set. Camilla pointed out that there were other excitations sent during the charge measurement that could explain the status bit.
Jenne D, Ryan S, Camilla C, TJ S
Today in a single bounce 10W configuration we set SR2 to center AS_C with the SRC2 ASC loops via the ALIGN_IFO guardian in the SR2_ALIGN state, then moved SR3 in steps to see how our AS_C power would change in different positions. We found that there is an area, or spot, that we lose significant throughput to AS_C, but moving around this spot in any direction recovers our nominal single bounce power. This is followup from Jenne Driggers SR3/2 move (alog77388) to bring back our power at the AS port on April 24th, and Jennie Wright, Minhyo, and Sheila's efforts searching in yaw to find where we are losing the power (alog77513). This time we went further than Jennie W and team went and managed to get back almost all of the AS_C sum back. Almost all because just before we got there we starting running into a different, perhaps clipping, issue that changed the shape of the AS air camera in a much different way than when around this spot.
More details:
We started out by reverting the alignment to a time during DRMI locking from the Tuesday morning of April 23. We then brought up tried to move SR2 and SR3 as was done previously, then Jenne suggested that we turn on SRC2 to have SR2 follow our SR3 moves and keep AS_C centered. This worked great along with a little extra SRC2 gain to help move things along faster. Moving in pitch in either direction yielded fairly quick power gains (trends SR3 -P move & SR3 +P move). Jenne suggested that we try to go further in yaw than the Jennie W. team did to see if it ever improves, and we were able to get AS_C almost back after ~550urad in SR3 (trend SR3 -Y move today, and SR3 +Y move April 24 ). If I had the time I'd love to make a nice graphic to show where we can't go but we'll have to deal with this table for now.
| Pre April 24 | May 07 10:39 | May 07 11:03 | May 07 11:39 | Post April 24 | |
| Start | -P move | +P move | -Y move | +Y move | |
| SR3 P slider value | 438 | 81.9 | 798 | 438 | 438 |
| SR3 Y slider value | -148.8 | -148.8 | -148.8 | -686.3 | 120 |
Here's a screenshot of the AS air camera when we were at the edge of our SR3 -Y move. The beam spot began to squish and spread across the screen a bit more.
Here are some trends with SR2 and SR3 M1 osems during these moves.
EDIT: Added a revamped table with the SR2 and SR3 OSEM changes. The deltas from these could all be found by subtracting the "Pre April 24" value from each column for each move. These values are the final position when AS_C power was recovered to nominal values.
| Pre April 24 | May 07 10:39 | May 07 11:03 | May 07 11:39 | Post April 24 | |
| Start | -P move | +P move | -Y move | +Y move | |
| SR3 P slider value | 438 | 81.9 | 798 | 438 | 438 |
| SR3 Y slider value | -148.8 | -148.8 | -148.8 | -686.3 | 120 |
| SR3 P M1 osem | -290 |
-674 |
112 | -263 | -292 |
| SR3 Y M1 osem | -616 | -592 | -640 | -1018 | -405 |
| SR2 P M1 osem | -570 | 3040 | -1955 | 503 | 596 |
| SR2 Y M1 osem | 11 | 34 | 28 | -2164 |
1160 |
Sheila, Jennie, Alena
Alena realised during her calculations of the spot positions on the OFI at different SR2 and SR3 alignments, that the osem value quoted in the table above for SR2 P M1 osem should be +570.
Sheila alos saw this when looking at osem trends.
Sheila, Camilla.
After this morning's windy lockloss from TRANSISITON _FROM_ETMX, we continued previous 77366 troubleshooting.
Sheila manually stepped though TRANSISITON _FROM_ETMX:
[RyanS, TJ, Jenne]
We've had 2 locklosses today that seem to be about when that MadHatter Darm FM2 gets turned off. But, since Sheila and Camilla moved the filter turning off, now the locklosses are happening a little later.
As Camilla points out, the ramptime of that filter inside Foton is very short. I've increased it to 3 seconds and we're about to give it a try (since I don't have a better plan to try right now). Something we haven't seen (since we're already locked right now) is whether increasing the ramp of that filter inside Foton causes trouble for the engagement of that filter, in DARM_OFFSET.
EDIT: Indeed we made it through the turning-off of the MadHatter filter with this 3 second ramp time (rather than the previous 0.1 sec ramp). I am hopeful that it won't matter for the turning-on of the filter, since that happens in a quite stable part of the locking sequence. But, we'll just have to see over the next few lock acquisitions.
Also EDIT: If we are unable to relock with this ramp time, attached is a screenshot of the previous ramp time, that we should revert to.
We've now relocked twice with the longer ramp time in the MadHatter filter in place for the turn-on and turn-off actions of that filter, so it seems fine to leave in place.
In the observing stretch that started Monday around 8 pm, there was a drop in optical gain (by 4%), and power at AS port PDs (4% drop in AS_A sum, AS_B sum, AS_C sum, and OMC REFL). There not at that time any change in circulating power in the arms, PRG, coupled cavity pole, or alignment of suspensions (shown are SR2, SRM, OM1+2, but we have also looked at many other suspension, ISI and HEPI related channels for this time 77382 ). This time is shown by the first vertical cursor in the attachment.
We were unable to relock the interferometer after that Monday evening lock (a new lockloss type appeared early Tuesday morning, 77359), and after the maintence window we were uable to lock with difficulties powering up (77363) and an AS camera imagine that had lobes whenever the beam was well centered on AS_C. We locked that evening by adding large offsets to AS_C's set point, (77368). This is the cause of the large alignment shifts seen in the screenshot on Tuesday evening to Wed morning, which allowed us to lock the IFO but created a large scatter shelf and resulted in a lower coupled cavity pole, and lower optical gain, and we did not have much squeezing that night.
We do not think that Tuesday maintence activities are the cause of our problems, although some of the Tuesday work has been reverted (77350 77369).
Yesterday we spent much of the day with SRY locked, single bounce or using the squeezer beam reflected off SRM to investigate our AS port alignment. 77392, We are able to recover the same throughput of a single bounce beam to HAM6 by moving the alignment of SR2 + SR3 by a huge amount 77388, which also produced a round looking beam on the AS camera. We haven't since tried to explore this aperture, to see if we could have also recovered this thoughput with a pitch move, for example. We also saw that the squeezer beam does not arrive in HAM6 with a good transmission when injected with the alignment used previously, but that we could recover good transmission to HAM6 by moving ZM5 by 150-200 urad, in pitch or yaw. With this shift in SRC axis, and squeezer alignment we were able to relock and not have the large scattering issues we had Tuesday night.
Today's time was spent recovering from a seemingly unrelated problem in the SQZ racks, and some commissoning aimed at recovering our previous (165Mpc) sensitivity with this new alignment. This will continue during tomorow's commissoning time.
additional related information:
Adding some trends, which have otherwise been mentioned. The optiocal levers and top mass osems suggest that there hasn't been any shift in the PRC, Michelson, or arms. There was also not a shift in alignment of the SRC in the first low optical gain lock on the 22nd, that alignment didn't shift until the manual move of the SRC in the recovery effort.
Camilla notes that the OFI temperature controler had unusual behavoir in the Tuesday relocking attempts: 78399
comparisons of single bounce throughputs: 77441
