TITLE: 03/06 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 119Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY: Locked for 6h30
LOG:

• 16:11 Lockloss see alog 55450
• 16:25 Tyler moving Big green to front of OSB from the y-arm direction to clear tumbleweeds in front of offices!
• 16:44 Had a call from TJ Massinger to say that the INJ_TRANS node had frozen after failing to do last nights injection so clicked INJECT_KILL, INJECT_SUSSES to get it working.
• 17:07 Big green finished and parked.
• 17:36 Observing
• 21:42 (back 22:30) Gerardo out to MX
• 22:04 Kyle out to MY then MX
• 22:34 (to 22:35) Commissioning for Jenne to revert SQZ channel from Tuesday and Jim to load SEI_ENV GRD changes (as described in alog 55457). 
• 22:43 Gerardo out to MX

All oplevs recently dentered on unlocked/aligned IFO. Loops have driven ETMX OpLev to te limits shown in the trend plots. Not much to do about this at this time. It is our present reference of locked/"stable" alignment.

chiller water at max on Xtal chiller. No alarms on Diode chiller. No water added

There was a small earthquake this morning that passed through, which I expected to have cause the seismic system to transition to the earthquake state. It didn't, and probably didn't need to, but it did indicate that the seismon test in SEI_ENV was too strict. That test stopped checking whenever the seismon arrival time went to 0, so wouldn't trigger on an earthquake if arrived after the seismon prediction. There's an independent "passive" test that triggers when peak mon goes above 1000 nm/s, but for moderate earthquakes, that could be too late to prevent a lockloss.

I've changed the test to give us a window of 2 minutes after the seismon prediction. So line 49 used to be:

           ezca['SEI-SEISMON_LHO_R35_ARRIVALTIME_TOTAL_SECS_{}'.format(i)] > 0:

is now: 

           ezca['SEI-SEISMON_LHO_R35_ARRIVALTIME_TOTAL_SECS_{}'.format(i)] > -120:

[A. Viets, M. Wade, J. Kissel]

The filters for C01 calibration for the first part of O3b are now ready for use.  There will only be one epoch spanning the GPS time period 1256655618 - 1263060018.  Information about filters and configurations to be used for each epoch can be found on the GDS/DCS configurations wiki page.

Epoch 1: 1256655618 (Nov 01 2019) - 1263060018 (Jan 14 2020)

This epoch uses filters file aligocalibration/trunk/Runs/O3/GDSFilters/H1DCS_C01_1256655618.npz which is made from the model file aligocalibration/trunk/Runs/O3/H1/params/modelparams_H1_20200103.

Info about model file:  This model includes a dynamical model of the UIM to TST transfer function which mitigates the 3%-level systematic error in the response function at ~150 Hz.  This model also includes an updated test mass mass for O3, improved locations of violin mode frequencyes for L2 and L3 transfer function, reduction in amount of violin modes accounted for on the L1 to L3 stage, updated actuation strength coefficients for all three stages, updated sensing function parameters to account for switch to 38W power from 36W.

These filters were tested by calibrating C01-style data during three different PCAL broadband injection throughout this epoch and comparing the calibrated strain data to the broadband injection.  The three attached plots show this ratio for broadband injections at GPS times 1258923929, 1260738026, and 1262638968, respectively.  Plots of the filters themselves can be found in aligocalibration/trunk/Runs/O3/H1/Scripts/TDfilters/H1DCS_C01_1256655618_plots.

TITLE: 03/05 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 120Mpc
OUTGOING OPERATOR: Jim
CURRENT ENVIRONMENT:
    SEI_CONF state: WINDY
    Wind: 4mph Gusts, 3mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.49 μm/s
QUICK SUMMARY: Locked 3 hours. Lock acquisition from last nights 2020-03-05 11:49:11 UTC lockloss happened 100% automatically!

This is a follow up to alog 47604, mostly this gif.

LHO is currently locking the SRCL degree of freedom with 50 cts of offset.  Detuning in the SRCL dof causes an optical spring to appear in DARM. (see e.g. alog 52981, host to this plot).
From the many DARM TFs, 50 cts in the SRCL loop corresponds to about 0.5 degrees of detuning from perfect resonance.

Why should the SRCL loop lock in a detuned state?  I am testing the idea that higher order modes existing in the SRC spoils the SRCL error signal.
The SR3 heater alters the radius of curvature of the SR3, changing the mode content in the SRC.
The gif above shows the effect of a SR3 heater off-on-off test has on the DARM plant.  The DARM plant TF changes from anti-spring to spring to anti-spring again.
This suggests that the mode content of the SRC has a strong effect on the SRCL error signal.

Using Finesse, I have modeled the LHO higher order mode content in each cavity while changing the SR3 radius of curvature (via "lock dragging"). 
If I change the SR3 RoC by ~10 mm, we start to see a number of effects on the model:
1) The 02 and 20 HOM content in the SRC starts to become significantly high. (Plot 1, [here "omc" means incident on omc, and "as" means OMC DCPDs])
2) The SRCL error signal becomes distorted on the upper side (Plot 2)
3) The SRCL error signal zero-crossing moves away from 90 degrees (Plot 3)
4) SRM tuning moves away from 90 degrees to keep the IFO locked (Plot 4)
5) As SRCL becomes detuned, we see the optical spring appear in the DARM TF (Plot 5)

At the moment, this model cannot totally explain the DARM optical spring.  This Finesse model is fairly optimized, with no astigmatism in the arms or mode mismatch from IMC to IFO.  But if we take the DARM plant MCMC fits from the gif to be accurate enough, the SR3 heater caused the optical spring frequency to flip from around -3 Hz to 3 Hz and back again.  This model is good to about that order of magnitude.

TITLE: 03/05 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 114Mpc
INCOMING OPERATOR: Jim
SHIFT SUMMARY:
H1 running smoothly for almost 8.25hrs.  

If the FSS has trouble locking, call Jason (Rick is back up if you don't reach Jason).

LOG:

• 7:18 incoming EQ for 5.5 from Chile.  
  • Seeing SEI_ENV flash like an Xmas tree between Calm & Seismon Alert.
  • Then it stayed calm.
  • And then no observable EQ.

Had a recent stint of glitches, but other than that, smooth sailing with H1 locked for 4.5hrs and a range hovering around 117Mpc.

TITLE: 03/05 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 116Mpc
OUTGOING OPERATOR: Cheryl
CURRENT ENVIRONMENT:
    SEI_CONF state: WINDY
    Wind: 11mph Gusts, 9mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.39 μm/s 

Microseism has inched up slightly over the last 24hrs.
QUICK SUMMARY:

H1 was recently locked as I arrived.  Currently seeing the range decrease (it's under 115Mpc currently).

FSS:  If there are issues with it locking, we are to call Jason/Rick.

TITLE: 03/05 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 116Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY: Lost lock in the middle from, seemingly, commissioning activities. We then took some time to try to diagnose the FSS relocking issues we have had lately. Lock acquisition after that was all autonomous.
LOG:

• 1731 Vanessa to MX
• 1734 Out of Observing for Commissioning
• 1755 Observing
• 1834 Chandra to MY
• 2026 Lockloss
• 2143 Richard to CER
• 2150 Richard out
• 2344 Observing

A few weeks ago we tried to install an new network switch in the CER.  For some reason it did not work for uur needs.  We pulled the switch out today to download the config to show the vendor as we try to figure out what happened.

[Sheila, Jenne]

We took a few tens of minutes this morning to check how far and fast we can move the SRC spot by changing the AS_C offset.  Once we had those numbers, we started a script to slowly move the offsets while we're Observing.  The script started at 18:21 UTC.

[Sheila, Jenne]

Although the squeezer seems to not have gone into oscillation since last Thursday when we lowered the green power (alog 55339), we are looking to see if we can better understand the cause and ameliorate it (spoiler alert: so far we don't know, although we have further tests to try today). 

Here's what we've done so far:

• Noted that the OPO_PZT_1_VOLTS was 57.4V and had been drifting downward lately.  Recall that we don't tend to see oscillations unless the OPO locks with the PZT above 60V. 
• While on the phone with Sheila, I moved the green ISS setpoint (H1:SQZ-OPO_ISS_SETPOINT) to bring the OPO_TRANS_DC_NORMALIZED power up until we started to see oscillations. 
  • The oscillations started when the TRANS_DC was just shy of 1.7. 
  • This brought the SHG_LAUNCH_DC_POWERMON to about 17.7mW, which is under the threshold of 20mW (to prevent fiber degredation we prefer not to launch too much power in).
  • Interestingly, the OPO_REFL_DC_POWER was slowly increasing as I increased the green power, but then it jumped up a lot when the oscillations started.
  • In the first attachment (IncrPowerToStartOsc.png) you can see that the TransDC and ReflDC are increasing as I change the ISS setpoint, but around -4490sec the REFL power jumps up and we start oscillating.
• We turned off the green ISS using the Servo/Ramp button.  The oscillations were gone, but the power had gone down since we were no longer servoing to that ISS setpoint.  Turning the ISS back on brought the power back up and the oscillations back.
  • Turning off the ISS is shown at the very end of the first attachment, around -4455sec.
• I went out to the squeezer rack and changed which of the 2 PZTs that can be used to lock the OPO we were driving. 
  • We have access to both via the squeezer interface chassis in the squeezer rack's slot 12, but only one driver.
  • Sheila had brought the squeezer manager guardian to DOWN, and ensured that the PZT voltage out was near zero (~1V). Richard confirmed that it should be totally fine to switch the cables on the back of the interface chassis.
  • The driver had been plugged in to PZT1, and a terminator was on the PZT2 SHV connector. The second attachment (PZT_connectors_before_change.jpg) shows their configuration before my change.
  • I unplugged both the cable and the terminator, and put the terminator onto the PZT1 connector and the cable from the drivere onto the PZT2 connector. The third attachment (PZT_connectors_after_change.jpg) shows their configuration after my change.
• Sheila requested the squeezer manager to relock.  Using PZT2 (although the channels are still called PZT1) the OPO locked at around 26.5V.
  • The oscillations were really bad, although that was partly because the ISS was railed.  (The voltage limiter at the output of the ISS had a red box around it.)
  • We turned off the ISS and the oscillations went away. 
  • We returned the ISS setpoint to the value we'd been using that gave green power of 1.2, then reclosed the ISS and the oscillations were gone.
• We moved the ISS setpoint to re-increase the green power, and the oscillations showed up just shy of 1.6 (a little lower than when we were using the original PZT). 
  • This must have been very close to the threshold where the oscillations start, because they seemed to breathe, and then went away on their own.
    • In the fourth attachment (PZT2_oscGoAwayByThemselves.png), the oscillations start near the left side of the plot, and decay away by about -2540sec.
  • I increased the green power a small amount, and the oscillations came back. 
  • I decreased the green power and the oscillations went away, so this was definitely on the threshold of where the oscillations are happening.
    • The increase and decrease of power happened around -2500sec on the fourth attachment.
• Sheila changed the locking parameters for the squeezer guardian (the voltage at which it starts the scan for locking the OPO), and relocked the OPO at a higher PZT voltage.  It ended up being about 58.5V.
  • The oscillations were present.  I reduced the green power a small amount around -2385seconds in the fifth attachment (PZT2_higherVoltage.png).
    • The oscillations in the TransDC and ReflDC got a bit smaller, but the oscillations on the launch power completely went away.  This is new behavior.
• At this point, we are thinking about other tests, so we leave the PZT driver connected to PZT2 (we'll want to revert this at the end of our tests today).  The squeezer manager guardian is in DOWN.