Displaying reports 67441-67460 of 85335.Go to page Start 3369 3370 3371 3372 3373 3374 3375 3376 3377 End
Reports until 11:14, Tuesday 12 May 2015
H1 CDS
patrick.thomas@LIGO.ORG - posted 11:14, Tuesday 12 May 2015 - last comment - 11:48, Tuesday 12 May 2015(18375)
restarted h1ecatx1 computer
Did before its expected biweekly crash. Burtrestored to 10:10 am.
Comments related to this report
patrick.thomas@LIGO.ORG - 11:42, Tuesday 12 May 2015 (18378)
Well, it still crashed anyway. Restarted the computer again. This time the IOC failed to start. The IOC reports 'Failed to start', 'Failed to open ADS ports' for each PLC.
patrick.thomas@LIGO.ORG - 11:48, Tuesday 12 May 2015 (18379)
Logged into h1ecatx1. Opened the LIGO TwinCAT Target Configuration. Selected h1ecatx1, PLC1, PLC2, PLC3. Hit Restart EPICS database. This time it worked. Burtrestored again to 10:10 am.
H1 General
thomas.shaffer@LIGO.ORG - posted 10:21, Tuesday 12 May 2015 (18374)
ESD driver medm update and SYS_DIAG user guide

The ETMX ESD driver medm screen 'Active light' has been flickering when it is OFF. To fix this issue, I pushed this lower threshold to +/-325 from +/-200.

I also changed this in SYS_DIAG.

 

While talking about SYS_DIAG, I have made a wiki page for troubleshooting the usermessages that it will bring up. This is a page mainly to help operators find the source of the problem and how to resolve it.

It can be found here:  https://lhocds.ligo-wa.caltech.edu/wiki/SYS_DIAG%20Guardian

H1 SEI
hugh.radkins@LIGO.ORG - posted 08:29, Tuesday 12 May 2015 (18372)
Check how the STSs look with a big Earthquake--HAM2 Y no good

My usual image of ASD and coherence between the three corner station STS2s.

Great coherence pretty much on everyone from 1 hz down to .002hz except HAM2 Y.  HAM2 X is better but still not as good as Z or the other instruments.  With this signal size, there is no excuse for poor coherence.  I'm going to move the HAM2 sensor back to the BierGarten for one final check.

Images attached to this report
H1 ISC
stefan.ballmer@LIGO.ORG - posted 00:52, Tuesday 12 May 2015 (18370)
ITM QPD loop[ and SRCL FF work
Sheila, Kiwamu, Evan, Stefan

Today we first recommissioned the QPD transmon to ITM loops.
- We set the transmon QPD offsets to zero at 10W input power and engaged all four loops. This brought the recycling gain up to about 40 consistently.
- The optimal QPD offset seems to slightly depend on input power, which is why we set them at 10W for now.
- We want to see whether this type of QPD loop is consistent from day to day before we physically center them.
- The loops are now engaged at low bandwidth in the script.
- We haven't designed propper plant inversion and roll-off filters for the loops..

Next we went to low noise and re-examined the SRCL coupling For some reason the SRCL coupling gave no subtraction at all - just some noise reshaping. (It could be due to our QPD-to-ITM loop.)
- We remeasured the coupling by i) first driving SRC_EXC, and measuring the TF from SRCL_OUT to DARM_IN1, and ii) SRCFF to DARM_IN1. iii) the ratio i/ii should be the desired FF path.
- We first hand-fitted the TF: 
    poles: 0,0, 800 (Q=2)     zeros: 32 (Q=7) , -180
    or
    zpk([2.28571+i*31.9183;2.28571-i*31.9183;-180],[0;0;200+i*774.597;200-i*774.597],1,"n")gain(5)

- Note the negative frequency zero - a clear indication that we have two coupling paths. We should just design two separate FF path - this would allow for easy individual tuning of low and high frequency feed-forward.

- Unfortunately an earthquake struck during the filter designing, so we couldn't test them.


Images attached to this report
H1 AOS
keita.kawabe@LIGO.ORG - posted 18:40, Monday 11 May 2015 - last comment - 09:40, Tuesday 12 May 2015(18366)
SR3 really physically moves in PIT during a long lock. Why? (Stefan, Evan, Sheila, Kiwamu, Keita)

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.

Images attached to this report
Comments related to this report
suresh.doravari@LIGO.ORG - 21:20, Monday 11 May 2015 (18368)

How about using the SR3 oplev as a reference and feed back to the mirror to hold alignment as the mirror pitches forward?  It might serve to obtain longer locks during which you could tune the TCS to reduce this effect.  At present the SR3 oplev does not glitch and can be used during lock.   It has less than 0.01 microrads in pitch drift over 1000 seconds as shown in the LLO alog 18097.  The mirror motion and microseismic motion are also clearly visible above the noise floor.

keita.kawabe@LIGO.ORG - 09:40, Tuesday 12 May 2015 (18373)

Maybe it was not clear, but the point is that the SR3 motion itself isn't probably a serious problem, but the differential heating of ITMs might be, causing something funny in SRC, eventually causing the IFO to unlock.

H1 General
jeffrey.bartlett@LIGO.ORG - posted 15:57, Monday 11 May 2015 (18363)
Ops Day Shift Summary
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


H1 ISC (CAL, ISC)
sudarshan.karki@LIGO.ORG - posted 14:54, Monday 11 May 2015 - last comment - 19:23, Thursday 14 May 2015(18361)
Cavity Pole monitoring using Pcal Lines

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.

Images attached to this report
Comments related to this report
gabriele.vajente@LIGO.ORG - 16:24, Monday 11 May 2015 (18364)

Since the pole frequency is at about 300 Hz, it would be useful to have a high frequency line, for example at about 1 kHz. This will allow a better reconstruction of the pole frequency.

peter.fritschel@LIGO.ORG - 19:46, Monday 11 May 2015 (18367)

If you haven't already, I recommend also putting a notch in the DARM loop at 310 Hz. That way any phase change that occurs at 310 Hz in DARM should be a direct measurement of changes in the sensing phase (which would presumably come from a chang in cavity pole). I probably would have gone a little higher with the 2nd line, closer to 400 Hz. Why did you choose what you did?

sudarshan.karki@LIGO.ORG - 22:51, Monday 11 May 2015 (18369)CAL, ISC

Gabriele, We also have a permanent Pcal line at around 540 Hz. We thought it should be enough. Is there any advantage of going close to1 KHz?

Peter, I will have to talk to Jeff about putting a notch on the DARM loop, I am not sure how to go about it. Regarding the choice of 240 Hz and 310 Hz, knowing we already had one line at around 540 Hz we picked a pair of line between one of the non-vetoed frequency band of pulsars. We could easily shift the second line to 400 Hz. 

jameson.rollins@LIGO.ORG - 11:20, Tuesday 12 May 2015 (18376)

Larry Price did an analysis of just this situation, i.e. at what frequencies should you measure the transfer function to most optimally extract the features in the frequency response.  His analysis showed that the most optimal place is at the feature itself.  In other words, the best place to put your calibration line to most efficiently measure the cavity pole is at the expected cavity pole frequency.  See: LIGO-G1400084

evan.hall@LIGO.ORG - 04:15, Wednesday 13 May 2015 (18401)CAL

In light of this optimal, Fisher-matrix-based approach, Kiwamu and I have installed a notch in DARM at 322.1 Hz (actually an 80 dB elliptic bandstop from 321 Hz to 323 Hz). The goal is to inject a calibration line digitally into DARM control, so that we can use an LSC lock-in to demodulate the line.

We have set up LSC oscillator #3 to take OMC DC and demodulate it at 322 Hz. Both I and Q have 4th order butterworth low-pass filters. The lock-in output drives ETMX and ETMY differentially. The lock-in drive is currently 0 ct. It has not been set yet.

christopher.wipf@LIGO.ORG - 14:04, Wednesday 13 May 2015 (18411)

Better check the assumptions here. Doesn't Larry's result assume an open-loop measurement, white actuator strength, and white measurement noise (none of which holds in this case)?

kiwamu.izumi@LIGO.ORG - 19:23, Thursday 14 May 2015 (18439)

Chris,

Thank you for pointing it out. We also noticed that the assumptions were not quite valid in our case. On the other hand, Larry's analysis still gives us a good idea of what frequency we should excite. According to his Fisher matrix analysis, the measured transfer coefficient exhibits a maximum response to change in the cavity pole frequency when the excitation is at the exact pole frequency. This led us to a frequency at around 322 Hz. If you take the spectral shape of sensor noise (or DARM residual) and the actuator transfer function into account, probably a slight lower frequency than the current choice may be better, but since we wanted to have a notch in DARM far from the UGF, we chose it to be close to the cavity pole.

H1 SEI
hugh.radkins@LIGO.ORG - posted 12:45, Monday 11 May 2015 - last comment - 15:22, Monday 11 May 2015(18359)
STS2 A & B cables swapped at Interface--Noise goes away, again

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.

Images attached to this report
Comments related to this report
hugh.radkins@LIGO.ORG - 15:22, Monday 11 May 2015 (18362)

Tested the shut down/restart theory.  Over about an hour, I powered off the interface chassis and restarted it ~10 seconds later, five times over the course of this hour.  No obvious change in the spectra observed.  This power cycle is certainly quicker than the time to restart after switching cables much less to move the instrument from location to location, so, maybe, not a valid test.  Maybe the 'change' requires being off longer.  This morning when the extreme noise became just marginal, it was just a chassis cable swap but still probably took a couple minutes, not 10 seconds.

The Y channel signals for the HAM2 sensor have a bit worse coherence than the X channel, but the X channel too does standup to the solid coherence between ITMY & HAM5.

H1 CAL (DetChar, ISC)
jeffrey.kissel@LIGO.ORG - posted 12:30, Monday 11 May 2015 (18360)
This morning's DARM Coupled Cavity Pole: 303 [Hz]
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). 

Non-image files attached to this report
H1 TCS
eleanor.king@LIGO.ORG - posted 11:31, Monday 11 May 2015 - last comment - 08:01, Tuesday 12 May 2015(18355)
HWS power supply coupling into DARM

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.

Images attached to this report
Comments related to this report
aidan.brooks@LIGO.ORG - 08:01, Tuesday 12 May 2015 (18371)
H1 PSL (PSL)
jason.oberling@LIGO.ORG - posted 10:52, Monday 11 May 2015 - last comment - 17:12, Monday 11 May 2015(18358)
Weekend PSL Trips

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.

Images attached to this report
Comments related to this report
daniel.sigg@LIGO.ORG - 17:12, Monday 11 May 2015 (18365)

One thing to consider is that the EtherCAT safety terminals go to their nominal safe position, if communication is interrupted. Assuming that the safe state of the terminal corresponds to the tripped state, any communication error between the safety PLC and any of its safety terminals can trigger a PSL shutdown. Maybe check the system for lost frames?

H1 CAL (ISC)
jeffrey.kissel@LIGO.ORG - posted 09:33, Monday 11 May 2015 - last comment - 10:23, Monday 11 May 2015(18352)
5 to 5000 [Hz] DARM OLG TF, Take Four
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.
Images attached to this report
Non-image files attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 10:23, Monday 11 May 2015 (18357)
I've learned from Kiwamu this morning that the ITM control loops were OFF during the mini-run, and they're OFF now. Unclear if/when Evan & Shiela had them over the course of the measurements. 

On my list of things to track down during all measurements to see if they affect the DCCP and I can find a pattern:
- ITM alignment loops (differential ITM alignment influence is still under suspicion)
- ITM/ETM optical lever
- TCS power on ITMX (for SRC mode-matching)
- Transmitted Arm Cavity power (to track carrier PRC gain)
- POP18 / AS90 power (to track sideband PRC gain, and decouple SRC alignment)
- MICH / SRCL feed-forward status
It's gunna be one heck-of-a detective's adventure. I hope it's fruitful.
Displaying reports 67441-67460 of 85335.Go to page Start 3369 3370 3371 3372 3373 3374 3375 3376 3377 End