J. Kissel, T. Sadecki, D. Hoak, E. Merilh

As a last ditch effort to be able to recocile the calibration for the rest of the run, given the drastic change to the ETMY ESD, I've completed a DARM OLGTF, and also tuned and completed a PCAL EX to DARM transfer function. I got halfway through the same transfer function using PCAL EY, but the lock broke from some sort of seismic disturbance. The interferometer was at 17 [W] requested input power for all of the below measurements, I attach the relevant digital parameters that are relevant (sadly the list is growing! as so many things are changing!).

Analysis to come, but the measurements have been committed to the CalSVN repo here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Measurements/DARMOLGTFs
2015-06-13_H1_DARM_OLGTF_LHOaLOG19128_ETMYL3LPOFF.xml

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER7/H1/Measurements/PCAL_TRENDS
2015-06-13_H1PCALEX_2_DARM.xml
2015-06-13_H1PCALEX_2_DARM_stronger.xml

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER7/H1/Measurements/PCAL_TRENDS
2015-06-13_H1PCALEY_2_DARM_stronger.xml

For the PCAL sweeps, I've modified the following settings from what Sudarshan had set up (2015-06-12_pcal_sweep_X.xml in the same folder) such that (a) the measurement would complete in a reasonable amount of time, (b) we'd get coherence over the entire band of measurement, and (c) that the frequency vector would match the DARM OLGTF:
- Changed the frequency range to 5 to 5000 [kHz]
- Changed the frequency vector from linear to logarithmic
- Changed the user-defined amplitude format to Envelope
- Increased the number of cycles to 25
- Increased the duration of a cycle to 1 [sec]
- Increase the drive strength in various frequency bands where there remained no coherence

LHO ER7 data quality shift Wednesday 6/3 to Friday 6/5 (1117378816-1117584015). TJ Massinger was the shift mentor.

Things we noticed:

- Thursday the sensemon was incorrectly generating the inspiral range, which has since been fixed. The range was between 45 and 55 Mpc on Thursday.

- The calibration accuracy seemed to be more widely varying than in previous days, with large departures (factor of >5) at the high frequency (~6kHz) end.

- We saw the 14Hz roll mode ringing down at the beginning of each lock, except for the 11:00-13:00 UTC segment Thursday, where a ring-down measurement was being performed. Nothing to see here.

- Some ugly wandering lines in CARM around 600Hz that also showed up through their 4th harmonic.

- A particularly glitchy segment just before 18:00 UTC Friday. We tracked down the loudest glitch which was identified as 2.16kHz (SNR 3,190). A time plot shows this was actually high frequency glitches riding on a much larger ~7.7 Hz blip. The high frequency components also showed up in the PRM M2 suspension control signals. Some discussion in the aLog about this: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=18918

A link to the shift report: https://wiki.ligo.org/DetChar/DataQuality/DQShiftLHO20150603

15:58PDT

Jeff K in the control room wants to take a DARM loop open gain and correct the calibration. Will wait to go into science mode. Handing of to Travis.

LLO was down at the beginning but came up during the injections. I did most of what I had hoped to do in the first round.

22:09UTC H1 is in science mode:

• The OIB was switched to Undisturbed

• Robert is going to destinations down the Y-arm where shakers will eventually be set up to do some "banging". He will record the time of his actions and the glitches can also be observed by the Detcharrians (spelling?)

• Aaaaaaaaannddd LOCKLOSS @ 22:18 RATS!

After much diddling with PR's and SR's while swinging them and watching camera images and dataviewer I finally came to my happy place with the alignments!

• 13:00 FINALLY got DRMI locked. It kept locking on the wrong mode. Trial and error landed me a manual pitch adjustment of PRM. BINGO.

• 13:08 RESONANCE

• 13:20 After much cautiousness, Locked at LSC_FF about 56Mpc. 

Robert Schofield is here and looking to do some PEM injections. He'll be going into the LVEA.  There seems to be a  strange disturbance in the Force that we can't explain. (see attached screenshot)

I spoke to Joe Hanson at LLO. At 20:30UTC they were locked on RF and were looking to move forward to DC Readout. I informed him as to our status and the testing that Robert was about to do for the next 1.5 hours or so.

For now.....life is good!

IFO locking difficulties continue:

• I re-checked initial alignment from "the ground up" just to review the state of everything else. Green looked good in both arms. PRM_ALIGN seemed to have gone well. I did improve the alignment on PR3 slightly. I then moved to MICH_DARK_LOCKED which seemed to converge nicely. It needed a little touching but at the outset always seemed to have some movement to it. I then moved on to SRC_ALIGN, which is where TJ handed off to me.

• Spent some time on the phone with Sheila trying to get the SRC alignment back to quasi-nominal. I got the spot bright and as round as I could get it. Increasing the laser power to 10W made the chore easier to deal with. It did lock but the stability was never resolved.

• I took a chance at moving forward to the DRMI_LOCKED state to see what would break. As I suspected by all of the swinging going on in the intial alignment, there was no glory.

• I then reverted back to looking at the PRM_ALIGN and saw that the alignment wasn't to good. Working on that now. Sheila will be in this afternoon. Fun.

As TJ mentioned in a earlier post there is an excitation showing at ETMX with 5-6 Testpoints occupied with some kind of business. We don't know what this is about and we really hope it isn't a contributing factor to our locking woes.  

I'm considering killing them if no one owns them.

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

Summary

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.

Details

First, let us enumerate some of the mysteries surrounding the EY ESD:

1. After the low-voltage driver was installed (i.e., after 2015-05-22), we found that we had to flip the sign of the L3 actuation from positive to negative. This is despite the fact that both the low-voltage driver and the high-range driver supposedly have positive polarity at dc (so we should not expect to have to compensate for an analog sign flip).
2. After the low-voltage driver was installed, we found that the dc actuation strength of EY L3 was 50 times weaker than EX L3. We expect only a factor of 20×1.25 = 25. The factor of 20 comes from the difference in dc gain between the high-range driver and the low-noise driver (40 V/V versus 2 V/V). The factor of 1.25 is what Kiwamu had previously found necessary to match the dc strengths of EX L3 and EY L3 when they were both driven by the high-range drivers.
3. After the low-voltage driver was installed, the analog readbacks for the high-range driver (bias line and 4 quadrants) were stuck at −15000 ct.
4. After Richard reset the high-range EY driver for the charge measurements (2015-06-11, circa 21:00:00 UTC), there has not been a successful transition of DARM from EX to EY (although there have been only four trials, according to the summary pages).

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.

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.

• The BS limiter was off durring DRMI lock acquisition, this is turned on and off by guardian.  I've attached a screenshot of the gaurdian log.  The code should have returned true imediately after having turned off the limiter, and proceeded onto the next state, however, it ran the LOCK_DRMI_1F run again.  The requested state at this time was DRMI_1F_OFFLOADED, which means that this guardian should have moved onto the next state.  Is there a way to search the Guardian logs to see if we have had other instances of this?
  • we have seen this behavoir in the past, and Jamie suggested that this could have been because the state LOCK_DRMI_1F was requested.  I know that was not the issue today, but I changed the state so that it is no longer a requestable state anyway, since it should never be requested.
• The roll mode damping for ETMY was switched off at the output.  All the roll mode damping settings are now enforced by the guardian, using ezca.get_LIGOFilter().only_on.  

I reloaded both ISC_DRMI and ISC_LOCK guardians today, to incorporate these changes.  

• We had difficulty transitioning to ETMY ESD, evan is writting an alog about what we think is the solution
• Now the winds are quite high, the forecast says they will die down around 1 am.  

Good luck TJ!