Displaying reports 55921-55940 of 78094.Go to page Start 2793 2794 2795 2796 2797 2798 2799 2800 2801 End
Reports until 03:35, Friday 23 October 2015
H1 General (Lockloss)
nutsinee.kijbunchoo@LIGO.ORG - posted 03:35, Friday 23 October 2015 (22768)
Lockloss 09:27:16 UTC

Corey, Nutsinee

Few minutes before the lockloess we noticed DHARD, IMC-F_OUT16, and ETMY DRIVEALIGN was running away on the FOM. No earthquake report from USGS within half an hour before/after the lockloss. No seismic activity in the earthquake band. I've attached some lockloss plots below. All the pretty much ASC signal were running away exacpt DSOFT and CSOFT.  WITNESS channels show BS, ETMX, ETMY, PRM, and SR2 running away. I've (temporarily) added IMC-F, ETMX and ETMY DRIVEALIGN to the plot.

Images attached to this report
H1 PSL
corey.gray@LIGO.ORG - posted 01:56, Friday 23 October 2015 (22767)
PSL Crystal Chiller Topped Off

Although it's technically Fri morning, I did check on the PSL chiller since its on the Thursday section of the Operator Check Sheet.  Tonight I topped it off with 100mL of water (it was last topped off yesterday with 150mL).

LHO General
corey.gray@LIGO.ORG - posted 00:43, Friday 23 October 2015 (22765)
Transition to OWL Shift Update

TITLE:  10/23 OWL Shift:  07:00-15:00UTC (00:00-08:00PDT), all times posted in UTC     

STATE of H1:  Observation Mode at 77Mpc

Outgoing Operator:  TJ

Support:  On Call-->Kiwamu

Quick Summary:  TJ walked me through the the special state H1 is in (running 45mHz blends & manual shuffling in the ENGAGE ASC PART3 step); this hub bub is all related to the elevated useism (it's currently around 0.03um/s).  TJ/Sheila felt the Blends were possibly having issues with the Soft Loop FM1 gains, so they are kept ON for this lock (FM1, -20dB gain is ENABLED).

We'll see how we do during the night as to whether we should run with these filters ON or OFF

LHO General
thomas.shaffer@LIGO.ORG - posted 00:20, Friday 23 October 2015 (22763)
Ops Eve Shift Summery
LHO General (Lockloss)
thomas.shaffer@LIGO.ORG - posted 23:12, Thursday 22 October 2015 - last comment - 23:24, Thursday 22 October 2015(22761)
Ops Update: Lockloss

H1:LSC-POP_A_LF_OUTPUT had an oscillation grow.

Useism still high (peaks at 0.5um/s)

Possible eathquake that was trending down that may not have helped (4.5 in Argentina says USGS).

Winds < 10mph

 

I will post Lockloss plots after I get this up again.

Comments related to this report
thomas.shaffer@LIGO.ORG - 23:24, Thursday 22 October 2015 (22762)

Possibly PRC1 running away. The controls Striptool showed DHARD Y looking similar to PRC1 as well

Images attached to this comment
LHO General (OpsInfo)
thomas.shaffer@LIGO.ORG - posted 22:06, Thursday 22 October 2015 (22759)
Ops Update: Observing

After about 9 hours of being down, we are now in Observing. BUT we are not is our normal configuration setting. Here is what worked/changed:

The current configuration settings that are different than our normal are: SOFT loops in low gain and BSC blends at 45mHz. Future operators may need to change these back for future locks, depending on conditions. (OpsInfo tagged)

 


 

More on the blend switching

 

The 90mHz blends seemed to not do well with the ALS during the high useism. Looking at the ALS X/Y power on Striptool, there is visible movement in the power while in the 90's, but not while in the 45Hz. After the the Engage ASC steps, it seemed as though the 45's would become unstable. Sheila thought that the 90's may be better after we have transitioned off of ALS, so we thought to try to switch blends after getting to DC_READOUT.

When we got to DC_READOUT I first changed the ETMX X blend from 45 -> 90. This worked with some disturbance seen in AS90. I moved on, with Jim W giving me some advice, and changed ETMX Y to 90. This also didn't drop us out of lock, but the AS90 trace wasn't getting any better. Next ETMY Y -> 90, same as the last two. And finally what did us in was ETMY X -> 90. Not sure if it just couldn't hold the instability anymore or if that particular dof just didnt agree with the change.

Since the ends were in 90 and the CS was in 45, I figured let's try it like that. ALS power looked slightly better than with 45 all around, but much more jagged and not as consistent of an oscillation as with all 45's. This configuration couldn't make past the first couple of steps, similar to all 90's.

Switched back to 45's and stayed here. When we got to DC_READOUT the next time all seemed well and we moved on to NOMINAL_LOW_NOISE.

H1 ISC (DetChar, OpsInfo, SEI)
sheila.dwyer@LIGO.ORG - posted 21:49, Thursday 22 October 2015 - last comment - 22:16, Thursday 22 October 2015(22757)
high microseism configuration (locking today)

TJ, Jeff K, Jim W, Sheila

We are on 45 mHz blends today, with microseism and wind that TJ will post. The first attached screenshot shows that today at least the optical levers show more motion when we are on 90 mHz blends. 

We are also running with low gain in the SOFT loops today.  We struggled with locklosses when turning up the gain in these loops (similar story in alog 22447).  This seems to be related to the 45mHz blends, because the gain peaking with these blends is unfortunately near something a little unstable in these loops with their nominal gains.  So it may be that we are best off to use low gains when we are on 45 mHz blends (FM1 off for all soft loops)  screen shot is attached.  Operators can probably let these come on in ENGAGE_ASC_PART3 and then manualy turn them off.  If this is not woking you can call me, we can add a check on the blend configuration in the guardian.  With low gain in these loops we do not have the large fluctuations in power build ups we had when we locked with 45 mHz blends in the past. The attached screenshot shows that when we used the 45 mHz blends in the past (22477), there were rather large fluctuations in POP LF (500 counts peak to peak)  Tonight with low gain in the SOFT loop the fluctuations are more like 100 counts peak to peak.  

For a good part of the afternoon we were struggling to lock because the recylcing gain was too low when the PRC2 loop came on.  We already had a check on recycling gain in the guardian, but the threshold was set too low, 31.5 (or 1050 in TR_X and TR_Y).  I increased the threshold to 34.5 (or 1150 in TR_X and TR_Y).  This means that the operators are now more likely to get an error message in ENGAGE_ASC_PART1 that says "Low recycling gain! Align by hand or redo Intial alingment"  If this happens people can try to align things by hand, (adjusting PR2 would be a place to start, maybe ITMs).  If we loose lock it is probably best to just redo inital alingment.  

We were also loosing lock when the SRC loops were re-engaged after being turned off for the CARM offset reduction. 22554 We edited the guardian to leave them on all the time, because I don't think that was really the problem with the locklosses durring CARM offset reduction. The good news is that we didn't have any trouble with these locklosses today, despite high ground motion. 

Images attached to this report
Comments related to this report
thomas.shaffer@LIGO.ORG - 22:16, Thursday 22 October 2015 (22760)

Attaching screenshots of: BLRMS for useism, SDF for blends on one BSC, SDF for the ASC SOFT, wind Striptool, and range.

Images attached to this comment
H1 INJ (CAL, INJ)
christopher.biwer@LIGO.ORG - posted 21:19, Thursday 22 October 2015 - last comment - 21:32, Thursday 22 October 2015(22756)
attempt to turn CW injections failed
I attempted to turn back on the CW injections since they were turned off earlier this week from the power outage.

Upon restarting psinject through the monit web inteface it said it the process was running. However the CAL-INJ_HARDWARE_OUT_DQ and CAL-INJ_CW_OUT_DQ time series were still zero.

I turned off the psinject monit instance and returned the hardware injections to the state they were in.
Comments related to this report
christopher.biwer@LIGO.ORG - 21:32, Thursday 22 October 2015 (22758)DetChar, INJ
I've attached a time series of CAL-INJ_CW_OUT_DQ that encompasses the time I had turned the psinject monit instance back on. It shows it is constantly zero.
Images attached to this comment
LHO General
thomas.shaffer@LIGO.ORG - posted 20:24, Thursday 22 October 2015 (22755)
Ops Eve Mid Shift Report

Seems to be the microseism keeping us down. The DMT monitor is showing levels reaching 0.5um/s. Sheila, Jeff K, Jim W, and I have been trying some different blend combinations and trying to switch from the 45mHz to the 90mHz at DC_READOUT, but just can't seem to make it past that point.  Sheila still has some ideas up her sleeve, so I will update more along the way.

H1 CAL (CAL)
sudarshan.karki@LIGO.ORG - posted 18:02, Thursday 22 October 2015 (22753)
Averaged time varying calibration parameters

In order to apply the calibration parameters kappas to h(t), we need to low pass it so that the noise (high frequency variation) picked up from the detector is smoothed out and only the low frequency variation, which we are confident is an actual change in the response of IFO, is applied to the data.

The value of kappas (data) obtained from the GDS pipeline is calculated by doing a 10s FFT and stored at 16 Hz to the frame. In order to determine an appropriate low pass filter, I averaged the 16 Hz data at 64s, 128s and 256s. 

The attachment below contains 3 pages of plots for each IFO. I took a day worth of data where there were several locks during the day. The plot on page 1 and 2 are plots for kappa_C and kappa_tst respectively. Each page contains four plots of which the first one is the actual 16 Hz data  with 64s, 128s and 256s averaged data overlayed on top of it. The rest three plot are individual averaged plots.

The plot on the last page is standard deviation of the data after applying the averaging plotted along with the estimate standard deviation as if the variation improved as square root of N. The two agree very closely. This just says that data is normally distributed (could be noise but not necessarily) and variation improves as a square root of average time.

Non-image files attached to this report
H1 General
travis.sadecki@LIGO.ORG - posted 16:30, Thursday 22 October 2015 (22752)
OPS Day shift summary

Title: 10/22 Day Shift 15:00-23:00 UTC (8:00-16:00 PST).  All times in UTC.

State of H1: Locking

Shift Summary:  After losing lock early in my shift, I have been struggling to get locked.  After doing initial alignment 1.5 times, we have been getting to DRMI 1f consistently, and made it as far as ENGAGE_ASC_PART3.  Microseism is high.

Incoming operator: TJ

Activity log:

18:55 Adjusted ISS diffracted power from ~11% to ~8% after Guardian complained

20:48 Switched BSC ISIs to 45mHz blends due to high microseism

21:26 GRB alert

21:50 Betsy and Mitchell to optics lab

22:18 Betsy and Mitchell done

LHO General
thomas.shaffer@LIGO.ORG - posted 16:26, Thursday 22 October 2015 (22751)
Ops Eve Shift Transition
H1 CAL (CAL)
joseph.betzwieser@LIGO.ORG - posted 14:37, Thursday 22 October 2015 - last comment - 04:02, Friday 23 October 2015(22748)
Comparison on of C01 recalibrated strain to C00 (online) strain
I have taken a look at the recalibrated C01 frames for LLO and LHO.  See LLO alog  21961 , for the LLO version of this.

I grabbed the H1:GDS-CALIB_STRAIN (online) and H1:DCS-CALIB_STRAIN_C01 (recalibrated) data from the Caltech cluster, and generated the ratio of the spectrum at time which we expect both the C01 and C00 to be correct.

The data is stored in the calibration svn at:
https://svn.ligo.caltech.edu/svn/aligocalibration/trunk/Runs/O1/H1/Results/C01

It was generated by the script:
https://svn.ligo.caltech.edu/svn/aligocalibration/trunk/Runs/O1/H1/Scripts/CHECKS/compare_C00_C01.m

Below I attach a ratio of the strain between C01 and C00, from GPS 1128249017 (Oct 7, 2015 10:30 UTC).  This is a time period when the front end models and GDS pipeline matched our best knowledge of the instrument and were used to generate the recalibrated C01 data.
 
This should be compared to LHO alog  22291 , first attachment.  Similarly to LLO (see LLO alog  21357 ), we believe the small 2% differences at low frequency are due to minor mismatches in the front end filter realization against our full calibration model which the GDS filters match well against.

The large narrow frequency 5% differences are around the DARM calibration line (at 37.3 Hz) is similar to LLO (see  21961 ).  The other higher discrepancy is I believe related to the front end filtering handling of certain notches, which Kiwamu had to reduced the Q for in the calibration.  See LHO alog  21332  and  22738 .

Non-image files attached to this report
Comments related to this report
daniel.hoak@LIGO.ORG - 04:02, Friday 23 October 2015 (22769)CAL

The issue with the front-end filters around the violin modes (see 22631) was only present in the C00 calibration between 0200 Sep 11 and 1600 Sep 14, so I think this does not appear in this comparison (which Joe says uses data from Oct 7).  The +/-5% discrepancy in magnitude at high frequency is around 600Hz, maybe it's a calibration line?

It might be worth making a plot like this for a stretch of time when the 508Hz noise was present in the C00 frames.

H1 SUS
jeffrey.kissel@LIGO.ORG - posted 14:34, Thursday 22 October 2015 (22749)
Charge plots from data taken Tuesday

Betsy writing on Kissel's account, but on behalf of Kissel for the most part...

 

Attached are the long trend plots of the ETM charge data taken last Tuesday after the power outage.  Stuart has added a new plot ala Kissel's request which plots ESD actuation strength.  This new plot will be useful in comparison against calibration's estimate of the actuation stregth from calibration lines, aka the parameter "kappa_TST" (for example alog 21817).  The sign flip of the ETMY bias voltage for a couple weeks ago seems to have turned the effective charge voltage back towards zero as expected.

Images attached to this report
H1 General
travis.sadecki@LIGO.ORG - posted 12:05, Thursday 22 October 2015 - last comment - 00:27, Friday 23 October 2015(22746)
Lockloss

Lockloss @ 18:46 UTC.  Cause is currently under investigation.

Comments related to this report
jenne.driggers@LIGO.ORG - 13:02, Thursday 22 October 2015 (22747)

This lockloss was caused by an EPICS freeze. 

We regularly run the SR3 "cage servo" instead of an oplev servo.  It is normally always on (even if the IFO is unlocked), but just in case it's not, the locking guardian requests that the SR3_CAGE_SERVO guardian turns on the servo sometime during the DRMI lock sequence.  As a reminder, this servo looks at the OSEM pitch value of the M3 stage, and actuates on the M2 stage to keep the OSEM values constant. This has been determined to be more stable over very long time scales than the optical levers. 

The SR3_CAGE_SERVO guardian was running along like normal, trying to write values to the SUS-SR3_M2_TEST_P_OFFSET channels. However, since EPICS was frozen, these values weren't actually being written.  The servo thinks that it just needs to push harder and harder, so starts significantly changing the offset value that it's trying to write (it's normally +-10 counts or so, but after this starts changing by about 1000 counts).  Once the EPICS freeze is over, it successfully writes one of these new, significantly different values.  This kicks SR3 pretty significantly, and we lose lock shortly afterward.

The attached lockloss plot shows POPAIR dropping at -1.75 seconds, which is when the actual lockloss happens.  Starting at -20 seconds, the OFFSET channel flatlines, which causes the M2_MASTER_OUT channels to also flatline.  You can see in 3 of the 4 NOISEMON channels that the RMS is significantly reduced temporarily.  Perhaps the M2 UL Noisemon is one of the ones that is broken, and that's why we don't see it there?  Anyhow, at around -6 seconds, the EPICS freeze is over, and the OFFSET comes back on with a very different value.  This causes a big glitch in the MASTER_OUTs and the NOISEMONs.  We lose lock about 4 seconds later.

Images attached to this comment
sheila.dwyer@LIGO.ORG - 18:06, Thursday 22 October 2015 (22754)

Dave, Evan, Sheila

We've added a few lines to the SR3 cage servo guardian to hopefully avoid this in the future. This will not update the offset unless the witness sensor value has changed. This may cause the cage servo to occasionally not run, but this doesn't seem like a problem. 

 

in the main we added 

        self.wit = ezca['SUS-SR3_M3_WIT_PMON']

 

    def run(self):
        if ezca['GRD-SUS_SR3_STATE_N'] == 100 and not self.not_aligned_flag:
            #if the value has not changed (possibly an epics freeze) skip running the servo
            if self.wit == ezca['SUS-SR3_M3_WIT_PMON']:
                pass
            else:
                self.servo.step()
                return True
        else:
            notify('SR3 not aligned!')
            return 'CAGE_SERVO_OFF'
    def run(self):
        if ezca['GRD-SUS_SR3_STATE_N'] == 100 and not self.not_aligned_flag:
            #if the value has not changed (possibly an epics freeze) skip running the servo
            if self.wit == ezca['SUS-SR3_M3_WIT_PMON']:
                pass
            else:
                self.servo.step()
                return True
        else:
            notify('SR3 not aligned!')
            return 'CAGE_SERVO_OFF'
sheila.dwyer@LIGO.ORG - 00:27, Friday 23 October 2015 (22764)GRD
Actually the code above won't do what was intended. We need to make sure self.wit gets updated each time run is executed. This code does no harm as is, so I will wait until morning to fix it.
Displaying reports 55921-55940 of 78094.Go to page Start 2793 2794 2795 2796 2797 2798 2799 2800 2801 End