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.

[Stefan, Chris, Kiwamu]

We spent some time today at ISCT1 to locate the forest-type noise at around 1 kHz which we saw in the ALS CARM signal (see alog 6900) and also did some hardware works.

We did find a couple of suspicious optics on the table although we are still studying how they pollute the ALS CARM signal. We have stick foam in the mount of every reflective optic on the table to help their mechanical damping ability. The work continues.

Noise hunting at ISCT1

To do noise hunting on ISCT1 we did a speaker technique --- we hooked up a small speaker at the output of the common mode servo while keeping the green beatnote within the PLL's readout range by ezcaservo acting on the ALS_COMM VCO. The ALS CARM noise sounded mostly high frequency-ish although we didn't confirm how exactly high the frequency was. Then we bought the speaker close to every optic to see if they resonate due to the acoustic (positive) feedback at exactly the same frequency as that of the ALS CARM noise. We found a couple of optics which do resonate with the CARM sound. They are :

• ALS-M9
• ALS-M10
• ALS-BS5
• ALS-BS3

We are suspicious about these optics. They may be the ones introducing the forest noise at around 1 kHz. We have stick foam in the mount of every reflective optic to damp unwanted mechanical vibration. We will take another noise spectrum tomorrow to see how this improves it.

SHG mystery

There has been a mystery that somehow the SHG efficiency dropped by  a factor of 4 or so at some point (approximately from 0.5 mW to 0.1 mW level) and it didn't come back to the high value. As a part of the ISCT1 works we inspected the doubling oven to see if there is an obvious clipping or something stupid. However we didn't find a thing. We did the following things:

• A knife edge measurement for measuring the beam sptial jitter of the frequency-doubled PSL light
  • We placed a knife-edge type object to partially block the beam and placed a PD in the downstream. We didn't see forest type structure around 1 kHz. Though it is possible that the electronics noise was so high that it covered possible noises around this region.
• Alignment of the SHG green power monitor PD
• Placement of a razer blade to dump a stray light
• Re-alignment of the SHG oven to maximize the power
  • This didn't help increasing the SHG power.
• Re-adjustment of the oven temperature set point.
  • We ended up a usual set point of 35 deg. No improvements in the SHG power.

After all these works we measured the SHG power again and it was measured to be 0.140 uW which is still low compared with the past. It is still unclear what happened and we are not quite sure how this can be related to the ALS CARM noise.

REFL alignment

To evaluate the residual noise in the PSL frequency we needed a length sensor of the Y arm, namely the interferometer reflection (REFL) RFPD. We started rearranging the optics to guide the REFL beam to the RFPD. The work is ongoing. Currently the REFL beam is dumped. To prevent a damage on the RFPD due to an accidental power increment we need the trigger function of the mechanical shutter working.

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

Attached are plots of dust counts requested from 5 PM June 25 to 5 PM June 26.

Attached are plots of dust counts requested from 5 PM June 24 to 5 PM June 25.