Displaying reports 69381-69400 of 85849.Go to page Start 3466 3467 3468 3469 3470 3471 3472 3473 3474 End
Reports until 22:06, Wednesday 25 February 2015
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 General
edmond.merilh@LIGO.ORG - posted 15:19, Wednesday 25 February 2015 (16922)
In the spirit of "Alarm" Watching...

I have added some blinkies/flashies to the OPS_OVERVIEW medm screen. FSS: When the TPD Voltage drops below .9V a yellow alert blinker will appear under the FSS button. TCSX: A button similar to the one someone added for the Fast Shutter has been added and will turn red if the LASER should lose power. These are just for "heads-up" until something better can be arranged and implemented.

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 SUS
betsy.weaver@LIGO.ORG - posted 12:34, Wednesday 25 February 2015 (16918)
empty filters requested ON

While Stuart and I were looking at SDF and GRD monitoring, we noticed that there were some empty filters that were requested to be on, but were not on.  I've turned them off.  Attached are the 2 screens where I found such benign filters in the half-state (ETMX L3 LOCK, and BS M2 COIL).  They are off now.  We intend to get new safe.snaps tomorrow so likely any remaining leftover empty filtering will be cleared out.

Images attached to this report
H1 SUS (AOS)
stuart.aston@LIGO.ORG - posted 11:31, Wednesday 25 February 2015 - last comment - 12:44, Wednesday 25 February 2015(16917)
OpLev Power Spectra - Targeting ITMY
[Doug C, Jason O, Stuart A]

We are planning a B&K hammer training session on an OpLev pier during the maintenance period tomorrow. I conducted a survey of current OpLev power spectra to help identify any particular piers that we should target. The power spectra (attached below) suggest some very low resonances (3.3 Hz & 6.6 Hz) for ITMY, so we shall focus our attention there. n.b.PR3 looks to be misaligned.
Images attached to this report
Comments related to this report
betsy.weaver@LIGO.ORG - 12:44, Wednesday 25 February 2015 (16919)

Note, while the PR3 OL looks to have been decentered in some event last week, the PR3 itself took a pointing jump yesterday.  We might want to double check the PR3 alignment with comissioners before we bother recentering it.

Note, he the OL did not see yesterdays PR3 alignment, maybe because it is out of range.

Images attached to this comment
H1 PSL
edmond.merilh@LIGO.ORG - posted 11:12, Wednesday 25 February 2015 (16916)
PSL Weekly Report

Here are the trends for the past 10 days:

Images attached to this report
H1 General
jeffrey.bartlett@LIGO.ORG - posted 10:48, Wednesday 25 February 2015 (16915)
Morning Meeting Minutes
Seismic – Jim running tests on ETM-X, ITM-X, and HAM4 for Jeff K. 
Working on feed forward on HAM4

Suspensions – Stuart is rebuilding suspension models
Installed switchable Mid-Stage coil 
Cleaning up old/unused channels 

PSL – Realigned the RefCav to bring power up to 1.5V. Tightened loose periscope mirror mounts. These could be the source of the alignment drift.  

3IFO – Jodi and team parts hunting in the LVEA. 
They moved the IO parts top the staging building.  
The remaining three desiccant cabinets were moved to the VPW	
Danny checked optics for first contact
The Seismic team moved the last BSC-ISI into its storage container

FAC/VAC – Roughing on HAM1. 
Kyle needs to install a temporary gauge onto of HAM1
SnoValley – On site working on A/C at VPW and chiller yard
OpLev – Modifying grout forms. Hope to start grouting OpLev piers next week 
H1 SUS
betsy.weaver@LIGO.ORG - posted 10:46, Wednesday 25 February 2015 (16914)
PR2 TFs are healthy

As a follow on from my alog last week (16811), I ran TFs on the PR2 while the largish IFO pointing offsets were enabled.  With offsets of P = 1816, Y = 4315, the P and Y TFs look healthy.  Phew.

H1 SUS
travis.sadecki@LIGO.ORG - posted 10:42, Wednesday 25 February 2015 (16913)
SUS Driftmon updates

With some guidance from T. Abbott, I have gotten the SUS Drift Monitor back up and functioning.  I have updated all the suspension alignments to the most recent good lock stretch of 1108702216 GPS.  After this update, a few suspensions were showing that they are misaligned from this previously good alignment. 

PR3 - Pitch, not sure why this is aligned differently now.  Trends show this changed Feb. 24 at 20:00 UTC.  I could not find an aLog specifically stating that this SUS was touched.

SR2 - Changed Pit alignment to alleviate possible rubbing.  See aLog 16831.

RM, IM, and OM alarm level are still in a state of flux.  To be continued.

H1 PSL (DetChar, PSL)
jason.oberling@LIGO.ORG - posted 10:41, Wednesday 25 February 2015 (16912)
PSL DBB/ISS Scans

No significant changes from last week.

Non-image files attached to this report
X1 DTS (CDS)
james.batch@LIGO.ORG - posted 10:34, Wednesday 25 February 2015 (16911)
Update root and gds software on DAQ test stand
The version of root software used on x1work has been updated to root-5.34.21, the version of gds software for x1work has been updated to gds-2.16.12.4, to match what is used in the LHO control room.
X1 DTS (CDS, DAQ)
james.batch@LIGO.ORG - posted 10:13, Wednesday 25 February 2015 (16909)
Update daqd, nds on DAQ Test Stand
The daqd and nds software for x1dc0, x1nds1, and x1fw1 has been updated to branch 2-9, r3965.  It was fairly old, at r3626 and needed to be updated to test daqd protocol 12.1 with nds2 client software.
H1 SEI
jim.warner@LIGO.ORG - posted 09:29, Wednesday 25 February 2015 (16908)
FF looks mostly harmless

Since we started running feedforward on the BSC-ISI's, Jeff and Hugh noticed that the feedforward path is not controlled by Guardian. This means that if FF is engaged and the ready state is requested through Guardian, the St1 actuators will still be driving. From a safety standpoint, it looks like this probably isn't an issue. I took spectra this morning with the ITMX ISI off (FF off, too) and with FF only (no damping or isolation loops). The FF only state actually still provides some isolation above 1hz (see attached plot, dashed references are the off state, solid lines are FF only). I also turned HEPI off, then turned it back on while watching the ISI seismometers, and didn't see anything obviously terrible. The actuator signals stayed below a couple hundred counts the whole time, much like the ISI with damping only, and only the T240's got agitated while HEPI servoed to position, which is normal. It's still possible that whacking the HEPI piers could cause FF to do bad things, so...don't do that.

Images attached to this report
H1 SEI
hugh.radkins@LIGO.ORG - posted 09:27, Wednesday 25 February 2015 (16907)
Improvements to EndY HEPI Pumps Removes the last of Fluid Pressure Coherences

See JeffK's 16857 where he analyses the End Station's performance relative to the fluid pressure noise.  The attached plots compare those final performance numbers for YEND  from Sunday at 6pm pst with data taken 25 Feb at 0230utc -- after the EndY HEPI plumbing system maintenance detailed in 16899.

Bottom line--The DOFs still showing coherence on Sunday (Jeff's 16857) are all almost completely gone, there is still a bit of coherence in the HP dof in places between 10 & 100mhz.  So this maintenance would appear to be very important.  The DOFs remaining were the 'common' mode dofs.  That is, the Z and the HP modes of the HEPI--those dofs where the Actuators move in common.  All other dofs have counter moving actuators which one might expect a common noise like pump pressure to cancel out.

Now, understand, Jeff's work on the controller characterization and tuning provided most of the decoupling to the platform; this maintenance work just closed a few final loose ends.

The xml for these is /ligo/svncommon/SeiSVN/seismic/HEPI/H1/Common/2015-02-25_H1HPI_EndYStation_Coh_wISIT240s.xml

Images attached to this report
LHO VE
kyle.ryan@LIGO.ORG - posted 16:51, Tuesday 24 February 2015 - last comment - 10:14, Wednesday 25 February 2015(16901)
Pumped HAM1 to rough vacuum (4 hours pumping = 0.3 torr at pump inlet, HAM1 pressure???)
Kyle, Gerardo 

Added remaining bolts to HAM1 West door and finished torquing -> Soft-closed GV5 and GV7 (GV5 hard-closed on its own at only 20 psi) -> Pumped HAM1 with scroll pump via vent/purge valve (as such, atmospheric pressure remains on air-side of closed vent/purge valve) -> Opened GV5 and GV7 

Richard M. is investigating getting signal cables to HAM1 gauges 
Comments related to this report
kyle.ryan@LIGO.ORG - 10:14, Wednesday 25 February 2015 (16910)
Kyle, Gerardo

~0910 hrs. local, Wednesday morning -> Installed temporary pirani gauge controller on top of HAM1 so as to view pressure until CDS cabling gets installed -> HAM1 now showing 0.4 torr which is as expected.

In retrospect, I should have not pumped HAM1 without this to monitor -> I had reasoned that the view ports are exposed to 2 atmospheres (gauge) differential (both directions) during bench testing so are considered "safe" -> I now consider the failure mode whereby a view port could have cracked during pumping resulting in a measurable change in the pump down curve -> In this scenario we would not have opened GV5 and GV7 -> Lesson learned 
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 69381-69400 of 85849.Go to page Start 3466 3467 3468 3469 3470 3471 3472 3473 3474 End