aLIGO LHO Logbook

H1 ISC

sheila.dwyer@LIGO.ORG - posted 10:34, Tuesday 18 June 2019 - last comment - 14:05, Tuesday 18 June 2019(50029)

PRMI ASC states, a fix for MICH BRIGHT

I did a little bit of PRMI ASC this morning while we were unlocked because of the earthquake but before maintence day was in full swing.

For MICH I used ASB45Q, and for PRC1 (feedback to PRM) I used REFLA9I. The BS oplev damping is left on while the PRMI ASC is on, otherwise we get a pitch oscillation.
I've added these states to the DRMI guardian, there are states for PREP_PRMI_ASC and ENGAGE_PRMI_ASC which have been tested.
Edit: for now the PRC1 loop is not engaged in PRMI ASC, because we had some locklosses when engaging it. We can come back to this but won't spend more time on it today.
I also added a PRMI_ASC state which has a convergence checker for the error and control signals, the thresholds currently in are arbitrary and need to be adjusted, and an offload state which hasn't been tested either.

INIT_ALIGN

As operators have started using the INIT_ALIGN guardian one thing people have noted is that MICH_BRIGHT often doesn't lock on the first try.
There was a check for large outputs in ACQUIRE_MICH_BRIGHT and ACQUIRE_MICH_DARK, but the thresholds were set too high, so I've lowered them.
Now if the MICH outputs become larger than 1e5 in either MICH BRIGHT or MICH DARK, the ALIGN_IFO gaurdian will go back to down and try again.

Comments related to this report

jenne.driggers@LIGO.ORG - 13:45, Tuesday 18 June 2019 (50034)

Link

As Patrick is bringing back the IFO from maintenance, the PRMI locks are have very low POP18 and POP90 values, and it looks like we might be touching the low side of the gain bubble, because things keep oscillating, then we lose the PRMI lock before the PRMI ASC can come on.

I tried by-hand changing the CHECK_MICH_FRINGES state to a mich bright state (just hand flipped the sign of the gain), and then tried the initial alignment mich bright ADS settings, which dither the BS, demodulate AS_DC, and actuate on the BS. I'm not sure why, but this didn't seem to bring the BS to a better alignment. I only tried twice since I don't want to delay the IFO recovery by much, but I think that we should someday investigate this as a follow on to the PRMI work that Sheila has done today.

sheila.dwyer@LIGO.ORG - 14:05, Tuesday 18 June 2019 (50036)

Link

A few more guardian changes:

(Almost) One click initial alignment:

The INITIAL_ALIGNMENT state in ISC_LOCK is now set up to use TJ's INIT_ALIGN gaurdain. So in principle the only thing an operator needs to do now for initial alignment is click INITAL_ALIGNMENT in ISC_LOCK. Patrick tried this and found that he had to touch up the y arm alignment, which is probably going to happen fairly often for now.
In our first attempt to do INITIAL_ALIGNMENT this way, we also had a problem with the IMC guardian becoming stalled, it unlocked after the X arm IR lock dropped as usual but wasn't unstalled. I added an unstall_nodes decorator to INITAL_ALIGNMENT to fix this problem next time.
Also in this first attempt, the ETM suspensions weren't managed by ALIGN_IFO, which probably happens after the charge measurements are run. I added a request to ALIGN_IFO to go through INIT before it starts the inital alignment, which should fix this problem.

PRMI changes in ISC_LOCK:

We added an optional path in the PRMI brach of ISC_LOCK that will run the ASC, wait for it to converge, and offload it. This hasn't been tested, but you can request it by asking ISC_LOCK to do PRMI_ASC.
We lost lock from PRMI a couple of times, and realized that there was no lockloss checking for PRMI. We added a new state to ISC_LOCK called LOCKLOSS_PRMI.
We added a timer in ACQUIRE_DRMI_1F so that after it has been attempting to lock for 10 minutes, it will go through PRMI. The idea is that eventually this will run and offload the PRMI ASC, then come back to DRMI. We will wait until we have tested the PRMI ASC more before actually putting that in the path.