Matt, Terra

Status of PI after TCS work and ring heater change transient (for at least the first three hours of 50 W lock):

1. Successfully damping all modes (with some caveats; see #4,5.)
2. Actively damping ITMX 15520, ITMY 14980 and 15515, ETMX 15541 and 15008, ETMY 15542, 15009, 18041 and 18059 Hz. Of these, the 18kHz and 15kHz only ring up during the transient. 
3. All modes are now getting damped using the PLL. One motivation for this is avoiding saturations. I'm fairly certain that the mysterious sign flips and illogical behavior when increasing gain in the past have been due to something saturating along the loop, usually resulting in ringing up the mode. 
4. 15009 Hz (MODE 26) is still a bit confusing: it rings up twice during the transient period and appears to require a sign flip to damp each time. I'm not yet convinced this isn't just a byproduct of the transient though (we flip a gain sign and see a slow downturn on the same timescale as the transient passing, attributing the turn around to the wrong reason?). 
5. After ~2 hours, 15541/2 Hz (MODE 17/25) ring up. While we have the actuation strength to damp these, these modes are ~.5 Hz apart, so the PLL is having trouble staying on the right one and I had to do lots of actively jumping back and forth between controls. We are going to try sending both drive signals to both optics, etc. 

3 hours into the lock and all PI's are stable. Leaving PI control with Matt for the night. 

Kiwamu I, Jeff K, Darkhan T,

Overview

Today we looked at the calibration line coherence values calculated in the front end. We discovered that in the front-end model with the currently used averaging parameters the coherence value is updated once every 10 seconds (first 1.5 minutes in Fig. 1).

We propose modifying the averaging code to improve coherence calculation and avoid potential aliasing (see details).

Details

A front-end model that calculates coherence uses N data points taken every S_cycles computational cycles to calculate cross-spectral density of the signals. S_cycles is controlled by an EPICS record $(IFO):CAL-CS_TDEP_COH_STRIDE (or simply STRIDE): S_cycles = FE_RATE * STRIDE. There are drawbacks associated with this approach:

• New coherence value will appear every STRIDE seconds;
• Skipping data points will produce aliasing.

We can deal with the first problem listed above by reducing STRIDE. On Fig. 1 we show coherence values for N = 10 and STRIDE set to 10, 5, 1, 1/16 and again 1. Notice that this test was done when the IFO was not locked, thus we do not expect a coherence of ~1. When STRIDE is set to 1/16, we can see that the number of averages must be increased in order to include actual fluctuations in the signals (in the last 2.5 minutes N = 120).

Fig. 1

Several minutes later IFO locked (at t = -5 in Fig. 2) and the coherence became ~0.8. After we set the line amplitude to its nominal value we got coherence of ~1.

Fig. 2

Next, to avoid aliasing we should use all data points (equivalent to setting STRIDE = 1/FE_RATE in the current code) and increase N accordingly. Thus to integrate over 10 seconds and avoid aliasing the current code will require O(FE_RATE * 10) = O(160k) operations per cycle and a buffer for 160k values, which is unnecessary expensive.

A following minor modification of the averaging code can solve the issue described above. Instead of adding every S_cycles'th data point into the averaging buffer, we could insert an average of S_cycles values. E.g. buffer_and_average() can be modified as follows:

...

    static int mini_sum = 0;

...

    //Increment cycle count
    mini_sum += data;
    cycle_counter++;
    if (cycle_counter >= cycles_between_data) {
        buffer[current_pointer] = mini_sum / ((double) cycles_between_data);
        current_pointer++;
        cycle_counter = 0;
        mini_sum = 0;
    }

...

With this modification and N = 160, STRIDE = 1/16 (S_cycles = 1024), the coherence will be calculated with 10 second integration and will require O(160) operations per cycle, and the coherence value will be updated every 1/16 of a second.

Neither PIT or YAW trends were near/approaching +/-10urads, so it looks fine.  Nothing obvious on the SUM trend either.

This CLOSES FAMIS #4693.

[Jenne, Sheila, Matt]

On our way to trying for some low noise, we went through the CoilDrivers state.  But, somehow there was some buggy code in there that it was only trying to switch the UL coil of all the optics ('PRM', 'PR2', 'SRM', 'SR2', 'BS', 'ETMY', 'ETMX', 'ITMY', 'ITMX') over and over again, and never going to any other coils.  After a few minutes of this, we lost lock.  I don't know that I can prove that that's why we lost it, but we lost lock on this state yesterday also, and certainly having 3 coils one way, and one coil continually going between states 1 and 3 isn't helping keep us locked. Code fixed, we'll try it again next lock.

Jeff K, Darkhan T,

Overview

CAL-CS synchronized oscillator settings for cal. line coherence calculations were lost after the recent power glitch (LHO alog 29592). The settings were lost because after populating the settings (see LHO alog 28995) on August 10, not all of the channels were monitored by SDF_OVERVIEW.

Today we restored the coherence calculation settings and accepted the changes in SDF_OVERVIEW.

Details

The power glitch did not cause losses of the H1CALCS filters, so running set_coherence_h1.py (that populates filter modules) was not necessary this time (only changes names of the "1/f^2" filters to ":1,1", same as in PCAL models).

However filter module switches needed to be turned on (those previously weren't monitored by SDF_OVERIVEW). Some of the synchronized oscillator settings were also lost during the power glitch, they have been fixed now.

Today we updated coherence calculation settings for the following lines:

•   35.9 Hz - ESD, SUS_LINE1
•   36.7 Hz - PCALY_LINE1
•   37.3 Hz - DARM_LINE1
•  331.9 Hz - PCALY_LINE2
• 1083.7 Hz - PCALY_LINE3

All channels have been added to the list of monitored channels and the values have been accepted in SDF_OVERVIEW tables (safe.snap and OBSERVE.snap).

Note: IFO was not locked when the screenshots were taken.

Terra, Dave:

new h1susprocpi model was installed. This adds 64x2k chans to the science frame. The 'place holder' zeroed data were removed at the same time. DAQ was restarted.

related to 29648,

The output from HWSY doesn't look reasonable. This is something we knew, but this time a surprising thing was that, if I interpret the data as it is, the self heating on ITMY introduced negative lensing rather than positive lensing. This does not make sense. See the second attachment below. The first attachment is the HWS signal for ITMX with its prediction from the TCS simulator for comparison.

State of H1: has locked and made it to DC readout

Activities:

• new ISS code
• new LSC code
• multiple DAQ reboots
• many visits to the LVEA since there was access

Relocking:

• old offsets for IR beam caused the dark level to be around -0.3.  Jenne fixed
• BS and PRM needed to be aligned and Jenne showed me her new state that isolates the BS for alignment in ISC_LOCK, and it worked well
• transition from DRMI to DC_Readout went smoothly
• lock didn't last, so Corey is relocking

Jeff K, Chris Whittle

Following on aLOG 28363 (initial proposal) and 29250 (installation), we measured the open loop gain of the IMC loop (without full CARM) with the AG4395A, both with and without the daughter board 200 kHz pole. The GPIB is still connected to the AG4395A by the Common Mode Board.

TFAG4395A_15-09-2016_140247.txt has the transfer function without the daughter board, TFAG4395A_15-09-2016_140553.txt with the daughter board. The attached plots were generated with daughter_tf_plots.py.

See the attached plots of open loop gain, loop suppression and closed loop gain. Takeaways:

• features around 800 kHz suppressed by 200 kHz pole
• we still have 48° of phase margin compared to our previous 63°
• unity gain frequency has moved from 75kHz to 64kHz
• gain margin has increased from 2.7 dB to 4.6 dB
• maximum gain peaking in the loop suppression has been reduced from 4 to 2.5
• closed loop gain is relatively unchanged below 40 kHz and should not affect CARM loop

Also note some variation in the OLG at about 200 kHz compared to the previous measurement.

Added 200mL to the crystal chiller.

FAMIS#6488

State of H1: unlocked, maintenance activities

Activities:

• 15:10 - Peter - PSL - alignment
• 15:20 - Fil - LVEA vertext - pulling cables
• 15:43 - Kyle - EX VEA - vacuum
• 15:43 - Betsy - LVEA - parts
• 16:00 - Gerardo - MX and EX - ion pump swap
• 16:30 - Dave - restart LSC to load new code
• 16:30 - MikeL - LVEA - tour
• 16:37 - Kiwamu - LVEA - tour
• 17:00 - MikeL - done
• 17:05 - Kiwamu - done
• 17:14 - Betsy - done
• 17:34 - Peter - done
• 17:37 - Dave restarting LSC and ISS code and DAQ
• 17:37 - JeffB - diode room
• 17:43 - JimW - EY - BRS, ion pump might not be on
• 18:25 - Betsy - LVEA - iLigo and 3IFO TCS parts
• 18:43 - Betsy - done - found two
• 19:00 - ChrisWhittle and JeffK - LVEA - GPIB

As of 20:29UTC:

• ChrisWhittle and JeffK - done
• JimW - done
• JeffB - done
• Dave - done
• Gerardo - done
• Kyle - done
• Fil - done

Commissining Work:  LSC and ISS

Daniel, Keita, Dave:

we installed new versions of h1psliss and h1lsc. This required a DAQ restart.

A brief history of IP10, the controller for IP10 had A channel go somewhat bad on 9/3/2016, controller was set to output 5k volts but its output was only able to do about 2k, then we had a power glitch on 9/10/2016, that caused the current output to go down and the pressure to go up (see attached graph).

Since IP12 is currently valved out, where the pump is pumping on a small volume, we decided to swap controllers between pumps.  So for now IP12 will show some alarm values until the controller is fixed.  And to keep the small volume at IP12 good, we are pumping with one channel despite of what the signal says.

The factory flanged flange containing the inadequate fasteners was "gappy" enough that I tried the easy in-situ replacement of its fasteners but unfortunately it didn't work (2x10-8 torr*L/sec leak) and I had to vent the RGA volume and replace the gasket along with adding the good fasteners -> pumped down RGA volume and leak tested new joint -> No leak detected (Leak Detector baseline signal 3.5 x 10-9 torr*L/sec helium).  I didn't have the RGA laptop so I'll need to go out again at the next interferometer (IFO) downtime to verify the the RGA works after having being withdrawn from and reinserted into its protective nipple (this exercise can result in a grounding of some of the tight clearance electrodes upon re-insertion).  

Leaving work area shut down, i.e. there are no pumps running or related electronics energized etc. 

I have increased the chilled water set point by 5 degrees F to 45 F on the corner station chiller.

The BRS at EY has had a long term drift requiring periodic recentering. That drift seems to have stopped or changed sign, following the power outage on Saturday. Attached image is a 60 day trend for H1:ISI-GND_BRS_ETMY_DRIFTMON. The black streaks are from when the BRS went out of range and when it was recentered during Krishna's last visit. The little blip up to zero at the end is from the power outage, before the commissioners recovered the BRS code. Second image is the last 6 days, outage is when the signal goes to zero. Definitely looks like the drift has changed sign.

Sheila, Matt, Lisa

The ISS has been oscillating a couple of times when reaching 50W in the last two locks. Sheila fixed that by turning off the AC coupling.

We leave the IFO locked at 50W with the ISS AC coupling off, at Sep 15, 9.45UTC. It has been locked for about 20 minutes, powers are stable, no PIs.

Matt updated SDF with the latest PI settings.

We just noted that the PSL NOISE EATER is oscillating -- so please fix that in the morning.

I have spent some time trying to understand the behavior of the CARM loop in full lock.

First, I have reduced the loop to the following block diagram:

P is the IFO, K is the IMC, and G is the FSS. F and M represent the fast and slow common-mode feedback paths, and A represents the IMC PDH board and the VCO. A fuller accounting of these blocks is given in the sections below.

The OLTF of CARM is then given by