Displaying reports 62101-62120 of 83002.Go to page Start 3102 3103 3104 3105 3106 3107 3108 3109 3110 End
Reports until 23:00, Saturday 12 September 2015
LHO FMCS
corey.gray@LIGO.ORG - posted 23:00, Saturday 12 September 2015 (21458)
EX Chiller Critical Alarm: Came and Gone

At 5:26 UTC (10:26pmPST), received a LOW/MAJOR alarm for H0:FMC-EX_CY_H2O_SUP_DEGF with a value of 34.99degF.  Looking at trends, it appears this signal approaches this lower limit value every 24hrs (so perhaps it should be lowered more, or something needs to be addressed at EX).  It stayed in alarm for 7minutes and then the signal started turning up.

Attached is a 3-day trend of the channel.  Will send an email to Bubba about this, so he can check it out Monday.

Non-image files attached to this report
H1 INJ (INJ)
peter.shawhan@LIGO.ORG - posted 22:05, Saturday 12 September 2015 (21456)
Unable to start CW hardware injections
(Peter Shawhan, Corey Gray)

After the evening's GRB alert stand-down period expired, I asked Corey to turn off the Intent bit briefly so that I could start the CW hardware injections with the new ER8B configuration.  At about 21:55 PDT I did "bin/x_start_psinject Peter Start with new ER8B config", at the injections were supposed to start at GPS 1126155410.  However, it didn't work.  The file log/psinject_H1.15_09_12_21:55:33 says: "../../bin/psinject: error while loading shared libraries: libCore.so: cannot open shared object file: No such file or directory".  I won't try to debug that tonight.
H1 INJ (INJ)
peter.shawhan@LIGO.ORG - posted 21:27, Saturday 12 September 2015 (21455)
Added burst hardware injections to schedule
I added 17 burst hardware injections to the future schedule, at the following GPS times:
1126160500, 1126180500, 1126190500, 1126210500, 1126220500, 1126240500, 1126270500, 1126280500, 1126300500, 1126310500, 1126330500, 1126340500, 1126360500, 1126390500, 1126400500, 1126420500, 1126450500

As described the last time we started a sequence of burst injections (alog), an injection will automatically be skipped if the instrument is not in observing mode, if there is a GRB alert one-hour stand-down, if the operator disables or pauses injections, etc.
H1 ISC
evan.hall@LIGO.ORG - posted 21:18, Saturday 12 September 2015 (21450)
HAM6 injections

Stefan, Evan

We spent some time trying to see if some of the unexplained noise in DARM is caused by jitter (or other nonlinear pointing noise) in HAM6.

First, some things that didn't work:

We were able to make jitter noise by driving OM3 (I guess it would be surprising if we weren't able to do this). The first attachment shows some example bilinear coupling made by driving OM3 in yaw at 94.3 Hz.

Then we opened the OMC REFL beam diverter and tried some bandlimited injection between 35 and 45 Hz. The result is attached. We saw no coherence between OMCR and DARM (consistent with the notion that the coupling is all bilinear). Also, pitch and yaw of OMC REFL are highly cross-coupled. [Sorry for choosing a polluted band—I wanted a place where the DARM noise was low but where the OMC REFL QPDs are still plausibly seeing displacement noise.]

Finally, we made a broadband injection from 10 Hz to 300 Hz, in pitch and yaw. The times were 01:44:40–01:51:40 for yaw and 01:54:30–01:59:30 for pitch, both 2015-09-13 Z. The result for yaw is attached.

Non-image files attached to this report
H1 General
corey.gray@LIGO.ORG - posted 21:06, Saturday 12 September 2015 (21454)
GRB at 3:52UTC

At 3:52 (8:52pmPST), Verbal Alarm notified us of a GRB.  Event info is here.  Verbal Alarm was quick with the notification (TJ and others mentioned it had been getting notices minutes/hours after an event).

Following GRB Checklist (p.2 of L1500117), we have the following:

LHO General
corey.gray@LIGO.ORG - posted 20:12, Saturday 12 September 2015 - last comment - 20:26, Saturday 12 September 2015(21451)
Mid Shift Summary

9/12 EVE Shift:  23:00-7:00UTC (16:00-0:00PDT), all times posted in UTC

At 3:08UTC H1 was taken to Observation Mode since Evan was done with his injections.  

Prior to this we saw some oscillations on IMC-F on the Tidal StripTool of nuc1, but we saw no other oscillations or seismic noise.  

Support:  Jenne & Evan are also in the Control Room, but sounding like they are finishing up for the night.  

Comments related to this report
corey.gray@LIGO.ORG - 20:26, Saturday 12 September 2015 (21453)

Winds have just quickly jumped up to over 20mph at around 3:10utc.

H1 CAL
madeline.wade@LIGO.ORG - posted 18:51, Saturday 12 September 2015 - last comment - 22:01, Sunday 13 September 2015(21445)
Time-dependent correction factors for calibration as computed by GDS calibration pipeline
Attached are plots of the time-dependent calibration correction factors as computed by the GDS calibration pipeline for GPS times 1126003432-1126011584 (Fri Sep 11 03:43:35 PDT 2015 - Fri Sep 11 05:59:27 PDT 2015).  The derivation of these factors and their meaning is described in DCC-T1500377.  

The channel names correspond to the factors as such:

GDS-CALIB_F_CC: frequency of coupled cavity pole
  - average value ~ 350 Hz
GDS-CALIB_KAPPA_C: time-dependent scale factor for the sensing 
  - average value ~ 1.07
  - expected average value = 1
GDS-CALIB_KAPPA_A_IMAGINARY: imaginary part of time-dependent scale factor for the total actuation
  - average value ~ -0.01
  - expected average value = 0
GDS-CALIB_KAPPA_A_REAL: real part of time-dependent scale factor for the total actuation
  - average value ~ 1.01
  - expected average value = 1
GDS-CALIB_KAPPA_PU_IMAGINARY: imaginary part of time-dependent scale factor for the PUM/UIM stages of actuation
  - average value ~ 0.03
  - expected average value = 0
GDS-CALIB_KAPPA_PU_REAL: real part of time-dependent scale factor for the PUM/UIM stages of actuation
  - average value ~ 1.07
  - expected average value = 1
GDS-CALIB_KAPPA_TST_IMAGINARY: imaginary part of time-dependent scale factor for the TST stage of actuation
  - average value ~ 0.05
  - expected average value = 0
GDS-CALIB_KAPPA_TST_REAL: real part of time-dependent scale factor for the TST stage of actuation
  - average value ~ 1.0
  - expected average value = 1.0

These values indicate some (O(5%)) differences in gain between the current calibration models and the IFO.  We expect this level of difference for kappa_tst and kappa_c.  However, we anticipated kappa_pu to be closer to the expected average values.  This discrepancy is still being investigated.
Images attached to this report
Comments related to this report
madeline.wade@LIGO.ORG - 22:01, Sunday 13 September 2015 (21485)

I recomputed the factors for this time period using the "fudge factor" described in alog 21479.  The new computed factors match with those for the later times in Sudarshan's alog (#21479).  See attached plots.  (Note: The units on the f_cc plot are Hz on the y-axis. Sorry for the confusion in the labeling.)

Images attached to this comment
H1 INJ (INJ)
peter.shawhan@LIGO.ORG - posted 18:11, Saturday 12 September 2015 (21444)
Restarted tinj (transient injection process), but no new injections scheduled YET
'tinj', the transient injection driver program, has not been running since Sept. 8 -- which is fine since there were no signals scheduled to be injected.  This evening I restarted it by logging into the h1hwinj1 machine (as user 'hinj'), cd'ing to /data/scirun/O1/HardwareInjection/Details/tinj/, and doing "nohup run_tinj >& nohup.out &".  So tinj is now running, but we have not YET put any new injections into the schedule.  We'll do that after checking with people that they won't interfere with other activities.
LHO General
corey.gray@LIGO.ORG - posted 17:39, Saturday 12 September 2015 - last comment - 19:32, Saturday 12 September 2015(21443)
Transition To EVE Shift Update

TITLE:  9/12 EVE Shift:  23:00-7:00UTC (16:00-0:00PDT), all times posted in UTC

STATE OF H1:  Relocking, but also riding out remnants of New Zealand EQ from 2hrs earlier.  

OUTGOING OPERATOR:  Jim

QUICK SUMMARY:  Walked in to H1 in Lock Acquisition, and saw several attempts during high seismic noise.  

Once in NOMINAL_LOW_NOISE, Evan took over for commissioning (I talked with Joe at LLO and they were having Bounce Woes.  When they get it locked, Anamaria/Robert would probably take L1.  So they will be out of Observation for a while.  In the meantime, Evan will conduct Noise Budget injections.  

Seismic coming down & winds inching up.

Comments related to this report
corey.gray@LIGO.ORG - 18:55, Saturday 12 September 2015 (21447)

EARTHQUAKE COMING!!  EARTHQUAKE COMING!!  

1:55 UTC:  5.8 earthquake from Indonesia on the way-->  ETA of Rayleigh wave:  2:10UTC

Evan's trying to finish a measurement.  Jenne might try to do some offloading if there's time.....

corey.gray@LIGO.ORG - 19:32, Saturday 12 September 2015 (21448)

False Alarm:  Did not see anything in the control room for the above-mentioned incoming EQ.  Note:  It's velocity was 0.59um/s (compared to 1.1um/s of similar magnitude New Zealand quake which kept us down for 2+hrs.

H1 INJ (INJ)
peter.shawhan@LIGO.ORG - posted 17:29, Saturday 12 September 2015 (21442)
Diagnosing problematic hardware injection on September 4: pointer to wiki page
We started a sequence of scheduled transient hardware injections with burst waveforms on September 3 (LLO aLOG 20246, LHO aLOG 21186) with the intention of testing the basic operation of the low-latency burst analysis and the EM follow-up event selection logic.  It was done with the inverse actuation filters left over from ER7, so we didn't expect accurate injection of the desired strain waveforms, but that was OK for the purpose at the time.  However, we woke up the next morning to find that one of the injected coherent signals had been unexpectedly loud.  (Another injected coherent signal, though, was fine.)  Investigations of that anomalous event have been collected at https://wiki.ligo.org/LSC/JRPComm/G181472.

No further transient hardware injections have been done since then (LHO aLOG 21202, LLO aLOG 20254).  However, we are planning to resume burst hardware injections, restricted to fairly low frequencies, soon.
H1 General
jim.warner@LIGO.ORG - posted 16:02, Saturday 12 September 2015 (21441)
Shift Summary
H1 AOS (DetChar, PEM, SEI)
joshua.smith@LIGO.ORG - posted 14:57, Saturday 12 September 2015 - last comment - 14:02, Wednesday 30 September 2015(21436)
The 50Hz glitches in DARM: EX mains glitches coupling into EX seismic?

Josh, Andy, David, Jess

Conclusion: We suspect that the 50Hz glitches in DARM are caused by EX Mains glitches that happen 400+/-70ms earlier (reliably matched) and may(?) couple through EX Seismic. 

Throughout September there has been a persitent line of glitches at 50Hz in DARM with a pretty high rate. See the attached glitch-gram from today's summary pages. Based on the one hour plots on the summary pages, the rate of these 50Hz glitches in DARM is about once per minute. 

We found (see e.g. the first round here) that these DARM glitches are correlated in time with glitches in EX channels, particularly PEM EX SEIS/ACC*, ISI ETMX ST1 BLND*, and ASC-X_TR*. 

It looks like the cause of this may be a big glitch in EX Mains. Wew see the EX and DARM channels are all glitching with a 400+/-70ms delay (averaged five examples followed up by hand) after EX mainsmon. Attached are two examples where we lined up the glitch in EX mainsmon and showed that the glitches in EX seismic and DARM are 400ms later. 

Notes:

We would be happy to follow up further leads, but wanted to report what we found so far. 

PS. Should you wish to repeat this yourself, attached is a list of these glitches in DARM today (with nice GPS times) and a screenshot of the ldvw settings I used. 

Images attached to this report
Non-image files attached to this report
Comments related to this report
david.shoemaker@LIGO.ORG - 14:55, Saturday 12 September 2015 (21438)
Note that the signal in the seismometer is a bit later than the mainsmon glitch, and that the seismometer glitch is narrowband around 50 Hz in contrast to the mainsmon. A guess is that there is a mechanical coupling -- maybe a motor running slow due to it hitting something, or a transformer core pulsing -- which induces the 50 Hz characteristic. Seems like it might be easy to hear. The delay suggests that it could be something a bit away -- maybe a chiller?
john.worden@LIGO.ORG - 20:17, Saturday 12 September 2015 (21452)

The chiller compressor is probably on the order of 100 hp (>100 amps at 480v) and is cycling with a period of ~1hour during most of the day. The period depends on the heat load into the building. During the hot time of day one chiller compressor will continue to run while a second compressor will cycle as needed. In the attached plot the peaks represent the start of the chiller compressor. The valleys represent the shutdown. Times are PDT. 

Images attached to this comment
joshua.smith@LIGO.ORG - 14:14, Sunday 13 September 2015 (21470)DetChar, PEM, SEI

After emails with Robert S and John W we did an extensive search in the "HVE-EX:*" and "H0:FMC-EX*" channels for anything that is switching on or off at the same time as the glitches reported above. John Worden suggested that the instrument air compressor (a ~5hp motor at EX) would switch on and off with about the right period. I attach a plot that shows that the glitches discussed above for EX seismic (left) and DARM (right) are correlated with the compressor turning ON at the bottom of the triangle waveforms. 

Images attached to this comment
H1 SUS
jenne.driggers@LIGO.ORG - posted 14:24, Saturday 12 September 2015 - last comment - 19:48, Saturday 12 September 2015(21437)
EQ lockloss

Terramon told us that we had an incoming earthquake large enough to likely break lock, so I asked Jim to take us out of Observing mode so that I could quickly try to increase the SRM offloading, to see if that would save the lock.  In the end, we still lost the lock.

I changed the SRM M1 Lock L gain from the nominal -0.02 to -0.05 with a 10 second ramp.

I need to look at the data to know more, but the verbal alarm did not complain about SRM saturations.  It did however complain about ETMY saturations. 

If that really did help prevent SRM saturations from causing our lockloss, I wonder if we should think about increasing every optics' offloading gain by a factor of 2 or 3 when we have an earthquake coming.  Anyhow, I need to look at the data to see what really happened, and to see if I can figure out what really helped.

Comments related to this report
jenne.driggers@LIGO.ORG - 19:48, Saturday 12 September 2015 (21449)

SRM offloading by just increasing the gain was no good. 

I think that I must have made the crossover unstable, which made something not good at the AS port.  The HARD ASC loops (particularly DHARD Pitch) start to oscillate, which is probably why all 4 test masses are saturating their L2 drives at the time of lockloss (and ETMY is also saturating the L3 drive). 

So, oopsies.  While trying to save the lock, I seem to have killed the lock. 

To actually fix the SRM offloading, I'll need to measure the crossover to check its stability, and maybe tune the filters a bit.

H1 ISC
stefan.ballmer@LIGO.ORG - posted 13:10, Saturday 12 September 2015 - last comment - 17:26, Saturday 12 September 2015(21435)
ODC housekeeping
IM4 QPD, lower 2 quadrants were saturating - lowered their whitening gain by 9dB from 36dB to 27dB (gain value from 12 to 9) IM4 is not in any loop, so no impact on feed-back.


Before clicking undisturbed, we updated some ODC settings:
- default ODC filter mask were set for PRM, SRM, SR3, ETMX and ETMYY
- took out LSC and ASC party check from MASTER mask (the party from those models is not reported correctly, see alog 20936)
- all changes are in SDF

- additionally updated the ASC ODC transmon alarm thresholds form 0.2 (Xarm) and 0.3 (Yarm) to to 0.7 at 20:02 UTC - the intent bit was unset for 2 min,. but the data is unaffected.
Note that H1:ASC-Y_TR_B_YAW_OUTPUT had drifted all the way up to -0.55 - presumably due to TMS drift.
We are using -1.1*TRY_A_YAW + 0.5*TRY_B_YAW for servoing, because this independent of TMS drift. Of course, if we move enough that we fall off one diode, that's no longer true. We should keep an eye on that.
- all changes are in SDF
Comments related to this report
stefan.ballmer@LIGO.ORG - 17:26, Saturday 12 September 2015 (21440)
Updated the site overview screen to show blue for bits that are know to stay not green in full lock. The site overview screen should now show NO red in lock.
Also made a stripped down mini version, and stuck it on nuc1.

Note: If there is any red in full lock now, something changed - please track it down from now on.

Attached are screen shots of how the overview screens should look.

Images attached to this comment
H1 CAL (CAL)
matthew.evans@LIGO.ORG - posted 07:59, Saturday 12 September 2015 - last comment - 15:25, Saturday 12 September 2015(21424)
Inverse Actuation Filter for Hardware Injections

A few thought as a follow on to Jeff's entry:

  1. Injecting signals at DARM control (see G1501146) seems like a bad idea
    • while this worked in iLIGO, which had a relatively simple actuation TF, the DARM ctrl to DARM displacement TF is much more complicated now that we have a multi-stage suspension
    • the inverse TF looks like 1 / A * (B + C + D), which, by virtue of containing a sum in the denominator, can be very messy
    • not only is it messy, it is not robust against small changes in the DARM actuation path.  Think 1 / A * (g * B + C + D) and then let g vary... this will cause the poles and zeros to move.
    • Injecting directly into an actuator with a simple TF to DARM displacement (or force) would be much better (e.g., at the ESD or with PCAL).
  2. I'll see what I can do to make an inverse filter, but I will be happy if a better way is found and this filter is never used.
Comments related to this report
matthew.evans@LIGO.ORG - 12:44, Saturday 12 September 2015 (21432)

SVNs required for this:

svn co https://svn.ligo.caltech.edu/svn/aligocalibration/trunk/Runs/ER8 CalSVN/aligocalibration/trunk/Runs/ER8
svn co https://svn.ligo.caltech.edu/svn/aligocalibration/trunk/Common/H1CalFilterArchive CalSVN/aligocalibration/trunk/Common/H1CalFilterArchive
svn co https://svn.ligo.caltech.edu/svn/aligocalibration/trunk/Runs/S7/Common/MatlabTools CalSVN/aligocalibration/trunk/Runs/S7/Common/MatlabTools
svn co https://svn.ligo.caltech.edu/svn/seismic/Common/MatlabTools SeismicSVN/seismic/Common/MatlabTools
svn co https://redoubt.ligo-wa.caltech.edu/svn/sus/trunk/Common/SusModelTags/Matlab SusSVN/sus/trunk/Common/SusModelTags/Matlab

All of which results in an ETMY actuation function, saved in the attached .mat file (and shown in the image).  In the attached image, I have removed the 1/f^2 slope to reveal the bumps and wiggles of the TF that needs to be inverted.

Images attached to this comment
Non-image files attached to this comment
matthew.evans@LIGO.ORG - 15:25, Saturday 12 September 2015 (21439)

A fit to the actuation function is attached, along with images of the fit and the residual.  Mostly, the fit is within 10% and 5dg from 10Hz to 1kHz.  The pole and zero Qs are not very large, so the inverse should be workable.

Images attached to this comment
Non-image files attached to this comment
Displaying reports 62101-62120 of 83002.Go to page Start 3102 3103 3104 3105 3106 3107 3108 3109 3110 End