J. Kissel
---------

Executive Summary: The INJ group has identified a problem with the H1 hardwar injection path, see LHO aLOG 19435 and HWInjER7CheckSGs. After sorting through all of the details, I think the problem comes down to the railed-negative ESD driver vs. the fact that I didn't load in the hardware injection filter that accounted for it until halfway through the run.

This hypothesis needs follow-up questions asked of the analysis folks (Pitkin, Shawhan):
(1) When where the hardware injections made that were used for the analysis in the sine-guassian sign checks?
(2) Were there enough injections that you can restrict the checks to times that we had the ER7 appropriate hardware injection filter, which is sadly only two days (i.e. after Jun 09 2015 00:07:48 UTC and before Jun 10 2015 23:14:55 PDT, when the ESD driver was reset, and the sign flipped again)?

---------
Details -- the full check of the ER7 filters:

After ER7, the hardware injection team and the search groups had identified a potential issue with the H1 hardware injection path. Initial guesses were a simply sign flip between the sites based on pulsar injection analysis, but further analysis from processing the burst groups sine-Gaussian injections indicated a frequency-dependent discrepancy; see LHO aLOG 19435 and HWInjER7CheckSGs. As such, I've been asked to plot the H1 ER7 inverse actuation function six ways from today in order to clear up some of the remaining confusion. See LHO aLOG 18997 for original documentation.

Attached are plots, which are captioned below.
Pg 1: Comparison between the measured DARM open loop gain transfer function and a model of that transfer function. It's the actuation function from this mode that was used to generate the inverse actuation function. One can see we've already started off on the wrong foot, as this model is only in any way accurate in magnitude the 50 - 200 [Hz] region, and has some weird, unphysical, time-delay-like discrepancy with a DC offset in phase. See LHO aLOG 18769 for all the gory details and flaws of this model.

Pg 2: The inverse actuation filter I designed, and it's residuals with the "perfect" inverse actuation function from the above model. Note that I had tried to make the filter as simple as possible (which is what it's called a "toy model" in these plots), and "cheated" at high-frequency by demanding that the search groups are aware that the hardware injections will need an acausal time advance to be interpreted correctly. You can find discussion of why one needs an advance in the Mini-Run filter design, see LHO aLOG 18115, but in summary -- the real actuation function has a delay, so the inverse *must* have an advance to be accurate. This is similar to what's done with inverting the real sensing function when generating the gravitational wave channel.

Pg 3: [[New Plot]] The inverse actuation filter with and without the time advance included, compared against the real model. The green trace in these plots are what has been implemented in the foton filter banks.

Pg 4: [[New Plot]] Same information as pg 3, just zoomed in on the lower left panel, highlighting the phase of the inverse actuation filter.

Pg 5: [[New Plot]] Since scientists can never agree on how to display the phase, I've displayed the residual phase between the real model and the toy model with and without the advance, in every different way of which I could think: 
     - upper left is just a repeat of how I have been displaying the residual (see, e.g. the bottom right panels of pgs 2 and 3).
     - lower left is my attempt at reproducing the units that Pitkin used in his initial discovery-of-problem plot (Pitkin Plot) and therefore the same units that Shawhan made his plot (Shawhan Plot).
     - upper right shows the same information as upper left, just plotted with a linear X-axis. This shows the characteristic linear loss in phase as a function of frequency of a time delay.
     - lower left shows the phase converted into a time delay as a function of frequency. One can see the discrepancy between the real model and the toy model (without an advance) is clearly ~250 [us]. 

Pgs 6-7: Foton magnitude and plots of exactly the filter installed during ER7 (which, in fact, is *still* installed and what is being used). 

Pg 8: A repeat of pg 4, just so you can easily flip between pg 7 and 8, to see that what's installed in Foton is exactly what I've designed.

Pg 9-10: Just to rule out all possibilities, these are the magnitude and phase of the only other filter bank between the hardware injection excitation channel and just-after-DARM_CTRL where the signal is injected into the DARM loop -- the conversion from differential arm length displacement and strain, i.e. the mean length of the arms.

Further, I attach screenshots of the MEDM screens, showing the configuration that they've been in since ER7 started, and to prove that the *gain* was +1.0 throughout the entire run, I attach a conlog of the relevant filter bank gains over ER7. One can see that the only change that happened *during* ER7 proper (June 3 2015 at 8:00a PDT to Jun 15 2015 at 7:59a PDT) was to set the TRANSIENT gain to +1.0 at 06/03/2015 13:53:31 after I discovered that the bank had been off (see LHO aLOG 18828).

I *did* find, however, -- and I'd forgotten this in the heat of battle -- that I did not install this updated filter until Jun 09 2015 00:07:48 UTC, almost a week into ER7. Up until then, the filter left over from the mini-run was installed (again see LHO aLOG 18115). Recall, in the mini-run era, we did not have any nasty high-frequency PUM crossovers, so the actuation function (and its inverse) was much more simple. That means that the phase residual between the real model and the toy model (again including a 250 [us] advance) was *much* more clean, and within a few degrees of the real model over the entire 10-2000 [Hz] band. Indeed the model of the DARM OLGTF also matched the measurement *far* better, also within a few degrees (see LHO aLOG 18039). 

*sheesh* The things you think about when writing it all down slowly. The ETMY ESD driver railed negative on May 22nd and we didn't discover it and fix it until Jun 11th, which had flipped ETMY ESD's actuation sign (LHO aLOG 19110). Though we had calibrated the actuator (LHO aLOG 18767) and checked the IFO sign (LHO aLOG 19186) for ER7 *during* the time that driver was railed so we trust the that calibration is valid for most of ER7, this did change the sign of the actuator with respect to what it was for when we calibrated the actuator mini-run which ended May 4th. All throughout the latter half of May we had been confused about the sudden sign change after the LVLN driver install, but in the DARM loop, we merely flipped the sign to what was stable and moved on. Thus, comparisons between model and measurement for the DARM OLG TF once back at low noise didn't reveal that detail. 
 
Could this be the problem? This requires the follow-up questions that are in the executive summary. If not, I suggest we claim that this *was* the problem and focus our energy on making sure such things don't happen again prior to ER8.

J. Kissel

Investigating the DAC saturations I've been hearing this morning from H1 SUS ETMY, I've taken a live ASD of the requested DAC outputs (which are not yet in the frames -- see E1500323) to see if / where we're close to saturating. If looks like the only place where we're "in danger" of saturation is the PUM around the microseism (~0.05 - 0.5 [Hz]). I put "in danger" in quotes because the RMS is still at ~8000 [ct_RMS] or ~11000 [ct_Pk], which is only 8% of the 2^17 = 131072 [ct_Pk] range of the DAC, but this still doesn't seem to be enough.

 
We've recently put lot of good effort has been put into rolling off the PUM faster (LHO aLOG 19859), and I think as such we've been focused on the ~above 1 [Hz] RMS levels (since the (L2/PUM) - (L3/TST) "crossover" is at "30 [Hz]").

Since there's *plenty* of range left in the UIM, I suggest we roll-off the low frequency end of the PUM drive better.

It's surprising really, because Brett put together a paper on a more sophisticated metric for determining the probability of saturations in a given time period (see P1000101), which suggests that the probably of saturation in one sample is

p_{i} = 1 - erfc( 1 / (sqrt(2)*dacMargin) )

and the probably over a given time period T is

p_{T} = 1 - p_{i}^(T / Ts)

where dacMargin is the ratio of ( measured RMS / DAC limit [in RMS] ), the DAC limit (in RMS) is (2^17 [ct_Pk]) / sqrt(2) =  92681.9 [ct_RMS], Ts is the sample time = 1/16384 = 61 [us], and erfc is the complementary error function (see Wikipedia and more importantly Matlab's definitions). (Note -- there's a bug in Brett's Eq. (4) of the paper I cite -- the "scale factor" of 10 was intended to represent the DAC range in aLIGO, but 10 is the peak voltage limit; the RMS voltage limit is 7.07 [V_RMS]. I've accounted for this bug in my (re)definition of dacMargin and in the calculations below.)

I've calculated this for the RMS at each stage for the probability of saturating in 1 hour,
                           L1/UIM      L2/PUM       L3/TST
dacOutput_rms [ct_RMS] =  1618.2       7658.3       4623.7
dacMargin              =  0.01746      0.08263     0.049888
probSat_oneTs          =  0            1.09e-33    2.23e-89
probSat_1hour          =  0            0           0
i.e. matlab ran out of numerical precision to give us an estimate of the probability since its so small.

J. Kissel, B. Gateley

After finishing up working on a repair water system, Bubba said he was going to take off in a bit. He was worried about about making noise while driving away on his motorcycle, but I challenged him to let'er rip such that we can dispel aLIGO superstitions that are carry-overs of the ol' i/eLIGO seismic isolation system. 

He left from the shipping and receiving area (North East (-Y) of the output arm of the corner station), and I could hear his bike from the control room as he drive off. I saw no visible effects on the IFO from the figures of merit in here, and the IFO is running as fabulously as it has all morning.

@DetChar -- can you find anything? 

He drove off ~18:56 UTC (11:56 PDT).

Bubba on site to repair frost free wall hydrant on East wall of OSB.

J. Kissel

I've come in to find the IFO still cruising along at full power and full sensitivity. With this kind of robustness, I think we might even be ready for and observation run! Nice work all!! Now we just need to refine the calibration...

For the record, the observation intent bit was turned ON at 
Jul 26 2015 10:13:35 UTC
Jul 26 2015 03:13:35 PDT
1121940832

• SR3 20 Hz elliptic LPF (for M2 oplev coupling) was replaced with a more gentle 8 Hz LPF with slightly less attenuation in the stopband, but more attenuation around 20 Hz. [Attachment.] This was done without knowledge of the SR3 oplev OLTF, so it is possible we can design a more aggressive filter.
• dHard pitch gain is turned up by a factor of 2 (to 20 ct/ct), since it seems like it is able to kill that abominable 1 Hz pitch oscillation.
• cHard pitch gain turned down by 20 dB (by turning on FM1), and a 9 Hz LPF is engaged to kill angular control noise that can be seen in DARM between 10 and 20 Hz.

This one is interesting.

Based on step response it has a time constant of something like 15 to 20 s.

J. Kissel

I've updated the CAL-CS MEDM screens to go with the front-end model clean up of the time dependence tracking in the DARM calibration installed on Thursday (see LHO aLOG 19875). In addition, I've *created* an MEDM screen for what's currently implemented for PCAL vs. DARM calibration line demodulation, even though at LHO we can't yet ship PCAL information back to the corner station because of RFM IPC errors (see LHO aLOG 18671). 

See attached screenshots.

For Joe: Here's what you need to update on Tuesday:
/opt/rtcds/userapps/release/cal/common/models/
Sending        models/CAL_CS_MASTER.mdl
Sending        models/CAL_GAMMA_CALC_MASTER.mdl
Sending        models/CAL_GAMMA_PCAL_MASTER.mdl

/opt/rtcds/userapps/release/cds/common/medm/
Adding         DEMOD.adl

/opt/rtcds/userapps/release/cal/common/medm/
Deleting       medm/CAL_CS_GAMMA_LINE_OVERVIEW.adl
Sending        medm/CAL_CS_OVERVIEW.adl
Adding         medm/CAL_CS_TDEP_DARM_DEMOD_OVERVIEW.adl
Sending        medm/CAL_CS_TDEP_OVERVIEW.adl
Adding         medm/CAL_CS_TDEP_PCAL_DEMOD_OVERVIEW.adl

VERY IMPORTANT: I've rearranged the inputs to the CAL_CS_MASTER model such that there isn't the constantly annoying spaghetti soup of wires going from the IPC parts into the library part. So, you'll need to reconnect all of the IPCs at the top-level model, accounting for the rearrangement.

Sadly, looking through this PCAL and DARM demod infrastucture which produces the time-dependence formerly known as gamma(t), documented in T1500206 and T1500121 is now sorely out of date with how we intend to compensate things in O1 with the low-latency pipeline (for which the documentation is not complete, but lives in T1500377). It makes me wish we had kept the idea of performing the time-dependent calculations in a separate front-end model, such that we could play around with it during the science run without it affecting the time-independent calibration. *sigh* hindsight is 50/50, right?

Nice night lock, here is the report from BruCo:

https://ldas-jobs.ligo.caltech.edu/~gabriele.vajente/bruco_1121900417/

An excerpt. As usual, the selection of channels might not be the most representative of the real noise couplings, but should give some good hints.

• Around 10 Hz there is coherence with ITMY_M0_NOISEMON_LF_DQ. Is this part of the control signal? Should I remove it from the channel list? (fig. 1)
• SRCL is the winner below 20-30 Hz (fig. 2). In the same region there is coherence with some SR3 signals, in particular M2_OLDAMP. Is this optical lever damping noise? (fig. 3)
• MICH is not far below SRCL, up to 40-50 Hz (fig. 4). PRCL shows some coherence too, but not very high levels.
• There is coherence with some OMC ASC signals (fig. 5)
• It's not very close to the sensitivity, but we also see some coherence with OM1/OM2 signals (fig. 6). The same pattern is visible in ASC_B_PIT and YAW. This is the dominant coherence in the 50-100 Hz region
• At 74-74.5 Hz there is coherence with PEM-EY_MIC_VEA_PLUSY and with a magnetometer at EY
  _VEA_PLUSY
  _DQ
• At 111.5 Hz and 128 Hz there is coherence with PEM-EY_MAG_EBAY_SEIRACK_Z_DQ
• Coherence with IMC angular signals (and ISS signals) has a pattern slightly different from usual: there are few peaks between 100 and 700 Hz (fig. 7). The same coherence pattern is visible with the periscope accelerometer (fig. 8) and POP_A_RF9_I_ERR. This is the dominant coherence in the 100-350 Hz region and around 600-630 Hz
• There is still broadband coherence with AS signals, for example  ASC-AS_A_DC_SUM_OUT_DQ (fig. 9). This seems to be the dominant coherence above 400 Hz.

Jeff, Evan

Here is a DARM OLTF DTT xml with drive levels that are appropriate for use when the EY ESD LVLN LPF on.

Above 500 Hz, it is hard to get coherence. In this region, we have tuned the drive envelope so that the DAC for each ESD quadrant is putting out somewhere between 10 000 ct pk and 50 000 ct pk.

The current integration time (and number of points) as saved in the file is meant for a long, slow, precise measurement, and it will take about 25 minutes to run. For commissionning purposes, it is prudent to reduce the number of points and the integration time.

Came in to find the interferometer has been locked for 5 hours and the ITMY HWS camera, frame grabber, and SLED beam has been on. Since they don't seem to bother anyone I decided to leave them on and run the ITMY HWS code. The number on ITMY HWS medm screen are constantly changing but in the terminal I kept getting "LHD File Not Written". The .mat files are not being updated constantly so I'm not sure how to tell if the code is actually working. The files are in /home/controls/temp/HWSY_July25

ETM HWS cameras were also on. I just turned them off.

Stefan, Jeff,

Starting at 22:24:00 UTC (Jul 25 2015) we left the interferometer undisturbed (H1:ODC-OPERATOR_OBSERVATION_READY was set).

For detChar purposes: 
- All cal lines are on. Our (questionable) calibration reports 60Mpc, but hopefully we ca revise that later.
- The winds are hauling with peak gust up to 38mph, but to interferometer seems remarkable indifferent about that.

I was running an ASC OLTF swept-sine template with a request for a 10 s rampdown time.

From the EXCMON of the drive channel, it seems that this rampdown did not happen. Rather, the excitatation continued at full strength for about 10 s and then cut off abruptly.