12:35 H1 Lockloss (nothing obvious:  seismic quiet, and all the H1 strip tools showed nothing obvious before lockloss)

During Lock Acquisition, during 2nd locking attempt, had issues with ALS XARM:

• ALS_XARM Node, there was a Guardian FAULT:  PLL, PDH
  • Symptoms:  Xarm was flashing through all kinds of modes, & guardian was in FAULT state
  • On the PLL medm, the fiber lock temperature controls error signal was in the "Beat Note Error" state (vs "PZT Frequency").  Had no idea how to fix/clear fault, but after a while it appeared to clear up on its own & go to PZT Frequency.
• Waited for DRMI acquisition about 12-15min and then went through Sheila's PRMI procedure:

1) You can either misalign SRM using the SUS_SRM guardian, or use a new state in ALIGN_IFO called SET_SUS_FOR_PRMI_W_ALS. 

2) Request OFFLOAD_PRMI from the DRMI guardian.

• Was in the PRMI_LOCK_WAIT state for a long time (order of 15min?).  How long should we wait for PRMI to lock??

3) Once PRMI locks adjust PRM and BS alignment until you get about 80 counts on POP90 and 50 counts on POP18.  

• PRM finally locked!  PRM was moved the most, a little BS & PR2

4)Realign SRM by undoing whatever change you made in step 1.

5) Request DRMI_1F_OFFFLOADED from the ISC_DRMI guardian.

Waited for DRMI to lock again.  Several times I had a Verbal Alarm which sounded like "Slip Mode"?  What do we do about this?  It looked ugly on AS-AIR video.  Had "Slip Mode" alarms a few times while waiting for DRMI, and then the Vancouver earthquake arrived!

After recovering ISIs and ETMy, took ISC_LOCK to LOCKING_ALS, but haven't made it there yet (the guardian log keeps saying "Waiting for arms to settle").  The 0.03-0.1Hz seismic band was ramping down, but flattened out at 0.3um/s (which is over an order of magnitude from normal quiet levels).  Perhaps we should wait for this to come down to normal levels.

At 13:54 Verbal Alarm posted Earthquake.

Looks like Magnitude 5.5 from Vancouver Island at 13:49.  (Terramon did not alert us to this one.)  0.03-0.1hz seismic has increased 3 orders of magnitude (!) and 0.1-0.3Hz seismic has increased 2 orders of magnitude.

ETMy & all BSC ISIs have Watchdogs have tripped.

H1 had a ~46Hr lock that ended toward the end of Jim's shift.  He noted DRMI was looking pretty ugly.  I waited DRMI a little, but eventually gave Sheila's new PRMI procedure a try, but POP18 & POP90 remained at a flat zero and PRMI never locked.  So went through the Initial Alignment procedure (I went slow & took notes since this is something we do rarely.).  Alignment was and getting to NOMINAL_LOW_NOISE were straightforward.

• H1 was down for ~2hrs (6:30 - 8:34).
• 1hr was alignment (PRMI & Initial), and 1hr was locking
• H1 currently in Observation at ~75Mpc

Reason for Lockloss?

I saw nothing obvious from seismic signals when I walked in, everything quiet!  Jim mentioned ASAir/OMC video spots took an odd move prior to lockloss.  H1 was trending down over 6hrs before the lockloss, and Jim mentioned this could be the RF45 issue which has been coming up.

Initial Alignment Notes:

• ALS locking, no issues
  • Comm beatnote ~4.7dBm
• video0 was super slow!  So, it was slow to watch control signals settle (video0 was rebooted after getting to Observation Mode)

TITLE:  9/24 OWL Shift:  7:00-15:00UTC (00:00-8:00PDT), all times posted in UTC

STATE OF H1:   H1 in lock acquisition after ~45hr lock.

OUTGOING OPERATOR:  Jim W. 

SUPPORT:  None

QUICK SUMMARY:  DRMI looked ugly.  Tried Sheila's new procedure for PRMI, but POP90 & POP18 were flat at zero.  Proceeding with an Intial Alignment.

• Title: 9/23 Eve Shift: 23:00-7:00UTC 

• State of H1: Re-locking after loss of 46 hr lock

• Support: Most of the commissioning crew was here when I arrived, Jenne held out till 6 UTC

• Shift Summary: Mostly quiet untill lockloss at 6:30

• Activity Log:

• 23:00 ish JeffK doing PCAL measurements

• 1:00 ish I load new code for event triggers

• 5:00 ish RFAM starts acting up, range starts trending down more

• 6:30 Lock loss, no obvious cause, I start trying to recover

Durring yesterday's maintence window I made some excitations on both transmons to investigate the noise peaks around 75-85 Hz.  The main conculsions are that the coupling from TMS X L drive to DARM is bilinear while the coupling from TMSY is linear, and it seems likely that TMSX motion accounts for some significant part of the unexplained noise in the H1 noise budget (21162) even at frequencies where there is no coherence between DARM and the X QPDs. 

In the first attached screen shot you can see the DARM spectra durring some of my excitations in the upper panel and TMS QPD spectra in the lower panel.  In the QPD spectra, you can see that the X end QPDs have some excess noise compared to Y.  These spectra were from a time when I had a TMSX longitudnal injection at 75 Hz (this is the same time as the yellow DARM trace).  There is a narrow line in the X QPD spectra, but in the DARM spectrum the line that appears is about 1 Hz wide, indicating there is some bilinear coupling.  The excitation either did not show up or was very small in the QPD sums.

I also made a few injections into TMSY longitudnal which produced only narrow lines in DARM, both X and Y injections are shown at 100 Hz for comparison.  

We can attempt to make projections of this noise into DARM using the ratio or the injection line peaks or the rms of the injection peaks to estimte the coupling.  I drove longitudnally and the only good witness sensor we have is an angular sensor.  If the coupling mechanism is something like scatter off the QPDs that goes directly back into the arm, DARM would be mostly sensitive to the longitudnal TMS motion and if the QPDs are only seeing the unintentional length to angle coupling the projection from the normal level of the QPD spectra to the normal level of DARM could be an overestimate. This projection does show that this would be within a factor of 10 of DARM from about 100 Hz down to at least 75 Hz.

Perhaps when we get a chance we can try misaligning TMSX to see if we can reduce the noise in DARM this way. 

Everything quiet on site. Environment quiet. The current lock is approaching 40-some odd hours. 

The code the brings up GraceDB alerts on our overviews was somewhat outdated, as it used an FAR of 1e-6 hz (~once every 12 days) instead of 3.8e-7 (~1 a month). Dave wrote up instructions for me to do the update when one of the IFOs dropped out of lock. Just before he left, the opportunity arose, so I updated the code. It's running now.

J. Kissel

I've taken new DARM open loop gain and PCALY to DARM transfer functions to validate the current calibration. During the PCALY to DARM transfer function, I take the transfer function from PCALY's RX PD (calibrated into [m] of ETMY motion) and the CAL-CS front-end's DELTAL_EXTERNAL (calibrated into DARM [m], which -- since we're driving ETMY -- is identical to [m] of ETMY motion). These two different methods agree to within 4% and 3 [deg] over the 15 [Hz] to 1.2 [kHz] band. The calibration discrepancy expands to a whopping 9% and 4 [deg] if we look a frequencies between 5 and 15 [Hz] ;-).

I think we're in great shape, boys and girls.

Details
--------------
- CAL-CS does not correct for any slow time depedence (optical gain, test mass actuation strength, etc), so any agreement you see with the current interferometer is agreement with the reference model taken on Sep 10th 2015 (LHO aLOG 21385).

- In the previous measurement, Kiwamu had to fudge the phase by ~90 [us] to get the phase to agree. Now that we've updated the cycle delay between sensing and actuation to 7 [16 kHz clock cycles] to better approximate the high-frequency frequency response of AA, AI, and the OMC DCPD signal chain, we no longer have to fudge the phase -- AND the phase between the two metrics agree. NICE.

- I've made sure to turn OFF calibration lines *during both of these measurements, but there should be ample data just before and just after with calibration lines ON, such that we can compare our results against theirs to help refine our estimates of systematic error.

- The measurements live in
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O1/H1/Measurements/DARMOLGTFs/2015-09-23_H1_DARM_OLGTF_7to1200Hz.xml
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O1/H1/Measurements/PCAL$/2015-09-23_PCALY2DARMTF_7to1200Hz.xml
and have been committed to the CalSVN. We'll process these results shortly, and perform a similar analysis as Darkhan has done in yesterday's aLOG 21827.

TITLE:  Sept 23 Day shift, 15:00-23:00UTC, 08:00-16:00PT

STATE Of H1:  Commissioning, Range = 78Mpc, lock is 30+ hours long!

SUPPORT: MikeL, Sheila, Chris Biwer, JeffK

SHIFT SUMMARY:  In Observe most of shift, currently in Commissioning.  Commissioning includes injections, filter change, and others in progress.

INCOMING OPERATOR: Jim

ACTIVITY LOG: 

15:58:43UTC - DMT glitch, Range = -1, no effect on IFO

16:00:43UTC - DMT glitch, Range = -1, no effect on IFO

20:16:27UTC - Commissioning, injections 

20:35UTC - Chris Biwer injections end

20:45:20UTC - cleared the ETMX timing error bit that was stuck

20:45:40UTC - GRB notice

20:47:16UTC - put IFO back into Observe

22:21:53UTC - Commissioning

22:22:06UTC - engaged Sheila's DHARD_Y filter

22:22:16UTC - put IFO back into Observe

22:22:18UTC - with the new filter, SDF kicked the IFO out of Observe

Currently JeffK has the IFO.

L1 went out of lock. At H1 we turned off the intent bit and injected some hardware injections.

The hardware injections were the same waveform that was injected on September 21. For more information about those injections see aLog entry 21759

For information about the waveform see aLog entry 21774.

tinj was not used to do the injections.The commands to do the injections were:
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 H1-HWINJ_CBC-1126257410-12.txt 0.5 -d -d >> log2.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 H1-HWINJ_CBC-1126257410-12.txt 1.0 -d -d >> log2.txt
ezcawrite H1:CAL-INJ_TINJ_TYPE 1
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 H1-HWINJ_CBC-1126257410-12.txt 1.0 -d -d >> log2.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 H1-HWINJ_CBC-1126257410-12.txt 1.0 -d -d >> log2.txt

To my chagrin the first two injections were labeled as burst injections.

Taken from the awgstream log the corresponding times are approximates of the injection time:

1127074640.002463000
1127074773.002417000
1127075235.002141000
1127075742.002100000

The expected SNR of the injection is ~18 without any scaling factor.

I've attached omegascans of the injections. There is no sign of the "pre-glitch" that was seen on September 21.

I've uploaded new and approved coherent waveforms for hardware injection testing. SVN is at revision number 5097.

There is a H1L1 coherent version of the September 21 test injection that was done at LHO. It can be found here:
  * H1 waveform
  * L1 waveform
  * XML parameter file

There is a H1L1 coherent version of the September 21 test injection that was done at LHO and the waveform begins at 15Hz. This waveform should be tested after the previous waveform has been tested. It can be found here:
  * H1 waveform
  * L1 waveform
  * XML parameter file

Cheryl and Jeff brought to my attention that GWIstat was reporting incorrect information today.  It turns out that the ~gstlalcbc home directory at Caltech was moved to a new filesystem today; GWIstat gets its information from a process running under that account, and apparently got into a funny state.  I have now restarted it.  For the rest of the current observing segment it will report the duration only from the time I restarted it, about 3:32 UTC.  I apologize for the problem!

Durring the maintence window we left the DHARD yaw boost on (21768 and 21708). There was no evidence that it caused any problems, but I was putting excitations onto transmon at the time and there were other maintence activities going on.  We'd like to check that it doesn't impact the glitch rate, so if LLO drops out of lock or if you see an earthquake on the way ( 0.1um/sec or larger predicted by terramon), it would be great if you can turn it on.  You can find it under ASC overview> ASC arm cavities, DHARD YAW FM3 (labled boost). (screenshot) 

It would be good to get more than an hour of data, so if you see that LLO has dropped it would be awesome if you could turn this on util they are back up.  

This is just a temporary request, only for tonight or the next few days.  

SudarshanK, DarkhanT

We were using 137 degree of correction factor on kappa_tst on our time varying parameters calculation. (alog 21594). Darkhan found a negative sign that was placed at a wrong position in the DARM model which gave us back 180 degrees of phase. Additionally, Shivaraj found that  we were not accounting for DAQ downsampling filter used in ESD Calibration line. These two factors gave us back almost all the phase we were missing. There was also an analog antialiasing filter missing in the actuation TF that was applied in the new model. After these corrections, Darkhan created the new upated epics variable. These epics variable are committed at:

CalSVN/Runs/O1/Scripts/CAL_EPICS

Using these new epics  variable, kaapas were recalculated for LHO. For, LLO these epics variable doesnot exist yet. The new plot is attached below. The imaginary parts of all the kappa's are now close to their nominal values of 0 and real part are few percent (2-3%) from their nominal values of 1, which is within the uncertainity of the model. Cavity pole is still off from its nominal value of 341 Hz but has stayed constant over time.

The script to calculate these time varying factors is committed to SVN:

LHO: CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/CAL_PARAM/

LLO: CalSVN/aligocalibration/trunk/Runs/ER8/L1/Scripts/CAL_PARAM/

These are the channels in the DMT (GDS) hoft frames, which include the calibrated strain channel (H1:GDS-CALIB_STRAIN) and the calibration factors (the kappas):

H1:GDS-CALIB_STATE_VECTOR 16
H1:ODC-MASTER_CHANNEL_OUT_DQ 16384
H1:GDS-CALIB_STRAIN 16384
H1:GDS-CALIB_KAPPA_A_REAL 16
H1:GDS-CALIB_KAPPA_A_IMAGINARY 16
H1:GDS-CALIB_KAPPA_TST_REAL 16
H1:GDS-CALIB_KAPPA_TST_IMAGINARY 16
H1:GDS-CALIB_KAPPA_PU_REAL 16
H1:GDS-CALIB_KAPPA_PU_IMAGINARY 16
H1:GDS-CALIB_KAPPA_C 16
H1:GDS-CALIB_F_CC 16

These channels should be available using NDS2.

(For LLO the channels are the same with: H1-> L1.)