Displaying reports 61521-61540 of 84967.Go to page Start 3073 3074 3075 3076 3077 3078 3079 3080 3081 End
Reports until 09:45, Wednesday 09 December 2015
H1 General (DetChar, PSL)
edmond.merilh@LIGO.ORG - posted 09:45, Wednesday 09 December 2015 (24081)
PSL Status and Past 10 Day Trends
Laser Status:
SysStat is good
Front End power is 30.97W (should be around 30 W)
Frontend Watch is GREEN
HPO Watch is RED
 
PMC:
It has been locked 14.0 days, 23.0 hr 44.0 minutes (should be days/weeks)
Reflected power is 1.843Watts and PowerSum = 24.85Watts.
 
FSS:
It has been locked for 0.0 days 0.0 h and 6.0 min (should be days/weeks)
TPD[V] = 1.341V (min 0.9V)
 
ISS:
The diffracted power is around 7.185% (should be 5-9%)
Last saturation event was 0.0 days 0.0 hours and 5.0 minutes ago (should be days/weeks)
Laser Status:
SysStat is good
Front End power is 30.97W (should be around 30 W)
Frontend Watch is GREEN
HPO Watch is RED
 
PMC:
It has been locked 14.0 days, 23.0 hr 44.0 minutes (should be days/weeks)
Reflected power is 1.843Watts and PowerSum = 24.85Watts.
 
FSS:
It has been locked for 0.0 days 0.0 h and 6.0 min (should be days/weeks)
TPD[V] = 1.341V (min 0.9V)
 
ISS:
The diffracted power is around 7.185% (should be 5-9%)
Last saturation event was 0.0 days 0.0 hours and 5.0 minutes ago (should be days/weeks)
Laser Status:
SysStat is good
Front End power is 30.97W (should be around 30 W)
Frontend Watch is GREEN
HPO Watch is RED
 
PMC:
It has been locked 14.0 days, 23.0 hr 44.0 minutes (should be days/weeks)
Reflected power is 1.843Watts and PowerSum = 24.85Watts.
 
FSS:
It has been locked for 0.0 days 0.0 h and 6.0 min (should be days/weeks)
TPD[V] = 1.341V (min 0.9V)
 
ISS:
The diffracted power is around 7.185% (should be 5-9%)
Last saturation event was 0.0 days 0.0 hours and 5.0 minutes ago (should be days/weeks)
 
Images attached to this report
H1 General
edmond.merilh@LIGO.ORG - posted 08:46, Wednesday 09 December 2015 - last comment - 13:31, Wednesday 09 December 2015(24078)
Taking advantage of Environmental Down time

Mike Landry has given the final "OK" to proceed with maintenance tasks this morning due to the IFO being down due to high winds. Livingston has been contacted regarding our plan. They are currently back "UP".

Comments related to this report
edmond.merilh@LIGO.ORG - 13:31, Wednesday 09 December 2015 (24085)

This period ended at ≈ 19:00UTC

H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 08:23, Wednesday 09 December 2015 (24077)
CDS model and DAQ restart report, Monday, Tuesday 7th,8th December 2015

O1 days 81,82

model restarts logged for Tue 08/Dec/2015
2015_12_08 11:51 h1broadcast0

Maintenance day, DMT channel added to broadcaster

model restarts logged for Mon 07/Dec/2015

No restarts reported

H1 General
edmond.merilh@LIGO.ORG - posted 08:08, Wednesday 09 December 2015 (24076)
Shift Summary -Day Transition

TITLE: Dec 9 DAY Shift 08:00-1t6:00UTC (00:00-08:00 PDT), all times posted in UTC

STATE Of H1: Environment

OUTGOING OPERATOR: Patrick

QUICK SUMMARY: Doesn’t look like a good day for locking unless the wind dies back significantly.

LHO General
patrick.thomas@LIGO.ORG - posted 08:04, Wednesday 09 December 2015 (24072)
Ops Owl End Shift Summary
TITLE: 12/09 [OWL Shift]: 08:00-16:00 UTC (00:00-08:00 PDT), all times posted in UTC

STATE Of H1: Unlocked
SHIFT SUMMARY: Lock loss likely from earthquake. High winds and microseism have hindered relocking ALS. Tried different combinations of ISI blends to no avail. The Y arm has been the least stable.
There is a timing error on H1SUSETMX.
INCOMING OPERATOR: Ed
ACTIVITY LOG:

10:41 UTC Lock loss. Arms not staying locked on green. Put ISC_LOCK guardian to DOWN to wait out earthquake. Adjusted REF_SIGNAL to increase ISS diffracted power.
13:38 UTC Started attempting to relock
15:33 UTC Bubba driving down arms to assess tumbleweed buildup
H1 PSL (PSL)
peter.king@LIGO.ORG - posted 07:30, Wednesday 09 December 2015 - last comment - 09:24, Wednesday 09 December 2015(24073)
reference cavity transmission
In checking on the reference cavity transmission this morning, I noted that it took a
dive over the last day in particular, and over the last three days in general.  Also
attached is a plot of the IMC locked status.

Looking over the trend data, it appears to me that the reference cavity transmission
suffers when there are long periods of time when the IMC is trying to acquire lock.
My hypothesis is that the IMC trying to acquire lock means that the VCO frequency of
the double-passed AOM swings from one extreme to the other.  This might result in
heating of the AOM, which in turn changes the alignment of the AOM with respect to
the input beam.  We don't observe an alignment change on the nearby EOM because the
EOM is too close for a small alignment change to be noticed.  Of course we observe
the alignment change on the iris located in front of the reference cavity, since that's
some distance away from the AOM (~2 m).

Also attached is a plot of the reference cavity transmission and VCO frequency.

One might ask, why didn't you just fix it by re-aligning the AOM previously.  And the
convenient answer is that the AOM alignment is quite sensitive.  This doesn't necessarily
fix the problem if overheating of the AOM is the culprit.
Images attached to this report
Comments related to this report
peter.king@LIGO.ORG - 09:24, Wednesday 09 December 2015 (24080)
Predominantly changes to pitch with a slight change in yaw.
Images attached to this comment
LHO General
patrick.thomas@LIGO.ORG - posted 07:28, Wednesday 09 December 2015 - last comment - 13:16, Wednesday 09 December 2015(24074)
SNEWS alert test in GraceDB
Mike L. called and notified me that there was a SNEWS test alert entered into GraceDB (E206974, see attached screenshot). I did not get a verbal alarm.
Images attached to this report
Comments related to this report
thomas.shaffer@LIGO.ORG - 13:16, Wednesday 09 December 2015 (24084)

There was no alarm for this in the control room because the script that queries GraceDB (ext_alert.py) will only look back 36000 seconds and the delay for this alarm was 73681.000000sec.

We have been using the default 'lookback' time, but can set to be any value we choose from the command line at the start of ext_alert.py. This delay was a special case, but it might be worth looking back a bit more than 10 hours...

Lookback time code is below if anyone is curious.



actions['run'].add_argument('-l', '--lookback-time', type=float, default=36000,
                            dest='lookback',
                            help='how far back in time to query, '
                                 'default: %(default)s')

...(later, in the loop)

            # query gracedb
            now = gps_time_now(ifo=args.ifo)
            start = now - args.lookback
            client, events = list(
                 query_gracedb(start, now, ifo=args.ifo, connection=client,
                               far=args.far, test=args.test))

LHO General
patrick.thomas@LIGO.ORG - posted 04:02, Wednesday 09 December 2015 (24071)
Ops Owl Mid Shift Summary
Put ISC_LOCK guardian to DOWN and waiting for earthquake to subside. Wind speeds are peaking around 40 mph.
Images attached to this report
H1 General
patrick.thomas@LIGO.ORG - posted 03:05, Wednesday 09 December 2015 (24070)
Lock loss
Range was degrading with increasing winds.

There was also an earthquake and LLO went down at the same time:

6.9
106km SE of Amahai, Indonesia
2015-12-09 10:21:50 UTC 33.9 km deep
Images attached to this report
LHO General
patrick.thomas@LIGO.ORG - posted 23:55, Tuesday 08 December 2015 (24069)
Ops Owl Beginning Shift Summary
TITLE: 12/09 [OWL Shift]: 08:00-16:00 UTC (00:00-08:00 PDT), all times posted in UTC

STATE Of H1: Observing @ ~ 79 MPc
OUTGOING OPERATOR: Cheryl
QUICK SUMMARY: 
From the cameras:
The lights are off in the LVEA.
The lights are off in the PSL enclosure.
The lights are off at end X.
The lights are off at end Y.
I can not tell if the lights are on or off at mid X and mid Y.

The 0.03 - 0.1 Hz (earthquake) seismic band is between ~ 0.01 and 0.1 um/s.
The 0.1 - 0.3 Hz (microseism) seismic band is trending slightly up and is now between ~ 0.2 and 0.9 um/s.

The winds are between ~ 0 and 15 mph.

See screenshot for ISI blends.

From pinging:
CDS WAP is off at the LVEA.
CDS WAP is off at end X.
CDS WAP is off at end Y.
CDS WAP is on at mid X.
CDS WAP is on at mid Y.
Images attached to this report
H1 General (DetChar, PEM, SEI, SUS, VE)
cheryl.vorvick@LIGO.ORG - posted 23:50, Tuesday 08 December 2015 (24068)
Ops Eve Summary: H1 now in Observe

Ops Eve Summary:  00:01-08:00UTC (16:00-23:59PT)

State of H1: locked in Observe for 2+ hours

Help: Jenne, Sheila, Evan H

Shift Summary:

Timeline:

 

H1 DetChar (DetChar, PEM, VE)
cheryl.vorvick@LIGO.ORG - posted 23:12, Tuesday 08 December 2015 (24066)
Kyle driving down Y arm - GRB alert - travel times and GRB times recorded here:

Kyle was here and needed to drive down the Y arm:

Timeline including GRB:

  1. 6:20UTC - Kyle at the CS
  2. 6:23UTC - GRB alert
  3. 6:26UTC - Kyle arrives
  4. 6:53UTC - Kyle called to say he was driving back
  5. 7:03UTC - Kyle and his car were visible on the outside camera in the parking lot
LHO VE
kyle.ryan@LIGO.ORG - posted 23:10, Tuesday 08 December 2015 (24065)
~2215 - 2250 hrs.local -> Kyle on site to refuel generator running at Y2-8


			
			
H1 SEI (ISC, Lockloss, OpsInfo, SEI, SUS)
cheryl.vorvick@LIGO.ORG - posted 22:45, Tuesday 08 December 2015 - last comment - 09:17, Wednesday 09 December 2015(24064)
ETMY ISI blend filters changed - big improvement in motion in Y and RX

Evan Hall suggested changing ETMY ISI blend filters after a couple lock losses between DRMI and ENGAGE_ASC.

The change from all Quiet_90s to Quiet_90 in X direction, and 45mHz in Y direction was easilly seen on ST1_ISO_RX and ST2_ISO_Y, and the ASC control signal in pitch being sent to the optic, ASC-ETMY_PIT_OUTPUT.

Plot attached shows those channels before and after the blend filter change, and ETMX ASC control signal, to compare.

Current blend filter config. medm is also attached.

Images attached to this report
Comments related to this report
richard.mittleman@LIGO.ORG - 07:48, Wednesday 09 December 2015 (24075)

Why are the y blends set different from the X blends?

evan.hall@LIGO.ORG - 09:17, Wednesday 09 December 2015 (24079)

Over the past month or so, having the 45 mHz blends on EX causes the ISI to ring up in full lock (for example: alog 23674 and comments).

H1 ISC (DetChar, ISC, OpsInfo)
evan.hall@LIGO.ORG - posted 20:14, Tuesday 08 December 2015 - last comment - 21:49, Sunday 13 December 2015(24063)
Violin mode damping turned off

I have edited the ISC_LOCK guardian so that it now turns violin mode damping off before the interferometer reaches nominal low noise. This will hopefully allow us to collect ringdown data on the violin mode fundamentals.

Violin mode damping is still turned on as usual in BOUNCE_VIOLIN_MODE_DAMPING, but it now is turned off in the COIL_DRIVERS state. Thus the modes will still receive a few minutes of damping before DARM is switched to dc readout.

If this behavior needs to be reverted, there is a flag in the main() function of COIL_DRIVERS called self.turnOffViolinDamping which can be set to False.

Violin mode damping in full lock will be re-enabled once sufficient data have been collected.

Comments related to this report
corey.gray@LIGO.ORG - 21:42, Sunday 13 December 2015 (24192)

Are there any observable results from this?  For example, does this mean we will now see these on the running power spectrum on nuc3?  And is this the reason we now have the red boxes on the violin mode medm on nuc0?  I hadn't noticed the latter before, so I was wondering why these were flashing red.

evan.hall@LIGO.ORG - 21:49, Sunday 13 December 2015 (24193)

Since turning the damping off, the violin mode fundamentals seem to appear on the DARM FOM at the level of 10−16 m/Hz1/2 or so. Before turning the damping off, they would eventually damp down below 10−18 m/Hz1/2 after a few hours.

I'm guessing this is why the violin mode monitors are red, but I don't know what Nutsinee set the monitor thresholds to.

Also, since writing the above alog I changed the Guardian code for turning off the damping. It is no longer executed inside an if statement; it's just executed directly in the main() function of COIL_DRIVERS.

H1 DetChar (ISC, PEM)
jordan.palamos@LIGO.ORG - posted 19:36, Tuesday 08 December 2015 - last comment - 12:01, Thursday 10 December 2015(24062)
Evidence that mystery ~650Hz noise caused by COMM VCO

The mystery ~650Hz noise reported here and here also shows up in the PEM rf antenna (in both 9MHz and 45MHz located in CER and LVEA). Further investigation revealed that this peak shows up in the PEM antenna during lock aquisition at the start of the DC Readout Transition step (if it appears at all; it's not present in every lock--more on this later). At the start of this step the ALS COMM VCO is parked at some value.

To determine whether this VCO could be responsible for the ~650Hz noise, the frequency readback of the VCO was compared to the frequency of the mystery peak in the PEM antenna. Attached (figure 1) is a plot of H1:ALS-C-COMM_VCO_FREQUENCY timeseries on top and spectrogram of the PEM 45MHz LVEA antenna on the bottom. The frequency of the peak seems to track with the VCO frequency if you take into account the fact that the VCO frequency readback is digitized into steps of 8Hz (does anyone know why / can we fix this?).

Also, there appears to be 2 different values where the VCO can be parked. Figure 2 has similar plots to figure 1, over a 28hr stretch which contained multiple locks where the peak was sometimes present. In locks where the peak was present, the VCO was set to ~78.7873MHz. For locks where the peak is not there the VCO was set to ~78.7944MHz. These values correspond with two different values of H1:ALS-C_COMM_VCO_TUNEOFS : ~-1.39 and ~1.25, respectively.

To test this, we tried moving the COMM VCO TUNE OFS slider with the IFO locked (before continuing to NLN / Observing). While initially it looked like the peak in the PEM rf channel moved as the slider was moved, the lock broke before we could conclusively tell. The lockloss occurred right as Sheila was moving the slider. We don't know why this should cause a lockloss, so this is a subject for further investigations (it was windy and ground motion-y at the time so it could have been a coincidence).

Also included (figure 3) is a plot of the VCO frequency (again, 8Hz digitization) and the CER Rack temperature. More data is needed, but it looks like the freqency trends down after the temperature rises.

Finally, there is still the question as to why this is showing up in the 9MHz and 45MHz channels (and, ultimately, DARM). As a first check, I compared 9.100230 MHz and harmonics to 78.7873 MHz and harmonics to see if a beat would show up within 600 Hz. Out to 10 harmonics of the VCO frequency the closest they came to each other was 200 kHz--still a mystery.

 

Jordan, Robert, Sheila

Images attached to this report
Comments related to this report
keita.kawabe@LIGO.ORG - 23:13, Tuesday 08 December 2015 (24067)

8Hz is the single precision rounding, so somewhere somebody is casting the number to single. Bekhof code?

VCO frequency is about 80MHz, and 8e7=(1+fractional)*2^26 (fractional is about 0.1921, but that's not important).

Single precision number uses 23 bits for fractional. For any number in [2^26, 2^27) range, the least significant bit is 2^-23 * 2^26 = 8.

daniel.sigg@LIGO.ORG - 08:57, Thursday 10 December 2015 (24109)

EPICS values are fine, so this is a problem of DAQ/NDS/DV.

andrew.lundgren@LIGO.ORG - 12:01, Thursday 10 December 2015 (24110)CDS, DAQ, DetChar
Channels are double-precision in the front end, but stored as single-precision in the frames. Maybe Jordan was getting this data from the frames/NDS2, rather than live, so that's why there's this quantization error?
Displaying reports 61521-61540 of 84967.Go to page Start 3073 3074 3075 3076 3077 3078 3079 3080 3081 End