LVEA: Laser Hazard
Observation Bit: Undisturbed   

07:15 Karen & Cris – Cleaning in the LVEA
08:00 Reset Observation Bit to Commissioning
08:12 Jim – Running testing on HAM4 & HAM5
08:14 Filiberto – Cabling vacuum gauge at HAM1
08:15 Elli – Going to HAM1 area to look for parts
08:15 Hugh – Doing HEPI maintenance at End-Y & End-X
08:20 Elli – Out of the LVEA
08:39 Nutsinee – Going to End-X to recycle PCal camera
08:52 Jim – Finished testing
09:12 Nutsinee – Back from End-X
09:23 Adjusted ISS RefSignal to reduce diffracted power
09:41 Kiwamu – Transition LVEA to Laser Safe
09:55 Sudarshan – Installing accelerometers on IOT2R and ISCT6
10:30 Mitch – Working in the LVEA on 3IFO stuff
10:50 Dave & Jim – Moving fibers at End-Y & restart End-Y PEM/PCal model
10:52 Betsy – Making Safe.Snap of all CS suspensions
11:21 Filiberto – Going to Mid-Y to get parts
11:32 Dave & Jim – Back from End-X
11:33 Dave & Jim – Going to End-Y to move fibers
11:52 TJ – Going to End-Y and End-X to drop off tools
12:10 Kyle – Closing GV5 & GV7
12:14 Dave & Jim – Back from End-Y – Restarting PEM models
12:15 Sheila – Transitioning LVEA back to Laser Hazard
12:16 Contractor on site to see Bubba
12:38 Karen – Cleaning at End-Y
12:44 Richard & Filiberto – Working on electronics at HAM1
12:53 Vender on site to stock snack machines
13:03 TJ – Back from End stations
13:08 Bubba – Going to End-Y to get equipment
13:44 Karen – Leaving End-X
13:45 Mitch – Out of the LVEA
14:05 Stuart & Jason – Running B&K testing of ITM-Y OpLev piers
14:10 Hugh – Going to End-Y to check HEPI
14:15 Richard – Restarting vacuum system computer
14:18 Dave – Restarting vacuum model
14:19 Dick – Going into LVEA to checking RF analyzer
14:35 Betsy, Mitch, & Travis – Going into the LVEA
15:05 Doug & Danny – Looking at OpLev piers to prep for grouting 
15:20 Sudarshan – Working on IOT tables
15:25 Doug & Danny – Out of the LVEA
15:25 Dough – Going to End-Y & End-X to check OpLev piers to prep for grouting
15:30 Stuart & Jason – Out of the LVEA
15:52 Sudarshan – Out of the LVEA

This morning, Stuart and I used the SDF front end to take new SAFE.SNAP snapshots of the balance of the suspensions - recall, he had done the BS previously, see alog 16896.

Repeating his alog instructions on how to perform this:

- Transition the Suspension to a SAFE state via Guardian
- On the SDF_RESTORE MEDM screen available via the Suspension GDS_TP screen select FILE TYPE as "EPICS DB AS SDF" & FILE OPTIONS as "OVERWRITE" then click "SDF SAVE FILE" button to push a SDF snap shot to the target area (which is soft-linked to userapps).
- This safe SDF snapshot was then checked into the userapps svn:
/opt/rtcds/userapps/release/sus/h1/burtfiles/
M        h1susbs_safe.snap

Note, please don't use the BURT interface to take SAFE.SNAP snapshots anymore, as the SDF monitoring will become disabled.  All other snapshots are free to be taken via BURT, however.

Also, we found many alignment values not saved on IFO_ALIGN which, after confirming with commiss, we saved.

I have updated the SUS Driftmon again with the values from the middle of the most recent good lock stretch (1108983616 GPS).  As of the update time, all SUSes are in the green, with the exception of the OMs, RMs, and OMC, whose alarms values have yet to be evaluated.

Took 24 hour OpLev trend measurements. 

Altough the high frequency is kind of screwed up by the wandering line, we can get some interesting information about the lower frequencies.

The full report can be found at the following address:

https://ldas-jobs.ligo.caltech.edu/~gabriele.vajente/bruco_1108981336/

The most interesting coherence is with SUS-BS_M1_ISIWIT_PIT_DQ, which seems enough to explain most of the noise up to 100 Hz. This is consistent with what Sheila told me, i.e. that we're not fully using BS ISI.

For those interested in the BruCo details, I managed to reduce a lot the time needed to analyze the data, basically with the following modifications: split coherence computation into the single FFT computations, to reduce redundancy; parallelize the computation and expcially the disk access using all available processors. This brought down the typical execution time to analyze 10 minutes of data from 8 hours to about 20-30 minutes. The new code is attached. 

J. Kissel, K. Izumi,

Regrettably, I have to put this work on hold for the weekend, but it turns out calibration of the IMC in the new CAL-CS infrastructure will be more involved that I thought.

(1) I've managed to install the frequency dependence of the suspensions. Sadly, I've given up (once again) on developing an automated way to generate a photon design string from our matlab dynamical state space models of the suspension. Instead, I used zpkdata on the state space model, and by-hand-cancel all poles and zeros that were obviously the same (for some reason minreal can't do this for me). The end result is happily what I expect -- see first attachment.

Here're the final filters as implemented in foton, which have been stuck in FM5:
"M1toM3"
zpk([0.018585-i*3.410679;0.018585+i*3.410679;1.606379;0.044818-i*1.036165;0.044818+i*1.036165;
  0.118436-i*0.689908;0.118436+i*0.689908],
  [0.264197-i*3.085648;0.264197+i*3.085648;0.019394-i*3.411951;0.019394+i*3.411951;1.586567;
  0.103907-i*1.688080;0.103907+i*1.688080;0.085448-i*0.524339;0.085448+i*0.524339;
  0.043202-i*0.791714;0.043202+i*0.791714;0.043839-i*1.040618;0.043839+i*1.040618], 5.070123e+05,
   "n")
gain(1.97234e-06)

"M2toM3"
zpk([0.018965-i*3.411371;0.018965+i*3.411371;0.383092-i*2.775995;0.383092+i*2.775995;
  0.109233-i*0.626005;0.109233+i*0.626005;0.045076-i*1.037432;0.045076+i*1.037432;1.595790],
  [0.264197-i*3.085648;0.264197+i*3.085648;0.019394-i*3.411951;0.019394+i*3.411951;1.586567;
  0.103907-i*1.688080;0.103907+i*1.688080;0.085448-i*0.524339;0.085448+i*0.524339;
  0.043202-i*0.791714;0.043202+i*0.791714;0.043839-i*1.040618;0.043839+i*1.040618], 2.394780e+03,
   "n")gain(0.000417575)

"M3toM3"
zpk([0.019384-i*3.411943;0.019384+i*3.411943;0.268344-i*3.080800;0.268344+i*3.080800;1.587283;
    0.119880-i*1.524350;0.119880+i*1.524350;0.105649-i*0.583444;0.105649+i*0.583444;
    0.046372-i*1.036411;0.046372+i*1.036411],
    [0.019394-i*3.411951;0.019394+i*3.411951;0.264197-i*3.085648;0.264197+i*3.085648;1.586567;
    0.103907-i*1.688080;0.103907+i*1.688080;0.085448-i*0.524339;0.085448+i*0.524339;
    0.043202-i*0.791714;0.043202+i*0.791714;0.043839-i*1.040618;0.043839+i*1.040618], 2.462902e+01,
     "n")
gain(0.0406025)
Again, the design script can be found here:
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/MC2/Common/H1SUSMC2_GlobalTFs_to_Foton_20150224.m

(2) The DC gain of the actuation chain -- the M3 (optic) displacement in [m] per (M1, M2, M3) LOCK L drive [ct] gain of the actuation function have not been updated to reflect that we've increase the drive range of the M2 stage. So these should be recalculated.

(3) In the current calibration scheme, we use the error point * 1 / (the sensing function) + the control signal * actuation function. However, the IMC's sensing function will vary with input power, because it doesn't get normalized with ever level of input power. We need to think about how to continually compensate for the optical gain change due to input power change.

(4) In the calibration current scheme, where we use the IMC error point AND control signals to reconstruct the mode cleaner length isn't properly supported with the current LSC infrastructure. Namely, the error point of the IMC control loop is an analog signal that's *before* the control signal is split into the FAST and SLOW paths. See attached screenshot. The signal is already digitized in the LSC frontend, as "H1:IMC-I_OUT_DQ," but it is not sent over IPC to the CAL-CS model. Further, for the control signal, we need both the FAST and SLOW actuator paths (which *are* already sent to the CAL-CS model). So, if we want to continue with the new CAL-CS calibration scheme, we need send the output of the IMC_I filter bank to the CAL-CS model -- which requires a modification to the LSC model and to the CALCS model.

So.... more work to do on this than I had initially planned and hoped for. We'll get back to it on Monday. *Maybe* I can convince people to make the front end model change on next Tuesday.

I just pushed a patch to cdsutils (now r441) that includes improved CDSMatrix support:

• Supports "ramping" matrices with the "ramping=True" option:
  • the load() method is used to load values (NOTE: must be called after any put operation)
  • the TRAMP property is used to set the TRAMP
  • the is_ramping() method can be used to check if any element is currently ramping
• The get/put() methods can be used to get/put any element, row, column, or entire matrix.
• The zero() method can be used to zero any element, row, column, or entire matrix.

See the built-in help for full documentation:

jameson.rollins@operator1:~ 0$ guardian -i
--------------------
aLIGO Guardian Shell
--------------------
ezca prefix: H1:

In [1]: from cdsutils import CDSMatrix

In [2]: help(CDSMatrix)

Last night we noticed, looking at the real time spectrum of DARM, that there was a wandering line. The attached spectrograms show the peculiar behavior: about every 270 seconds (not regular) this line enter the spectrum from the high frequency range and moves down in a quite repetible way (the frequency has quite perfect exponential evolution with time). Then there is some sort of burst of noise before the line starts again from the high frequency.

This behavior seems different from the wandering line related to IMC-F seen at Livingston.

The dmtviewer on projector0 used up all available memory on projector0 (it takes over a month to do this), so I rebooted the computer and restarted the dmtviewer display of seismic data.

End X PCal camera lost connection last night. The camera control software crashed and didn't detect the camera when I restarted the software. I went in to restart the communication unit this morning and that solved the problem.

Jason spotted the RefSignal voltage was 2.07V and Diffracted power was over 14%. I adjusted the RefSignal voltage to 2.13V bringing diffracted power to ~ 7.5%

model restarts logged for Tue 24/Feb/2015
2015_02_24 05:42 h1fw0
2015_02_24 09:03 h1lsc
2015_02_24 09:03 h1omc
2015_02_24 09:09 h1alsex
2015_02_24 09:09 h1iscex
2015_02_24 09:11 h1alsey
2015_02_24 09:11 h1iscey
2015_02_24 09:16 h1omc
2015_02_24 09:31 h1omc
2015_02_24 09:39 h1asc
2015_02_24 09:49 h1lsc
2015_02_24 09:51 h1susmc2
2015_02_24 09:56 h1calcs
2015_02_24 10:06 h1lsc
2015_02_24 10:14 h1asc
2015_02_24 10:19 h1susetmy
2015_02_24 10:19 h1susitmx
2015_02_24 10:24 h1susitmx
2015_02_24 10:26 h1susetmx
2015_02_24 10:28 h1oaf
2015_02_24 10:28 h1susitmy
2015_02_24 10:34 h1susbs
2015_02_24 10:38 h1dc0
2015_02_24 10:38 h1fw0
2015_02_24 10:38 h1fw1
2015_02_24 10:38 h1nds0
2015_02_24 10:38 h1nds1
2015_02_24 10:39 h1broadcast0
2015_02_24 12:01 h1pemex
2015_02_24 12:16 h1omc
2015_02_24 12:32 h1lsc
2015_02_24 12:35 h1omc
2015_02_24 12:52 h1pemex
2015_02_24 12:57 h1pemex
2015_02_24 13:34 h1broadcast0
2015_02_24 13:34 h1dc0
2015_02_24 13:34 h1fw0
2015_02_24 13:34 h1fw1
2015_02_24 13:34 h1nds0
2015_02_24 13:34 h1nds1

one unexpected restart. Maintenance day: work on ISC and SUS and CAL. PEM restart for RFM testing. Two related DAQ restarts.

model restarts logged for Wed 25/Feb/2015
2015_02_25 06:45 h1fw0
2015_02_25 10:18 h1fw0

two unexpected restarts.

04:57 Turned on the HEPA fans in the H1 PSL Laser Room.  I would like to run this test for at least
      a couple of hours.

      It is noticeable that as soon as the fans are turned on, the minimum and maximum values of the
      ISS percent diffraction vary by ~1%.

06:55 Turned off HEPA fans.

    In running this test, I had forgotten that running the HEPA fans generates heat, and is not a good
idea without turning on the air conditioning.  I switched on the air conditioning to bring the
temperature back down and switched it off after about 40 minutes.

    Attached is the output of the quadrant photodiode that is located inside the power stabilisation
photodiode box.  Assuming that DY is vertical and DX is horizontal, it appears that the vertical
alignment does not recover, whilst the horizontal alignment does.

    Also attached is the reference cavity transmission signal during the same period.  It seems to
recover.

Sheila, Alexa, Gabriele, Evan

Summary

In addition to the differential ETM loops, we now have closed the common ETM degrees of freedom using REFLA9I + REFLB9I. These loops are slow, with bandwidths of a few tens of millihertz.

Details

Previously (LHO#16883), we had closed loops around IM4 in order to reduce the amount of reflected light into REFL_A_LF. However, tonight we decided instead to close the common ETM DOF, so that the ETMs are nominally controlled in all four angular degrees of freedom. This (hopefully) leaves us free to pursue more loop-closing with the corner optics.

The common ETM loops are implemented in the CHARD filter modules. These modules are stuffed with the same filters as for their DHARD counterparts.

• For CHARD pitch, we have FM3, FM4, FM6, FM7, FM9, and FM10, with a gain of −14 ct/ct.
• For CHARD yaw, we have FM3, FM4, FM7, FM8, FM9, and FM10, with a gain of −5 ct/ct.
• For DHARD, the gains are 12 ct/ct for pitch and 15 ct/ct for yaw.