Displaying reports 56881-56900 of 78036.Go to page Start 2841 2842 2843 2844 2845 2846 2847 2848 2849 End
Reports until 19:33, Sunday 20 September 2015
H1 ISC (SEI, SYS)
sheila.dwyer@LIGO.ORG - posted 19:33, Sunday 20 September 2015 (21708)
Locklosses between Sept 10th and 17th (DHARD yaw needs a boost)

I had a look at locklosses durring the last week of ER 8 (Sept 10 to 17th)  The mesage is that loose and cross coupled angular controls that can't handle increased ground motion seem to be contributing to most of our locklosses (at least 15 out of 18).

There were 22 locklosses durring this time, I discarded 4 of them because of commisioning activites: (1125897235.18750 (ASC commisioning) 1125951730.31250(ASC commisioning) 1125996518.31250 (ASC commisioning) 1126229152.18750 (not really a lockloss)  1126251273.81250 (AS Bdiv open, probably beam jitter measurements)) 

Of the remaining 18 locklosses, 9 were within 5 minutes of an earthquake arriving on site, and a tenth had an earthquake showing up on the 30-100 mHz blrms 5-10 minutes after the lockloss. 5 more of the locklosses were at times when there was no earthquake but the ground was tilting probably due to wind.  (The z direction ground motion was quiet but the X direction was moving).

Most of the earthquake locklosses where ones in which the ASC error signals were not well supressed for 10s of seconds before the lockloss.  The first attachment shows how I sorted the locklosses into ones where some ASC error signals were clearly not supressed, and others where there was no obvious problem in the error signals for 10s of seconds before the lockloss.  The second attachment shows plots of the ground motion at the time of lockloss with the same sorting of locklosses into bad ASC/ OK ASC. 

Next I plotted all the ASC error signals (normalized by a max of each) on one plot for pit and one for yaw for each lockloss. I won't attach all those plots, but generally yaw went bad earlier than pitch and DHARD yaw was one of the first error signals to wander away in almost all of the locklosses.  We have a boost (FM3) available for DHARD Y that we aren't currently using, and plently of phase margin available to turn it on  20084. Turning this on seems like the very first step we should take in trying to ridde out ground motion better.  If any operators see an earthquake coming they might as well try this.  Also if you need to leave observation mode or relock, you might as well try engaging this boost.

I also looked at saturations for 9 of the earthquake locklosses, severa of them seem to have no saturations until after the lockloss.  A few have saturations of ETMY, there is a pitch oscillation that grows in the final seconds of the lock making the L2 control signal large.  The L3 length control signal responds to this and can also become large.  There were a few locklosses where SRM M3 saturates because of a large pitch drive. 

The next steps I would propose are to engage the DHARD yaw boost first (this should be safe and only take seconds).  After that, it would be good to continue trying to decouple our ASC loops better by phasing the REFL 45 WFS, and using them to control the SRC ASC.  This is a project that is probably best done at 3 Watts and whenever we can set aside a few hours for commisioning.  It doesn't seem like saturations from length loops are much of a problem for us now, so we can probably not worry about that for now.

Images attached to this report
H1 GRD (ISC)
thomas.shaffer@LIGO.ORG - posted 19:22, Sunday 20 September 2015 - last comment - 08:19, Monday 21 September 2015(21714)
ISC_LOCK Guardian error

While I was investigating alog21712 I found that the ISC_LOCK Guardian node went into error at 22:43 UTC.  "AttributeError: 'REFL_IN_VACUO' has no attribute 'failure' ". Seems like a code error but I don't see an log if it was fixed or just reloaded or what. I will investgate further when I get a chance.

Images attached to this report
Comments related to this report
travis.sadecki@LIGO.ORG - 08:19, Monday 21 September 2015 (21730)

That was my fault due to an errant button click while frantically trying to relock before your shift started.  This was during initial alignment in which I had the ISC_LOCK guardian in manual mode in order to take it to DOWN.  I believe I was trying to click another window below the open 'ALL LOCK STATES' window (note that the REFL_IN_VACUO button is the bottom left button in this window).  I noticed it went into error trying to get to this state, but attributed it as my mistake, reloaded the node, and failed to log it since I was doing other things at the time.  Once I went back to AUTO, the error state cleared.

LHO General
thomas.shaffer@LIGO.ORG - posted 19:09, Sunday 20 September 2015 - last comment - 19:17, Sunday 20 September 2015(21713)
Out of Observation for a quick fix

Going out of Observation to hopefully fix and issue with an RF Amp. The range has been dropping for the past hour and now we are down to ~40Mpc. Broadband noise has also been getting worse. Stephan has an idea on how to fix it, so I'm going to let him attempt a fix. We have consulted with Keita who has seen this before, and also got the OK from Mike Landry. I'm sure there will be an alog to follow.

Comments related to this report
thomas.shaffer@LIGO.ORG - 19:17, Sunday 20 September 2015 (21715)

Back into Observation. Not a great fix but slightly better. 

Winds are down to 20mph gusts and seismometers are a littleb bit better as a result.

H1 GRD (CDS)
thomas.shaffer@LIGO.ORG - posted 18:44, Sunday 20 September 2015 - last comment - 09:26, Monday 21 September 2015(21712)
Guardian DIAG_MAIN frequent error from cdsutils avg

The DIAG_MAIN node will go into error a little less than once a day, and report:

File "/ligo/apps/linux-x86_64/cdsutils-497/lib/python2.7/site-packages/cdsutils/avg.py", line 67, in avg
2015-09-21T01:10:35.46180     for buf in conn.iterate(*args):

RuntimeError: Requested data were not found

(screenshot attached)

 

While this only requires the operator to reload the node, the cdsutils avg package is used in other nodes such as ISC_LOCK and OMC_LOCK (and others that I can't think of off the top of my head). This inconsistancy also omits its use in the DIAG_CRIT node, for fear that it will not be able to find the data, bring the node into error, and then out of Observation.

Operators: Please log and screenshot the Guardian log any time that a Guardian node goes into error. This will help us diagnose the problem, or others, faster.

Images attached to this report
Comments related to this report
jameson.rollins@LIGO.ORG - 09:26, Monday 21 September 2015 (21734)

The logs are plain text, so you can just copy/paste them into the log as well.

H1 ISC
stefan.ballmer@LIGO.ORG - posted 18:40, Sunday 20 September 2015 - last comment - 20:17, Sunday 20 September 2015(21709)
Weird HF noise
We again have the non-stationary noise described in alog 21353 

Interestingly, the noise also seems to move around in frequency. Attached is a power spectrum of 3 different UTC times, both of DELTAL_EXTERNAL and OMC_DCPD_SUM. (OMC_DCPD_NULL does not show it.)
Images attached to this report
Comments related to this report
stefan.ballmer@LIGO.ORG - 19:37, Sunday 20 September 2015 (21716)
.. was due to to the RF45 EOM driver acting up.

Attached are the same specra, from the same times, but including the H1:LSC-MOD_RF45_AM_CTRL_OUT_DQ channel, as well as its coherence with DCPD_SUM.

H1:LSC-MOD_RF45_AM_CTRL_OUT_DQ is clearly elevated when we have this noise show up.

As a temporary fix (because we are still in a CAMLAND alert) we lowered the modulation index by 1dB:

H1:LSC-MOD_RF45_AM_RFSET  was 23.2   is      22.2
and related (because this lowered the light entering HAM6)
H1:ASC-ODC_AS_A_DC_LT_TH  was -13000  is   -11000
(this could just stay there - no need to revert)

Remarks:
- Currently the DOWN script will NOT set H1:LSC-MOD_RF45_AM_RFSET back on lock loss
- This change in the SB power will lower the modulation index (normally ~0.3) by 1 dB.
- Thus the carrier power (~(1-Gamma^2/2) will go up by about 1%.
- Updated the guardian to reset H1:LSC-MOD_RF45_AM_RFSET to 23.2 in the DOWN state (ISC_LOCK.py, svn revision 11674) It was reloaded at 2:59 UTC.
Images attached to this comment
jeffrey.kissel@LIGO.ORG - 20:17, Sunday 20 September 2015 (21718)CAL, CDS, DetChar, PEM, SYS
Tagging a few more subsystems so more people get the memo to help investigate, and note the change in configuration for this lock stretch.
H1 AOS
jeffrey.kissel@LIGO.ORG - posted 18:01, Sunday 20 September 2015 - last comment - 20:45, Sunday 20 September 2015(21707)
Reducing the Watchdog Noise -- SRM and OMC are in no Danger...
J. Kissel, T. Schaffer 

During the brief period we were down and attempting to lock the IFO this afternoon, TJ's robot -- we'll call him Jeeves today -- was announcing that the SUS SRM and SUS OMC's Software Watchdogs were tripping. The software watchdogs have not tripped. This watchdog noise has been going on for quite some time, and I wanted to get to the bottom of it. Here're my conclusions:

(1) Neither the SUS SRM or SUS OMC are in danger.
(2) The robot is claiming a "trip," but it is merely reporting that the EPICs records
H1:IOP-SUS_$(OPTIC)_WD_RMS
H1:IOP-SUS_%(OPTIC)_DK_SIGNAL
are indicating that the BLRMS of top mass OSEMs is briefly surpassing threshold. Recall that we need 300 [sec] = 5 [min] of these indicators at solid "bad" = "red" before *any* action is taken by the software watchdog. Thus, the robot is claiming a much worse thing has happened than what has really happened.
(3) The suspensions' top masses are moving "so much" because of ISC control fed to the SUS and those stages of the SUS (for the SRM, it's occasionally blasts from the angular controls, and for the OMC it's more consistent blasting in all L, P, and Y DOFs -- but also for angular control). I imagine that because the ground motion is rather large right now with the wind, the top masses are moving more from residual ground motion AND the ISC request is larger trying to account for it.
(4) The threshold for the software watchdog is set right where it should be, given how long and consistently the threshold must saturate before any action is taken. The USER watchdogs, which watch the same RMS signal (just not calibrated into volts as the software watchdog has been), are at 20% / 75% of their threshold for SRM / OMC (respectively) for tripping during this time. I don't argue that these have been set any more carefully, but in any case, the USER WD should trip first, and in this case it will.
(5) We could probably treat the suspensions a little nicer by being a little smarter about when we turn on the ASC control, or putting software limits on the control signals, but they're big girls -- they can handle it.

I suggest the only thing we change is the EPICs record that Jeeves watches to 
H1:IOP-SUS_OPTIC_DK_WD_OUT
to report that the software watchdogs have tripped. This record tells you that 5 minutes has passed in which the OSEMs have surpassed their threshold, and has triggered the SEI system's countdown until shutdown which will be 5 minutes later.

I attach screenshots of the ISC Lock Guardian's state, the RMS values of the trigger signals for both the USER and SW WDs for both SRM and OMC, as well as a trend of the ISC requested drive to that respective suspension. These trends, and my knowledge of the design of each of these watchdogs, are what have convinced me of the above conclusions.
Images attached to this report
Comments related to this report
thomas.shaffer@LIGO.ORG - 20:45, Sunday 20 September 2015 (21721)

I've changed it in "Jeeves" aka VerbalAlarms

LHO General
thomas.shaffer@LIGO.ORG - posted 17:12, Sunday 20 September 2015 (21706)
Observing

Observing at 0:08 UTC

Both LHO and LLO received a GRB alert at 23:34 UTC, so we are up for the end of the alert at least.

There are still high winds, 35mph gusts, so let's hope its stays.

H1 INJ (CAL, CDS, DetChar, INJ, ISC)
jeffrey.kissel@LIGO.ORG - posted 16:11, Sunday 20 September 2015 (21703)
Minus Sign Installed in HARDWARE INJ Filter
J. Kissel,

I've finally been on site while one of these extremely robust IFOs (LHO aLOG 21702) was out of observation mode! As such, I've installed the minus sign needed in the inverse actuation filter in the DARM CTRL path for hardware injections (see explanation for need in LHO aLOGs 21627 and LHO aLOG 21616). I've done so by installing a third filter called "O1.C" in FM5, which is simply a gain of -1.0. To the best of my knowledge, hardware injections have not yet gone through anywhere since the TINJ, regularly scheduled, burst injections Monday afternoon which re-found the need (LHO aLOG 21508), the like of which have since been halted. Also, note that there have been no other changes to the filter. For example, I have not modified the filter to roll-off the inversion at high frequency as LLO expects we need to do (LHO aLOG 20665), because this would require a refitting of polls and zeros.

Finally, the delightful details of configuration control:
- I've loaded the entire filter file of the H1CALCS front-end model, such that we have a nice pretty string EPICs record that records the time at which the filter file was loaded (2015 Sep 20 15:41:39 PDT).
- I have *not* commit the 
/opt/rtcds/lho/h1/chans/H1CALCS.txt -> /opt/rtcds/userapps/release/cal/h1/filterfiles/H1CALCS.txt
foton file to the userapps repo, because -- also as far as I know -- Dave Barker still has possession of this file because he wants to gradually commit the file in increments based on the contents of the filter archive. This is motivated by the flurry of activity during the calibration period in which we had several changes (see LHO aLOG 21513) which were not committed.
- I've turned on FM5
- I've accepted the change in the OBSERVE.snap SDF table, which showed the difference from (previous) nominal configuration.
- I've switched tables to the SAFE.snap SDF table, which also showed the difference, and accepted the change.
- I've commit both files describing the change to the userapps repo:
/opt/rtcds/userapps/release/cal/h1/burtfiles/h1calcs_OBSERVE.snap
/opt/rtcds/userapps/release/cal/h1/burtfiles/h1calcs_safe.snap

I've uploaded the new CAL-CS filter file, in case the hardware injection vetting team (HWINJVT) needs it. ( There's a 23-point scrabble acronym for ya. (-; )
Images attached to this report
Non-image files attached to this report
H1 General
travis.sadecki@LIGO.ORG - posted 16:03, Sunday 20 September 2015 (21705)
OPS Day shift summary

Title: 9/20 Day Shift 15:00-23:00 UTC (8:00-16:00 PST).  All times in UTC.

State of H1: Lock Acquisition

Shift Summary:  Locked for all but the last hour of my shift.  Several ETMy saturations throughout the shift.  I ran through initial alignment after lock was lost.  Winds are highish.  During the unlocked period, I changed the ALS-Y_WFS_DOF3 GAINs back to their old values (and accepted them in SDF) per Evan's advice.

Incoming operator: TJ

Activity log:

22:27 Started initial alignment

23:00 Initial alignment complete, lock acquistion, hand over to TJ.

LHO General
thomas.shaffer@LIGO.ORG - posted 16:02, Sunday 20 September 2015 (21704)
Ops Eve Shift Transition

Title: 9/20 Eve Shift 23:00-7:00 UTC (16:00-0:00 PDT). All time posted in UTC.

State of H1: Relocking

Outgoing Operator: Travis S.

Summary: Lost lock about an hour ago, seems to be consistant with the rising wind speeds (35mph gusts right now). Forcast says the wind should begin to die down at 19:00PST, but I will keep trying to lock it in the mean time.

H1 General
travis.sadecki@LIGO.ORG - posted 15:10, Sunday 20 September 2015 - last comment - 18:41, Sunday 20 September 2015(21702)
Lockloss

Lockloss @ 22:05 UTC.  ITMx saturation coincides with time, but ASC Yaw loops have been ringing up for hours (due to wind increasing?). Winds are now low to mid 20 mph with gust to mid 30s. 

On the bright side, we have a new record lock stretch at almost 28 hours.

Comments related to this report
alan.weinstein@LIGO.ORG - 18:41, Sunday 20 September 2015 (21710)

I'm looking for the "Like" or "+1" button.

H1 SUS
keith.riles@LIGO.ORG - posted 13:35, Sunday 20 September 2015 - last comment - 09:42, Wednesday 23 September 2015(21696)
Pair of lines near 41 Hz
It was noted recently elsewhere that there are a pair of lines in DARM near 41 Hz
that may be the roll modes of triplet suspensions. In particular, there is
a prediction of 40.369 Hz for the roll mode labeled ModeR3.

Attached is a zoom of displacement spectrum in that band from 50 hours of early 
ER8 data. Since one naively expects a bounce mode at 1/sqrt(2) of the roll mode,
also attached is a zoom of that region for which the evidence of
bounce modes seems weak. The visible lines are much narrower,
and one coincides with an integer frequency.

For completeness, I also looked at various potential subharmonics  and harmonics
of these lines, in case the 41-Hz pair come from some other source with non-linear coupling. 
The only ones that appeared at all plausible were at about 2/3 of 41 Hz.

Specifically, the peaks at 40.9365 and 41.0127 Hz have potential 2/3 partners at
27.4170 and 27.5025 Hz (ratios: 0.6697 and 0.6706) -- see 3rd attachment. The 
non-equality of the ratios with 0.6667 is not necessarily inconsistent with a harmonic
relation, since we've seen that quad suspension violin modes do not follow a strict harmonic 
progression, and triplets are almost as complicated as quads. On the other hand, I do not see
any evidence at all for the 4th or 5th harmonics in the data set, despite the comparable strain
strengths seen for the putative 2nd and 3rd harmonics. 

Notes:
* The frequency ranges of the three plots are chosen so that the two peaks would
appear in the same physical locations in the graphs if the nominal sqrt(2) and 2/3 relations were exact..
* There is another, smaller peak of comparable width between the two peaks near 27 Hz,
which may be another mechanical resonance.
* The 27.5025-Hz line has a width that encompasses a 25.5000-hz line that is part of a
1-Hz comb with a 0.5-Hz offset reported previously.
Images attached to this report
Comments related to this report
nelson.christensen@LIGO.ORG - 14:09, Sunday 20 September 2015 (21698)DetChar, PEM
We are looking for the source of the 41 Hz noise lines. 
We used the coherence tool results for a week of ER8, with 1 mHz resolution:
https://ldas-jobs.ligo-wa.caltech.edu/~eric.coughlin/ER7/LineSearch/H1_COH_1123891217_1124582417_SHORT_1_webpage/
and as a guide looked at the structure of the 41 Hz noise, as seen in the PSD posted above by Keith.
Michael Coughlin then ran the tool that plots coherence vs channels, 
https://ldas-jobs.ligo-wa.caltech.edu/~mcoughlin/LineSearch/bokeh_coh/output/output-pcmesh-40_41.png
and made the following observations

Please see below. I would take a look at the MAGs listed, they only seem to be spiking at these frequencies.
The channels that spike just below 40.95:
 H1:SUS-ETMY_L3_MASTER_OUT_UR_DQ
 H1:SUS-ETMY_L3_MASTER_OUT_UL_DQ
 H1:SUS-ETMY_L3_MASTER_OUT_LR_DQ
 H1:SUS-ETMY_L3_MASTER_OUT_LL_DQ
 H1:SUS-ETMY_L2_NOISEMON_UR_DQ
 H1:SUS-ETMY_L2_NOISEMON_UL_DQ
 H1:PEM-CS_MAG_EBAY_SUSRACK_Z_DQ
 H1:PEM-CS_MAG_EBAY_SUSRACK_Y_DQ
 H1:PEM-CS_MAG_EBAY_SUSRACK_X_DQ

The channels that spike just above 41.0 are:

 H1:SUS-ITMY_L2_NOISEMON_UR_DQ
 H1:SUS-ITMY_L2_NOISEMON_UL_DQ
 H1:SUS-ITMY_L2_NOISEMON_LR_DQ
 H1:SUS-ITMY_L2_NOISEMON_LL_DQ
 H1:SUS-ITMX_L2_NOISEMON_UR_DQ
 H1:SUS-ITMX_L2_NOISEMON_UL_DQ
 H1:SUS-ITMX_L2_NOISEMON_LR_DQ
 H1:SUS-ITMX_L2_NOISEMON_LL_DQ
 H1:SUS-ETMY_L3_MASTER_OUT_UR_DQ
 H1:SUS-ETMY_L3_MASTER_OUT_UL_DQ
 H1:SUS-ETMY_L3_MASTER_OUT_LR_DQ
 H1:SUS-ETMY_L3_MASTER_OUT_LL_DQ
 H1:SUS-ETMY_L2_NOISEMON_UR_DQ
 H1:SUS-ETMY_L2_NOISEMON_UL_DQ
 H1:SUS-ETMY_L2_NOISEMON_LR_DQ
 H1:SUS-ETMY_L2_NOISEMON_LL_DQ
 H1:SUS-ETMY_L1_NOISEMON_UR_DQ
 H1:SUS-ETMY_L1_NOISEMON_UL_DQ
 H1:SUS-ETMY_L1_NOISEMON_LR_DQ
 H1:SUS-ETMY_L1_MASTER_OUT_UR_DQ
 H1:SUS-ETMY_L1_MASTER_OUT_UL_DQ
 H1:SUS-ETMY_L1_MASTER_OUT_LR_DQ
 H1:SUS-ETMY_L1_MASTER_OUT_LL_DQ
 H1:SUS-ETMX_L2_NOISEMON_UR_DQ
 H1:SUS-ETMX_L2_NOISEMON_LL_DQ
 H1:PEM-EY_MAG_EBAY_SUSRACK_Z_DQ
 H1:PEM-EY_MAG_EBAY_SUSRACK_Y_DQ
 H1:PEM-EY_MAG_EBAY_SUSRACK_X_DQ
 H1:PEM-CS_MAG_LVEA_OUTPUTOPTICS
 H1:PEM-CS_MAG_LVEA_OUTPUTOPTICS_QUAD_SUM_DQ

The magnetometers do show coherence at the two spikes seen in Keith's plot. The SUS channels are also showing coherence at these frequencies, sometimes broad in structure, sometimes narrow. See the coherence plots below.

Nelson, Michael Coughlin, Eric Coughlin, Pat Meyers
 
Images attached to this comment
jeffrey.kissel@LIGO.ORG - 14:43, Sunday 20 September 2015 (21700)DetChar, PEM
Nelson, et. al

Interesting list of channels. Though they seem scattered, I can imagine a scenario where the SRM's highest roll mode frequency is still the culprit. 

All of the following channels you list are the drive signals for DARM. We're currently feeding back the DARM signal to only ETMY. So, any signal your see in the calibrated performance of the instrument, you will see here -- they are part of the DARM loop.
 H1:SUS-ETMY_L3_MASTER_OUT_UR_DQ
 H1:SUS-ETMY_L3_MASTER_OUT_UL_DQ
 H1:SUS-ETMY_L3_MASTER_OUT_LR_DQ
 H1:SUS-ETMY_L3_MASTER_OUT_LL_DQ
 H1:SUS-ETMY_L2_NOISEMON_UR_DQ
 H1:SUS-ETMY_L2_NOISEMON_UL_DQ
 H1:SUS-ETMY_L2_NOISEMON_LR_DQ
 H1:SUS-ETMY_L2_NOISEMON_LL_DQ
 H1:SUS-ETMY_L1_NOISEMON_UR_DQ
 H1:SUS-ETMY_L1_NOISEMON_UL_DQ
 H1:SUS-ETMY_L1_NOISEMON_LR_DQ
 H1:SUS-ETMY_L1_MASTER_OUT_UR_DQ
 H1:SUS-ETMY_L1_MASTER_OUT_UL_DQ
 H1:SUS-ETMY_L1_MASTER_OUT_LR_DQ
 H1:SUS-ETMY_L1_MASTER_OUT_LL_DQ

Further -- though we'd have to test this theory by measuring the coherence between, say the NoiseMon channels and these SUS rack magnetometers, I suspect these magnetometers are just sensing the requested DARM drive control signal
 H1:PEM-EY_MAG_EBAY_SUSRACK_Z_DQ
 H1:PEM-EY_MAG_EBAY_SUSRACK_Y_DQ
 H1:PEM-EY_MAG_EBAY_SUSRACK_X_DQ

Now comes the harder part. Why the are ITMs and corner station magnetometers firing off? The answer: SRCL feed-forward / subtraction from DARM and perhaps even angular control signals. Recall that the QUAD's electronics chains are identical, in construction and probably in emission of magnetic radiation.   
 H1:PEM-CS_MAG_EBAY_SUSRACK_Z_DQ
 H1:PEM-CS_MAG_EBAY_SUSRACK_Y_DQ
 H1:PEM-CS_MAG_EBAY_SUSRACK_X_DQ
sound like they're in the same location for the ITMs as the EY magnetometer for the ETMs. We push SRCL feed-forward to the ITMs, and SRM is involved in SRCL, and also there is residual SRCL to DARM coupling left-over from the imperfect subtraction. That undoubtedly means that the ~41 [Hz] mode of the SRM will show up in DARM, SRCL, the ETMs and the ITMs. Also, since the error signal / IFO light for the arm cavity (DARM, CARM -- SOFT and HARD) angular control DOFs have to pass through HSTSs as they come out of the IFO (namely SRM and SR2 -- the same SUS involved in SRCL motion), they're also potentially exposed to this HSTS resonance. We feed arm cavity ASC control signal to all four test masses.

That would also explain why the coil driver monitor signals show up on your list:
 H1:SUS-ITMY_L2_NOISEMON_UR_DQ
 H1:SUS-ITMY_L2_NOISEMON_UL_DQ
 H1:SUS-ITMY_L2_NOISEMON_LR_DQ
 H1:SUS-ITMY_L2_NOISEMON_LL_DQ
 H1:SUS-ITMX_L2_NOISEMON_UR_DQ
 H1:SUS-ITMX_L2_NOISEMON_UL_DQ
 H1:SUS-ITMX_L2_NOISEMON_LR_DQ
 H1:SUS-ITMX_L2_NOISEMON_LL_DQ

The 41 Hz showing up in
 H1:SUS-ETMX_L2_NOISEMON_UR_DQ
 H1:SUS-ETMX_L2_NOISEMON_LL_DQ
(and not in the L3 or L1 stage) also is supported by the ASC control signal theory -- we only feed ASC to the L2 stage, and there is no LSC (i.e. DARM) request to ETMX (which we *would* spread among the three L3, L2, and L1 stages.). Also note that there's a whole integration issue about how these noise monitor signals are untrustworthy (see Integration Issue #9), and the ETMX noise mons have not been cleared as "OK," and in fact have been called out explicitly for their suspicious behavior in LHO aLOG 17890

I'm not sure where this magnetometer lives:
 H1:PEM-CS_MAG_LVEA_OUTPUTOPTICS
 H1:PEM-CS_MAG_LVEA_OUTPUTOPTICS_QUAD_SUM_DQ
but it's clear from the channel names that these is just two different versions of the same magnetometer.

I'm surprised that other calibrated LSC channels like
H1:CAL-CS_PRCL_DQ
H1:CAL-CS_PRCL_DQ
H1:CAL-CS_PRCL_DQ
don't show up on your list. I'm staring at the running ASD of these channels on the wall and there's a line at 41 [Hz] that in both the reference trace and the current live trace (though, because PRCL, SRCL, and MICH all light that bounces off of HSTSs, I suspect that you might find slightly different frequencies in each).

"I see your blind list of channels that couple, and raise you a plausible coupling mechanism that explains them all. How good is your hand?!"
keith.riles@LIGO.ORG - 14:42, Sunday 20 September 2015 (21701)
I neglected to state explicitly that the spectra I posted are taken
from non-overlapped Hann-windowed 30-minute SFTs,
hence with bins 0.5556 mHz wide and BW of about 0.83 mHz.
keith.riles@LIGO.ORG - 19:01, Sunday 20 September 2015 (21711)
Attached are close-in zooms of  the bands around 41 Hz peaks,
from the ER8 50-hour data integration, allowing an estimate of 
their Q's (request from Peter F). 

For the peak at about 40.9365 Hz, one has:
FWHM ~ 0.0057 Hz
-> Q = 40.94/.0057 = 7,200

For the peak at about 41.0127 Hz, one has:
FWHM ~ 0.0035 Hz
-> Q = 41.01/0.0035 = 12,000

Also attached are zooms and close-in zooms for the peak at 41.9365 Hz
from 145 hours of ER7 data when the noise floor and the peak were
both higher. The 41.0127-Hz peak is not visible in this data set integration.

In the ER7 data set, one has for 41.9365 Hz:
FWHM ~  0.0049 Hz
-> Q = 40.94/0.0049 = 8,400

Peter expected Q's as high as 4000-5000 and no lower than 2000 for
a triplet suspension. These numbers are high enough to qualify.

Images attached to this comment
keith.riles@LIGO.ORG - 19:35, Sunday 20 September 2015 (21717)
Andy Lundgren pointed out that there is a line at about 28.2 Hz that 
might be close enough to 40.9365/sqrt(2) = 28.95 Hz to qualify as
the bounce-mode counterpart to the suspected roll mode.

So I've checked its Q in the 50-hour ER8 set and the 145-hour ER7 set
and am starting to think Andy's suspicion is correct (see attached spectra).
I get Q's of about 9400 for ER and 8600 for ER7, where the line in 
ER7 is much higher than in ER8, mimicking what is seen at 41 Hz.
Images attached to this comment
nelson.christensen@LIGO.ORG - 07:38, Monday 21 September 2015 (21727)DetChar, PEM
In an email Gabriele Vajente has stated, "...the noise might be correlated to PRCL." There is a coherence spike between h(t) and H1:LSC-PRCL_OUT_DQ at 40.936 Hz. Here is the coherence for a week in ER8.
Images attached to this comment
norna.robertson@LIGO.ORG - 09:04, Monday 21 September 2015 (21731)DetChar, SUS
Peter F asked if Q of ~ 10,000 for bounce and roll modes was plausible.

Answer is yes. We have evidence that the material loss can at least a factor of 2 better than 2e-4 - e.g. see our paper (due to be published soon in Rev Sci Instrum,) P1400229, where we got an average 1.1 x 10^-4 loss for music wire. Q = 1/loss.
stuart.aston@LIGO.ORG - 10:53, Monday 21 September 2015 (21738)
[Stuart A, Jeff K, Norna R]

After having looked through acceptance measurements, taken in-chamber (Phase 3), for all H1 HSTSs, it should be noted that our focus was on the lower frequency modes of the suspensions, so we have little data to refine the estimates of the individual mode frequencies for each suspension.

No vertical (modeV3 at ~27.3201 Hz) or roll (modeR3 at ~40.369 Hz) modes are present in the M1-M1 (top-to-top) stage TFs of the suspensions.

Some hints of modes can be observed in M2-M2 and M3-3 TFs (see attached below), as follows:-

1) M2-M2, all DOFs suffer from poor coherence above 20 Hz. However, there are some high Q features that stand out in the L DOF for SRM, at frequencies of 27.46 Hz and 40.88 Hz. In Pitch, there is a high Q feature at 27.38 Hz for PR2. In Yaw, a feature at 40.81 Hz is just visible for MC1.

2) M3-M3, again all DOFs suffer very poor coherence above 20 Hz. However, a feature can be seen standing above the noise at 26.7 Hz for MC2 in the L DOF. Also, a small peak is present at 40.92 Hz for SR2 in the Yaw DOF.
Non-image files attached to this comment
brett.shapiro@LIGO.ORG - 14:53, Monday 21 September 2015 (21741)
I had a look through the SVN data for the individual OSEMs on M2 of PR2 and PRM at both LHO and LLO because Gabriele suggested the power recycling cavity might be involved.
I also looked at SR2 and SRM on Peter's suggestion.
 
I found all the roll modes and most of the bounce modes for these.
 
SUS           Bounce (Hz)        Roll (Hz)
 
H1 PR2      27.41                    40.93
H1 PRM     27.59                    40.88
H1 SR2      27.51                    40.91
H1 SRM     27.45                    40.87
L1 PR2        ----                       40.88
L1 PRM     27.48                     40.70
L1 SR2      27.52                       ----
L1 SRM     27.51                     40.88
 
I found all these in the M2 to M2 TFs in the …SAGM2/Data directories on the SVN. Screenshots of the DTT sessions are attached. You can see the relevant file names where I found the modes in these screenshots (L1 PRM bounce came from the M2 Pitch to M2 LR transfer function, not shown in the screenshot).
 
The error bar on these frequencies is about +-0.01 Hz, due to the 0.01 Hz resolution of the measurements.
 
For reference, the HSTS matlab model given by the hstsopt_metal.m parameter file in (SusSVN)/sus/trunk/Common/MatlabTools/TripleModel_Production
gives the bounce and roll modes as respectively
 
27.32 Hz and 40.37 Hz 
 
 
Brett
Images attached to this comment
sheila.dwyer@LIGO.ORG - 20:27, Monday 21 September 2015 (21765)

We currently don't have any bandstops for these modes on the tripples, except for in the top stage length path to SRM and PRM.  It would not impact our ASC loops to add bandstops to the P+Y input on all triples.  We will do this next time we have a chance to put some changes in.  

brett.shapiro@LIGO.ORG - 17:05, Tuesday 22 September 2015 (21808)

Ryan Derosa mentioned that he took some low resolution measurements that include an L1 SR2 roll mode at 41.0 Hz.

I have now looked at the data for all the MCs, to complement the PRs and SRs above in log 21741. Screenshots of the data are attached, a list of the modes found are below.

H1

SUS    bounce (Hz)      roll (Hz)

MC1      27.38                40.81

MC2      27.75                40.91

MC3      27.43?              40.84

 

L1

SUS    bounce (Hz)      roll (Hz)

MC1      27.55?              40.86

MC2        ---                   40.875

MC3      27.53                40.77

 

Error bars of +- 0.01 Hz.

I am not sure about the bounce modes for H1 MC3 and L1 MC1 since the peaks are pretty small. I couldn't find any data on L1 MC2 showing a bounce mode.

Images attached to this comment
patrick.meyers@LIGO.ORG - 09:42, Wednesday 23 September 2015 (21841)DetChar

Expanding the channel list to include all channels in the detchar O1 channel list:

https://wiki.ligo.org/DetChar/O1DetCharChannels

I ran a coherence study for a half our of data towards the end of ER8.

I see particularly high coherence at 40.93Hz in many channels in LSC, OMC, ITM suspensions, and also a suspension for PR2. It seems to me like this particularly strong line is probably due to PR2 based on these results, Keith's ASDs, and Brett's measurements, and it seems to be very highly coherent.

Full results with coherence matrices and data used to create them (color = coherence, x axis = frequency, y axis = channels) broken down roughly by subsystem can be found here:

https://ldas-jobs.ligo-wa.caltech.edu/~meyers/coherence_matrices/1126258560-1801/bounce_roll4.html

Attached are several individual coherence spectra that lit up the coherence matrices with the frequency of maximum coherence in that range picked out.

-Pat

Images attached to this comment
H1 PEM (DetChar)
jeffrey.kissel@LIGO.ORG - posted 12:50, Sunday 20 September 2015 - last comment - 20:39, Sunday 20 September 2015(21694)
Music turned on in Control Room at 19:36:30 UTC
J. Kissel, E. King, M. Oliver, T. Sadecki

Unsure where Robert and Nutsinee left us off on whether we could enjoy our Sunday afternoon in the control room (LHO aLOG 21180), I figure I'd log that we've turned on music using the "big" speaker in the control room at a medium to light volume (max volume from my laptop, bass and treble roughly in the middle of the range, just a hair under the first volume tick of the "line in" port). We're listening to Lake Street Dive's two albums "Bad Self Portraits," and "Lake Street Dive;" some relaxing Sunday modern pop folk rock, with a hint of 60s motown and some southern flare. Track one of Bad Self Portraits started at 19:36:30 UTC, (12:36:30 PDT).
Comments related to this report
nutsinee.kijbunchoo@LIGO.ORG - 13:59, Sunday 20 September 2015 (21697)

The bass-heavy one showed up on a microphone but no evidence of it coupled into DARM. Enjoy the music =)

jeffrey.kissel@LIGO.ORG - 14:10, Sunday 20 September 2015 (21699)DetChar
By "the bass heavy one," I believe Nutsinee is referring to the song that was using *during* the PEM injections (Underworld's "Sola Sistem"), *not* what we're listening to now.

P.S. we've now switched artists -- at around 20:45 UTC, we switched to listening through Hiatus Kaiyote's "Chose Your Weapon." A little bit more bass heavy, neo soul / R&B, with Jazz influences. Volume and Bass settings are the same.
jeffrey.kissel@LIGO.ORG - 20:39, Sunday 20 September 2015 (21719)DetChar
Music has been turned OFF at 03:38 UTC. (Or at least mine).
Displaying reports 56881-56900 of 78036.Go to page Start 2841 2842 2843 2844 2845 2846 2847 2848 2849 End