= Ops Summary =

== Morning Meeting ==

Visitors: Stuart, Gabriele, Ken, Myron. Welcome to Tumbleweed Land.

SEI (Hugh) Things seems okay. Platform survived the weekend.
SUS (Betsy) I can't hear you. Sorry :-(
ISC *silence*
CDS (Richard) Things are somewhat stable. Loading/unloading ldas racks.
Vacuum ...
 

== Activities ==

9:58 Elli and Dave to IOT2R

*Difficulty requesting MICH_DARK_LOCKED. The beam was too low and the PD wasn't picking up all the signal. Alexa adjusted SR2 - All is well (for now)*

10:49 Mitchell to Mid X
11:54 Mitchell back
12:36 Got an automated call from Hanford Emergency System saying the alarm will go off at some point...
12:40 Elli and Dave back
13:38 Myron and Ken to Mid X
15:04 Myron and Ken back

Jodi - The big truck that supposed to come move the racks is not coming today.
 

Laser Status: 
SysStat is good
Output power is 28.7 W (should be around 30 W)
FRONTEND WATCH is RED
HPO WATCH is RED

PMC:
It has been locked 1 day, 2 hr 34 minutes (should be days/weeks)
Reflected power is 2 Watts  and PowerSum = 24.4 Watts.
(Reflected Power should be <= 10% of PowerSum)

FSS:
It has been locked for 0 h and 44 min (should be days/weeks)
Threshold on transmitted photo-detector PD = 0.70 V (should be 0.9V)

ISS:
The diffracted power is around 13.8% (should be 5-15%)
Last saturation event was 1 d 2 h and 4 minutes ago (should be days/weeks)

Added 250mL of water.

As I logged Friday (16836,) I set the minor alarm point to +- 2psi but that is just too tight for the EndY where the pressure sensor channels are the most noisy (by 4 to 10x.)  I opened the non-alarm pressure to +-3psi.  Please note if these alarms continue.  The trends suggest that still might be just a tad too close.

Attached is 5 seconds of full data where the ISC sent a whole bunch (5e5nm) of LONG output to the HEPI all at once.  The fast channels (shown on HPI ISO X) triggered the HEPI watchdog and the slow channels never see a thing.  Why would ISC do such a thing?

Patrick T., Cyrus R.

The work described under permit 5066 is complete. No issues came up.

A late entry with data:  It doesn't look like the ETMx offsets that Keita (alog 16591) implemented in an attempt to decouple the large pitch of the main chain from the reaction chain was doing much.

Attached are Pitch transfer functions of the top, middle, and lower stages of the ETMx comparing various times when the large pitch bias and the Keita offsets were on and off.  Not much change in any of the configurations in any of the 3 stages of the ETMx.  Note, according to Jeff's alog 16824, the Keita offsets were all turned off last Thur night.

After clearing all the SEI Overflows on the GDS_TP medms Friday, this morning some have and some don't report new overflows.  Where do this come from?

Okay--No Overflows reported over the weekend on:

HEPI: HAMs 2, 4 & 5, BSCs ITMY, ITMX, BS, ETMY; ISIs: HAMs 2, 4, 5, ITMY, ITMX, ETMY.

So that leaves Overflows did occur on:

HPIs HAMs 3, 6, & BSC ETMX and ISIs HAM3, HAM6, BS, & ETMX.

Okay so there is almost a complete pattern here.  The BS is the only platform that had overflows on the ISI but not on the HEPI.

So for the overflows, on the ISIs, HAM3, HAM6, ETMX and the BS have overflows on the GS13s, the L4Cs, and on the DACs.

For HEPI there are overflows on the ETMX DAC; but, strangely, while the GDS-TP Overflows (e.g.:H1:FEC-55_ACCUM_OVERFLOW) have non-zero numbers, non of the ADC or DAC accumulators show any totals on the HAM3 or HAM6 (e.g.:H1:FEC55_ADC_OVERFLOW_ACC_2_9)...

See the attached for the inconsistant circled numbers: there are overflow totals on the overflow but non on the ADCs or DAC to support where they originate.

So next, I'll try to put a reason for the Overflows: maay an earthquake or a trip (although I don't believe we had any trips.  HAM6 with the Fast Shutter may be the only platform with a valid reason for overflows.  And, why does the HAM3 and HAM6 HEPI overflows don't show from where they came.

model restarts logged for Sat 21/Feb/2015

no restarts reported

model restarts logged for Sun 22/Feb/2015

2015_02_22 03:42 h1fw0

one unexpected restart.

Dan, Sheila

OP Lev Damping on ETMs

We have turned the op lev damping for the ETMs off completely after the interferometer is locked.  This is now in the gaurdian.  The attached spectra show the witness sensors with oplev damping on (dashed lines) and off (solid lines).  We knew these loops were not good, but this clearly shows it.  The bottom right plot shows the DHARD WFS error signal with the oplev damping on and off.  

DHARD WFS

The DHARD loop, which was designed based on measurements made at a carm offset of about 50 picometers with high op lev damping gain (see alog 16501 comment) , needs to be redesigned to take into account changes in the plant on resoannce and with the op lev damping off or reduced.  The attached plots show the change in the transfer function, the first one shows the open loop gain in the situation where the loop was designed, the transfer function on resonance, and a partial measurement of the TF with oplev damping gain reduced.  You can see this loop becomes unstable, which explains why we have had to reduce the gain several times in the last few weeks.  After turning off the op lev damping, we attempted to take some measurements which could be used to design a new loop, these are shown in the last screen shot and can be found in my directory under /Alingment/DHARD_WFS_NO_OPLEV_WHITE_NOISE.xml While the cohernce is not good at some frequencies, this should be better than what we have now.  

Attachments:

1) Spectra showing that op Lev damping was imposing noise, and is now off

2) Swept sine measurements showing that DHARD PIT becomes unstable as we go on resonance and reduce Op Lev gains. 

3) swept sine measurements of DHARD Pit plants on resonance and with reduced op lev gain 

4) noise injection measurements of DHARD plant with op lev damping off.  

J. Kissel

While reducing the EPICs sampling rate, and adjusting the servo PID parameters has killed most coupling to the SEI systems at the end stations, in the DOFs that it does remain, there is still a significant amount of coherence. The table below summarizes the remaining coupling:
               Freq        Coherence
EX Z  L4Cs   0.2 - 1 [Hz]     ~0.7
      T240s  30-150 [mHz]     ~0.85
             0.2 - 1 [Hz]     ~0.7  
   
   RZ L4Cs   (none -- sensor noise limited)
      T240s  40-150 [mHz]     ~0.7

   HP L4Cs   30-180 [mHz]     ~0.85
             0.2-0.8 [Hz]     ~0.85
      T240s  (no such sensor)

EY Z  L4Cs   70-150 [mHz]     ~0.6
             0.2-0.9 [Hz]     ~0.9
      T240s  60-150 [mHz]     ~0.8
             200-450 [mHz]    ~0.9
             0.5-0.9 [Hz]     ~0.85

   HP L4Cs   20-700 [mHz]    ~0.9  
      T240s  (no such sensor)
Indeed the coupling looks strikingly like what's left over in the Beam Splitter. I wonder -- since the differential pressure is being measured by sensors right on BSC2 if the measurement of coherence is better than with the rest of the tanks in the corner. In other words, if you measure the differential pressure noise at the tank where your sensors are, you may get a better measurement of the noise coupling.

The pump pressure noise (or the ADC noise) is significantly larger in amplitude at both end stations, and it even appears as though EY isn't getting any suppression at all. Further, because the "SMOO" low-pass filter has been removed, the noise above 100 [mHz] is larger than before. Looking at the HP ASDs, you can see a clear, order of magnitude reduction in the resulting noise in the platform, but at least EY still looks largely dominated by the pump pressure noise between 0.01 and 1 [Hz]. 

Looks like there's still some commissioning to do on these end station servos. Booooo.
We'll have measure the voltage input noise on the pressure sensors like we've done with the corner station sensor, to make sure this isn't real pressure noise, and if it isn't -- this gives warrant to accelerate the development of an alternative readout system with lower noise. Further, we'll have to see why EY isn't getting any suppression at all.

Dave, Jeff, Rick, Alexa, Sheila, Elli

This morning we discovered the PSL watchdog had tripped last night aroun 9.40 UTC.  Sheila says this was not a flow error, but we don't know what caused the trip.  To recover the PSL we did the following steps:

...

-With Rick's help over the phone, we restarted PSL at 12.15 in the fiber room.  We then set about waiting an hour for the laser temperature to settle before we turned the PSL watcdogs back on.

-During this hour, we observed an oscillation build up in IMC-MC2_TRANS_SUM_OUTPUT trace.  This built up to  oscillations between 300-990 counts with a 30 sec period over the hour (see picture).  IMC_PWR_IN_OUT16 also oscillating, suggesting a problem downstream of the IMC. (We eventually fixed this by changing the H1:PSL-ISS_REFSIGNAL so that the diffracted power was around 8%.)

-We noticed BS ISI tripped at 6.41 PST and Ham3 ISI triped at 12.06 PT, so we reset these watchdogs..  Big Earthquake at 6am PST which caused the BS trip.

-At this point we turned off IMC WFS by switching H1:IMC-WFS_GAIN from 0.1 to 0, and took the IMC lock guardian from locked to down, and turned off Input 1 on IMC servo board.  We cleared the history of the IMC_ASC MC1,MC2,MC3 and PZT loops.  As it later turned out, clearing the PZT history was not helpful as clearing this hstory removed a necessary alignment offset.

-We looked at the ISS.  Diffracted pw in % ( H1:PSL-ISS_DIFFRACTION_AVG) was also spiking in a saw-toothed wave shape (see picture).  We turned off autolock and IMC input power settled down.  We reduced H1:PSL-ISS_REFSIGNAL from -2.11V to -2.07V, untill the H1:PSL-ISS_DIFFRACTION_AVG was around 8%.  Before this change the diffracted power was getting close to 0%.  This changed fixed the strange oscillations we were seeing in IMC-MC2_TRANS_SUM.

-Once the ISS was behaving again, we re-locked theIMC and turned the IMC WFS back on.  Because we had cleared the PZT history, turning on the WFS did not bring us back to full IMC power buildup.  The beams on WFS-A and WFS-B were not centered, again because the IMC PZT mirror was not correctly aligned.  We adjusted PZT H1:IMC-PZT_PIT_OFFSET ( from 2650 to 3535) and H1:IMC-PZT_YAW_OFFSET (from 5774 to 5970) to compensate for the history we cleared.   This brought the IMC-IM2_TRANS power back up to its expected value, and WFS-A and WFS_B were again centered.

...

At the end of all this, we think we have recovered the PSL and IMC alignments to where we were at the start.

Dave O, Ellie and Jeff K

We noticed this morning that the PSL laser had shut-down. A quick survey of the PSL channels showed that this occurred at 09:34:06 UTC. We phoned Rick S who called Peter K and they agreed that we should restart the laser. Then Rick S talked us through the re-start procedure in the diode room. The laser was re-started around 11.50am PST.

Ellie, Evan and Dave
It has been noticed that the H1 Inteferometer has a tendency to spatial mode-hope between TEMOO and TEMO1 modes whilst L1 does not have this tendency. We have been setting up to characterize the SRC cavity length and Gouy phase to see whether it differs from the design settings.

To do this we set-up the auxillary laser and improved the focusing of the light onto the high speed 1611 diode of ISCT6 on the OMC_REFl_Air periscope. As a first step we repeated the previous measurement describe in AlOG 16084 with considerably higher signal to noise. 

With a bright Michelson lock we observed the reflection maximum on the either side of the Michelson. By eyeballing this data we can see that these occurred at -790+/-10 MHz and 905 +/- 10 MHz. Assuming that these are difference because of an offset in lock. The Michelson Reflection Dip is peaked at 847 MHz +/- 7 MHz.
This corresponds to a Schnupp Asymetry = 8.9 cm +/- 1mm. A more rigorous analysis of this data will follow.

J. Kissel, S. Dwyer

During the earthquake we captured new safe.snaps  for the ETMs. Note that in doing so, I brought the SUSs to "safe" by hand, then requested the guardian to go to "SAFE", and vice versa brought the sus to "ALIGNED" via guardian, then restored everything that the guardian didn't touch -- all because I finally wanted to compare what my impression of what the guardian should be doing is different from what the guardian currently does after months of neglect from me, and commissioning by others. Most notably, it DOES NOT touch any part of the locking filters, and it DID turn on BOTH degrees of freedom of optical lever damping. For the record, the safe I gathered, I turned OFF ALL euler basis output switches: LOCK, DITHER, DAMP, OL DAMP, DARM DAMP, etc. Further, I've turned OFF the large offsets installed by Keita reference in LHo aLOG 16591. Those offsets, and all the expected LOCK filter banks and optical lever Pitch damping has been turned back ON. I've committed the new safe.snap the the userapps repo.

Currently, we want optical lever damping to be either under human control or ISC guardian control, so we have commented out the lines in the INIT and ENGAGE_DAMPING states with call the function susobj.olDampOutputSwitchWrite to turn the levers ON. I've commited SUS.py to the userapps repo.

The attached PDFs show the resistance measurements for all RHs and the relative resistance vs time for the RHs as 1W is applied to each segment. All segments are operating within nominal parameters.

The resistances for the segments are: