Apologizes for the late entry.

Yesterday all site supply fans were lubricated per the quarterly schedule.

We also took the maintenance period opportunity to change some extremely dirty air filters which are located in the supply fan areas.

TITLE: 11/03 Owl: 8:00-16:00 UTC 
STATE Of H1: Observing @ ~75 MPc.
SHIFT SUMMARY: 
SUPPORT:
ACTIVITY LOG:

H1 was locked when I arrived, RF45 was acting up occasionally, though. Otherwise quiet shift.

15:00 UTC Started receiving CS temp notifications, Bubba notified/working on it.

This morning about 15:00 UTC, I got a couple notifications that temps were low in the LVEA. I let Bubba know, but he was already working on it. I haven't heard any notifications since, Bubba said he will keep an eye on it.

TITLE: 11/03 [EVE Shift]: 00:00-08:00 UTC (16:00-00:00 PDT), all times posted in UTC
STATE Of H1: Observing @ ~75 MPc.
SHIFT SUMMARY: Initial lock impeded by bounce and roll modes. Lost lock during earthquake in East Timor. Seismic stayed abnormally high for almost 2 hours. Recovered and back to observing.
SUPPORT: Evan, Jenne
INCOMING OPERATOR: Jim

ACTIVITY LOG:

00:13 UTC Kyle and Gerardo back from X28 (near end X)
01:25 UTC Towing truck through gate
04:36 UTC Nutsinee leaving, driving up bridge before heading out
04:40 UTC Jenne driving to end stations to turn card readers on
04:49 UTC Turned power off to speaker in control room
05:06 UTC Jenne back
05:45 UTC Restarted video2, Ops overview frozen

Seismic took about 2 hours to ring down to the point that we could relock. The 0.03 - 0.1 Hz seismic band is between ~ .02 and .1 um/s. The microseism is between ~ .1 and .2 um/s. The winds are around 10 mph.

Violin mode damping for ITMX and ITMY is off.

ISI blends are at Quite_90.

Jenne turned the card readers on at end X, end Y and the LVEA.

Range is around 78 MPc.

[Jenne, Miquel, Patrick]

The card readers providing access to the VEAs were turned off during maintenence today.  Since we're unlocked due to an earthquake anyway, they have now been turned back on (EX, EY and vertex).

SUS I_T_M_Y saturating (Nov 4 04:14:41 UTC)
DRMI Unlocked (Nov 4 04:14:41 UTC)
Intention Bit: Commissioning (Nov 4 04:14:41 UTC)
ISC_LOCK state: DOWN (Nov 4 04:14:48 UTC)

From USGS:
6.3 77km WNW of Dili, East Timor 2015-11-04 03:44:15 UTC 14.3 km deep

Spike to ~ .3 um/s in 0.03 - 0.1 Hz seismic band

Have remained in observing. No changes to report.

I have turned off the violin mode damping filters for IX and IY by zeroing their gains. Patrick accepted these into SDF so that we can go to observing.

This is meant to be temporary, i.e., for this one lock only.

The next time the interferometer comes into lock, the Guardian will turn on the normal violin mode damping settings. These settings will appear as SDF diffs (two on IX, and six on IY). These should be accepted into SDF.

We do not expect these modes to ring up during the course of the lock. However, if the mode height on the control room DARM spectrum around 500 Hz rises above 10⁻¹⁶ m/rtHz, the damping should be turned back on:

1. Make sure the ramp times for the damping filter modules are at least a few seconds (currently they seem to be set to 10 s).
2. The filters should already be configured to provide the right damping phase, so changing the filters should not be necessary.
3. Start typing in gain settings. Refer to the values listed below. If the violin mode amplitude is much much higher than usual (e.g., it's off the scale on the control room DARM spectrum), it is wise to start with a small gain (e.g, gain of ±1) in order to make sure the suspension drive does not saturate. Then you can increase the gain in several steps, until the nominal setting is achieved.

A screenshot of the nominal IY damping settings is attached (I didn't take one for IX).

ITMX:

• MODE3 gain: −100
• MODE6 gain: +200
• all others zero

ITMY

• MODE1 gain: −200
• MODE2 gain: −200
• MODE3 gain: +100
• MODE4 gain: −50
• MODE5 gain: +400
• MODE6 gain: +50
• all others zero

There was some suspicion that the whitening gain for some of the ACB PDs became bad, but I have confirmed on the floor that the gain setting on the MEDM screen is reflected correctly in the diode amplifier box (D1301017) over the entire gain range for all baffle PDs for IX, IY, EX and EY.

I've followed the test procedure E1400003.

Violin mode damping for ITMX and ITMY is off. The damping gains of 0 were accepted in SDF (see attached screenshots). Evan wants to see how long they take to ring down without damping.

ISI blends are at Quite_90.

During today's maintenance period I surveyed the switch configuration of the Output Configuration Switch (OCS) for each SUS oplev (WP #5588).  The OCS is the small board with 4 banks of 8 switches each that attaches to the front of each oplev whitening chassis; it allows us to control the amount of whitening gain and filtering we apply to the oplev QPD signal.  The results of this survey have been gathered and posted to the DCC here: T1500556.  This document needs to be updated anytime the switch configuration of these OCSs changes; if anyone makes any changes to an OCS please let me know, via email or alog (preferably both), what you did so I can keep us up to date with the current OCS configuration.

TITLE: 11/03 [EVE Shift]: 00:00-08:00 UTC (16:00-00:00 PDT), all times posted in UTC
STATE Of H1: Lock acquisition
OUTGOING OPERATOR: Jeff
QUICK SUMMARY:
Lights appear off in the LVEA, PSL enclosure, end X, end Y and mid X. I can not tell from the camera if they are off at mid Y.
Winds are less than 10 mph. Appear to be increasing.
ISI blends are at Quite_90.
Earthquake seismic band is between 0.01 and 0.02 um/s. Microseism is between 0.1 and 0.3 um/s.

Jeff has been having trouble with ITMY bounce and roll modes. Has been stopping at REDUCE_CARM_OFFSET_MORE to allow Jenne and Evan to investigate.

following Keith's LLO install, I have configured monit on h1fescript0 to automatically start the GraceDB notification system on system reboot,and to restart it if it stops running. Here are the details:

created a new exttrig account local to h1fescript0. Currently this has the standard controls password.

In the exttrig home directory, install script run_ext_alert.sh

Install a start/stop script in /etc/init.d/ext_alert

Install monit and mailx on the machine

Configure monit via /etc/monit/monitrc and /etc/monit/conf.d/monit_ext_alert

I changed the ownership of the cert files from user controls to user exttrig

Tested by killing the ext_alert process and checking monit restarted it

I have removed the obsolete startup instructions in the [[ExternalAlertNotification]] wiki page

This closes FRS3415.

I have spent about an hour today checking some basic behavior of the ISS 2nd loop servo circuits. I did the following two measurements.

1. Offset measurement
2. Measurement of operating point as a function of the input power

No crazy thing was found in today's test. Our plan is that whenever we have issues with the ISS 2nd loop in some future, we will repeat the same type of measurements with an aim to identify what is changing.

Offset measurement

I checked how the reference signal propagates to the servo signal output by changing the reference signal. The measurement was done with the IMC intentionally unlocked. Therefore there was no light incident on the ISS PD array in HAM2. The result is shown in the first attachment. An important quantity to note here is the signal output value when zero reference voltage was requested. It was 2.76 V. Also note that zero output signal can be obtained when the reference signal is requested to be between 5 and 10 mV. This does not sound crazy to me. According to the resultant plot, the linearity seems also fine. Additionally I checked the reference monitor as well which also showed a good linearity. Later, I did a coarse version of the same test with the full power incident on IMC (~22 W). Even though the actual RIN was too high to make a precise measurement, the linear coefficient between the reference and output signals seemed consistent with what I have measurement with no light. I also attach the raw data in txt format.

Operating point measurement

Then I locked the IMC and changed the input power step by step with a step size of about 2 [W]. In each step, I manually moved the reference signal such that the output signal stays around zero [V]. This tells us how the operating point evolves as a function of the input power. I did this test from 2 [W] to 22 [W]. The result is shown in the second attachment. As you can see in the plot, the operating point evolves linearly against the input power as expected. Additionally, I recorded IM4_TRANS_SUM as well in order to check the linearity of the output power of the IMC. IM4_TRANS seems to be also linear. The data in txt format is attached as well.

Note that all the tests were done with PD1-4 as an intensity sensor. PD5-8 was not checked during the tests.

Per JimW's request (alog 23032), I edited the ISC_LOCK guardian such that it throws notification messages when the ISS 2nd loop fails in the engagement. I have reloaded ISC_LOCK and checked the code into the SVN.

The notification messages will be displayed (1) if the IMC_LOCK guardian falls back to the LOCKED state (which is the programmed failure sequence) and/or (2) if the engagement process takes more than 4 minutes. The below are the new version of the ENGAGE_ISS_2ND_LOOP state. The red lines are the ones I newly added.

* * * * * * in ENGAGE_ISS_2ND_LOOP * * * * * *

    def main(self):
        nodes['IMC_LOCK'] = 'ISS_ON'
        self.wait_iss_minutes = 4.0 # in [min]
        self.timer['ISSwait'] = self.wait_iss_minutes*60 # in [sec]

    @get_watchdog_IMC_check_decorator(nodes)
    @nodes.checker()
    def run(self):
        # notify when the ISS fails. 2015-Nov-3, KI
        if nodes['IMC_LOCK'] == 'LOCKED' or nodes['IMC_LOCK'] == 'OPEN_ISS':
            notify('!! 2nd loop engagement failed !!')    
        # notify when the ISS is taking too many minutes. 2015-Nov-3, KI
        if self.timer['ISSwait']:
            notify('ISS spent more than %d minutes. Check ISS'%(self.wait_iss_minutes))
        # if IMC arrives at the requested state, move on.
        return nodes['IMC_LOCK'].arrived

The DTT template for showing the MICH spectrum on the control room wall is suffering from leakage,  preventing us from seeing some features in the 8 to 11 Hz range. The current parameters and window are:

Window: Hanning

Start/end frequencies: 0/74444Hz 

BW: 0.1Hz 

Overlap: 70% 

Avarages: 3

Resulting BW: 0.18Hz

After playing with the available windows (but keeping all other parameters fixed so it will refresh with the same latency), I have found that Flat-Top reduces the resulting BW to 0.24Hz but also reduces the leakage problem. This would allow us to see features over the problematic range. The first two attached figures correspond to 2015-10-28 14:48:24 ; they show how the Hanning window suffers from a real leakage problem while Flat-top maintains it’s performance. The feature over 8Hz corresponds to a problem solved by Bubba on log (22939). 

We have a few piece of evidence that suggest that anthropegenic noise (probably trucks going to ERDF) couples to DARM through scattered light which is most likely hitting something that is attached to the ground in the corner station.

1. Our spectrum is more non-stationary between 100-200 Hz durring times of high anthropegenic noise. Nairwita noted this by looking through summary pages (these glitches only seem to appear on weekdays between 7 am and 4pm local (14-23UTC), and not on Hanford Fridays when anthropegenic noise is low), and Jordan confirmed this by making a few comparisons of high/low anthropegenic noise within lock stretches.  (alog 22594)
2. Corner station ground sensors are a good witness of these glitches.  HVETO shows this clearly (see page for October 14th for example).  Also, comparison of bandpassed DARM to several corner ground motion sensors and accelerometers show that glitches in DARM coincide with ground motion (for example see nutsinee's alog 22527)
3. The DARM spectragram at the time of these glitches show what looks like scattering arches from 1 Hz motion and a velocity of around 40 um second total path length change. alog 22523  Both this high velocity and the fact that the seismometers on the tables don't seem to witness this motion well suggest that something bolted to the ground is involved in the scattering. This velocity is probably too high for something bolted to the ground.
4. The scattering amplitude ratio (ration of scattered amplitude to DC readout light on DCPDs) we would estimate bassed on the fringes in DARM 1e-5, similar to what we got in April  Using the ISCT6 accelerometer to predict the velocity of the motion doesn't quite work out.
5. Annamaria and Roert did some PEM injections in the east bay, which showed a linear coupling to DARM.  Annamaria is still working on the data and trying to disentangle downconverion from the linear coupling, but if we assume that scattered light is responsible for the linear coupling the amplitude ratio is fairly consistent with what we got from the fringe wrapping when trucks go by.

On monday, Evan and I went to ISCT6 and listened to DARM and watched a spectrum while tapping and knocking on various things.  We couldn't get a response in DARM by tapping around ISCT6.  We tried knocking fairly hard on the table, the enclosure, tapping aggresively on all the periscope top mirrors, and several mounts on the table and nothing showed up.  We did see something in DARM at around 100 Hz when I tapped loudly on the light pipe, but this seemed like an excitation that is much louder than anything that would normaly happen.  Lastly we tried knocking on the chamber walls on the side of HAM6 near ISCT6, and this did make some low frequency noise in DARM.  Evan has the times of our tapping.

It might be worth revisiting the fringe wrapping measurements we made in April by driving the ISI, the OMC sus, and the OMs.  It may also be worth looking at some of the things done at LLO to look accoustic coupling through the HAM5 bellow (19450 and 

19846)

Summary:

We had single-IFO time so I tested the new inverse actuation filter for PCALX. WP5530

Sudarshan and I believe we tracked down the factor of 2 and sign error from the initial PCALX test, see aLog 22160. We wanted to do this test to confirm that.

CBC injections:

The waveform file is: https://daqsvn.ligo-la.caltech.edu/svn/injection/hwinj/Details/Inspiral/H1/coherenttest1from15hz_1126257408.out

The XML parameter file is: https://daqsvn.ligo-la.caltech.edu/svn/injection/hwinj/Details/Inspiral/h1l1coherenttest1from15hz_1126257408.xml.gz

I did three CBC injections. The start times of the injections were: 1128303091.000000000, 1128303224.000000000, and 1128303391.000000000.

The command line to do the injections is:
ezcawrite H1:CAL-INJ_TINJ_TYPE 1
awgstream H1:CAL-PCALX_SWEPT_SINE_EXC 16384 coherenttest1from15hz_1126257408.out 1.0 -d -d >> 20151006_log_pcal.out
awgstream H1:CAL-PCALX_SWEPT_SINE_EXC 16384 coherenttest1from15hz_1126257408.out 1.0 -d -d >> 20151006_log_pcal.out
awgstream H1:CAL-PCALX_SWEPT_SINE_EXC 16384 coherenttest1from15hz_1126257408.out 1.0 -d -d >> 20151006_log_pcal.out

I have attached the log. I had to change the file extension to be posted to the aLog.

DetChar injection:

I injected Jordan's waveform file: https://daqsvn.ligo-la.caltech.edu/svn/injection/hwinj/Details/detchar/detchar_03Oct2015_PCAL.txt

The start time of the injection is: 1128303531.000000000

The command line to do the injections is:
awgstream H1:CAL-PCALX_SWEPT_SINE_EXC 16384 detchar_03Oct2015_PCAL.txt 1.0 -d -d >> 20151006_log_pcal_detchar.out

I have attached the log. I had to change the file extension to be posted to the aLog.