Displaying reports 66521-66540 of 83004.Go to page Start 3323 3324 3325 3326 3327 3328 3329 3330 3331 End
Reports until 11:40, Thursday 26 February 2015
H1 ISC
gabriele.vajente@LIGO.ORG - posted 11:40, Thursday 26 February 2015 - last comment - 14:26, Thursday 26 February 2015(16942)
Wandering line in DARM

Last night we noticed, looking at the real time spectrum of DARM, that there was a wandering line. The attached spectrograms show the peculiar behavior: about every 270 seconds (not regular) this line enter the spectrum from the high frequency range and moves down in a quite repetible way (the frequency has quite perfect exponential evolution with time). Then there is some sort of burst of noise before the line starts again from the high frequency.

This behavior seems different from the wandering line related to IMC-F seen at Livingston.

Images attached to this report
Comments related to this report
thomas.massinger@LIGO.ORG - 12:02, Thursday 26 February 2015 (16943)DetChar

I was just looking at the same feature. The burst of noise looks like a beatnote whistle, similar to what we saw at Livingston with IMC-F. At first glance, it looks like the whistle is occuring when the drifting signal crosses through the OMC length dither at 3.3kHz. I'm attaching a few spectrograms zoomed on to various levels to look more closely at the feature. The frequencies look discrete when you zoom in, it doesn't seem to be a continuous signal. Was there some kind of swept sine injection that was unintentionally left on during the lock?

Images attached to this comment
thomas.massinger@LIGO.ORG - 12:19, Thursday 26 February 2015 (16944)DetChar

I plotted a spectrum long enough to catch all of the frequencies of the signal as it swept down. The placement of frequencies seems more sparse at higher frequencies and becomes more densely packed as it dips below the kHz range.

Images attached to this comment
gabriele.vajente@LIGO.ORG - 13:16, Thursday 26 February 2015 (16945)

The feature is visible in REFL signals as well, hinting in the direction of something going on in the laser. It's visible as well in LSC-IMCL and LSC-REFL_SERVO_ERR

Images attached to this comment
thomas.massinger@LIGO.ORG - 13:27, Thursday 26 February 2015 (16950)DetChar

This feature is showing up in MICH, SRCL, and PRCL. It's more faint in MICH, but is very strong in PRCL and SRCL. It's also showing up in the input to BS M3 LOCK filter for the length DoF, but it looks like MICH was being used to feed back on the BS position. I didn't see any evidence of the signal in MC2 trans, IM4 trans, IMC-F, or the IMC input power.

Images attached to this comment
gabriele.vajente@LIGO.ORG - 14:26, Thursday 26 February 2015 (16953)

Problem solved: a SR785 was connected to the excitation input of the common mode board, and the excitation was on. We disabled the excitation input from the common board medm screen

H1 PEM (CDS)
james.batch@LIGO.ORG - posted 10:57, Thursday 26 February 2015 (16941)
Restarted projector0
The dmtviewer on projector0 used up all available memory on projector0 (it takes over a month to do this), so I rebooted the computer and restarted the dmtviewer display of seismic data.
H1 CAL (CAL)
nutsinee.kijbunchoo@LIGO.ORG - posted 09:41, Thursday 26 February 2015 (16940)
EX PCal camera reconnected

End X PCal camera lost connection last night. The camera control software crashed and didn't detect the camera when I restarted the software. I went in to restart the communication unit this morning and that solved the problem.

H1 PSL
jeffrey.bartlett@LIGO.ORG - posted 09:26, Thursday 26 February 2015 (16939)
Adjust ISS Power
Jason spotted the RefSignal voltage was 2.07V and Diffracted power was over 14%. I adjusted the RefSignal voltage to 2.13V bringing diffracted power to ~ 7.5%
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 08:04, Thursday 26 February 2015 (16936)
CDS model and DAQ restart report, Tuesday, Wednesday 24th,25th February 2015

model restarts logged for Tue 24/Feb/2015
2015_02_24 05:42 h1fw0
2015_02_24 09:03 h1lsc
2015_02_24 09:03 h1omc
2015_02_24 09:09 h1alsex
2015_02_24 09:09 h1iscex
2015_02_24 09:11 h1alsey
2015_02_24 09:11 h1iscey
2015_02_24 09:16 h1omc
2015_02_24 09:31 h1omc
2015_02_24 09:39 h1asc
2015_02_24 09:49 h1lsc
2015_02_24 09:51 h1susmc2
2015_02_24 09:56 h1calcs
2015_02_24 10:06 h1lsc
2015_02_24 10:14 h1asc
2015_02_24 10:19 h1susetmy
2015_02_24 10:19 h1susitmx
2015_02_24 10:24 h1susitmx
2015_02_24 10:26 h1susetmx
2015_02_24 10:28 h1oaf
2015_02_24 10:28 h1susitmy
2015_02_24 10:34 h1susbs

2015_02_24 10:38 h1dc0
2015_02_24 10:38 h1fw0
2015_02_24 10:38 h1fw1
2015_02_24 10:38 h1nds0
2015_02_24 10:38 h1nds1
2015_02_24 10:39 h1broadcast0

2015_02_24 12:01 h1pemex
2015_02_24 12:16 h1omc
2015_02_24 12:32 h1lsc
2015_02_24 12:35 h1omc
2015_02_24 12:52 h1pemex
2015_02_24 12:57 h1pemex

2015_02_24 13:34 h1broadcast0
2015_02_24 13:34 h1dc0
2015_02_24 13:34 h1fw0
2015_02_24 13:34 h1fw1
2015_02_24 13:34 h1nds0
2015_02_24 13:34 h1nds1

one unexpected restart. Maintenance day: work on ISC and SUS and CAL. PEM restart for RFM testing. Two related DAQ restarts.

model restarts logged for Wed 25/Feb/2015
2015_02_25 06:45 h1fw0
2015_02_25 10:18 h1fw0

two unexpected restarts.

H1 PSL (PSL)
peter.king@LIGO.ORG - posted 07:19, Thursday 26 February 2015 - last comment - 08:31, Thursday 26 February 2015(16935)
H1 PSL Laser Area Enclosure Test
04:57 Turned on the HEPA fans in the H1 PSL Laser Room.  I would like to run this test for at least
      a couple of hours.

      It is noticeable that as soon as the fans are turned on, the minimum and maximum values of the
      ISS percent diffraction vary by ~1%.

06:55 Turned off HEPA fans.

    In running this test, I had forgotten that running the HEPA fans generates heat, and is not a good
idea without turning on the air conditioning.  I switched on the air conditioning to bring the
temperature back down and switched it off after about 40 minutes.

    Attached is the output of the quadrant photodiode that is located inside the power stabilisation
photodiode box.  Assuming that DY is vertical and DX is horizontal, it appears that the vertical
alignment does not recover, whilst the horizontal alignment does.

    Also attached is the reference cavity transmission signal during the same period.  It seems to
recover.
Images attached to this report
Comments related to this report
peter.king@LIGO.ORG - 08:31, Thursday 26 February 2015 (16937)PSL
Attached is the temperature rise during the period concerned.  Of note is that the reference
cavity transmission recovered whilst the pitch alignment into the power stabilisation photodiode
box did not.
Images attached to this comment
H1 ISC
evan.hall@LIGO.ORG - posted 01:23, Thursday 26 February 2015 - last comment - 14:32, Thursday 26 February 2015(16931)
Closing common ETM alignment loops

Sheila, Alexa, Gabriele, Evan

Summary

In addition to the differential ETM loops, we now have closed the common ETM degrees of freedom using REFLA9I + REFLB9I. These loops are slow, with bandwidths of a few tens of millihertz.

Details

Previously (LHO#16883), we had closed loops around IM4 in order to reduce the amount of reflected light into REFL_A_LF. However, tonight we decided instead to close the common ETM DOF, so that the ETMs are nominally controlled in all four angular degrees of freedom. This (hopefully) leaves us free to pursue more loop-closing with the corner optics.

The common ETM loops are implemented in the CHARD filter modules. These modules are stuffed with the same filters as for their DHARD counterparts.

Comments related to this report
sheila.dwyer@LIGO.ORG - 01:40, Thursday 26 February 2015 (16933)

This is a screen shot of QPDs durring a well aligned lock tonight.  

Images attached to this comment
sheila.dwyer@LIGO.ORG - 02:28, Thursday 26 February 2015 (16934)

Since about 10:22 UTC Feb 26th, the IFO has been locked on DC readout with 4 ASC loops closed : DHARD PIT+YAW and CHARD PIT and YAW.  

We are leaving this locked with the intent bit undisturbed.  

lisa.barsotti@LIGO.ORG - 08:26, Thursday 26 February 2015 (16938)
For the records, ~3h lock
Images attached to this comment
evan.hall@LIGO.ORG - 14:32, Thursday 26 February 2015 (16954)

For this lock stretch the ETM ASC loop settings were a bit different from what I said above:

  • All filter modules: FM3, FM4, FM7, FM8, FM9, FM10
  • Gains were 8 ct/ct diff pitch, 30 ct/ct diff yaw, -4 ct/ct comm pitch, -5 ct/ct comm yaw.
H1 ISC
alexan.staley@LIGO.ORG - posted 00:30, Thursday 26 February 2015 (16932)
New green references for better alignment

Gabriele, Sheila, Evan, Alexa

Summary

We now have new green alignment references for the WFS that should bring us to a better alignment while on resonance.

Details

Now that we have enaged more ASC loops and touched up the alignment while on resonance (i.e. we acheived a recycling gain of 29), I have updated the green QPD offests and the ITM camera nominal positions in hope that this will improve our initial alignment. For reference, I have also included the old values that we have been using.

Y-ARM OLD NEW
QPDA P 0.0 0.3
QPDA Y 0.5 0.1
CAMERA P 229.9 216.5
CAMERA Y 315.2 302.6

 

X-ARM OLD NEW
QPDA P 0.0 -0.08
QPDA Y 0.0 0.09
CAMERA P 248.3 241.3
CAMERA Y 354.8 369.6

Note: we had touched up the ITMX camera nominal position once before (LHO#16825).  After one of our locklosses we ran the green wfs on the y-arm ONLY with this new configuration, and went through our inital alignment procedure. These new values seemed to be good. After another locklos, we then ran the green wfs on the x-arm to test this new configuration, and went through the inital alignment once again. This also seemed to be fine.

H1 SEI (SEI)
sheila.dwyer@LIGO.ORG - posted 23:34, Wednesday 25 February 2015 (16930)
riding out an "earthquake"

There's nothing on the USGS website, but we have been riding out some seimsic disturbance that reached 10 um/sec in the 0.03-0.1 Hz band, locked with DARM on RF.  

Nice!

Images attached to this report
H1 SUS
gabriele.vajente@LIGO.ORG - posted 23:12, Wednesday 25 February 2015 (16929)
ETMY gets periodically kicked

During all today locks, we could see from time to time the AS beam shake.

It seems that the cause is ETMY, which gets quite often kicked in pitch. Nothing is visible in yaw or in the other mirrors.

Images attached to this report
H1 ISC
sheila.dwyer@LIGO.ORG - posted 22:44, Wednesday 25 February 2015 (16928)
Differential ETM pitch loop

Today we have changed the plant inversion for the DHARD pit loop (which is really differential ETM).  

The first two attachments show the data collected, the data used for fitting, and the fit both at a CARM offset of 50 pm and on resonance.  The third attachment shows the fit after some poles and zeros were removed by hand.  Our strategy was to invert the plant for the on resonance case, and aim for a stable but very low bandwidth loop to engage durring the CARM offset reduction.  The resulting controller is plotted in the 4th attachment, this includes FM3,4,6,7,9,10 in the DHARD filter bank.  We are using a gain of 16 and the signal is AS A 45 Q.  

On resonance, we now have a ugf of about 150 mHz, a gain margin of 10dB and plenty of phase (last attachment).  The RMS of the error signal is still dominated by fluctuations between 0.5-0.1 Hz.  This was measured with the oplev damping on at full bandwidth. 

We later turned the OpLve damping down and saw an instability at 0.55 Hz, which could be due to multiple UGF crossings in this loop.

Images attached to this report
H1 ISC (AOS, SUS)
sheila.dwyer@LIGO.ORG - posted 22:06, Wednesday 25 February 2015 (16927)
PR3 alignment

Today Betsy brought to our attention that PR3 had moved yesterday durring model restarts.  We have now moved it to bring the ALS beatnote back to 5dBm, and we have since locked the full IFO with a recylcing gain of 29.  The attached screenshot shows that the OPLev is still miscentered, so it is probably still a good idea to recenter it in the morning.  

Images attached to this report
H1 ISC
keita.kawabe@LIGO.ORG - posted 16:11, Wednesday 25 February 2015 (16923)
Green X beam might be clipping somewhere between ICSTEX green Faraday and TMSX M3

Summary:

RIN of X arm green beam everywhere (input measured by QPD, transmission measured at corner, reflection measured by WFS) is much larger than Y arm for a broad frequency range, the descrepancy peaking at around 10Hz.

Looking at various things, the beam might be clipping somewhere between ISCTEX green Faraday and TMSX M3 (that's the HR/partial for IR/green to split the green main path and green QPD path).

This is not an ultra serious clipping, causing additional 1%-ish pk-pk RIN, but could be an issue for our initial alignment scheme. Needs more investigation.

Details:

First attachment, top panel shows various RIN when the arms are locked with reasonable alignment (ALS-TRX and TRY both more than 0.95).  Thick lines = X, thin ones =Y.

X arm RIN for input (QPD), transmission (ALS TR) and reflection (WFS DC) are all about 2 orders of magnitude larger than Y at 10Hz. The middle panel shows that the QPD signals for X arm shows similar structure, and it's mainly PIT.

On the bottom panel you see that the PIT to NSUM coherence is really high. This means that the structure is not due to some intensity noise from the laser, it's more likely that the PIT clipping is causing the RIN and increasing (or decreasing) PIT signal at the same time.

Perfect coherence between X QPDA and QPDB means that the clipping location is upstream of the QPD sled. High coherence between the QPD RIN and transmission RIN at 10Hz should mean that the clipping is upstream of TMSX M3 where transmission and QPD path are separated.

Back to the middle panel, the reflection RIN (WFS DC) is larger than input and transmission by a factor of 1.5 or so. This should mean that the clipping location cannot be upstream of the green Faraday on ISCTEX.

So the conclusion for now is that it's likely clipping between green Faraday and TMSX M3.

The noise is not stationary, it goes up and down, but it never comes down to the same level as Y arm.

The second plot shows that X arm has been like this for the past 6 months except for two brief periods.

(Note that I needed to set a factor of 0.685 calibration for X WFS DC NSUMs, as the DC value for these was about 1.45, not 1.00. I didn't have to do this to any other RINs.)

Images attached to this report
H1 General
jeffrey.bartlett@LIGO.ORG - posted 15:58, Wednesday 25 February 2015 (16924)
Ops Day Shift Summary
LVEA: Laser Hazard
Observation Bit: Commissioning  

07:15 Karen – Cleaning in the LVEA
08:00 Alarm on PY-199 – Notified Bubba & Kyle
08:11 Jim – Running testing on ETM-X, ITM-X, and HAM4
09:15 Kyle & Gerardo – Installing vacuum gauge on HAM1
09:25 Kyle & Gerardo – Out of the LVEA
12:09 Ken M – Going to Mid-X to recover parts
13:04 Filiberto – Working on Test Stand near Y-Arm spool
13:16 Kyle – In LVEA checking the HAM1 vacuum gauge
13:22 Kyle – Out of LVEA
13:40 Filiberto – Out of LVEA
15:17 Bubba – Going to Mid-X to receiving area
 
H1 ISC
alexan.staley@LIGO.ORG - posted 14:17, Wednesday 25 February 2015 - last comment - 17:26, Wednesday 25 February 2015(16920)
Decoding SWSTAT

Just for referecne. If you want to decode a SWSTAT value use the following, and replace '#' with the SWSTAT value:

cdsutils sfm decode #

Comments related to this report
jameson.rollins@LIGO.ORG - 17:26, Wednesday 25 February 2015 (16925)

There are a couple of other useful SFM tools inside of cdsutils as well:

You can get a textual display of the full current state of a filter module by using the 'switch' command without any arguments (note the leading "H1:" IFO prefix is optional):

jameson.rollins@operator1:~ 0$ cdsutils switch LSC-DARM
INPUT
OFFSET
FM7
FM7_ENGAGED
FM8
FM8_ENGAGED
FM10
FM10_ENGAGED
LIMIT
OUTPUT
DECIMATION
jameson.rollins@operator1:~ 0$ 

The 'sfm' command can also guess that you're looking to decode a SWSTAT:

jameson.rollins@operator1:~ 0$ cdsutils sfm 48832
INPUT
OFFSET
FM7
FM8
FM10
LIMIT
OUTPUT
DECIMATION
jameson.rollins@operator1:~ 0$ 

Note that SWSTAT doesn't include the "_ENGAGED" status bits that are included in the 'switch' readback above.  But you can also give 'sfm' SW{1,2}R values to get the full status:

jameson.rollins@operator1:~ 0$ cdsutils read H1:LSC-DARM_SW{1,2}R
12
1999
jameson.rollins@operator1:~ 0$ cdsutils sfm 12 1999
INPUT
OFFSET
FM7
FM7_ENGAGED
FM8
FM8_ENGAGED
FM10
FM10_ENGAGED
LIMIT
OUTPUT
DECIMATION
jameson.rollins@operator1:~ 0$ 

See 'cdsutils sfm -h' for help:

jameson.rollins@operator1:~ 0$ cdsutils sfm -h
usage: sfm [] 

decode/encode filter module switch values

commands:
  decode SW1 SW2                  decode SM1 and SM2 values into engaged button names
  decode SWSTAT                   decode SWSTAT value into engaged button names
                                  (NOTE: does not include DECIMATION)
  encode [+e] BUTTON [BUTTON...]  encode list of engaged buttons into switch values
                                  with +e don't include button engaged bits

If the commands names are left out and the encoding/decoding will be guessed.
Filter banks names may be specified by index when encoding
(e.g. '3' instead of 'FM3').
jameson.rollins@operator1:~ 0$ 
H1 ISC
daniel.sigg@LIGO.ORG - posted 16:03, Tuesday 24 February 2015 - last comment - 19:08, Wednesday 25 February 2015(16893)
OMC/LSC Model Split

(Kiwamu, Dave, Jim, Jeff, Daniel)

The LSC and OMC models have been re-partitioned, so that DARM and CARM (to the ifo) are processed in the OMC.

The current processing times are:

  mean (µs) max (µs)
lsc 30 37
omc 13 14
alsex 32 35
alsey 32 34
iscex 5 7
iscey 5 7
susetmx 48 50
susetmy 50 56

Only the OMC sends data to the ETMX/Y, and only ISCEX/Y send data back to the LSC. With no more than 13µs processing time one might expect that there is plenty of time to send the DARM signal to the ETMs without an IPC errors. But no! We still have one every couple of seconds. This is down from a ~10Hz error rate. Strangely, the ALS, which picks up the common tidal signal and is located after the SUS in the fiber loop, does not see any errors. We now suspect a problem at the receiving end. More investigations ongoing.

Comments related to this report
jeffrey.kissel@LIGO.ORG - 19:08, Wednesday 25 February 2015 (16926)CAL, DetChar, INJ
A few comments on the DARM topology changes that were made as a result of this split:

* Now that the OMC's DCPD's are fed into the DARM filter bank and the output is sent directly to the suspensions, we have removed one, inter-process communication, 16 [kHz] cycle (61e-6 [s]), delay or the equivalent of 22 [deg] of phase loss at 1 [kHz] (among other benefits like decreasing the turn-around time on the LSC computer, removing a whole bunch of will-never-be-needed input and output matrix elements, and just general cleanliness).

* The location / topology of where MICH, and SRCL feed-forward corrections are made has changed. The infrastructure for PRCL feed-forward correction does not exist (why? Every interferometer I know has *some* that has been corrected for in the past...).
Now, the MICH, and SRCL control signals are picked off, feed through a "MICHFF" or "SRCLFF" bank, respectively, and the outputs are sent to the LSC model's LSC output matrix. The LSC output matrix still have outputs for the ETMs, but their outputs are now fed via shared memory to the OMC model, and added in independently and respectively directly after the OMC model's LSC output matrix.

* Similarly, any *other* corner station photo-diode signals (POP, REFLA, POPAIR, REFLAIRA, REFLAIRB, TRX, TRY and their various combinations, REFL9, The Digitized Additive Offset for CARM, etc.), which can be chosen in the LSC model's LSC input matrix are fed over IPC directly to the output of the OMC model's input matrix.

* That means the location of feed-forward, with respect to hardware injections has changed, but this does not affect their impact on the loop. It has *not* changed with respect to the calibration lines, i.e.  the calibration lines are still added *before* DARM_CTRL is picked off.

I attach an updated diagram (the .pdf) of how the DARM path gets distributed about the interferometer. This updated diagram also lives here
/ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Documents/T1300088
Images attached to this comment
Non-image files attached to this comment
Displaying reports 66521-66540 of 83004.Go to page Start 3323 3324 3325 3326 3327 3328 3329 3330 3331 End