Displaying reports 61661-61680 of 82999.Go to page Start 3080 3081 3082 3083 3084 3085 3086 3087 3088 End
Reports until 15:07, Thursday 24 September 2015
H1 PEM (DetChar)
dale.ingram@LIGO.ORG - posted 15:07, Thursday 24 September 2015 (21903)
Outreach activity report
A tour group was on site early this afternoon.  Arrival time at LSB = ~12:30 PM.  Departure time = ~3:00 PM.  Group size = ~20 adults.  Vehicles at the LSB = ~10 passenger cars.  The group walked the site near the corner station and visited the control room between 1:30 and 3:00 PM.
H1 INJ (DetChar, INJ)
christopher.biwer@LIGO.ORG - posted 15:01, Thursday 24 September 2015 - last comment - 16:04, Thursday 24 September 2015(21901)
Beginning coherent hardware injection test
Adam, Chris

We are beginning to test coherent hardware injection with tinj. Will update this aLog with schedule as they happen.
Comments related to this report
christopher.biwer@LIGO.ORG - 15:05, Thursday 24 September 2015 (21902)
1127167840 1 0.5 coherenttest1_1126257410

EDIT: Cancelled, do not have permission to upload to CBC group on GraceDB.
christopher.biwer@LIGO.ORG - 15:09, Thursday 24 September 2015 (21904)
Cancelled the last scheduled injection. Cannot upload events to gracedb.
christopher.biwer@LIGO.ORG - 15:22, Thursday 24 September 2015 (21906)
1127168901 1 0.5 coherenttest1_1126257410
christopher.biwer@LIGO.ORG - 16:04, Thursday 24 September 2015 (21910)
The last injection did not go in at LHO. tinj had stopped eariler.

At LLO the wrong schedule was updated. See ALog entry

We are stopping with the tests.
H1 General
cheryl.vorvick@LIGO.ORG - posted 14:53, Thursday 24 September 2015 (21900)
Praxair has departed - IFO back to Observe, 21:43:53UTC

Commissioning from 19:37:35UTC to 21:43:53UTC.

 

DHARD_Y FM2 turned off at the end of Commissioning. 

 

During the commissioning period that just ended, there was:

- Praxair at EX

- light equipment moved from OSB receiving to MY (pickup truck)

- equipment moved from VPW receiving to MY (pickup truck)

- EX pcal switches changed, and backed out

- DHARD_Y FM2 engaged and disengaged

- ETMX Diag_Reset to clear another timing error that showed up today

 
IFO Range is now 74Mpc.
H1 General
cheryl.vorvick@LIGO.ORG - posted 13:18, Thursday 24 September 2015 (21894)
IFO in Commissioning: Praxair arrived on site

19:26UTC - 12:26PT, truck at receiving

19:37:35UTC - Commissioning , Praxair on site

 

Praxair takes about 2.5 hours, so expect to be in Commissioning until about 22:15UTC.

 

There is a second Praxair truck expected today as well.

 

19:44UTC - Richard, Filiberto, Mid-Y

 

19:45:55UTC - engaged FM2 on DHARD_Y, Sheila's filter

- heard the rumbling of the truck in the CR, and saw the range drop to 55Mpc just before engaging the filter

- apparently the truck had to turn around and go to the Y arm, which is the rumbling I heard

 

 

 

 

H1 General (GRD, ISC, PSL, SUS)
cheryl.vorvick@LIGO.ORG - posted 12:22, Thursday 24 September 2015 (21893)
OPS Mid-shift update: IFO back in OBSERVE

TITLE: IFO returns to Observe after multiple large earthquakes over the last 4 hours.

ASSISTANCE: Hugh (HAM5 SEI clearing all Guardian issues), Sheila (bounce-roll mode damping)

TIMELINE: 

15:00UTC - start of shift, high ground motion

- SYS_DIAG telling me ISS defracted power is too high - I reduce the slider.  Defracted power was 12 and went to 9.

15:47:12UTC - ground motion just coming down enough to relock, first DRMI lock since the earthquake in Canada

16:09:36UTC - IFO made it to Bounce Violin Mode Damping

16:19:37UTC - IFO unlocked

- A couple more DRIM locks that didn't survive.

- Four more 5-6 magnitude earthquakes come in and prevent locking.

18:04:31UTC - IFO ready to lock, and this starts the locking sequence that resulted in the IFO going to Low Noise

- Longer than usual time from ready to Low Noise, and one reason was that the roll mode on ITMY was about 4, so with Sheila's help I started the damping of the roll mode manually, and waiting for it to improved  = 20 minutes

18:55:04UTC - IFO in Low Noise

18:58:57UTC - IFO in Observe

LHO FMCS
john.worden@LIGO.ORG - posted 09:55, Thursday 24 September 2015 (21891)
LVEA and VEA temperature control

All buildings are beginning to respond to the lower outdoor temperatures so Bubba and I have turned on heaters in both end stations and the LVEA.

One stage of HC5 is now on in the LVEA. This will impact the input chambers the most. The response appears to be ~0.5 F.

The End stations have variac control so these have been incremented from 4ma(off) up 8.5ma

 

H1 General
cheryl.vorvick@LIGO.ORG - posted 09:40, Thursday 24 September 2015 (21888)
OPS Morning Update: IFO did lock, but a new earthquake is preventing full lock

TIME: 16:39UTC, 9:39PT

STATE OF THE IFO: Unlocked

EXPLANATION:  The IFO did lock and made it past ENGAGE_ASC_PART3, but then another earthquake arrived, and broke the lock, and ground motion is high.

H1 ISC
cheryl.vorvick@LIGO.ORG - posted 09:29, Thursday 24 September 2015 - last comment - 11:54, Thursday 24 September 2015(21886)
video0 - I see lots of red on the striptools, and not much else...

Video0's striptools have been modified, and now they have a red background, due to the channels DHARD_Y and DHARD_P.

When making a change to a screen, it's important to test it in all situations.  Maybe this addition worked quite well during our long lock, but right now with earthquakes and relocking, the change to the striptools have rendered them unusable.

FOM image attached.

Images attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 11:54, Thursday 24 September 2015 (21892)

This is a symptom of a rung up roll mode.  Cheryl spent the last few minutes damping it (ITMY) and now these displays are back to looking normal. 

H1 SEI (SYS)
sebastien.biscans@LIGO.ORG - posted 08:36, Thursday 24 September 2015 (21885)
Locklosses between Sept 10th and 17th due to EQs

Following Sheila's entry (alog 21708), I've tried to figure out which locklosses where due to Earthquakes during the week of Sep 10th (ER8).

Out of the 22 locklosses seen this week, I've counted 6 locklosses due to EQs. Sheila counted 9, I'll double check my conclusions with her.

EQ Location Ground Velocity at LHO Status Lock Loss time
5.9 Alaska 5.99 microns/s Lockloss 1125916264.5625
5.2 Mexico 1.08 microns/s Lockloss 1126042739.0625
5.7 New Zealand 1.16 microns/s Lockloss 1126127070.8125
6.3 Indonesia 3.20 microns/s Lockloss 1126427496.4375
6.1 Papua New Guinea 2.90 microns/s Lockloss 1126448905.3125
8.3 Chile 170 microns/s Lockloss + SEI trip 1126480080.5625

 

The ground velocities represent the maximum amplitude predicted by the Seismon software.  These predictions could be inaccurate by a few percents.

Six examples is not enough to do some accurate statistics, but the behavior observed during ER8 doesn't contradict the conclusions drawn from ER7 (see DCC T1500230). My conclusions were:

Note: among the 16 remaining locklosses, some of them are due to a high ground motion, but EQ is not the cause (wind? human activity?).

LHO General
corey.gray@LIGO.ORG - posted 08:05, Thursday 24 September 2015 (21881)
OWL Ops Summary

TITLE:  9/24 OWL Shift:  7:00-15:00UTC (00:00-8:00PDT), all times posted in UTC

STATE OF H1:  Unlocked.  Waiting out Earthquake.

SUPPORT:  None (& not needed)

SHIFT SUMMARY:

More action during this shift with the end of the long lock stretch (no obvious reason for lockloss by Jim, although he said he mentioned 45MHz issues for end of that lock).  Went through an alignment & then had a 4hr lock, and then had another Unknown lockloss.  Then while trying to bring back H1 had some issues (noted earlier).  And now handing off unlocked H1 with seismic ringing down from Vancouver EQ.

Shift Activities:

  • ETMy Saturations:  9:14 (set of 3), 10:18, 10:29, 11:19, 11:37, 11:39, 12:18, 
  • 8:34 H1 back to Observation
  • 9:04:15 H1 slipped out of Observation accidentally for 15sec
  • Noticed CDS O1 Overview was not up on video2 (had old version), so I brought it back up.
  • 12:35 Lockloss (nothing seen on seismic, and all H1 striptools show no issues; therefore UNKNOWN)
  • 13:54 Earthquake Verbal Alarm (Vancouver 5.5 quake)
  •  
H1 General
corey.gray@LIGO.ORG - posted 07:51, Thursday 24 September 2015 (21882)
H1 Lockloss @ 12:35: Unknown Cause

12:35 H1 Lockloss (nothing obvious:  seismic quiet, and all the H1 strip tools showed nothing obvious before lockloss)

During Lock Acquisition, during 2nd locking attempt, had issues with ALS XARM:

1) You can either misalign SRM using the SUS_SRM guardian, or use a new state in ALIGN_IFO called SET_SUS_FOR_PRMI_W_ALS. 

2) Request OFFLOAD_PRMI from the DRMI guardian.

3) Once PRMI locks adjust PRM and BS alignment until you get about 80 counts on POP90 and 50 counts on POP18.  

4)Realign SRM by undoing whatever change you made in step 1.

5) Request DRMI_1F_OFFFLOADED from the ISC_DRMI guardian.

Waited for DRMI to lock again.  Several times I had a Verbal Alarm which sounded like "Slip Mode"?  What do we do about this?  It looked ugly on AS-AIR video.  Had "Slip Mode" alarms a few times while waiting for DRMI, and then the Vancouver earthquake arrived!

After recovering ISIs and ETMy, took ISC_LOCK to LOCKING_ALS, but haven't made it there yet (the guardian log keeps saying "Waiting for arms to settle").  The 0.03-0.1Hz seismic band was ramping down, but flattened out at 0.3um/s (which is over an order of magnitude from normal quiet levels).  Perhaps we should wait for this to come down to normal levels.

H1 CAL
jeffrey.kissel@LIGO.ORG - posted 17:03, Wednesday 23 September 2015 - last comment - 19:18, Thursday 24 September 2015(21868)
DARMOLGTF and PCALY to DARM Sweeps taken for Calibration Validation
J. Kissel

I've taken new DARM open loop gain and PCALY to DARM transfer functions to validate the current calibration. During the PCALY to DARM transfer function, I take the transfer function from PCALY's RX PD (calibrated into [m] of ETMY motion) and the CAL-CS front-end's DELTAL_EXTERNAL (calibrated into DARM [m], which -- since we're driving ETMY -- is identical to [m] of ETMY motion). These two different methods agree to within 4% and 3 [deg] over the 15 [Hz] to 1.2 [kHz] band. The calibration discrepancy expands to a whopping 9% and 4 [deg] if we look a frequencies between 5 and 15 [Hz] ;-).

I think we're in great shape, boys and girls.

Details
--------------
- CAL-CS does not correct for any slow time depedence (optical gain, test mass actuation strength, etc), so any agreement you see with the current interferometer is agreement with the reference model taken on Sep 10th 2015 (LHO aLOG 21385).

- In the previous measurement, Kiwamu had to fudge the phase by ~90 [us] to get the phase to agree. Now that we've updated the cycle delay between sensing and actuation to 7 [16 kHz clock cycles] to better approximate the high-frequency frequency response of AA, AI, and the OMC DCPD signal chain, we no longer have to fudge the phase -- AND the phase between the two metrics agree. NICE.

- I've made sure to turn OFF calibration lines *during both of these measurements, but there should be ample data just before and just after with calibration lines ON, such that we can compare our results against theirs to help refine our estimates of systematic error.

- The measurements live in
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O1/H1/Measurements/DARMOLGTFs/2015-09-23_H1_DARM_OLGTF_7to1200Hz.xml
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O1/H1/Measurements/PCAL$/2015-09-23_PCALY2DARMTF_7to1200Hz.xml
and have been committed to the CalSVN. We'll process these results shortly, and perform a similar analysis as Darkhan has done in yesterday's aLOG 21827.
Images attached to this report
Comments related to this report
darkhan.tuyenbayev@LIGO.ORG - 14:41, Thursday 24 September 2015 (21898)

The parameter file for this measurement was committed to calibration SVN:

CalSVN/aligocalibration/trunk/Runs/O1/H1/Scripts/DARMOLGTFs/H1DARMparams_1127083151.m

Attached plots show components of DARM loop TF and their residuals vs. DARM model for O1.

Non-image files attached to this comment
kiwamu.izumi@LIGO.ORG - 19:18, Thursday 24 September 2015 (21926)CAL

It looks better. Very nice.

By the way, I wanted to measure the open loop without the MICH or SRCL feedforward because I wanted to demonstrate that the unknown shape in the residual in magnitude is not due to these feedforward corrections. Though this may be a crazy thought. Anyway, it would be great if you can run an open-loop measurement without the feedforwards at some point, just once.

H1 INJ (DetChar, INJ)
christopher.biwer@LIGO.ORG - posted 13:53, Wednesday 23 September 2015 - last comment - 12:53, Friday 25 September 2015(21852)
single-IFO hardware injection tests at H1
L1 went out of lock. At H1 we turned off the intent bit and injected some hardware injections.

The hardware injections were the same waveform that was injected on September 21. For more information about those injections see aLog entry 21759

For information about the waveform see aLog entry 21774.

tinj was not used to do the injections.The commands to do the injections were:
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 H1-HWINJ_CBC-1126257410-12.txt 0.5 -d -d >> log2.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 H1-HWINJ_CBC-1126257410-12.txt 1.0 -d -d >> log2.txt
ezcawrite H1:CAL-INJ_TINJ_TYPE 1
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 H1-HWINJ_CBC-1126257410-12.txt 1.0 -d -d >> log2.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 H1-HWINJ_CBC-1126257410-12.txt 1.0 -d -d >> log2.txt

To my chagrin the first two injections were labeled as burst injections.

Taken from the awgstream log the corresponding times are approximates of the injection time:

1127074640.002463000
1127074773.002417000
1127075235.002141000
1127075742.002100000

The expected SNR of the injection is ~18 without any scaling factor.

I've attached omegascans of the injections. There is no sign of the "pre-glitch" that was seen on September 21.
Images attached to this report
Comments related to this report
christopher.biwer@LIGO.ORG - 13:57, Wednesday 23 September 2015 (21855)DetChar, INJ
Attached stdout of command line.
Non-image files attached to this comment
david.shoemaker@LIGO.ORG - 14:04, Wednesday 23 September 2015 (21857)
Neat! looks good.
john.veitch@LIGO.ORG - 01:37, Thursday 24 September 2015 (21878)
Hi Chris,
It looks like there is a 1s offset between the times you report and the rough coalescence time of the signal. Do you know if it is exactly 1s difference?
peter.shawhan@LIGO.ORG - 09:19, Thursday 24 September 2015 (21887)INJ
Yes, as John said, all of the end times of the waveforms are just about 1 second later that what's in the original post.

I ran a version my simple bandpass-filtered overlay script for these waveforms.  Filtering both the model (strain waveform injected into the system) and the data from 70-260 Hz, it overlays them, and also does a crude (non-optimal) matched filter to estimate the relative amplitude and time offset.  The four plots attached are for the four injected signals; note that the first one was injected with a scale factor of 0.5 and is not "reconstructed" by my code very accurately.  The others actually look rather good, with reasonably consistent amplitudes and time delays.  Note that the sign of the signal came out correctly!
Images attached to this comment
Non-image files attached to this comment
christopher.biwer@LIGO.ORG - 09:47, Thursday 24 September 2015 (21890)
I ran the daily BBH search with the injected template on the last two injections (1127075235 and 1127075742).

For 1127075235; the recovered end time was 1127075235.986, the SNR was 20.42, the chi-squared was 29.17, and the newSNR was 19.19.
For 1127075242; the recovered end time was 1127075242.986, the SNR was 20.04, the chi-squared was 35.07, and the newSNR was 19.19.
reed.essick@LIGO.ORG - 14:19, Thursday 24 September 2015 (21896)
KW sees all the injections with the +1 sec delay, some of them in multiple frequency bands.
From 
  /gds-h1/dmt/triggers/H-KW_RHOFT/H-KW_RHOFT-11270/H-KW_RHOFT-1127074624-64.trg
  /gds-h1/dmt/triggers/H-KW_RHOFT/H-KW_RHOFT-11270/H-KW_RHOFT-1127074752-64.trg
  /gds-h1/dmt/triggers/H-KW_RHOFT/H-KW_RHOFT-11270/H-KW_RHOFT-1127075200-64.trg
  /gds-h1/dmt/triggers/H-KW_RHOFT/H-KW_RHOFT-11270/H-KW_RHOFT-1127075712-64.trg

    tcent         fcent significance channel
1127074640.979948   146    26.34      H1_GDS-CALIB_STRAIN_32_2048
1127074774.015977   119    41.17      H1_GDS-CALIB_STRAIN_8_128
1127074773.978134   165   104.42      H1_GDS-CALIB_STRAIN_32_2048
1127075235.980545   199   136.82      H1_GDS-CALIB_STRAIN_32_2048
1127075743.018279   102    74.87      H1_GDS-CALIB_STRAIN_8_128
1127075742.982020   162   113.65      H1_GDS-CALIB_STRAIN_32_2048

Omicron also sees them with the same delay
From :
  /home/reed.essick/Omicron/test/triggers/H-11270/H1:GDS-CALIB_STRAIN/H1-GDS_CALIB_STRAIN_Omicron-1127074621-30.xml
  /home/reed.essick/Omicron/test/triggers/H-11270/H1:GDS-CALIB_STRAIN/H1-GDS_CALIB_STRAIN_Omicron-1127074771-30.xml
  /home/reed.essick/Omicron/test/triggers/H-11270/H1:GDS-CALIB_STRAIN/H1-GDS_CALIB_STRAIN_Omicron-1127075221-30.xml
  /home/reed.essick/Omicron/test/triggers/H-11270/H1:GDS-CALIB_STRAIN/H1-GDS_CALIB_STRAIN_Omicron-1127075731-30.xml

    peak time          fcent      snr
1127074640.977539062  88.77163  6.3716
1127074773.983397960 648.78342 11.41002  <- surprisingly high fcent, could be due to clustering
1127075235.981445074 181.39816 13.09279
1127075742.983397960 181.39816 12.39437

LIB single-IFO jobs also found all the events. Post-proc pages can be found here:

 https://ldas-jobs.ligo.caltech.edu/~reed.essick/O1/2015_09_23-HWINJ/1127074640.98-0/H1L1/H1/posplots.html
 https://ldas-jobs.ligo.caltech.edu/~reed.essick/O1/2015_09_23-HWINJ/1127074773.98-1/H1L1/H1/posplots.html
 https://ldas-jobs.ligo.caltech.edu/~reed.essick/O1/2015_09_23-HWINJ/1127075235.98-2/H1L1/H1/posplots.html
 https://ldas-jobs.ligo.caltech.edu/~reed.essick/O1/2015_09_23-HWINJ/1127075742.98-3/H1L1/H1/posplots.html

all runs appear to have reasonable posteriors.
florent.robinet@LIGO.ORG - 23:17, Thursday 24 September 2015 (21935)DetChar
Here is how Omicron detects these injections:

https://ldas-jobs.ligo-wa.caltech.edu/~frobinet/scans/hd/1127074641/
https://ldas-jobs.ligo-wa.caltech.edu/~frobinet/scans/hd/1127074774/
https://ldas-jobs.ligo-wa.caltech.edu/~frobinet/scans/hd/1127075236/
https://ldas-jobs.ligo-wa.caltech.edu/~frobinet/scans/hd/1127075743/

Here are the parameters measured by Omicron (loudest tile):
1127074640: t=1127074640.981, f=119.9 Hz, SNR=6.7
1127074773: t=1127074773.981, f=135.3 Hz, SNR=11.8
1127075235: t=1127075235.981, f=114.9 Hz, SNR=12.8
1127075742: t=1127075742.981, f=135.3 Hz, SNR=12.4
joey.key@LIGO.ORG - 12:53, Friday 25 September 2015 (21947)
The BayesWave single IFO (glitch only) analysis recovers these injections with the following SNRs:
4640: 8.65535
4773: 19.2185
5253: 20.5258
5742: 20.1666
The results are posted here:
https://ldas-jobs.ligo.caltech.edu/~meg.millhouse/O1/CBC_hwinj/
Images attached to this comment
H1 ISC
paul.fulda@LIGO.ORG - posted 13:22, Tuesday 22 September 2015 - last comment - 08:16, Monday 12 October 2015(21792)
AS 36 MHz WFS sensing as a function of SR3 RoC (SRC mode matching)

Elli and Stefan showed in aLOG 20827 that the signals measured by AS 36 WFS for SRM and BS alignment appeared to be strongly dependent on the power circulating in the interferometer. This was apparently not seen to be the case in L1. As a result, I've been looking at the AS 36 sensing with a Finesse model (L1300231), to see if this variability is reproducible in simulation, and also to see what other IFO variables can affect this variability. 

In the past when looking for differences between L1 and H1 length sensing (for the SRC in particular), the mode matching of the SRC has come up as a likely candidate. This is mainly because of the relatively large uncertainties in the SR3 mirror RoC combined with the strong dependence of the SRC mode on the SR3 RoC. I thought this would therefore be a good place to start when looking at the alignment sensors at the AS port. I don't expect the SR3 RoC to be very dependent on IFO power, but having a larger SR3 RoC offset (or one in a particular direction) may increase the dependence of the AS WFS signals on the ITM thermal lenses (which are the main IFO variables we typically expect to change with IFO power). This might therefore explain why H1 sees a bigger change in the ASC signals than L1 as the IFOs heat up. 

My first step was to observe the change in AS 36 WFS signals as a function of SR3 RoC. The results for the two DOFs shown in aLOG 20827 (MICH = BS, SRC2 = SRM) are shown in the attached plots. I did not spend much time adjusting Gouy phases or demod phases at the WFS in order to match the experiment, but I did make sure that the Gouy phase difference between WFSA and WFSB was 90deg at the nominal SR3 RoC. In the attached plots we can see that the AS 36 WFS signals are definitely changing with SR3 RoC, in some cases even changing sign (e.g. SRM Yaw to ASA36I/Q and SRM Pitch to ASA36I/Q). It's difficult at this stage to compare very closely with the experimental data shown in aLOG 20827, but at least we can say that from model it's not unexpected that these ASC sensing matrix elements are changing with some IFO mode mismatches. The same plots are available for all alignment DOFs, but that's 22 in total so I'm sparing you all the ones which weren't measured during IFO warm up. 

The next step will be to look at the dependence of the same ASC matrix elements on common ITM thermal lens values, for a few different SR3 RoC offsets. This is where we might be able to see something that explains the difference between L1 and H1 in this respect. (Of course, there may be other effects which contribute here, such as differential ITM lensing, spot position offsets on the WFS, drifting of uncontrolled DOFs when the IFO heats up... but we have to start somewhere). 

Non-image files attached to this report
Comments related to this report
keita.kawabe@LIGO.ORG - 18:33, Tuesday 22 September 2015 (21819)

Can you add a plot of the amplitude and phase of 36MHz signal that is common to all four quadrants when there's no misalignment?

paul.fulda@LIGO.ORG - 10:01, Wednesday 23 September 2015 (21839)

As requested, here are plots of the 36MHz signal that is common to all quadrants at the ASWFSA and ASWFSB locations in the simulation. I also checked whether the "sidebands on sidebands" from the series modulation at the EOM had any influence on the signal that shows up here: apparently it does not make a difference beyond the ~100ppm level. 

Non-image files attached to this comment
paul.fulda@LIGO.ORG - 07:57, Friday 25 September 2015 (21895)

At Daniel's suggestion, I adjusted the overall WFS phases so that the 36MHz bias signal shows up only in the I-phase channels. This was done just by adding the phase shown in the plots in the previous comment to both I and Q detectors in the simulation. I've attached the ASWFS sensing matrix elements for MICH (BS) and SRC2 (SRM) again here with the new demod phase basis. 

**EDIT** When I reran the code to output the sensitivities to WFS spot position (see below) I also output the MICH (BS) and SRC2 (SRM) DOFs again, as well as all the other ASC DOFs. Motivated by some discussion with Keita about why PIT and YAW looked so different, I checked again how different they were. In the outputs from the re-run, PIT and YAW don't look so different now (see attached files with "phased" suffix, now also including SRC1 (SR2) actuation). The PIT plots are the same as previously, but the YAW plots are different to previous and now agree better with PIT plots.

I suspect that the reason for the earlier difference had something to do with the demod phases not having been adjusted from default for YAW signals, but I wasn't yet able to recreate the error. Another possibility is that I just uploaded old plots with the same names by mistake. 

Non-image files attached to this comment
paul.fulda@LIGO.ORG - 14:47, Thursday 24 September 2015 (21899)

To clarify the point of adjusting the WFS demod phases like this, I also added four new alignment DOFs corresponding to spot position on WFSA and WFSB, in ptich and yaw directions. This was done by dithering a steering mirror in the path just before each WFS, and double demodulating at the 36MHz frequency (in I and Q) and then at the dither frequency. The attached plots show what you would expect to see: In each DOF the sensitivity to spot position is all in the I quadrature (first-order sensitivity to spot position due to the 36MHz bias). Naturally, WFSA spot position doesn't show up at WFSB and vice versa, and yaw position doesn't show up in the WFS pitch signal and vice versa. 

For completeness, the yaxis is in units of W/rad tilt of the steering mirror that is being dithered. For WFSA the steering mirror is 0.1m from the WFSA location, and for WFSB the steering mirror is 0.2878m from the WFSB location. We can convert the axes to W/mm spot position or similar from this information, or into W/beam_radius using the fact that the beam spot sizes are at 567µm at WFSA and 146µm at WFSB.

Non-image files attached to this comment
paul.fulda@LIGO.ORG - 10:04, Tuesday 29 September 2015 (22058)

As shown above the 36MHz WFS are sensitive in one quadrature to spot position, due to the constant presence of a 36MHz signal at the WFS. This fact, combined with the possibility of poor spot centering on the WFS due to the effects of "junk" carrier light, is a potential cause of badness in the 36MHz AS WFS loops. Daniel and Keita were interested to know if the spot centering could be improved by using some kind of RF QPD that balances either the 18MHz (or 90MHz) RF signals between quadrants to effectively center the 9MHz (or 45MHz) sideband field, instead of the time averaged sum of all fields (DC centering) that is sensitive to junk carrier light. In Daniel's words, you can think of this as kind of an "RF optical lever".

This brought up the question of which sideband field's spot postion at the WFS changes most when either the BS, SR2 or SRM are actuated.

To answer that question, I:

  • Added 18MHz and 90MHz "WFS" to the Finesse model.
  • Phased these new "WFS" so that all the 18MHz or 90MHz "sum" signals show up in the I-phase (see first two plots).
  • Plotted the new "WFS" responses to BS, SR2 and SRM pitch and yaw (normalized by their "sum" signal), as a function of SR3 RoC (see the rest of the plots).

Some observations from the plots:

  • 90MHz "WFS" show much more response to SRC1 (SR2) and SRC2 (SRM) tilts than 18MHz "WFS". This is somewhat intuitive, because the 45MHz sidebands are resonant in the SRC and the SRC eigenmode may be more sensitive to SR alignments than a beam traced through "single bounce" style.
  • The 90MHz response to SRM/SR2 tilt remain very much in the I phase, with almost no signal in the Q-phase. 
  • 18MHz "WFS" show more response to MICH (BS) than the 90MHz "WFS". This is problably because a BS tilt causes a large coupling of 9MHz HG10/01 mode from the PRC to the SRC relative to the amount of 9MHz HG00 mode already in the SRC (due to high Michelson reflectivity + SRC non-resonance for 9MHz HG00). Since I normalize to the total sideband power, this looks like a bigger response in 18MHz than 90MHz.
  • The 18MHz response to BS tilt is mostly in the Q phase. I'm not sure exactly how to interpret this, but my naive guess is that it's related to the BS tilt being a "differential" mode tilt for the X and Y arms of the small Michelson.
Non-image files attached to this comment
paul.fulda@LIGO.ORG - 08:16, Monday 12 October 2015 (22432)

I looked again at some of the 2f WFS signals, this time with a linear sweep over alignment offsets rather than a dither transfer function. I attached the results here, with detectors being phased to have the constant signal always in I quadrature. As noted before by Daniel, AS18Q looks like a good signal for MICH sensing, as it is pretty insensitive to beam spot position on the WFS. Since I was looking at larger alignment offsets, I included higher-order modes up to order 6 in the calculation, and all length DOFs were locked. This was for zero SR3 RoC offset, so mode matching is optimal.

Non-image files attached to this comment
H1 SEI (CDS)
brian.lantz@LIGO.ORG - posted 17:11, Monday 21 September 2015 - last comment - 14:19, Thursday 24 September 2015(21755)
HAM5 Rogue Excitation alarm annoyance from bad channel readback
Folks have been complaining that the HAM5-ISI Rogue Excitation monitor is a pain. 
(see e.g. https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=21474)

It looks like the coil-voltage-readback monitor for the V2 coil is busted somewhere, and so the monitor is sitting around -500 counts all the time. 

Hugh gave me the GPS time for a recent earthquake, and in the attached plot you can see the watchdog trip from normal (state 1) to damp-down (state 2) at T+3 seconds. The coil voltages come down pretty quickly. Then the WD goes to state 4 (full trip) about 3 seconds later and the coil drive monitors (except V2) get quite small. The rogue excitation alarm goes off about 3 seconds after that, because the V2 monitor has not fallen to abs(Vmon) < +100 counts. 

The V2 monitor just sort of sits at ~-500 counts all the time. 
I'm pretty sure the V2 coil drive is working, otherwise the HAM5-ISI platform would act very poorly.
I'm guessing the problem is somewhere in the readback chain.

Note - the channels I use for this are all Epics channels, so the timing is a bit crude and the voltages are sort of jumpy. The channels are:
H1:ISI-HAM5_ERRMON_ROGUE_EXC_ALARM
H1:ISI-HAM5_CDMON_H1_V_INMON
H1:ISI-HAM5_CDMON_H2_V_INMON
H1:ISI-HAM5_CDMON_H3_V_INMON
H1:ISI-HAM5_CDMON_V1_V_INMON
H1:ISI-HAM5_CDMON_V2_V_INMON
H1:ISI-HAM5_CDMON_V3_V_INMON
H1:ISI-HAM5_WD_MON_STATE_INMON

I've also attached screenshots of the "coil drive voltage too big" calculation and the "rogue excitation alarm generation" calculation from the HAM-ISI master model
Images attached to this report
Non-image files attached to this report
Comments related to this report
brian.lantz@LIGO.ORG - 17:23, Monday 21 September 2015 (21757)
I've added integration issue 1127 on this
https://services.ligo-wa.caltech.edu/integrationissues/show_bug.cgi?id=1127
hugh.radkins@LIGO.ORG - 14:19, Thursday 24 September 2015 (21897)

I think I've got all the colors sorted out and pretty sure it looks like H2 Monitor isn't working either.  At first I thought it was just zero on the plot but I don't think so.  At least it won't cause this problem and being H2 may help find the problem.

Displaying reports 61661-61680 of 82999.Go to page Start 3080 3081 3082 3083 3084 3085 3086 3087 3088 End