• Crystal Chiller:  added 350mL 
• Diode Chiller & both filters looked OK.

Note:  Was skipped last week.

Lilli S, Jeff K

We have processed all valid measurements for the observing period from 0611 (powered up to 37W) to 0828 (fixed SRC deturning), including high freq data. New GPR hdf5 files are generated, and the uncertainty budget is reestimated.

The actuation and sensing GPR fitting results are attached in the pdf files:
A_GPR_allmeas0327-0904_model0416.pdf
C_GPR_allmeas0328-0828_model0416.pdf

The scripts used to generate the GPR fittings are:
^trunk/Runs/O3/H1/Scripts/Uncertainty/process_allmeas_writeGPRHDF5_model20190416-A.py
^trunk/Runs/O3/H1/Scripts/Uncertainty/process_allmeas_writeGPRHDF5_meas20190328-20190828_withHF_model20190416-C.py

The resulting hdf5 files are:
^trunk/Runs/O3/H1/Results/Uncertainty/O3_H1_A_GPR_20190416_meas0327-0904.hdf5
^trunk/Runs/O3/H1/Results/Uncertainty/O3_H1_C_GPR_20190416_meas0328-0828_withHFafter0611_nofsQcorr_fmin30Hz_lengthscaleZp5.hdf5

The uncertainty plot was generated using this command line:
python3 RRNom.py --IFO=LHO --HDF5_A_MCMCresults=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/O3_H1_A_MCMC_20190404.hdf5 --HDF5_A_GPRresults=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/O3_H1_A_GPR_20190416_meas0327-0904.hdf5 --HDF5_C_MCMCresults=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/O3_H1_C_MCMC_20190404.hdf5 --HDF5_C_GPRresults=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/O3_H1_C_GPR_20190416_meas0328-0828_withHFafter0611_nofsQcorr_fmin30Hz_lengthscaleZp5.hdf5 --modelPath=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/params/ --modelFilename=modelparams_H1_20190416 --IFOmodel=modelPars --outDir=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/ --plot1SigmaUncs --sampleNumber=1000 --seed=1234 --version=ref --gpsTime=1247687618

NOTE: Please see the 3rd pdf file showing the GPR fitting with all available HF meas (three additional sets 0515, 0531, and 0610 compared to the results above). The 0610 (lasting from 0610 to 0618) data set (green dots with large systematics in the upper right corner) is obviously problematic because it includes the power up on 0611. Hence we decided to throw it away. We did not include 0515 and 0531 data sets either since they were taken before the power up and did not match the IFO configuration during 0611-0828 (in fact including them or not does not impact the final results).

H1 dropped out of Observing (15:09:13) due to the Squeezer not SQUEEZING (Manager & CLF_LR nodes were not in nominal states at first glance).  I'm used to Squeezer locking back up on its own, but this time it appeared at a standstill.  So did the following:

• Clicked LOCKED for CLF_LR node (it was in LOCKING), but this did nothing.
• Ran an INIT on CLF_LR node, but this didn't do anything.
• Ran an INIT on the MANAGER node & this did more, ran a DOWN command and took several other SQZ nodes out of nominal.  Then after about 45sec all nodes were NOMINAL & green. 
• 15:13:09 Went back to Observing

Attached is a screenshot of nodes and logs for the MANAGER & CLF_LR (doesn't capture everything, but most of the action).

TITLE: 09/25 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 114Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_CONF state: WINDY
    Wind: 8mph Gusts, 5mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.24 μm/s

Microseism is above the 50th percentile (it had been below for last few weeks).
QUICK SUMMARY:

H1's been Observing for 14.5hrs (locked for 14.75hrs) with a range hovering around 114-115mpc.

Whoops:  H1 just dropped out of Observing due to the Squeezer...and it's not coming back on its own.....more to come later.

TITLE: 09/25 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 114Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY: Quiet shift, nothing to report.

Locked for 12 hours, no issues to report.

TITLE: 09/25 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 113Mpc
OUTGOING OPERATOR: Ed
CURRENT ENVIRONMENT:
    SEI_CONF state: WINDY
    Wind: 19mph Gusts, 10mph 5min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.28 μm/s
QUICK SUMMARY: 6.5 hour lock, useism is elevated but the wind seems to have calmed down.

TITLE: 09/25 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 114Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY:
Winds became calmer. Shift was quiet. Nothing strangeer than previous logs to report. Handing off to TJ
LOG:

• I had to restart the wind speed ndscope on NUC22

Scattered light cause by high uSeism and wind is causing this "shelvin effect in DARM between 20 and 60 Hz. Range is suffering.

Jeff K sugests that this may be a good time for Gabriele's non-linear subtraction.

E. Hall, J. Kissel, E. Merilh

While clearing SDF DIFFs for the first observation ready segment after maintenance, we noticed that 4 channels on the h1asc model,
    H1:ASC-RPC_DHARD_P_GAIN
    H1:ASC-RPC_DHARD_Y_GAIN
    H1:ASC-RPC_CHARD_P_GAIN
    H1:ASC-RPC_CHARD_Y_GAIN
had diffs. These channels (loop gains) are a part of the radiation pressure compensation (RPC) system that Hang Yu designed (T1800077), to help compensate the arm angular degrees of freedom (CHARD and DHARD, Pitch and Yaw) for the change in response of these loops' at various 1064 nm arm power levels inside the arm cavities. Because the loop response depends on arm power, these gains are set based on the input power (as a proxy for arm power) by a function inside the ISC_LOCK guardian's ISC_library -- adjust_radiation_pressure_compensation (defined on line 305 of the current svn rev). Inside *that* function, there are human-set, hard-coded, input power thresholds set at 29.5, 33, 36.5, and 40 W, compared against the power in to the IMC (H1:IMC-PWR_IN_OUT16). As we know, (see e.g. LHO aLOG 51734), the input power is dropping slowly over time, and *today* for the first time, this power dropped below the 36.5 W at the time of measurement.

Thus, while cruising through the "run" portion of the INCREASE_POWER state -- just before MAXIMUM_POWER -- these gains were set based on the 33W configuration, instead of the 36.5W configuration we've running in throughout O3, i.e. some ~10% lower. This rightfully triggered the SDF warning in the h1asc comparison against its OBSERVE.snap later during NOMINAL_LOW_NOISE. However, it happened to occur in the middle of the automatic acquisition sequence when no one was otherwise touching the IFO, let alone this sophisticated, known to be carefully tuned, part of the ASC system.

Just because the PSL laser power has just so happened to drop the tiniest hair under exactly 36.5 W during the power up and this check, it didn't seem to us like a reason to change these gains. 

All that context to say that when we found this, we reverted the gains, but did it slowly and simultaneously:
    - increased the ramp time on these banks to 30 seconds
    - used a simple command line "caput" to push the gains up to their 36.5W values
    - reverted the ramp time
This went smoothly. 

The screen on which these filter banks live is a little tough to find. From the sitemap, go to ASC > Overview > "ASC ARM CAVITIES" for PITCH (in the top middle of the overview) > "HARD loop detail (rad press, blends)" button (in the middle left). This will pull up the attached screen.

All this aLOG is just in case it stumps operators again -- with the intent that one does not ACCEPT the values just because they're different, but REVERT them, slowly, with the above procedure.

Chandra R., Kyle R.

Today we successfully demonstrated that the energize-to-open/spring-to-close "SAFETY VALVE" located at the exhaust of the to-be-installed turbo pump on the Vertex Turbo Station would close with the absence of the QDP80's "PUMP RUNING" signal for both the "ROUGH" and "TURBO" selector switch positions.  This same test failed last week as, at that time, we had had the local scroll pump running with its intake valve open independently and simultaneously to the QDP80 pump that we were testing.  In the control panel's logic, if either or both baking pump (scroll and/or HEPTA -> QDP80 substituted for HEPTA here) is running and its intake valve is open, then the SAFETY VALVE can be opened and will remain open.  Thus, cycling the QDP80 last week didn't result in the SAFETY VALVE closing as the logic remained satisfied by the scroll's status. 

Also, I finished terminating the YBM TURBO STATION-to-HEPTA signal cable at the turbo end in the LVEA. 

23:28 Re-locking from EQ attempt -1 (my shift)

• Running INIT and DOWN did NOT re-align ITMs!
• Had to select ALIGN for both ITMs to get ALS flashing back
• Moved to PRMI to correct questionable alignment to deal with less than favorabel conditions

00:18 NLN

• 4 SDF diffs - They are with regards to radiation pressure- Jeff K and Evan H are investigating which action to take to get to Observing

00:36 H1 back to Observing

TITLE: 09/24 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Earthquake
OUTGOING OPERATOR: Niko
CURRENT ENVIRONMENT:
    SEI_CONF state: WINDY
    Wind: 19mph Gusts, 12mph 5min avg
    Primary useism: 0.15 μm/s
    Secondary useism: 0.31 μm/s
QUICK SUMMARY:

• Difficulties re-locking due to EQ.
• Safety audit
• 23:20 Kyle and/or Gerardo out to HAM5 area to take pictures
• Evan Hall doing dark noise measurements - IMC is OFFLINE
• 23:28 IMC is back ONLINE

TITLE: 09/24 Day Shift 15:00 – 23:00 (08:00-16:00), all times posted in UTC

STATE of H1: Tuesday Maintenance

INCOMING OPERATOR: Ed

SHIFT SUMMARY: Tuesday maintenance went until ~1:30pm. Initial alignment had some hiccups with a stalled ETMY, then we had the standard CARM_TO_TR lockloss, and then made it up to NLN for one minute before losing lock. Brought it up to TRANSITION_TO_ETMX before 6.1 EQ near Madagascar knocked us out.

LOG:

15:01 (08:01) Tyler to LVEA -- start crane maintenance

15:02 (08:02) Chris to LVEA -- set up forklifts

15:04 (08:04) Chandra to LVEA -- start cutting/drilling work

15:06 (08:06) Vanessa to LVEA

15:09 (08:09) Richard, Ken to EX -- PEM coil install prep

15:16 (08:16) Karen to EY

15:23 (08:23) Betsy to LVEA -- check laser barriers

15:34 (08:34) Jim, Gavin to end stations -- test fit BRS heater

15:38 (08:34) Cheryl to Optics Lab/PSL enclosure -- Adjust IO High Power Beam Dump hoses (phone/paging system on in PSL enclosure)

15:41 (08:41) Pest control spraying around OSB/LSB for ~1hr

15:41 (08:41) Betsy out of LVEA

15:42 (08:42) Hugh to LVEA -- extract iLIGO equipment

15:46 (08:46) Gerardo to LVEA -- help with drilling work

15:48 (08:48) Corey to LVEA -- help Chris with HAM6 work

Jeff. K, Niko, Rahul

After the scheduled Tuesday maintenance, during IFO lock acquisition attempt, we found that the ETMY Guardian got stalled and got into MISALIGNING STATE (as per NIKO, ETMY also tripped this morning). In order to understand, what's going on, we looked at the channel H1:GRD-SUS_ETMY_STATE_N along with the log file (screenshots attached). Initially, Guardian was at ALIGNED (100) state and while attempting (with several requests) to jump (via 109 state) to MISALIGNED state (110), it got stuck at MISALIGNING (109) state. This can be seen in the highlighted section of the log file. During this time the Align IFO (H1:GRD-ALIGN_IFO_STATE_N) went from SET_SUS_FOR_ALS_FPMI (5) to DOWN (0) state and then to PREP_XARM_IR (10). Finally, Guardian went into SAFE and then RESET state.

S. Karki, J. Kissel

Sudarshan is working on processing the high-frequency roaming PCALX line that has been sweeping through the DARM data above 1 kHz throughout the run. In order to facilitate that processing, and to pick up where Pep left off I report the times at which the sweep restarted during the run thus far, determined by a trend of the requested frequency channel, H1:CAL-PCALX_PCALOSC1_OSC_FREQ. We should consider a modification of the HIGH_FREQ_LINES guardian such that we have a less GUI way to gather this information in the frames.

For now, I give you the dates of the repeat to-date at H1 via ndscope trends and cursoring:

    2019-04-01 16:00 UTC Starts at 3001.3 Hz. Start of the run (spends a long time at 3001.3 Hz until bug fix, see aLOG below). 
    2019-04-15 21:27 UTC Re-start at 3001.3 Hz LHO aLOG 48505
    2019-04-19 23:22 UTC Re-start at 3001.3 Hz
    2019-04-24 23:51 UTC Re-start at 3001.3 Hz 
    2019-04-28 19:08 UTC Re-start at 3001.3 Hz
    2019-05-05 01:16 UTC Re-start at 3001.3 Hz
    2019-05-07 17:22 UTC Re-start at 4001.3 Hz More bug-fixes, no running nominally LHO aLOG 49064
    2019-05-15 22:40 UTC Re-start at 4001.3 Hz
    2019-05-31 06:54 UTC Re-start at 4001.3 Hz
    2019-06-10 17:07 UTC Re-start at 4001.3 Hz
    2019-06-18 13:34 UTC Re-start at 4001.3 Hz
    2019-06-27 22:08 UTC Re-start at 4001.3 Hz
    2019-07-06 03:20 UTC Re-start at 4001.3 Hz
    2019-07-15 13:10 UTC Re-start at 4001.3 Hz
    2019-07-25 17:16 UTC Re-start at 4001.3 Hz
    2019-08-03 11:55 UTC Re-start at 4001.3 Hz