Moved the interface box to the Turbo pump to eliminate interferences with new equipment.  Also move a conduit that would interfere with the oplev pier. 

New fibers were run to the network switch in the vacuum rack and connected to the fibers for the corner station.  Cyrus will get the network running and connect the HEPI servo

We are tracking a network switch/fiber patch problem which has caused the DAQ data from EY to be bad from 9am onwards.

I have enabled jumbo frames in the core switch on all interfaces expected to require them in the future - this is largely to prepare for implementing the gigabit ethernet video cameras.

While I expected this to be a non-destructive change, apparently it interrupted the inter switch trunk links long enough to crash the Comtrol based systems (dust monitors and weather stations) and potentially caused the EDCU to drop channels.  Those systems have been (or are) being restarted.

In addition, I have enabled jumbo frames and loaded new IOS code on sw-msr-ops, sw-msr-server1, sw-lvea-aux0, and sw-msr-gc, but these switches have NOT been restarted for jumbo frames and the new IOS to take effect.  This will be done during the next available maintenance period.  The code version installed is 15.0.2-SE2, upgraded from 15.0.2-SE1.  15.0.2-SE2 has already been installed and tested on the (new) sw-msr-server2, and appears to be an uneventful upgrade.

(Michael R., Rick S., Oliver P.)

After turning on the high power satge, the amount of light in the FSS path was about six times higher than in the low power mode. To operate the FSS properly, the amount of light at the RF photodiode had to be attenuated. Therefore, we add an additional R=80% splitter to the beam phath. Also, the lens, focussing the beam to this diode had been exchanged: the focal length is now 100 mm instead of 50 mm, which gives more space for the beamsplitter, the diode itself, a stirring mirror in front of the diode and a beam dump, blocking the light, reflected from the chip (see the attached picture).
We were able to lock the FSS. The measured parameters are as follows:

power downstream of the Faraday isolator behind the reference cavity:  39.0 mW

DC voltage at photodiode in reflection, if locked: 0.052 V

DC voltage at photodiode in transmission, if locked: 1.119 V after optimizing lambda/4 wave plate

We adjusted the unity gain frequency using RF analyzer. The common gain has been set to 16 dB. We found the unity gain frequency at 309 kHz with 44 deg of phase margin.

If the FSS remains unlocked, the powers and voltages are:

RFPD DC 0.386 V

incident on RefCav 73 mW --> 86.5% visibility (including sidebands)

total power transmitted by RefCav: 43.5 mW

h1dc0 disappeared from medm screens running on the OPSLAN. Initially I thought it was a cds-h1fe epics gateway error and I restarted that, but it did not fix the connection. I ran a DAQ MEDM on the FELAN and verified h1dc0 was running correctly, at which point the OPSLAN MEDM came to life but showed the EDCU disconnected from 1130 channels. I logged into h1dc0 and it verified it was not connecting to 1130 channels but did not give a disconnected channel list. When this had happened before we suspected the Beckhoff OPC-IOC and its epics gateway, so I restarted the h1slow-h1fe gateway, which did not fix this. Vincent needed a DAQ restart, after the restart the EDCU was happy again. Looking at channel lists in EDCU  ini files I cannot find a single system with 1130 channels in it.

Transfer functions are running overnight on HAM2-ISI.

At 07:10 this morning the IOP model on h1seib2 (Beam Splitter Chamber) showed an IOP timing error. The IOChassis timing slave looked to be clocking correctly. A model restart did not clear the problem so I performed a full frontend-IOChassis power cycle. It was found that somehow a duplicate B2 IOP EPICS process has been incorrectly running on h1seib3 since april 11. This was presumably a cut-and-paste error when B3 was built for the first time. I power cycled h1seib3 to ensure it only runs B3 processes, which it now does. The error on B2 went away on hard power cycle, why it appeared this morning remains a mystery.

 - Tyler (Apollo), Cheryl

Panel is on the table enclosure - bellows is not installed - opening is covered with ameristat to maintain positive pressure.

[Chris W. Mark B. Arnaud P.]

Thanks to the generous help of Chris, the problem of binary I/O control has been finally solved. The routing of the monitoring signals was wired incorrectly in the model. More details in the attached screenshots.
First picture shows what part in the model has been modified, the two others show the actual change.

The model has been commited on the svn. LLO model is consistent with LHO.

WP 3852.

The following computers were renamed at EY

All corresponding IOP models were also changed. User models which run on these front end needed a minor change to the "host=" component of their CDS part. User models which were changed are: h1susetmy, h1sustmsy, h1hpietmy, h1isietmy, h1pemey, h1iscey and h1susauxey.

Instructions for changing the computer name, and changing the IOP model names are given in the LHO CDS Wiki pages

https://lhocds.ligo-wa.caltech.edu/wiki/RenamingFrontEndComputers

https://lhocds.ligo-wa.caltech.edu/wiki/RenamingFrontEndModels

The IOP models have no fast channels being acquired by the DAQ, but their slow channels minute trend data was preserved by renaming the raw minute trend files on both frame writers.

The DAQ was restarted many times during this transition. MEDM screens, alarm handler files were modified as part of this work.

After the user model restarts it was noted that h1hpietmy showed an ini file change.

This closes WP 3852

[Dick, Kiwamu]

 We took a look at the IMC demod phase shifter [1] which had been found to be out of Beckoff's control the other day last week [2]. The conclusion is that it magically recovered by itself and became under Beckoff's control again. Anyway we set the delay by the hardware switches and disabled the digital switching as this is relatively safer than setting it digitally. There should be no impact on the IMC locking.


The optimum delay setting
   The delay is set to be 14.4375 nsec (= 1/16 + 1/8 + 1/4 + 2 + 4 + 8 nsec)
 where the I signal is maximized. This corresponds to a step setting of 231=(1+2+4+32+64+128) in the digital system. Note that the IMC modulation frequency is at 24078360 Hz.

The Symptom
 The symptom we saw last week was that the delay time didn't change when we changed the digital values in the corner Beckoff. I don't know what had happened to the electronics and digital system. Somehow we were able to change the delay from the Beckoff today.

The right half of the device is not functioning
 This is not important. A sad thing we found is that the right half of the delay line device doesn't seem working for some reason. We are not going to fix this because we haven't been using it and also we are not going to use it. Dick found that the loss of the circuit heavily depends on the amount of the delay and sometime it can reduce the ~15 dBm input signal down to -20 dBm or even less at the output port. We are guessing that there is some kind of loose contact in the circuit.


[1] DCC S1103425
[2] LHO alog 6265 "IMC locked, relocking well, visibility is good, but not TRANS beam, as it is clipped by it's bellows."
 

Since the IMC test, the ISIs of the input arm were subject to payload changes and mechanical adjustments. 

Activities From Today Mostly In Order Of Occurence

Apollo working in South Bay (causing some HAM2 Dust Alarms)

Oli working at PSL

Snow Valley switching Xarm Chillers & cleaning chillers on site

ISC Cable-pulling (mainly Input)

LVEA Crane survey continues

David is re-naming computers/models/medms at EY & needed to take DAQ down as well (also went out to re-label at racks and check on HEPI Servo work)

Installing HEPI Pump Servo at EX / Replace HEPI Pump Servo Lid at EY / Run new fiber for HEPI Pump Servo at EX & EY (Filberto & Aaron)

Paradise water at 9:53am

Tyler installing a panel at IOT2L

Oplev work at BSC2 & Y-Beam Manifold (Thomas)

BSC2 SEI Front End alarmed this morning at 7:05am (will require a reboot)...but it looks like the issue was more subtle & involved (and included BSC3) (Dave B.)

MX Weather Station work (Patrick)

EY Transitioned to Laser SAFE at 12:45pm (Sheila)

PCal work in H2 PSL room (Pablo)

Mark B. and Thomas Vo

Thomas is extremely close to plugging in the ITMy OL and this is maintenance Tuesday, so I changed the h1susitmy model to conform to D1100022-v9 (OL signals at ADC0, channels 4-7 rather than ADC1, channels 0-3 as left over from H2). 

The updated model is running and has been committed to the SVN.

Jeff Kissel and Mohana Mageswaran are working on an update to D1100022, so it's not inconceivable that the mapping could change again, but it's the best bet for now. 

Daniel rebooted h1ecatey while trying to debug the problem with epics communication

Szymon and Mark B.

We extensively revised the TMTS model using first article data from Ken Mailand. The preferred model is now at

^/trunk/Common/MatlabTools/DoubleModel_Production/tmtsfa.m

In conjunction with the DTT data plotting script

^/trunk/TMTS/Common/MatlabTools/plotTMTS_dtttfs.m

it gives a respectable fit to measured data:

^/trunk/TMTS/H1/TMSY/SAGM1/Results/2013-03-14_1936_H1SUSTMSY_M1.mat
^/trunk/TMTS/H1/TMSY/SAGM1/Results/2013-03-14_1936_H1SUSTMSY_M1_ALL_TFs.pdf

The biggest mismatch is that an R (Mathematica/Matlab pitch) mode predicted for 0.6 Hz is observed at more like 0.7 Hz. Everything else is pretty much bang on.