J. Kissel

I haven't processed them yet, but for the record, I was able to grab a collection of measurements of the pas few days that should be a nice reference for 
    (a) The PUM driver fiasco, and
    (b) a before vs. after the Holiday shut down

The data lives here:
FullIFOActuatorTFs/2016-12-20/2016-12-20_H1SUSETMY_L1_iEXC2DARM.xml
FullIFOActuatorTFs/2016-12-20/2016-12-20_H1SUSETMY_L1_PCAL2DARM.xml
FullIFOActuatorTFs/2016-12-20/2016-12-20_H1SUSETMY_L2_iEXC2DARM.xml  << During temporarily swapped PUM Driver
FullIFOActuatorTFs/2016-12-20/2016-12-20_H1SUSETMY_L2_PCAL2DARM.xml  << During temporarily swapped PUM Driver
FullIFOActuatorTFs/2016-12-20/2016-12-20_H1SUSETMY_L3_iEXC2DARM.xml
FullIFOActuatorTFs/2016-12-20/2016-12-20_H1SUSETMY_L3_PCAL2DARM.xml

FullIFOActuatorTFs/2016-12-21/2016-12-21_H1SUSETMY_L2_iEXC2DARM.xml  << After PUM driver was reverted
FullIFOActuatorTFs/2016-12-21/2016-12-21_H1SUSETMY_L2_PCAL2DARM.xml  << After PUM driver was reverted

SensingFunctionTFs/2016-12-20_H1DARM_OLGTF_4to1200Hz.xml             << During swapped driver
SensingFunctionTFs/2016-12-20_H1_PCAL2DARMTF_4to1200Hz.xml           << During swapped driver -- unfortunately incomplete due to lock loss

SensingFunctionTFs/2016-12-21_H1DARM_OLGTF_4to1200Hz_25min.xml       << After PUM driver was reverted
SensingFunctionTFs/2016-12-21_H1_PCAL2DARMTF_4to1200Hz_8min.xml      << After PUM driver was reverted

We'll process this data of the next few weeks and get back to you.

J. Kissel 

Yesterday, after seeing little-to-no impact from replacing the H1 SUS ETMY PUM driver, we have reverted to the original driver.
     - Spare Driver (s/n S1102648) swapped in: LHO aLOG 32745
     - Original Driver (s/n S1102652) reverted in: LHO aLOG 32780
The only H1 observational stretch that includes this temporary PUM driver:
    Dec 20 2016 10:44:28 UTC - Dec 20 2016 13:43:44 UTC
    Dec 20 2016 02:44:28 PST - Dec 20 2016 05:43:44 PST
              GPS 1166265885 - GPS 1166276641
    Duration: 10756[sec] or 2.99 [hr]
During this time, L1 only had a short 22 minute lock stretch,
    Dec 20 2016 12:31:15 UTC - Dec 20 2016 12:53:34 UTC
    Dec 20 2016 04:31:15 PST - Dec 20 2016 04:53:34 PST
              GPS 1166272292 - GPS 1166273631
    Duration: 1336 [sec] or  0.37 [hr]

Note: While reverting the coil driver, Fil also power cycled the respective AI chassis, so observational stretches after Dec 20 2016 13:43:44 UTC, if they have an improved glitch rate, are likely due to either reseating / reconnecting the original PUM driver (s/n S1102652), or are perhaps more likely related to the power cycle of the AI chassis.

---------
Characterization Measurement Comparison between Temporary Spare Original (S1102648) and Original Driver (S1102652)

Using the same entirely digital measurement technique we used to determine the compensating poles and zeros for the coil drivers before O1 (i.e. using the coil driver monitor circuits; see LHO aLOG 20846), I measured the PUM driver's frequency response before and after we swapped out the driver for a spare. Results are attached.

The .png attachments focus on State 3, which is the state used in nominal low noise and therefore would affect calibration, coil balancing, and length-to-angle decoupling filters. The .pdf attachments cover all four states for all four coils that were measured (because we do transition between states during lock-acquisition -- important for duty cycle, not sensitivity).

The analysis process is as follows (in order of .png attachments):
(1) In order to get coherence across the entire relevant frequency band**, I took both swept sine and white noise transfer functions. These were each filtered for high coherence (a threshold of 0.99), and then concatenated. The .png shows one coil (LR), in one state (state 3), for the original driver (S1102652) as an example to illustrate the process.
(2) Once this data is gathered and concatenated for the two drivers, for all 4 states of all 4 coils, I take the ratio of the original vs. the temporary driver. The .png shows an example of this again for the LR coil in state 3, but for both drivers and their ratio.
(3) The ratio of driver response for all four coils is shown in the same plot in the 3rd .png.
(4) To compute the impact of these changes on the longitudinal response of the stage, we show two traces in the 4th .png. Mathematically similar but not identical, I show 
     (a) the "average" (more accurately, the sum of each coil multiplied by 1/4) of the ratios from plot (3), and 
     (b) the ratio of the "average" of each driver's coils.

Plot 4 shows that, if we had left the temporary driver in place, then we would have a frequency dependent, +/- 4% / 5 [deg] systematic error in the IFO's response to gravitational waves in the 10 - 30 Hz region.
It also means, that for that 3 [hr] observation stretch on Dec 20th, we have this +/- 4% / 5 [deg] systematic error in the IFO's response in the 10 - 30 Hz region. For this reason, if at all reasonable, I suggest we create a data quality flag for that observation stretch. Otherwise, the librarian's nightmare of creating a new DARM model for just those 3 [hrs] would divert the calibration group's energy away from where I think our priorities lie in the foreseeable future.

* This actuator authority comparison was generated by Evan, originally in LHO aLOG 28746. The script to generate these plot lives here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER9/H1/Scripts/HeirarchicalFilterDesign/HeirarchicalFilterDesign.m
and the plots from the entry live in the same directory.

** This data was taken when I expected that we were going to stick with the S1102648 PUM driver and needed to readjust the coil compensation filters (see LHO aLOG 21232). As such, the relevant frequencies are from 0.1 [Hz] -- enough below the lowest pole frequencies it can be separated from DC transconductance in fitting -- to 10 kHz where the impact of coil impedance begins to flatten out.

------------
The templates and exported data from this aLOG live in:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/Measurements/Electronics/

The script to analyze the data lives in:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/Scripts/Electronics/

The .pdfs of the attached plots live in:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/Results/Electronics/

Starting CP3 fill. LLCV enabled. LLCV set to manual control. LLCV set to 50% open. Fill completed in 1476 seconds. TC B did not register fill. LLCV set back to 19.0% open.
Starting CP4 fill. LLCV enabled. LLCV set to manual control. LLCV set to 70% open. Fill completed in 36 seconds. TC B did not register fill. LLCV set back to 34.0% open.

The H1 PSL Detailed Screens link from the LHO MEDM Screens web page now displays additional screens for TCSX and TCSY. 

Starting CP3 fill. LLCV enabled. LLCV set to manual control. LLCV set to 50% open. Fill completed in 1476 seconds. TC B did not register fill. LLCV set back to 19.0% open.
Starting CP4 fill. LLCV enabled. LLCV set to manual control. LLCV set to 70% open. Fill completed in 36 seconds. TC B did not register fill. LLCV set back to 34.0% open.

Starting CP3 fill. LLCV enabled. LLCV set to manual control. LLCV set to 50% open. Fill completed in 1476 seconds. TC B did not register fill. LLCV set back to 19.0% open.

5.9M Northern Mariana

Was it reported by Terramon, USGS, SEISMON? Yes, Yes, No

Magnitude (according to Terramon, USGS, SEISMO): 5.9, 5.9, NA

Location 120km NNE of Farallon de Pajaros, Northern Mariana Islands; LAT: 21.5, LON: 145.4

Starting time of event (ie. when BLRMS started to increase on DMT on the wall): 17:00 UTC

Lock status?  Lockloss due to earthquake

EQ reported by Terramon BEFORE it actually arrived? Terramon reported before the lockloss, but I noticed the EQ band BLRMS coming up before checking Terramon

I noticed that the dust monitor 10 (beer garden) was stopped, trending showed it was stopped about 09:58 PST Tuesday Dec. 20. After talking with Jeff B, restarted it. It's now faithfully reporting dust in the LVEA again.

• 08:38UTC restarted lock clock. It had been frozen since the last 4+hr lock
• EX Temp is High Alarm @ 14:55:00, 15:30:15. Some temp data is listed below in screenshots.
• 15:58 Out of Observing to run a2l script while Livingston is doing some WFS investigations regarding their short lock stretches. Some measurement progressions are listed below including the latest post-a2l script screenshot.

All trends appear normal. Diode powers tracking humidity trends as usual. Everything else is relatively nominal.

Carlos, Jim B, Dave, Nutsinee

Follow up of WP6382

I took advantage of the earlier down time to test the HWS stream images script and swapping CLink around. The original set up after Carlos installed the second PCI-e card was HWSY CLink was plugged into the new card and HWSX CLink remained the same (plugged to old card). HWSX streamed live images without problem while HWSY can't get any sensible image at all (see attachment). So I tried a few more configurations:

• HWSX CLink plugged to the new card, HWSY plugged to the old card
  • Result: HWSY worked, HWSX didn't
• HWSX and HWSY CLink both plugged into the new card
  • Result: None worked
• HWSX and HWSY CLink both plugged into the old card
  • Result: Both worked (just like how they were prior to adding the second card)

We have come to the conclusion that the spare card might be busted. The next thing to try is to order a new card and try again. This way we will know for sure that the card actually works. We don't know where the spare card came from and whether or not it has been tested.

This has not been attempted previously to CP3 or CP4 though it is not a new or original idea.  

Both CP3 and CP4 are thought to be experiencing the same issue, i.e. an obstructed level sensing line.  This could be due to the accumulation and clumping of "snow flakes" of water ice.  It may be that the relative buoyancy in LN2 of these "snow flakes" is concentrating them near the bottom of the LN2 pump which is also where the lower sensing line enters the pump and samples the LN2.  With an increasingly dense concentration over time it is easy to imagine these "snowflakes" interlocking and forming clumps which eventually restrict the ID of the sensing line (the "cholesterol" theory!) to the point of complete obstruction.    

In the past we had applied UHP N2 (various pressures/durations -> Max. of 180 psi) to these clogged lines in an attempt to "push" this obstruction back into the 80K pump.  These attempts gave no indication of a resulting movement of the obstruction nor flow of the applied UHP N2.  Today, while changing the most recently depleted cylinder of UHP LN2 (leak into the room), I decided to reconnect the sensing line to the local differential pressure gauge.  I noticed that it indicated a differential pressure of 5" of water.  I repeated the process of decoupling the line from the gauge and exposing it to atmosphere for a period then reconnecting it to the gauge.  Each time the pressure difference increased by ~0.5" of water.  This got me thinking..... 

Considering the relatively large mass of water that can be extracted from food in the freeze drying process while exposed to vacuum and in such a relatively short amount of time, I discussed with John W. the risks and possible benefits of applying vacuum to our clogged CP4 line.  The hope is to encourage the sublimation of the "ice plug".  It was decided that applying a vacuum to the sensing line would be low risk at this point.   

So, late in the day, I hooked up a small diaphragm pump and pumped on the sensing line for a few minutes.  After reconnecting it to the differential pressure gauge and CDS level transducer I found that the indicated pressure difference had increased.  Repeated cycles produced repeated benefit (see attached image).  Of particular note is that an audible release of built-up gas could be heard each time the sensing line connection was loosened to do the next round of vacuum pumping.  This suggests that the CDS indicated pressure difference is due to a real pressure difference and that, perhaps, the vacuum pumping has established a flow path through the plug!  Or, that the ice plug has been pulled into a warm area.

Gerardo and I will continue tomorrow.  Chandra R. will be back after the new year. 

The original ETMY PUM coil driver (S1102652) was reinstalled this morning. Two hour lock shows little or no change in the glitch rate. The AI chassis controlling the PUM chassis was also power cycled.