809 - Richard to both ends

809 - Jeff B to LVEA then to ends setting up dust mons

811 - Christina fork lifting to OSB receiving and opening door

814 - Rick to manifolds on both arms

820 - Kyle to EY

823 - Jodi to LVEA to put signs up, then to MY

826 - Christina/Karen to EY to clean

827 - Beam tube cleaning start

832 - Robert to EY to move coils

832 - Patrick to restart EX Beckhoff

835 - Jodi and Rick out of LVEA

838 - Andres to LVEA to move parts around

845 EX Beckhoff back up

853 - Fil/Peter K to LVEA

900 - Kingsoft on site for RO work

905 - Praxair truck on site

907 - Fil/Peter out of LVEA

909 - Jodi leaving MY

917 - Andres out

921 - Gerardo to LVEA for wrenches

923 - Mitch to ends for serial number hunt

927 - Karen/Christina leaving EY for EX

928 - Gerardo out and to EY

947 - Robert out of LVEA

1000 - Praxair truck #2 on site

1006 - Daniel to EY to look at TCS setup

1010 - Richard back fomr Ends

1020 - Robert to LVEA

1020 - Karen/ Christina leaving EX

1020 - Fil to EY

1027 - Ed to CER

1036 - Ed out

1040 - RIchard to EY

1049 - Rick LVEA fit check

1052 - Daniel back, for a moment

1057 - Richard to LVEA looking at Cosmic Ray Detector

1105 - Christina/Karen to LVEA

1107 - Patrick restarting PEMEY

1128 - Mitch back

1128 - Daniel back

1133 - Jeff B back

The ring heater for ETMY was disconnected from the chassis. The power of the chassis was already off, since we were not using it. A special cable which shorts all ring heater segments together was connected to the output of an SR560. The SR560 ground was connected to the ESD driver ground, while its input is driven by the PEM DAC (H1:PEM-EY_GDS_1_EXC). A drive of 12000 counts corresponds to about 1.8Vpp.

Got disconnected as part of dust monitor work at end Y. Burtrestored.

J. Kissel

In the H1:CAL-INJ_HARDWARE and H1:CAL-INJ_BLIND filter banks, I've turned ON the updated inverse actuation filter for ER7 (which lives in FM2 of both banks), turned OFF the mini-run filter (which *still* lives in FM1) and accepted the changes in the SDF system. See LHO aLOG 18997 for design details of the new filter.

J. Kissel

Over the weekend, Evan, Stefan and Kiwamu has explored running the IFO at 24 [W] request PSL input power (see e.g. LHO aLOG 18923) instead of 17 [W] for which the interferometer had been calibrated (see LHO aLOGs 18769 and 18813). Because we do not yet have automatic optical gain scaling built into the IFO's control system, the calibration will be incorrect for the following science segments:
Seg Num GPS Start       GPS End         Duration [s] UTC Start             UTC End
1	1117601338	1117665437	64099        Jun 06 2015 04:48:42  Jun 06 2015 22:37:01
2	1117667359	1117702258	34899        Jun 06 2015 23:09:03  Jun 07 2015 08:50:42
3       1117709888	1117743019	33131        Jun 07 2015 10:57:52  Jun 07 2015 20:10:03
4	1117748054	1117773188	15134        Jun 07 2015 21:33:58  Jun 08 2015 04:32:52
5	1117803358	1117814235	10877        Jun 08 2015 12:55:42  Jun 08 2015 15:56:59
6	1117814313	1117815464	1151         Jun 08 2015 15:58:17  Jun 08 2015 16:17:28
7	1117829201	1117833161	3960         Jun 08 2015 20:06:25  Jun 08 2015 21:12:25
---
                        Total Time      Uptime@23[W] Single IFO Duty Factor During These Segments
                        64.40 hr        45.27 hr     70.3% 

Offline optical gain calculations are being made by the GDS calibration pipeline, but they are not being applied directly since this is the first time they've been calculated. However, evidence still suggests that LHO's DARM coupled cavity pole frequency (i.e. the single-pole approximation to the interferometer's response to gravitational waves / displacement noise) is still a moving target, so the calibration error (not uncertainty, but actual error) may not only just be a scale factor, but a frequency-dependent error. We should* have enough information from PCAL and DARM calibration lines to make an estimate of how the frequency dependence is changing over time.

*"should" is still "in principle;" we have not yet finished the commissioning of processing PCAL / DARM calibration lines to a point where we can determine at what precision the 6 lines will be able to determine the optical transfer function. This work is on-going.

Biweekly crash recovery. Burtrestored to 06/08/2015 00:10.

Out of Science mode.

I flipped the intent bit because with Tuesday maintenance comes lots of noise.

Peter Shawhan, Andy Lundgren, Nutsinee Kijbunchoo

We did a first -- and successful! -- test of the "detchar" or "safety" hardware injections shortly after 6:00 PDT this morning, at the time recommended by Jeff (work permit 5262).

The detchar injections are a sequence of loud sine-gaussians at a range of frequencies, primarily intended to check for couplings from the GW strain channel to auxiliary channels.  (See https://dcc.ligo.org/LIGO-G1500713 .)  For now, at least, we are using a set of 14 frequencies logarithmically spaced from 30 Hz to 2000 Hz, each injected at 3 different amplitudes to try to get target SNR values, spaced 5 seconds apart.  Here is the full list with times relative to the start time of the injection:
Matlab> GenerateSGSequence('H1','H1_ASD_at_1117710916.txt');
__time__   __freq__   __SNR__    __AMP__
    0.50       30.0      25.0    2.22e-20
    5.50       41.4      25.0    7.54e-21
   10.50       57.2      25.0    2.86e-21
   15.50       79.1      25.0    1.72e-21
   20.50      109.2      25.0    1.52e-21
   25.50      150.9      25.0     1.7e-21
   30.50      208.4      25.0    1.97e-21
   35.50      287.9      25.0    2.92e-21
   40.50      397.7      25.0    3.73e-21
   45.50      549.3      25.0    5.42e-21
   50.50      758.8      25.0    6.95e-21
   55.50     1048.2      25.0     1.1e-20
   60.50     1447.9      25.0    1.71e-20
   65.50     2000.0      25.0    2.68e-20
   70.50       30.0      50.0    4.44e-20
   75.50       41.4      50.0    1.51e-20
   80.50       57.2      50.0    5.71e-21
   85.50       79.1      50.0    3.44e-21
   90.50      109.2      50.0    3.03e-21
   95.50      150.9      50.0    3.41e-21
  100.50      208.4      50.0    3.94e-21
  105.50      287.9      50.0    5.85e-21
  110.50      397.7      50.0    7.47e-21
  115.50      549.3      50.0    1.08e-20
  120.50      758.8      50.0    1.39e-20
  125.50     1048.2      50.0     2.2e-20
  130.50     1447.9      50.0    3.41e-20
  135.50     2000.0      30.0    3.22e-20
  140.50       30.0     100.0    8.88e-20
  145.50       41.4     100.0    3.02e-20
  150.50       57.2     100.0    1.14e-20
  155.50       79.1     100.0    6.87e-21
  160.50      109.2     100.0    6.06e-21
  165.50      150.9     100.0    6.81e-21
  170.50      208.4     100.0    7.87e-21
  175.50      287.9     100.0    1.17e-20
  180.50      397.7     100.0    1.49e-20
  185.50      549.3     100.0    2.17e-20
  190.50      758.8     100.0    2.78e-20
  195.50     1048.2     100.0    4.41e-20
  200.50     1447.9      75.0    5.12e-20
  205.50     2000.0      30.0    3.22e-20
The file, on h1hwinj, is /data/scirun/O1/HardwareInjection/Details/config/Burst/Waveform/detchar_1117890580_3_H1.txt .

With H1 running in good low-noise mode, Nutsinee switched the intent bit to 'commissioning' and we first injected the sequence starting at 1117890580 with an overall scale factor of 0.25 -- so the target SNRs/amplitudes are a factor of 4 smaller than in the table above.  Nutsinee didn't see anything obvious appearing in the live spectrum initially, but Andy looked at Omicron output afterward and say that it had picked up at least some of the louder signals.

We then injected the sequence again starting at 1117891250, this time with an overall scale factor of 1.0 .  Nutsinee saw the signals clearly peak up in the live spectrogram, and Andy's quick check with Omicron showed many signals found with large SNR.  The interferometer appeared to handle the injections fine, staying in lock.  Afterward (and also in between the two injections), Nutsinee set the intent bit back to 'science'.

Note: In the future, we expect detchar safety injections such as these to be marked with the DetChar bit in the CAL-INJ_ODC bitmask, but for the test today we treated it as a burst injection -- it will be marked in ODC (and GDS-CALIB_STATE) as a burst injection, and should produce ODC-INJECTION_BURST segments in the DQ segment database.

Jim told me that Guardian kept losing lock at BOUNCE_VIOLIN_MODE_DAMPING. After the lock loss I let Guardian took care of the locking up until this state and it lost lock as expected. I've just finish the initial alignment and will be doing the Bounce violin mode damping by hand. LOWNOISE_ESD_ETMY also known to have problems today so I will be doing the same thing when I get there. I have never run the code by hand so success not guaranteed. I'll do the best I can to get the ifo up for the 6AM hardware injection. Detcharians please stay tuned.

Mostly quiet shift

16:00 Took over initial alignement from Cheryl, trying to lock

18:30 Finally locked

19:00 Robert to  EY to bang on beam tube, lots of glitching -> particulate?

20:00 Evan breaks lock with a small change to Guardian

22:00 Lock reacquired, LLO is up too.

23:26 HFD is on site, out the gate at 23:55

HFD reports a power outage (? I could barely hear him... gate phone,ftl) and they need to check some boxes. He's currently driving down the X-arm very slowly, so I've flipped the intent bit. Will revert when I see he's off site.

The ISC_LOCK guardian now has a state HIGH_RANGE_ESD_ETMX, which is intended to be used to transition control of DARM from ETMY back to ETMX.

However, in the interest of maximizing the amount of coincident locking time with L1, this state has not yet been tested.

Starting right around 21:00 local, the 25.4 hz (well, DTT says something like 25.37) peak showed back up, creating a nasty looking comb in the DARM spectra (first image). Unsure of what else to do, I turned the power down to 16 watts, the peak has now kind of subsided(second image). I'll wait to see if the peak settles down any more, then maybe turn the power back up. 

Stefan, Kiwamu,

In this morning, DARM had many numbers of glitches which were visible in the DARM spectrum as wide band noise. We looked at various channels to see what caused the glitches, but we were not able to identify them.

We would like to get some help from the detchar people. Could you guys please look for a cause of the DARM glitches ?

The lock stretch which had a high glitch rate is the one starting at 2015-06-05 17:17 -sh to 18:00 -ish UTC. I attach an example time series of the glitches shown in OMC-DCPD A and B. We know that some of the loud ones were so large that they saturated the ADCs of the OMC DCPD.

Note that in the same lock stretch, we changed the DARM offset multiple times which changed the amount of the carrier light resonating in OMC. We do not think our activity with the DARM offset caused the high glitch rate.