Over the last few weeks we've done some work on ARM ASC loops, mostly for the hard modes.  

We've been in the HARD soft basis for a few weeks (19752 19775).  Changing to HARD/SOFT was didn't seem to have negative consequences for us, we don't think that it changed our A2L decoupling much. Our method tuning the coefficents before the change was not very precise, some of the coefficents are now different by up to 50%, but they were probably just not correct a few weeks ago.

In the past two weeks we have been retuning the loop shapes for the hard arm loops. There were three motivations:

• We had locklosses both durring the CARM offset reduction (REFL trans 19243) that were due to a DHARD instability (20055), and from full lock that seemed to be from arm signals contaminating other ASC signals, in particular the SRC alignment (19855).
• We had 10% or more fluctuations in optical gain with frequencies around 0.05-0.1 Hz, which we monitored with a BLRMS around a calibration line.  Although there was no conclusive evidence, watching ASC error signals it seems that the fluctions in CHARD (Yaw especially) on the same timescale could be the cause of the optical gain fluctuations.
• We have been in the hard soft basis, but we are running optical levers on the ITMs and not the ETMs.  We have had some instabilties when we turn them off.  We don't understand why the damping helps us stay stable. 
• The DHARD yaw loop had several marginally stable ugfs, and
• CHARD loops had very low ugfs, below 0.1 Hz.

DHARD retuning was fairly sucsesfull, we added boosts to both DHARD loops that seem to help our stability at high power.  Neither of these loops has a cut-off, which we need to add.  We have locked a few times without op damping, but turned them back on due to instabilities. 

We then moved on to CHARD, where we have rather bad SNR in the sensor (the sum of the REFL 9 I signals).  We had very low gain loops here (both less than 0.1 Hz) because we had previously seen that increasing the gain added noise in DARM.  We tried rephasing the refl 9 wfs by driving a line into the mode cleaner, and by driving CHARD in pitch.  (20364 and at a higher TCS power: 20368) This rephasing did seem to cause any stability problems, and could be fine tuned. We then increased the bandwidth for the CAHRD loops.  This introduced large non-stationary noise into DARM, which might have been made worse by a non-optimal alingment.  Last night we reduced the amount of non-stationary noise by reverting to our old, low gain loops (with cut offs and leads still added).  There was some remaining coherence with CHARD (non-stationary, up to 90 Hz).  Today we think that we fixed some SRC alignment issues (20519) which we think is the reason why the coherence with CHARD has been reduced.  However, we still have coherence with CHARD from time to time. 

Nominally, our next steps would be to try to find a better error signal to use for CHARD, by driving excitation in CHARD, im4, and one of the PRs to check if our input matrix can be improved. We could also think about running DC loops to TMS to create an AC coupled signal to blend with refl for CHARD. To improve the stationarity of DARM we could be more agresive with cut off filters or decrease the bandwidth more. UPDATE: Evan and I looked at the sensing matrix for refl tonight and it seems like the phasing of 45 is way off.

Open loop gain measurements:

DHARD PIT 20144  Since this measurement Evan has added a resonant gain at 0.46 Hz tonight to squash the instability we sometimes see.  

DHARD YAW 20084 no changes to this loop that I know of since the measurement. 

CHARD PIT 20497 This gain has since been reduced by 6dB, and neither of the boots are used.  

CHARD YAW 20499 Since this measurement 20 dB of gain was removed, the MS boost was removed (a gentle boost with a pair of complex zeros at 0.5 Hz that adds 25 dB at DC), a 2:3Hz lead filter was added and a 30Hz elliptic low pass was added.  

Spectra of the error and control signals are attached.  So are the control filters, CSOFT and DSOFT are the same, so only CSOFT are plotted. Obviously, the soft loops could be improved, but we haven't gotten to that yet, and aren't sure if we will. 

Times in UTC (PST)

• Started off shift with Commissioning crew working on H1
• 2:45 (7:45):  Gerardo & Kyle back from banging around at Y28 (near EY)
• Able to help out a little with getting H1 up and also picking Sheila & Evan's brains about acquisition questions I had.
• Fairly quiet night and the plan is for a little more commissioning and possibly some long stretches of lock tonight for Nutsinee's shift.

Sheila, Gabriele, Elli, Evan

The message:

We think that some of the trouble we've been having with ASC could be because the sensing matrix for AS36 can change quite a lot when the alignment changes, and our DC coupled oplev servo on SR3 PIT has been introducing an alignment drift.  A drift of 0.3 urad in SR3 seems to have caused many of our headaches this week.  On the one hand it seems silly that we were not resetting the oplev offset regularly (that was my fault), but on the other hand it seems strange that a rather small misalignment can change our sensing matrix this much. 

The problems:

We've had a long history of changing the input matrix for AS36 I to SRM, rephasing AS 36 WFS .  This has seemed mysterious at times, that the matrix we need changes as we power up, and that once a month or so we have had to retune them.  

This week we have had a particularly bad time with alignment related problems.  Monday we had a temperature excursion in the PSL, and the periscope PZT lost power (20396), after this something has changed in the PMC (20490), and the spot position on IM4 trans moved.   Although we think the change was upstream of the IMs we were unable to fix it with the PZT and mode cleaner mirrors.  Yesterday we moved IM3 to bring the spot back to the same position on IM4 trans.  We've had fast locklosses within 10 minutes of powering up (20465), the pernicious 0.46 Hz instability that can be fixed by increasing DHARD PIT gain (20404), several changes of the sensing matrix for AS36 (20465 20512 20497),  huge nonstationary noise with high CHARD bandwidth, and coherence with CHARD drive signals in DARM that came and went with the non stationary noise (20497).

This morning TJ, Jim, and other operators were losing lock in the ENGAGE ASC state.  With Gabriele they traced it down to the change in the SRC matrix.  Yesterday we found that AS36 A I was the best signal to use for SRM control as we powered up, by watching all the error signals as we powered up, moving SRM to maximize build ups and choosing a signal that responded to SRM and had a zero crossing in a good location. This morning the same method of choosing an error signal indicated that we should use only AS36 B I.

 Gabriele and I saw that the signal we were using for BS control was sensitve to SRM moving.  At 3 Watts we opened both the BS and SRM loops, and found a matrix that would make the BS signal insenstive to SRM motion. 

While Gabriele and I were checking the sensing for AS36 as we increased the power, Elli noticed that SR2 and SRM witness sensors had moved between midnight UTC on August 10th and August 11th, which is approximately coincident with the start of these problems. After we lost lock, I restored SRM and SR2 pitch to their previous locations based on the witness sensors, and locked SRY, first with the DC coupled oplev on then with it off.  The spot on AS_C was off in pitch by about half a beam width, and came back to nearly centered when I turned off the DC coupling on the oplev servo.  The moves all in pitch were: SR3 -0.3 urad, SR2 +6 urad.  

After we reset the offset and relocked, the BS signal (AS B 36 I) was insensitive to SRM alingment, and the input matrix for SRM yaw that seems good is the same as what we had last week and for several weeks previous: -3 for AS A 36 I and 1 for AS B 36 I.  We have been stable throughout power up since this.  The coherence with CHARD is greatly reduced, and mostly below 20 Hz.  The spectrum  is more stationary, but we still have some non stationarity.  Gabriele looked at a spectrogram and a coherence gram, and sees that the non stationary noise in DARM no longer coresponds to times when the coherence with CHARD is high.  

Since moving SR3 we have had the 0.46 Hz instability again.  This time Evan added a ResG in DHARD P to give us some gain at that frequency (instead of increasing the FM gain which leaves us with very little phase margin).  We plan to add this to the 23Wboost filter that gets turned on when we power up. 

Kyle, Gerardo 

Today we closed the 10" BT gate valve at Y2-8, vented and removed the isolated port volume hardware -> Next we installed the new large custom reducing tee, 8" gate valve, (2) 1.5" angle valves, 1.5" tee, 10" blank and gauge at beam tube port Y2-8 -> we also pumped out this new volume and sprayed helium on the new joints -> The next task will be to position the new ion pump and stand/director assembly and couple it to the hardware installed today

I got a factor of 3 or so reduction in motion (Figure 1) of a test stand blade spring with a captured mass on Viton pads that attaches to the end of the blade (Figure 2). I think that further development requires a better test stand with a loaded blade spring.  The damper is made of a 3” long, 1” square steel bar on adjustable Viton pads held inside a square aluminum tube with a 1.25” inner diameter. I think this should be reasonable to install (see photo of blade spring in place, Figure 3). In my setup I use a C-clamp to attach it to the blade spring in place of a small integrated clamp like the magnet-free blade clamps designed for SUS. I suspect that the Q is higher for the real setup than for my setup, so the improvement may be better in real life.

C. Cahillane, J. Kissel

I have taken a look at our measurements of the actuation coefficients on ETMY L3 as reported by  LHO aLOG 18767.
We have three measurements of actuation:  Free Swinging Mich, ALS DIFF VCO, and PCAL, which each have different measurement values and uncertainty bars.

The measurements were significantly different, so I looked for mathematical motivation for seeing if the weighted mean and uncertainty calculated in aLOG 18767 was meaningful.

I found a document that walks you through the basics:  Understanding Data Better with Bayesian and Global Statistical Methods by William H. Press.  The document claims that if the chi^2 value is outside the range of (N-1) +- sqrt( 2*(N-1) ) where N = number of measurements, then our measurements are incompatible and our weighted mean has no justification.

For our actuation coefficients:
chi^2 = 72.4250
acceptable range (N=3) = [0, 4]
(Calculation of the above found here: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Scripts/ETMY_L3_Actuation_Coefficient_Compatibility_Test.m )

Our chi^2 is clearly outside the acceptable range, meaning that at least one of our measurements has high systematic uncertainty that renders our weighted mean are poor estimate of the actuation coefficient.

Bayesian methods are advocated to identify the problematic measurement and appropriately quantify our actuation coefficient given our current measurements and uncertainty, or else we may search our measurement methods of sources of systematic uncertainty.

Times in UTC (PST)

15:15 (8:15) Karen opening rollup door in receiving.

15:54 (8:54) Fil to roof.

17:00 (10:00) Fill off roof.

17:11 (10:11) Jason, Ed to optics lab.

17:26 (10:26) Kyle, Gerardo to Y28 port on Yarm

17:48 (10:48) Gerardo back from Y28

17:57 (10:57) Gerardo to EY to look at a wireless card

18:30 (11:30 Kyle, Gerardo back

20:30 (13:30) Kyle, Gerardo to Y28

22:10 (15:10) John to Y28

Summery:

Locking this morning wasn't too sucessful, it would drop lock at ENGAGE_ASC every time in what seemed to be the same place. Jim W and I decided to run that state by hand in a Guardian terminal. Doing this showed that changing matrix elements in ASC input yaw, for SRC1 from AS_B_REF36I to AS_A_REF36I was dropping the lock. We got Gabriele involved and he saw that the error signal was no longer good for AS_A. Gabriele and Sheila have changed some things around and it seems to be holding lock now though!

A follow up on how the "new" old, slower FE computers have been running from Jim Batch:

If you trend H1:FEC-88_CPU_METER over the last 45 days, you can see 
what the h1susetmx was using before we installed the new "faster" 
computer, and when we reinstalled the original computer. 

After the "faster" computer was installed, changes were made to the
model which increased the amount of time the model uses, so now it is
over the limit frequently. 

On the DAQ test stand, we removed a portion of the changes that were
made which only calculated values and reported them with EPICS
channels.  That can be done in the corner station instead of sending 
the signal to the end station to be calculated.  The saving was 
3 to 4 uS which is enough to keep the model running under the max 
limit most of the time.

ECR E1500376 has been filed to move violin mode monitoring channels off of these machines and into the OAF one.

The Butterfly and Drumhead modes of various optics are summarized below.  This is taken from work performed by Calum, etal (CIT) in T1500376 on most optic types, and Slawek (MIT) in T1400738 on the test masses.

Note, I have only summarized the x-polarized butterfly mode because all of our drives to optics are along that axis, not the +-polarized direction.  It would be hard to drive the +-pol mode so we don't think we'll see them anyways.  As well, the modeled x-pol is the same freq

First attachment: Coherences are huge berween TMSX IR QPD SUM, PIT and YAW for 100>f>8Hz in full lock. So many peaks. These appear only when the beam is on QPD.

TMSY QPDs, though not featureless, don't show much coherence and the noise is almost featureless for f>8Hz.

Though X QPDB YAW doesn't show coherence with SUM in this specific plot, this is not always the case (at other times other DOFs loose coherence). Seems like this is dependent on either IFO alignment or TMSX alignment or both.

IN1 of each segment is about 10k counts maximumin full lock, far from saturation.

SUM bump at around 9Hz  is about 10^-5 RiN/sqrtHz.

Second attachment: All segments have the same structures. (16Hz peak is probably the roll mode.)

This is in RF full lock, 2.2W, and the peaks look different from the first attachment (e.g. 12Hz bump is a lot smaller relative to 9Hz bump, there are 2nd, 3rd and maybe 4th harmonics of 9Hz bump).

The 9Hz bump is O(10^-5) RIN/sqrtHz again.

In both QPDA and B, seg1 and seg4 are larger than 2 and 3.

For QPDA, SEG1 is coherent with SEG4 (in-phase) but not with SEG2 and SEG3, while SEG2 is coherent with SEG3 (out of phase) for f>8Hz. SEG1 and SEG2 look kind of out of phase but the lack of coherence means that this doesn't mean much.

For QPDB SEG1 is coherent with SEG2 and SEG4 (1 and 2 in-phase, 1 and 4 out) but not as coherent with SEG3. SEG1 and SEG3 might be in-phase with the same caveat as QPDA SEG1 and SEG2.

(All of these may or may not depend on the alignment and IFO state.)

This doesn't make much sense. If it's TMSX hitting something and exciting mechanical resonances I'd expect some coherence between all segments at around bumps, even if there's some clipping.

If this is a simple electronics problem, different segments should not be coherent with each other.

Third attachment: When IR and green are resonant at the same time, for example the twin bumps at 9 and 12Hz or so for IR and green line up. But they are not coherent with each other (black trace at the bottom is the green QPD, black at the top is green/IR coherence).

Green QPDs are coherent with seismometers, IR QPDs are not. 

RIN of 9Hz bump for IR and green are on the order of 10ppm/sqrtHz and 1000ppm/sqrtHz, respectively.

TMS BOSEMs are too noisy to detect anything at this frequency (no difference between TMSX and TMSY in this regard).

Question: What are we seeing here?

This morning the lock acquisition always failed at the ENGAGE_ASC step. We traced down the problem to the change in SRC1_Y input matrix: the error signal was changed from 2 * AS_B_RF36_I to -3*AS_A_RF36_I. We tried this transition manually with -20dB of loop gain, and altought the loop was moving the rror signal toward zero, the result was a misalignment of the IFO and unlock.

So for the moment being I com mented out this matrix change in the guardian. ENGAGE_ASC is now stable with this configuration.

The main story of the day is related to the non stationary low frequency noise first seen early in the morning. It seems to come from CHARD noise, which could be coupling to DARM more now because of a change in alignment.   

• Once we were stable at 24 Watts this afternoon, we didn't see the terrible low frequency noise that was seen in the early morning (at least it was not as bad).  
• Jenne and I worked a bit more on the CHARD loops, adding 23 Watt boosts, a lead filter that gave us some phase to make cut offs.  The first attached screen shot is a comparison of CHARD PIT at 3 Watts, and at 24 Watts before and after the changes.  Jenne has similar measurements for yaw.
• The terrible low frequency noise came back.  
• We undid all of the CHARD changes we made yesterday and this afternoon(keeping only the leads and cut offs) .  The terrible low frequency noise did get better, although some extra non stationary low frequency noise remains below 50 Hz.  The non statinary noise was reduced when we did this, although we still had some excess non stationary noise below 50 Hz, and coherence with CHARD.  We did another round of on/off test to be sure CHARD was involved.  
• We decided to check on alignments that we thought moved durring monday's PZT power off and PSL temperature excursions.  We could see that we had moved on IM4 trans after monday, so in full lock we moved IM3 to bring ourselves back to the old location on IM4 trans.  
• We then redid inital alingment, carefully, and relocked, using the low bandwidth CHARD loops and our new cutoffs.  After this the noise does seem better, but there is still excess noise that is non stationary.  

A few ideas for next steps:

• see if we can find a better CHARD sensor.  Do we need to use trans mon QPDs or is there a way to find a better SNR on the refl WFS?
• can we do a better job with A2L?
• We could try to change our alignment to see if we can reduce this noise.
• DHARD resonant gain for the 0.46 Hz instability.  This instability only seems to come up when we have a bad alignment, but a little more gain can probably help us avoid it. 

We also worked on a few other things today...

• Between Evan and I we reverted the phase of the 45 WFS to what they were a week ago (before TCS tuning)
• Gabriele and I saw this morning that we think that a SRC1 YAW input matrix of -3 for AS A 36 I and no signal from AS B is good.  We watched all of the AS 36 Yaw signals as we powered up to 17 Watts, and saw that AS B sees something that drifts as we power up.  When we removed AS B from the input matrix, the AS 90 power increased.  
• The SRC2 Yaw loop was painfully slow (several minutes reaction time).  It now has a factor of 2 more gain (-40 is fm gain now, it was -20 before).  This is in gaurdian. 
• Gabriele had a look at doing frequency dependent A2L for ETMX.  We have reverted it for now, but it seemed promising. 
• Our locks today seem quite stable, we have been loosing lock by making mistakes, and when we have a combination of driven measurements and PEM injections.  
• ETMY ESD LP had been turned off at some point, most likely unintentionally.  It's on again, and now monitored in SDF.  We also turned the PUM coil drivers back to their low noise state.  We needed more range for DHARD when the roll mode was rung up very badly last week (because of DOWN not runnning for extended of periods of time twice.)  These were a mixed bag of monitored and not in SDF, I think I've set them all to monitored now, with the requested state as 3.  However, this gets over written by the gaurdian.  
• I had put offloading of full lock ASC in the normal guardian path, but this seemed to make the DRMI alingments for relocking worse (possibly because the full lock ASC is compensating for some wire heating).  So it is now removed from the normal path, but can be choosen as an option after transitioning to DC readout.  

I ran Hang's latest A2L script (see aLog 20013), after the realignment work that was done tonight (Sheila is writing up her entry as I type). 

We stil have excess noise at low frequency, but maybe there's a bit less than when I started the script?  The noise we're seeing is totally non-stationary, so it's hard to say.  Certainly the A2L didn't eliminate it.

I took a look at the scattering noise we see in all lock since last night .

I computed the band-limited RMS between 20 ans 120 Hz, and this is a good indicator of the scattering noise level. Then I looked at correlations with all suspension motions (using M0 and M1 signals, as Keita did for the OMC).

So I'm able to reconstruct the noise variation over time, using a linear combination of all the suspension signals and their squared values. However, I'm not able to pick point one single mirror which is moving more, as shown in the ranking of the most important channels for the BLRMS reconstruction.

I compared the suspension motion spectra from tonight (GPS 1123422219) and few days ago (GPS 1123077617). The most relevant difference is that all test masses YAW motion have now a large bump at 3 Hz. ITMY also has large lines at 0.45 and 0.63 Hz. Finally ETMY pitch shows a large line at 6 Hz and some excess noise above that frequency.

Not sure if all of this is really relevant...

I looked into the glitches created by Robert's dust injections. In brief: some of the glitches, but not all of them, look very similar to the loud glitches we are hunting down

Here is the procedure:

1. select all drops of the range in the two hours of injection
2. for each one, load three minutes of data, compute the 30-300 Hz BLRMS and find the glitch tims as the maximum of the BLRMS peaks

In this way I could detect a total of 42 glitches. The last plot shows the time of each glitch (circles) compared with the time of Robert's taps (horizontal lines). They match quite well, so we can confidently conclude that all the 41 glitches are due to dust. The times of my detected glitches are reported in the attached text file, together with a rough classification (see below)

I then looked at all the glitches, one by one, to classify them based on the shape. My goal was to see if they are similar to the glitches we've been hunting.

A few of them (4) are not clear (class 0), some others (14) are somehow slower than what we are looking for (class 3). Seven of them have a shape very close to the loud glitches we are looking for (class 1), and 16 more are less obvious but they could still be of the same kind, just larger (class 2).

See the attached plots for some examples of classes.