Displaying reports 57181-57200 of 78025.Go to page Start 2856 2857 2858 2859 2860 2861 2862 2863 2864 End
Reports until 09:23, Friday 11 September 2015
LHO General
thomas.shaffer@LIGO.ORG - posted 09:23, Friday 11 September 2015 (21398)
Out of Observing

Out of Observing due to some SDF work and a few maintenance items.

H1 DAQ (CDS)
james.batch@LIGO.ORG - posted 09:23, Friday 11 September 2015 (21397)
The h1tw0 trend writer has been restarted
The raw minute SSD RAID has been rebuilt, and h1tw0 is now writing raw minute trend data to it's disk.  Since data from April 14 to present was lost, we will evaluate if data recorded from h1tw1 can be used to fill in the gap.
H1 General
cheryl.vorvick@LIGO.ORG - posted 08:03, Friday 11 September 2015 (21396)
OPS OWL Summary:

Sheila and Evan here for a few hours, and Sheila a bit more, then we put the IFO into Observation, and It's been locked since.

One DIAG_MAIN Guardian glitch where it lost the connection to the nds server.  I reloaded, and it reconnected.

H1 ISC
sheila.dwyer@LIGO.ORG - posted 03:18, Friday 11 September 2015 - last comment - 03:37, Friday 11 September 2015(21394)
looking at refl WFS for SR3 control

Evan, Sheila, Cheryl 

After realizing that T0900511 suggests using REFL 45 for SRC control and only using AS36 for the BS (not any SRC controls), we decided to have a look at the REFL 45 WFS tonight.  Indeed, what we see is rather consistent with what is predicted T0900511.

We have known for a while that the phasing of the refl 45 WFS is wrong (we are subtracting a lof of our signals), so we would like to fix that before attempting to use them in an additional loop.

First we disengaged the PRC2 loop (combination of REFL 9+45 A+B to PR3) at 23 Watts, we reverted the phases of the refl wfs to the ones we found in 20811 .  We checked that these are still phases where the CHARD signal is in the Q phase, and we checked the transfer function from a CHARD PIT excitation to each quadrant.  The phases for the individual quadratures are consistent with a pitch signal.  

We also drove PR3 and SR3 PIT and measured the transfer function to each quadrant of refl 45.  The measurement was a little tricky for PR3.  At first we drove at 8 Hz, and got a signal that looked mostly like a length sigal (same phase on all 4 quadrants).  We added a resG filter (which is now loaded in PRM M3 ISCINF), which changed the quadrant TF phases to be somewhat PITCH like.  We then drove at 3 Hz to be well within the bandwidth of all our LSC loops, and got quadrant TF phases that would prodce a pitch signal for a pitch drive.  

We then looked at the DC signals and moved optics around to see what gave us a good signal.  The matrix that you would guess based on T0900511 seems like a good one:  REFL 45 A + B I to PR3, REFL 45 A - B to SR3, and we have CHARD signal in REFL 45 A + B Q.  

After a lockloss that I caused by moving optics too far, Cheryl brought the IFO back up and we engaged the ASC with the new REFL 45 phases, and a matrix that did not include any refl 9 signals for PR3.  This seemed OK although the turn on was a bit rough.  At 10 Watts and 15 Watts things also seemed fine, but at 20 Watts we had our usual runaway, with POP 90 increasing.  

Comments related to this report
sheila.dwyer@LIGO.ORG - 03:37, Friday 11 September 2015 (21395)

I left a few alingment offsets different after working on ASC, so SDF was red.  We accepted SR3 and PR3 alignment values.  We thought about not monitoring these channels, but they don't change every lock.  

H1 AOS
jeffrey.bartlett@LIGO.ORG - posted 00:28, Friday 11 September 2015 (21392)
Evening Shift Summary
Title: 09/10/2015, Evening Shift 23:00 – 07:00 (16:00 – 00:00) All times in UTC
Support: Jenne, Evan, Jeff K., Sheila 
Incoming Operatror: Cheryl
Shift Summary: 
- Attend operators training meeting until 23:10 (16:10)
- In Maintenance Mode due to S&K Electronics hammering drilling at End-Y 
- S&K Electronics finished – Turn IFO over to Kiwamu for commissioning work
- Repaired leak in OSB sprinkler system – Have informed Facilities
- Dropped out Observing mode to Commissioning – Turn IFO over to Evan for commissioning work. LLO was not in Observing Mode.

Activity Log: All Times in UTC (PT)

23:15 (16:15) Take over from TJ
23:15 (16:15) IFO locked at NOMINAL_LOW_NOISE, 22.7W, 60Mpc
23:34 (16:34) Switch Observatory Mode from Maintenance to Commissioning
01:24 (18:24) Dick G – Out of the Optics lab
02:01 (19:01) Set intent bit and Observatory Mode to Observing at 22.7W 72Mpc 
02:50 (19:50) Lockloss – Cause unknown
03:14 (20:14) IFO locked at NOMINAL_LOW_NOISE, 22.6W, 69Mpc
03:16 (20:16) Set intent bit and Observing Mode to Observing
03:24 (20:24) Commissioners reloaded Guardian code – DID NOT DROP OUT OF OBSERVING
04:42 (21:42) Drop to Commissioning mode per commissioner’s request
07:28 (00:28) Turn over to Cheryl
H1 CAL (CAL)
darkhan.tuyenbayev@LIGO.ORG - posted 00:05, Friday 11 September 2015 (21391)
Updated EPICS values for DARM time-varying parameters (canonical param. set for O1)

EPICS values used for calculation of DARM time-varying parameters (DCC T1500377) in GDS pipeline and with PCALMON data were updated on 10-Sep-2015,   23:38:17 PDT (11-Sep-2015,   06:38:17 UTC) using H1 DARM model with canonical parameter set for ER8/O1 (LHO alog 21386).

There is an additional phase of 136.7 degrees that was fudged into H1:CAL-CS_TDEP_REF_INVA_CLGRATIO_TST_(REAL|IMAG). This value is used for calculation of kappa_{tst} (the phase fudge factor was introduced one day ago, see LHO alog 21358). We are investigating the source of this discrepancy.

New values were accepted in SDF_OVERVIEW.

Output files (raw epics values, more verbose log and a matlab file with EP# variables that correspond to table 2 in T1500377 convention) were committed to the calibration SVN directory: (detailed log is also attached to this alog):

CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/CAL_EPICS/

The EPICS values correspond to the model file and the parameter file in calibration SVN at rev. 1381:

CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/DARMOLGTFs/H1DARMOLGTFmodel_ER8.m

CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/DARMOLGTFs/H1DARMparams_1124954397.m

Non-image files attached to this report
H1 AOS (CAL)
craig.cahillane@LIGO.ORG - posted 22:31, Thursday 10 September 2015 (21390)
Preliminary Strain Uncertainty
I have produced first-order plots of the magnitude and phase strain uncertainty.
These plots look very good mostly because I am using only statistical uncertainty, and in some cases eyeballing the systematics from residual plots to get an idea of our final uncertainty.
These are the values of sigma I used for the various parameters important to strain:

σ_|A_tst| = 0.01*abs(A_tst);    1% uncertainty
σ_|A_pu| = 0.039*abs(A_pu);     3% uncertainty
σ_|C_r| = 0.01*abs(C_r);        1% uncertainty
σ_|kappa_tst| =  0.0040;        std of first order |kappa_tst| calculations
σ_|kappa_pu| = 0.0066;          std of first order |kappa_pu| calculations
σ_φ_A_tst = 5;                  5 degree assumption
σ_φ_A_pu = 5;                   5 degree assumption
σ_φ_C_r = 5;                    5 degree assumption
σ_φ_kappa_tst = 0.27;           std of first order phi_kappa_tst calculations
σ_φ_kappa_pu = 0.35;            std of first order phi_kappa_tst calculations
σ_kappa_C = 0.0049;             std of first order kappa_C calcs
σ_f_c = 23.4731;                std of first order f_c calcs

Plots 1 and 2 are the Magnitude and Phase Uncertainty Plots using the Response function.  Recall the Response function R = (1 + G) / C.  I will also have the "Two Signal" calibration uncertainty (h = DARM_ERR / C + A * DARM_CTRL), and I expect them to coincide nicely someday soon.
Note that the max uncertainty in magnitude is ~4% at 30 Hz and the max uncertainty in phase is ~7 degrees.  (Remember that these are first order plots, but this is surely auspicious!)

Plots 3 and 4 are the squared component plots where we can see which parts of the uncertainty dominate where.
For magnitude, phi_A_pu and phi_A_tst dominate at low frequency and phi_C_r dominates at high frequency.
For phase, phi_A_pu dominates at low frequency and phi_C_r dominates at high frequency.

Next I will ensure the Two Signal and Response Function uncertainties are similar, then I will begin to inform our sigmas more intelligently.
Non-image files attached to this report
H1 ISC
jenne.driggers@LIGO.ORG - posted 21:02, Thursday 10 September 2015 (21389)
PRCL gain not being changed properly by guardian - race condition now fixed

As part of my clearing of SDF earlier (alog 21387), I found that the LSC-PRCL_GAIN did not match the value in the observe.snap file. 

The gain is set to 8 during the DRMI acquisition, but then is supposed to be changed to 6 during CARM_15PM in the CARM offset reduction sequence in the ISC_GUARDIAN.  This change is supposed to happen during the run part of the state, after some timers have completed, and after some other things have finished.  However, the conditional for exiting the state didn't include a "if self.counter == 1" statement, so depending on which of 2 timers finished first, we either would or would not change the PRCL gain.  Thumbs down to that.

As can be see in the plot from Evan below, over the last week some of our long locks have had a PRCL gain of 6, and others have had a gain of 8.  Not good.

I fixed the conditional, so now it will always change the PRCL gain appropriately before exiting the CARM_15pm state.  We reloaded the guardian at 03:24 UTC. 

Images attached to this report
H1 General
jeffrey.bartlett@LIGO.ORG - posted 20:38, Thursday 10 September 2015 (21388)
Evening Mid Shift Summary
Generally a good first half of the shift. Commissioning work was successful. Wind speed and seismic activity low.Had a ~4 hour lock at 68+Mpc  
Lost lock at 02:50 - cause unknown - Relocked and in Observing mode at 03:16. 

NOTE: Commissioners reloaded Guardian code at 03:24 and the IFO did not drop out of Observing Mode.   
H1 CAL
kiwamu.izumi@LIGO.ORG - posted 20:09, Thursday 10 September 2015 - last comment - 15:10, Tuesday 15 September 2015(21385)
New calibration in place in CAL-CS, 10% magnitude error, 5 deg phase error in 10 - 1200 Hz

Jeff, Darkhan, Sudarshan, Craig, Kiwamu,

 

We have updated the calibration filters in CAL-CS with the latest filters.

With a Pcal sweep measurement, we have confirmed that the current calibration is accurate within 10 % in magnitude and 5 deg in phase.

Calibration on the front end side is done.


(Verification measurement)

 

 

The above screen shot shows a measured transfer function from displacement estimated by Pcal Y to displacement estimated by CAL-CS. They agree within +/- 10 % in magnitude and +/- 5 deg in phase all across the frequency band we swept. Note that one data point at 10 Hz showed magnitude that is slightly above 10%, but this was not repeatable and therefore we don't think it is a reliable data point. We measured the same transfer function three times within the same lock stretch and saw the magnitude changing to a value between 0.85 and 1.1 at this particular frequency point. We are guessing that this is due to a bounce mode confusing our measurement.

Also, even though the coherence was high all across the frequency band, the data points below 30 Hz seemed to change in magnitude in every sweep. So we increased the integration time from 3 sec to 6 sec which seemed to improved the flatness.

The optical gain was adjusted by measuring the sensing function with a Pcal sweep within the same lock stretch. This gave me a 341 Hz cavity pole (which is the same as two nights ago, alog 21352) and an optical gain of 8.834e-7 meters/counts. Both the parameters are now loaded into the CALCS foton file and enabled.

 

(Phase correction)

Sudarshan will make a separate alog on this topic, but a trick to get this beautiful plot was to properly incorporate the know time delays. Based on our knowledge, we have included a 115 usec = (41 + 61 + 13 usec) time delay. If we did not remove the delay, the phase would have been off by 40 deg at 1 kHz.

 

(An extra measurement)

Independently of the calibration validation measurement, we did a simple measurement -- check the binary range with and without the calibration lines. Here is the relevant time stamps:

We will check the range later.

Images attached to this report
Comments related to this report
kiwamu.izumi@LIGO.ORG - 09:45, Friday 11 September 2015 (21399)

All the data are accessible at the following SVN locations:

DARM open loop measurements

aligocalibration/trunk/Runs/ER8/H1/Measurements/DARMOLGTFs/2015-09-10_H1_DARM_OLGTF_7to1200Hz.xml

aligocalibration/trunk/Runs/ER8/H1/Measurements/DARMOLGTFs/2015-09-10_H1_DARM_OLGTF_7to1200Hz_halfamp.xml

For the analysis, I have used the first measurement. The second measurement was meant to assess repeatability of the measurement by applying the half size of the usual excitation in DARM.

 

 

Pcal to DARM responses:

aligocalibration/trunk/Runs/ER8/H1/Measurements/PCAL/2015-09-10_PCALY2DARMTF_7to1200Hz.xml

aligocalibration/trunk/Runs/ER8/H1/Measurements/PCAL/2015-09-10_PCALY2DARMTF_7to1200Hz_v2.xml

aligocalibration/trunk/Runs/ER8/H1/Measurements/PCAL/2015-09-10_PCALY2DARMTF_7to1200Hz_v3.xml

The final plot, that I have posted above, is from the third measurement in which I have doubled the integration time in order to obtain better signal-to-noise ratio.

 

 

DARM paramter file (as reporeted in alog 21386):

aligocalibration/trunk/Runs/ER8/H1/Scripts/DARMOLGTFs/H1DARMparams_1125963332.m

evan.hall@LIGO.ORG - 15:10, Tuesday 15 September 2015 (21548)

On 2015-09-12 06:30:00, the gain from the DCPD sum to DARM IN1 was 3.477×10−7 ct/mA. Therefore, using Kiwamu's number of 8.834×10−7 m/ct, this gives the optical gain as 3.26 mA/pm. (One stage of DCPD whitening.)

H1 CAL (CAL, DetChar, INJ, ISC, SYS)
jeffrey.kissel@LIGO.ORG - posted 19:28, Thursday 10 September 2015 - last comment - 16:15, Sunday 13 September 2015(21386)
CAL-CS Calibration Parameters Updated; Info on DARM Loop Parameters for which GDS Pipeline will Compensate
J. Kissel, for the LHO CAL Team

Spoiler Alert: Kiwamu has updated the sensing side of front-end calibration, and has tuned the CAL-CS model to match a fit to the current optical gain of this lock stretch. 
This means the CAL-CS calibration has been updated, and is now complete for O1.

He has analyzed the results, and created the cannonical parameter set for O1. That parameter set is:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/DARMOLGTFs/H1DARMparams_1125963332.m

This should be run with the now canonical model:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/DARMOLGTFs/H1DARMOLGTFmodel_ER8.m

To push things forward while he gets a final super-long integration time comparison between PCAL and the CAL-CS model, we give this parameter set to Maddie such that she can you it to inform the parameters of the high-frequency corrections to the output of the CAL-CS model.

In summary, those corrections are 
(1) The precisely known time delays (advances) for the (inverse) sensing and actuation chains
(2) The compensation for the average of the uncompensated, high-frequency poles in the OMC DCPD's readout chain.

%% Details:
Note that, though there are uncompensated, 24e3 [Hz] poles in the ESD response portion of the actuation chain, we have chosen in ER8/O1 to ignore these poles. Preliminary results from craig indicate that we're sitting at ~3 or 4 degrees strain uncertainty at 30 [Hz] (right where the PUM / TST cross-over lies, as expected)  and ignoring this pole corresponds to a 0.07 [deg] systematic error, i.e. negligible. So, the above two items should be the only difference between the CAL-CS front-end model (the relative time-delay between the paths, which affects ERR and CTRL crossover, and the uncompensated poles, which means there's a 15 [deg] phase loss at 1 [kHz]).

To obtain these values from code in the SVN, run
[openloop,par] = H1DARMOLGTFmodel_ER8(H1DARMparams_1125963332);
and the values you (Maddie) need(s) are
(1) The precisely known time delays (advances) for the (inverse) sensing and actuation chains:
    - Sensing Delay (or Inverse sensing advance): par.t.sensing + par.t.armDelay =  8.9618e-05 [s]
    - Actuation Delay: par.t.actuation = 1.4496e-04 [s]

(2) The high-frequency poles in the OMC DCPD's readout chain:
    - par.C.uncompensatedomcpoles_Hz = 13700       17800       14570       18525       98650 [Hz]
    or you can use the preformulated LTI object,
    - par.C.uncompensatedomcdcpd.c
           ans =
                                    6.3585e+25
         ----------------------------------------------------------------
         (s+8.608e04) (s+9.155e04) (s+1.118e05) (s+1.164e05) (s+6.198e05)


Stay tuned for aLOGs from Maddie over the next day or so, as she compares the output of the CAL-CS model with the output of the GDS pipeline.

Thanks to everyone for all the hard work!!
Comments related to this report
jeffrey.kissel@LIGO.ORG - 16:15, Sunday 13 September 2015 (21472)
M. Wade, J. Kissel

In the above list of for what the GDS pipeline must correct, I've neglected several pieces of both chains -- the anti-aliasing and anti-imaging filters of the sensing and actuation chains, respectively. I've slept a little more, and I repeat the list that is now complete:

In summary, those corrections are 
(1) The precisely known time delays (advances) for the (inverse) sensing and actuation chains
(2) The compensation for the average of the uncompensated, high-frequency poles in the OMC DCPD's readout chain.
(3) The digital and analog anti-aliasing filters in the sensing chain
(4) The digital and analog anti-imaging filters in the actuation chain

In more detail,

Actuation: 
(1) Actuation Delay
   -- par.t.actuation = 1.4496e-04 [s]

     
(3) The digital and analog anti-imaging filters (now separated, due their export as LTI objects; they cannot be combined (without squeezing on to a frequency vector) because one is a discrete zpk, the other is a continuous) 
Digital Anti-Imaging Filter (a.k.a. IOP up-sampling filter) 
   -- par.A.antiimaging.digital.response.ssd
Analog Anti-Imaging Filter 
   -- par.A.antiimaging.analog.c

Sensing
(1) Sensing Delay (or Inverse sensing advance): 
   -- par.t.sensing + par.t.armDelay =  8.9618e-05 [s]

(2) The high-frequency poles in the OMC DCPD's readout chain:
   -- par.C.uncompensatedomcpoles_Hz

(4) The digital and analog anti aliasing filter 
Digital Anti-Aliasing Filter (a.k.a. IOP down-sampling filter)
   -- par.C.antialiasing.digital.response.ssd
Analog Anti- Aliasing Filter 
   -- par.C.antialiasing.analog.c
H1 AOS
jeffrey.bartlett@LIGO.ORG - posted 17:30, Thursday 10 September 2015 (21384)
Day/Evening Transition Summary
Title: 09/10/2015 Evening Shift 23:00 - 07:00UTC (16:00 - 00:00) All time in UTC
State of H1: Maintenance mode, 68Mpc for last 2 hours
Outgoing Operator: TJ
Quick Summary: In maintenance mode because S&K electronics working at End-Y. Commissioning work ongoing. Wind below 10mph. No significant seismic activity. Monitors and displays are normal.     
LHO General
thomas.shaffer@LIGO.ORG - posted 16:50, Thursday 10 September 2015 (21383)
Ops Day Shift

Summery:

A few maintenance tasks brought us out of Observing mode and while these were being done, people took advantage of the time to take measurements.

 

Log:

UTC (PST)

H1 SEI
hugh.radkins@LIGO.ORG - posted 16:23, Thursday 10 September 2015 (21380)
HEPI Pump Station ALarm Handler Adjusted--Better!

Duhhh.  To get rid of the nuisance alarms from bothering the operators, of which the HEPI Pump Station EX contributes,  I just needed to filter the alarm.  ALH has the ability.  So now the Pump Pressure has to be in continual alarm for 5 seconds before it will alarm.  With the glitchy nature of the EndX pressures this is not likely unless a real problem is occurring.  The filtering occurs for all the controllers.  The MINOR alarm is set to +-2psi and the MAJOR alarm is +-5psi.  Also, this allows the controller to be restarted with the default epics values and the alarm levels do not need to be reset for the handler.

The file is under svn control and is committed.

H1 INJ (CAL, ISC)
jeffrey.kissel@LIGO.ORG - posted 16:00, Thursday 10 September 2015 (21379)
Study of ETMY L3 LOCK Bank Notches in prep for Inverse Actuation Filter Design
J. Kissel, P. Fritschel

We have recently been reminded that, in the past (prior science runs with the initial detectors), the inverse actuation filter did not include inverse of all the necessary notch filters in the DARM actuation function. This reminder came from early ER8 analysis (LHO aLOG 20893 and subsequent comments). All of these notch filters live in one digital filter bank in the actuation chain, up-stream of the DARM filter bank. Remember that the injection point for hardware injections is currently just up-stream of the DARM filter bank, in the LSC portion of the OMC front end model, passed in from the CAL-CS front-end model over IPC.

In studying this a little more carefully, Peter pointed out that if we don't include the notches, the phase distortion (with respect to a perfect inversion of the actuation function) will be quite significant (10s of degrees), even well-out-side the frequency region that one might niavely think is impacted when only looking at the magnitude.

I attach several plots of the same thing in various formats to show this affect.

H1 Mini-run Filter LHO aLOG 18115
H1 ER7 Filter LHO aLOG 18997 (not installed until halfway through ER7, and known to have problems: )

In the mini-run design, I had slapped something quickly together because we were strapped for time, that quick approximation did not include any notches -- but mostly because we hadn't yet started nothing these features out of the DARM loop yet. In ER7, we had installed some of our notches, and I took my time to tailor the inverse filter to be very close to the full model of the inverse actuation filter. 

LLO has replicated the inverse actuation function without notch filters for ER7 LLO aLOG 18499. 
ER6 design was similar to LHO's Mini-run's design -- something simply to get us started LLO aLOG 16129.

We intend to discuss this with the hardware injection team, and more appropriately with the search groups as to how we should proceed. 
Non-image files attached to this report
H1 General
betsy.weaver@LIGO.ORG - posted 14:39, Thursday 10 September 2015 - last comment - 21:02, Thursday 10 September 2015(21372)
New SDF configuration for OBSERVE mode continued

Betsy, Hugh

There are some channels which we have identified with SDF that change between lock stretches and should therefore be not monitored.  So far, Hugh and I have set the foolwing to not be monitored:

- SR3 CAGE SERVO OFFSET -SR3_M2_TEST_P_OFFSET)

- BSC ISI CPS SETPOINTS_NOW

- IMC PZT P/Y OFFSETS

- LSC PSL-POWER_SCALE_OFFSET

- ALS CAMERA SERVO SETTINGS (ALS_CAM)

- PSL-ISS_REFSIGNAL and PSL-ISS_SECONDLOOP_REF_SIGNAL_ANA

 

We have not set the alignment sliders to be NOT MONitored so be prepared to set those tonight as needed:

ALL SUS OPTICALIGN P/Y OFFSETS

 

Again, if you run into problems with red alarms on any SDF screen that is blocking you from hitting the Intent bit, please 1) check with your commissioners to clear any temporary changes and then 2) set the outstanding channels to NOT MON and we will audit them tomorrow when we continue on this work.

Comments related to this report
jenne.driggers@LIGO.ORG - 21:02, Thursday 10 September 2015 (21387)

In prep for going to Observe this evening, I NOT MONed a few channels.  All of these should stay NOT MONed.

  • H1:SUS-IM4_M1_OPTICALIGN_P_OFFSET
    • In general, will be slightly different each lock.
  • H1:SUS-SRM_M1_OPTICALIGN_P_OFFSET
    • In general, will be slightly different each lock.
  • H1:SUS-PR2_M1_OPTICALIGN_Y_OFFSET
    • In general, will be slightly different each lock.
  • H1:SUS-SR2_M1_OPTICALIGN_Y_OFFSET
    • In general, will be slightly different each lock.
  • H1:ALS-C_DIFF_PLL_CTRL_OFFSET
    • Adjusted by guardian each lock.
  • H1:OMC-READOUT_ERR_GAIN
    • Calculated and written by guardian each lock.
  • H1:LSC-REFLAIR_B_RF27_I_OFFSET
    • Measured and set by guardian each lock.
  • H1:LSC-REFLAIR_B_RF27_Q_OFFSET
    • Measured and set by guardian each lock.
  • H1:LSC-REFLAIR_B_RF135_I_OFFSET
    • Measured and set by guardian each lock.
  • H1:LSC-REFLAIR_B_RF135_Q_OFFSET
    • Measured and set by guardian each lock.
  • H1:LSC-TR_X_QPD_B_SUM_OFFSET
    • Measured and set by guardian each lock.
  • H1:LSC-TR_Y_QPD_B_SUM_OFFSET
    • Measured and set by guardian each lock.

In addition, the new epoch of SDF caught something, that we may not have caught without it. See alog 21389 for details, but the LSC-PRCL gain was not correct.  It was reverted by hand, and then the guardian bug was fixed.  We used to have this channel "NOT MON"ed by SDF (since it is changed by guardian), which is likely why we haven't noticed this before.

H1 ISC
evan.hall@LIGO.ORG - posted 12:29, Thursday 10 September 2015 - last comment - 15:30, Tuesday 19 January 2016(21357)
DCPD sum and null

Sheila, Evan

Since we have recently gotten rid of the excess oscillator AM noise in DARM, we wanted to look at the residual of the DCPD sum and null. This test has been done at LLO several times (most recently here).

Unlike the previous look at this noise, we decided to follow the LLO technique and notch the DARM loop by 20 dB between 100 Hz and 700 Hz. In order to do this, we had to reduce the DARM ugf to 20 Hz or so. Unfortunately, this rang up the quad bounce modes. Rather than recommission the bounce mode damping, we just turned it off and collected the sum/null data in a few 20-minute intervals, and then applied damping inbetween using the usual DARM loop shape. In total we collected a little over an hour's worth of data, with the usual 20 mA of current on the sum. The attached plot shows the data processed into 1-second ASDs.

The dc current of the sum was 20.0 mA, meaning we expect a shot noise of 8.00×10−8 mA/Hz1/2. On the other hand, the ratio of sum/shot and null/shot (attached) indicates that we might be too low by a few percent. It's a bit complicated, since it relies on a combination of the frontend calibration (Koji's preamp and whitening compensation filters) and a post facto calibration (Kiwamu's combination of the IOP inversion, the supernyquist preamp poles, the AA response, and the mystery 10.7 kHz pole).

Images attached to this report
Non-image files attached to this report
Comments related to this report
gabriele.vajente@LIGO.ORG - 09:25, Thursday 10 September 2015 (21365)DetChar

Why is the coherence between A and B not one at the jitter peaks (300-400 Hz)?

You band-stopped the DARM loop in that region, so there should be no correlation induced by DARM. So I would expect that the coherence is one, if the peaks are coming through intensity noise on the laser beam (possibly converted from jitter by the OMC). Instead there is low coherence, which seems to me not compatible with the shot noise level: this is visible in Evan's plot too, since the uncorrelated noise is closer to the value of the sum than to the null...

Two hypothesis 

  1. this is reidual jitter that couples on the diodes due to some non homogeneity
  2. I'm missing something in this analysis
Images attached to this comment
evan.hall@LIGO.ORG - 14:29, Thursday 10 September 2015 (21376)

I think the numbers hang together. Let SAA = S00 + SA'A' and SBB = S00 + SB'B', where S00 is the PSD of the correlated component of the noise between the DCPDs, and SA'A' and SB'B' are the PSDs of the uncorrelated noises on each PD.

From last night's data, at 315 Hz we have SAA = SBB = (1.14×10−7 mA/Hz1/2)2. Looking nearby at 540 Hz, where the DCPDs seem to be shot-noise dominated, we can estimate SA'A' = SB'B' = (0.577×10−7 mA/Hz1/2)2, so therefore S00 = (0.983×10−7 mA/Hz1/2)2.

For the CSD, we have SAB = S00.

Therefore, the coherence we expect is γ2 = |SAB|2/(SAA×SBB) = 0.55.

Or in terms of the PSDs of sum (S++) and null (S−−), the coherence should be γ2 = [(S++ − S−−)/(S++ + S−−)]2.

Images attached to this comment
gabriele.vajente@LIGO.ORG - 16:48, Thursday 10 September 2015 (21382)

I agree with your computations. But why is your projection of the residual showing the peaks? it should line up with the shot noise if that's what is limiting the coherence.

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

Dan, Evan

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

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

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

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

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

Transfer function please.

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

TFs of the yaw measurement attached.

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

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

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

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

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

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

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

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

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

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

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

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

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

Displaying reports 57181-57200 of 78025.Go to page Start 2856 2857 2858 2859 2860 2861 2862 2863 2864 End