I tried for a while today to go back toward our July 16th alignments, as suggested by Sheila in alog 30648.  I put offsets in POP_A and the SOFT loops to try to make the witnesses/oplevs go back toward their July16th values. 

I only made the DARM spectrum worse, not better.  In the attached screenshot, green is the spectrum before I started doing anything, pink is after my alignment work, and red is after taking the offsets out again. 

I also attach a screenshot showing that the buildups and the recycling gain all deteriorated while trying to go back to July's alignment.  To be fair, I was not able to get all optics' witnesses back to their July values, so it's still not really the same alignment, but I think it's closer than what we usually run with.  I don't really think that this is a fruitful direction to continue to persue unfortunately, especially in light of what has just been discovered about the noise improvement when we close the DBB. 

TITLE: 10/18 Day Shift: 15:00-23:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Lock Aquisition

SHIFT SUMMARY: Locking has been better today, but ITMY bounce modes16:00 Kyle to EX

2:30 pm local

Took 3 min. 30 sec. to overfill CP3 with 1/2 turn open on bypass LLCV. Newly installed thermocouples in exhaust pipe (a few feet up the vertical run) responded well to LN2. On Friday let's overfill by doubling LLCV setting (to ~34% open) and see how long it takes for LN2 to trickle out. Meanwhile I've increased LLCV from 16% to 17% open.

3600 second trend attached. As soon as I opened the bypass valve I saw a {small} dip in temperature. 

Sheila, Terra, Jeff K, Patrick, Nutsinee

Tonight we continued with the PRMI locking difficulties of yesterday.  Nutsinee managed to lock PRMI by lowering the MICH gain and commenting the boost and offloading out of the guardian. 

Patrick tracked down some differences between the "good" PRMI time that Jenne mentioned (Oct 17 16:03 UTC) and now, there was a filter missing in the BS top mass offloading, and two whtening stages (with the anti whitening) were engaged in the middle of the lock yesterday afternoon.  We don't know why this happened, but just undoing it actually makes it impossible to lock at all. 

To match the PRCL loop shape to a reference, I had to add 6 db of gain (PRCL digital gain of 16 rather than 8).   However it looks like we still missing some kind of boost in PRCL (1st screenshot).  The second screenshot shows the MICH loop measured today on the left, before and after the PRCL fix, and an old measurement on the left. 

We have commented out the boost and offloading of MICH in the guardian for PRMI, and nutsinee created  new prmi_mich_gain_als and prmi_prcl_gain_als parameters in lscparams, and we have set them to 0.7 and 16 for now, although the nominal values should be 1.4 and 8.  You will have to reduce the MICH gain by hand to get it lock. 

Could who ever did some measurements that required changing the REFLAIR whitnening gain triple check that whatever they did is not causing us problems in the morning?

Evan G., Chris B., Rick S.

Summary:
We started the INJ_TRANS guardian node, but due to a time zone issue in the gpstime python module, we couldn't schedule injections to verify the code was doing the right thing. We will come back to make the final tests once the time zone issue is sorted out. 

Details:
To do this test, we logged into the guardian machine and updated the guardian SVN to get the latest and greatest updates from Chris.

Then, because the guardian node for INJ_TRANS was not running, we started it by
$ guardctrl create INJ_TRANS; guardctrl start INJ_TRANS

We added a test injection to the new schedule file, set an injection time in the near future, and verified it by the following:
$ PYTHONPATH=/opt/rtcds/userapps/release/cal/common/guardian:${PYTHONPATH}
$ CAL_USER_APPS=/opt/rtcds/userapps/release/cal/common
$ python ${CAL_USER_APPS}/scripts/guardian_inj_schedule_validation.py --schedule ${CAL_USER_APPS}/guardian/schedule/schedule_1160692574.txt --min-cadence 300 --ifos H1

The state of the guardian never changed as it should have, so after some debugging, we found the difference in the GPS time the node thinks it is versus what GPS time it really is, is about 7 hours. It is likely due to the fact we got the following warning when starting the guardian node:
/ligo/apps/linux-x86_64/gpstime/lib/python2.7/site-packages/gpstime-0.1.2-py2.7.egg/gpstime/__init__.py:220: RuntimeWarning: GPS converstion requires timezone info.  Assuming local time...
  RuntimeWarning).

Chris is going to investigate how to set the time zone info for the GPS module before we try again to fully test the infrastructure

As mentioned in alog 30663, we have a slightly new infrastructure for balancing the OMC DCPDs.  I used the method that JeffK et al. used in alog 29856 to measure the imbalance between A and B. 

I'm not sure why I'm getting a different value for the imbalance than they did (I get that the ratio of B/A = 0.969 rather than their 0.958).  Perhaps we should look at how this number is actually changing over time, if it is.

Anyhow, the balancing matrix is now populated.  See screenshot for values.

model restarts logged for Mon 17/Oct/2016 No restarts reported

model restarts logged for Tue 18/Oct/2016

RCG upgrade, all frontend systems and DAQ restarted. Full log in attached file.

https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=30631

Satisfies FAMIS asset 364 maintenance

[Kiwamu, Jenne]

It looks like we did an svn-up of the OMC model sometime recently, and then it was compiled and installed yesterday with the RCG upgrade.  Due to the changes, and the fact that matrix EPICS values initialize to zero, we were getting a value of digital zero for the OMC DCPD sum, even though we were clearly seeing nice flashes on the camera. 

Kiwamu logged in to LLO and did an svn checkin of the new OMC screens that match the new model (they were modified there, but not checked in), and then we pulled them here.  This allowed us to set the matrix, and we're back in business. 

It is the channel OMC-DCPD_BALANCE (or something like that) that disappeared, and is replaced by an explicit matrix to take the _A and _B signals and form the sum and null channels. 

Kiwamu is currently finishing resolving the svn conflicts, so that both sites will be back in sync.

Installed two thermocouples per WP 6249 and connected to existing CDS channels:

HO:VAC-MY_CP3_TE202A_DISCHARGE_TEMP_DEGC
HO:VAC-MY_CP3_TE202B_DISCHARGE_TEMP_DEGC

Removed TC inside CP4 exhaust and reinstalled its check valve.

at 09:30 PDT this morning h1fw0 restarted itself with reports of a slow QFS disk system. Normally a power cycle of the solaris QFS/NFS server resolves these problems. Between 10:40 and 11:00 PDT I power cycled h1fw0 and h1ldasgw0. We will continue to monitor fw0's status.

   Fit air bleed intake filters to all pumps, and adjust pressures to 19.0inHg. All pump temperatures are normal. closed FAMIS #7506

Don't have remote monitoring and will need to enter X-end VEA to make measurements sometime this afternoon.

The first attached screenshot is a series of DCPD spectra from the last several months.  When we first turned on the HPO, the noise in DARM did not get any worse.  The noise stayed similar to O1 until July 16th, the lump from 200-1kHz started to appear in late July, when we started a series of changes in alignment and TCS to keep us stable with a decent recycling gain at 50 Watts.  

PMC

Last night, Gabriele pointed out that the noise in DARM is coherent with the PMC HV.  The HV readback had been mostly some white noise (probably ADC noise), until the last few weeks, but has been getting noisier so that some of the things jitter peaks show up in it now (SEcond attached screenshot, colors corespond to the dates in the DCPD spectrum legend.  This may be related to the problem described in LLO alogs 16186 and 15986.  The PMC transmision has been degrading since July, which could be a symptom of misalingment.  Since July, the REFL power has nearly doubled from 22 to 38 Watts, while the transmission has dropped 28%.  The PMC sum has also dropped by 4%, roughly consistent with the 3% drop in the power out of the laser.  Peter and Jason are planning on realigning the PMC in the morning, so it will be interesting to see if we see any difference in the HV readback.  

TCS + PRC alignment:

The other two main changes we have had in this time are changes in the alignment through the PRC, and changes to TCS.  These things were done to improve our recycling gain and stability without watching the noise impact carefully.  In July we were using no offsets in the POP A QPDs.  We started changing the offsets on August 1st, after the lumpy noise first appeared around July 22nd.  We have continued to change them every few weeks since then, but generally moving in the same direction.  

The only TCS change that directly coresponds to the dates when our noise got worse was the reduction of ETMY RH from 0.75 W each on July 22nd, the other main TCS changes happened September 10th.  It would be nice to undo some of these changes before turning off the HPO, even if it means reduing the power to be stable.  

Work Permit Number: 6252

The DMT calibration has been updated to gstlal-calibration 1.0.6-2.el7. Because of dependencies GDS was also updated to: gds-2.17.10-2.

John Zweizig has restarted the DMT monitors.
 

J. Kissel, S. Dwyer, L. Barsotti

At the advice of DetChar (LHO aLOG 29828) we've balanced the DCPDs, which indeed hasn't been done since the new breadboard and PDs were installed (LHO aLOG 28862). Unlike the previous pair of DCPDs which were out-of-the-box perfectly balanced (see LHO aLOG 17650), the current pair has an imbalance of 2.1106%. This value has been entered into H1:OMC-DCPD_BALANCE, and accepted into the SDF "down" state for the h1omc model.

Method:
For the DCPD sum, we take an average of the two: A/2 + B/2.
The h1omc front-end infrastructure is built such that the percentage imbalance, e, is applied to both equally: A*(1 + e)/2 + B(1 - e)/2
So, the transfer function measurement of DCPD A/B is (1+e)/(1-e) ~ 1 + 2e. Since the transfer function magnitude is 0.957788, then the imbalance we enter will be e = ((A/B) - 1) / 2 = 0.021106 = -2.1106%.

We also found this value gradually (because we weren't sure how the infrastructure worked), by confirming the imbalance that minimized the DCPD NULL stream (and the coherence drops to zero). Overshooting the imbalance (e.g. by entering in -4.2%) shows a clear sign flip from the reference trace where there is 0% imbalance compensation.