Displaying reports 62441-62460 of 86013.Go to page Start 3119 3120 3121 3122 3123 3124 3125 3126 3127 End
Reports until 16:05, Monday 14 December 2015
LHO General
thomas.shaffer@LIGO.ORG - posted 16:05, Monday 14 December 2015 (24209)
OPS Day Shift Summary

TITLE: 12/14 Day Shift: 16:00-00:00UTC (08:00-16:00 PDT), all times posted in UTC"

STATE Of H1: Observing at 75Mpc for 20.5hrs

SUPPORT: Patrick, Vern, Jenne

SHIFT SUMMARY: Quiet except for an EX ISI oscillation, the blends were changed and seemed to have made it better. The blends for EX only are now in the Quite_90s.

INCOMING OPERATOR: Corey

ACTIVITY LOG:

H1 SEI
hugh.radkins@LIGO.ORG - posted 14:25, Monday 14 December 2015 - last comment - 10:48, Tuesday 15 December 2015(24208)
Up dating ISI model

WP--5649, ECR E1500456, II 1167.  See aLog 23853 and SEI log 887 and 890.

In preparation for updating the ISI per above, I'm updating our local model and src areas:

hugh.radkins@opsws1:models 0$ svn st -u
?                    gnd_sts_library_NEW.mdl
        *    12022   isi2stagemaster.mdl
Status against revision:  12272
hugh.radkins@opsws1:models 0$ svn up isi2stagemaster.mdl
U    isi2stagemaster.mdl
Updated to revision 12272.
 

hugh.radkins@opsws1:src 0$ svn st -u
        *    11156   WD_SATCOUNT.c
?                    ISIWD_GPS_veryOLD.c
        *            BLENDMASTER_ST1.c
        *    10437   .
Status against revision:  12272
hugh.radkins@opsws1:src 0$ svn up
U    WD_SATCOUNT.c
A    BLENDMASTER_ST1.c
Updated to revision 12272.

hugh.radkins@opsws1:bscisi 0$ svn up
U    ISI_CUST_CHAMBER_ST1_BLEND_ALL.adl
Updated to revision 12272.
hugh.radkins@opsws1:bscisi 0$
 

I've successfully rebuilt all the ISI platforms.  Will wait until tomorrow for install & restart

Comments related to this report
hugh.radkins@LIGO.ORG - 10:48, Tuesday 15 December 2015 (24237)

FYI  The SATCOUNT.c update was a bug fix which applies to all ISI platforms.  This is why the HAMs were also rebuilt and restarted.  This fix will have the ISI saturations (seen n watchdog screen) clear immediately.  Added benefit for the BSC ISIs for not tripping those platforms from stale T240 saturations.  All good.

H1 SUS
jenne.driggers@LIGO.ORG - posted 14:21, Monday 14 December 2015 - last comment - 20:13, Monday 14 December 2015(24207)
SR3 cage servo beyond limit

The SR3 cage servo has gone beyond its limit, and is saturating the output of the SR3 M2 coils. 

Back in November (aLog 23131) I put a check into the SR3_CAGE_SERVO guardian to let the operator know when it's close to the limit, and that it needed to be offloaded to the M1 actuators.  However, I only put in a check for if the servo is getting close to the positive limit.  As of 12 Dec around 18:00 UTC, we've been railed at the negative limit.  Ooops. 

Right now, SR3 is about 13 urad from the usual value in pitch (currently the OSEMs read 935, rather than the 922 that is the cage servo's setpoint), but the ASC seems to be fine with it. 

At the next opportunity, we'll offload SR3's alignment, and fix the guardian code so that it checks for both the positive and negative limits.

In the attached figure, you can see that SR3 is no longer at its nominal pointing, and that the cage servo's setting is no longer within +/-15,000 counts (which corresponds to +/-130k counts at the DAC).

Images attached to this report
Comments related to this report
jenne.driggers@LIGO.ORG - 17:45, Monday 14 December 2015 (24212)

Trying to fix this broke the lock :(

Even though Corey and I typed a number (-16,000) into the SR3_M2_TEST_P_OFFSET (to get the cage servo closer to zero) that should have left the coil actuators railed, 2 of the coils seem to have flipped sign.  This broke the lock.  I'm still looking into why typing -16,000 didn't do what I expected.

jenne.driggers@LIGO.ORG - 20:13, Monday 14 December 2015 (24217)CDS, SUS

I have been looking into the lockloss that I caused earlier when Corey and I were offloading the SR3 cage servo, because I don't think that it should have caused a lockloss.

I think that I have found a mysterious sign flip in the DAC output, which I'm hoping that someone will have an idea about.  Somehow, the LR and UR DAC outputs switched sign a few days ago, even though the MASTER_OUTs did not flip sign.  See first attachment for a 3 day trend showing this.

When Corey typed -16,000 into the SR3_M2_TEST_OFFSET, the signs of the LR and UR DAC outputs flipped to correct themselves.  See second attachment for a 20 minute trend showing this.  The COILOUTFs are the same as the MASTEROUTs, and they stay whatever sign they started (LL and LR positive, UL and UR negative).  However, the DAC_OUTPUTs 6 and 7 (6=UR, 7=LR) flip sign.  This undoes the mysterious sign flip that happened a few days ago.

Why is the DAC output flipping sign, when the digital signals going to them are not?!?!

Images attached to this comment
H1 SEI
patrick.thomas@LIGO.ORG - posted 12:04, Monday 14 December 2015 (24205)
end X ISI blends switched
Jim W., Evan H., Patrick T.

The end X ISI was ringing up. I took the IFO out of observing while Jim W. switched the blends. Both DOFs were on 45mHz and were switched to Quite_90. I accepted the SDF differences and returned the IFO to observing.

Screenshots of the accepted SDF differences and current blends are attached.

Out of observing from 19:34:07 to 19:54:02 UTC.
Images attached to this report
H1 CAL (CAL)
joseph.betzwieser@LIGO.ORG - posted 11:08, Monday 14 December 2015 - last comment - 14:34, Wednesday 30 December 2015(24204)
H1 calibration measurements and script clean up
We've been cleaning up the scripts used to present the various calibration measurements against the model and each other.

A longer description of script locations and cleanup is LLO alog 23558.

This is basically the same as  LHO alog 21280, except comparing against the O1 model (H1DARMparams_1124827626.m) and trying to use more generic scripts for both sites.

The attached pdfs are results, and can also be found in the aligo calibration svn under:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O1/H1/Results/

The first 3 all measurement types (Free swinging Michelson, ALS DIFF, PCAL) from 3 different days plotted against each other and the O1 model.

The second set of 3 are just the PCAL measurements against the model.
Non-image files attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 14:34, Wednesday 30 December 2015 (24570)
The all-method comparison plots attached here have been renamed to 
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O1/H1/Results/
2015-12-11_H1SUSETMY_ActuationCoeffComp_EYL1_AllMethods.pdf
2015-12-11_H1SUSETMY_ActuationCoeffComp_EYL2_AllMethods.pdf
2015-12-11_H1SUSETMY_ActuationCoeffComp_EYL3_AllMethods.pdf
in order to distinguish them from the L1 results, and committed to the repo.

The PCAL-only results have been moved into the PCAL subdirectory and similarly renamed,
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O1/H1/Results/PCAL/
2015-12-11_H1SUSETMY_ActuationCoeffComp_PCAL_EYL1_Residuals.pdf
2015-12-11_H1SUSETMY_ActuationCoeffComp_PCAL_EYL2_Residuals.pdf
2015-12-11_H1SUSETMY_ActuationCoeffComp_PCAL_EYL3_Residuals.pdf

H1 PSL (PSL)
peter.king@LIGO.ORG - posted 09:38, Monday 14 December 2015 (24203)
Front End laser pump diodes
Attached is a plot summarising the behaviour of the front end laser pump diodes.
The oscillation in the output power has been observed before and I'm not sure
what it is caused by.  I had thought that it might be due to an oscillation in
the PID loop controlling the pump diode temperature, however it's not visible
in the TEC signals (D[1-4]TEC).

We still have a reasonable amount of headroom for the pump diodes.  At the
moment the diode current is ~51.5 A.  The maximum is 65 A.
Images attached to this report
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 09:24, Monday 14 December 2015 (24202)
CDS model Wednesday-Sunday 9th-13th December 2015
O1 days 83-87. No restarts reported for this time period.

LHO General
thomas.shaffer@LIGO.ORG - posted 08:45, Monday 14 December 2015 (24201)
Morning Meeting Minutes

Planning for Tuesday Maintenance:

H1 General
jeffrey.bartlett@LIGO.ORG - posted 08:08, Monday 14 December 2015 (24200)
Ops Owl Shift Summary
Activity Log: All Times in UTC (PT)

08:00 (00:00) Take over from Corey
08:46 (00:46) Reset L4C WD saturations on HAM3, ITMX, and the BS
16:00 (08:00) Turn over to TJ


End of Shift Summary:

Title: 12/14/2015, Owl Shift 08:00 – 16:00 (00:00 – 08:00) All times in UTC (PT)

Support:  
 
Incoming Operator: TJ

Shift Detail Summary: Locked in Observing mode for entire shift. Power at 21.8w, range 79Mpc. Wind is light breeze (4-7mph), seismic and microseism are improving. 

There is an oscillation showing up in the 20 minute ASAIR_B_RF90_I_NORM, and SUS-PRM_MC3_LOCK signals. There are also oscillations showing up in the Pitch and Yaw ASC Control strip tools.   
LHO General
thomas.shaffer@LIGO.ORG - posted 08:06, Monday 14 December 2015 (24199)
Ops Day Transition
H1 General
jeffrey.bartlett@LIGO.ORG - posted 04:00, Monday 14 December 2015 (24198)
Ops Owl Mid-Shift Summary
  In general a good first half of the shift. 
   
  In Observing mode for past 8 hours, with a couple of exceptions as noted during the Evening shift. The IFO appears to be functioning normally. Environmental conditions are good or improving except microseism, which remains elevated and shows signs of a decline.       
H1 General
jeffrey.bartlett@LIGO.ORG - posted 02:40, Monday 14 December 2015 - last comment - 02:48, Monday 14 December 2015(24196)
Reset L4C WD
   08:46 (00:46) Reset L4C WD saturations on HAM3, ITMX, and the BS. 
Comments related to this report
corey.gray@LIGO.ORG - 02:48, Monday 14 December 2015 (24197)

Are you able to do this while in Observation Mode?

H1 General
jeffrey.bartlett@LIGO.ORG - posted 00:40, Monday 14 December 2015 (24195)
Ops Owl Shift Transition
Title:  12/14/2015, Owl Shift 08:00 – 16:00 (00:00 – 08:00) All times in UTC (PT)
	
State of H1: 08:00 (00:00), The IFO is in Observation mode. Power at 21.8W, range 78Mpc    

Outgoing Operator: Corey

Quick Summary:  IFO has been in observation mode for the past 5 hours, except as noted by the Evening shift. Wind is a light breeze (4 - 7mph). Seismic and microseism are still a bit elevated, but improving.  All appears to be normal.
LHO General
corey.gray@LIGO.ORG - posted 23:56, Sunday 13 December 2015 (24184)
EVE Ops Summary

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

STATE of H1:   4+ Hrs of locking (Almost 3hrs in Observing) at around 80Mpc.

Incoming Operator:  Jeff B.

Support:  Sheila On Phone at beginning of shift

Quick Summary:

(Finally, I lock H1!  Seems like I haven't done so since early October!!)  :)  One thing about these adverse weather conditions:  It has been nice to have one on one time working with the interferometer and with commissioners though.)
 
Posted most of the action from the shift earlier.  Current lock is 4+hrs with a range around 80Mpc.  useism is still high...thought it was dropping, but if anything looks like it's inched up!  winds are super calm though.  
   
Violin Modes are flashing RED on the nuc0 violin mode medms FOM.  Perhaps this is from Evan's alog (24063).  I did not do anything about this, other than note it here.

Shift Log:

  • 3:31 NLN & COMMISSIONING
  • 3:39 Robert heading out for upconversion injection measurements (by shaking each chamber).  This should be ~1hr.
  • 4:49 ETMy SUS Diag Reset
  • 4:50 Robert out of LVEA.  He did a Personal Sweep:  Turned OFF wifi, lights, and all of his equipment.  (Last major LVEA Sweep was done by Jeff B on 12/8.)
  • 4:52 Back to OBSERVING!
  • 7:55:25 Plane flying directly overhead/X1 beam tube (heard in Control Room)
H1 AOS
robert.schofield@LIGO.ORG - posted 21:56, Sunday 13 December 2015 (24194)
Up-conversion from low-f shaking of the BS BSC blue cross beams

We shook the PSL table and all chambers at the corner station except ITMY individually. By far the greatest up-conversion was at the BS. The figure shows that even a 20% increase in 1-80 Hz GS13 BLRMS produces bumps at higher frequencies. The up-conversion from injected peaks is not broadband like magnet domain changing noise, and is not a harmonic series like from scattering or saturation, but, instead produces peaks that look like intermodulation products.

Robert, Jordan

Non-image files attached to this report
LHO General
corey.gray@LIGO.ORG - posted 20:57, Sunday 13 December 2015 (24191)
Mid Shift Summary
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 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.

Displaying reports 62441-62460 of 86013.Go to page Start 3119 3120 3121 3122 3123 3124 3125 3126 3127 End