Displaying reports 51241-51260 of 83165.Go to page Start 2559 2560 2561 2562 2563 2564 2565 2566 2567 End
Reports until 09:02, Thursday 22 December 2016
H1 SEI
jim.warner@LIGO.ORG - posted 09:02, Thursday 22 December 2016 - last comment - 09:19, Thursday 22 December 2016(32832)
Earthquake Report

5.2M Nikol'skoye, Russia

Was it reported by Terramon, USGS, SEISMON? Yes, Yes, No

Magnitude (according to Terramon, USGS, SEISMO): 5.2, 5.2, NA

Location 79km W of Nikol'skoye, Russia; LAT: 55.3, LON: 164.7

 

Starting time of event (ie. when BLRMS started to increase on DMT on the wall): 16:30 UTC

Lock status?  Still locked

EQ reported by Terramon BEFORE it actually arrived? I noticed the EQ band BLRMS coming up before checking Terramon.

Comments related to this report
jim.warner@LIGO.ORG - 09:19, Thursday 22 December 2016 (32834)

We just lost lock, but I think it's pretty clearly not from the earthquake. The PSL is down, Peter is taking a look at it.

H1 General
edmond.merilh@LIGO.ORG - posted 08:04, Thursday 22 December 2016 (32830)
Shift Summary - Owl
TITLE: 12/22 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 72.2849Mpc
INCOMING OPERATOR: Jim
SHIFT SUMMARY:
Quiet night. H1 locked and observing for 08:48:00. Handing off to Jim.
LOG:
H1 General
edmond.merilh@LIGO.ORG - posted 04:44, Thursday 22 December 2016 (32828)
Mid-Shift Summary

H1 is locked and running at 73Mpc. Coincidental time with Livingston is approaching 5 hours and 20 minutes. The BNS range plot indicates features that are consistent with glitches but no glitches have been reported. Winds are calm. µSeism appears to be trending downward with the mean still riding at the 90%ile. EQ activity has been negligible. Steady as she goes.

H1 AOS
edmond.merilh@LIGO.ORG - posted 00:06, Thursday 22 December 2016 (32827)
Shift Summary - Owl Transition
TITLE: 12/22 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 71.0332Mpc
OUTGOING OPERATOR: Nutsinee
CURRENT ENVIRONMENT:
    Wind: 4mph Gusts, 3mph 5min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.65 μm/s 
QUICK SUMMARY:
H1 General
nutsinee.kijbunchoo@LIGO.ORG - posted 00:04, Thursday 22 December 2016 (32826)
Ops EVE shift summary

TITLE: 12/22 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC

STATE of H1: Observing at 70.6784Mpc

INCOMING OPERATOR: Ed

SHIFT SUMMARY: Jim had it locked for me when I arrived. Nothing exciting to report. Bounce and roll came back high when I relocked so I increased the ITMY gain a bit and accepted the SDF.

LOG:

16:00 Kyle to mid Y

16:45 Kyle back

6:11 Lockloss. Cause not obvious from the FOMs.

7:21 Observe again.

H1 General
nutsinee.kijbunchoo@LIGO.ORG - posted 20:48, Wednesday 21 December 2016 (32825)
Mid-ish shift summary

H1 locked for almost 9 hours and counting. LLO is down so I'll take this opportunity to run a2l (high coherence in pitch).

LHO VE
kyle.ryan@LIGO.ORG - posted 17:33, Wednesday 21 December 2016 (32823)
More experimenting with CP4's clogged level sensing line
After pumping on the clogged level sensing line for a short period this morning, I isolated the line by closing the in-line ball valve that is part of the adapting hardware.  Next, I removed the vacuum line and connected the actively flowing/purging UHP N2 line in its place (10 psi @ 1 lpm).  The clogged line then can be back-filled with dry N2.  Once back-filled, the adapting hardware is removed and the (slightly positive pressure) line then equalizes to room pressure.  The open line then gets connected to its nominal plumbing (local mechanical magnahelic differential pressure gauge in parallel with CDS pressure transducers).  At this point, the pattern is for a buildup of pressure until both the mechanical pressure gauge and CDS transducers "rail" at 100%  Keep in mind when looking at the data that the rate of this pressure build-up has been sporadic due to my inconsistent making up of the plumbing compression fittings - sometimes by hand, sometimes with wrenches - it turns out that even small leaks into the room confuse the issue.  Regardless something WONDERFUL is happening in all instances.  That is, gas is building up above room pressure after the equalized line gets connected to the "closed" non-leaking plumbing.  Each time the plumbing fitting is loosened, I can hear and feel a significant amount of built up gas being released into the room.  The only explanation the I can come up with is that LN2 is getting past the plug and vaporizing in the warm section of the sensing tube or the plug is comprised of a high vapor pressure material and is "inching" up the sensing line and getting warmed.  

I was only able to try two iterations today and am leaving the line connected to the UHP N2 (10 psi @ 0.5 LPM) over night.  Will try some more tomorrow.  
Non-image files attached to this report
H1 CAL
jeffrey.kissel@LIGO.ORG - posted 17:29, Wednesday 21 December 2016 (32824)
Full IFO Calibration Measurements During / After PUM Driver Swap
J. Kissel

I haven't processed them yet, but for the record, I was able to grab a collection of measurements of the pas few days that should be a nice reference for 
    (a) The PUM driver fiasco, and
    (b) a before vs. after the Holiday shut down

The data lives here:
FullIFOActuatorTFs/2016-12-20/2016-12-20_H1SUSETMY_L1_iEXC2DARM.xml
FullIFOActuatorTFs/2016-12-20/2016-12-20_H1SUSETMY_L1_PCAL2DARM.xml
FullIFOActuatorTFs/2016-12-20/2016-12-20_H1SUSETMY_L2_iEXC2DARM.xml  << During temporarily swapped PUM Driver
FullIFOActuatorTFs/2016-12-20/2016-12-20_H1SUSETMY_L2_PCAL2DARM.xml  << During temporarily swapped PUM Driver
FullIFOActuatorTFs/2016-12-20/2016-12-20_H1SUSETMY_L3_iEXC2DARM.xml
FullIFOActuatorTFs/2016-12-20/2016-12-20_H1SUSETMY_L3_PCAL2DARM.xml

FullIFOActuatorTFs/2016-12-21/2016-12-21_H1SUSETMY_L2_iEXC2DARM.xml  << After PUM driver was reverted
FullIFOActuatorTFs/2016-12-21/2016-12-21_H1SUSETMY_L2_PCAL2DARM.xml  << After PUM driver was reverted

SensingFunctionTFs/2016-12-20_H1DARM_OLGTF_4to1200Hz.xml             << During swapped driver
SensingFunctionTFs/2016-12-20_H1_PCAL2DARMTF_4to1200Hz.xml           << During swapped driver -- unfortunately incomplete due to lock loss

SensingFunctionTFs/2016-12-21_H1DARM_OLGTF_4to1200Hz_25min.xml       << After PUM driver was reverted
SensingFunctionTFs/2016-12-21_H1_PCAL2DARMTF_4to1200Hz_8min.xml      << After PUM driver was reverted

We'll process this data of the next few weeks and get back to you.
H1 CAL (DetChar, ISC, SUS)
jeffrey.kissel@LIGO.ORG - posted 17:17, Wednesday 21 December 2016 (32799)
PUM Driver Reverted; Detailed Comparison Between Temporary Swap and Now Reverted Driver; Suggest a 'Poor Calibration Flag' for the Observational Stretch
J. Kissel 

Yesterday, after seeing little-to-no impact from replacing the H1 SUS ETMY PUM driver, we have reverted to the original driver.
     - Spare Driver (s/n S1102648) swapped in: LHO aLOG 32745
     - Original Driver (s/n S1102652) reverted in: LHO aLOG 32780
The only H1 observational stretch that includes this temporary PUM driver:
    Dec 20 2016 10:44:28 UTC - Dec 20 2016 13:43:44 UTC
    Dec 20 2016 02:44:28 PST - Dec 20 2016 05:43:44 PST
              GPS 1166265885 - GPS 1166276641
    Duration: 10756[sec] or 2.99 [hr]
During this time, L1 only had a short 22 minute lock stretch,
    Dec 20 2016 12:31:15 UTC - Dec 20 2016 12:53:34 UTC
    Dec 20 2016 04:31:15 PST - Dec 20 2016 04:53:34 PST
              GPS 1166272292 - GPS 1166273631
    Duration: 1336 [sec] or  0.37 [hr]

Note: While reverting the coil driver, Fil also power cycled the respective AI chassis, so observational stretches after Dec 20 2016 13:43:44 UTC, if they have an improved glitch rate, are likely due to either reseating / reconnecting the original PUM driver (s/n S1102652), or are perhaps more likely related to the power cycle of the AI chassis.

---------
Characterization Measurement Comparison between Temporary Spare Original (S1102648) and Original Driver (S1102652)

Using the same entirely digital measurement technique we used to determine the compensating poles and zeros for the coil drivers before O1 (i.e. using the coil driver monitor circuits; see LHO aLOG 20846), I measured the PUM driver's frequency response before and after we swapped out the driver for a spare. Results are attached.

The .png attachments focus on State 3, which is the state used in nominal low noise and therefore would affect calibration, coil balancing, and length-to-angle decoupling filters. The .pdf attachments cover all four states for all four coils that were measured (because we do transition between states during lock-acquisition -- important for duty cycle, not sensitivity).

The analysis process is as follows (in order of .png attachments):
(1) In order to get coherence across the entire relevant frequency band**, I took both swept sine and white noise transfer functions. These were each filtered for high coherence (a threshold of 0.99), and then concatenated. The .png shows one coil (LR), in one state (state 3), for the original driver (S1102652) as an example to illustrate the process.
(2) Once this data is gathered and concatenated for the two drivers, for all 4 states of all 4 coils, I take the ratio of the original vs. the temporary driver. The .png shows an example of this again for the LR coil in state 3, but for both drivers and their ratio.
(3) The ratio of driver response for all four coils is shown in the same plot in the 3rd .png.
(4) To compute the impact of these changes on the longitudinal response of the stage, we show two traces in the 4th .png. Mathematically similar but not identical, I show 
     (a) the "average" (more accurately, the sum of each coil multiplied by 1/4) of the ratios from plot (3), and 
     (b) the ratio of the "average" of each driver's coils.

Plot 4 shows that, if we had left the temporary driver in place, then we would have a frequency dependent, +/- 4% / 5 [deg] systematic error in the IFO's response to gravitational waves in the 10 - 30 Hz region.
It also means, that for that 3 [hr] observation stretch on Dec 20th, we have this +/- 4% / 5 [deg] systematic error in the IFO's response in the 10 - 30 Hz region. For this reason, if at all reasonable, I suggest we create a data quality flag for that observation stretch. Otherwise, the librarian's nightmare of creating a new DARM model for just those 3 [hrs] would divert the calibration group's energy away from where I think our priorities lie in the foreseeable future.

* This actuator authority comparison was generated by Evan, originally in LHO aLOG 28746. The script to generate these plot lives here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER9/H1/Scripts/HeirarchicalFilterDesign/HeirarchicalFilterDesign.m
and the plots from the entry live in the same directory.

** This data was taken when I expected that we were going to stick with the S1102648 PUM driver and needed to readjust the coil compensation filters (see LHO aLOG 21232). As such, the relevant frequencies are from 0.1 [Hz] -- enough below the lowest pole frequencies it can be separated from DC transconductance in fitting -- to 10 kHz where the impact of coil impedance begins to flatten out.

------------
The templates and exported data from this aLOG live in:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/Measurements/Electronics/

The script to analyze the data lives in:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/Scripts/Electronics/

The .pdfs of the attached plots live in:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/Results/Electronics/
Images attached to this report
Non-image files attached to this report
LHO VE
logbook/robot/script0.cds.ligo-wa.caltech.edu@LIGO.ORG - posted 15:35, Wednesday 21 December 2016 - last comment - 16:37, Wednesday 21 December 2016(32819)
CP3, CP4 Autofill 2016_12_21
Starting CP3 fill. LLCV enabled. LLCV set to manual control. LLCV set to 50% open. Fill completed in 1476 seconds. TC B did not register fill. LLCV set back to 19.0% open.
Starting CP4 fill. LLCV enabled. LLCV set to manual control. LLCV set to 70% open. Fill completed in 36 seconds. TC B did not register fill. LLCV set back to 34.0% open.
Comments related to this report
david.barker@LIGO.ORG - 16:37, Wednesday 21 December 2016 (32822)

this robo-posting is the final in today's test. It was generated by a crontab running on script0. In future it will run every Mon, Wed, Fri at 12:10 and report on the 11am CP3,4 autofills.

H1 PSL (CDS)
james.batch@LIGO.ORG - posted 14:52, Wednesday 21 December 2016 (32817)
TCS MEDM Screens Added to PSL Detailed Web Screens
The H1 PSL Detailed Screens link from the LHO MEDM Screens web page now displays additional screens for TCSX and TCSY. 
Images attached to this report
LHO VE
logbook/robot/script0.cds.ligo-wa.caltech.edu@LIGO.ORG - posted 12:48, Wednesday 21 December 2016 - last comment - 16:30, Wednesday 21 December 2016(32814)
CP3, CP4 Autofill 2016_12_21
Starting CP3 fill. LLCV enabled. LLCV set to manual control. LLCV set to 50% open. Fill completed in 1476 seconds. TC B did not register fill. LLCV set back to 19.0% open.
Starting CP4 fill. LLCV enabled. LLCV set to manual control. LLCV set to 70% open. Fill completed in 36 seconds. TC B did not register fill. LLCV set back to 34.0% open.
Comments related to this report
david.barker@LIGO.ORG - 12:50, Wednesday 21 December 2016 (32815)

our reporting script now shows both cp3 and cp4 fills. We will change the format of the text slightly to show the start/stop times because the reporting is delayed beyond the time-out period of one hour.

gerardo.moreno@LIGO.ORG - 14:59, Wednesday 21 December 2016 (32818)VE

For CP3:

Increased the LLCV to 20 from 19, due to amount of time it took to overfill CP3 (1476 seconds).

chandra.romel@LIGO.ORG - 16:30, Wednesday 21 December 2016 (32821)
I recommend raising CP3 even more to last through the break. Exhaust pressure will register a value above zero when it's boreline overfilling.
LHO VE
logbook/robot/script0.cds.ligo-wa.caltech.edu@LIGO.ORG - posted 12:36, Wednesday 21 December 2016 (32813)
CP3, CP4 Autofill 2016_12_21
Starting CP3 fill. LLCV enabled. LLCV set to manual control. LLCV set to 50% open. Fill completed in 1476 seconds. TC B did not register fill. LLCV set back to 19.0% open.
H1 SEI
jim.warner@LIGO.ORG - posted 10:57, Wednesday 21 December 2016 (32812)
Earthquake Report

5.9M Northern Mariana

Was it reported by Terramon, USGS, SEISMON? Yes, Yes, No

Magnitude (according to Terramon, USGS, SEISMO): 5.9, 5.9, NA

Location 120km NNE of Farallon de Pajaros, Northern Mariana Islands; LAT: 21.5, LON: 145.4

 

Starting time of event (ie. when BLRMS started to increase on DMT on the wall): 17:00 UTC

Lock status?  Lockloss due to earthquake

EQ reported by Terramon BEFORE it actually arrived? Terramon reported before the lockloss, but I noticed the EQ band BLRMS coming up before checking Terramon

H1 General
edmond.merilh@LIGO.ORG - posted 08:12, Wednesday 21 December 2016 - last comment - 13:40, Wednesday 21 December 2016(32808)
Shift Summary - Owl
TITLE: 12/21 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 71.7255Mpc
INCOMING OPERATOR: Jim
SHIFT SUMMARY:
Quiet , glitch free night. Livingston reported some possible artifacts from maintenance day causing sporadic lock stretches.
LOG:
 
Images attached to this report
Comments related to this report
john.worden@LIGO.ORG - 13:40, Wednesday 21 December 2016 (32816)

Re EX temperatures;

I have made adjustments at both EX and EY (lowered heater settings by 1ma). Bubba will adjust chilled water settings tomorrow morning.

H1 TCS (TCS)
nutsinee.kijbunchoo@LIGO.ORG - posted 23:30, Tuesday 20 December 2016 - last comment - 09:27, Thursday 22 December 2016(32801)
Second PCI-e card didn't solve the glitch problem

Carlos, Jim B, Dave, Nutsinee

Follow up of WP6382

I took advantage of the earlier down time to test the HWS stream images script and swapping CLink around. The original set up after Carlos installed the second PCI-e card was HWSY CLink was plugged into the new card and HWSX CLink remained the same (plugged to old card). HWSX streamed live images without problem while HWSY can't get any sensible image at all (see attachment). So I tried a few more configurations:

We have come to the conclusion that the spare card might be busted. The next thing to try is to order a new card and try again. This way we will know for sure that the card actually works. We don't know where the spare card came from and whether or not it has been tested.

Images attached to this report
Comments related to this report
nutsinee.kijbunchoo@LIGO.ORG - 16:30, Wednesday 21 December 2016 (32820)

Only HWSX code is left running for now.

aidan.brooks@LIGO.ORG - 09:27, Thursday 22 December 2016 (32835)

The cards were all ordered at the same time for aLIGO but were not individually tested.

It's probably the capture card but It might also be the actual PCI slot on the bus. Have you tried swapping the two cards around?

  • card one in slot one, card two in slot two (FAIL)
  • card one in slot two, card two in slot one (??)
Displaying reports 51241-51260 of 83165.Go to page Start 2559 2560 2561 2562 2563 2564 2565 2566 2567 End