I've updated TRANSITION_FROM_ETMX
to activate the new DARM configuration directly. On the next lock we'll test whether we can transition directly into this configuration smoothly without having to move to ETMY before settling in.
svn commit version: r27235
On Wednesday, while testing filters in the "New DARM" state, the ETMX roll mode was inadvertently rung up (I assume it was ETMX because that was the suspension we were changing filters on). It dominated the DARM RMS long enough that I figured I could get a fit of the ringdown and measure the via the OMC DCPD sum.
I extracted the data during the ringdown time, after the filter that was driving the mode was turned off. I split the data up into smaller segments and estimated the height of the peak in the ASD and fit a decaying exponential. The estimated Q of this mode is about 6173 with an estimated frequency of 13.759 Hz. The resulting plot of the exponential fit is show in the third attachment. I performed the fit by taking the logarithm of the data and fitting a linear regression- the resulting r-squared value was 0.998, so I think this is a very good fit. However, I made no estimate of the background for this fit, so there may be some bias in the fit itself. I tried to perform a more precise fit of the damped sinusoid using a digital heterodyne, but I'm unhappy with my curve fitting algorithm. I think ultimately that may be a better way to get a more accurate Q (but if I'm being honest I am unlikely to follow through on that work unless someone really wants me to).
However, I think this is still a pretty good measurement, especially given that Jeff measured a Q of about 7000 for the ETMY roll mode. It is a bit high, given the goal of the BRD was "a Q between one and a few thousand" (quoting Norna's slides from https://dcc.ligo.org/LIGO-G1600371). From a practical point of view, within 10 minutes the roll mode was back to nominal anyway.
Fri Mar 15 10:12:31 2024 INFO: Fill completed in 12min 27secs
Gerardo confirmed a good fill curbside.
With the offset on the AS_A WFS centering, that should lower DHARD_Y coupling to DARM:
https://ldas-jobs.ligo-wa.caltech.edu/~gabriele.vajente/bruco_1394535464_DARM
Indeed, DHARD_Y coherence with DARM is much lower. Interestingly, now CHARD_Y coherence seems higher.
In other news, there is some coherence with MICH, but hopefully the retuned FF filter will help with that.
Coherence with input jitter witness is also large, see for example the PSL periscope
[Trent, Georgia]
We were curious if the coherence between DARM and the PSL periscope accelerometer was improved with Craig's Wednesday night input alignment. Though there wasn't much time without glitches or excitations during this lock, we got a 700 averages with 75% overlap bw 0.1Hz. In the attached plot, top is DARM ASD, bottom is coherence with the PSL periscope accelerometer (witness sensor for jitter), and right plot is zoomed in on some of the jitter peaks. It looks pretty convincing that for the resonances above 100Hz, the coherence was lower with the new input (and full IFO) alignment on Wendesday.
According to some of the sensors in HAM2 and HAM3, we might have walked the input pointing further in PIT than the O4A alignment, so maybe there is an IM1 and IM3 alignment somewhere in between the two times in the attached plot that has even lower input jitter coherence.
Attachment shows DARM × PSL acceleration coherence on 13 Dec (red), 11 Jan (turquoise), and 16 Mar (black). There is no significant difference between the latter two.
OM2 was hot on 13 Dec and cold on the latter two.
Picket Fence on nuc5 stopped updating 18:44 Thu 14mar2024 PDT. I killed the frozen window and started the code by hand on nuc5 via a vnc connection, it is updating again now.
TITLE: 03/15 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 4mph Gusts, 3mph 5min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.28 μm/s
QUICK SUMMARY:
IFO is in locked and in NEW_DARM.
Other:
Lines started at 7:52am LT on CDSWS35
[Gabriele, Louis] we added a counter increment at the end of the run method in the NEW_DARM state (ISC_LOCK). The missingself.counter += 1
was causing the state to continuously setLSC-MICHFF_GAIN
andLSC-SRCLFF1_GAIN
to 1. This incidentally caused at least one lockloss as Gabriele was trying to run a MICH feedforward measurement tonight. this was on line 6207
[Louis, Gabriele]
We did again the noise injections for retuning the MICH FF, analysis and fit will follow tomorrow.
New fit done, loaded into FM2, not tested yet.
We tested the new FF, and it didn't perform as well as expected. However
We therefore used the measurement to fit another MICH FF, we'll test it soon
Gabriele created two new filters in FM1 and FM2 to try out in DARM. Currently, we are using FM3. I ran an injection using the current filter, and then for each of Gabriele's new filters. Overall, if we want the most suppression 10-20 Hz, we should go with the current, FM3. If we want to do better 20-40 Hz, we can choose one of the new filters. FM2 is worse from 40-70 Hz, but I'm not sure how much that matters. FM1 will inject a few dB more noise than the others from 7-10 Hz, again, not sure how much that matters. I am staying with FM3 pending some evaluation.
[Louis, Gabriele]
The DHARD_Y to DARM coupling always showed two regimes: a steep coupling below 20-30 Hz, and a flatter coupling above 20-30 Hz. We've been able to change the flatter coupling above 20-30 Hz by changing the ITMT Y2L coefficient.
Today we confirmed a suspicion: the steep low frequency coupling is due to length to angle coupling at the AS WFS. We changed the beam position on the WFS by adding an offset to the WFS centering (H1:ASC-AS_A_DC_YAW_OFFSET) and saw a change in the DHARD_Y to DARM coupling.
A value close to -0.14 gives the minimum coupling below 20 Hz. we now have two independent knobs to minimize the DHARD_Y to DARM coupling at all frequencies.
Incidentally, the higher frequency couping is now lower than yesterday, with the same ITMY Y2L coefficient of -1.65
We did a scan of the AS_A_WFS Y centering from -0.2 to -0.1 in steps of 0.01, an analysis will follow tomorrow:
-0.200: 1394510627 - 1394510727
-0.190: 1394510777 - 1394510877
-0.180: 1394510927 - 1394511027
-0.170: 1394511077 - 1394511177
-0.160: 1394511227 - 1394511327
-0.150: 1394511377 - 1394511477
-0.140: 1394511527 - 1394511627
-0.130: 1394511677 - 1394511777
-0.120: 1394511827 - 1394511928
-0.110: 1394511978 - 1394512078
-0.100: 1394512128 - 1394512228
0.000: 1394512278 - 1394512378
We are leaving a value of -0.14 in the WFS offset
Attached is a comparison of the DARM sensing function with no AS A centering offset vs an offset of -0.14. With an AS A centering offset of -0.14, which we found to be the value that results in the minimum amount of coupling to DARM below 20Hz, the sensing function clearly shows optical spring-like characteristics. This brings to mind a few thoughts: 1. This supports the idea that coupling from the DHARD loop into DARM has a noticeable effect on the structure seen in the sensing function at low frequencies. We've been wondering about this for some time, so it's nice to finally have a direction to point in. 2. We tend to adjust the src detuning by constantly measuring the sensing function and trying to find an SRC offset that results in a flat sensing function at low frequencies. The fact that DHARD also couples with DARM in such a way that it can affect the shape of the sensing function at low frequencies begs the question: could we be in fact further detuning the src while intending to do the opposite due to confusion caused by the dhard coupling effects? 3. I recall being told that sometimes squeezing gets better with some level of detuning. If our only measure of SRC detuning is from measuring and inspecting the sensing function then this measurement hasn't been clean due to the DHARD coupling. lots to think about..
Here's a more detailed analysis of the AS WFC centering steps.
The first plot shows the steps in ASC-AS_A_DC_YAW_OFFSET compared with a DARM spectrogram, during a DHARD_Y injection. The spectrogram shows that there is minimum in the coupling of DHARD_Y to DARM around -0.15 / =0.16.
The second plot shows the transfer function from DHARD_Y to DARM for all values of the offset. A value of -0.15 gives the lowest coherence and the lowest coupling, so that seems to be the optimal value. One can notice how the transfer function phase flips sign as expected when one goes through the minimum coupling.
Changing the AS_A centering offset also moved SR2, SRM and BS.
I tried stepping the REFl WFS A and B DC offsets in yaw similarly to see if the CHARD Y coupling to DARM would change. In summary, I stepped between -0.2 and 0.2 for both WFS and saw no change.
Method: I set a 30 second ramp on the offsets because the DC centering loops are slow. I stepped first in steps of 0.01, and then 0.02. I injected a broadband CHARD Y injection and measured the transfer function to darm between 10-30 Hz. I saw no change in the coupling while I made these steps.
Before checking on the calibration change in DARM and DHARD, I check on the thermalisation effect with the coupling.
I chose long duration locking time (Mar. 16, 05:30:00 UTC ~ 15:30:00 UTC) without centering offset, and selected start, middle (10:30:00 UTC) and end time within the time window.
Three plots are; 1) DARM, 2) DHARD PIT, 3) DHARD YAW.
In addition, I included screenshot of ndscope to confirm the time window.
As the 'end' time data in all plots show different trend compare to the other times, it seems that the thermalisation affects DARM and DHARD.
Checked on the calibration lines in DARM and DHARD with centering offset on/off conditions.
To minimize the thermalisation effect, time for the comparison were chosen within short time window.
Figures are; 1) Comparison altogether, 2) DARM comparison, 3) DHARD PIT, 4) DHARD YAW, 5) Screenshot of the ndscope around comparison time.
It can be confirmed that the peaks of calibration lines were same in DARM with and without the centering offset. However, for DHARD, only YAW showed calibration lines, and with different peak magnitude (lower in without offset).
I updated the front end calibration with 20240315T012231Z. I also tried to update the GDS pipeline but ran into errors (attached as gds_error.txt ). I accepted the attached SDFs on observe.snap and checked that safe.snap for the CAL-CS was clear. screenshot.
Naoki, Dhruva, Nutsinee
Yesterday we had only 3dB squeezing at IFO so we checked squeezing at homodyne. Although the visibility is good (98.5%), the squeezing was only 4.5dB at homodyne with 6dBm CLF6. We reduced the CLF power and recovered 8dB squeezing as shown in the attached figure.
The CLF6 was reduced from 6dBm to -42dBm and the 8dB squeezing was obtained with -38dBm CLF6. The CLF6 between -38 and -20 dBm gave similar squeezing so we set it at -24dBm, which is similar to O4a value and corresponds to 8uW CLF_REFL_LF_OUTPUT. The squeezing at IFO is recovered to 4.5dB with -24dBm CLF6.
Note that the LLO also saw the better squeezing at IFO with less CLF power in LLO70072.
We had 6.5dB squeezing at homodyne in 76040 and 4.5dB squeezing at IFO in 76226 with 6dBm CLF6 before. The question is why we lost squeezing at homodyne and IFO this week with same CLF power? The commissioning list in 76369 might give us a clue.
At high CLF power we have about 12 uW of light for CLF and RLF after the OPO. Each homodyne PD has 0.5 mW of power, or 1 mW total. This yields a CLF/RLF to LO ratio of 0.012. Using the equation Gamma^2/2 to get the modulation index, we obtain an estimate of 150 mrad for the maximum phase modulation. In reality, it will be somewhat smaller since some of the power will be in amplitude modulation. This will limit the maximum amount of achievable squeezing on the homodyne. But, this has no bearing on the DCPDs, since the CLF/RLF to LO ratio there is approximetaly 5000 times smaller.
A bit more details on this.
The power ratio between SB and CR of each sideband is approximated to be ~ (gamma/2)^2 where gamma is modulation depth in radian. Add the two sidebands together you get (gamma^2)/2.
A total power transmits through the OPO during high CLF case was 12uW. A total LO power hitting the HD was 1mW. So the phase noise contribution to HD sqz was
(gamma^2)/2 = 12uW/1mW
High CLF phase noise (gamma) at the homodyne = 154mrad (max)
A total power transmits through the OPO during low CLF case was 0.6 uW. A total LO power hitting the HD was 1mW. So the phase noise contribution to HD sqz was
Low CLF phase noise (gamma) at the homodyne = sqrt(2*0.6uW/1mW) = 35mrad (max)
These number include amplitude modulation. It's the worse case that could possibly happen. Using 45 mrad of phase noise and *16dB of asqz fits the high CLF squeezing of 6.5 dB in the homodyne. 15 mrad and 16 dB of squeezing fits the low CLF squeezing of 8 dB in the HD.
For the IFO case we've only injected sqz using low CLF so far. All the sideband power gets attenuated by the OMC (a factor of 5000). The LO (IFO carrier) is ~40mW. Phase noise contribution from CLF/RLF sidebands is 0.08 mrad, which is negligible. Even for high CLF power (RF6 = 6 dBm) this phase noise would be 0.3 mrad. That number is still negligible so there's no reason why we shouldn't be able to see good squeezing with high CLF. Using **15dB of aSQZ and a loss of ***30% we have 5 dB of squeezing as observed on Friday.
*ASQZ trace overlapped with 16 dB aSQZ reference in HD https://alog.ligo-wa.caltech.edu/aLOG/uploads/73562_20231018171710_8dB_hd_sqz_2023Oct18.png
**15 dB of aSQZ in DARM https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=76426
*** If I'm reading this noise budget correctly the inferred loss in the IFO is 30%.
Gabriele, Louis We've successfully run a full set of calibration swept-sine measurements in the new DARM offloading (LHO:76315). In December, I tried running simulines in the new DARM state without success. I reduced all injection amplitudes by 50% but kept knocking the IFO out of lock (LHO:74883). After those repeated failures, I realized that the right thing to do was to scale the swept-sine amplitudes by the changes that we made to the filters in the actuation path. I prepared four sets of simulines injections last year that we finally got to try this evening. The simulines configurations that I prepared live at/ligo/groups/cal/src/simulines/simulines/newDARM_20231221
. In that directory are 1.) simulines injections scaled by the exact changes we made to the locking filters, 2.-4.) reductions by 10,100, and 1000 of the rescaled injections that I made out of an abundance of caution. The measurements we took this evening are:2024-03-15 01:44:02,574 | INFO | File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20240315T012231Z.hdf5 2024-03-15 01:44:02,582 | INFO | File written out to: /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20240315T012231Z.hdf5 2024-03-15 01:44:02,591 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20240315T012231Z.hdf5 2024-03-15 01:44:02,599 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20240315T012231Z.hdf5 2024-03-15 01:44:02,605 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20240315T012231Z.hdf5
We did not get to take a broadband PCALY2DARM measurement as we usually do as part of the normal measurement suite. Next steps are to update the pyDARM parameter file to reflect the current state of the IFO, process these new measurements, then use them to update the GDS pipeline and confirm that is working well. More on that progress in a comment. Relevant Logs: - success in transitioning to the new DARM offloading scheme in March 2024: LHO:76315 - unable to transition into the new offloading in January 2024, (we still don't have a good explanation for this): LHO:75308 - cal-cs updated for the new darm state: LHO:76392 - weird noise in cal-cs last time we tried updating the front end calibration for this state (still no explanation): LHO:75432 - previous problems calibrating this state in December: LHO:74977 - simulines lockloss in new darm state in December: LHO:74887
the script i used to rescale the simulines injections is at /ligo/groups/cal/common/scripts/adjust_amp_simulines.py
. it's the same (but modified) I used in LHO:74883.
On Updating the pyDARM parameter file for the new DARM state: - copiedH1OMC_1394062193.txt
to/ligo/groups/cal/H1/arx/fotonfilters/
(see Nov 28, 2023 discussion section in LIGO-T2200107 regarding cal directory structure changes for 04b). Since pyDARM logic isn't fully transitioned yet, I also copied the same file to the 'old' location :/ligo/svncommon/CalSVN/aligocalibration/trunk/Common/H1CalFilterArchive/h1omc/
. - i also copiedH1SUSETMX_139441589.txt
to both (corresponding) locations. - pyDARM parameter file swstat values were updated according to what was active at 1394500426 (SUSETMX and DARM1,2) the git commit encapsulating the changes to the parameter file can be found here: https://git.ligo.org/Calibration/ifo/H1/-/commit/119768de95a66658039036aca358364c1d39abe4
here is the pyDARM report for this measurement: https://ldas-jobs.ligo-wa.caltech.edu/~cal/?report=20240315T012231Z