For fun I've written a script to calculate the site windchill now the wind has kicked up. It uses the NOAA formula. The script is called windchill

david.barker@zotws2: windchill
EX temp 20.1(degF) wind 09.0(mph) windchill 09.6(degF)
MX temp 19.4(degF) wind 09.0(mph) windchill 08.8(degF)
CS temp 21.2(degF) wind 08.0(mph) windchill 11.7(degF)
MY temp 19.3(degF) wind 08.0(mph) windchill 09.4(degF)
EY temp 17.8(degF) wind 08.0(mph) windchill 07.6(degF)
 
wind chill average over site 9.4 degF
 
 

   At 19:06 (11:06) took advantage of LLO being down to dropped out of Observing to run the A2L script. Back in Observing at 19:18. 

   After relocking this morning had an SDF diff for IMC-REFL_SERVO_IN1GAIN. 

TITLE: 12/16 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 75.8911Mpc
INCOMING OPERATOR: Jeff
SHIFT SUMMARY:  Smooth sailing for the first 6 hours of shift.  Then a mysterious lockloss, followed by a quick IA, and back to Observing.
LOG:

See previous aLogs for the play-by-play.

15:59 Lockloss.  Cause unknown.  I'll let Jeff investigate and relock.
 

After a quick and painless IA, we are back to Observing.  I had to accept a few more SDF diffs for ECAT systems. Seems oddly similar to Corey's mysterious lockloss followed by ECAT diffs in aLog 32591.  Seen screenshots of accepted SDF diffs.

Cause is yet unknown.  Nothing seemed to ring up on any of the normal FOMs.  Just got a sudden Verbal Alarms notification that the HAM6 ISI WD had tripped.

Locked for ~22.5 hours.  No issues.

TITLE: 12/16 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 69.5545Mpc
OUTGOING OPERATOR: Patrick
CURRENT ENVIRONMENT:
    Wind: 10mph Gusts, 8mph 5min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.27 μm/s
QUICK SUMMARY:  Locked in Observing for 19+ hours.  No issues as of yet.
 

TITLE: 12/16 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 73.1215Mpc
INCOMING OPERATOR: Travis
SHIFT SUMMARY: No changes to note since mid shift summary. 
LOG:
01:10 UTC Brief notification that HWSX code stopped running.
01:40 UTC Out of observing to run a2l.
01:48 UTC a2l done. No errors reported. Back to observing.
02:04 UTC EY started constantly saturating.
02:44 UTC Out of observing. Changed gain for H1:SUS-ETMY_L2_DAMP_MODE10 from 100 to 0.02. Turned off FM1 and turned on FM9 and FM10 (Settings at Dec 15 2016 08:46:51 UTC from conlog test machine). 4.7kHz mode has come down and saturations have stopped.
02:59 UTC Accepted SDF differences. Back to observing.
03:17 - 03:27 UTC Stepped out of control room.
03:48 UTC Changed phase to damp PI mode 26.

Out of observing twice. Once to run a2l and once to damp 4.7kHz violin mode. PI mode 26 started increasing again. This time changing the phase damped it.

Verbal alarms started alerting that EY was saturating at 02:04 UTC. It has continued since. Attached is a plot of the L3 ESD drive signals for the last 2 hours. They have been growing. Is this the violin mode at 4.7 kHz that Keita and Cheryl were investigating?

TITLE: 12/16 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 71.2515Mpc
OUTGOING OPERATOR: Cheryl
CURRENT ENVIRONMENT:
    Wind: 0mph Gusts, 0mph 5min avg
    Primary useism: 0.08 μm/s
    Secondary useism: 0.20 μm/s 
QUICK SUMMARY:

Locked for over 11 hours.

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

Activities:

• earthquake: event time: 22:23:29UTC: alog 32611
• earthquake: event time 22:53:03UTC: no alog, 0.05um/s on DMT
• EY gltich at 23:23:09 and 23:23:17UTC
• range drop 23:24UTC, L1 lost lock
• DUST ALARM: 23:25:11UTC: PSL: 0.3um, 220PCF, cleared: 23:36:11UTC

Looking at a few tasks on the calibration to-do list, I ended up down the rabbit hole. Sadly, it's getting late and will have to return to this tomorrow.

Investigations:

1) Working on fixing the PCAL --> CAL-CS_DELTAL_EXTERNAL calibration (see LHO alog 31994). Kiwamu's original script computed a transfer function accounting for time delays caused by the DAQ and the CAL-CS whitening filter. However, this is already taken into account in the clock cycles delay in the CAL-CS model when adding the sensing and actuation paths. Since CAL-CS corrects for the phase delay caused by AA/AI filtering--analog and digital--using the delayed actuation path, then what one really wants is to correct CAL-CS for the magnitude changes of the AA/AI filtering and any CAL-CS whitening on this channel while also correcting the PCAL_RX_PD channel for the effect of AA and that we also have not applied a filter with two poles at 1 Hz (for the free-mass response):

DELTAL_EXT   W * [Derr/C_foton + A*Dctrl*delay]
---------- = ----------------------------------
PCAL_RX_PD         m * f^2 * AA_a * AA_d

 m     DELTAL_EXT [C_real/C_foton] / [W * abs(AA_a * AA_d * uncompensatedOMCpoles)]
--- = ------------------------------------------------------------------------------
 m                PCAL_RX_PD / [f^2 * AA_a * AA_d]

Note that the correction factors applied in the numerator of the final equation are really only to be applied to the sensing side. However, the corrections are only at high frequency (low-frequency corrections are simply unity), so the numerator term is dominated by the sensing function.

Thus the calibration to be applied is thus:

   [C_real/C_foton] * [f^2 * AA_a * AA_d]
----------------------------------------------
[W * abs(AA_a * AA_d * uncompensatedOMCpoles)]

Unfortunately, this results in a large deviation in phase at higher frequencies (~60 degrees at 1 kHz, see attached figure) while recent measurements using an incorrect calibration filter do not suffer from this large phase deviation. The phase deviation is due to application of the analog and digital AA on the Pcal. Why?

2) I constructed an O2 version of the front-end calibration time delay diagrams based on the model (see attached), but when I look at the GDS correction factors to be applied to the CAL-CS channels, I do not find matching delays. In addition, the values obtained to not mesh with the recent work done at LLO (see LLO alog 29899). This will have to be investigated further tomorrow also.