Similar to yesterday's plot but I've added MICH SRCL & PRCL

See the attached three panel for all the three building Pressures coherence to trhe IFO control signals.

Corner Station had coherence approaching 0.7 with Mich at ~20mHz, everything else is less.

WP #5164

Replaced dataviewer and command line nds tools to remove warning message about communication protocol version being unexpected.

WP #5170

Update control room GDS tools to version 2.16.17.2-1, includes awgstream (compiled against new gds libraries, no code change).

This change fixes printing to files in diaggui and foton, gives the user the ability to set very small numbers in awggui, fixes a minor bug in allowed sample rates in foton. 

For the more obscure changes, foton can be used for non-aLIGO filter development involving non-standard sample rates (using a command line option).  In diag and diaggui, multiple broadcast addresses can now be specified as a comma-separated list in the LIGO_RT_BCAST environment variable.  Also in awggui, awgstream, diag and diaggui, setting testpoints can be restricted to specific models.

Comparison between the control channels used for the signal recycling cavity (SRC) alignment, H1 and L1:

Both IFOs use a AS port, 36 MHz WFS to control SRM alignment, though H1 uses WFS B and L1 uses WFS A. I don't know if this difference is arbitraty or reflects some real difference in sensing. Both IFOs use the AS port QPD, AS_C, to control the alignment of SR2, though H1 also feeds this signal to the SRM, to decouple the action of this loop (SRC2) from the SRC1 loop.

The other thing to notice is that the DoF (degree-of-freedom) naming between the H1 and L1 is swapped. This is just unfortunate and should be fixed.

J. Kissel

I had trouble compiling the 
/opt/rtcds/userapps/release/hpi/h1/models/h1hpibs.mdl
in that where all other HEPI top-level models had no problem, the BS wouldn't compile when the actuator output signals were connected to the DAC via a bus & tag system. I tried grabbing new busses and tags and reconnecting, I tried grabbing a new cop of the hepitemplate library part, neither of which worked. It would only compile if I directly connected the library outputs to DAC.

I'll ask the CDS crew to investigate.

J. Kissel

Plan for the morning:
- Recompile, reinstall, and restart BSC HPI models to absorb changes that were a residual from the HAM model updates
- Install ALS EX and EY models, which have been compiled against the tagged release of RCG 2.9.2 (it had only been compiled against the branch to date)
- Restart the frame builder / DAQ / h1cd0 to absorb new TCS Beckhoff channels and the updated channel list from the new BSC HEPI template.

Bringing all IFO guardians to DOWN and IMC guardian to OFFLINE, and bringing BSC Chambers to OFFLINE.

Kiwamu, Elli

NF1611 photodiode taken from ISCT6 and put iinto ISCT1 in front of ASC WFS Reflair A.  There is 6mW coming from REFL-BS3, then we placed the 1611 behind a 90% 45-P beamsplitter.  There was .4mW of light incident on the 1611 when looking at a prompt reflection from the PRM.   The PSL was running at 2.3W. The aux laser was running at 500mW, 0.5mW reached the pd.  I unplugged the power to the BBPD Refl photodiode (Reflair B) to power the 1611. 

The alignment of Aux laser and carrier onto IOT2R was adjusted to maximise the power of both beams onto the 1611PD on this beam.  I tried to lock the aux laser to the carrier frequency plus a fixed offset using a servo controller, same settings as previously, but have not yet succeeded.  To be continued tomorrow.

It seems that the ETMX oplev calibration has been off by a factor of 2.3 with the oplev values smaller than that expected from the alignment biases. I have corrected the calibration of yaw, but not pitch yet. I will do the calibration of pitch tomorrow.

The attached is a plot of the oplev signal in yaw as a function of the alighnment bias before the correction. According to a least square fitting, the oplev was underestimating the angle by a factor of 1/0.436 ~ 2.3. I corrected this by multipling the same factor to the oplev pitch gain so that the gain is now 81.2 /0.436 = 186.2 urad/cnts.

7 - 8 Cris & Karen in LVEA (note on desk)
07:49 Turned the state bit from undisturbed to commissioning
09:23 Elli and Kiwamu to ISCT1 to add photodiode to table
10:05 Ed to H2 building
11:06 Bubba going into LSB LDAS computer room to look at fire extinguisher system
13:50 Keita to end Y to check IR QPD amplifiers
14:24 Keita back
14:42 Kyle to mid Y
16:06 Evan and Elli to ISCT1 to check on photodiode
16:10 Kyle back
16:12 Evan and Elli back

Summary of the PSL trips from 2015-5-1 to 2015-5-3 during the LHO mini run.  Every instance of the PSL tripping was due to the same interlock, H1:PSL-IL_DCHILFLOW, tripping with no apparent loss in coolant flow for the diode chiller, H1:PSL-OSC_DCHILFLOW.  The first three trips on 2015-5-3 were during the long interlock trip that Nutsinee reported in alog 18187.  Data for the other PSL trips over the last 10 days have been reported in alogs 18083 and 18134.  All times UTC.

Apparently I haven't aloged it last week, but oplevs recive the IR scatter from the arm. It's not a big deal, I'm writing this just for the record.

Attached shows one 7W lock when ETMY OPLEV was not working (no light). As soon as IR resonates in the arm, ETMY oplev segments jump up  and the SUM goes to 560 counts (left and middle row). If the oplev laser was alive, this 560 counts would have been added on top of about 30k counts. Fortunately this is mostly common for all four segments, and the effect on the angle readout, when the oplev laser is alive, would have been about  0.03% of the full range, or about 0.03 urad.

The same thing happens to ETMX (right bottom) except that the oplev laser was alive and that the scatter increased the oplev SUM by only 360 counts.

For ITMs the SUM due to the arm scattering seems to be abount an order of magnitude smaller than ETMs, but the oplev power itself is also smaller (3000 to 4000 counts).

J. Kissel

Having processed the last two DARM open loop gains -- the first measurements out to 5 [kHz], and the first measurements after we've tuned up the ASC loops to give us a consistent recycling gain of 35-40 -- I can now make the following statements:
- The DARM Coupled Cavity Pole (CCP) frequency is now consistently much closer to the "as designed" value. The measurements are consistent with a model of the DARM loop using a CCP of 355 [Hz].
- The ETMY ESD's driver pole frequency is 2.2 [kHz], not the colloquially thrown about 2 [kHz].
- I've added the violin modes to the model of the QUAD suspension, and they have no appreciable effect, but I'll leave them in for completeness.

On what these measurements and changes to the model mean for the uncertainty (precision and accuracy):
- The modeled unknown time delay remains at 0 +/- 5 [us].
- The frequency dependent uncertainty in the calibration model remains at +/- 2.5% in magnitude and 1 [deg], but I've data to back up that this extends out to the entire required* frequency band 10 and 2000 [Hz]. See attachment 2015-05-02_FittedCCP_H1DARMOLGTF.pdf (* OK, what *used* to be the requirement. The requirements are now extended albiet inflated out to 5 [kHz]; see T1300950)
- Over these last two measurements, the scale factor used to match the model against measurement has only varied by 3%. Indeed, if you cluster the eight measurements, grouping by CCP, then the standard deviations of the three, three, and two measurements are 7%, 41%, and 3%. However, the total standard deviation of all measurements is 22%, and the latter two measurements are only 1 day apart. From the data I have, I'm still not confident in decreasing the scale-factor uncertainty below 22%; perhaps PCAL can make a better statement on this (but I fear the current Mini-Run noise is too high for the low-frequency PCAL line). See 
2015-05-02_upto5kHzOnly_FittedCCP_H1DARMOLGTF.pdf
- The current calibration installed in the CAL-CS model is incorrect, both in frequency dependence and scale factor. 
    - Frequency dependence: The CAL-CS filters assume a DARM CCP of 389 [Hz] in the sensing path, and an ESD Driver Pole (ESDP) of 2.2 [kHz] in the actuation path. For the latest lock stretches, that inflates the uncertainty of CAL-DELTAL_EXTERNAL_DQ with a known, systematic error of 
      current / correct = ( 1 / (current CCP / correct CCP) + (current ESDP / correct ESDP) ) / (properly normalized)
                        = ( 1/zpk(-2*pi*389,-2*pi*355,355/389) + zpk(-2*pi*2e3,-2*pi*2.2e3,2.2e3/2e3) ) / 2
      which translates to as much as a 7% magnitude error at 1 [kHz], and 1.8 [deg] swing in phase surrounding 1 [kHz].
      This is demonstrated in 2015-05-02_H1CAL-CS_Systematic.pdf,
      This is also reflected in the statistical uncertainty estimate. All comparisons are shown if a 389 Hz CCP and 2 kHz ESDP were used in 2015-05-02_389HzCCP_2p0kHzESDPole_H1DARMOLGTF.pdf.
    - Scale Factor: this depends on whether we want to use 22% or 3% for our scale factor uncertainty. If 22%, then the last two lock stretches still fall within the 1.1e6 +/ 22% [ct/m]. But, if the scale factor is 1.2725e6 (the mean of the last two scale factors), then that indeed falls outside of 1.1e6 +/-3%
    - We *still* have not implemented any compensation for the analog or digital, AA or AI filters. 
- The GDS/DMT produced calibration is off just as much as the CAL-CS produced calibration, because GDS/DMT calibration is using the same filters.

------------------
All parameter files have been committed (with updated ESD driver poles, and fitted DARM coupled cavity poles) here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Scripts/
H1DARMparams_1109994128.m
H1DARMparams_1111998876.m
H1DARMparams_1112399129.m
H1DARMparams_1112933759.m
H1DARMparams_1112942996.m
H1DARMparams_1113119652.m
H1DARMparams_1114541595.m
H1DARMparams_1114634170.m

Which are processed by the DARM model function here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Scripts/H1DARMmodel_preER7.m

And then compared with the script here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Scripts/CompareDARMOLGTFs.m

J. Kissel, N. Kijbunchoo

We've tried several more times to reacquire lock after the damping the rung up violin modes (LHO aLOG 18153), a slow but steady increase in wind up to the current 30-35 [mph] (see 1st attachment), the PSL tripping (LHO aLOG 18159), a mysterious guardian failure (LHO aLOG 18162), and now a rigorous trip of the ETMX seismic isolation because of what I think is my user error. We've run out of steam, and I don't think there's a point in continuing to battle the IFO under these terribly windy conditions. We'll start again tomorrow morning.

Some details from the few lock acquisition attempts after the Guardian failure:
Attempt 1: Just let the guardian try and do it's thing. Lost lock at the start of TRANSITION_TO_QPDs (but didn't realize it)
Attempt 2: Noticed the recycling gain (as measured by ASAIR) was low, lost lock again
Because I'd heard Kiwamu talking about low recycling gain vs. high recycling gain causing a sign flip in the ASC loops, I suspected the low recycling gain was the problem. So I had Nusinee play with the alignment of PR3, and the ITMs to try and get the ASAIR  signal back up into the 600s (where is was in the 500s). She found that PR3 YAW was most effective (and the recycling gain has stayed in the 600s since she touched it up) -- we still lost lock on the TRANSITION TO QPDS.
Attempt 3: After relocking, the recycling gain came up awesomely with out having to touch anything. Still lost lock at the same point.
Attempt 4: This time, requested DRMI_LOCKED, such that we could go manually through each of the steps leading up to SWITCH_TO_QPDs. We got as far as the step right before -- REDUCE_CARM_OFFSET -- which completed. I was *just* about to hit go on the TRANSISTION_TO_QPDS when we lost lock.
Then Nutsinee noticed that the ETMX SEI isolation system had tripped. After chasing down a bunch of WD trip and lock loss tools, we found the lock loss in the following order:
HEPI 03:54:12 UTC (Actuators)
IFO  03:54:13 UTC 
ISI  03:54:19 UTC (ST1 Actuators)
TMSX 03:54:24 UTC
Now, because I was messing around with the ISC_LOCK guardian in manual, I have a feeling it was me somehow sending a huge Tidal impulse to HEPI that took down the chamber but I can't be sure. Looking at the plot of the lock loss, it's certainly a huge impulsive spike that kicks the chamber, not like some slow shove from the wind or as if the Tidal was huge (again because of wind) and it suddenly hit the edge of the range.

Anyways, I don't think there's something systematically wrong with HEPI that we need to freak out about, this was one lock loss of MANY over the past day, and my gut feeling tells me that the problem right now is that the TRANSITION_TO_QPDs fails while it's servoing the ALS-C_DIFF_PLL_CTRL_OFFSET and even during the REDUCE_CARM_OFFSET, because there's too much uncontrolled arm angular motion (from wind) for the CARM reduction to happen. According to the guardian logs, this servo seems to stress and eventually break the IMC lock, but I'm not sure if it's a cause or effect.

We're gunna try to lock one more time, because getting to DRMI_LOCKED is incredibly robust, even in these high winds. BUT, we're not gunna log the result if negative and just go home. 

I have created a 10 minute injection file simulating a stochastic source at omega_GW=1 at 100Hz, and placed it on the cds system in:
/ligo/home/edward.daw/research/hardware_injections/2015_05_01/inj10mins.txt
The file was created as follows:
on the h1hwinj1 machine,
cd /ligo/home/edward.dad/research/hardware_injections/dependencies/sources/virgo/NAPNEW/SCRIPTS/IsotropicSbGenerator
python IsotropicSbGenerator.py --init IsotropicSbGenerator2.ini
This code generates a single 600 second frame which I subsequently moved to /ligo/home/edward.daw/research/hardware_injections/2015_05_01/SB_HI_L1-1114555770-600.gwf.
To convert the frame to an ascii file, I tried running a local matlab, but I couldn't get a license. I therefore shipped the frame to my laptop, and used matlab interactively:
>> [data,tsamp]=frgetvect('SB_HI_L1-1114555770-600.gwf','H1:strain',1114555770,600);
>> outfile=fopen('inj10mins.txt','w');
>> fprintf(outfile,'%g',data);
>> fclose(outfile);
...and finally I used gsisftp to move the resulting text file back to the cds machine at the above location.
The above matlab code could easily be used to scale the data by a factor, as it seems you have done with previous injections, if the existing scale proves inappropriate for the injection. Please inject this 10 minute duration signal once the machine is stable and you are ready for more injection tests.
Thanks. 
Ed