Displaying reports 55721-55740 of 83041.Go to page Start 2783 2784 2785 2786 2787 2788 2789 2790 2791 End
Reports until 11:59, Thursday 30 June 2016
H1 CAL (SUS)
jeffrey.kissel@LIGO.ORG - posted 11:59, Thursday 30 June 2016 (28086)
ETMY Calibration Line Oscillator Frequencies Swap on Test Mass Stage
J. Kissel, J. Betzwieser

We've recently installed CDS oscillator parts which have their phase synchronized to GPS time 0, in order to progress with the O2 calibration line scheme of PCAL cancelling suspension lines (see LHO aLOG 27733). However, when I turned the lines on the other day (see LHO aLOG 27981), I'd installed the new oscillator / cal line frequency (a copy of LLO's frequency) in the Pitch Oscillator of the optical lever lockins. These lockins still use the former unsynchronized oscillators. As such, I've swapped the calibration line frequencies such that the old frequency (35.9 Hz) is now run by the Pitch Optical lever lockin, H1:SUS-ETMY_LKIN_P_OSC (so that it's just as unsynchronized as it was during O1) and the new frequency (35.3 Hz) is run by the now synchronized cal line oscillator that *used* to run the O1 test mass calibration line, H1:SUS-ETMY_L3_CAL_LINE.

These settings have been captured in the SAFE and down.snaps of the SDF system.
H1 TCS
nutsinee.kijbunchoo@LIGO.ORG - posted 11:30, Thursday 30 June 2016 (28084)
AOM driver power supply has been locked and tagged
Images attached to this report
LHO VE (CDS, VE)
patrick.thomas@LIGO.ORG - posted 10:21, Thursday 30 June 2016 - last comment - 13:42, Thursday 30 June 2016(28083)
h0vacmx Beckhoff vacuum controls updated
WP 5972

The Beckhoff vacuum controls code on h0vacmx has been updated to use the same PI controller as h0vacey (alog 27886).

I have put both CP5 and CP6 on PID control.

The channels in the DAQ and autoBurt request snapshots still need to be updated.
Comments related to this report
patrick.thomas@LIGO.ORG - 13:42, Thursday 30 June 2016 (28091)
CP5 and CP6 settings and response attached. The initial increase in the CP6 pump level happened because I first had the minimum output set at 50, which was too high. I lowered it to 20 and it recovered.
Images attached to this comment
Non-image files attached to this comment
H1 SEI
jim.warner@LIGO.ORG - posted 09:34, Thursday 30 June 2016 (28082)
BSC-ISI models updated to most recent version, new ETM STS science frame channel

A little late, but on Tuesday the BSC-ISI models were updated to the newest version. This was also mentioned in Dave Barkers Tuesday summary. The master parts. several MEDMs, common guardian and chamber specific guardian code was all updated. Seems to work. Changes are described in detail in T1600216.

We also added a science frame channel for the end station BRS/STS super-sensor. This channel is a 256 channel and is called ISI-GND_SENSCOR_ETMX/Y_SUPER_X/Y_OUT_DQ. This channel is the tilt subtracted STS channel for each endstation in the beam line.

H1 ISC
sheila.dwyer@LIGO.ORG - posted 03:49, Thursday 30 June 2016 (28081)
looking for clipping

After we gave up on locking tonight, I spent some time using Keita's method to search for clipping. 

The red cirles on the attached plots show the AS_C sum, normalized to the maximum found durring the scan, as different alingments changed in single bounce.  For the IM4 and PR2 scans, I used DC7 to make a servo from AS_C to ITMX (settings in screenshot), for the SR3 and ITMX scans I used out normal AS_C to SR2 loop, with the output matrix for SRM set to 0.   Blue x's show the slider values we have been using, you can see they are pretty much in the clear apperature and there is no smoking gun here for our recycling gain/ noise problems. 

Images attached to this report
LHO General
thomas.shaffer@LIGO.ORG - posted 00:07, Thursday 30 June 2016 (28072)
Ops Eve Shift Summary

TITLE: 06/30 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Lock Aquisition
INCOMING OPERATOR: None
SHIFT SUMMARY: Never really quite made it to low noise stably, but had about 7 attemps. fw1 went down at around 615, but a call to Dave and we got it goping again, although Monit is reporting "Resource limit matched" for the localhost randomly.

Note: DOWN in ISC_LOCK seemed to have missed something after a few of the locklosses. I noticed that the green was insanely misaligned after a few of the locklosses, so I ran DOWN again and it fixed it every time. Hmm

H1 ISC
stefan.ballmer@LIGO.ORG - posted 22:28, Wednesday 29 June 2016 - last comment - 13:05, Thursday 30 June 2016(28078)
Short lock

Sheila, Carl, Stefen

With the ISS 2nd loop patch (see alog 28076) we successfully reached the "lowish" nosie state again. The spectrum loked the same as in alog 27990.
.

Start: Jun 30 2016 05:01:36 UTC
Loss:Jun 30 2016 05:05:22 UTC

The loss was presumably cause by a 18.04kHz mode ringing up rapidly. Carl will add more details on that.

Comments related to this report
carl.blair@LIGO.ORG - 22:54, Wednesday 29 June 2016 (28079)

The spectrum at lockloss shows a line in OMC DCPDs and Arm transmission QPDs - see first image.
This is not the first time I have seen this line.  On 22nd June I saw it but I thought it was asociated with Terra's mode excitation experiments.  On the 22nd it appeared out of nowhere, with a time constant of 16 seconds.   See second image.
Today the time constant was not as short, about 20 seconds.  See the third image of the ringup and fit.  Today I did not see any associated increase int he ITM drive signals.

Images attached to this comment
sheila.dwyer@LIGO.ORG - 03:51, Thursday 30 June 2016 (28080)

We had 2 more of these short locks, the first we again got to "lowish" noise and lost lock sudenly after a few minutes, the next time we sat at increase power (40 Watts, none of our low noise steps) and lost it after about 10 minutes. 

We reverted a ring heater change from a few days ago. 

During the second short lock we started the calibration measurement, but had to abort when we lost lock.   What we got is saved here:

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER9/H1/Measurements/DARMOLGTFs/2016-06-29_H1_PCAL2DARMTF_4to1200Hz.xml
 

carl.blair@LIGO.ORG - 13:05, Thursday 30 June 2016 (28088)ISC

As a first guess it looks like the unstable mode seen at 18039Hz is a supernyquist ETMY mode.  This is from the frequency shift of this mode over yesterday evening.  In the first figure the change in frequency of a bunch of peaks around 18kHz is compared to the known set of 15200Hz drumhead mode frequency shift.  The frequency shift is -2.5 times the ETMY mode at sample point n=50  (we'd expect -2.6 times) and then they both aproach zero frequency shift towards n=67 (ETMY ring heater was stepped).  This may be contrasted to the 18002Hz mode that appears to be a subnyquist ETMY mode.  Assuming this preliminary analysis is correct this mode is a 47497Hz ETMY mode.  

The new HF DCPD channels allow us to see markedly more of the ringup curve (about one order of magnitude).  See the comparison between the original and HF DCPD channels in the second figure.

Several modes are going through an amplitude transient.  Tracking of some of the largest modes in the 18kHz area are shown in the last 2 figures showing mode amplitude vs time.  Strangely the second peak at 18056 also looks like an supernyquist 47480Hz ETMY mode.    The difference in amplitude transient makes me think it is real.   

The arm mode spacing simulation from TCS indicates this instability occured when the mode spacings were X - 4950Hz, Y - 5015Hz.  The chnage of ETMY ring heater dropped the mode spacing of ETMY by 5-10Hz.  There was not instability in the last lock at this mode spacing (see the last image )however it was short.

Images attached to this comment
H1 CAL (CDS, ISC, SUS)
jeffrey.kissel@LIGO.ORG - posted 21:18, Wednesday 29 June 2016 (28073)
Calibration (No Good, Very Bad) Day (i.e. a Normal Commissioning Day)
J. Kissel, E. Goetz, K. Izumi, S. Ballmer, P. Thomas, T. Shaffer, D. Tuyenbayev, C. Cahillane, P. King

We had a pretty rough day today as far as robust interferometry. Lots of problems resulted in no low-noise locks today (well, none that lasted more than a few minutes. Also "low noise" still only ~40 Mpc). Some problems were related to freshly commissioned things, some due to infrequently seen not-yet-fixed problems, some due to maintenance day recovery, and finally some due to honestly challenging things that are just not yet well-commissioned. The message: we were not able to perform any of the measurements needed for Calibration Day (i.e. measurements of the IFO's optical plant and of the ETMY Isolation Stage Actuation Strengths).

We'll discuss tomorrow if and when to reschedule. 

Details:
----------------

Why do you care? It's only ER9...
Most importantly, it doesn't matter if the run is 3 days or 3 months, we need to measure the interferometer so that we can *quantify* how well or how poor the calibration uncertainty is. Otherwise, when told "It's just ER9 ... you don't have to do better that ___% and ___ [deg]" (where you can pick your favorite large numbers for "___") we do not have any way to claim whether we are meeting that accuracy other than gut feel. Yes, we could go through the laundry list of things that have changed, try to model them, and make some sort of "how has the response function changed" model and infate the uncertainty accordingly, but that takes just as much, if not more, effort than measuring the IFO as is because those changes have not been quantitatively well-tracked over these past few months (which is totally understandable for a commissioning period).

There's been very little change between O1 and ER9, right? What's the big deal?
Here's a list of things that have changed between O1 and ER9 that all affect the most sensitive region of the interferometer at the several percent level:
- ETMY ESD Actuation Strength has changed due to charge accumulation / evolution. This hasn't been quantified in Longitudinal since the PostO1 calibration period, and we've since reduce the charge (as measured in angle) by manipulating the bias voltage sign. We need to confirm its current value. Especially since we've either not had calibration lines on for the past few months or we've not had a sensitive enough interferometer to resolve them.
- We want to identify the PUM / UIM Actuation Strength better. The Calibration Lines during O1 revealed a 2% systematic error on either the PUM or UIM. Because we only ran with a limited number of lines, we don't know to which stage we should associate this error. 
- Given all of the new alignment work over the past few months, and the recent woes on recycling gain, we want to get a new reference for the DARM coupled cavity pole frequency to make sure that 341 Hz is still a good reference.
- Now that we're running at 40 W, and it has recently been shown that signal recycling cavity detuning is affecting us as low as 10-20 W, we need to pay close attention to this, as the detuning might be high enough to start affecting the DARM actuation and sensing crossover at ~45 Hz.
- We've updated all of the coil driver and OMC sensing chain compensation to match the analog electronics "perfectly." All of these upgrade filters have a frequency dependent improvement on the few percent level. We need to make sure that all of those filters are indeed making the measurements and model comparison better.
- The new digital AA and AI (or IOP downsampling) filter has phase significantly different from the O1 filter, even down as low as a few hundred Hz. 

Other things that have changed that will affect high and low frequencies:
- A New OMC DCPD split whitening chassis has been installed to support PI tracking. Though the Gravitational Wave DCPD path is *nominally* the same, i.e. it has the same circuit design, its components are real and different, so they need to be remeasured. These will likely be differences in the high-frequency poles, so there affect will be likely be small and above ~1 kHz.
- Evan and Rana have changed the local QUAD damping loops. So we need to create a new SUS dynamical model and update everywhere its needed. This should primarily affect frequencies and dynamics below 10 Hz.

Why can't you get what you need next Tuesday, the day before the run?
*If* we get all the measurements we need, we need time to analyze and process those measurements, update all of the appropriate calibration filters (both in the front-end and in the GDS pipeline), make sure the calibrated pipeline agrees with our measurements and is producing sane results, run for a day or two's worth of lock stretches and confirm that it all works . Again, if we want to be quantitatively sure of our calibration, one really has to take all of the appropriate steps to well-calibrated data, regardless of the length of the run. Further, we've made drastic software changes to the GDS calibration pipeline, in order to make incremental progress toward O2. These need to be tested, and they'll likely only be ready by the end of the week.

Today's Lock Loss Break Down; Why we had so much trouble
There're 5 major lock stretches shown in the attached inspiral range time series. The lock losses and in between problems are described below:
Lock 1: Patrick and I'd gotten all the way to a 40 W (nice work commissioning team!), and was in the middle of switching coil drivers to their low-noise configuration (ISC_LOCK state "COIL DRIVERS") but got hit by some Izumi-Ballmer dP/dtheta instabilities. I found out later that this was because the ASC SOFT degrees of freedom had had their offsets commissioned last night, but they were left out of the Guardian because they weren't yet confident in their robustness. Apparently, with out them, the IFO is aligned to a place with reasonably large dP/dtheta, so I lost lock.

Between locks 1 and 2:
- We were having the same problems with the PSL FSS vs.ISS that Shiela found last night. We spent some time with Peter King trying to diagnose and debug.
- The OMC SUS had tripped (which is apparently a reasonably common occurance after lock-loss because of the suddenly bogus OMC input alignment signals)
- We'd lost lock in the middle SRM's bottom-stage matrix dance that facilitates coil driver state switching. However, the DOWN states did not restore these matrix values. Stefan spent some time fixing this. See LHO aLOG 28053.

Mini-lock 2: Intentionally broke the lock because PSL FSS / ISS / Noiseeater was oscillating, and because we were past DARM ASC signals being turned on we were blasting the PUM stage of test masses with junk, and we were worried about violin mode ring-ups and PUM stage coil driver RMS watchdog trips.

Big Lock 2: Lost lock after 40W power up because of ISS 2nd Loop Offset transient.

Between locks 2 and 3: 
- Continuing to have problems with PSL servos, Kiwmau and Peter found that settings had not been restored properly after maintenance day. These issues were completely resolved after we reverted some PMC locking servo gains using the correct SAFE.snap SDF file. See LHO aLOG 28058.

Lock 3: Unknown lock loss. These things happen! ¯\_(ツ)_/¯

Between locks 3 and 4
- OMC LSC Input Matrix ramping failed to scale the DARM gain correctly. Solution found in LHO aLOG 28074.
- Violin Modes on ITMY and ETMX rung up for unknown reasons, some PUM stage RMS watchdog trips, took a while to damp back down with some manual gain reduction and gradual re-increase.
- Needed to come up with no stages of OMC whitening to prevent saturations

Lock 4: Lost lock after 40W power up due to ISS 2nd Loop Offset transient.

Between locks 4 and 5
- TJ takes over, runs initial alignment.

Lock 5: Lost lock after 40W power up due to ISS 2nd Loop Offset transient.

As of this entry we're on Lock #6. And if we lose lock due to 2nd ISS offset problems again, Stefan's going to spend some time commissioning it. 

Note, that the 2nd loop closure problems (recall that the 3rd loop is ON during power up, and then once complete, we have to transition back to turning on the 2nd loop) have been newly difficult because there is just more intensity noise coming out of the IMC than there was during O1. Both the DC alignment into the mode cleaner has changed for the worse, increasing the natural jitter-to-intensity conversion of the IMC, and also the HPO just produces more intensity/jitter noise now that it's in use. Check out LHO aLOG 28076 for Stefan's report on today's attempts to improve it.
Images attached to this report
H1 ISC
stefan.ballmer@LIGO.ORG - posted 20:56, Wednesday 29 June 2016 - last comment - 16:07, Thursday 30 June 2016(28076)
Engaging the ISS 2nd loop a 40W

Jeff, Kiwamu, Stefan

We had trouble engaging the ISS 2nd loop at 40W. The core issue is that the digitized signal (H1:PSL-ISS_SECONDLOOP_SIGNAL_OUTPUT) swings rail to rail without the loop, making it difficult to properly pre-set the offset adjuster (H1:PSL-ISS_SECONDLOOP_REF_SIGNAL_ANA).
As a result, when engaged, the ISS 1st loop tended to swing into saturation.

I patched the Guardian as follows:
- Instead of trying to rely on a calculation for the offset adjuster (H1:PSL-ISS_SECONDLOOP_REF_SIGNAL_ANA), I hard-coded it to 0.987 V, which is where it likes to sit at 40W. (THis is obviously not a long-term solution.)
- As soon as the servo comes on, I ramp H1:PSL-ISS_SECONDLOOP_REF_SIGNAL_SERVO_GAIN to zero, clear the history, and re-engage it on the diffreation power.

 

This seemed to engage the 2nd loop without excessive transient - back to full locking.

PS: I might have already mentioned this: but the ISS SHOULD BE AC COUPLED!

 

Code:

In PREPARE_ISS:

        # read current servo signal value. If it is too far from the operating point, correct the offset.
        #second_loop_out = cdu.avg(1, 'PSL-ISS_SECONDLOOP_SIGNAL_OUT16')
        #if abs(second_loop_out) > 1.0:
        #    # measure current input PD value
        #    # Sets the ref. signal value to bring it to close to the operating point
        #    pd_avg = cdu.avg(1, 'PSL-ISS_SECONDLOOP_PD_14_SUM_INMON')
        #    ezca['PSL-ISS_SECONDLOOP_REF_SIGNAL_ANA'] = round(0.5*((pd_avg*2.29*.0006103515625)+0.101), 6)
        #    time.sleep(5)

        # above section commented out - instead command the value that worked  (Stefan Ballmer 20160629 for 40W)
        ezca['PSL-ISS_SECONDLOOP_REF_SIGNAL_ANA']=-0.9826934814453125
 

In CLOSE_ISS, once the loop is closed:

            # the loop is successfully locked, ramp off the loop (Stefan Ballmer 20160629 for 40W)
            ezca['PSL-ISS_SECONDLOOP_REF_SIGNAL_SERVO_GAIN'] = 0

and a little later:

            # clear and ramp on the loop (Stefan Ballmer 20160629 for 40W)
            ezca['PSL-ISS_SECONDLOOP_REF_SIGNAL_SERVO_RSET'] = 2
            time.sleep(0.1)
            ezca['PSL-ISS_SECONDLOOP_REF_SIGNAL_SERVO_GAIN'] = 1
 


 

Comments related to this report
keita.kawabe@LIGO.ORG - 16:07, Thursday 30 June 2016 (28099)

When people were engaging the offset adjuster servo with 40W into IMC, eventually H1:PSL-ISS_SECONDLOOP_REF_SIGNAL_MON_OUTPUT settled down to -0.98V and H1:PSL-ISS_SECONDLOOP_SUM14_DC_OUT16 to 39.6.

This PSL-ISS_SECONDLOOP_SUM14_DC_OUTPUT thing is a digital sum of four digital outputs, each with dewhite, so it's well behaved even with high power, unlike PSL-ISS_SECONDLOOP_PD_14_SUM which is just a readback of the second board input without dewhite.

pd_avg = cdu.avg(2, 'PSL-ISS_SECONDLOOP_SUM14_DC_OUT16')
ezca['PSL-ISS_SECONDLOOP_REF_SIGNAL_ANA'] = round(-pd_avg*0.98/39.6, 6)

instead of

ezca['PSL-ISS_SECONDLOOP_REF_SIGNAL_ANA']=-0.9826934814453125

 

But you might have to fine tune the above to account for some offset in the board. I haven't changed the guardian.

Images attached to this comment
H1 SUS
rainer.weiss@LIGO.ORG - posted 20:44, Wednesday 29 June 2016 (28075)
Thermal Noise from Composite SRM
After talking with Rana and Evan during the NSF review, I made some independent estimates of the thermal noise that
could come from the composite SRM which had a measured resonance frequency of 3.34KHz with a Q of 150. I get the same
thermal noise displacement spectra of the mirror surface as Evan in log 27488,27490,and 27490. Tend to favor the viscous case
as Peek is a thermoplastic as is Nylon which was measured to have a viscous spectrum. The model is a shear motion of Peek 8-32 screws 
clamping the 2 inch diameter 1 inch thick mirror into the metal carrier. The motion is a displacement of the mirror allowed by shearing
the 8-32 bolts in and out of the plane of the carrier - longitudinal modulation of the light beam. Thermo elastic damping is much too small
to explain the low Q. The time constant for thermal diffusion in the Peek screws is about 10 seconds. The thermo elastic delta is about 10^-2,
so that loss tangent phi varies as 1/f with a value of 5x 10^-8 at 3.4kHz and about 2 x 10-6 at 100Hz. My guess unfortunately is the
SRM is not responsible for the excess low frequency noise we are seeing. I think Evan and Rana had come to the same conclusion. 
H1 ISC
thomas.shaffer@LIGO.ORG - posted 20:34, Wednesday 29 June 2016 (28074)
LSC OMC DARM Gain matrix loading

The OMC would not lock as we entered DC_READOUT_TRANSITION, and the DARM spectrum had risen around 100Hz. Sheila tracked it down to H1:LSC-ARM_INPUT_MTRX_RAMPING_1_3 having a gain of 20 and not 8. She investigated further and realized that the matrix was not being loaded beore the actual value was in place, something that a sleep of 0.1s can cure. With her help. I added in these short sleeps or just loaded later.

H1 PSL (ISC, Lockloss)
jeffrey.kissel@LIGO.ORG - posted 19:08, Wednesday 29 June 2016 (28070)
Added AOM Diffracted Power and Decreased Step Size Increments on PSL ISS 2ND Loop Screen
J. Kissel

Several lock losses were caused by DC coupled ISS loops today, so in my desperation to make things better, I modified the PSL ISS 2ND Loop MEDM screen to include all the relevant PSL AOM Diffracted Power information on the same screen (formerly only available on the 1st loop ISS screen). Also, to facilitate the turn on dance, I've decreased the default increment on the slider used to tune the analog reference signal (H1:PSL-ISS_SECONDLOOP_REF_SIGNAL_ANA) and increased the precision which the reference signal value is displayed.

The updated screen has been committed to the user apps repo here:
/opt/rtcds/userapps/release/psl/common/medm/ISS/PSL_CUST_SECONDLOOP.adl
Images attached to this report
H1 ISC (ISC)
sheila.dwyer@LIGO.ORG - posted 18:19, Wednesday 29 June 2016 (28068)
New filters for CHARD Yaw low bandwidth

Sheila, Haocun

We designed some new filters for the low bandwith CHARD Yaw at 40W.

We plan to lower the gain for about 6dB, which will give us a UGF at 3.5Hz and use the new filters 6 ('40W') and 7 ('ctrlHBW') to stablize the loop (blue curve in the 2nd Figure). The new cutoff filter for 40W is filter 9 ('cutoff40W') (Figure 1). The pink curve in the second curve is what we expect from the simulation.

Images attached to this report
H1 ISC
cheryl.vorvick@LIGO.ORG - posted 15:32, Wednesday 29 June 2016 - last comment - 10:13, Friday 01 July 2016(28064)
8 minutes of power up - alignment changes

biggest = prm pitch changing by 2.5urad

close second = im4 pitch changing by 1,15urad

plot and chart of top 16 optics/DOFs attached

Images attached to this report
Comments related to this report
cheryl.vorvick@LIGO.ORG - 13:03, Thursday 30 June 2016 (28089)

plot of optics/DOFs in the chart - meant to attach yesterday.  I

used OpLev signals when available and OSEMs when not.

Images attached to this comment
cheryl.vorvick@LIGO.ORG - 10:13, Friday 01 July 2016 (28116)

UPDATE to my alog's less than descriptive title:  I think the original title suggests these changes were during a 40W lock, but this is not the case.  

The optic alignment changes are actually happening over 8 minutes of full lock while the input power increased from 22W, the O1 power level, to 40W.

H1 ISC
stefan.ballmer@LIGO.ORG - posted 14:14, Wednesday 29 June 2016 - last comment - 11:47, Friday 01 July 2016(28061)
YAW motion during and after power-up to 40W

Kiwamu, Stefan

We were trying to nail down what is responsible for the Power Recycling Gain change during power-up, so we went through the whole sequence slowly, and gave the system time to settle in each state:

All times UTC of 20160629:

- 18:54:37 / Green dot: Power-up starts from 2Watt to 10Watt
- 19:00:32 / Red dot: Power-up restarts from 10Watt to 40Watt
- 19:06:10 / Black dot: : Power-up to 40W finishes, but additional SOFT offsets remain left off.
- 19:10:15 / Blue dot: Soft offsets in yaw start ramping on over 2 minutes
- 19:12:17: Soft offsets ramp in yaw is done
- 19:15:17: Soft offsets in pit start ramping on over 3 minutes
- 19:18:19: Soft offsets ramp in yaw is done
- 19:21:20: End of undisturbed period - guardian continued
 

In particular, we now there is a significan power recycling gain improvement with a soft yaw adjustment of the x-arm. Additionally, the beam splitter cannot affect the relative alignment of x-arm and power recycling cavity. SO attached are only yaw signals from x-arm and power recycling cavity.

 

Conclusions:

- During the very first step in power up (green dot) there is a momentary shift in PRM yaw and IM4 yaw, but it does not continue during the additional power increase.
- During the main power increase (between red dot and black dot). There is a consiostent signature in the ETMX control, oplev and IR camera signal, sggesting that we are slightly moving the x-arm with the ASC system. THe ITMX doesn't see much of this in control signal and oplev signal (its camera is broken and not plotted). However no significant motion is visible in any of the power recycling cavity mirrors (this includes PR2, which is not plotted).
- Once we start moving the soft loops with soft offsets, ETMX, ITMX, PR3 and BS clearly respond. Interestingly, the ETMX moves to the same direction as during the power increase.

Images attached to this report
Comments related to this report
stefan.ballmer@LIGO.ORG - 22:07, Wednesday 29 June 2016 (28077)

Attached are 220days of recycling cavity alignment data (Nov 15 2014 to now)

Images attached to this comment
cheryl.vorvick@LIGO.ORG - 11:47, Friday 01 July 2016 (28117)IOO

The alignment offsets for IM1-3 are not a valid way to track the optic alignment, since IM1, IM2, and IM3 all have significant alignment shifts after a HAM2 ISI trip.

  • IM2 shifts the most in pitch and it's shift is typically 40urad.
  • IM3 typically shifts in pitch and it's shift is typically smaller than IM2's, around 20urad.
  • IM1 typically shifts in yaw, and it's shift is typically smaller than IM3's, around 10urad.

I wrote a procedure to correct these after restoring the ISI and the optics but adjusting the alignment offsets to drive the optics back to their nominal alignments.

 

During O1 the procedure was to drive the optic back to it's most recent good value, however this can be hard to decipher, so in May I posted a Nominal Alignment for the IMs and have maintained it since.

 

I've been maintaining an alignment of the IMs based on our last good high power lock in April 2016, and this alignment choice is explained in alog 26916, and recently updated in alog 28016.

 

On a longer time scale, the alignment of the IMs is harder to track since I only started restoring their alignments after an ISI trip around September 2015, so before that time when IM2 pitch shifted 40urad we spent time realigning H1 to follow that change.  

 

In my investigation, I see that the IM alignment shifts have caused down time in H1, and IM1-3 now have an alert in guardian to prevent the IM alignment shifts from causing down time in O2.

 

Here are some pertinent alogs from my investigation:

  • alog 24696: alignment changes in yaw, for IM1, IM2, IM3, PRM and PR2, over 150 days (all of O1 plus a few days)
  • alog 25075: IO IM2 alignment changes after a HAM2 ISI trip - January 20th power outage
  • alog 25688: Alignment shifts of IO IMs (IM1-3) in H1 also occurring in L1:
  • alog 26685: IM1, IM2, and IM3 now have a notification in DIAG_MAIN when alignment has shifted
H1 ISC (CDS, PSL)
sheila.dwyer@LIGO.ORG - posted 00:41, Wednesday 29 June 2016 - last comment - 19:41, Wednesday 29 June 2016(28045)
trying to improve recycling gain

Marie, Sheila, Kiwamu, Lisa, Stefan

We tried a few things to improve the recycling gain tonight. We  believe that the problem is with something in our PRC.  We can see that the green power transmitted through the X arm stays stable as we power up, we think this means the optics are stable.  When we move the soft offsets to improve the recycling gain we change the X arm alignment to follow something in the vertex.

As TJ noted, since the computer problems earlier we are having trouble relocking the PSL after locklosses, with noise eater, PMC and FSS and ISS problems.  It seems like trying to lock the FSS causes the noise eater to oscillate again after it has been reset. 

Comments related to this report
kiwamu.izumi@LIGO.ORG - 12:12, Wednesday 29 June 2016 (28058)

Jeff K, Stefan, Peter, Kiwamu

We kept having the same issues with the PSL in this morning as reported by Sheila in the above entry. We now think that it is all fixed. Here are what we have done for fixing the issues.

  • At the begining, no issues were found and in fact Jeff was able to lock at 40 W. Then the lock was broken due to the angular instability and we started having the issues.
  • First of all, we noticed the noise eator oscillating. Peter went to the floor and fixed it.
  • Having trouble engaging the FSS, we noticed that the FSS common gain was too high by 6 dB. We set the common gain back to 14.
    • The Observe snapshot said it should be 20.4 dB, but the safe snapshot said it should be 14. We set the observe to 14 dB.
    • The gain seemed to have been set to 20.4 dB after the maintenance yesterday.
  • Then having trouble engaging the ISS, we noticed that the PMC gain was too high by 6 dB too. We set this back to 16 dB.
    • This also seemed to have been set to 22 dB after the maintenance yesterday.
    • After this reset, the ISS seems to work well.
jeffrey.kissel@LIGO.ORG - 19:41, Wednesday 29 June 2016 (28071)
Not that all of the settings that Kiwamu describes were not found by the SDF system because I'd mistakenly set the SDF system to look at the OBSERVE.snap record instead of the SAFE.snap record after maintenance yesterday. The OBSERVE.snap was out of date, having not been updated since O1 and/or the HPO turn-on. Both the safe and OBSERVE.snaps have not been updated. 

Another case of the difficulty of maintaining several .snap files per front-end model...
H1 ISC
daniel.sigg@LIGO.ORG - posted 12:36, Tuesday 28 June 2016 - last comment - 11:45, Thursday 30 June 2016(28010)
Hardware Modifications for OMC PI Mode Monitoring

(Richard M, Fil C, Ed M, Daniel S)

ECR E1600192.

Split Whitening Chassis S/N S1101627:

AA Chassis S/N S1102788 & S1202201:

The attached plots show the transfer functions of

  1. whitening chassis: OMC DCPD_A: same as before
  2. whitening chassis: OMC PI DCPD_A: modified
  3. whitening chassis: OMC DCPD_B: same as before
  4. whitening chassis: OMC PI DCPD_B: modified
  5. AA chassis: channel 15
  6. AA chassis: channel 16
Non-image files attached to this report
Comments related to this report
filiberto.clara@LIGO.ORG - 14:59, Tuesday 28 June 2016 (28019)

Whitening chassis S1101603 was removed from ICS-R5 U18. New chassis S1101627 was reinstalled with modifications listed above. New unit is the split variant.

carl.blair@LIGO.ORG - 17:59, Tuesday 28 June 2016 (28030)

[Kiwamu, Carl]

First indications are that the DCPD HF channels are behaving as expected.  With the OMC locked on an RF sideband the DCPD A is compared to the new DCPD HF A.  The transfer function between them at low frequency has a 'f' relation which transistion fto f^3 at 10kHz as expected from the AC coupling change and the removal of 2 poles at 10kHz.  Coherence is lost at about 20kHz.  

Images attached to this comment
carl.blair@LIGO.ORG - 01:25, Wednesday 29 June 2016 (28046)

I have changed the whitening gain of the AHF DCPD path (A and B) to 15dB.  This pushed the noise floor in the 15-29kHz region to a factor ~2 above what I guess is ADC noise.  In the attached plots the original DCPD can be seen to reach a common noise floor with the AHF DCPD path with no whitening gain at about 17kHz.  Turning the whitening gain up we can get some coherence with the shot noise of the DCPD through original electronics. 
A forest of new peaks is visible, mainly in the 17-29kHz region.  There are 80 peaks in teh 25-26kHz band.  I stepped the ETMX ring heater at 7:01 up by 0.5W and down again at teh end of lock at 7:22.  This may give some mode identificatiion data.

Images attached to this comment
richard.mccarthy@LIGO.ORG - 11:45, Thursday 30 June 2016 (28085)
This morning we removed the Twin T notch on the AA board by removing C3, C4, C5, C10, C11 leaving in the 100 Ohm resistors in place.
Non-image files attached to this comment
H1 ISC
stefan.ballmer@LIGO.ORG - posted 20:04, Saturday 25 June 2016 - last comment - 18:10, Wednesday 29 June 2016(27968)
40W operations

Jenne, Lisa, Stefan,

Still running at 40W, for 2h.

Tried to damp some PIs and go to low-noise.

- We successfully damped 15009Hz (ETMY) and 15542Hz (ETMY) (damp settings picture attached.)

- 15541Hz (ETMX) was ringing up.So we tried switching to ETMY and transition the ETMX coil driver to low noise.

- We successfully switch the coil drivers, but...

- We switched to ETMY, low noise, held lock for a while, but saturated the ETMY ESD with 20Hz noise from the ASC, as well as a 532.77Hz line, that we don't know the origin off. (PI?) (picture)

 

 

===================================

Also, we realized that DTT is a bit too smart: The 64kHz channel H1:OMC-PI_DCPD_64KHZ_A_DQ can in principle look at PIs above the Nyquest through aliasing. However, since DTT only alows you to select a freqency about 10% below the Nyquist frequency, there is an effecive dead band where DTT cannot see PIs between ~29500Hz and ~36036Hz. The MATLAB script below produces a spectrum up to the Nyquist. Indeed, we found an elevated mode at 30018.3Hz, although it was not quite saturating.

MATLAB code to get spectrum up to Nyquist frequency:

addpath /ligo/svncommon/NbSVN/aligonoisebudget/trunk/Externals/SimulinkNb/Utils/
gwd = GWData();
gwd.make_kerberos_ready;
gwd.site_info(2).port = 31200;
gwd.site_info(2).server = 'nds.ligo-wa.caltech.edu';
H1.channels = {'H1:OMC-PI_DCPD_64KHZ_A_DQ'};
time_fetch = tconvert('26 Jun 2016 01:15:00');
[data, t, ~] = gwd.fetch(time_fetch, 1000, H1.channels);
Fs=4*16384;
pwelch(data,[],[],[],Fs)
 

Images attached to this report
Comments related to this report
jenne.driggers@LIGO.ORG - 20:09, Saturday 25 June 2016 (27969)

[Lisa]

Attached is Jenne's PI knowledge, she also updated the PI wiki page.

This last 40W lock ended at June 26, 2.11 UTC while trying transitioning to low noise to damp the 15541 Hz ETMX PI.

 

Images attached to this comment
carl.blair@LIGO.ORG - 18:10, Wednesday 29 June 2016 (28069)

The 532.7Hz matches the beat frequency between the 15541.9Hz ETMY and 15009.2Hz ETMY modes that were at very elevated amplitudes during this lock.  15541.9Hz appears to have been unstable ringing up with a time constant of 190 seconds, damping was engaged with a gain of 1000, so it may have been PI or being driven up, while the 15009Hz damped over the duration of the lock with someone actively changing the control gain.  See the figures of 15540Hz and 15kHz mode group amplitudes over the last half hour.

There were two peaks ringing up in the unmonitorred region between 29000Hz and 32768Hz, one appearing in the OMC DCPD signals at 30551.09 and another at 31083.90.  See third figure.  The beat note between these two peaks is also around 532.7Hz.  The connection can be seen in the fourth figure when the beginning of lock spectrum (green) is compared to the end of lock spectrum (blue).  The largest green peak is the sensing harmonic of the 15009Hz mode.  The largest blue peak is the first sensing harmonic of the 15541Hz mode.  These mixing with the 532.7 produce the center frequency and the 31620Hz peak.  There appears to be something else producing messy ~480Hz 'sidebands' on some of these peaks.


 

Images attached to this comment
Displaying reports 55721-55740 of 83041.Go to page Start 2783 2784 2785 2786 2787 2788 2789 2790 2791 End