• We changed the sensor for the DHARD WFS from AS B 45 Q to AS A 45Q, based on what Ryan told us about the LLO experience.  With this sensor we can keep the loops closed throughout the whole CARM offset reduction without flipping the sign. 
• We reduced the PSL power to 2.8 Watts after locking DRMI and transitioning to TR_CARM. (this is added to the guardian)
• We let the guardian take us to the "10PM" state
• We added a boost to the REFL BIAS path, (FM2) which has a z2:p0.01. 
• We adjusted the TR_CARM offset (to about -34 or -36) to get the offset in TR_REFLAIR input to -0.08
• We ramped on TR_REFL with 8 in the input matrix and 0 in TR_CARM.
• We reduced the TR_REFL offset to zero
• in this situation we had large angular fluctuations, and didn't hold the lock very long.  Our arm buildups were around 800 times the single arm power, and REFL was less than 10%

Our next steps will be to check the loop gains before we try turning off the refl offset, and trying to increase the DHARD WFS bandwidth.  

We also toggled the noise eater tonight (we thought it might have been oscillating but this probably wasn't the case). We also copied the invP2P and Y2Y filters from the drivealign matrix into the opLev servos so that we can work on the DHARD WFS loops independent of these filters.  

Lock loss times: all Feb 4th UTC 

4:14:00

5:00:00

7:09:00

J. Kissel

More interesting data on the HEPI Pump Servo. Looking to ID the response of the HEPI Differential Pressure "Plant," i.e. from the control drive output to differential (supply - return) pressure change, I turned OFF the servo and put small steps in the control output of varying sizes (see pg 1 of 2015-02-03_H1HPI_PumpServo_SysID.pdf). First linearly increasing step amplitudes to determine the DC gain (see pgs 2 and 3). Then, to determine the frequency response, I put in many steps of the same size to fit the impulse response (see pg 4).

The results: As it stands, the HEPI pump servo plant can be well-approximated by a single pole at 24 +/- 1 [mHz] and a DC gain of 0.0546 [PSI/ct]. Note, E1100508 suggests that the plant is a single pole a 7 [mHz], with a DC gain of 0.087 [PSI/ct]. Looks like not.

With this information, and the current PID settings of (35,0.45,0) respectively, I can predict the current open loop gain (see pg 5). I model a UGF of 39 [mHz], with a suppression of 0.37 @ 10 [mHz], 0.2 @ 1 [mHz], below which the 1/f integrator kicks in. Note, E1100508 suggests using PID params of (20, 0.07, 0), which would result in even lower a UGF and less suppression.

With such a simple plant, it's really tough to find PID parameters that aren't stable, so I also show a toy set of parameters with much higher values, (P,I,D) = (300,30,0), where the integrator dominates. With these parameters, we get a UGF of 390 [mHz], with suppression of 0.24 @ 100 [mHz], 0.035 @ 10 [mHz], and so on.

Why not increase the UGF to infinity? 
Because there're worries out there that above a few [Hz], poorly-matched impedance, transmission-line-like effects take over the frequency response, which may cause sharp, phase-full features in the plant that are not characterized by a simple pole.

Why does this not-at-all match what's measured when comparing Closed vs. Open. vs. No Sensor ASD spectrum?
(see 2015-01-27_H1HPI_DifferentialPressure_Open_v_ClosedLoop_Comp.pdf, and 2015-02-02_H1HPI_PumpServo_ADCNoiseCharacterization_DiffASD.pdf, which is not new data, but copied to this aLOG for convenience)
Open vs. Closed loop ASDs show that there is suppression of 0.1 @ 10 [mHz], not the modeled 0.37 @ 10 [mHz]. Further, the measured spectra shows some gain peaking of a factor of 2, where the model predicts no region where the suppression is above unity. It really does seem like the ASD behavior of the signal is totally disconnected from the time series behavior of these sensors. I really hope this whole saga isn't some false alarm from EPICs vs DTT nonsense...

-----
Raw Data lives here:
/ligo/svncommon/SeiSVN/seismic/HEPI/H1/Common/2015-02-03_H1HPI_PumpServo_StepResponse.mat

Data Processing Script lives here:
/ligo/svncommon/SeiSVN/seismic/HEPI/H1/Common/H1HPI_PumpServo_StepResponse_20150203.m

As it happened the new als models contain another experimental feature: An align/misalign button for the input beam steering. This feature was added at the end of the integration module. The aim is to have separate values for the misaligned and aligned state. The alignment values are the output bias of the integrators. This allows for instantaneous and glitch-free off-loading as well as a single button misalignment. The misaligned state can either be a fixed value or a value which is added to the aligned value. An additional calibration gain has been added to the output to make sure the alignment values are in physical units. All state changes are done with a smooth ramping process.

All integrators have been updated to include a ramp time.

Before today's work the models running on h1iscex, h1iscey were:

After the split the models now are:

teal = model not changed

New PEM = OLD PEM + OLD CAL

NEW ALS = ALS component of old ISC (inherrits old ISC core and dcuids)

NEW ISC = old ISC minus ALS (uses old CAL core and brand new dcuids)

Spliting the End Station ISC Models Into Two

Daniel, Jim, Dave:

WP5034. The problem: end station isc models are running long, so their RFM IPC to the corner station do not make it in time. The solution: split the ISC model up into ALS and ISC, with the latter running faster and able to send RFM IPC to the corner in the allocated time (60uS).

Because the h1iscex,ey computers did not have any spare cores (iop, pem, isc, odc, cal) for now we added CAL to PEM to free up a core. Hopefully a better long term solution is to combine isc and odc.

Daniel had done a lot of early legwork getting the models into shape. He hand edited the H1.ipc file to change the source model name for channels moving from ISC to the new ALS models. Daniel also handled the filter module files.

We identified all models which receive IPC channels (including Dolphin) from the new ISC and ALS models. These were also recompiled and restarted.

First thing this morning we moved the new H1.ipc file into place and did a round of make and make-install on the related models. The testpoint.par file needed editing during the "make install" process due to the model-dcuid change for the isc models.

The rtsystab file was modified for the new model layout in the end station isc front end.

Then all the related models were stopped:

h1lsc, h1asc, h1susetmx, h1susetmy, h1hpietmx, h1hpietmy, h1pemex, h1iscex, h1odcx, h1calex, h1pemey, h1iscey, h1odcy, h1caley

The h1iopiscex and h1iopiscey were restarted. We saw an awgtpman autostart problem with these models.

The end station models were restarted (h1pemex, h1iscex, h1odcx, h1alsex, h1pemey, h1iscey, h1odcy, h1alsey). We had to play around with the safe.snap files for the ISC and ALS models to get them to startup.

The receiving models were restarted (h1lsc, h1asc, h1susetmx, h1susetmy, h1hpietmx, h1hpietmy)

The IPC from the end station ISC models to the LSC are now without any errors. The ALS model still has some IPC to the LSC and this retains its error rate (this model was not substantially sped up).

The DAQ master file was reconfigured for the new model layout, and H1EDCU_DAQ.ini was resynced.

I checked the DAQ data for the PEM and found it was corrupted. This was tracked to the change of the ADC part name in the model when PEM and CAL were combined, and we forgot to remap the bus selector parts attached to the ADC. This was fixed, there is a two hour gap in PEM data.

CDS OVERVIEW MEDM

Dave:

The H1CDS_STATE_WORD_CUSTOM.adl overview MEDM screen was updated:

• model shuffle in end station ISC front ends
• addition of CFC (configuration file change) bit. A BLUE bit like the overflow.
• addition of the CONLOG section

Pump #8 back on line--FClara had to rewire the db9 end of the Control VOUT.

Pump #7 taken off line to check Accumulators--all good, none with low pressures, #7 back on line.

Added explicit ground to + & - power outputs of power supply.  All kinds of wires jiggled, poked, & twisted.  No change in the sensor noise.

7:10 Peter King and Richard McCarthy to PSL

8:06 Jim running measurements on ITMx ISI, Jeff K running measurements on HEPI pump servo

8:13 Cris and Karn to LVEA

8:21 Jim done with ITMx

8:31 Betsy to LVEA

8:41 Gerardo to LVEA

8:47 Jodi moving dessicant cabinet from high bay to VPW

8:48 Jim, Hugh, and JeffK to LVEA HEPI spring constant measurements

8:54 Corey to LVEA inventorying enclosures

9:14 Krishna was at EX from 7:30-9:00 working on BRS

9:16 Dave B starting ISC, ASC, and LSC work

9:19 Jodi done

9:40 Corey out of LVEA

9:45 Corey heading to EX and EY for enclosure inventory

9:45 Karen to MY

9:49 Jim, Hugh, and JeffK out of LVEA

9:49 reconnecting HEPI caused a short of pumps, Hugh swapping plugs while down

10:03 Gerardo done

10:03 Betsy done

10:19 Cris to MX

10:36 Betsy to LVEA

10:37 Richard and Peter out of PSL

10:39 Cyrus taking down Framewriter 1

10:40 Elli to EX, EY

10:41 Fil to EX

10:55 Cyrus done

11:03 Corey back from ends, heading to LVEA

11:06 Dave B restarting DAQ

11:13 Karen out of MY

12:05 Betsy and Corey done

13:11 John and Bubba to LVEA

13:33 John and Bubba done

J. Kissel, H. Radkins, J. Warner

To help better characterize and model the HEPI system (and to get some gratification out of using M*g = k*x), Hugh, Jim, and I measured the vertical spring rate / spring stiffness of several H1 HEPI systems in the corner station. 

Here're the results:
Chamber       Spring Rate (+/- Uncertainty) [N/m]
ITMX (BSC1)       7.52e6 (4.22e4)
ITMY (BSC3)       7.75e6 (8.09e4)
HAM4              7.55e6 (1.19e5)
HAM5              8.21e6 (3.23e5)

Method:
(1) Turn OFF HEPI and ISI feedback control for chamber (brought OFFLINE by guardian)
(2) Measure raw V1-V4 IPS signals (waiting for signals to settle enough that the one's digit is all that's changing, and then just caget the H1:HPI-${CHAMBER}_IPSINF_${DOF}_INMONs)
(3) Place 10 [kg] load on all four corners of the suspended payload (on the blue cross-beams directly vertical of the vertical actuators on the BSCs, and on the "do not step" cover for the vertical L4C, also directly vertical of the vertical actuators, on the HAMs)
(4) Measure raw V1-V4 IPS signals
(5) Remove masses
(6) Measure raw V1-V4 IPS signals
(7) Re-place masses
(8) Measure raw V1-V4 IPS signals
... repeat of all four chambers.
(9) "Offline" convert raw data to [m] of displacement, x,
    (a) convert raw IPS signals to [m], with 3.87e-08 [m/ct]
    (b) take average of V1 - V4 to get Z position
    (c) create three Z displacement measurement trials, (4) - (2), (6) - (4), and (8) - (6)
(10) Calculate spring rate for each trial, k = F / x, where F = m g, with m = 40 [kg] and g = 9.81 [m/s^2].
(11) Take the mean and std / sqrt(3) of three trials, to report spring rate mean and uncertainty on the mean in the above table.

Raw notes from data taking (includes load on each spring, which was also measured)
/ligo/svncommon/SeiSVN/seismic/HEPI/H1/Common/2015-02-03_HPI_SpringRates.txt


Script to process data:
/ligo/svncommon/SeiSVN/seismic/HEPI/H1/Common/HEPI_Spring_Rate_20150203.m

WP #5037

Dataviewer has been updated to version 2.9.1.2 for Ubuntu workstations in the control room.  This is to fix bugzilla 775, to prevent incorrect channel names from being entered by the user.  An incorrect string comparison of entered names to the channel list read from the NDS allowed certain bad channel names to be entered manually, and since data wasn't available for the incorrect channel, dataviewer would substitute different channel data, leading to confusion.

I want to get the HWS working.  This morning I installed HWS power cables on ISCTEY and ISCTEX, and plugged in the HWS fiber-optic cable at EY.  ETMY power cable was re-wired to match ETMx, as required.

It looks like everything is in place for ETMx HWS.  At EY, there are no cables running from the ISTEY feedthrough panel to the TCS rack.  I couldn't connect to the HWS computers from the control room, need to find out what state they are in.

(Peter K, Richard M, , Filiberto C, Daniel S)

We noticed that the fast channels corresponding to H1:IMC-PWR_IN and H1:IMC-PWR_EOM were never hooked up. This required installing the PD interface box in the PSL enclosure, running the DAQ cable into the PSL and installing a tee in the photodetector readback. (These channels have previously been hooked up to the EtherCAT system, so they that they are available to the rotation stage.) The EOM channel is currently railed and needs an adjustment of the PD gain.

EPICS updates:

• Added buttons for these channels to the IMC overview screen.
• Fixed the screen for the PSL rotation stage in the sitemap.
• Added rotation stage button to the IMC overview screen.

K. Venkateswara

In response to the problems reported in 16391, I centered the beam-balance in BRS within the nominal range of the angular readout. To do so, I physically moved a small mass on the balance using the bellows mounted on the front face of the vacuum can. After a few tries I was able to center it to within a ~1/3 of the full range. The balance was then damped to low amplitudes and I repositioned the damper.

BRS is now functioning correctly. The first attached plot shows the tilt-subtraction at work. The second shows the coherence between various sensors. The low coherence between the tilt-subtracted super-sensor and BRS RY shows the subtraction is working reasonably well.

Had to boot EX which seems to be a biweekly occurrence. The problem aren't the PLCs or the hardware interface but the communications. The tcioc stops updating with a "No DS mailbox available" error message. This is always preceded by numerous "CAS: UDP  recv error". So far, the only way to fix it is to reboot. I did notice that h1ecatx1 runs the Windows firewall whereas the c1 and y1 run a commercial product.

C. Reed, D. Moraru

In an effort to ameliorate the daqd crashes on framewriters 0 and 1, we have enabled jumbo frames on the private network links between the framewriters and the QFS gateways under WP 5035.  This was the last remaining major difference between our configuration and the LLO DAQ (that we know of).  If this doesn't help, we will need to keep looking for a cause for our framewriting woes.

J. Kissel, J. Warner, D. Barker, E. Merilh, TJ Shaffer

The one final quiver in our arrow against the sharp HAM3 0.6 [Hz] resonant feature was a computer (as suggested e.g. here), so we did so this morning. Sadly, it did not cure the problem. For now, we continue on, running in the configuration defined by Seb last week, see LHO aLOG 16100, in which the RY blend filters at a higher blend configuration, which is the only thing we can find that seems to help (see LHO aLOG 16001). This has now officially become a low-priority until it begins to quantifiably impact IFO performance.

A Recap of all of the things we've tried that DIDN'T make the feature go away:
- Restarting the front-end process LHO aLOG 15759

- Full power-down of Front-end and I/O Chassis (This aLOG)

- Coil Driver Swap LHO aLOG 16071, LHO aLOG 16061, LHO aLOG 15981

- Changing Suspension Damping LHO aLOG 16013, LHO aLOG 16001

- Changing Isolation Loops LHO aLOG 16001

- Location of Sensor Correction; ISI vs HPI LHO aLOG 15941. LHO aLOG 15933

- Changing from STS2 B to A; In analog LHO aLOG 15811, In digital LHO aLOG 15927, LHO aLOG 15894

- Checking between ADC and sensor correction bank LHO aLOG 15783

- Turning OFF CPS satellite amplifiers, checking jumper settings (oscillators, jumpers, etc.) LHO aLOG 15751

- Adding a large mechanical offset to relieve supposed mechanical rubbing LHO aLOG 15751

- Waiting LHO aLOG 15565