Stream images looks funny. Powercycled the camera and frame grabber solved the problem.
Conor, Jeff K Summary: - Conversion of ISI Suspoint motion into the DoF basis works for the arms, with limited fidelity. - Corner station DoFs seem not to work, possibly some problem with inclusion of the Beamsplitter. - IPC communication between ISI and SUS at ETMY is spoilt somehow. The GS-13s on stage 2 are used as witnesses for residual motion. Their outputs are calibrated to nm, and converted to suspension point motion using Euler matrices (Cart2Eul). The output is in the local suspension coordinates. For example, the channel 'H1:ISI-ITMX_SUSPOINT_ITMX_EUL_L_DQ' is the longitudinal motion of ITMX, which is along the normal vector pointing outward from the HR surface, in the global +X direction. These suspension point motions are IPC'd to the OAF model, and in the case of the ETMs this involves some multiplexing/AI-filtering for communication down the arm. In OAF they are combined into the IFO degrees of freedom based on T1500610 . As a sanity check, I fetched the ISI-model Suspoint channels and matrix'd them into the IFO DoFs in Matlab, for comparison with the OAF DoF channels. For the arms (XARM, YARM, CARM, DARM), things seem to be somewhat okay. I confirmed this by eye, and then took the spectrum of the subtraction (attachment 1, CARM_Spectrum). The residual is consistent with the dynamic range of single-precision floats (about 10^9), at least at high frequencies. A quick software-only transfer function using four poles at 0.1Hz and white-noise injection in a spare filter bank shows a similar total dynamic range (attachment 2, DTT_dynamic_range). The anti-imaging filters, for transmission of the ETM signals along the arm, should allow a considerably smaller residual than we see at low frequencies, and I don't really know what else might cause this. The corner station DoFs are substantially wrong, visible directly in the time series' (eg attachment 3, MICH_time_series). Since MICH only uses the ITMs (confirmed to be 'okay') and the Beamsplitter, presumably the difference arises there. PRCL and SRCL are similarly incorrect. Document T1500610 has some minor errors in the Suspoint->IFO-basis definitions, but the current matrix has correct values as far as I could see. It also points to the Suspension model versions of the Suspoint motion, eg 'H1:SUS-ITMX_M0_ISIWIT_L_DQ', but the model uses the ISI versions. Initial testing revealed discrepancies between: 'H1:ISI-ETMY_SUSPOINT_ETMY_EUL_L_DQ' 'H1:SUS-ETMY_M0_ISIWIT_L_DQ' visible in attachment 4 (ETMY_IPC_issue). The other 3 test masses didn't show this gross level of disparity.
The problem with the corner station calculations are a model mapping error. I pointed this out to Jeff but he must have thought I fixed it or he just spaced it out given his usual very full to-do list. I've never edited the OAF model and did not feel comfortable doing so. Attached is the errant part of the model. The BS PRM PR2 and PR3 are all mis-mapped in this section.
Dave, Conor, Jenne, Hugh
Jenne is fixing the mapping mis-wire for the corner station calculations.
Dave checked the data path and found the SUS and ISI versions of the CART2EUL matrix for the ETMY were not the same. This looks likely to be the issue rather than an IPC problem.
I checked the values against the data file I used to populate the matrices for all the suspensions and it still agrees. I suspect the values in the SUS ETMY matrix are out of date.
See alog 11036 for more details: Data file is
/opt/rtcds/userapps/release/isc/common/projections/ISI2SUS_projection_file.mat
Here is some detail on the GS13 signal paths. The six GS13 signals coming out of the ISI model are split, with one set going via Dolphin IPC to the SUS system, and the other set going through the ETMn_CAL into the ETMx_SUSPOINT part, in which is passes through a CART2EUL matrix. The SUS model receives the six dolphin channels, passes these through the ISIINF part, then through its CART2EUL matrix into the ISIWIT. It is these two CART2EUL matrices which have identical settings at ETMX and are slightly different at ETMY.
J. Kissel I've compiled, installed, and restarted the OAF model with the SUSPOINT to IFO basis transformation bug fix, and committed the top level model, /opt/rtcds/userapps/trunk/isc/h1/models/h1oaf.mdl Attached is a screen shot showing the current and correct channel ordering.
J. Kissel I've also updated the SUS version of the ETMY CART2EUL matrix (i.e. H1:SUS-ETMY_M0_CART2EUL channels) with the values found in /opt/rtcds/userapps/release/isc/common/projections/ISI2SUS_projection_file.mat that was apparently discrepant in only *some* of the rotational terms, and only by ~10%. I can't explain why these were off, and I'd trended the values for the past 850 days (with the stop time of June 2015, so I covered the time install time mentioned in LHO aLOG 11036) and they've not been changed. One of life's mysteries, I suppose. Fixed now! For the record, the new values are | L | | 0 -1.0000 0.2000 0 -0.2823 0 | | X | | T | | 1.0000 0 0.4294 0 0 -0.2823 | | Y | | V | = | 0 0 0 1.0000 -0.4294 0.2000 | | RZ | | R | = | 0 0 0 0 0 -1.0000 | | Z | | P | | 0 0 0 0 1.0000 0 | | RX | | Y | | 0 0 1.0000 0 0 0 | | RY |
Also, I posted some analysis of the relative motion between HAM2 and HAM3 in the DCC https://dcc.ligo.org/G1601390 differential Z is really small. differential X kind of sucks at the microseism. Not sure how much it matters for the IMC, but it is worth thinking about. I think there is some fruitful work to be done here - if it would be useful to reduce the relative motion of the ISI tables in the corner at the microseism.
Wrote a a new guardian (VIOLIN_DAMPER.py in /opt/rtcds/userapps/release/isc/common/guardian/) that can figure out the best damping phase for the violin mode damper. (This automates a usually very boring task.)
The code relies on each modal damper filter module being set up the same way, with a narrowband filter in FM1, a -60deg filter in FM2 and a +60deg filter in FM3. This setup allows setting the feed-back phase in 60deg increments. E.g. 240deg = negative gain & +60deg filter.
The code loops through the 6 possible phase settings (0deg,180deg,60deg,240deg,120deg,300deg). For each setting it waits for the filter to settle, takes a peak reference value of the mode strength, then waits for a specified time and measures the mode strengh again, calculating the after/before ratio. If the mode grows too fast, the code stops earlier to avaoid a runaway, and procedes to the next phase setting.
After loopig through all settings, it sets the module to the best daming setting.
This seems to work reliably as long as we are not hampered by closely neighbouring modes, and should reduce the repetitive work in modal damping.
As example, I attached the output of the Guardian when it was applied to SUS-ITMY_L2_DAMP_MODE8. Plot 1 shows the violin mode strength over the 15min the code ran, screen shot 2 shows the Guardian message output.
We had an episode of really large beam motion at about 0.6Hz on OMC QPDs as well as OMCR QPDs but not on ASC_AS_C nor AS WFSs. It was very very slow to damp, and at some point it didn't damp further. It was clear that the OMC or OM3 was moving, but the motion didn't show up on none of OMC and OM3 OSEMs. But the OMC SD and RT OSEMs were super noisy.
On inspecting the spectrum of OSEMs, it was clear that the SD and RT OSEMs of OMC had a large broad band noise, the signature of the satellite amp oscillation. However, the difference is that we couldn't see the oscillation in kHz range even using the 16kHz channel (sorry no screen shot). Maybe the oscillation frequency got higher?
Anyway, apparently it has been like that since power outage (attached). Though it's not shown in the spectrum, we confirmed that the broadband noise was there every day after the power outage.
We disabled the OMC damping and the beam motion on OMC QPD immediately got quieter.
We went to the floor and power cycled the satellite amp for RT/SD of OMC (they're on the same box, everything else is on another one), and the noise went away.
Turned on the damping again and it worked fine, no excessive beam motion.
Apparently this happens even though all satellite amplifiers are "fixed". It's worth checking all OSEMs for all optics.
I made a PDF with spectra of all of the OSEMs. The green trace is after the power outage, the black is a reference time before. I used the same times as in Jenne's alog. There's a turn-up in some quadrants of ETMX L2 at high frequency. IM3_M1_LL has a big broadband noise increase. ITMX L2 has a new peak at 3 Hz in all quadrants (it might be worth checking with faster channels in case this is aliasing). ITMY_L2_LR has a turn-up at high frequency. MC1_M3_UL has a small broadband noise increase. Obviously OM1, OM2, and OMC look terrible. PRM_M2_UR has a broadband noise increase. SR2_M1 LF and T1 look like they might have started glitching (bouncy shape in the spectrum). A bunch of channels also have excesses at low frequency, but I don't know if that's a change in physical motion, or maybe it's a result of other things being unstable.
Sheila, Cheryl, Haocun
We re-centered the WFS A and B this afternoon to fix the misalignment (alog27792). Both of them are centered around (0,0) now and we took measurements on the IMC.
The spectrum (measured at test 1) and transfer function (with 20dB gain) of the IMC were taken both before and after re-centering, but there were nearly no differences between them.
For the spectrum, several peaks are:
-55.5 dBm/Hz @ 197.5kHz
-85 dBm/Hz @ 87.5kHz
-83.7 dBm/Hz @ 25kHz
For the Transfer Function:
UGF @150kHz, and we have a bump close to 0dBm at higher frequency.
IMC loop gain measurements should always go up to 5 MHz. There can be EOM resonances as high as 2.5 MHz which, if unmonitored, can poke up and make another unity gain crossing.
Jenne, Nutsinee Sheila
We had trouble with locking the arm in IR for inital alingment, because PSL-POWER_SCALE_OFFSET was different from the input power. We added a statement to the "IDLE" run state of LASER_PWR (the generator of states when not changing the power) that will adjust the normalization if it is more than 0.5Watts wrong.
if abs(ezca['PSL-POWER_SCALE_OFFSET'] - ezca['IMC-PWR_IN_OUTMON'])> 0.5:
ezca['PSL-POWER_SCALE_OFFSET'] = ezca['IMC-PWR_IN_OUTMON']
I came to the realization, this fine Monday morning, that this was my fault. I adjusted the laser power down from 25W to 2W without using the PSL Guardian node. Lesson learned. Apologies to those involved in the solution for taking the time to discover and fix MY "oops".
I checked the pickoff mirror, IO_MCR_M14, that I installed on the MCR path on IOT2L (see alog 27725), which picks off the p-pol beam and sends it to a beam dump. I found that with a locked IMC, the edge of the p-pol beam was getting past the pickoff mirror, so I adjusted the mirror position about 1mm toward the main beam. By IR card, there's about 3mm between the p-pol beam and the main s-pol beam where the pickoff is installed, so enough clearance that the pickoff mirror should not clip the main beam.
15:00 Krishna out to EY to re center BRS. Also Chris went to EX to check on the wind screen construction; back inside 30 minutes.
16:30 Chandra at MX performing manual overfill of CP5. Wanred me about ensuing alarms.
16:45 Dave B called to ask me about the aforementioned alarms.
17:14 Schofield and co. into CER
18:17 Sheila and Haocun out to ISCT1 to center POP wavefront sensor that is railing
18:27 Sheila and Haocun out.
20:19 Sheila out to LVEA to take some IMC measurements
20:21 Cheryl out to IOT2L
20:24 Karen to optics lab for cleaning
20:45 Karen out of the optics lab
21:05 Keita out to IMC area
21:12 Kyle into LVEA to retrieve a meter by HAM4
21:16 Keita back
21:17 Kyle out
21:26 Gerardo to MX
22:29 Cheryl/Haocun/Sheila back from aligning IMC WFS
22:40 Initial Alignment
Now for the excessive detail.
Before the last couple of months work, we thought that for the end station ISI's, we should use the Quite_90 blends and the Mitt_SC broadband sensor correction. A couple of months ago, Krishna pointed out that the Mitt_SC filter was probably insufficiently rolled off at low frequency, where the BRS actually makes the STS/BRS supersensor worse. There have been a number of iterations on sensor correction filters, but I think we now have a good filter. The first attached images shows a few of the filters we have tried, I won't go through them all, but the dark blue is the Mitt SC filter of old, and the cyan is what we are using currently. The other two are filters that we've tried and discarded, for various reasons,and there are many more in the foton files, but I'm tired of plotting them.
Around the same time, I realized that using the Quite_90 blend may not roll off the ISI T240's quickly fast enough at low frequency to avoid injecting platform tilt and that we should use a higher blend, at least while the microseism is low. Currently we're using the Quite_250 blends for a high blend, but there may be room for optimization there.
The next plot is the estimated supprestion of the "old" BRS configuration (the Mitt_SC filter, Quite_90 blend), the "new" SC/blend configuration (Warn_SC_v3, Quite_250 blend), and a couple relevant CPS blend filters (which are a good first approximation to the low frequency performance, without sensor correction). JeffK has a log (594) in the seismic log that explains this estimation of the expected sensor correction performance, for those interested.
We know from experience the 45mhz blends are hopeless in 10+ mph winds but suppress the microseism well, and the Quite_90 are okay in winds to 20 mph, but are no good in high (~>.5 micron BLRMS) microseism. I've tried using the Quite_250 blends alone with low microseism, but I think the motion around the first TM modes was too high (the spots on the AS port were moving around a lot at something like .5hz). The new configuration has allowed us to lock in 30-40mph winds (and lower), but microseism is very low. Based on the the simple model used in the second plot, it should do better than the Quite_90 blends alone in high microseism. It even looks like it should do better that the 45mhz blends at the secondary microseism (.150 hz), but the gain peaking is right on top of the primary microseism (~30-80mhz), which we don't see often.
The gain peaking of the new configuration looks like it would be worse than either the 45mhz blends or the Quite_90s, but this model doesn't include platform tilt, which is filtered out by using a higher blend on the ISI and a tilt-subtracted STS ( at the ETM's) or a low tilt STS ( ITMY) for sensor correction. I think Krishna showed that this "new" configuration is in practice better, in his alog 27735.
LLCV bypass valve 1/2 turn open, and the exhaust bypass valve fully open.
Flow was noted after 52 seconds, closed LLCV valve, and 3 minutes later the exhaust bypass valve was closed.
After Sheila's log about the BS causing locklosses, I wanted to check a few things in the guardian code and I found what looks like conflict in the code. In /opt/rtcds/userapps/release/isi/h1/guardian/ ISI_BS_ST2.py, line 4
ISOLATION_CONSTANTS['CART_BIAS_DOF_LISTS'] = ([ ] , [ ])
the empty brackets at the end indicate the ISI is not set to restore any Cartesian locations. This is supposed to be the code that sets what dofs are restored when the ISI re-isolates, and is particular to the beamsplitter.
However, in /opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/isolation/ CONST.py lines 102 (for BSC ST1) and 122 (for BSC ST2) both read
CART_BIAS_DOF_LISTS = ([], ['RZ']),
CONST.py is common code, and I would interpret this to mean that all BSCs are restoring a stored RZ location. This isn't a problem for the other BSCs, because they never change state, but if we turn on the ST2 loops for the BS, this code could force the ISI to rotate some after the loops come on. The attached trend shows the last ten days of the BS ST2 RZ setpoint and locationmon, and they track each other, so I dont think the BS is returning to some old RZ location, but someone who understands this code should explain it to me.
The CART_BIAS_DOF_LIST in the common code you could say is the "default" setting, but can be overwritten by the chamber node's local file (as is done here). The two empty lists in the local file show that there are no cartesian bias degrees of freedom being being restored.
A quick "grep CART_BIAS ./*.py" in (userapps)/isi/h1/guardian/ yields:
./ISI_BS_ST1.py:ISOLATION_CONSTANTS['CART_BIAS_DOF_LISTS'] = ([], [])
./ISI_BS_ST2.py:ISOLATION_CONSTANTS['CART_BIAS_DOF_LISTS'] = ([], [])
./ISI_ETMX_ST1.py:ISOLATION_CONSTANTS['CART_BIAS_DOF_LISTS'] = ([], [])
./ISI_ETMX_ST2.py:ISOLATION_CONSTANTS['CART_BIAS_DOF_LISTS'] = ([],[])
./ISI_ETMY_ST1.py:ISOLATION_CONSTANTS['CART_BIAS_DOF_LISTS'] = ([], [])
./ISI_ETMY_ST2.py:ISOLATION_CONSTANTS['CART_BIAS_DOF_LISTS'] = ([],[])
./ISI_HAM2.py:ISOLATION_CONSTANTS['CART_BIAS_DOF_LISTS'] = ([], ['X', 'Y', 'Z', 'RX', 'RY', 'RZ'])
./ISI_HAM4.py:ISOLATION_CONSTANTS['CART_BIAS_DOF_LISTS'] = ([], ['X', 'Y', 'Z', 'RX', 'RY', 'RZ'])
./ISI_HAM5.py:ISOLATION_CONSTANTS['CART_BIAS_DOF_LISTS'] = ([], ['X', 'Y', 'Z', 'RX', 'RY', 'RZ'])
./ISI_HAM6.py:ISOLATION_CONSTANTS['CART_BIAS_DOF_LISTS'] = ([], ['X', 'Y', 'Z', 'RX', 'RY', 'RZ'])
./ISI_ITMX_ST1.py:ISOLATION_CONSTANTS['CART_BIAS_DOF_LISTS'] = ([], [])
./ISI_ITMX_ST2.py:ISOLATION_CONSTANTS['CART_BIAS_DOF_LISTS'] = ([],[])
./ISI_ITMY_ST1.py:ISOLATION_CONSTANTS['CART_BIAS_DOF_LISTS'] = ([], [])
./ISI_ITMY_ST2.py:ISOLATION_CONSTANTS['CART_BIAS_DOF_LISTS'] = ([],[])
So it seems that we only restore the bias on HAMs 2,4,5,6. Doing this for L1 shows all empty lists, if the version we have is up to date.
After talking to JIm, he suggests that we change the "default" value to be an empty list, to avoid any possible future mishaps. Just to reiterate though, it is currently not restoring any biases on any of the BSCs, only HAMs 2,4,5,6.
TJ's analysis is correct: the default is what's defined in the isiguardianlib/isolation/CONST.py, which currently specifies that the RZ cart bias should be restored during the second phase of the isolation.
You can change the default in the CONST.py, but any change has to be well corrdinated with LLO, since that configuration is common for them as well.
TJ missed HAM3 in the list of platforms restoring biases. This miss of the grep is likely from some h1 files being in the common area rather than the H1 directory.
Raised CP5 Dewar pressure (3/4 turn at pressure regulator + 1/4 turn yesterday). Will take days to read a pressure response. Current pressure is 17.5 psi in tank and 15 psi at exhaust. Also filled CP5 to 100% with 1/2 turn open on LLCV bypass valve.
CP5 "setting % open" has been shifting upward. The vacuum team is working to try to get it under control. Last week such setting was around 88% now is oscillating around 100%.
Note to operators if "cryopump level % Full" falls below 88% it will be very hard for the current system to bring it up to nominal (92%), if it does reach that point, feel free to call a member of the vacuum team, the cryopump will need manual filling.
Trend data.
I am also monitoring from home - I don't think that there are "operators" working the weekends(?)
Evan, Stefan
We didn't get past the ASC engaging tonight.
The one thing that clearly improved stability was setting the MC2 cross-over up by 4dB - before that even the slightest disturbances kicked the x-over into an oscillation.
After that fix, we at least didn't have any more immediate losses.
However, the current ASC engaging logic doesn't work. It also doesn't seem to make much sense. We have convergence checkers, but they are currently used before all loops are closed. Thus we wait for one loop to drag us off into some direction, only for the next loop to come on and load up the previous loop again.
What changed? The MC crossover only depends on the actuator strength ratio between MFC and MCL.
Peter, Sheila, Evan
We have been having trouble keeping the IMC locked when powering up (without the interferometer).
We found that the UGF of the loop was something like 110 kHz. During O1, we ran with a UGF that was more like 50 kHz. Recall also that the IMC loop at one point had some questionable resonance features above 100 kHz, so it is probably in our interest to keep the UGF on the low side (though we should confirm this with a high-frequency OLTF measurement).
We turned down the loop gain by 4 dB, giving a UGF that is more like 60 kHz. We were able to power up from 2 W to 23 W without lockloss.
Attached is an OLTF measurement after turning down the gain. As usual, the last point is garbage.
To keep the IMC length crossover stable in full lock, Stefan and I increased the gain by 7 dB. This brought the crossover form 16 Hz (nearly unstable) to 40 Hz (stable).
In fact the right way to compensate for the decreased electronic IMC gain is to also decrease the AO gain (not the MCL gain). Now both are decreased by 4 dB.
C. Cahillane I have revamped the uncertainty budget to include covariances between all stages of actuation and all time-dependent parameters. I computed each parameter's covariances in real and imaginary coordinates to provide a consistent basis. I then compiled an6 x 6Actuation Covariance MatrixC_A, a2 x 2Sensing Covariance MatrixC_S, and an8 x 8Kappa Covariance MatrixC_K. Then I compile them into a giant covariance matrixC:_ _ | C_A 0 0 | C = | 0 C_S 0 | |_ 0 0 C_K _|Then, I multiply by some conspicuous Jacobian vectorsJ(f)to get the final2 x 2uncertainty matrix σ_R^2(f):σ_R^2 = J * C * J'whereJlooks like:_ _ | d Re(R) d Im(R) | | --------- --------- .... | | d Re(p_i) d Re(p_i) | J(f) = | | | d Re(R) d Im(R) | | --------- --------- .... | |_d Im(p_i) d Im(p_i) _|(I was able to use complex differentiation and Cauchy-Riemann here to make the derivatives easier. Recall that R = 1/C + D*A. Now I can compute dR/dA = D and dR/dC = -1/C^2 to formJ(f), thanks to 200 year old mathematics) Finally, to make the uncertainties readable by humans, I divideσ_R^2(f)by|R(f)|^2, rotateσ_R^2(f)byangle(R(f))via a rotation matrix, and read off the square roots of the diagonal of the rotatedσ_R^2(f)to get the magnitude and phase uncertainties plotted below. I have plotted the uncertainty at GPSTime = 1135136350, the time of the Boxing Day Event. The plot shows an overall increase in magnitude uncertainty of about 1% at low frequency. Phase uncertainty increased by about 0.5 degrees at low frequency. The effects are more dramatic at Livingston. Check out LLO aLOG 26542.
C. Cahillane I have reproduced the uncertainties including covariance for GW150914 for the calibration companion paper. We will have to update the associated uncertainty calculation sections of the paper. I have also attached two .txt files for the R_C01/R_C03 response comparison and the associated uncertainty. Something I failed to emphasize above: Our uncertainties in the response function are now fully covariant... the plots I show of the magnitude and phase are only approximations to the true uncertainty. I have looked at the 3D plots of the covariant ellipses, and it's a fairly good approximation in this case.
C. Cahillane
I have attached and printed my relative covariance matrix. Please see DCC T1600227 for an explanation of the relative covariance matrix.
Basically, the below is percentage covariances.
Re(A_U) Im(A_U) Re(A_P) Im(A_P) Re(A_T) Im(A_U) Re(C_R) Im(C_R) Re(K_T) Im(K_T) Re(K_P) Im(K_P) Re(K_C) Im(K_C) Re(f_C) Im(f_C)
Re(A_U) 0.0166 0.0083 0.0139 0.0079 0.0146 0.0067 0 0 0 0 0 0 0 0 0 0
Im(A_U) 0.0083 0.0209 0.0091 0.0169 0.0071 0.0178 0 0 0 0 0 0 0 0 0 0
Re(A_P) 0.0139 0.0091 0.0163 0.0052 0.0157 0.0066 0 0 0 0 0 0 0 0 0 0
Im(A_P) 0.0079 0.0169 0.0052 0.0181 0.0057 0.0156 0 0 0 0 0 0 0 0 0 0
Re(A_T) 0.0146 0.0071 0.0157 0.0057 0.0251 0.0047 0 0 0 0 0 0 0 0 0 0
Im(A_T) 0.0067 0.0178 0.0066 0.0156 0.0047 0.0187 0 0 0 0 0 0 0 0 0 0
Re(C_R) 0 0 0 0 0 0 0.0207 0.0079 0 0 0 0 0 0 0 0
Im(C_R) 0 0 0 0 0 0 0.0079 0.0208 0 0 0 0 0 0 0 0
Re(K_T) 0 0 0 0 0 0 0 0 0.0025 -0.0002 0.0019 -0.0018 -0.0004 0 0.0004 0
Im(K_T) 0 0 0 0 0 0 0 0 -0.0002 0.0025 0.0017 0.0019 0.0001 0 0.0001 0
Re(K_P) 0 0 0 0 0 0 0 0 0.0019 0.0017 0.0035 -0.0003 0.0002 0 -0.0003 0
Im(K_P) 0 0 0 0 0 0 0 0 -0.0018 0.0019 -0.0003 0.0035 0.0006 0 -0.0005 0
Re(K_C) 0 0 0 0 0 0 0 0 -0.0004 0.0001 0.0002 0.0006 0.0037 0 -0.0036 0
Im(K_C) 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Re(f_C) 0 0 0 0 0 0 0 0 0.0004 0.0001 -0.0003 -0.0005 -0.0036 0 0.0054 0
Im(f_C) 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Jenne, Peter, Jeff, Terra
We took charge measurements on the ITMs by driving 20.1 Hz into H1:SUS-ITMX/Y_L3_DRIVEALIGN_L2L_EXC with 100k cts and looked at the coupling to DARM. We stepped up and down the ESD bias voltage from zero and found the bias that gave zero coupling to get charge measurements, where Vcharge= (20/218) * bias * 40. ITMX zeroed with bias = 3k, ITMY zeroed with bias = 2.5k. See bias stepping ITMX and ITMY spectra attached.
ITMX charge: 9.15 V, ITMY charge: 7.6 V
ITMX:
| BIAS offset | RMS AMPL (m) | PEAK AMPL (m) | PHASE (deg) |
|---|---|---|---|
| 0 | 4.9x10-15 | 6.9x10-15 | 37 |
| 50K | 7.6x10-14 | 1.1x10-13 | -142 |
| 100K | 1.6x10-13 | 2.6x10-13 | -142 |
| -50K | 8.5x10-14 | 1.2x10-13 | 38 |
| -100K | 1.7x10-13 | 2.4x10-13 | 38 |
ITMY:
| BIAS offset | RMS AMPL (m) | PEAK AMPL (m) | PHASE (deg) |
|---|---|---|---|
| 0 | 5.4x 10-15 | 7.6x10-15 | -142 |
| 50K | 9.3x 10-14 | 1.3x10-13 | 38 |
| 100K | 1.9 x 10-13 | 2.7x10-13 | 38 |
| -50K | 1.0 x 10-13 | 1.4x10-13 | -142 |
| -100K | 2.0x 10-13 | 2.8x10-13 | -142 |
Approximating alpha: The first term in the expression for the force produced by the ESDs is the attractive force between the ESD fringe fields and the test mass: F = alpha(Vbias - Vsignal)2, where alpha is a constant of proportionality. With the known bias voltage Vb, signal drive voltage Vs, drive frequency f, and now the peak amplitude xpp , we used the largest bias offset (100k) to approximate alpha for both ITMs. Work is attached.
ITMX: alpha = 1.78 x 10-11 N/V2, ITMY: alpha = 1.85 x 10-11 N/V2
These LHO ITM force coefficients agree with LLO's. Using Valera and Den's 2015 measurements (and assuming an 80 Hz ESD drive), I calculated alpha for LLO ITMX: alpha = 1.46 x 10-11 N/V2