Displaying reports 57141-57160 of 78025.Go to page Start 2854 2855 2856 2857 2858 2859 2860 2861 2862 End
Reports until 14:57, Saturday 12 September 2015
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 General
jim.warner@LIGO.ORG - posted 12:35, Saturday 12 September 2015 - last comment - 12:17, Wednesday 16 September 2015(21433)
Mid shift summary

Things were quiet. Then Stefan arrived, and I realized I had set the observatory mode but forgot the Intent Bit, and which spiraled into a bunch SDF differences. The LSC guardian showed a difference on a t-ramp (annoying that this kind of difference would keep us from going into Observe) and ASC had two diffs that I guess Evan logged about last night but didn't accept. Then Stefan went and set a bunch of ODC masks (this also would have kept us from going into observe, so also annoying) as well as tuning the whitening the IM4 QPD (which was saturating, Stefan assures me is out of loop so shouldn't affect anything). Guardian recovered from the earlier lock loss in 20 minutes (not annoying!) back to 70 mpc and it has been otherwise quiet.

Comments related to this report
jim.warner@LIGO.ORG - 13:08, Saturday 12 September 2015 (21434)

We just came out of Observe for a minute so Stefan could set more ODC bits. Service has resumed.

jameson.rollins@LIGO.ORG - 12:29, Monday 14 September 2015 (21507)

The ODC status should not affect OBSERVATION READY in any way.  If it does, then ODC is misconfigured and needs to be fixed.

betsy.weaver@LIGO.ORG - 12:17, Wednesday 16 September 2015 (21581)

SDF is unfortunately looking at all channels - including ODC mask bits.  When anyone updates the ODC masks, the SDF goes red, and you then havta accept the ODC mask channel value in SDF, or ignore it.  Again, it's a one-time thing to update these ODC values, just late in the game and not all at one time.

H1 INJ
keith.riles@LIGO.ORG - posted 12:18, Saturday 12 September 2015 (21431)
Reduced CW HW injection amplitudes for two highest-frequency pulsars
Given PeterF's recent calculations of maximum HW injection amplitude vs frequency,
it appears that the current injection amplitude for the 1991-Hz pulsar (#14) is too high and the
amplitude for the 1403-Hz pulsar (#4) is high enough to be worrisome, once we have in place an updated
inverse actuation filter for hardware injections (assuming we continue using the current injection
point, for now -- see Jeff's entry).

So I have reduced the #14 amplitude by a factor of 10 and the #4 amplitude by a factor of 2 in
the config files used by the injection machine. The next time pulsar injections are restarted,
the new amplitudes should become active. Note that I've redefined the symbolic link RELEASE
to point to a new pulsar subdirectory ER8B with the revised amplitudes.

For reference, the new maximum pulsar injection amplitudes (+ and x source polarization values,
which are summed together with sidereal-time-dependent antenna-pattern functions) are plotted in
the attached figure, along with eyeballed curves of Peter's max allowed ETM displacement amplitudes
(ESD and PCAL actuation) for frequencies higher than 100 Hz. 

The new pulsar injection parameters are given in full here.
Non-image files attached to this report
H1 General
jim.warner@LIGO.ORG - posted 10:32, Saturday 12 September 2015 - last comment - 10:45, Saturday 12 September 2015(21429)
Transition Log
  • TITLE9/12 DAY Shift:  15:00-23:00UTC (8:00-16:00PDT), all times posted in UTC

  • STATE Of H1: Shift started in Observing, range ~70mpc

  • OUTGOING OPERATOR: Cheryl was on OWL shift.

  • QUICK SUMMARY:  H1 has been locked for 12 hrs, wind and seismic quiet, noone else on site.

Comments related to this report
jim.warner@LIGO.ORG - 10:45, Saturday 12 September 2015 (21430)

Lock-loss at about 17:44 UTC. Unclear why, but range had been trending down for the last 20 minutes or so.

H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 09:37, Saturday 12 September 2015 (21428)
CDS model and DAQ restart report, Friday 11th September 2015

ER8 Day 26. No unexpected restarts. tw0 recovered from raid problem.

model restarts logged for Fri 11/Sep/2015
2015_09_11 08:45 h1tw0
2015_09_11 09:16 h1tw0

H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 09:36, Saturday 12 September 2015 (21427)
CDS model and DAQ restart report, Thursday 10th September 2015

ER8 Day 25. no unexpected restarts, working on recovering tw0.

model restarts logged for Thu 10/Sep/2015
2015_09_10 11:51 h1tw0
2015_09_10 12:35 h1tw0
2015_09_10 12:40 h1tw0
2015_09_10 12:45 h1tw0
2015_09_10 12:49 h1tw0

H1 General
cheryl.vorvick@LIGO.ORG - posted 08:01, Saturday 12 September 2015 (21426)
OPS OWL Summary:

IFO locked all shift, 4 ETMY glitches, nothing else to report.

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
H1 ISC
evan.hall@LIGO.ORG - posted 00:48, Saturday 12 September 2015 (21423)
Low-pass filtering for SR2 ASC loops

Since turning up the bandwidth of the AS_C → SR2 loops, we had not engaged cutoff filters. There are now 18 Hz elliptic LPFs installed for both pitch and yaw. They are turned on the ISC LOCK guardian just after the final gain increase of the yaw loop.

LHO General
corey.gray@LIGO.ORG - posted 00:16, Saturday 12 September 2015 (21416)
EVE Ops Summary

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

SUPPORT:  Evan helped me out with a question.  Others were here working throughout the night.

SHIFT SUMMARY:  

H1 at LOW_NOMINAL_NOISE for most of the shift (~43min of locking after a lockloss), and was in Commissioning for much of that time.  Range hovered around 75-80Mpc.  A couple of Mexico aftershocks barely registered here.  Other than that a fairly quiet night.  

OPERATOR OPEN ITEMS:  

INCOMING OPERATOR:  Cheryl

SHIFT ACTIVITIES:

H1 INJ (CAL, ISC)
jeffrey.kissel@LIGO.ORG - posted 00:06, Saturday 12 September 2015 - last comment - 08:00, Saturday 12 September 2015(21419)
Designing the Inverse to the latest ER8 DARM Actuation Function for Hardware Injections Will Be Even Harder Than I Thought...
J. Kissel, D. Tuyenbayev

Although the jury is still out as to what accuracy we need for the start of O1, I've pushed forward with the plan to design an inverse actuation filter that removes the notches from the test mass stage of actuation, as discussed yesterday (LHO aLOG 21379). In doing so, I've plotted the total DARM actuation function for the first time since (a) we've an updated knowledge each stages' the actuation strength (LHO aLOG 21280), and (b) since the hierarchy filters were changed to reduce the impact of the wide-band impact of PUM violin mode resonances (LHO aLOG 20143). 

Regrettably, just like in ER7 (see pg 7 of G1500750), I've discovered that the PUM/L2 interaction with the TST/L3 stage is still very ugly, if not worse than it was. This means that even after taking out the notches in the TST/L3 stage and softening the Q of the TST/L3, 950 [Hz] L3 elliptic filter, there remains very complicated, 30%, 15 [deg] wiggles in the 100 [Hz] to 1000 [Hz] band that would require a great deal of poles and zeros to get correct.

I've found poles and zeros that could be used for a first cut filter, but it really does not do the full actuation function any justice, and is not worth installing. Matt Evans has suggested that he will give it a go tomorrow, but I really think this accelerates the need to inject hardware injections in a different place (the two options being PCAL and further upstream in the SUS actuation chain -- both of which have no notches or elliptic filters or anything complicated to invert). Either that, or we do an honest job cleaning up and rolling off the PUM with a sensible design, which means a significant change to the calibration and impact of the robustness of the IFO operation. Yes, it's just updating digital filters in the front end, but it would be a day or so of model parameter set development, coupled with verification against an open loop gain measurement, and testing whether the IFO was still stable. Kiwamu, Peter, Rick, and I are leaning towards the PCAL option, but we don't yet know what impact this will have on the hardware injection software infrastructure. 

As usual, Stay tuned. 
#NoSleepTilO1

The full story
--------------

Each page of the first pdf attachment walks you through the story of how I've attempted to go about this.

Just like before the H1 Mini-run and ER7, I've gone into the creation of this filter assuming that below the ~30 [Hz] PUM / TST cross-over frequency the PUM is the PUM stage, and above the TST is the TST stage. As such, I think "I should be able to create a simple set of poles and zeroes that roughly rise the shape of f^2, that I can roll off at high frequency, that may have a few poles and zeroes worth of complication. Certaintly something I can fit into one filter module of 10 second-order-sections. This way I don't have to deal with complicated, often buggy, fitting functions like vectfit or liso, nor with matlab-to-foton filter loading functions that are prone to errors / mistakes like autoquack. Plus I'll truely understand what I'm installing, and I can keep track of the systematic error all along the way." 

As such, I started the project as planned: take out the notches from the L3 stage, and reduce the Q of the elliptic filter. 
Pg 1 shows the progression as I reduce the complexity of the TST / L3 stage actuation authority. Blue is the full L3 actuation function, as taken directly from the canonical DARM model LHO aLOG 21386. Green is that same model, with the notches removed. Red is the same model, notches removed, and with the Q of the elliptic reduced from essentially infinity to 30.

Pg 2 shows the detail of the tailoring of the elliptic filter.

Great! This'll be nice and easy to invert.

So, I shoved the newly modified L3 / TST stage into the entire actuation function -- and I see a whole bunch of wiggles between 100 and 1000 [Hz] that are just not a part of the L3 / TST actuation (as seen on pg 1).

After quintuple checking for bugs, I plotted the decomposition of the total actuation function into all stages. This is pg 4. One can immediately see from this that there are interactions between the PUM and TST stage well-above the PUM / TST cross-over frequency. YUCK.

After digging around a little bit, I take a look at the filters that have been installed when the control authority was "reduced" in LHO aLOG 20143. I see that not only was the PUM *not* rolled off better, but the notches and elliptic filters that were put in place *instead* of just softly rolling off the stage better are just rediculous. Bode plots of the PUM notch filters and elliptic filters are shown in the second attachment for proof. 

Finally, just so I could demonstrate how a simple, 10-pole, 10-zero fit just would in no way be able to reproduce this actuation function, I put together such a function and caluculated the residuals. Pg 5 and 6 (back to the first attachment) show these residuals.

----------
The analysis script that generated these plots and the filter are here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/InvActuation/generate_invactuation_filter_ER8.m

The model and parameter file to generate the full actuation function live here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/DARMOLGTFs/
H1DARMOLGTFmodel_ER8.m
H1DARMparams_1125963332.m

The filter file that contains the digital filters in the SUS chain lives here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Common/H1CalFilterArchive/h1susetmy/H1SUSETMY_1124818267.txt

I attach the filter file and screenshots of all relavant filter banks here, for Matt's convenience, if he wants to waste a perfectly good Saturday.
Images attached to this report
Non-image files attached to this report
Comments related to this report
matthew.evans@LIGO.ORG - 08:00, Saturday 12 September 2015 (21425)

Comment in entry 21424

H1 General
corey.gray@LIGO.ORG - posted 21:25, Friday 11 September 2015 - last comment - 00:08, Saturday 12 September 2015(21418)
H1 Lockloss at 3:22UTC (8:22pmPST)

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

3:22 H1 lockloss.  "ITMY Saturation" on VerbalAlarm.  Terramon said a 4.5 Japan quake within a minute of this, but we don't see any seismic evidence.

I also talked with LLO (William on shift), and he said they were fighting roll modes.  When they get it back, Anamaria/Robert would like to do PEM Injections (they said it was late, so they might only wait it out a little longer).  So Evan will be opportunistic (WP5467) with H1 in the meantime.  

Comments related to this report
corey.gray@LIGO.ORG - 00:08, Saturday 12 September 2015 (21422)

Because of the pointing change to TMSX noted above, there was now an SDF Diff for the pitch offset for TMSX, so I added this channel to the Not Monitored list (NOTE:  yaw was already not-monitored, not really sure why pitch was left out).  Sounds like this is left to Operators to take care of Not Monitoring these pit/yaw biases as we go through alignments in the future (which is a bit of a rare thing nowadys with aLIGO H1). 

The more indepth story is that I had to move TMSX a little.  SDF had a setpoint value of 41.5848.  When I used conlog to get the value, it didn't list the original value, it lists the first change from the original value.  So, the first change was 41.4848, and I thought that is where I had to go to, but since SDF showed me that difference, I knew I was off by 0.1 and moved the TMSX pit to 41.5848.  But it still had a diff (an issue with decimal points between values).  So at this point, I chose to NOT MONITOR this channel.

Displaying reports 57141-57160 of 78025.Go to page Start 2854 2855 2856 2857 2858 2859 2860 2861 2862 End