Displaying reports 62861-62880 of 83104.Go to page Start 3140 3141 3142 3143 3144 3145 3146 3147 3148 End
Reports until 16:51, Saturday 22 August 2015
H1 CAL
kiwamu.izumi@LIGO.ORG - posted 16:51, Saturday 22 August 2015 - last comment - 10:03, Wednesday 26 August 2015(20788)
Calibration prep: ETMY dtt templates tuned

Since LLO had been down in this afternoon, I took this oportunity to renew the dtt templates that are for measuring the transfer function of each stage of ETMY. I tuned the envelop parameters while the interferometer was locked at 23 W in the NOMINAL_LOW_NOISE state. The attached are the resultant templates. The frequency range is newly adjusted to [10 200] Hz with 21 frequency data points as planned. Each one takes several minutes to complete the measurement. According to the results I got, we can get a quite good coherence for all the relevant stages (i.e. L1, L2 and L3 stages) at all the frequency points with a coherence of more than 0.99. On the other hand, the template for measuring the DARM closed loop in this particular frequency band may need a bit more tuning because the coherence was not as great as the ones for the ETMY transfer functions.

Non-image files attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 10:03, Wednesday 26 August 2015 (20918)
These measurements have been committed to the CalSVN repo, under 
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/FullIFOActuatorTFs/2015-08-22/
2015-08-22_H1SUSETMY_L1toDARM_FullLock.xml
2015-08-22_H1SUSETMY_L2toDARM_FullLock.xml
2015-08-22_H1SUSETMY_L3toDARM_LVLN_LPON_FullLock.xml
H1 ISC
evan.hall@LIGO.ORG - posted 16:20, Saturday 22 August 2015 (20783)
45 MHz oscillator frequency noise coupling into DARM, noch einmal

Daniel, Dan, Evan

Summary

We took another measurement of 45 MHz oscillator frequency noise into DARM.

The conclusions are as follows: (1) like the previous measurement, the transfer function is flat in terms of frequency noise coupling into DCPD current, but (2) the coupling is about 7×107 mA/Hz, which is 5 to 6 times lower than the previous measurement. Assuming a flat 45 MHz phase noise of 4×10−7 rad/Hz1/2, we expect a contribution in the DCPD sum that is 3×10−10 Hz/Hz1/2 and rising like f, which is not enough to explain the excess we see (and isn't the right shape).

In the previous measurement, we had some trouble with the calibration (namely, the voltage-to-frequency coefficient on the IFR front panel didn't match what we measured with a mixer), and also we were shaking the 9 MHz and 45 MHz sideband phases simultaneously. So I am more inclined to believe this measurement.

Details

  1. First we wanted to measure the relative delay of the 9 MHz and 45 MHz sidebands using the nominal (OCXO/HG) configuration, so that we could preserve this phase when switching to the IFR. On a scope we saw that the crest of the 45 MHz lagged behind the 9 MHz crest by 12.8(4) ns. [Of course, this is cable-length dependent and has no absolute meaning.]
  2. Then we set up a PLL as shown in the attached diagram. We lock an IFR to the 45 MHz output of the HG and use this output to generate the 45 MHz signals for the interferometer. This PLL has a ugf of 46 kHz or so. By 7 kHz it has 20+ dB of loop suppression, so for the rest of this analysis we don't correct for the loop gain.
  3. We calibrated the PLL drive by tuning the error point offset knob on the LB1005 and watching the relative delay between the 45 MHz drives of the IFR and the HG. From this, we measured that the calibration at the error point is 45 mV/ns, which is 0.16 V/rad.
  4. Then using the same cable lengths as in the first step, we looked at the of the 9 MHz (from the OCXO) and the 45 MHz (from the IFR) on a scope and tuned the error point offset to give an identical delay as before.
  5. Then we hooked up the spare LSC DAC channel to the unused ("B") error-point input of the LB1005. The SFM for this channel is calibrated so that the excitation is in volts. We verified this in the CER with a scope. [The calibration uses FM1, which is a flat gain of 3276.8 ct/ct, along with a factor of 2 in the SFM gain. We're not sure why we need this factor of 2 to get the right calibration, since we think the calibration should be 216 ct / 20 V = 3276.8 ct/V.]
  6. Then we relocked the interferometer and measured the transfer function from the LSC DAC channel into the DCPD sum.

The attachments show the calibrated transfer function (both in terms of phase noise and frequency noise).

Images attached to this report
Non-image files attached to this report
H1 General (GRD)
cheryl.vorvick@LIGO.ORG - posted 16:18, Saturday 22 August 2015 - last comment - 19:10, Saturday 22 August 2015(20787)
Day Summary:

Locked about 5 hours into day shift - a continuation from owl shift.

LLO down and commissioners arrive, so went to commissioning mode.

Excitation broke the lock.

IFO relocked with only a tweak to the BS alignment for DRMI.

Commissioning continues, but this lock does not have an extra stage of whitening on the OMC - see note below.

 

--- 

OMC_Lock has a new stage ADD_WHITENING

This is added after the IFO reaches Nominal_Low_Noise, BUT

H1:OMC-DCPD_A_IN1 and H1:OMC-DCPD_B_IN1 need to be less than 3000 counts peak to peak, or adding the extra whitening will saturate... and bad will happen like lock loss or increased noise

Comments related to this report
evan.hall@LIGO.ORG - 19:10, Saturday 22 August 2015 (20792)

There was a DMT glitch around 2015-08-22 21:00:00 Z. Our previous range channel disappeared, and the seismic FOMs dropped out for 10 minutes or so.

As Cheryl says, in order to turn on an extra stage of whitening, OMC-DCPD_A_IN1 and OMC-DCPD_B_IN1 must each have an ac peak-to-peak less than 3000 ct. Otherwise, turning on more whitening will saturate the ADCs. If the peak-to-peak is more than 3000 ct, probably it is due to some violin mode(s), which must first be damped.

Probably it is a good idea to wait until nominal low noise to activate extra whitening.

H1 General (GRD)
cheryl.vorvick@LIGO.ORG - posted 13:29, Saturday 22 August 2015 (20786)
Commissioning Mode 20:26UTC, 13:26PT

Commissioners arrived and LLO is down, so took IFO out of Observing/Undisturbed Mode for commissioning work.

IFO has been in lock 10+ hours.

H1 General
dale.ingram@LIGO.ORG - posted 13:15, Saturday 22 August 2015 (20785)
8/22/15 Midday
H1 has been locked for 10 hours as of 20:00 UTC with a steady range of a bit more than 60.  The detector has experienced one or two momentary disruptions per hour over the last seven hours.  Since 17:00 when I arrived, the voice inside has indicated ETMY when these have occurred.  Cheryl had initiated an oplev strip tool earlier this morning; the H1:SUS-ETMY_L3_OPLEV_SUM_OUTPUT trace has moved higher throughout the last couple of hours.  SDF:  OMC Table (5) and Calcs Table (29) are red.  Vacuum:  Several LX and LY ion pump status readouts are linking red. And CP-1 is reading 23.  Dust:  EX dust is alarming white.

LHO General
corey.gray@LIGO.ORG - posted 09:05, Saturday 22 August 2015 (20780)
Ops 8/22 OWL Summary

8/22 OWL Shift:  7:00-15:00UTC (00:00-8:00PDT), all times posted in UTC

Arrived to Commissioning on a locked H1, and L1 down for last 12+hrs.  Environemental conditions were nominal with wind dipping below 20mph & all seismic bands also quiet.

Want to reiterate that for ER8, we are deeming 1pm - 10pm (with L1 down) as the Commissioning window.  And I'd say if you need a measurement done during the 1-10pm window and H1 is locked, break lock in H1 and do your measurement if L1 is already down.

Additionally, before Evan, Dan, Stefan left, I made sure to have them clean up any differences on SDF.  Most were cleared up except for the OMC. 

After the Commissioning work, H1 has been locked the rest of the shift with nice range ~65Mpc & a few ETMy glitches dropping range.  DARM looks nice.  At times we seem to run below the reference from 10-20Hz.  There is also a bump at about 330Hz which is above reference.  H1 was much less glitchy for this OWL shift vs yesterday.

Shift Activities:

H1 General
corey.gray@LIGO.ORG - posted 04:16, Saturday 22 August 2015 - last comment - 19:06, Saturday 22 August 2015(20782)
Mid-Shift Update: H1 Back To Observing

SUMMARY:  Arrived to an H1 locked and in Commissioning, and L1 down for last 12+hrs.  There was some commissioning work and then H1 was taken to Observing Mode at 65Mpc.  Environemental conditions were nominal with wind dipping below 20mph & all seismic bands also quiet.

Commissioning Activity

Had a discussion about WP5442 with commissioners and since L1 was down and there was a measurement which needed to be done before O1, gave them a few hours to run a PLL measurement (they had it from roughly 7-10UTC).

H1 Back To Observing

Once they were done and H1 was back up to Low Noise, a roll mode was noticed aroudn ~41Hz (Dan/Evan mentioned it's a triple).  It rung down after about 10min, but it was huge at the onset.

While checking items before going to Observing Mode, noticed a CFC bit for H1OMC on the CDS Overview.  This was due to Evan & a diagnostic for LSC CARM (which we don't use).  I hit Load Coefficients to clear this bit.

At this point we were hovering at about 55Mpc.  Since we had low violin modes, transitioned from READY_FOR_HANDOFF to  ADD_WHITENING on the OMC_LOCK guardian (and then went right back to READY_FOR_HANDOFF).  This took the range up to 65Mpc. 

The range then went to a cool 65Mpc and the DARM spectrum looked very nice (compared to the previous night)--spectrum was very close/better than the reference.

SDF Overview had some DIFFERENCES, but Evan/Dan cleared most of them.  The only differences left were for:

OMC (5 diffs)

CALCS (29 diffs)

Comments related to this report
evan.hall@LIGO.ORG - 19:06, Saturday 22 August 2015 (20791)

According to Mark Barton's Mathematica model, 40.4 Hz is the HSTS roll mode.

H1 ISC (ISC)
stefan.ballmer@LIGO.ORG - posted 00:55, Saturday 22 August 2015 (20777)
Power increase with BS and SRM dither lines
We ran dither lines for BS and SRM during the power increase, as well as during the 45MHz EOM modulation depth reduction:

Lines:
H1:SUS-SRM_M3_ISCINF_P_EXC 7.0Hz, 300cts
H1:SUS-SRM_M3_ISCINF_Y_EXC 7.5Hz, 900cts
H1:SUS-BS_M3_ISCINF_P_EXC  8.0Hz, 100cts
H1:SUS-BS_M3_ISCINF_Y_EXC  8.5Hz,  30cts

Lines started by        2015/08/22 06:23 UTC
Start PWR UP:           2015/08/22 06:24 UTC
Stop PWR UP:            2015/08/22 06:26 UTC
Start EOM MOD:          2015/08/22 07:02 UTC
Stop  EOM MOD (-4dB):   2015/08/22 07:11 UTC
Lock loss:              2015/08/22 07:15 UTC

The EOM reduction reached -3dB, and was lost due to a SRC1_Y run-away.

Attached are (all plots have 72 min span, halting just before lockloss):
- Plot 1: AS RF36 PIT and YAW signals, plus the ASAIR_A_LF_OUTPUT for reference, showing i) power increase, ii)  beam diverter closing, and reopening, iii) modulation index reduction.
= Plot 2: All quadrants of the AS36 WFS, on the same scale
More details later.
Images attached to this report
H1 General
jim.warner@LIGO.ORG - posted 00:11, Saturday 22 August 2015 - last comment - 00:14, Saturday 22 August 2015(20775)
Shift Summary

Mostly quiet night, first couple of hours were hindered by winds maxing out at ~40mph. Once the max got down to ~35 we were able to lock. Winds have been slowly declining since.

~1:00 UTC Dan discovered an OMC PZT was tripped. See alog 20767.

Most of the rest of the night has been noise hunting.

~6:55 UTC, I went on the roof to look for grass fires as the front of the OSB smelled like smoke, and the cameras were too grainy to see anything. Commissioning crew reported no clear effect on IFO, but there was a series of saturations on ETMY.

Comments related to this report
evan.hall@LIGO.ORG - 00:14, Saturday 22 August 2015 (20776)

Saturations on EY appear to be from ASC dither lines we have temporarily inserted for diagnostic purposes.

H1 ISC
jenne.driggers@LIGO.ORG - posted 22:32, Friday 21 August 2015 (20771)
OMC dither alignment working again

[DanH, Jenne]

We have turned on the dither alignment for the OMC once again. 

Prior to the vent and addition of the shroud, the dither alignment was trying to drive the OMC suspension farther than the range of the actuators.  We gave it a try again today though, and it worked just fine. 

We used /opt/rtcds/userapps/release/omc/common/scripts/ditherDCsense.py to measure the DC sensing matrix, and write the calculated input matrix to OMC-ASC_DACTMAT. The matrix was somewhat different.   The servo filters and gains are unchanged, with the exception of the OMC-ASC_MASTERGAIN, which is now 0.05 (was 0.1 when using the QPDs). This is the same gain value that was previously used for the dither loops.   

The offsets in the OMC QPDs have been set so that they will servo the OMC to the same place as the dither servos, so that they agree. 

We didn't see any change in the ~300 Hz bump, even though Gabriele did see the OMC alignment correlate with the size of that hump (alog 20555). 

The use of the dither servos is now back in the guardian.

H1 SEI
jim.warner@LIGO.ORG - posted 22:08, Friday 21 August 2015 (20768)
Differences between grouted and ungrouted HAM HEPI's

I've been working on implementing blended inertial isolation on the HAM1 HEPI. This requires designing higher UGF loops, which I've been struggling with. I have Arnauds commissioning scripts, which I used as a starting point, but it was really hard to get as high a UGF as he did. When I dug into his data I realized that his plant was very different from mine. The first attached pdf compares his cartesian super-sensor transfer functions and mine (LLO is green, LHO is red, dof order is X, Y, RZ, HP, Z, RX, RY, VP). The only known difference between the two sites is the grouting on the HEPI piers. To test this, I looked at HAM4 and 5 here. I chose these chambers (4&5) because they are oriented the same direction, their payloads are similar (enough) and HAM5 is not grouted, while HAM4 is. Second attached pdf shows what i found (blue is HAM4 (grouted), orange is HAM5 (no grout), dof order is the same). Clearly grouting makes a difference. On all DOFs except HP HAM4's modes are higher by ~20-40%.

 

I don't think this makes a huge difference for HAMs 2-6 right now, but for HAM1 it will be difficult to make higher gain loops without grouting. It's not clear that better isolation at HAM1 will get us much right now, though Jeff took some initial measurements a few days ago, in alog 20664.

Non-image files attached to this report
H1 ISC (DetChar, ISC)
daniel.hoak@LIGO.ORG - posted 22:06, Friday 21 August 2015 - last comment - 03:41, Saturday 22 August 2015(20770)
DRMI glitches

Jenne, Dan, control room people

Attached are some additional plots of the glitches that Sheila posted about earlier today.  These are the same 'DRMI' glitches which we observed back in ER7 -- or, at least, they are similar enough that I can't tell the difference. 

In our most recent lock stretches, started around 0400 UTC, the glitches have gone away.  The mystery continues.

The excess noise is loudest in POP_A_RF9_I_ERR, which is what we use for PRCL in low noise.  We also see noise in POPA_45_I_ERR (used for SRCL), and not so much in the Q-phases.  See the first plot.  So, they're not an issue with the PD or the demod electronics.  It seems like real length noise, except the noise is very flat.  It's hard to imagine a glitchy actuator making flat noise in the PRC and SRC lengths.

FWIW the noise is also visible in POPAIR, with the same pattern as POPA.  We also see the excess noise in REFLA_45_I and Q (second plot).

Since these glitches appeared in ER7 we have implemented the offloading of the PRM and SRM M3 stages, so the drives to the last stage are mostly around zero.  We looked for any correlation with zero-crossings in the SRM and PRM M3 coils (third and fourth plots).  No smoking gun.

Images attached to this report
Comments related to this report
daniel.hoak@LIGO.ORG - 23:59, Friday 21 August 2015 (20774)DetChar, INJ, ISC, SUS

Jenne, Dan

Maybe the PRM M3 coil driver is bad?  Or something else in the analog electronics...

The gliches in the DRMI signals are correlated with bursts of noise in the PRM M3 NOISEMONs.  Compare the first plot (a glitching time) with the second plot (a quiet time).

This isn't surprising - if the PRM drive is compensating for a burst of noise in the PRCL error signal, we'd expect to see something in the coils.  But the NOISEMON readbacks for PRM M3 are different for each coil, and LL is the worst offender at the glitchy times.  See the third plot.  This plot includes a comparison with the SRM M3 NOISEMON, which also shows a difference between glitchy and quiet times, but the coil NOISEMONs agree.

The variation between the coils is certainly due to something in the analog electronics.  In the fourth plot we show the PRM M3 MASTER_OUT signals.  The drive to the optic from the digital side is the same for all the coils.

It could be that the PRM M3 NOISEMONs are just wrong, but the correlation with the glitches is suspicious.

Not sure if this is enough to justify swapping the coil driver.

The fifth plot is a time-series of the PRM NOISEMONs at the time of a glitch.  The y-axis has been scaled the same for all channels to highlight the large value of the LL readback.  Note that the LR channel has two dropouts, this happens frequently (there are LR dropouts in both of the first two plots) but is not correlated to the DRMI glitches.

Images attached to this comment
andrew.lundgren@LIGO.ORG - 02:14, Saturday 22 August 2015 (20778)DetChar, SUS
Agreed that the PRM M3 LL driver looks like it's broken. The excess noise in all of the ISC channels is a shelf up to about 70 Hz, and that's what is being sent out to the PRM drive. But in just the LL noisemon, the noise bursts actually go up past 1000 Hz. In UR and UL, the noisemons look just like the drive signal. The attached PDF lines up the two spectrograms to show this. Unless the noisemon is very nonlinear, LL is generating excess noise. Is there a transfer function somewhere of PRM M3 to different ISC degrees of freedom that would tell us whether this could be causing all the noise we see?

The second page shows that the noise from LL is probably not major-carry glitches. They don't line up with zero crossings in the drive.

The third page shows that the LR noisemon is broken. It looks like it's got ADC overflows or some other kind of saturation. I'll try to check it for ADC overflows.  
Non-image files attached to this comment
daniel.hoak@LIGO.ORG - 02:12, Saturday 22 August 2015 (20779)

For completeness, I checked if the glitches show up in the ASC signals that are sensitive to the PRC alignment.  They do: the plot attached shows that during glitch times (dashed references) the REFL WFS have excess noise in the same band as the LSC sensors.

So, it's not pure length motion -- consistent with the picture of a single glitchy quadrant on PRM M3.

Images attached to this comment
andrew.lundgren@LIGO.ORG - 03:41, Saturday 22 August 2015 (20781)DetChar, ISC, SUS
Dan and Jenne were wondering if this happened in ER7. I took a time when we saw similar mysterious DRMI glitches (June 7 19 UTC) and made some spectra and spectrograms. It looks like the same thing happening, but less severely. The noisemon in UR has the same shape as the drive signal, but LL clearly has a different shape and more excess noise at high frequency. Maybe some other Detcharians can look into this in more detail.
Images attached to this comment
H1 General
travis.sadecki@LIGO.ORG - posted 16:13, Friday 21 August 2015 - last comment - 09:37, Saturday 22 August 2015(20763)
OPS Day Shift Summary

We were locked most of the day until ~21:00, out of lock for around an hour, and came back up relatively easily ~22:00.  Another successful PRMI-->DRMI transition trick seemed to help expedite the process. 

Although I failed to note specific times, Kyle and Gerardo were working at Y-2-8 most of the day, and Jodi visited the mid stations for property tagging work.  Neither of these seemed to effect the IFO performance noticably.

Winds have been in the 20-30mph range for the past 4 hours, with a few gusts to ~40mph.

Comments related to this report
corey.gray@LIGO.ORG - 22:39, Friday 21 August 2015 (20772)

What's the PRMI -> DRMI transition trick?

betsy.weaver@LIGO.ORG - 09:37, Saturday 22 August 2015 (20784)
We added it to the ops wiki under the DRMI section. It's from an slog a day or two ago by Stefan.
H1 General
travis.sadecki@LIGO.ORG - posted 10:56, Friday 21 August 2015 - last comment - 15:47, Sunday 23 August 2015(20744)
PCal line turned back on

Sudarshan reports that a PCal line was turned off sometime last night.  He is turning it back on at 17:53.

Comments related to this report
sudarshan.karki@LIGO.ORG - 11:30, Friday 21 August 2015 (20747)

Darkhan, Sudarshan

Pcal Lines got turned off last night during a pcal sweep measurements (LHO alog 20734 and  20732) because the optical follower servo got unlocked. We  turned two lines one at 36.7 Hz and the other one at 331.9 Hz back on. We ramped it slowly to avoid any lock loss but we still saw some drop in the range. We left the higher frequency line at 1083.7 Hz off for now. We will turn this back on during the comissioning period or next lockloss opportunity.

Attached is a trend of  Optical Follower Servo error signal showing when the lines got turned off.  (around 2015-08-21 07:20:00 UTC)

Images attached to this comment
laura.nuttall@LIGO.ORG - 13:54, Friday 21 August 2015 (20754)

Are we meant to be able to see the PCal lines in the normalised spectrogram of DARM? You can see them disappear and turn on again at about the times you mention, see the first plot (this is GDS strain). Also PCal End Y doesn't look so happy, see second plot. Plots were taken from the PCal part of the summary pages

Images attached to this comment
sudarshan.karki@LIGO.ORG - 14:47, Friday 21 August 2015 (20759)

Yes, Pcal line are supposed to appear in h(t).

Also, the third line at 1083.7 Hz is turned back on after the lockloss.

corey.gray@LIGO.ORG - 22:43, Friday 21 August 2015 (20773)

What's the best way for Operators to confirm whether PCal (and DARM) Cal Lines are present?  (seeing Excitation on CDS Overview?  looking for lines on DARM spectra?  Navigating to Calibration Line medms?)

Let us know and we can put this in checklists for operators to check.

sudarshan.karki@LIGO.ORG - 15:47, Sunday 23 August 2015 (20804)

I made  a DTT template which has all the calibration lines  on it. May be we can arrange to display this on the screen (A screenshot is attached.).  The template sits on the following location.

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/Templates/ Calibration_line_template.xml

The other way  is to head to PCAL medm screen and look at the OFSPD plot on the screen. If there is no excitation this plot should be flat.

Images attached to this comment
Displaying reports 62861-62880 of 83104.Go to page Start 3140 3141 3142 3143 3144 3145 3146 3147 3148 End