With the previous filters file at LHO, the GDS pipeline was not computing correct values for the kappas. As pointed out by Darkhan, the ESD line frequency at LHO was changed on Aug 24, 2016. The value used in aligocalibration/trunk/Runs/O2/TDfilter/create_partial_td_filters.m was updated accordingly, and the new filters file computes the kappas as expected. The new filters file can be found in the calibration SVN:

aligocalibration/trunk/Runs/PreER10/GDSFilters/H1GDS_1159648300.npz

These filters were made using revision #3400 of the calibration SVN.

Several plots are attached: 
A plot of the h(t) spectrum calibrated using this filters file and the output of the front-end CALCS model
CALCS vs. GDS residual plot
Plots of the control correction filter and the residual correction filter

Some T240 proof masses are out of range:

• 2016-10-04 13:52:22.364340
• There are 8 T240 proof masses out of range ( > 0.3 [V] )!
• ETMX T240 2 DOF X/U = -0.522 [V]
• ETMX T240 2 DOF Y/V = -0.617 [V]
• ETMY T240 1 DOF Y/V = 0.349 [V]
• ETMY T240 3 DOF Z/W = 0.344 [V]
• ITMX T240 1 DOF X/U = -0.433 [V]
• ITMX T240 3 DOF X/U = -0.409 [V]
• ITMY T240 3 DOF X/U = -0.307 [V]
• ITMY T240 3 DOF Z/W = -0.528 [V]

All others are within range.

All STS proof masses are within a healthy range.

Details attached.
 

model restarts logged for Mon 03/Oct/2016
2016_10_03 09:23 h1ioplsc0
2016_10_03 09:23 h1lsc
2016_10_03 09:23 h1omc
2016_10_03 09:24 h1ioplsc0
2016_10_03 09:24 h1lscaux
2016_10_03 09:24 h1lsc
2016_10_03 09:24 h1omc
2016_10_03 09:24 h1omcpi

h1lsc0 restart to fix power switch on IO Chassis in CER.

model restarts logged for Sun 02/Oct/2016 None reported

model restarts logged for Sat 01/Oct/2016 None reported

model restarts logged for Fri 30/Sep/2016

Site power outage at 06:08PDT, all machines rebooted between that time and 08:30.

2016_09_30 13:58 h1fw2

upgrade daqd code for minor bug fix found at llo.

Fault Report 4683
WP 6211

One of the binary cards inside IO Chassis SEIEY was replaced this morning. This was to fix the remote auto-zero function for the STS-2 chassis. Hugh did a functionality check for the binary input/outputs for associated card. The h1seiey IO chassis and front end computer were restarted.

J. Batch, F. Clara, H. Radkins

WP 6214

Dave, Jim, Jamie

Added 24G of RAM to h1nds0 to bring a total of 72GB.  Increased daqd's memory buffer usage in the daqdrc from 50 to 100. Jamie tested his application that collects recent data, which now works properly.

This was actually done in two steps, the first try installed a total of 96GB.  We determined that was far more than was needed, so we backed that out to a total of 72GB, made up of 3-16GB DIMM in the first bank, 3-8GB DIMM in the second bank.

The LHO DMT machines were updated today with the gstlal-calibration-1.0.3 package.  The GDS pipeline was restrated to work from this package at 1159637032. 

For the record, the chiller controller software versions for both crystal chiller and diode chiller are:
  CCC-3
  Firmware-Vers. 0.82

    That does not necessarily imply that a controller for the diode chiller can be replaced with one from
a crystal chiller and vice versa.

TCS-X: Full, level at 29.0, 3.7 gpm, 20.5 deg. C

TCS-Y: found water level at 4.3, added 500 mL water, raised water level to 8.7, 4.0 gpm, 20.3 deg. C

Attached are what the signals from the Kobold vortex flow sensors look like as read across
a 240-ohm resistor.

TEK00001.png shows the signals corresponding to switching off and back on the chiller.
TEK00002.png shows the signal decay from the power meter circuit flow sensor when the
  chiller is switched off.
TEK00004.png both signals when the chiller is switched off.
TEK00005.png looking for glitches when one of the sensors drops
TEK00007.png both signals when the chiller is switched off, only this this both outputs
  fell to zero within the same oscilloscope sweep
TEK00008.png both flow sensors were physically disconnected to simulate a power failure or
  dramatic sensor failure.
TEK00010.png the power meter flow sensor output was switched off

    There are a couple of things of interest to note:
 1.  The signal from the sensors is much "cleaner" than what comes out of data acquisition,
most likely due to the digitisation of the readout Beckhoff terminal.
 2.  Using an AC mains powered oscilloscope introduces a large 60 Hz signal on top of whatever
is there.  A battery power oscilloscope was used for these measurements.

Time-dependent parameter ("kappas") trends calculated from two lock stretches on September are attached to this report.

It seems that the front-end produced fairly smooth kappas several hours after the most recent update of the front-end setttings (LHO alog 29992). See figures 1 and 2.

However, from later lock stretches on September 30 (after the Tuesday activites), it looks like the synchronized oscillators for SUS line were synched with an incorrect phase of 143.6 degress w.r.t. each other (see KAPPA_TST values in Fig. 3 and TF phase in Fig. 4). A similar issue was reported in the previous report (LHO alog 29992). I was able to fix the problem for this particular line by resetting the line frequency to 0 Hz (turning off the line) in the SUS-ETMY model and then setting it back to its nominal state 35.9 Hz (see Fig. 5). We probably need to check "FIXED_PHASE_OSC_WITH_CONTROL.c" for bugs.

A while ago we noticed that the auxillary loops have had increased noise compared to O1.  Here is a plot verry similar to what I posted in 30032, but with correct labels. 

Here is a more detailed timeline:

March 8th, the noise is pretty much the same as O1. 

March 12th: a 2W lock where the low frequency noise is similar to O1, but the shot noise is high. 

March 14th-20th, we were down for grouting work in which I think we lost the green camera references, alignment redone March 19th.

March 20th the exposure of the PR2 camera was increased from 500 to 1 million, then reset to 1000 March 21st.  Since the camera was saturated at 1000, I have now reset it to the old exposure of 500. 

I cannot seem to get data from late march until April 2nd, when the noise is already elevated.

April 4th the HPO is turned on, and we are down for several weeks, the noise stays around.  

So, this noise could be due to some clipping or other problem that was introduced when we lost our alingment references.  

TITLE: 10/04 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: None
SHIFT SUMMARY: PSL down.  Work continues in the morning.  Calling it a night due to no laser.
LOG:  None
 

For reasons best known to itself, the diode chiller is no longer cooling the diodes but heating them up.
This was the most likely reason why the laser tripped out when it was fired up this afternoon.

    Another report will follow later about the signals we observed from the front end flow meter and the
power meter circuit flow meter.

   The crystal chiller has been left running.  The diode chiller is off.  A new controller for it is
expected soon.




Jason/Peter

In an attempt to bring some clarity into the beam jitter discussion I looked at the Gouy phase evolution of the input beam. I collected distance and focal length information from a variety of sources, notably T1200470 and E1200616.

The biggest uncertainty I had was the PSL persicope to HAM1 viewport distance - if someone knows that, let me know.

The MATLAB script with all the numbers is in ~controls/sballmer/20160930/inputBeamCalc.m. It creates a structure of the following form, fully describing the beam and optical mode:

IMC =
    lambda: 1.0640e-06               % The wavelength in m
         q: 0.2325 +13.3832i          % The input Gaussian beam parameter q=z+izR in m
         N: 4                                 % number of optics
      dist: [16.2406 16.2406 0.2325 0.2325 0] % Distances between the optics (one more than N)
      ifoc: [0.0731 0 0 0]               % inverse focal length for all lenses and mirrors (f=R/2 for mirror)
     label: {'MC2'  'MC3'  'Waist'  'MC1'} % optic names
 

The attached .mat file contains the following structures of that form::

IMP:    Input beam: From PSL periscope to MC3
IMC:    Input Mode Cleaner
IMCp:  Input Mode Cleaner from MC1 to MC3 only (output path inside IMC)
IM:      Input Mirros: from IMC to PRM
PRC:  Power Recycling Cavity forward path
PRCr: Power Recycling Cavity return path
PRCrt:Power Recycling Cavity round trip

Below are plots and data for the different beam segments.

This is a plot of the jitter measured by the IMC WFS DC PIT/YAW sensors during last nights lock. The 280 Hz periscope peak reaches about 1x10^-4/√Hz in relative pointing noise, or about 3x10^-4 rms. The relative pointing noise out of the HPO is about 2x10^-5/√Hz at 300 Hz. After the attenuation through the PMC this would correspond to a level below 10^-6/√Hz. The jitter peaks show up in DARM, if they are high enough. This is clearly visible in the coherence spectra.

The ISS second loop control signal is an indication of the intensity noise after the mode cleaner with only the first loop on. The flat noise level above 200 Hz is around 3x10^-6/√Hz in RIN, with peaks around 240 Hz, 430 Hz, 580 Hz and 700 Hz. Comparing this to the free-running noise in alog 29778 shows this RIN level at 10^^-5/√Hz. We can also compare this with the DBB measurements, such as in alog 29754: the intensity noise after the HPO shows a 1/f behaviour and no peaks. Looking at the numbers it explains the noise below 300 Hz. It looks like a flat noise at the 10^-5 level including the above peaks gets added to the free-running intensity noise after the PMC. The peaks in the controls signal of the second loop ISS line up with peaks visible in the pointing noise. But, neither the numbers nor the spectral shape matches. These peaks have coherence with DARM.

Kiwamu, Sudarshan, Jenne, Darkhan

Overview

EPICS records that are used for calculating DARM time-dependent parameters ("kappas"), were updated using corrected DARM model (with the correct sign of the ETMY_L3_DRIVEALIGN_L2L gain). These EPICS values result in reasonable kappa values (see details).

"512 Hz DAQ downsampling" filter was installed into CAL-CS synched oscillator that replicates 35.9 Hz cal. line (ESD).

Investigations showed that the synched oscillators for 35.9 Hz cal. line were running at 180 degrees out of phase w.r.t. each other. They got synched to the same phase after I played some with the oscillator settings in CAL-CS model.

Jenne noticed that today f_C was oscillating between 320 and 360 Hz at the time-scale of ~20s. This issue was resolved by turning on low-pass filters in the CAL-CS model.

Details

Sudarshan confirmed that kappas calculated from SLM tool data using these EPICS values are within reasonable ranges. After updating EPICS records one of the issues was that κ_TST calculated in the front-end was around -1.0. Further investigations showed that the synched oscillators for 35.9 Hz cal. line in SUS-ETMY and CAL-CS models were running at 180 degrees out of phase w.r.t. each other. We could get rid of the discrepancy by setting the phase of the CAL-CS oscillator to 180 degrees (see attached plot).

After changing settings on the synchronized oscillators their phases somehow got synchronized. So, I removed 180 degrees of an additional phase in the CAL-CS oscillator. It is still not clear what was the cause for the phase of two synched oscillators being exactly 180 degrees off. Now the oscillator outputs (after the 512 Hz DAQ downsampling) are pretty much the same (TF measurement at 35.9 Hz is attached).

New EPICS values and corresponding logs were commited to calibration SVN. The values were accepted in SDF_OVERVIEW.

ECR E1600230-v1

WP 6053

We analyzed the transfer function through the ETM ESD Driver before and after the capacitor and TVS were applied (see ECR).  Using the Dynamic Signal Analyzer (SR785) set to sweep from 1kHz to 100kHz at 1000mV, the driver performs as expected when the waveform is applied to the PI input.  I have attached a plot of the transfer function displaying modified HV, modified LV, and pre-mod HV values.