Attached is a pre-ER7 list of narrow lines seen above 5 Hz in recent H1 DARM data, along with spectra containing labels for the lines.

The spectra used for line-hunting are from 18 hours of DC-readout conditions on May 17. Most of the lines were also seen
in the early-May mini-run data, but are more exposed in the more sensitive May 17 data (see figure 1)

Notable combs / lines:

 Exact integers: 16.0000 Hz, 64.0000 Hz (distinctly louder than other 16-Hz lines), 81.0000 Hz, 1150.0000 Hz, 1672.0000 Hz, 1704.0000 Hz, 1880.0000 Hz, 1896.0000 Hz
 Nearly exact-integer combs: 

 3.9994 Hz (offset by ~2 Hz from zero, first visible harmonic at 13.9977 Hz -- these seem to correlate with a near 4-Hz comb starting at 2 Hz in EX magnetometers (and to a lesser degree in EY magnetometers), where the contamination in DARM at 10 Hz and below is presumably too faint to be seen in the rapidly rising DARM noise. A strong comb is apparent in PEM FScans.
 99.9989 Hz (correlated with magnetometers in EX - see NoEMi and PEM FScans)

 Quad suspension violin modes with fundamentals near 500 Hz are not quite truly harmonic, but some of their upconversion is (see figure 2)
 Especially pervasive combs: 3.9994 Hz (34 harmonics), 16.0000 Hz (124 harmonics), 60.0 Hz (9 harmonics), 64.0000 Hz (31 harmonics), 36.9733 (54 harmonics), 59.9954 (6 harmonics), 99.9989 (13 harmonics)
 There are tentative identifications here of lines near 300 Hz and their harmonics as due to beam splitter violin modes, but their frequencies shifted by several mHz between the mini-run and the May 17 lock stretches, unlike the quad suspension violin modes which hardly moved at all (attributable to temperature?)
 Designated calibration line frequencies are shown on the spectra even when there is no apparent line (some not yet enabled?)

Notes:

 Because the binning in the spectra is 0.5 mHz (based on 30-minute FScan Hann-windowed SFTs), but the line widths in the plots are much larger, the spectra shown here look awful (but aren't). Dewhitening applies five poles at 1 Hz and five zeroes at 100 Hz.
 I didn't bother labeling the forest of bounce/roll-mode sidebands on the quad suspensions and their harmonics
 Although the 1150-Hz line seems well centered on the integer value, its energy is spread over several tenths of a Hz, unlike other integer-Hz lines
 Many line frequencies are give to four digits after the decimal point, but their statistical uncertainties are typically no better than a few tenths of a mHz, and based on changes between early and mid May, some lines have systematic drifts of O(mHz).
 With one exception, the quad violin mode fundamental frequencies were determined from the mini-run data, where they were more excited than on May 17. Those frequencies agree (independently) to within 2 mHz (in most cases, to better than 1 mHz) with the frequencies measured for individual test masses here. The one exception was that I had originally marked 504.1492 Hz as a mode in the mini-run, while the earlier study had found a mode instead at 501.254 Hz. Since the earlier measurements are guided by test-stand data, I am deferring to them and tagging 501.2544 Hz here, since I do see a line there in the mini-run data, albeit weaker than other modes.


Key to spectra labels:

b = Bounce modes
r = Roll modes
C = Calibration lines
L = Lock-in oscillator
M = Power Mains comb
N = Near to power mains comb
S = 64 Hz comb
s = 16 Hz comb
F = Near to 4 Hz (3.9994 Hz) comb
H = Near to 100 Hz (99.9989 Hz) comb
D =  59.3155 Hz comb
E = 36.9733 Hz comb
G = 75.23 Hz comb
Q = Quad violin modes
B = Beam splitter violin modes
x = Miscellaneous singlets

Figures:
1 - Superposition of 0-2000 Hz spectra for minirun (29.5 hours) and May 17 data (18 hours)
2 - Quad violin mode regions for first three harmonics (actual modes are non-harmonic, but some upconversion of fundamental is propagation harmonically)
3 - May 17 spectrum with labeled lines

Other attachments:
1 - Ascii list of narrow lines / combs found in 0-2000 Hz
2 - zipped tar file of 27 sub-band spectra (mostly 100-Hz wide)

J. Kissel, D. Barker,

Receiveing word from DetChar on yesterday's run meeting call that they're seeing major carry transition glitches in the IMC, Dave and I have restarted the h1iopsush34 front end model on the h1sush34 front-end, which runs a calibration routine on the 18-bit DACs in the corresponding I/O chassis. The reboot is now complete, and the IMC is up and running. We've confirmed that all DAC cards had a successful auto-calkbiration.


controls@h1sush34 ~ 0$ uptime
 11:52:19 up 13 days, 33 min,  0 users,  load average: 0.01, 0.02, 0.00
controls@h1sush34 ~ 0$ dmesg | grep AUTOCAL
# After the I/O chassis Power Supply, Timing Slave Firmware, and 18 bit DAC card upgrades had finished on May 21 2015:
[   49.512048] h1iopsush34: DAC AUTOCAL SUCCESS in 5341 milliseconds 
[   54.875289] h1iopsush34: DAC AUTOCAL SUCCESS in 5344 milliseconds 
[   60.668130] h1iopsush34: DAC AUTOCAL SUCCESS in 5345 milliseconds 
[   66.030689] h1iopsush34: DAC AUTOCAL SUCCESS in 5341 milliseconds 
[   71.823494] h1iopsush34: DAC AUTOCAL SUCCESS in 5344 milliseconds 
[   77.186841] h1iopsush34: DAC AUTOCAL SUCCESS in 5345 milliseconds 
# This restart:
[1121136.381304] h1iopsush34: DAC AUTOCAL SUCCESS in 5345 milliseconds 
[1121141.741653] h1iopsush34: DAC AUTOCAL SUCCESS in 5344 milliseconds 
[1121147.529535] h1iopsush34: DAC AUTOCAL SUCCESS in 5344 milliseconds 
[1121152.889081] h1iopsush34: DAC AUTOCAL SUCCESS in 5340 milliseconds 
[1121158.677788] h1iopsush34: DAC AUTOCAL SUCCESS in 5345 milliseconds 
[1121164.037291] h1iopsush34: DAC AUTOCAL SUCCESS in 5340 milliseconds


@ DetChar -- we are VERY interested to track how we these DAC calibrations behave over time, to find out how often we need to do these auto cal routines. Please make sure to look for glitches *every day* during ER7, and report back to us
- Did *this* autocal fix the problem you've seen that made you request it?
- If you still see the problem, did the autocal at least *reduce* the glitches?
- How quickly, if at all, do glitches come back? (a plot of glitch amplitude vs time over ER7)
- You'd mentioned you can't see it in DARM -- confirm that this is true for the entire run
- Because we've have so many of these DAC cards fail during the May 21 upgrade, we were forced to *not* upgrade the cards in the h1sush56 I/O chassis. This means that H1SUSSRM, H1SUSSR3 and H1SUSOMC *have not* had their DAC cards upgraded. Can you tell a difference? 
- I would expect H1SUSSRM and H1SUSSR3 to have great influence on DARM, given the know SRCL to DARM coupling. Is there evidence of this?
- We send control ASC control to both SR2 and SRM, and LSC control to SRM. SR2 has new 18 bit DACs and SRM does not. If you can see glitching in SRCL -- can you tell if it's more SRM / SR3 than SR2? 

Thanks ahead of time!

Greg, Dan, Jim, Dave:

Dan has the new LDAS SFP to install on the single mode link between MSR and LSB which was reporting errors. For now he has inserted the new SFPs in the QLogic switches but for now these ports are still disabled. We will enable them and remove the link between the MSR switches at the end of ER7.

To clear the accumulated processor load of 40 on h1guardian0, I rebooted this machine at 11:41PDT. All guardian nodes came back online with no problems. The load average is now back at its starting value of 7.

Jeff, Dave

We restarted the h1iopsush34 model, which performed a calibration on all six 18bit DAC cards (including MC2's M3 DAC which had reported zero crossing glitching Link). All autocals completed successfully. 

Andrew, could you verify if the recalibration has made any improvement in MC2 M3? The calibration could deteriorate over time.

model restarts logged for Mon 01/Jun/2015
2015_06_01 01:02 h1fw1*

model restarts logged for Sun 31/May/2015
2015_05_31 06:42 h1fw0*
2015_05_31 23:10 h1fw1*

* = unexpected restart

It has been 5 or more weeks since I noted the fluid levels in the reservoirs and there is no measurable change in levels.  This indicates there is obviously no leaks larger than a few nusaince drips, and, the Accumulators remain well charged.

If there is a level trip anytime soon, it means a substantial leak has developed or one or more accumulators has lost its gas charge.

NutsineeK, RickS

This morning, we went to Xend to capture images of the ETM with the illuminator on and the green ALS and red OptLev beams blocked.

The procedure for capturing the measurements is as follows:

[Ryan F, Duncan M, etc.]

I have committed a new version of the CAL_INJ_MASTER common library model used to control hardware injections in the front-end system. This change reimplements the logic for the ODC state vector, making the state reporting more robust, and implementing logging for the Stochastic injections. The change has no impact outside of the /INJ/ODC block excepting input connections to that block.

If this model could be pulled onto the production system at LHO, and the h1calcs front-end rebuilt and restarted, that would be spiffing. At LLO this change did not require a restart of daqd, which is nice.

Once that change is made, I can remotely modify the related MEDM screens and EPICS variables to ensure that hwinj reporting is configured correctly before data-taking restarts this afternoon.

Times in UTC

7:10 Locked LSC FF, intent bit set to undisturbed (probably ignore this since I was a bit hasty in setting the bit)

8:12 Lockloss

9:00 Locked LSC FF

9:10 Lockloss.

9:20 Round of initial alignment

10:53 Locked LSC FF

10:59 Intent bit set to undisturbed

11:33 Lockloss

11:45 Another round of alignment as the X arm alignment didn't look good

13:09 Locked LSC FF

13:27 Intent bit set to undisturbed

14:02 Lockloss

14:12 Bubba to LVEA taking measurements

14:36 Locked LSC FF

14:40 Bubba out

14:50 Lockloss.  Good luck Patrick!

14:37 Intent bit set to undisturbed

J. Kissel, E. Hall

See Evan's entry here: LHO aLOG 18770.

We still need to double check it, and I'm sure we've made a mistake or two, but we think we've installed as much as we can based on the results of the DARM Open Loop Gain transfer functions we have compared against a model (see LHO aLOG 18769) and of the actuation coefficient measurements (see LHO aLOG 18767)

For lack of better quantitative understanding of the DARM OLGTFs we have, we should still consider this calibration at an accuracy of 50% and 20 [deg]. (At least it's better than the factor of two promised :-/ ).

Note that we have NOT yet updated the inverse actuation function in the hardware injection path. Sorry -- but that'll have to wait until the morning.

We've still got plenty more to do and understand, but thanks to all who have helped over the past 1.5 weeks. You help has been invaluable, and much appreciated!!

P.S. IF NEED BE -- one can revert to the old CAL-CS calibration by switching back to ETMX, then reverting to the former sensing function via the filter archive.

J. Kissel, K. Izumi, E. Hall

We've put together a model of the new DARM loop after (a) all of our core CDS electronics been replaced (DAC, AI filters, AA filters, I/O chassis power supplies you name it), (b) a low-noise, low voltage driver on our ETMY, and (c) reshaping of the hierarchical control scheme to account for the new driver's lack of drive strength. 

The message -- we've still got some work to do to get back to the level of understanding we had of the frequency dependence before the above mentioned changes. As such, we have to inflate the frequency dependent uncertainty in the run back to 50% in magnitude and 20 [deg] in phase. Indeed, because the frequency dependence of residual between model and measurement is so large, it's difficult-at-best to make a statement about the optical gain (overall sensing function scaling factor), even though we have so accurately and precisely measured the actuation scale factors (LHO aLOG 18767).

For the time being, we'll use an optical gain of 1.31e6 [ct/m] in the sensing path, having scaled the model to match the OLGTF measurement at the UGF (for the first two measurements shown). Further, we'll stick with a DARM coupled cavity pole frequency of 355 [Hz], since it had been so for the few lock stretches we'd gotten before all the electronics hubbub.

--------
Details:
The model lives in 
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Scripts/DARMOLGTFs/H1DARMOLGTFmodel_ER7.m, 
the parameters with which to match the three measurements are in the functions
H1DARMparams_1116854228.m (for 2015-05-28 measurement)
H1DARMparams_1116990382.m (for 2015-05-30 measurement)
H1DARMparams_1117124229.m (for 2015-05-31 measurement)

Since the first 2015-05-28 measurement is with the low noise ESD driver's low pass engaged, and the last 2015-05-31 measurement had a poorly scaled control system (see discussion below), we should use the parameter set and model from the second 2015-05-30 measurement.

TIME DOMAIN CALIBRATORS -- THIS PART'S FOR YOU
The model(s) have been seen saved to the following .mat file:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Results/DARMOLGTFs/2015-06-01_LVLNDriver_DARMOLGTF.mat
(apologies, it still composed of frequency response vectors, I didn't have time to convert everything to LTI objects).
The total actuation function is model(2).par.A.total with a delay of model(2).par.t.actuation microseconds.
The total sensing function is model(2).par.C.total with a delay of par.t.sensing + par.t.armDelay microseconds.
The stuff that's included in this model already that we don't plan on putting in the CAL-CS model that should be included in the GDS pipeline:
Actuation: 
     The digital and analog anti imaging filters -- model(2).par.A.antiimaging.total 
     The super-Nyquist-frequency pole of the new driver -- model(2).par.A.esdDriver.fc (at 2.42e4 [Hz]) << this one's tricky to include given the new hierarchy, just leave it out if you don't get how to do so.
Sensing
     The digital and analog anti aliasing filter -- model(2).par.C.antialiasing.total
     The super-Nyquist-frequency poles of the OMC whitening -- model(2).par.C.uncompensatedomcdcpd.c (at 13.7e3 and 17.8e3 [Hz])
END TIME DOMAIN PART

What we've learn about / explored so far trying to clean up the model:
- We need to invert the sign of the L3 / ESD stage in order to get the phase to even closely match the measurement. We have a couple of theories on this, and our "best" is that the charge is so large on ETMY that it's effectively flipping the sign of the ESD actuator. We saw hints of this during our ALS DIFF and FS MICH actuation coefficient measurements, but didn't need to pay attention to them at the time. Now (not that we weren't before, but), we should perform the same sign checks that Shivaraj and co performed at LLO (see LHO aLOG 18406).
- We've been have problems for the past month or so with our optical gain fluctuating, and I think we've narrowed it down to poor compensation / scaling of the OMC during the hand off to DCPDs. We thing we've addressed this now here: LHO aLOG 18768, but the last open loop gain transfer function (I took it -- LHO aLOG 18733) in which I had incorrectly scaled the DARM loop gain to compensate for the poor scale factor should probably, eventually, be thrown out. I kept it in this data set, simply because we've had so few, and one needs at least three to make a pattern.
- Recall the first measurement was taken with the new ESD driver's low pass filter engaged, and I release while writing this aLOG that I didn't properly include that in the model. However, I've received a spice model of the driver with and without the low pass engaged, so I've fit the poles and zeros to be
par.A.esdDriver.poles_Hz = [159.1 2.42e4]; % [Hz] 
par.A.esdDriver.zeros_Hz = 3189.4; 
see /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Scripts/Spice/model_LVLN_driver_20150601.m
- We did NOT have time enough to include all of the recent measurements of the analog AA and AI filters, but we're currently using the mean of the some 200 measured filters as before, and we don't expect this to have too much of an influence in the gravitational wave band. Certainly not the source of the bonkers frequency repsonse residual we have at the moment.
- We need to include the above poles and zeros properly into the ESDOUTF bank, and change the ESD driver's state machine so that it can handle all of the different configurations of the driver. After ER7.
- Now that we're using a sort of hybrid offloaded AND distributed control scheme for the three actuation stages of ETMY, we needed to rethink the loop math, specifically how each stage should be added together. In short, it changes from a simple
A_TOTAL = LOCK_L1 * SUS_L1toL3 + LOCK_L3 * SUS_L3toL3;
to a nasty
A_TOTAL =   LOCK_L1 * LOCK_L2 * LOCK_L3 * DRIVEALIGN_L1_L2L * SUS_L1toL3 
          + LOCK_L2 * LOCK_L3 * DRIVEALIGN_L2_L2L * SUS_L2toL3 
          + LOCK_L3 * DRIVEALIGN_L3_L2L * SUS_L3toL3

(plus the sign flip in front of the last term mentioned above).
- We've double checked and triple digital filters and gains, which are being read in from the foton file archive, so we're 80% confident (as confident as one can be at 3am) that we're not stupidly loading in bad filters or anything. 

That's all I've got steam for at the moment. I'll see y'all in the morning.

Dan, Jeff B, Evan

Some guardian tweaks to be aware of:

• Some settings in the OMC guardian were changed so that the AS45Q → OMC DC scaling factor calculation is more robust. The averaging time for the data is slightly longer, and the scaling is taken to be the median rather than the mean. Over the course of five lock acquisitions today, we measured the DARM OLTF both before and after transitioning to dc readout, and we did not see any degredation of the loop gain.
• On several occasions, the roll mode damping gains in the guardian were too large and caused lockloss. Therefore, they are now reduced by a factor of 5. The full gains are set in the DC_READOUT state.

J. Kissel, K. Izumi, S. Karki

I've culminated the results of the three different measurement techniques for determining the actuation strength of all three stages of ETMY, 
- Laser Wavelength: Free-swinging Michelson LHO aLOGs 18718
- Voltage Controlled Oscillator: ALS DIFF VCO LHo aLOG 18711
- Photon Radiation Pressure: Photon Calibrator LHO aLOG 18758 (Only for ETMY L3)
The numbers quoted below are what will be used in DARM model we'll use during ER7, which we'll then use to update the GDS pipeline and CAL-CS models.

    'Optic'      'Weighted Mean'    '1-sigma Uncertainty'    '1-sigma Uncertainty'
    'Stage'      '[m/ct]'           '[m/ct]'                 '%'                  
    'ETMY L1'    '5.12e-11'         '8.6e-13'                '1.7'                
    'ETMY L2'    '6.97e-13'         '1.2e-14'                '1.8'                
    'ETMY L3'    '6.07e-15'         '1.4e-16'                '2.4'                
    'ETMX L3'    '3.56e-13'         '8.2e-15'                '2.3'

See attached for a graphical representation of how the individual results compare against the weighted mean and uncertainty (Wikipedia).

Recall that all of these numbers' uncertainty arises from either the statistical uncertainty of the individual measurements which compose the result (i.e. the coherence of the transfer function), or a compression of each frequency point in a TF into one number via weighted means and uncertainties. In no way have we accounted for systematic uncertainty other than comparing using the three different methods (for ETMY L3 at least). Very encouraging that they agree to within 2.5%!

We have enough data to propagate PCal's number for L1 and L2 of ETMY, but we've just run out of time. However, we've found that with the other two methods (Free-swinging MICH, and ALS DIFF) that the L1 and L2 stages agree with the dead-reckoned model to within 4%, and we don't at all expect these actuators to be varying with time like we do the ESD stages.

Note that the ratio between EX and EY's ESDs confirms the factor of ~50 that was needed when scaling EX to EY during the initial attempts to relock the IFO with the low noise driver.

Further, it's encouraging to see that three measurement techniques each of which take several hours (save PCAL) taken over the course of a few days. I'm still not convinced that the actuation strength didn't actual increase between the FS MICH and ALS DIFF measurements (since they're all systematically higher), but we just need more data to confirm. However, now that we trust that PCAL agrees with ALS DIFF and FS MICH, we can focus our energy on PCAL. Surdarshan's working on grabbing past lock stretches from the frames and assessing how this coefficient has varied over time.

Observation Bit: Commissioning 

16:20 Take IFO to LCS_FF 
16:27 Lockloss – 
16:45 RO system down – Reset system
18:23 IFO locked at DC_Readout_Transition – Dan taking measurements
18:25 IFO locked at DC_Readout – Evan taking measurements
18:28 Increase ISS Diffracted power from @ 3% to 8%
18:33 IFO locked at LSC_FF 
18:35 Set Observation bit to Undisturbed
18:46 Set Observation bit to Commissioning – Dan working on OMC
18:49 Lockloss – Guardian recovering
19:22 Lockloss at DC_Readout – Guarding recovering
19:48 Lockloss at DC_Readout_Transition – Guardian recovering 
	     Evan & Dan working on Bounce, Roll, and Violin damping	
20:40 IFO locked at LCS_FF
20:53 Lockloss – Guardian recovering
22:00 Run initial alignment
23:00 Running Guardian locking

Sudarshan, Duncan, Branson, Andrew, Michael T, Greg, Dave:

I got a lot further in installing the GRB alert system at LHO. It now runs, but fails after a couple of minutes. Here is a summary of the install:

LHO and LLO sysadmins decided to run the GRB code on the  front end script machine (Ubuntu12). At LHO it is called h1fescript0

I requested a Robot GRID Cert for this machine, Branson very quickly issued the cert for GraceDB queries last Friday

Following Duncan's and the GraceDB install instructions, I was able to install the python-ligo-gracedb module. The initial install failed, Michael resolved this, I was using the Debian Squeezy repository (which uses python2.6) rather than Wheezy which uses python2.7.

Greg told us how to install the GRID cert on the machine and setup the environment variable so the program could find it.

I found a bug in the code for the lookback, it appears the start,stop times were reversed in the arguments to client.events().

For testing, I saw that a GRB event had happened within the past 10 hours, so I ran the program with a 10 hour lookback. It found the event and posted it to EPICS (see attachement)

But afer running for several minutes, it stopped running with an error. This is reproducible.

controls@h1fescript0:scripts 0$ python ext_alert.py run -l 36000
Traceback (most recent call last):
  File "ext_alert.py", line 396, in
    events = list(client.events('External %d.. %d' % (start, now)))
  File "/usr/lib/python2.7/dist-packages/ligo/gracedb/rest.py", line 450, in events
    response = self.get(uri).json()
  File "/usr/lib/python2.7/dist-packages/ligo/gracedb/rest.py", line 212, in get
    return self.request("GET", url, headers=headers)
  File "/usr/lib/python2.7/dist-packages/ligo/gracedb/rest.py", line 325, in request
    return GsiRest.request(self, method, *args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/ligo/gracedb/rest.py", line 200, in request
    conn.request(method, url, body, headers or {})
  File "/usr/lib/python2.7/httplib.py", line 958, in request
    self._send_request(method, url, body, headers)
  File "/usr/lib/python2.7/httplib.py", line 992, in _send_request
    self.endheaders(body)
  File "/usr/lib/python2.7/httplib.py", line 954, in endheaders
    self._send_output(message_body)
  File "/usr/lib/python2.7/httplib.py", line 814, in _send_output
    self.send(msg)
  File "/usr/lib/python2.7/httplib.py", line 776, in send
    self.connect()
  File "/usr/lib/python2.7/httplib.py", line 1157, in connect
    self.timeout, self.source_address)
  File "/usr/lib/python2.7/socket.py", line 571, in create_connection
    raise err
socket.error: [Errno 110] Connection timed out