Displaying reports 61541-61560 of 84537.Go to page Start 3074 3075 3076 3077 3078 3079 3080 3081 3082 End
Reports until 05:11, Saturday 21 November 2015
H1 General
jeffrey.bartlett@LIGO.ORG - posted 05:11, Saturday 21 November 2015 (23618)
Owl Mid-Shift Summary
   A good first half of the Owl shift. IFO in Observing mode for the past 9.75 hours, with a range around 80Mpc. Seismic is coming down from a mag 6.1 EQ in Indonesia, and is currently around 0.01um/s. Microseism is centered around 0.3um/s. Wind is still a calm to gentle breeze (0-7mph). 

   There have been 10 ETM-Y saturation events thus far. At 11:45 (03:45) there was an ETM-Y saturation associated with sharp spiked glitch in RF45.     
Images attached to this report
H1 General
jeffrey.bartlett@LIGO.ORG - posted 00:22, Saturday 21 November 2015 (23617)
Ops Owl Shift Transition
Title:  11/21/2015, Evening Shift 08:00 – 16:00 (00:00 – 08:00) All times in UTC (PT)
	
State of H1: 08:00 (16:00), The IFO locked at NOMINAL_LOW_NOISE, 22.2w, 80Mpc.  

Outgoing Operator: TJ

Quick Summary:  IFO has been in Observing mode for the past 6 hours. Environmental conditions are good – wind is a calm to light breeze (0-7mph) seismic activity is well below 0.1 um/s and microseism is centered around 0.3 um/s.  
LHO General
thomas.shaffer@LIGO.ORG - posted 00:01, Saturday 21 November 2015 (23616)
Ops Eve Summary

TITLE: 11/21 EVE Shift: 00:00-08:00UTC (16:00-00:00 PDT), all times posted in UTC

STATE Of H1:  Observing for 5.5hrs at 79Mpc

SHIFT SUMMARY: Lost lock once, still not sure why, but other than that it was smooth sailing.

INCOMING OPERATOR: Jeff B

ACTIVITY LOG:

LHO General
thomas.shaffer@LIGO.ORG - posted 18:39, Friday 20 November 2015 (23615)
Observing

Observing at 02:32 UTC

Locking DRMI took around 35min. It would start to catch it for a second and then lose it. This happened a handful of times before I went to just lock PRMI. PRMI locked very quickly and needed minimal adjustment. Went back to DRMI and it was the same story, and alignment looked good. Eventually it locked and stayed lock.

There was an odd SDF difference before I went back to Observing. H1:LSC-TRIG_MTRX_2_8 was 1.0 but was saved at 0.0. This was the ASAIR_B_RF18 leading to MICH_TRIG. Trending it showed that it has been 0 for the last few days. I didn't see anything in the alog. So I just put it back to 0. Not sure why it would have suddenly changed...

Images attached to this report
LHO General
thomas.shaffer@LIGO.ORG - posted 17:12, Friday 20 November 2015 (23614)
Lockloss

Lockloss at 01:10 UTC

Cause: Unknown (for now)

LHO General
patrick.thomas@LIGO.ORG - posted 16:43, Friday 20 November 2015 (23608)
Ops Day End Shift Summary
TITLE: 11/20 [DAY Shift]: 16:00-24:00 UTC (08:00-16:00 PDT), all times posted in UTC
STATE Of H1: Locked at NLN
SHIFT SUMMARY: Out of observing while Jeff B. went to end Y. Lost lock when Keita and Evan removed the RF AM monitor coupler from the EOM driver cable. Switched blends to Quite_90. Had to move TMS X and Y to optimize green. Had to move BS and PRM to lock on DRMI. Lost lock on SWITCH_TO_QPDS. Locked on NLN.
SUPPORT: Jenne, Evan, Keita, Jim W.
INCOMING OPERATOR: TJ
ACTIVITY LOG:

16:12 Jeff B. to end Y to take pictures in receiving area and hallway to VEA, out of observing
16:18 Chris and Joe to X arm beam tube enclosure
16:39 Jeff B. back, back to observing
17:24 Bubba reports that the landscapers are bailing tumble weeds around the highbay
17:32 Landscapers truck driving back toward kitchen
18:20 Gerardo to mid Y to pick up power supply and then to X28
18:23 Karen to mechanical building to get coffee cups
18:36 Fire department through gate, notified Richard
18:38 Kyle to X28
18:38 Fire department to mid X to check on RFAR
Fire department back (forgot to note time, before 19:39)
19:54 Joe back, Chris on his way back
20:12 Kyle and Gerardo back
21:32 Evan and Keita into the H1 PSL enclosure to remove the RF AM monitor coupler from the EOM driver cable, out of observing
21:33 Kyle and Gerardo back to X28
21:38 Joe and Chris back to X arm beam tube enclosure
22:12 Evan and Keita done

Put ISI blends on Quite_90
Had to move TMS X and TMS Y to increase green power in both arms even though WFS were engaged
Went to LOCK_PRMI and misaligned PRM. Aligned the BS on flashes.
Realigned PRMI and was able to lock PRMI. Moved mostly PRM to increase power buildup.
Requested DRMI_LOCKED. Transition from LOCK_PRMI to DRMI_LOCKED failed. Eventually DRMI locked.

23:13 Joe and Chris back
23:38 Kyle and Gerardo back
LHO General
thomas.shaffer@LIGO.ORG - posted 16:21, Friday 20 November 2015 (23612)
Observing

Observing @ 00:19 UTC

LHO General
thomas.shaffer@LIGO.ORG - posted 16:06, Friday 20 November 2015 (23611)
Ops Eve Transition
H1 SEI
jim.warner@LIGO.ORG - posted 16:03, Friday 20 November 2015 - last comment - 17:33, Wednesday 02 December 2015(23610)
BSC Blend switching glitches

Because the microseism is down to a level similar to what we saw over the summer, I asked Patrick to put the ISI's in the more wind tolerant 90 mhz blends. Wind is also low right now, but it can come up suddenly, while microseism takes days to rise. We also need more data about what conditions necessitate switching. After, Evan and Keita finished in the PSL, Patrick started relocking but was having troubles with the  green. Fiddling the TMS alignments fixed it, I looked to see if the ISI positions had changed. They haven't moved but I found something interesting.

Most of the ISIs all showed a relatively smooth switch from the 45 to 90 blends except for ETMY. ITMY is the first plot and is pretty consistent with all the other chambers, except ETMY. Patrick switched the X&Y blends at the same time , in the middle of the time span I grabbed in the plot. You can kind of tell because the ITMY location mon range gets a little smaller and there are fewer low frequency swings on X&Y, due to the lower gain peaking at higher frequency of the 90 blend. The other DOFs don't seem to see anything.

ETMY however shows a huge 30 micron shift in the Y direction (second plot), and is visible in all DOFs. This chamber was only running the 45mhz blend in the Y DOF, so only the Y blend got switched on this chamber, at about 21:48 UTC today. No idea why it should be any different from the other chambers, although BrianL did note a while ago that the ETMY STS is poorly centered (maybe relevant because the STS is used for sensor correction, so gets summed with the CPS signal before the blend). It would be good to get some time to see if this is repeatable and truly limited to ETMY or not.

Images attached to this report
Comments related to this report
brian.lantz@LIGO.ORG - 17:33, Wednesday 02 December 2015 (23919)
For some discussion about how to fix this, see the SEI log, entry 887.
https://alog.ligo-la.caltech.edu/SEI/index.php?callRep=887

short answer - 
1) SEI team needs to update the blend-switch code to wait longer during the switch process so that the transients can settle down.
2) don't try to change the blend filters while the Tidal-offload is pushing hard on HEPI - wait at least 200 seconds after it finishes. 
3) SEI team needs to have less tilt on HEPI when it gets moved by the tidal offload.

LHO FMCS
bubba.gateley@LIGO.ORG - posted 15:59, Friday 20 November 2015 (23609)
Staging building double doors
The lock for the double doors on the upper section of the staging building is completely disabled. It will be addressed next week.
LHO FMCS
bubba.gateley@LIGO.ORG - posted 15:55, Friday 20 November 2015 (23607)
Beam Tube Enclosure Joint Repair on the X-Arm
This report will include this week and last week. We were able to clean the joints, install metal strips and caulk on 360 meters of enclosure.
LHO VE
kyle.ryan@LIGO.ORG - posted 15:47, Friday 20 November 2015 (23606)
BT ion pump @ X2-8
Kyle, Gerardo 

Today we tested the functionality of the ion pump mounted at X2-8 using a local controller and cable -> pump works as expected -> We also changed the oil and filter on the diesel generator and finished installing the heat tapes etc. on the ion pump-connecting vacuum hardware -> We will start the 72 hr. bake out of the new ion pump Monday morning.  We will need access to BT port X2-8 every 10 hrs. or so between 0900 Monday morning thru Wednesday afternoon to refuel the generator.
H1 ISC
evan.hall@LIGO.ORG - posted 15:16, Friday 20 November 2015 (23605)
45 MHz EOM couplers removed

Keita, Evan

We went in and removed the couplers between the EOM driver and the EOM (see 23472), as well as the extra phase delay cable on the ISC rack which was being used to match the coupler-induced delay.

Removing the couplers got rid of the extra noise on the 45 MHz OOL readback (see attachment).

Strangely, putting the couplers on the spare driver in the CER (which is terminated with a 50 Ω resistor, rather than an EOM) does not produce this extra noise (see attachment).

We have turned the spare driver back on and reconnected it to the digital system.

Non-image files attached to this report
H1 INJ (INJ)
cregg.yancey@LIGO.ORG - posted 15:01, Friday 20 November 2015 - last comment - 16:02, Wednesday 06 January 2016(23603)
HWInjReport 1129593617 - 1131828544

HWInjReport 1129593617 - 1131828544

Performed a run spanning the time period from 1129593617 (Oct 23 2015 00:00:00 UTC) to 1131828544 (Nov 17 2015 20:48:47 UTC)

Parameters

The following parameters were used for this run:

Scheduled Injections

Only two injections were found to be scheduled during this period:

However, neither of these injections were found to actually occur within the examined time period.

Network and IFO Injections

There were no normal injections that occurred within the examined period. There were a number CAL-INJ resets, all single-IFO with the same curious pattern to the frame flags as denoted in the immediately prior HWInj report (https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=23485). There was a single-IFO burst injection in H1

BURST 1129673117.000 (H1)

with the only anomaly being that it is UNSCHEDULED. There was a single UNKNOWN injection in L1

UNKNOWN 1129673117.000 (L1)

This injection was confirmed to occur only within the CAL-INJ channel of RAW frames with the TRANSIENT bit indicating an injection but none of the specific injection-type bits, CBC, BURST, DETCHAR, or STOCHASTIC, indicating an injection. It was confirmed to not occur in ODC HOFT, ODC RDS, ODC RAW, or GDS HOFT frames.

Discussion of Anomalies

It is interesting that the single-IFO injections BURST 1129673117.000 (H1) and UNKNOWN 1129673117.000 (L1) are found to occur at the exact same time but within different IFOs. Even further, the fact the BURST injection in H1 is perfectly normal, other than being UNSCHEDULED, while the UNKNOWN injection in L1, in addition to being UNSCHEDULED, is inconsistent. HWInjReport currently does not check the HW bit or the CW bit in the CAL-INJ channel for RAW frames for the presence of injections; however, upon examining these bits directly, it was found that while the HW bit indicated an injection, along with the TRANSIENT bit, the CW bit did not indicate an injection (my first thought was that this may be a CW injection only occurring in L1). This means this was a truly UNKNOWN, UNSCHEDULED injection occurring only with L1. Given both injections occur at the exact same time and the L1 injection is a truly UNKNOWN type (practically a ghost injection, by the bits), it is likely this was intended to be a normal network injection; however either user-error or a catastrophic software error corrupted the proper setting of the bits.

Non-image files attached to this report
Comments related to this report
cregg.yancey@LIGO.ORG - 14:21, Monday 23 November 2015 (23670)

There was an additional UNKNOWN injection that occurred at 1131397646 in both H1 and L1 (as noted by Peter Shawhan) with a signature similar to the one reported here.  However, for some reason HWInjReport missed it.  I will have to investigate why HWInjReport missed that particular injection, but, unlike the last session of bug-fixing, I am not going to cease production of reports.  It is my estimation that HWInjReport is currently operating with reasonable confidence to find and report most true anomalies.  If reporting errors or omissions are found, then those errors should be correctable and a new report on the relevant time period can be generated.

christopher.biwer@LIGO.ORG - 13:54, Monday 14 December 2015 (24206)
I didn't see any follow-up on this but I did some checks:

The injection at 1129673117 is the stochastic hardware injection that Joe and Chris did. This was out of science mode.

The injection at 1131397646 should be the injection in the schedule file from line: 1131397639 1 1.0 coherentbbh0_1126259455_

This CBC injection was not logged properly for the searches because tinj was setting CAL-INJ_TINJ_TYPE instead of CAL-PINJX_TINJ_TYPE. So I would guess that was the problem that you're seeing here. The issues have since been fixed though.
cregg.yancey@LIGO.ORG - 16:02, Wednesday 06 January 2016 (24732)INJ

Now that I finally have my diagnostic tool working (it's a ripped-down version of HWInjReport called HWInjCheck that simply returns raw output from FrBitmaskTransitions to allow rapid verification of anomalies found in HWInjReport), I re-examined the missing UNKNOWN injection at 1131397646.  Firstly, HWInjReport can only identify injections as UNKNOWN if they occur in the CAL-INJ.  This is because, as far as I can determine, only the CAL-INJ channel has an independent excitation bit that indicates whether a transient injection has occurred, regardless of type (as well as an independent HW bit indicating the occurrence of an injection of any type).  This does not seem to be true for ODC-MASTER and GDS-CALIB channels.  So, in CAL-INJ, if the TRANSIENT bit is "off" (indicating the presence of a transient injection) but the CBC, BURST, DETCHAR, and STOCHASTIC bits, which indicate the type of injection, are "on", then it is clear we have an UNKNOWN type transient injection occurring.  However, for ODC-MASTER and GDS-CALIB, if the type bits are not "off", there is nothing to indicate excitation of a transient injection with an unspecified type.  If 1131397646 occurs with an unspecified type in the ODC-MASTER or GDS-CALIB channel but not in the CAL-INJ channel, then HWInjReport will completely miss the injection as it won't show up at all in any of the bits and channels that HWInjReport checks.

Using HWInjCheck to check the output from FrBitmaskTransitions, I have not, yet, found any indication of the occurrence of 1131397646, that is, there is no indication of excitation in the excitation bits.  I will check again more carefully, but, at this point, it does seem HWInjReport is working properly; this is an expected missing injection.  To be clear, there may still have actually been an excitation, there just doesn't seem to be any record of it in the bits and channels that HWInjReport checks.

H1 CAL (CAL)
richard.savage@LIGO.ORG - posted 14:34, Friday 20 November 2015 (23604)
Analysis of DARM time varying factors generated using the GDS calibration code

SudarshanK, RickS

Using the 16 Hz kappas generated by the GDS code from the C01 frames, we generated the differences between a given kappa value and the one immediately preceding it ("deltaKappas") with the caveat that we have pre-selected only the kappas for which the GDS state vector is greater or equal to 32735.
 
The first plot below is kappa_tst and kappa_C for the full period, about 9 days.
 
In the second through fifth plots below, the blue points are these deltaKappas and the red points are the deltaKappas that exceed the thresholds of +,- 0.0008 for deltaKappa_tst and +,- 0.002 for deltaKappa_C.
 
Plots:
The kappas for the whole 9 days.
The deltaKappas for the whole 9 days.
The deltaKappas for two one-day periods
The deltaKappas for one six-hour period
Images attached to this report
H1 General
patrick.thomas@LIGO.ORG - posted 14:15, Friday 20 November 2015 (23602)
Relocking
Evan and Keita are done. Attempting to relock. ISI blends are on Quite_90 per Jim's request.
H1 General
betsy.weaver@LIGO.ORG - posted 13:52, Friday 20 November 2015 - last comment - 13:47, Saturday 21 November 2015(23601)
VCO channel flipped once 10 days ago - does this mean anything to anyone?

While trying to understand and deal with the Beckhoff SDF diffs in OBSERVE mode, I stumbled on a weird channel that toggled states around 4pm local last Wed Nov 11 (01 UTC WED 11th).  (Note, this occured well before the windy troublesome locking period when we saw a power glitch on Tuesd Wed 17th.)  If the VCO Frequency Servo is set to "Int" (see the center of the medm pic attached below), do we care what this EXTFREQUENCYOFFSET channel is doing?  And where is the medm for this EXTFREQUENCYOFFSET channel anyways? - Even with commissioners, we couldn't immediately find it...  And, and, what's with the glitch in the middle of the 20 day trend on Wed 11th?

Images attached to this report
Comments related to this report
peter.king@LIGO.ORG - 13:47, Saturday 21 November 2015 (23627)
Not sure but it might be related to this entry.
https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=23293
Perhaps the wrong button was pushed?  Or if there were problems
encountered re-locking the input modecleaner after installation
of the 45 MHz RFAM hardware, this may have been flipped to see
if the input modecleaner would lock.
H1 General
betsy.weaver@LIGO.ORG - posted 13:39, Friday 20 November 2015 (23600)
This weeks charge measurements on ETMs - taken Wed

Attached are the updated charge trends with this weeks newest data.  So far so good...

Images attached to this report
H1 General
patrick.thomas@LIGO.ORG - posted 13:35, Friday 20 November 2015 (23599)
Out of observing
Evan and Keita are going into the H1 PSL enclosure to remove the RF AM monitor coupler from the EOM driver cable. This will take us out of lock.
H1 ISC
evan.hall@LIGO.ORG - posted 17:47, Thursday 19 November 2015 - last comment - 16:26, Friday 20 November 2015(23577)
DARM residual with AS45Q and DCPD sum

As a follow-up to Hartmut's question about the DARM rms, here are spectra of the in- and out-of-loop DARM sensors before and after transitioning to DC readout (at 2 W input power). The spectra are calibrated into RIN.

The left-hand plots show the sensors when DARM is controlled via AS45Q. Above 10 Hz or so, we see the sensing noise of AS45Q impressed onto the DARM loop. From 2 Hz to 8 Hz or so, and below 0.5 Hz, both sensors appear to see some DARM displacement noise. Between 0.5 Hz and 2 Hz, the sensors are not seeing the same signal. If the AS45Q signal in this region is indeed DARM displacement noise (rather than some kind of loop-suppressed sensing noise), this would seem to indicate that the sensing noise of the DC readout chain is higher than the intrinsic DARM displacement noise by a factor of a few in this region.

The right-hand plots show the sensors when DARM is controlled via DCPD sum. During the transition, an additional boost is engaged (two complex poles at 2 Hz, two complex zeros at 8 Hz), so this makes it tricky to directly compare these plots with the left-hand plots. Probably it is best to try to get an equivalent set of plots for the intermediate case (DARM controlled by AS45Q, boost engaged).

Non-image files attached to this report
Comments related to this report
evan.hall@LIGO.ORG - 16:26, Friday 20 November 2015 (23613)

Attached is the same plot as before, but this time both configurations have the same OLTF (boost on).

Times:

  • 23:51:15 – 23:53:15: DARM on AS45Q, boost off
  • 23:53:30 – 23:55:30: DARM on AS45Q, boost on
  • 23:56:00 – 23:58:00: DARM on DCPD sum, boost on
Non-image files attached to this comment
Displaying reports 61541-61560 of 84537.Go to page Start 3074 3075 3076 3077 3078 3079 3080 3081 3082 End