Displaying reports 62041-62060 of 82999.Go to page Start 3099 3100 3101 3102 3103 3104 3105 3106 3107 End
Reports until 16:56, Monday 14 September 2015
H1 CAL (DetChar, INJ, ISC)
jeffrey.kissel@LIGO.ORG - posted 16:56, Monday 14 September 2015 (21513)
Timeline of CAL-CS Calibration Filter Updates In Detail
J. Kissel

Since updates to the CAL-CS model have been a little sporadic over the past few days, I recap below what happened when, as logged by the filter archive.
What Changed                                                                    Local Time (PDT)    Corresponding Archive of Change    Corresponding aLOG

SUS dynamical model update is complete                                          Thu Sep 10 13:50    H1CALCS_1125953445.txt             LHO aLOG 21322

Cavity pole frequency changed from 389 to 341 [Hz] (+optical gain name change)  Thu Sep 10 14:03    H1CALCS_1125954209.txt
Optical gain is renamed (no substantial change)                                 Thu Sep 10 14:03    H1CALCS_1125954234.txt   
DARM_ERR Optical gain is tuned                                                  Thu Sep 10 17:49    H1CALCS_1125967809.txt             LHO aLOG 21385

Installed inverse actuation filter                                              Sun Sep 13 22:35    H1CALCS_1126244167.txt             LHO aLOG 21487

Kiwamu changes L1 and L2 violin modes                                           Mon Sep 14 09:03    H1CALCS_1126281835.txt             LHO aLOG 21500

Copied new inverse actuation filter over to blind injection                     Mon Sep 14 09:08    H1CALCS_1126282148.txt             
Changed the names of the blind injection filter banks (no substantial change)   Mon Sep 14 09:09    H1CALCS_1126282176.txt             LHO aLOG 21499
(Note the filter files are tagged with the GPS time that they're created. so they're more accurate (to the second) than the local time I quote.)

Given that the DARM calibration was tuned at Sep 10 2015 17:49:00 PDT = Sep 11 2015 00:49:00 UTC, and Kiwamu started the PCAL to CAL-DELTAL_EXTERNAL transfer function at Sep 10 2015 18:08:12 PDT = Sep 11 2015 01:08:12 UTC, I would conlcude that 
the front-end calibration has been stable for LHO since the first lock stretch that was placed in observation mode after that measurement, which starts at 
     1125972087 = Sep 11 2015 02:01:10 UTC = Sep 10 2015 19:01:10 PDT
until the last observation stretch -- which ended at 
     1126281754 = Sep 14 2015 16:02:17 UTC = Sep 14 2015 09:02:17 PDT
-- before Kiwamu's change at Sep 14 2014 09:03:00 PDT = Sep 14 2015 16:03:00 UTC. 

I say the front end calibration has been "stable" instead of "valid" because because we know that Kiwamu's work this morning was to correct a systematic error from a bug that had been found.

We only briefly took the IFO out of observation mode (though the IFO stayed happily locked) while Kiwamu loaded new SUS filters and I the copy of inverse actuation filters. We resumed a new observation segment Sep 14 2015 16:10:43 UTC.

As noted in Kiwamu's most recent aLOG about updating the calibration this morning (LHO aLOG 21500), his update changed the UIM and PUM stages, and for features well-above the cross-over frequencies of those stages (TST/ PUM ~30-40 [Hz], PUM / UIM ~ 2 [Hz]). The update was a bug fix, and it means that the front is now more accurately representing the violin modes that were already correct in the DARM model. We all suspect this is a small change in the overall actuation function, but the recent discovery of how poorly the PUM has been rolled off (LHO aLOG 21419), means we have to verify. 

After these messages, we'll be riiiight back. *whistle glitch*

P.S. Since Matt and I performed all of our inverse actuation filter design on the original matlab model of the DARM actuation function, the inverse actuation filter design and implementation is unaffected by Kiwamu's change, nor was it impacted by the systematic error that he found.
H1 General
vernon.sandberg@LIGO.ORG - posted 16:29, Monday 14 September 2015 (21515)
Cancelation of Tuesday Maintenance Day

Mike Landry & Vern Sandberg  ER8 to O1 Transition

Cancellation of Tuesday Maintenance Day, September 15, 2015 to allow for IFO ER8-Quality data collection.

H1 General
jim.warner@LIGO.ORG - posted 16:00, Monday 14 September 2015 (21512)
Shift Summary
H1 SEI
hugh.radkins@LIGO.ORG - posted 15:49, Monday 14 September 2015 (21511)
HEPI Fluid Levels Checked--all good--no leaks--Accumulators would appear charged

Checked the Reservoir Levels this morning.  All steady; no further maintenance called for.

H1 SEI
hugh.radkins@LIGO.ORG - posted 15:25, Monday 14 September 2015 (21510)
LHO HEPI Output Drives--For Valve Condition Assessment--Seems Okay

Attached are 60 day means of the HEPI Drive outputs.  The expectation is that if we have a bad valve, this would show in a trend up or step up as the valve is failing.

Not sure about the efficacy of this manner of investigation and this 60 day look could easily be too coarse to see the needed details plus it is confused with platform trips and maybe the occasional alignment change, but for now, it looks like there is no obviously bad or failing valve. I'll continue with weekly or bi weekly shortly duration trends.  We are attempting to avoid doing the invasive Valve Check routine.

Images attached to this report
H1 INJ (INJ)
peter.shawhan@LIGO.ORG - posted 13:18, Monday 14 September 2015 (21508)
Two successful burst hardware injections this morning
From the tinj log files, and visible on https://ldas-jobs.ligo-wa.caltech.edu/~detchar/summary/day/20150914/plots/H1-ALL_893A96_ODC-1126224017-86400.png, I see that two scheduled burst injections were successful this morning.  The GPS times were 1126270500 and 1126280500.  That's good, because it seems to mean that yesterday's problem with injections was temporary.

These injections were only done at LHO; LLO was not observing at those times.
H1 DetChar (DetChar)
beverly.berger@LIGO.ORG - posted 12:53, Monday 14 September 2015 (21506)
DQ shift for 10-13 September 2015

Beverly, Jess

The full details for the shift may be found here

Images attached to this report
LHO FMCS
john.worden@LIGO.ORG - posted 10:40, Monday 14 September 2015 (21505)
Shorted vibration isolation at End stations.

Bubba and I inspected the instrument air compressors at both end stations and the corner.

The two end stations have failed vibration isolators. Bubba is checking our inventory of spares.

The corner station is in good condition - and has been mounted in a different fashion.

Attached are two photos; shorted.jpg is one of the end station units, notshorted.jpg is the corner.

Ref; https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=21436

Images attached to this report
H1 General
jim.warner@LIGO.ORG - posted 10:02, Monday 14 September 2015 (21504)
Morning meeting summary
O1 is delayed, progress is reasonable
Calibration for LHO is done
Hardware and blind injections still need work
Site Safety inspection tomorrow
H1 PSL
jim.warner@LIGO.ORG - posted 09:50, Monday 14 September 2015 (21503)
PSL Status
		Laser Status: 
SysStat is good
Front End power is 33W (should be around 30 W)
FRONTEND WATCH is GREEN
HPO WATCH is RED

PMC:
It has been locked 12 days, 23 hr 3 minutes (should be days/weeks)
Reflected power is 2.1 Watts  and PowerSum = 26.5 Watts.
(Reflected Power should be <= 10% of PowerSum)

FSS:
It has been locked for 2 h and 24 min 
TPD[V] = 1.48V (min 0.9V)

ISS:
The diffracted power is around 8% (should be 5-9%)
Last saturation event was 2 h and 51 minutes ago 

NOTES: 
H1 CAL
kiwamu.izumi@LIGO.ORG - posted 09:36, Monday 14 September 2015 - last comment - 23:46, Wednesday 21 October 2015(21500)
violin filters updated in CAL CS

WP 5489

I have update the violin mode filters in CAL CS in order to make them more accurate. This will impact on the calibration at sub-percent level at around 30 Hz.

Joe B pointed me out that the way my matlab script (alog 21322) handles violin's zpk was not ideal (i.e. I was implicitly assuming certain ordering in the zeros and poles in zpk data format). I corrected the script as was already done in Livingston (LLO alog 20512). This resulted in somewhat better accuracy for PUM in 1-100 Hz . The attached screenshots are the new filters and discrepancy between the full ss model and the installed discrete filters. Compared with the one I previously reported in alog 21322, the magnitude of PUM is now somewhat better. The magnitude of PUM at 30 Hz is now more accurate with a very small discrepancy of 0.08 % (which used to be 0.2 % discrepancy ), and it is also more accurate at 100 Hz with a small discrepancy of 0.65 % (which used to be 2.4 %). I do not expect any noticeable change in the binary range with this update.

I have installed the new filters and loaded the coefficients in CAL-CS.

Images attached to this report
Comments related to this report
kiwamu.izumi@LIGO.ORG - 23:46, Wednesday 21 October 2015 (22738)

This is a follow up on the change we made on the L1 and L2 stage violin mode filters for calibration.

 

As Andy reported in alog 22631, there had been a prominent peak at 508 Hz before the change on the violin calibration filters. This was due to the fact that both ETMY L1 and L2 stages of CAL-CS had a too high violin mode by mistake (see the original entry above) at 508 Hz. The spectral shape of the violin modes that he posted looks very similar to what we mistakenly had in CAL-CS before Sep. 14th.

I am concluding that the 508 Hz nonstationary behavior seen in the calibrated signals before Sep. 14th are indeed artifact due to too-high response in the violin calibration filters.

I made a comparison between the violin calibration filters before and after my fix on the matlab code. See the attached screenshots below:

Fig.1 L1 stage violin calibration filter. (Blue) before the bug fix, (red) after the bug fix.

Fig.2 L2 stage violin calibration filter. (Blue) before the bug fix, (red) after the bug fix.

 

It is clear in the plots that the previous filters had a high peak at 508 Hz and they were as tall as 120 dB ! Therefore the ETMY suspension calibration filters must have been unnecessarily sensitive to any small signals in DARM_CTRL before Sep. 14th. In fact, this was exactly the thing I was worried and was the main motivation to decrease the violin Qs down to 1e3 (alog 21322). Note that, according to the suspension model, the Q-factor of the violin modes can be as high as 1x109. However, we decided to artificially decrease the violin Qs for the actuator calibration filters  in order to maintain the IIR filters reasonably stable. Otherwise, the modes would be easily rung up by numerical precision errors, a small step in the actual signal or anything.

I also attach the difference of the filters in zpk formt. See the third and fourth attachements. Since their violin Qs are chopped off to be 1e3, both L1 and L2 stages have the same frequency response.

Images attached to this comment
H1 General
jim.warner@LIGO.ORG - posted 09:25, Monday 14 September 2015 - last comment - 09:37, Monday 14 September 2015(21501)
Intent bit set to commissioning for preventative maintenance

Bubba and John want to drive down the Xarm, so I've taken the IFO to commissioning/maintenance. Otherwise, no work is currently being done on the instrument.

Comments related to this report
jim.warner@LIGO.ORG - 09:37, Monday 14 September 2015 (21502)

Hugh is also going to both ends to check HEPI fluid levels. Should be non-invasive.

H1 General
nutsinee.kijbunchoo@LIGO.ORG - posted 08:00, Monday 14 September 2015 (21497)
Owl Shift Summary
H1 INJ (CAL, ISC, SUS)
jeffrey.kissel@LIGO.ORG - posted 00:21, Monday 14 September 2015 - last comment - 09:12, Monday 14 September 2015(21487)
Inverse Actuation Filter Installed; A Challenge -- and yet another reason to Switch to PCAL
J. Kissel, M. Evans

After downloading the work that Matt has done (LHO aLOG 21424)carefully fitting the nasty actuation function we'd discovered (LHO aLOG 21419), 
1) I've plotted it myself, to make sure I understand what Matt has given me
2) Inverted it, made sure I got the same residuals he did
3) Discovered the fit contained a pole at 15 [kHz], played around with the implications of moving the pole to the highest frequency foton accepts (8190 [Hz])
4) Painstakingly copied over to foton, because the fit poles and zeros did not all fit into one filter bank, and *I* wanted to control how they were divided between banks
5) Exported the foton filter, loaded it back into matlab, and fine tuned the necessary advance.

T'was a lot of work, but we have something installed and running. Now we beat the heck out of it to find the bugs, while we (in parallel) push injection through the photon calibrator forward.

In addition to this pain-in-the-tuckus inversion process, Joe Betz -- on the phone for other reasons -- brought up another excellent point: LHO does NOT use linearization on the H1SUSETMY electrostatic drive. While we get away with doing so during a quiescent lock, any loud control signal will expose the non-linearity (quadratic) nature of the ESD. We think we've already seen some evidence of this while measuring DARM open loop gain transfer functions. Yuck. PCAL has no such problems (in fact, though it uses an inherently quadratic AOM, it has analog electronics to ensure its linearity).

Note: Contrary to all of my suggestions, Matt *has* included and fit inverses to the notches in the actuation function. This means, while we will likely have the same amplification problems around the notch frequencies (see, e.g. LHO aLOG 20904), the phase reconstruction of all regions except this frequency is within 5 [deg]. Since there seemed to be competing interests in the CBC group on whether or not to include the inverse of the notches, I've left them in. If we need to remove them, and somehow retain the phase reconstruction in the surrounding frequency regain, then it'll be another day's worth of work between Matt and I. But honestly, if it comes to that, we're switching to PCAL.

%%
Details
%%
--------
Not much to say on the design here -- Matt did almost all of the work. The only two gotchas were as mentioned above: I had to move the highest fitted pole down and I must split the filter in to two parts. For the splitting, I chose to put everything from the (inverse) beam-splitter violin mode notch at ~300 [Hz] into the first module ("O1.A" in FM3), leaving the (inverse) QUAD violin notches and 950 [Hz] elliptic low-pass for the next ("O1.B" in FM4).

After exporting the product back into matlab, I tuned the timing advance to account for the pole that I'd moved down from the "ideal" fit. 
Thus, all analysis should assume the waveforms need a timing advance of 255 [us]. 
Also, of course exactly surrounding the frequencies of the notches at ~300, 500, 1000, and 1500 [Hz] there is greater than 50% mismatch between the real SUS and the inverse actuation filter. 

The first .pdf attachment shows 
(pg 1) my reproduction of Matt's filter comparsion (over a little bit wider a frequency band), 
(pg 2) the inverse function, both of Matt's ideal fit, and of the reconstruction from foton, and 
(pg 3) a zoom in on the interesting region between 100 [Hz] and 2000 [Hz].

The second .pdf attachement shows a bode plot showing the breakdown of the filter between FM3 and FM4, and compares the filter against the ER7 filter. 

Noteably, there is *not* a sign difference between the new filter and ER7 or the H1 Mini-run filter, but the phase has rotated once around the unit circle.  For a clear demonstration of this, see the third .pdf attachment. Recall, folks have been worried about the hardware injection filter since ER7 (see LHO aLOG 19948 for complete summary). I'm not sure how this ~360 [deg] rotation could be mistaken for a sign flip -- but maybe I'm just carrying around the term that was used during the initial guess of what the problem was, even though the real problem was more subtle. I've confirmed that neither the design string nor the "alternate" (i.e. as what foton interprets your design) show a minus sign in the gain.

--------
Configuration control:
(1) Stefan and I updated the ODC state vector for the hardware injections, since flipping the FMs from 2 to 3&4 make the "HARDWARE filter stated OK" light go red. To make green, we changed the recently modified bit status check from 0x1602 to 0x160c. 
(2) I accepted the new filter bank state (and ODC bit word) into both the OBSERVE.snap and into the SAFE.snap for the CAL-CS front-end model.
I attach ascreenshot of the filter bank as I've left it.
Images attached to this report
Non-image files attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 09:12, Monday 14 September 2015 (21499)CAL
J. Kissel

The above inverse actuation filter has been copied into the blind injection filter bank, and is now on and running. The new configuration has been accepted into both the OBSERVE.snap and SAFE.snap files.
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 DetChar
sheila.dwyer@LIGO.ORG - posted 20:07, Wednesday 09 September 2015 - last comment - 17:44, Monday 14 September 2015(21353)
strange non stationary spectrum

While we were in commisioing mode, we had a strange non stationary spectrum, with large non stationary noise also appearing in MICH and PRCL.  I quickly looked at some triple witness sensors, since we've had issues with these recently, but didn't see anything obvious.  

The strange noise started a few minutes before 2:50:34 UTC Sept 10, seemed to get better for a few minutes and then got worse again around 2:57:21. 

We don't think that this was related to any comissioning we were doing.  Evan had temporarily lowered the DARM ugf and put a notch in, (which should cause anything like this).  He undid both changes when we saw the unusual noise, but the noise was unaffected by his change.  

We aren't going to investigate any further right now since the problem seems to have gone away.  

Comments related to this report
sheila.dwyer@LIGO.ORG - 16:00, Monday 14 September 2015 (21514)

This is happening again.  (this time it seems worse)  It started about a half hour ago, at 22:30 UTC on Sept 14th

evan.hall@LIGO.ORG - 17:12, Monday 14 September 2015 (21517)

We ran a bruco on 5 minutes of this excessively noisy period (2015-09-14 22:55:00). Results here.

From 10 Hz to 1 kHz, most of the LSC and ASC signals are coherent with DARM, so it's hard to say what's going on here.

Above 1 kHz, there is some coherence with the RFAM monitor on the EOM driver. A series of spectra are attached showing elevated RIN in this monitor, compared to a quiet period roughly 30 minutes later. What mechanism could cause this? Also included are spectra of the LSC magnetometer in the CER, since this also showed elevated coherence.

Images attached to this comment
keita.kawabe@LIGO.ORG - 17:44, Monday 14 September 2015 (21518)

RF45 AM stabilization looks fishy.

Look at feedback signal (Ch3) VS the range. They're in sync today (left) as well as back on 10th of Sept. (right).

Images attached to this comment
H1 ISC (ISC)
daniel.hoak@LIGO.ORG - posted 04:07, Saturday 05 September 2015 - last comment - 13:27, Monday 14 September 2015(21234)
Input beam jitter coupling to DARM

Dan, Evan

This evening we made a qualitative study of the coupling of beam jitter before the IMC into DARM.  This is going to need more attention, but it looks like the quiescent noise level may be as high as 10% of the DARM noise floor around 200Hz.  While we don't yet understand the coupling mechanism, this might explain some of the excess noise between 100-200Hz in the latest noise budget.

We drove IMC-PZT with white noise in pitch, and then yaw.  The amplitude was chosen to raise the broadband noise measured by IMC-WFS_A_I_{PIT,YAW} to approximately 10x the quiescent noise floor.  This isn't a pure out-of-loop sensor, and since we were driving the control point of the DOF3 and DOF5 loops of the IMC alignment channels we will need to work out the loop suppression to get an idea of how much input beam motion was being generated.  Unfortunately we don't have a true out-of-loop sensor of alignment before the IMC.  We may try this test again with the loops off, or the gain reduced, or calibrate the motion using the IMC WFS dc channels with the IMC unlocked.  Recall that Keita has commissioned the DOF5 YAW loop to suppress the intensity noise around 300Hz.

The two attached plots show the coherence between the excitation channel (PIT or YAW) and various interferometer channels.  The coupling from YAW is much worse: at 200Hz, an excitation 10x larger than normal noise (we think) generates coherence around 0.6, so the quiescent level could generate a few percent of the DARM noise.  Looking at these plots has us pretty stumped.  How does input beam jitter couple into DARM?  If it's jitter --> intensity noise, why isn't it coherent with something like REFL_A_LF or POP_A_LF (not shown, but zero)? 

The third plot is a comparison of various channels with the excitation on (red) and off (blue).  Note the DCPD sum in the upper right corner.  Will have to think more about this after getting some slpee.

Images attached to this report
Comments related to this report
keita.kawabe@LIGO.ORG - 08:43, Tuesday 08 September 2015 (21290)

Transfer function please.

evan.hall@LIGO.ORG - 12:04, Tuesday 08 September 2015 (21294)

TFs of the yaw measurement attached.

If the WFS A error signal accurately represents the quiescent yaw jitter into the IMC, the orange TF suggests that this jitter contributes the DCPD sum at a level of 3×10−8 mA/Hz1/2 at 100 Hz, which is about a factor of 6 below the total noise.

Images attached to this comment
evan.hall@LIGO.ORG - 02:02, Friday 11 September 2015 (21393)

Using this measured WFS A yaw → DCPD sum TF, I projected the noise from WFS A onto the DARM spectrum (using data from 2015-08-27). Since the coupling TF was taken during a completely different lock stretch than the noises, this should be taken with a grain of salt. However, it gives us an idea of how significant the jitter is above 100 Hz. (Pitch has not yet been included.)

Non-image files attached to this comment
keita.kawabe@LIGO.ORG - 11:33, Friday 11 September 2015 (21402)

PIT coupling per beam rotation angle is a factor of 7.5 smaller than YAW:

https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=21212

paul.fulda@LIGO.ORG - 07:38, Monday 14 September 2015 (21496)

Re: "How does beam jitter couple to DARM?" : jitter can couple to DARM via misalignments of core optics (see https://www.osapublishing.org/ao/abstract.cfm?uri=ao-37-28-6734).

If this is the dominant coupling mechanism, you should see some coherence between a DARM BLRMS channel where this jitter noise is the dominant noise (you may need to drive jitter with white noise for this) and some of the main IFO WFS channels. 

gabriele.vajente@LIGO.ORG - 09:00, Monday 14 September 2015 (21498)

The BLRMS in the input beam jitter region (300-400 Hz) is remarkably stable over each lock (see my entry here), so there seems to be no clear correlation with residual motion of any IFO angular control.

paul.fulda@LIGO.ORG - 13:27, Monday 14 September 2015 (21509)

Thanks for the link to that post, I hadn't seen it. It may still be possible though that there's some alignment offset in the main IFO that couples the jitter to DARM (i.e. a DC offset that is large compared to residual motion – perhaps caused by mode mismatch + miscentering on a WFS). This could be checked by putting offsets on WFS channels and seeing how the coupling changes. 

Displaying reports 62041-62060 of 82999.Go to page Start 3099 3100 3101 3102 3103 3104 3105 3106 3107 End