Summary:  H1 was out from 7:58 - 9:45.  Not totally clear when to Intervene due to repeating locklosses.

A minute before my shift started H1 lost lock.  I immediately got set up to lock H1 with our new operator protocol (T1900725) of allowing H1 to lock as much as it can WITHOUT operator intervention.  Still think there are some states/steps where we might want to change intervention thresholds. 

To Intervene, Or Not Intervene

For example, there were several locklosses in a row which happened in odd states (several in a row while waiting for DRMI to acquire & one during FIND_IR)...I was fearing I was in a loop of locklosses at this point!  And so, to prevent waisting time, on the 9th (!) lock, I threatened to run an alignment by opening up all the nodes needed to do that, and (wouldn't ya know it!) H1 then locked all the way up!!  Ha!  

As for actual intervention, it only happened on the very first lock (tweaking ETMy for y-arm green locking) & after that, I sat on my hands and noted where it dropped out.

H1:LSC-PRCLFF FM4 is OFF

Looks like Guardian is taking us to the standard state of keeping PRCLFF's FM4 OFF, but with tests last night, there was an SDF diff for wanting it ON.  I went back to Accepting FM4 OFF.  Attached is a screenshot of the SDF diffs I observed and then ACCEPTED to get us back to OBSERVING.

Notes On Operator Intervention & Locking:

• 7:58 lockloss! (After 19.5hr lock)
  • LOCK#1 7:59 -8:09
    • Green arms:  Y-arm not locking. 
      • After 5-min Ops Wait:  ETMy Pit moved +0.3 clicks & immediately locks up.
    • DRMI:  LOCKLOSS went down at ACQUIRE_DRMI_1F  :-/
  • LOCK#2 8:11 - 8:27
    • Lockloss #1 at ENGAGE_ASC_FOR_FULL_IFO 
  • LOCK#3 8:28 - 8:41
    • Lockloss #2 at ENGAGE_ASC_FOR_FULL_IFO 
    LOCK#4 8:42 - 8:48
    • DRMI:  LOCKLOSS at ACQUIRE_DRMI_1F  
  • LOCK#5 8:49-8:52
    • LOCKLOSS at FIND_IR
  • LOCK#6 8:53-8:58
    • DRMI:  LOCKLOSS at ACQUIRE_DRMI_1F
  • LOCK#7 8:59-9:05
    • DRMI:  LOCKLOSS at ACQUIRE_DRMI_1F
  • LOCK#8 9:06-9:10
    • DRMI: LOCKLOSS at ACQUIRE_DRMI_1F
  • LOCK#9 9:11 -  9:42
    • During this DRMI acquisition, I decided to opt out of the new Operator Intervention procedure & go for an alignment.  I began opening up all the ALIGN windows to get ready....and wouldn't you know it, H1 FINALLY makes it past the ASC steps and eventually to...
    • Nominal Low Noise!

TITLE: 11/09 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Corey
SHIFT SUMMARY: locked all shift until 7:58UTC, range was stable, Corey is relocking
LOG:

• 00:31:38 - out of Observe for Jenne's filter change
• 00:32:04 - H1 back in observe
• 00:48:49 - out of Observe for Jenne's filter change
• 00:49:05 - H1 back in observe
• 01:03:32 - H1 back in observe, without any note on Verbal Alarms that H1 was out of observe
• 02:03:10 - H1 out of Observe for violin mode damping
• 02:03:57 - H1 back in Observe
• 03:26:47 - H1 out of Observe for violin mode damping
• 03:30:49 - H1 back in Observe
• 07:58:06 - lockloss, very fast, no warning

TITLE: 11/09 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Cheryl
CURRENT ENVIRONMENT:
    SEI_CONF state: WINDY
    Wind: 5mph Gusts, 3mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.32 μm/s
QUICK SUMMARY:

We literally just lost lock 2min before my shift!  So working on bringing H1 back (nothing looks crazy btw).

H1 remains locked, range is 115Mpc, two short exits from Observe for violin mode damping.

[Craig, Jenne]

On Wednesday I took measurements for iterative update filters for the LSC feedforward.  SRCL and MICH don't really look like their ideal update filters are very far from unity at frequecies we care about, so I'm not going to fit and implement them today.  However PRCL has some updating that it could use.  Note for the future, slightly stronger excitations may help to get better, easier-to-fit data. 

In the attached figure, the blue points are the measured transfer function to fit, which will become the update filter in series with the current feedforward filter.  Note that in this plot, data points that have poor coherence are set to 1, so the low and high frequency portions of this plot look funny.  The fit is only considering data points with high coherence, so those points are ignored.  The green trace is the fitted filter that will be put into Foton.  If our original FF filters were perfect, these update filters would be unity everywhere.  You can see that my fit doesn't match the measurement very well below ~15 Hz, but I'm going to accept that in hopes that we make improvements at higher frequencies where we're actually detecting GWs - hopefully this will be easier to fit with better data next time we take these 'update' measurements.

At around 00:32 (+/- 1 min) on 9 Nov 2019 UTC I turned on this new update filter.  We were out of observe for a few tens of seconds during the transition, then I accepted the SDF diff (FM4 in LSC-PRCLFF) and put us back in Observe.  Seems to have perhaps improved the range a bit.

At around 00:49 I turned the new filter back off.  Again I accepted the SDF diff, and we were back in Observe within a few tens of seconds. 

At around 1:03 I turned the new filter back on, accepted SDF, and we were back in Observe within a few tens of seconds.  I think we'll leave it on for the weekend to see how it goes longer term.

Craig will post a comment with some plots showing that perhaps we're making a bit of an improvement. 

The pressure gauge on HAM6 was replaced due to noisy read back (spiked above high voltage pressure set point more than once causing fast shutter to close) and then gauge failure during troubleshooting (pirani or filament gone bad? - gauge sent back to manufacturer via RMA).

We replaced the entire gauge but the readback is still noisy. Suggest we leave the HV interlock on the new ion pump controller at HAM6 until we can trend gauge over longer period of time to confirm it won't spike above 1e-5 Torr. Not sure what is causing the spikes.

Four pieces of equipment were brought on site today in preparation for wind fence construction activity next Monday 11 Nov 2019: cart, backhoe, fork truck and crane truck. Those that were brought on a flatbed were offloaded outside the gate and slowly driven past the corner station to be parked for now near the fire water tank. Photos attached. Additionally, grout and rebar vendors visited for walkdowns and pre-activity discussions.

TITLE: 11/09 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 108Mpc
OUTGOING OPERATOR: Ed
CURRENT ENVIRONMENT:
    SEI_CONF state: WINDY
    Wind: 2mph Gusts, 1mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.40 μm/s
QUICK SUMMARY:  Locked in Observe, plans for some changes to filters, related to H1's wandering drop in range

Ed, Camilla

TITLE: 11/08 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 107Mpc
INCOMING OPERATOR: Cheryl
SHIFT SUMMARY:

• Experimenting with squeezer gain and phase settings because of range drop. aLog
• Heavy equipment for the wind fence was staged by the fire tank
• Jeff Jones brought the vendors for said wind fence to the end stations

LOG:

Ed, Camilla

22:54 for about 15 seconds

Following Sheila's SQZ test ALOG

TEST 2

H1:ISC-RF_C_SQZAOM200M_OUTPUTMON correlates with range drops even on sub-second time scales.

Attached are plots for GPS

1256913467 (same drop as in alog 52979)
1257226318 (today)
1257229296 (today)

Note that the sharp drop in 1256913467 corresponds down to the second with the range drop in alog 52979.

Ed, Camilla

16:47UTC The large equpiment bearing truck that is currently parked on the road beyond the gate will unload a backhoe/frontloader and slowly drive it to the water tower area. I'll note more accurate times as this takes place for DetChar.

Continuing from conclusion of aLOG.

I have sought to import SUS models into foton using the foton.py library linked in the last alog, which was written by Lee McCuller.

I have produced a script which takes the TST transfer function to update the foton filters for Pcal via a python script, avoiding the need to 'quack' the filter with matlab scripts.

The quack scripts have a lot of error handling so that filters are compatible with foton. Here I directly input the filters with foton, with all its built in error handling.

I produce a filter that is arguably more accurate than what matlab is putting into foton... since I handle the DC gain with more precision.

I compare how matlab and my script fare against the original intended TF, by comparing the TFs that foton sees the inputs to be. You will note that the TF's have a bit of an error in magnitude at high frequency, I suspect that is due to the fact that the 1/f^2 filter (titled '1:1') is built within foton, and there is some difference from the system modelled in matlab.

Caveats of this process:
Until there is an update to the python control library, there is no clean way of recovering to true DC gain of a ZPK TF, without importing the SS model generated by matlab. One also needs to import the ZPK model generated by matlab, because the python control library doesn't make the same changes to the SS to produce the ZPK, and I get a bit of a magnitude error at around 2 Hz.
Hence, I end up importing both the SS and ZPK models that matlab spits out, which is not great.

If you want to play with this, be concious that you must change paths to things.

I will be putting this in the relevant places in the CalSVN, and writing up some more robust documentation going forward.

Nutsinee, Daniel, Sheila

We have some requests for the operators to try some tests next time the range drops to around 110Mpc.  We'd ask you to try each of these tests, which you can do by copying and pasting the lines below into a terminal.  Waiting 10-15 minutes between each one would make sure we what happens.  If any of these appear to fix the problem (or the range goes back to normal on its own) obviously you can stop the test. 

Keita has OK'd staying in observe, so before starting this go into SDF and unmonitor these channels, and remonitor them when you are done.   If there is a problem with this and we are out of observing momentarily that's sort of OK, although we would like to avoid it if possible.  Also, please alog carefully and include times when you do this. Thank you.

1) increase SHG gain by 20dB

• caput H1:SQZ-SHG_SERVO_IN1GAIN 27
• Wait 5-10 minutes. 
• caput H1:SQZ-SHG_SERVO_IN1GAIN 7

2)H1:SQZ-CLF_REFL_RF6_PHASE_PHASEDEG move up  and down by 10 degrees, wait 10-15 minutes between moves.  

• caput H1:SQZ-CLF_REFL_RF6_PHASE_PHASEDEG 120
• wait 5-10 minutes
• caput H1:SQZ-CLF_REFL_RF6_PHASE_PHASEDEG 100
• wait 5-10 minutes
• caput H1:SQZ-CLF_REFL_RF6_PHASE_PHASEDEG 110

3)lower CLF ISS gain

• caput H1:SQZ-CLF_ISS_GAIN 10
• wait 5-10 minutes
• caput H1:SQZ-CLF_ISS_GAIN 16