Tagging OpsInfo and guardian since this log includes some big changes.

Tonight after several tries and failures I have found a workaround for the carm offset reduction sequence that should get us locked. I have adjusted the code and proofread it multiple times, but it is currently untested in the sense that I have not run it, I have only replicated in code the steps that I took to get us locked.

The major problem I faced tonight is that I could not engage DHARD at DHARD WFS; the CARM offset that is set in CARM_150_PM is just too far off the fringe to make the DHARD signal any good. I found that as soon as the CARM OFFSET REDUCTION state ran, the DHARD signal was actually useable for control. The first thing CARM OFFSET REDUCTION does is set H1:LSC-TR_CARM_OFFSET to -7, whereas CARM 150 PM ends with this offset at -3. I found that getting this offset to -7 or -8 sometimes is close enough to make the DHARD signal "real". I tried just setting the value in CARM 150 PM, but I had one lockloss with that strategy, not sure if it was the cause. I finally decided that I think the correct order here (for now) should be CARM 150 > DARM TO RF > PARK ALS VCO > SHUTTER ALS> CARM OFFSET REDUCTION > DHARD WFS. DHARD WFS usually comes right after DARM TO RF so this involves moving the DHARD engagement up a bit. This is a little risky, as anyone who watches the AS camera during carm offset reduction knows, because the arm alignment starts to get really shaky as the arms get closer to resonance. However, I've been doing a version of this for a bit now as a part of debugging this sequence and I think it generally works.

Besides that problem, we had several locklosses tonight around CARM 5 PM, which is where Sheila made several changes to follow our "new recipe" for getting CARM to REFL. A major change we are making here is that we are further reducing the CARM offset and further bumping up the PRCL gain while it is on REFLAIR 27I. PRCL seems to be losing too much gain as we reduce the offset and it causes locklosses when we reach resonance. However, once PRCL is on POP, the gain is fine, so Sheila and I chose to edit the LSC input matrix value. I had to correct some errors to ensure the correct intrix value is changed and that it is changed to the correct value. Then, I realized that in our "recipe" steps, we actually ran the entire usual CARM 5 PM state first, then we an our new steps which hard codes a TR carm offset and such. So, I edited the code to run the usual CARM 5 PM steps, then if we set this "after_power_outage" value to True, it will also run the additional recipe steps.

That is a lot of words, so below I am going to write down the steps of what should happen, if all goes correctly:

• guardian is run as normal through to DARM_TO_RF state
• instead of going to DHARD WFS, the guardian should go next to PARK_ALS_VCO (and then shutter als)
• after the CARM_OFFSET_REDUCTION state, the guardian should go to DHARD WFS (this is out of order numerically and ladder-wise, but I confirmed the new graph shows this)
• after DHARD WFS, the guardian should run CARM 5 PM
• during CARM 5 PM, the following should happen:
  • the "normal" CARM 5 PM code should run which goes from about line 2648 to 2672. at the end of these steps the TR CARM offset should be a number between -48 and -49, depending on what the code calculates
  • then, if self.after_power_outage is TRUE the code should:
    • set the TR CARM offset to -52 and wait 5 seconds for the ramp
    • increase the TR CARM gain to 2.1 and wait 5 seconds for the ramp
    • set the TR CARM offset to -56, and set the LSC AIR3F matrix value for PRCL (REFLAIRB27I) to be 1.6 times the value it already is, so 1.6*-1.22 and then wait 5 seconds for ramp
    • load the AIR3F matrix which should ramp the intrix value set above, and increase the DHARD P and Y gains to their "resonance" values, -30 and -40 respectively
    • then it should return True
  • if self.after_power_outage is FALSE, the state should return true instead of running the extra steps
• Then, CARM_TO_REFL should run and the rest of the steps can proceed as normal

Here are some other details:

Since DHARD WFS was behaving bizarrely, I did leave the green shutters open and check the green alignment once the ASC converged, using the normal technique of running the green QPD offsets while the IFO ASC converges so the green alignment follows the IFO alignment. Once that completed, I checked and all the offsets appeard to be the same, the largest difference being less than 0.1. Therefore, I concluded that it is unlikely that we need to reset the green alignment, and that whatever is causing the DHARD issue is not because we are in a bad alignment.

When I moved DHARD WFS around in the ladder, I realized that this messes up the IDLE_ALS option. I'm hoping that this DHARD change is temporary, so I just commented out the ladder options that include IDLE_ALS.

We had a mystery lockloss during MOVE SPOTS that I don't understand.

Based on our calculations of the PSL>IMC throughput, I determined that the PSL power should be set to 62 W requested, which should give us 56 W on IM4 trans (we get about 91% now verses 93% before the power outage). I confirmed that is the case, IM4 trans is 56.7 W now, before we went to laser noise suppression (where ISS second loop is engaged). I edited the NLN power value in LSCparams and I reloaded both ISC_LOCK and LASER_PWR guardians.