Jenne, Hang, Ketia, Sheila, Kiwamu, Matt, Lisa, Robb, Evan, everyone in the control room...

today we mostly focused on RF centering.  

We made two model changes:

•  normalize the RF centering signals by their sums
•  adding the I+Q phases in quadrature to for each quadrant so that we will not have to worry about phasing 

We noticed that our normal DC centering loops for the AS port have eveloved to a bad state. In the end we have had about 5 degrees of phase margin and 40dB gain peaking in these loops with the nominal settings we used durring O1.  

We reduced the gain and switched over to 90 MHz centering.  The input matrix that resulted in an upper ugf around 2 Hz for all 4 loops is attached.  The next four attachments are OLG measurements of the centering loops, the blue curves are for the DC centering with the nominal settings used for O1, the red ones are with the input matrix shown in the attached screenshot.  

After adjusting the gains of the RF loops, we closed the BS pitch loop using AS36AQ (our normal sensor).  The closed loop response of the centering loop is clearly a feature of the MICH loop with this centering, as the 6th screenshot shows.  When we are on the DC centering, changing the bandwidth of the centering loops didn't change the shape of the MICH loop, but clearly it does with the RF centering, which must be responding to BS.  FOr the time being I turned off the ELF20Hz (a low pass in the centering loops), which gives us more phase and less gain peaking,  so that our MICH loops still seem stable.  This results in the OLG shown in purple in the 6th attachment.  The Yaw OLG is the 7th attachment.  (The MICH digital gains here were 0.8 for pit and 0.7 for yaw, our nominal settings are 0.7 for both, which is probably fine.)

We left the AS36I to SRM loop open and locked the IFO (including the DRMI on POP state which has coil drivers switching and caused problems last week) without any problems.  I checked that the MICH YAW gain was the same in full lock as it was in DRMI.  In engage ASC part 2 a 5Hz low pass is engaged on the MICH loop, this was not stable and blew the lock.  I've commented this out of the guardian for now. The next two locking attempts failed, AS90 dropped as we came into resonance and never recovered, which could be due to the SRC loop being open, or a problem with MICH loop.  I've saved an SDF snap with the current settings as ASC_progress_March3evening.snap

To sumarize changes:

• MICH P and Y FM5 are no longer engaged in ENGAGE_ASC_PART2
• ELF20s are off in DC3 and DC4 loops
• input matrix for DC3+4 is as in the screenshot
• We are manually not letting the SRC1 loops come on.

The next step is probably to open the MICH ASC loops after they have run in DRMI, and check in full lock that the lock point is still good.  It is clear that there is a difference between DC centering and RF centering when we reduce the CARM offset.  

C. Cahillane

I have been working on a preliminary calibration uncertainty budget for the parameter estimation group to come up with something more sophisticated than "10% and 10 degrees" spline fitting that is currently done.

The plot below shows my attempt at a numerical budget.  I have imported my analytical budget for simplicity of comparison.  They are the dark red lines.  Dashed lines represent the uncertainty envelope.  
What is plotted is the C01/C03 response function.  The deviations from 1 (mag) or 0 (phase) represent the systematic differences between our model and our measurements between our C01 (uncorrected) and C03 (perfect) calibration versions.
The light red dots illustrate the 100-iteration MC performed.  
These MCs were performed in the following way: The response function is a function of 14 parameters [R(f) = R(f|a1,a2,a3,...,a14)].  Each of these a_i have an associated uncertainty sigma_a_i.  
The person running the MC supplies 14 random samples from a 0-mean 1-std Gaussian distribution.  I take these random samples, multiply it by sigma_a_i, then alter a_i by the result [a_i_new = a_i + rand * sigma_a_i].  Then I recalculate the response function using a_i_new.  That gives me a single light red line.

The dark grey lines are the median (dots) and 1 sigma deviations from the median.  The deviations are found by looking for the 68% confidence interval.  For example, in this 100 iteration example, I look for the innermost 68 points and plot the limits on this as my "numerical envelope".  This envelope agrees fairly well with my analytical envelope.  If I increase the number of iterations the envelope should collapse to my analytical uncertainty envelope.

See the LLO Numerical Uncertainty Budget (LLO aLOG 25104)

Kyle, Chandra

1520 -1655 hrs local -> To and from Y-mid 

LN2 @ exhaust 3 min 5 secs with 1/2 turn open.  Next overfill to be Sat. 3/5 before 4:00 pm local.  

Since the ISI will trip its watchdog when the suspension it carries trips, a path to the particular tripped suspension seems convenient.  This already existed for the HAMs and I've now added it to the BSC ISIs.

On the ISI OVERVIEW medm, there is a Payload button in the middle left.  This will be ringed in red if the suspension is either tripped or its model stopped.   The PAYLOAD medm has a link to the suspension(s) (very convenient for the likes of HAM2,) and an override button.  If the SUS model is not running, the operator can hit the override button and untrip the ISI watchdog.  The override does not work for a running suspension.  The attached shows the medms.

Had to add sus variables to get the correct SUS medms to the ISI overview_macro files:

hugh.radkins@opsws10:bscisi 0$ pwd
/opt/rtcds/userapps/release/isi/h1/medm/bscisi
hugh.radkins@opsws10:bscisi 0$  svn commit -m "Added sus medm style for payload display"
Sending        bscisi/H1_isibs_overview_macro.txt
Sending        bscisi/H1_isietmx_overview_macro.txt
Adding         bscisi/H1_isietmy_overview_macro.txt
Sending        bscisi/H1_isiitmx_overview_macro.txt
Sending        bscisi/H1_isiitmy_overview_macro.txt
Transmitting file data .....
Committed revision 12788.
hugh.radkins@opsws10:bscisi 0$

And, edited two ISI medms:

hugh.radkins@opsws10:bscisi 0$ pwd
/opt/rtcds/userapps/release/isi/common/medm/bscisi
hugh.radkins@opsws10:bscisi 0$ svn commit -m "Completing links to SUS medm via PAYLOAD"
Sending        bscisi/ISI_CUST_CHAMBER_OVERVIEW.adl
Sending        bscisi/ISI_CUST_CHAMBER_PAYLOADMON.adl
Transmitting file data ..
Committed revision 12789.
hugh.radkins@opsws10:bscisi 0$

Added 72 channels. Removed 152 channels. Changes attached.

State of H1: down, reboots, locking to resume

Shift Summary:

Site Activities:

• Kyle to mids and LVEA
• Karen to LVEA and optics lab
• Kiwamu to Hartman Sensor table
• landscapers - worked clearing the roads on both arms
• Bubba/Nicole - LVEA and optics lab in OSB

Reboots/Restarts:

• DAC
• ASC model
• Verbal Alarms

Environment:

• Winds to 35mph - visible on 0.03-0.1Hz monitor
• Earthquake R waves arrived around 22:00UTC, making locking impossible for a while - visible on 0.03-0.1Hz monitor
• useism is below 5um/s

Current Status:

• Commissioners working on relocking

New code was restarted on h1asc. Because ch11 of dac1 was offloaded from the h1ascimc model over to the h1asc model, I first had to kill both models and then cleanly restart them to avoid two models using the same DAC channel. The h1asc model added and removed slow channels in the DAQ, so a DAQ restart was performed at 16:00PST.

I checked out the hardware/software we need for implementing POP_X:

• The WFS sensor head is available and "stored" on ISCT6
  needs to be moved to ISCT1 with some additional optics and a PZT steering mirror
• The WFS power supply is the one for REFLAIR_A (3rd channel of WFS interface chassis in R4)
• The DC signals are hooked-up to the DAQ and readout in the ASC model
• The entire demod chain (original REFL leapfrog) is available, powered up and read by the DAQ
• The in-rack RF cable for the 36MHz demod is being made
• The WFS cables will be taken from a REFL WFS (REFL_B 45 seems to reach/R2)
• We need to mount an MCL controller on top of ISCT1, requires power
• The feedthrough panel is on order as well as the required DB9 cables
• The cables between the MCL controller and the DE2SE converter in R1 are being made
• The h1asc model was updated to send the pit and yaw signals to the DAC channels
  (these channels were removed from the h1imcasc model, where they were hooked up, but not used)
  The models have been build, but not installed
• Some medm screens need to be updated

Documents:

• Issue tracker: 1128
• ISCT1 optical table: D1201103
• ISCT1 feedthroughs: D1201331
• ISCT1 rack mounting: D1201499
• RF distribution: E1100591
• DAQ channel assignment: T1100472
• Cable pull list: E1200408

Last Friday, the STS2-A near HAM2 had its igloo installed.  The masses still look well centered.  Attached is a view of the three LVEA instruments' ASD and coherence with each other.  The thin current traces are from 0100utc when wind and seismic was minimal; the thick reference traces are from a week ago.

The improved thermal state of the HAM2 unit is evident on the Z dof where all sensors follow each other well and the coherence is much improved especially below 40mHz.

However, HAM2's Y & X performance at low frequency but especially the Y dof, show that HAM2 continues to have a problem even though Quanterra had the machine in their vault for a month and could not determine an issue.  Since the Z signal is determined from all 3 masses, it suggests the problem might be in electronics converting U V W to Y and X.

The Z coherence plot suggests the HAM2 and HAM5 Z dofs are doing well but ITMY Z dof is flakey.  The Y coherence indicates the HAM5 and ITMY Y dofs are okay but the HAM2 Y is not.  The X coherence suggests the HAM2 is better than the ITMY as ITMY has worse coherence with both HAM2 & 5.

So summary:

The HAM2 unit, STS2-A does not work well in Y and is marginally better in X; it is good in Z.

The ITMY unit, STS2-B, does not work well in Z or X but is tolerable in Y.

The STS2-C, HAM5 unit works best even though we have to surmise X since both other units are poor in that dof.  Jim would agree based on detchar and sensor correction performance.

Brynley, Vinny,

Please see the attached presentation, regarding the work summarized in previous aLOG: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=25772

LIGO has 15 hardware watchdog (HWWD) units. They are distributed five per IFO (one per Quad Suspension plus a spare).

Of the 15, 12 have the new firmware loaded. The remaining three had been in use at LHO and have been replaced with new units and shipped to Caltech for upgrade.

I have tested all 12 of the upgraded units on the LHO DAQ Test Stand (DTS). All 12 units have passed the tests.

My test procedure is:

power cycle unit 10 times in succession.

run the script hwwd_test.py which:

  for each LED raises an error and verifies error is detected and the countdown starts

  raise error on all LEDs and wait for the 20 minute countdown to expire, verify the SEI enable voltages go to zero

  for each Photodiode, simulate a ring up to greater than 110mV RMS and verify unit detects the error and the countdown start

  ring up the F1 PD and wait for the 20 minute countdown to expire, verify the SEI enable voltages go to zero

The test script is under cds_user_apps SVN repository cds/h1/scripts/hwwd_test.py

For these tests the units were connected as they will be when installed on H1 and L1. Test configuration drawing is sheet 2 in D1300475 We also tested Rolf's latest hwwd RCG part in the test model x1susetmywdt.mdl.

The tested units (which all passed) are:

S1301697, S1301699, S1301701, S1301704, S1301706, S1301707, S1301708, S1301713, S1301714, S1500331, S1500332, S1500333

The units shipped to Caltech for upgrade are: S1301703, S1301709, S1301712

LHO HWWD installed status

We have two units currently installed on H1, on ITMY and ETMY.

ITMY S1301708: this unit is running in monitor-only mode. It is monitoring the ITMY M0 top stage OSEM and cannot disable the ISI coil drivers for BSC1.

ETMY S1301701: this unit is fully functional. It is monitoring the ETMY M0 top stage OSEM and can power down all three ISI coil drivers for BSC10 if an error condition is raised for 20 minutes.

WP5756

h1asc model was restarted 10:17PST. Slow channels were changed, requiring a DAQ restart at 10:35PST.

During O1 run we have monitored slow variations in the DARM actuation and sensing functions with several ~35 Hz and a ~350 Hz line at both observatories.

Systematics in the actuation function mostly affect systematic errors at frequencies below UGF, while systematics in the sensing mostly show up at higher frequencies.

Variation in the DARM sensing is parametrized with an overall sensing gain κ_C and a cavity pole frequency f_C. Most dramatic changes in both of these parameters appear in the beginning of locks, which could be a result of changing of cavity modes due to thermal heating of test masses and possibly some other effects.

Variation in the DARM actuation is parametrized with κ_TST and κ_PU. The κ_TST is a scalar gain factor of the ESD driver actuation which drives only the TST stage. We believe that it changes mostly due to charge accumulation on the surface of an ETM. The κ_PU is a scalar gain factor of the actuation functions of the upper stages PUM and UIM. The coil-drivers as used to for actuation of these stages. We do not believe that κ_PU should change over time, but monitoring it helps to make sure that we do not miss any slow variations that we did not account for.

Time-frequency plots of the known time-depedent systematics in the overall DARM response function calculated from κ_TST, κ_PU, κ_C and f_C in O1 run are attached.

Update: replaced figures (portrait -> landscape orientation) for convenience.

17:20UTC With Sheila's "ok" I cleared the excitation (tp and awg) on H1ASC as an exerscise in vetting the instruction WIKI for "Tracking Down Excitations".

As of 16:47UTC (8:47PT):

16:30UTC (08:30PT) Meeting:

• No system reports
• A reminder to include Betsy in communications about  SUS
• Kyle/Gerardo - still wanting to go to EX, but road isn't yet clear
• Landscapers here to clear the roads to EX and EY, and other areas

Site Activities:

• 15:20UTC ChrisS - X-arm beam sealing approx. 300 yards from corner station
• 16:40UTC Kiwamu - TCS Hartman table
• 16:50YTC Bubba and Nicole - LVEA vertex and then Optics lab

H1 Plans:

• DRIM lock for commissioning
• Current State of H1: arms locking in green, haven't made it to PRMI lock yet this morning
• WP to load new ASC model approved, loading now

I've been slowly trying to get stuff figured out for testing a wind fence set up at LHO, and am getting ready to try to set something up. I'll summarize where I think things are here.

Currently, I want to try a small, cheap wind fence at EX, mostly to explore how effective screens are at slowing wind, effects on ground motion and tumbleweed build up. The fence would be a couple of 4x4-ish 12-15 foot posts and some fine polymer netting like that used around tennis courts, gardens and the like. It may be necessary to add guy lines, as well.  In addition to the fence, Richard has said he will help me get an STS buried at EX, similar to Robert's set up at EY, and we are ordering 3 anemometers with stand alone data collection so no changes need to be made to CDS for this. I think this set up will allow me to look at a few of the concerns that people have brought up. So far the concerns I've heard are:

1. Increased ground motion. Fences slow wind by applying a force to the airstream, this is transmitted to the ground and produces increased tilt and other high frequency motion. I think the tilt can be addressed by placing the fence some few tens of meters from the building, per Robert's measurements of building tilt. Higher frequency motion can hopefully be addressed by design of the fence support structure, but we'll have to see how bad the motion is.

2. Similarly, the fence could make airflow more turbulent. I suspect that airflow at the building level is probably turbulent anyway. Hopefully, a well designed fence push turbulent flows around the building, while slowing most of the air makes it through.

3. Tumbleweed build up. Anything that blocks the wind will gather tumbleweeds around here, which could make a fence a fire hazard and maintenance issue.  This  could be addressed by leaving a gap at the bottom. The airflow below a few feet probably isn't a significant source of problems for us, but I don't know how big this gap would need to be. I also plan on using a mesh fine enough that tumbleweeds won't stick to the fence very easily. Industrial fences are flame resistant, and won't ignite on their own.

4. Wind damage. We have seen winds above 100 mph during a storm, this would create very high loads on any fence. I haven't been able to figure out how to calculate wind loads on a permeable wall yet, but Civil Engineers have building codes dealing with this. For my test, I'm trying to get some idea of the loads involved with moderatewind, and just making the fence so that the mesh will tear free in a way that won't damage the EX building if the wind gets too bad. Industrial fences are designed to stand similar wind loads, and their screens are held in place with replaceable break-away clips to prevent damage.

5. Cost/size. BrianL talked to a company that makes industrial fences a few months ago. The ball park figure for a 40 x 200 foot fence was about $250,000. That was a first pass at a price and the company had some suggestions at how to cut down on the cost. This price also needs to be weighed against the 10-15 % of down time we have due to wind. Something of that size would also probably have to be approved by the DOE. It's also unclear if we would have to completely surround each endstation, or if we could get away with less coverage. Probably, we don't need to "protect" EY along the X-axis, or EX along the Y-axis.

Comments, criticism, praise are all welcome.

Attached are 7 day pitch, yaw, and sum trends for all active H1 optical levers.