The LVEA main crane rail shimming as suggested by the survey crew from Duane Hartman & Associates Inc. has been completed. A copy of the shim changes will be entered in the DCC soon.

The attached plot (and script) shows the nominal TCS power levels required for O2 to correct for just the ITM substrate lenses.

The following values are assumed:

• ITMX substrate lens: -80km (single-pass)
• ITMY substrate lens: +590km (single-pass)
• Absorption: 250 +/- 50 ppb
• RH actuation: -9 uDiopters per Watt (single-pass)
• CO2 actuation: +62.3 uDiopters Per Watt (single-pass)
• Self heating: 487 uDiopters per Watt (single-pass)
• Nominal lens required in substrates: +50km (in front of ITM - see attached note from Chris)

The bottom line is that we will cease to need central heating around 45W on ITMX and 30W on ITMY and will need to start using the RHs to compensate for the thermal lenses. No consideration is yet given to HOM correction with annular CO2 heating.

 

Subject: Re: RC as-built design

Date: May 14, 2015 at 7:54:37 PM EDT

Hi All,

The value of the thermal lens that was always used when adjusting the cavities is 50 km.  

The issue which caused all of the confusion last summer was one of definition; i.e. what does it mean to have a 50 km thermal lens.  The plots Muzammil put together, on which the decision to include the thermal lens was based, modeled the thermal lens as being inside the ITM.  The model we used to adjust the optic positions had the 50 km thermal lens immediately in front of the ITM.  The effective focal length in the two cases differs by a factor of n (the index of refraction), with it being stronger in the model which was used to calculate the positions.  Because of this the positions were tuned to have a slightly stronger thermal lens than was originally decided on based on Muzammil's plots.  

Fortunately, Lisa and I discovered that this is essentially a non-issue since the length changes needed to tune for the two different thermal lenses are less than the length changes needed to compensate for tolerances in the measured radii of curvature of the optics.  
 

All T240s prrof masses that within healthy range (< 0.3 [V]). Great!


Here's a list of how they're doing just in case you care:
ETMX T240 1 DOF X/U = 0.077 [V]
ETMX T240 1 DOF Y/V = 0.094 [V]
ETMX T240 1 DOF Z/W = 0.119 [V]
ETMX T240 2 DOF X/U = -0.199 [V]
ETMX T240 2 DOF Y/V = -0.246 [V]
ETMX T240 2 DOF Z/W = -0.094 [V]
ETMX T240 3 DOF X/U = 0.093 [V]
ETMX T240 3 DOF Y/V = -0.087 [V]
ETMX T240 3 DOF Z/W = 0.06 [V]
ETMY T240 1 DOF X/U = 0.03 [V]
ETMY T240 1 DOF Y/V = -0.042 [V]
ETMY T240 1 DOF Z/W = 0.005 [V]
ETMY T240 2 DOF X/U = -0.168 [V]
ETMY T240 2 DOF Y/V = 0.029 [V]
ETMY T240 2 DOF Z/W = 0.132 [V]
ETMY T240 3 DOF X/U = -0.001 [V]
ETMY T240 3 DOF Y/V = -0.003 [V]
ETMY T240 3 DOF Z/W = 0.1 [V]
ITMX T240 1 DOF X/U = -0.023 [V]
ITMX T240 1 DOF Y/V = 0.275 [V]
ITMX T240 1 DOF Z/W = 0.202 [V]
ITMX T240 2 DOF X/U = 0.24 [V]
ITMX T240 2 DOF Y/V = 0.262 [V]
ITMX T240 2 DOF Z/W = 0.296 [V]
ITMX T240 3 DOF X/U = 0.064 [V]
ITMX T240 3 DOF Y/V = 0.247 [V]
ITMX T240 3 DOF Z/W = 0.239 [V]
ITMY T240 1 DOF X/U = 0.192 [V]
ITMY T240 1 DOF Y/V = 0.068 [V]
ITMY T240 1 DOF Z/W = 0.116 [V]
ITMY T240 2 DOF X/U = 0.196 [V]
ITMY T240 2 DOF Y/V = 0.266 [V]
ITMY T240 2 DOF Z/W = 0.214 [V]
ITMY T240 3 DOF X/U = 0.121 [V]
ITMY T240 3 DOF Y/V = 0.214 [V]
ITMY T240 3 DOF Z/W = -0.149 [V]
BS T240 1 DOF X/U = 0.054 [V]
BS T240 1 DOF Y/V = 0.091 [V]
BS T240 1 DOF Z/W = 0.22 [V]
BS T240 2 DOF X/U = 0.162 [V]
BS T240 2 DOF Y/V = 0.237 [V]
BS T240 2 DOF Z/W = 0.231 [V]
BS T240 3 DOF X/U = 0.134 [V]
BS T240 3 DOF Y/V = 0.087 [V]
BS T240 3 DOF Z/W = 0.024 [V]
 

Jim W suggested that I run the script for the STS's as well while I'm here.

There are 1 STS proof masses out of range ( > 2.0 [V] )!
STS C DOF Z/W = 3.155 [V]


All other proof masses are within range ( < 2.0 [V] ):
STS A DOF X/U = -0.947 [V]
STS A DOF Y/V = 0.13 [V]
STS A DOF Z/W = -0.068 [V]
STS B DOF X/U = 0.886 [V]
STS B DOF Y/V = 0.62 [V]
STS B DOF Z/W = 0.563 [V]
STS C DOF X/U = -1.536 [V]
STS C DOF Y/V = -0.929 [V]
STS EX DOF X/U = 0.516 [V]
STS EX DOF Y/V = -1.076 [V]
STS EX DOF Z/W = 0.387 [V]
STS EY DOF X/U = 0.518 [V]
STS EY DOF Y/V = 0.683 [V]
STS EY DOF Z/W = -0.266 [V]

FAMIS #4366  closed
 

As part as Tuesday maintenance today March 8, 2016 CDS system admins will be deploying a new file system ( /Ligo ) the switch over will limit the ability to use any workstation or server that mounts /Ligo until the work is completed; Once the switch over on the MSR has been done, every workstation must be updated and restarted.

Sheila, Jenne, Matt, Rob, Evan, Lisa

Several things happened today, more details will be posted later:
we locked several times in low noise (note: ASC in the old configuration with DC (not RF90MHz) centering, see week-end entries for more details): the best range we saw today was about ~70 Mpc, due to some peaks in the spectrum higher than usual -- the 290 Hz was particularly higher than during O1;
in low noise Sheila made several ISI shaking tests, Robert did some investigations in parallel as well;
we looked at the coupling into the OMC at full power: this measurement needs to be repeated to make sure the conclusion we get is right, as the inferred coupling to the OMC would be significantly lower than what assumed from previous measurements;
Jenne took some DHARD open loop transfer functions as function of the DARM offset;
some off-line investigations to get hints of the mystery noise happened as well, more details will follow.
 
Some of these things are not finished as an earthquake hit us around 10pm local time; we waited for two hours for the noise to go down again, but we couldn't really relock robustly afterwards, even when the ground motion seemed back to normal (to be investigated). 

Some items for our to-do-list that came up tonight (to be merged with what we already have on the control room whiteboard) are:
inspired by Kiwamu's analysis, modulate the vertical position of optics and look for changes in the DARM noise;
(new entry): look at the DARM rms, and see if there is some loop optimization that can be done to minimize it (in particular, check if rms optimization advocated by Jeff at the last commissioning workshop happened or not);
in-depth analysis of frequency noise, in particular look for saturations in the common mode board;
close the loop on this OMC coupling, and if it is real, distinguish between mode mismatch vs misalignment - if it turns out that the alignment into the OMC is bad, resurrect deacon alignment (ECR already submitted and approved).

Lisa, Evan

We repeated the DARM-to-OMC coupling test (25852) at full power.

Tentatively, the change in the violin mode heights with the OMC locked and unlocked suggests only a 75 % coupling into the OMC (i.e., a 25 % loss).

We are not sure why the violin mode at 502.8 Hz is fatter with the OMC locked, so we would like to repeat this test with a calibration line.

I made a quick "noise budget" which accounts for most of the H1 noise with just shot noise, coating thermal noise, a 1/f mystery noise, and a 1/f^4 "other noises" curve.  This is a much poorer version of the real noise budget, but it is enough to help with the mystery noise search.

State of H1: locking well, and made it to Low Noise multiple times

Commissioning:

• noise hunting

Site activities:

• Gerardo to CP3

Current Status:

• waiting out an earthquake, which arrived around 6:05UTC
• Commissioners here - planning to relock and continue working

Even if H1 had been brought back to low noise before the week-end, the SensMon was not properly showing the range. This was due to a change in the whitening filters in CAL_DELTAL_EXTERNAL_DQ that happened last week (see  Sheila's entry ). John Z updated SensMon to take the new filters into account (thanks John), so the range monitor is back, and the summary pages show it correctly. 

WP 5765  See T1600062 for details of all updates.

SVN UP'd:

hugh.radkins@operator3:models 0$ svn up
U    isi2stagemaster.mdl
A    ISI_to_SUS_library.mdl
Updated to revision 12797.
hugh.radkins@operator3:models 0$ pwd
/opt/rtcds/userapps/release/isi/common/models
 

hugh.radkins@operator3:src 0$ pwd
/opt/rtcds/userapps/release/isi/common/src
hugh.radkins@operator3:src 0$ svn up
A    WD_SATCOUNT_vb.c
Updated to revision 12797.

Top Level Model edits:

Added Paths to all BSC top level models to calculate the SUSPOINT motion in the ISI.  Once these are working in the ISI model, the calc done in the SUS model and the IPC to the SUS will be removed.  See the attached for a before (left) and after (right) look at the model changes.
 

This morning we had a combination of moderately high winds (gusts up tp 30-35 mph) and microseism above the 90% percentile, this is a combination of ground motion conditions where we had trouble durring O1.

We attempted to lock several times, and probably would have been able to if we had just kept trying, although we had random locklosses at diffrent stages of the CARM  offset reduction. 

One thing that we know is a weak point in our acquisition now is the ALS DIFF loop, so Matt and I had a look at improving that loop.  We saw that our UIM control filter, which has some modest plant inversion to make the crossover between the ESD and UIM stable, was not quite right.  We had features just above 2 Hz which were causing us to nearly have a second UGF there, and gain peaking was clearly visible in our control signals.  This was predicted by the sus model and our filters, although reality was a little worse than what was predicted.  

The first attached screnshot is the OLG before (blue) and after (red).  You can see that there was a small dip that nearly had multiple ugfs just above 2 Hz, which is improved a little.  THe second screenshot shows the crossover measured by injecting at L1, the third one shows the change to the filter. 

With this filter, we were no longer able to engage the 1 Hz resonant gain in the DARM filter bank.  From our model it isn't clear why that would be, but we also don't see any reason why we need such an aggressive ResG at the moment, so we are leaving it out.  

1/2 open LLCV bypass valve, and the exhaust bypass valve fully open.

Flow was noted after 95 seconds, closed LLCV valve, and 3 minutes later the exhaust bypass valve was closed.

Next over-fill on Thursday, March 9th before 23:59 utc.

It turned out that all my previous analysis did not correct for the time-varying optical gain when calibrating the cross spectra into displacement even though I thought I have done it. I have recalibrated all the O1 data with the optical gain properly corrected.

Fortunately, the conclusions I have arrived so far qualitatively did not change.

Related alogs: 25847, 25768

Here are some plots with the newly calibrated cross spectra, mainly to show there is no drastic changes.

Fig.1 Band limited rms of the cross spectra in time series for the entireO1 run. The old data (without the optical gain correction) are show as "+" symbols while the recalibrated data are shown as dots.

Fig.2 Ratio of the band limited rms, (new data) / (old data). Notice that the high frequency bands (bands 3-8) tend to have larger displacement now. The low frequencies do not fluctuate as big as those for high frequencies as expected.

Fig.3 A naive correlation diagram in which the linear dependency between high frequency bands (bands 5-8) is still visible.

Fig.4 Time series plot of scaled band 8 BLRMS, LVEA temperature and scaled vertical sensors of various suspended optics.

Laser Status:
SysStat is good
Front End power is 32.01W (should be around 30 W)
Frontend Watch is GREEN
HPO Watch is RED

PMC:
It has been locked 12.0 days, 22.0 hr 9.0 minutes (should be days/weeks)
Reflected power is 3.078Watts and PowerSum = 25.24Watts.

FSS:
It has been locked for 0.0 days 0.0 h and 15.0 min (should be days/weeks)
TPD[V] = 1.466V (min 0.9V)

ISS:
The diffracted power is around 8.465% (should be 5-9%)
Last saturation event was 0.0 days 0.0 hours and 15.0 minutes ago (should be days/weeks)

For further in-depth analysis of the trends, please refer to Jason O., Pete K. or Rick S.

FAMIS#4140  closed

I have power-cycled camera 18 and restarted it's server. It appears to be working again.  My first try at just restarting the server didn't work, only after power cycling the camera did it appear to be working.