ISC_LOCK reloaded

Robert had me investigating something similar to this, specifically around the input power changes (4/7 and 6/21). I found that the noise seemed to be strongest after the power increase on 4/7. But it's been hard to tell how it changed after the decrease on 6/21. (I have tons of other reference images but I've attached one from each time period - before the power increase, during, and after.)

Thanks for identifying this! 
These lines have now been turned OFF as of 2023-08-09 16:40 UTC as a result of this study.

Tested the new feedforward fits, they work better than the old ones, so we'll leave them running. ISC_LOCK updated and reloaded.

SDF diffs Accepted

Interestingly, retuning the FF reduced thee 52 Hz peak in DARM.

Much later, we've identified that this routine filter update was informed by a measurement of the IFO incorrectly taken while calibration lines were still on. This causes the measurement fitter to  create a filter that tries to "compensate" for the high-Q feature with some equally high-Q zero:pole pairs LHO:72537. 

Once installed, the impulse response of this zero:pole pair causes hours-long ring-ups in the IFO sensitivity right at the calibration line frequency as the two features mix LHO:72064.

The procedure for taking LSC FF measurements has been rectified now (see LHO:72572), to explicitly call out that calibration lines MUST be turned OFF if you're gathering a set of measurements to be used for FF filter creation.

While I was adjusting the line heights, Jeff let me know about the following tip: 

Stepping the calibration height for one of the ETM{X,Y} SUS lines consists of changing all of the following channels such that they're all reflecting the same amplitude gain value.

Using the TST stage as a reference:
H1:SUS-ETMX_L3_CAL_LINE_CLKGAIN
H1:SUS-ETMX_L3_CAL_LINE_SINGAIN
H1:SUS-ETMX_L3_CAL_LINE_COSGAIN
H1:CAL-CS_TDEP_SUS_LINE3_COMPARISON_OSC_CLKGAIN
H1:CAL-CS_TDEP_SUS_LINE3_COMPARISON_OSC_SINGAIN
H1:CAL-CS_TDEP_SUS_LINE3_COMPARISON_OSC_COSGAIN

For example, here's the command that I used to change the TST line to 0.085:


val=0.085 && caput H1:SUS-ETMX_L3_CAL_LINE_CLKGAIN $val && caput H1:SUS-ETMX_L3_CAL_LINE_SINGAIN $val && caput H1:SUS-ETMX_L3_CAL_LINE_COSGAIN $val && caput H1:CAL-CS_TDEP_SUS_LINE3_COMPARISON_OSC_CLKGAIN $val && caput H1:CAL-CS_TDEP_SUS_LINE3_COMPARISON_OSC_SINGAIN $val && caput H1:CAL-CS_TDEP_SUS_LINE3_COMPARISON_OSC_COSGAIN $val

Although I saw Louis ACCEPT the SDF Diffs for SUSETMx, I think with the safe.snap stuff afterward, maybe it didn't take? 

Anyway, We had SUSETMX diffs again.  So I ACCEPTED the 9-diffs (attached).  Hopefully good for next lock.

Something happened that reverted my changes for CAL-ETMX back to the old settings. Maybe something happened with SDF?

Corey brought us out of OBSERVE for me to restore the new amplitude heights.

Here's the command I used:


caput H1:SUS-ETMX_L3_CAL_LINE_CLKGAIN 0.085 && caput H1:SUS-ETMX_L3_CAL_LINE_SINGAIN 0.085 && caput H1:SUS-ETMX_L3_CAL_LINE_COSGAIN 0.085 && caput H1:SUS-ETMX_L2_CAL_LINE_CLKGAIN 9 && caput H1:SUS-ETMX_L2_CAL_LINE_COSGAIN 9 && caput H1:SUS-ETMX_L2_CAL_LINE_SINGAIN 9 && caput H1:SUS-ETMX_L1_CAL_LINE_CLKGAIN 6.6 && caput H1:SUS-ETMX_L1_CAL_LINE_COSGAIN 6.6 && caput H1:SUS-ETMX_L1_CAL_LINE_SINGAIN 6.6


output:

Old : H1:SUS-ETMX_L3_CAL_LINE_CLKGAIN 0.3
New : H1:SUS-ETMX_L3_CAL_LINE_CLKGAIN 0.085
Old : H1:SUS-ETMX_L3_CAL_LINE_SINGAIN 0.3
New : H1:SUS-ETMX_L3_CAL_LINE_SINGAIN 0.085
Old : H1:SUS-ETMX_L3_CAL_LINE_COSGAIN 0.3
New : H1:SUS-ETMX_L3_CAL_LINE_COSGAIN 0.085
Old : H1:SUS-ETMX_L2_CAL_LINE_CLKGAIN 50
New : H1:SUS-ETMX_L2_CAL_LINE_CLKGAIN 9
Old : H1:SUS-ETMX_L2_CAL_LINE_COSGAIN 50
New : H1:SUS-ETMX_L2_CAL_LINE_COSGAIN 9
Old : H1:SUS-ETMX_L2_CAL_LINE_SINGAIN 50
New : H1:SUS-ETMX_L2_CAL_LINE_SINGAIN 9
Old : H1:SUS-ETMX_L1_CAL_LINE_CLKGAIN 35
New : H1:SUS-ETMX_L1_CAL_LINE_CLKGAIN 6.6
Old : H1:SUS-ETMX_L1_CAL_LINE_COSGAIN 35
New : H1:SUS-ETMX_L1_CAL_LINE_COSGAIN 6.6
Old : H1:SUS-ETMX_L1_CAL_LINE_SINGAIN 35
New : H1:SUS-ETMX_L1_CAL_LINE_SINGAIN 6.6

OK, for this current lock, we had SDF Diffs for SUSETMX (I'm assuming for the previous lock, we did not save the appropriate .snap file (SAFE.snap or OBSERVE.snap?)).

So for this current lock, the OBSERVE segment from 0222-0238 was with the WRONG (9) SUSETMX CAL_LINE channels & I ACCEPTED these diffs to get to OBSERVE.

Then Louis noticed my alog, and saw that we had the OLD values for these (9) channels!  So we immediately ended that OBSERVE segment and worked on correcting SUSETMX.  I'm hoping I am doing this right, but this is what we did for the SUSETMX SDF:

• Louis reverted the values to the (9) channels to what they were supposed to be (see his comment above).
• This brings up SUSETMX SDFs.
• I ACCEPTED these.
• Then I clicked SUSETMX's "SDF RESTORE SCREEN" (orange button)
• On new window, I clicked "! SELECT REQUEST FILE" (black button)
• This opens a gray file window for h1susetmx burt files (.snap files)
• I selected the safe.snap file & clicked OPEN (closing this window)
• I clicked the "LOAD TABLE" button on the "SDF RESTORE SCREEN" window
  • I believe at this point, the SUSETMX sdf screen went from green to light blue, becaue now the TABLE FILE NAME is the safe.snap (table is filled with all the safe.snap files)---so we can't go to Observe.
• Went back to the "SDF RESTORE SCREEN", and clicked "! SELECT REQUEST FILE"
• Selected the OBSERVE.snap file & clicked OPEN
• Clicked LOAD
• And then SUSETMX returned to green and the OBSERVE file was now the "TABLE FILE NAME"

I think that covers everything.  I was able to go back to OBSERVE.  Fingers crossed that for the next lock, SUSETMX has all the CORRECT values for these pesky (9) CAL_LINE channels!  Sorry for not being more diligent on ACCEPTING diffs!  I should have caught the values---I'm glad Louis was online and noticed this from my earlier alog comment!

The reason why Louis' CAL-ETMX gain changes "didn't take" is because they are set by the ISC_LOCK guardian in several places during lock acquisition, including when we reach Nominal Low Noise. This was discovered somewhat recently by Jeff; see his alog 71710 for the full breakdown of the tug-of-war that guardian plays with these gains. Corey and Louis had correctly accepted the new gain values in both the SAFE and OBSERVE SDF tables, but this caused SDF diffs to appear once we reached NLN, preventing us from going into observation.

Since I don't have an answer for how these gains should be set during full lock acquisition, I've just updated the gain values to Louis' new ones for when we reach NOMINAL_LOW_NOISE, not in PREP_FOR_LOCKING or anywhere else. This is set in the gen_NOMINAL_LOW_NOISE() function within ISC_GEN_STATES.py

EDIT: ISC_LOCK has been loaded.

How to turn off RFSBs.

Disconnect the cable for 118MHz on the patch panel at the bottom of the PSL rack (1st picture).

On top of the patch panel there's a 24MHz amplifier, don't turn it off.

On top of the 24MHz thing, there are amplifiers for 9MHz and 45MHz. You will turn off the output of both (2nd picture showing the 45MHz unit with the RF output switch in OFF position).

If we just believe TCS frontend simulation, H1:TCS-SIM_ITMY_SUB_DEFOCUA_FULL_SINGLE_PASS_OUTPUT was ~17.05uD during the last OMC scan before we gave up.

We might be able to use this to distinguish between the two patches in the MM parameter space (update in https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=71477) but I'll wait for the OMC scan fitting results.

Executive Summary: The mode mis-match with no central heating on the ITM is 8.2%, the mode mis-match with central heating on the ITM is 3.6%.

For the first scan:

T0 = 1373734011

delta T = 87s

OMC scan is shown in the first png image.

Fitted C20/02 peak is shown in the first pdf.

We expect the HOM spacing to be 0.588 MHz as per this entry and DCC T1500060 Table 25.

The mode spacing is 148.796 - 149.388 = 0.592 MHz.

The ratio of second order to zeroth order carrier is (0.575 + 0.853)/(0.575 + 0.853 + 15.90) = 0.082 = 8.2 % mode mis-match

To run the code checkout git branch /dev of labutils and run measurement.

python OMCscan_nosidebands3.py 1373734011 87 "Sidebands off, 10W input, cold ITM + OM2" "single bounce" --verbose -m -o 2

and for the split peak fitting:

python fit_two_peaks_no_sidebands3.py

For the second scan:

T0 = 1373736206

delta T = 90s

OMC scan is shown in second png image.

Fitted C20/02 peak is shown in the second pdf.

The mode spacing is 148.741 - 149.338 = 0.597 MHz.

The ratio of second order to zeroth order carrier is (0.201 + 0.428)/(0.201 + 0.428 + 17.02) = 0.036 = 3.6 % mode mis-match

Run the following on the same git branch.

python OMCscan_nosidebands4.py 1373736206 90 "Sidebands off, 10W input, hot ITM + cold OM2" "single bounce" --verbose -m -o 2 -p 0.01

and for the split peak fitting:

python fit_two_peaks_no_sidebands4.py

data is in labutils/omc_scan/data/2023-07-18

files in labutils/omc_scan

figures in labutils/omc_scan/figures/2023-07-18

Summary:

Incorporated the fit results and updated the plot. Original analysis is in alog 71145.

In the attached, there are two pairs of patches, each pair comprising yellow and lighter blue, that represent the previous measurement (alog 71145 where ITMX single bounce was used with no TCS, OM2 hot/cold) and two pairs, each pair comprising greenish blue and darker blue, that represent the measurent done this time (ITMY single bounce, cold OM2, TCS ON/OFF).

Since it's impossible that the beam parameters of ITMX single bounce beam on the OMC are totally different from those of ITMY single bounce, you can just look at the distance between pairs and judge which ones represent the reality. In this case, the patches in the left half plane are the clear winners.

Details and caveats:

Calculation done for the ITMY single bounce is exactly the same as ITMX except that the measured losses are different and the mode actuator is ITMY central TCS instead of OM2.

As for the TCS optical power I  used H1:TCS-SIM_ITMY_SUB_DEFOCUS_FULL_SINGLE_PASS_OUTPUT~17uD for the central heating (zero for no heating). I simply doubled the number for double-pass effect. If this is grossly off the result might look different.

Since 1st order HOM power was not negligible in ITMY single bouncer scan, as a first order approximation, I used P2/(P0+P1+P2) as the measured mode matching loss where P0, P1 and P2 are the power of 00, 1st order and 2nd order mode (for the 2nd order mode, 20 and 02 were resolved by the fit code). I've done this to ITMX single bounce scan too just for consistency.

If the model is perfect and has everything, the difference between yellow "X, OM2" and greenish-blue "Y, OM2 Cold/TCS OFF" should be explained by the difference in the ITM ROC, substrate lensing/heating including the TCS (and IFO heating prior to lock loss, since we haven't waited for hours and hours after the IFO was unlocked). It would be interesting to see if ITM difference will make the plot look any different.

However, the model doesn't have ITMX and ITMY, it's just a single ITM at the average location. Though it's easy to implement that feature in principle, I have a suspicion that the numbers used for ITM substrate lens effect in the past could be off, and I've contacted GariLynn. Wait for the conclusion of that discussion.

A big caveat is that you cannot quickly draw conclusion about the full IFO mode matching from this. At the very least, you have to take into account that the arm mode is primarily determined by the HR and that the carrier coming to OMC from inside the arms only experience the ITM lensing once (-ish).

Another big caveat is that the ADC was railing for the 00 mode peak. Look at the 2nd attachment bottom where H1:OMC-DCPD_B_STAT_MIN=-(2^19). It's not as bad as the finesse measurement (alog 71888) as the scan was slower, but if we want a better data we need to redo it with lower power or w/o x10 gain.

Last attachment shows what happens when you change OM2 (left, 1 step in the plot = maximum range of the T-SAMS) or ITM heating (right, 1 step = 10uD single pass).

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