22:09UTC H1 is in science mode:
LLO showed up on DMT at ~ 20:48UTC
Robert into LVEA @ 20:47UTC
Jeff K into control room with a tour group @ 21:48
Still no locking for my shift. I talked to Sheila for a bit and it seems that when the ISC_LOCK guardian was getting stuck in LOCK_DRMI_1F asking you to adjust by hand, it was only in a PRMI configuration and SRM was misaligned somehow(perhaps related to what I was seeing during IA). I moved SRM around for a bit and brought it back to some old values but still nothing.
Ed will have to finish up the mess I made for him.
	model restarts logged for Fri 12/Jun/2015
	2015_06_12 23:27 h1fw1*
* = unexpected restart
I took over for Travis as the interferometer was locking DRMI, shortly after I had to damp ETMY and ITMX bounce and roll modes. It then made it to BOUNCE_VIOLIN_MODE_DAMPING before it broke. After recovery, it got stuck on LOCK_DRMI_1F for a long time, much longer than usual (25min is where I would give up) . I have heard this could be from a bad alignment so I did a quick initial alignment with no issues and then made it a few times to REFL_TRANS/RESONANCE before it broke lock.
Again LOCK_DRMI_1F took a long time so I did another initial alignment. This time, I struggled keeping the ALS locked. It would all seem good and then one of them would catch a flurry of large modes and then recover back to a steady power above 1. When I limped through IA to SRC_ALIGN, Guardian said that it was locked and it was not. This happens some times and is normally an easy fix but I couldn't make it work well at all, it was constantly moving around. I eventually got something that was round(ish) but pretty wavey and tried to move on. Made it to LOCK_DRMI_1F and it asked that I adjust it by hand, which is also not working.
That's the rundown of my shift so far, let's hope it improves.
Looks like an excitation got left on for H1SUSETMX. I saw it on the CDS Overview when I arrived, there are 6 test points running on it right now. I don't see anything in the alog about this being here intentionally.
Times UTC
5:13 Intent bit set to undisturbed. Note: calibration may have changed due to EY ESD issues.
5:18 Lockloss.
6:34 Intent bit set to undisturbed.
6:49 Lockloss.
Winds have calmed down since the beginning of the shift. Now a breezy 10-20 MPH.
Richard, Evan
It appears that the EY ESD bias was stuck at −430 V ever since the installation of the low-voltage driver in May. It became unstuck on 11 June, when Richard reset the driver.
Since we have always requested a positive bias for EY in the digital system (using SUS-ETMY_L3_LOCK_BIAS), this means that the reset on 11 June flipped the sign of the EY ESD actuation, causing the transition of DARM from EX to EY to fail (as TJ found).
To fix the transition, the EY bias is now requested to be negative in the digital system, thereby restoring the sign (but not the magnitude) of the true analog bias that we have had since 22 May. Of course, if the magnitude of the L3 actuation has changed, this will affect the accuracy of the calibration in the region dominated by the control signal.
First, let us enumerate some of the mysteries surrounding the EY ESD:
We hypothesize that mysteries (1), (3), and (4) are explained by the EY ESD bias being stuck at −430 V between 2015-05-22 and 2015-06-11, and the driver's readbacks being nonresponsive. Mystery 2 is still unsolved.
When Richard went to EY on the 11th, he found the high-range driver putting out −430 V on all five lines, and the driver's analog readbacks were frozen at −15000 ct or so. According to him, this is a known failure mode of the driver's microcontroller. After he reset the driver, the analog readbacks became functional again.
The attached plot shows a trend of the analog readback of the EY ESD bias. It is stuck at about −15000 ct from 2015-05-22 (when the low-voltage driver installation was finished) to 2016-06-11 21:00:00ish UTC (when Richard reset the driver). The natural conclusion from this is that the EY ESD bias has been railed at −430 V between these two dates (even though we thought we were giving +380 V of bias).
I flipped the requested bias so that it is now (I think) −380 V, which is the most negative bias that can be requested from the driver when it is operating properly. I was able to transition control of DARM from EX to EY by hand following the steps in the guardian.
Also, Travis and I are hearing ETMY saturations every so often. The rms drive to EY L2 is 40000 ct or so, which is higher than the 15000 ct that we measured when we first started using EY L2. (Could it just be wind?)
If you, like us, don't like it when your suspensions saturate in full lock, then we suggest trying out a higher L1/L2 crossover. Engage FM9 in H1:SUS-ETMY_L1_LOCK_L, and turn up the gain from 0.16 to 0.31.
Per Jeff's request, here is an excerpt from an email I sent to Evan and Jeff: Some architectures used in amplifiers suffer from a phenomenon known as Phase Reversal wherein the feedback sign of the amplifier can actually change on certain saturation events. I have not looked to see if that is whatsoever possible with the HV ESD amplifiers. Something that bothers me here is that if you are running in low voltage mode, there is no way the high voltage drive signals for the quadrants can make it to the reaction mass. A relay disconnects them. This makes me somewhat puzzled about potential HV/LV interactions causing any sort of actuation force reduction. The actual applied bias could be changing by the time it makes it through the non-trivial series resistance associated with the bias filters (~70kohms), but there would have to be a low impedance on the bias terminal to created the necessary voltage divider. As for the sign flip, I have no answer there. I will check (again) that I didn't do something dumb and make a typo on the + and - wires.
Following up on the notion of phase reversal, I checked all the chips used in the HV ESD Driver signal chain. Here's the result: LT1124 - Input receiver, these are the same architecture as the ubiquitous LT1125 we use everywhere at LIGO, so I'm not too suspicious here. LT1007 - Second stage of input receiver, no mention of immunity to phase reversal in data sheet. This is often a bragging point among chip designers, so I can't eliminate this chip from the list of suspects. OP-97 - Front end chip for the HV output stage, Vcm = +/-13.5V min, this is a possible culprit as the input architecture appears to be jfet based, and it's used in a feedback loop, which is a double whammy for phase reversal. PA-95 - HV driver chip. No mention of phase reversal immunity. Definitely jfet based, used in a feedback loop, and is not grounded on the positive pin. Triple whammy for phase reversal, although it would be hard to exceed the input common mode voltage with +/-430V rails... Mostly pseudo science here, but my two cents.
No luck locking so far. Winds are an issue once again, 20+ MPH with gusts over 40 MPH. Commissioners may have discovered an issue with the EY ESD which could have been partially to blame for the lack of locks in the past day. Talked to Gary in the LLO CR again and let him know we are in for another tough night.
We had four known reasons for having difficulty locking today, one is an unsolved mystery that might be hurting us more often than we realize.
I reloaded both ISC_DRMI and ISC_LOCK guardians today, to incorporate these changes.
Good luck TJ!
I don't think the log snippet included above shows the problem, but I found where in the log it does:
2015-06-13T05:36:35.76316 ISC_LOCK [LOWNOISE_ESD_ETMY.enter]
2015-06-13T05:36:35.78009 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_L3_LOCK_L_TRAMP => 0
2015-06-13T05:36:35.78025 ISC_LOCK [LOWNOISE_ESD_ETMY.main] Preparing ETMY for DARM actuation transition...
2015-06-13T05:36:36.03624 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_M0_LOCK_L => OFF: INPUT
2015-06-13T05:36:36.03791 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_L1_LOCK_L_GAIN => 0.16
2015-06-13T05:36:36.03886 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_L3_LOCK_L_GAIN => 0
2015-06-13T05:36:36.04021 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_L1_LOCK_L_SW1S => 20804
2015-06-13T05:36:36.29496 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_L1_LOCK_L => ONLY ON: INPUT, FM2, FM3, FM5, FM6, FM7, FM8, OUTPUT, DECIMATION
2015-06-13T05:36:36.55096 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_L2_LOCK_L => ONLY ON: INPUT, FM6, OUTPUT, DECIMATION
2015-06-13T05:36:36.55229 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_L3_LOCK_L_SW1S => 16388
2015-06-13T05:36:36.80324 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_L3_LOCK_L => ONLY ON: INPUT, FM6, FM8, FM9, FM10, OUTPUT, DECIMATION
2015-06-13T05:36:37.05938 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_L2_DRIVEALIGN_L2L => ONLY ON: INPUT, FM2, OUTPUT, DECIMATION
2015-06-13T05:36:37.31538 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_L3_DRIVEALIGN_L2L => ONLY ON: INPUT, FM3, FM4, FM5, OUTPUT, DECIMATION
2015-06-13T05:36:37.31694 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_L3_LOCK_L_TRAMP => 10
2015-06-13T05:36:37.32341 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMX_L1_LOCK_L_SW1 => 16
2015-06-13T05:36:37.57613 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMX_L1_LOCK_L => OFF: FM1
2015-06-13T05:36:38.57792 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_L3_LOCK_L_GAIN => 0.7
2015-06-13T05:36:38.57846 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMX_L3_LOCK_L_GAIN => 0.5
2015-06-13T05:36:49.58941 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_L1_LOCK_L_SW1 => 16
2015-06-13T05:36:49.84053 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_L1_LOCK_L => ON: FM1
2015-06-13T05:36:50.84245 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_L3_LOCK_L_GAIN => 1.25
2015-06-13T05:36:50.84585 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMX_L3_LOCK_L_GAIN => 0
2015-06-13T05:36:50.84640 ISC_LOCK [LOWNOISE_ESD_ETMY.main] timer['ETMswap'] = 10.0
2015-06-13T05:36:50.85290 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_L3_LOCK_L_TRAMP => 0
2015-06-13T05:36:50.85341 ISC_LOCK [LOWNOISE_ESD_ETMY.main] Preparing ETMY for DARM actuation transition...
2015-06-13T05:36:51.10580 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_M0_LOCK_L => OFF: INPUT
2015-06-13T05:36:51.11470 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_L3_LOCK_L_GAIN => 0
2015-06-13T05:36:51.11670 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_L1_LOCK_L_SW1S => 20804
2015-06-13T05:36:51.37015 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_L1_LOCK_L => ONLY ON: INPUT, FM2, FM3, FM5, FM6, FM7, FM8, OUTPUT, DECIMATION
2015-06-13T05:36:51.62486 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_L2_LOCK_L => ONLY ON: INPUT, FM6, OUTPUT, DECIMATION
2015-06-13T05:36:51.88017 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_L3_LOCK_L => ONLY ON: INPUT, FM6, FM8, FM9, FM10, OUTPUT, DECIMATION
2015-06-13T05:36:52.13170 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_L2_DRIVEALIGN_L2L => ONLY ON: INPUT, FM2, OUTPUT, DECIMATION
2015-06-13T05:36:52.38753 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_L3_DRIVEALIGN_L2L => ONLY ON: INPUT, FM3, FM4, FM5, OUTPUT, DECIMATION
2015-06-13T05:36:52.39457 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_L3_LOCK_L_TRAMP => 10
2015-06-13T05:36:52.65332 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMX_L1_LOCK_L => OFF: FM1
2015-06-13T05:36:53.65498 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_L3_LOCK_L_GAIN => 0.7
2015-06-13T05:36:53.65562 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMX_L3_LOCK_L_GAIN => 0.5
2015-06-13T05:37:04.66682 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_L1_LOCK_L_SW1 => 16
2015-06-13T05:37:04.91783 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_L1_LOCK_L => ON: FM1
2015-06-13T05:37:05.91955 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMY_L3_LOCK_L_GAIN => 1.25
2015-06-13T05:37:05.92183 ISC_LOCK [LOWNOISE_ESD_ETMY.main] ezca: H1:SUS-ETMX_L3_LOCK_L_GAIN => 0
2015-06-13T05:37:05.92216 ISC_LOCK [LOWNOISE_ESD_ETMY.main] timer['ETMswap'] = 10.0
2015-06-13T05:37:05.94222 ISC_LOCK [LOWNOISE_ESD_ETMY.run] MC not locked
	Based on the ezca and log output during LOWNOISE_ESD_ETMY.main it does in fact look like main() was executed twice in a row.  That should never happen under any circumstances.  I'm investigating.
I think that there are potentially two different issues, one being what is shown in the original alog, where the run should return true, but the guardian state doesn't change even though the current state is not the requested state. We could re-wrtie the guardains (or at tleast this state) to reduce the harm from this, but it still seems like a bug in the way the gaurdian is working.
On the other hand, the problem that Jamie pointed out is more serious. For other reasons, I have been looking at histograms of how long the guardian spends in each state. Some states should take the same amount of time to execute each time, but analog carm for example has 3 possibilities. We often detect a lockloss in the first second of the state, if the state executes normally it takes 18 seconds, but there were 5 times that it took 35 seconds because it repeated main. GPS times of these events are:
1117983542.06250
> 1118037936.06250
> 1118148903.93750
> 1118294947.06250
> 1118295997.06250
I looked at guardian log for the first three of these events, and indeed they
are times when the main was repeated. These are mosly sucsesfull locks, so the bug isn't causing locklosses here although it easily could.  
The ISC_LOCK code that was running at the time is in the svn as revision 10776.
		
		
	
	A 6.0mag EQ occurring in Tonga, 8700km distance is a better candidate than the 5.7 EQ in Miyako Japan (7400km) alog 19074, I looked at yesterday for evaluating Terramon. Slightly further away but enough larger and it makes all the difference. With the 5.7 EQ, I couldn't be sure there was anything on the seismos, the predictor estimated a velocity of 1.9um/sec for the R-wave. For the 6.0 EQ, the estimate is 5.
The arrival at the site is clear on the ground STS2--see attached. I've marked the 3 times from the predictor with thin lines and we clearly see the arrivals. The P-wave arrival estimate is very good; the plot is 40 minutes long. The S-wave arrival is 'late' tens of seconds and the surface wave arrives more than 5 minutes sooner than predicted. These channels should all be calibrated in nm/sec
The second plot shows some GS-13 channels on the BS ISI stage2 and an IFO red power showing if the IFO is fully locked. The Surface (R-phase) arrival (last arrival) does clearly change the motion on the GS13s--I've marked the apparent arrival of the Surface wave on the plots--the thicker line. The two fat portions of the GS-13 signal correspond to locked DRMI periods, beginning and middle of plot. So what can I say...
1) The arrival of this P-wave may have brocken the DRMI although it broke ~20+ seconds after arrival prediction.
2) Clearly, the DRMI can hold lock during the arrival of the S-phase: it arrived some 50 seconds after the middle DRMI lock section began.
3) This IFO lock break was not caused by the surface wave arrival: it broke ~6 minutes before the obvious surface waves hit-marked at thick line.
4) The DRMI did not lock while the Surface Waves had the BS GS13s rung up although later looks show the DRMI may not be soley resposible for the GS13 ring up. Still need to understand better what the IFO state does to the ISI. I've chosen BS GS13s as they are not in loop so maybe the most vulnerable.
5) The arrival velocity prediction is within a factor of 2 of that observed.
Observation Bit: Commissioning 08:00 – Take over from TJ – IFO not locked 08:07 Christina & Karen – First cleaning at End-Y 08:10 Betsy – Running ETM charging measurements at End-X 08:31 – Beam tube cleaning crew start work on X-Arm 08:50 Christina & Karen – First cleaning at End-Y 08:55 Richard – Cabling work at End-X for ETM charging measurement 09:06 Filiberto – Going to Mid-Y to get cables 09:15 Peter – Transition End-X building to Laser Safe. Lasers are on, tables & viewports secured 09:15 Betsy – Finished with ETM charging measurements 09:30 Filiberto – Back from Mid-Y 09:45 Richard – Back from End-X 09:50 Peter – Transition End-Y building to Laser Safe. Lasers are on, tables & viewports secured 09:55 GRB Alert – IFO not Locked 09:58 Christina & Karen – Finished with first cleaning at both End Stations 10:43 Robert – Going to End-Y 10:52 Snack Vendor on site to restock machines 11:20 Robert – Back from End-Y 11:37 Robert – Going to End-Y 11:54 Beam tube cleaning crew break for lunch 12:18 Robert – Back from End-Y 12:53 Beam tube cleaning crew working 13:43 Beam tune cleaning crew finished 15:34 Robert – Going beam tube enclosure near Mid-Y 15:55 Robert – Back from Mid-Y 16:05 Hand off to Travis
	HAM6, Vent Master = Hugh Radkins
	https://dcc.ligo.org/E1500267
APPROVED work to be done in order of importance:
Install OMC glass stray light baffle assembly (Matt, Calum, Kate, Dan)
Install in-vac accelerometers if available (Matt, Calum, Kate, Dan)
Acoustic coupling measurements (Robert, Hugh)
DCC Vent Documents referenced in this plan:
Additional Documentation:
SCHEDULE
TUES, June 16, 2015
1) Transition to LASER SAFE
2) Turn cleanrooms on around HAM6
3) Clean area, door flange, and cleanrooms
4) Start staging of supplies and equipment
5) Confirm dust monitor is working
6) Lock HEPI
WED, June 17, 2015
7) Confirm purge air is on at HAM6
8) Vent HAM6
9) Remove door – Review and follow M1100039 “ Hanford checklist – HAM Door Removal”
10) Entry chamber checklist items: Pick up floor CC wafers. Take particle counter measurements and record:
11) Perform acoustic coupling investigations
12) SEI Lock ISI
THUR, JUNE 18, 2015
13) Start payload rework of ISI in prep for rebalancing after OMC baffle installation E1100742
FRI, JUNE 19, 2015
14) Start prep of OMC stray light black glass shroud
MON, June 22, 2015
15) Start install of OMC stray light black glass shroud as per E1500214
16) Take particle measurements and record:
TUE, June 23, 2015
17) Continue install of OMC baffle
18)Take particle count measurements and record:
WED, June 24, 2015
19) Continue install of OMC baffle
20) Install in-vac accelerometers if available – location TBD
21) Take particle count measurements and record:
THUR, June 25, 2015
22) Transition to LASER HAZARD
23) Check alignment of beams in and out of OMC
24) Transition to LASER SAFE
25) Final rebalance ISI
26) Take particle count measurements and record:
FRI, June 26, 2015
27) SEI test ISI
28) OM SUS checkouts if needed (DAN)
29) Chamber closeout – perform applicable exit checklist tasks E1201035.
30) Put doors on, begin pump down.
· Acoustic coupling measurement details (description from Robert):
Robert Schofield is interested in getting some vent time in HAM6 for investigating the resonance that promotes high acoustic coupling (we are only a factor of 2 above having ambient acoustic noise cause features in DARM (https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=18504)).
The plan would be to tap particular structures and monitor the frequency on the GS13s or on a temporarily mounted Class-A compatible accelerometer that we normally use. If we find a candidate, we will damp it using a Class-A compatible temporary damping setup, and measure the damping using an externally mounted shaker. Then we would remove anything that we put in the chamber and turn the chamber over to the next project.
	
	
	
	
	 
Andy, Jess Since the 79.2 MHz fixed frequency source was powered off alog, we have not seen any RF beatnote/whistles in DARM at Hanford. We see them in DARM at Livingston, however, but the mechanism is much more complicated than Hanford. The mechanism is not the PSL VCO beating against a fixed frequency. Since we still see whistles at Hanford in auxiliary channels, we thought we'd revisit them, to see if that gives us clues for L1. We looked at the lock of Jun 11 starting at 6 UTC. We see whistles in PRCL, LSC-MCL, and sometimes in SRCL. Choosing two times, we find that the whistles correspond exactly to a beatnote of the PSL VCO frequency with a fixed frequency of 78.5 MHz (or something within a few hundred Hz of that). So it's the same simple mechanism as before, just against a different frequency. Attached are plots of two times in PRCL where we predict the exact shape of the whistle, using IMC-F as a proxy for the PSL VCO frequency. SRCL and MCL are similar. We'll go back and check other locks to see if there's any evidence for other frequencies or shifts in the frequency.
First, a question. Is there something at 34.7 MHz in the center station? I see this frequency on channel SYS-TIMING_C_FO_A_PORT_11_SLAVE_CFC_FREQUENCY_4 - the PSL VCO is number 5 on this fanout. The numerology just about works with 2*34.7+9.1 = 78.5, i.e. that frequency gets doubled and is seen in the 9 MHz demod of the POP and REFL PDs. Jeff wanted me to also post an expanded version of the whistles story that I had sent by email, so here it is: To be clear, H1 *did* have whistles in DARM. Once we got the secret decoder ring that told us how to figure out the PSL VCO frequency, we realized that the whistles in DARM were precisely a beatnote of that frequency with 79.2 MHz. As a result of that investigation, that fixed frequency was turned off, and the whistles in DARM went away. Huge success! We also see whistles in SRCL, PRCL, and MCL. We haven't been worrying about them, since they're not in DARM. But just yesterday we decided to see if this is also a simple mechanism. As you can see from the alog, it is - at least at the times we've checked, the whistles are a beatnote against something at 78.5 MHz. I realized just a little while ago that these channels all come from 9 MHz demods, so maybe the actual frequency we're looking for is actually 69.5 or 87.5. We'll check whether these signals show up on POP or REFL at either LF or 45 MHz. We know that LLO is a very different mechanism. Not only do they not have this particular fixed oscillator, but these whistles: 1. Come from multiple very different VCO frequencies. 2. The beat frequencies don't seem stable even within a lock. 3. The whistles do not follow the PSL VCO frequency. They are more like 4 to 7 times the VCO frequency. The multiplier doesn't seem stable, and sometimes the whistles seem to decouple a bit from the VCO frequency. 4. The whistles show at LF, 9 MHz, and 45 MHz PDs, on REFL and POP. Different crossings show up in different photodiodes and with different strengths. So you can see why we want to tackle Hanford first. I was hoping it would be more complicated but tractable, and that would give us a clue to what's going on in L1. In case you're wondering whether this is academic, the CBC search loves triggering on the whistles at LLO, and it's hard to automatically reject these because they look like linear or quadratic broadband chirps. I think these give the burst search trouble as well.  We'll probably spend another day nailing down the case at Hanford, then look over all ER7 to figure out what was going on at L1.
00:00 The ifo locked right before I came in. Wind speed is <20 mph. 90 mHz blend filter is used for BSC2.
I noticed the BS oplev sum is saturated (> 80000 counts). Is this alright? It's been around this value for 10+ days.
01:55 There's a big bump at ~30 Hz that caused a big dip in the BNS range. SUS Oplev plots didn't show anything suspicious. The bump at this frequency happened through out the night, just not as big.
02:00 A 4.7 MAG earthquake in Ecuador shook PR3 a little and BNS range dropped slightly (from 61 Mpc to 60 Mpc), but that's all it did. No WD tripped.
08:00 We've been locked for 8+ hours and still going strong at 61 Mpc! We had 5+ hours of coincidence with Livingston tonight. Handling the ifo to Jeff B.
Judging from the normalized spectrograms on the summary pages, the 30Hz noise looks like occasional scattering noise, likely from the alignment drives sent to the OMC suspension. Currently the Guardian sets the OMC alignment gain at 0.2 (for a UGF of around 0.1-0.5 Hz in the QPD alignment loops). This is probably too high from a scattering-noise perspective, it can be reduced by a factor of two without ill effects.
To follow up on this noise, here is a plot of one of the noise bursts around 20-30Hz, alongside the OMC alignment control signals. The noise has the classic scattering-arch shape, and it is correlated with the ANG_Y loop, which send a large signal to the OMC SUS. We've seen this kind of thing before. The start time for the plot is 09:27:10 UTC, June 11 (the time axes of the two plots are a little off, because apparently indexing for mlab PSDs is the hardest thing I've had to do in grad school.)
The second plot attached compares the OMC-DCPD_SUM and NULL channels at the time of the noise bursts in the first plot, to a quiet time one minute prior. The scattering noise is largely coherent between the two DCPDs.
Dan, Travis
Tonight during our long lock we measured the decay time constant of the ITMX bounce mode. At 10:10 UTC we set the intent bit to "I solemnly swear I am up to no good" and flipped the sign on the ITMX_M0_DARM_DAMP_V filter bank and let the bounce mode ring up until it was about 3e-14 m/rt[Hz] in the DARM spectrum. Then, we zeroed the damping gain and let the mode slowly decay over the next few hours.
We measured the mode's Q by fitting the decay curve in two different datasets. The first dataset is the 16Hz-sampled output of Sheila's new RMS monitors; the ITMX bandpass filter is a 4th-order butterworth with corner frequencies of 9.83 and 9.87Hz (the mode frequency is 9.848Hz, +/- 0.001 Hz). This data was lowpassed at 1Hz and fit with an exponential curve.
For the second dataset I followed Koji's demodulation recipe from the OMC 'beacon' measurement. I collected 20 seconds of DELTAL_EXTERNAL_DQ data, every 200 seconds; bandpassed at 9 and 12Hz, demodulated at 9.484Hz, and lowpassed at 2Hz; and collected the median value of the sum of the squares of the demod products. Some data were neglected on the edges of the 20-sec segment to avoid filter transients. These every-200-sec datapoints were fit with an exponential curve.
Results attached; the two methods give different results for Q:
RMS channel: 594,000
Demodulated DARM_ERR: 402,000
I fiddled with the data collection parameters and filtering parameters for both fits, but the results were robust. When varying parameters for each method the results for Q were repeatable within +/- 2,000, this gives some sense of the lower limit on uncertainty of the measurement. (The discrepancy between the two methods gives a sense of the upper limit...) Given a choice between the two I think I trust the RMS channel more, the demod path has more moving parts and there could be a subtlety in the filtering that I am overlooking. The code is attached.
I figured out what was going wrong with the demod measurement - not enough low-passing before the decimation step, the violin modes at ~510Hz were beating against the 256Hz sample rate. With another layer of anti-aliasing the demod results are in very good agreement with the RMS channel:
RMS channel: 594,400
Demodulated DARM_ERR: 593,800
To see what we might expect, I took the current GWINC model of suspension thermal noise and did the following. 1) Removed the horizontal thermal noise so I was only plotting vertical. 2) Updated the maraging steel phi to reflect recent measurement (LLO alog 16740) of Q of UIM blade internal mode of 4 x 10^4. (It is phi of 10^-4, Q 10^4 in the current GWINC). I did this to give better estimate of the vertical noise from higher up the chain. 3) Plotted only around the thermal noise peak and used 1 million points to be sure I resolved it. Resulting curve is attached. Q looks approx 100K, which is less than what was reported in this log. That is encouraging to me. I know the GWINC model is not quite right - it doesn't reflect tapered shape and FEA results. However to see a Q in excess of what we predicted in that model is definitely in the right direction.
Here we take the Mathematica model with the parameter set 20150211TMproduction and we look at varying some of the loss parameters to see how the model compares with these measurements. The thermal noise amplitude in the vertical for the vertical bounce mode is tabularised around the resonance and we take the full width at 1/√2 height to calculate the Q (equivalent to ½ height for power spectrum). With the recently measured mechanical loss value for maranging steel blade springs of 2.4 e-5, the Mathematica model predicts a Q of 430,000. This is a little bit lower Q than the measurement here, but at this level the loss of the wires and the silica is starting to have an effect, and so small differences between the model and reality could show up. Turning off the loss in the blade springs altogether only takes the Q to 550,000, so other losses are sharing equally in this regime. The attached Matlab figures shows mechanical loss factor of maraging steel versus predicted bounce mode Q and against total loss plus the resonance as a function of loss. Angus Giles Ken & Borja
Since there has been some modeling afoot, I wanted to post the statistical error from the fits above, to give a sense of the [statistical] precision on these measurements. The best-fit Q value and the 67% confidence interval on the two measurements for the bounce mode are:
RMS channel: 594,410 +/- 26
Demodulated DARM_ERR: 594,375 +/- 1590
The data for the measurements are attached. Note that this is just the statistical error of the fit -- I am not sure what systematics are present that could bias the measurement in one direction or another. For example, we did not disable the top-stage local damping on ITMX during this measurement, only the DARM_CTRL --> M0 damping that is bandpassed around the bounce mode. There is also optical lever feedback to L2 in pitch, and ASC feedback to L2 in pitch and yaw from the TRX QPDs (although this is very low bandwidth). In principle this feedback could act to increase or decrease the observed Q of the mode, although the drive at the bounce mode frequency is probably very small.