Loss of heat in midX VEA and then regain Monday afternoon caused pressure fluctuations.

model restarts logged for Tue 31/Jan/2017
2017_01_31 11:11 h1isibs
2017_01_31 11:15 h1isiitmx
2017_01_31 11:17 h1isiitmy
2017_01_31 11:21 h1isietmx
2017_01_31 11:25 h1isietmy
2017_01_31 11:27 h1isiham4
2017_01_31 11:28 h1isiham5
2017_01_31 11:30 h1isiham6
2017_01_31 12:13 h1broadcast0
2017_01_31 12:13 h1dc0
2017_01_31 12:13 h1fw0
2017_01_31 12:13 h1fw1
2017_01_31 12:13 h1fw2
2017_01_31 12:13 h1nds0
2017_01_31 12:13 h1nds1
2017_01_31 12:13 h1tw1
2017_01_31 12:18 h1isiham4
2017_01_31 12:20 h1isiham5

Maintenance. New ISI models, restart of h0vacex (not shown), associated DAQ restart. Restart of ISI ham4,5 to clear DAQ status 0x2000 (possible NFS caching)

model restarts logged for Mon 30/Jan/2017 No restarts reported

late entry for yesterday's maintenance

WP6457 Remove coil driver BIO input to watchdogs

Hugh, Jim, Dave:

All ISI frontends except for HAM2,3 had new code loaded. After HAM4,5 were restarted, their DAQ status did not go to 0x2000. Subsequent DAQ restart did set their status to 0x2000. To be safe, we restarted these models a second time. Investigating why this happened.

WP6431 New IP12 Beckhoff vacuum controls code

Patrick, Dave:

h0vacex was restarted with new code. A new INI file was added to the DAQ. Also, water pressure channels were added (verifiied these are present in the other building systems).

TITLE: 02/01 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 67Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY:

• lockloss, I ran our lockloss tool, then computer crashed, I saw bursts of noise before lock loss
• relocking, ETMs, TMSs, BS, PRM needed adjustments, then all the way up to NLN
• PI mode 27 saturated ETMY drive, I didn't recognise, Terra called and helped, PIs are good now, alog 33795
• I changed ITMX bounce mode damping phase, alog 33796

• While working on PI modes, I  had added -30deg phase for ITMX roll mode, and the damping has improved.
• plot attached is a dtt showing ITMX previous locks (black) and current lock (green)
• I went ahead and accepted the -30deg filter change in SDF so I could put H1 in Observe

• PI mode 27 rang up first, but I had trouble damping it, followed Terra's instructions, changed phase, lowered the gain, changed the phase on the damping fitler
• mode 27 leveled off
• in the mean time mode 28 rang up, followed Terra's instructions, changed phase, changed the gain, changed the phase on the damping fitler
• mode 28 leveled off
• mode 26 rang up
• Terra called, identified that the drive to ETMY was saturating
• I lowered mode 27's gain even more (was 7000, then 3500, now 2000)
• reset damping filter phases with SDF
• it took a few minutes, but all modes damped
• H1 into Observe
• the range drop before going to Observe is due to PI modes, tagging for DetChar

Here are plots of IM1, IM2, IM3, and IM4 OSEM input signals, test points, and coherence with DARM.

Power Spectrums:

• IM4, right side plot, only IM driven by ASC, and shows a difference in peaks between 0.1Hz and 0.2Hz, with upper OSEMs showing more motion that lower OSEMs, meaning of this is not immediately clear to me, but different that all other IMs
• IM3, right of center, OSEM LL noisy, and peaks at 1+Hz in OSEMs UL and UR are smaller than expected mangitude, OSEM LR magnitude at that frequency is expected
• IM2, left of center, all OSEM spectra look very similare
• IM1, left side plot, OSEM UR noisy

Coherence with DARM: all low, but some features

• IM4, right side plot, peak between 0.4Hz and 0.5Hz
• IM3, right of center, uneventful
• IM2, left of center, OSEM UR, brown trace, has a possibly interesting peak at 1.8Hz
• IM1, left side plot, peak between 0.1Hz and 0.2Hz very different that for all other IMs, lower and broader, also OSEM UR has coherence peaks up to 0.2 from 8Hz to about 15Hz, which is unique to IM1, so possible interesting

I noticed ITMX roll mode during my shift yesterday (and the day before) and ran a power spectrum with coherence with CAL-DELTA;

• ITMX roll peak magnitude is 1.7, compared with the next highest which is ITMY at 0.4
• ITMX coherence is at 0.53, compared to ITMY's at 0.03

TITLE: 02/01 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 66Mpc
OUTGOING OPERATOR: Jim
CURRENT ENVIRONMENT:
    Wind: 12mph Gusts, 11mph 5min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.47 μm/s
QUICK SUMMARY:
H1 locked and looking good
 

TITLE: 02/01 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 65Mpc
INCOMING OPERATOR: Cheryl
SHIFT SUMMARY: Another quiet shift
LOG:
Corey had just finished IA when I arrived. The only lock losses I had after were during ALS acquisition. Straight from DRMI to NLN.

J. Kissel

After Keita begin using DELTAL_EXTERNAL_DQ for his subtraction studies, I was reminded that we need to update the control room wall FOM template for the recent DARM loop model changes (see LHO aLOG 33585 and 33434). Also, it reminded me that here at LHO, we have not switched over to using the more precise method of adding the CAL-CS DELTAL_CTRL vs DELTAL_RESIDUAL developed at LLO (see LLO aLOGs 28268 and 28321) that allows us to correct for all of the high-frequency limitations of the front-end CAL-CS DARM loop model replica (see II/ET Ticket 4635) without being limited by integer clock cycles.

As such, I copied a script from Shivaraj,
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/L1/Scripts/CALCS_FE/CALCSvsDARMModel_20161125.m
that computes what this relative delay should be as a function of frequency. Because it needs interferometer specific information as he's written it, I've put H1's version for the latest reference model time (2017-01-24, after the 4.7 kHz notch was added to the DARM filter bank, again see LHO aLOG 33585) in an appropriate place,
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/Scripts/CALCS_FE/CALCSvsDARMModel_20170124.m
and updated it accordingly. The function also has the bonus of checking the CAL-CS model implementation against the supposedly perfect Matlab model.

I attach the output.

The first plot shows the ratio between the CAL-CS replica (re-exported back into matlab) and the perfect matlab DARM loop each for each actuation and sensing path. This ratio should expose all the the CAL-CS model is missing:
     - computational delays, 
     - the light-travel time delay
     - the pre-warping of high-frequency roll-off filters
     - the response of uncompensated high-frequency electronics, and 
     - the digital and analog AA or AI filters. 
That which CAL-CS is lacking is accounted for in the GDS pipeline to form the product consumed by the astrophysical searches, GDS (or DCS)-CALIB_STRAIN. However, since the front-end / CAL-CS is incapable of precisely handling these effects for the real-time control room product DELTAL_EXTERNAL, and they're predominantly high-frequency effects, we, in the past have approximated them with adding a relative delay between the sensing and actuation paths, as explained by LHO aLOGs 32542, 21788 or 21746.

The second plot shows the same sensing function ratio, but now with the entire actuation function summed together. 

The phase difference between the two function on page two, as a function of frequency, is recast as a delay and converted to 16 kHz clock-cycles in the third attachment.

Ideally, this phase difference / delay would be flat as a function of frequency, so we'd feel good about applying a single delay number in-between the paths, even if it was a non-integer 16 kHz clock cycle. This is what LLO's looked like in LLO aLOG 28321, and what they installed according to the last paragraph of LLO aLOG 29899. 

However, LHO's is *not* flat, so I'm not sure what to do.

Also, at the DARM loop Unity Gain Frequency (68 Hz) where you would expect the delay needs to be perfect at the crossover between actuation and sensing functions -- the phase difference or delay is exactly 427 [usec], which is 7 16kHz clock cycles, which is at what the delay is currently set. 

So... do we need an update? I'll converse with Joe and Shivaraj and decide from there.

-------------
The DARM model and parameters used to generate the plots in this aLOG are:
    trunk/Runs/O2/H1/params/2017-01-24/
       modelparams_H1_2017-01-24.conf  (r4241, lc: r4241)

    trunk/Runs/O2/DARMmodel/src/
       DARMmodel.m                     (r4241, lc: r4241)
       computeDARM.m                   (r4241, lc: r4241)
       computeActuation.m              (r4241, lc: r4241)
       computeSensing.m                (r4093, lc: r4025)
       
    trunk/Runs/O2/H1/Scripts/CALCS_FE/
       CALCSvsDARMModel_20170124.m     (r4263, lc: r4263)

Modified the output of HAM6 ion pump controller to -7.0 kV from -5.6 kV, did a re-configuration/calibration after via the front panel.

Work done under WP#6461.

EDP200 s/n CSM1166
Oil level good but dirty -> Internal coolant ~12 fluid oz. low - Added ~12 fluid oz. of 50/50 mix of distilled water and Drystar coolant w/rust inhibitor.  Installed modified ASA blank to cap inlet.  Modification included tapped hole allowing addition of a mechanical vacuum gauge and 1/4" ball valve for gas admission.  Ran pump for 1 hour with the only load being 2 LPM of UHP GN2.  Pump ran quiet and achieved operating temperature; pressure < 29" Hg - no problems with this unit - Same as last week for s/n CSM1165

Kyle, Chandra

WP 6463

Today we fed a 1/16" diam. rope wire through the bottom sensing lines of CP 3 & 4. Length of 109.5" penetrated CP4 (measured from the 1/4" swagelock fitting). Length for CP3 was 105.5". The sensing line is 1" longer on CP4 than for CP3 (based on how much it protrudes from nipple welded to CP outer body).

The theoretical length from drawings V049-4-005, V049-4-090, V049-4-121 is 111.7" ....and then add 1.2" for CP3 and 2.2" for CP4 for additional length of swagelock connections.

We felt resistence toward the end, where I thought we were hitting the 90 deg bend just past the bibraze joint (until looking at these measurements more closely); then we were able to push another ~2". Vertical length is 2.25". The gap between the inner and outer vessel wall at the bottom is only 7/8". The last 4-5" of the wire was cold and frosted when we pulled it out. We then cycled between ~1 Torr (diaphragm pump) and 100 psig pressure on CP4 lower sensing line. Did not detect any breakthrough.

We left both CP3 and CP4 upper and lower sensing lines plumbed together through the shunt valve, essentially bypassing the transducer. Currently not pumping or pressurizing CP4 line.

WP 6457  ECR E1700032 FRS 7099 DCC T1700025

This model update takes the binary coil status data out of the WD tripping code.  If this data goes bad for 60 seconds, a red medm light will show on the ISI platform overview screen labeled OVERTEMP.  If the coil driver actually does experience an overtemperature condition, the hardware itself will trip and of course the ISI will trip as the Actuators let go and seismometers rail, you know, cats & dogs living together, mass histeria.  So there is little risk that anything too bad would result from this change.

The change was to prevent unnecessary tripping of the ISI when the binary signal from the Coil Driver went erroneously bad.  This happened to LHO Oct 2015 & 22977  and the model was changed to allow a 10 sec wait before tripping the watchdog.  In May 2016 this was extended to the HAMs. In Sept 2016, this 10 second delay proved not sufficient for LHO BS ISI.  It then became a problem for LLO earlier this month.  So this is a short likely episode missing history of the problem leading to this model change.

Summary of the DQ shift from Thursday 26th to Sunday 29th (inclusive), click here for full report:

• Very high duty cycles of 95% Observing. Range sitting around 68-70 Mpc.
• Range drops caused by; ETMY ESD overflows, glitches on the 100-200Hz band, and scattering of SUS-SRM_M1.
• IMPORTANT: Range reduced when broad excess noise below 70Hz was present. In one case this noise increased after running of A2L DTT script for dither-up. (see attached pic)
• NOTE: Presence of nonstationary narrow excess noise at around 70Hz causes small reductions of range sensitivity (few Mpc). In some case observed time agreement with increase in Pitch and Yaw motion of ITMX. (see attached pic)
• Not all lockloss understood. One was preceded by overflow of H1:ASC-AS_C_SEG2 and H1:ASC-AS_C_SEG4, this lockloss showed agreement with spikes on HAM6 X-Y acelerometers and with some erratic behaviour of the Corner building external temperature (see attached pic). Other nonunderstood lock losses had time coincidence with ground motion and wind activity.
• Violin modes have been well damped for the whole shift. And 2nd order harmonics (1kHz) have not been a proble either, specially since damping of these were added to the Guardian. Relevant is the damping of the ETMY modes at 1009.44 and 1009.49 Hz which have been associated to a high SNR glitch line at 2kHz.
• No lockloss after an earthquake Mag 5.8 EQ near Ragul Island, New Zealand.
• IMPORTANT: Coincidence of PyCBC? live newsnr of ~11 glitch with strong glitches on PEM channels for MAINSMON and MAG in all buildings.
  (see attached pic)
• Summary page issue: ODC Overview plots did not agree with the corresponding channels segment info --> This is now fixed and Summary Pages are being regenerated for the last year.