ASC showing up in displacement / roll mode ringup

a) The first plot, middle graph, shows coherence between ASC loops and DARM. CHARD shows up very prominently - it's narrow stop-band get imprinted on the coherence. The same noise is also seen in IMP1_P, but it is likely just a witness, since it shares sensors with CHARD. Bottom lime: CHARD needs a proper low-pass.

b) The first plot, bottom graph shows some coherence between the 20Hz-100Hz excess and ASC_MICH_P. ASC_SRC2_P also shows it, but might again just be a witness (it uses AS_C as error signal). That excess BTW is all glitches.

c) The roll mode was seen to ring up over the 2h lock. Interestingly both ETMX and ETMY modes seem to be ringing. Since DARM feedback only goes to ETMX, but CHARD goes to both, I again suspect CHARD. Again: CHARD needs a proper low-pass.

The bounce and roll mode ringups were due to human intervention -- Chris and I stayed a bit later last night working on the violin mode damping, and we couldn't resist changing the gains on the feedback loops, enough that things became unstable.  At 09:10 UTC when Stefan took his DTT spectrum, the gains on the feedback were nonzero, which impresses bounce & roll mode noise on the M0 stage OSEMs.  When the feedback gain is zero you can't see these modes in the top stage OSEMs -- this makes identifying the optic that's bouncing or rolling a challenge.  It may have been only one ETM was rolling, or an ITM (although I suspect both ETMs thanks to the ASC loops, as Stefan says.)

The attached images from the summary pages show the roll mode increasing around 09:40 UTC, when we realized our feedback was hurting more than helping.  After this I zeroed the gain on the DARM --> ETM M0 feedback and the mode stayed the same height for the rest of the night.  (When the noise got very bad after 11:00 UTC the bounce mode stayed pretty much the same.)

That said I would not argue against some roll-off filters for CHARD!

The attached screencaps show the roll mode damping setup that has worked well for us, tonight. (ETMX gain 10000/ETMY gain -600)

Updated user environment configuration script to include LD_LIBRARY_PATH and PYTHONPATH environment variables.

Due to miscommunication, SRM was aligned briefly at 15:01 UTC. Take SRM off the list of SUS that have been free and undisturbed for these hours. We'll get him on Thursday.

ITMX ISI Tripped at 16:14 UTC. Take him off the list.

Period of free resonances is now closed as of 16:30 UTC. Other maintenance activity begins!

The weird REQUEST states where my fault.  I pushed a new version that I was going to deploy tomorrow, and there was a very minor bug that I've now fixed.  Restarting the node should fix that problem.

Still don't know what the epicsMutex thing is about...

I have attached a plot comparing our various configurations:

1. Red trace: RF DARM sus compenstation as designed by Peter to obtain more phase margin. The LSC DARM configuration is: FM1(suscomp), FM2(2:0), FM3(resG), FM4(4^2:1^2), FM5(2:0), Gain 800 (LHO#16728, 16840)

2. Blue trace: Our old RF DARM sus compenstation where we used the LLO control filer and a 200Hz lead filter. (LHO#16381)

3. Green trace: ALS DIFF sus compensation. This is the configuration we use to lock ALS DIFF. The LSC DARM configuration is: FM1(suscomp), FM2(2:0), FM3(resG), FM7(SB60), FM8(acqLP),FM10(RLP33), Gain 400. As Stefan mentioned, FM1+FM8 returns our old LLO control filter.

I have also attached the RF DARM OLTF model with the new (red) and old (blue) configuration as described above, along with the respective measured data. The RF DARM UGF is now 55 Hz with a phase margin of ~45deg.

Measurement of new DARM loop on dc readout is attached.

I've saved Evan's .xml to the calibration repository here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Measurements/DARMOLGTFs/2015-03-09_DARM_OLGTF_LHOaLOG17153.xml
and exported text files of the transfer function and coherence,
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Measurements/DARMOLGTFs/
2015-03-09_H1_DARM_OLGTF_LHOaLOG17153_coh.txt
2015-03-09_H1_DARM_OLGTF_LHOaLOG17153_tf.txt

Transfer function contains the following columns (i.e. I exported IN1 / IN2 "as is"):
Frequency [Hz]    Real Part [ ]    Imaginary Part [ ]

We'll use later for calibration / noisebudget model verification!

Also including the CARM OLTF that we took at 9 W.

I checked the measured DARM open loop transfer function posted by Evan against my DARM open loop model. Even though I did not do a fitting or any fancy analysis yet, it seems that the optical gain was consistent -- the measurement matched the model with an optical gain of 1.1x10⁶ cnts/m or 9.09x10-7 m/cnts which we have been using since Feb. 21st (alog 16843) for the CAL-CS front end model.

Here is a plot showing the model and measured one:

The matlab script to generate this plot is archived in calSVN:

 /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Scripts/DARM_OLTFGTF_LHOaLOG17153.m

Note for myself:

optical gain in the model = 1.1e6

ESD strength in the model = 2.8e-10 [N/V^2] (see alog 16843)

LSC_DARM_GAIN = 800 (instead of 400)

Only ETMX was actuated

We have changed the INCREASE_POWER state in the ISC_LOCK guardian, it now turns the power up to 10 Watts and adjusts both the power normalization and the gain in the summing junction to keep the CARM ugf around 9 kHz.  

This worked several times with the rotation stage going pretty fast ("velocity" set to 100) but we have now slowed the velocity down to 10 so that things are not as exciting.  

Once people had tuned up the alingment to improve the recycling gain, it no longer works to increase the power with the high recycling gain.