Displaying reports 71741-71760 of 86133.Go to page Start 3584 3585 3586 3587 3588 3589 3590 3591 3592 End
Reports until 16:13, Saturday 01 November 2014
H1 SEI (SEI)
hugo.paris@LIGO.ORG - posted 16:13, Saturday 01 November 2014 - last comment - 16:14, Tuesday 25 November 2014(14794)
SEI Test Configuration Switching Scripts

A set of scripts was created last week to allow commissioners to switch SEI platforms to SEI’s preferred testing configuration at the end of their shift.

 

The scripts are very simple for now: 

Those new scripts were put in the svn so they can be remotely adjusted, and improved (made more generic, make classes/methods, etc…):
/ligo/svncommon/SeiSVN/seismic/BSC-ISI/H1/Common/Misc/Test_Configuration_Scripts/

To run those scripts:
$ cd /ligo/svncommon/SeiSVN/
$ python Switch_To_Test.py (at the end of the commissioning shift)
$ python Switch_To_Comm.py (when commissioning resumes)

Kiwamu used those scripts at the end of his shift on 10/28/14. JimW and I added the senscor switching capability on 10/29/14, which does not change the way to run the scripts.

Comments related to this report
jim.warner@LIGO.ORG - 16:14, Tuesday 25 November 2014 (15294)

These scripts are now executable. They are run by navigating to the folder and typing ./Switch_To_Comm.py or ./Switch_To_Test.py . They currently control HEPI Z and ISI X sensor correction for the X arm BSC's.

H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 08:39, Saturday 01 November 2014 (14793)
CDS model and DAQ restart report, Friday 31st October 2014

model restarts logged for Fri 31/Oct/2014
2014_10_31 08:44 h1fw0
2014_10_31 13:23 h1susauxh34
2014_10_31 13:33 h1broadcast0
2014_10_31 13:33 h1dc0
2014_10_31 13:33 h1fw0
2014_10_31 13:33 h1fw1
2014_10_31 13:33 h1nds0
2014_10_31 13:33 h1nds1
2014_10_31 21:46 h1fw0

one unexpected restart. New h1susauxh34 model (driftmon change) and associated DAQ restart.

H1 ISC
evan.hall@LIGO.ORG - posted 00:20, Saturday 01 November 2014 (14792)
Investigating REFLAIR_B

Alexa, Rana, Peter, Evan

Tonight we spent some time looking at REFLAIR_B to see if we could improve DRMI 3f locking. This was motivated by the experience at Livingston, where supposedly too much power on the PD causes RF saturation, which in turn screws up the demod phases of the DRMI length signals.

To test this, we drove PR2 with 300 counts at 131.7 Hz, and SR2 with 300 counts at 183.7 Hz. We then looked at the ASDs of RF135I&Q under the following configurations:

  1. The first configuration is with no ND filter. Incident power on the PD was 28 mW.
  2. Rana and Alexa then added an ND1.0 filter in front of the PD, and made sure to direct the reflection from the filter onto a razor blade dump. Incident power on the PD was then 3 mW.
  3. Rana and Alexa then replaced this with an ND0.5 ND filter. Incident power on the PDwas 8 mW.

The results are summarized in the table below. In each cell, the first number is the height of the peak (in cts/rtHz), and the second number is the pedestal that the peak sits on (also in cts/rtHz), and so the difference gives the net power. The bandwidth for all these ASDs is the same (0.1 Hz), so there should be no bandwidth normalizaton issue.

No ND PR2 drive SR2 drive
135I (cts/rtHz) 0.26 - 0.30 = 0 0.77 - 0.30 = 0.47
135Q (cts/rtHz) 0.56 - 0.30 = 0.26 0.29 - 0.30 = 0
ND0.5 PR2 drive SR2 drive
135I (cts/rtHz) 0.26 - 0.20 = 0.06 0.47 - 0.20 = 0.27
135Q (cts/rtHz) 0.62 - 0.20 = 0.32 0.22 - 0.20 = 0.02
ND1.0 PR2 drive SR2 drive
135I (cts/rtHz) 0.36 - 0.20 = 0.16 0.34 - 0.20 = 0.14
 135Q (cts/rtHz) 0.29 - 0.20 = 0.09 0.60 - 0.20 = 0.30

This seems to indicate that the PR2 signal transitions from 135Q to 135I as we lower the power, while the SR2 signal transitions from 135Q to 135I, consistent with the idea that there is some funny business with REFLAIR_B.

We tried locking DRMI on 3f with the ND0.5 filter in place, but found that we could not do it, even after increasing all loop gains by 3 to compensate for the decreased optical power.

The attached spectra perhaps show why. These were taken with DRMI locked on 1f. The dashed spectra are with the ND0.5 filter present, and the solid spectra are with no ND filter. With the ND0.5 filter, RF135I&Q seem to be noise-dominated above 10 Hz or so. Additionally, we note removing the ND0.5 filter does not boost the low-frequency portions of the spectra by 3.4 (=27/8), as we would expect. RF27I appears to be increased by a factor of 5 or so, while RF135Q appears to be increased by a factor of 10 below 1 Hz, and by a factor of 30 at 10 Hz. So there seems to be something strange going on.

Non-image files attached to this report
H1 ISC
kiwamu.izumi@LIGO.ORG - posted 19:52, Friday 31 October 2014 - last comment - 11:10, Wednesday 20 June 2018(14788)
unclipping on PR2 baffle

Alexa, Kiwamu,

We spent most of the daytime today for

There were a few noticable effects after the PR2 spot was moved:

 

Summary of the spot measurements before and after the unclipping.

    before [mm] after [mm]
PRM Pitch -2.82 NA
  Yaw 0.402 toward West NA
PR2 Pitch -6.04  -5.44
  Yaw 2.26 toward West 14.1 toward West
PR3 Pitch -24.5 NA
  Yaw 0 NA

 

(Some more notes)

We aimed for a displacement of 16 mm on PR2 in order to bring the beam to the ideal point according to Keita's measurement (see alog 14640). cheeky However, later, I realized that I had picked a wrong number from his entry -- I must have chosen eitehr 14 or 10 mm. Anyway, the resultant dither measurement suggested that we moved it by 11.5 mm to the right direction on PR2. So it happened to fall into a OK displacement. I think that we anyhow improved the clipping situation on the PR2 baffle.

The POP extraction path was then corrected by using the pico-motorized mirror in HAM3. This was not a difficult task as the beam was hitting the swiss cheese baffle and therore it was visible. We then went out and did fine tunings. The pico motor was adjusted to recover the highest green TRX. We steered a steering mirror for each POP diode.

In order to compute the off-centering on HLTS, I used the mirror sizes described in D1101381.

For computing the HSTS spot position, I used 42.2 mm per alpha (see alog 13765).

Comments related to this report
kiwamu.izumi@LIGO.ORG - 21:19, Friday 31 October 2014 (14789)

Alexa measured another set of the beam spots. Here are the summary:

    spot positions [mm]  
SRM Pitch + 3.42   
  Yaw 2.42 toward South  
SR2 Pitch + 2.42  
  Yaw 6.44 toward South  
SR3 Pitch -13.1   
  Yaw 19.9 toward North  

The measurement was done after the unclipping effort and we measured them in the DRMI sb lock configuration. The excitation was set at 131.7 Hz in order to reduce interference from the length loops. 

craig.cahillane@LIGO.ORG - 11:10, Wednesday 20 June 2018 (42600)
In 2017, Koji corrected his coil balancing calculations from 40m elog 2863

Now,  instead of , where  is the ratio of moment of inertia and optic mass,  is the coil force imbalance factor, and   is the distance between coils.

Corrected alpha to mm for HLTS optics: 
Vertical: 50.93 mm / alpha
Horizontal: 87.43 mm / alpha

For HSTS optics, see alog 42601
H1 SUS (SUS)
keita.kawabe@LIGO.ORG - posted 17:12, Friday 31 October 2014 (14786)
PR2 M3 LL FAST IMON is not working, PR2 M3 UR NOISEMON gain is low by 6db

This is not blocking our progress right now, but M3 LL FAST IMON is not working, and M3 UR NOISEMON is lower than others by 6 db.

I know that this not the problem of actuation as giving DC offset for each coil moves the optic by roughly the same amount in a correct direction, and VMON works for all coils. There's no reason to believe that there is a big difference in the current/counts between coils.

Images attached to this report
H1 AOS
evan.hall@LIGO.ORG - posted 16:50, Friday 31 October 2014 (14785)
PR3 oplev now aligned

Doug, Sheila Evan

We used the stage controller to align the PR3 oplev to <0.1 urad in yaw and pitch.

The dip switch board for PR3 now has the serial number H202. There are already H201, H203, and H204 in the oplev cabinet by the PSL. Other unlabeled boards should probably be assigned serial numbers accordingly.

H1 SUS (AOS, SEI)
jeffrey.kissel@LIGO.ORG - posted 16:17, Friday 31 October 2014 (14782)
End-station Optical Lever Configuration Switch Status
J. Kissel

I've collected all the information necessary to reproduce the corner-station optical lever status report (see LHO aLOG 14749) for the end-station levers. I attach pictures, and tabulate info as before below.

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-R2       1          ETMX               Yes          B0       1       +24 [dB]     X            OFF          No*      *SUS is Misaligned, 
  (pg 1)                 (pgs 2-3)                         B1       2       +12 [dB]     X            OFF                   so can't get info
                                                           B2       3       +6  [dB]          X       ON                
                                                           B3       4       +3  [dB]          X       ON
                                                           B4       5       (1:10)       X            OFF
                                                           B5       6       (1:10)            X       ON
                                                           B6       7       (1:10)       X            OFF
                                                           B7       8       Latch        X            OFF
                                                              Total ETMX TF = (1:10), G = +9 [dB]
 
                2          none               Yes          N/A                                                     N/A

SUS H1-R2       1          ETMY               Yes          B0       1       +24 [dB]     X            OFF          No*      *SUS is Misaligned
  (pg 4)                 (pgs 5-6)                         B1       2       +12 [dB]     X            OFF                   so can't get info
                                                           B2       3       +6  [dB]     X            OFF               
                                                           B3       4       +3  [dB]     X            OFF
                                                           B4       5       (1:10)            X       ON
                                                           B5       6       (1:10)            X       ON
                                                           B6       7       (1:10)       X            OFF
                                                           B7       8       Latch        X            OFF
                                                              Total ETMY TF = (1,1:10,10), G = 0 [dB]
 
                2          none               Yes          N/A                                                     N/A

I can confirm that any whitening stages have been correctly compensated for digitally. In addition, recall that ETMX is compensating for the gains shown above, but it's not necessary. Will fix all the levers and compensation on some (glorious) day (hopefully soon) when the IFO isn't needed.
Non-image files attached to this report
H1 General
jeffrey.bartlett@LIGO.ORG - posted 16:05, Friday 31 October 2014 (14783)
Ops Shift Summary
LVEA: Laser Hazard
Observation Bit: Commissioning

08:00 Alarm on Mid-X Instrument Air; informed the vacuum group
08:18 Aidan – In LVEA to check TCS laser
08:40 Travis – Going to both end stations to work on PCal cameras
08:55 Robert & Sudarshan - End-X to work on PEM
09:00 King Water – On site for water sampling
09:25 Bubba – Repaired Instrument Air compressor at Mid-X
09:30 Filiberto – End-X to work on PEM cabling 
10:05 Jodi & Gary – At Y-End
10:45 Betsy & Sheila – In LVEA for quick survey
13:05 Alistar – Working on TCS in LVEA
13:30 Dave – DAQ restart
14:38 Jeff K. – Going to X & Y end stations to take pictures of OpLevs
15:18 Robert – In the beam tube enclosure between Mid and End-Y
H1 PEM (PEM)
dale.ingram@LIGO.ORG - posted 15:52, Friday 31 October 2014 (14781)
Friday Seismic Forecast
Hanford transportation will operate during swing shift tonight, 10/31.  There's no indication that site crews will work over the weekend.  Over the last two weeks there's been some day-to-day variation in the number of containers moving in and out of ERDF because of high winds.  Transportation and rubble pit operations apparently aren't affected much by rain.
H1 SEI
hugh.radkins@LIGO.ORG - posted 15:39, Friday 31 October 2014 (14780)
WHAM2 HEPI Cartesian Plant Changes with corrected Matrices

In preparation to correcting the Matrices on HEPI for HAM2, I generated new Plants to see if they'll be too different for the generic controllers.  Here are the Symmeterized L2L & C2C,the latter equivalent to the plant with a HEPI Position loop blend (1,0.)  The L2Ls are the same as the previous (data from 4 Sept 2013) since I did not collect new data.  But the C2C are different.  Attached are two pdf with all the plots to compare.

Bottom line--asside from the VP dof at DC, they all look pretty much the same and I think the generic loops will be fine.

Non-image files attached to this report
H1 SEI (DetChar)
krishna.venkateswara@LIGO.ORG - posted 14:29, Friday 31 October 2014 - last comment - 10:19, Wednesday 05 November 2014(14779)
ETMX HPI controller change improved Stage 1 X low frequency performance

This is related to Hugh's log 14774. To elaborate a bit on Hugh's log, I made a measurement with Stage 1 Damped only and HPI isolated. The first plot shows the GND_T240_X ,  ST1_T240_X  and HPI L4C (out of loop witness). There was no coherence with ground below 0.1 Hz but there was significant coherence with HPI L4C. This meant that HPI was somehow introducing excess low-frequency motion.

We then did the same measurement on ETMY and saw no such excess motion. The second pdf shows the corresponding measurement. Stage 1_Y was very coherent with ground_Y. Jim mentioned he had modified the HPI controllers on ETMY as described in Hugh's log, so we decided to try the same on ETMX in X and Y.

This has made a significant difference to the low frequency performance of Stage 1 as shown in the third file. Performance below 0.1 Hz is much closer to ground motion now.

Non-image files attached to this report
Comments related to this report
jim.warner@LIGO.ORG - 08:06, Monday 03 November 2014 (14784)

Some more plots of the old vs new isolation filters, per Jeff's request. I dug into the foton file to find numbers to back up what I thought the original design was. The gains of the old and new foton filters are shown in the first image, they show that not much was done to the filter design, just that the gain was reduced. Solid lines are the old design(higher gain, UGF), dashed lines are the current design. Second and third images are the currently installed plant design and a reconstruction of the orignal design (no plots were found from the original design from earlier this year). The solid and dashed orange lines tell most of the story, mostly we just cut the UGF to 2hz, and modified the boost to get more phase margin. No idea why this affect the very low frequency noise, Jeff and Krishna suggested maybe we were re-injecting IPS noise with the higher gain.

Images attached to this comment
hugh.radkins@LIGO.ORG - 08:04, Monday 03 November 2014 (14803)

Here is another look at the controller with the amplitude scale zoomed out to see the lowest frequencies of the open loop.

Images attached to this comment
krishna.venkateswara@LIGO.ORG - 10:19, Wednesday 05 November 2014 (14863)

J. Warner, K. Venkateswara

We repeated this measurement today and did not see the same results. Sensor correction was off. The attached pdf shows the before (old controller) and after (new low gain UGF controller) data. Very strange. We may have been fooled by different ground motion or perhaps by sensor correction. There is good coherence with ground till ~60 mHz in either controllerconfiguration.

Jim has reverted to the new low gain UGF controller as it should help with ringing of HEPI at 9 Hz.

Non-image files attached to this comment
H1 CDS
david.barker@LIGO.ORG - posted 14:06, Friday 31 October 2014 (14776)
SUS-DRIFTMON: h1susauxh34 modified, DAQ restarted

Dave, Jeff [WP 4927]

the h1susauxh34 model  was modified to add EPICS channels to support the SUS Drift Mon program. The model was restarted at 13:22 and the DAQ was restarted to resync at 13:32. It was not a clean DAQ restart, mx-streams had to be restarted on h1pemmx, h1pemmy, h1susex and h1susauxex.

I reverted out my local changes to the driftmon files (changes needed when we didn't have the supporting epics channels) and svn updated this code to the latest version.

The Driftmon MEDM is linked to the SITEMAP via the SUS button on the left-hand block (see attached)

The python script to update the alarm levels is in the general search path. To run it to update all suspension the command is

driftmon_update.py H1 -H nds2.ligo-wa.caltech.edu -P 31200 -l 3600 -d 600 --minor-stdev=4 --major-stdev=5 --all

This gets data starrting one hour ten minutes ago up to one hour ago.

This closes out WP 4927.

Images attached to this report
H1 DAQ (CDS, DAQ)
keith.thorne@LIGO.ORG - posted 14:00, Friday 31 October 2014 (14775)
Commissioning and science frame fast-data rates at LHO (corrected)
The ever eagle-eyed Peter Fritschel found some duplicate PEM channels in my list of science-frame channels (see earlier aLOG entry 14718).  I had failed to remove an old channel list (H1PEML0.ini) from the compilation.  I redid all the files and tables after that change (see attached rate, channel list files). The commissioning-only counts did not change, as all PEM are in both frames)

I have posted the updated FrameRates spreadsheet and PDF of science, commissioning frame counts.

The science-frame H1 PEM rate drops from 6.79 to 4.19 MB/s (uncompressed). This is still equal to all the ISC channels (LSC,ASC,OMC,OAF,ISC).
Non-image files attached to this report
H1 SEI
hugh.radkins@LIGO.ORG - posted 13:52, Friday 31 October 2014 - last comment - 14:26, Friday 31 October 2014(14774)
WBSC9 ETMX EndX HEPI X & Y Isolation Loop Boost's Gain 'UGF' Lowered

Jim Krishna Hugh

The gain was too close to the UGF and there was very little margin.  The zero in the boost where it meets the main controller was lowered from 1.75 to 0.75 hz.  This lowered the boosted gain but it is only a position loop anyway.

Comments related to this report
hugh.radkins@LIGO.ORG - 14:17, Friday 31 October 2014 (14777)

Here is  before and after plots--it seems pretty obvious that this was a problem.  Very interesting how it affects things below 100mHz--see Krishna's alog.  The first is before, the second after the change.--Need to svn the foton file.

Images attached to this comment
H1 ISC
kiwamu.izumi@LIGO.ORG - posted 02:16, Friday 31 October 2014 - last comment - 21:54, Friday 31 October 2014(14762)
Several attempts for CARM reduction

Lisa, Rana, Evan, Sheila, Chris, Kiwamu,

The DRMI was stable tonight. So we did several attempts for reducing the CARM offset and the smallest we got tonight was 125 Hz in IR. We will performe careful analysis of lock losses tomorrow.

Lock loss events to lock at are: 7:59:30, 8:11:09 and 8:56 UTC. The second one reached 200 Hz in IR and the last reached 125 Hz. We decreased the MICH gain from 7.9 to 3.0 because its UGF was found to be too high when the arm cavities were held at a off resonant point. According to the lockin demodulators, all the loops stayed without a significant gain change or anything. ALS COMM seemed to tend to lose its lock when it is "IR FINE TUNE". We need to investigate what causes lock losses.

Comments related to this report
kiwamu.izumi@LIGO.ORG - 21:54, Friday 31 October 2014 (14790)

I made an offline analysis of the last lock loss event.

It looks like some kind of instability happened and all the three loops oscillated at 5 or 6 Hz. Since all of them showed similar oscillatory behavior, it is difficult point out which loop was unstable. My guess is that this instability was induced by alignment fluctuation of the DRMI which eventually resulted in a mod hop in SRC -- the hopping-ish events are visible between t= -2.2 and -2.0 where POP18 is glitchy and AS90 went to negative and positive values back and forth. The CARM offset was set to 125 Hz in IR at this time.

Images attached to this comment
H1 ISC
evan.hall@LIGO.ORG - posted 23:42, Thursday 30 October 2014 - last comment - 19:16, Friday 31 October 2014(14757)
Measurement of 1f and 3f sensing matrices for DRMI

Rana, Kiwamu, Lisa, Alexa, Sheila, Evan

We took some time to measure the 1f and 3f DRMI sensing matrices.

To do this, we used the digital lock-in oscillators on the LSC screen to feed back onto some of the DRMI optics (PR2, SRM, BS, and a combination of 1×BS + 0.02×PR2 that we refer to below as BS+PR2).

The procedure was as follows:

  1. In the first digital oscillator lock-in matrix, we wired REFLAIR9I→DEMOD 5, REFLAIR9Q→DEMOD 6, REFLAIR45I→DEMOD 7, and REFLAIR45Q→DEMOD 8. Each demod had an 0.1 Hz Butterworth filter.
  2. For each demod, we made all the power appear in I by running, e.g, cdsutils servo -r LSC-LOCKIN_1_DEMOD_5_Q_OUTPUT -g -10 -s 0 -t 100 LSC-LOCKIN_1_DEMOD_5_PHASE.
  3. For each optic in turn, we enabled the oscillator in the output matrix. We then turned on a 131.7 Hz oscillator excitation whose amplitude was 15, 3333, 1999, and 1999 counts for PR2, SRM, BS, and BS+PR2, respectively.
  4. We monitored the four demod I channels in StripTool. Then we used z avg -s 8 to average them.

Results for the 1f sensing matrix are as follows. The drive amplitudes have been divided out (and the entire matrix normalized).

1f PR2 SRM BS BS+PR2
9I 2604(2) 0.136(4) −51.60(9) −3.56(2)
9Q 107.5(9) −0.0364(3) −2.254(15) −0.035(2)
45I 2015(4) −3.70(4) −39.69(6) −5.51(5)
45Q −693(7) −0.469(6) 29.58(8) 18.70(5)

The matrix elements for SRM (in red) are probably bogus, because we were saturating the SRM actuator while driving.

Then we repeated this for the 3f signals, with REFLAIR27I→DEMOD 11, REFLAIR27Q→DEMOD 12, REFLAIR135I→DEMOD 13, and REFLAIR135Q→DEMOD 14. The drive amplitudes were 15, 9333, and 1999 counts for PR2, SRM, and BS. The results are as follows. Again the drive amplitudes have been divided out (and the entire matrix normalized).

3f PR2 SRM BS
27I 9400(40) −2.560(11) −173.5(3)
27Q −154(8) 0.618(9) 14.72(5)
135I 2940(50) −7.96(7) −58.3(5)
135Q −22 550(90) −0.17(7) 543(2)

DRMI lost lock before we were able to get the BS+PR2 measurement for 3f.

Comments related to this report
evan.hall@LIGO.ORG - 01:40, Friday 31 October 2014 (14760)

Kiwamu did some work to figure out what output matrix values are needed to drive mostly MICH; it is 1×BS + 0.02×PR2 − 0.014×SRM. Rana then measured the sensing matrix with 333 counts on MICH, 17 counts on PRM, and 18999 counts on SRM (and without saturation). WFS were engaged, and the loops were notched at the drive frequency (131.7 Hz).

Here is the 1f sensing matrix, with the drives appropriately divided out.

1f MICH PR2 SRM
9I 0.921(26)  1329.0(3.4) 0.04300(70)
9Q 0.1122(58) 76.43(46) -0.02287(16)
45I 0.234(76)  1635.6(3.1) -3.3273(58) 
45Q 20.922(62)  -262.6(5.7) -0.4903(13) 

And likewise for 3f.

3f MICH PR2 SRM
27I 4.32(21)  5410.9(5.8)  -1.7543(47)
27Q 8.431(72) -157.0(2.5)  0.4443(43)
135I -8.5(2.1)  1389.4(22.9) -7.289(59) 
135Q 125.6(2.4)  -12638.3(77.9) -0.135(63) 
Non-image files attached to this comment
evan.hall@LIGO.ORG - 19:16, Friday 31 October 2014 (14787)

Also last night, we took similar measurements of the PR2/SR2 portions of the DRMI sensing matrices while we tried bringing in the arms. Sheila started at ≈ 7.5 nm and over a few minutes brought the arms to slightly under 4 nm, at which point we lost lock (the conversion from displacement to detuning is 7 nm / Hzgreen). So the attached plots should be read from left to right.

The big jump at 6.5 nm is because Kiwamu had to tune up the DRMI alignment to prevent lock loss. So the jump in the sening matrix elements isn't surprising. Beyond that, the values appear more or less constant, to within uncertainty.

Non-image files attached to this comment
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 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$ 

Displaying reports 71741-71760 of 86133.Go to page Start 3584 3585 3586 3587 3588 3589 3590 3591 3592 End