Dan Brown, Cheryl, Craig

All three observatories have switched on the OBSERVING bit, and are acquiring triple coincident data. (pic 1) #ER13

Some notes from Hanford Saturday Night Locking:

- I fixed the INCREASE_POWER state so that is actually always goes to the power set in lscparams.input_power['NLN'], which is 20 watts currently.  Previously it would stop anywhere between 10 and 20 because of a race condition within the state.  We lost lock once while trying to get through LOWNOISE_ASC with only 10 watts.

- Dan and I tried engaging the DRMI ASC straight after locking DRMI (INP1, PRC1/2, SRC1/2) using the settings that are in there for full IFO.  PRC1/2 were able to close, but made the alignment worse.  SRC1/2 killed the DRMI lock straightaway.

- MICH ASC sensor transitions are extremely rough, and have caused some locklosses right after acquiring DRMI.  

- We keep having FAST SHUTTER DID NOT CLOSE guardian warnings, even though the fast shutter appears to be working fine.  This causes us to linger in DOWN forever rather than continuing to lock.  This seems to be happening because the LOCKLOSS_SHUTTER_CHECK guardian is always unhappy with the results of its shutter check test.  

- Dan changed the ITMY ringheater set value from 0.89 W to 1.15 W for both upper and lower heaters at 2018/12/16 1:43:54 UTC.  Waiting for things to thermalize to see if this was a move in the right direction.

EDIT:

- We've had two locklosses tonight, neither of which we understand.  There was nothing too suspicious in any of the ASC or LSC signals, the microseism is super high right now, 1 μm/s.  I checked the drift monitors for locks so far, nothing seems to out of the ordinary, maybe SR2 is drifting more than the other optics during the course of the locks, could the significant differential heating of our ITMs be responsible? (pic 3, 4).

- After locklosses, the FSS seems to be losing lock and remaining down for ~4 minutes or so.  The laser crystal temperature seems to be jumping around a lot when it gets close to the correct values (pic 2). I don't understand enough about the FSS autolocker to change anything, but it used to reacquire in under a minute.

- We just recovered the IFO in 28 minutes without us touching it.

EDIT 2:

- We lost lock again after about an hour.  It's possible that this lockloss was due to INP1, PRC1, and PRC2 pitch, but I'm not certain.  It seems like the locklosses tonight have been due to ASC, because the PR gain and POPAIR 18 and 90 respond slightly before the lockloss, and have been "dippy", (i.e. slow fluctions in power) all night.  I accuse PRC1 and PRC2 pitch because they all happened to hit local extrema at the same time as the maximum dip in the power monitors (pic 5).  The problem is these dips don't seem particularly egregious by themselves, especially considering the previous time series of these error signals.

H1 made it to Observe, just broke lock, Dan and Craig are on site, useism is fully above 0.5um/s, and max is crossing 1um/s , winds less than 10 mph.

Keita, TVo, Hang

In the ASC related lockloss reported in Keita's morning alog (LHO:45969), we saw an oscillation grew first in DH Y at 0.8 Hz. See the first attached plot. After that, we were able to went to the nominal low noise state and stay there for > 4 hrs. However, locking at the ASC error points we saw an significant peak at 0.5 Hz in the ARM ASC loops. Both the 0.8 Hz and 0.5 Hz instabilities were due to my original boost filter which tried to partially invert the 10 W plant and thus put more gain at 0.3 Hz to suppress the microseismic motion. However, this boost seemed to make the loop too close to the stability margin and could not tolerate small changes in the ASC OLTFs due to the change in TCS preloading and the CHARD mysterious phase delay at <0.4 Hz for the REFL signal path.

Thus we gave up the original boost filters in both CH Y and DH Y, and simply replaced them with two low Q low height res g's. In the forth plot we showed the comparison of the old boost (blue) and the new boost (red). We gave up 10 dB gain at 0.3 Hz but the new filter made the loops much more robust. In the third plot we showed the ASC error signals after changing to the less aggressive boost.

With this filter modification, we were able to reduce the CHARD YAW loop gain by a factor of 2 (now DC gain 0.75) and engage a more aggressive LP filter than the one we used last night. A comparison between the LP filter we currently use (FM3 in CH Y) and the one we used in the past (FM2 in CH Y) was shown in the fifth attached plot. If we care only the noise above 20 Hz the current filters were fine but if we want to reduce the noise in the 10 - 20 Hz band we had to further shape the CH Y loop.

In the last plot we show the current CH Y loop's model at 10 W. We only need to consider a single power as we have the radiation pressure compensation.

With the modification in the YAW loops we were also able to reduce the DH P gain down. We first tried to decreased it all the way to the original value of -30 (3 Hz UGF) and engage the original, aggressive LP filter ELP10b (FM1 in DH P) . However, after 10 mins or so we saw an oscillation grew in DH P at ~0.5 Hz. Similar to our solution to the yaw loops we removed the DH P boost filter for now and increased the DC gain to -40. This would leave the upper UGF a low phase margin (~20 deg) with the original aggressive LP filter. Nonetheless this seemed fine for now as the loops are stable.

After touching base with Keita, I have turned on CW hardware injections into H1 (scheduled to begin at GPS 1228959604). CW injections are now running at both observatories.

M. Wade

There was an issue at LHO where the OBSERVATION_READY bit of the ODC-MASTER channel was not reporting properly.  Since this is the channel used by the GDS calibration code to determine h(t)-OK in the GDS-CALIB_STATE_VECTOR, in consultation with Keita I made a configuration change so that h(t)-OK is now determined based on OBSERVATION_INTENT instead of OBSERVATION_READY.  This change was made and the pipeline was restarted on the DMT machines at GPS time 1228956497.

TITLE: 12/15 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC

STATE of H1: Commissioning/Observing

INCOMING OPERATOR: Cheryl

SHIFT SUMMARY:

Did initial alignment during the first hour. Lost lock twice before hitting nominal low noise at around 19:00 UTC. After about two hours of trying to get the observation bit to work, we managed to get into Observation mode (see Keita’s alog 45969 for more information). Maintained observation mode until 23:00 UTC, when we started commissioning. Lost lock around 23:40 UTC.

Additional notes: Hanford’s observing mode status was not showing up in summary pages or the LIGO Data Grid Status page. Keita is looking into it.

Following the Qs measurements done by Terra and I a couple of days ago (alog 45812), we wanted to measure the max PI gain for the 15kHz, 15.5kHz and 18kHz (aliased from 47.5kHz) mechanical modes. This is done by ringing up and down these modes for the different test masses during a self heating thermal transient and 2.4 W ring heater transient. When the HOM3 and the mechanical mode frequencies overlap, the maximum PI gain is achieved.

Carl's python script was used to excite the mechanical modes with the ESDs every 300 seconds, similarly to what has been done at LLO (see alog 41630). By fitting the ringdowns, the Qs are then estimated. I've used a homemade matlab script to do the tau fits, manually rejecting bad or fishy data.

We managed to have a ~6hours long stretch (see Dec11.pdf) and ~1h stretch (see Dec12.pdf) both at 20W. During the first lock, we monitored the 15kHz and 18kHz modes (unfortunately, we didn't monitor the 15.5kHz). The measured Qs are shown in Dec11.pdf. relative to the simulated HOM3 spacing (x3). We only observe an evolution of Q (apart for statistical deviation) for mode 14.98 IX, 14,98 IY, 15.01 EY, 15.08 EY and 17.94 EX. Unfortunately, this doesn't seem to correlate with the HOM spacing. Could the simulation be off?

On the following days, the longest lock that we manage to have was an hour. The measured Qs as we go through self heating are shown in Dec12.pdf. The self heating goes fast and we don't have a lot of data point, but I put it there if people are interested. No obvious change in Qs.

To conclude, I would say we have some interesting data that are worth to analyze a little more, as we did see some nice Q changes the first night. By comparing these measurements with what has been done at LLO, we should come up with some interesting numbers... We will work on that in the coming weeks.

Daniel, Nutsinee

Yesterday we tried to see squeezing while PSL is locked with PSL LO just to see if we see the same excess noise at ~1kHz that we saw in DARM during the last squeeze injection (alog45767). I quickly balanced the Homodyne and tweaked the fringe visibility so it was within 90% range (measured 95% out of PD2). I didn't optimize the temperature or measure the non-linear gain since we just wanted to see the excess noise. We saw ~1.5dB of squeezing at ~4mW input to the OPO and ~0.7mW CLF input to the coupler (the CLF locking signal was at about the same strength I would say, roughly about the same CLF power went through as the night we injected into the IFO). The noise looks okay. Whatever we saw in DARM that night didn't exist on the homodyne. We also looked at single homodyne noise with one diode blocked. Most excess noise seems to have come from the PSL LO itself.

For the record, here's an LO in-loop error signal measurement.

Here's what it looked like the night we injected squeezing into the IFO.

Both of these are in-loop measurement. I forgot to write down the gain/boost settings for Dec14 data. Once I have that I'll post an out-of-loop measurement so we can compare apple to apple. The (OMC) LO measurement looks more like (PSL) LO measurement from October 12 (alog44575). These peaky features are new and we think it comes from CLF (some how, electronics cross talk?). They also show up in OPO locking signal. Sheila suggested we try to lock with the old scheme (OPO error signal feed back to itself) and see if the contamination still exists. That is easy enough to do.

How we lock SQZ angle (LO loop):

If the 3MHz signal comes from IFO AS_A, B, then it goes into an IQ demod board. If the signal comes from Homodyne, it goes into a PFD (we used PFD because we had a lot of excess noise which we thought came from PSL LO fiber, PFD gave us more range). The error signal (I) goes to LO common mode board (input1 for OMC 3MHz, input2 for HD 3MHz). the slow signal goes to OPO PZT, and the fast signal goes to TTFSS additive offsets. Depending on gain setting, the UGF can be cranked up to 60kHz (alog44484). 

(Niko, Hang, TVo, Danny, Keita, with Sheila, Dave Barker, Ryan, TJ and JeffK providing telephone technical and moral support)

• After such a windy night, relocking was not difficult at all in the morning.
• We lost lock once during CARM_TO_TR for unknown reason.
• We lost lock once somewhat after CHARD_BLEND or LOWNOISE_ASC due to 0.8Hz ASC oscillation (probably in DHARD_YAW). See Hang's comment.
• Since OMC SUS was still not settled from the initial kick by the OMC ASC when the second lock loss happened (that was before I realized that this was IFO ASC problem), in the next lock I waited for a while in DC_VIOLINS until OMC ASC settled though this might have been a red herring, anyway after this we were able to go to NOMINAL_LOW_NOISE.
• Two things to note at this point.
  1. Somehow we ended up in POWER_17W in nominal low noise. With a telephone support from Sheila, I put ISC_LOCK to manual, went to POWER_ADJUST, requested POWER_20W to LASER_PWR guardian, requested NOMINAL_LOW_NOISE to ISC_LOCK, and then put ISC_LOCK back into auto.
  2. However, in doing the above, we forgot to AC couple the ISS 2nd loop. Somehow the servo was able to take it, and I didn't care to go back to 17W, AC couple, then 20W, then DC couple, because I wasn't sure if AC coupling from DC coupling is reliable at all. So the power injected into IMC might not be the same as when everything is handled automatically by the guardian.
• We approved everything in SDF. Some are really negligible changes (e.g. diff of 1e-17). We need to go through the SDF files to set appropriate tolerances.
• LOCKLOSS_SHUTTER_CHECK guardian was in HIGH_ARM_POWER but the nominal state was LOW_ARM_POWER due to the change made yesterday. This didn't make sense to me so I changed the nominal to HIGH_ARM_POWER.
• We pressed OBSERVE button, the intent bit was set for a fraction of a second but it was reverted back to COMMISSIONING.
  • We lost about 2 or 3 hours due to this, but it turns out that H1:ODC-AUTO_UNSET_OBS_INTENT needed to be set to zero. This should be good enough for the engineering run for now, but we need to think about what we want to do for ODC in the future.
• H1:ODC-OPERATOR_OBSERVATION_READY was successfully set  to 1 at about 2018-12-15 20:51:00 UTC. .

Keith Riles, T.J, Jonathan, Dave:

Late entry for yesterday's and Thursday's work.

external alerts

I wrote a python script to replace the EXTTRIG EPICS channels needed for the system (originally they ran on h1calcs). Jonathan did a lot of work to update the certificate for GraceDB access, and create a virtual environment for the latest code to run on Ubuntu12 (this machine will be upgraded to Debian prior to O3). As before, the code runs under monit control on h1fescript0. I'm unsure if Verbal continues to audibly announce these events.

Hardware Injection

Working with Keith R, we completed the install of the new h1hwinj1 machine (it was upgraded to SL7.5 by installing from scratch). Jonathan created the TCL environment and Keith verified that ps_inject was able to run. (Note to self: we need to test that transient injections are denied if ext_alert is in an event stand-down period.)

Lock_Loss

T.J. got this code ready to run, Jonathan helped with the monit environment settings. This code runs continuously on h1fescript0 under monit control.

Over the last hour, max. wind speeds have been between 25 mph and over 40 mph, and gusts have been easily heard in the CR.  As a test, we tried the SEI config. useism_mod_wind, and couldn't get through ALS, set it back, couldn't get through ALS. 

• Guardian is set to DOWN.
• Efforts to lock are concluded for tonight
• Keita gave the OK to cancel the remainder of the ops eve shift
• still on site at the time of this alog: TVo, Hang, Danny
• Guardian is set to DOWN.

Attached: a plot of some gain changes I used tonight that improved damping, and VAC alarms for 5 days that are in alarm, and since this system is redundant to the notices sent to the VAC team, no known action is required.

J. Kissel, T. Vo, H. Yu, K. Kawabe, C. Vorvick, D. VanderHyde

Hang got us through low noise ASC, and we pushed through switching to low noise ETMX and into nominal low noise for the first time in DAYS. Hooorrrrray!! 

As we were reconciling all SDFs for all models against their OBSERVE files (which we were able to do and we blindly accepted everything), and clearing guardian nodes, in order to got to OBSERVING mode, the wind decided to pick up to 40 mph, and we lost lock. 10 minutes at ~75 Mpc...

J. Kissel

A big time suck after lock losses this evening, and last night, has been the FSS going into oscillation after a full IFO lock loss. This has been reported before (45551) but the loop parameters appear to only have been checked in upon last in late November (LHO aLOGs 45547, 45541). 

I'm not enough of an expert to commission the thing better... we've tried only the few superstitious things we know of -- namely, turning on and off the autolocker. We're typically waiting for the time scale it takes for the temperature loop to scan the entire cavity -- 5 to 10 minutes.