Displaying reports 57581-57600 of 78016.Go to page Start 2876 2877 2878 2879 2880 2881 2882 2883 2884 End
Reports until 08:00, Friday 28 August 2015
H1 General
thomas.shaffer@LIGO.ORG - posted 08:00, Friday 28 August 2015 (20979)
Ops Owl Shift Summery

(All times UTC)

Summery:

Evan and Stefan were working on recentering the AS WFS when I arrived. When they were done, Evan cleared out his changes in the SDF aside from some ASC diff that occurred from dark offset scripts. I accepted the ODC Master changes from alog 20915.

Guardian brought the IFO into a full lock really quick, Evan added some DCPD Whitening, and it has stayed in lock since.

Locking:

H1 General
thomas.shaffer@LIGO.ORG - posted 04:00, Friday 28 August 2015 - last comment - 10:39, Friday 28 August 2015(20980)
Intent Bit set

Itbit set at 10:48 UTC with long lock hopes.

Comments related to this report
thomas.shaffer@LIGO.ORG - 04:13, Friday 28 August 2015 (20981)

HWS SLED IX is ON

eleanor.king@LIGO.ORG - 10:19, Friday 28 August 2015 (20983)

Having the HWS SLED on should not effect the interferometer, I added this into the guardian because we don't want the SLED running indefinately, but it is easy to turn it on and forget.  If the warning message is confusing we could remove it, or move it to a less obtrusive place.

jameson.rollins@LIGO.ORG - 10:39, Friday 28 August 2015 (20985)

Presumably this check is coming from the DIAG_MAIN node.  I think the important principle for that node should be that all the diagnostic checks should be actionable, in other words someone should get out of their chair and deal with whatever the notification is to make the notification stop.  If the plan is to leave the HWS SLED on, or it's not critical to shut it off, then it should be removed from DIAG_MAIN.

Maybe we can add a second DIAG node for not immediately actionalbe diagnostics, but my guess it that it will just be ignored, since by definition nothing there will be critical.

H1 ISC
evan.hall@LIGO.ORG - posted 02:47, Friday 28 August 2015 (20976)
90 MHz AS WFS centering again

Stefan, Evan

We made another attempt at using 90 MHz to center WFS AS B.

This time we turned up the whitening gain to 45 dB, which gave a healthy number of counts on each quadrant. We then redid our dark offsets, which were significant at this whitening gain. [We actually redid the dark offsets for all the REFL and AS WFS signals using the script in the userapps repo.]

Then in DRMI, we phased each quadrant to put most of the power in I. At this point we saw that the centering signals provided by these 90 MHz quadrants (pitch and yaw) were slightly different than the dc centering signals for AS B, so we switched the centering over to these signals (a relative gain of −0.003 is required between these 90 MHz signals and the dc signals). Things seemed fine in DRMI (the sideband buildups all changed slightly, but it was hard to say whether they were better or worse), but when we tried the CARM reduction sequence, the new centering ran away on the DARM WFS step.

So instead, we went to full lock at 2 W with the old centering scheme and switched over again to the new 90 MHz AS B centering. Things again seemed fine.

We weren't quite sure what to do about the BS/SRM matrix elements. In the end we tried using AS B 36 I&Q only to control these loops (i.e., no mixture with AS A 36), and this was fine at 2 W, but we lost lock immediately when trying to power up.

H1 AOS (CAL)
craig.cahillane@LIGO.ORG - posted 00:34, Friday 28 August 2015 (20974)
Strain Uncertainty Carpet Plots Developments
C. Cahillane, D, Tuyenbayev

In a previous alog alog 20946 I showed preliminary carpet plots of ER7 strain uncertainty based on changes in the calibration parameters |kappa_tst|, φ_kappa_tst, |kappa_pu|, φ_kappa_pu, kappa_C, f_c.
Here are some updated plots.  (Plots 1 - 6)

The data is now low-noise, and is dewhitened.  This gives much nicer, more accurate results.
I have been working to reproduce Darkhan's carpet plots from T1500422.  The method he uses to find error in Delta_L_ext is as follows:

delta Delta_L_ext =  C_true / (1 + G_true)     
                             ------------------------------
                                        C / (1+G)

where C_true and G_true are the quantities where kappa_tst, kappa_C, and f_c are varied.

The method I use to find error in strain is:

delta strain = (1 / C_true) * d_err + A_true * d_ctrl
                      ----------------------------------------------
                                  (1 / C) * d_err + A * d_ctrl

Plot 7 is Darkhan's method of computing error from changes in kappa_tst reproduced by me.
Plot 1 is my method of computing error from changes in |kappa_tst|.  They should be the same.  They aren't.

We are searching for potential reasons behind the structure found in Darkhan's plot.  Something odd may be going on at the UGF of the CLG, causing the low magnitude error near 65 Hz and low phase error near 35 Hz.
My plot, on the other hand, has no low error region in phase, in fact it has a maximum near 35 Hz, and has a tilted low magnitude error region between 30 and 40 Hz.

I am investigating this difference now.
Non-image files attached to this report
LHO General
patrick.thomas@LIGO.ORG - posted 00:12, Friday 28 August 2015 (20971)
Ops Evening Summary
23:00 (16:00) Darkhan and Travis at end Y running PCAL measurements. Leo running charging measurements for ETMX.
23:36 (16:36) Kiwamu to electronics room to measure transfer function of whitening filter
23:40 (16:40) Evan to CER to run measurement with network analyzer
23:41 (16:41) Darkhan and Travis done at end Y, moving to end X
00:09 (17:09) Nutsinee to TCS X to take picture of control box
00:15 (17:15) Nutsinee back
00:44 (17:44) Evan done, Leo done
01:18 (18:18) Travis and Darkhan done at end X
01:37 (18:37) Travis and Darkhan back

02:13 (19:13) Kiwamu and I start locking
Trouble locking on DRMI
Ran through initial alignment starting with CHECK_IR
Lost lock engaging ASC WFS in LOCK_DRMI, Kiwamu had to revert phase settings for AS 36
Lock loss on bounce mode
03:17 (20:17) h1fw2 crashed and restarted
04:48 (21:48) Locked on Low Noise, Darkhan running calibration measurements

05:22 (22:22) Darkhan done, Stefan and Evan starting wiggling cables test
05:26 (22:26) Kiwamu to CER to clean up previous work
Kiwamu is back
06:22 (23:22) h1fw2 crashed and restarted
07:00 (00:00) handing off to TJ, Evan and Stefan are investigating RF

Other
end Y dust alarms
smelled a lot of smoke in hallway, went up to roof, didn't spot any fires
H1 CAL (CAL, CDS, ISC)
jeffrey.kissel@LIGO.ORG - posted 23:50, Thursday 27 August 2015 (20972)
Comparison between DAC and ADC DuoTone Timing Signals for DARM-Relavent IO Chassis
J. Kissel, K. Kawabe

Similar to what is shown and briefly mentioned in LLO aLOG 18406, I've done a comprehensive transfer function study between the DAC and ADC Duotone timing signals from the following IO chassis:
h1lsc0 (which houses the ADC for the OMC DCPDs),
h1susex & h1susey (which house the DACs for the ETM QUADs)
h1iscex & h1iscey (which house the ADC for the PCAL RXPDs)
h1oaf0 (which receives the DARM_ERR and DARM_CTRL channels from the OMC model over IPC)
Recall that these Duotone signals are merely *checks* on the system that is actually providing the time signals for the DAC / ADC cards, which is the 1 PPS signal from the local timing fanout in the building (which in in turn receives its 1 PPS from the timing master in the corner station which is GPS synchronized). The results indicate that -- although there is a few tens of micro-second offset between all of these front-ends, they appear to not *differ* by more than a few hundred nano-seconds, and typical in the tens of nano seconds. This is consistent with what Shivaraj found when making the comparison between his l1iscex and l1iscex against l1oaf0. Recall that our requirement is that the timing uncertainty is no greater than 25 [us], so at least the DuoTone signals between each IO chassis fall in well-below this. What we would need to do to confirm that the actual front end timing is to then compare this DuoTone against the "digital world" 1 PPS, as Keita has done for the ADC and DAC DuoTone signals for all of the above mentioned chassis in LHO aLOG 20962. His aLOG also indicates a ~100 [ns] difference between chassis, on top of the ~7 [us] offset.

So far, so good in timing land.

Details:
---------
For all measurements, I used h1lsc0 ADC and DAC duotone singals as the reference (TF denominator), and the others as the response (TF numerator). Below are the results for the phase relationship between each at 960 [Hz] (the results are the same within the precision stated for the 961 [Hz] line):
          xxxx ADC      xxxx DAC      xxxx ADC     xxxx DAC
          --------      --------      --------     --------
          LSC0 ADC      LSC0 ADC      LSC0 DAC     LSC0 DAC

h1lsc0       n/a         -26.42        +26.42         n/a
h1susex    +5.14         -21.27        +26.45       +5.14
h1susey    +5.13         -21.28        +26.44       +5.13
h1iscex   +0.008         -21.29        +26.45       +5.13
h1iscey   +0.028         -21.27        +26.47       +5.14
h1oaf0    -0.013         -21.34        +26.43       +5.07

which we can turn in to an equivalent delay (or advance) between the two front end timing signals, with 1e6 * (pi/180) * phase_deg * / (2*pi*961 [Hz])
          xxxx ADC      xxxx DAC      xxxx ADC     xxxx DAC
          --------      --------      --------     --------
          LSC0 ADC      LSC0 ADC      LSC0 DAC     LSC0 DAC
            [us]          [us]         [us]          [us]
h1lsc0       n/a         -76.4         76.4          n/a
h1susex     14.9         -61.5         76.5          14.9
h1susey     14.8         -61.6         76.5          14.8
h1iscex     0.023        -61.6         76.5          14.8
h1iscey     0.081        -61.5         76.6          14.9
h1oaf0     -0.038        -61.7         76.5          14.7

Templates live in 
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/Timing/
2015-08-27_H1LSC0_to_CALCS_DuoTone_TFs.xml
2015-08-27_H1LSC0_to_ISCEND_DuoTone_TFs.xml
2015-08-27_H1LSC0_to_SUSEND_DuoTone_TFs.xml
of which I attach an example.
Images attached to this report
H1 CAL (CAL)
darkhan.tuyenbayev@LIGO.ORG - posted 23:09, Thursday 27 August 2015 (20973)
Pcal to DARM TF measurements

Sudarshan, Darkhan

Overview

Today we took PCALX to DARM and PCALY to DARM TF measurements.

These measurements will be used to assess time delays/advances between Pcal excitation/readout channels vs. DARM_IN1.

Details

Earlier today we took PCAL(X|Y) to DARM TF measurements for estimating timing of Pcal channels vs. DARM_IN1. We noticed that in today's earlier measurements "2015-08-27_PCALX2DARMTF_TIMING.xml" and "2015-08-27_PCALY2DARMTF_TIMING.xml" used log.spaced frequency vectors. Since later in the day we got another opportunity to measure these transfer functions, we repeated earlier measurements but this time taking a linearly spaced frequency vector.

So the most recent measurements taken at a lin.spaced frequency vectors are (notice that they also include earlier log.spaced measurement TFs and coherences as ref0 and ref1):

All 4 measurements have been uploaded to calibration SVN (r1161):

CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/PCAL/2015-08-27_PCALX2DARMTF_linspace.xml
CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/PCAL/2015-08-27_PCALX2DARMTF_TIMING.xml
CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/PCAL/2015-08-27_PCALY2DARMTF_linspace.xml
CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/PCAL/2015-08-27_PCALY2DARMTF_TIMING.xml

Images attached to this report
Non-image files attached to this report
H1 SUS (SUS, SYS)
leonid.prokhorov@LIGO.ORG - posted 18:08, Thursday 27 August 2015 - last comment - 21:16, Thursday 27 August 2015(20968)
OPLEV charge measurements
Charge measurements was done on both ETMs.
It seems like ETMY change the sign of charging after changing the bias sign on ETMY (see 20387) while ETMX charging is the same (as well as the bias sign).
Now (since Aug,10) both ETMX and ETMY Biases are -9.5V, 
Plots are in attachment.
Images attached to this report
Comments related to this report
daniel.sigg@LIGO.ORG - 21:16, Thursday 27 August 2015 (20970)

Since we turn teh ESD in X off during a lock stretch, could it be that ETMX has been used less since the start of ER8?

H1 SYS
jameson.rollins@LIGO.ORG - posted 17:50, Thursday 27 August 2015 - last comment - 11:56, Friday 28 August 2015(20967)
new EXCITATION_OVERVIEW screen

New EXCITATION_OVERVIEW screen has been created:

$USERAPPS/sys/common/medm/EXCITATION_OVERVIEW.adl

Hopefully this can help in tracking down excitations that could be preventing the system from entering READY:

The two columns show the front-end excitation monitors (FEC, left) and the ODC monitors (ODC, right).

NOTE: ONLY ODC monitors count towards OBSERVATION READY at the moment.

The FEC monitors are there for reference, and for completeness.

The EXCITATIONS box in the OBSERVATION_OVERVIEW screen now contains a link to this screen.

Images attached to this report
Comments related to this report
jameson.rollins@LIGO.ORG - 11:56, Friday 28 August 2015 (20989)

I updated this screen to remove the PEM_M* and ODC_MASTER checks, and added the missing CAL_EY.

H1 General
nutsinee.kijbunchoo@LIGO.ORG - posted 16:11, Thursday 27 August 2015 (20964)
Ops Day Shift Summary

(All time in UTC)

15:15 Christina opening the roll-up door, OSB receiving area

15:30 Christina done

16:36 Kiwamu to electronics area by PSL and HAM6

16:59 Sudarshan has been doing Pcal swept sine. Now done.

           Kiwamu done

17:00 Observing intent bit set. SDF hasn't been cleared at this point. See attachment.

17:34 Bubba to Mid station

18:03 Intent bit switched to Commissioning. Flipped DHARD 20-30 Hz BP filters.

18:05 Intent but switched back on

18:33 Kyle to beam tube near EY to make measurement. 300 m away from EY.

18:36 Wind picking up. Reaching 30 mph.

           Intent bit swited to Commissioning. Daneil to CER.

18:53 Daniel back. Intent bit Observing.

19:00 Calibration group taking over. Bring interferometer to down. Intent bit set to Commissioning

19:11 Kiwamu to LVEA doing OMCDCPD measurement

19:23 Fire protection Specialists back on site. Fire suppression in Network Room.

19:30 Sheila to LVEA looking for Kiwamu.

19:38 Kyle back

20:47 Sheila locking MICH

           Something water on site. Couldn't hear the guy. Let a white pick-up truck in.

21:09 Bubba done

21:42 Travis, Sudarshan, Darkhan to EY (Pcal calibration)

19:02 Hand the ifo over to Patrick

Images attached to this report
H1 ISC
sheila.dwyer@LIGO.ORG - posted 15:21, Thursday 27 August 2015 - last comment - 03:46, Friday 28 August 2015(20961)
changing RF phase in HAM6 racks.

Evan, Sheila

While the IFO was down for some calibration measurements, we made another attempt at phasing AS36. 

We first redid the dark offsets, this was an important step.  Then we locked the bright michelson with 22 Watts of input power. 

We steered the beam onto each quadrant of AS_A by maximizing the DC counts, then phased 36 to minimize Q.  There were several things that made this seem much more promising than any of our previous attempts to phase these WFS:

Both of these things are firsts for these WFS as far as I'm aware, so this seemed like real progress.  

We started to do the same procedure for AS_B 36, but after we phased the first quadrant the phase jumped.  Kiwamu was in the rack working on the calibration measurements of the DC PDs at this time and reported that he had plugged a signal into the patch panel.  After this I looked at the A signals again, and they did not make sense any more. I tried repeating the procedure above for A, and found that the phases needed to minimize Q with the light maximized on each quadrant had changed by -15, -10, 0, and -20 degrees for quadrants 1,2,3,4.  

It seems like we need to make a thorough check of the HAM6 racks before we continue trying to make sense of AS WFS.  

Just for the record the momentarily sane phasings were:

segment phase (degrees)
1 -155
2 -175
3 -165
4 -158
Comments related to this report
evan.hall@LIGO.ORG - 03:46, Friday 28 August 2015 (20978)

Stefan and I did a wiggling test of the cables in the HAM6 rack while the interferometer was locked.

We watched AS90I, AS45Q, and all the quadrants of the AS WFS (36 and 45 MHz). The only thing we saw was a 5% fluctuation in AS90I in response to the 90 MHz LO cable being wiggled. [Although once the beam diverter is closed and the AS90 signal is attenuated, the response to wiggling is much stronger—something like 20% to 40% fluctuation.]

H1 CAL (CDS)
jeffrey.kissel@LIGO.ORG - posted 13:30, Thursday 27 August 2015 - last comment - 17:28, Monday 31 August 2015(20958)
IFO Taken down to take LSC and END SUS DAC DuoTone Timing Checks
J. Kissel, K. Kawabe, S. Karki

We've broken observation mode such that we can enable the DAC DuoTone timing readbacks on the front ends that are responsible for DARM control, i.e. h1lsc0, h1susex, and h1susey. We needed to take the IFO down for this because the last channel on the first DAC cards for the end station SUS are used for top-mass OSEMs for damping the suspensions. If the damping loops get a two sign waves at 960 and 961 [Hz] instead of the requested control signal for one of the OSEMs, then we get bad news.

Here are the times when the DAC DuoTone switches were ON for the following front ends:

h1susex and h1susey --- 19:04 to 20:04 UTC (12:04 to 13:04 PDT)
h1lsc0 --- 19:16 to 20:06 UTC (12:16 to 13:04 PDT)

Though all relevant channels (ADC_0_30,  ADC_0_31, DAC_0_15) are free on the h1lsc0 front end, we elected to turn the DAC DuoTone off, so that we aren't in danger of an oscillitory analog voltage being sent around the IO chassis that's used to measure the OMC DCPDs.

Data and analysis to come. 

The IFO will be staying down for a few hours, while we finish up some electronics chain characterization of the OMC DCPD analog electronics (along with some other parasitic commissioning measurements).
Comments related to this report
keita.kawabe@LIGO.ORG - 16:24, Thursday 27 August 2015 (20962)

I showed Sudarshan which signal to look at and how to analyze them. He will make an awesome drawing of how things are connected up in this alog.

The first and second attachment shows the duotone timing of the signals pulled from the IOP channels (all 64kHz). The results are summarized in the following table.

Measurement time (UTC)

IOP ADC0 Ch31 (direct) (us) ADC0 Ch30 (loopback) (us) Round-trip (us)
27/08/2015 19:16:11.0 LSC0 7.34 83.78 76.44
SUS_EX 7.25 68.90 61.65
SUS_EY 7.26 68.93 61.67
27/08/2015 22.32:20.0 ISC_EX (PCALX) 7.32 68.93 61.61
ISC_EY (PCALY) 7.26 68.90 61.84

As per yesterday's alog, duotone is about 7.3usec delayed behind LSC ADC, and actually this turned out to be the case for all ADCs.

According to Zuzsa Marka, duotone was "delayed a bit above 6 microseconds compared to the GPS 1pps" (report pending), so probably this means that the ADC timing (i.e. time stamp of ADC) is decent.

Duotone round trip delay for all IOPs except IOP-LSC0 is about 61us or about 4 64k-clock cycles. For LSC0, this was about 5 64k-clock cycles.

I don't know where the difference comes from. This is totally dependent on how the 64kHz ADC input is taken, routed to 64kHz DAC when "DT DAC" bypass switch is in "ON" position (third attachment), and finally output by DAC, but I don't think there should be difference between LSC and everybody else. At least LSC DAC timing doesn't come into the DARM timing.

The next table is for 16kHz pcal channels on the frame. The measurement results as well as the channel names are shown in the last attachment.

UTC user model ADC0 Ch31 (direct in)
(raw, raw-decimation)
loop back Round trip
27/08/2015 22.07.23.0 CAL-PCALX (63.30, 7.37)

ADC0 Ch30 (direct in without AI and AA)
(raw, raw-decimation)
(124.92, 68.99)

61.62
ADC0 Ch28 (with AI and AA)
377.72
 
CAL_PCALY (63.24, 7.31) ADC0 CH30 (direct in without AI and AA)
(raw, raw-decimation)
(124.89, 68.96)
61.65
ADC Ch28 (with AI and AA)
377.07
 

For Ch31 and Ch30, the routing is done bypassing the user model, the signals are merely imported into the user model and decimated.

Sudarshan found the 4x decimation filter delay to be 19.34deg or 55.93us at 960.5Hz, and "raw-decimation" number is obtained by just subtracting this from the raw number. This is consistent with the 64kHz result, so from now on we can look at 16kHz signals as far as pcal is concerned.

I don't know anything about AA and AI, so I'll leave the analysis to Sudarshan.

Relevant scripts and dtt templates are in /ligo/home/keita.kawabe/Cal/Duotone.

Images attached to this comment
sudarshan.karki@LIGO.ORG - 17:28, Monday 31 August 2015 (21043)

Keita's alog explained the timing on Duotone to ADC and DAC to ADC loop as well. Additionally in pcal, channel 28 is routed through the analog AI and AA chasis. The details about how the channels are connected can be found in the attached schematics.

 

From the schematics we can see there are three (3) 4X decimation filters (two downsampling and one upsampling) in this particular chain (Channel 28). This amounts 3*55.93 us = 167.79 us of delay (each of these filter produce phase delay of 19.34deg or 55.93us at 960.5Hz). The analog AA and AI chassis produce phase delay of 13.76  degrees which amounts to about  39.82 us at 960.5 Hz from each chassis totaling in 79.64 us of time delay.

Total Delay = 3*55.93+2*39.82 =247.73 us.

Column 3  contains the measured (raw) time delay and "raw- total delay".

Column 4 contains the roundtrip time (raw-timedelay-7 us) = ~ 122 us (8-64 KHz cycle).

UTC Channel ADC CH 28 LOOP BACK (FILT DUOTONE) Round trip
27/08/2015 22.07.23.0
CAL_PCALX

ADC0 Ch28 (with AI and AA)

(raw, raw-(3*decimation+2*analog AA/AI))

(377.72, 130.29)

 122.92
CAL_PCALY

ADC Ch28 (with AI and AA)

(raw, raw-(3*decimation+2*analog AA/AI))

(377.07, 129.64)

 122.33
 

 

UTC user model ADC0 Ch31 (direct in)
(raw, raw-decimation)
loop back Round trip
27/08/2015 22.07.23.0 CAL-PCALX (63.30, 7.37)

ADC0 Ch30 (direct in without AI and AA)
(raw, raw-decimation)
(124.92, 68.99)

61.62
ADC0 Ch28 (with AI and AA)
377.72
 
CAL_PCALY (63.24, 7.31) ADC0 CH30 (direct in without AI and AA)
(raw, raw-decimation)
(124.89, 68.96)
61.65
ADC Ch28 (with AI and AA)
377.07
 
 
Images attached to this comment
H1 CAL (CAL)
craig.cahillane@LIGO.ORG - posted 00:26, Thursday 27 August 2015 - last comment - 18:45, Thursday 27 August 2015(20946)
Preliminary Strain Uncertainty Carpet Plots
C. Cahillane

I have managed to use ER7 data produce preliminary carpet plots of frequency vs. strain magnitude and phase based on the Uncertainty Estimation paper T1400586.
The code that generates these plots may be found here: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/S7/Common/MatlabTools/strainUncertainty.m

Darkhan recently did a similar study to this looking at error in magnitude and phase of Delta_L_ext when kappa_C, kappa_A, and f_c changed.  
My study currently looks at the error in magnitude and phase of strain when the magnitude and phase of kappa_tst and kappa_pu vary, as well as kappa_C and f_c.  (Recall that in general kappa_tst and kappa_pu can be complex.)

Right now I believe there is a serious error in the code, because the plot of the optical gain (plot 5) and the plot of the cavity pole (plot 6) show there is absolutely no error in strain even if these values differ greatly from the expected value.  The cavity pole varies by up to +- 100 Hz and does not vary by more than 1%.  The result is robust: I have calculated the strain using two independent methods and still I get these odd results.  These are my results right now, and this is why I call these plots preliminary.

I do believe the magnitude kappa_tst (plot 1), phase kappa_tst (plot 2), magnitude kappa_pu (plot 3), and phase kappa_pu (plot 4) plots look sensible.  Any phase in kappa_tst is generally intolerable for high frequency phase information, while phase in kappa_pu yields high error in low frequency phase information.  Since we do not expect any phase component at all in kappa_tst and kappa_pu, this makes sense.
Also, the magnitude of kappa_tst and kappa_pu must be tracked carefully at high and low frequency respectively.  10% errors in these magnitudes are enough to give more than 9% errors in strain magnitude.

Note that these results use ER7 data (GPS_start = 1116990382).  I'll soon be able to get ER8 data when it is all available (go calibration week!)


Non-image files attached to this report
Comments related to this report
craig.cahillane@LIGO.ORG - 00:41, Thursday 27 August 2015 (20949)CAL
I believe my "no uncertainty" issue with the optical gain and cavity pole may be related to this graph.
The 1/C*d_err term in blue is completely overwhelmed by the A*d_ctrl term.  My reconstruction of hMag may be improperly weighting these two factors.
That is why the Actuation terms (kappa_tst and kappa_pu) have sensible errors, but the Sensing terms (kappa_C and f_c) don't have any effect whatsoever.
Non-image files attached to this comment
craig.cahillane@LIGO.ORG - 18:45, Thursday 27 August 2015 (20969)
I have posted some less preliminary plots of the ER7 data.  I have now dewhitened the data, which has properly scaled the gain such that the inverse sensing term is no longer overwhelmed by the actuation term.  
The spikes everywhere are due to a single-pass fft I have taken.  I am working on a proper fft algorithm now.
Non-image files attached to this comment
H1 ISC
jenne.driggers@LIGO.ORG - posted 21:30, Wednesday 26 August 2015 - last comment - 00:52, Friday 28 August 2015(20939)
Template to decide if OMC DCPD extra whitening is okay

I have created a DTT template that makes it easier to decide when it's okay to turn on more OMC DCPD whitening.

Evan wrote an alog some time ago about the new OMC DCPD whitening on/off guardian states (alog 20578), and Cheryl and Evan made some notes on when it's okay to go to these new states (alog 20787).

As of right now, the guardian will automatically turn on one stage of whitening, but we get better high frequency noise performance if we add a second stage.  However, if some mode (eg. a violin mode) is rung up, then we can't add the second stage of whitening without being in danger of saturating the ADC.  So.  The new DTT template should help decide when it's okay to add the second stage.

The template is /ligo/home/ops/Templates/dtt/DCPD_saturation_check.xml (screenshot below). The template should be run after we have arrived at NOMINAL_LOW_NOISE for the main lock sequence.  If the dashed RMS lines are below the green horizontal line, it's okay to add the second stage of whitening.  

To engage the second stage of DCPD whitening:

Open the full list of guardian states for the OMC_LOCK guardian, and select "ADD_WHITENING". It will take a minute or two, and automatically return to the nominal "READY_FOR_HANDOFF" state.

Images attached to this report
Comments related to this report
rana.adhikari@LIGO.ORG - 16:17, Thursday 27 August 2015 (20965)

could you explain the math & logic a little bit more?

I would have thought that an RMS of 3000 cts is as high as we want to go. Increasing the RMS by a factor of 10 would make it so that its always saturating = not OK. Or isn't this IN1 channel the real ADC input?

evan.hall@LIGO.ORG - 00:52, Friday 28 August 2015 (20975)

Yes, 3000 ct rms = 8500 ct pkpk = too many counts to add a second stage of whitening.

We run with about 10 mA dc on each DCPD, which shows up as 13000 ct or so of dc on the IN1 channels. That means we have something like 19000 ct of headroom before the ADCs saturate on the high side (+32 kct). Assuming the ac fuzz is symmetric about the mean, saturation will certainly occur if the ac is greater than 38000 ct pkpk with two stages of whtening, or 3800 ct pkpk with one stage of whitening.

That's why the criterion I've been using for turning on a second stage of whtening is to look at the IN1 channels and verify that the ac is less than 3000 ct pkpk, or 1000 ct rms when there is only one stage of whitening on. If we find the DCPDs saturating too often with two stages, we should be even more restrictive.

H1 ISC
daniel.sigg@LIGO.ORG - posted 19:02, Wednesday 26 August 2015 - last comment - 03:30, Friday 28 August 2015(20930)
RF AM at 45.5MHz

Evan Stefan Daniel

The second EOM driver was installed in the CER using the 9MHz control and readback channels. The first attached plot shows the DAQ readback signals. Both drivers show the similar noise levels for the in-loop and out-of-loop sensors. They are also coherent with each other as well as ASC-AS_C! The in-loop noise is clearly below which would indicate that the signal is suppressed to the sensor noise. The measured out-of-loop noise level is also a factor of 4 higher than the setup in the shop.

The second plot shows the same traces but this time the ifr is feeding the EOM driver in the CER. As expected its out-of-loop noise level is now consistent with measurements in the shop and no longer coherent with the unit in the PSL.

We were starting to suspect that we are looking at down-converted out-of-band noise...

Non-image files attached to this report
Comments related to this report
evan.hall@LIGO.ORG - 03:24, Thursday 27 August 2015 (20950)

Using a network analyzer, we took the following measurements:

  • rf spectrum of 45.5 MHz from harmonic generator + distribution amplifier in CER,
  • rf spectrum of 45.5 MHz from IFR in CER,
  • rf spectrum of 45.5 MHz from spare harmonic generator in the EE shop,
  • rf spectrum of 9.1 MHz from OCXO + distribution amplifier in CER,
  • audio-band spectrum of out-of-loop RAM readback of EOM driver, using harmonic generator as 45.5 MHz source, and
  • audio-band spectrum of out-of-loop RAM readback of EOM driver, using IFR as 45.5 MHz source.

The first four of these are shown in the attached plot [the OCXO has been multiplied by 5 in frequency for the sake of comparison]. The message is that the 45.5 MHz in the IFO distribution system has huge, broad wings out to 2 MHz away from the carrier. These are not seen on the IFR, the harmonic generator on the bench, or the 9.1 MHz in the distribution system.

Although the EOM driver still works to suppress some of the RFAM below 50 kHz, the broad wings still contribute significantly to the rms; most of it is accumulated above 200 kHz offset from the carrier. This is shown in the second attachment.

Non-image files attached to this comment
evan.hall@LIGO.ORG - 03:30, Friday 28 August 2015 (20977)

I looked again at some rf spectra in the CER.

These peaks appear on every output of the harmonic generator, even when it is not driving any distribution amplifiers (just a network analyzer).

These peaks also appear even when the harmonic generator is driven by +12 dBm of 9.1 MHz from an IFR (not from the OCXO + distribution amplifier).

This suggests we should focus on the harmonic generator or its power supply.

H1 INJ (INJ)
eric.thrane@LIGO.ORG - posted 22:57, Tuesday 25 August 2015 - last comment - 17:17, Thursday 27 August 2015(20893)
CBC Injection Test For Saturation + First Blind Injection Test
Patrick, Sheila, Jenne, Eric

For the first part of the test, we injected our fiducial CBC waveform (same one used in ER7) and tried raising the LIMIT value on the hardware injection block in order to address saturation problems observed in ER7. During ER7, the LIMIT was 200. We raised it to 400. The first injection did not go through:

1124601535 1 1.000000 cbctest_1117582888_		intent bit off, injection canceled

Patrick, Sheila, and Jenne tried to turn on the intent bit, but there was some sort of problem, which will be alog'ged separately. As a temporary work-around, we turned off the tinj intent-bit check and injected again:

1124602724 1 1.000000 cbctest_1117582888_		successful

Patrick determined that the injection produced a maximum |amplitude| of 15 counts coming out of the injection block, which seemed to indicate that the original LIMIT value of 200 was sufficient. However, an alarm went off to indicate that there was saturation at ETMY. Thus, the saturation problem cannot be solved by tinkering with the INJ block in MEDM. Rather, the problem is occurring downstream on the ETM actuators. We request that Jeff K, Adam M, et al. look into options for avoiding saturation at the ETMs.

Next we tried a blind injection using the new blind injection code. The blind injection code does not log injections in EPICS so they are not automatically picked up in the segment database.

1124603111 1 1.000000 cbctest_1117582888_		successful

The blind injection was clearly visible. The ETM saturation warning went off again. The injection was logged correctly in the blind injection blindinj_H1.log:

current time = 1124603049...
Attempting: awgstream H1:CAL-INJ_BLIND_EXC 16384 /ligo/home/eric.thrane/O1/Hardw
areInjection/Details/Inspiral/H1/cbctest_1117582888_H1.out 1 1124603111
Injection successful.

All of these injections were carried out with scale factor = 1; (that's the 1.000000). The injection file, described in a comment below, is a 1.4 on 1.4 BNS, optimal orientation, at D=45 Mpc. It is the same waveform used in previous ER tests.
Comments related to this report
andrew.lundgren@LIGO.ORG - 00:49, Wednesday 26 August 2015 (20894)DetChar, INJ
It looks like the injection actually does hit the 400 count limit (plot 1). It saturates right at the end when the injection chirps up to high frequency. There's some kind of ringing as well (plot 2). From the spectrogram (plot 3) and the zoom (plot 4) this looks like a feature at just above 300 Hz. I thought it might be a notch for the PCal line, but that's 331.9 Hz. So someone will have to check the inverse actuation filter and see what's happening at that frequency.

It's possible to see the overflow from the first injection in the ETMY L3 MASTER channel (plot 5). It happens at -131072 counts, and the injection is trying to push it past -200000. The blind injection caused an overflow as well, but since this channel is only recorded at 2048 Hz, it looks like it falls short of overflow (plot 6). There's a faster readback whose name escapes me at the moment.

Unless the blind injection is made a factor of about 10 smaller, or rolled off at high frequency, it will be trivial to detect it by looking at the drive to the ETM.
Images attached to this comment
eric.thrane@LIGO.ORG - 04:24, Wednesday 26 August 2015 (20901)INJ
FYI, the injected waveform was fiducial waveform from ER7:

https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=16125

It's a 1.4-1.4 BNS at 45 Mpc, optimal orientation.
duncan.brown@LIGO.ORG - 05:06, Wednesday 26 August 2015 (20904)

There are a couple of things to watch out for when performing CBC hardware injections, based on iLIGO experience:

  • In iLIGO, the actuation function had a notch at the violin-mode frequencies. If you just invert A(f) without smoothing this out, the notch will get inverted and you'll give the the mirrors a hard kick as the inspiral sweeps through the notch frequency. (My guess is that Adam and Jeff have already dealt with this, though.)
  •  If the end of the inspiral signal is not smoothly rolled off and the signal drops from some loudish amplitude to zero then you put a step function in. This caused the iLIGO test mass to swing at its pendulum frequency, putting a huge ringdown in the data (called the "whooper" in iLIGO). In iLIGO, the CBC group generated waveforms in counts, by applying 1/A(f) ourselves using the adiabatic inverse calibration, so we smoothed 1/A(f) ourselves before applying it. In aLIGO, 1/A(f) is: (i) more complicated, and (ii) applied in the front end by IIR filters. It is possible that the sharp turnoff of the CBC injection at the end is causing the filters that apply 1/A(f) to ring and that's what's giving us garbage at the end of the signal.

For the ER7 injection we used an SEOBNRv2 waveform that has a ringdown at the end, hoping that this turn off would not trigger an impulse. However, for BNS masses, the turn off and ringdown is pretty sharp. I've asked Chris check that there are no "whooper" effects with the SEOBNRv2 waveform, but we haven't had chance to do this yet. For a SpinTaylorT4 waveform (the other waveform CBC wants to inject), there will definitely be a step, so this needs to be checked and rolled off carefully.

duncan.brown@LIGO.ORG - 05:08, Wednesday 26 August 2015 (20905)

One other comment on the test: what scaling in awgstream did you use? That waveform looks monstously loud (eyeball SNR > 20). That's much louder than would be useful for a blind injections, but good for helping us find whooper effects.

eric.thrane@LIGO.ORG - 16:44, Wednesday 26 August 2015 (20928)INJ
Duncan, the scale factor is 1.
andrew.lundgren@LIGO.ORG - 14:27, Thursday 27 August 2015 (20959)DetChar, INJ
Just for completeness, because I didn't see it posted, here's an Omega scan of the injections in h(t). The first is the non-blind injection, the second is the blind injection. I think the glitch ten seconds after the blind injection is unrelated. I thought it might be a filter turning off or being reset, but it's not on a GPS second (it's at 1124603210.28). It does cause an overflow of the ETMY ESD DAC.
Images attached to this comment
peter.shawhan@LIGO.ORG - 17:17, Thursday 27 August 2015 (20966)INJ
I verified that the blind injection was correctly recorded in the raw frame file.
Displaying reports 57581-57600 of 78016.Go to page Start 2876 2877 2878 2879 2880 2881 2882 2883 2884 End