TCS X slewing does not produce a null for jitter coupling

I looked back at the first TCS X slewing that Kiwamu, Stefan, and I did at the start of August. It seems that during this slewing, there was no null of the IMC jitter coupling. On the other hand, we already know that the coupling passes through a null close to the beginning of each lock stretch (22208).

First, the caveats: (1) the ISS outer loop was off during this test, and (2) one can see that the shape and location of the jitter peaks is different from what we normally observe in DARM.

The first attachment is a normalized spectrogram of DARM error during the slewing. It can be seen that the jitter peaks around 250 and 350 Hz increase monotonically from start to finish.

As a check, I looked again at the complex coherence between the IMC WFS error signals and DARM at the beginning and the end of this test (at 01:19:00 and 03:19:00, 2015-08-03 Z). Unlike what we see at the start of each lock, there is no sign flip of the coupling:

This seems to indicate that thermal tuning of the X arm alone is not enough to minimize the coupling. Either the null that we see at the beginning of each lock cannot be reached by thermal tuning, or we need thermal compensation on both arms.

LHO HEPI Pressure Trends--All Pumps Operating Steady

Attached is 2 weeks of data.  No pressure fluctuations seen == Pumps running well.  Also on the plots are the Control Out from the VFD.  Looks like outside temperature trends showing at EndY and that is likely the reason for the large fluctuations on the L0 (CS) control--facility adjusting HVAC.  The daily and weekly glitches at the EndY continue unabated.

LHO HEPI Fluid Reservoirs Checked--Good

Levels steady for several weeks now.  No further maintenance required.

duty cycle sept 17th to Oct 2nd, downtime Oct2-3rd

Motivated by our locking difficulties at the end of last week, I downloaded guardian state data for the last two weeks to look into our locklosses durring the CARM offset reduction.

To start with the good news, the script that I use to do this automatically makes a few figures that tell us about our duty cycle, and we are doing well overall. As usual, I am only looking at the guardian state, and not considering any intent bits.  My reaasoning is that the hardest part is getting and keeping the IFO locked, and that is currently the important limit to our duty cycle. 

• We have been locked in the nominal low noise state for 83% of the time (compared to 68% for the last week of ER8).  A good part of the improvement is probabably because the ground has been quieter in the last 2 weeks, although I didn't try to quantify that. (guardian state pie chart is the first attachment).
• About half of our DRMI locks result in nominal low noise locks (33/64).  A lockloss pie chart is in the second attachment. We have fewer locklosses in the late stages of the guardian, which could be because we are waiting for the first sets of ASC loops to engage before we engage the soft loops (alogs 21583 21587)
• The median low noise lock stretch was 5.5 hours long, while the longest was 59.7 hrs long.  A histogram of the length of low noise locks is in the third attachment.

The main weakness in our lock acquistion sequence now seems to be the early steps of CARM offset reduction, as we saw yesterday. 

•  We certaintly have a harder time with these early steps of CARM offset reduction when the ground motion is high, which explains most of our down time from the 2nd to the 3rd.
  • The 4th attachement show a histogram of locking attempts bined by ground motion, which is the maximum of the sum of the Y direction blrms for 30mHz-100mHz and 100-300mHz bands durring the locking attempt. I chose the Y direction at Y end because that tends to have more wind induced tilt, so this should include the impact of wind, earthquakes and useism.  You can see that we struggle to lock when the ground motion in these bands is above 250nm/sec, although occasionally we do suceed.  In the version of the plot attached here, I called a locking attempt sucsesfull if it reached the low noise state, but the plot doesn't change much if you instead make it for locks which make it past the stage where the DHARD ASC loops come on. 
  • The 5th attachment shows the ground motion over the last week, with a plot of the range to illustrate where the long stretch of downtime was.  Clearly, this was mostly time when the ground motion was high enough to cause us locking difficulties.
• One thing that might be hurting us in these early stages of CARM offset reduction is OMC flashing, see alog 22237. We will pull this off resonance using the guardian soon.  These OMC flashes are mostly not bright enough for us to see them on the AS camera, and it may just be that we see more OMC flashes when there is more light at the AS port because of bad alignment or high ground motion. 

DQ Shift Oct. 1 - Oct. 4

Link to the DQ shif paget: DQ Shift page.

Summary:
 * October 1 had locks lost doing injections looking for scattered light in the X end. Otherwise a nice set of data, with a duty cycle ~80%.
 * October 2 and 3 there was some problems locking. High winds, beam splitter optical lever glitching, and ALS X/Y problems locking. At one point ~22 hours unlocked.
 * October 4, recovered from the past two days and had some long locks with a duty cycle ~80%.

H1 PSL FE Watchdog Reset

I reset the PSL FE watchdog at 16:14 UTC (09:14 PDT).

Shift Summary -Day Transition

TITLE: Oct 6 DAY Shift 15:00-23:00UTC (08:00-04:00 PDT), all times posted in UTC

STATE Of H1: Commissioning

OUTGOING OPERATOR: Patrick

QUICK SUMMARY:IFO in commissioning mode as Maintenance Day begins.

ISP network maintenance begins

Expected Internet outage of about 15 minutes as one of our ISPs performs network maintenance this morning, between 0800 and 0900 Pacific (1500-1600 UTC).

Maintenance has been completed.

Ops Owl End Shift Summary

TITLE: 10/06 [OWL Shift]: 07:00-15:00 UTC (00:00-08:00 PDT), all times posted in UTC
STATE Of H1: Locked. Commissioning.
SHIFT SUMMARY: Locked entire shift. One GRB alert. Went to commissioning at the end of the shift to allow Sheila to run injections.
INCOMING OPERATOR: Ed
ACTIVITY LOG:

11:08 - 11:18 UTC Stepped out of control room
14:18 UTC Went to commissioning to allow Sheila to run injections (WP 5528)
14:27 UTC Bubba driving to VPW
14:47 UTC Let Safety Clean truck through gate. Notified Bubba.

SUS E_T_M_Y saturating (Tue Oct 6 11:22:48 UTC)
SUS E_T_M_Y saturating (Tue Oct 6 13:54:13 UTC)

From watching the monitor it seemed that RF45 coherence may have risen with the DARM spectrum during these saturations.

Ops Owl Mid Shift Summary

17:20 UTC Stopped/restarted gracedb query script
07:42 - 7:44 UTC Stepped out of control room
09:55 UTC GRB alert. Notified LLO.
10:30 - 10:36 UTC Stepped out of control room

Still observing @ ~79 MPc.

Restarted grace query db script in screen

I saw on a terminal on the ops workstation that someone had logged into h1fescript0 and started the query grace db script without running it in screen. I ctrl-c terminated that script. I did a listing of the current screen sessions (screen -ls) and saw two running. The one with PID 4403 had the printout from a crashed query db script. I restarted it in that screen and detached from the session. It is now running in screen with PID 4403.

Ops Owl Beginning Shift Summary

TITLE: 10/06 [OWL Shift]: 07:00-15:00 UTC (00:00-08:00 PDT), all times posted in UTC
STATE Of H1: Observing @ ~ 78 MPc.
OUTGOING OPERATOR: Nutsinee
QUICK SUMMARY: From the cameras the lights are off in the LVEA, PSL enclosure, end X, end Y and mid X. I can not tell if they are off at mid Y. Seismic in 0.03 - 0.1 Hz band is around .015 um/s. Seismic in 0.1 - 0.3 Hz band is around .1 um/s. Winds are less than ~5 mph.

Ops EVE Shift Summary

TITLE: "10/05 [EVE Shift]: 23:00-07:00UTC (16:00-00:00 PDT), all times posted in UTC"

STATE Of H1: Observing at ~75 Mpc for the past 9 hours. Range recently went up to ~78 Mpc for no apparent reason.

SUPPORT: Mike

SHIFT SUMMARY: Quiet shift. Minimal/nominal seismic activity. Wind below 5mph. GraceDB querying failed once.

INCOMING OPERATOR: Patrick

ACTIVITY LOG:

23:51 Chris started HW injection.

01:41 Injection done

04:00 Noticed GraceDB querying failure. Restarted the python script. Called Mike about GraceDB events that weren't labeled as INJ.

Follow up on H1 Loud glitches

I was following up the LHO loud glitches from 26th September. I had a look at the transmitted power signals as done in alog 20395 for dust glitches. The attached pdf contains the plots of band passed (10Hz-100Hz) DARM, as well as ASC-{X,Y}_TR_{A,B}_NSUM_OUT_DQ and SUS-ETMY_L3_MASTER_OUT_LL_DQ channels for the 8  time instances when ETMY saturation was observed. The ETMY saturation times are given below:

 1127380417.6250 1127380418.6875
 1127384361.3750 1127384361.8125
 1127389556.1250 1127389556.2500
 1127403691.3750 1127403691.5000
 1127409078.3750 1127409078.5625
 1127418386.1875 1127418386.4375
 1127423722.0000 1127423722.1250
 1127424221.7500 1127424222.0000
 1127427748.9375 1127427749.0625

It can be noticed that the glitches also appear in  Y TR signals (e.g., ASC-Y_TR_{A,B}_NSUM_OUT_DQ) with large amplitude except the 4th one. For the 4th glitch, it is not visible in ASC-Y_TR_{A,B}. In this particular case, , it is visible in X QPDs  but much smaller than the other ones in Y. Also it doesn't look like that it is much above the noise in the QPD, and even the glitch shape in DARM seems different. In most of these cases DARM is going down and  ASC-Y_TR_{A,B}_NSUM is going up initially. So it is interesting that in spite of ETMY saturation, the glitch shape is completely different as well as nothing can be found in Y QPDs. 

Noticed GraceDB querying failure around 4:00 UTC

I followed alog22210 and fixed the problem. Since I wasn't sure when exactly GraceDB querying failed (It was working duringt Chris's injection), I looked into all the GraceDB events that happened after 01:36:48 UTC with FAR of 1e-7 and below as Mike suggested. They were all hardware injections.

8 successfully scheduled coherent hardware injections

Summary:

I performed 8 coherent H1L1 CBC hardware injections. They were all successful.

Waveforms:

Waveforms are in the hardware injection SVN: https://daqsvn.ligo-la.caltech.edu/svn/injection/hwinj/Details/Inspiral/${IFO}/coherentbbh*_1126259455_${IFO}.out

Waveform parameter files are in the hardware injection SVN: https://daqsvn.ligo-la.caltech.edu/svn/injection/hwinj/Details/Inspiral/coherentbbh*_1126259455.xml

Schedule:

The following was appended to the schedule:
1128124325 1 1.0 coherentbbh1_1126259455_
1128125225 1 1.0 coherentbbh2_1126259455_
1128126125 1 1.0 coherentbbh3_1126259455_
1128127025 1 1.0 coherentbbh4_1126259455_
1128127925 1 1.0 coherentbbh5_1126259455_
1128128825 1 1.0 coherentbbh7_1126259455_
1128129725 1 1.0 coherentbbh8_1126259455_
1128130625 1 1.0 coherentbbh9_1126259455_

Recall we had the issue before where injections were being cancelled since they triggered an EM alert for testing. Peter S. documented what needed to be changed in aLog 22163. I reset ${IFO}:INJ-CAL_TINJ_PAUSE and ${IFO}:INJ-CAL_EXTTRIG_ALERT_TIME between injections so that they were not cancelled. It worked.

The gracedb entries for these injections are H190051 to H190068.

I've attached omegascans of the injections.

Stopped hardware injections from getting labeled with H1OPS

Since the current set of hardware injections is testing the injections themselves, not the human response to event candidates, I have changed the Approval Processor configuration to no longer treat hardware injections like real GW event candidates.  That means that they will not get the H1OPS and L1OPS labels, and operators will not be presented with a sign-off box for them.  However, with the CURRENT version of the external alert code (ext_alert.py), audible alerts will still sound in the control rooms.  I am trying to arrange that during tomorrow's maintenance period we will update the ext_alert.py scripts so that the audible alerts sound only for triggers that operators are asked to sign-off on.

After that change is made (hopefully tomorrow), please take any audible alert seriously as a genuine external-trigger alert or low-latency GW trigger alert.  Exception: we are planning to set up weekly tests of the alert system that will happen during Tuesday maintenance periods; details to come later.

CDS model and DAQ restart report, Saturday Sunday 3rd,4th October 2015

O1 days 16,17

Saturday 3rd October 2015. Many unexpected restarts of h1fw0 due to failed SSD raid. No other restarts reported. Details in attached text file.

Sunday 4th October 2015. Many unexpected restarts of h1fw0 due to failed SSD raid. No other restarts reported. Details in attached text file.

Starting coherent hardware injection test

I am starting some coherent H1L1 hardware injections test. There will be the 8 test injections that Adam and I did not get a chance to perform last Friday. I will add a comment with the schedule when it they have been added. More details to follow later.

The schedule was appended with:

1128124325 1 1.0 coherentbbh1_1126259455_
1128125225 1 1.0 coherentbbh2_1126259455_
1128126125 1 1.0 coherentbbh3_1126259455_
1128127025 1 1.0 coherentbbh4_1126259455_
1128127925 1 1.0 coherentbbh5_1126259455_
1128128825 1 1.0 coherentbbh7_1126259455_
1128129725 1 1.0 coherentbbh8_1126259455_
1128130625 1 1.0 coherentbbh9_1126259455_

Last scheduled injection performed. More details later.