J. Kissel, J. Driggers, S. Dwyer

I've already mentioned this a few months ago in LHO aLOG 27517, but I'll repeat these requests again, because we've thought a little bit more on how we'd like them implemented.

Thing we need to make SDF more maintainable:
1) Remove the distinction between SAFE and DOWN for SUS and SEI. Because SEI and SUS come up with the watchdog tripped, and the start up state for both systems guardian has the masterswitch off, there's no difference between these states. 
2) A rapid way to assess and change a group of front-end model's SDF reference files. I.e. we should be able to switch between OBSERVE and DOWN quickly instead of having the 4 screen, 15 clicks per front-end process it is now.
3) A easy, built in way to find out what channels of a given front-end are controlled by all guardians, such that we can un-monitor them.
4) A much easier way to reconcile non-initialized and not-found channels than the still-confusing SDF Save and SDF Restore screens.

Regarding 
(1) -- This has been completed. The SUS that *have* down.snaps all now have their safe.snaps soft-linked to their down.snaps.
(2) -- we now have a rapid way to assess at which reference file a front end is looking, because I've modified the overview. However, we still need a rapid way to change them all. Sheila and Jenne have programmed the enforcement of those front end models that *have* down.snaps to reference them in the DOWN state of the ISC_LOCK guardian, using shell scripts like
/opt/rtcds/userapps/release/isc/h1/guardian/
All_SDF_down.sh
All_SDF_observe.sh

These are rapid ways to change them all, once created, but because the SDF system identifies models by DCUID number instead of model name, it's arduous to create and maintain such a script.

(3) -- We still don't have this. Jamie and Jenne (and several others, I'm sure) have already discussed that parsing guardian code to find what channels it touches is intractable. 
As such, the new idea is that we have some script that 
     (a) takes two burt snapshots of an entire front-end model EPICs settings database
     (b) compares them -- any channel that has a change between those two snap files gets flagged for not-monitoring, all others get flagged for monitoring.
     (c) Those flags are absorbed into a *single* SDF file (with none on this unmaintainable several-file nonsense), and then
     (d) all monitored settings values are accepted.
We imagine this script to be run once a week, or so.

(4) -- We can now initialize a value by just flipping over to the "CHANS NOT INIT" menu, and accepting them. However, by default, they go into the list of channels *not* monitored. In order to initialize them as monitored, one has to remember to select *MON* (all) and then confirm. Until we get (3) addressed, the functionality should be that hitting *accept* for a non-initialized channel should automatically monitor it. For CHANS NOT FOUND We still must do the multi-screen, confusing save and reload.

This entry is posted as a request to the CDS software team to help us out. We don't think we can accomplish the solutions to (3) or (4), and we're mildly unhappy with the work-arounds we've done for (1) and (2). Thanks ahead of time.

The title says it all!

Operators: If PI modes bounce during your shift - such as Mode26 and Mode18 - tune phase based on overall slope of the top of the bounces. The bouncing is not real (it's a filter issue I'm working on), but the overall height of the bounces is, so damp that as usual. This should only happen when two modes close in frequency are rung up at the same time, so you might need to be changing both phases during this time. Note that this will likely occur within the first half hour of powering up from a cold(er) state. 

- - - - - 

Since editing filters to help with the crossing modes - Mode18 and Mode26 - we've seen PI signals bounce on the PI StripTool several times now. I think this occurs during crossing when both modes are rung up; in this case, there are two peaks of similar amplitude within a few tenths of a Hz apart, the amplitudes are enough to engage the PLL, and the PLL(s) get confused about which peak is 'theirs' and end up jumping back and forth between the two. At the same time, bandpass filters are being turned on/off by the guardian, based on the frequency readback of the PLL's; the bounciness is caused by alternatively right and wrong BP filters being turned on, so the amplitude of peak appears to change dramatically as its within or outside of the bandpass. 

Attached are spectra during bouncy time when both peaks are elevated and during normal damping time (ten minutes later) when only one peak is high. Also attached are trends of relevant channels during this time. Bounciness seen in first bump in RMSMON channels, no bounciness ten minutes later in second bump. The FREQ_MON channels show the first bump correlating with strong switchbacks in frequency (especially in Mode18), versus single frequency tracking ten minutes later.

Still working on a good solution to handle this. For now, Mode's 18 and 26 have only been staying so close and rung up for periods of ~10 min and only during colder lock starts (after that Mode18 rises in frequency away from Mode26); we only saw this once over the full weekend of locking. And if we damp based on overall slope of bouncing, it's been damping well. 

TITLE: 10/17 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Aquisition
INCOMING OPERATOR: Nutsinee
SHIFT SUMMARY: Lost lock a few times just after getting to NLN or just after powerup, not really sure why (once was me trying to adjust the ISS diffracted power too late in the game). Been locked for 4hours, commissioners hard at work.
LOG:

• 15:50 - Bubba, John to mids.
• 16:49 - Bubba, John back
• 17:30 - Jim W to EX to check on wind fence
• 20:52:52 - Kyle starting pump at EX (WP#6221)
• 21:08 - Kyle test complete.
• 21:19 - Kyle to CP3
• 21:30 - Kyle back.

J. Kissel for S. Karki

I've changed the > 1 kHz PCALX calibration line frequency, a.k.a. the "long duration sweep" line, from 2501.3 to 2001.3 Hz. Recall this started moving again on Oct 6th (see LHO aLOG 30269) I report the progress towards completing the sweep below. 

Frequency    Planned Amplitude        Planned Duration      Actual Amplitude    Start Time                 Stop Time                    Achieved Duration
(Hz)         (ct)                     (hh:mm)                   (ct)               (UTC)                    (UTC)                         (hh:mm)
---------------------------------------------------------------------------------------------------------------------------------------------------------
1001.3       35k                      02:00      
1501.3       35k                      02:00     
2001.3       35k                      02:00                   39322.0           Oct 17 2016 21:22:03 UTC
2501.3       35k                      05:00                   39322.0           Oct 12 2016 03:20:41 UTC    Oct 17 2016 21:22:03 UTC      days
3001.3       35k                      05:00                   39322.0           Oct 06 2016 18:39:26 UTC    Oct 12 2016 03:20:41 UTC      days
3501.3       35k                      05:00                   39322.0           Jul 06 2016 18:56:13 UTC    Oct 06 2016 18:39:26 UTC      months
4001.3       40k                      10:00
4301.3       40k                      10:00       
4501.3       40k                      10:00
4801.3       40k                      10:00  
5001.3       40k                      10:00

LN2 @ exhaust in 60 seconds after opening LLCV bypass valve 1/2 turn -> closed LLCV bypass valve. 

Next over-fill to be Wednesday, Oct. 19th.  

WP#6221

While locked in Low Noise, Kyle headed to EX to start and stop a pump in two 5 min intervals. The pump is connect to the North side of BSC5.

Times in UTC (GPS):

Start1 - 20:52:52 (1160772789)

Stop1 - 20:57:52 (1160773089)

Start2 - 21:02:52 (1160773389)

Stop2 - 21:07:52 (1160773689)

The purpose of this test is to determine if these pumps can be run without interferring with commissioners.

The Mid station chillers were turned off today and will likely remain off until March or so when the warmer weather returns.

Some recent locks have had steeply downward-trending ranges, which seem to be due to a steady increase in jitter coupling.

I hadn't seen anyone say it explicitly, so I decided to check the cause of one of these drops in range. I picked the lock on Oct 15, where the detector was in intent mode around 19:30, and the range had dropped 20 Mpc by 20:30. I ran Bruco at this later time (Bruco results page).

Above 200 Hz, all the coherences are with ISS PDB, IMC WFS, and the like, suggesting that jitter coupling is steadily increasing (and I think there's no feedforward because of issues with the DBB). Attached are the h(t) spectrum and the change in coherence with PDB relative to the start of the lock - the spectrum of PDB and the WFS don't change.

No restarts reported over these 4 days.

Weekly Xtal - graphs show some strange power fluctuations in Amp diode powers starting on or around the 10th. Also, this can be seen in the OSC_DB4_PWR graph as well.

Weekly Laser - Osc Box Humidity reached a high point at about the same time (10th) but seems to have started an upward trend sometime between the 8th and the 9th. PMC Trans power looks pretty erratic.  Included is a zoomed view of the Osc box humidity and the OSC Box Temp just for correlative purpose.

Weekly Env - nothing notable. 

Weekly Chiller - some marginal downward trends in headflow for heads 1-3. Head 4 is eother crazy stable and good OR this data is trash. ??

I went to EX this morning to check on the wind fence after Friday's wind storm. The fence is still there, intact, and hasn't accumulated any tumbleweeds, which is one of the concerns Robert had about a fence. However, a couple of the posts have been twisted, probably by the wind load and moisture, and all of the poured concrete footings have started creeping in the sand. I dont think there is any danger of the fence collapsing, yet, but I'll keep an eye on this.

Attached photos are: a picture of the total coverage from a month or two back (this hasn't changed), a picture showing the worst twisted post (this is new, I didn't notice this the last time I looked) and a picture of the gap in the sand around one of the footings (not new, but it's been getting bigger).

Laser Status:
SysStat is good
Front End Power is 34.67W (should be around 30 W)
Front End Watch is GREEN
HPO Watch is GREEN
PMC:
It has been locked 0.0 days, 0.0 hr 48.0 minutes (should be days/weeks)
Reflected power is 33.57Watts and PowerSum = 126.8Watts.

FSS:
It has been locked for 0.0 days 0.0 hr and 42.0 min (should be days/weeks)
TPD[V] = 3.225V (min 0.9V)

ISS:
The diffracted power is around 6.695% (should be 5-9%)
Last saturation event was 0.0 days 0.0 hours and 51.0 minutes ago (should be days/weeks)

Possible Issues:
PMC reflected power is high
ISS diffracted power is High (This seems to pop up after power increases)

SEI - Testing out some new configurations to get ready for O2.

SUS - No report

CDS - Running (go catch it. Ha.)

PSL/TCS - All good

Vac - Kyle wants to do test with pumps at end stations with locked IFO.

Fac - RO system issues, but it is back and running.

Maintenance

CDS - FRS's to address, cable pulling, power up RGAs at ends.

PCal - Travis to do some work.

I wanted to find out how much contrast defect light we have in DARM at the moment. It seems to be about 2.0(5) mA at the moment. Since we run with 20 mA of total photocurrent, this implies a homodyne angle that is mistuned by about 6° away from the nominal value of 90°. I did not check how stable it is over the course of several hours.

To measure the contrast defect, I watched the height of 332 Hz pcal line in DARM while varying the dc offset.

J. Kissel, D. MacLeod

Duncan had noticed that Omicron triggers for the H1 PCAL Y RX PD (H1:CAL-PCALY_RX_PD_OUT_DQ) had failed on Oct 13 02:51 UTC (Oct 12 18:51 PDT) because it was receiving too many triggers. 

Worried that it might have been a result of the recent changes in calibration line amplitudes (LHO aLOG 30476) or the restoration of the 1083.7 kHz line (LHO aLOG 30499), I've trended the output of the optical follower servo, making sure that it has not saturated, and/or is not constantly glitching.

Attached is a 3 day and 30 day trend.

There is indeed a feature in the trend at Oct 13 02:51 UTC, but it is uncorrelated in time with the two changes mentioned above. Indeed, the longer trend shows that the OFS has been glitching semi-regularly for at least 30 days. I'll have Detchar investigate whether any of these correspond with heightened period of glitching in DARM, but as of yet, I'm not sure we can say that this glitching in a problem.