Sheila, Koji, Dan, Evan

Summary

Today we recovered a 35 Mpc lock and put the necessary steps in the Guardian.

Details

Bounce mode damping

For EY bounce mode damping, the DARM→EY element in the LSC output matrix is set to −1 and L3 ISCINF is enabled. Length feedback is entirely disabled on EY at this point. Then in the M0 DARM damping filter module, the +60° rotator and the bandpass are enabled, and the gain is −0.1.

Since this new damping feedback topology is not fully implemented on the ITMs, the DARM error signal is routed through LSC-YARM and into IX L3. In M0 DARM filter module, there is no phase rotation, only the bandpass at 9.7 Hz. I found that I needed to flip the sign of the gain compared to what we used to use; −80 seemed to damp the mode alright. Since this is a hack and likely will not be necessary 24 hours from now, it has not been put into the Guardian.

In both cases I have removed the 120 dB of gain from the bandpass FM and put it in a separate FM. This 120 dB is no longer sensible when using DARM control rather than DARM error.

Sheila has pointed out that any test mass which uses this damping scheme is ineligible to be used for feedfoward subtraction of other length DOFs, unless we come up with some workaround.

OMC ASC

As mentioned yesterday, we reverted the HAM6 centering scheme so that we could keep the interferometer ASC working.

Consequently, we now see scattering shelves in the DARM spectrum if the OMC ASC gain is set to 1. Setting it to 0.2 makes the DARM spectrum less painful to look at.

MICH coupling

Although tonight's campaign of noise coupling measurements was cut short by the PSL tripping, Koji and I managed to get a MICH→DARM transfer function with good coherence from 20 Hz to 400 Hz. The DTT files are attached.

For quiet data, one can look at 2015-04­-01 07:50:15 to 07:55:15.

Automation

Now that we have a reliable readback of the EY ESD state, the EX→EY transition has been reenabled in the Guardian.

The new final state is LSC_FF, which enables the MICH and SRCL feedforward and adds a cutoff to the SRCL loop.

Koji, Evan

The NPRO shut off at around 08:11:00 UTC.

The interferometer was locked with no measurements or injections running.

With help from Evan Hall, Jeff Kissel and Ross Kennedy, got preliminary spectra from REFL-I and IMC-I, with the idea of identifying high frequency lines. A plot and some data are attached. Here are the frequencies of lines and clusters identified in these plots. They were taken with the SR785 box next to WHAM1, using the GPIB/ethernet bridge to the control room and Eric Quintero's readout scripts.

There are two attached figures, one with the two ASDs in separate planes, the other with them overlaid. Notice that the cavity length mode at around 36kHz is not in exactly the same place in the two channels, and neither is the first harmonic at around 70kHz. Other narrow peaks, however, do line up.

REFL-Q
Frequency ; ASD 
1. 2440Hz ; 21uVrms/rtHz 
2. 13.9kHz ; 16uVrms/rtHz
3. 34.4kHz ; 16uVrms/rtHz - broadband, bandwidth 1.2kHz
4. 40.4kHz ; 9.7uVrms/rtHz
5. 56.7kHz ; 13.0uVrms/rtHz
6. 60.9kHz ; 5.7uVrms/rtHz
7. 62.4kHz ; 7.4uVrms/rtHz
8. 65.6kHz ; 6.6uVrms/rtHz
9. 66.3kHz ; 6.3uVrms/rtHz
10. 70.2kHz ; 18.9uVrms/rtHz - broadband, bandwidth 3kHz 

IMC-I
Frequency ; ASD
1. 2453Hz ; 2uVrms/rtHz
2. 13.9kHz ; 16uVrms/rtHz
3. 38kHz ; 4uVrms/rtHz - broadband, bandwidth 1.2kHz, but does not line up with REFL-Q peak 3.
4. 40.6kHz ; 2.4uVrms/rtHz 
5. 56.5kHz ; 2.4uVrms/rtHz
6. 62.4kHz ; 2.4uVrms/rtHz
7. 65.6kHz ; 3.1uVrms/rtHz - double peak, just resolved.
8. 69.1kHz ; 3.1uVrms/rtHz
9. 76.6kHz ; 9.3uVrms/rtHz - broadband, bandwidth 3kHz, but does not line up with REFL-Q peak 10.

I took the transfer function between H1:OMC-DCPD_A_OUT and H1:OMC_DCPD_B_OUT while the IFO was still at RF Readout.

The balance of the PD at DC is actually very good (delta<0.5%) but they are not well matched between 10-100Hz.
The difference is as much as 20%. The noise at high frequency is due to shotnoise between two PDs.

This could be caused by a mismatch between the V2cnt filters in the filter modules and the actual preamplifier filters in the vacuum chamber.
I'll look into this issue in the daytime as I don't want to screw up the overall calibration for DARM.

J. Kissel, E. Hall, S. Dwyer

After getting back to a reasonable DARM spectrum, we began experimenting with the new DARM_CTRL damped 9 [Hz] highest vertical mode. We quickly discovered that the change made for the ITMs won't work, because the single pipe in which ISC control comes into the suspension -- which is what we'd picked off the control point from to feed to the top mass -- can no longer contain DARM signals after we split / redistributed the LSC and OMC front-end code (i.e. there are no DARM to ITM output matrix elements in the LSC control).

Evan hacked around the problem for tonight by using the input matrix to pipe DARM_ERR straight through the YARM bank, and out to the ITMs.

However, for a more permanent solution, I've modified the ITM models (again) to include a new PCIe receiver of the H1:OMC-CAL_DARM_CTRL IPC channel (already being broadcast in the corner for the CAL-CS calibration of DELTA L EXTERNAL), which is now piped separately from DARM_ERR into the main QUAD block, and fed to the top mass for bounce damping.

The model changes for h1susitmx and h1susitmy are complete, I've confirmed that they can compile, and I've committed the changes to the userapps repo. The attached screen shots show the various portions of the model that were changed.

We (either Stuart or myself) will install and restart the front-end process in the morning.

 

J. Kissel, D. Barker, J. Batch, J. Warner, S. Aston

Advised by J. Smith that LHO is suffering from Major-Carry transition glitching (LHO aLOG 17555), we've taken advantage of the front-end model restart chaos to re-calibrate the BSC SUS 18-bit DACs -- i.e. taken all front-end "user" processes (i.e. the SUS code) offline, and restarted the IOP process for the h1susex, h1susey, and h1susb123 front end computers / I/O chassis, which runs each chassis' DAC cards through their auto-calibration procedure. Those front ends include DACs for H1SUSETMX, H1SUSTMSX, H1SUSETMY, H1SUSTMSY, H1SUSITMX, H1SUSITMY and H1SUSBS.

Sadly, I realize while writing this entry, and after rereading Josh's entry (LHO aLOG 17555), that he says that it's the -2^16 transitions that are most of the glitches. Indeed, I even got an email I got from P. Fritschel today, en passant, reminding me that J. Betz and he have shown that the recalibration procedure does not reduce the -2^16 [ct] transition glitching (see G1401269). Hurumph.

Anyways, the re-calibration will at least help with the drift in glitchiness of the other two transitions ( 0 and +2^16 , potentially seen in, e.g. 16354).

I attach procedural notes that I gathered during the restart process (I learned quite a bit!)

P.S. There may be a "danger" that auto calibration of the 8th DAC (or DAC cardNum 7 if you count from zero) on the h1susb123, which house the control for the PUM on ITMX and ITMY, as the h1susb123 dmesg reports that the AUTOCAL failed for this DAC:
[6643729.576353] h1iopsusb123: 18-bit dac card on bus 36; device 4
[6643729.576367] h1iopsusb123: pci0 = 0xdfefe000
[6643729.576391] h1iopsusb123: dac pci2 = 0xdfefc000
[6643729.576398] h1iopsusb123: DAC I/O address=0xdfefc000  0xffffc90011b08000
[6643729.576403] h1iopsusb123: DAC BCR = 0x40000
[6643729.576427] h1iopsusb123: DAC BCR after init = 0x20040000
[6643729.576432] h1iopsusb123: DAC OUTPUT CONFIG = 0xff
[6643734.724703] h1iopsusb123: DAC AUTOCAL FAILED in 5133 milliseconds 
[6643734.724712] h1iopsusb123: DAC OUTPUT CONFIG after init = 0x102ff with BCR = 0x40000
[6643734.724719] h1iopsusb123: set_8111_prefetch: subsys=0x8111; vendor=0x10b5
I've confirmed that for every other DAC card (5 in EX, 5 in EY, and the other 7 on B123) we re-calibrated today, the dmesg claims success.

J. Kissel, D. Macleod, J. Betzwieser
WP #5124

The hardware injection team wished to have separate filter banks for transient hardware injections -- one CBC and one for BURST -- to ease the automation of recording the information for later processing. There was previously only one called TRANSIENT. 

As such, Duncan modified the 
/opt/rtcds/userapps/release/cal/common/models/CAL_INJ_MASTER.mdl
library part, committed to the repo, that corner of which I updated, and recompiled, installed, and restarted the 
/opt/rtcds/userapps/release/cal/h1/models/h1calcs.mdl
front end model/code. 

Details:
- See attached screen shot for what the hardware injection corner of the h1calcs.mdl looks like now, with the update.
- The ODC vector for transient injections is now also split into BURST and CBC bits.
- This required a DAQ restart.
- I confirmed that there were no SDF system differences before restarting, so there was no need to capture a new safe SDF file.
- Since this was merely an update to the library part, there are no changes to the top-level model, so there's nothing to commit once finished.

J. Kissel, S. Dwyer

As we battle against wind again tonight, Sheila asked "Are there windy blends on the ITMs?" I replied, "No, but we can easily copy them from the ETMs."

As such, I've copied and pasted FM10, the 90mHz blends, of the H1ISIETMX CPS, L4C, and T240, CUR filter bank on ST1 into the corresponding CUR and NXT filter banks of H1ISIITMX, H1ISIBS, and H1ISIITMY. I attach a comparison between the 45mHz and 90mHz blends, generated by 
/ligo/svncommon/SeiSVN/seismic/Common/MatlabTools/plot_current_blends.m
(where I've removed the RY filters by hand, because they're split between two banks and therefore what would be plotted can't be trusted)
 'cause I've never seen such a comparison before -- at least their complementary filter form.

We'll need more time with the IFO when it's more stable, but preliminary results -- where we'd switched the blends on ITMX in X and ITMY in Y to 90 [mHz] -- say that it isn't better. But they're preliminary, and I can't rule out that I've screwed up the copy-and-paste process. I'll double check everything once I don't have two more aLOGs to write.


P.S. Questions about the blend filters:
90mHz: 
- Do we really like these 90 [mHz] blends? 
- Seems like we should roll off the T240s way faster above 10 [Hz], like is done in the 45 [mHz] blends. 
- Do the Q's of the 0.5 and 1 [Hz] notches need to be that deep, or that what's *really* giving us the improvement when it's windy?
- Seems like the notches are at the wrong frequency, and could be moved down to get similar notching as the 45 mHz blends, and to better match the 0.43 [Hz] mode of the QUAD. Or maybe it's matching the 0.56 [Hz] pitch mode, which is actually the problem under windy conditions?

45mHz:
- Do we really like that much *un*complementarity in the 45 [mHz]? Maybe at this low a frequency, the loop gain is large enough -- even without the boost -- that any phase wiggle doesn't impact the stability during ramp up or nominal operations. But it'll certainly change the isolation loop error signal at low frequency when switching *between* blends. But also maybe not, because we've been able to successfully switch between 90 and 45 mHz blends on the ETMs for months now...

J. Kissel, S. Dwyer, J. Warner

Jim spent some more time trying to understand the difference in noise change in the HAM5 and HAM6 ISI X&Y directions (see LHO aLOG 17521) today, but left the HAMs in an odd configuration, where his new elliptic low-passes were turned ON for HAM5 X&Y and HAM6 X only. 

Having trouble locking the DRMI, we've turned these filters OFF. Not because we actually have reason to think they're the problem, but because we want one less thing to think about whether it *could* be the problem.

Also, because we otherwise can't think of how the additional elliptic low-pass can make anything *worse* -- except if it's only installed sporadically in random HAMs as Jim left it -- Jim has copy-and-pasted the filter to every HAM chamber in the X&Y DOFs, such that we *could* turn on the elliptic for *every* HAM in X&Y if we think it'll help.

These filters currently live in FM5 of the "current" CPS blend filter banks in X&Y (see attached example, called "EllipseP"), and they have a nice slow ramp time, such that you can turn them off and on willy-nilly. BUT because they're in a separate bank the blend switching doesn't work with them. Of course, if we end up really liking these filters, we'll combine them with the 01_28 blends, and we will be able to again blend-switch to our hearts' desire.

J. Kissel, K. Izumi
WP #5128

As per Rana's suggestion (LHO aLOG 17473), we've switched from using (the equivalent of) DARM_ERR to using (the equivalent of) DARM_CTRL for the error signal used for the M0/Top Mass, highest Bound and Roll mode damping of the QUADs on the ETMs. 

Details:
- Thankfully, this did *not* require adding any new IPCs -- all we did was replace the DARM_ERR M0 top-mass input "from" tag with a copy of the L3_ISC_DIST_L "from" tag, which is equivalent to the output of the L3 ISCINF L filter bank, which is post-IPC-signal-conditioned equivalent to the DARM_CTRL pick-off in the OMC model that's (of course!) already sent via RFM IPC from the corner to the end station. See attached screenshots.
- Because the all of the top level QUAD models are unhooked from the library (thanks to how tidal has been implemented differently at both sites, and which ASC sensor is used for damping the violin modes), this was an easy swap of "from" tags to the just-below-top-level QUAD block in each of the four QUAD models:
/opt/rtcds/userapps/release/sus/h1/models/
h1susetmx.mdl
h1susetmy.mdl
h1susitmx.mdl
h1susitmy.mdl 
and required no DAQ restart. This also therefore doesn't impact LLO or the QUAD library parts. All top level models have been committed to the repo.
- The models were compiled, installed, and then the restart was coupled with the recalibration of the QUAD computer's 18-bit DACs (separate aLOG pending).

SUS ADC move, ETM to AUX

Richard, Jim, Stuart, Jeff, Dave:

The second ADC in the h1susex, h1susey IO Chassis were removed and inserted as a fith ADC in the h1susauxex, h1susauxey chassis. The IOP models h1iopsusex and h1iopsusey were modified to remove ADC1. This did not affect the SWWD code, it only reads ADC0 channels. The IOP models h1iopsusauxex and h1iopsusauxey were modifed to add ADC4. These models were started when the front ends were powered back up after the hardware swap.

PEM Mainsmon DAQ rate increase [WP5123]

Robert, Dave:

I increased the DAQ data rate for the PEM MAINSMON channels, including the quadrature sum, from 256Hz to 1024Hz as approved by Peter in DCC document T1400768. I discovered that the ODC part in the model did not differentiate between end stations, resulting in duplicate channels in the DAQ ini files. I renamed these parts ODC_X and ODC_Y to remove the duplication. The 60Hz mains AC voltage now looks like a clean sine wave in the DAQ (please see attached image). This closes WP5123.

Suspensions recalibration of 18bit-DACs

Jeff, Jim, Dave:

Jeff restarted the SUS QUAD IOP models to perform a recalibration of the 18bit-DAC cards. He noted that some restarts completed too rapidly for the calibration to have been performed successfully (should be 5 seconds per DAC card). This was an intermittent problem, we should investigate on the DTS.

[Richard M, Filiberto C, Stuart A]

Further debugging and refinement of the ESD Driver remote restart has been carried out during today’s maintenance period. Yesterday, it was reported that the Y-end ESD Driver could remotely be turned on, but oddly, not off (see LHO aLOG entry 17570). The sequencer module was swapped out for the spare, which rectified the issue (see LHO aLOG entry 17589).

With the aim of eventually being able to hook-up ESD Driver Analogue and Digital monitors, it was first necessary to swap an ADC from the SUS front-end into the SUSAUX IO chassis (as per the latest version of D1002741). This also required these ADC's be relocated in the IOP models, which was carried out courtesy of David B.

Moving the ESD monitoring ADC also necessitated channel name changes in the ESD Monitor MEDM screens I generated yesterday. It was also found during debugging that the single START/STOP button latched high, so I've added another button to enable latching the ESD reset channel low. Therefore, to toggle the state of the ESD Driver, from active to idle or visa versa, it is necessary to go high for ~1 second, then return to low. n.b. nominally this channel should be low. If all is well with Beckhoff, then this should be sufficient to transition the state of the ESD Driver.

At Jeff K's request, I've also added a large ESD Active display to help users quickly identify the state of the ESD Driver (Red = Off, Green = On). This is determined by evaluating if the ESD DC bias channel monitor is above or below a threshold of 200 counts and the ESD reset channel is set low. 

The modified ESD Monitor MEDM screens for each state can be seen below.

The updated MEDM screens have been checked into the cds userapps svn:-

/opt/rtcds/userapps/trunk/sus/common/medm/quad/
U        SUS_CUST_QUAD_MONITOR_EX_OVERVIEW.adl
U        SUS_CUST_QUAD_MONITOR_EY_OVERVIEW.adl

Digital monitors are now reporting values, however, these should be ignored until the cabling is hooked-up.

Per ECR E1500184, moved AA/AI chassis in the ISC-XC1 and ISC-YC1 racks. This was to provide spacing between units for better heat dissipation. Rack layout is now consistent with drawing number D1001459 ver 13.

Continued troubleshooting EY ESD remote restart capability. Replaced Sequence Module inside the ESD unit. Unit can now be controlled on/off from the control room.

F. Clara, R. McCarthy, S. Aston

Sheila, Ed, Ross, Evan

This morning we had another incident where we seemed to have glitches in the channel H1:ALS-Y_REFL_CTRL_OUT_DQ that could have been the cause of ALS locklosses, similar to what was described in alog 15242 and alog 15402.  Some screenshots are attached.  There is a distinctive pattern in the REFL CTRL signal, and the error signal (ALS-Y_REFL_ERR_OUT_DQ) has a large glitch, as well as the transmitted green light (ALS-C_TRY_A_LF_OUT_DQ).  Today these things were happening only every 10-15 minutes, but that is often enough to prevent locking.  As before this problem went away after a while, without us doing anything to fix it.  Several screen shots are attached. These glitches sometimes show up in the X arm, but that could be because the DIFF control imposes them on the X arm even if the originate in the Y arm.  The glitches still happen when we had tidal off, and COMM unlocked, so I would not think that there was anyway a glitch that originated in the X arm could have been imposed on the Y arm.  There are no coincident gliches in the Optical levers or in the Fiber control or error signals. 

It would be good to know how often these glitches happen, how intermitent the problem has been over the last several months, and how often they coincide with a lockloss.  Ed and Ross started to look into this, and started a script to identify these glitches in a way that is easier than looking though a time series.  I made an attempt to use omega scan on ligodvweb, but I ran into trouble producing a plot.  

I am wondering if anyone from Detchar has tools that could be helpful (and maybe used from the control room?) in finding times when these glitches have happened.  

The optimal location for  a single version of Krishna’s BRS (intermediate frequency tilt sensor), or, if it would be better to have two of them, depends on the tilt spectrum in the beam direction. We suspected that wind-induced tilt is worse at EY than EX, where the BRS is currently located, because, for typical wind storm directions, the building is being pushed roughly along the beam axis at Y-End and roughly perpendicular at X-End (the tumble weeds usually roll down the Y-Arm). But we aren’t sure whether a single sensor at EY would make sense (e.g. if EY is 10x worse than EX) or if two BRSs would be better.  Since we have only the one BRS, we used the 0.03-0.08 Hz band of STS seismometers to compare the two stations. This frequency band was selected as a proxy for tilt because this band is below the microseismic peak frequency and, in windy conditions, ground motion in this band is usually dominated by tilt. Figure 1 shows the strong correlation between the 0.03-0.08 Hz seismometer band and the tilt measured by the BRS at EX for one wind storm. Each of the small points in the plots in this log represent a 60s average of the wind speed and a 60s fft of the ground motion.

Figure 2 shows 4 months (Aug 15, 2014 - Dec 15, 2014) of the 0.03 to 0.08 Hz beamline seismic band at EY and EX plotted against wind speed measured at EX.  The large red and blue dots show the median of minute points in 2 MPH bins. Dipongkar has plotted the median because large earthquakes, which also appear in this band, would bias the mean. Roughly speaking, for a particular wind speed, the signal at EY is twice the signal at EX when averaged over many storms in 4 months. This data suggests to me that we may want a second BRS at EY rather than moving the sensor from EX to EY, because the difference is, on average, only a factor of 2.

The differences between the stations can change for different wind storms, possibly because of different wind directions. Figure 3 shows the effects of individual storms (each storm is a different color, the same color on both plots) at the two stations. One of the storms produced about 5 times more beam-line tilt at EY than at EX.

Caveat: Getting this data is very time-consuming, so we are putting in this log even though we have obtained only 4 months of data. Dipongkar will continue to increase coverage to include the spring windy period and we will update if necessary.

Robert Schofield, Dipongkar Talukder