Displaying reports 51481-51500 of 83202.Go to page Start 2571 2572 2573 2574 2575 2576 2577 2578 2579 End
Reports until 18:26, Thursday 15 December 2016
H1 SUS
patrick.thomas@LIGO.ORG - posted 18:26, Thursday 15 December 2016 - last comment - 19:04, Thursday 15 December 2016(32616)
constant ETMY saturations
Verbal alarms started alerting that EY was saturating at 02:04 UTC. It has continued since. Attached is a plot of the L3 ESD drive signals for the last 2 hours. They have been growing. Is this the violin mode at 4.7 kHz that Keita and Cheryl were investigating?
Non-image files attached to this report
Comments related to this report
patrick.thomas@LIGO.ORG - 19:01, Thursday 15 December 2016 (32617)
02:44 UTC Out of observing.
Changed gain for H1:SUS-ETMY_L2_DAMP_MODE10 from 100 to 0.02. Turned off FM1 and turned on FM9 and FM10. 4.7kHz mode has come down and saturations have stopped.
02:59 UTC Back to observing.
patrick.thomas@LIGO.ORG - 19:04, Thursday 15 December 2016 (32618)
Accepted SDF differences attached.
Images attached to this comment
LHO General
patrick.thomas@LIGO.ORG - posted 17:06, Thursday 15 December 2016 (32614)
Ops Evening Shift Start
TITLE: 12/16 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 71.2515Mpc
OUTGOING OPERATOR: Cheryl
CURRENT ENVIRONMENT:
    Wind: 0mph Gusts, 0mph 5min avg
    Primary useism: 0.08 μm/s
    Secondary useism: 0.20 μm/s 
QUICK SUMMARY:

Locked for over 11 hours.
H1 General
cheryl.vorvick@LIGO.ORG - posted 15:51, Thursday 15 December 2016 - last comment - 17:35, Thursday 15 December 2016(32609)
Ops Day Summary:

TITLE: 12/15 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 70.0775Mpc
INCOMING OPERATOR: Patrick
SHIFT SUMMARY:

Activities:

Comments related to this report
cheryl.vorvick@LIGO.ORG - 16:27, Thursday 15 December 2016 (32613)

additional activity before I arrived:

  • 17:29UTC - alog 32600 - ETMY violin mode 10 damping switched from 4.7KHz to 1009Hz
  • this was successful in damping the 1009Hz, however the 4.7KHz harmonics are growing, see attached
Images attached to this comment
keita.kawabe@LIGO.ORG - 17:35, Thursday 15 December 2016 (32615)

Just FYI.

The problem of big violin (or any big high-Q resonances) is mostly the saturation of ADC (OMC DCPD) or DAC (mostly ESD).

To tell if whatever peak is too big or not, measure the OMC DCPD A  IN1 and one of the EY ESD output as shown in the attached.

First of all, you see the time series and OMC DCPD is still very far from its ADC ceiling of +-32k, and ESD output is also very far from its ceiling of +-131k, so you don't need to worry about saturations. Note that you need to set the resolution of dataviewer 16384 and observe for at least 10 seconds before making your judgement.

If these things approach the ceiling you need to damp the worst offender, which you identify by looking at the DARM spectrum, or better, by measuring the DCPD_A_IN1 and ESDOUTF_LL_OUT spectrum (second attachment). In this case, even though we already know that it's still safe, you can see that the 4.7kHz mode is the biggest offender. In DCPD it's about 100 cts RMS or 2*sqrt(2)*100 ~300 cts pp, which is totally negligible compared with DC. In ESDOUTF_LL_OUT, it's about 10k cts RMS or ~30k pp.

Images attached to this comment
H1 General
cheryl.vorvick@LIGO.ORG - posted 15:15, Thursday 15 December 2016 (32611)
earthquake

  Reported by Magnitude Location
Terramon yes 5.3

LAT: -9.9, LON:160.5

USGS yes 5.3 9.926°S 160.510°E
SEISMON no -  

Starting time of event on BLRMS: 22:48UTC

Lock status, did H1:

EQ reported by Terramon before it actually arrived: no

H1 DetChar
jordan.palamos@LIGO.ORG - posted 14:35, Thursday 15 December 2016 (32607)
DQ Shift: Dec 12th 00:00:00 - Dec 14th 23:59:59
Link to detailed report. Some highlights of the shift pasted below:
H1 DetChar (DetChar, ISC)
gabriele.vajente@LIGO.ORG - posted 13:46, Thursday 15 December 2016 - last comment - 14:52, Thursday 15 December 2016(32605)
BruCo scan

A scan of coherences can be found at the following link:

https://ldas-jobs.ligo.caltech.edu/~gabriele.vajente/bruco_lho_1165834817/

Here's my summary

Images attached to this report
Comments related to this report
young-min.kim@LIGO.ORG - 14:52, Thursday 15 December 2016 (32608)

Here is bruco scan on a recent time, 21:30:00 UTC (https://ldas-jobs.ligo-wa.caltech.edu/~youngmin/BruCo/ER10-O2A/H1/Dec15/H1-OMC-DCPD-1165872617-600/).

Now pitch motion is worse, see Fig1. ASC-CHARD_P_SM_DQ, Fig2. ASC-CSOFT_P_OUT_DQ

SUS-ITMY_L2_MASTER_OUT_UR_DQ shows high coherence value between 15~30Hz (Fig3..), and UL/LL/LR look similar.

is it a concern which should be handled ?

Images attached to this comment
H1 General
peter.king@LIGO.ORG - posted 13:28, Thursday 15 December 2016 (32604)
A VPW With A View
There has to be some bonus with this weather.
Images attached to this report
H1 General
cheryl.vorvick@LIGO.ORG - posted 10:47, Thursday 15 December 2016 (32602)
Ops Day Transition:

TITLE: 12/15 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 71.2751Mpc
OUTGOING OPERATOR: Corey, Jim
CURRENT ENVIRONMENT:
    Wind: 1mph Gusts, 0mph 5min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.21 μm/s
QUICK SUMMARY:

H1 General
jim.warner@LIGO.ORG - posted 09:48, Thursday 15 December 2016 (32600)
Dropped out of Observe to address 1009 hz violins

Terra noticed that one of the 1000 hz violins was pretty high. Because LLO is down, we decided to quickly try to address it. At 17:29, I ramped off the gain for the 4.7khz mode for ETMY mode 10, switch the BP filter to FM1 for the 1009.44 hz mode and left the 100db filter on. While watching the filter output and a live spectra, I slowly worked the gain up, it's sitting at 100 right now and both 1009hz modes seem to be coming down. We'll watch for a little while longer, then move back into Observe.

LHO General
corey.gray@LIGO.ORG - posted 08:23, Thursday 15 December 2016 - last comment - 09:17, Thursday 15 December 2016(32590)
OWL Operator Summary

TITLE: 12/15 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 73.335Mpc
INCOMING OPERATOR: Cheryl later if the winter weather/roads cooperate
SHIFT SUMMARY:

Have been in locked for all but 1hr of the shift (down for two locklosses).  Weather is the big news of the shift thus far.  There have been delayed work advisories issued and the latest is a Work Cancellation for the Hanford site---this is all due to Adverse Weather Conditions.  

I have talked with the LLO operator and have notified them of our situation & we should talk to them as soon as we get coverage back here, so they can stand down with covering for us.

LOG:

Comments related to this report
terra.hardwick@LIGO.ORG - 09:12, Thursday 15 December 2016 (32597)

Jim W. and I just got in for coverage now. We've talked with LLO. 

We took Stevens in (admittedly in a truck with 4 wheel drive) and it wasn't bad; roads are pretty clear the whole way and were being actively plowed.

corey.gray@LIGO.ORG - 09:17, Thursday 15 December 2016 (32598)

Yay!  Thank you!!  

Roads were not too bad (via Rt10/SR240/Twin Bridges).  Some compact snow, but just didn't speed through it and was fine.  Let's hunt some Gravitational Waves!  :)

H1 AOS (DetChar)
joshua.smith@LIGO.ORG - posted 17:13, Wednesday 14 December 2016 - last comment - 10:57, Monday 19 December 2016(32580)
More sounds from the LVEA (this time in O1)

Josh, Andy, David

After stumbling on the ringing phones in the LVEA in O2 (entry 32503) we sent this request, to find other times in h(t) that look like phone ringing glitches, to GravitySpy citizen scientists. Though it's dirty laundry airing this is a way to engage a network of many interested folks to find issues.  

The reply from user @EcceruElme pointed to two similar glitches in O1/ER10/O2.
One is in Livingston at 1132398529.14 (Nov 24th 11:08 UTC - link) and looks like an ER10 instance of engaging violin mode damping while in observation ready but before SDF checks were being enforced, so ok.
One is in Hanford at 1128269436.32 which is 2015-10-07 at 16:00 during a long nice science mode lock (summary page for that day). This sounds a little like a fax machine then some bangs and a human voice through a loudspeaker and some more bangs. In the hour around that time there are also some other loud bangs. We have no idea what it could be but it happened in otherwise unbroken excellent O1 data so perhaps folks on site know what it is and if it can be (or has been) turned off.

Attachments:

- Audio file of Input Optics Microphone with no filtering.
- Spectrogram of Input Optics Mic (it was also loud in BS Mic, others in LVEA but quiet in PSL room Mics) and Strain
- OmegaScan of Strain (from GravitySpy) 

Images attached to this report
Non-image files attached to this report
Comments related to this report
cheryl.vorvick@LIGO.ORG - 21:08, Wednesday 14 December 2016 (32586)

I listened to this in Quicktime with the bass at max and treble at min, and it sounds like a crane being actuated on/off multiple times, which I hear in the clicking.  I think the screaching is metal to metal contact as the crane moved.  I hear one voice.

Listening with trebble at max and bass at min gave the same results for me.

ryan.blair@LIGO.ORG - 09:49, Thursday 15 December 2016 (32599)
inputoptics-mic-2015-10-07.wav sounds to me like an accidental dial into the public address system in the OSB/LVEA with feedback coming from standing near one of the overhead speakers throughout the building.
david.shoemaker@LIGO.ORG - 13:46, Friday 16 December 2016 (32638)
Is it possible to dial into PA systems in the VEAs? Seems that should definitely be disabled during science runs. I can see that for safety it may need to be turned on for e.g., Tuesday maintenance, but it is such an easy way to corrupt the data with rich signals that it needs to be off bounds.

May I also ask that the card reader records at the time of the Event (audio event that is) be inspected, in order to determine if anyone entered the LVEA around that time? 
keita.kawabe@LIGO.ORG - 10:57, Monday 19 December 2016 (32737)

Card reader shows no activity in the LVEA between Oct /07/2015 00:00:00 and Oct/08/2015 00:00:00 Pacific (that should be Oct/07/2015 07:00:00 to Oct/08/2015 07:00:00 UTC).

The event time is around Oct/07/2015 16:09:43 UTC.

H1 CAL (CAL)
evan.goetz@LIGO.ORG - posted 19:09, Tuesday 13 December 2016 - last comment - 11:24, Friday 16 December 2016(32542)
Some investigations needed
Looking at a few tasks on the calibration to-do list, I ended up down the rabbit hole. Sadly, it's getting late and will have to return to this tomorrow.

Investigations:

1) Working on fixing the PCAL --> CAL-CS_DELTAL_EXTERNAL calibration (see LHO alog 31994). Kiwamu's original script computed a transfer function accounting for time delays caused by the DAQ and the CAL-CS whitening filter. However, this is already taken into account in the clock cycles delay in the CAL-CS model when adding the sensing and actuation paths. Since CAL-CS corrects for the phase delay caused by AA/AI filtering--analog and digital--using the delayed actuation path, then what one really wants is to correct CAL-CS for the magnitude changes of the AA/AI filtering and any CAL-CS whitening on this channel while also correcting the PCAL_RX_PD channel for the effect of AA and that we also have not applied a filter with two poles at 1 Hz (for the free-mass response):

DELTAL_EXT   W * [Derr/C_foton + A*Dctrl*delay]
---------- = ----------------------------------
PCAL_RX_PD         m * f^2 * AA_a * AA_d

 m     DELTAL_EXT [C_real/C_foton] / [W * abs(AA_a * AA_d * uncompensatedOMCpoles)]
--- = ------------------------------------------------------------------------------
 m                PCAL_RX_PD / [f^2 * AA_a * AA_d]

Note that the correction factors applied in the numerator of the final equation are really only to be applied to the sensing side. However, the corrections are only at high frequency (low-frequency corrections are simply unity), so the numerator term is dominated by the sensing function.

Thus the calibration to be applied is thus:

   [C_real/C_foton] * [f^2 * AA_a * AA_d]
----------------------------------------------
[W * abs(AA_a * AA_d * uncompensatedOMCpoles)]

Unfortunately, this results in a large deviation in phase at higher frequencies (~60 degrees at 1 kHz, see attached figure) while recent measurements using an incorrect calibration filter do not suffer from this large phase deviation. The phase deviation is due to application of the analog and digital AA on the Pcal. Why?

2) I constructed an O2 version of the front-end calibration time delay diagrams based on the model (see attached), but when I look at the GDS correction factors to be applied to the CAL-CS channels, I do not find matching delays. In addition, the values obtained to not mesh with the recent work done at LLO (see LLO alog 29899). This will have to be investigated further tomorrow also.

Images attached to this report
Non-image files attached to this report
Comments related to this report
shivaraj.kandhasamy@LIGO.ORG - 09:59, Thursday 15 December 2016 (32601)CAL

The AA (analog and digital) had to be taken into for DELTAL_EXT also, including their phase. And also we need a cycle advacne for DELTAL_EXT. Attached plot show the same comparison with the mentioned modifications and we see that the old correction factor was good to use. I have also attached the script used to make the plot. Most of these correction factors are calculated in computeSensing.m of DARM model code, so I just get these factors from there.

Images attached to this comment
Non-image files attached to this comment
evan.goetz@LIGO.ORG - 15:03, Thursday 15 December 2016 (32606)
Thanks to Shivaraj for pointing out the 7 clock cycles adjusted the actuation path to have consistent phase with the sensing path, but that a signal measured by back CAL-CS_DELTAL_EXTERNAL would have an apparent delay of 117.6 usec (see PDF attachment to original alog entry above) + 61 usec for the delay between OMC user model and CAL-CS user model. The apparent 117.6 usec on the sensing side is a combination of optical response, AA filtering, and uncompensated, super-Nyquist OMC DCPD poles.

The correct math is as follows:

DELTAL_EXT   W * [Derr/C_foton + A*Dctrl*delay]
---------- = ----------------------------------
PCAL_RX_PD         m * f^2 * AA_a * AA_d

 m     DELTAL_EXT * [C_foton/C_real] / [W * AA_a * AA_d * OMCpoles * OMCtoCALCSdelay * lightTimeDelay * unknownSensingDelay]
--- = -----------------------------------------------------------------------------------------------------------------------
 m                                       sign * PCAL_RX_PD / [f^2 * AA_a * AA_d]


So the calibration transfer function is:

                           [C_foton/C_real] * f^2
-------------------------------------------------------------------------------------------
[W * sign * uncompensatedOMCpoles * OMCtoCALCSdelay * lightTimeDelay * unknownSensingDelay]


A comparison of the new transfer function is attached below. Note that the magnitude is basically unchanged, but there are changes in phase at the ~5 degree level or less from 10 Hz to 1 kHz. The new transfer function is stored at: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Scripts/ControlRoomCalib/pcal2darm_calib.txt.

I also attach a comparison of DTT transfer functions using the old calibration versus the new calibration. The magnitude of the transfer function is basically unchanged. The phase is modestly affected. Unfortunately, since the transfer function wasn't perfect before and it remains imperfect (darn). I saved 2016-11-30_H1_PCAL2DARMTF_4to1200Hz_fasttemplate.xml with the new calibration transfer function.
Images attached to this comment
evan.goetz@LIGO.ORG - 11:24, Friday 16 December 2016 (32630)
The broad-band calibration has also been updated. The transfer function is also created by the same script,
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Scripts/ControlRoomCalib/H1_pcal2darm_correction.m

The broad band transfer function is stored at: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Scripts/ControlRoomCalib/caldeltal_calib.txt

I have updated the most recent DTT session with this changed calibration (see attached): /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Measurements/PCAL/2016-11-30_H1_PCAL2DARMTF_BB_5to1000Hz.xml

Note that the DTT session calibrates the DELTAL_EXTERNAL and PCAL_RX_PD channels separately. The PCAL_RX_PD channel is calibrated by zpk([],[1;1],1,"n"); therefore, the DELTAL_EXTERNAL needs to have all the other calibration applied to it:

                           [C_foton/C_real]
-------------------------------------------------------------------------------------------
[W * sign * uncompensatedOMCpoles * OMCtoCALCSdelay * lightTimeDelay * unknownSensingDelay]
Images attached to this comment
H1 CAL (CAL)
alexander.urban@LIGO.ORG - posted 11:57, Tuesday 13 December 2016 - last comment - 12:35, Thursday 15 December 2016(32517)
GDS calibration pipeline restarted at LHO with gstlal-calibration-1.1.2

I've restarted the primary and redundant h(t) pipelines at Hanford at GPS second 1165664237. This restart picks up a software update to gstlal-calibration-1.1.2-v1, which contains a couple of bug fixes:

(1) The h(t) data product should now be identical between the primary and redundant pipelines when time-dependent corrections are applied (i.e., the previously observed numerical roundoff error has been addressed);

(2) The pipeline will now run properly in offline mode, which had become a serious problem after the first bug fix referred to above.

The filters file has also been changed; see this aLOG: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=32389

Note, time-dependent corrections to h(t) (the kappa factors) are still being applied in low latency at Hanford, with the exception of changes to the coupled cavity pole frequency.

Comments related to this report
aaron.viets@LIGO.ORG - 12:35, Thursday 15 December 2016 (32603)
The most recent bug fix that prevents the pipeline from hanging does so by adding a 20 second latency to the low-pass-filter used in demodulating the time-dependent calibration factors. This was necessary so the the timestamps on this stream are aligned with the timestamps of the coherence uncertainty channels. Otherwise, the gate element that receives these misaligned streams will lock up, causing the pipeline to hang.

However, I have now realized that this introduces minor subtlety -- the coherence gating does not take this additional 20 seconds into account. This introduces the possibility that there could be undesirable jumps in the kappas in C01 frames produced by this version of the code that do not show up in C00 (Similar to what is discussed in https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=31911 , which has been addressed in a recent bug fix).

I have a different fix to this, for which I will request another release for next Tuesday. Instead of adding a latency to the low-pass filter, I have added queues before the gate, which allow it to run properly. (Note that we never encountered this problem online; the reason is because there are queues that have this effect when running online that were not previously in all the right places for the offline version.)
Displaying reports 51481-51500 of 83202.Go to page Start 2571 2572 2573 2574 2575 2576 2577 2578 2579 End