Displaying reports 68881-68900 of 84421.Go to page Start 3441 3442 3443 3444 3445 3446 3447 3448 3449 End
Reports until 14:23, Friday 09 January 2015
H1 CDS
patrick.thomas@LIGO.ORG - posted 14:23, Friday 09 January 2015 - last comment - 15:25, Friday 09 January 2015(15970)
Stopping h1conlog3 per WP 5002
Conlog searches unavailable for duration.
Comments related to this report
patrick.thomas@LIGO.ORG - 15:25, Friday 09 January 2015 (15974)
Done. Seems to have been successful. I have restarted the crontask for reporting frequently changing channels every hour.
H1 SUS (COC, SUS, SYS, VE)
vernon.sandberg@LIGO.ORG - posted 14:20, Friday 09 January 2015 (15969)
Schedule for BSC09 "Abbreviated Vent & Closure": Earth Quake Stop Adjustment of EX Test Mass, January 7-8, 2015

Schedule for BSC09 "Abbreviated Vent & Closure": Earth Quake Stop Adjustment of EX Test Mass, January 7-8, 2015

Approved work to be done:

  1.  Assessment of earth quake stops gaps for the test mass
  2.  Set lower  EQ stops gaps to ~1.5 mm

Wednesday, Jan. 7

Thursday, Jan. 8

The last step is at the time and discretion of the Vacuum crew.

H1 IOO
evan.hall@LIGO.ORG - posted 14:14, Friday 09 January 2015 (15968)
IMC WFSs don't work with wrong slider values

Alexa, Thomas, Evan

Over the past 24 hours, the alignment slider values of MC1, MC2, and MC3 have been changed. (Perhaps the WFS offloading script was run?) However, these new alignments weren't saved.

This morning, we changed the IMC guardian from LOCKED to DOWN to do a scattering test with the Y arm. When we brought the IMC guardian back to LOCKED, we found that the WFSs would cause MC2 trans to ramp continually in a saw-tooth fashion, from about 100 % nominal transmission to less than 50 % transmission.

Eventually Alexa figured out it was because the guardian had restored the old, previously saved alignments for MC1, MC2, and MC3, and this had caused the beam to fall off WFS A and WFS B. Dialing in the new slider values for MC1, MC2, and MC3 (and then saving them on the IFO ALIGN screen) made the WFS loops work again.

Images attached to this report
H1 SUS
betsy.weaver@LIGO.ORG - posted 10:57, Friday 09 January 2015 - last comment - 14:55, Friday 09 January 2015(15964)
ETMx - Bad news, still rubbing

The TFs I took this morning show that the rubbing is back on the ETMx main chain now that we are back down to 7 Torr in pressure.  The rubbing TF looks exactly like the rubbing TF we had before I opened up the gap of the EQ stops around the test mass.  While we knew that the rubbing could have been possibly due to the barrel stops around the test mass OR the PUM mass above the test mass, we assumed it was specifically the stops around the test mass since those were the only ones adjusted during the Dec vent.  I did not check the PUM stops (or any other stops further up the chain) yesterday.  Darn it, I should have!  The temp+buoyancy effect is the same on the PUM as it is on the Test mass, so the gap of the EQ stops should be bigger around the barrel there too.

So, we are re-venting today to now:

- Inspect other EQ stops, look for outliers in gap settings further up the main chain

- Open up the gap around the barrel of the PUM to the 1mm (top stops) and 1.5, (bottom stops)

We'll employ the same stripped down version of the entry/exit checklist as yesterday, namely to inspect and DI Nitrogen blow the HR face of the ETMx on the way out.

 

The reaction chain TFs continue to look healthy, so no problems there.

Non-image files attached to this report
Comments related to this report
betsy.weaver@LIGO.ORG - 11:10, Friday 09 January 2015 (15965)

Attached here is a trend of ETMx Vertical and Pitch relative to the pressure and temp of the chamber/VEA, with some annotations of know and unknown events.

Note, the vertical seems to stall out as expected after the buoyancy sag, however the pitch trend turns over for some unknown reason at ~1:30pm PT yesterday for a yet uncorrelated reason. (Kyle paused the roughing pump for the evening at ~4pm PT, and no one claims to be doing anything with the ETMx or out at Ex.  I've confirmed that the pitch offsets were not changed during any of this trend.)

Images attached to this comment
betsy.weaver@LIGO.ORG - 14:55, Friday 09 January 2015 (15973)

During today's vent I took a few ETMx TFs at various chamber pressures.  At 270 Torr, the suspension still showed rubbing.  Now at 550 Torr, the suspension is free of rubbing, however the vertical trend shows that it is only ~10% into it's buoyancy "unsag".  It looks like there is a wiggle at ~400 Torr which may indicate when it came fully free from the rubbing stop.

Images attached to this comment
H1 General
jeffrey.bartlett@LIGO.ORG - posted 09:35, Friday 09 January 2015 (15960)
08:30 Meeting Minutes
Seismic:  
Working on HAM3 sensor correction problem.
3IFO HAM storage retrofit prep work.

Suspensions:	
Check out of ETM-X after vent for EQ stop work.
Brett working ESD charging scripts.

PCal:	
Software upgrade at End-Y.
Calibration work at END-X; End-X will transition back to laser hazard.

Commissioning: 
Will be enforcing stricter limits to LVEA access and work during the afternoon. 
All persons entering LVEA or end stations must check in and out with operator.

3IFO:
Rodica and Jodi working on finding 3IFO parts and sorting optics.
Work continues on removing the H2 test stand electronics from LVEA.      	  	 
H1 ISC
suresh.doravari@LIGO.ORG - posted 03:28, Friday 09 January 2015 (15959)
IM4 TRANS QPD saturated several weeks ago and stopped being a reliable reference for beam pointing

[Sudarshan K, Suresh D]

 

  We looked at the data to see if work associated with engaging the IMC WFS DC centering loops resulted in a shift of the IMC output beam pointing.    There was no evidence to support that conjecture.    The last known instance when ISS outerloop was reliably locked was on Dec 9th.   We could not trace the reason for the shift of the beam to any specific event other than that mentioned below.

  In the attached set of time series plots we see that the IM4_TRANS_QPD segments started saturating several weeks ago and three out of four segements were continuously saturated from Dec 27th onwards.  Therefore this QPD could not be used subsequently to determine if the beam moved during the IMC centering loop work (which commenced on Jan 4th)

 However we can see that there was a change in the DC values of the  ISS QPD pitch and yaw signals around 27th Dec.  We can see an associated change in the signals of the IM4 QPD segments as well.   It is most likely that the IMC output beam shifted around that time and was probably associated with the recovery from the power glitch on 26th.  I could not find any other logged activity around that time.

[suresh]

As early as 10th of Dec we can see from the 40 day trend (attached) that the segs 3 and 4 of IM4 QPD had started to saturate.   We could not therefore use this sensor to monitor the beam position since that time.

I have reduced the Whitening gain on the IM4 TRANS QPD ( from 36dB to 0 dB ) and  recentered the spot on the QPD by using the IM4 TRANS QPD picomotor.   We can monitor the beam motion from now onwards to see if there is any effect from the DC spot centering loops in the IMC ASC.

Images attached to this report
H1 ISC
eleanor.king@LIGO.ORG - posted 18:41, Thursday 08 January 2015 - last comment - 14:06, Friday 09 January 2015(15956)
Auxiliary laser locking for schnupp asymmetry measurement

Keita, Elli

Continuing with Evan's and my attempts to lock the auxiliary laser or IOT2 to the PSL with a frequency offset in order to continue the PRC measurements started by Paul Fulda...

Today Keita and I got the auxiliary laser locked for periods of ~20s.  Then PLL servo control signal would reach its maximum of 5V and the lock would drop.  The beat note between the aux laser and the PSL was continually drifting in one direction- this may have been due to temperature instability on the table (the fan was off to start with and then I turned it on for a while when adjusting the Aux laser temperature.)  I am watching

The PLL is controlled by an SR560 servo controller with 10Hz low-pass filter cutoff and 500 gain. A 7dBPm signal is demodulated with the beat signal between the PSL and the auxiliary laser for the error signal.

Comments related to this report
eleanor.king@LIGO.ORG - 14:06, Friday 09 January 2015 (15967)

Today the frequency drift of the auxiliary laser was much slower, I was able to lock it the the PSL and sweep it across 2MHz a few times before the SR560 output railed.  I moved the 1611 photodiode  back a few cm to where the beam is more tightly focused, increasing the beat note power from -42dBm to -33dBm.

I will switch from using the SR560 to the New Focus LB1005 servo controller.  I also plan to add an amplifier with gain 25 output voltage +/- 125 V after the LB1005, to increase the voltage driving the PZTs.

keita.kawabe@LIGO.ORG - 19:34, Thursday 08 January 2015 (15957)

10Hz single pole, combined with a integration of PLL, means that the OLG phase is already -135deg at 10Hz, so the UGF could not possibly be much more than 10Hz.

But it easily acquires lock and stays locked until the output rails. Anyway this is just the first setting that worked while I was changing things non-systematically. Students will improve it to perfection.

As for the 5V output rail of SR560, using something else to go 10V would only be a marginal improvement as the drift is big. The frequency shifted by at least 200MHz while I was watching and it was not slowing down.

According to Evan, offloading to temperature was attempted without much success in the past, but it seems to me that it is still the way to go.

In preparation of allowing a larger offset frequency, I gave Elli a ZFM-2 that is a level 7 mixer for 1MHz to 1GHz.

daniel.sigg@LIGO.ORG - 23:01, Thursday 08 January 2015 (15958)

We should have a New Focus/Newport LB1005 in the lab which is a proper PI controller for laser locking. We also should have +/-120V PZT driver for the JDSU NPROs.

LHO General
patrick.thomas@LIGO.ORG - posted 16:58, Thursday 08 January 2015 (15942)
Ops Summary (after 9am)
09:03 Vern to end X
09:07 Jim W. and Sebastian to LVEA to turn off HAM3 HEPI pier pods
09:14 Hugh craning in LVEA
09:26 Jim W. and I turned off sensor correction at end Y
09:31 Corey and Grant to the squeezer bay
09:37 Jeff B. and Andres to LVEA west bay to move 3IFO parts
09:43 Travis to end X
09:57 Hugh craning in LVEA
10:00 Jodi out of LVEA, reports clean room between HAM2/3 is on
10:03 Doors back on end X
10:39 Mitchel parking crane in LVEA
10:52 Hugh and Mitchel out of LVEA
10:57 Rick to end Y to work on photon calibrator
11:11 Sheila and Evan turned off clean room at HAM1
11:12 Manny done
11:19 Pepsi truck through gate
11:35 Jeff B. and Andres out of LVEA
11:48 Doug measuring distances for optical lever light pipes near HAM3/4
11:55 Kyle and Gerardo back from end X (started pumping)
12:52 Betsy putting parts in the cleaning bay
13:02 Filiberto to end X to look at cabling
13:04 Corey to squeezer bay
13:28 Aaron to end Y, PCAL cabling
13:51 Aaron done
14:40 Elli working on IOT2

Cyrus and I ran fsck on h1conlog3
Dave tested compilation of frontend models against RCG 2.9
In chamber work was completed at end X
H1 SUS
betsy.weaver@LIGO.ORG - posted 16:35, Thursday 08 January 2015 (15953)
More on QUAD earthquake stops

Attached is a trend of the average LVEA temperature showing the daily ~0.2 deg C temp swing.  The plot is for the month of August 2014 when we were finishing installation of the vertex.  When we are vented and adjusting the EQ stops of a suspension we may see a ~0.06mm change in the gap of the EQ stops around the barrels of the PUM and Test Masses in the QUAD daily.   (0.2degC change x ~0.3mm/1degC temp change = 0.06mm)

This is pretty negligible.  Phew.  However, this temp change pitches the suspension, so now I'll try to find out by how much.  To be continued...

Images attached to this report
LHO VE
kyle.ryan@LIGO.ORG - posted 16:15, Thursday 08 January 2015 (15955)
1605 hrs. local -> Paused X-end rough pumping -> Will resume in the morning


			
			
H1 CDS
david.barker@LIGO.ORG - posted 16:11, Thursday 08 January 2015 - last comment - 10:05, Friday 09 January 2015(15954)
Status of FE code for RCG2.9 upgrade

I performed a "make World" compile of all front end models. The following failed compilation:

All the failures are due to filtermodule-with-control parts with disconnected inputs (unused inputs must be grounded for RCG2.9). The compiler fails at the first error, more parts may need grounding.

 

ISI-HAM

part not grounded: HAMn_L4CINF_V1

file: isi/common/models/isihammaster.mdl

lho r8122 not modified
repo r8876 14oct2014 Stuart
llo modified r8876 03nov2014

ISI-BSC

part not grounded: OPTICNAME_ST1_L4CINF_H1

file: isi/common/models/isi2stagemaster.mdl

lho r8417 not modifed
repo r8875 14oct2014 Stuart
llo modified r8875 03nov2014

LSC

part not grounded: PSL_POWER_SCALE

file: lsc/common/models/lscpsl.mdl

lho r8741 not modifed
repo r9038 03nov2014 Joe B
llo modified r9038 03nov2014

SUS

part not gounded: <RC>_M3_LOCK_L

file: sus/common/models/RC_MASTER.mdl

This file is unique to LHO, L1 still uses the MC_MASTER.mdl

Comments related to this report
jeffrey.kissel@LIGO.ORG - 10:05, Friday 09 January 2015 (15962)
J. Kissel, D. Barker

I've grounded and committed the M3_LOCK banks RC_MASTER.mdl as requested, and committed the new version to userapps repo. Dave confirms that these now compile with RCG 2.9 as expected.
H1 SEI (SEI)
sebastien.biscans@LIGO.ORG - posted 15:42, Thursday 08 January 2015 - last comment - 15:52, Friday 09 January 2015(15944)
Tuned matching gain for the sensor correction

The sensor correction is installed and ON on all the chambers, but with a nominal matching gain of 1.

I made a small script to calculate the correct matching gain for X, Y, Z. The script works only for the HAM-ISIs for now, but it will be pretty easy to adapt. What it does:

- Grab the ground seismometer and GS13 data in X, Y, Z.

- Calculate the ASDs and calibrate them in m/rt(Hz).

- Calculate the GS13 over Ground ratio.

- Take the mean of the ratio for a [0.1Hz 0.4Hz] bandwidth.

Before running this process, the ISI needs to be in High blend mode (750mHz) on all DOFs with sensor correction OFF.

 

I've done this exercise for HAM4-ISI. The numbers seem a little small (Gain for X: 0.8784, gain for Y: 0.8702, gain for Z: 0.8574) but brings some improvement (see plot attached).

This has been done during the day, we might want to do it overnight for better tuning.

I'll do the other chambers ASAP. The script that I made is for now commited in the HAM4 folder of the svn:

/ligo/svncommon/SeiSVN/seismic/HAM-ISI/H1/HAM4/Misc/gain_matching_calculation.m

Images attached to this report
Comments related to this report
sebastien.biscans@LIGO.ORG - 15:52, Friday 09 January 2015 (15975)

After some feedback, I rearranged the script and commited it into:

/ligo/svncommon/SeiSVN/seismic/HAM-ISI/Common/Misc/HAM_gain_matching_calculation.m

What it does now:

 HAM_gain_matching_calculation(IFO,Chamber,start_time,duration)
 
. Grab the ground seismometer and GS13 data in X, Y, Z from start_time to start_time+duration.
. Calculate and plot the calibrated TF between Ground and GS13
. Take the mean of the amplitude for a [0.1Hz and 0.4Hz] bandwidth

Remember. before running this process, the ISI needs to be in High blend mode (750mHz) on all DOFs with sensor correction OFF.

I put HAM4, 5, 6 in this configuration last night and calculated the new matching gains.

 

  HAM4 HAM5 HAM6
X 0.8730 0.9280 0.96
Y 0.8619 0.9161 0.9496
Z 0.8487 0.9604 1.0189

I'll put this new numbers in the MEDM screens in a minute.

H1 AOS (DetChar, SUS)
thomas.vo@LIGO.ORG - posted 14:54, Thursday 08 January 2015 - last comment - 10:34, Friday 09 January 2015(15951)
SUS ODC BIts

Sheila, Jeff, Thomas

We changed the H1:SUS-$(OPTIC)_ODC_CHANNEL_BITMASK from 1 to 0 for all the LOCK States for the following optics:

Comments related to this report
thomas.vo@LIGO.ORG - 10:34, Friday 09 January 2015 (15963)

Added the changes to the safe.snap files in userapps, by hand,  for the respective optics above. Also committted to SVN.

H1 SUS (ISC)
jeffrey.kissel@LIGO.ORG - posted 18:49, Tuesday 23 December 2014 - last comment - 12:30, Friday 09 January 2015(15809)
H1 SUS ETMY ESD Turned ON, Linearization Force Coefficient ... Explained?
J. Kissel, R. McCarthy

At my request, after seeing that the EY BSC 10 vacuum pressure has dropped below 1e-5 [Torr] (see attached trend), Richard has turned on the H1 SUS ETMY ESD at ~2pm PST. I'm continuing to commission the chain, and will post functionality results shortly. 

Also -- 

I've found the ESD linearization force coefficient (H1:SUS-ETMX_L3_ESDOUTF_LIN_FORCE_COEFF) to be -180000 [ct]. I don't understand from where this number came, and I couldn't find any aLOGs explaining it. I've logged into to LLO, their coefficient is -512000 [ct]. There's no aLOG describing their number either, but I know from conversations with Joe Betz in early December 2014 that he installed this number when the LLO linearization was switched from before the EUL2ESD matrix to after. When before the EUL2ESD matrix the coefficient was -128000 = - 512000/4 so we was accounting for the factor of 0.25 in EUL2ESD matrix. I suspect that -128000 [ct] came from the following simple model of longitudinal force, F_{tot} on the optic as a result of the quadrant's signal voltage, V_{S} and the bias voltage V_{B}, (which we know is incomplete now -- see LLO aLOG 14853):
     F_{tot} = a ( V_{s} - V_{B} )^2
     F_{tot} = a ( V_{s}^2 - 2 V_{s} V_{B} + V_{B}^2)
     F_{lin} = 2 a V_{s} V_{B}
where F_{lin} is the linear term in the force model, and a< is the force coefficient that turns whatever units V_{S} and V_{B} are in ([ct^2] or [V_{DAC}^2] or [V_{ESD}^2]) into longitudinal force on the test mass in [N]. I *think* the quantity (2 a V_{B}) was mistakenly treated as simply (V_{B}) which has always been held at 128000 [ct] (or the equivalent of 390 [V] on the ESD bias pattern) and the scale factor (2 a) was ignored. Or something. But I don't know.

So I try to make sense of these numbers below.

Looking at what was intended (see T1400321) and what was eventually analytically shown (see T1400490), we want the quantity 
       F_{ctrl}
       -------
      2 k V_{B}^2
to be dimensionless, where F_{ctrl} is the force on the optic caused by the ESD. Note that comparing John / Matt / Den's notation against Brett / Joe / my notation, k = a. As written in T1400321, F_{ctrl} was assumed to have units of [N], and V_{B} to have units of [V_{esd}], such that k has units of [ N / (V_{esd}^2) ], and it's the number we all know from John's thesis, k = a = 4.2e-10 [N/V^2]. We now know the number is smaller than that because of the effects of (we think) charge (see, e.g. LHO aLOG 12220, and again LLO aLOG 14853).

In the way that the "force coefficient" has been implemented in the front end code -- as an epics variable that comes into the linearization blockas "Gain_Constant_In,"  (see attached) -- I think the number magically works out to be ... close. As implemented, the linearized quadrant's signal voltage is as shown in Eq. 13 of T1400490, except that the EPICs record, we'll call it G, is actually multiplied in
     V_{S} = V_{C} + V_{B}(1 - sqrt{ 2 [ (F_{ctrl} / V_{B}^2) * G  + 1 + (V_{C}/V_{B}) + (V_{C}/V_{B})^{2} * 1/4 ] )}
Note, that we currently have all of the effective charge voltages set to 0 [ct], so the equation just boils down to the expected
     V_{S} = V_{B}(1 - sqrt{ 2 [ (F_{ctrl} / V_{B}^2) * G  + 1] )}
which means that 
     G == 1 / (2 k) or k = 1 / (2 G)
and has fundamental dimensions of [V_{esd}^2 / N]. So let's take this "force coefficient," G = -512000 [ct], and turn into fundamental units:      
     G = 512000 [ct]             {{LLO}}
         * (20 / 2^18)     [V_{dac} / ct] 
         * 40              [V_{esd} / V_{dac}] 
         * 1 / (V_{B} * a) [(1 / V_{esd}) . (V_{esd}^{2} / N)]
     G = 9.5391e9 [V_{ESD}^2 / N]
   ==>
     k = 5.37e-11 [N/V_{ESD}^2]  {{LLO}}
where I've used V_{B} = 400 [V_{esd}] and the canonical a = 4.2e-10 [N/V_{esd}^2] originally from pg 7 of G0900956. That makes LLO's coefficient  assume the actuation strength is a factor of 8 lower from the canonical number. For the LHO number, 
     G = 180000 [ct]             {{LHO}}
         * (20 / 2^18)     [V_{dac} / ct] 
         * 40              [V_{esd} / V_{dac}] 
         * 1 / (V_{B} * a) [(1 / V_{esd}) . (V_{esd}^{2} / N)]
     G = 3.2697e9 [V_{ESD}^2 / N]
   ==>
     k = 1.53e-10 [N/V_{ESD}^2]  {{LHO}}
Which is within a factor of 3 lower, and if the ESD's as weak as we've measured it to be it may be dead on. So maybe whomever stuck in 180000 is much smarter than I.

For now I leave in 180000 [ct], which corresponds to a force coefficient of a = 1.53e-10 [N/V_{ESD}^2].
Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 15:33, Monday 05 January 2015 (15873)
B. Shapiro, J. Kissel

As usual, two heads are better than one when it comes to these nasty dealings with factors of two (go figure). Brett has caught a subtlety in the front-end implementation that further makes it different from the analytical approach used in T1400321 and T1400490. In summary, we now agree that the LLO and LHO EPICs force coefficients that have been installed are closer to the measured values by a factor of 4, i.e.
G = 512000 [ct] ==> k = 2.0966e-10 [N/V^2]  {{LLO}}
and
G = 180000 [ct] ==> k = 6.1168e-10 [N/V^2]  {{LHO}}
which means, though they still differ from the canonical value (from pg 7 of G0900956)
k = 4.2e-10 [N/V^2]  {{Canonical Model}}
and what we've measured (including charge) (see LHO aLOG 12220, and LLO aLOGs 14853 and 15657)
k = 2e-10 +/- 1.5e-10** [N/V^2] {{Measured}}
they're much closer. 

**I've quickly guesstimated the uncertainty based on the above mentioned measurement aLOGs. IMHO, we still don't have a systematic estimate of the uncertainty because we've measured it so view times, in so many different ways, infrequently, and with the ion pumps still valved in, and each test mass has a different charge mean, charge location, and charge variance.

Here's how the aLOG 15809 math should be corrected: The F_{ctrl} and k = a in the analytic equations is assumed to be for full longitudinal force. However, as implemented in the front end, the longitudinal force F_{ctrl} has already been passed through the EUL2ESD matrix, which splits transforms into quadrant basis force F_{ii}, dividing F_{ctrl} by 4. The EPICs force coefficient, G, should therefore *also* be divided by 4, to preserve the ratio
       F_{ctrl}            F_{ii}
       -------      =   ------------
      2 k V_{B}^2     2 k_{ii} V_{B}^2
inside the analytical linearization algorithm. In other words, as we've physically implemented the ESD, on a quadrant-by-quadrant basis,
       F_{ctrl} = F_{UL} + F_{LL} + F_{UR} + F_{LR}
where
       F_{ii} = k_{ii} (V_{ii} - V_{B})^2
and 
       k_{ii} = k / 4 = a / 4.
As such, the implemented front-end equation
       V_{ii} = V_{B}(1 - sqrt{ 2 [ (F_{ii} / V_{B}^2) * G  + 1] )}
means that
      G == 1 / 2 k_{ii} = 2 / k = 2 / a
and still has the fundamental units of [V_{esd}^2 / N]. So nothing changes about the above conversation from G in [ct] to G in [V_{esd}^2 / N], its simply that the conversion from G to the more well-known analytical quantity k was off by a factor of 4,
     G = 512000 [ct]             {{LLO}}
         * (20 / 2^18)     [V_{dac} / ct] 
         * 40              [V_{esd} / V_{dac}] 
         * 1 / (V_{B} * a) [(1 / V_{esd}) . (V_{esd}^{2} / N)]
     G = 9.5391e9 [V_{ESD}^2 / N]
   ==>
     k = 2.0966e-10 [N/V_{ESD}^2]  {{LLO}}
where I've used V_{B} = 400 [V_{esd}] and the canonical a = 4.2e-10 [N/V_{esd}^2] originally from pg 7 of G0900956. That makes LLO's coefficient assume the actuation strength is a factor of 2 lower from the canonical number, pretty darn close to the measured value and definitely within the uncertainty. For the LHO number, 
     G = 180000 [ct]             {{LHO}}
         * (20 / 2^18)     [V_{dac} / ct] 
         * 40              [V_{esd} / V_{dac}] 
         * 1 / (V_{B} * a) [(1 / V_{esd}) . (V_{esd}^{2} / N)]
     G = 3.2697e9 [V_{ESD}^2 / N]
   ==>
     k = 6.1168e-10 [N/V_{ESD}^2]  {{LHO}}
both of which are closer to the measured value as described above.
jeffrey.kissel@LIGO.ORG - 22:02, Tuesday 06 January 2015 (15905)
N. Smith, (transcribed by J. Kissel)

Nic called and fessed up to being the one who installed the -180000 [ct] force coefficient at LHO. Note -- this coefficient only is installed in ETMX, the ETMY coefficient is still the original dummy coefficient of 1.0 [ct].

He informs me that this number was determined *empirically* -- he drove a line at some frequency, and made sure that the requested input amplitude (driven before the linearization algorithm) was the same as the requested output amplitude (the MASTER_OUT channels) at the that frequency, with the linearization both ON and BYPASSED. He recalls measuring this with a DTT session, not just looking at the MEDM screen (good!). 

Why does this work out to be roughly the right number? Take a look at the front-end equation again:
      V_{ii} = V_{B}(1 - sqrt{ 2 [ (F_{ii} / V_{B}^2) * G  + 1] ) } )
and let's assume Nic was driving V_{ii} at a strength equal and opposite sign to the bias voltage V_{B}. With the linearization OFF / BYPASSED,
      V_{ii} = - V_{B}
Duh. With the linearization in place,
      V_{ii} = - V_{B} = - V_{B} (1 - sqrt{ 2 [ (F_{ii} / V_{B}^2) * G  + 1] ) } )
so we want the quantity 
      (1 - sqrt{ 2 [ (F_{ii} / V_{B}^2) * G  + 1] )} = 1
which only happens if 
      (F_{ii} / V_{B}^2) * G = 1.
If Nic wants to create a force close to the maximum, it needs to be close to the maximum of 
      F_{ii,max} = 2 k_{ii} V_{B}^2, 
which makes
      2 k_{ii} * G = 1
or
      G = 1 / (2 k_{ii}) = 2 / k
which is the same result as in LHO aLOG 15873. Granted, it's late and I've waved my hands a bit, but this is me trying to justify why it feels like it makes sense, at least within the "factor of two-ish" discrepancy between the canonical value and the accepted measurements of the right number. 
jeffrey.kissel@LIGO.ORG - 12:30, Friday 09 January 2015 (15966)
I've summarized this exploration of Linearization Science in G1500036.
H1 SEI (ISC, SYS)
jeffrey.kissel@LIGO.ORG - posted 16:29, Friday 19 December 2014 - last comment - 18:17, Sunday 11 January 2015(15756)
Bad GS13 Gain Guardian Switching vs Watchdog Loop
J. Kissel, K. Venkateswara, K. Izumi, J. Warner

While Kiwamu was trying to lock the Michelson, several things went wrong, but it uncovered a flaw in the new gain switching of the GS13s that has been implemented in the Guardian (see LHO aLOG 15537. Here's what happened.
(1) Kiwamu incorrectly brought up the BSC ISI in "fully isolated," which turns on stage 2 isolation loops, and switches the GS13s to high-gain mode.
(2) As expected, while trying to acquire MICH lock, impulses sent to the SUS BS kick the cage as well, which is attached to the BS ISI ST2, and trips the ST2 on the GS13s watchdog.
(3) We then reset the watchdog, and switched to "isolated damped," and this triggered the new guardian feature to *start* switching the GS13s back to low gain, but with MICH still trying to lock, impulses would still trip the watchdog before guardian had the chance to switch *all* of the GS13s gains. 
(4) This, trigger-happy watchdog resetting, and guardian half transitioning, caused a nasty loop of guardian sloshing the GS13 gains back and forth between high and low, which, with MICH impulses, continued to trip the watchdog.

I attach a plot of one of the WD trip, which clearly shows that the V3 GS13 had failed to have its gain switched to low. 

We should 
(a) look the new code to make sure there isn't a bad loophole regarding the GS13 gain switching when transitioning from "fully isolated" to "isolated damped"
(b) look for ways to increase the switching speed, or add a pause / check that the switch has occured on all GS13s before proceeding with the transition
(c) remember that these are physical, several thousand pound systems -- if you have to reset watchdogs repeatedly something is wrong and you don't know why, don't just blindly continue to mash the reset button, figure out what's wrong, or do what Kiwamu did and ask an expert!

#justwait
Images attached to this report
Comments related to this report
hugo.paris@LIGO.ORG - 09:40, Friday 09 January 2015 (15961)

The GAIN and DWT filters' switching mode is set to zero-crossing, with a time-out of 2s (see attachement). Even though Guardian engages the filters properly, they don’t actually switch until a certain time, causing MICH to start acquiring lock before the ISI is ready for it.

This could be solved by selecting the immediately switch mode for the GS13 GAIN and DWT filters. But, after discussing it with Jeff yesterday it turned out that he recalled switching gains with the ISO on, which would be way less stable without zero-crossing.

I modified the SEI guardian to add a 3s wait at the end of the gain switch sequence to give the filters the time they need to switch with the current zero-crossing configuration, before allowing MICH to start acquiring lock.

This fix should be tried next time we start acquiring lock on MICH.

Non-image files attached to this comment
hugo.paris@LIGO.ORG - 18:17, Sunday 11 January 2015 (16007)

Jeff, Hugo,

The SEI guardian patch I made was tested today. Jeff locked MICH while SEI_BS was in the ISOLATED_DAMPED state (GS13 in low-gain). Once MICH was locked, we switched SEI_BS to FULLY_ISOLATED (GS13s in High Gian, and ST2 Iolation loops turned on). The ISI did not trip, and MICH remained locked.

In order to make sure that this was ra reliable fix, we went ahead and switched the state of the SEI_BS node back and forth between ISOLATED_DAMPED and FULLY_ISOLATED a couple times. Once again, the ISI did not trip, and MICH remained locked.

Time series of the state of the SEI_BS Guardian node, versus the MICH error signal, are attached

 

The updated  code was commited under the SVN:
/opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/isolation/util.py     -r9543

 

Note: Jamie gave me good feedback on how to improve this new code. The goal here was to make sure it works. I will optimize it once I am back at Stanford.

Images attached to this comment
Displaying reports 68881-68900 of 84421.Go to page Start 3441 3442 3443 3444 3445 3446 3447 3448 3449 End