Tonight we again weren't able to engage the soft loops without pulling the sideband powers down and dropping lock, so I spent a little time on ASC. 

For one thing I looked at the phasing of AS36 A to see if we can reduce the SRM signal in the Q phase.  The reasoning for this is that the SRC loops are sensitive to the soft arms through AS_C, and if the BS is also sensitive to SRM this could be one way that moving SOFT misalings the beamsplitter.  However, it looks like we are already kind of using a phase that minimizes the SRM signal in Q, (-140), so I left this as is. 

I also had a look at the best combination of TMS QPDs to use, since we retuned this on saturday I was curious to see if the combination had changed today with a different alignment.  I checked only TMSX pit, but it had only changed by 1%, even with the soft loops off. 

Lastly, I tried to increase the bandwidth of the CHARD loops, in part because we know we need to do this, and in part because CHARD is cross coupled with the yaw loops and there is a long slow osciallation in all 3 loops due to this.  A screenshot is attached with settings that result in CHARD BWs similar to the DHARD ones, this initially does seem to reduce the long slow oscillation of the soft loops, but we still have the problem that the slow loops misalign the vertex.  I've added these settings, which are engaged with a lower gain and not the boosts on, to the guardian, but they will probably add noise, so we can reduce their gains when we want to go to low noise.

Top pannel is IM2 OSEMS.  Bottom pannel is select OSEMs from IM1, IM3, and IM4.

State of H1: locking and getting Engage ASC, Sheila working on the ASC

Site Activities:

• Maintenance included a reboot of all CR computers, including those on the walls
• All but nuc4 have been restored
• New code for EX VAC and CP8 PID loop - Kyle and Patrick still here evaluating
• Video0 has special vacuum screens so that the new code at EX can be monitored - blue sticky note on Video1
• nuc0 has the user "***-test" logged in - controls by itself didn't work
• DAC restart to change channels
• Kyle and Patrick were at EX to verify the new control software - back now

LVEA and OSB optics lab access:

• Nutsinee, Ed, Filiberto, Dick, Rick, Kyle, Gerardo, Robert, Richard

Currently:

• Sheila has H1 locked in Engage ASC, and is working on the ASC

I made a folder called beckhoff in /ligo/lho/h0/ve/medm and copied the new medm screens for the Beckhoff vacuum controls into it. I then changed the 'VE EX' link in the 'VE/FMC' drop down menu on the sitemap to point to /ligo/lho/h0/ve/medm/beckhoff/H0_VAC_EX_CUSTOM.adl. I committed the change to the sitemap into svn.

/ligo/lho/h0/ve/medm/beckhoff/H0_VAC_MENU_CUSTOM.adl is a mini sitemap for just these screens.

The screens that do not have CUSTOM in the name are generated from a script.

The files necessary to generate these screens are in the slowcontrols svn repository in trunk/TwinCAT3/Vacuum/MEDM/LHO.

Kyle, Patrick 

The new Beckhoff control parameters still need "tuning".  As of this writing, the control of CP8's level is via the Proportional term only.  Initial attempts resulted in overfilling which then resulted in a closed LLCV which then resulted in a warm transfer line.  Patrick and I opened the exhaust check valve bypass valve to relieve the back pressure and then cooled the transfer line via the manual LLCV bypass.  With the transfer line cold and the pump level responding to changes in the LLCV, I manually filled the pump to 95% full, closed the exhaust check valve bypass valve am leaving the LLCV manually set at 50% open overnight which is its recent nominal value to maintain the pump level.  

Jim Batch set up and included two MEDM screens so the X-end status can be monitored from home.  Patrick and Cheryl also are leaving an MEDM screen in the Control Room which can be monitored from home.  

2135 hrs local -> I'm leaving now and will monitor CP8's level from home (every 2 hours)

I changed the end X channel names to match the new Beckhoff channel names in /opt/rtcds/userapps/release/cds/h1/alarmfiles/ve.alhConfig. There are no new Beckhoff channel names corresponding to HVE-EX:GV19_CCOFFALARM and HVE-EX:GV19_OVERPRESSURE so I commented these out of the file. I will have to see if there are other channels that can be alarmed on instead of these. I committed the changes to svn in cds_user_apps/trunk/cds/h1/alarmfiles/ve.alhConfig. I restarted the alarm handlers on alarm0 to use the updated file.

The Beckhoff control system upgrade was performed at X-end today and I just wanted confidence for this value -> Both values agreed to with 1%.

Kyle. Gerardo, Chandra 

Gerardo -> Installed 12" CFF at HAM10 D8 and gauge pair isolation valve on BSC4 

Chandra -> R&R LVEA Turbo levitation batteries 

Kyle -> Drilled and tapped holes, mounted scroll pump local to Diagonal Turbo and upgraded gauge controller on Diagonal Turbo 

Kyle, Chandra -> Ran QDP80s, YBM, XBM and Diagoanl Turbos and vent/purge air supply (KOBELCO).  The KOBELCO displayed a "HIGH LUBE OIL TEMP" Warning after having run for a while.  Chandra noticed that the chilled water booster pump was off and that the output pressure once on was only 60psi (this may be the result of a reduced frequency running of the chilled water circulating pump - nominally this would be 90 psi - we need to investigate)  The measured dewpoint after > 1 hour of run time was <-30C.  Gerardo noticed that the Diagonal volume was still left connected to the purge air header from when it had last been purged, the isolation valve was then closed.

NOTE: The XBM Turbo spun up to full RPM but tripped off during the braking phase.  This Turbo has a history of high vibration - typically during the accelerating phase.  

A line at 47.683 Hz has appeared in the output of the stochastic O1 (time shifted) analysis. We have used the coherence tool to search for look for the source of this line in H1 and L1.

The line at 47.683 Hz appears very clearly in H1 in the h(t) coherence with H1:PEM-EY_MAG_EBAY_SEIRACK_X_DQ (week 13 example attached) and H1:PEM-EY_MAG_EBAY_SEIRACK_Y_DQ, in weeks 12, 13, 14, 16.

It also appears clearly in the L1 h(t) coherence, apparently associated with some other lines (eg, 47.42Hz) in weeks 5-10, 14, and 16 in these channels:

L1:SUS-ETMX_L1_WIT_P_DQ (week 5 example attached)
L1:SUS-ETMX_L1_WIT_L_DQ
L1:SUS-ETMX_L1_WIT_Y_DQ
L1:PEM-EX_MAINSMON_EBAY_3_DQ (week 5 example attached)
L1:PEM-EX_MAINSMON_EBAY_QUAD_SUM_DQ
L1:PEM-EY_MAG_EBAY_SUSRACK_X_DQ 

Finished the wiring and installation of the electronics for the new CPS timing distribution at EX, EY, and LVEA. CPS interface units need to be modified before switching to the new timing distribution.

I was only able to take the ETMY charge measurements today.  I've processed the results, and the last 2 weeks of data that others have taken.

Plots pending...

At Keita's request, I've added the summarized table info of modeled optic body modes from alog 20513 to the Resonance wiki.

Recall, the RESONANCE WIKI is here.
 

Per workpermit 5758 installed the new Beckhoff based vacuum control chassis and computer.  There were a couple of hardware issues.  First was the polarity of the 4-20ma inputs.  One set of 4 for the fan vibration monitors were fine but we had to swap the 3 for vacuum LN2 gauges.  Also plugged the Watchdog shorting connector in backwards which prevented the LN2 control valve from operating.  Once we fixed those issues the hardware and Beckhoff software worked fine.  The next problem was the gateway computer.  Some files needed to be modified to allow the channels to pass. I will let other comment on this.

For now the system is running and screens are being modified so the users will not see much difference.

I wrote a quick script that will change all of the gains in the appropriate degrees of freedom for the SEI Corner Station sensor correction. The gains should be 0 or OFF when recentering the STS, and then turned back ON after (assuming the chambers are up). I imagine there will be more guidence for operators to do this in the future.

The script can be found in (userapps)/isi/h1/scripts/Toggle_CS_Sensor_Correction.py

thomas.shaffer@opsws10:/opt/rtcds/userapps/release/isi/h1/scripts$ ./Toggle_CS_Sensor_Correction.py -h
usage: Toggle_CS_Sensor_Correction.py [-h] ON_or_OFF

positional arguments:
  ON_or_OFF   1 or 0 to turn the gain ON or OFF respectively

optional arguments:
  -h, --help  show this help message and exit
 

WP 5765 See T1600062  SEI log 897

Changed data storage rate for BSC:

1) ISI-optic_STi_MASTER_H(V)j_DRIVE & ST2_BLND_dof_GS13_CUR_IN1

This change means that for the next week or so, inquiries of these channels for times from ~5 days ago to before the restart will need to be via nds2.  And, one must avoid selecting a request or data that spans the change.  Middle of a maintenance day...maybe that should just be avoided anyway.

2) Increased allowable saturations on L4Cs, GS13s & ACTs to reduce unwarranted tripping.

3) Replaced some utility channels with lower case characters with upper case.

4) Replaced a momentary  with LONG_PULSE for STS2 mass centering function.

5) Added SUS Point calculation blocks (detailed in 25913.) ISI will take the overhead of calculating this to ease the load of the SUS model.

6) Added Stage2 senscorr DQ channels for T240 & CPS.

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.  
 

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.