Displaying reports 64061-64080 of 83146.Go to page Start 3200 3201 3202 3203 3204 3205 3206 3207 3208 End
Reports until 15:50, Monday 13 July 2015
H1 General
jim.warner@LIGO.ORG - posted 15:50, Monday 13 July 2015 (19597)
Endstation SDF's cleaned up in prep for FE replacment tomorrow

Betsy, Jeff, Ed, Sheila, Kiwamu, JimW, probably others

Because we wanted to reduce the opportunities for chaos tomorrow, we worked on making sure SDF's were clean at the end stations. This involved a lot of asking questions, head-scratching and saying "yeah, it's probably fine".  There are still a number of red tables for the corner station, such as windy blends on the CS BSC's and a bunch of LSC and ASC diffs, but the plan currently only includes restarting end station models.

LHO VE
kyle.ryan@LIGO.ORG - posted 15:05, Monday 13 July 2015 (19593)
Reverting back to "Fixed" voltage for large ion pumps
Rediscovering why we fixed the large ion pump voltages at 7000V in the past -> Changed IP1-6 to 7000V fixed voltage
H1 ISC
eleanor.king@LIGO.ORG - posted 14:06, Monday 13 July 2015 - last comment - 18:10, Monday 13 July 2015(19524)
Shot noise curve with power on the beamsplitter

I have been working on putting together a power dudget for Hanford IFO. I have calulcated the power on the beamsplitter using abolute power on vaious photodiodes, and put this into a shot noise curve model.  I have compared this to shot curve is measured using DCPD null readout.The shot noise curve is taken from the GWinc model.  The parameter file I am using is attached.  These files are available in /ligo/home/eleanor.king/PowerBudget. 

I calculated the power on the beamsplitter using the TR QPDS  (TR_X/Y_QPD_A/B) to determine the power in the arms,  and using the POP sensors(POP_A_QPD, POP_B_QPD POP_A_LF).  The resuts are summarized in the table below.  There is a matlab script with my actual calculations in /ligo/home/eleanor.king/PowerBudget/PowerOnBS.  The recycling gain for the TR is larger than that measured with the POP_PDs.  If calibrate the POP_A PDs to a single shot, same result. I am assuming the TR QPDs are correct.  The resylsing gain calculated by the absolute powers on these PDs agrees with the recycling gain calculated by the relative power change before and after locking using both TR and POP photodiodes.

I have taken an average value of all of the TR QPDs, which is 41(+/-15%).  I have also included lines showing +/- 1 standard deviation in the plot of the shot noise curve.  The photodecetctor quantum effieciency is 85%, and the losses in the arms are 120ppm, measured alog 16579.  Next I plan get a better understanding of the mode matching numbers used for generating the shot noise curve.  (Mode matching into arms and mode matching into SRC, which is currently assume dto be perfect.)

 

Sensor Caculated power on BS [W]

Calculated

Recycling Gain

15_06_07 0:00:00 UTC

LSC-POP_A_LF

751.3 33.6

ASC-POP_A_QPD

723.1 32.4

ASC-POP_B_QPD

662.0 29.6

ASC-X_TR_A

716.8 32.0

ASC-X_TR_B

940.6 42.1

ASC-Y_TR_A

963.9 43.2

ASC-Y_TR_B

1026.2 45.9

-------

Additional Comments:

Propagation of arm power to recycling gain:

Assume losses in arms 0f 120ppm, alog 16579.

Recycling gain from power on the beamsplitter:

Pinput=IMC_input_power*0.88*Tprm.  (It is power on the beamsplitter that I am calculateing from the photodiodes and putting into the GWINC noise model.  But I find it easier to convert from this to recycling gain, and think in terms of recycling gain.

Some comments on the current photodiode calibrations:

POP LSC Photodiodes were calibrated by Kiwamu in alog 13905, based on the transimpedence of this photdiode.  [cnts/W] = 0.76 [A/W] x 200 [Ohm] x 216 / 40 [cnts/V]

TR_QPDs and  POP_QPD calibrated using Dan's calibration alog 15432.  Note the whitening gain changes on these during full lock, so it is important to keep track of the multiple dewhitining filter banks.

Images attached to this report
Non-image files attached to this report
Comments related to this report
eleanor.king@LIGO.ORG - 18:10, Monday 13 July 2015 (19606)

And the promised parameter file...

Non-image files attached to this comment
H1 CDS
james.batch@LIGO.ORG - posted 11:27, Monday 13 July 2015 (19590)
Replaced workstation opsws6 with temporary
The disk drive in control room computer opsws6 has died.  The computer was removed and will be taken in for service, a substitute has been installed in it's place.  The name of the substitute is lveaws2, so don't be surprised when you log in if it has a different name.  The opsws6 computer will be reinstalled when it has been repaired.
H1 General
jim.warner@LIGO.ORG - posted 08:54, Monday 13 July 2015 (19589)
Morning meeting summary
HEPI maintenance tomorrow
New SUS FE's at the endstations, new adc cards and changes to SUS models
CDS more work on GPS antenna, new sus computers have been tested on test-stand, replacement of endstation computer will interfere with Dolphin network
TMDS work going on at end X
Kyle & Gerardo leak checking at Y mid, RGA attempts at EY so far not successful, will try again next maint day
vacuum gauge on Getter pump will be powered off
Jason going into PSL tomorrow, refcav TPD is low, needs realignment, should not affect IFO alignment
PEM install activities, installing cabling, instruments
Robert working on damping PSL periscope
9 MhzRF Source swap tomorrow
H1 AOS
daniel.hoak@LIGO.ORG - posted 22:10, Sunday 12 July 2015 - last comment - 14:09, Monday 13 July 2015(19585)
Oooh those python indents

(Not Dan)

An accidental INDENTING change in the ISC_LOCK guardian affected a "return True" statement. Result:

- CARM_ON_TR returned true without actually ramping H1:LSC-REFL_SERVO_IN2GAIN to -32dB.
- This resulted in random lock losses later on in the lock sequence.
- This resulted in 6h of head scratching of the assembled commissioning team.

There is a long an ongoing discussion about the python indentation convention. No need to state which side the author of this log is on.

Comments related to this report
evan.hall@LIGO.ORG - 00:00, Monday 13 July 2015 (19587)

In the end we were able to bring the interferometer back into full, low-noise lock at 24 W. The DARM spectrum between 10 and 100 Hz is attached, along with the previous best. Of course, our actuator has changed since the vent, so the calibration must be redone. However, I have tried to make the comparison more fair by (1) making sure the DARM OLTF is the same as at the start of ER7, and (2) rescaling the calibrated control and error signals (in the frontend) to restore the heights of the pcal lines (the required rescaling seems to be about 1.2 for both control and error). I also adjusted the EY L3 drivealign calibration gain from -50 to -30, since that is what we now use in lock.

Images attached to this comment
jameson.rollins@LIGO.ORG - 00:47, Monday 13 July 2015 (19588)

Dan, can you paste a diff of the offending indent code?  Or point to a revision in the USERAPPS SVN?  It would be instructive to see the code explicitly.

H1 ISC
sheila.dwyer@LIGO.ORG - posted 15:08, Sunday 12 July 2015 (19581)
Alignment recovery

We've been stably locked with a recycling gain of 38 at 23.3 Watts for almost 2 hours (I intentionally broke the lock).   There were some of the slow (20 second) oscillations that cause some of our locklosses durring ER7.  

When I first came in I had some trouble with locklosses durring ENGAGE_ASC.  One problem was just a typo, the other one seems to be when the gain is increased for the SRC2 loop.  I think this caused the increase in POP90 we were seeing last night, which went away.  This morning it kept increasing until the lockl dropped. I moved the transmon QPD offsets back to the pre-vent offsets, powered up to 18 Watts, turned off the ITM loops and adjusted the ITMY alingments slightly to get a decent recycling gain.    The green alignment in the arm was OK here, and the camera positions not off by more than 4 counts so I did not update the references. 

The offsets where we are stable with recycling gain of 38 and 23.3 Watts are:  

H1:ASC-X_TR_A_PIT_OFFSET       0
H1:ASC-X_TR_B_PIT_OFFSET       -0.11
H1:ASC-Y_TR_A_PIT_OFFSET       -0.128
H1:ASC-Y_TR_B_PIT_OFFSET       -0.516
H1:ASC-X_TR_A_YAW_OFFSET       -0.095
H1:ASC-X_TR_B_YAW_OFFSET       -0.067
H1:ASC-Y_TR_A_YAW_OFFSET       -0.174
H1:ASC-Y_TR_B_YAW_OFFSET       -0.1
 
The pre-vent offsets are:
H1:ASC-X_TR_A_PIT_OFFSET       -0.029
H1:ASC-X_TR_B_PIT_OFFSET       -0.158
H1:ASC-Y_TR_A_PIT_OFFSET       0.101
H1:ASC-Y_TR_B_PIT_OFFSET       -0.056
H1:ASC-X_TR_A_YAW_OFFSET       -0.007
H1:ASC-X_TR_B_YAW_OFFSET       0.105
H1:ASC-Y_TR_A_YAW_OFFSET       -0.127
H1:ASC-Y_TR_B_YAW_OFFSET       0.055
 
The "post-vent, not stable" offsets are:
caput H1:ASC-X_TR_A_PIT_OFFSET       -0.048
H1:ASC-X_TR_B_PIT_OFFSET       -0.148
H1:ASC-Y_TR_A_PIT_OFFSET       -0.118
H1:ASC-Y_TR_B_PIT_OFFSET       -0.369
H1:ASC-X_TR_A_YAW_OFFSET       -0.004
H1:ASC-X_TR_B_YAW_OFFSET       0.078
H1:ASC-Y_TR_A_YAW_OFFSET       -0.242
H1:ASC-Y_TR_B_YAW_OFFSET       -0.318
 
The new camera positions are (I did not update these since they are not verry different from the old ones):
H1:ALS-X_CAM_ITM_PIT_POS H1:ALS-X_CAM_ITM_YAW_POS H1:ALS-Y_CAM_ITM_PIT_POS H1:ALS-Y_CAM_ITM_YAW_POS
254.325
336.287
300.563
434.418 
H1:ALS-X_CAM_ITM_PIT_POS H1:ALS-X_CAM_ITM_YAW_POS H1:ALS-Y_CAM_ITM_PIT_POS H1:ALS-Y_CAM_ITM_YAW_POS
254.325
336.287
300.563
434.418
H1:ASC-X_TR_B_PIT_OFFSET       -0.11
H1:ASC-Y_TR_A_PIT_OFFSET       -0.128
H1:ASC-Y_TR_B_PIT_OFFSET       -0.516
H1:ASC-X_TR_A_PIT_OFFSET       0
H1:ASC-X_TR_B_PIT_OFFSET       -0.11
H1:ASC-Y_TR_A_PIT_OFFSET       -0.128
H1:ASC-Y_TR_B_PIT_OFFSET       -
H1:ASC-X_TR_A_PIT_OFFSET       0
H1:ASC-X_TR_B_PIT_OFFSET       -0.11
H1:ASC-Y_TR_A_PIT_OFFSET       -0.128
H1:ASC-Y_TR_B_PIT_OFFSET       -0.516
H1 ISC (ISC, SUS)
sheila.dwyer@LIGO.ORG - posted 14:26, Sunday 12 July 2015 (19579)
roll mode damping with AS 45 Q yaw

Before ER7 we noticed that we have a better signal for damping the ETMX roll mode in AS 45Q yaw than in pitch. Durring the vent we added a matrix to the ASC model to allow switching.  On Friday Nic found that the old settings for damping ETMX roll (using AS45Q PIT) were not working, so he found some settings that worked using DARM err alog 19561.  

Today I needed to damp ETMX roll again, so I tried using AS45 Yaw, this worked well, with a phase of -90 degrees relative to the settings we had for pitch (so we use bp 13.9, -60degrees, -30 degrees, -100dB and a gain of 60).  I also attempted to damp ITMX and ETMY using AS 45 Yaw (which has better SNR for these as well).    

While these settings seemed to work for each individual optic, when I turned all three on and left them on simultaneously for several minutes, they rang up all the modes.  

  ETMY ETMX ITMY ITMX
Frequency [Hz] 13.816 13.889 13.93 13.978
Filters FM3(-100dB) FM4 (bp13.9) FM2(-60deg)FM3(-100dB)FM4(bp13.9)FM7 (-30deg) FM1(+60deg) FM3(-100dB) FM4(bp13.9)

??

Gain -50 60 -80  

Reminder, the nominal settings for bounce and roll damping (with AS pit) can be found in alog18614.  

Images attached to this report
H1 SUS
sheila.dwyer@LIGO.ORG - posted 10:04, Sunday 12 July 2015 (19577)
some settings that were wrong after the vent

We've tracked down a few settings which became wrong durring our down time.  

BS OpLev yaw limit was set to 0, so we were not using yaw damping while trying to acquired DRMI (it has been working OK).

ITMY violin mode damping for mode6 had the wrong filters engaged.  This rang up the mode, meaning that we had to reduce the whitening gain for the DCPDs.  Now that the right filters are engaged the mode is coming down.  I went through and made sure that the handfull of violin mode damping settings that were not monitored are.  We use guardian to set the gains for these filterbanks, but not to choose the switch status.  

H1 ISC (ISC)
stefan.ballmer@LIGO.ORG - posted 02:42, Sunday 12 July 2015 - last comment - 05:16, Sunday 12 July 2015(19574)
More ASC work at high power
Sheila, Evan, Stefan,
With information for Sheila on Sun morning

We tried to operate the ASC system at full power (24W), using two different sets of QPD offsets (I'll call them pre-vent and post-vent, see burt files below).

With the pre-vent offsets we
 - The ASC system was stable at full input power
 - We had a recycling gain of about 36. (Based on transmitted power.)
 - These QPD offsets are not compatible with the current initial alignment (i.e. the Guardian will drop lock during ENGAGE_ASC - however a slow 2-min offset ramp from post-vent to pre-vent, with 20dB lower gains on the ITM loops worked)

With the post-vent offsets we
 - Get a recycling gain of 40. (Based on transmitted power.)
 - These QPD offsets are compatible with the current initial alignment. The ENGAGE_ASC step works fine.
 - Assuming the higher recycling gain is real (and not due to a difference in QPD clipping), we'd like to keep those QPD offsets because of the higher recycling gain.
 - However we get a 0.41Hz oscillation which starts at about 20W or 21W.


About this 0.41Hz oscillation:
 - It shows up in arm build-up's as 0.41Hz modulation (i.e. 1-f).
 - It is CSOFT PITCH, i.e. all 4 test mass optical levers show it exactly in phase.
 - The arm powers are exactly out-of-phase with the optical level pitch signals, i.e. when all optics point downward (highest OL value), the arm power is at a minimum. (see plot)
 - 

To deal with this mode, we switched the ITM ASC loops for PITCH to the common/differential basis (i.e. DSOFT is now DITM, and CSOFT is now CITM). At the time of this elog we were still designing a filter to stabilize the oscillation.



========================================================================================
Pre-vent QPD offsets (in /ligo/home/evan.hall/Public/Burt/ItmQPDsPre.snap burt file):
H1:ASC-X_TR_A_PIT_OFFSET 1 -2.900000000000000e-02
H1:ASC-X_TR_B_PIT_OFFSET 1 -1.580000000000000e-01
H1:ASC-X_TR_A_YAW_OFFSET 1 -7.000000000000000e-03
H1:ASC-X_TR_B_YAW_OFFSET 1 1.050000000000000e-01
H1:ASC-Y_TR_A_PIT_OFFSET 1 1.010000000000000e-01
H1:ASC-Y_TR_B_PIT_OFFSET 1 -5.600000000000000e-02
H1:ASC-Y_TR_A_YAW_OFFSET 1 -1.270000000000000e-01
H1:ASC-Y_TR_B_YAW_OFFSET 1 5.500000000000000e-02

Post-vent QPD offsets (in /ligo/home/evan.hall/Public/Burt/ItmQPDsPost.snap burt file):
H1:ASC-X_TR_A_PIT_OFFSET 1 -4.800000000000000e-02
H1:ASC-X_TR_B_PIT_OFFSET 1 -1.480000000000000e-01
H1:ASC-X_TR_A_YAW_OFFSET 1 -4.000000000000000e-03
H1:ASC-X_TR_B_YAW_OFFSET 1 7.800000000000000e-02
H1:ASC-Y_TR_A_PIT_OFFSET 1 -1.180000000000000e-01
H1:ASC-Y_TR_B_PIT_OFFSET 1 -3.690000000000000e-01
H1:ASC-Y_TR_A_YAW_OFFSET 1 -2.420000000000000e-01
H1:ASC-Y_TR_B_YAW_OFFSET 1 -3.180000000000000e-01
Images attached to this report
Comments related to this report
evan.hall@LIGO.ORG - 05:16, Sunday 12 July 2015 (19576)

After switching the ITM basis to common/differential, we tried for a while to measure the cITM pitch loop to see if we could put it to work in mitigating this 0.4 Hz resonance.

The attachment shows the loop OLTF at several different powers (yellow: 8W; green: 11 W; blue: 18 W). First, the ugf of the main, 1/f portion of the loop is about 40 mHz. Second, around 0.8 Hz there is a power-dependent resonance which is probably the hard mode. Third, we can see the 0.4 Hz resonance in the cITM loop, although the coherence of the measurement is not great between 0.4 Hz and 0.6 Hz. This makes the behavior of the TF around this resonance hard to interpret. Under the assumption that it's just a pair of complex poles, this means that the total TF will have a 180° lag at the resonance, and hence the loop will go unstable if the gain is increased too much. Hence this current loop shape cannot be used to control the instability.

Therefore, we designed a filter (FM6 in the cSoft filter bank) which flips the sign of the feedback near this resonance. It is a complex pair of RHP zeros at 0.3 Hz, and a complex pair of poles at 0.5 Hz. Together they give 180° of lag at 0.4 Hz. (There is also about 30° of lead and 10 dB of gain near the hard mode.)

We flipped this filter on and off a few times in lock at 18 W, and it seems to correlate well with the apperance and disappearance of the 0.41 Hz oscillation in the ITM error signals, the test mass oplevs, the arm buildups, and the sideband buildups. A quick OLTF shows that the suppression is pretty marginal; probably less than 2 dB. This is with the filter gain increased from -0.3 to -0.8.

Images attached to this comment
H1 GRD
evan.hall@LIGO.ORG - posted 02:23, Sunday 12 July 2015 - last comment - 21:19, Sunday 12 July 2015(19573)
Bat control

Sheila, Evan

Bat control is among the most challenging of control problems. In this case, some patience and a cardboard box were all that was needed to solve the problem.

Images attached to this report
Comments related to this report
jameson.rollins@LIGO.ORG - 02:46, Sunday 12 July 2015 (19575)

BAT_TRAP

jeffrey.kissel@LIGO.ORG - 10:31, Sunday 12 July 2015 (19578)INJ
@Jamie -- Is that a python script / guardian state developed to solve this problem? Could you please point us to the relevant aLOG, ECR, Integration Issue or FRS ticket?? ;-)
jameson.rollins@LIGO.ORG - 16:20, Sunday 12 July 2015 (19582)

The bat ate my ECR.

jeffrey.kissel@LIGO.ORG - 21:19, Sunday 12 July 2015 (19584)
OH! I'll file an FRS ticket.
H1 ISC (ISC)
stefan.ballmer@LIGO.ORG - posted 21:27, Saturday 11 July 2015 - last comment - 20:04, Sunday 12 July 2015(19572)
AS_A_36 phasing
Evan, Stefan

When we came in the winds were relatively high, so we decided to take another loock at the AS_A_36 phasing. We did so in DRMI.

- To take out the effect of WFS centering and the otherASC loops, we lowered the total ASC gain by a factor 10, and increased the WFS centering gain from 1 to 200 (raising the centering gain by a factor of 20).
- We then drove the SRM at 0.3Hz in PIT and YAW.
- Interestingly PIT and YAW totaly disagree on the phase, by about 125deg...
- Attached are screen shots for the old phases (picture 1), phased for PIT (picture 2), and phased for YAW (picture 3)
- Additionally, while all 4 quadrants show a reasonable signal for PIT, the YAW signal is weak in quadrant 1 and not present in quadrant 2
- We decided to make a pragmatic choice:
  - For PIT AS_B_36_I is already a fine signal - only for YAW it doesn't work
  - Thus we decided to phase AS_A_36_I for YAW...
  - ... and only use quadrants 3 and 4 (the lower two quadrants).
  - Quadrants 3 & 4 also have a similar strength signal (with opposite sign) and similar RF offset (with the same sign)
  - So: this new YAW signal AS_A_36_I should be fine now.

YAW Input matrix for I and Q now is:
H1:ASC-AS_A_RF36_I_MTRX_2_1    0
H1:ASC-AS_A_RF36_I_MTRX_2_2    0
H1:ASC-AS_A_RF36_I_MTRX_2_3    -2
H1:ASC-AS_A_RF36_I_MTRX_2_4    2

With this new YAW sensor we updated the ASC sensing matrix (pictures 3 and 4).

This sensor seemed to do a good job at 17W and at 24W. However at 24W we still saw a 0.4Hz instability - see next alog.
Images attached to this report
Comments related to this report
stefan.ballmer@LIGO.ORG - 20:04, Sunday 12 July 2015 (19583)
Some more screen shots
Images attached to this comment
H1 CDS
sheila.dwyer@LIGO.ORG - posted 22:07, Friday 10 July 2015 - last comment - 18:32, Sunday 12 July 2015(19566)
EPICs freezing

We've noticed two more examples of epics channels freezing for a few seconds.  Yesterday (July 9 16:25:09 UTC) and tonight (0:22:49 UTC July 11)

Comments related to this report
david.barker@LIGO.ORG - 08:07, Saturday 11 July 2015 (19567)

I have opened an FRS on this issue (#3279) which contains details of my investigation. I have seen two extended CA freeze-ups of LSC over the past two days (11 and 14 seconds in duration) with an apparent increase in CPU load on h1lsc0 at the time. The DAQ data does not show any drop-out, this only impacts CA access to LSC data. This is an inconvenience for MEDM and StripTool, but has potentially more serious implications for Guardian. Investigation is continuing. With only one large event per day it unfortunately takes some time to gather data. I'm also trying to reproduce the issue on the DTS.

https://services.ligo-la.caltech.edu/FRS/show_bug.cgi?id=3279

evan.hall@LIGO.ORG - 18:32, Sunday 12 July 2015 (19569)

Just to build statistics, we observed these dropouts as well:

  • 2015-07-11 00:21:40 Z
  • 2015-07-13 01:31:20 Z
H1 SEI (CDS)
jim.warner@LIGO.ORG - posted 16:23, Wednesday 08 July 2015 - last comment - 10:10, Friday 17 July 2015(19509)
Quacking matlab filters and foton filter glitching

Earlier today, I wrote a couple out of loop feedforward filters to the BS ISI foton file using Foton. When I hit the load coefficients button (while the ISI was isolated, the ff paths were off, so it shouldn't have done anything), the ISI tripped, hard. It rang up the T240's pretty bad and I couldn't isolate the ISI for several minutes after. Worried I had inadvertantly written some other filter I ran a diff on the most recent archived file and the file created yesterday when Jeff restarted the models. This showed a whole bunch of filter coefficient differences, which shouldn't have been there (as reported by a diff of the two archive files, I don't know exactly what changed, see attached). Talking to Jim, Dave and Jeff, it sounds like the glitch was probably caused by my having used Quack recently (June 22nd) to load some blend filters. Jeff's model restart (and even a prior model restart on June 30) simply inherited that quack-written file. Today was the first time the BS's foton file was opened and saved in Foton. Quack can apparently load coefficients with higher precision than Foton will accept, so when you open and save a "too high" precision filter with Foton, it rounds the coefficients off. Sudden change in precision of SOS coefficients in the blend filters = bad for isolation loops = bad trip.

We've seen this Foton vs. Quack Rounding problem before -- see e.g. https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=3553 -- and it's still biting us.

This sounds like a relatively easy thing to control for, I can think of two ways:

- getting Quack to check and do the rounding on it's own before writing to the Foton file.

- have the post-build script run a "foton -c" on all filter files before the model gets restarted.

Is there someone in the CDS group who can fix this? Maybe it has been? There are several versions of Quack running around, June was my first attempt with it, maybe I used the wrong one.

I used /ligo/svncommon/SeiSVN/seismic/Common/MatlabTools/autoquack.m

 https://svn.ligo.caltech.edu/svn/seismic/Common/MatlabTools/autoquack.m

Last Changed Author: brian.lantz@LIGO.ORG
Last Changed Rev: 7939
Last Changed Date: 2014-02-14 15:38:15 -0800 (Fri, 14 Feb 2014)
Text Last Updated: 2014-02-14 15:48:16 -0800 (Fri, 14 Feb 2014)

Non-image files attached to this report
Comments related to this report
richard.mittleman@LIGO.ORG - 07:02, Thursday 09 July 2015 (19514)

we should use the readfoton script to read and plot the installed filter, i can do that

brian.lantz@LIGO.ORG - 13:57, Monday 13 July 2015 (19591)
I suspect that the problem appears because a change (however small) in the filter coefficients causes the filters to reset (clear history, start over) and reset of the filter history = glitch in the output. It is easy to image this glitch being quite large for a ISI loop which is holding a static offset. 

I am working on an update to autoquack which will have it automatically call foton -c so that the filter updates happen in a deterministic way, and there is a log file telling you which filters have been touched.
 
brian.lantz@LIGO.ORG - 10:10, Friday 17 July 2015 (19704)
filed ECR 
https://services.ligo-wa.caltech.edu/integrationissues/show_bug.cgi?id=1077

testing of possible solution, see 
https://alog.ligo-la.caltech.edu/SEI/index.php?callRep=789
-Brian
H1 ISC
stefan.ballmer@LIGO.ORG - posted 20:24, Monday 06 July 2015 - last comment - 23:43, Sunday 12 July 2015(19461)
DRMI back, MICH freeze working, but no obvious benefit
Evan, Kiwamu, Jenne, Stefan

- DRMI alignment is back to the old-good one: strategy: Used old slider values for everything but large optics. Tweaked SR3 (for instance) to get the beam spot centred on ASPD. Aligned PRX using PRM and PR2.
- DRMI ASC worked except PRC2 loop (didn't further investigate because we didn't care without the arms)
- Then we focused on MICH freeze:
  - We fine-tweaked the transfer function using a zpk([0.03],[0.054],1,"n")gain(0.555556) filter.
  - This made the gain roughly 1 below 0.1Hz. Plot 1 shows that - if measured coherently - we win up to a factor of 10 reduction at 0.01Hz. (Blue: no MICH freeze, red: MICH freeze)
  - In terms of RMS reduction (position) of the power spectrum, we gain a factor of 2, at the cost of significant noise injection at 8Hz. (Plot 2)

Interestingly, this RMS is now small enough that we spend most of the time in about 1/3 for the whole simple Michelson fringe. Unfortunately there is still slow drift, so parking at a "good" position isn't quite possible. But we are definitely in a regime where simple "fringe velocity" isn't a good parameter by itself. Fringe position must matter too. In our brief attempt to see locking performance changes we didn't notice anything significant though.

However, the next time we have high winds, we should definitely re-evaluate MICH freeze.


Images attached to this report
Non-image files attached to this report
Comments related to this report
evan.hall@LIGO.ORG - 23:43, Sunday 12 July 2015 (19586)

As was pointed out during the commissioning meeting, the labels in the attached pdf are reversed.

H1 CAL (AOS, CAL)
sudarshan.karki@LIGO.ORG - posted 10:01, Wednesday 17 June 2015 - last comment - 14:41, Sunday 12 July 2015(19186)
Gravitational Wave Strain h(t) sign convention determination using Pcal

Calibration Team

Sign of h(t):

The gravitational wave strain h(t) is given by  h(t) = Delta L/L where Delta L  is is computed using

                         Delta L = ± (Lx - Ly)

The sign of Delta L can be determined using Pcal actuation on the test mass. Pcal only introduces a push force  so pcal readout signal (truly pcal excitation) is minimum when the testmass is away from the corner station (closer to pcal laser). From the first plot the phase between DARM/PCAL is ~ -180 degrees (DARM lags PCAL) which suggests that DARM signal from ETMX will be maximum when pcal is minimum (ETMX further away from corner station). Similarly, from second plot, since DARM and PCAL have a phase difference of ~-360 degrees (essentially 0 degrees), the  DARM signal from ETMY is minimum when the pcal is minimum. This shows that the sign convention for the Delta L is '+'

Time Delay between Pcal and DARM:

Also the slope of the curve gives the time delay between Pcal and DARM signal chain. The time delay is about 125±20 us. This time delay can be accounted for, within the uncertainity, from the difference in signal readout chain outlined in Figure 3 attached.

Refer to LLO alog #18406 for the detailed explanation behind this  conclusion.

Images attached to this report
Comments related to this report
peter.shawhan@LIGO.ORG - 10:04, Friday 03 July 2015 (19437)CAL
I believe this sign check and the sign check at LLO are correct.  For the record, below is how I reached that conclusion:

The photon calibrator laser can only push, but there is a nonzero baseline intensity and you modulate the intensity around that.  The question is, if you apply a positive voltage to the PCAL system input, do you get more force or less force on the test mass?  Figure 21 of the PCAL final design document seems to show that the undiffracted beam through the AOM is what is sent to the test mass, so increasing the amplitude of the 80 MHz drive to the AOM REDUCES the force on the test mass.  However, the AOM driver electronics could introduce a sign flip when it conditions the input voltage.  To check that, I pulled up PCAL excitation and receiver photodiode data (e.g. H1:CAL-PCALX_EXC_SUM_DQ and H1:CAL-PCALX_RX_PD_OUT_DQ) and plotted a short time interval at GPS 1117933216.  I saw that the PCAL photodiode signal variations are basically in phase with the PCAL input excitation, with just a ~30-40 degree phase lag at ~500 Hz, presumably from filter delay.  So, applying a positive voltage to the PCAL system input causes more force on the test mass, and anyway the PCAL receiver photodiode measures intensity directly.  I confirmed this for all four PCALs (H1 and L1, X and Y) and also confirmed that the transmitter and receiver photodiodes vary together.

The PCAL pushes on the front of the ETM, i.e. on the face that the primary interferometer beam reflects off of.  This being a pendulum, the ETM is closest to the laser (i.e., the arm is shortest) when the force is at its MAXIMUM.  LLO alog 18406 has a comment consistent with that: "Theory of pendulums suggests that Pcal signal will be minimum when ETM swings further away from corner station".  LHO alog 19186, above, has a statement, "pcal readout signal (truly pcal excitation) is minimum when the testmass is away from the corner station (closer to pcal laser)", which is more ambiguous because the ETM being away from the corner station would put it FARTHER from the PCAL laser.  But both draw the correct conclusion from the data: with the intended sign convention, DARM should be at its positive maximum when the X arm is longest (ETMX is farthest from the corner station; PCALX intensity is at its minimum) or when the Y arm is shortest (ETMY is closest to the corner station; PCALY intensity is at its maximum), and that is what was reported at both sites.
darkhan.tuyenbayev@LIGO.ORG - 10:33, Tuesday 07 July 2015 (19466)

Peter,

I disagree with one assumption in your argument, but it does not disprove (or support) the rest of your conclusions.

"The question is, if you apply a positive voltage to the PCAL system input, do you get more force or less force on the test mass? Figure 21 of the PCAL final design document seems to show that the undiffracted beam through the AOM is what is sent to the test mass, so increasing the amplitude of the 80 MHz drive to the AOM REDUCES the force on the test mass. However, the AOM driver electronics could introduce a sign flip when it conditions the input voltage."

As far as I know there's no sign flip in AOM electronics. Undiffracted beam gets dumped in BD2, while diffracted beam is sent to the ETM.

Unfortunately I couldn't find an explicit noting of it in our recent DCC documents.

peter.shawhan@LIGO.ORG - 14:41, Sunday 12 July 2015 (19580)CAL, INJ
Oh, the diffracted beam gets sent to the test mass?  Then I agree, there isn't a sign flip in the electronics.  (In figure 21 in the document, it looks like the undiffracted beam went to the test mass.)

BTW, I've posted a multi-frequency look at the hardware injection actuation sign (and amplitudes and time delays) at https://wiki.ligo.org/Main/HWInjER7CheckSGs.
Displaying reports 64061-64080 of 83146.Go to page Start 3200 3201 3202 3203 3204 3205 3206 3207 3208 End