Seismic:
	Hugh will be doing HEPI maintenance in the LVEA during the Tuesday maintenance window.
	Jim will be running transfer functions as opportunity allows.

CDS:
	Need to work on shutter interface at End-Y.
	3IFO work in the H2 Electronics building.

VAC:
	Kyle will swap the ion pumps at HAM1 and HAM2 during the maintenance window.

3IFO:
	Work continues on IO inventory & storage tasks.
	The temp/dew point sensors are ready; connecting the 3IFO storage containers to N2 can start.   

See the attached for trends of the BRS for health assessment.  It has been down since ~22 Feb.

The first plot is the minute trend of H1:ISI-GND_BRS_ETMX_RY_INMON.  This is 100 days of just the mean and the flat lined sections are BRS in trouble areas.  The 2nd attachment is a 60 minute second trend.  This shows the healthy 9mhz signal of the BRS.

    After a bit of a struggle getting the pre-modecleaner out of its tank, we managed to
examine the mirrors of the pre-modecleaner.  Visually most looked okay, except one which
showed some evidence of a film.  It was not easy to see, nor photograph but certainly the
impression is that something is there.

    This is most likely the reason of the pre-modecleaner's demise, which may have been
the result of it having been stored with its tank lid on.







Ed, Peter

More details on the scattering Dan mentioned on Friday, with some new and re-interpreted details (the responsible motion is horizontal) that became clear after further investigation.

This last Monday, DARM spectra showed a double scattering shelf occasionally reaching 60 Hz and 120 Hz (Figure 1) and even higher.  I searched for the source of the scattering path length variation by looking for motion sensors that detected maximum motion at the times that the higher frequency scattering shelf reached its highest frequency.  The top trace of Figure 2 is a 700s time series of DARM, band passed between 90 and 145 Hz. Each of the spikes in the time series was produced when the scattering shelf reached into this band. The lower plot shows that the maxima in one of the OMC OSEM signals coincides with the spikes in the DARM plot above it. All OMC OSEMs show this correlation except the side sensor (on the short side). I found no other GS13 or OSEM channels that showed this correlation; most importantly, it was not in the GS13 signals from HAM6. Figure 3 is a zoom in to one of the clusters of scattering spikes, showing that the scattering spikes appear to occur at the steepest part of the OSEM signals (when velocity would be highest), and that the time spacing between DARM spikes agreed with the resonant frequencies of the OMCS. Beating between 2 of the suspension modes seems to cause the variation in motion.

Using the 1 um/count calibration of the OSEM OUT channels, I obtained average velocity spetra that, for some OSEMs, reached 10 um/s (Figure 4).

In order to produce a shelf out to 60 Hz, the rate of path length change for a single bounce would have to reach about 30 um/s. The OSEMs measure displacement of the top mass, M1, and the OMC hangs below it. At the resonant frequencies of this suspension, the motion of the OMC, while damped, would still be greater than the top mass. Also, the 10 um/s figure is only an average rms. Thus the OMC motion can account for the 60Hz shelf with a single reflection. 

There are two shelves in Figure 1 spaced by a factor of 2 in frequency. The spectrogram in Figure 5 shows that the frequency spacing of the two shelves is always a factor of 2. The shelf at 120 Hz in figure 1 is about an order of magnitude below the shelf at 60 Hz. If this represents a scattered beam that reflects twice instead of once, then the reflectivities at each of the two extra surfaces would have to be very high. While there may be other mechanisms to generate the double shelf, it is probably worth looking for bright beam spots on highly reflective surfaces in HAM6.

Finally, it would be nice to reduce the motion of the OMC by a factor of ten, particularly, the side to side and rolling motion perpendicular to and about the line connecting the two suspension points of M1, motion detected by the LF, RT, T2 and T3 OSEMs.

Today we have high winds again.  At 22:24 UTC I've switched the ALS arm requests to LOCKED_NO_SLOW_NO_WFS.  This means H1:ALS-REFL_CNTRL_OUT_DQ will be a measure of the arm length fluctuations (in um), contaminated by the coupling of angle to the length sensor which is due to the high transmission of the ETMs.  The locks are only lasting at most 30 seconds.  We've have both end station ISIs with 45 mHz blends along the beam direction.  

Blends along the beam direction were switched to 90 mHz at 22:37 UTC. 

At 23:23 UTC I switched the end X sensor correction to use the BRS, and turned off beam direction sensor correction in End Y. 

Sheila, Dan, Chris, Stefan

Tonight we first spent time making the Guardian automation work all the way. After making sure our ASC loops work properly, we added the OMC_LOCK Guardian to ISC_LOCK Guardian control. We had several completely hands-off relocks, taking us all the way to DC readout. Since we often broke the lock trying new things, we got some relocking statistics: from lock-break back to DC-lock is about 15min.

We notched violin modes (0th, 1st and 2nd harmonic) in DARM. This was required for driving ETMY L2, but can't hurt regular ESD operation either.

Next we tries to hand off the ETMX ESD to ETMY L2 stage. For this we copied the LLO L2 suscomp filter to our ETMY. We balanced the gain by driving a line in both ETMX ESD and ETMY L2. We did quickly had off control, but we were battling instabilities at 0.4Hz and 1.8Hz (the suspension resonances), as well as ringing up violin modes.
As a consequence we lost lock a few seconds later, before we could turn down the ESD bias.

On the next lock, we again succeeded in the hand-off, and turned the ESD off. But there was still some saturation happening, just as we started seeing the noise floor fall.

Finally, we found a gain configuration that kept the interferometer stable on ETMY (see below). However at the time the violin modes were so rung up that we had lots of extra noise due to saturation.





We had one unexplained lock-loss at UTC 2015 3/14 10:11:08.

PS: It is really nice the have 15min of thinking time between locks - without having to click any buttons...
PPS: Happy birthday, Albert Einstein!


===============================

For reference, below are the ETMY hand-off steps we used. In addition the filter FM6 (Q) in the L2 LOCK filter back of ETMY was on, as well as a gain of 20.


ezcawrite H1:SUS-ETMY_L3_ISCINF_L_TRAMP 3
ezcawrite H1:SUS-ETMX_L3_DRIVEALIGN_L2L_TRAMP 3
ezcawrite H1:SUS-ETMX_L3_DRIVEALIGN_L2P_TRAMP 3
ezcawrite H1:SUS-ETMX_L3_DRIVEALIGN_L2Y_TRAMP 3
ezcawrite H1:SUS-ETMY_L3_ISCINF_L_GAIN 0
ezcaswitch H1:SUS-ETMY_L1_LOCK_L OUTPUT OFF
ezcawrite H1:SUS-ETMY_L2_LOCK_L_GAIN 20
sleep 4
ezcawrite H1:LSC-ARM_OUTPUT_MTRX_2_1 -1

# all at once
ezcastep H1:SUS-ETMY_L3_ISCINF_L_GAIN +1.2 H1:SUS-ETMX_L3_DRIVEALIGN_L2L_GAIN +-1 H1:SUS-ETMX_L3_DRIVEALIGN_L2P_GAIN +-0.021 H1:SUS-ETMX_L3_DRIVEALIGN_L2Y_GAIN +-0.007

In our many locks and relocks tonight we have worked out the bugs in the OMC guardian's locking sequence.  This process has succeeded several times now and is integrated with the overall ISC_LOCK guardian.

The steps taken by the guardian are the following:

• Engage the OMC QPD alignment loops
• Sweep the cavity with the PZT while recording the DCPD sum (see attached figure), identify the 45MHz sideband peaks, find the carrier peak in the middle, and jump to the PZT voltage.  THIS NEVER WORKS EXACTLY, and it's not clear why.  (PZT hysteresis?)  The guess is always wrong in the same direction, so the code steps slowly downwards until it reaches a resonance.
• Turn on the OMC LSC servo
• Collect ten seconds of OMC-DCPD_SUM and LSC-DARM_IN1 data and calclate the transfer function.  Change the OMC-READOUT_SCALE factor and LSC-OMC_DC_OFFSET so that the DCPD input to the LSC matrix matches the current DARM_IN1.  (This step allows you to change power settings and the DARM offset without having to retune the scale factor and offset every time.)

The whole thing takes about two minutes.  There are ways to make it faster (Stefan suggested locking on a sideband earlier in the acquisition process and jumping to the carrier later on) and more robust (applying some more intelligent peak-finding will be necessary once we go to higher power), but for the near future this seems like a good, hands-free solution.

There's one failure mode which is likely to be encountered not infrequently: if the ETM roll mode is run up (or other modes, but that one is the most problematic) then the DCPDs will saturate and the OMC won't lock.  In this case the guardian will fail to read READY_FOR_HANDOFF and the ISC_LOCK guardian will not transition to DC readout.  If this happens you can damp the mode and then rerun the OMC guardian to get to low noise.

Robert, Dan

On some locks we've noticed very loud scattering noise, sometimes extending out to >100Hz, implying an impressive fringe velocity of tens of microns per second.  Robert pointed out to me yesterday that the OSEMs of the OMC suspension saw high amplitude motion around the time of these glitches.  The OMC SUS motion seemed to be in the vertical direction, and we guessed that the OMC ASC pitch feedback to the OMC SUS was coupling to the vertical motion of the suspension.  And, from there, some scattering path length was changing very rapidly.

Recently the OMC has been aligned using the QPD loops, which are relatively high gain (ugfs around 1Hz).  These loops drive the OMC SUS fairly hard.  Coupling to the other SUS DOFs has been a concern.

Today on our first low-noise lock we immediately noticed the scattering noise between 40 and 200Hz.  We reduced the OMC ASC gain and the noise disappeared.

The scattering noise is highly correlated with the velocity of the OMC SUS in the vertical and longitudinal directions.  In the plots attached, the top panel is a spectrogram of the whitened calibrated DARM channel.  Scattering arches are seen at 60Hz and up to 220Hz.  The bottom panel is the absolute value of the time-derivative of the OMC SUS motion, either vertical (first two plots) or longitudinal (second two plots).  The units are in velocity although I haven't gotten the calibration to make sense, and anyways we would need to calculate the motion of the bottom stage.  (These plots are reminiscient of similar work by Bas Swinkels a few years ago.)

The second plot or each pair shows 100 seconds of data, as I turned down the gain on the OMC ASC loops and the suspension was driven more and more gently.  As the velocity drops, so do the scattering glitches in DARM.

For now we'll run in a low-gain state for the OMC ASC.  After talking with Jeff, one solution might be coil balancing of the OMC SUS to decouple pitch actuation from the vertical mode.  Also, we might try some vertical and longitudinal  compensation in the OMC ASC actuation itself.  Or, we can chuck it all and use only the tip-tilts.

Sheila, Stefan, Chris

• We were having mode hopping problems this morning, which we fixed by centering on AS_C.  We've now revived the initial alignment step that aligns SRM using refl wfs and SR2 using AS_C with SRY locked.  We are using feedback only to the top stage, we feed AS_C to SR2, and SRM, with a 7.12 in the output matrix. we use a gain of 2 for the WFS loop (SRC1) with an integrator and 2 poles at 0.3 Hz (FM2,3,5) and a gain of 100 for the AS_C path (pure integrator, 70dB and our HSTS comp filter (FM2,3,4,9).  
• We have changed the PRC1 loop during DRMI so it now only feeds POPA to PRM top stage, instead of sending it to several other optics as described in alog 17136.  This allowed us to send the feedback to only the top stage of PRM, eliminating the saturation problems we were having when engaging this loop. Once we have aligned this in DRMI, in full lock we engage the loop as it was described in 17136 (except that IM4 is not driven) without problems since the error signal is already small. We also have a factor of 10 more gain in the offload path for PRM (in both DRMI and full lock) than we had before.  
• I changed the script that is called by the clear history button on the ALS screens, it now clears the history of the top stage of ETM, TMS, ITM.  This isn't working yet, but the old script wasn't working either since we moved the integrators into the suspensions.  I'll revisit that soon, for now you have clear the history in each suspension if you want to clear  the green WFS history (ISC_LOCK guardian DOWN does this for you)
• We are no longer saving alignments!  (alog 17259) Operators can skip all "save alignment" steps in their instructions
• The guardians are committed as revision 10088 and 10089
• The problems that Chris and Stefan had last night (alog 17250) were because I had moved the integrator into IM4 top stage from the ASC filter bank (alog 17244), this is now fixed by the guardian.  

J. Kissel

After we got back to low-noise RF spectrum, we noticed our wall template displaying H1:CAL-DELTAL_EXTERNAL_DQ was not showing anything. We quickly realized that the recently implemented but still uncommissioned optical gain correction factor, GAMMA was dividing the sensing term in the calibration process by 0.0. This has been happening since Tuesday (LHO aLOG 17179), but we haven't noticed because we haven't put any low-noise points on the board. After the first low-noise lock broke, I quickly added a switch to the CAL-CS library part that passes a 1.0 into the sensing normalization of the switch is OFF. 

Of course, this required a model recompile, reinstall, restart, and a DAQ restart because I added one EPICs channel. Apologies for bypassing the work permit process, and rebooting front end models on a Friday evening, but I figured having a well-calibrated DARM spectrum during low-noise operation was more important.

We're now back in low-noise, and all is well calibrated again. 

We'll commission the optical gain compensation soon...

I've committed the updated CAL_CS_MASTER.mdl library part to the userapps repo.

TJ Massinger, Ryan F.,

We created new MEDM screens for the new ASC and OMC ODC channels, and updated the screen for LSC.  These are in their appropriate common/medm/ directories.  The LSC_ODC.adl has not been committed to the SVN because the local directory is in a strange state.  Pictures attached!

We also took a first pass through setting all of the EPICs records for the LSC and ASC ODC channels.  These settings have been captured in the safe.snap files for the two models and committed to the SVN.

The SUS guardians has been revamped

This was done in order to fix a couple of outstanding usability issues with the SUS guardians, and to make things generally easier to deal with.  Here are the key changes:

complete overhaul of alignment procedure

• The OPTICALIGN OFFSET is now user ONLY for holding the ALIGNED offset value.
• We will no longer misalign the optic by writing different values into the OPTICALIGN OFFSET.
• The OFFSET in the top-stage TEST_P/Y filter banks will be used to store relative misalignment values, which will be engaged (with a ramp) to misalign the optic.

This is a fairly substantial change to procedure, but it has a couple of important benefits:

• no longer need to store and update alignment offsets in separate files
• can misalign optic by engaging just the TEST_OFFSET switches
• now have a trend-able record of the optic alignment offsets

This gives an effective "one button" misalign/align.  We also no longer need to worry about saving alignments.  w00t!

no more ALIGN_TO_PD* states

Sheila declared that the ALIGN_TO_PD1 and ALIGN_TO_PD4 states are no longer needed with the new changes.

alignment offset ramps are now reset to default values after offsets are (dis)engaged

guardian no longer touches filter gains

In general, guardian now touches less stuff.  This is important because it reduces the cross section with the ISC automation that occaissionally needs to adjust the LOCK filter module gains.  It also increases what can be monitored by the new SDF system.

INIT improvements to better determine SUS state on intialization

This will help get the suspensions to the correct state quicker on guardian restarts, with less disturbance.

new procedure to fully enable SUS

In the SAFE state, the SUS is in the following state:

• outputs of (almost) all control filter banks (LOCK, OPTICALIGN, TEST, DAMP) are DISABLED
• alignment OFFSETS, in both the OPTICALIGN and top-stage TEST filter modules, are DISABLED
• MASTERSWITCH is OFF

The full "enable" and alignment procedure is as follows:

• turn on MASTERSWITCH
• turn on DAMP outputs, which enables the damping loops (in reaction masses as well for the quads)
• enable alignment and control module outputs (LOCK, OPTICALIGN, TEST)
• engage OPTICALIGN OFFSET to set DC alignment
• (to misalign, engaged TEST_{P,Y}_OFFSETs)

Here's the new graph:

The DAMPED state now has just the DAMP outputs engaged, so just the damping loops are on.  The FULLY_ENABLED state has the remaining control outputs engaged.  The ALIGNED and MISALIGNED states have the OPTICALIGN and TEST P/Y OFFSETs enabled.

Current status

All SUS guardians were updated such that the TEST_P and TEST_Y filter modules have the same GAIN calibrations that are in the OPTICALIGN banks.  The OFFSETS in the TEST_{P,Y} modules were set such that they corresponded to the last stored "misaligned" values in the alignment snapshots.

All SUS guardian nodes were then restarted.  They all came up without issue.

Important notes

OPTICALIGN OFFSET is no longer the full story of the SUS alignment

This is probably the biggest gotcha.  We need to update the IFO_ALIGN screen to give an indication that the MISALIGNMENT (TEST) OFFSETs are enabled.  There is also no indicator on the SUS_*_OVERVIEW screens that the suspension is in a misaligned state.  Guardian should be considered the main authority for SUS alignment state now.

ALIGNMENT OFFSETS are no longer stored in files, nor are they stored in the safe.snaps

This means that after a front end reboot the stored alignment and misalignment OFFSETS will be lost.  However, they can be easily restored from the BURT snapshots.

I will put together a script that will allow us to easily restore an alignment offset to any point in past, including possibly the last alignment before a reboot.

OPTICALIGN calibrations should be set in the TEST_{P,Y}_GAINs

This is to ensure the same calibrations for the OPTICALIGN and TEST OFFSETs.  These don't usually change, so it shouldn't be an issue, but when they do need to be changed, they will need to be updated in two places

Configuration

The new code is in two new files:

• USERAPPS/sus/h1/guardian/SUS2.py
• USERAPPS/sus/h1/guardian/sustools2.py
• USERAPPS/sus/h1/guardian/SUS.py is a symbolic link to SUS2.py

The new SUS2.py holds all the new guardian logic, and the new sustools2.py is a slightly cleaned-up, guardian-ified and improved version of sustools.  SUS2.py imports sustools2.py.  The old SUS.py was renamed to SUS1.py.  Reverting to the old configuration is a simple matter of repointing the new SUS.py symlink to the old SUS1.py module.

TODO

The plan is still to overhaul the OPTICALIGN parts such that they handle all of this in one place, without needing to use these TEST modules.  This will make things even cleaner.  We will also integrate the new Sigg integrators so that we can have glitch-less offloading of integrated DC values from the ASC loops to the OPTICALIGN biases.

So, things to do:

• Update IFO_ALIGN screen to reflect ALIGNED/MISALIGNED status (maybe add guardian MINI or MICRO screens).
• Script to reset OFFSET from some date in the past.
• Update sustools to handle turning on/off the other control filter modules (DITHER, OLDAMP, etc.)
• Make sure SDF for all SUS is up-to-date for these changes.

Times in PST

08:33 Bubba to CER changing filters

08:37 Peter to H2 PSL enclosure

10:22 Corey to squeezer bay, Kyle checking vacuum gauges in LVEA

10:35 Kyle out of LVEA

11:05 Doug to Mid X

11:12 Corey out

11:41 Peter out

12:35 Corey to LVEA for a cable

12:40 Corey out

13:57 Peter and Ed to H2 PSL enclosure

15:31 Peter and Ed out

15:45 Kyle in LVEA shutting off pumps

15:52 Kyle out

Ryan F., TJ Massinger, Stefan

We edited the following models in the local copy of userapps without committing them.  We tested that all of these compiled successfully (and emailed CDS about some RCG bugs found when using GoTo and From parts in the models).  Screenshots demonstrating the changes are attached.  

We added a proper ODC channel (mostly still placeholders with no inputs or logic) for the following models to replace the current placeholders:
 h1pemey  
 h1pemex
 h1caley
 h1calex
 h1iscex
 h1iscey
  these last two require the changes to sys/common/models/ODC_MASTER_PARTS_V2.mdl
 h1alsex
 h1alsey

We also edited the h1omc model that was installed Tuesday to add checks on DCPD_A,B and PZT2_MON_AC error signals.
 h1omc
  requires changes to omc/common/models/omc.mdl

All of these models should be ready to be make-installed, restarted and committed to the SVN during the next maintenance period.

We also edited PSL_STATUS.adl locally to fix a white box (changed H1:PSL-ODC_CHANNEL_OUTPUT to H1:PSL-ODC_CHANNEL_OUTMON)

We created a new MEDM screen for ASC_ODC.adl and fixed some errors in the LSC_ODC.adl created by Duncan M.  These screens are not yet linked to any other MEDM screens.

We also committed a new safe.snap file for h1odcmaster.

We left the IFO on a DC lock last night. Attached is the spectrum. Two nights were notable:

1) The hump around 800Hz (apparently known as "twin peaks") was bigger than ever. Interestingly it was NOT there at all during earlier locks during the day. The only thing we know we did between the locks was a complete initial alignment. Also, over the period of about 1h, the hump completely disappeared.

2) The low-frequency noise (20Hz to 100Hz) is significantly less stationary now. (This did not improve over time.)