Displaying reports 55521-55540 of 84599.Go to page Start 2773 2774 2775 2776 2777 2778 2779 2780 2781 End
Reports until 00:01, Thursday 22 September 2016
H1 General
jeffrey.bartlett@LIGO.ORG - posted 00:01, Thursday 22 September 2016 (29897)
Ops Evening Shift Summary
Title:  09/21/2016, Evening Shift 23:00 – 07:00 (16:00 - 00:00) All times in UTC (PT)
State of H1: IFO is locked. Environmental conditions are good. Wind and microseism are low. The seismic band being somewhat elevated in X & Y is subsiding.       
Commissioning: On going commissioning
Outgoing Operator:  Ed
 
Activity Log: All Times in UTC (PT)

23:00 (16:00) Start of shift

Title: 09/21/2006, Evening Shift 23:00 – 07:00 (16:00 – 00:00) All times in UTC (PT)
Support:  Jenne, Sheila, Lisa, Kiwamu       
Incoming Operator: N/A

Shift Detail Summary: Good Shift. Had one lockloss at beginning of the shift. IFO locked for ~7 hours, most at 50W NOMINAL_LOW_NOISE. Commissioning work continues apace.   
H1 CAL (CAL)
darkhan.tuyenbayev@LIGO.ORG - posted 23:37, Wednesday 21 September 2016 (29895)
Updated EPICS records for tracking DARM time-dep. params (preliminary for ER10)

Kiwamu, Darkhan,

Summary

EPICS records used for calculation of the DARM time-dependent parameters have been updated with the values calculated using the most recent DARM model configuration parameters for ER10.

All κ's except for κPU calculated in the CAL-CS model are within reasonable ranges (see attachment 1):

κTST ≈ 0.75
κPU ≈ -0.25
κc ≈ 1.2
fc ≈ 345 Hz

We will investigate why κPU calculations are incorrect.

Details

The H1 DARM model parameters used for generation of the EPICS values are

Output files: raw EPICS values, a verbose log and a Matlab file with EP# variables (T1500377-08, Table 2) were committed to the calibration SVN (rev. 3335):

Runs/PreER10/H1/Scripts/CAL_EPICS

./callineParams_20160919.m
./20160921_H1_CAL_EPICS_VALUES.txt
./D20160921_H1_CAL_EPICS_VALUES.m
./20160921_H1_CAL_EPICS_verbose.log
./writeH1_CAL_EPICS.m

Runs/O2/Common/Scripts/CAL_EPICS/writeO2_TDEP_EPICS.m

The changes were accepted in SDF_OVERVIEW (safe.snap and OBSERVE.snap). For ER9 EPICS see LHO alogs 28180, 29104.

Images attached to this report
Non-image files attached to this report
H1 GRD
jenne.driggers@LIGO.ORG - posted 23:03, Wednesday 21 September 2016 (29894)
IFO Guardian back to monitoring all nodes

Since we have started putting the ALS and SEI_BS nodes into their nominal states, I have uncommented them from the list of monitored nodes for the main IFO guardian. 

Recall (alog 28280) that they were commented out before ER9, and have remained so, so that we could set the Observation Intent bit when the IFO was being left alone, so that the analysis teams could check their pipelines.  Now we're back in the state of being ready to monitor those nodes, I've uncommented them.

As we wind down on creating new nodes, perhaps TJ can do an audit of all the nodes that should be monitored, and make sure that they are being watched by the main IFO guardian.  There shouldn't be anything left that we want un-monitored, except the SDF.  We're still not quite ready for that.

H1 ISC
evan.hall@LIGO.ORG - posted 18:44, Wednesday 21 September 2016 - last comment - 17:13, Monday 03 October 2016(29893)
Frequency noise coupling looks OK

Here is a frequency noise coupling transfer function during tonight's lock.

I calibrated REFL9 into watts using a the factor 2900 V/W (from the diode to the output of the demodulator) and 12 dB, −21 dB, and 2 V/V for the analog and digital signal gains.

If the loop is shot-noise-limited (with 4.6 mW on the diode), this implies a noise of about 40 pW/Hz1/2. This would imply a noise in DARM that is more than a factor of 10 below DARM shot noise.

Images attached to this report
Non-image files attached to this report
Comments related to this report
evan.hall@LIGO.ORG - 17:13, Monday 03 October 2016 (30192)

Daniel and I spent some time looking at the various CARM error and control signals we have on hand.

Here we have referred the fast (ao) control signal back to the error point in watts. The horizontal line is the shot noise for 5 mW.

The slow control signal (LSC-REFL_SERVO_SLOW) would also probably work as a proxy for the error point, once properly referred. The error readback (LSC-REFL_SERVO_ERR) is heavily contaminated by some kind of white noise. Ditto LSC-REFL_A_RF9_I_ERR.

Images attached to this comment
H1 ISC (ISC, SUS)
jenne.driggers@LIGO.ORG - posted 16:44, Wednesday 21 September 2016 - last comment - 17:37, Wednesday 21 September 2016(29888)
ITMY different bounce mode damping settings

[JeffK, Sheila, Jenne]

The bounce mode has been giving us extra trouble today.  In the end, we used a very fine bandwidth spectrum to confirm that it really was ITMY's bounce mode (as the monitor bar graph was telling us).  We tried out some different phases, and ended up with some settings that are now working.  When I went to put the new settings into the guardian, I found that these exact filters had once been used for ITMY, but had been commented out and changed.  I'm not sure how long ago this happened, but it was at least before Sheila made the gain=-1 filters, so that the numerical gain is positive for all test masses, since that filter wasn't included in the commented-out settings. 

So.  Why did the damping phase change some time ago, and why did it change back?  Unknown.

Comments related to this report
jeffrey.kissel@LIGO.ORG - 17:37, Wednesday 21 September 2016 (29890)
J. Kissel, S. Dwyer

First attachment -- a screen cap the currently functional Bounce and Roll mode damping settings that work as Jenne describes above.

One potential cause Shiela and I explored: we're using DARM_CTRL as our error signal for the bounce mode damping. We've always assumed that the DARM open loop gain is large enough that the open loop gain of the bounce mode damping loop is unaffected by changes in the DARM filter, D, or the DARM plant, or sensing function, C. Given recent, uncompensated issues with SRC cavity detuning cause optical spring changes in the plant, the DARM open loop gain near 10 [Hz] has been questionably low. We've been struggling with interferometric SRC alignment signal, and therefore leaving SRC angular control essentially off recently. This implies the SRC detuning can be changing from lock-stretch to lock-stretch, which means the DARM optical plant is changing from lock-stretch to lock-stretch. And if the overall DARM open loop gain is low enough, then the phase impacts of this change in optical plant will change the phase necessary to damp the bounce modes.

The second attachment compares Kiwamu's DARM OLG TFs taken on 2016-09-16 vs 2016-09-21, and indeed, the open loop gain magnitude is only ~4 to 5 at 10 [Hz], and once can clearly see substantial phase differences between the two measurements.

The third attachment shows the loop math to aide the following proof of how the two loops are coupled:

C = DARM IFO plant, or sensing function
D = DARM filter bank
A = ISC L to TST L DARM super-actuator TF
V = Bounce mode damping filter
alpha = TOP V to TST L actuation function
xi = coupling from TST L to DARM

Delta L_{res} = Delta L_{V} + Delta L_{ctrl}
               = Delta L_{V} + A D C Delta L_{res}

               d_{ctrl} = D C Delta L_{res}
     --> Delta L_{res} = d_{ctrl} / (D C)

d_{ctrl} / (D C) = Delta L_{V} + A D C d_{ctrl} / (D C)
        d_{ctrl} = D C Delta L_{V} + A D C d_{ctrl}
            
               G_{darm} = - A D C

   (1 + G_{darm}) d_{ctrl} = D C Delta L_{V}

        d_{ctrl} / Delta L_{V} = D C / (1 + G_{darm})

     --> G_{V} = alpha xi beta D C / (1 + G_{darm})

     --> IF G_{darm} << 1, then
         G_{V} ~ alpha xi beta D C
     and we have dependence on the changes in the optical plant of DARM.

     --> IF G_{darm} >> 1, then
         G_{V} ~ alpha xi beta D C / G = alpha xi beta / A
     and we have the scenario we have always assumed was happening.


Now that Jenne's just restored old damping, this is less of a suspicion, but I wanted to write it down so that we keep this sort of loop inter-dependence in mind.
Images attached to this comment
Non-image files attached to this comment
H1 General
edmond.merilh@LIGO.ORG - posted 15:54, Wednesday 21 September 2016 (29886)
Shift Log

15:43 Cleaning crew headed to mid stations

15:47 Keita doing ISS measurements

16:31 Karen leaving MY

16:43 Jim headed to EX to tame the BRS beast

16:48 Kiwamu to LVEA to check TF of ISS loops

16:50 Christina left MX

17:01 Jim back. Report is damping was turned off last night to allow ring down(didn't happen). At this point no correcive action has been taken.

17:08 Kyle to MY

17:33 Chandra and John to head to MY

17:34 Kiwamu out of LVEA. We can return to locking

17:45 Jeff K restarting CAL_CS model

18:18 John and Chandra are back

18:25 Kyle back from MY

21:03 Kyle Gerardo and Chandra going to MY

21:49 Kyle Gerardo and Chandra back from MY

22:30 Tour group into control room

H1 PSL
edmond.merilh@LIGO.ORG - posted 14:26, Wednesday 21 September 2016 - last comment - 08:32, Thursday 22 September 2016(29883)
PSL Weekly Report - FAMIS #6114
Images attached to this report
Comments related to this report
jason.oberling@LIGO.ORG - 08:32, Thursday 22 September 2016 (29903)

Nothing here looks out of the ordinary.

H1 PSL
edmond.merilh@LIGO.ORG - posted 14:22, Wednesday 21 September 2016 (29882)
PSL Status - FAMIS #7404
 
Laser Status:
SysStat is good
Front End Power is 34.78W (should be around 30 W)
Front End Watch is GREEN
HPO Watch is GREEN
PMC:
It has been locked 0.0 days, 0.0 hr 12.0 minutes (should be days/weeks)
Reflected power is 31.79Watts and PowerSum = 148.0Watts.
 
FSS:
It has been locked for 0.0 days 0.0 hr and 12.0 min (should be days/weeks)
TPD[V] = 4.461V (min 0.9V)
 
ISS:
The diffracted power is around 4.525% (should be 5-9%)
Last saturation event was 0.0 days 0.0 hours and 12.0 minutes ago (should be days/weeks)
 
Possible Issues:
H1 ISC
sheila.dwyer@LIGO.ORG - posted 14:22, Wednesday 21 September 2016 (29878)
jitter coupling and projection

Here is some of the data from Saturday's jitter injections (29780), plotted differently.  The main point is that we should be able to reduce the yaw jitter coupling by at least a factor of a few, and this should help the DARM spectrum, but not enough to get the noise a factor of 10 belpw the quantum noise with the current level of jitter.  

Images attached to this report
H1 PSL (IOO, ISC)
kiwamu.izumi@LIGO.ORG - posted 13:41, Wednesday 21 September 2016 (29880)
ISS 1st loop open loops

Related to 29870, 29804,

I have taken open loop transfer functions of the 1st loop in this morning to see where the UGF currently is.

Based on the measurements, I set the gain slider in the medm to 9 dB which gives us a UGF of 50-60 kHz.

Also, the raw data is attached as a zipped file.

Apart from these measurements, I confirmed two features as follows.

During the measurements, I kept the suspiciously high offset value of 20 for the 1st loop. The second loop was off.

Images attached to this report
Non-image files attached to this report
H1 PSL (PSL)
travis.sadecki@LIGO.ORG - posted 13:16, Wednesday 21 September 2016 (29879)
Weekly PSL Chiller Reservoir Top-Off

I added 125 mL to the crystal chiller.  I noted that the fill port water is very turbulent, swirling and full of air bubbles.  I recall that it is usually calm.

FAMIS 6489.

H1 CAL (CAL)
richard.savage@LIGO.ORG - posted 11:51, Wednesday 21 September 2016 - last comment - 16:49, Wednesday 21 September 2016(29873)
Optimizing Pcal beam positions at Xend

SudarshanK, TravisS, RickS

Yesterday, we went to Xend to assess and optimize the Pcal beam locations on the ETM surface.

Since O1, we have known that the beams were clipping somewhere on the receiving side.

Unsing an updated method of assessing the beam locations that is based on the work that Miranda Chen (REU student from UTRGV) did this summer (basically using the ESD electrode pattern rather than the edge of the ETM) we found that the Pcal beams were quite far from their optimum locaitons (see first image attached below). The offests from the optimal locations (111.6 mm above and below the center of the face of the optic) were U [ 1.71, 12.27], L[10.02,  -7.27] where U and L denote the upper and lower Pcal beams and the coordinates are [x offset, y offset] in millimeters with the usual conventions, positive x to the right, positive y up.  Because we use 2" diameter optics in the Pcal periscope structure and because the receiveing-side mirrors are twice the distantance from the ETM, an offset of 12 mm at the ETM would correspond to an offset of ~24 mm at the periscope, likely the cause of the clipping we have observed. The reflected power measured by the power sensor in the receiver module increased by about 50% from about 4 V to 6.2 V.

We adjusted the beam locations using the steering mirrors in the Pcal transmitter module and ended up with positions that are within a mm of the optimal locations (see second image attached below): U [ 0.15, 0.43], L[-0.18,  0.05].

The third image below shows the Pcal spots on the ETM surface (inside green circles), visible when the chamber illuminator is off.

We are in the process of modeling the expected calibration errors resulting from bulk elastic deformation induced by the Pcal forces being so far from the optimal locations, but we expect errors as large as 20-40% at frequencies above 4 kHz for offsets as large as what we had before correcting the positions yesterday.

Images attached to this report
Comments related to this report
sudarshan.karki@LIGO.ORG - 16:13, Wednesday 21 September 2016 (29885)

Attached is a plot that shows the expected calibration error at higher frequencies due to the effect of bulk elastic deformation of the test mass. The estimated error is calculated using the COMSOL modeling (worked on by Nicola and Shivaraj this summer) for the pcal beam configuration prior to moving the beam (LHOX_ER9). This is the same configuration in which we were running the the high frequency calibration lines during ER9 and even during O1 (there is no reason to believe the beam positions have changed appreciably since O1). The measurement data plotted alongside are the high frequency calibration lines run during the end of O1 and described in LHO alog 26275. The data is normalized to the model at 1 KHz and agrees closely to the model at frequencies above it. The beams are now moved to their optimal position as described above. The model shows smaller error (plotted in cyan) due to bulk elastic deformation  for this optimal configuration (LHOX_ER10). Similar measurement will be done during and before ER10 in order to confirm the model. 

LHOX HF

Images attached to this comment
richard.savage@LIGO.ORG - 16:49, Wednesday 21 September 2016 (29889)

Note that the movement of the beam on the ETM, per quarter turn on the adjustment knobs of the mirror mounts in the tramsmitter module, is about 10 mm (judging by what we experienced yesterday).

If one works out the numbers using the 100 TPI actuators in the mount and the 1.5" between the actuator and the pivot point, the result is about 12 mm per quarter turn, assuming the mirror is about 7 m from the mount.  It might be closer to 8 meters given the distance from the mirror mount to the periscope and the path in the periscope (larter for the lower - outside - beam).

H1 ISC
keita.kawabe@LIGO.ORG - posted 09:54, Wednesday 21 September 2016 - last comment - 00:12, Thursday 22 September 2016(29870)
ISS second loop OLTF at 50W

Attached is the OLTF in two configurations with 7dB VGA gain.

50W (actually 48W), AC coupling OFF, and boost ON (solid line)

50W (actually 48W), AC coupling ON, boost OFF (dashed).

UGF is about 9kHz with phase margin of 40 deg or so (boost ON) or 50 (boost OFF).

Boost buys us about 9dB more gain at 1kHz.

I asked Kiwamu to do an analog measurement up to higher frequency on the floor.

Images attached to this report
Comments related to this report
kiwamu.izumi@LIGO.ORG - 12:17, Wednesday 21 September 2016 (29877)

Here is a transfer fucntion with SR785 to check the high frequency portion.

Also, the attached zip contains the data, plot script, and figure.

Images attached to this comment
Non-image files attached to this comment
daniel.sigg@LIGO.ORG - 14:50, Wednesday 21 September 2016 (29884)

Taking this data I looked at modifications to the ISS board to increase its bandwidth. The attached plot shows:

  • brown — original measurement
  • green — adding a zero at 20kHz and adding a gain of 2
  • blue — same as green but also moving the knee of the boost from 2kHz to 4kHz
  • red —same as green but adding a second boost with knee at 2kHz.

Adding the 20kHz zero is a no brainer, since it only requires to limit the dominant pole in the circuit. It improves the phase margin over the measured curve and allows the ugf up to move to 20kHz. This will increase the ISS gain by 2 at 1kHz. The increased ugf and phase margin will in turn allow us to move the knee of the boost higher with the option to add a second boost. The later two solutions will add another gain of 2 at 1kHz.

Images attached to this comment
sheila.dwyer@LIGO.ORG - 00:12, Thursday 22 September 2016 (29899)

We engage the ISS boost twice today in low noise, and did not see any impact on the DARM noise. We expected an improvement at 1 kHz at least.  Attached are before and after spectra of the in and out of loop diodes (at least that's what I think the new cahnnel names mean).  If it is correct that INNER means in loop and outer means out of loop, we are sensor noise limited at 100 Hz with the boost on. 

Images attached to this comment
H1 CAL (ISC)
kiwamu.izumi@LIGO.ORG - posted 02:52, Wednesday 21 September 2016 - last comment - 21:59, Thursday 22 September 2016(29860)
seemingly wrong calibration -- probably the EY L3 actuator sign

Lisa, Kiwamu,

We think that the calibration has been wrong and therefore it lifted up the noise floor below 300 Hz. We need another set of eyes tomorrow to doublecheck our theory (we are currently too sleepy to do systematic investigation).

In short, we believe that the sign of ETMY L3 stage in CALCS (or somewhere else similar to it) is wrong which is exactly the same situation as what happened in this past July (28396).


Because I knew that our DARM open loop model is accurate and consistent with the recent measurement (29748), I made a calibration filter for DARM_IN1 which converts DARM_IN1 to DARM displacement as opposed to the use of both DARM_IN1 and DARM_OUT. Here is a comparison of the CALCS spectrum against the spectrum derived from DARM_IN1.

As shown in the plot, the CAL CS spectrum overestimates the noise floor below 300 Hz or so. This is exactly the same behavior as what we have experienced in this past July. In addition, we have noticed that the noise floor of CALCS changed as a function of the DARM control gain which should not happen in the calibration scheme used in CAL CS. Also, when we flipped the sign of the EY L3 stage in CAL CS, the leve of the noise floor became identical to the one derived by DARM_IN1 and also became insensitive to the control gain. This increased our confidence that the L3 sign was wrong in CALCS.

We are leaving the L3 stage gain flipped (DRIVEALIGN_GAIN -30 --> +30) for the night. If our theory is correct, we regain the binary range back to ~60 Mpc with this change.

Also, we took a DARM open loop and PCAL sweep measurement within the same lock stretch. We did not analyze them yet, but they are available at:

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Measurements/PCAL/2016-09-21_H1_PCAL2DARMTF_4to1200Hz.xml

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Measurements/DARMOLGTFs/2016-09-21_H1_DARM_OLGTF_4to1200Hz.xml

Also, my code which generated the calibration filter for DARM_IN1, as well as, the generated filter are available at:

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Scripts/ControlRoomCalib/CalibrateH1DARM_IN1.m

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Scripts/ControlRoomCalib/DARM_IN1_calib.txt

Images attached to this report
Comments related to this report
evan.hall@LIGO.ORG - 18:19, Wednesday 21 September 2016 (29892)

I don't know what was decided this morning, but somehow we ended up with the wrong actuator sign in the front-end calibration again. So I reinstated the sign flip in the drivealign calibration filter.

kiwamu.izumi@LIGO.ORG - 20:56, Thursday 22 September 2016 (29930)

After we fixed the sign flip on the night, the Pcal to CAL-CS transfer function looked indeed correct. See the attatched screenshot below.

The transfer function from Pcal to CAL-CS is almost unity in magnitude and zero in phase which double-confirms that the sign flip was the right action. The dtt template was updated with the latest DELTAL_EXTERNAL whitening filter, known delays.

The dtt file can be found at:

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Measurements/PCAL/2016-09-21_H1_PCAL2DARMTF_4to1200Hz.xml

The matlab script which produced the calibration filter can be found at:

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Scripts/ControlRoomCalib/H1_pcal2darm_correction.m

Finally the calibration filter in ascii formt is available at:

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Scripts/ControlRoomCalib/pcal2darm_calib.txt

By the way, in the script, I needed to add an additional minus sign in order to get the resulting phase close to zero rather than close to 180 deg. I feel like this is one of theose things we had found during O1, but I can't recall what introduced a minus sign. In addition, the calibration filter currently does not include the effect of the supernyquist poles of OMC DCPDs which introduces a phase delay at high frequencies.

Images attached to this comment
kiwamu.izumi@LIGO.ORG - 21:59, Thursday 22 September 2016 (29931)

The open loop transfer function(s) can be now analyzed by a copy of Evan G's code,

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Scripts/DARMOLGTFs/compareDARMOLGTFs.m

The attached are the resulting figures from the code. I have not adjusted kappas or examined each piece of the DARM loop yet, but the model showed a good agreement with the measurement-- no crazy bug so far in the model.

Non-image files attached to this comment
H1 DetChar (DetChar)
keith.riles@LIGO.ORG - posted 13:31, Sunday 18 September 2016 - last comment - 10:33, Friday 23 September 2016(29783)
Looking at narrow lines in last night's H1 data
I took a quick look at six hours of 30-minute SFTs automatically
created by FScans this morning (thanks for setting the intent bit!),
to see if recent line mitigation attempts have reduced the amplitude
of the 1-Hz and other combs at low frequencies. Unfortunately, 
the low-frequency noise floor is too elevated to say much yet
about that mitigation success, but in the band 28-32 Hz, where
last night's noise is lower, there do seem to be fewer and lower-level
lines, including reduced amplitudes for the 1-Hz comb with a ~0.25-Hz offset.

Please note that the 56.84-Hz comb reported in the ER9 data
(present but weaker in O1 data)  remains quite strong.
There are other strong lines present, too, but I gather noise-hunting
is just getting started. The 56.84-Hz comb suggests a DAQ problem
somewhere, as noted before.

The attached plots show different bands of O1 data (narrow black curves)
superposed on last night's data (broad red swath). In each case, an 
inverse-noise weighting is used, to suppress periods of elevated noise.

Figure 1 - 10-2000 Hz
Figure 2 - 10-28 Hz
Figure 3 - 28-32 Hz
Figure 4 - 32-50 Hz
Figure 5 - 50-100 Hz
Figure 6 - 100-200 Hz
Figure 7 - 200-1000 Hz
Figure 8 - 1000-2000 Hz

Images attached to this report
Comments related to this report
keith.riles@LIGO.ORG - 14:13, Wednesday 21 September 2016 (29881)
Ansel just brought to my attention this alog entry by Robert identifying a 56.8-Hz line
with the EX HWS. In that entry Robert suggests isolating the HWS power supply at EX 
as was done at EY (if I understand correctly) or shutting off the HWS during O2.
Is there any reason to leave either HWS on during O2? The 56.84-Hz comb was
visible at a low level in O1 data.
ansel.neunzert@LIGO.ORG - 10:33, Friday 23 September 2016 (29941)

Update after looking at this + subsequent lock stretches (through last night):

  • The 1-Hz comb with 0.5 Hz offset (targeted by LED reprogramming in the timing system) looks improved, but is not entirely gone.
  • The 1-Hz comb with 0 Hz offset seems to be slightly stronger.
  • Good news: the near-2Hz comb (targeted by re-powering & reprogramming the CPS timing fanout) is not visible.

These results are pretty consistent across the recent locks. Attached: a representative plot of these combs in the 30-50Hz region in 2 hours of the most recent lock stretch.

Images attached to this comment
H1 CAL (CAL)
darkhan.tuyenbayev@LIGO.ORG - posted 22:03, Thursday 15 September 2016 - last comment - 18:22, Wednesday 21 September 2016(29744)
Testing coherence calculation w/ different averaging parameters

Kiwamu I, Jeff K, Darkhan T,

Overview

Today we looked at the calibration line coherence values calculated in the front end. We discovered that in the front-end model with the currently used averaging parameters the coherence value is updated once every 10 seconds (first 1.5 minutes in Fig. 1).

We propose modifying the averaging code to improve coherence calculation and avoid potential aliasing (see details).

Details

A front-end model that calculates coherence uses N data points taken every Scycles computational cycles to calculate cross-spectral density of the signals. Scycles is controlled by an EPICS record $(IFO):CAL-CS_TDEP_COH_STRIDE (or simply STRIDE): Scycles = FE_RATE * STRIDE. There are drawbacks associated with this approach:

We can deal with the first problem listed above by reducing STRIDE. On Fig. 1 we show coherence values for N = 10 and STRIDE set to 10, 5, 1, 1/16 and again 1. Notice that this test was done when the IFO was not locked, thus we do not expect a coherence of ~1. When STRIDE is set to 1/16, we can see that the number of averages must be increased in order to include actual fluctuations in the signals (in the last 2.5 minutes N = 120).

Fig. 1

Several minutes later IFO locked (at t = -5 in Fig. 2) and the coherence became ~0.8. After we set the line amplitude to its nominal value we got coherence of ~1.

Fig. 2

Next, to avoid aliasing we should use all data points (equivalent to setting STRIDE = 1/FE_RATE in the current code) and increase N accordingly. Thus to integrate over 10 seconds and avoid aliasing the current code will require O(FE_RATE * 10) = O(160k) operations per cycle and a buffer for 160k values, which is unnecessary expensive.

A following minor modification of the averaging code can solve the issue described above. Instead of adding every Scycles'th data point into the averaging buffer, we could insert an average of Scycles values. E.g. buffer_and_average() can be modified as follows:

...

    static int mini_sum = 0;

...

    //Increment cycle count
    mini_sum += data;
    cycle_counter++;
    if (cycle_counter >= cycles_between_data) {
        buffer[current_pointer] = mini_sum / ((double) cycles_between_data);
        current_pointer++;
        cycle_counter = 0;
        mini_sum = 0;
    }

...

With this modification and N = 160, STRIDE = 1/16 (Scycles = 1024), the coherence will be calculated with 10 second integration and will require O(160) operations per cycle, and the coherence value will be updated every 1/16 of a second.

Images attached to this report
Comments related to this report
darkhan.tuyenbayev@LIGO.ORG - 16:54, Wednesday 21 September 2016 (29887)CAL

Jeff K, Kiwamu I, Joe B, Darkhan T,

The modifications suggested above have been implemented at LHO (the modification was implemented during a bug fix, LHO alog 29876). The modifications also include an increased max buffer size:

...

#define MAX_SIZE 256

...

    static double mini_sum = 0;

...

    //Increment cycle count
    mini_sum += data;
    cycle_counter++;
    if (cycle_counter >= cycles_between_data) {
        buffer[current_pointer] = mini_sum / ((double) cycles_between_data);
        current_pointer++;
        cycle_counter = 0;
        mini_sum = 0;
    }

...

The changes have been committed to cds_user_apps repository, r14301.

Following is how coherence was calculated for locked but with high noise floor at lower frequencies (see attached displacement ASD during this measurement), so only PCAL_LINE2 (at 331.9 Hz) has coherence of ~1, and all three of the ~35 Hz lines do not have good coherence:

Fig. 1

The coherences were calculated with H1:CAL-CS_TDEP_COH_STRIDE set to 1/16 and H1:CAL-CS_TDEP_COH_BUFFER_SIZE (N in the original alog) set to 80 (at [-4, -2] min time interval) and 160 (at [-2, 1] min time interval). With H1:CAL-CS_TDEP_COH_BUFFER_SIZE set to 160, each of the coherence calculations include data points from past 10 seconds.

Images attached to this comment
darkhan.tuyenbayev@LIGO.ORG - 18:22, Wednesday 21 September 2016 (29891)CAL

Attached is a plot of the DARM time-dependent parameters calculated in the front-end when the IFO noise floor was reasonably low (at about 23 UTC). Notice that Y-axis for coherence is zoomed to 1 for a better detail.

It seems that the ER9 Matlab DARM model parameters for H1 that was used for calculation of current TDEP EPICS values needs an update. The ESD sign is opposite to the one in the DARM model. Calculation of κPU is hugely biased due to the wrong sign of κTST and it's magnitude being incorrect by an order of magnitude.

During last night's lock stretches the sign of κTST calculated in the front-end was positive (see attachment 2), opposite to the currently calculated value. A possible explanation for this is that L3 stage sign flip commisioning activities are underway (see LHO alog 29860).

Images attached to this comment
Displaying reports 55521-55540 of 84599.Go to page Start 2773 2774 2775 2776 2777 2778 2779 2780 2781 End