Related alog: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=18269

Summary:

During long lock stretches where POPAIR_B_RF90 slowly drifts up, SR3 pitches up, and this seems to be a real PIT motion, not some bogus signal, even though SR3 is not touched by ASC nor LSC.

Turning SR3 back to the original angle when in lock doesn't restore POP90 (see the above alog by Evan), so this PIT is not the cause of POP90 drift, but rather the result of something else affecting both SR3 and POP90.

The time constant of SR3 drifting in-lock is much slower than the time constant of SR3 getting back after lock loss as was pointed out by Evan. The former looks as if it could be the mirror heating, and the latter could be the wire cooling.

The power buildup in the SRC itself is about 120mW or so according to Kiwamu and probably is not enough to cause wire heating by some scattered light.

Based on these, one possibility that Stefan came up with is that the heating of the ITMs changes the amount of higher order mode spilling over on the SR3 wires, causing PIT. Since wire heating is much quicker than the mirror, the time constant is equial to that of the mirror. Once the lock is lost, the power is lost immediately, and the cooling is determined by the wire alone.

We could play with TCS during a long lock to see how POP90 responds, and/or scan OMC to see the mode change during a long RF lock.

Details:

The two plots show the same set of signals. The first one is from last night and the second one is when Evan changed SR3 PIT manually while in lock.

If you look at POP90 (ch2), SR3 OPLEV PIT (Ch6) and SR3 M3 witness BOSEM PIT signal (ch9) in the first plot, they are almost perfectly correlated, and in this case SR3 moved by 0.7 urad. The fact that the motion is seen by oplev and bosem suggests that this is real.  Also, if the oplev signal is caused by e.g. some scattered light caught by oplev, the oplev sum (ch.8) should change at least 2% over the lock stretch, but in reality it changed by less than 0.2%.

SR2 PIT (Ch. 13) and SRM YAW (Ch.12) are also coherent with POP90.

SR2 PIT should be the result of ASC feeding back to SR2. In the second plot, when Evan turned SR3 back, SR2 also moved back.

SRM YAW might be the similar effect as SR3.

LVEA: Laser Hazard
Observation Bit: Commissioning   

07:00 Karen & Cris – Cleaning in the LVEA
08:06 Karen & Cris – Out of the LVEA
09:30 Sun Rentals delivery of scissor lift to Mid-X – Bubba escorted
09:43 Hugh – Going to CER to swap STS interface cables
10:00 Several small fires between Mid-X and End-X – Will monitor – Appears to be controller burning
10:13 Sun Rentals truck leaving site
11:13 Hugh – Going to CER to work on STS
13:40 Hugh – Going to CER to work on STS

SudarshanK, DarkhanT

We introduced two Pcal lines at 240 Hz and 310 Hz on photon calibrator at Y end.  The Pcal lines are about a factor of 10 above the DARM sensitivity at those frequencies. We will look into any changes in the amplitude and phase of these lines to determine the the position of cavity pole frequency. The cavity-pole has been observed at frequencies listed in  alog LHO #18360.

After swapping the cables at the interface, the noise on the A seismometer was gone (see attached)--should have been now on the B channel (it has never been seen on the B channel.)  Okay, one thing in common, the B cable has no shell so it has never been tightened onto the chassis and I had not tightened the A cable when connected to the B chassis.  Watching a running spectra, I tightened the A cable into the B chassis--no change observed.  Powered off the chassis and swapped the cables back A to A & B to B but did not tighten the screws--no noise seen once the signal settled down.  Then tightened the screws slowly while watching the spectra--no change in the noise seen.

The second attachment below is after the cables were swapped back to their correct positions.   Now looking closer and talking to Robert, we see that while the noise in the magnitude looks much better, it is still not as good in the coherence especially if you compare it to the Z channel.  With all the swaps and tests, it may be the powering off of the interface during swaps or moves that causes the problem.  This will be my next campaign; otherwise, move the HAM2 unit back into the BierGarten and swap the signals at the instruments.

J. Kissel

According to this morning's measurement of the DARM OLG TF (LHO aLOG 18352), comparing model against measurement -- which recall has a ~2.5%, 1 [deg] precision (see LHO aLOG 18186) -- the DARM Coupled Cavity Pole (DCCP) frequency was 303 [Hz]. 

Just to refresh everyone's memory, since the DCCP's frequency has been constantly evolving, I list below the measurement times and the resulting DCCP frequency for all measurements thus far. As mentioned in LHO aLOG 18352, now my goal to data mine as much information as I can, similar to what Kiwamu has done for just two of these measurements, see LHO aLOG 18298.

     Date UTC               DCCP Frequency [Hz]
'Mar 10 2015 03:41:52 UTC'        320
'Apr 02 2015 08:34:20 UTC'        320
'Apr 06 2015 23:45:13 UTC'        320
'Apr 13 2015 04:15:43 UTC'        290
'Apr 13 2015 06:49:40 UTC'        290
'Apr 15 2015 07:53:56 UTC'        290
'May 01 2015 18:52:59 UTC'        355
'May 02 2015 20:35:54 UTC'        355
'May 06 2015 11:37:31 UTC'        270
'May 07 2015 07:08:12 UTC'        260
'May 11 2015 15:50:43 UTC'        303


The attached comparison only shows the latest 5 of these measurements for clarity, because they extend out to the largest frequency range, increasing the confidence in the DCCP frequency.

Note this is also the reason why we've held off on updating the calibration of the CAL-CS (and therefore the GDS low-latency pipeline). 

Last week we put the EY HWS on it's own separate power supply to see if this would reduce the 57Hz coupling of the HWS into DARM.  This workes. When the EY HWS is on, we see no coupling into DARM at 57Hz. (See attached sprectum.)  EX is still on the shared power supply, and the 57Hz line is clearly present.  The current setup at EY is only as temporary setup.  It looks like we should permanantly move all the HWS onto their own power supplies.

On Sunday evening Elli and Nutsinee logged another PSL trip here.  Taking trends over this time shows that again the chillers appear to not be bringing down the PSL (first attachment).  I've also attached trends over the same time period of all the flow rates: diode and crystal chillers, front end, HPO heads, and power meters.  All these flow rates are where they are supposed to be.  The third attachment shows all the interlock signals we capture.  Only the H1:PSL-IL_OK trips, all other interlock signals indicate no problems.

Rick covered the PSL trip early Sunday morning in alog 18346.

Seismic: No activities
Suspensions: No activities
CDS: Finish making CPS cables – Will install at BSC1, 2, & 3 during the Tuesday window.
	     Continuing with work on AA/AI boards in H2 electronics building.
PSL: Tuesday work on RefCav alignment and Laser/Chiller tripping problem.
FMC: Painting in OSB 
Vacuum: Bake-out of RGA at End-X
Software: Work on timing distribution system  

Laser Status: 
SysStat is good
Front End power is 31.8W (should be around 30 W)
FRONTEND WATCH is RED
HPO WATCH is RED

PMC:
It has been locked 0 day, 17 hr 30 minutes (should be days/weeks)
Reflected power is 2.4 Watts  and PowerSum = 24.4 Watts.
(Reflected Power should be <= 10% of PowerSum)

FSS:
It has been locked for 1 h and 28 min (should be days/weeks)
TPD[V] = .93V (min 0.9V)

ISS:
The diffracted power is around 7.8% (should be 5-9%)
Last saturation event was 1 h and 29 minutes ago (should be days/weeks)

NOTES:

Noise study recap for HAM2, STS2-A instrument:

STS2-A Noise identified at orignal location (not first time) aLog 18207.

STS2-A moved to BierGarten (on concrete & under igloo) with different field cable--still looked bad, 18305, 18307.

Satellite cable and box swapped with STS2-B, noisy Y channel still with HAM2 channel--18314 (comment to 18305.)

Field Cable swapped at Chassis end (STS2-A & B signals swapped--bad channel should now be seen on the B channel data): Noise goes away, not seen on either channel!  Although the connector at Chassis for STS2-A had already been exercised when we moved to the new cable, this connection seems the suspect.  aLog 18324.

Spent 10 minutes wiggling and straining the cable chassis connection but could not get the channel noise to come back--18326, comment to 18324.  Chassis cables swapped back.  Signals still look good.

Friday afternoon I moved the STS2-A back to its home igloo by HAM2 with its orignal Satellite cable and box.  This morning, the noise has returned to STS2-A--see attached.

J. Kissel

The last few measurements of the DARM open loop gain transfer function have revealed that the DARM coupled cavity pole has gone back down to 270 [Hz] and 260 [Hz] (not posted yet), from where it was at the mini-run at a consistent 355 [Hz]. We're at the beginning stages of tracking this change in frequency dependence "online" by comparing high and low frequency PCAL and DARM calibration lines (and considering adding a few more to increase the precision of the analysis), but until that analysis gets into full swing, I'm taking every chance I can get to measure the DARM OLG TF.

Here's another data point. We're in the "LSC_FF" IFO state, with the request input power at 10.7 [W], MICH subtraction ("FF") was ON, but the SRCL FF has a gain of zero (!! -- forgive the file names "FFon," I hadn't actually checked until writing this log).

I'll have some more complete analysis (and an answer of what today's DARM coupled cavity pole frequency is) shortly.

Nutsinee, Elli

Today we noodled around a bit, but still don't have a measuremnt of SRC length.  Once Rick had reset the PSL trip, we spent of time recovering the alignment, locked DRMI, got were ready to take a measurement when the PSL tripped again.  Just like this morning, the PSL stystem status screen only showed the interlock ok bit was tripped.  The diode chiller flow bit was green and the chiller was working fine.  After talking to Rick,  we used the PSL card in the key storage box in the control room to get into the diode room and  reset the PSL.  We are starting to get tired, and are calling it a day.

J. Kissel

5.6 Mag Earthquake near Japan at 2015-05-10 21:25:46 UTC.

For quite some time, when an ISI's watchdog trips, it runs the equivalent of a "down" script via front-end code (see E1300685, installed circa Fall 2013). One of the many things the front-end down script does is to force the isolation feedback loop filter banks' gain to zero, 0.0. However, in the era of the Celerier system of SEI guardians, the ISI nodes are using some Jedi-Level-9 combination of the python tools in 
/opt/rtcds/userapps/release/isi/common/guardian/isigiardianlib/
to run the platform's isolation stages, and somewhere along the journey to "FULLY_ISOLATED," these filter banks are set to 0.1, and then 1.0 (and I don't think ever to zero, 0.0). Thus, when a watchdog trips, the new Set Point Monitor -- who thinks it's the only thing in control of these values -- sends a notification up the ladder that these gains to zero (0.0) have been changed by something other the guardian, i.e. the front end's down script. 

No big deal here, it just caught my eye while Elli and Nutsinee were asking me "Can I reset the SEI system... now? How about now?" after the earthquake mentioned above, and I recommended bringing the SEI manager to DAMPED (such they could regain alignment, but be robust while the EQ rings down). I presume we'd never notice, since rarely if every request this interim DAMPED state of the SEI systems these days, but in the interest of non-expert clarity, it would be good to sort this one out.

I attach a screenshot of the relevant MEDM screens in this state.

Also note ETMX HPI tripped which caused the ISI and SUS to go down a few seconds later, via horizontal actuators (see second attachment), and it looks to a pretty darn quick signal causing the trip. SYS_DIAG was reporting that the EX Tidal was near the edge of its range...

Evan, Sheila

The PSL has been working all night tonight.  We got a chance to try SRCL feedforward.  It works, but it doesn't improve the noise.  We saw that we were able to reduce the noise coupling by 12 dB at first, but then later saw that the coupling was changing by about 6dB at most. The second time we tried it we did not get as good subtraction.  Evan has new measurements of the SRCL coupling and frequency noise coupling to include in the noise budget over the weekend.  

Other things:

We used the TMSY picomotors to center the beams on the QPDs, this didn't change the combination of QPDs we used for the ITM loops.  We might want to check the normalization for the Y arm QPD next time we do inital alingment. 

We can switch SRM coil drivers in full lock, PRM, PR2, SRM, SR2 are now in the guardian in the DRMI_ON_POP state. 

We started to measure the ASC sensing matrix with all the loops closed including the ITM loops, we got a reasonable measurement for pitch, the data is all on disk although we had some trouble extracting it.  We were in the middle of tuning the yaw excitations when we got another earthquake.  We were moptivated to work on ASC because we have been aligning a little by hand before turning on the ASC all night, and we are hoping to find more diagonal signals so that we don't have to do this each lock.