Sheila, Jenne, Daniel

1. The beam jitter seen by the IMC WFS became worse below 100 Hz as soon as the HPO was turned on, and has stayed similar since. The jitter at 100 Hz isn't much worse than it used to be. 
2. Today Jenne and I redid a few white noise injections for MICH, SRCL, and jitter from the IMC PZT. The aux loop noise seems to be low enough that it is not our main problem.
3. We don't think that the main coupling of HPO jitter noise to DARM is through lock point errors on the refl diode.

More about the jitter measurements:

Jenne, Daniel and I made two types of jitter measurements this afternoon, first exciting the IMC PZT and making a projection using IMC WFS DC, then exciting IM4 and making projections using REFL WFS.  The jitter measurements in the attached noise budget are based on the IMC PZT measurements, the IM4 ones are not included, because we don't believe that the REFL WFS noise floor is jitter, so these measurements were more like upper limits. The HPO jitter is in a gouy phase more similar to the one we excited using IM4 we believe, while the PZT excitations are in a gouy phase more simliar to the peaks from structures on the PSL table. 

For both types of measurements, we wanted to see if it is plausible that the coupling mechanism to DARM is through the REFL diode.  To do this we measured transfer functions to both the REFL control signal and to DARM.  When we are exciting the IMC PZT, we cause sensor noise in the IMC loop which gets supressed by the CARM loop, so measuring the coupling to DARM CONTROL and multiplying by the previously measured REFL control to DARM coupling causes us to overestimate the coupling to DARM.  For the IM4 excitation, we injected a line at 150 Hz, because we had to make a rather large injection in DARM to see it in REFL control.  Using the REFL control signal to estimate the coupling to DARM we underestimate the coupling by about a factor of 5.  This means that at least in the gouy phase that we excite with IM4 (which we think is similiar to the gouy phase where the broadband HPO jitter shows up), the main coupling of jitter noise to DARM is not through lock point errors on the REFL diode. 

TITLE: 10/17 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Lock Aquisition
INCOMING OPERATOR: Patrick
SHIFT SUMMARY: We had trouble locking DRMI. ISI BS ST2 CPs looked noisy but they weren't the cause of the problem. Noise eater acted up once or twice. Jenne and Sheila working on the alignment to reduce some excess noise.

The water was at 5.6 cm when I went out. I added ~500 ml of water and the level indicator went all the way to the top. I noticed the water had a hard time making it's way down the filter and indeed the filter was puffed up from the bottom -- just like what Jason has seen before (alog30351). I took out the filter to let the indicator fall to it's true reading and added ~1250mL of water (total -- without filter in place). This brought the indicator from 5.6cm to 8.9cm. I put the filter back in and closed the cover very carefully so it doesn't push the metal filter on the side.

Daniel, Evan, Keita, Kiwamu,

We checked the level of frequency noise at various out-of-loop equivalent sensors and then projected them to DARM to see if they make sense at all.

If we accept the projected noises, it is unlikely that frequency noise is the limiting noise source in the 200 - 1 kHz band.

[Various out-of-loop sensors for freq. noise]

We wanted to know the out-of-loop stability of frequency noise. We measured frequency noise transfer functions for the following sensors relative to REFL9I.

• REFL 45 I
• POP 9 I
• POP 45 I

To do this, we excited one of the inputs of the summing node board with broad band noise from 100 Hz to 4 kHz. The relative transfer functions between REFL 9I and these sensors were found to be almost flat as expected. See the upper left panel of the third attachment for the flatness. In the reset of this report, the following scaler values will be used and we do not use the actual measured transfer functions.

• (REFL45 I) / (REFL9 I) =  0.004 cnts/cnts
• (POP 9 I) / (REFL 9 I) =  32.2 cnts/cnts
• (POP 45 I) / (REFL 9 I) = 38 cnts/cnts

We then converted the sensor spectra (taken when the interferometer was in low-noise) by using the above values to (uncalibrated) frequency noise as seen in REFL9I. The below shows (uncalibrated) frequency noise estimated by these sensors.

Good agreement is seen above 3 kHz where all the sensors see the loop-gain-limited frequency noise. For POPs, they are found to be limited by shot noise as expected at frequencies below 2 kHz or so, except that POP 9 sees some extra frequency noise in the jitter band (200 Hz- 1kHz). Since the coherence is not low below 50 Hz, we should not believe the spectra below 50 Hz or so.

[Projection to DARM]

The below plot shows projections of frequency noises to DARM using the different sensors. The coupling transfer function of REFL9I -> DARM was once measured by exciting the same excitation point as the above measurement. We confirmed that the coupling grows proportionally to frequency (29893). Also, see the upper middle panel in the third attachment for the coupling transfer function. For noise projection, I have used a simplified transfer function of 1e-5 x ( f /700Hz) [DARM meters / REFL9I counts]. Since all the out-of-loop sensors are already calibrated to equivalent of REFL 9I digital counts, all of them are just propagated to DARM by multiplying the same coupling transfer functions.

Again, the projection below 50 Hz is not trustable because of low coherence in the measurements. High frequency excess in DARM above 4 kHz seems to explainable by the frequency noise -- all the projections more or less agree with DARM. In the jitter band, 200 Hz - 1 kHz, the closest projection was given by POP 9I which showed some acoustic type structure. Although POP9I is still not high enough to entirely explain what we see in DARM. Moreover, the peak structure seen in POP 9I do not quite match the ones in DARM. Probably those structures in POP 9I are likely some kind of sensing noise.

In any case, if we believe this plot, frequency noise does not seem to be limiting the current DARM in the 200 Hz - 1 kHz band.

WP6251 RCG3.2 upgrade.

In preparation for the RCG3.2 upgrade I have compiled all 106 models against it. I did not install the new code, this was just a check that all models compile against the new system. I took the opportunity to rebuild the H1.ipc file (current has 5544 lines, new has 5096 lines).

Procedure was:

create new build area /opt/rtcds/lho/h1/rtbuild-3.2

save H1.ipc to archive/H1.ipc.17oct2016 and empty H1.ipc

do first round of compiles (make -i World) to fully populate H1.ipc (many compiles abort on ipc error)

do second round of compiles to actually compile each model (took 49 minutes)

check that all error.log files are empty (indeed they are)

save the new H1.ipc into archive/H1.ipc.rcg3_2

restore original H1.ipc file (in case any models are restarted tonight)

J. Kissel

After taking a look at the SDF overview screen, I noted a plethora of yellow lights indicative of many channels not found or not initialized because of front-end model changes. As such, I've initialized and monitored all channels not initialized, and I've updated all (currently in use; see attachment) reference files to rid them of channels that no longer exist. The affected sub-systems are:
PEM EX, PEM EY
PSL ISS, and
CS ECAT1PLC1

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.

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.