Activity Log: All Times in UTC (PT)

15:55 (07:55) Jeff B. – In the LVEA to take 3IFO storage temp/humidity data
16:00 (08:00) Peter – Into the PSL for alignment work (WP #5626)
16:08 (08:08) Take over from TJ
16:15 (08:15) Gerardo – Going to End-Y to pull high voltage cable for Ion pump at Y2-8
16:20 (08:20) Lockloss – Jeff K. running charge measurements at End-X
16:21 (08:21) Jeff K – Charge measurements on ETM-X
16:24 (08:24) Filiberto – Going to End-Y for cabling work (WP #5630)
16:26 (08:26) Bubba – Going down Y-Arm to survey for rock delivery
16:50 (08:50) John & Nutsinee – Going to TCS-X table to check view ports
16:50 (08:50) American Rock – Rock delivery along Y-Arm
16:55 (08:55) Joe – Going into the LVEA 
16:58 (08:58) Patrick – Starting on software side of WP #5630
17:00 (09:00) Jodi & Mitch – Going to End-Y to start garb room change (WP #5628)
17:08 (09:08) Bubba & Betsy – Going into LVEA to move Quad boxes – Using crane
17:18 (09:18) N2 delivery to End-X
18:35 (10:35) Filiberto – Finished at End-Y – Going to End-X (WP #5630)
18:41 (10:41) Joe – Going into LVEA to unplug battery chargers
18:42 (10:42) John & Nutsinee – Out of the LVEA
18:45 (10:45) Jeff K. – Going to End-Y to reset railed ESD
18:50 (10:50) Joe – Going to End-Y to check batteries
19:10 (11:10) Nutsinee – Going into the LVEA to work on HWS alignment
19:12 (11:12) Gerardo & Kyle – Back from X-Arm
19:15 (11:15) Contractor on site to meet with Bubba
19:24 (11:24) Richard and Ken out to End-X to check on some ION pump controls 
19:28 (11:28) Joe is back from End-Y
19:43 (11:43) Dave & Patrick – adding FMCS temperature channels (WP 35631)
20:05 (12:05) Locked IMC at the request and approval of Kissel and Landry.
20:07 (12:07) Kyle and Gerardo back from End-X. He says Filiberto is still there, though.
20:28 (12:28) Tried relocking – Found initial alignment off
20:40 (12:40) Redo initial alignment
21:34 (13:34) FD on site
21:53 (13:53) Kyle & Gerardo – Going to X2-8
22:27 (14:27) John & Bubba – Going to Mid-X 
22:37 (14:37) Kyle & Gerardo – Back from X-Arm
22:50 (14:50) Start relocking
23:49 (15:49) Locked at NOMINAL_LOW_NOISE
23:50 (15:50) In commissioning mode so Kissel can run measurements
00:07 (16:07) Turn over to Travis	



End of Shift Summary:

Title: 12/01/2015, Day Shift 16:00 – 00:00 (08:00 – 16:00) All times in UTC (PT)

Support: Kiwamu
 
Incoming Operator: Travis

Shift Detail Summary: 16:00 (08:00) Start Tuesday maintenance window.
After maintenance window tried to relock. Green alignment bad. Realigned green and tried relocking. Found BS alignment was off. Did full initial alignment and tried to relock. Had a problem with OMC not finding carrier. Kiwamu found lower limit of carrier detection was too tight. He changed it in Guardian from 10% to 25% (which matches the upper limit). Continued with relocking and reached NOMINAL_LOW_NOISE. IFO is in observing mode while Kissel runs measurements. 	   

Today, Kissel moved the 9 Beckhoff SDF medm modules to the main SDF Overview screen.  Now all SDF monitors are in one place, however the 9 Beckhoff ones are not yet tied to the OBSERVE bit.  He also cleaned up the sitemap by removing a stale SDF AUTO screen and the now old Beckhoff SDF screen.  He has committed the new screen to SVN.

With the IFO in Low Noise Lock, we also cleared a few of the Beckhoff SDF red errors via accepting them to the OBSERVE.snap file.  The ones cleared have been hanging around for a while now.

I got the green beam through both irises and fairly centered on every optic in the path. Any other beam that follows the green should travel parallel to the surface of the table. This alignment was done to get ready for the PBS installation next week. I didn't bother to look for the return sled beam.

John, Richard, Nutsinee

Today's plan was to go out to TCSX table, take out the old IR sensor, and replace it with the new one (+VP inspection). John wanted to make sure that the sensor actually does what it was designed to do before we unwrap the light pipe and put it in so we did some tests. The comparator box was thought to be calibrated to trip at ~45 degree C. However, I forgot to write down how I did it so the number was very shady... We waved a small soldering iron in front of it, starting at low temperature (~150 deg F). The box would trip when the soldering iron was waved at half a centimeter away from the sensor. Keep in mind that the sensor is mounted at ~2.5 inches away from the center of the viewport with a small angle (the sensor is looking straight down while the optical window is about 0.6 cm deep under the viewport cover. So, the sensor must be able to trip when seeing a heat source at 2.5" away with ~22 deg viewing angle. We did a quick test by waving the soldering iron in front of the sensor with several temperature settings at several distances (At this point the potentiometer was about a quarter turn away from the room temperature tripping point. It's a 10-turn pot!). 800 deg F setting tripped the box at ~3" away, 600 deg F and 500 deg F tripped the box when waved at ~2" away. But these temperatures are impractical settings. At 800 deg F, 3" away we were able to make the box trip when placed the soldering iron rounghly 1cm above the sensor's viewing axis. This gives as a viewing angle of ~8deg, about a factor of 3 less than what's required. We did the same test with the sensor that was mounted on the TCSY viewport. The results were similar (400F, 500F soldering iron didn't trip the sensor when places at the center of the viewport but tripped the sensor when moved to the edge of the viewport. 600F at the center of the viewport did trip the sensor.)

To confirm the temperature of the soldering iron we used to do this test, we used Richard's FLIR camera and a thermocouple. Turns out the actual temperature of a certain spot on the soldering iron we pointed the IR sensor to was lower than the display. The thermocouple measured 304 F when display reads 350F, 630 F when reads 700F, and 750F when reads 850F.

Conclusion: The sensor unit isn't doing what's it supposed to do and we should rethink about installing them without an improvement to the comparator box circuit. Note that we were only using half a turn out of 10 turns available on the pot to set up this test. There's no way to fine tune this thing to where we want it to trip!

FMCS EPICS channels added

WP5631. John, Bubba, Patrick, Dave

The FMCS to EPICS system was modified to add the corner station control average temperature channel. Both the raw channel (in degF) and the degC channels were added to the IOC. The new channel names are:

H0:FMC-LVEA_CONTROL_AVTEMP_DEGF

H0:FMC-LVEA_CONTROL_AVTEMP_DEGC

These channels were added to the DAQ for trending by modifying H0EDCU_FMCS.ini

Beckhoff Vacuum Gauge channels added to EX and EY.

Patrick, Dave:

Please see Patrick's alog for full details. After the Beckhoff changes were made, the ini files were generated and copied into the DAQ chans area.

DAQ restart

Jim, Dave:

To apply the Beckhoff and FMCS changes the daq was restarted at 12:32PST. This was a very messy start and took about 25 minutes to get the DAQ back. The main issue was the monit system on h1dc0 was trying too rapidy to start the data concentrator, resulting in duplicate ini and par files in the running configuration directory. In the end we started the data concentrator manually to get the system running. We will investigate the monit settings offline.

DIAG_MAIN guardian has code change, found error and fixed it

Jeff, Dave

After the long h1nds0 downtime, Jeff was getting the guardian nodes which use NDS back by reloading them. The DIAG_MAIN node would not run, giving an error saying float and int datatypes cannot be bitwise-anded. I found the error in DIAG_MAIN.py and fixed it by casting the ezca to an INT before bitwise AND. We tested the new code by stopping and restarting the CW hw-inj. The operator saw the message on Guardian MEDM and the verbal system announced the error every second.

h1lsc stuck testpoint cleared

Dave:

we had a stuck testpoint on h1lsc for some while, I cleared them.

Test change of filter module on h1pemmx

Dave:

To test the robot updates of filter files to daqsvn, I made a blank-line change to H1PEMMX.txt and loaded it on the front end.

An unnecessary trip of the ISI occurs everytime the complete platform is deisolated and then reisolated.

The model code keeps the T240 Saturations out of the watchdog bank for tripping the ISI when ever all the isolation gains are zero.  But if the T240s are riled up the Saturations still accumulate.  As soon as the T240 Monitor has alerted the Guardian that the T240 has settled and the Guardian then starts Isolating, the watchdog trips because the T240 saturations are too many.  This only trips the ISI and so the T240 does not get upset again, and after the operator has untripped the watchdog (clearing the saturations,) the ISI isolates fine.

It seems we missed this loophole, if the HEPI does not trip, the T240s often don't get too upset so it isn't a problem.  Otherwise, usually something is happening, EQ, platform restart, etc, and the operator (Jim & Me too) just untrip and chalk it up to whatever.

This should be fixed and I'm sure Jamie/Hugo will have some ideas but I suggest something like adding lines:

reset (push) H1:ISI-{platform}_SATCLEAR

wait 60+ seconds

after line 51 in .../guardian/isiguardianlib/isolation/states.py

ISSUEs: 1) The reset will clear all saturations, not just the T240s.  2) The wait is required because the Saturation bleed off code still has the bug of needing a bleed cycle to execute so any reset can take up to 60 seconds.  Wasted time not locking/observing.

Integration Issue #1163 filed

J. Kissel, S. Karki, B. Weaver, R. McCarthy, G. Merano, M. Landry

After gathering the weekly charge measurements, I've compared H1 SUS ETMY ESD's relative Pitch/Yaw actuation strength change (as measued by the optical levers) against the Longitundinal Actuation Strength (as measured by PCAL / ESD calibration lines). As has been shown previously (see LHO aLOG 22903), the pitch/yaw strength's slope trends very nicely along with the longituinal stength change -- if you take a quick glance. Upon closer investigation, here are things that one begins to question:
(1) We still don't understand why the optical level actuation strength assessments are offset from the longitunidal strength assessment after the ESD bias sign flip. 
(2) One *could* argue that, although prior to the flip the eye-ball-average of oplev measurements trackes the longitudinal strength, after the flip there are periods where two quadrants (magenta, in pitch, which is LR, from Oct 25 to Nov 8; black, in yaw, which is UR, from ~Nov 11 to Dec 06) track the longitudinal strength. As such, one *could* argue that the longitudinal actuation strength trend is dominated by a single quadrant's charge, instead of the average. Maybe.
(3) If you squint, you *could* say that the longitudinal actuation strength increase rate is slowly tapering off, where as the optical lever strength increase *may* be remaining constant. One could probably also say that the rate of strength increase is different between oplevs and cal lines (oplev P/Y strength is increasing faster that cal line L strength).
All this being said, we are still unsure whether we want to flip the ETMY ESD bias sign again before the observation run is out. Landry suggests we either do it mid-December (say the week of Dec 14), or not at all. So we'll continue to track via optical lever, and compare against the longitudinal estimate from cal lines.

Results continue to look encouraging for ETMX -- ever since we've had great duty cycle, and turned off the ETMX ESD Bias when we're in low-noise and/or when the IFO is down, the charging rate has decreased. Even though the actuation strength of ETMX doesn't matter at the few % level like it does for ETMY (because ETMX is not used as the DARM actuator in nominal low-noise, so it doesn't affect the IFO calibration), it's still good to know that we can get an appreciable effect by simply reducing the bias voltage and/or turning it off for estended periods of time. This again argues for going the LLO route of decreasing the ETMY bias by a factor of 2, which we should certianly consider doing after O1.

---------------
As usual, I've followed the instructions from the aWiki to take the measurements. I had much less trouble today than I had last week gathering data from NDS, which is encouraging. One thing I'd done differently was wait a litle longer before requesting the gathering and analysis (I waited until the *next* measurement had gone through -9.0 and -4.0 [V] bias voltage points and started the 0.0 [V] point, roughly 5 minutes after the measurement I wanted to analyze ended). As such, I was able to get 6 and 4 oplev data point to compose the average for ETMX and ETMY, respectively (as opposed to the 3 and 1 I got last week; see LHO aLOG 23717).

Once all data was analyzed, I created the usual optical-lever-only assessment using 
/ligo/svncommon/SusSVN/sus/trunk/QUAD/Common/Scripts/Long_Trend.m
and saved the data to here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O1/H1/Results/CAL_PARAM/2015-12-01_H1SUSETMY_ChargeMeasResults.mat

However, I'd asked Sudarshan to gather the latest calibration line estimates of the ESD longitudinal actuation strength (aka kappa_TST), which he gathered from his matlab tool that gathers the output of the GDS function "Standard Line Monitor." (He's promised me an updated procedure and an aLOG so that anyone can do it). This is noteably *not* the output of the GDS pipeline, but the answers should be equivalent. His data lives here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O1/H1/Results/CAL_PARAM/2015-12-01_Sep-Oct-Nov_ALLKappas.mat

Finally, I've made the comparison between oplev and cal live strength estimates using
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O1/H1/Scripts/CAL_PARAM/compare_chargevskappaTST_20151201.m

   Finishing up with maintenance window and getting ready to relock. Nutsinee and Jeff did a sweep of the LVEA. 

Attached are plots of the IOO IMs, IM1-4, and their alignments in pitch and yaw.  Also plots of IM4 Trans pitch and yaw over 90 days.

Plot 1: IM4 Trans pitch and yaw

• - noteable is that at the start of the plot (sept 2nd) the pitch and yaw values were -0.2 and 0.054 respectively
• - change around sept 12th attributed to IM alignment changes, pitch and yaw now -0.330 and 0.095 respectively
• - mostly stable until oct 21st and by oct 29th pitch and yaw have drifted to -0.450 and 0.090 respectively
• - more drift and a change around nov 30th, and current values are -0.486 and 0.065 respectively

Plot 2: IM4 Trans and IM1-4 pitch

• - IM1 pitch changes are 10urad and smaller
• - IM2 pitch changes are 70urad and smaler
• - IM3 pitch changes are 12urad and smaller
• - IM4 folllows

Plot 3: IM4 Trans and IM1-4 pitch

• - IM1 yaw changes are 30urad and smaller
• - IM2 yaw changes are 5urad and smaler
• - IM3 yaw changes are 52urad and smaller - note, the big change near the end of the plot is due to an intentional alignment change
• - IM4 folllows

In all plots, changes can be attributed to both alignment shifts after shaking (HAM2 ISI trips / earthquakes) and intentional alignment adjustments.

Robert and Nutsinee had tested the noise from an additional cleanroom in the Optics Lab in alog 23169.  With Michael's OK, I've turned this cleanroom on and expect it to be on for the duration of O1 as we use it to inventory oustanding hardware.

LLO and LHO use somewhat different RZ blends on St1 of our BSCs. Because the T240s have a RZ coupling to Z drives, we use a high CPS blend to avoid injecting this coupling into the control loops. The blends are shown in my first plot. The low pass CPS (red) is common to both, but LLO uses a CPS/L4C blend ( their L4C high pass is dashed green), while LHO is using a blend that has both the T240 (light blue) and L4C (brown). RichMs seismic log 647 shows that the CPS/L4C ends up injecting a bunch of L4C noise  at low frequency. Arnaud and Rich have worked on testing a CPS/L4C blend that rolls the L4C off more at low frequency, see LLO alog 21941. The blend that LHO uses rolls off the L4C more, but replaces that signal with possibly spurious T240 signal. I tested that this morning and it looks like this is not a problem for LHO. Second plot is the CPS and oplev for ITMX, third plot is L4C and T240, references are with the L4C/CPS RZ blend, the live traces are with the T240/L4C/CPS blend. The CPS shows that the L4C only blend does indeed move a lot more at low frequency, though the oplev doesn't see any difference. The T240 and L4C don't really see a difference, but the T240 is suspect and the L4C is a poor low frequency sensor.

There is one reason why LHO maybe okay with T240s in our RZ blend while LLO may not, we are using HEPI sensor correction to offload low frequency Z isolation ( and thus, drive) to HEPI. Arnaud has also tried lower blends on St1 with L4C/CPS RZ blends succesfully, something I want to test, which may not work as well at LHO because we are using T240s in RZ. I would also like to try Rich's new 750mhz blend, with and without T240s, but all of that will probably wait until after 01.

J. Oberling, P. King

I reset the 35W FE watchdog this morning at 18:24 UTC (10:24 PST).  I also noticed that the crystal chiller was low so I added 125 mL of water to top it off.  While doing that Peter noticed the warning light on the diode chiller that coincides with low water was lit, so we added water until the light went off.

After yesterday's report that CER temperature was high (alog 23826), Bubba made some adjustment of the diverter(???) for CER yesterday, which made the temperature go down by 0.5 C, and RF output level got somewhat higher.

The second attachment shows that the temperature jump on 27/Nov in CER (red vertical lines) didn't coinside with the time they made the adjustment to the air handler (blue vertical lines). Though we don't understand why the temperature went up at that timing, since no catastrophy was observed, and since the temperature seems to be well regulated, I guess we need to operate like this.

Note that the PEM temperature screen is reporting many out-of-tolerance errors including CER and Sup. It doesn't prevent us from going observation, but when we figure out that the current temperature is good, I think we'd better update eiither the tolerance or the nominal temperature.

The beam alignment into the reference cavity was tweaked.  Most of the alignment was done
by adjusting the mirror mounts on the periscope.  The other mounts did not yield as much
gain as the ones on the periscope.  With the pitch adjustments the transmission signal went
from ~0.75 - 0.78 to ~1.16.  Relatively minor tweaks were made to the AOM alignment without
any big improvements, which suggests that the adjustments for the AOM are in the mid-range.
Went back to the periscope adjustments and adjusted yaw which improved things to ~1.2.
Walking the beam in yaw, followed by small pitch adjustments improved the signal to ~1.5
with the HEPA fans on and the ISS unlocked.

The power into the reference cavity was measured to be 30.1 mW - measured with Ophir stick
calorimeter.

Both mounts on the periscope were locked as best as possible.  The transmission signal was
1.52.

The signal on the RFPD was:
unlocked : -245 mV
locked   : -40 mV
offset   : -2 mV

With the ISS on, the reference cavity transmission was measured to be 1.54.

Attached, for reference, is the camera image of the various spots from the cavities.


As an aside, the recent drift in reference cavity transmission seems to coincide with some
jumps in the pre-modecleaner temperature.

Jason, Ed, Peter

This morning before maintenance really took off, we tried switching blends on all of the BSCs, while the IFO was still locked. Contrary to my findings a couple weeks ago (alog 23610), it now seems like it's possible to switch blends while the IFO is locked and not break lock. We started out carefully, switching only the ETMs, one at a time, then the corner station ISIs. We then tried a little faster, doing the corner station all at once, then both ETMs. Finally, we switched all chambers all at once. For each of these tests, we switched from our nominal 90mhz blends to the 45mhz blends then back. The lock survived each switch, although the ASC loops would ring up some, especially when we switched the ETMs.  The corner station ISIs didn't seem to effect ASC as much.

The only IFO difference I know of between the last time I looked at this and now is that Hugh went down and recentered the ETMY's T240s. Environment is also different today, with pretty quiet winds (<10mph) and only moderate microseism (rms < .5 microns).

The attached trends are for the ASC D/C Hard, D/C soft, ETM oplevs and corner station oplevs. Similar to what I found a while ago, ETMY seemed to have the biggest effect on the IFO (based on what we saw on the ASC foms in the control room), although the ITMY oplev actually moved more. Still, the oplevs didn't see more the about 1.5 microradians motion at any point.

You can also tell what blends were running on the traces based on the eye-ball rms of the ASC signals. The 90mhz blends don't filter out the microseism which is moderate today, so the ASC pitch signals get noisier. This is also visible on the oplevs.

I'm testing a new commissioning reservation system I wrote this afternoon using python. This is a file based system replacing the old EPICS system. The main reason for the change is that the old EPICS system developed problems related to updates and required a lot of maintenance. It was also awkward to configure and restrictive in what it could do.

The reservation file is /opt/rtcds/lho/h1/cds/reservations.txt

There are three python scripts:

make_reservation.py is available to all users, it allows you to create your reservation

display_reservations.py script loops every second and shows the currently open reservations

decrement_reservations.py script is ran as a cronjob every minute, it decrements the time-to-live of each reservation and deletes them when they expire.

I have a display running on the left control room TV closest to the projector screen.

Here is the usage document for the make_reservation.py script

controls@opsws6:~ 0$ make_reservation.py -h

usage: make_reservation.py [-h] system name task contact length

create a reservation for a system

positional arguments:

  system      the system you are reserving, e.g. model/daq

  name        your name

  task        description of your task

  contact     your contact info (location, phone num)

  length      length of time (d:hh:mm)

optional arguments:

  -h, --help  show this help message and exit

If you need to use spaces, surround the string with quotes. There are no limitations on string contents. Here is an example reservation

      make_reservation.py "PEM and DAQ" david.barker "update PEM models, restart DAQ" "phone 255" 0:2:0