Jeff B. brought to my attention that the purge-air flow in the combined volume of HAM4, HAM5 and HAM6 seems to be fluctuating in a periodic fashion -> I investigated and found that the low pressure output pressure regulator supplying purge air to the LVEA is stuck -> As such, the output pressure of the regulator (to the LVEA) is fluctuating between the nominal 1 psig and 1/2 psig as the input to the regulator fluctuates between the nominal band of 120 psig and 80 psig -> I'll order a part and get this fixed but in the meantime, in-chamber work can continue. 

(Aidan B, David H, Thomas V, Matt H....Alastair H (remotely))

We have been trying to align the table the last few days, but ran into an issue with trying to get a good extinction of the beam reflected off the two "wavelength" branded polarisers that are after the Beckhoff controlled HWP.

First for a little bit of history. For the two table builds at LLO, the reflection off the 2nd of the polarisers after the Beckhoff controlled HWP could be minimised to a couple mW as measured by a power meter.  (in fact I think I even heard could get down to 0.2mW). However, the two tables at LLO were built up only in "phase 1" build. Thus they do not have things like the AOM installed (which will be used for intensity stabilisation).

Here at LHO we are trying to do the phase 1 and phase 2 builds at the same time to work out as many issues as we can before trying to build up the other table at LHO, and do the phase 2 builds at LHO.

When doing the alignment the first time around, we found that for ~10W (about 20%) CO2 power we couldnt get the power reflected off the polariser to be anything less than ~10mW. We tried various times to fine tune the rotational angle of the polarisers as the power reflected is very sensitive to angle. However no success. We decided to simplify the setup to have a look at what was going on.

Firstly we put another HWP right after the ouput of the laser and then we looked at the performance of the very first polariser (II-VI brand) that is right after the laser. At an angle of 60 degrees on the HWP we got maximum transmission through this first polariser, and by fine tuning the angle of the polariser, we can get an extinction ratio of around 200:1 (p to s polarisation) which is what we roughly expected for the laser output (and double checked this was the case by removing the HWP and seeing that the results for what is transmitted and refected from the polariser essentially stays the same). So we are getting what we expect from the laser.

We then experimented with what we see when we placed wavelength type polariser after the AOM (so setup is laser, HWP, polariser, AOM, polariser). In this simple setup we couldnt get the reflection off the polariser after the AOM to be at a low power level like expected (we got around 0.43W  at only 20% power level). Removing the AOM decreased the reflected power off the second polariser by around half this amount. We even tried moving the HWP to between the two polarisers and playing with it and looking at what we see, but minimum reflected power could get was still around 200mW (at 20% power setting of laser on PWM mode).

So decision was to make a real simple experiment and mimic what essentially LLO has (except for a bunch of steering mirrors between first polariser and Beckhoff controlled HWP). So we had a setup of laser, polariser, HWP (mimicking beckhoff controlled HWP), polairiser, polariser. With this setup we were able to get roughly the results see at LLO (ie a few mW of power reflected off the last of the polarisers when laser running in CW mode at full power). 

So now went back and went for broke and put everything back as should before phase 2 layout (ie AOM back in, polarisers after beckhoff controlled HWP), and after realigning/checking alignment of everything, the minimum power we could get off the reflection of the 2nd of the polarisers after the Beckhoff controlled HWP when laser is in CW mode is ~95mW AAAAArrrrrggggghhhhhhh. At a hunch I ripped the AOM out (it only transmits the beam so should not affect the alignment pulling it out), and immediately the power reflected off the second of the polarisers after the HWP went down to a few mW. 

Thus it seems the AOM is affecting the polarisation of the beam. We are going to look further into it (may be due to some kind of stress being induced to the AOM in someway), we may also look at changing the layout (move the first of the polarisers to after the AOM) to mimimise the affects of what the AOM is doing to the polarisation of the beam. The hunt goes on..................

All the BSC-ISIs foton files have been updated with the good switch output coniguration, according to the list posted in the SEI log (https://alog.ligo-la.caltech.edu/SEI/index.php?callRep=439)

I had to restart the h1guardian0 machine. Commissioners reported that the guardian IOC was still running, but the guardian processes were unresponsive and the log windows would not open. I was able to ssh into the machine, but could not run any command with the error "fork: no memory". Since I could not execute the "reboot" command, I rebooted the machine by pressing the front panel RESET button.

I am setting up sysadmin monitors on this machine to report processor space and memory usage. The machine had only been running for 7 days. Stefan reported that he was running a guardian in dry-run mode recently, other than that regular operation of guardian over the past week.

At about 16:42 UTC, I found the IRIG-B timing was off by more than 65000 on h1iopsusb123, and all user models had stopped running.  Not sure what the cause was, a minute trend of the IRIG-B time showed it went bad about 16:23 UTC.  I killed the user models (h1susitmx, h1susbs, h1susitmy), and restarted the h1iopsusb123 model.  It came back in a normal state, so I restarted the user models.  All is running OK at this time.

Jim reported some issues on ETMY HEPI yesterday https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=11618

Turns out that the position loops used were adding extra amplification at 10Hz (a 10Hz already amplified by the pier on this chamber). This was causing the HEPI to go unstable, dragging the ISI with it.

I switched to the controllers installed in FM2&FM3 (Cont_2), which are more generic, less aggressive loops. It works just fine.

ETMY chamber is used by the commissioners right now, but as soon as I have a chance I'll modified the design of the Cont_1 loops.

2014_04_29 10:06 h1susbs

2014_04_29 10:07 h1susbs

2014_04_29 10:54 h1susitmx

2014_04_29 10:55 h1susitmx

2014_04_29 11:16 h1susitmy

2014_04_29 11:29 h1susetmx

2014_04_29 11:44 h1susetmy

2014_04_29 11:57 h1susetmx

2014_04_29 11:58 h1asc

2014_04_29 12:00 h1isiitmx

2014_04_29 12:10 h1susetmx

2014_04_29 12:12 h1asc

2014_04_29 12:12 h1susetmy

2014_04_29 12:22 h1isiitmx

2014_04_29 12:26 h1isiitmx

2014_04_29 12:29 h1sustmsx

2014_04_29 12:33 h1isiitmx

2014_04_29 12:34 h1sustmsy

2014_04_29 12:35 h1isiitmx

2014_04_29 12:49 h1isiitmx

2014_04_29 12:57 h1broadcast0

2014_04_29 12:57 h1dc0

2014_04_29 12:57 h1fw0

2014_04_29 12:57 h1fw1

2014_04_29 12:57 h1nds0

2014_04_29 12:57 h1nds1

2014_04_29 13:10 h1isiitmx

2014_04_29 13:25 h1isiitmy

2014_04_29 13:34 h1iscex

2014_04_29 13:36 h1iscey

2014_04_29 13:41 h1iscey

2014_04_29 13:41 h1isietmx

2014_04_29 13:47 h1isietmy

2014_04_29 13:55 h1isibs

2014_04_29 14:44 h1iscex

2014_04_29 14:45 h1iscey

2014_04_29 15:19 h1susomc

2014_04_29 16:03 h1susitmx

2014_04_29 16:07 h1susitmy

2014_04_29 16:11 h1iscex

2014_04_29 16:12 h1susetmx

2014_04_29 16:19 h1susetmy

2014_04_29 16:25 h1susbs

2014_04_29 16:32 h1suspr3

2014_04_29 16:42 h1susmc1

2014_04_29 16:43 h1susmc3

2014_04_29 16:45 h1susprm

2014_04_29 16:51 h1susmc2

2014_04_29 16:53 h1suspr2

2014_04_29 16:57 h1sussr2

2014_04_29 16:59 h1sussr3

2014_04_29 17:01 h1sussrm

2014_04_29 17:02 h1sussrm

2014_04_29 17:04 h1broadcast0

2014_04_29 17:04 h1dc0

2014_04_29 17:04 h1fw0

2014_04_29 17:04 h1fw1

2014_04_29 17:04 h1nds0

2014_04_29 17:04 h1nds1

2014_04_29 17:10 h1sussr2

2014_04_29 17:53 h1susetmy

No unexpected restarts. A very busy maintenance day.

Kiwamu, Arnaud, Sheila

We spent this evening trying to get UIM to test mass length to length measurements.  We do this with no slow feedback to the top mass.  With optical lever damping on, we saturate the PUM at high frequencies, so it has been easier to make the measurements with OpLev damping off.  We have reasonable coherence from 5Hz down, saved as 2014-04-29_H1SUSETMX_L1_L2LPY_SwpetSine_OLDamp_Off_5Hz_to600mHz.xml

We are leaveing one measuremetn running on opsws6 with an envelope that we have tuned to get the low frequency part, saved as 2014-04-29_H1SUSETMX_L1_L2LPY_SwpetSine_OLDamp_Off_1Hz_down.xml.

We briefly tried using the UIM for feedback, with a theoretical plant inversion filter, with no obvious sucess. 

Kiwamu fixed the calibration of REFL_Y_CTRL, makiing it identical to REFL_X_CTRL. 

Sheila told me that a couple of OSEMs on the ETMY M0 stage were reading almost zero values. Since ETMY is a key for the upcoming DARM locking, I tried fixing them.

I went down to EY and spent some time trying to understand what is causing it. Finally I found out that this was due to a loose connection at a DB9 connector on a QUAD coil driver (D0902747).  Since I was standing in front of the electronics rack with a flat top screw driver in hand, I tightened every DB9 connector which was in the same rack. This should increase a chance to detect gravitational waves.

Some detailed notes

• I used D1002741-v6 for tracing the cables
• The loose cable is CAB:H1:SUS_ETMX_10
• The malfunctioned channels are M0_F1, F2, F3 and SD. They are exactly the channels that the loose cable is supposed to send to the ADC0.
• TOP coil driver S1000300.
• LED MON was very useful to determine if the signal arrive at the coil driver.

JustinG, PeterK, RickS

We went out to investigate issues with the PMC that might have caused it not to lock when the room temperature varied (Reported by Robert Schofield and others).  The first thing we noticed was that the resonance threshold upper limit was set above the unlocked state level, which seems to indicate that the loop would consider itself locked even when it was not.  We changed the upper level to 0.65 which was half of the unlocked level.  I suspect that this was the cause of the problems with the automatic locking.

We then adjusted the alignment into the PMC to minimize the reflected light level while the loop was locked.  We reduced the reflected light monitor level from about 1.3 to about 1.0.  However, we later noticed that the sum of the reflected and transmitted levels had dropped significantly.  We re-visited the alignment and it seemed to be correct, with a calculated visibility (using the RFPD DC out, [unlocked -locked]/unlocked) of 92%.  Something doesn't seem right with the PMC loop or the PMC itself.  I suspect contamination windows and/or cavity.  We measured the incident and transmitted light levels using the water-cooled power meter, 12 and 8 W respectively.  Thus only 67% transmission with 92% visibility.  

We also looked at the FSS.  We found that the beam was too high on the AOM and raised the AOM to significantly improve the diffraction efficiency.  Then, we adjusted the retro-retlecting curved mirror to bring the beam up at the EOM position to achieve a single-pass efficiency (sqrt of the overall double-pass efficiency) of 86%.  We then aligned into the Reference Cavity and measured a transmission efficiency of about 50%, consistent with earlier measurements.

We then proceeded to measure the Open-loop transfer function of the Frequency Stabilization Servo but found that it was too low, about 150 kHz, even with the gain slider all the way up at 30 dB.  The gain margin was only about 35 deg.  This after increasing the power directed to the reference cavity and the reference cavity alignment.  The phase of the FSS loop has a "bubble" centered around 400 kHz so the phase margin is about 25 deg. larger at 400 or 500 kHz than at 150 kHz.  I'm somewhat surprised the performance was acceptable at all with what must have been a sub-100-kHz UGF.  Don't have a simple idea for increasing the UGF.  We need about 10 dB more gain.  Increasing the light level incident on the PMC to 35 W, which we plan to do in June, will help.  Otherwise, we will have to increase the modulation depth or increase the gain in one of the OpAmps on the FSS board.

It appears that the Test2 input on the FSS is always enabled, even when disabled on the MEDM screen.

Notes from today's work included below for future reference.  

Notes:

April 29 2014
PeterK, Justin, Rick

Mac mini OS 10.7.2

"medm_f" is the command to get fixed font sitemap

PMC as found 
PowerRefl 1.3 W
RFPD DC -0.138 V
unlocked
PowerRefl 11.3 W
RFPD DC -1.25V
89% visibility
resonance threshold 1.346 changed to 1.000

Tweaked alignment into PMC.  Not much improvement 0.138 -> 0.130
Changed upper limit on resonance threshold from 1.0 to 0.65, half of the unlocked level

FSS
as-found locked state 0.028 mV at RFPD DC
measured power after the AOM and iris 18.5 mW
measured power after AOM and before iris 26 mW

adjusted AOM height up and measured power now 23.35 mW after AOM and iris
27.35 mW total power of all beams

double pass - started 14.3 mW...by adjusting beam upward return path increased to 20.35 mW
double-pass efficiency = 74%
 single-pass (sort double-pass) = 86%

measured power after EOM 19.9mW
by dropping EOM .5mm meas pwr now 19.45
better centered on apertures

Slow setting start point -0.2511
starting common gain 30.0 dB, fast gain 16.0 dB
FSS RFPD dc level locked 19 mV
FSS RFPD dc level unlocked 107 mV
visibility 82%

power incident on reference cavity ~14 mW
power transmitted by reference cavity ~7 mw

Measured power incident on PMC 12.3 - 12.5 W
Measured power transmitted by PMC 8 W

1.289 reflected when PMC unlocked
0.099 reflected when PMC locked

Note that the TEST2 enable does not appear to work for the FSS S/N S1107453, D040105

at 1082859581 could have been due to my kicking the suspension around

J. Kissel

We can't have a days worth of model changes, recompiles, reinstalls, restarts, and restores without at least one mystery. Today's casualty is H1SUSETMY's, M0, F1 F2 F3 SD cluster of OSEMs, which appear to be dead, reading out bit noise. I suspect this is an analog electronics failure that is merely coincident today's reboots, because the OSEMs that have failed are all on one satellite amplifer / coil driver chain. All other OSEM sensors appear fine. We'll have to check the analogue electronics in the morning. 

The timeline of the day is as follows:
15:50:11 UTC / 08:50:11 PDT Event -- DC shift in OSEM values, with some ringing appears to be indicative of a ISI trip
18:42:35 UTC / 11:42:35 PDT Signals go dead -- corresponds with h1susetmy model restart at ~11:44 pm 00:02 PDT
19:56 UTC / 12:56 PDT       Signals come back -- corresponds with h1dc0 framebuilder restart at 12:57 pm 00:02 PDT
20:47 UTC / 13:47 PDT       h1susey model restart -- note the large temporal separation between the restart and the signal death.
~21:17 UTC / 14:17 PDT      Signals die
23:19 UTC / 16:19 PDT       h1susey model restart -- note the large temporal separation between the restart and the signal death.
00:04 UTC / 17:04 PDT       h1cd0 frambuilder restart --- signals DO NOT come back
00:53 UTC / 17:53 PDT       h1susey model restart, because I've noticed the problem, found the third bit of ADCO as red, assumed it was a too-speedy "make" and "make-install" 
The last reboot did fix the ADC0 bit error, but it did not restore the OSEM values. 
             
Note I'm retrieving the model restart times from the very useful model_start.log here:
/opt/rtcds/lho/h1/data/startlog/2014/04/29/2014_04_29_model_start.log 
which is a daily log of all model restarts (a new folder and file is automatically created each day).

I was asked by Keiko and Adam from LLO to update the iscex, iscey and asc models in order to keep them identical between two sites. So I updated them under WP#4609. Here are the status:

• h1iscex: updated successfully, running fine (now at rev.7858)
• h1iscey: upadted successfully, running fine (now at rev.7858)
• h1asc: I was not able to compile. Currently it runs with the previous version of ASC_MASTER.mdl (i.e. rev.7418)

h1iscex and h1iscey got two new RFM sender blocks so that they can send LOCKIN clock signals over to the ASC model. Also they got a LOCKIN block so that they can assess the green WFS sensing matrix with the LOCKINs. I haven't updated the screens yet and therefore the LOCKINs are hidden from the point of view of users at this point. I will update the screens as well once the compilation issue in h1asc is resolved.

Prior to the compilation of h1asc, I updated the master model; common/models/ASC_MASTER.mdl which had been updated by Livingston in order to have the RFM receivers for the new LOCKINs. However I was not able to compile h1asc. It seems that there is some bugs in ASC_MASTER. So I reverted ASC_MASTER back to the previous revision. At the moment, h1asc is running with the previous version of ASC MASTER. I am checking with Keiko to make sure that the new version of ASC_MASTER is healthy.

Chris Murphy, JustinG, PeterK, RickS

We went into the LAE today for some Tues. morning maintenance on the PSL.  

Chris took the opportunity to do routine cleaning of both the Ante-room and the Laser Room.

Many user model changes were made today by SUS and SEI groups. Two DAQ restarts were performed to support these changes at 12:55 and 17:03PDT.

I created a mini CDS overview MEDM to display on the TV monitors for the operators. I regenerated the detailed CDS overview screen, it still needs some updating. I created a new MEDM called H1CDS_FE_FMDAQ_STATUS_STRINGS_CUST.adl which is launched from CDS on the sitemap (FE FiltDaq entry). It shows if individual filter modules have been loaded, if changes are pending and other possible configuration mismatches.

I hand edited the H1EDCU_GRD.ini Guardian file to "green" up the EDCU by removing systems which are not running.

My EDCU greening did not last long, around 3pm PDT the conlog was restarted but has not come back. Patrick will investigate tomorrow.

The preparation for individual logins was completed and an email sent today to encourage users to log into the control room workstations using their own accounts. Main change to the CDS was the adding of common files to the controls groups and making them group writable (was done end of last week).

Some RFM0/1 IPC mismatches were found in the H1.ipc file and were corrected by removing the incorrect entries and recompiling the models (ASC and ISC).

J. Kissel, D. Barker, J. Batch

I've finished the front-end model modifications for adding independent alignment dither paths, as per ECR E1400105. Today's focus on the BSC suspensions, i.e. the QUADs, the BSFM, and the collateral damage on the TMTS. In addition to adding the dither paths, because I was already modifying top-level, I've cleaned up the ordering of the output ports such that all HAM and BSC SUS types now spit out similar signals in the same order. This includes piping the LOCK control signal out to the top-level model, for the eventual consumption of some auxiliary calibration front end (currently still called OAF) as is already done for the HAM SUS. I've also added any missing SVN $Id$ and $HeadURL$ tags.

When finished, after noticing a peculiar error with the new end-station IPC signals, Dave and Jim reminded me that the different RFM network fabrics for the end-stations require one to add the card number to the IPC part. 
For LHO, EX = card 0, and EY = card 1. 
Last Wednesday, I had incorrectly installed all the RFM IPC parts to both end stations with cardnum=1. This resulted in the two ETMX channels having duplicate IPC numbers, and a receiving error found on the GDS_TP screen. This has now been fixed. It required clearing out all the RFM channels from ASC in the IPC file (/opt/rtcds/lho/h1/chans/ipc/H1.ipc), fixing the card number in the h1asc model, recompiling the sender (h1asc) and the two receivers (h1susetmx, h1susetmy), and a clearing of the RT NET STAT errors by hitting diag reset.

I also terminated the dither inputs to the SIXOSEM_T_STAGE_MASTER library part used in the OMCS_MASTER, which I'd forgotten to do last weekend.

I'll now begin adding this dither path to all SUS MEDM overview screens (and hopefully not uncover any bugs!).

Details:
------------
Affected models:
/opt/rtcds/userapps/release/sus/h1/models
M       h1susbs.mdl
M       h1susetmx.mdl
MM      h1susetmy.mdl
MM      h1susitmx.mdl
MM      h1susitmy.mdl
MM      h1sustmsx.mdl
 M      h1sustmsy.mdl
M       h1susomc.mdl

/opt/rtcds/userapps/release/sus/common/models/
M       BSFM_MASTER.mdl
M       TMTS_MASTER.mdl
M       QUAD_MASTER.mdl
M       OMCS_MASTER.mdl
M       SIXOSEM_F_STAGE_MASTER.mdl

Tips for Stuart:
----------------
- After an svn up of the common/models/ directory, you should only need to make changes to the top-level models.
- The TMTS and OMCS do not need any top level changes, all extra unused ports have been terminated inside the TMTS_MASTER / OMCS_MASTER block, since we know they'll never receive any dither signals.
- Pay close attention to the input and output connections at the top level, especially the lower half of them. This is the only thing you should need to change, but I've added the dither inputs and LOCK outputs in the middle of the input and output list, so most of the lower half of the connections need re-ordering.
- As mentioned above, when adding the RFM IPC to both the ASC and ETM models, be sure to call out the appropriate card number for each end station. You shouldn't need to clear out the IPC file, as long as you don't make the same card numbering error.

Mark B. and Gerardo

Yesterday (4/22/14) Gerardo and I measured the vertical mode Q of the OFIS for three different positions of the ECD block to try to get the Q in the specified range of 25-30.

The OFIS was set up on the optical bench in the H2 laser enclosure. The ECD block sits on a tray below the payload which is supported by four groups of vertically pointing screws at accessible positions around the edge of the structure. Gerardo had earlier attempted to set the ECD block at the nominal height using the spacer tool provided but found that this was too high and caused interference. He therefore lowered the block until it was just barely clear plus approximately an extra two turns of the 1/4-20 screws. This was our starting point for further adjustments.

To measure the vertical Q, we used the laser pointer and QPD from the monolithic violin mode setup and used a convenient screw on the top of the payload to partially block the beam. We displayed the "pitch" output of the QPD box on a digital oscilloscope with a 1 sec/div timebase and photographed the screen to capture the data. I read off the peak positions with GraphClick, and worked out the logarithmic decrement and Q with Mathematica.

For the initial position, the Q was 10.7. We lowered the ECD by one turn on all the screws and got Q = 18.9. We lowered the ECD another half turn and got Q = 23.3. Finally, today (4/23/14) we lowered the ECD another 3/4 turn and got 27.8, which is in spec.

Attached is a JPG of the setup, a PDF of all the screenshots, and for the fourth and final run, the Mathematica notebook, PDF thereof and the raw data.