J. Kissel

In light of the recent problems with VEA temperature causing sag in the L1 QUADs -- to the point of rubbing earthquake stops (see LLO aLOG 12633) -- I've gathered a similar 1-year long collection of hour trends of each VEA's temperature vs. vertical displacement of each QUAD. Our temperature appears to be rock solid (certainly within 1 [deg C], and at the end stations, better than +/- 0.2 [deg C]). After installation, the vertical position of QUADs also remains pretty darn stationary, staying within a few 10s of [um] (a more precise assessment would require a better tool than dataviewer).

... it's finally there, thanks to Jamie's great work.

This morning we used ITMY to fine tune the parameters. After increasing the HEPI Boost filters ramping time from 5s to 10s on the vertical dofs, and from 5s to 15s on the horizontal dofs, there were no more saturations of the GS13s during the Turn ON process of HEPI. The SEI manager was able to entirely bring the HEPI, Stage 1 and Stage 2 under full control, including a restore of 300uRad of HEPI  pitch offset.

9:29 -> We request the manager to bring the entire chamber from "everything OFF" to "Fully Isolated"

9:31 -> HEPI is fully isolated. The Yaw and Pitch alignments have been restored. The Manager code waits for the T240s to settle

9:39 -> The T240 monitor indicates to the Manager that the T240 have settled. The manager starts isolating Stage 1. The SEI front end code automatically resets the T240 Saturation counter and the WD starts watching the T240s.

9:41-> Stage 1 and Stage 2 are fully isolated. The Yaw offesets have been restored. The SEI system is "Fully Isolated"

We tried this full cycle another time and it worked just as well.

A few notes:

- we need to fix the HEPI boost filters

- we tried to Auto Z the T240s after restoring the HEPI offset. It looks like it could save a couple on minutes in waiting time if needed

- the GS13 trip at the very end of de-isolation process. That's no big deal as we almost never need to fully de-isolate for now, but we should have a look into it.

- there is probably some room to reduce some ramping and waiting time here and there, but more than half of the turn on process will still be dedicated to waiting for the T240s to settle

- in the future, we can think of turning on the ISI  in high blend mode while the T240 settle, and then switch to low blend. For that, we'll need the additional guardian node that we talked about to switch the blends and other control parameters.

- it could be nice to add a clock on the T240 monitor screen showing how much time there is still to wait

SRM
Jason setting up for pitch measurements
Betsy running transfer functions
Jeff B. wants to connect the wiring for the bottom two stages (needs to wait for transfer function measurements to finish)

HAM4
Last TCS components to be installed: ISI probably ready for balancing next week
Betsy installing baffles

TCS
No work on X or Y CO2 tables, HWS work only: No need for laser hazard

ACB
Ready to start balancing and suspending
Photodiodes need to be tested

Staging building
Jim W. finishing testing on Unit 2

Apollo
Bubba machining parts for TCS


Unifirst will be delivering on Thursday for the next couple of weeks
Jamie and Robert scheduled for weekend work
Rai W. will be here next week to take acoustic measurements of the beam tube
Peter K. is working on ISS in the H2 PSL laser enclosure
Chris to move 3 IFO PCAL parts from the LSB, VPW and woodshop to mid X and 3 IFO PCAL parts from the LSB to mid Y

Came in this morning to find the BS ISI stage 2 GS13 watchdog tripped.  Unclear why.

The strange thing is that the trip appears to have occured at GPS 1084253752, which is 10:30pm last night, whereas commissioning finished up around 4:30am.  Did they just run with the BS tripped all night?

The watchdog was reset and guardian recovered everything fine.

DetChar line hunters emailed me with some results from their HIFO-X investigations. The line looked to me like lines I had seen before from an I/O box in the test stand (here). Figure 1 shows that, when I partially covered the fan intake of the I/O box that carried the channel, the line dropped in frequency, and returned after I uncovered it. The peak from the second fan, up around 80 Hz, also moved when I partially covered its intake. This confirms that these lines that they found in H1:ALS-X_ARM_IN1_DQ are from the cooling fans in the h1iscex I/O box. In the above reference I note that running similar fans off of a separate power supply reduced the lines that the fans produced in the I/O box channels by about a factor of 10. This suggests that the dominant coupling is through power supply ripple.

In addition, I tested for lines from the h1iscex I/O box switching power supply. These lines are produced by coupling of the large magnetic fields that the supplies generate, to cables and connectors in or near the I/O box (same link as above). The magnetic fields produced by the switchers include rapidly drifting lines from beats between high frequency oscillators and lines from the fans in the switcher. I partially blocked the switcher air intakes to move the fan peak frequency in order to confirm that the field I was seeing on a magnetometer that I had set near the switcher, came from the switchers.  Figure 2 shows that there was coherence between channels in the I/O box and the magnetometer reading the switcher field, at the frequencies of the switcher fans. In this particular I/O box, the peaks produced by magnetic coupling of switcher fields were smaller than those produced by power supply ripple from the I/O box fans. The size of the peaks from the switcher depend, in part, on how close the cables pass to its location in the back of the I/O box (here) .

Robert Schofield, Nelson Christensen, Jialun Luo, Patrick Meyers, Michael Coughlin, Eric Thrane, Keith Riles 

model restarts logged for Thu 15/May/2014
2014_05_15 13:16 h1isiitmy
2014_05_15 13:19 h1asc
2014_05_15 13:22 h1broadcast0
2014_05_15 13:22 h1dc0
2014_05_15 13:22 h1fw0
2014_05_15 13:22 h1fw1
2014_05_15 13:22 h1nds0
2014_05_15 13:22 h1nds1
2014_05_15 16:58 h1susetmx
2014_05_15 17:30 h1susetmx

no unexpected restarts. h1susetmx restarts part of 8Hz noise investigation.

Lisa, Kiwamu, Stefan

- We had the 18Hz mode of the BS ring up. an additional notch in the MICH loop fixed it.
- We tried to use the REFL27 demod phase to reduce the CARM noise in MICH, but this did not work.
- We had the BS being kicked too hard by the PRMI lock acquisition, producing a yaw misalignment, resulting in a loss of the DIFF beat note. We disabled the BS top mass feed-back, which solved this issue.
- In the process of this debugging we also checked the beat note of DIFF - it was however already pretty well aligned.
- Next we noticed that at -1kHz offset we were sitting right on the 2omega arm resonance. This caused large offset changes in the 3f signal. We decided to try using a ~600Hz offset instead.
- That turned out to make locking on 1f very difficult. 2 hours later we tried a 2kHz offset (on the wrong side of the 1kHz 2f resonance), which worked fine.
- At the 2kHz offset we successfully transitioned to 3f, but as expected, when marching across the 2f arm resonance MICH went unstable.
- But we had to increase the REFLAIR_B_RF27_Q gain in the input matrix from 2.5 to 4.

- Our next goal was to lock at 2kHz offset, then stay on 1f as we move in to about 600Hz, and then try the transition to 3f there.

- another earthquake...

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

Successful upgrade of SEI guardian code today to achieve full SEI deployment

Yesterday, we:

• installed new guardian core (v918) and cdsutils (v237)
• HPI guardian nodes deployed for all active HPI systems: HAM 2,3 and BSC 1,2,3,9,10
• upgraded ISI single-stage code which includes monitoring of T240 saturation state: all ISI stage nodes were restarted
• upgraded BSC chamber manager nodes to include handling of BSC HPI: all BSC managers restarted
• deployed HAM chamber managers for HAM 2,3 that coordinates HAM ISI and HPI

In other words, we now have full SEI guardian for both HAMs and BSCs.  This is a fairly big milestone, as now essentially all seismic systems are fully automated (modulo the output HAMs which are still undergoing installation).

SEI guardian operation

The most important new UI aspect of these improvements is that all interface to the seismic systems for each chamber is now done through the chamber managers, e.g. SEI_HAM3, SEI_ITMY, etc.  They are the manager nodes that coordinate the activity of the HPI and ISI in each chamber.  All HPI and ISI nodes should now be operating in managed mode, which means that there activity is controlled by their respective chamber manager.  Managed nodes are purple.  Here is a shot from the guardian overview screen, showing the BS manager SEI_BS in blue, and the one HPI and two ISI nodes in purple:

All interaction with the seismic systems should now go through the managers.  Here's the graph of the SEI_BS manager, which is identical to the graphs of the rest of the BSC chamber managers:

The dark blue states above are the requestable states, e.g. DAMPED or FULLY_ISOLATED.

In general, hte managed subordinate nodes (i.e. the ISI and HPI nodes) should not be touched while they're in managed mode (i.e. purple) unless you know what you're doing.  Otherwise you run the risk of interfering with and potentially confusing the manager, and therefore distrupting the automation.  That said, the managers are designed to be fairly robust against noodling with their subordinates (see alog 11077 for more information about manager behavior).  Probably the most important thing to keep in mind, that might help you out of a jam or to reset things:

If any of the subordinates are out of wack, for whatever reason, e.g. they are not in the correct MODE or STATE or REQUEST etc., command the chamber manager to go to the INIT state

The manager INIT state will:

• reset all subordinates into MANAGED mode (i.e. reacquire them to being managed)
• check the STATEs of the subordinates to determine the overall state of the system
• REQUEST the appropriate states of the subordinates to recover the system back to a known configuration

SEI guardian code structure

All SEI guardian code is installed in:

$USERAPPS_DIR/isi/common/guardian

At the top level of this directory are the main guardian nodes for HPI, each ISI stage, and the chamber managers.  These modules all load their code from the SEI guardian library:

$USERAPPS_DIR/isi/common/guardian/isiguardianlib

This library includes the primary packages for HPI, ISI_STAGE, HAM_MANAGER, and BSC_MANAGER.  These load support modules/packages also part of isiguardianlib.  For example, the ISI_ITMY_ST1 guardian is defined by the ISI_ITMY_ST1.py module:

from isiguardianlib.ISI_STAGE
import * prefix = 'ISI-ITMY_ST1

The first line loads all code from the isiguardianlib.ISI_STAGE package, and the second line sets the channel access prefix.  All the SEI modules are structured in this way.

Jamie, Dave, Fabrice,

We have implemented the modifications in the isi2stage master model that were necessary to:

1)  Allow  good functioning of the guardian

2)  Investigate the subtraction scheme we have been talking about to improve teh RZ (Yaw) isolation.

We are testing these changes so we can decide which ones to propagate (ECR, svn commit, install on other units, other sites...)

Details of the changes:

- Added a block in the ST1 block, to filter the T240RZsignal induced by the Z drive. This block is called T240 subtract

- Changed the way the WD "ignore" the T240 when they are not in loop. This is now done in the T240 block instead of being done in the c code. It permits to keep the c code generic for all other types of sensors. The c code is back to 9 inputs. I removed the 10th input in Stage 1 and Stage 2 "Muxes" entering in the Simulink. We must check that everything i s compatible with the HAM-ISI and BSC-ISI models

- Changed the logic to calculate the state of Stage 1 ISO. It is now done with boolean operators. The output returns a "0" if all gains are 0, and a "1"  if any of the gains in non-zero. Added an Epics output to monitor this variable.

- Added some logic to reset the T240 counter when the isolation is tuned on.

The model has been compiled, installed and started on ITMY.   The T240 counter does reset when the isolation is turned on. However, on the last test I did with the guradian before to hand the unit back to commissioning, it tripped on the T240s. To be investigated tomorrow morning.

Other problems to be fixed:

- the GS13s trip when the boosts of the HEPI horizontal loops are engaged. We must check if it's a matter of adding phase margin or adding some ramping time.

- all the safe.snaps must be updated to record the T240 saturation counter parameters

- for some reasons, the cont2b filters in ITMY Stage 1 X,Y, Z had disappeared. I assumed they were just constant values of "1" and added such filters with foton. To be checked.

- some HEPI ETMX boost filters were not loaded. We loaded constant values of "1" so we could keep working on the guardian. To be fixed.

Hosken, Grabeel, Vo

CO2X:
- Laser left on running overnight again.
- Prepare gig-E camera infrastructure for wiring and software.

CO2Y:
- Rotation Stage working, turns out that the motor power cable  at the feed through was not plugged in.
- Starting to connect up temp. sensors on table, looking for the custom clamps that mount the sensors.
 
HAM4 HWS:
- Alignment laser is the wrong wavelength for the dichroic mirror which is HR at 650-900nm and HT at 500-550nm.
- Lens mounts readied for install in-vac

We twice observed a filter module turn on almost immediately, even though it was supposed to ramp over 15seconds.

It is not reproducable in the sence that it seems to be a random occurance, and usually ramps with the propper time.

8:00-9:42 Getting ready to move clean room in LVEA (Craning) – Apollo
8:30 Water supplier on site – Paradise
8:35 Going into the LVEA to search for parts – Corey
8:40-14:00 Continue assembling/suspending/balancing of the ACB suspension- Betsy/Travis/Margot
8:48-13:02 Heading into the LVEA for SRM alignment – Jason
9:00-11:50 Joining Jason on SRM alignment – Jeff B
9:05-9:44 Retrieving items from LVEA - Gerardo 
10:04-12:02 Heading in to the LVEA for TCSx table work – David
10:09-15:43 ICS rack inventory in LVEA – Filiberto
13:14 Restarting ISI model for ITMY – Dave/Fabrice
13:16 Restarting ASC model and the DAQ – Dave/Fabrice
13:32-14:20 Back to HAM5 to connect BOSEMs – Jeff B
14:05 Transitioning the LVEA to Laser HAZARD
14:13 Back to West bay (LVEA) – Betsy/Travis/Margot
14:37 Back to the LVEA for TCSY table work – David/Greg

 LVEA is Laser HAZARD!

NOTE: Today while going over the CDs Check sheet, I noticed that the Right BOSEM on PRM was reading almost 0. I talked to Alexa and concluded that it was because the suspension has been yawed.

Heated volume is adjacent to but isolated from unpumped volume seen by PT246A,B gauges -> Ignore readings from PT246A,B until further notice (2 weeks?)

Took a first look at the SRM surrogate (SRM-s) today and lo-and-behold, no adjustment was necessary.    The cookie cutters did their job and placed the suspension within spec for X, Y, and Z axis positions.  The position errors are below:

• X axis (lateral): -1.5 mm (south)
  • Tolerance: ±4.6 mm
• Y axis (longitudinal): +1.3 mm (west)
  • Tolerance: ±3.0 mm
• Z axis (vertical): +0.9 mm (high)
  • Tolerance: ±3.0 mm

I have begun and mostly completed the setup for the rough pitch/yaw alignment of the SRM-s.  This will be completed tomorrow morning and the rough pitch/yaw alignment will follow.

Yesterday night, I tried to run SR2 M2-M2 and M3-M3 (lower stages) in chamber transfer functions after the osems were centered on wednesday. Although both M2 and M3 watchdogs tripped during the measurement, so I am running it again tonight. (This time, I decreased the drive and increased the watchdog threshold).