Displaying reports 49101-49120 of 83228.Go to page Start 2452 2453 2454 2455 2456 2457 2458 2459 2460 End
Reports until 16:44, Monday 27 March 2017
H1 General
nutsinee.kijbunchoo@LIGO.ORG - posted 16:44, Monday 27 March 2017 (35118)
Ops EVE shift transition

TITLE: 03/27 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC

STATE of H1: Observing at 65Mpc

OUTGOING OPERATOR: Jim

CURRENT ENVIRONMENT: Wind: 16mph Gusts, 13mph 5min avg Primary useism: 0.05 μm/s Secondary useism: 0.34 μm/s

QUICK SUMMARY: Been locked for 10.5 hours. Balers should be done by now (Bubba reported that they should be done by 16:30 local) Nothing else to report.

H1 General
jim.warner@LIGO.ORG - posted 16:05, Monday 27 March 2017 (35117)
Shift Summary

TITLE: 03/27 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 67Mpc
INCOMING OPERATOR: Nutsinee
SHIFT SUMMARY:
LOG:

15:00 Bailers on Xarm

21:00 Betsy, TJ to Opstics Lab, out 22:00

21:15 Fil & Richard on Xarm, working on vault

22:00 Gerardo to optics lab

21:30 Evan & Miriam doing blip glitch measurements while LLO is down

H1 ISC
kiwamu.izumi@LIGO.ORG - posted 15:37, Monday 27 March 2017 (35115)
preparation for model change on OMC and CALCS

WP 6544, ECR E1700107,

I have updated the following frontend models to implement the time-domain DCPD cross correlation technique.

The h1omc and h1calcs models will be installed and restarted tomorrow during the maintenance period.


[The changes]

Here is a list of things that I newly added today in the OMC models (namely h1omc.mdl and omc.mdl). Also the attached are screenshots of relevant part of the models.

Here is a list of things I added today in the CAL CS models, e.g. h1calcs.mdl and CAL_CS_MASTER.mdl.

After these changes, I confirmed that they compile without an error. They are ready for tomorrow's installation. The models are checked into svn.

Images attached to this report
H1 DetChar (DetChar)
miriam.cabero@LIGO.ORG - posted 15:28, Monday 27 March 2017 - last comment - 12:26, Tuesday 28 March 2017(35116)
Blip-like injections

Evan, Miriam,

While L1 was having a small lock loss, we made a series of injections (with H1 in comissioning mode) in the H1:SUS-ETMY_L2_DRIVEALIGN_Y2L_EXC channel. The injections are single sine-gaussian pulses that simulate blip glitches (see https://ldas-jobs.ligo-wa.caltech.edu/~miriam.cabero/sine-gaussian.png ).

We started very quiet and slowly increased the amplitude, so that only the last 3 of the 9 injections appear in GDS-CALIB_STRAIN. The GPS times of the injections are:

1174684631

1174684680

1174684715

1174684745

1174684793

1174684854

1174684889 *

1174684945 *

1174685355 *

* Can be seen in CALIB_STRAIN

 

We will be repeating this kind of injections at opportunistic times (L1 not observing) in the next days, taking different blip morphologies, and different amplitudes.

Comments related to this report
andrew.lundgren@LIGO.ORG - 12:26, Tuesday 28 March 2017 (35143)DetChar, ISC, SUS
Only the loudest of these saturated the noisemons, and it did so by hitting an analog limit at plus/minus 22000 counts.

I projected the drive signal into noisemon counts and looked at the last three injections on the list. In the first two, the noisemon signal tracks the drive, and the subtraction of the two is just noise. In the last (loudest) injection, the noisemon hits an analog saturation at both plus and minus 22,000 counts leaving a huge glitch in the subtracted data.

This is good because it suggests that the only important analog limit in the noisemon is this threshold. I don't have time to document it now, but I've tried the same with a set of loud detchar injections, which go up to hundreds of Hz, and I get the same behavior. So when the drive signal does not push the noisemon beyond 22,000 counts, we can trust the subtraction, and anything we see has entered the signal between the DAC and noisemon; it's a glitch in the electronics and not a result of the DARM loop.

Attached are the three subtractions, noisemon minus projected drive signal.
Images attached to this comment
LHO FMCS
bubba.gateley@LIGO.ORG - posted 13:25, Monday 27 March 2017 (35113)
HVAC Controls Upgrade
Apollo is working at Mid-Y on the HVAC controls upgrade project. Both air handlers are down and will be for the night. This may cause a slight temperature rise in the building and may trigger some alarms. These are minor and only temporary.
H1 CDS (SYS)
david.barker@LIGO.ORG - posted 12:12, Monday 27 March 2017 - last comment - 11:09, Tuesday 04 April 2017(35111)
Timing error at 08:45 PDT this morning

Jim, Dave:

At 15:44:58 UTC (08:44:58 PDT) we received a timing error which only lasted for one second. The error was reported by the CNS-II independent GPS receivers at both end stations, they both went into the 'Waiting for GPS lock' error state at 15:44:58, stayed there for one second, and then went good. The IRIG-B signals from these receivers are being acquired by the DAQ (and monitored by GDS). The IRIG-B signals for the second prior, the second of the error, and the following two seconds (4 seconds in total) are shown below.

As can be seen, even though EX and EY both reported the error, only EX's IRIG-B is missing during the bad second.

The encoded seconds in the IRIG-B are shown in the table below. Note that the GPS signal does not have leap seconds applied, so GPS = UTC +18.

Actual seconds EX IRIG-b seconds EY IRIG-b seconds
15 15 15
16 missing 16
17 16 17
18 18 18

So EY was sequential through this period. EX slipped the 16 second by a second, skipped 17 and resynced at 18.

Images attached to this report
Comments related to this report
stefan.countryman@LIGO.ORG - 08:02, Tuesday 28 March 2017 (35126)
Summary: All problems were in CNS II GPS Channels at LHO. No problems were observed in the Trimble GPS Channels at either site, nor in the LLO CNS II Channels, with the exception of a change of -80ns in the LLO Trimble GPS PPSOFFSET a few seconds after the anomally (see below). It seems that both LHO CNS II Clocks simultaneously dropped from 10 to 3 satellites tracked for a single second. There is no channel recording the number of satellites locked by the Trimble clocks, but the RECEIVERMODEs at both sites remain at the highest level of quality, OverDeterminedClock (level 5 for the Trimbles) with no interruption at the time of the anomaly.

It is unclear whether the LLO PPSOFFSET is causally related to the LHO event; the lack of other anomalous output from the LLO Trimble clock suggests that it is otherwise performing as intended.

Descriptions of anomalous plots below. All anomalous plots are attached.

Dilution of precision at BOTH LHO CNS II clocks skyrockets to 100 around the event (nominal values around 1) (H1:SYS-TIMING_X_GPS_A_DOP, H1:SYS-TIMING_Y_GPS_A_DOP). Number of satellites tracked by BOTH LHO CNS II clocks Plummets or two seconds from 10 to 3 (H1:SYS-TIMING_X_GPS_A_TRACKSATELLITES, H1:SYS-TIMING_Y_GPS_A_TRACKSATELLITES). In the second before the anomaly, Both of the LHO CNS II Clocks' RECEIVERMODEs went from 3DFix to 2DFix for exactly one second, as evidenced by a change in state from 6 to 5 in their channels' values (H1:SYS-TIMING_X_GPS_A_RECEIVERMODE, H1:SYS-TIMING_Y_GPS_A_RECEIVERMODE). The 3D Speed also spiked right around the anomaly for both LHO CNS clocks (H1:SYS-TIMING_X_GPS_A_SPEED3D, H1:SYS-TIMING_Y_GPS_A_SPEED3D). LHO CNS II Clock's 2D speeds both climb up to ~0.1 m/s (obviously fictitious) (H1:SYS-TIMING_X_GPS_A_SPEED2D, H1:SYS-TIMING_Y_GPS_A_SPEED2D). LHO Y-End CNS II Clock calculated a drop in elevation of 1.5m following the anomaly (obviously this is spurious) (H1:SYS-TIMING_Y_GPS_A_ALTITUDE). LHO X-End CNS II Clock thinks it dropped by 25m following the anomaly! I'm not sure why this is so much more extreme than the Y-End calculated drop (H1:SYS-TIMING_X_GPS_A_ALTITUDE). The Livingston Corner GPS PPSOFFSET went from its usual value of ~0+/-3ns to -80 ns for a single second at t_anomaly + 3s (L1:SYS-TIMING_C_GPS_A_PPSOFFSET). The GPS Error Flag for both LHO CNS II clocks came on, of course (H1:SYS-TIMING_Y_GPS_A_ERROR_FLAG, H1:SYS-TIMING_X_GPS_A_ERROR_FLAG)
Images attached to this comment
patrick.thomas@LIGO.ORG - 11:09, Tuesday 04 April 2017 (35312)
Using my very limited knowledge of Windows administration, I have attempted to list the events logged on h1ecatc1 from 8:00 - 10:00 AM on Feb. 27 2017. Attached is a screenshoot of what was reported. I don't see anything at the time in question. However, there is a quite reasonable chance that there are other places to look that I am not aware of and/or I did not search correctly.
Images attached to this comment
LHO VE
logbook/robot/script0.cds.ligo-wa.caltech.edu@LIGO.ORG - posted 12:10, Monday 27 March 2017 - last comment - 13:45, Monday 27 March 2017(35110)
CP3, CP4 Autofill 2017_03_27
Starting CP3 fill. LLCV enabled. LLCV set to manual control. LLCV set to 50% open. Fill not completed after 3600 seconds. LLCV set back to 15.0% open.
Starting CP4 fill. LLCV enabled. LLCV set to manual control. LLCV set to 70% open. Fill completed in 1127 seconds. TC A did not register fill. LLCV set back to 44.0% open.
Images attached to this report
Comments related to this report
chandra.romel@LIGO.ORG - 13:45, Monday 27 March 2017 (35114)

Raised CP4 to 45% open.

Manually overfilled CP3 from control room at 100% open (@1:35pm local). Took 9 min. to overfill. Raised nominal value to 17% open.

H1 General
christopher.soike@LIGO.ORG - posted 10:48, Monday 27 March 2017 (35109)
VPW Desiccant cabinet relative humidity readouts for the last month+
Attached are plots with this months' data.
Non-image files attached to this report
H1 DetChar (DetChar)
alexander.urban@LIGO.ORG - posted 10:13, Monday 27 March 2017 (35108)
DQ shift report, 23-26 March 2017

I have finished my DQ shift at LHO for 23-26 March 2017. Here are the highlights:

My full report can be read at the DQ shift wiki page.

H1 PSL
edmond.merilh@LIGO.ORG - posted 09:07, Monday 27 March 2017 (35106)
PSL 10 Day Weekly Trends: FAMIS #6141

Everything appears normal. 

Images attached to this report
LHO General
patrick.thomas@LIGO.ORG - posted 07:53, Monday 27 March 2017 - last comment - 08:14, Monday 27 March 2017(35102)
Ops Owl Shift Summary
TITLE: 03/27 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 63Mpc
INCOMING OPERATOR: Jim
SHIFT SUMMARY: One lock loss from 6.1 mag earthquake west of Alaska. No issues relocking after seismic settled down. Accepted SDF differences from Cheryl's bounce mode damping filter changes.
LOG:

07:22 UTC Powercycled video0
11:13 UTC Lock loss (earthquake). Set to down. Set observing bit to earthquake.
13:18 UTC Back to observing. Accepted SDF differences for Cheryl's bounce mode damping filter changes (see attached).
13:25 UTC Powercycled video2
13:40 UTC Damped PI mode 27 by changing phase from -80 to 0
13:48 UTC Damped PI mode 27 by changing phase to 20
14:09 UTC Bubba to mid Y with Apollo to work on HVAC controls
Images attached to this report
Comments related to this report
patrick.thomas@LIGO.ORG - 08:12, Monday 27 March 2017 (35103)
15:12 UTC Balers are at mid X and working towards end X
patrick.thomas@LIGO.ORG - 08:14, Monday 27 March 2017 (35104)
15:14 UTC Damped PI mode 28 by changing sign of gain
H1 SEI
patrick.thomas@LIGO.ORG - posted 04:32, Monday 27 March 2017 (35101)
Earthquake Report
6.1 Attu Station, Alaska

Was it reported by Terramon, USGS, SEISMON? Yes (twice), Yes, No

Magnitude (according to Terramon, USGS, SEISMON): 6.1, 6.1, NA

Location: 66km W of Attu Station, Alaska; 52.798°N   172.199°E

Starting time of event (ie. when BLRMS started to increase on DMT on the wall): ~10:58 UTC

Lock status? Both L1 and H1 lost lock.

EQ reported by Terramon BEFORE it actually arrived? Not sure
Images attached to this report
LHO General
patrick.thomas@LIGO.ORG - posted 04:01, Monday 27 March 2017 (35100)
Ops Owl Mid Shift Summary
Have remained in observing. No issues to report.
H1 SEI
patrick.thomas@LIGO.ORG - posted 02:49, Monday 27 March 2017 (35098)
Earthquake Report
3.1 Eureka, Nevada

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

Magnitude (according to Terramon, USGS, SEISMON): 3.1, 3.1, NA

Location: 35km S of Eureka, Nevada; 39.189°N   115.938°W

Starting time of event (ie. when BLRMS started to increase on DMT on the wall): ~9:24 UTC

Lock status? H1 stayed locked, L1 broke lock, but L1 operator says not likely due to earthquake

EQ reported by Terramon BEFORE it actually arrived? Not sure
Images attached to this report
H1 General
cheryl.vorvick@LIGO.ORG - posted 19:51, Saturday 25 March 2017 - last comment - 09:29, Monday 27 March 2017(35085)
H1 glitch, Verbal Alarms shows OMC DCPD Saturation, but date and time are incorrect, maybe the claimed source of the glitch is too
Images attached to this report
Comments related to this report
thomas.shaffer@LIGO.ORG - 09:29, Monday 27 March 2017 (35107)OpsInfo

This is a classic case of "Middle-Click Syndrome". Someone highlighted that OMC DCPD line in the Verbal Terminal and then accidentally middle clicked later. I checked this by first checking the Verbal logs to make sure it wasn't in there, and then I went to the alarms work station and middle clicked in the Verbal Terminal. Sure enough, the same March 10 OMC DCPD saturation message showed up.

H1 General
cheryl.vorvick@LIGO.ORG - posted 19:39, Saturday 25 March 2017 - last comment - 13:13, Monday 27 March 2017(35086)
Control Room computers powered off

About an hour after coming on shift I noticed something in the CR air and put on my mask, but after a while it was clear that that didn't help, so I started looking for other things, and realized it sort of smelled like burnt plastic.  Called Corey, Richard, Dave, and a couple other people.  Turned off most of the CR computers (about 4 warm ones), checked the MSR, checked the Computer user's room, and the smell was only in the CR.  Tried to contact Robert, waited, but then turned off his computer, and am now waiting to see if that computer was overheating, and if turning it off clears up the air.

Currently watching H1 from the Computer Users Room, and have Verbal Alarms running in here.

Comments related to this report
david.barker@LIGO.ORG - 13:13, Monday 27 March 2017 (35112)

we were not able to pin down where the odor was coming from, and there are no odors today.

H1 CAL (CAL)
aaron.viets@LIGO.ORG - posted 09:54, Friday 24 March 2017 - last comment - 05:20, Wednesday 07 June 2017(35041)
Data collected to analyze SRC detuning
I have added an (unreleased) algorithm into the GDS/DCS pipeline to compute the SRC spring frequency and Q. This algorithm was used to collect 18 hours of data on February 4 (first plot) and 18 hours of data on March 4 (second plot). The plots include kappa_c, the cavity pole, the SRC spring frequency, the SRC Q, and 4 of the coherence uncertainties (uncertainty of the 7.93 Hz line is not yet available).

The derivation this algorithm was based on is similar to what Jeff has posted ( https://dcc.ligo.org/DocDB/0140/T1700106/001/T1700106-v1.pdf ), with differences noted below:
1) The approximation made at the bottom of p4 and top of p5 was only used in the calculation of kappa_c and the cavity pole. So SRC detuning effects were not accounted for in computing S_c. However, kappa_c and the computed cavity pole were used in the calculation of S_s.
2) In eq. 18, I have a minus (-) sign instead of a plus (+) sign before EP6. S_c = S(f_1, t) has been computed this way in GDS/DCS since the start of O2 (I assume during O1 as well).
3) Similarly, in eq. 20, I have a minus sign (-) before EP12.
4) In the lower two equations of 13, I have the terms under the square root subtracted in the opposite order, as suggested by Shivaraj. (Also, I noted that the expression for Q should only depend on S(f_2, t), with no dependence on S(f_1, t). )

The smoothing (128s running median + 10s average) was done on f_s and 1/Q, since that is the way they would be applied to h(t). Therefore, the zero-crossings of 1/Q show up as asymptotes in the plot of Q. I think it would be better to output 1/Q in a channel rather than Q for this reason.

There is a noticeable ramping up of f_s at the beginning of lock stretches, and the range of values agrees with what has been measured previously.

I've noted that it is quite difficult to resolve the value of Q with good accuracy. These are some reasons I suspect:
1) Higher uncertainty of calibration measurements at low frequency can add a systematic error to the EPICS values computed at 7.93 Hz. This may be why the Q is more often negative than positive ??
2) In the calculation of S_s, the actuation strength is subtracted from the ratio of pcal and DARM_ERR. Since this is such a low frequency, the subtracted values are close to the same value in magnitude and phase. Thus, subtracting magnifies both systematic error and uncertainty.
3) The imaginary part of S_s (see eq. 13, bottom equation) in the denominator, is very close to zero, so small fluctuations (about zero, as it turns out) in 1/Q cause large fluctuations in Q.

These reasons make it difficult to measure Q with this method. The effect of these measured-Q fluctuations on S_s, the factor we would actually apply to h(t) (see eq. 22), is not enormous, so long as we apply the smoothing to 1/Q, as I have done here.
Images attached to this report
Comments related to this report
shivaraj.kandhasamy@LIGO.ORG - 09:16, Monday 27 March 2017 (35105)CAL

First attachment is a hand written note containing derivation of the equations 13 in DCC document T1700106. As Aaron mentioned above, in the derivation the order of the quantities in the sqrt function comes out to be in the opposite order  (Re[S] - abs[S]^2 instead of abs[S]^2 - Re[S]).  The second plot show  the estimation of the four sensing function quantities for 2017-01-24 calibration sweep measurement done at LHO (a-log 33604). Instead of tracking across time here we track across sweep frequencies. The top two plots in the second figure show the estimation of optical gain and cavity pole frequency assuming no detuning. We see that above ~100 Hz we get almost constant values for optical gain and cavity pole frequency suggesting detuning doesn't affect the estimation of those quantities (currently we use 331.9 Hz line at LHO for estimating optical gain and cavity pole). Substituting back the optical gain and cavity pole calculated this way, we then calculated detuning frequency and Q. The bottom two plots of the second figure show those. We see that upto ~60 Hz we can use the lines to estimate detuning frequency (currently at LHO we are running the line at 7.83 Hz). However the Q is hard to estimate, the variation is pretty large (Evan's recent a-log also indicate this 34967; Aaron also finds this to be the case). Also in the 7-10 Hz region its value seems to be negative (need to look at more data to make sure that it not just a fluctuation). With the current set of calibration lines, it seems tracking of detuning frequency would easy but estimating Q might be a little difficult.

Images attached to this comment
Non-image files attached to this comment
shivaraj.kandhasamy@LIGO.ORG - 10:21, Monday 17 April 2017 (35584)

In the second page of the derivation,  at the half way point I have unintentionally switched the notation from S_s to S_c (it should be S_s till the end of the page 2).

aaron.viets@LIGO.ORG - 05:20, Wednesday 07 June 2017 (36692)
[Daniel Finstad, Aaron Viets]

The time series and histograms attached show additional data collected using the DCS calibration pipeline from Jan 19, 2017 at 21:44:14 UTC (GPS 1168897472) until Jan 20, 2017 at 09:02:38 UTC (GPS 1168938176).
Images attached to this comment
Displaying reports 49101-49120 of 83228.Go to page Start 2452 2453 2454 2455 2456 2457 2458 2459 2460 End