After our modifications to the DRMI LSC thresholds and loop gains on Thursday night, we had several short locks. Yesterday, we saw the same good locking behavior again. We found that the reason for the short lock duration was a typo in our trigger matrix: the PRCL boosts weren't getting turned on. After switching those and tweaking some filter shapes, the locking is fast and the locks last a long time.
The first attached plot shows the minute trend of our 4 hour lock last night. The 6 WFS loops are engaged during this time, as well as the DC centering. Near the end of the lock, there is a SRC mode hop and it stays locked like that for 1 hour. There are 20% fluctuations in the SPOP18 and SASY90. The control signal plots in the left hand column are scaled so that the full y-scale is approximately the full suspension DAC range (there is a divide by 4 from the LSC to the SUS DAC outputs). The MICH and PRCL loops are pretty calm, but there are several large transients in the SRCL loop which, I believe, corresponds to the TEM00 -> TEM01/10 mode hop.
The second PDF shows the error and control signal spectra for the DRMI LSC loops during a non-hopping epoch from last night.
PRCL: The error signal is white, so not much to be gained by changing the loop shape. The control signal is dominated by 0.05 - 0.5 Hz as is expected from the ISI performance.
MICH: The error signal is dominated by sub-Hz stuff, so we could squash it better with a 1:0.1 zero:pole stage if we found it necessary. The MICH control signal is dominated more by the sub 0.1 Hz motion than anythin else in the DRMI. Usually we think this is the seismic amplification produced by the seismic isolation system.
SRCL: Similar story to PRCL, but more noise from <0.1 Hz than 0.1-0.5 Hz.
In all spectra, the large line at 131 Hz is a calibration line used for making sensing matrix and demod phase measurements.
After the lock loss, it never got it itself together. The ASC loops stayed railed and kept it from being aligned enough to lock.
Also, the Guardian had a filter writing problem and so it stopped restoring the correct IFO state after the DOWN state
(it was trying to set a filter which was under the control of the LSC filter module trigger logic and stopped because it didn't
get the correct readback. This fault condition should be added to Guardian to make the log file more informative and we
should fix this conflict in the LSC state defs).
After clearing all of that stuff and bypassing the Guardian temporarily, the Michelson, PRMI and DRMI all locked fine.
Our DOWN state triggering during DRMI lock acquisition is probably the main holdup in acquisition times now. Watching the Guardian log files I see that it often just attempts acquisition for several seconds before it then begins a ~30 second period of switching buttons on and off until its ready to lock again. We would be better off adjusting these state triggers such that it stays in the 'trying to lock' state all the time. It should only do any of the DOWN stuff if its gone up into M2 offloading or WFS boost turn ons. We may be able to get a 2-3x speedup by trimming these downtimes.
I had tried reducing the guardian "DOWN" time by sending the guardian to "LOCK_DRMI_1F" if the locking failed as it entered the wfs centering or offloading. This seemed to work on Friday, but there were/are still certain instances where the guardian goes to the "DOWN" state. I have attached an example from the log. Both "OFFLOAD_DRMI" and "ENGAGE_DRMI_WFS_CENTERING" are now suppose to return to "LOCK_DRMI_1F", but it seems that when there is a transition between these two states, it jumps to the "DOWN" state. Jamie and I will take a look at this on Monday.
Sheila and I looked at the Guardian script this morning; I had missed an assert function that would take ISC_DRMI to the "DOWN" state, I have changed this to the "LOCK_DRMI_1F", so hopefully this fixes the problem ....