Following along Gabriele's work to understand noise from modulation of low frequency lines in DARM, I made a noise comparison today using DARM with no calibration lines. We stayed in NLN CAL MEAS (all cal lines off) long enough to get a good measurement of GDS CALIB STRAIN with no calibration lines. I compared this with GDS CALIB STRAIN NOLINES during times when the calibration lines were on. See attached plot. The difference is small, but I think it is evidence that we are seeing some of these low frequency peaks like the 2.6 Hz modulating the calibration lines and causing excess noise. Even though the NOLINES channel has the calibration lines subtracted, we do not subtract any bilinear effects from the calibration lines. I grabbed a couple different random times from recent locks to make sure I wasn't getting fooled by transient noise.
Our range jumped up to 147-151 Mpc during times when the calibration lines were off, which I think is a combined effect of the additional sensitivity from no lines and also no other peaks from line modulations. Usually our range is around 145 Mpc.
Since the low-frequency noise is now lower at the new lower operating power, the calibration line amplitudes can be turned down proportionally and still achieve the same SNR. Has this been done?
Mode matching of the single bounce beam to the OMC is really bad and we don't know why. We don't even know the beam shape of the single bounce beam hitting the OMC. I constrained the beam shape by looking at the OMC scan data.
There are many OMC single bounce scans but the most recent two w/o RF SBs, one with cold and the other with hot OM2, were carefully analyzed by Jennie to resolve 02 and 20 mode as separate peaks (alogs 70502 and 71100), so I used them here.
If you just want to see the results, look at the third panel of the first attachment.
X-axis is the normalized waist position difference, Y-axis is the normalized waist radius difference. From the measured cold mode matching loss of 11.5%(!!) and hot loss of 6.2%, and the fact that the loss changed by only changing the ROC of OM2, the beam parameters hitting the OMC were constrained to two patches per each OM2 ROC. Yellow is when OM2 is cold, blue is when OM2 is hot. Arrows show how cold (yellow) patches are transformed to hot (blue) patches when OM2 ROC is changed by heating.
Note that we're talking about inconceivably huge mismatching parameters. For example, about -0.3 normalized waist position difference (left yellow patch) means that the waist of the beam is ~43cm upstream of the OMC waist. Likewise, about +0.3 normalized waist radius difference means that the beam waist radius is 690um when it should be 490um.
We cannot tell (yet) which patch is closer to reality, but in general we can say that:
There are many caveats. The first one is important. Others will have limited impact on the analysis.
Moving forward:
Here's a brief explanation of what was done.
Top left panel of the 1st attachment is the mode matching loss contour plot. loss=0 when [posDiffNormalized, sizeDiffNormalized]=[0.0]. Contours are not circular because the loss is calculated analitically, not by quadratic approximation.
Top right panel of the 1st attachment only shows the region close to the measured losses. Yelllow ring is when OM2 is cold, blue is when hot. Each and every point on these rings represent a unique waist size and waist position combination (relative to the OMC waist).
Since we are supposed to know the OMC-OM2 distance and ROC of the cold and hot OM2, you can choose any point on the yellow (cold) ring, back-propagate the beam to the upstream of OM2 (assuming the cold ROC), "heat" the OM2 by changing the ROC to the hot number, propagate it again to the OMC waist position, and see where the beam lands on the plot. If it's on the blue ring, it's consistent with the measured hot loss. If not, it's inconsistent.
Just for plotting, I chose 9 such points on the cold ring and connected them with their hot landing points on the top right panel. If you for example look at the point at ~[0, 0.4] on the plot ("beam too big but position is perfect when cold"), after heating OM2 the beam becomes smaller but the beam position doesn't change meaningfully, therefore the matching becomes better. In this case the improvement is much better than the measured (i.e the landing point is inside the blue ring), so we can conclude that this ~[0, 0.4] for cold is inconsistent with the measured hot loss.
By doing this for each and every point on the yellow ring we end up with a patch or two that are consistent with reality.
If you cannot visualize what's going on, see the 2nd attachment. Here I'm ploting the beam propagation of "beam too big but position is perfect when cold" case in the top panel. The beam between the OM2 and OMC is directly defined by the initial (cold) parameters. The beam upstream of the OM2 is back-propagation of that beam. On the bottom panel is the propagation diagram of when OM2 becomes hot. The beam upstream of OM2 is the same as the cold case. You propagate that beam to the OMC position using hot ROC. In this case the loss, which was ~12% when cold, was improved to 4.3%, that's inconsistent with the measured hot loss of (1+-0.1)*6.2%.
Further summary:
We can probably down-select the patch by 30uD single-path thermal lensing in ITM comp plate relative to the thermal lensing we had in previous scans (alogs 70502 and 71100). Start by a hot OM2. If we see a significant reduction in MM loss after ITM TCS, the actual beam parameters are on the patches in the left half plane.
Details 1:
In the 1st attachment, I took two representative points on the hot patches indicated by little green circles, which define the beam shape at the OMC waist position. I then back propagated the beam to the upstream of ITM (i.e., in this model, optics are correctly placed with correct ROC and things, but the input beam is bad). ITM is at the average ITM position. The only lensing in the ITM is the nominal diversing lens due to ITM's curvature on the HR.
Then I added the thermal lens, once to the beam impinging the ITM HR and once to the beam reflected, and see what happens to the beam parameter at the OMC waist location. These parameters are represented by tiny crosses. Blue means negative diopters (annular heating) and red means positive (central heating). I changed the thermal lensing by 10uD steps (single-path number).
As you can see, if you start from the left half plane patch, central heating will bring you close to ~(-0.04, 0) with 30uD single-path (or 60uD double-path).
OTOH if you start from the right half plane, ITM heating only makes things worse both ways.
FYI, 2nd plot shows, from the left to the right, good mode matching, hot patch in the left half plane and in the right half plane. The beam size on the ITM is ~5.3cm nominally, 5.1cm if in the left half plane (sounds plausible), 6.8cm in the right (sounds implausible). From this alone, right half plane seems almost impossible, but of course the problem might not be the bad input beam.
Details 2:
Next, I start with (almost) perfectly mode-matched beam and change the optics (either change ROC/lens or move) to see what happens. We already expect from the previous plots that ITM negative thermal lensing will bring us from perfect to the hot patch in the left half plane, but what about other optics?
3rd attachment shows twice the Gouy phase separation between ITM and other optics. Double because we're thinking about mode matching, not misalignment. As is expected, there's really no difference between ITM, SR3 and SR2. OM1 is almost the opposite of ITM (172 deg), so this is the best optic to compensate for the ITM heating, but the sign is opposite. OM2 is about -31 deg, SRM ~36 deg. From this, you can expect that SR3 and SR2 are mostly the same as ITM as actuators.
4th attachment shows a bunch of plots, each representing the change of one DOF of one optic. (One caveat is that I expected that the green circles, which repsent the beam perfectly mode matched to the arm propagated to the OMC waist position, will come very close to (0, 0) with zero MM loss, but in this model it's ~(-0.4, 0.1) with ~1.2% loss. Is this because we need a certain amount of ITM self-heating to perfectly mode match?)
Anyway, as expected, ITM, SR3, SR2 all look the same. It doesn't matter if you move the position of SR3 and SR2 or change the ROC, the trajectory of the beam parameter points on these plots are quite similar. These optics all can transform the perfectly matched system to the blue patch in the left half plane.What is kind of striking, though not surprising, is that 0.025% error in SR3 ROC seem to matter, but this also means that that particular error is easily compensated by ITM TCS.
SRM, OM1 and OM2 are different (again as expected). Somewhat interesting is that if you move OM2, the waist size only goes smaller regardless of the direction of the physical motion.
From these plot, one can conclude that if you start from perfectly matched beam, you cannot just change one optic to reach the hot patch in the right half plane. You have to make HUGE changes in multiple optics at the same time e.g. SRM ROC and ITM thermal lensing.
Both Details 1 and 2 above suggest that, regardless of what's wrong as of now (input beam or the optics ROC/position), if you apply the central heating on ITM TCS and see an improvement in the MM loss, it's more likely that the reality is more like the patches on the left, not right.
Dan pointed me to their SRC single-path Gouy phase measurement for the completely cold IFO, which was 19.5+-0.4 deg (alog 66211).
In my model, 2*Gouy(ITM-SRM single path) was ~36deg, i.e. the SRC single-path Gouy phase is about 18 degrees. Seems like they're cosistent with each other.
ITM central heating plot was updated. See attached left. Now there are four points as the "starting points" without any additional TCS corresponding to both hot and cold patches.
According to this, starting with cold OM2, if the heating diopter (single path) is [0, 10, 20, 30, 40]uD, the loss will be [11.5, 7.1, 3.5, 1.1, 0.1]% if the reality is in the left half plane (attached right, blue), or [11.5, 9.9, 10.5, 13.1, 17.3] % if in the right half plane (attached right, red).
Updated to add cold OM2, ITMY single bounce, central CO2 OFF/ON case in alog 71457.
Jennie Wright, Keita Kawabe, Sheila Dwyer
Above Keita says "I assumed that the distance between OM2 and OMC waist is as designed (~37cm). " 37 cm is a typo here, the code actually uses 97 cm, which is also the value listed for OMC waist to OM2 in T1200410
Today I convinced myself that I can reproduce, offline, the filtering and subtraction that the calibration pipeline does.
This enables me to try different GDS FIR filters that Louis has created for me (also offline) by training NonSENS coefficients for that filter, putting the coefficients into the front end to calculate a noise estimate, and then use the noise estimate to offline filter and subtract, to see what the effect would be. All of this last sentence is done out of Observing, so I tried several different combinations during our commissioning window today.
I put a notebook up on git, to remind myself how to do it. In the plot at the bottom, the green and red traces are indistinguishable, which is good, and means that my by-hand filter+subtraction worked the same as the GDS calibration pipeline's filtering and subtraction.
Since I haven't yet gotten an offline front end model working (Erik and EJ showed me how, I just haven't had time yet), I'm still using the actual front end to do the calculation of the noise estimate for me, which is why these tests below had to be done while we were out of Observing.
The tests below are different sets of coefficients, trained on different FIR filter files that Louis created for me. The start and stop times are written, so I can go back and offline filter and subtract, to see what would be the subtraction that we have if we had that FIR filter set in use in the calibration pipeline.
After I was done testing things, I reverted all of the coefficients I had changed this afternoon. It doesn't really matter, since no subtraction is engaged in Observing, but since I don't have good motivation to make them different, I put them back.
TITLE: 07/07 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Commissioning
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 11mph Gusts, 8mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.07 μm/s
QUICK SUMMARY:
H1 is locked (~17hr lock) and in comissioning
TITLE: 07/07 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
SHIFT SUMMARY:
- EX saturation @ 19:38
- Planned 2 hrs of commissioning began at 21:00
- Leaving H1 with Ibrahim, locked at NLN (going on a 17 hour stretch) with commissioning ongoing
LOG:
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 14:41 | FAC | Christina | LSB -> Staging | N | Forklift 2 crates | 15:11 |
| 15:12 | PCAL | Tony | PCAL Lab | Y (LOCAL) | Measurements | 19:06 |
| 15:27 | FAC | Karen | OSB Fire Pump/Wood Shop | N | Tech clean | 16:40 |
| 17:08 | VAC | Janos | EX | N | Check pumps | 17:30 |
| 17:52 | FAC | Kim | H2 | N | Tech clean | 18:07 |
| 18:18 | FAC | Karen | Optics Lab | N | Tech clean | 18:31 |
| 19:01 | VAC | Gerardo | MX | N | Vac work | 21:18 |
| 20:08 | PCAL | Tony | PCAL Lab | Y (LOCAL) | Measurements | 22:46 |
| 21:00 | SEI | Jim | CR | N | Simulines work | 21:50 |
| 21:51 | CAL | Louis | CR | N | CAL measurement | 22:48 |
Compiling recent squeezing levels to look at squeeze losses with recent anti-squeezing, mean squeezing levels. Reminder the expected losses are minimum ~15-20% (see sqz budget). Recent measurements suggest ~35-40% ~32-40% total sqz losses, higher than compared to our best previous obervations of squeezing, where 4.5dB indicated ~30-35% total sqz losses.
edit2: As pointed out by Daniel, these loss estimates are extremely course, mostly useful for us to check if something is extremely wrong, but error analysis required to make real statements about loss based on this. In particular, to estimate loss from mean-sqz* (insensitive to sqz angle rotations + phase noise) -- the loss error bars depend on error in the generated sqz / NLG level, and errors in our measure of mean-sqz levels (w.r.t no-sqz). I don't have an estimate of NLG error bars right now, so this uncertainty is open. To give a sense of the varying loss estimates based on mean-sqz levels, I am adding in some totally eye-balled error estimates of mean-sqz levels, just looking at DARM screenshots in the alogs listed.
| alog | gen sqz (NLG) | anti-sqz (dB) | mean-sqz (dB) | sqz (dB) | est'd loss from asqz | est'd loss from mean sqz |
| 71088, 7/5 | 18.3 dB (22.7) | 16.7 | 13.5 - 14 |
~35% | 40% - 32% |
|
| 70932, 6/28 | 15.5 dB (12.6) | 13.3 | 10.4 - 10.9 |
-3.7 | ~43% | 43% - 36% |
| 70686, 6/21 | ~15.5 dB (12.6) | 13.6 | -- | -3.7 |
~40% |
-- |
Re: IFO output losses without squeezing -- this is best analyzed for no-sqz times from e.g. 70930 with hot OM2. Some no-sqz times early on at 60W (cold OM2, before LSC FF tuning, not sure calibration) in e.g. 70668 (~20min), 70686 (~5min). Analysis of output losses at 60W, with hot vs. cold OM2, forthcoming. edit: Recent info on AS port losses -- see Sheila's log 71087 regarding HAM6 losses w.r.t. OM2 heating (could change IFO-OMC mode-matching differently than SQZ-OMC matching), and OMC single bounce scans with hot OM2 70866, and cold OM2 70409 (can be useful w.r.t. OMC round-trip optical losses).
Re: technical noise limitation, here's a reminder of this log from Naoki 69767. Classical noise corresponds to an effective / apparent loss in the squeezing level, like the ratio (classical noise asd / no-sqz noise asd)^2. If this ratio is e.g. 0.3, this looks like an apparent loss of (0.3**2)~10% in the observed squeezing level. edit: Noted by Daniel, that Sheila's recent cross-correlation estimate of classical (non-quantum) noise 70891 suggests that at 1kHz, classical noise is ~40% of shot noise without squeezing, this is like an apparent sqz loss of (0.4**2)~16%. This technical noise is an extra loss, contributing to the difference between observed sqz vs. anti-sqz levels.
Given output losses & technical noise close to shot noise, anti- and mean- squeezing can provide additional constraints on squeezing losses without subtracting classical noise and ignoring sqz phase noise, which *should* be low. In particular, mean-sqz should provide a good loss estimate since it's also not sensitive to the squeeze angles / mis-rotations, while anti-squeezing could be misleading depending on how the rotation goes.
edit: Looking at recent DARM with high NLG, shot noise squeezing seems to improve with more sqz despite the alog text, so I don't think squeezing is limited by phase noise yet, even at really high NLG's like 20+.
edit2: * the phrase "mean squeezing" refers to an unlocked squeezer with the sqz beam diverter open. In this configuration, sqzing hasn't been phase-locked to the outgoing IFO light yet, so we see just the noise power from sqz added to DARM. In this way, the unlocked "mean sqz" configuration averages over all sqz angle phases (averaging out e.g. phase noise). This case is also unlike anti-squeezing, which adds noise in a controlled way that we have to rotate into (sometimes we don't have the demod-phase range to rotate into anti-squeezing fully; this would bias our measurements of it), and asqz may be subject to random sqz-misrotations from e.g. SRCL detuning/mode-mismatch. Averaging overall sqz angle phases allows mean-sqz to show approximately the average noise variance from anti-squeezing and squeezing, e.g. (V_asqz + V_sqz)/2, aka "mean-squeezing". Extracting loss from mean-sqz levels requires only measures of generated sqz level (=nonlinear gain) and the mean-sqz level, but these measurements need to be somewhat precise to extract meaningful loss data.
Fri Jul 07 10:07:46 2023 INFO: Fill completed in 7min 46secs
Gerardo confirmed a good fill from curbside.
TITLE: 07/07 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 147Mpc
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 7mph Gusts, 4mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.09 μm/s
QUICK SUMMARY:
- H1 has been locked for 8.5 hours
- CDS/SEI/DMs ok
TITLE: 07/07 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 143Mpc
SHIFT SUMMARY:
LOG:
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 14:41 | FAC | Christina | LSB -> Staging | N | Forklift 2 crates | 15:00 |
Since May 11, 2023 22:18 the spectrum of H1:PEM-CS_ACC_LVEAFLOOR_HAM6_Z_DQ seems low. I don't quite see anything in the alog about this. Is this the expected behaviour of this channel?
Yes, that channel is not working. It was unplugged during the run-up to O4 and I wasn't able to find where it was disconnected at - the accelerometer cable disappears into some cable trays that run the length of the output arm. We have some sensor coverage in the area from three accelerometers mounted on the HAM 6 chamber walls.
STATE of H1: Observing at 144Mpc
We've been locked and Observing for 4:32. Everything seems stable, the violins are still damping down.
TITLE: 07/07 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 142Mpc
SHIFT SUMMARY: Lockloss after O4 lock record of 46h25. Reacquisition was all automatic apart from ISC_LOCK edit and violin damping. Handing off to Ryan C
LOG:
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 23:01 | CDS | Dave B | H2 | N | Restart H1 EDC connections. 71120 | 00:00 |
| 23:31 | PCAL | Tony, Oli | PCAL Lab | Local | PCAL setup | 00:26 |
| 23:47 | VAC | Gerardo | MY | N | Working on VAC lines | 00:55 |
| 00:04 | CDS | Dave | Remote | N | CW injections restart (takes IFO out of observing) 71122 | 00:09 |
| 00:09 | COMM | Jenne | CR | N | TOO OAF changes 71124 | 00:11 |
Lockloss after 46h25 in NLN. 1372737707.
No obvious cause, DCPD saturation tag. DARM was the first loop to change attached plot.
NOISE_CLEAN reloaded as requested in 71124.
Back to NLN and Observing at 06:24UTC.
This lockloss has again rung up the violins again, 71063. 1h25m in OMC_WHITENING. ITMY was slowest to damp.
The last lock we had with low violins was the 42hr lock after Tuesday maintenance, 06/27 21UTC to 06/2915UTC. Search for things that changed during that time:
All the modes (both 500Hz and kHz) have been damping down nicely in the last 6hrs of so (EY20 is still higher than expected and we don't have setting for it - have tried finding one few times but it needs more effort).
Daniel and Sheila note that the H1:FEC-8_ADC_OVERFLOW_0_{12,13} are from before the ADC was updated so the real OMC channels are not overflowing, this is just a relic and can be used to see OMC_DPDC being closer to saturating level, could equally see using H1:OMC-DCPD_{A,B}_WINDOW_{MIN,MAX}.
We checked that OMC gain settings were not changed on the 29th June.
Perhaps unsurprisingly given its previous history, the strong 1.6611 Hz comb that disappeared (alog 69791) in late May has resurfaced. It shows up clearly in Fscans; I did some additional digging and it looks like the first traces appear on June 27th in the 12:00-14:00 UTC range. This corresponds in time with some of the work described in alog 70849, but OM2 heater changes don't account for the previous disappearance of the comb; Sheila confirms that heater wasn't on earlier in May. So it's still not clear what's going on.
Update: it's coherent with H1_PEM-EX_VMON_ETMX_ESDPOWER48_DQ and H1_PEM-EX_VMON_ETMX_ESDPOWER18_DQ, and *not* with CS or EY VMON channels.
(Last time we tried to hunt this comb down, I think we didn't have high resolution coherence plots generated to high enough frequencies for these channels.)
Plots attached. The gray dots are harmonics of a separate 99.9989 Hz comb.
It looks like the behaviour of this comb changed again on July 13, shifting slightly in frequency, before then disappearing again on July 14. It is as yet unclear what caused the changes. The attached weekly average Fscan From July 12 - 19 shows these changes around 280 Hz especially.
This comb seems to reappear between 7:30 and 9:00 UTC on July 19, 2023. Hopefully this time range can point to something that specifically changes. See attached daily Fscan image
Edit: I made an error in calibrating mA to mW, changes to this alog are coming soon.
Last Tuesday we stepped up the ring heater and did a couple of DARM offset steps before and after the change.
The first attachment shows the trends of the two sets of DARM offset steps and the two hour transitent of OM2, in that time the power on OMC refl increased by 3%. The next plots show the DARM offset steps, each was for 1 minute and the steps were larger than in 69653 to help make a small change more easily measureable. With OM2 cold, the refl diode still doesn't seem like it makes a nice measurement of the darm offset light reflected by the OMC, with OM2 hot it is clear that we can see the change in OMC refl when the DARM offset steps.
change in HAM6 throughput estimated by AS_C
For both hot and cold OM2, we can use the power change on AS_C to estimate the HAM6 throughput. Calibrating DCPD sum into Watts using 0.858e-3 A/W gives 63% HAM6 throughput for cold OM2 with 60W input power, and 57% throughput for the hot OM2. (A 9.6% decrease in HAM6 throughput from heating OM2) This can be compared to 69653, done with 75W input power (430kW in arms) where Jennie W found 82% throughput of HAM6 (Jennie also used 0.858AW for the DCPD responsivity).
change in darm offset infered by power on AS_C
The power incident on HAM6 (measured by AS_C) increased while OM2 was heating up, as can be seen in the first attachment. The estimate of the amount of sideband/carrier junk light on AS_C with OM2 cold is 627mW/628mW and with OM2 hot it is 634mW/635mW. Of the 15mW increase in power on AS_C, 7.4mW is DARM offset light while 8mW is sidebands/contrast defect light. The DARM offset light at AS_C increased from 54mW to 60.6mW, this should be caused by the change in DARM offset needed to keep the power on the OMC DCPDs constant while the HAM6 throughput changed, so the darm offset increased by sqrt(60.6/54) =6% . This implies a decrease in HAM6 throughput of throughput_cold/throughput_hot = (darm_offset_hot/darm_offset_cold)^2 = 60.6/54 = 1.12 , or 11% decrease in HAM6 throughput from heating up OM2.
OMC mode matching from OMC refl diode
The light which is insensitive to DARM in OMC reflection increased from 623.3/624mW to 634.4mW . Similar to llo 60885, the darm offset light on AS_C times 0.985*0.993 to account for the reflectivity of OM3 and the OMC QPD pickoff, means that there is 53mW/52.6mW of darm offset light incident on the OMC for cold OM2 and 59.3mW for hot OM2. We can estimate the mode matching of the OMC (which could include misalignment) as 1-reflected darm offset light/ incident darm offset light which gives 96% mode matching for the cold OM2 (where the measurement may be suspect) and 85.6% or 85.2% mode matching for the hot OM2. This would imply an 11% decrease in HAM6 throughput from heating OM2.
Optical gain change
The normalized optical gain (kappa c) dropped from 1 to 0.98 while OM2 was heating up. Since the power on the DCPDs is kept constant, the DARM offset changes when the HAM6 throughput changes, and the optical gain should be proportional to the sqrt(HAM6 throughput), which would imply a 4% decrease in HAM6 throughput from heating OM2.
| DCPD sum (mW) | AS_C sum (W incident on HAM6) | OMC refl (mW) | om2 |
| 4.58 | 0.634 | 624 | cold |
| 34.3 | 0.6801 | 626 | |
| 4.58 |
0.635 |
624 | |
| 34.3 | 0.682 | 626 | |
| 4.58 | 0.643 | 636 | hot |
| 34.3 | 0.696 | 643 | |
| 4.58 | 0.643 | 636 | |
| 34.3 | 0.696 | 643 |
gps times:
# DARM offset OM2 scan log file, gps start, gps stop
Please ignore the alog above, I will reproduce it here with corrected numbers with the responsivity used correctly.
Summary: With a cold OM2 we estimate 11% unknown HAM6 losess (including OMC losses, modemismatch, DCPD QE), with hot OM2 that goes to 21%. We can estimate the change in HAM6 throughput 4 ways, three methods that depend on the DARM offset steps agree that the HAM6 throughput with hot OM2 is 90% of what it is with cold OM2. The optical gain suggests that the throughput only dropped to 96% of what it was for cold OM2.
Details:
Last Tuesday we stepped up the ring heater and did a couple of DARM offset steps before and after the change. The first attachment shows the trends of the two sets of DARM offset steps and the two hour transitent of OM2. The next plots zoom in on the DARM offset steps, each step was for 1 minute and the steps were larger than in 69653 to help make a small change more easily measureable. With OM2 cold, the refl diode still doesn't seem like it makes a nice measurement of the darm offset light reflected by the OMC, with OM2 hot it is clear that we can see the change in OMC refl when the DARM offset steps.
change in HAM6 throughput estimated by AS_C
For both hot and cold OM2, we can use the power change on AS_C to estimate the HAM6 throughput. Calibrating DCPD sum into Watts using 0.858e-3 A/W gives 86% HAM6 throughput for cold OM2 with 60W input power, and 77% throughput for the hot OM2. This can be compared to 69653, done with 75W input power (430kW in arms) where Jennie W found 82% throughput of HAM6 (Jennie also used 0.858AW for the DCPD responsivity). We can add up known HAM6 losses from the SQZ loss wiki, 0.993(OM1)*0.985(OM3)*0.9926(OMC QPD) = 97% HAM6 transmission if OMC mode matching, losses and QE were perfect. This means that we have 11% additional HAM6 losses for a cold OM2, and 21% for the hot OM2. (The HAM6 throughput with OM2 hot is 90% of what it is with OM2 cold)
change power on AS_C from darm offset and sidebands/contrast defect
The estimate of the amount of sideband/carrier junk light entering HAM6 based on AS_C is 623mW/624mW with OM2 cold and with OM2 hot it is 634mW. This 10-11mW increase might be due to the alignment shift in the SRC that Elenna plotted 70886 which could be due to the change in gouy phase on the AS WFS when OM2 changes. The total power incident on HAM6 increased by 15mW during the OM2 thermal transient, the light from the DARM offset increased by 6-6.6mW. When the HAM6 throughput changes from cold (eta) to hot (eta') the darm offset has to change from cold X to hot X' = X* sqrt(eta/eta') to keep the power on the DCPDs the same, which increases the DARM offset light on AS_C by eta/eta' (so, as_darm_power_hot/as_darm_power_cold = HAM6 througput cold/ HAM6 throughput cold). This implies that the HAM6 throughput with OM2 hot is 89% of the HAM6 throughput with a cold OM2.
OMC mode matching from OMC refl diode
The light which is insensitive to DARM in OMC reflection increased from 623.3/624mW to 634.4mW . We can estimate the OMC mode matching with an approach like llo 60885: there is 53mW of darm offset light incident on the OMC for cold OM2 and 59mW for hot OM2 (taking into account known HAM6 losses). We can estimate the mode matching of the OMC (which could include misalignment) as 1-reflected darm offset light/ incident darm offset light which gives 96% mode matching for the cold OM2 (where the measurement may be suspect) and 85.4% or 85.2% mode matching for the hot OM2. This implies that the OMC mode matching with OM2 hot is 89% of what it is with OM2 cold.
Optical gain change
The normalized optical gain (kappa c) dropped from 1 to 0.98 while OM2 was heating up. Since the power on the DCPDs is kept constant, the DARM offset changes when the HAM6 throughput changes, and the optical gain hot/optical gain cold = sqrt(throughput hot/throughput cold). Kappa c of 0.98 implies that HAM6 throughput with OM2 hot is 96% of the throughput with OM2 cold.
| DCPD sum (mW) | AS_C sum (W incident on HAM6) | OMC refl (mW) | om2 |
| 6.2 | 0.634 | 624 | cold |
| 46.6 | 0.6801 | 626 | |
| 6.2 |
0.635 |
624 | |
| 46.6 | 0.682 | 626 | |
| 6.2 | 0.643 | 636 | hot |
| 46.6 | 0.696 | 643 | |
| 6.2 | 0.643 | 636 | |
| 46.6 | 0.696 | 643 |
# DARM offset OM2 scan log file, gps start, gps stop
Following up on the DARM bicoherence observation and the non-stationarity of low frequency noise: the noise in DARM between 20 and 40 Hz is correlated with the amplitude of the 2.6 Hz peak
The attached plot is an histogram of the DARM RMS in the 20-37 Hz region (computed by summing bins in a whitenend spectrogram) and the DARM RMS around the 2.6 Hz peak (computed with a band-pass filter between 2.4 and 2.7 Hz).
There is a clear correlation between the DARM noise in the 20-40 Hz region and the RMS in the 2.6 Hz region.
An exploration of where the 2.6 Hz peak is visible and coherent with DARM
The ETMX M0 / R0 / TMSX are interesting signals, maybe something isn't working properly in the R0 tracking loop?
The usual ASC suspects, especially CHARD_Y.
Several DC centering loops.
Some OMC signals.
No smoking gun
I have some evidence that could indicate that this peak is related to some instability in the HARD loops.
First, we noticed this 2.6 Hz peak is very prevalent in the OMC and OM3 suspensions. Evan was tracking the presence of the peak in OM3 yaw and noted it appeared sometime around April 9-14. This was a tricky time because many things happened: we powered up, we adjusted the compensation plates and OMC to reduce scatter, etc. Evan also noticed it doubled in size on June 22, which corresponds to when we went down in power. I used the OMC SUS master out channels as an indicator of when this peak appeared. I noticed it was not present April 7th and then appeared on April 8th, UTC time. More specifically, it appeared in the Lownoise ASC guardian state. This was around the time I was working on removing RPC completely from the ASC control and working with Dan and others on increasing the power. It appears that the peak pops up right when I turned off the RPC and transitioned all the HARD loops to the new high power controllers.
The fact that the peak height doubled when we went down in power also bolsters this theory: if there was something a bit marginal in the loop at higher power, the shift in the radiation pressure plant could have worsened the marginality. To further confirm, I looked at spectra of the HARD and SOFT loops, and the 2.6 Hz peak becomes prominent around the time I changed the loop control and turned off RPC.
As a test, Gabriele and I would like to make small changes in the HARD loop gains and see if we can pinpoint which loop is marginal. If we're lucky, the peak could be fixed with a gain change. If we're less lucky, maybe we need to redo one or more loop controllers.
First attachment is an ndscope screenshot. I plotted the guardian state, RPC gains, and the SWSTATs for all the HARD loops. The cursor is on the time when I hard turned off all the RPC gains and switched the loop controllers. GPStime: 1364955781. This also corresponds to when the peak appears in the OMC suspension channels.
Second attachment is a dtt screenshot of a plot comparing the OMC sus master out spectra now (blue refs) with the spectra on April 7 before the ASC change (red live).
Edit to add: Gabriele and I tested raising and lowering various ASC loop gains but we saw no difference in the peak.
We also hypothesized that this is related to the reaction chain tracking and/or damping. We turned off the reaction chain tracking of ETMX for L, P and R and saw no change in the peak.
Every lockloss after Tuesday maintenance last week has run up the violins.
Even though before this last lockloss the fundamental mode was very low (but harmonics were still elevated) the IFO has relocked with very high violins. Attached is the violins screen and DARM at the LOWNOISE ISC_STATES before we get to NLN.
They look much better now (after few hours of damping) - see screenshot attached (red trace is the current value, blue and green is old data). Not sure what is causing them to ring up after every lockloss. I will keep tracking them, especially after lockloss and new lock acquisition.
I just had a thought, although I'm not sure how much credibility it has. Our higher order violin modes have also been quite high the last week or so. I wonder if we had one as-yet-undetermined something that kicked up all the modes, and then now between locks there's energy transfer from those higher order modes (that we don't damp in lock, so they haven't really been getting smaller) to the fundamental modes. Then each lock we damp the fundamentals (and some of the 1kHz modes), but then the next lockloss puts a little more energy into the modes, and again there's energy transfer between the modes. Would we help this situation if we damped more of the higher order modes? Even if it doesn't directly help, getting those modes damped is probably a good idea (although generally a low priority, since they usually aren't a problem and we have many higher priority items).