[M. Wade, G. Mendell, A. Viets]

I restarted the primary and redundant GDS calibration pipelines around GPS time 1235572363 to pick up gstlal-calibration-1.2.8, which Greg installed yesterday on h1dmt0 and h1dmt2 (see LHO aLOG 47234).  Everything appears to be running normally.

A while ago Georgia and I moved the DARM offset and found that the 9 MHz RIN to DARM coupling decreases with increasing DARM offset.
Two days ago, I swept the DARM offset from 4 pm to 14.7 pm while a 70 Hz 9 MHz RIN line was on and present in DARM.  I then demodulated the line in software, plotted it as a function of DARM offset, and compared a few models to the data.  

It seems that 9 MHz RIN to DARM coupling falls like 1/DARM offset.  This rules out couplings like those explained by Kiwamu in attachment 4, which increase with increased DARM offset.

Dan, Alexei, Georgia, Craig

- FSS was refusing to lock after the 1 AM lockloss tonight, or losing lock soon after acquiring.  The problem went away by itself after about 30 minutes.

- Still dealing with 1 Hz ASC oscillation in full lock causing PRG and POP18 dippiness.  Likely DHARD.

- Lost lock three times at RESONANCE.  We were losing after increasing the DHARD gains.  Possible bad alignment heading into RESONANCE, I touched up the corner alignment and this help get through the fourth time.

- Lock lock from 1 Hz ASC oscillation during power up twice.

I took a PCAL to DARM broadband injection earlier this evening, and when I did I noticed that the front end CAL-DELTAL_EXTERNAL calibration was not great in the bucket.  We were underestimating DARM meters by 10% at 70 Hz.  
I spent a long time playing around with front end calibration gains in an effort to improve the front end calibration.  I was largely unsuccessful, as we lost lock before I could find a reasonable calibration.  

Things are mostly within 10% now, but still underestimating DARM meters at 70 Hz by about 8%.

The calibration from this afternoon (after Stefan played with these gains) is in red in the plot below, while the one now is in blue.  

Cal settings                           This afternoon     Now
----------------------------------------------------------------
H1:CAL-CS_DARM_ANALOG_ETMX_L1_GAIN     1                  3
H1:CAL-CS_DARM_ANALOG_ETMX_L2_GAIN     1.65               1.3
H1:CAL-CS_DARM_ANALOG_ETMX_L3_GAIN     1.24               1.2
H1:CAL-CS_DARM_ERR_GAIN                1.175              1.175

I've started looking again at DHARD, after Sheila's noise budget that shows that DHARD is contributing more than a passive coherence test will indicate (which also means that we cannot get the full impact of DHARD out of DARM with the offline cleaning pipelines). 

Sheila points out that one of the first things that we should do (and should have done several weeks ago when DHARD was causing us so much trouble) is take out the bounce and roll notches in the L2 stages of our quads.  We now have the bounce roll dampers, and we've been able to take the equivalent notches out of the DARM loop, so we shouldn't need to actively notch those modes.  This will win us quite a bit of phase below 10 Hz.  See the first attachment for a plot of our control filters with and without the bounce roll notches.

I measured DHARD this morning (shown in second attachment), with the notable changes from last time of new spot positions, and extra boost in DARM loop.  It seems like we're much better off, and don't seem to have the non minimum phase problem.  See the third attachment for an extraction (undoing the control filters) of the DHARD_P plant, as measured in late January and today.  I show different plant models though, since today's measurement much better matches the 30W model, even though we are definitely using active radiation pressure compensation to make our plant look like 10W.  More thinking to be done on this.

In the 4th attachment I show my measurement, manipulated to remove the bounce and roll notches, removing the gentle cutoff, and adding in the hard cutoff.  I'm happier using these manipulations of my measurement, to ensure that I'm looking at what the situation would *really* be, since we don't match any of the models precisely. I reduce the gain by a factor of 2 in the final proposed OLG shape with the hard cutoff.

The last attachment shows the error and control signals before and after we implemented these changes.  The residual motion RMS increases by about a factor of 2, but we can afford that and still be moving less than about 1 nrad RMS.  You can see that the control signal is much reduced at higher freqs.  We did see that a roll mode of one of the quads started ringing up, so our new plan is to instead using the roll-only notch filters.

Sheila has put these changes into the guardian.  We could definitely see an improvement in the DARM spectrum, although we've had some small earthquakes giving extra ground motion, so the range impact isn't quite quantified yet.  We didn't get as much range improvement as we hoped for, but that seems consistent with Sheila's noise budget from the other day that DHARD Yaw is more impactful.  So, that's next up!

NikoL, RickS

First, we re-installed the transmitter module shutter (Lasermet S/N 1258) that had been repaired by Filiberto and RichardM).

Then, we proceeded to investigate the clipping that had been reported based on observation of peaks in the Pcal Rx sensor signal ASD displayed in the control room.

We found that the outer (lower) Pcal beam was WAY off center (beam to the right in the first attached photo) at the Rx module power sensor.  Since doing in-chamber alignment of the Pcal beams at all four end stations, this is the first time we have seen significant beam movement at the Rx power sensor.

Inspection of the alignment irises revealed that the Outer Beam  pointing was also significantly off (several mm left of center) on the far iris (see second attached image), with the temporary, kinematically-mounted retro-reflecting mirror in place (fourth attached image shows optical layout in Tx module).

Given that the inner beam had not moved at the Rx sensor, and that the pointing was off in the Tx sensor, it seemed that either the beamsplitter or one of the two downstream mirrors that direct the Outer Beam out of the Tx module had moved.

The attached video shows that the BS mount moves significantly, and much more than expected, in response to rocking forces applied at the top of the mirror mount.

Either there are issues with this particular mount, or this type of mount has design flaws.  Or maybe it is the way we are suing them (over-tightening?).  The third attached image shows that a piece of paper could be slid under the back of the base, indicating that the base is only contacting the breadboard one edge.    I've discussed this briefly with Stephen Appert and we plan to investigate this flaw and possible solutions with the SYS group.

We adjusted the beamsplitter to re-center the Outer Beam on the Rx power sensor aperture (see fifth image below, with both beam incident on the Rx power sensor aperture), fine-tuned the alignment onto the Far Outer Beam iris in the Tx module, then proceeded with a standard end station Pcal calibration measurement suite.  The scanned log of the measurements is in the attached .pdf file.

Current results are in good agreement (with a few hundredths of a percent) with the mean of the previous Yend measurements.

Because we were curious, we looked at the residual DARM motion when locked in low-noise, and looked at the effect of the PUM boost filter that was added earlier this week (47164). I used H1:CAL-DELTAL_RESIDUAL_DBL_DQ, but had to remove the effect of the detuned SRC optical spring that was being applied in the CAL model. The attached PDF shows the calibrated residual spectra for 3 cases:

• Before the PUM boost was added (data from a week ago, 23 Feb 2019, 10:00:00 UTC). The residual in the band DC-10 Hz band is 7.1e-16 m-rms.
• After the PUM boost (data from today). Residual in the DC-10 Hz band = 2.9e-16 m-rms.
• With the 'resG' filter engaged (FM3 in the DARM1 bank). Residual = 2.6e-16 m-rms

'resG' was an existing filter, but wasn't being used until now. It contains a couple of resonant gain filters (0.45 Hz, 1 Hz, 0.15 Hz), and an integrator below 0.5 Hz (which we just added). It also had a bandstop filter at 332 Hz (PCal line), but we removed that because it is already notched in another filter. Engagement of 'resG' has been added to the guardian.

There is no obvious benefit to the reduction in DARM residual from the new filters, but they just seem like a good idea. The residual from the test mass violin modes is not captured in these spectra, but looking at the time series we can see that their amplitude is about the same level as this DC-10 Hz stuff. The nominal DARM offset is 11 pm, so the fractional residual is about 5e-16/1e-10 = 5 ppm.

As per WP 8104 and SCCB issue 82, I have updated the DMT production computers to gstlal-calibration-1.2.8. For example, this allows pcal correction factors that are applied to GDS strain to be updated from the front end for ER14. See: https://git.ligo.org/sccb/requests/issues/82.

I have not restarted the DMT calibration code. No changes have taken place yet.

When H1 is down, I have asked Aaron Viet to restart the DMT calibration code and put in an alog. This should not affect FOMs in the control room.

(More DMT/GDS updates are scheduled for next Tuesday maintenance, on March 5, as per WP 8106.)

Dave and Jonathan.

We rack mounted 3 of the new daq machines.  These will eventually be replacements for h1dc1, h1fw1, h1nds1.  We have the I/O cards in the machines, along with power and network cables run to the machines, but not yet plugged in.

We also pulled two older sun x4600 from the racks.  These where decommissioned VM hosts.  Pulling them frees up rack space for some computer moves that will take place in prior to the observing runs.

TITLE: 03/01 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: None
SHIFT SUMMARY: Commissioning all day. After 2 lock losses around DHARD_WFS (much like yesterday), but with a seemingly well aligned IFO, Jenne suggested we run the wfsreliefpast.py script from a time last lock. Seemed to work, even though DRMI didn't seem as well aligned. So it goes. The range reads 99.5Mpc as I write this, fantastic work commissioning crew!
LOG:

1630 Kyle to MY
1644 Vanessa to MX
1740 Chandra to MY
1824 Nutsinee to LVEA ISCT6
1918 Nutsinee out

2330 Kyle at MX

Following alog 47217 we set the DCPD input matrix.

- Added a gain of 0.977 to FM10 on DCPD_A. This matches the shot noise level in PDA and PDB

- Then the signal ratio g=PDA/PDB was measured to be g=1.021. Base on that, using the script in alog 47217, the matrix was calculated to be

  1.01039   0.98961
  0.98961  -1.01039
 

This matrix was loaded and committed to SDF, as was FM10.

I verified that the coherence of PDA-PDB agrees with DELTA_A-DELTA_B, i.e. the mixing and un-mixing of the signals indeed does not introduce a error.

Attached is a x-power measurement. Note that there is evidence for correlated noise at higher frequencies. I suspect that comes from glitches.

(The stuff at lower frequencies was an injection.)

Filiberto, Peter, Rich

The analysis of the OMC grounding and shielding is complete as far as it can be diagnosed with HAM6 closed.  There is only one area associated with the OMC PZT cable that needs to be scrutinized but it is inside the vacuum system.  The attached PDF has been carefully boiled down to the simplest form possible to explain the current situation.

The highlights are:
1.  A 25 pin breakout board was added to the QPD cable to break a ground loop that became apparent during this analysis.  There has been no observable benefit to this change, so at some point it might be that it is removed and the system restored to normal.
2.  The shield of the PZT cable is grounded in the vacuum system somewhere.  This does not create a ground loop per se (see attached diagram to see why), but it's not deliberate, and should be investigated next time HAM6 is open.
3.  There is a break somewhere in the shield of the PZT cable inside the vacuum system.  We don't know how big this gap in shielding is, but it does exist.  This needs to be identified next chamber opening.

I will alert Betsy to the need for these investigations to be added to the "when vent" category of tasks associated with HAM6

I have noticed a few times that the Big Red Button on the ISI_CONFIG screen is a little too appealing, and the button has been used at times when it maybe shouldn't have. The original intent of that button was to put the platforms in the safest possible state before or during a Montana sized (as in the 5.8 magnitude in Montana during July of O2) earthquake. The earthquake last night tripped ISI's, but probably wouldn't have tripped HEPI. So, I've changed the script the button runs to just take the platforms down to damped, leaving HEPI on. This should save some recovery time in the future. 

Because seismon doesn't give a good prediction of what surface velocities we should expect, the verbal notification only gets triggered if the earthquake is above a 6. So what should we do when we get a verbal notification? It depends, every earthquake is unique, but generally the smaller and further away the earthquake is, the response should be less dramatic. I discuss a few cases here.

1. Really, really bad earthquakes like the 5.8 in Montana, very close. Something like that will be onsite before seismon will see it.

Response: do nothing, wait for things to settle down before trying to recover.

2.Really bad farther away like 7-8+ in Mexico or Alaska, large and on the order of 5-6000 km away. 

Response: Put the platforms in as safe a state as possible, we will probably get a couple minutes early warning,. The Big Red Button will start this, but if the earthquake is big enough, or close enough, the added step of turning HEPI off may be help. But if the ISIs are already damped, it may not be any worse to just let HEPI trip on its own.

3. The 7 in Peru last night is kind of an edge case, about 8000 km away.

Response: Probably put the SEI_CONF guardian in the LARGE_EQ_NOBRSXY state. This won't save a lock, but this should keep ISI's from tripping, especially if the earthquake is much farther away than 8000 km. The Peru earthquake tripped ISIs, but I can't say for sure that changing just the sensor correction state wouldn't have prevented that. But, being on a different continental plate reduces the effect on we see here, I believe similar sized earthquake a bit further north in Central America would have been worse for us.

4. Magnitude 6-7 more than 8000 km away. These are common, sometimes we ride them out and they don't present any risk to the IFO.

Response: Nothing, or try the SEI_CONF EARTH_QUAKE state. Again, smaller and farther away require less response. We generally don't even see 4-5 magnitude eqs over 8000 km away.

I haven't had many chances to test it, but there is some fancy new code in the seismic models that we hope will allow us to stay locked through earthquakes like this. Because most of the ground motion is common ground motion during an earthquake is common mode, the new code uses the corner and end station seismometers to calculate this common motion, and the models subtract this out of the sensor correction signal. In SEI_CONF, this should be the EARTH_QUAKE state. I haven't had a chance to test this during any earthquakes, and it will probably help only during moderate or low microseism times. 

I had a quick look at the range integrand tonight, at a time last night when both L1 and H1 had fairly good ranges according to sensmon (L1 was nearly 140Mpc, H1 was nearly 100Mpc).  I used some code that gives an approximation of the range integrand, the absolute scale is wrong so that the total ranges I calculate are underestimated. The first attachment shows the sensitivity of L1 compared to H1 and in the lower plot the range integrand.  The second plot shows the cumulative range for both interferometers and the difference. 

From the second attachment you can see that we can gain ~20 Mpc by improving our noise from 40-20Hz.  In the first attachment you can see that the shoulders on the 60Hz lines are costing us. 

Last night I posted an incomplete ASC noise budget that shows that DHARD P+Y are both making large contributions to the DARM noise in this band. 47176  Since this is the band that we need to improve I started to look at why this noise is worse.  The third attachment shows a comparison of the DHARD P control signals from October 25th and last night, you can see that the control signal is about a factor of 10 larger in the band where it limits DARM than it was in October.  The RPC output is not included in this plot or in the noise budget that I posted last night, but it is too small to matter. The 4th attachment shows a comparison of the filters we were using in October; in addition to the filter change we are now using a gain of -42 instead of -30 in October.  

The last attachment shows a comparison of the coupling (DARM uncalibrated ASD/DHARD out ASD), you can see that the coupling hasn't changed much since October and most of the difference in noise is due to the loop shaping.  We have had many problems with the stability of the DHARD loop, which have been written about in several alogs, which is why the gain of this loop has increased, and the cut offs have become less aggressive.  It has been a while since we measured DHARD, so we were planning to try to get a good measurement before the earthquake hit. 

There is a broad noise peak at 48 Hz and its harmonic (96 Hz) that comes and goes in DARM. We do not know the cause, and I am posting this in hopes that DetChar can look into it. The attached pdf shows the DARM spectrum over ~10 minutes, but the spectrogram shows that the broad spectral feature is actually a narrower line that is wandering in frequency by several Hertz, at a time scale of 5-10 seconds. We know that these peaks can appear with or without the squeezer injection.

The peaks at 206Hz and 234Hz are gone. I guess the PBS did something good. The other two lines are still persistent. One at 177.7Hz got worse after I closed and reopened the beam diverter after a long lock (orange trace for ASQZ, cyan for SQZ). Compare to purple trace that I took right when I got in the control room. The line at 262Hz got worse after the beam diverter closed/opened but got better after sometime passed (dark purple). Maybe this suggests something mechanical? The next thing to do is to check the coherence with accelerometers.

Note that I kept the phase the same as last sqz measurement and I didn't optimized the nlg before I took this measurement (temperature setting was the same as last time).

We got a few noise budget injections done in this lock before we lost lock.  We will post a more complete noise budget once we have some more of the excitations done, a partial noise budget for the ASC noise contributions to DARM are attached. 

The other interesting thing that we found was that MICH is only about a factor of 3 below DARM from 60-80Hz.  

After we lost lock we needed to redo initial alignment, this might require realignment on ISCT1 since Jenne updated the initial alignment references for our new spot positions. 47168