Day Shift 16:00-23:59UTC (08:00-16:00PT)

State of H1: DRMI lock for Jenne

Shift Summary:

Site Activities:

- 19:30 Kyle - LVEA to survey for upgrade

- 19:45 Kyle - out of LVEA

- 21:27 Corey - optics lab

- 21:15 Ed - LVEA to reset PSL watchdog

- 21:25 Ed - out of PSL

Locking / Initial Alignment:

- locking X arm in red was very fast, and had good power

- ITMY needed more of an offset during SRC alignment

- PRMI needed to adjust BS for DRMI

- DRMI is well aligned and relocking quickly for the last 2-3 hours of the shift

Control Room:

- Video0 froze, now fixed after a reboot

- Video4 had the wrong striptool displayed, now fixed

I've been slowly trying to get stuff figured out for testing a wind fence set up at LHO, and am getting ready to try to set something up. I'll summarize where I think things are here.

Currently, I want to try a small, cheap wind fence at EX, mostly to explore how effective screens are at slowing wind, effects on ground motion and tumbleweed build up. The fence would be a couple of 4x4-ish 12-15 foot posts and some fine polymer netting like that used around tennis courts, gardens and the like. It may be necessary to add guy lines, as well.  In addition to the fence, Richard has said he will help me get an STS buried at EX, similar to Robert's set up at EY, and we are ordering 3 anemometers with stand alone data collection so no changes need to be made to CDS for this. I think this set up will allow me to look at a few of the concerns that people have brought up. So far the concerns I've heard are:

1. Increased ground motion. Fences slow wind by applying a force to the airstream, this is transmitted to the ground and produces increased tilt and other high frequency motion. I think the tilt can be addressed by placing the fence some few tens of meters from the building, per Robert's measurements of building tilt. Higher frequency motion can hopefully be addressed by design of the fence support structure, but we'll have to see how bad the motion is.

2. Similarly, the fence could make airflow more turbulent. I suspect that airflow at the building level is probably turbulent anyway. Hopefully, a well designed fence push turbulent flows around the building, while slowing most of the air makes it through.

3. Tumbleweed build up. Anything that blocks the wind will gather tumbleweeds around here, which could make a fence a fire hazard and maintenance issue.  This  could be addressed by leaving a gap at the bottom. The airflow below a few feet probably isn't a significant source of problems for us, but I don't know how big this gap would need to be. I also plan on using a mesh fine enough that tumbleweeds won't stick to the fence very easily. Industrial fences are flame resistant, and won't ignite on their own.

4. Wind damage. We have seen winds above 100 mph during a storm, this would create very high loads on any fence. I haven't been able to figure out how to calculate wind loads on a permeable wall yet, but Civil Engineers have building codes dealing with this. For my test, I'm trying to get some idea of the loads involved with moderatewind, and just making the fence so that the mesh will tear free in a way that won't damage the EX building if the wind gets too bad. Industrial fences are designed to stand similar wind loads, and their screens are held in place with replaceable break-away clips to prevent damage.

5. Cost/size. BrianL talked to a company that makes industrial fences a few months ago. The ball park figure for a 40 x 200 foot fence was about $250,000. That was a first pass at a price and the company had some suggestions at how to cut down on the cost. This price also needs to be weighed against the 10-15 % of down time we have due to wind. Something of that size would also probably have to be approved by the DOE. It's also unclear if we would have to completely surround each endstation, or if we could get away with less coverage. Probably, we don't need to "protect" EY along the X-axis, or EX along the Y-axis.

Comments, criticism, praise are all welcome.

Along the same lines of earlier investigations into DARM noise fluctuations, I checked the "high frequency" (1-100mHz) spectrum of the DARM RMS in 2 bands between 80 and 100Hz.  The fluctuations in these BLRMSs are fairly featureless, though there appear to be small peaks at 30 and 70mHz (see plot).

The code used to generate these plots is:

gwd = GWData;
data7 = gwd.fetch('26 Dec 2015 8:00:00', 3*60*60, 'H1:SUS-ETMX_L2_DAMP_MODE7_RMSLP_OUT16', 'mDV');
dd7 = GWFilt.detrend(data7.data);
fs = data7.rate; tfft = 256;
[p7, ff] = pwelch(dd7, hann(fs * tfft), [], fs * tfft, fs);

data8 = gwd.fetch('26 Dec 2015 8:00:00', 3*60*60, 'H1:SUS-ETMX_L2_DAMP_MODE8_RMSLP_OUT16', 'mDV');
dd8 = GWFilt.detrend(data7.data);
[p8, ff] = pwelch(dd8, hann(fs * tfft), [], fs * tfft, fs);

loglog(ff, [p7, p8]); axis([0.005, 0.2, 1e-4 1e-2]); grid on
title('Flucutations in DARM noise (Boxing Day 2015)')
legend('80-100Hz band', '100-120Hz band')
xlabel('frequency [Hz]')
ylabel('Power spectrum of variations')

The watchdog was reset at 13:22PST as per FAMIS http:// https://ligo-wa.accruent.net/LB_Request_Update.asp?RequestID=3587. 

I took advantage of the the earthquake and the higher winds this morning and went to test out a new PSL node. Much of the code was taken from LLO's PSL guardian, but I tweaked it for our uses and added a few things that they didn't have. After I created the node, I could not get "guardctrl medm" to pop up a medm for the node.  (shot of the error attached) In the interest in time, I continued just using the the log and other guardctrl commands. This is much more awkward that I expected and slowed me down quite a bit. After sorting through the few syntax errors, bringing the power up and down, and searching for home, I have some notes and will work on a few issues I found. Overall, it went well and it should, hopefully, be usable very soon.

I stoped and destroyed the node when I was done, I will recreate it next chance I get to test it (whenever that may be).

Site activities:

- 17:16UTC Kyle and Gerardo - at EX and door X2-8 to work on cable for annulus ion pump

H1 Update:

- 17:53UTC all ISI platforms returned to nominal isolation

Earthquake:

Time: Wed Mar 02 12:49:47 UTC 2016

Location: Southwest of Sumatra, Indonesia; LAT: -4.9, LON: 94.3

Magnitude: 7.8

- HEPIs that tripped: HAM1, ETMX (BSC9)

- ISIs that tripped: all ISIs

- oprics that tripped: BS, PR2 (full trip), SR2 (only upper two stages), and MC1(only upper two stages)

- Hugh and Jim were here early, and have ISIs in Damped, and HEPIs in Robust_Damped

- 0.03-0.1Hz ground motion is typically around 0.05um/s, and is currently 0.5um/s

- useism (0.1-0.3Hz ground motion) is at 0.5um/s

Current H1 Status:

- guardian issues being worked on

- too much ground motion to lock 

I'm leaving conlog-test-master running and connected to the same channels as h1conlog1-master.

0:25 UTC Kyle to end X to get something forgotten outside of LVEA
0:42 UTC Kyle back

After TCS work was done for the day Sheila and I attempted to lock the X and Y arms on green. I was able to lock the X arm fairly quickly, but the Y arm took a long time to realign. Further attempts were abandoned for the night with winds over 40 mph.

svn up at .../SusSVN/sus/trunk/QUAD/Common/MatlabTools/QuadModel_Production/

Updates:

1) Added an option for optical lever damping that actuates at the PUM (L2) stage. Like top mass damping, this can be imported from the sites, or added in locally.

2) Added options for violin modes at all stages. Previously this was only available for the fibers. You can choose how many modes you want at each stage, doesn't have to be the same number.

3) Added an option to load damping from a variable in the matlab workspace. Previously this could only be done from a saved file or imported from the sites.

Detailed instructions fpr generate_QUAD_Model_Production.m are commented into the header. See G1401132 for a summary of the features, and some basic instructions on running the model.

I am tagging this to the svn now as

quadmodelproduction-rev7995_ssmake4pv2eMB5f_fiber-rev3601_h1etmy-rev7915_released-2016-03-01.mat

...the file is large (386 MB) so it is slow to upload.

The tagged model includes 25 violin modes for the fibers, 20 for the uim-pum wire, 15 for the top-uim wire, and 10 for the top-most wire. For the 25 fiber violin modes, the first 8 are based on measured frequencies from h1etmy, the remainder are modeled frequencies. All metal wire modes are modeled values. The oplev filters are turned off in this model as well (I imported the filters from LHO, and they were turned off at the time).

For reference, this is a summary of the history of model revisions in the svn:

* generate_QUAD_Model_Production.m

rev 7359: now reads foton files for main chain and reaction damping

rev 7436: Changed hard coded DAMP gains to get the correct values for LHO ETMX specifically.

rev 7508: Restored damping filter choice for P to level 2.1 filters as opposed to Keita's modification. Cleaned up error checking code on foton filter files, and allowed handling of filter archive files and files with the full path.

rev 7639: renaming lho etmy parameter file

rev 7642: Adding custom parameter file for each quad. Each one is a copy of h1etmy at this point, since that one has the most available data.

rev 7646: added ability to read live filters from sites, and ability to load custom parameter files for each suspension

rev 7652: updated to allow damping filters from sites from a specific gps time (in addition to the live reading option)

planned future revision - seismic noise will progate through the damping filters as in real life. i.e the OSEMs are relative sensors and measure the displacement between the cage and the suspension.

rev 7920: big update - added sus point reaction forces, top OSEMs act between cage and sus, replaced append/connect command with simulink files

rev 7995: added oplev damping with actuation at the PUM (L2); added options for violin modes at all stages, rather than just for the fibers; added option to load damping from a variable in the workspace, in addition to the existing features of loading damping from a previously saved or importing from sites.

* ssmake4pv2eMB5f_fiber.m

no recent (at least 4 years) functional changes have been made to this file.

* quadopt_fiber.m

- rev 2731: name of file changed to quadopt_fiber.m, removing the date to avoid confusion with Mark Barton's Mathametica files.

- rev 6374: updated based on H1ETM fit in 10089.

- rev 7392: updated pend.ln to provide as-built CM heights according to T1500046

- rev 7912: the update described in this log, where the solidworks values for the inertias of the test mass and pum were put into the model, and the model was then refit.  Same as h1etmy.m.

* h1etmy.m

- rev 7640: created the H1ETMY parameter file based on the fit discussed in 10089.

- rev 7911: the update described in this log, where the solidworks values for the inertias of the test mass and pum were put into the model, and the model was then refit. Same as quadopt_fiber.m.

As a curiosity, here are some projections comparing the current H1 noise with SRM T = 20% (nominal aLIGO design) and no SRM (power recycling only). The SRM T=20% and no SRM curves are obtained simply by replacing the modeled H1 quantum noise in the present configuration (SRM T equivalent = 39%) with the quantum noise calculated for these alternative configurations, assuming the rest of the noise the same.

We would have detected GW150914 no matter what; the SNR could have been 30% worse. 


GWINC output for corresponding theoretical curves:

Current H1

BNS Inspiral Range:      159.65 Mpc
BBH Inspiral Range:        3.04 Gpc (z = 1.0)

SRM T = 20%

BNS Inspiral Range:      131.75 Mpc
BBH Inspiral Range:        2.35 Gpc (z = 0.8)

NO SRM

BNS Inspiral Range:      155.89 Mpc
BBH Inspiral Range:        2.95 Gpc (z = 1.0)

Patrick, Sheila

Since we are getting high wind tonigh, we are not trying to lock and it seemed like a good chance to try to speed up the green WFS.  For the X arm I've turned the gains up as high as they can go before oscillating then turned them down a factor of 3.  We will have to reshape the loop to make things faster. 

Just as patrick got the Y arm aligned the wind picked up to above 60 mph, and we can't hold the green arm lock anymore.  

Evan, Matt, Lisa

While IFO realignment work was in progress yesterday, we spent sometime looking into the H1 quantum noise.

There are a couple of known issues when trying to explain the measured H1 shot noise level:

1) the H1 measured cavity pole (~340 Hz, see  the calibration companion paper ) is actually lower than expected from the nominal IFO parameters, so you can't get the right shape with the current GWINC parameter model (nominal parameters give a higher pole frequency);

2) beside that, higher losses and/or lower power are needed to explain the actual measured shot noise level.

Evan calculated the H1 shot noise contribution in the H1 noise budget (fig 2 in the detector companion paper) from the shot noise on the DCPD sum (8e-8 mA/rtHz), and then referred to displacement noise using the GDS channels for optical gain and cavity pole (optical gain = 3.24 mA/pm). This measurement well explains the H1 noise level at high frequency.

When trying to match the measured shot noise level with GWINC, we realized that an easy way to match the frequency dependence caused by the low H1 cavity pole frequency is to increase the transmission of the SRM to 39% (nominally 37%). We believe the real mechanism is actually a mismatch of the SRC cavity wrt to the arms, translating in a lower "effective" reflectivity of the SRM mirror (i.e., less efficient signal extraction). 

Still, even after fixing the frequency dependence with the higher SRM transmission, if one tries to reproduce the shot noise level with GWINC by using parameters inferred from measurements of loss/power at the various IFO ports, it is evident that extra losses (or lower powers) are actually needed. 

With power entering the IFO ~19W, recycling gain ~37, intra cavity power ~95kW, we need ~15% extra losses in the readout chain wrt to the measured ones (25%) in order to reproduce the observed shot noise level. One obvious way of getting that is if the OMC throughput and mode matching are not as good as inferred from  previous measurements .

A 10 degree mistuning of the homdoyne phase wrt to the "nominal" (pi/2) could explain up to ~5% of the observed loss. 

Bottom line: while one can see many ways to improve this analysis, either powers / recycling gain are not what we think they are, or, most likely, we have higher loss in the readout chain that we think we have (and an imperfect homodyne phase). 

The plot shows the best H1 noise, the H1 measured shot noise, and the GWINC quantum noise model including radiation pressure noise corresponding to 95kW in the arms.


% GWINC parameters
ifo.Laser.Power = 21 * 0.88;
ifo.Optics.Loss = 45e-6;  %Arm loss = 90 ppm
ifo.Optics.BSLoss  = 0.5e-3;  
ifo.Optics.PhotoDetectorEfficiency  = 0.65; %Readout loss tuned to match measured shot noise level
ifo.Optics.SRM.Transmittance  = 0.39;    % "Effective" Transmittance of SRM    
ifo.Optics.SRM.Tunephase = 0;            % SRM tuning
ifo.Optics.Quadrature.dc = 90 * pi/180;  % demod/detection/homodyne phase pi/2  

%GWINC Output
Laser Power:              18.48 Watt
SRM transmission:          0.3900
Finesse:                  445.93
Power Recycling Factor:   36.83
Arm power:                95.26 kW

Hardware Watchdog Swap-Out WP5750

Hugh, Jim, Dave:

We swapped out the older HWWD units in the corner station CER and the EY CER with newer models.

The corner station CER old unit was S1301712, it was unpowered and did not have the two long DB37 cables connecting it to the ITMY top stage satellite amps. It did have both binary in/out cables attached to SUS ITMY binary chassis. We replaced with the new unit S1301708 and connected both satellite amp monitor cables. We removed the binary control line, leaving just the binary monitoring line. This unit does not control the power to the ISI coil drivers for BSC1.

The EY old unit was S1301709. It was fully operational and controlling the three ISI coil drivers. Hugh put ISI into a safe state so we could de-energize the ISI coil drivers when the HWWD was powered down. We replaced with unit S1301701. We reattached all cables except for the binary control of the HWWD from the sus model (monitoring only).

The new HWWD units have different binary monitor voltage levels (low = FAULT, high = GOOD). The HWWD status is read by the SUS QUAD model via its binary input. The new hwwd-part code is in the RCG trunk version, so rather than risk building h1susitmy and h1susetmy against trunk, I made a simple model change to invert the four input binary lines to reflect to new binary levels. Both h1susetmy and h1susitmy models were restarted, no DAQ restart was required. SVN version of new sus models = r12764.

h1guardian0 reboot

Dave:

To resync all guardian nodes with recent file changes, I elected to reboot h1guardian0 to check that all nodes start automatically. First I rebooted the machine, and the nodes did not start automatically. Second I power cycled the machine and the guardian nodes did start.

h1tcscs new SIM model parts WP5749

Aidan, Dave, Jim:

Aidan made changes to his SIM parts of the h1tcscs model. Jim and I helped in getting the new code compiled. The model h1tcscs on h1oaf0 was restarted, followed by a DAQ restart.

ISI HAM4,5 model change

Hugh, Jim:

the models h1isiham4 and h1isiham5 were restarted with new models. No DAQ restart was required.

Timing System IRIG-B units handling leap year

Jim:

Jim checked that our IRIG-B fanout units in MSR, EX, EY and DTS have handled this year's Feb 29th inclusion correctly, they have.

DAQ Minute trends offload from h1tw1. WP5747

Jim:

The minute trends offload from h1tw1 was completed today. During this afternoon's DAQ restart h1nds1 was configured to use the new minute trend archive.

DAQ Restart

Dave:

The daq was restarted at 15:30 to resync with the new h1tcscs model and reconfigure h1nds1 to use the new minute trends archive. This was a clean restart. h1fw0 started sufficiently in advance of h1fw1 to write a 64 second frame before h1fw1 wrote its first frame.

(Chandra, Gerardo and Kyle)

Regenerated NEG pump with the aid of an aux cart.

Valved out NEG pump from X-End, then started regeneration of NEG pump ~19:00 utc.
2 hours later heating was complete, waited for temperature to drop down, valved in NEG pump to X-End volume at 21:45 utc and @ 92 deg C.

Finished adding Caps to the Negative regulator per latest dwg. Today we completed the ITMx,ITMy,BS, and all of Ham5 and Ham6 Suspensions.  Also verified and corrected were needed Ham2 optics.
This should stem any oscillations caused by the long cables from the SAT amp side.

IM2 position is now oscillating by 5urad in pitch and yaw after satellite module fix on Feb. 23.

Three plots attached:

• Time series showing it working briefly then going into oscillation
• power spectrum of all IM2 OSEM inputs - high res, 0-7000Hz
• power spectrum of all IM2 OSEM slow channels - 0-100Hz, showing a 10Hz comb