[Aidan, Alastair]

Per the discussion on the position dependent coupling of CO2 noise to DARM, we injected a 23.8Hz line into CO2Y yesterday (using a function generator) yielding a 1.5E-2 /sqrtHz line in RIN for that laser.

We turned the laser on to inject 100mW onto ITMY. A line appeared in DARM at 23.8Hz

We used PICO_G Motor 3 to steer the TCSY beam around on ITMY and observed the magnitude of the line in DARM. By eyeballing the live spectra, I could roughly maximize the line around PICO motor counts [-1E4, 3E4]. Then we swept the beam in the vertical direction on the mirror until the line disappeared in DARM. We reversed the direction of the sweep, moving the beam through maximum coupling through to minimum coupling again. We returned the beam to the rough position of maximum coupling and repeated the procedure in the horizontal direction.

The results were a bit noisy. We used the following channels to track the position of the PICO_G mirror and the line magnitude vs time.

• t0 = 1138508180
• t_end = 1138510325
• power to ITM:'H1:TCS-ITMY_CO2_LSRPWR_MTR_OUT16
• X-position: H1:SYS-MOTION_C_PICO_G_CURRENT_X_POSITION
• Y-position: H1:SYS-MOTION_C_PICO_G_CURRENT_Y_POSITION
• DARM spectrum: H1:CAL-DELTAL_CTRL_DQ

We left the mirror at position [-1E4, 3E4] last night.

Following the scanning, I analyzed the data this morning and found that the, despite being noisy, we could estimate the maximum coupling point as [-5E3, 3.1E4] with an uncertainty of approximately +/- 3000 counts. I moved the mirror to this position this morning.

----

A word on the uncertainty:

• as previously established, the beam moves approximately 6E-6m on the test mass per count of the PICO mirror.
• The uncertainty of 3000 counts corresponds to approximately +/- 20 mm
• The single-pass thermal lens per Watt of CO2 laser central heating is around 39uD

We can estimate the maximum single-pass thermal tilt we should see because of the uncertainty in the alignment:

• defocus: S = 39uD/W
• wavefront, 1D: W = S/2 * x^2
• gradient: dW/dx = S*x
• centering uncertainty: sigma_xc
• maximum thermal tilt = S*sigma_xc ~ 40uD/W*20mm ~ 800nrad/W

If we operate the TCS in the range [0, 500mW], then we should anticipate up to 400nrad of thermal tilt induced in the IFO beam

Added 200ml water to Crystal Chiller. 

Peter K. added 350ml water to the Diode chiller (see aLOG #25343)  

Ran HEPI Pump Trends per FAMIS #1935. End-Y showed a cavitation after the power outage, which was corrected.  

Results from STS Centering Script:

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


Here's a list of how they're doing just in case you care:
STS A DOF X/U = 0.426 [V]
STS A DOF Y/V = -1.085 [V]
STS A DOF Z/W = -0.267 [V]
STS B DOF X/U = 0.688 [V]
STS B DOF Y/V = 0.468 [V]
STS B DOF Z/W = 0.405 [V]
STS C DOF X/U = 0.533 [V]
STS C DOF Y/V = -0.546 [V]
STS C DOF Z/W = -0.956 [V]
STS EX DOF X/U = 0.521 [V]
STS EX DOF Y/V = -1.057 [V]
STS EX DOF Z/W = 0.456 [V]
STS EY DOF X/U = 0.519 [V]
STS EY DOF Y/V = 0.741 [V]
STS EY DOF Z/W = -0.28 [V]

I forgot to alog this, its been usable for a few weeks now.

I made a script that will create a map of all the nodes and who is managed by whom. It uses the same packages as the normal Guardian maps for a similar look, and the same colors as the medms. The script will only map the current management, so if managers change, it will have to be re-ran for a new map. I will try to make this better later, but for now this will have to work.

Location: /opt/rtcds/userapps/release/guardian/manager_map.py

I attached a sample output.

T240 Centering script results:

There are 18 T240 proof masses out of range ( > 0.3 [V] )!
ITMX T240 1 DOF X/U = -3.297 [V]
ITMX T240 1 DOF Z/W = 0.439 [V]
ITMX T240 2 DOF Y/V = 0.505 [V]
ITMX T240 3 DOF X/U = -3.301 [V]
ITMX T240 3 DOF Z/W = -0.341 [V]
ITMY T240 1 DOF X/U = -0.433 [V]
ITMY T240 1 DOF Y/V = 0.359 [V]
ITMY T240 1 DOF Z/W = 0.34 [V]
ITMY T240 2 DOF Y/V = 0.43 [V]
ITMY T240 2 DOF Z/W = -0.345 [V]
ITMY T240 3 DOF X/U = -0.941 [V]
ITMY T240 3 DOF Y/V = -0.319 [V]
ITMY T240 3 DOF Z/W = -3.275 [V]
BS T240 1 DOF Y/V = 0.904 [V]
BS T240 1 DOF Z/W = 0.384 [V]
BS T240 2 DOF X/U = 0.96 [V]
BS T240 2 DOF Z/W = 0.481 [V]
BS T240 3 DOF Z/W = 0.927 [V]


All other proof masses are within range ( < 0.3 [V] ):
ETMX T240 1 DOF X/U = 0.158 [V]
ETMX T240 1 DOF Y/V = 0.143 [V]
ETMX T240 1 DOF Z/W = 0.19 [V]
ETMX T240 2 DOF X/U = 0.061 [V]
ETMX T240 2 DOF Y/V = -0.052 [V]
ETMX T240 2 DOF Z/W = 0.168 [V]
ETMX T240 3 DOF X/U = 0.153 [V]
ETMX T240 3 DOF Y/V = 0.008 [V]
ETMX T240 3 DOF Z/W = 0.113 [V]
ETMY T240 1 DOF X/U = 0.066 [V]
ETMY T240 1 DOF Y/V = 0.006 [V]
ETMY T240 1 DOF Z/W = 0.046 [V]
ETMY T240 2 DOF X/U = -0.126 [V]
ETMY T240 2 DOF Y/V = 0.059 [V]
ETMY T240 2 DOF Z/W = 0.148 [V]
ETMY T240 3 DOF X/U = 0.045 [V]
ETMY T240 3 DOF Y/V = 0.038 [V]
ETMY T240 3 DOF Z/W = 0.152 [V]
ITMX T240 1 DOF Y/V = -0.16 [V]
ITMX T240 2 DOF X/U = -0.227 [V]
ITMX T240 2 DOF Z/W = 0.219 [V]
ITMX T240 3 DOF Y/V = 0.18 [V]
ITMY T240 2 DOF X/U = 0.219 [V]
BS T240 1 DOF X/U = 0.207 [V]
BS T240 2 DOF Y/V = 0.182 [V]
BS T240 3 DOF X/U = 0.072 [V]
BS T240 3 DOF Y/V = 0.241 [V]

Feb. 3 2016 16:38 UTC Reconnected conlog-test-master to the same 99,560 channels are h1conlog1-master.

Added 350 ml of water to the diode chiller, as I noticed the red LED was on with the error
message about low water level.

4f H4 looks clean except for a small wipe mark near 1 o'clock close to the
retaining ring.

4f H1 has streaks visible with green light.  Wipe spots between 3 and 6
o'clock.  Possible spot/damage mark in centre of optic.  Hard to see.
Try cleanroom cotton tip to wipe pump light side.  Drag wipe removed
centre smudge.

4f H2 has a streak mark around 6 o'clock near the edge.  Also has a
hard to spot streak lined up with 12 o'clock and is ~3 mm wide.  Not
visible with white light, only seen with green light.

4f H3 has a spot around 7 o'clock near the edge.  Does not blow off.
Spot is ~2-3 mm from the edge.  Possibly on the pump light side of
the optic.  Hard to get to with the quartz rotator in the way.

Re-examined 4f H4 with green light.  Smudge in middle visible.
Vague spot visible under green light from the pump light side.
Spots visible from the pump light side, not visible from the H3 side.
Drag wiped surface, spot is now gone.

Quartz rotator surfaces look good under white and green light.

Spot on resonator side of output coupler, a little more than half
way from the centre to the edge, around 2 o'clock.  Drag wiped
clean.

Perhaps out of an abundance of caution it was good that we examined
the surfaces with green light.  Certainly a few wipe marks that were
present and not visible under a bright light source, were just visible
in green.  It might be that the wipe marks are inconsequential but at
this moment, it seemed prudent to deal with them.

Replaced intra-cavity shutter blade with new model.  The shutter
blades shipped from Livingston do not fit the external shutter as
there is a handedness problem.  EXTERNAL SHUTTER STILL
NEEDS UPGRADING.

Front end laser beam centered through MM2 iris, slightly off
to the left of centre as you look at the MM1 iris.  It is not clear
whether or not the beam was centred in the first place.

12:46 (PT) Turned on front end laser power watchdog.

Original mode matching lens positions:
L02 = 13.38, L03 = 6.42
L02 = 14.26, L03 = 6.35

PMC we have an offset somewhere as it does not lock to the
maximum transmission level unless the power on the locking
photodiode is turned down below the nominal 1.5V unlocked.
Upon some navel gazing, the offset might be due to some light
in the wrong polarisation falling on the photodiode.

ISS - adjusted waveplate until PDA DC = -10.0V and 
PDB DC = -10.16V.  Zeroed ISS QPD; new readings are 
dX = 0.0005 mm, dY = 0.0013 mm.





Jason, Peter

Summary:  Fairly straightforward recovery from maintenance day activities, which didn't end until after 4pm PST.  Several locklosses due to commissioning effort. 

Activity log:

0:04 Kyle back from MY

0:30 PSL crew done

0:39 Fil done

1:07 Jeff K to turn on EY ESD driver

3:37 cleared H1SUSETMY tim error

There seem to be two new rf oddities that appeared after maintenance today:

• AS90 seems to jump back and forth between two different offsets, maybe about once every hour or so.
• POP90 and AS90 both show irregular low-frequency motion, similar to what we see when an in-loop OSEM (or its sensing chain) goes bad. Ease of locking doesn't really seem to be affected, unlike the previous experience with bad OSEM electronics.

Jeff Kissel graciously made 4 StripTool templates for OPS use when having issues with WFS running away during green locking, as happened today.  These templates are:

ALSX_GreenWFS_Pitch_Metrics.stp
ALSX_GreenWFS_Yaw_Metrics.stp   
ALSY_GreenWFS_Pitch_Metrics.stp 
ALSY_GreenWFS_Yaw_Metrics.stp

and can be found in the usual place for OPS templates: /ligo/home/ops/Templates/StripTool.

These will likely be used with the assistance of a commissioner since I didn't catch all the intricacies of manipulating the WFS enough to explain it here, but they are there to save some time when needed.

I have reset all WD saturation counters for the platforms with warning. 

Also, I reset the HAM6 watchdog counter, which is not found on the OPS_HEPI_L4C_WD_SAT_CUSTOM.adl screen.  However, I was notified that HAM6 watchdogs were beyond 75% full via DIAG_MAIN.  Perhaps we should add HAM6 to this MEDM screen?  Or maybe not, since this seems to have been an ACT saturation, not an L4C??

See attached pics for details of what was reset.

[Jenne, JeffK, EvanH, Travis]

On our very first lock attempt (that made it past DRMI) after today's maintenence, we lost lock during the BS coil driver switching state.  Thanks to today's data saving work (see alog 25329), we now have some data to look at!

Attached are 2 figures of the same lockloss, one of which shows the whole time we were in the COIL_DRIVERS state, and the other zoomed in on the lockloss itself. On the top row of these figures, the left 3 plots are just power buildups, to indicate when the lock was actually lost.  The right-most plot is the ISC guardian state - state 505 is COIL_DRIVERS.  The bottom row of plots are the new FASTIMONs for each OSEM of the BS M2 stage.

These channels are plotted in units of ADC counts, but we have 40V/2^16 counts over a 40 ohm resistance, and the BS M2 actuation strength is about 1N/A.  The features in the LL channel are of order 100 counts, which corresponds to about 15 microNewtons.  For longitudinal, this is of order 60 nm of a kick to the BS.  The rms for MICH control above 10Hz is only 1e-14 m, so this is 6 orders of magnitude above the rms.  For pitch and yaw, this corresponds to about a 2 urad kick to the BS.  (Newtons to meters or radians from T1200404).

This seems like plenty to explain our locklosses. Next up: what to do about it?

H1 has 30 sender RFM channels on each arm, of which only 26 have corresponding receiver(s). So 4 are being sent and no model is using the data.

L1 has 29 senders on the X-ARM (of which there are 26 receivers), and 30 senders on the Y-ARM (of which there are 26 receivers).

So the two sites are very close in number of sending channels.

Analysis details: The base number of potential senders was derived from the main IPC file, looking for RFM0 and RFM1 ipc types. This resulted in 30 for H1-X and H1-Y, and 42 for L1-X and L1-Y. Because the ipc file is only appended to during compilation, if it has not been cleanly regenerated recently it may overcount the number of sending channels.

For each channel, I searched the models' RCG generated IPC_STATUS.adl medm file for the channel name (e.g. H1LSC_IPC_STATUS.adl). Assuming that no two ipc channels share the same name, if I found the channel name in the adl file this means it is a running sender with a receiver. For the remaining possible senders without receivers (H1-X=4, H1-Y=4, L1-X=16, L1-Y=16) I looked for the channels in the top level simulink source files (e.g. /opt/rtcds/userapps/release/*/l1/models/l1*.mdl). This showed that all four channels on H1-X and H1-Y do have sending models, and for L1-X 3 of the 16 had sending models, and for L1-Y 4 of the 16 had sending models.

If we can possibly remove some of the RFM channels which are not being received, additional RFM channels can be added to the loop with no risk.

For H1 the sending channels with no receivers are:

• H1:OAF-PEME[X,Y]_RFM
• H1:ASC-[X,Y]_TR_A_SUM_RFM
• H1:ALS-[X,Y]_ARM_RFM
• H1:ALS-[X,Y]_REFL_B_LF_RFM