David.M, Filiberto.C

Yesterday I was looking at the NN array output channels to check everything was working and noticed that the 7th NN channel (H1:NGN-CS_L4C_Z_7_OUT) was producing a noisy output about 3 orders of magnitude higher than expected. I thought potentially the L4C might be busted, so I went into the LVEA this morning and swapped it out for another one that we tested earlier (L41429). The problem remained even with the new sensor and also even when the sensor was unplugged. We went into the CER to diagnose where the problem was. Turning off the L4C interface chassis and the AA chassis both didn't fix the problem, which seems to indicate that the large noise level in this channel is caused by a problem in the I/O Chassis.

Attached is a plot of the cooling circuit performance since the water manifold swap out for
the last ~1-5/8 days.  About halfway through there is an increase in the manifold pressure,
which is reflected in the flow rates of heads [1-3] but not 4, nor the power meter circuit.

    Not sure what to make of things yet other than to simply provide a time reference.

I'm testing an addition to the PI guardian code. If PI MODE2 starts to ring up while we're in INCREASE_POWER, please wait to attempt damping until it is above ~30 amplitude on the PI RMS Monitor StripTool. This ring up is due to a gain sign phase flip and I'd like to automate the necessary gain sign change. Turn around should happen around 10 amplitude so if it continues to rise, damp away.

[Jenne, Terra, Koji, Ed]

Koji suspects that we might have a length offset in PRCL of about 1nm, so we tried giving PRCL an offset to see if that would help the recycling gain.  Nope.  Using the calibration for the PRCL error signal, Kiwamu told us that 1nm in PRCL is about 1,000 counts of offset.  Empirically, about 100 counts of offset breaks the lock, and we don't see any change in the PRC gain.  We'd expect a change of about 1 for 0.1nm if that were the true problem, so since we don't, we infer that PRCL length is not the source of all our PRC gain troubles.

After doing math today, I realized that yesterday's moves of about 16urad in IM3 corresponds to only about 50um in spot motion on PRM (IM4 is flat, 1.5889m between IM3 and PRM AR face according to E1200616).  That's basically nothing. Tonight I moved much farther, and was able to see changes in the PRC gain, although I couldn't get it above 30.  On the other hand, this was done without optimizing the soft offsets, so maybe we can get some more out of that. 

I also tried moving the spot on PR2, but that didn't do anything for my recycling gain.

Also of note is that I was able to get more PRC gain out of PRC1 offsets by also including a yaw offset.  In the end, I was happiest with +0.5 pitch offset, and +0.4 yaw offset.  This is the starting PRC gain in the striptool plot below, before I got even more PRC gain from moving the PRM spot.

When we lost lock, the alignment was terrible, which is perhaps not too surprising.  What is surprising is that somehow the PRM sliders got changed by more than 1,000 urad after the lockloss.  In the PRM plot below, you can see that the OSEM readbacks start aligned, and the sliders are at some value.  Then, at lockloss, the PRM is misaligned, so the sliders stay the same but the OSEMs read different values.  Then, the sliders get moved.  This should never happen, and isn't called for in any guardian that I (a) can find now or (b) have ever seen.  Unclear what that was.

Just finished initial alignment, so the IFO is ready to go for the morning operator to start locking.  With the OMC situation and my guardian "hack" (see alog 28686), you should be able to select IncreasePower basically any time after DRMI has locked, and everything else will run through smoothly and get you to 50W.

Opening statement: Script to do the transition aLog not working. Initial alignment following left doing entry by the wayside. Script seems to be working now.

TITLE: 07/28 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC

STATE of H1: Commissioning

We have a serious issue with the OMC. Even after a day of trying, we are unable to resonate a 00 mode.

David McManus, Jenne Driggers

IMPORTANT: The channel numbers which correspond to locations of the L4Cs have been changed since previous posts, see the updated table and map below and ignore information in previous posts.

When i reference channel numbers in this post I mean the channels H1:NGN-CS_L4C_Z_#_OUT where # is the channel number

After today 29 of the 30 L4Cs have been fixed to the floor and connected to cds. Each sensor on the floor is positioned inside the foam coolers as in previous posts, the boxes are now clearly labelled with the channel number of the L4C as shown in the first picture (with sensor 25). There are now proper threaded connections between each sensor and cable which prevent the cables from being pulled out.

The map attached to this post shows the locations of all sensors in the array, and their channel numbers in cds. L4C number 1 is the only one which is not currently placed because it is right in the middle of a busy and narrow walkway. 

The attached table shows which L4C serial numbers correspond to which channels and also which channel this serial number used during the calibration huddle. Note that because all 30 sensors could not be plugged in during the huddle certain channels were used for different sensors at different times. For this reason this table includes the start date and end date for when this L4C was attached to the channel listed during the huddle.

The other pictures attached show areas where cable protectors are now layed out in the LVEA to stop people tripping on cables.

Jenne approved, I set the IMs back to nominal values from alog 28016

1605 - 1620 hrs. local -> To and from Y-mid 

Opened exhaust check-valve bypass-valve, opened LLCV bypass-valve 1/2 turn -> LN2 at exhaust in 45 seconds -> Restored valves to as found configuration. 

Next overfill to be Friday, July 29th.

Lowered CP3 LLCV from 19% to 18% open. 

Interesting change in exhaust pressure trend going from 20% to 19% this morning.

I had a look at lock loss times and their durations during O1 (only lock losses from nominal low noise). I've had a brief look at a couple of the physical environment channels (H1:PEM-EY_WIND_ROOF_WEATHER_MPH for wind and H1:ISI-GND_STS_ITMY_Z_BLRMS_100M_300M for seismic) to see how they are correlated to these lock losses. There are a few plots I've attached here below. All of the data for these plots are mean minute trends

Plots:

Duty_cycle_noncumulative.pdf  - This is a 3D plot showing the duty cycle for different wind and seismic bins (percentiles)
Duty_cycle_cumulative.pdf   - This is a 3D plot showing the duty cycle when the wind or seismic behaviour is greater than or equal to the given percentiles 
Downtime_wind_seis.pdf  - This is a 3D column plot showing the integrated 'downtime' that results from a lock loss in the given wind and seismic bins (percentiles)
lock_losses.pdf  - This plot shows the number of lock losses per percentile bins, surf (matlab) makes it look a bit weird. 

I've also attached lock_losses.txt which is a list of the times in GPS when the lock losses occur (first column) and their duration in seconds (second column). The durations and loss times are only to the nearest minute unfortunately since I used minute trend data.

Percentiles.txt contains the wind (first row) and seismic (second row) channel values that correspond to 5% intervals starting from the 0th percentile (0,5,10...). These are for the mean minute trends though which are much lower than the maximum minute trends.