This is a temporary setup needed to operate the RGA at BSC8. These are rack mount crate type units but I have them stacked on the LVEA floor (south side of BSC8). If these interfere with commissioning tonight, feel free to turn them off. Otherwise, please them on.
8:15 – 8:40 Installation Meeting Minutes 8:45-10:13 ESD drive work at EndY – Richard/Filiberto 9:09 – 10:19 Heading to EndY/MidY for cleaning – Karen 9:12- 12:00 ISI work (table balancing) on HAM5 – Hugh 9:27- 11:27 TCS Hartman table work continues – David 9:55- 11:42 Contamination & control activities at HAM6 – Jeff B. 10:25- 12:00 Heading into the LVEA (West bay) Inventyory – Jody 11:12- Going to End Y to work on WFS – Keita 11:53 LVEA transitioned to LASER HAZARD – Justin 12:58- 14:55 Back to LVEA for TCS work – David 13:00- 15:22 Heading to work in LVEA (West bay) – Betsy/Travis 13:45- 15:36 Heading back to HAM5 – Hugh 12:47- Heading to Endy/EndX to intall ESD grounding – Aaron LVEA is Laser HAZARD!
The corner whitening filters were not switching, with an error message invalid data chn and readback different for Refl 9 and refl air 9, and for POP we had an error message invalid data for channels 1, 2, 3 and 4.
Daneil fixed this by going to the system manager for the corner, finding the X gateway under device 1, corner MSR L0, Corner MSR L8_9 Vertex, going to the Online tab, and clicking on several of the buttons under state machine (Init, pre-op, safe op, op) in an order that seemed random to me.
I am just writing down the solution to this problem so that we can look it up next time it happens.
Jeff B reported that the OSEM speed-dial screens were not working on the QUAD test stand. A bit of poking showed that the sitemap1 alias invoked
/opt/rtcds/tst/x1/userapps/release/cds/x1/medm/X1SITEMAP.adl
The Display File field for the QUAD button on that screen invoked
/opt/rtcds/tst/x1/userapps/release/sus/x1/medm/quad/SUS_CUST_QUAD_OVERVIEW.adl
but the Arguments field included
SUSDIR=/opt/rtcds/tst/x1/cds_user_apps/trunk/sus/common/medm/quad
which references a newer set of files where all the speed-dials have been renamed from SUS_CUST_QUAD_M0_OSEM_ALIGN.adl and the like to SUS_CUST_QUAD_M0_CENTERING.adl etc.
I changed the SUSDIR and it now works. I also had to manually load the safe.snap file to get all the matrix elements and gains filled in.
Removed 106kg from Stage1 including 20kg from Table top. Wall payload went from 125 to 40kg in addition to removing 2 10kg masses from table top. Lone table top mass at +X, -Y area gone, viton damping of Table Top masses still to go. When we balanced the table before any SUS went in, we had 810lbs on the table top (iLIGO & aLIGO stuff.) This was removed, table top balance mass added per D1001139, SUS adds SRs, OFI, & Baffles. Not sure what the projected payload was going to be on the table but this indicates it is 302kg. Sound good? Anyone care about how the mass distribution has changed? How about the poor distribution of the Table Top 1075s for damping?
Several questions have come up over which wipes to use, when to use them, and where to use them. This table should clarify and answer these questions:
1. In chamber cleaning
Pre-soaked Vectra Alpha 10
Vectra Alpha 10
2. Glove cleaning
Pre-soaked Vectra Alpha 10
Vectra Alpha 10
3. Gross cleaning - up to and including clean-room walls / outside of chamber
Valutek pre-soaked wipes
4. Daily wipe-down of work surfaces, drying clean parts
Contec PNHS99
5. Back up if out of Vectra Alpha 10 (or have heavy inventory)
Contec PNHS99
Kyle noticed that the web MEDM snapshots had stopped when script0 has issues yesterday at 6pm PDT. I have restarted them after the reboot of script0.
Installation Meeting Minutes 8:15-8:40 Fred, Richard, Aaron, Gerardo, Jeff B, Vern, Bubba, Travis, Hugh, Mitchell, Mike, Arnaud, Thomas, Daniel, David, Corey, etc. • Went over Work Permits • Work on HAM5 ISI (table balancing) – Hugh • BK hammering test on SR3/SRM suspensions (HAM5) – Arnaud • TCS work continues - David • Sled getting ready to be moved to HAM6 – Dan/Corey • Quad upper structure work in LVEA (West Bay) – Travis/Betsy • ESD driver work at End Y – Richard/Filiberto • Staging building activities ongoing – Mitchell/Scott LVEA is Laser SAFE
Moday and Tuesday, no restarts reported. Maintenance was deferred until the vent.
script0 was not running correctly, we ended up rebooting it via the front panel reset button.
Sheila, Lisa
Previous alignment positions were not saved correctly, apparently, so when the Guardian was restarted today we lost our references.
Daniel had recovered a good green alignment for both arms, but the IR beams where not very well aligned. We tried to look at the PRMI anyway but we realized that it was very misaligned and far from locking. Since a good alignment for IR had not been done in a while, we decided to realign everything from scratch.
Unfortunately we have been tripping SUS/ISIs several times today by engaging ALS DIFF during this alingment process, and as Arnaud reported, we were misaligning the X arm again with every kick..so the whole process took a while.
We leave the X arm with both green and IR aligned; the Y arm is ok fro green, but not for IR.
More alignment tomorrow..
On a positive side, we used dither + green WFSs for the X arm several times today, and we could consistently achieve a good alingment for green.
I accidentaly sent a transient to the suspension. It makes sense that we loose lock when I do something like that, and we give the suspension a kick, but it doesn't seem like this should trip the ISI.
There was an error, most likely from a divide by zero somewhere in the corner beckhoff. I reset all (including persisent variables) a few times, and then did a burt restore to 4 pm.
[Sheila Lisa Jeff Arnaud]
Sheila and Lisa were having alignment issues in the X arm this afternoon, in the sense that some fine alignment was always needed after recovering from a lock loss. A good example is shown in the attached screenshot. In that case, diff lost lock, and kicked both etmx and etmy suspensions (top right plot showing the diff error signal in purple). At that point the green transmitted power in the X arm (bottom left plot) dropped to 0, and came back to 0.5 after the test mass settled down (instead of expected 1). This was due to the alignment : comparing the pitch of the test mass with the oplev before and after the event, we see that etmx pitched down by ~1.5urad (left middle plot in green). Neither ISIs HEPIs SUS were tripped during those times, the Ry DC values (corresponding to sus pitch) from ST1 ST2 ISI and HEPI were identical, etmx yaw was identical, itmx pitch and yaw were similar.
Sheila then used itmx (bottom right plot in yellow) to realign the cavity, pitching it by ~1.5urad which was just enough to bring the transmitted power back to 1 (bottom left plot in red).
It would be interesting to know if this is what happens all the time.
Wrong login, this was me.
Can you check if the ETMX keeps pitching down from lock to lock, or if it just snaps back? We are actuating to the top mass, so it is conceivable that a lock loss changes the alignmement through the relief of the length actuation. The problem is that the new alignment scheme feeds back to the PZT which will not snap back, but would follow an alignment drift over time when locked.
2 hour graph of X-arm locking with WFS off. Power drops to 0.5 in about an hour due to length to angle coupling. The tidal motion is about 60µm/h. The effect is clearly seen in ETMX YAW and to a lesser degree in PIT. ITMX yaw is flat. What's going on with ITMX PIT? No external drive was sent to ITMX.
Both were T240 trips. There isn't a clear reason, the tour hasn't started yet, the door work is finished.
Something was tilting the platform
J. Kissel The Messages: (1) The effective bias voltage charge on the test mass is -28 [V_pk], which quite small compared to the BIAS range of 400 [V_pk] (and in conflict with Keita's assessment from the optical levers [see LHO aLOG 11905]). (3) The force actuation strength is asymmetric with respect to bias voltage, confirming Keita's result (see LHO aLOG 11872) (2) The force coefficient at 11 [Hz], measured as a function of bias voltage, is roughly 0.5e-10 [N/V^2], a factor of 8 below the expected 4.2e-10 [N/V^2] (expected from pg 7 of G0900956) DETAILS ------------- Brett: please proof read: ------------- Note, no linearization algorithm was used during this experiment. (1) Using the time-honored MIT method of measuring test-mass charge (e.g. from Brett, John, and Lisa), I drove a single frequency line into the control voltage H1 SUS ETMX ESD drive, looking at the X arm cavity length (as measured by green), while stepping the bias voltage through its entire range. As one steps down the bias voltage, we expect the linear response to drop to zero. Further, one can take the slope of the response as the bias decreases from both the positive and negative side and predict an effective bias voltage created by residual charge on the test mass. I attach the results. Using a linear regression, weighted by the coherence as follows, unc = sqrt( (1 - coh) / 2*nAvgs*coh ) weight = 1 / unc^2; I calculated the intersection of the two slopes to be -27.99 [V_pk]. I took an excessive amount of data points, because I didn't know what I was doing when I started and wasn't sure how the results would turn out. The template is here for excitation: /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGL3/Data/2014-05-15_H1SUSETMX_L3_ChargeTest.xml For the record, I tried using the script recommended by Brett (LHO aLOG 11914), but after updating all the necessary channel names and input variables. it failed deep with in its subfunctions because of some xmlconv library that's now gone missing since 2009. I didn't have the time nor expertise to debug, so I just changed the bias by hand and measured the ten averages with the GUI DTT session, capturing references as I went, and exported at the end for processing. (2) No further details here, it's obvious that the drive strength is weaker with positive bias voltage than with negative. I have no good explanation for this. (3) From these displacement response results, one can also obtain the force coefficient for each bias step. The calculation is as follows: disp_mpk = 1e-12 * sqrt(2) * sqrt(binWidth) * disp_pmrtHz; force_Npk = disp_mpk * 1./compliance_11Hz.mpN; V_CTRL.Vpk = nActs * sqrt(2) * sqrt(binWidth) * esdGain * excChannel.amplitude.V_DAC.VrtHz; V_BIAS.Vpk = bias.V_ESD; forceCoefficient = abs(force_Npk ./ (2*V_CTRL.Vpk * V_BIAS.Vpk)); where disp_pmrtHz = displacement response of the arm cavity length at 11 [Hz] during each bias voltage setting, in [um] (which I subsequently turned into [pm] for plotting clarity) as measured from the calibrated ALS control signal, H1:ALS-X_REFL_CTRL_OUT_DQ sqrt(2)*sqrt(binWidth) = sqrt(2)*sqrt(0.09375 [Hz]), calculation needed to change from noise units ?_{rms}/rtHz to amplitude units of ?_pk 1e-12 = 1e-12 [m/pm] compliance_11Hz.mpN = 5.3e-06 [m/N], TST to TST, L to L transfer function at 11 [Hz], obtained from the QUAD model. excChannel.amplitude.V_DAC.VrtHz = 12.45 [V/rtHz], measured output request voltage from the DAC (calibrated from counts out of the digital last output to ESD, i.e. H1:SUS-ETMX_L3_MASTER_OUT_LL_DQ using the 180bit DAC gain, 20/2^18 [V/ct]) esdGain = 40 [V/V], gain of the ESD driver sqrt(2)*sqrt(binWidth) = sqrt(2)*sqrt(0.09375 [Hz]), calculation needed to change from noise units ?_{rms}/rtHz to amplitude units of ?_pk nActs = 4, since the calibrated output requested voltage is only from one channel. and I've computed the force coefficient, a, using only the linear term, since I used the amplitude of the linear term alone F = a (V_CTRL sin(wt) - V_BIAS)^2 = a V_CTRL^2 sin^2(wt) - 2 a V_CTRL V_BIAS sin(wt) + a V_BIAS^2 [ sin^2(wt) = 1/2 - 1/2 cos(2wt) + O(4w) ] = a(V_BIAS^2 + 1/2 V_CTRL^2) - 2 a V_CTRL V_BIAS sin(wt) + - 1/2 a V_CTRL^2 cos(2wt) DC Term Linear Term Bi-linear Term =>> Linear Term, a = F (2 V_CTRL V_BIAS) Confusingly, this resulting coefficient, a = 0.5e-10 [N/V^2] is a factor of 8 weaker than expected, which is *different* than the factor of 4 weaker that was needed to explain the linear transfer functions taken last week (see the second attachment of LHO aLOG 11676). The script that processes the measurements is here: /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGL3/Scripts/analyzeesdcharge_20140515.m
Jeff, This is getting pretty mysterious. Suggest that you try to establish whether you actually can see the capacitance change with relative motion of the test mass with respect to the recoil mass in each ESD quadrant. The bridge circuit would be a good way of doing this. I will be at LHO starting Monday and could help out with the measurement. One explanation is that you do not really have a solid connection to either the bias or the control electrodes - an open connection with either only capacitive coupling or a high resistance. RW
Jeff, 1 piece of good news - this amount of voltage implies that the isolation performance is probably not compromised by the charge. Long ago I did a rough estimate for how much charge could be on the optic in a blob near the tip of the earthquake stop. https://dcc.ligo.org/T080214 Although the field gradient is the important thing, and this is a function of both of the amount of charge and the spatial distribution there-of, one can say the if the blob is about the size of the stop, then the voltage of it is about 140 V before it compromises the isolation performance. -Brian
J. Kissel, B. Shapiro, Brett has caught a mistake in my calculations above, in that I *should not* multiply the control voltage, V_CTRL.Vpk, by a factor of four (i.e. nActs). My thoughts on including the factor of four were that I was measuring the requested DAC output of *one* quadrant, and since there're 4 quadrants, I add the force created by each of them. However, given how the force coefficient was defined for all four quadrants, it's better to think of each of the four quadrants creating a ring of control voltage, all held at the same requested value. It's then the potentional difference between this control ring and the bias ring that generates the forces on the test mass. Hence the caluclation for the force coefficient should be disp_mpk = 1e-12 * sqrt(2) * sqrt(binWidth) * disp_pmrtHz; force_Npk = disp_mpk * 1./compliance_11Hz.mpN; V_CTRL.Vpk = sqrt(2) * sqrt(binWidth) * esdGain * excChannel.amplitude.V_DAC.VrtHz; V_BIAS.Vpk = bias.V_ESD; forceCoefficient = abs(force_Npk ./ (2*V_CTRL.Vpk * V_BIAS.Vpk)); (Thanks for the clarification Brett!) In addition, while debugging, I caught another error: The uncertainty from each data point as calculated above computes the *relative* uncertainty. As displayed on the graph, since the plot shows absolute amplitude of the displacement, the uncertainty should be displayed in absolute units, as in unc = disp_pmrtHz.full .* sqrt( (1 - coh) / 2*nAvgs*coh ) weight = 1 / unc^2; Finally, even more dumb of a mistake, a copy and paste error meant I was using the asd vector as my coherence vector. All of the above errors, bugs, and mistakes have been corrected, and I attach a revised plot. The new force coefficient is roughly 2.2e-10 [N/V^2].
This happened again, we repeated what we did, on the Corner Chassis 2 L-2 (X-gateway) under Online the current state was safeop. We hit a bunch of buttons (including clear error) until it arrived in OP. We repeated this for L-1, which was also in safe OP.
An alternative solution would be to restart h1ecatc1