Dave [WP#4929] new models for h1calex, h1caley. Same functionality, split code into a common library part. May install h1calcs on h1oaf0 if the specific_cpu assignments can be verified for this front end. DAQ restart is required.

Dave: Reconfigure EDCU for latest Beckhoff and resync to guardian. Restart DAQ.

Jeff K, Stuart A: possible SUS model optlev changes, DAQ restart required.

Dave: recompile h1lsc against older version of RCG to fix slow-data-channel-offset-in-daq problem which was reintroduced last week

No other work planned.

They are not 'prepared' yet but that is but a moment.  So this uses TF data from 4 Sept 2013 but with the correct Local <--> Cartesian matrices.  Additionally, these are Hugo's Generic Controllers in use already on HAMs 4 5 & 6; we'd like to use these where ever we can.  Otherwise I attach them here if you wish to look at them.  A few of the dofs have phase margins less than 30; but, our problem at EndX had only 20 degrees of margin.

I plan to 'prepare', load , and test them tomorrow morning.

9:00 Bubba to LVEA measuring cleanrooms

~10:58 Rai and Kyle to EY removing ionizer setup

12:00 Rai and Kyle back from EY

1:00 Cris and Karen to MX and MY respectively

1:45 Karen leaving MY

Alastair

The flipper mask holders are installed on the X and Y tables.  Both are cables up and working using a 'caput' command.  At the moment they won't work using the MEDM screen since this requires checking the state of the flipper (up/down) using sensors that are not yet on the table.

Final outstanding intstall work is :  X-table needs 1 flipper sensor.  Y-table needs 2 flipper sensors, FLIR camera and baffles around PDs.

The difficulties with H1 DRMI locking, and with getting H1 to full lock, prompt me to survey the top level configuration differences between H1 and L1.

Some other comparisons that should be made (not in the table) are:

• In loop LSC error signals in DRMI, locked using 3-f
• In loop WFS signals in DRMI
• ALS COMM and DIFF spectra
• Light levels on all PDs used during lock acquisition

At this point we don't know which of these differences, if any, are significant for the lock acquision. Please post comments to this entry if you have some ideas on this, or if there are other known differences that we should be looking at.

A reminder that at 2am PDT, the clocks went back one hour to 1am PST. This means the hourly autoburt wrote out two "1am" sets of data, the second one overwriting the first. This can be seen if we look at a GPS time channel in one of the snap files. There gap between the midnight entry and the "1am" entry is 7198 seconds, or 1.999 hours.

Also remember local time is now UTC - 8hr

00:10/h1nds0epics.snap:RO H1:DAQ-NDS0_GPS 1 1.098947755000000e+09

01:10/h1nds0epics.snap:RO H1:DAQ-NDS0_GPS 1 1.098954953000000e+09

02:10/h1nds0epics.snap:RO H1:DAQ-NDS0_GPS 1 1.098958553000000e+09

03:10/h1nds0epics.snap:RO H1:DAQ-NDS0_GPS 1 1.098962155000000e+09

Adjusted REFSIGNAL from -2.02V to -2.06V to bring diffracted power down from ~12% to ~10.8%.  I am hesitant to make more aggressive adjustments since last time I did, Rick was surprised that such large adjustments were required.  Further investigation?


Laser Status: 
SysStat: Warning “VP program online” is red
Output power is 29.4 W (Should be around 30 W)
FRONTEND WATCH is active
HPO WATCH is red

PMC:
It has been locked 5 days, 21 hours, 58 minutes.
Reflected power is 2.0 Watts and PowerSum = 25.4 Watts.
(Reflected Power should be <= 10% of PowerSum)

FSS:
It has been locked for 15 hour, 22 min.
Threshold on transmitted photo-detector PD = 2.20 V (should be at least 0.9V)

ISS:
The diffracted power is around 10.8% (should be 8-10%) 
Last saturation event was 1 hour, 34 minutes ago 

Morning meeting:

• 3IFO storage (moving SUS into ISI cans) at HAM 11/12 area starting 11/4 8am-noon for a week or so
• OpLev swaps for more stable units under discussion
• Richard installing power cabling everywhere
• Krishna working on ITMx seismometer Tues.
• Rai wrapping up ionizer work
• 3IFO Quad work continuing
• Hugh HEPI matrix work, pump station work Tues.

Commissioning:

• DRMI stable without arms
• gain changes in DRMI loops
• 3f REFLAIR phase investigation ongoing
• still working on clipping/PR2 input pointing
• Jeff/Betsy working on HSTS loop building

No commissioners asked for this, but I was curious so I installed Rich's sensor correction filter on the HAM6 ISI. It looks like it does good things, but I've only tried Z so far. I don't really know if there are any optics or useful oplevs on HAM6, so I'll bug commissioners about what metrics they would use at that chamber to measure performance, but the ISI's own sensors show improved performance down to 100mhz and very little re-injection below that. First attached plot is before, second is after. Comparing the upper right plot on each shows the improvement. It's interesting that RX and RY also seem to be improved.

model restarts logged for Sat 01/Nov/2014
2014_11_01 15:27 h1fw1

model restarts logged for Sun 02/Nov/2014

One unexpected restart Saturday. No restarts reported Sunday.

Rana had asked me to perform another sweep of the OMC to measure the modulation depth.  The results using a single-bounce beam from ITMY are attached; the observed modulation depths are:

Gamma1 (9MHz) = 0.191

Gamma2 (45MHz) = 0.284

This should be compared to the previous measurements from Sep 28th, and also Kiwamu's measurement of the modulation depth and the recycling gain (and subsequent measurements after an RF amp was installed).  There is probably an error of order one percent in these measurements, in particular the 9MHz sideband which is close enough to the carrier peak that it relies on the subtraction of the TEM00 lorentzian.  The results above include this subtraction, but my lorentzian fit isn't perfect, perhaps due to the very slight nonlinearity of the PZT drive.  The plot attached shows the five mode scans that were used to calculate the Gamma's, the peaks identified as the upper and lower sidebands are marked with black crosses.  The measured values for Gamma are consistent (to much better than 1%) between the upper and lower sidebands at each frequency, and from one sweep to the next, so the statistical errors are small.  The raw data are here.

(FWIW the mode-matching from ITMY is still 0.91, consistent with the previous measurement and with the predictions from beam propagation.)

Other OMC work: I connected the OMC shutter controller box above ISCT6, the input for channel 1 comes from the ASC-AS_C SUM output fro the transimpedance board, the controller output goes to the trigger on the OMC PZT driver.  The polarity of the shutter logic seems backwards, 'open' gives 0V and 'closed' is 5V, also I can't get the trigger to fire using the threshold on the PD input.  Probably there is some work to do in Beckhoff-land.

The regular ~1nm variations in ETM coating thickness cast a diffraction ring onto beam tube baffles that may produce excess noise through modulation of retro-reflected light (https://dcc.ligo.org/T1300354). We are considering making an estimate of the noise produced by this effect by shaking the beam tube at one of the baffles with large enough amplitude to produce noise at the current LLO sensitivity (here). In making this noise prediction, it is important to know if the shaking moves more than the one baffle. To answer this, I measured the relative motion and phase of every baffle in a 550m stretch of the beam tube centered on the baffle by the shaker. 

The relative motions of the neighboring baffles are shown in Figure 1. The relative motions can exceed 0.1 even for baffles a couple of hundred meters away from the shaker. The motion is also not symmetrical about the shaken baffle. I had a hard time believing this at first and returned to many of the baffle locations, remounting an accelerometer and re-starting the shaker, several times. The relative amplitudes were consistent, as were the phases, except for one early set of measurements at one location. Because the asymmetry suggests a location dependence, I think I will have to measure the motion of neighboring baffles when the experiment is done for real at LLO, a significant increase in the difficulty of the experiment. 

I spent some time working on the ISC guardians today, in the hope that we could save ourselves alot of mindless clicking in the coming week.  The users guide:

• It basically works to select CHECK_IR, then the guardian will find the IR resonance in both arms for you.  Beyond this state things are still not ready to be regularly used. 
• If the FSS drops lock, the IMC guardian will get hung up.  You can fix this by selecting LOCKED as the requested state (even though it is already selected, you have to click the button again because of a bug)
• If the DIFF beatnote is out of range and isn't coming into range, you can manually select LOCKED_W_SLOW for the X arm (that usually brings it in, but you could also try the Y arm if not).  Once DIFF is locked, you will need to manually go back to LOCKED_NO_SLOW for the manager to take over again.

Now there is a generator for states where we sweep some channel and search for the transmitted light, which is used by both COMM and DIFF for a coarse then a fine sweep.  This is slow but does work, and will be faster than doing it by hand.  After COMM finds the resonance, it is now resetting the VCO set frequency, so that when the set frequency offset is 0, the arms are on resonance.  However, there is some kind of a bug in the beckhoff that causes an error in the VCO after this.  I will look into it tomorrow, since I try not to work on beckhoff on the weekends. 

There is another bug, either in the IMC_LOCK guardian, the node manager, or the way that I am trying to use the node manager.  When the IMC goes to its fault state (which usually happens because the FSS has dropped lock) it gets stuck there and won't move on.  Dan pointed out that one difference between this and other transitions that seem to be working fine, is that the arrow goes from the fault state to INIT.  We tried having it return 'INIT' instead of return True with an edge to INIT, this didn't work either (It got to down and just didn't move on from there). 

I've added a goto state called bring_down_nicely to the DIFF guardian.  The current DIFF down state gives the suspensions a terrible kick, I think this is not necessary. 

Rana, Alexa, Sheila, Peter, Evan

Given last night's strange behavior from REFLAIR_B, we wanted to check the RF powers coming out the BBPD and going into the ISC rack.

With DRMI locked (on 1f, and then on 3f), we used the HP4395A to take an RF spectrum of the "direct" output of the REFLAIR_B diplexer board. This should be the raw RF signal out of REFLAIR_B, with 12 dB of attenuation from a coupler inside the diplexer.

The spectra (adjusted for the 12 dB coupler) are attached.

For 27 MHz, the power into the diplexer is -41 dBm. Using the diplexer schematic (D1300989), this should give -23 dBm at the diplexer's 3x output, which is well below the compression point of the amplifier (ZHL-500HLN+; 1 dB comprsesion occurs at +16 dBm). Similarly, for the 15x output we expect -13 dBm.

The analogous LLO measurement is at LLO#10494.

This is related to Hugh's log 14774. To elaborate a bit on Hugh's log, I made a measurement with Stage 1 Damped only and HPI isolated. The first plot shows the GND_T240_X ,  ST1_T240_X  and HPI L4C (out of loop witness). There was no coherence with ground below 0.1 Hz but there was significant coherence with HPI L4C. This meant that HPI was somehow introducing excess low-frequency motion.

We then did the same measurement on ETMY and saw no such excess motion. The second pdf shows the corresponding measurement. Stage 1_Y was very coherent with ground_Y. Jim mentioned he had modified the HPI controllers on ETMY as described in Hugh's log, so we decided to try the same on ETMX in X and Y.

This has made a significant difference to the low frequency performance of Stage 1 as shown in the third file. Performance below 0.1 Hz is much closer to ground motion now.

The current cdsutils installation (r361) has a new and improved NDS avg() function.  The previous version was buggy, was calculating the standard deviation incorrectly,  and had a clunky interface.  This new version fixes those issues:

fixes to standard deviation calculation

The standard deviation was previously being calculated incorrectly and the returned values were wrong (off by some unknown but kind of large factor).  The new version uses the python numpy.var() function to calculate the variance, from which the standard deviation is calculated.  It has been verified to be correct.

channel IFO prefixes no longer need to be specified

Previously, the avg() function required full channel names, with IFO prefixes.  This new version works like the ezca interface whereby the IFO prefix can be left off of the channel name.  This makes things much cleaner, and allows scripts to be portable.  E.g., instead of:

cdsutils.avg(2, IFO+':LSC-DARM_OUT')

just do:

cdsutils.avg(2, 'LSC-DARM_OUT')

new format for returned values

Probably the thing that's going to cause the most trouble is that the interface to the function has been fixed up.  Previously, the function was returning a dictionary of channel:avg key pairs.  This was very clunky to use.

The return value of the function now mirrors the input argument.  So for instance, if a single channel is requested, a single avg value is returned.  If a list of channels is requested, a list of average values is returned, in the same order as the input channel list.  So calls like:

avg = cdsutils.avg(2, 'LSC-DARM_OUT').values()[0]

can now just be:

avg = cdsutils.avg(2, 'LSC-DARM_OUT')

If the stddev option is provided, the output will be an (avg, stddev) tuple, or if multiple channels is requested, a list of such tuples, e.g.:

avg, stddev = cdsutils.avg(2, 'LSC-DARM_OUT', True)

I have fixed all calls to cdsutil.avg() that I could find in the USERAPPS/release.  I likely didn't catch everything, though, so be aware of the new interface and update your code appropriately.