We have had SDF examples of a setting change which is smaller than the displayed resolution and so hidden by rounding. For example, I have changed a gain setting from its safe.snap value of 1.0 to 0.9999999999999998 and the SDF difference table shows both values being rounded to 1.000000. To get the actual value to 15 decimal places, use caget with the "-e 15" argument (without this argument it rounds to 1.0)

caget H1:PEM-MY_CHAN_17_GAIN
H1:PEM-MY_CHAN_17_GAIN         1
caget -e 15 H1:PEM-MY_CHAN_17_GAIN
H1:PEM-MY_CHAN_17_GAIN         9.999999999999998e-01
 

The snapshot of the table shows the two values are apparently the same when rounded to 6 decimal places.

6:45 Jeff - LVEA West Bay SUS Storage, LVEA East/West Bay Laser Safe
7:15 Cris – LVEA in
7:26 Mitch – LVEA in
8:12 Andres – LVEA West Bay w/Jeff
8:35 Mitch – LVEA out
8:45 Kyle, Gerardo – LVEA N. Crane
9:15 Filberto – To End X 
9:20 Kyle, Gerardo – LVEA out
9:30 Doug, Jason – To both ends
9:39 Christina – To both Mids for storage
9:57 Joe – End X
10:01 Corey – To End Y
10:14 David, Jeff – ETMX, TMSX, ETMY, TMSY brought down to Safe for restart
10:21 Truck in to take water samples
10:27 Cris – End X
10:29 Doug, Jason back from ends, to LVEA
10:45 Water delivery
11:00 Jeff, Andres – Out of LVEA, back to Full Laser Hazard
11:03 Doug, Jason out of LVEA
11:05 Kyle, Gerardo – Out of LVEA, they left a cart on next to BSC7
11:17 Sudarshan, Darkhan – To Ends to set up Pcal Lasers
11:39 Corey – Back from Ends
13:23 Kyle – Into LVEA to turn on power supply
13:52 Sudarshan, Darkhan - Done at Ends

J. Kissel, K. Izumi, A. Staley, S. Dwyer

ETMX, ETMY, and HAMs 2 and 3 were involved in maintenance day, and recovery was little-to-no different than any other Tuesday. Chasing alignment in the IMC and ARMs have been the most time consuming parts, though my impression is that it has been a little bit shorter / better today and the SUS are not nearly as far off as they have been. Indeed, in order to hard-reboot the SEI HAM23 front end and IO chassis, we needed to take down the IMC, all its associated suspensions (and the IM and PR suspensions), and the HAM 2-3 ISIs and HEPIs -- and this DID NOT shake the MC REFL path enough to cause any misalignment in pitch as we've seen in the past (see Integration Issue 854. Rather than going through my usual detail play-by-play, I've decided that its more productive to list what we should change as a result of today's experiences in order to keep getting better at the recovery.

Lessons (at least *I*) learned from today, in no particular order:
- We need to have guardian transition the BSC ISI Stage 2 Gains from HI to LO when a SEI manager requests to go from FULLY_ISOLATED to OFFLINE for ALL BSCs, because requesting to go from WATCHDOG TRIPPED (afer computer reboot) to OFFLINE to FULLY_ISOLATED after does *not* transition the gains to LO before getting started.
- We need to have the HAM ISI guardians *ensure* the GS13 gains are HI.
- We need to have an IMC "down" state that is actually DOWN, (or perhaps call it "OFFLINE") -- specifically the IMC WFS are turned off so no angular control is fed to the MC suspensions, and (less importantly) no longitudinal control is fed to MC2.
- The new(ish) IMC ASC DOF4 / MC WFS center servo really can pull the MC REFL pointing off into the weeds, so these should be the first thing turned off when ramping down the IMC.
- The transition from ISOLATED to OFFLINE on the HAM's watchdog trips the ISI halfway through the turn off process more often than not, and its likely because the GS13 gains remain in high-gain mode indefinitely.
- We need a guardian to manage the HSSS (today it was the IMs, but another day it was the RMs, etc.).
- We need to calculated / measure / install / save alignment offset calibrations for the HSSS. 
- We need a standardized, well-ordered check-list procedure for taking chambers / parts of the offline -- and then bringing them BACK online.
- We need to either resurrect / commission / trust the SUS DRIFT_MONITOR, or find another tool that we can quickly assess how all SUS alignments have changed from prior to the start of a maintenance day to after finishing.
- We need a tool that takes the output of the above (i.e. the assessment of the alignment), and *fixes* any SUS that are out of alignment.
- When the global "initial" alignment changes -- even by a few microradians here or there -- the optical gain of the IFO changes, which means we need to re-adjust ISC parameters.
- We need to include turning ON and OFF the ESD Bias into the SUS ETM guardians, such that it is ON in every state but SAFE. Further, we should pick a standard location to turn ON and OFF the ESD BIAS path.

We're not sure if we're *fully* recovered at this point, but we have gotten as far as a short DRMI locks with ARMs off-resonance, and we push onward.

Regarding the Guardian Logs: 
SEI_ETMX Manager Guardian was requested to go to OFFLINE from FULLY_ISOLATED between
2015-01-20 18:15:24.753 UTC
2015-01-20 18:16:43.581 UTC 

Rana, JeffK, Kiwamu,

We did some maintenance items on IMC ASC. The major activities are:

• We had a difficulty in restoring the IMC alignment back as we ran the offloading script when the HEPIs were down and therefore we screwed up the alignment.
  • Interestingly, restoring the suspensions using the witness sensors as references did not work at all. Simply burt-restoring the suspensions and ASCIMC frontends brought it back to a good lock-able alignment.
  • After the recovery, we ran the offloading script again and so all the MC suspensions now should be in good alignment.
• We set a limiter in each loop with a hope that this is going to reduce a risk of tripping the suspensions (alog 16138, 16128) . Here are the counts we set for the limiters:
  • DOF_1_P(Y)_LIMIT = 125
  • DOF_2_P(Y)_LIMIT = 125
  • DOF_3_P(Y)_LIMIT = 250
  • DOF_4_P(Y)_LIMIT = 3000
  • These values are derived such that they are roughly the same as their 5 sigma deviations in 100 days trend except for the DOF4 loop which had hit the new limiter once in this evening. So we set the DPF4 to a high value.
• We disabled the 2nd whitening stage in MC2_TRANS QPD because the signals were saturating most of the time when IMC was not locking.
  • Therefore the MC2_TRANS QPD now has one whitening filter.
• We cleaned up the control filters and installed a new low-pass in every DOF. Rana will report some more details about this.

Also, tomorrow or sometime this week, we might insert a lens in the REFL gigE path as the REFL beam now is a bit too big to be able to cover the spatial higher order modes.

J. Kissel, J. Warner, D. Barker, E. Merilh, TJ Shaffer

The one final quiver in our arrow against the sharp HAM3 0.6 [Hz] resonant feature was a computer (as suggested e.g. here), so we did so this morning. Sadly, it did not cure the problem. For now, we continue on, running in the configuration defined by Seb last week, see LHO aLOG 16100, in which the RY blend filters at a higher blend configuration, which is the only thing we can find that seems to help (see LHO aLOG 16001). This has now officially become a low-priority until it begins to quantifiably impact IFO performance.

A Recap of all of the things we've tried that DIDN'T make the feature go away:
- Restarting the front-end process LHO aLOG 15759

- Full power-down of Front-end and I/O Chassis (This aLOG)

- Coil Driver Swap LHO aLOG 16071, LHO aLOG 16061, LHO aLOG 15981

- Changing Suspension Damping LHO aLOG 16013, LHO aLOG 16001

- Changing Isolation Loops LHO aLOG 16001

- Location of Sensor Correction; ISI vs HPI LHO aLOG 15941. LHO aLOG 15933

- Changing from STS2 B to A; In analog LHO aLOG 15811, In digital LHO aLOG 15927, LHO aLOG 15894

- Checking between ADC and sensor correction bank LHO aLOG 15783

- Turning OFF CPS satellite amplifiers, checking jumper settings (oscillators, jumpers, etc.) LHO aLOG 15751

- Adding a large mechanical offset to relieve supposed mechanical rubbing LHO aLOG 15751

- Waiting LHO aLOG 15565

Sudarshan, Darkhan

Pcal Lasers at ENDX and ENDY are switched on but blocked at the transmitter module so that the light does not get into the test mass. These lasers will remain on until we report the change of status.

Andres R., & Jeff B.

   We craned the 3IFO Beam-Splitter storage container and the four (4) Quad Lower Storage containers (for Q6, Q7, Q8, & Q9) over the H1 Input arm and placed them into their final long-term storage positions. These containers are ready to be connected to the N2 system.  

Bubba G., Andres R., Mitch R., Jeff B.

   This morning Mitch and Jeff finished loading the Elliptical Baffles into HAM ISI Storage Container #2. Jeff added a 4" witness wafer. After securing the top on the container it was craned over the H2 input arm and placed into its final lone-term storage position. 

   We next craned the 3IFO BSC #4 container into its final long-term storage position. 

   This container was the last of the suspensions long-term storage containers to be filled and stowed. The cleanroom and dust monitor (#10) supporting this effort have been powered down.    

Pulled ETMX photodiode amplifier chassis from EX. Keita reported voltage outputs seemed to be reversed (negative output). Found the wiring for the outputs of the amplifier box wired wrong. Corrected wiring and placed unit back in rack. Patrick had to restart the Beckhoff computer for EX.

D1301017 SN S1400075

Kyle, Gerardo 

Craned pump cart out of Beer Garden with West crane -> Pump cart left running (near BSC7, west side of XBM) 

Filiberto, Patrick

Filiberto told me that the Beckhoff wasn't running after he took out a chassis at end X to switch some wires. I took the easy approach and just restarted the computer. I burtrestored the channels back to 8:10 this morning.

The XEND has been under vacuum now for 9 days since the last test mass adjustment. Plot attached.

model restarts logged for Mon 19/Jan/2015
2015_01_19 10:40 h1fw0
2015_01_19 12:07 h1fw0
2015_01_19 13:46 h1fw0
2015_01_19 15:37 h1fw0
2015_01_19 15:41 h1fw0
2015_01_19 16:06 h1fw0
2015_01_19 23:06 h1fw0

all unexpected restarts. Conlog frequently changing channels report attached.

[Koji Dan]

Summary

The estimated displacement noise of the OMC cavity due to the actuator noise is shown in Attachment 1

• From 0.3Hz to 1Hz, and from 30Hz to 100Hz, the HV PZT noise is likely to limit the OMC cavity length noise.
• Above 20kHz, the LV PZT noise is likely to limit the OMC cavity length noise. Particularly, the driver noise is exciting the OMC PZT prism parasitic resonance at ~10kHz.
• In other frequency, it is hard to declare anything definitive as the PZT noise measuements were dominated by readout noises.

Motivation

There was a suspicion that the OMC PZT driver noise was limiting the OMC cavity length noise. (LHO ALOG 16089). In the previous measurement, the output monitor ports for the HV and LV PZT drive were used. However, it was highly likely that the readout noise levels of these monitor ports are not low enough to measure quiscent noise levels of the PZT drivers. Therefore we wanted to try  direct measurements of the LV and HV PZT driver noises at the output of the PZT drivers.

Method

First of all, the HV power supply of the OMC PZT driver was turned down from 100V to 10V in oder to insure our safety. Of couse, this is not an ideal condition in terms of the proper noise measurement. However this should not be a problem, in principle, as the noise of the final HV stage should be limited by the OP27 at the input stage of this section. (The HV amp section of this board has cascaded amps in a single feedback circuit.)

A DB25 breakout board was inserted between the driver rack unit and the output cable to the vacuum feedthrough.

Pomona grabber clips were attached at the pins across each PZT electrodes. The voltage was fed to an AC coupled SR560 with a gain of 100 and HPF with fc at 3Hz (6dB/Oct).

After the measurement, the breakout board was removed, the cable was restored, and the HV power supply was reverted from 10V to 100V.

HV driver results

Here the result includes the explanation including the measurement of the monitor outputs.

1. Evaluation of  the AC/DC mon outputs (Attachment 2)

The raw output noise levels of the AC/DC monitor were compared with the readout circuit noise model by LISO. Basically this plot indicates that the outputs are limited by the noise of the readout circuit above 100Hz. Below 100Hz, it looks the measure noise levels are above the modeled noise levels. The difference is too small to declare the measure noise level is the true indication of the PZT noise.

2. Direct measurement (Attachment 3)

The noise levels across the HV PZT (green) was shown in the figure. Here AC/DC Mon measured voltage noise levels were converted to the equvalent output voltage for comparison.

The noise level of this measurement (indicated by a dark green dotted curve) was 4nV/rtHz down to 10Hz, which was as indicated in the SR560 spec. So this noise level is quite reliable. We can declare that the measurement below 100Hz indicates the actual voltage noise across the PZT. Otherwise, the minumum of all three measurement at each frequency above 100Hz should be taken as an upper limit.

The black curve in the plot is the modeled noise by LISO. The measued noise was consistently higher than the model. The reason of the descripancy is not known.

In the first plot, the noise level from the direct measurement was plotted below 100Hz after converting it to the displacement of the cavity.

LV driver results

Here the result includes the explanation including the measurement of the monitor outputs.

1. Evaluation of  the AC/DC mon outputs (Attachment 4)

The raw output noise levels of the AC/DC monitor were compared with the readout circuit noise model by LISO. The circuit noise dominates the outputs except for the AC Mon between 2kHz and 20lHz.

2. Direct measurement (Attachment 5)

The direct measurement indicates better noise level than the result of the AC monitor in all frequency. The direct measurement has clear gap from the measurement noise level below 100Hz and above 2kHz. So the measurement is reliable in these bands, and otherwise the level is an upper limit.

The black curve in the plot is the modeled noise by LISO. The measued noise was consistently higher than the model. The reason of the descripancy is not known. 20KHz.

In the first plot, the noise level from the direct measurement was plotted below 100Hz after converting it to the displacement of the cavity.

We are tracking the ADC errors which are being seen on the STATE_WORD for the IOP models. These are a feature RCG2.9 They are raised very infrequently, work to remove them is ongoing.

I have cleared the errors by pressing the DIAG RESET buttons on the IOP models. Here is the maximum ADC0 hold time for the models which were showing the error:

h1iopsusb123: adcHoldTimeEverMax=23, adcHoldTimeEverMaxWhen=1105450127 (Jan 16 2015 13:28:31 UTC)

h1iopsush34: adcHoldTimeEverMax=25, adcHoldTimeEverMaxWhen=1105533748 (Jan 17 2015 12:42:12 UTC)

h1iopsush56: adcHoldTimeEverMax=24, adcHoldTimeEverMaxWhen=1105583419 (Jan 18 2015 02:30:03 UTC)

h1iopsusey: adcHoldTimeEverMax=21, adcHoldTimeEverMaxWhen=1105219714 (Jan 13 2015 21:28:18 UTC)

h1iopslc0: adcHoldTimeEverMax=22, adcHoldTimeEverMaxWhen=1105241179 (Jan 14 2015 03:26:03 UTC)

We have had several incidents where MC1+MC3 trip, and sometimes also cause HAM2 ISI to trip.  Kiwamu found that there were large signals coming through DOF4 (16128), although there was some other underlying problem which was causing MC2 to get large length signals. 

We Had DOF 4 off for most of the day saturday, once we found and fixed the PSL noise eater oscillation we turned it back on.  This morning we dropped the mode cleaner lock when we were attempting to lock the X arm in IR, which also tripped MC1, MC3, and HAM2 ISI (this lockloss is the kind of thing that is expected to happen once in a while, and should not cause a cascade of trips).  We have again held the offsets on DOF 4,  because somehow this loop makes the sysem more fragile.  Since holding the outputs we have had several mode cleaner lock losses without any trips.