Found all front-end computers needed to be booted, so restarted all the front-end computers used on the test stand.

The BSC ISIs and HEPIs (BSC 1,2,6) were restored without troubles (Burt restore at Friday 28, 23h00).

These had disconnected. I restarted and burtrestored them.

J. Kissel, A. Pele

On the Thursday of the week before last (2013-06-20), Arnaud took some measurements of the H1 SUS ETMY's damping loop, open and closed loop gain transfer functions (i.e. DAMP IN1 / DAMP IN2 = G and DAMP IN1 / DAMP EXC = G / (1+G)). The goal of these measurements was to confirm that I'm modeling the loops correctly -- because, according to the model alone, we should (a) be getting *plenty* of 0.43 [Hz] L/P damping, and (b) increasing the gain by factors of ~3 should cause the loops to go unstable. I mention factors of ~3 with regards to stability because fellow commissioners have successfully run in that configuration to get what cavity motion they need for locking the cavity (I think -- I've only heard via word-of-mouth, I haven't seen any aLOG detailing so), yet my modeling suggests that the L loop would be unstable with this gain increase, with a phase margin of less than ~15 deg.

During the measurement, the loops were in the configuration that Arnaud had put together in early May (i.e. my Level 2.0, 2013-05-01 design but with the extra 0.43, 1.0 [Hz] boosts in L, and the 0.56 [Hz] boost in P). This is the configuration that we continue to run currently (with an overall gain of 1 or ~3). 

I've since compared the 2013-06-20 data against what I had modeled, and the results are attached.

The conclusions are quite interesting.

Let's focus on pg 1, the L Open Loop Gain transfer function comparison. There are four curves on the bode plot:
(1) BLUE The open loop model of the filter scheme. This is the 2013-05-01 filter design, with the extra boosts at 0.43 and 1 [Hz] for L as modeled on 2013-06-14.
(2) GREEN The down sampling filter used to down sample from 16k to 256 [Hz] before the channel is stored in the frames. (The low pass corner in magnitude is up at ~120 [Hz], so it's not visible in the current x limits.)
(3) RED The measurements Arnuad took *without* correcting for this down-sampling filter (though multiplied by -1, because IN1 / IN2 = - G if one defines G = + P * K, i.e. the feedback minus sign is left explicit in the loop math and *not* absorbed in G, as per the convention I've used in my model).
(4) CYAN The measurements Arnaud took, divided by the known down-sampling filter.

These same curves are shown for the Pitch loop on pg 2; Pg 3 is the ratio of model / measurement for both L and P; and pgs 4 and 5 are the closed loop gain transfer functions (which don't reveal any more information than the the open loop gain transfer functions, but I show them because Arnaud took the time to measure them).

Things to notice:
(1) Up to 10 [Hz] the magnitude scale, based solely on known calibration coefficients (no fits or scaling!), is really quite close. (Pg 3 reveals that the model over-estimates the measurement by ~25%.)
(2) From 1 - 10 [Hz], the magnitude and phase in general, are dead-on. This means that the loops are in fact as border-line stable as we had modeled.
(3) The down-sampling filter explains the huge phase loss we see in the measurement. In fact, I had seen this phase loss many times before (see, e.g. pg 5 of G1201258, or pg 8 of G1300621), but only this past week surmised out what it was, found the filter deep in the guts of the RCG code, and plotted it.
(4) The discrepancy at ~30 [Hz] is the OSEM cross-coupling that's the cross-talk between the drive and response. So, it's an artifact of the measurement, and not real. (HOW CAN WE FIX THIS?)
(5) Notice that the 0.56 Hz mode doesn't line up with the model. We should measure more suspensions to see if this is true (I think it is), and then tweak the model so it better matches. Regardless, it seems there's still enough loop gain in P (i.e. the boost filter has a low enough Q), that the mode still gets damped.
(6) Most importantly -- the lowest L mode, at 0.43 Hz, for some reason, has an "inverted" resonance. Unfortunately, it's only one data point, but the coherence for that point is ~0.85, and the phase looks pretty darn smooth, so I'm pretty sure it's real.
	- Is this mode-splitting from over-damping?
	- Is it rubbing?
	- Do we see this feature in the undamped Phase 3b testing?
        - Do we see this effect in other fiber QUADs?
This (we'll, for now call it) mode-splitting results in little-to-no loop gain on that resonance, which is most likely why we're not getting nearly as much damping as the model predicts we should on this mode. In fact, looking at the manifestation of the mode in the P to P TF, there's hardly any at all -- hence the cavity's spot moving so much.

Confusingly, undamped, Phase 3b transfer functions and spectra of this SUS reveal no such feature of the 0.43 [Hz] mode, so unless something has happen to the SUS since then, we can pretty much rule out rubbing. Unfortunately, the H1 ITMY is a wire-rehang suspension, whose modes are at different frequencies (at least as different as the fiber model is to the H1 SUS ETMY's measurement), so the filters interacts with the modes differently, so we can't make a direct peaches-to-peaches comparison.

So, we've still got some work to do on the loop design. 

Action Items:
- Measure the OLG TF of H1 ETMY with high resolution around the 0.43 [Hz] mode, such that we can really resolve what's going on.
- Gather up all the current Phase 3b fiber QUAD measurements we have (i.e. H1 ETMY, L1 ITMY, L1 ITMX), see if these 0.43 and 0.56 [Hz] L/P modes are consistently lower than the model in frequency, and if so, tweak the model to better match the data.
- Get similar measurements from the L1 ITMs, to see if the same sort of mode splitting is happening.
- Get measurements of H1 ITMY, and model the loop using the wire-rehang parameter set. See if these boosts are doing any good there.
- Install Level 2.1 filters -- which are *modeled* to be much more stable, but yielding the same reduction in Q of the low-frequency modes, and remeasure the loop. 


Measurement and Analysis Details
---------
The templates for the measurements can be found here:
${SusSVN}/sus/trunk/QUAD/H1/ETMY/SAGM0/Data/
2013-06-20_0800_H1SUSETMY_M0_openloop_P_WhiteNoise.xml
2013-06-20_0900_H1SUSETMY_M0_openloop_L_WhiteNoise.xml
Note that the measurement was taken with all loops closed, such that it accurately represents the MIMO Open and Closed loop gain transfer functions. Hence, the excitation was driven through the damping loop filter bank's excitation point.

Which have been exported to the text files:
${SusSVN}/sus/trunk/QUAD/H1/ETMY/SAGM0/Data/
2013-06-20_0800_H1SUSETMY_M0_P_WhiteNoise_IN1EXC_tf.txt  # Closed Loop Gain TF
2013-06-20_0800_H1SUSETMY_M0_P_WhiteNoise_IN1IN2_tf.txt  # Open Loop Gain TF
2013-06-20_0900_H1SUSETMY_M0_L_WhiteNoise_IN1EXC_tf.txt  # Closed Loop Gain TF
2013-06-20_0900_H1SUSETMY_M0_L_WhiteNoise_IN1IN2_tf.txt  # Open Loop Gain TF
where each file's columns are 
[freq Re{L} Im{L} Re{T} Im{T} Re{V} Im{V} Re{R} Im{R} Re{P} Im{P} Re{Y} Im{Y}]
of either the IN1 / EXC (closed loop gain, G / (1+G)) or the IN1 / IN2 (open loop gain, G) transfer functions.

The model of the design is produced by
${SusSVN}/sus/trunk/QUAD/Common/FilterDesign/
design_damping_QUAD_20130501_withArnaudBoost.m

I then compared the boosted 2013-05-01 design against those measurements with the script
${SusSVN}/sus/trunk/QUAD/Common/FilterDesign/
compare_olgtf_model_vs_meas_20130501_withArnaudBoost.m

That produces the attached plots, which can also be found in
${SusSVN}/sus/trunk/QUAD/H1/ETMY/SAGM0/Results/
2013-06-20_H1SUSETMY_dampingloopcharacterization_20130501_Filters_withArnaudBoost.pdf

During this week, the locking of the H1 IMC has been taken care of by the Guardian-based autolocker developed at LLO.

At the moment, it's capable of the following functions:

• Lock the IMC (choose state LOCKED from the IMC screen)
• Unlock the IMC (any other state except MANUAL -- they are all equivalent)
• Do nothing (MANUAL state)

Although 'Guardian' may seem like an overly grandiose term for this level of functionality, it's an improvement over what we had in place before.  It runs in a centralized location (h1script0), provides a graphical interface (MEDM), and is pretty adept at locking the IMC.

The most serious limitatation is that the IMC's Guardian is intended to be a "manager", but on H1 it currently has no subordinates. No subsystem guardians (SUS, ISI, et al) exist here, yet.  So state verification is not really being done (other than the check of the IMC transmission to tell if the cavity is locked), and switches/gains/etc in the subsystems have to be manipulated directly in the up/down scripts.

What was done

1. Move the old IMC Guardian scripts into an archive directory (.../ioo/h1/scripts/imc/guardian_2013-06-20)
2. svn up the L1 scripts directory (.../ioo/l1/scripts/imc), copy over the Guardian related ones
3. Hack on the scripts to make them ignore the SUS/ISI guardians that aren't running here yet
4. Hack on the scripts to accommodate differences in the installed feedback filters (location and quantity of boosts, offloading setup, etc)
5. Start the IMC Guardian (commands: ssh h1script0; screen -RAad imcguardian; cd /opt/rtcds/userapps/release/ioo/h1/scripts/imc; ./runIMCGuardian)
6. Add a feature to toggle the feedback and kick MC2 while waiting to acquire, to prevent getting stuck on a higher order mode or between fringes.

Performance assessment

The IMC was locked 93% of the time that the refcav was locked during this week.  There were 273 lock loss events, and the median time to reacquire lock was six seconds (excluding time spent waiting for the refcav).  There were 7 events where it failed to relock within three minutes.  I have not checked out all of these, but several could be explained by (1) waiting for the ALS down script (which restores the IMC length feedback that is disabled by the CARM handoff); or (2) slow controls reboots that resulted in a misconfiguration of the MC servo board.

Attached are plots of dust counts requested from 5 PM June 27 to 5 PM June 28.

(Kiwamu, Chris, Sheila, Daniel, Stefan)

We tweaked both acoustic noise sources and feed-back scheme today.
Result: 8Hz RMS down to 0.1Hz, 9Hz RMS down to 0.01Hz.

Details:
- turned off purge air escape noise and clean room HEPA fans (improved spectrum above 3Hz up to 6kHz.
- lowered the CARM feed-back gain by 42dB (new UGF is probably around 150Hz)
- added insane boosts at low frequency to squash arm motion
- there was also a loose connection at the PFD input, which was the reason for a low beat node strengh
- realigned the beat node beam splitter, we got 200mVpkk beat note

Still to do:
- there is some clipping on the doubler path and y-arm path - so we'll have to do a realignment.
- we need to attenuated the signal power at the new IR trans LSC PD
- need to do a noise characterization of the end station electronics, in particular we want the PFD noise and the PDH dark noise
- finish setting up the IR REFL demod signal.


In other news, we worked on the IR REFL path: installed a trigger PD and power source.

I did a lot of refining of the SUS-AUX screens I created the other day in alog 6893, as well as the SITEMAP and related SUS screens:

* I created argument macro files for the new screens and adjusted the SITEMAP to use them: susauxham2_overview_macro.txt, susauxham34_overview_macro.txt, susauxham56_overview_macro.txt, susauxex_overview_macro.txt and susauxey_overview_macro.txt.

* While I was at it, I created macro files for BSTST and the IM overview: susbstst_overview_macro.txt and susimall_overview_macro.txt. (The text for BSTST that I transferred from SITEMAP lacked assignments for UTF1 etc, leading to whiteness on the screens, so I copied the ones for BS. This may well be wrong and the BSTST and QUADTST files need to be checked against the H2 circuit diagram.)

* I edited the SITEMAP, the screens created the other day, and linked screens several deep, to call linked screens via macro files: SUS_AUX_HAM2_OVERVIEW.adl, SUS_AUX_HAM34_OVERVIEW.adl, SUS_AUX_HAM56_OVERVIEW.adl, SUS_AUX_EX_OVERVIEW.adl and SUS_AUX_EY_OVERVIEW.adl, quad/SUS_AUX_QUAD_OVERVIEW.adl, bsfm/SUS_CUST_BSFM_MONITOR_OVERVIEW.adl, hxts/SUS_CUST_HXTS_MONITOR_OVERVIEW.adl, omcs/SUS_CUST_OMCS_MONITOR_OVERVIEW.adl and tmts/SUS_AUX_TMTS_OVERVIEW.adl.

Every call from the SITEMAP should now look like (viewing the .adl file in a text editor)

        name="$(USERAPPS)/sus/common/medm/SUS_AUX_EY_OVERVIEW.adl"

        args="%(read $(USERAPPS)/sus/common/medm/susauxey_overview_macro.txt),USERAPPS=$(USERAPPS),SITE=LHO,site=lho,IFO=H1,ifo=h1"

and every call from another screen should look like

        name="$(USERAPPS)/sus/common/medm/hxts/SUS_CUST_HXTS_MONITOR_OVERVIEW.adl"
        args="%(read $(USERAPPS)/sus/common/medm/susmc1_overview_macro.txt),USERAPPS=$(USERAPPS),SITE=$(SITE),site=$(site),IFO=$(IFO),ifo=$(ifo)"

* I cleaned LLO-specific and apparently unused cruft out of the individual IM macro files: susim1_overview_macro.txt, susim2_overview_macro.txt, susim3_overview_macro.txt and susim4_overview_macro.txt.

* I made generic an LLO-specific call to SUS_CUST_QUAD_OVERVIEW in SUS_AUX_QUAD_OVERVIEW.

* I added a button from bsfm/SUS_CUST_BSFM_MONITOR_OVERVIEW.adl to SUS_CUST_BSFM_OVERVIEW.adl, as for QUAD, TMTS and OMCS. I looked at doing the same for hxts/SUS_CUST_HXTS_MONITOR_OVERVIEW.adl but came up against the problem that it would have to point to different screens depending on the suspension type (HSTS/HLTS).

All the above changes were committed to the SVN. I was careful to make all new stuff generic, so if LLO svn up's the lot it _shouldn't_ break anything. However there were a few isolated LLO-specific references that I weeded out, so care will be required. Odds will be better if the LLO SITEMAP uses the idiom illustrated above.

I have enabled multicast routing in the core switch to allow multicast streams to be routed to the ops network from the auxilliary network (between VLAN 20 and 106) - this is to support the upcoming digital video system.  The Loopback0 interface has been created in the switch to act as the PIM RP[1] for the CDS network, with address 172.17.2.1/32.  Interfaces Vlan20 and Vlan106 are configured to use 'ip pim sparse-dense-mode'.  No other VLANS are currently configured to route multicast traffic.

[1] Protocol Independent Multicast Rendezvous Point

The feedforward control is used as a complement of the feedback control mainly to reduce the motion around 10Hz (created by the HEPI piers). The L4Cs installed in the HEPI boots are used to feed the stage 1 actuators.

In https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=6768, the feedforward filters were set-up using transfer functions measured while the ISI was damped.  I evaluated how the ideal feedforward filters would change if the ISI was “feedback controlled”. I compared the ideal feedforward filters obtained in the two configurations: Damped vs feedback controlled (attachment shows the feedforward filter for the X direction).
Above 1Hz (super sensor dominated by the inertial sensor), the two filters are almost identical. The ground path and the force path are modified in the same manner by the feedback control.
Regarding these results, it doesn’t seem essential to measure transfer functions with the ISI “feedback controlled” to set the feedforward controllers.

Apollo removing door bolts on HAM5/6
Greg and Apollo craning optics tables into East Bay enclosure
Michael & Pablo in H2-PSL enclosure
Kyle replacing annulus ion pump on GV1
Betsy working around ITM-X Test Stand

Two large clean rooms were turned off at the request of the HIFO crew.

HAM1,2 cleanroom and HAM3 cleanroom.

Time of occurrence ~ 14:06 local time.

The two small clean rooms in the same area are on temporary power and may be turned off for short periods ~1 or 2 hours. They are currently ON.