Displaying reports 62901-62920 of 77255.Go to page Start 3142 3143 3144 3145 3146 3147 3148 3149 3150 End
Reports until 18:57, Thursday 30 October 2014
H1 SEI (ISC, SEI)
sheila.dwyer@LIGO.ORG - posted 18:57, Thursday 30 October 2014 - last comment - 23:24, Thursday 30 October 2014(14754)
unusual BS trip seems to cause DRMI lock loss

It seems as though an oscialltion in the BS (visible on the stage 2 GS13) caused a DRMI lock loss.  The oscillation seems to be in the ISI channels, but I don't see it in the control signals or on the OpLevs.

Images attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 19:49, Thursday 30 October 2014 (14755)

HAM3 also just tripped, we don't think there is anyone in the LVEA right now

Images attached to this comment
sheila.dwyer@LIGO.ORG - 23:24, Thursday 30 October 2014 (14758)

Chris, Kiwamu, Suresh, Sheila

We have had several more of these odd HAM3 trips tonight.  We chased it down to a problem in the IMC_LOCK guardian, where a huge impulse is sent to MC2 in the down state.   We are strongly suspicious of a the lines where the gain of MC2_M2_LOCK_L and M1_LOCK_L are set to zero, and the integrator in M1 and boost in M2 are switched off.  Both of these filters are switched with zero history, immediately.  We changed the boost in M2 to have the output ramped off over 5 seconds.  We also changed the code to nicely clear the integrator in M1:

        ezca.switch('SUS-MC2_M1_LOCK_L', 'INPUT', 'OFF')
        ezca.get_LIGOFilter('SUS-MC2_M1_LOCK_L').ramp_gain(0, 5)
        ezca['SUS-MC2_M1_LOCK_L_RSET'] = 2
        ezca.switch('SUS-MC2_M1_LOCK_L', 'FM1', 'OFF')
        ezca['SUS-MC2_M1_LOCK_L_GAIN'] = -1

We haven't loaded this, since by the time we figured this out we had already moved onto locking DRMI

One thing that is different tonight is that we started trying to use the ISC_LOCK guardian, which is managing the IMC_LOCK guardian.  It's not clear why this would have caused these kicks to the IMC. There is some kind of bug in the way that the ISC_LOCK is managing its subordinates, so sometimes they hang up, and do not leave a state which has finished even though there is a path to the requested state.

Fixing this problem in the ISC guardian may help to prevent the HAM ISI trips that we have occasionally had on restarting beckhoff code. 

H1 TCS (TCS)
aidan.brooks@LIGO.ORG - posted 17:30, Thursday 30 October 2014 (14753)
TCS RH ITMY test - 4W

I've set up a script to turn on the RH on ITMY around 2:30AM for 3 hours. To kill it if desired, either log in to operator1 and kill the tmux process, or just turn off the RH after it turns on.

H1 SUS (AOS, DetChar, ISC, SEI)
jeffrey.kissel@LIGO.ORG - posted 17:00, Thursday 30 October 2014 (14749)
Corner Station Optical Lever and Configuration Switch Status
J. Kissel

I attach pictures of the switchable configuration boards of all optical levers in the corner station. My fingers are supposedly indicative of the rack / chassis into which they're plugged, but I add a legend here anyways with the real rack numbers, and I include the exact switchable filter status. Note, I only report one of the channels' switch status, because (thank god) in every instance, all four channels are configured in the same way.

Rack          Board      Optical Lever    Config Board  |------------------ Switch Status ----------------|    Centered?  Raw Segment Counts
              Number                       Installed?    Board    Switch                                        
                                                        CH Name   CH Name    Function    HI   LO    ON/OFF        
SUS H1-R1       1        HAM2 Table?          No          N/A                                                  (HAM2) No     1:-339 3:-2243
  (Pg 1)                 HAM3 Table?                                                                                         4:-399 2:-3548 

                2        HAM2 Table?          No          N/A                                                 (HAM3) Maybe   1:-1260 3:-1167
                         HAM3 Table?                                                                                         4:-1921 4:-1594
                                                                                                                            
SUS H1-R2       1          none?              No          N/A                                                     N/A
  (Pg 2)
                2           PR3               Yes          B0       1       +24 [dB]     X            OFF      PR3 Yes-ish   1:-5600  3:-7400
                         (pgs 3-5)                         B1       2       +12 [dB]          X       ON                     4:-17800 2:-17500
                                                           B2       3       +6  [dB]          X       ON                
                                                           B3       4       +3  [dB]     X            OFF
                                                           B4       5       (1:10)            X       ON
                                                           B5       6       (1:10)       X            OFF
                                                           B6       7       (1:10)       X            OFF
                                                           B7       8       Latch        X            OFF
                                                              Total PR3 TF = (1:10), G = 18 [dB]

SUS H1-R4       1        HAM4 Table?          No          N/A                                                  (HAM4) No     ADC Noise
  (pgs 6-7)              HAM5 Table?

                2        HAM4 Table?          No          N/A                                                  (HAM5) No     ADC Noise
                         HAM5 Table?

SUS H1-R3       1           none?             No          N/A                                                  N/A
  (pg 8)                               
                2            SR3              Yes          B0       1       +24 [dB]     X            OFF      SR3 Yes-ish   1:-9100 2:-9200
                          (pgs 9-10)                       B1       2       +12 [dB]     X            OFF                    4:-7040 3:-9200
                                                           B2       3       +6  [dB]     X            OFF                   
                                                           B3       4       +3  [dB]     X            OFF
                                                           B4       5       (1:10)            X       ON
                                                           B5       6       (1:10)       X            OFF
                                                           B6       7       (1:10)       X            OFF
                                                           B7       8       Latch        X            OFF
                                                              Total SR3 TF = (1:10), G = 0 [dB]
                
SUS H1-R6       1            BS               Yes          B0       1       +24 [dB]     X            OFF      BS  Yes-ish   1:-6800 2:-6300
  (pgs 11)                 (pg 12)                         B1       2       +12 [dB]          X       ON                     4:-7250 3:-7350
                                                           B2       3       +6  [dB]     X            OFF                   
                                                           B3       4       +3  [dB]          X       ON   
                                                           B4       5       (1:10)            X       ON
                                                           B5       6       (1:10)       X            OFF
                                                           B6       7       (1:10)       X            OFF
                                                           B7       8       Latch        X            OFF
                                                              Total BS TF = (1:10), G = +15 [dB]

                2           ITMY              Yes          B0       1       +24 [dB]     X            OFF      ITMY Yes-ish  1:-2470 2:-2380
  (pgs 15)               (pg 16-20)       (NOT AS SHOWN)   B1       2       +12 [dB]     X            OFF                    4:-2250 3:-2900
                                                           B2       3       +6  [dB]     X            OFF                   
                                                           B3       4       +3  [dB]     X            OFF   
                                                           B4       5       (1:10)       X            OFF
                                                           B5       6       (1:10)       X            OFF
                                                           B6       7       (1:10)       X            OFF
                                                           B7       8       Latch        X            OFF
                                                              Total ITMY TF = (flat), G = 0 [dB]

SUS H1-R5       1           ITMX              Yes          B0       1       +24 [dB]     X            OFF      ITMX Yes-ish  1:-1000 2:-700
  (pgs 13)                 (pg 14)                         B1       2       +12 [dB]     X            OFF                    4:-1000 3:-700
                                                           B2       3       +6  [dB]     X            OFF                   
                                                           B3       4       +3  [dB]     X            OFF   
                                                           B4       5       (1:10)            X       OFF  
                                                           B5       6       (1:10)            X       OFF
                                                           B6       7       (1:10)       X            OFF
                                                           B7       8       Latch        X            OFF
                                                              Total ITMX TF = (1,1:10,10), G = 0 [dB]

Note that I've left ITMY with all of its switches OFF because we want to assess whether the internal gain of the QPD head (see D1100290) is set to the "high" (100 [kOhm] transimpedance) or "low" (10 [kOhm] transimpedance) -- and I got booted out of the LVEA for locking the IFO. Seems like 2000 counts is a little to low, we really want something like 10000 [cts] per quadrant. We will adjust tomorrow.

I've also confirmed that all over-all transfer functions for each optic has digitally compensated for correctly.
Non-image files attached to this report
H1 SEI
jim.warner@LIGO.ORG - posted 16:25, Thursday 30 October 2014 - last comment - 06:58, Friday 31 October 2014(14751)
Comparison of LLO and LHO sensor correction filters

Continuing a  trend of stealing from LLO without shame, I looked at the L1 ISI foton  file (via LLO's DAQ svn) to see what filters they were using for St1 sensor correction. I've attached some plots comparing some of the filters. It would be helpful if someone at LLO could summarize (again) what is being used in a complete and accurate way, because some of the filters have very similar names. FF is a common name for different filters. In the first plot, the green (I think) line is the sensor correction a version of the filter Rich Mittleman designed, that we have been using at ETMX with the BRS. The other lines, with an rdr are Ryans filters that I found in the LLO ITMY foton file, which I named based on what direction I found them. Second plot is the phases of same filters, with the same color scheme and order.

zpk's for the different filters:

rdr X,Y & Z Senscor

zpk([0.005868986282643151+i*0.005869222531082809;0.005868986282643151-i*0.005869222531082809;0;0;0;
    0],[0.02121320343296193+i*0.0212131204375177;0.02121320343296193-i*0.0212131204375177;0;0;
    5.326821252114442e-10;0.03999999945769176;0.0999999989897627;1.299999570000159;
    6.999932741807108],6217465930.447066,"n")

rdr Y Senscor

zpk([0.006840399999901201+i*0.01879390059988029;0.006840399999901201-i*0.01879390059988029;
    0.06062180000003715+i*0.03500000003808696;0.06062180000003715-i*0.03500000003808696;0],
    [0.01368079999995818+i*0.03758769978878637;0.01368079999995818-i*0.03758769978878637;
    0.03500000000007082+i*0.0606217999686012;0.03500000000007082-i*0.0606217999686012;
    0.01000000066387688;0.03999999933609382],99.46935875676593,"n")

Mittleman Senscor

zpk([0.05785089999994956+i*0.06894400006181636;0.05785089999994956-i*0.06894400006181636;0;0;
    1.054942208843087e-09;0.009999998945009785],
    [0.003420200000103372+i*0.00939692986876447;0.003420200000103372-i*0.00939692986876447;
    0.01267849999986304+i*0.02718920009938821;0.01267849999986304-i*0.02718920009938821;
    0.04499510000006567+i*0.05362309993610679;0.04499510000006567-i*0.05362309993610679;
    0.005000000000048375],0.006161864174656091,"n")

rdr Z Senscor

zpk([0;0;0],[0.003535529999897033+i*0.003535531890194072;0.003535529999897033-i*0.003535531890194072;
    0.000868241000053361+i*0.004924041464289278;0.000868241000053361-i*0.004924041464289278;
    50.0000000000001],252959718.8553666,"n")

Images attached to this report
Comments related to this report
richard.mittleman@LIGO.ORG - 06:58, Friday 31 October 2014 (14763)

The "Mittleman" and rdr Z" Filters (pink and green?) are both for use only with Z or a tilt correct tranlsation signal using Krishna's tilt meter.

The red, "rdr X,Y & Z" is Ryans 0.5Hz notch filter deisgned to be used in parallel with low frequency stage 1 feedback.

 

The blue is a substitute for the FIR filter chain(the FIR filter probably is better), obvously has a different sign from the others.

H1 AOS
edmond.merilh@LIGO.ORG - posted 16:00, Thursday 30 October 2014 - last comment - 08:22, Friday 31 October 2014(14723)
Daily Ops Summary

08:00 resarted Alarm Handlers; CDS overview: noticed some conflicting counts on fw1 and some timing flags at the mid station; Vacuum: noticed IP-01 flashing red. Sent out emails to the corresponding folks for a check-out.

08:30 ISS loop coming in and out of saturation. Diffracted power all over the place. I bumped the refsignal up a click and the diff power stabilized. I tried a series of clicks following and got the diff power back up to ~7.6%  

09:09 Betsy and Travis out to West bay to work on 3IFO Quad.

09:10 Andres out to W Bay

09:20 Peter F out to LVEA

09:55 J Bartlett, also Andres out of LVEA

10:25 Ryan reported a possible network outage lasting ~10 minutes maybe upstream of PM&L

? Alastair putting power meter on TCS X arm table (WP 4925)

11:12 Robert working in beamtube between mid Y and end Y (shaking tests)

11:21 Dan to end X to look for equipment

11:56 Shivaraj to end X and end Y to mount magnetometers on tripods

12:38 ISS first loop went erratic again until ~

13:19 Karen at end Y

13:51 Karen out of end Y

14:30 Dan H out to HAM6

15:20 Rana brought to my attention folks entering VEA areas. Not everyone is reporting their desire to enter to the operator. Cleaning personell are calling after they've arrived at end stations.

Comments related to this report
edmond.merilh@LIGO.ORG - 08:22, Friday 31 October 2014 (14764)

The ISS loop was sporadic all afternoon

H1 ISC
daniel.hoak@LIGO.ORG - posted 15:53, Thursday 30 October 2014 (14750)
ASC^2 QPD transimpedance box swapped, OMC PZT1 shutter logic flipped

As a first step towards a fast shutter at the AS port, I swapped the QPD transimpedance amplifier box for ASC-AS_C for one with the SUM output spigots for the shutter input.  From rack R5 slot 20:

Out: S1102836

In: S1301506

I also changed the P3 jumper on the OMC PZT LV driver board to the correct position (across pins 2 & 3).  Now, a 0V input to the 'shutter logic' input on the front of the OMC PZT driver box is recognized as a 'fault' condition (i.e., with 0V input, the PZT shutter function is triggered).  This draws the PZT1 drive down to 0V (from 10V).  It also pretty well disables the dither output to PZT1, so no OMC locking until we connect the PZT shutter input to a 5V supply (like, for example, the shutter logic controller on top of ISCT6).

It looks like the ASC-AS_C sum is about the same as before the swap, but we probably need to redo the dark offsets.

H1 SUS (AOS)
jeffrey.kissel@LIGO.ORG - posted 15:26, Thursday 30 October 2014 - last comment - 21:50, Thursday 30 October 2014(14732)
Gain filters in ETMX Optical Lever Input Filters?
J. Kissel, R. Abbott

Was checking the status of the ETMX optical lever against Doug's status report (see LHO aLOG 14711) before I took some measurements using it, and found that the ETMX optical lever's compensation filters (i.e. H1:SUS-ETMX_L3_OPLEV_SEG?) have to filters, "gain2" and "gain1.4" (which are gains of 0.5 and 0.707, respectively) that are turned ON. I couldn't find any aLOGs about these filters, and it doesn't really make sense to me to compensate for any analog gain, given that we normalize by the SUM.

Anyone know anything about this?


%%%%%%%%%% EDIT %%%%%%%%%%%
Doug's status chart reports values exactly backwards and bit-shifted up 1. "HIGH" bits are LO, and "B1" = B0. The confusion arised from Evan's convention for high vs. low, and that the switches are numbered starting at 0 on the board, and 1 right next to the switch. Therefore, the ETMX is compensated for correctly. 

Will post corrected assessment shortly.


%%%%%%%%%% Historical Log, for future reference %%%%%%%%%%%%%

Piecing together the puzzle, from Doug's aLOG (LHO aLOG 14711), and the various circuit schematics (Configuration Daughter Board D1001631, Chassis Assembly, ), Evan's recent PR3 tune up (LHO aLOG 14631), my aLOG from many moons ago (LHO aLOG 3619), and a phone call to R. Abbott, I can determine that having each channel in the following configuration (as indicated by Doug's aLOG, where B0-B7 is the configuration for the first channel, and the remaining 3 channels, B8-B15, B16-B23, and B24-31 are in the same configuration),
Switch     Function       Setting    Status
 Name                     HI   LO   
  B0      G = 24 [dB]           X      ON
  B1      G = 12 [dB]           X      ON
  B2      G = 6  [dB]      X           OFF
  B3      G = 3  [dB]      X           OFF
  B4      1:10 Whitening        X      ON
  B5      1:10 Whitening   X           OFF
  B6      1:10 Whitening        X      ON
  B7      Latch                 X      ON
Note -- and this seems to be a common misconception -- when the switch is LO (or "0", or away from the chassis as installed) the switch is ON / ENGAGED. Therefore, the total transfer function: G = 36 [dB], two stages of (1:10) whitening.

(filter zero and pole notation is (z:p) -- note that the poles and zeros is INCORRECT [i.e. inverted] in my old aLOG)

Thus, the current compensation scheme, with FM1 (10:1) with FM4 and 5 (the "gain" filters mentioned above), it seems as though the switches have been interpreted in exactly the opposite fashion as the schematic intends. Even worse -- the LATCH is ON, which means it's actually telling the board to engage whatever the settings were *before* the latch were engaged, and the current status of the bits B0 through B7 DON'T MATTER. #facepalm

Will get with Rana / Evan / Doug / Jason about this.

Comments related to this report
rana.adhikari@LIGO.ORG - 21:50, Thursday 30 October 2014 (14756)

PeterF, Rana

We checked out the SR3 optical lever signals and determined that we needed to turn on one stage of whitening (1:10) and no whitening gain stages to get us cleanly above ADC noise everywhere.

H1 AOS (TCS)
alastair.heptonstall@LIGO.ORG - posted 14:39, Thursday 30 October 2014 (14744)
Calibration of power from X-arm CO2 laser projector to CP

Measured power output of X-arm laser to be 56.3W directly after laser.  Thermopile in laser has a lower V/W sensitivity (0.116V/W) than others measured. I've updated the calibration to reflect this so that the channel H1:TCS-ITMX_CO2_LSRPWR_HD_PD_OUTPUT now gives correct laser output power.

I have also redone the calibration of the rotation stage using a second power meter on the table at the output to the CP.  The rotation stage position for a minimum output was correctly set at (37 degrees) giving a zero reading on a 100W and 10W power meter heads (we can go to a more sensitive power meter also, but here I'm measuring the full range of the rotation stage).  Maximum is seen at 82 degrees giving 5.44W.

Attached is a plot of angle to power for both power meters.

I've checked the calibration of the rotation stage, which was almost correct, and have slightly altered the maximum power output setting for this.  Minimum power and minumum power angle were both correct.

It looks like we are seeing the rotation stage not always going to exactly the requested angle.  This results in non-zero power output when minumum power is requested.  This is not an issue with the power meter - it is real.  So when there is a non-zero power reading on the power meter it means there is power going to the CP.  Repeated presses of the 'Go to minimum power' button result in the rotation stage eventually going to the correct angle.  If it still won't go to zero, then using the 'Home' button can reset the rotation stage position.

Images attached to this report
H1 CDS
david.barker@LIGO.ORG - posted 14:39, Thursday 30 October 2014 (14747)
script to report guardian nodes against the GUARD_OVERVIEW medm screen
I wrote a script which checks the guardian nodes (as listed by the 'guardctrl list' command) against the nodes shown on the GUARD_OVERVIEW.adl MEDM screen. It lists nodes which:
Here is the result of running the script:
 
david.barker@sysadmin0: checkGuardianNodesAgainstMedmScreen
-----------------------------------------
Guardian Nodes which exist, but not on GUARD_OVERVIEW medm screen:
IAS_TEST
-----------------------------------------
Guardian Nodes on GUARD_OVERVIEW medm screen but do not exist:

PSL
-----------------------------------------
done.
 
Should the node IAS_TEST be destroyed or added to the MEDM?
H1 SEI
hugh.radkins@LIGO.ORG - posted 14:25, Thursday 30 October 2014 - last comment - 15:14, Thursday 30 October 2014(14746)
WHAM2 ISI Guardian Tweeked--Changed Reference Location Load point

Observing the many trips HAM2 has experienced using the guardian recently, I've seen that after the first group of dofs are isolating, the remaining dof error points often grow large and when these dofs gains are ramped up, the ISI trips with a rung up GS13.  I saw that the guardian was loading the reference locations between the dof groups engagement.  Whereas the old seismic command scripts would only load the reference locations after all the dofs are isolating at the free hanging position.  Remember, the command script was not having any trouble turning the isolation back on.

Jamie modified the Guardian to do the loading of the reference location at the end of the isolation process like the command scripts.  When I got my window to test this, I actually forgot at first to restart the guardian.  And, the first couple times guardian was able to bring it up!  When I realized it wasn't doing it the new way, I remembered the restart, but I kept trying the guardian.  On the third or fourth attempt with the guardian it tripped.  I then restarted the guardian and then the guardian was successful at full isolation at least 6 times before the commissioners returned to the control room.

So again, my theory is, when the isolation loops are servoing to a place away from the free hanging position, the uncontrolled dofs error points can grow large.  This is dependent on many thing and lots of luck good & bad.  When the loop is engaged at low gain, the error point may be swinging about zero and if the loop gain is changed to 1.0 (from 0.01) at an unlucky time, bam goes the GS13.

Currently, HAM2 ISI is successfully back under Guardian conrol.

Comments related to this report
hugh.radkins@LIGO.ORG - 15:14, Thursday 30 October 2014 (14748)

Here are trends of the HAM2 ISO INMONs, OUTPUTS and the location servo Residuals.  I expected something to jump out in the OUTPUT or the residuals but nothing really at this resolution.  Well at least the INMONs correlate to the trip out.  You can see three successful isolations on these X & Y channels at the beginning of the plots.  You can see the OUTPUT quickly grow large after the gain has ramped.  On the fourth attempt, which is the trip, the INMON spikes much larger than before but I think it does so after the trip turn off...Yeah looked at full data and the large spike is after the OUTPUT drops to zero.

So well...I think my theory is sound but I don't think I've convinced anyone yet with data.

Images attached to this comment
H1 CDS
david.barker@LIGO.ORG - posted 13:44, Thursday 30 October 2014 (14743)
Reflective Memory IPC receive errors at end station SUS from LSC sender

Keith T, Jim, Daniel, Dave

As Keith mentioned in yesterday's CDS meeting, the RFM IPC error rate at the SUS model is related to the CPU usage of the LSC sender. To show this, I've attached a minute trend plot of the past 7 months of IPC error rates at SUS-EX, along with the CPU-MAX of the LSC model. As can be seen, when the LSC CPU-MAX is regularly around 40uS, the receive error rate goes up from 2 to 10 errors per 16384 received packets.

At 10 errors per 16384 packets, the error rate is 0.06%. Can we determine if this is significant?

questions/ideas which have been mentioned when thinking about possible solutions:

reduce LSC processing (filter modules unnessary or unnessarily complicated)
split LSC into two cores (again)
delay the RFM receiver by one whole cycle (adds 60uS latency to control signal)
replace LSC computer with faster hardware (being investigated by Rolf, Keith)
H1 PSL
edmond.merilh@LIGO.ORG - posted 13:31, Thursday 30 October 2014 (14727)
ISS maintanance

ISS first loop was all over the place as was the diffracted power at the beginning of my shift.  A slight tweak in the less negative direction set it back to stable. Further adjustment got it back to ~7:5% diff power at 2.04V refsignal. Perhaps more attention can be given to ISS on a daily basis by the operator on shift until a better solution can be implemented. 

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

Images attached to this report
H1 TCS (TCS)
aidan.brooks@LIGO.ORG - posted 13:31, Thursday 30 October 2014 - last comment - 11:10, Friday 31 October 2014(14742)
Required central heating to correct ITMX static lens: 201mW

Based on the TCSX central heating calibration (62.3 micro-diopters single-pass per Watt) and the calculated static lens of -80213m, we require:

+201mW of central heating on ITMX to correct this static lens.

Edited 31-Oct-2014: this isn't correct because of an error in the laser power calibration

Comments related to this report
aidan.brooks@LIGO.ORG - 11:10, Friday 31 October 2014 (14773)

The calibration of defocus vs delivered power is incorrect as the delivered power channel, H1:TCS-ITMX_CO2_LSRPWR_MTR_OUTPUT, was not calibrated correctly.

I went back and reviewed the delivered power for this measurement:

Before thermal lens: H1:TCS-ITMX_CO2_LSRPWR_MTR_INMON = 172.7 counts

During thermal lens H1:TCS-ITMX_CO2_LSRPWR_MTR_INMON = 2113.4 counts

The new gain through the filter banks is 7.2087E-4 Watts per count.

This means 1.399 Watts was applied to ITMX during the thermal lens measurement.

Further analysis of the HWS measurements of the thermal lens show:

  • the (double-passed) change in spherical power was 78.7 micro-diopters after 4.5 hours (close to steady-state).
  • the applied power was 1.399 mW

Therefore, the single-passed ITMX steady-state thermal lens coefficient is 28.1 micro-diopters per Watt

Based on the TCSX central heating calibration and the calculated static lens of -80213m, we require:

+444mW of central heating on ITMX to correct this static lens.

H1 CDS
david.barker@LIGO.ORG - posted 13:28, Thursday 30 October 2014 - last comment - 14:11, Thursday 30 October 2014(14741)
CSD guardian nodes stopped

Daniel, Dave

We have stopped the following CSD guardian nodes from running. They can be restarted at a future date if needed.

H1ECATC1PLC2
H1ECATX1PLC2
H1ECATY1PLC2
H1ISCEX
H1ISCEY
H1LSC
H1LSCAUX

If we choose to restart these, they should be generically renamed (dropping the H1 in the name)

Comments related to this report
david.barker@LIGO.ORG - 14:11, Thursday 30 October 2014 (14745)

also stopped the following nodes:

LSC
LSC_PRMI-VAR_FINESSE
H1 SEI (DetChar)
krishna.venkateswara@LIGO.ORG - posted 12:25, Thursday 30 October 2014 (14740)
More on noise in BRS/T240 below 30 mHz

K. Venkateswara

I've attached ASD and coherence plots from 40k seconds of data from BRS/T240 and the super sensor from last night. Wind speeds were in the 5-10 mph range. This time, I showed the raw signals coming out from BRS and the T240 X instead of showing the output of the filters. I've also shown the ref. mirror and the output of the super-sensor.

BRS has much larger noise below 2-3 mHz, than the T240, even though the sensor noise appears to be much less. It was interesting to me that it had a similar shape as the ref. mirror output and there does appear to be some coherence between the two. Temperature is the usual suspect at these frequencies. A sensitive temperature sensor on the BRS platform would be useful in diagnosing this noise.

Non-image files attached to this report
H1 SYS
jameson.rollins@LIGO.ORG - posted 12:21, Thursday 30 October 2014 - last comment - 13:27, Sunday 02 November 2014(14739)
new cdsutils.avg() interface and bug fixes

The current cdsutils installation (r361) has a new and improved NDS avg() function.  The previous version was buggy, was calculating the standard deviation incorrectly,  and had a clunky interface.  This new version fixes those issues:

fixes to standard deviation calculation

The standard deviation was previously being calculated incorrectly and the returned values were wrong (off by some unknown but kind of large factor).  The new version uses the python numpy.var() function to calculate the variance, from which the standard deviation is calculated.  It has been verified to be correct.

channel IFO prefixes no longer need to be specified

Previously, the avg() function required full channel names, with IFO prefixes.  This new version works like the ezca interface whereby the IFO prefix can be left off of the channel name.  This makes things much cleaner, and allows scripts to be portable.  E.g., instead of:

cdsutils.avg(2, IFO+':LSC-DARM_OUT')

just do:

cdsutils.avg(2, 'LSC-DARM_OUT')

new format for returned values

Probably the thing that's going to cause the most trouble is that the interface to the function has been fixed up.  Previously, the function was returning a dictionary of channel:avg key pairs.  This was very clunky to use.

The return value of the function now mirrors the input argument.  So for instance, if a single channel is requested, a single avg value is returned.  If a list of channels is requested, a list of average values is returned, in the same order as the input channel list.  So calls like:

avg = cdsutils.avg(2, 'LSC-DARM_OUT').values()[0]

can now just be:

avg = cdsutils.avg(2, 'LSC-DARM_OUT')

If the stddev option is provided, the output will be an (avg, stddev) tuple, or if multiple channels is requested, a list of such tuples, e.g.:

avg, stddev = cdsutils.avg(2, 'LSC-DARM_OUT', True)

I have fixed all calls to cdsutil.avg() that I could find in the USERAPPS/release.  I likely didn't catch everything, though, so be aware of the new interface and update your code appropriately.

Comments related to this report
rana.adhikari@LIGO.ORG - 23:07, Friday 31 October 2014 (14791)

controls@opsws5:sbin 0$ cdsutils -h

Usage:
  -c [OPTION...] - GStreamer initialization
 
Help Options:
  -h, --help                        Show help options
  --help-all                        Show all help options
  --help-gst                        Show GStreamer Options
 
controls@opsws5:sbin 0$ cdsutils avg -h
Usage:
  -c [OPTION...] - GStreamer initialization
 
Help Options:
  -h, --help                        Show help options
  --help-all                        Show all help options
  --help-gst                        Show GStreamer Options

rana.adhikari@opsws5|~> cdsutils avg -n 2 H1:LSC-MICH_IN1
ignoring first online block...
received: 1098858364 + 1.0
received: 1098858365 + 1.0
-195.380218506
 
Also would be helpful if these extraneous junk messages can be removed from the output. The idea of the "-n" flag is that only the number is returned so that we can use it in command line scripting.
jameson.rollins@LIGO.ORG - 13:27, Sunday 02 November 2014 (14797)

I pushed a new version of cdsutils (r366) that fixes the issue with the help.  Commands were being intercepted by one of the gstreamer libraries:

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

Advanced LIGO Control Room Utilites

Available commands:

  read         read EPICS channel value
  write        write EPICS channel value
  switch       read/switch buttons in filter module
  sfm          decode/encode filter module switch values
  step         step EPICS channels over specified range
  servo        servo EPICS channel with simple integrator (pole at zero)
  trigservo    servo EPICS channel with trigger
  avg          average one or more NDS channels
  audio        play NDS channel as audio stream
  dv           plot time series of NDS channels
  water        NOT SUPPORTED: No module named PyQt4

  version      print version info and exit
  help         this help

Add '-h' after individual commands for command help.
jameson.rollins@operator1:~ 0$ 

The "junk" messages, as you refer to them, in the avg output are actually just logging that are going to stderr, and therefore do not affect the stdout output:

jameson.rollins@operator1:~ 0$ foo=$(cdsutils avg -n 2 H1:LSC-MICH_IN1)
ignoring first online block...
received: 1098998811 + 1.0
received: 1098998812 + 1.0
jameson.rollins@operator1:~ 0$ echo $foo
75.2394218445
jameson.rollins@operator1:~ 0$ 

H1 SYS
jameson.rollins@LIGO.ORG - posted 12:03, Thursday 30 October 2014 (14738)
minor bug fixes pushed out for guardian and cdsutils, new guardian node log viewer

After the recent upgrades, a couple of small bugs were identified in guardian and cdsutils, and new versions were pushed out:

The new version have been pushed, and some of the guardian nodes have been restarted, but not all.  We should restart all nodes at the next opportunity.

New log viewer

I pushed out a new guardian node log viewing interface, so that you no longer need to ever type in a password when viewing logs.  This new interface can be used by using the new guardlog program that is now installed everywhere.  Just provide as arguments to the program the names of the nodes whose logs you would like to view, e.g.:

guardlog SEI_ITMY HPI_ITMY ISI_ITMY_ST1 ISI_ITMY_ST2

The logs of all specified nodes will be tailed, interleved as they are spit out, to the current terminal.  The GUARD medm control interfaces now use this log viewer as well.

tl;dr: A very lightweight "guardlog" server is now running on the guardian machine (h1guardian0), listening on port 5555.  Making a simple TCP connection to that port (with the guardlog client) will open up the interface and spit out the logs for the specified nodes.

H1 ISC (IOO)
kiwamu.izumi@LIGO.ORG - posted 19:11, Tuesday 28 October 2014 - last comment - 12:01, Thursday 30 October 2014(14690)
peek at PR2 baffle

Alexa, Kiwamu,

In response to Keita's alog about the PR2 baffle, we took a peek at the PR2 baffle by opening some of the viewports on HAM3 and HAM2 spool.

Conclusions:

 

(PR2 baffle check out)

We opened up a viewport on the East side of HAM3 which the leftmost one with an illuminator attached on. This was the only available viewport to open up. We removed the illuminator and looked at the baffle through the viewport. We confirmed that there was no cross bar structure on the side of the baffle unit as shown in the DCC document (D1000328). We could not see the top part of the baffle where it supposed to have a cross bar structure. We took some pictures and I attach them to this entry.

(Peek at the aperture position)

Then we tried a different zooming in the PR2 digital camera in order to have a better view so that we can determine if the aperture hole is in the middle of the baffle unit or not. With a help of flash light illuminating the PR2 baffle from the HAM2 East side viewport, we could clearly see the edge on both right and left sides of the unit as well as the edge of the aperture. It looked like the hole is centered with respect to the right and left edges of the unit. We took several pictures of it via the digital camera so that one can evaluate the position later if necessary.

(MC2 scraper baffle check out)

Then we opened up another viewport on the West side of HAM3 in order to see both MC2 and PR2 baffles. Though, the MC2 baffle was completely occulting the PR2 baffle and therefore we could not see it. We could still confirm that the MC2 baffle has a cross bar structure on the side as shown in the design document (D1000327).

Images attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 08:54, Wednesday 29 October 2014 (14699)

The baffle hole seems to be centered in the baffle frame within 3mm from the picture. Good.

The distance from the left baffle hole edge to the left inner edge of the baffle frame is about 52 pixels, it's 56 pixels  for the right, i.e. about 2 pixels offset to the left, which corresponds to 2 or 3mm.

Keita

keita.kawabe@LIGO.ORG - 12:01, Thursday 30 October 2014 (14737)

The hole diameter is also good (i.e. the ratio of baffle frame width to the hole diameter on the picture reasonably agrees with the spec).

Switch between the first attachment and the second to see if you agree with my assessment of the edges.

  Nominal Image
Baffle diameter 2.756" 53px
Baffle height 8.34" 160px
Baffle width 8.74" 165px
Diam/Width 0.315 0.321
Height/Width 0.954 0.970
Center offset none 2px to the left ~ 3mm
Images attached to this comment
Displaying reports 62901-62920 of 77255.Go to page Start 3142 3143 3144 3145 3146 3147 3148 3149 3150 End