Displaying reports 64561-64580 of 84555.Go to page Start 3225 3226 3227 3228 3229 3230 3231 3232 3233 End
Reports until 14:58, Friday 14 August 2015
H1 IOO (DetChar, IOO, ISC, PSL)
gabriele.vajente@LIGO.ORG - posted 14:58, Friday 14 August 2015 (20537)
Automatic tuning of IMC alignment offsets

Windy days are bad for locking, but good for other side activites. So I sat down to write a script that automatically tune the IMC aungular offsets to reduce to minimum the coupling of jitter to intensity noise. It basically follows the same procedure I performed manually earlier today. The script is attached to the elog entry. You can sae it and run it from terminal. it will open up a plot showing you the progress of the tuning. Run the script with the IMC locked, no IFO and ISS second loop open!

Here is what the script does

  1. Turn on excitations on the PSL PZT at 101 Hz (pitch) and 153 Hz (yaw). The excitation is removed when the script exits (even if you kill it with CTRL+C)
  2. Open up a window that shows you the progress of the tuning. There are three panels:
    1. Error signals for the tuning: real part of the transfer function of ISS_SECONDLOOP_SUM14 over excitations, both pitch and yaw. if the tuning is working, these two traces will be driven to zero
    2. Monitor of the band-limited RMS of ISS_SECONDLOOP_SUM14  in the 200-400 Hz region. this is where most of the PSL periscope noise sits, so if everything goes well you'll see this trace dropping down close to zero (typical values today when the alignment was good were 0.01-0.02 a.u.)
    3. Monitor of the IMC WFS offsets. The tuning acts on IMC-DOF_2_P_OFFSET and IMC-DOF_1_YAW_OFFSET, since those seem to be the most important offsets
  3. After an intiial wait of 30 seconds, the script will start servoing the error signals to zero by changing the offsets. Basically, it reduces to minimum the coupling of the two PZT angular lines to the power transmited by the IMC (as seen by the ISS array)

The script has a built in check of the IMC power, and it doesn't change any offset if the IMC is not locked. There is no check on the convergence of the error signals, but the script terminates automatically after 10 minutes, which is typically more than enough to find the right offsets. However, you can terminate the script with CTRL+C when you're satisfied withe the results. The excitations will be automatically removed.

I tested the script several times with random starting offsets, and it worked all the times.

The first attached plots show a comparison of IMC transmitted RIN before and after the script was run. The other plots show some examples of the plots generated by the script, showing the tuning in action.

Images attached to this report
Non-image files attached to this report
H1 SUS (SUS, SYS)
leonid.prokhorov@LIGO.ORG - posted 14:43, Friday 14 August 2015 (20532)
OPLEV charge measurements
Charge measurements was done on both ETMs.
It is early enough to discuss the new tendencies, but probably ETMY change the sign of charging after changing the bias sign on ETMY (see 20387).
Now (since Aug,10) both ETMX and ETMY Biases are -9.5V, 
Current results are in attachment.
Upd: Additional set of measurements was done at 12pm - 2pm (local). Windy, so the errors are large. New plots added. Script for gamma measurements debugged and tried on some of these measurements, results are not ready yet. 
Images attached to this report
H1 General
nutsinee.kijbunchoo@LIGO.ORG - posted 14:27, Friday 14 August 2015 (20536)
Its been a bit windy today

(TJ writing as Nutsinee)

 

No locking happening today so far, gusts breaching 50mph.

Getting some good windy data though!

Images attached to this report
LHO VE
bubba.gateley@LIGO.ORG - posted 14:09, Friday 14 August 2015 (20535)
Beam Tube Washing
Scott L. Ed P. Rodney H.

8/13/15
The crew cleaned 59 meters of tube and bellows ending at HSW-2-006. All support tubes on Y-2 are vacuumed and capped. The water tank was also refilled.
Today was the last day for Rodney. 

8/14/15
Scott L. Ed P.
39.8 meters of tube and bellows cleaned ending at HSW-2-004. Both men had appointments in town and left at lunch. 
LHO FMCS
bubba.gateley@LIGO.ORG - posted 12:11, Friday 14 August 2015 (20533)
Beam Tube Enclosure Joint Repair on the X-Arm
Chris S.(85%) Joe D.(60%)

Since 8/4 the guys have had various other chores, they also had to cut more metal into 10' lengths and since that date they have cleaned the existing seal joints, installed metal strips and caulked 500 meters of upper tube enclosure.

This brings the total installed to 1680 meters of enclosure on X-1. We are currently waiting on more metal to arrive. It has been ordered for 3 weeks.
H1 IOO (DetChar, IOO)
gabriele.vajente@LIGO.ORG - posted 11:32, Friday 14 August 2015 (20534)
Tuning of IMC alignment offsets

This morning I retuned the IMC alignment WFS offsets to reduce the coupling of jitter into the ISS array.

The results

I could reduce to basically zero the coherence between the PSL periscope accelerometer and the ISS second loop signal, with the IMC locked and ISS second loop open. The first plot shows that the periscope noise between 100 and 700 Hz reduced down to the background noise of the signal. The two lines at 101 and 153 Hz are respectively a PZT pitch and yaw lines I was injecting.

The new offsets are

  Old New
DOF_1_P 0 0
DOF_2_P 350 300
DOF_3_P 0 0
DOF_1_Y 200 20
DOF_2_Y 0 0
DOF_3_Y 0 0

The procedure

Here is the procedure I used to tune the offsets, in details:

  1. Inject a 101 Hz line in IMC-PZT_PIT_EXC with amplitude of 3 and a 153 Hz line in IMC-PZT_YAW_EXC with an amplitude of 3
  2. I wrote three python scripts to monitor the jitter coupling (attached to this elog). The scripts demodulate_iss_pit.py and demodulate_iss_yaw.py gives you a real time plot of the demodulated amplitude of the excitations lines in the ISS power signal. Each plot contains the real and imaginary part of the ransfer function at the line. Those traces turned out to be a wonderful signal to tune the offsets. See in the second plot how the traces go to zero when the offsets are tuned. The third script online_blrms.py gives you another real time trace of the band-limited RMS of the ISS signal in the 200 to 400 Hz, thus measuring the noise due to the jitter peaks. Notice in the second plot how the noise reduced a lot when the yaw offset was tuned.
  3. You can run the three scripts from any terminal, at the same time, and watch the traces as you change the offsets
  4. Today the yaw offset was the worst one, so I tuned it first. here is some cross coupling between yaw and pitch, so chancing the yaw offset had an effect in pitch too. With a few iterations I converged to the final values above.
Images attached to this report
Non-image files attached to this report
H1 ISC
evan.hall@LIGO.ORG - posted 10:13, Friday 14 August 2015 - last comment - 12:07, Friday 04 September 2015(20526)
Sensing noises in the OMC DCPDs

This entry is meant to survey the sensing noises of the OMC DCPDs before the EOM driver swap. However, other than the 45 MHz RFAM coupling, we have no reason to expect the couplings to change dramatically after the swap.

The DCPD sum and null data (and ISS intensity noise data) were collected from an undisturbed lock stretch on 2015-07-31.

Noise terms as follows:

The downward slope in the null at high frequencies is almost certainly some imperfect inversion of the AA filter, the uncompensated premap poles, or the downsampling filter.

Non-image files attached to this report
Comments related to this report
rana.adhikari@LIGO.ORG - 12:07, Friday 04 September 2015 (21214)

* What is the reasoning behind the updated suspension thermal noise plot?

* Its weird that cHard doesn't show up. At LLO, cHard is the dominant noise from 10-15 Hz. Its coupling is 10x less than dHard, but its sensing noise is a lot worse.

evan.hall@LIGO.ORG - 10:59, Wednesday 19 August 2015 (20680)

I remade this plot for a more recent spectrum. This includes the new EOM driver, a second stage of whitening, and dc-lowpassing on the ISS outer loop PDs.

This time I also included some displacement noises; namely, the couplings from the PRCL, MICH, and SRCL controls. Somewhat surprising is that the PRCL control noise seems to be close to the total DCPD noise from 10 to 20 Hz. [I vaguely recall that the Wipfian noise budget predicted an unexpectedly high PRCL coupling at one point, but I cannot find an alog entry supporting this.]

Non-image files attached to this comment
evan.hall@LIGO.ORG - 14:33, Friday 21 August 2015 (20758)

Here is the above plot referred to test mass displacement, along with some of our usual anticipated displacement noises. Evidently the budgeting doesn't really add up below 100 Hz, but there are still some more displacement noises that need to be added (ASC, gas, BS DAC, etc.).

Non-image files attached to this comment
evan.hall@LIGO.ORG - 16:25, Monday 24 August 2015 (20832)

Since we weren't actually in the lowest-noise quad PUM state for this measurement, the DAC noise from the PUM is higher than what is shown in the plot above.

If the updated buget (attached) is right, this means that actually there are low-frequency gains to be had from 20 to 70 Hz. There is still evidently some excess from 50 to 200 Hz.

Non-image files attached to this comment
evan.hall@LIGO.ORG - 13:04, Friday 28 August 2015 (20990)

Here is a budget for a more recent lock, with the PUM drivers in the low-noise state. The control noise couplings (PRCL, MICH, SRCL, dHard) were all remeasured for this lock configuration.

As for other ASC loops, there is some contribution from the BS loops around 30 Hz (not included in this budget). I have also looked at cHard, but I have to drive more than 100 times above the quiescient control noise in order to even begin to see anything in the DARM spectrum, so these loops do not seem to contribute in a significant way.

Also included is a plot of sensing noises (and some displacement noises from LSC) in the OMC DCPDs, along with the sum/null residual. At high frequencies, the residual seems to approach the projected 45 MHz oscillator noise (except for the high-frequency excess, which we've seen before seems to be coherent with REFL9).

Evidently there is a bit of explaining to do in the bucket...

Non-image files attached to this comment
evan.hall@LIGO.ORG - 10:06, Friday 04 September 2015 (21210)

Some corrections/modifications/additions to the above:

  • I updated the optical gain and DARM pole using the pcal like at 331.9 Hz; from this line I find the transfer function from the TX PD into DCPD sum is (1.69 − 1.59i) mA/pm, which works out to an optical gain of 3.19 mA and a DARM pole of 353 Hz. I think Kiwamu may have a different number from his pcal sweep, so there might be some reconciliation to do.
  • I now compensate the extra 10 kHz pole that Kiwamu found in the readout chain of the DCPDs.
  • I remade the quantum noise curve for 23 W, and with a more realistic estimate of the losses. In addition to the 87 % quantum efficiency, I include 14 % readout losses that Lisa has already tabulated: we expect 96.5 % transmission through the OFI, 93 % transmission through the OMC, 99% reflection from OM3, and (according to Dan) 97 % mode matching into the OMC. This results in a quantum noise curve that is 6.6×10−20 m/Hz1/2 at 1 kHz. The DARM pole predicted by GWINC is 360 Hz or so (slightly higher than what I extracted from pcal).
  • Previously, I had tuned the arm losses in GWINC to give a recycling gain of 40 W/W. In light of Sheila's analysis, this is too optimistic; usually our recycling gains are more like 36 to 37 W/W. In GWINC, this amounts to tuning the arm losses to 90 ppm (per arm), which gives a gain slightly in excess of 37 W/W.
  • The null stream is 5 % – 7 % higher than the GWINC curve, so either some parameter is mistuned or we need to be looking for some extra readout loss.
  • I replaced the GWINC suspension thermal noise curve with a (hopefully) more accurate curve that I got from Sheila.
  • I replaced the oscillator noise trace (which was flat in DCPD photocurrent) with a trace based on the TF that Stefan and I took. I still assume the underlying noise contribution is flat in RIN, at a level of 3.5×10−8 mA/Hz1/2. This trace will become less relevant since the excess oscillator noise now appears to be gone.
  • I added gas noises. Squeeze film damping was calculated after T0900582 using the nominal parameters (our end station gauges read 1×10−8 torr, and I've assumed the dominant species is molecular hydrogen). For residual gas, I again assume the species is molecular hydrogen, and the arm pressure is taken to be 5×10−9 torr (which is a rough average of the arm gauges).
  • The ASC trace contains only the dHard and BS loops. I drove in cHard, but even after driving far, far above the ambient noise floor I could not make excess noise appear in DARM.

Of course, the budgeted noises don't at all add up from 20 Hz to 200 Hz, so we are missing something big. Next we want to look at upconversion and jitter noises, as well as control noise from other ASC loops.

Non-image files attached to this comment
LHO General
thomas.shaffer@LIGO.ORG - posted 08:59, Friday 14 August 2015 (20529)
Morning Meeting Minutes

ISC: Did some good work last night, changed ASC input matrix to a, hopefully, good setting.

CDS: PEM antennas, noise on tigger signals, Vault seismometer.

PSL: PMC work on Tuesday. OpLevs currently behaving.

VAC: Today they will be driving between Y28 and X28 and dropping off things.

Fac: Beam tube cleaning ongoing, front double doors do actually lock (see Bubba if you need instructions on how to lock properly)

 

Monday is the start of ER8, there will be 3 weeks till the O1.

Week 1 - Annealing. The intent is to bring the IFO to a stable operating state.

Week 2 - Calibration. Stability, stability, stability.

Week 3 - PEM injections and commissioning cleanup.

Then if all is well at both sites, O1.

(Please see JRPC site for a more detailed and accurate schedule)

H1 General
nutsinee.kijbunchoo@LIGO.ORG - posted 08:00, Friday 14 August 2015 (20528)
Owl Shift Summary

All time in UTC

07:00 Came to find the interferometer locked.

9:30 Violin mode low enough. OMC PD whitening turned on. BNS range went up a bit.

9:41 Lock loss. Violin mode damping *accident*

10:26 Lockloss again. Not clear why.

10:42 Another lock loss. 5.0M earthquake at Northern Atlantic Ridge

13:52 Another 5.6M earthquake in New Zealand. Lock loss. Take down the ifo.

7:58 Wind speed reaching 30 mph. We are still waiting for the earthquake to settle. Mother Nature isn't happy today...

 

Other Notes:

- Trouble with violin first harmonics tonight. 991.9345 got rung up and I couldn't damp it with the setting that I knew worked just the night before. The filters are ITMY Mode9 and ITMX Mode10 (the line was identified to be ITMY, but I set the filter in ITMX too just in case). Mysterious.........

- ETMX L2 DAMP MODE10, ETMY L2 DAMP MODE3, and ETMY L2 DAMP MODE7 gains are now being turned on by Guardian.

Images attached to this report
H1 ISC
evan.hall@LIGO.ORG - posted 07:23, Friday 14 August 2015 (20527)
More DCPD whitening = more megaparsecs

Nutsinee, Sheila, Evan

Thanks to the recent work on violin mode damping, we now have periods where the modes are low enough to engage a second stage of whitening on the OMC DCPDs.

We engaged the second stage of whitening in full lock around 2015-08-14  09:25:00 Z.

This extra whitening lowers the noise in both the sum and null streams (as expected). In the null stream, the improvement is about 4%. This improvement was enough to bump up the range by 2 or 3 Mpc.

[The dc photocurrent on the DCPDs changed negligibly; A went from 9.95(10) mA to 9.90(10) mA, and B went from 10.05(10) mA to 10.10(10) mA. Also note that the very high-frequency part of the sum, where we are apparently not close to shot-noise limited, has stayed the same before and after the whitening change. So it does not seem to simply be a calibration error. See second attachment.]

The in-situ dark noise of the DCPDs (plus the preamp, whitening, and AA chains) was measured in LHO#16656.

Images attached to this report
H1 ISC
evan.hall@LIGO.ORG - posted 01:46, Friday 14 August 2015 (20524)
Excess DARM noise vs. 45 MHz modulation index

Gabriele, Sheila, Evan

Today we looked at how changing the 45 MHz modulation index changes the appearance of broadband excess noise in the DCPDs. As one should expect, this coupling goes like the square of the modulation index. With our current index, the excess of the sum over the null is about 8 %.

To be a bit more quantitative:

We tried to reduce the modulation index further, but by 4 dB it seems the interferometer will not stay locked for longer than a minute or so. While changing the modulation index we can see that the uncontrolled quadratures of the AS 36 WFS change, perhaps indicating that the error signals for the BS and SRM loops are also changing in an undesirable way.

The attachment shows the DCPD streams, along with the EOM driver RFAM readback and the IOP channel of ASC AS C segment 1. The solid traces are taken at the nominal modulation index, and the dashed traces are taken with a modulation index that is 3 dB lower.

Images attached to this report
Non-image files attached to this report
H1 ISC
sheila.dwyer@LIGO.ORG - posted 00:33, Friday 14 August 2015 (20523)
recent arm ASC work

Over the last few weeks we've done some work on ARM ASC loops, mostly for the hard modes.  

We've been in the HARD soft basis for a few weeks (19752 19775).  Changing to HARD/SOFT was didn't seem to have negative consequences for us, we don't think that it changed our A2L decoupling much. Our method tuning the coefficents before the change was not very precise, some of the coefficents are now different by up to 50%, but they were probably just not correct a few weeks ago.

In the past two weeks we have been retuning the loop shapes for the hard arm loops. There were three motivations:

DHARD retuning was fairly sucsesfull, we added boosts to both DHARD loops that seem to help our stability at high power.  Neither of these loops has a cut-off, which we need to add.  We have locked a few times without op damping, but turned them back on due to instabilities. 

We then moved on to CHARD, where we have rather bad SNR in the sensor (the sum of the REFL 9 I signals).  We had very low gain loops here (both less than 0.1 Hz) because we had previously seen that increasing the gain added noise in DARM.  We tried rephasing the refl 9 wfs by driving a line into the mode cleaner, and by driving CHARD in pitch.  (20364 and at a higher TCS power: 20368) This rephasing did seem to cause any stability problems, and could be fine tuned. We then increased the bandwidth for the CAHRD loops.  This introduced large non-stationary noise into DARM, which might have been made worse by a non-optimal alingment.  Last night we reduced the amount of non-stationary noise by reverting to our old, low gain loops (with cut offs and leads still added).  There was some remaining coherence with CHARD (non-stationary, up to 90 Hz).  Today we think that we fixed some SRC alignment issues (20519) which we think is the reason why the coherence with CHARD has been reduced.  However, we still have coherence with CHARD from time to time. 

Nominally, our next steps would be to try to find a better error signal to use for CHARD, by driving excitation in CHARD, im4, and one of the PRs to check if our input matrix can be improved. We could also think about running DC loops to TMS to create an AC coupled signal to blend with refl for CHARD. To improve the stationarity of DARM we could be more agresive with cut off filters or decrease the bandwidth more. UPDATE: Evan and I looked at the sensing matrix for refl tonight and it seems like the phasing of 45 is way off.

Open loop gain measurements:

DHARD PIT 20144  Since this measurement Evan has added a resonant gain at 0.46 Hz tonight to squash the instability we sometimes see.  

DHARD YAW 20084 no changes to this loop that I know of since the measurement. 

CHARD PIT 20497 This gain has since been reduced by 6dB, and neither of the boots are used.  

CHARD YAW 20499 Since this measurement 20 dB of gain was removed, the MS boost was removed (a gentle boost with a pair of complex zeros at 0.5 Hz that adds 25 dB at DC), a 2:3Hz lead filter was added and a 30Hz elliptic low pass was added.  

Spectra of the error and control signals are attached.  So are the control filters, CSOFT and DSOFT are the same, so only CSOFT are plotted. Obviously, the soft loops could be improved, but we haven't gotten to that yet, and aren't sure if we will. 

Images attached to this report
Non-image files attached to this report
LHO General
corey.gray@LIGO.ORG - posted 00:10, Friday 14 August 2015 (20521)
Ops EVE Summary

Times in UTC (PST)

H1 ISC
sheila.dwyer@LIGO.ORG - posted 21:29, Thursday 13 August 2015 (20519)
AS 36 sensing matrix changes with SR3 drift

Sheila, Gabriele, Elli, Evan

The message:

We think that some of the trouble we've been having with ASC could be because the sensing matrix for AS36 can change quite a lot when the alignment changes, and our DC coupled oplev servo on SR3 PIT has been introducing an alignment drift.  A drift of 0.3 urad in SR3 seems to have caused many of our headaches this week.  On the one hand it seems silly that we were not resetting the oplev offset regularly (that was my fault), but on the other hand it seems strange that a rather small misalignment can change our sensing matrix this much. 

The problems:

We've had a long history of changing the input matrix for AS36 I to SRM, rephasing AS 36 WFS .  This has seemed mysterious at times, that the matrix we need changes as we power up, and that once a month or so we have had to retune them.  

This week we have had a particularly bad time with alignment related problems.  Monday we had a temperature excursion in the PSL, and the periscope PZT lost power (20396), after this something has changed in the PMC (20490), and the spot position on IM4 trans moved.   Although we think the change was upstream of the IMs we were unable to fix it with the PZT and mode cleaner mirrors.  Yesterday we moved IM3 to bring the spot back to the same position on IM4 trans.  We've had fast locklosses within 10 minutes of powering up (20465), the pernicious 0.46 Hz instability that can be fixed by increasing DHARD PIT gain (20404), several changes of the sensing matrix for AS36 (20465 20512 20497),  huge nonstationary noise with high CHARD bandwidth, and coherence with CHARD drive signals in DARM that came and went with the non stationary noise (20497).

This morning TJ, Jim, and other operators were losing lock in the ENGAGE ASC state.  With Gabriele they traced it down to the change in the SRC matrix.  Yesterday we found that AS36 A I was the best signal to use for SRM control as we powered up, by watching all the error signals as we powered up, moving SRM to maximize build ups and choosing a signal that responded to SRM and had a zero crossing in a good location. This morning the same method of choosing an error signal indicated that we should use only AS36 B I.

 Gabriele and I saw that the signal we were using for BS control was sensitve to SRM moving.  At 3 Watts we opened both the BS and SRM loops, and found a matrix that would make the BS signal insenstive to SRM motion. 

While Gabriele and I were checking the sensing for AS36 as we increased the power, Elli noticed that SR2 and SRM witness sensors had moved between midnight UTC on August 10th and August 11th, which is approximately coincident with the start of these problems. After we lost lock, I restored SRM and SR2 pitch to their previous locations based on the witness sensors, and locked SRY, first with the DC coupled oplev on then with it off.  The spot on AS_C was off in pitch by about half a beam width, and came back to nearly centered when I turned off the DC coupling on the oplev servo.  The moves all in pitch were: SR3 -0.3 urad, SR2 +6 urad.  

After we reset the offset and relocked, the BS signal (AS B 36 I) was insensitive to SRM alingment, and the input matrix for SRM yaw that seems good is the same as what we had last week and for several weeks previous: -3 for AS A 36 I and 1 for AS B 36 I.  We have been stable throughout power up since this.  The coherence with CHARD is greatly reduced, and mostly below 20 Hz.  The spectrum  is more stationary, but we still have some non stationarity.  Gabriele looked at a spectrogram and a coherence gram, and sees that the non stationary noise in DARM no longer coresponds to times when the coherence with CHARD is high.  

Since moving SR3 we have had the 0.46 Hz instability again.  This time Evan added a ResG in DHARD P to give us some gain at that frequency (instead of increasing the FM gain which leaves us with very little phase margin).  We plan to add this to the 23Wboost filter that gets turned on when we power up. 

LHO VE
kyle.ryan@LIGO.ORG - posted 20:07, Thursday 13 August 2015 (20522)
Installed some new hardware on Beam Tube port Y2-8
Kyle, Gerardo 

Today we closed the 10" BT gate valve at Y2-8, vented and removed the isolated port volume hardware -> Next we installed the new large custom reducing tee, 8" gate valve, (2) 1.5" angle valves, 1.5" tee, 10" blank and gauge at beam tube port Y2-8 -> we also pumped out this new volume and sprayed helium on the new joints -> The next task will be to position the new ion pump and stand/director assembly and couple it to the hardware installed today
H1 SEI (SEI)
robert.schofield@LIGO.ORG - posted 19:36, Thursday 13 August 2015 (20520)
Potential ISI blade damper scheme to reduce acoustic coupling

I got a factor of 3 or so reduction in motion (Figure 1) of a test stand blade spring with a captured mass on Viton pads that attaches to the end of the blade (Figure 2). I think that further development requires a better test stand with a loaded blade spring.  The damper is made of a 3” long, 1” square steel bar on adjustable Viton pads held inside a square aluminum tube with a 1.25” inner diameter. I think this should be reasonable to install (see photo of blade spring in place, Figure 3). In my setup I use a C-clamp to attach it to the blade spring in place of a small integrated clamp like the magnet-free blade clamps designed for SUS. I suspect that the Q is higher for the real setup than for my setup, so the improvement may be better in real life.

Non-image files attached to this report
H1 CAL (CAL)
craig.cahillane@LIGO.ORG - posted 17:05, Thursday 13 August 2015 (20518)
Actuation Coefficient Measurements are Incompatible (i.e. systematic uncertainty is too high)
C. Cahillane, J. Kissel

I have taken a look at our measurements of the actuation coefficients on ETMY L3 as reported by  LHO aLOG 18767.
We have three measurements of actuation:  Free Swinging Mich, ALS DIFF VCO, and PCAL, which each have different measurement values and uncertainty bars.

The measurements were significantly different, so I looked for mathematical motivation for seeing if the weighted mean and uncertainty calculated in aLOG 18767 was meaningful.

I found a document that walks you through the basics:  Understanding Data Better with Bayesian and Global Statistical Methods by William H. Press.  The document claims that if the chi^2 value is outside the range of (N-1) +- sqrt( 2*(N-1) ) where N = number of measurements, then our measurements are incompatible and our weighted mean has no justification.

For our actuation coefficients:
chi^2 = 72.4250
acceptable range (N=3) = [0, 4]
(Calculation of the above found here: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Scripts/ETMY_L3_Actuation_Coefficient_Compatibility_Test.m )

Our chi^2 is clearly outside the acceptable range, meaning that at least one of our measurements has high systematic uncertainty that renders our weighted mean are poor estimate of the actuation coefficient.

Bayesian methods are advocated to identify the problematic measurement and appropriately quantify our actuation coefficient given our current measurements and uncertainty, or else we may search our measurement methods of sources of systematic uncertainty.



LHO General
thomas.shaffer@LIGO.ORG - posted 16:16, Thursday 13 August 2015 (20501)
Ops Day Shift Log

Times in UTC (PST)

15:15 (8:15) Karen opening rollup door in receiving.

15:54 (8:54) Fil to roof.

17:00 (10:00) Fill off roof.

17:11 (10:11) Jason, Ed to optics lab.

17:26 (10:26) Kyle, Gerardo to Y28 port on Yarm

17:48 (10:48) Gerardo back from Y28

17:57 (10:57) Gerardo to EY to look at a wireless card

18:30 (11:30 Kyle, Gerardo back

20:30 (13:30) Kyle, Gerardo to Y28

22:10 (15:10) John to Y28

 

Summery:

Locking this morning wasn't too sucessful, it would drop lock at ENGAGE_ASC every time in what seemed to be the same place. Jim W and I decided to run that state by hand in a Guardian terminal. Doing this showed that changing matrix elements in ASC input yaw, for SRC1 from AS_B_REF36I to AS_A_REF36I was dropping the lock. We got Gabriele involved and he saw that the error signal was no longer good for AS_A. Gabriele and Sheila have changed some things around and it seems to be holding lock now though!

H1 SUS
betsy.weaver@LIGO.ORG - posted 14:36, Thursday 13 August 2015 - last comment - 14:44, Thursday 13 August 2015(20516)
ETM FE slowness

A follow up on how the "new" old, slower FE computers have been running from Jim Batch:

 

If you trend H1:FEC-88_CPU_METER over the last 45 days, you can see 
what the h1susetmx was using before we installed the new "faster" 
computer, and when we reinstalled the original computer. 

After the "faster" computer was installed, changes were made to the
model which increased the amount of time the model uses, so now it is
over the limit frequently. 

On the DAQ test stand, we removed a portion of the changes that were
made which only calculated values and reported them with EPICS
channels.  That can be done in the corner station instead of sending 
the signal to the end station to be calculated.  The saving was 
3 to 4 uS which is enough to keep the model running under the max 
limit most of the time.

ECR E1500376 has been filed to move violin mode monitoring channels off of these machines and into the OAF one.
Comments related to this report
james.batch@LIGO.ORG - 14:44, Thursday 13 August 2015 (20517)
Attached is the plot of h1susetmx CPU usage over the last 45 days mentioned in the alog.
Images attached to this comment
H1 ISC
kiwamu.izumi@LIGO.ORG - posted 12:20, Wednesday 12 August 2015 - last comment - 11:50, Monday 19 September 2016(20481)
dtt correction filter updated for the control room DARM spectra

I have updated the correction filter for the dtt DARM spectra that are projected in the wall and screens in the control room. I hope Evan will like it.

This does not affect the CAL-CS or GDS calibrations. This is only for display purpose in diaggui.

 


[The DARM spectra]

Here is a comparison of the newly corrected and previous DARM spectra.

As shown in the attached screenshot, the high frequency excess wing that has been shown above 3 kHz is now gone. The noise level at around 7 kHz now seems a bit too low compared with the f-shaped GWINC curve (shown in green). This maybe a real calibration error because I have applied the best and latest knowledge about the sensing chain for correcting the spectrum.

The correction filter is made by a matlab script:

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER8/H1/Scripts/ControlRoomCalib/H1DARM_FOM_correction.m

This script creates a text file which contains the correction filter in [freq, dBmag, phasedeg] format from 1 Hz to 7444 Hz. The text file can be found at

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER8/H1/Scripts/ControlRoomCalib/DARM_FOM_calibration.dat

Both script and text files are checked in to the svn. Also I updated the latest FOM dtt template, H1_DARM_FOM_20150722.xml so that it now uses the new correction filter.

 

[Corrections newly included]

Here is a list of what I newly included.

Note that the previous correction was made only from the IOP down sampling filter and the numerical whitening zpk([1,1,1,1,1], [100,100,100,100,100]) which are still included in the new correction.

Images attached to this report
Comments related to this report
evan.hall@LIGO.ORG - 03:51, Friday 14 August 2015 (20525)

For those of us who like to look at the DCPD streams, I modified the script to also produce the appropriate correction TF (using the uncompensated preamp poles, the AA filter, and the downsampling filters only).

There is still a little bit of sloping at high frequencies, even in the null stream (which we expect to be flat above 100 Hz). Maybe the AA model needs to be tuned?

Non-image files attached to this comment
kiwamu.izumi@LIGO.ORG - 11:50, Monday 19 September 2016 (29795)

I happened to come across this code again to reproduce the calibration correction filter for O1. I then found some bugs in the code which are now fixed.

  • The code was looking at the latest foton filter
    • Now it looks at an archived filter from Sep.10.2015
  • The code was picking up a wrong filter module (FM2 instead of FM1) for whitening filter of DELTAL_EXTERNAL.
    • Now it looks for FM1.
  • Also, the ascii version of the filter (DARM_FOM_calibration.dat) was also dur to the above errors.
    • I reproduced and saved it in svn.
  • The code is saved to SVN.
Displaying reports 64561-64580 of 84555.Go to page Start 3225 3226 3227 3228 3229 3230 3231 3232 3233 End