WP 6287

Removed the ADC card that was added on Tuesday (WP 6287) because of instability of the h1oaf IOP model.  Several instances of ADC/DAC/DK bad status have been noted, the most recent at 06:53 PST this morning.

We will put the ADC card in the DTS for long term testing.

While I had the I/O chassis open, I checked for loose connections or anything else that might cause problems.  I noted that about half the interface cards at the rear of the I/O chassis were loose and able to wiggle back and forth.  I pushed them all down and tightened the screws on the brackets which were loose.  I then looked at the ADC and DAC cards. All the metal brackets were tight, but the last ADC card was not secured to it's metal bracket.  One screw was near falling out, the other was loose (picture attached), so the card was free to wiggle around in it's card connector.  This was tightened and reinstalled.  Not all of the cables plugged in to the back of the I/O chassis are able to be secured to their connectors.  I pushed on all of them to make sure they were seated.  I checked both the fans after power-up, they are both operational.

The h1iopoaf0 model was changed back to it's previous version to reflect the lesser number of ADC cards, and the DAQ was restarted.

The IFO has been in NLN for a while now, but I couldn't take the IFO to OBSERVE because the LASER_PWR guardian had the nominal state set wrong and it took a while to figure out how to change it.

For other operators while we are still in a semi-commissioning phase, I fixed this by editing the LASER_PWR guardian. In the LASER_PWR there is a line that says:

nominal = 'POWER_{}W'.format(REQUEST_POWERS[X])

where X is some negative number. REQUEST_POWER is a vector defined above this line:

REQUEST_POWERS = [DEFAULT_POWER,10,25,35,50]

X is the index of the element that corresponds to the power, counting from the right (i.e for 50 W, X = -1, for 35 W X= -2...).

I had to change:

nominal = 'POWER_{}W'.format(REQUEST_POWERS[-2])   for 35 W to

nominal = 'POWER_{}W'.format(REQUEST_POWERS[-3])   for 25 W.

Save, then hit load on LASER_PWR.

Daniel, Sheila

We have not been using REFL WFS to control PR3 in the last week or so because with somewhat high microseism this was making the IFO unstable.  Things got slightly better when we lowered the IMC WFS gain to avoid oscillating there. 

Tonight we started to look at the REFL centering loops, and re did them.  FIrst we started with diagonalizing them, the new matrix is in the screen shot.  Then we reshaped the loops a bit.  Before these changes the pitch loops were pretty close to unstable at 2.5 Hz with the ELF20s engaged, so we moved up the cut offs and moved the zeros down.  We have had trouble occasionally with CHARD loops ringing at 2.5 Hz, I hope this will be fixed now.

Since the microseism is down to around 0,4um/second, we tried the refl WFS again but lost the lock.  

The 260Hz peak was gone earlier tonight with an offset of 120 in DOF1P

The results of the recent A2L measurements for PR2 and PR3 are analyzed. Here is a summary.

Synopsys

The horizontal spot position on PR2 may sound too large, but I don't think this is bad.

Back in 2014 we adjusted the PR2 spot to be at 14 mm toward the West (14788) in order to improve the clipping situation on PR2 based on the study that Keita did (14640). Since the beam radius on PR2 is about 6 mm (see for example 30130), the spot position seems to have shifted by roughly the radius of the beam size further to the West comparing to the 2014 measurement. Note that the size of the PR2 optic is 150 mm in diameter (D1101377). According to these numbers, I don't think the measured spot position is too crazy.

Some details

Over the past week or so, the operators ran the a2l scripts for PR2 and PR3 (for example 31239). The scripts were the ones Jenne newly wrote specifically for checking the beam spot on these mirrors (31157). The attached shows trend of the a2l gains for the past two weeks. The values are then roughly averaged and used to estimate the typical spot positions as listed above. For the definition of alpha, see Koji's log entry in the 40m elog. For the conversion from alpha to the spot positions, see 14788.

There are some jittery peaks that may be doughnut jitter. How much are we going to gain if we squash them?

As a sensor for jittery things I chose IMC WFSA DC YAW. (Not because we believe that it's an angulay jitter, but because the coherence with DARM is high and therefore whatever polluts DARM is likely coming from the same place as the angular jitter measured by IMC WFSA DC YAW.)

Using DTT, I took 100 averages of CAL_DELTAL_EXTERNAL and IMC WFSA DC YAW from the night before (Nov/08 10:00:00 UTC) when there was this fabulously steady BNS inspiral range. As you can see from the first plot, IMC WFS is coherent with CAL_DELTAL_EXTERNAL.

I used the part where coherence is greater than 0.2 and did a dirty subtraction of the WFS signal from CAL_DELTA_EXTERNAL using a transfer function and the spectra measured. 60Hz and harmonics are excluded from the subtraction. The top panel shows both the raw and the post-subtraction spectrum.

The displacement was then divided by 4000 and was plugged into BNS inspiral range code (BNS_range.m) in calibration svn. Note that the range produced this way disagrees with the sensemon by about 10-% (my number overestimates), but it should still be useful for noise subtraction comparison.

In the second attachment, bottom shows the sqrt of the integrand (i.e. to obtain Mpc, you square the plot, add everything together, then sqrt).

The effect of the subtraction is small but not totally negligible, it seems like we'll gain something like 1.5 Mpc (or 1.3Mpc if you believe that the overestimation of the inspiral range is just a scale difference).

4pm local [Gerardo, Chandra]

Took 3 min. to overfill CP3 by increasing LLCV to 50% open (from 20%). 

State of H1: locking and making it NLN

Assistance: Sheila, Evan

Activities:

• ALS fiber polarization went bad again - there was two fibers hanging down when I opened the case, and so the second time I reset the polarization I secured them in a way that I beleive will not cause any issue, since they are in a large bundle
• PI modes 27 and 9 rang up. 27 needed constant adjusting, 9 eventually damped with more gain and phase change
• PI mode 24 rang up with 27, but stabalized, which was nice, since we don't actively damp it
• Roll and Bounce needed some attention
• SRM needed a small tweak of alignment for DRMI
• no new issues
• suspicion about PI settings, I didn't get a chance to look into it today

Site:

• Joe - MX
• Gerardo - LVEA between locks
• Chandra - MY for CP3

More musings on the wind.
- summary - 
Brian suspects that the motion of the building above 20 mHz is caused by turbulence generated at the building by the wind, and that below 20 mHz it is caused by the overall wind velocity. 
There is strong evidence of vortex shedding along the building. We see significant lateral tilting of the slab (ie transverse to the wind direction), and the motion along the wind direction shows a change in character which coincides with Strouhal number, which describes the vortex shedding scale. 

- not so summary - 
Jim W reported a big windstorm starting early in the morning local time on Oct 14.
https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=30592

I took a look at the impact of the this wind storm on the tilt of the End Y slab as seen by the  ground STS-2 and BRS. We know this slab bends, so this is just the motion near the tank, not of the whole floor.

All the data, plots, and matlab code is in the seismic SVN at
seismic/Common/Documents/T1600506_LHO_wind/wind_data_oct15

Pages 1-3 wind history. - wind is variable, but high

The data spans 21 hours, starting at about 11pm pacific time on Oct 13. The wind really gets going at about 1 am PDT Oct 14. There are several hours where the speed at EY is in the 15-20 m/s (33-44 miles/hour). 
The wind speed is different at the two end stations. The wind direction at EX shows that mostly the wind comes from the SW, up along the Y arm towards the corner station. WE ASSUME that the wind direction is similar at EY, even though the direction indicator there remains broken. (see pg 14 for the direction read by the EY station - you can see that it is broken.)

Pages 4-7 Data selection
Because the wind is variable, I decided to use just 3 segments where the wind is pretty steady. These are labeled t3, t12, and t13 for the hour they span.
t12 = avg speed = 15.1 m/s, time span = hour 11.5 - 12.5
t13 = avg speed =  9.2 m/s, time span = hour 12.6 - 13.7 
t3  = avg speed =  8.4 m/s, time span = hour  3.0 -  4.2

Pages 8-10: Coherence is very low above 20 mHz
Plot the coherence of various signals at end Y during the three times.
The BRS and the STS-2 Y signals are very coherent from 10 -100 mHz during 15 m/s wind
at 9 m/s, they are very coherent, but the primary microseism is evident at 70-80 mHz as a drop in the coherence.

Below 20 mHz, there is some coherence between the wind speed (also speed^2) and the STS-Y signal. Above 20 mHz there is no coherence between wind speed and anything.
The lack of coherence could be caused by the pixelization of the wind speed, but more likely is caused by turbulence at the building. ie - the speed at the anemometer is not a good measure of the net force on the building at 30-100 mHz because the turbulent flow of the air around the building means that wind speed/ building force at various points across the building at 30-100 mHz (30 sec to 10 sec periods) are not coherence with each other or the anemometer. This does not sound crazy because turbulence is chaotic. 

page 11-12: tilt motion of End Y
The wind is blowing in the -Y direction.
The building is tilting in both X and Y - the X motion is 2-3 times larger that the Y motion. This is interesting, and I'm not sure why we see this. 
Points to consider:
1) Maybe there is wind blowing in X? I don't think so. All the data we have says the wind is blowing along Y.
2) Vortex shedding - air blowing along the sides of the building causes big vortices, which break off and buffet the building side-to-side. This certainly happens with flag poles etc. I am sure this is happening, but I can't calculate how large an effect this is. 
3) STS-2 location on the floor - The floor bends, and the farther you are from the walls, the smaller the tilt is at your location. I think the STS-2 is closer to the big +X wall than it is to either the smaller walls at -Y or +Y (-Y is the wall closest to the corner station). So maybe because the sensor is closest to the X wall, it is seeing more of the tilt in the X direction (rY). Again, this is probably true, but I'm not sure how much of an effect this is. 

Whatever the cause, the effect is quite clear at the sensor location, and thus at the location of the ETMY optic.

Second plot on page 12 is the tilt seen by the EY BRS. The spectrum seems to have a corner at about 300-400 mHz. 

page 13 - BRS subtraction performance
We see the BRS subtraction is beating the End-Y STS 2 above 15 mHz, and doing very well above 30 mHz.
The two plots on page 13 compare the Y motion seen by the STS-2 Y in the corner station with the STS-2 Y motion on the floor in Y-end and with the real-time tilt-corrected signal formed by subtracting the BRS from the STS-2 ('H1:ISI-ETMY_SUPER_Y_OUT_DQ')

It is interesting to see that the y-end station has significant excess motion above 250 mHz in the high wind. this may be affecting the subtraction at 40-100 mHz (mccs2 might be able to tell you, but I have not checked).

Page 14 - tilt scaling with wind speed.
Does the tilt spectra scale like avg wind speed^2?
Nope! Plot 14 shows 3 BRS spectra, each with a polynomial fit. 
average wind speeds are:
t12 = 15.1 m/s,   t13 =  9.2 m/s,  t3  =  8.4 m/s,
(t12/t3) = 1.81, (t12/t3)^2 = 3.3
(t13/t3) = 1.1,  (t13/t3)^2 = 1.2
(t13/t12) = 1.64, (t13/t12)^2 = 2.7

If the ground tilt were simply a shaped spectrum which scaled as wind^2, then
the dashed blue curve would be a flat line at 3.3, 
the dashed red line a flat line at 1.2, and  
the dashed purple would be a flat line at 2.7.
Clearly this is not the case. 

turbulence? more turbulence at high wind speeds?

Page 15 - EY wind direction indicator is still busted.
EX sensor says the wind is mostly blowing in the -Y direction.
EX sensor signal is wierd and crappy.
Only processing I did was to take the the sensor readings, and if they were > 180, then I subtracted 360 from them.
EY is still busted, but we knew that already.

On the shape of the BRS rotation curve:
A casual look at the ground rotation indicates there might be some change in the slope of curve at about 200 mHz for the blue, 15 mps curve, and a similar bend at about 130 mHz in the red/ yellow curve for the 8-9 meter/sec wind speed.

This corner is very close to characteristic frequency given by the Stouhal number for vortex shedding. Interesting!

WARNING - These dimensionless numbers are intended to give a sense for the scaling of what is going on, NOT to predict what will happen (unless you happen to have a perfectly spherical building with no ground nearby)

Strouhal number for vortex shedding
(https://en.wikipedia.org/wiki/Strouhal_number)

For a Reynolds number of 1e7, the Strouhal number, St, is ~0.3.
St = f * L / v.
here the characteristic length is the length of the building 
so L is about 80 ft = 24 meters
f = 0.3 * v /24 
for v = 15 m/s, f = 0.19 Hz
for v = 9 m/s,  f = 0.11 Hz 

Reynold's Number
The flow is turbulent; the reynolds number is ~10^7
(https://en.wikipedia.org/wiki/Reynolds_number)

Reynolds number = ( velocity * L)/(kinematic-viscosity)
kinematic-viscosity =  1.460×10−5 m2/s for the atmosphere at sea level.(wikipedia)
L = 18 meters (building width) or 12 meters (building height)
v = 9 to 15 m/s 

R1 = 15 m/s * 18 m / 1.46e-5 (m^2/s) = 18* 10^6
R2 = 9 * 12 / 1.46e-5 = 7 * 10^6

- 
so if you are breaking off vortices at something like the frequency given by the Strouhal number, then I guess it is not crazy to think the building rocking will show that characteristic frequency. Need to follow up with someone who knows about these things!

 

Yesterday with the boot of h1oaf, the matrix elements for Modes 27 & 28 began using TRY QPD CHAN2 rather than OMC DCPD CHAN2.  This is because the safe.snap was set for TRY QPD CHAN2.  This file had not been updated since 18 October, even though these elements were set on 20 October.  Based on the trends, looked like this was spotted again last Tuesday when the OAF was restarted, again, the SDF was not updated.

There are currently ~40 diffs on the SDF and no NOT_MONITORED channels.  Maybe some of the gains and filters of these channels should be not monitored so things like signal source path changes will stand out.

I have written a script to decode the STATE_WORD reported on a model's GDS_TP MEDM screen. The script is called decode_state_word and takes the STATE_WORD as its argument.

For example, last night the h1iopoaf0 STATE_WORD went from 512 to 652 (data obtained from dataviewer trends)

david.barker@zotws2: decode_state_word 512
OVERFLOW

david.barker@zotws2: decode_state_word 652
ADC
DAC
DACKILL
OVERFLOW
 

J. Kissel

(Belated entry from last night)

During last night's ~1hr lock stretch over 02:00-03:00 UTC, I've continued a second round of tuning on the actuation side of the reference transfer functions for speed while retaining SNR. I was only able to make it through the lower two stages (L2 and L3, or PUM and TST) of H1SUSETMY before the IFO began having problems LHO aLOG 31345, but those series of 4 templates (to PCAL2DARMs and two iEXC2DARMs) can now be run in under 20 minutes.

The frequency vectors go from 5 Hz to 1.2 kHz for all stages -- the lower limit defined by the inability for the PCAL to drive above the noise to any lower frequency, and the upper limit defined by the integration time and actuation strength of the QUAD. Note, we want to go out to ~1 kHz not because the actuator plays and important role in the DARM loop up there, but to better nail down and delays that have been otherwise constantly confusing (see e.g. LHO aLOG 29259). I've also increased the density of points above 100 Hz, in order to improve the fidelity of future fits.

The new data live here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Measurements/FullIFOActuatorTFs/2016-11-08/
2016-11-08_H1SUSETMY_L1_iEXC2DARM.xml
2016-11-08_H1SUSETMY_L2_iEXC2DARM.xml
2016-11-08_H1SUSETMY_L2_PCAL2DARM.xml
2016-11-08_H1SUSETMY_L3_iEXC2DARM.xml
2016-11-08_H1SUSETMY_L3_PCAL2DARM.xml
Again, note that the L1 template has in complete data, and I was not able to get a corresponding PCAL2DARM transfer function. Will try again one more time this week -- hopefully we can find the problems impacting our duty cycle so this isn't a burden.

The attached plots show a length noise injection into the PMC using TFIN. The first plot is calibrated in Volts for the HV_MON, whereas the second plot is calibrated in displacement. The coupling coefficient at 1 kHz is about 3.5 x 10^-8 between the PZT and DARM length.

The reference traces 0 and 1 are without injection, whereas reference traces 2, 3 and 4 are from before the changes on the PSL table on Tuesday.

A measurement done at the very beginning of the run had about half the coupling—indicating that the coupling depends on thermal lensing.

Sheila reported that Nutsinee switched the SEI_CONFs to BLEND_45mHz_SC_useism last night but looking this morning I see that it did not switch the Blend on ETMY.  I manually switched the (X & Y dof) Blends only; the Sensor Correction did switch to not use the BRS.  Otherwise all switching worked with Sensor Correction for all Test Masses and no BRS in use at the Ends.