Tonight we again spent some time on ASC, which was causing us some problems staying locked: SRC1, PRC2 (REFL WFFS), and CHARD. 

• SRC1- changing the RF9 modulation depth definitely does change the sensing for SRM.  I've moved the modulation depth reduction to happen before we switch from the dither loop to AS36.  I also retuned the matrix we use to combine segments for AS 36AI again tonight.  (Last time this was done was in alog 30759) I've changed the seg 3 element for pitch to -0.487, and for yaw it is -0.205.  This seems to be working. Earlier tonight we had a lockloss that might have been due to the modulation depth change, or could have been something else like SRM ASC (or REFL WFS controlling PR3). 
• PRC2- we measured both the pitch and yaw loops on POP X and after transitioning to RELF WFS, and found that both gains were too low once we transitioned.  Yaw was 12dB too low, while pitch was only about 3dB too low.  For this lock I had added the extra gains in the filter modules, but I edited the guardian so that they should go into the input matrix next lock. Screenshots of the measurements taken after the gain adjustment are attached. Once the gains were increased the sideband powers no longer fluctuate as much when we are controlling PR3 using REFL WFS. 
• After about an hour, we had another example of the 0.5 Hz instability ringing up, which seemed to be stopped by turning off the cut off on CHARD P and increasing the gain from -0.14 to -0.2.  I took a long measurement of CHARD P (with the higher gain and cut off off), which broke the lock as it finished (3rd screenshot).  Based on this I modified Stefan's 25W filter to avoid having a ugf at around 0.7 Hz by moving the first set of poles down from 0.75 to 0.7Hz (screenshot attached of filter change)

This all seemed fine, but we just lost lock after trying to transition to the REFL WFS again.  For tonight we will leave the gaurdian set up to skip REFL WFS again. 

Other things: 
This afternoon we had a long stretch of down time mostly spent doing a couple of inital alingments.  One thing that didn't go well was locking the XARM in IR, which has been a long standing problem.  After Corey got it to lock, I measured the loop and had a look at the filters.  I made a new filter called servo and one called boost that I think should be able to replace all the filters that the guardian currently uses (boost should be triggered as the boosts currently are).  Next time we do an inital alingment and there is a commissioner around, please try these out, they might make life easier. There is a template to measure the loop in /ligo/home/sheila.dwyer/LSC/XARM_IR

I've discovered HAM2 ISO_Z and ISO_RZ are well correlated to alignment changes in MC1 pitch and yaw, MC3 yaw, and anticorrelated with PR3 OSEM yaw.

It seems odd that the nm sized ISI ISO signals are showing up in the optic alignments, however this is what I find, and the optic OSEM alignment changes are not small.

I also looked at optical lever signals, and see that HAM2 and PR3 optical levers don't corellate to ISO or OSEM signals long-term.  HAM2 oplev does occasionally see a large ISI excursion, and correlates with multiple ISO DOFs.

Plot 1: MC1, MC3, and HAM2 ISI ISO_Z and ISO_RZ, 400 days

• MC1 pitch, alignemt range of 80urad
• MC1 yaw, alignment range of 30urad
• MC3 ptich, increasing
• MC3 yaw, alignment range of 15urad
• HAM2 ISI ISO_Z
• HAM2 ISI ISO_RZ

Plot 2: PR3 OSEM yaw, oplev yaw, HAM2 oplev yaw, HAM2 ISI ISO_RZ, 400 days

• PR3 OSEM yaw
• PR3 oplev
• PR3 OSEM yaw, alignment range of 85urad
• PR3 oplev yaw is essentially flat (ignoring the large jump/recovery)
• HAM2 oplev long term
• HAM2 ISO_RZ, and I conceed the changes in this signal seem very small at a couple hundred nrad

Plots 3 and 4: HAM2 oplev pitch, HAM2 ISO_RZ, ISO_X, 400 days

• HAM2 oplev pitch does see large ISI excursions, and correlate to ISO_RZ and ISO_X, and not shown, ISO_Z and ISO_Y

Summary:

• HAM2 ISO_Z and ISO_RZ are showing up in HAM2 optic OSEM pitch and yaw signals
• MC1, MC3, and PR3 OSEMs see the ISO changes (likely other HAM2 optics, but I didn't look tonight)
• HAM2 and PR3 oplevs don't track the changes seen in the ISO_Z/RZ or optic OSEMs
• HAM2 oplev in it's current form is not going to provide a diagnostic for the IO chain as I had hoped

The attached plots show the frequency noise seen by the reference cavity (green), the IMC (red), the REFL port (blue)  and the POP port (brown). The first plot also shows the estimated in-loop suppressed noise in a lighter color as well.

The second plot shows uncalibrated traces but with a 30 kHz bandwidth. The peaks at ~7250 Hz and at ~13.6 kHz are already present in the IMC spectra when the interferometer is unlocked, and, therefore, are not introduced by the REFL servo. The I' channels are the DAQ sensor channels closest to true in-phase signals.

Although Jeff and I reduced the appearance of triple bounce and roll modes in DARM by adding notches to the top mass damping for the HSTS (30970), there are still a few modes that show up. 

The largest in our last lock was at 28.2 Hz, which belongs to PR3 according to the resonances wiki and Jeff's measurement in 30646.  We had no notches for the HSTSs so I have added notches 1 Hz wide centered around 28.2Hz and 44.2 Hz for PR3 and SR3.  

The other thing which is large in our spectrum from last night is the remaining 40.9375 Hz mode from PR2.  I am not sure why the PR2 mode shows up in DARM larger than the others.  I looked at spectra of the osems to see if there is more noise on the PR2 osems.  The attached screenshot shows that the top mass osems for PR2 aren't any more noisy than PRM, but there is extra noise in the lower stage osems for PR2, and a large comb.  This might be noise in the readback only.  

I made the notches in the damping loops 20dB deeper for PR2, we will see if this helps in the next lock. 

Last updated Nov 11, 2016

https://lhocds.ligo-wa.caltech.edu/wiki/Violin_Mode_Table_v2

TITLE: 11/17 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Corey
SHIFT SUMMARY: 16hr lock ended a few hours before the end of my shift. Things seemed to be misaligned after and it took me a bit, and with much help, to get it through an initial alignment. Handling off to Corey who may need to do another IA.
LOG:

• 16:51 Joe headed out to start beamtube enclosure sealing. We currently in Low Noise, it would be interesting to see if we can see his work.
• 15:54 Keita starting ASC work, out of Observing.
• 17:24 HAM1 HEPI tripped, reisolated and we kept full LN lock. H1:ASC-AS90_OVER_POP90_MON bumped up a bit on the FOM.
• 17:36 Richard to CS roof to replace anemometers
• 18:00 Richard down
• 18:03 Joe back
• 19:54 Richard headed to outbuildings to replace anemometers
• 21:08 Joe heading back out to do more beam tube enclosure sealing.
• 21:33 Kingsoft on site
• 21:47 Lockloss. ASC control signals started picking up, couldnt narrow it down more yet.
• 22:08 Joe back and done.

TITLE: 11/16 EVE Shift: 0:00-08:00 UTC (16:00-0:00 PST), all times posted in UTC

STATE of H1: Lock Acquisition
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    Wind:  under 5mph
    Primary useism:  Not changing much over last 24hrs
    Secondary useism:  --
QUICK SUMMARY:

TJ is still here and he & Jenne are addressing issue with Initial Alignment (current issue is with SRC Align).  This is all after a 16hr lock.  

Next up:  IM alignment tweak from Cheryl (& then tweak Initial Alignment to address that tweak....so skip Green Arms/ALS & start with INPUT_ALIGN).

Then we'll go back to locking.

Significant exhaust thermal couple response in 19 seconds after changing the as found control valve setting of 16% open to 50% open.  


Chandra's adjustment to 16% following yesterday's LN2 delivery looks to be an ideal value for the current LN2 column height in the storage tank.

After I left them off for camera glitch investigation (alog31456). Both IX and IY. ETM hws code also restored after hwsmsr restarted. I don't remember having to restart ETMY by hand. Maybe I did but I just forgot that I did.... Or it could be a glitch in the Matrix. I'll keep this in mind for next time.

After a week's worth of struggle with the h1oaf computer, and alignment loop instabilities, we've been blessed with another 16 hour lock stretch. As such, we've got sufficient amount of data for the roaming calibration line to move it from 4001.3 Hz to 4301.3 Hz. 

Though the line has been at 4001.3 Hz for 5 days, I recommend only using data from the two long lock stretches in that time from Nov 12 2016 05:00:00 UTC to Nov 12 2016 21:00:00 UTC and Nov 16 2016 06:00:00 UTC to Nov 16 2016 22:00:00 UTC. However, note that the mean laser power is different from the one lock stretch to another -- 29.5 [W] for the Nov 12 stretch, and 31.1 [W] for the Nov 16th stretch.

Current Schedule Status:
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                   39322.0           Nov 11 2016 21:37:50 UTC    Nov 12 2016 03:28:21 UTC      ~several hours @ 25 W
1501.3       35k                      02:00                   39322.0           Oct 24 2016 15:26:57 UTC    Oct 31 2016 15:44:29 UTC      ~week @ 25 W
2001.3       35k                      02:00                   39322.0           Oct 17 2016 21:22:03 UTC    Oct 24 2016 15:26:57 UTC      several days (at both 50W and 25 W)
2501.3       35k                      05:00                   39322.0           Oct 12 2016 03:20:41 UTC    Oct 17 2016 21:22:03 UTC      days     @ 50 W
3001.3       35k                      05:00                   39322.0           Oct 06 2016 18:39:26 UTC    Oct 12 2016 03:20:41 UTC      days     @ 50 W
3501.3       35k                      05:00                   39322.0           Jul 06 2016 18:56:13 UTC    Oct 06 2016 18:39:26 UTC      months   @ 50 W
4001.3       40k                      10:00                   39322.0           Nov 12 2016 03:28:21 UTC    Nov 16 2016 22:17:29 UTC      days     @ 30 W
4301.3       40k                      10:00                   39322.0           Nov 16 2016 22:17:29 UTC                                  
4501.3       40k                      10:00
4801.3       40k                      10:00  
5001.3       40k                      10:00

Began replacing the Anemometers on the weather stations.  Taking longer than anticipated as the stations are not in the same orientation as they were pre roofing.
The corner station is done and EndX is complete.  I had to rotate the mounting hardware so the Anemometer could point in the proper direction for 0deg.
Everything seems to be functioning.  This may also explain the complaints about the wind direction being broken in previous posts.

Here's a BruCo scan for last night lock:

https://ldas-jobs.ligo.caltech.edu/~gabriele.vajente/bruco_lho_1163325617/

Focusing on the band between 20 and 50 Hz, there isn't any large coherence. However:

• angular controls show a bit of coherence (MICH_Y and CHADR_Y).
• there is coherence with the input beam control (INP1_Y) which also shows up with the ISS second loop QPD
• SRCL is still the largest longitudinal control, but coherence isn't very high.

I've added a Weeklies screen to the Sitemap to make it easier for the operators to do FAMIS tasks. It can be found under the OPS tab. Pretty simple, there are a number of buttons that launch different scripts for different FAMIS tasks, so operators don't have to navigate from the command line. Operators and detector engineers should feel free to add tasks to this screen, I added the ones I could think of. Hopefully we can rely on this screen to make sure that operators use 1 version of a script, and give cognizant engineers some control over which version is used.

I also encourage anyone with any artistic inclinations to make it look nicer. I got nothin'.

model restarts logged for Tue 15/Nov/2016
2016_11_15 10:06 h1fw0
2016_11_15 11:45 h1susauxb123
2016_11_15 12:13 h1broadcast0
2016_11_15 12:13 h1dc0
2016_11_15 12:13 h1fw0
2016_11_15 12:13 h1fw1
2016_11_15 12:13 h1fw2
2016_11_15 12:13 h1nds0
2016_11_15 12:13 h1nds1
2016_11_15 12:13 h1tw1

Maintenance day. new frame-cpp version on fw0, new auxb123 model, daq restart.

model restarts logged for Mon 14/Nov/2016 - Thu 10/Nov/2016

Many h1oaf0 model restarts. Please see attached log text files for details.

model restarts logged for Wed 09/Nov/2016 No restarts reported

model restarts logged for Tue 08/Nov/2016
2016_11_08 08:24 h1iopoaf0
2016_11_08 08:24 h1oaf
2016_11_08 08:24 h1odcmaster
2016_11_08 08:24 h1pemcs
2016_11_08 08:24 h1tcscs
2016_11_08 08:25 h1calcs
2016_11_08 08:25 h1iopoaf0
2016_11_08 08:25 h1ngn
2016_11_08 08:25 h1oaf
2016_11_08 08:25 h1odcmaster
2016_11_08 08:25 h1pemcs
2016_11_08 08:25 h1susprocpi
2016_11_08 08:25 h1tcscs
2016_11_08 09:51 h1iopoaf0
2016_11_08 09:56 h1iopoaf0
2016_11_08 09:56 h1tcscs
2016_11_08 09:58 h1calcs
2016_11_08 09:58 h1oaf
2016_11_08 09:58 h1odcmaster
2016_11_08 09:58 h1pemcs
2016_11_08 09:59 h1ngn
2016_11_08 10:00 h1susprocpi
2016_11_08 10:06 h1pemex
2016_11_08 10:11 h1fw2
2016_11_08 12:32 h1iopoaf0
2016_11_08 12:34 h1calcs
2016_11_08 12:34 h1iopoaf0
2016_11_08 12:34 h1ngn
2016_11_08 12:34 h1oaf
2016_11_08 12:34 h1odcmaster
2016_11_08 12:34 h1pemcs
2016_11_08 12:34 h1susprocpi
2016_11_08 12:34 h1tcscs
2016_11_08 12:39 h1iopoaf0
2016_11_08 12:39 h1oaf
2016_11_08 12:39 h1pemcs
2016_11_08 12:40 h1calcs
2016_11_08 12:40 h1ngn
2016_11_08 12:40 h1odcmaster
2016_11_08 12:40 h1tcscs
2016_11_08 12:41 h1calcs
2016_11_08 12:41 h1iopoaf0
2016_11_08 12:41 h1ngn
2016_11_08 12:41 h1oaf
2016_11_08 12:41 h1odcmaster
2016_11_08 12:41 h1pemcs
2016_11_08 12:41 h1susprocpi
2016_11_08 12:41 h1tcscs
2016_11_08 13:00 h1dc0
2016_11_08 13:00 h1fw0
2016_11_08 13:00 h1nds1
2016_11_08 13:02 h1broadcast0
2016_11_08 13:02 h1fw1
2016_11_08 13:02 h1fw2
2016_11_08 13:02 h1nds0
2016_11_08 13:02 h1tw0
2016_11_08 13:02 h1tw1
2016_11_08 19:35 h1calcs
2016_11_08 19:35 h1iopoaf0
2016_11_08 19:35 h1oaf
2016_11_08 19:35 h1odcmaster
2016_11_08 19:35 h1pemcs
2016_11_08 19:35 h1tcscs
2016_11_08 19:36 h1ngn
2016_11_08 19:36 h1susprocpi

Maintenance tuesday. New frame-cpp code for fw2. ADC install in h1oaf0 starts the instabilities. DAQ restart.

model restarts logged for Mon 07/Nov/2016 - Fri 04/Nov/2016 No restarts reported

After switching to the down to check things and then going back to the OBSERVE, e-16 differences pop up that reflect the precision difference of the file and front end.  This will really hobble the commissioners/operators and jeopordize the configuration and IFO lock.  I know this is not a new problem.

The safe (for the lock) solution is to Accept the values in the FE to the file; but, this is temporary: the FE thinks the value in the file is the same even though it can not write that precision.  Next time the FE reads the file, the problem returns.  A more permanent fix is to revert the FE to the file but this requires the FE to change its value and potentially (maybe pretty small) break a lock.  Some argue we just not monitor these channels but I say that is risky for the configuration as we stop seeing actual problem channel changes.

The real solution is to have the FE code (RCG?) actually write the file at the precision of the FE so all these problems go away.

This channel will be different each lock (PerComm-JWarner.)

Here is the snap of the current 3 differences with the mask removed.

TITLE: 11/16 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing
INCOMING OPERATOR: TJ
SHIFT SUMMARY:  Locked at NLN for my entire shift.  Darkhan doing some PCal line work for the first half of the shift.  Observing for the second half.
LOG:

11:53 Turned off PCal lines. Start Kissel's PCAL2DARM measurement.

Saved as /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Measurements/PCAL/2016-11-16_H1_PCAL2DARMTF_4to1200Hz_fasttemplate.xml

12:08 Start Kissel's DARMOLGTF measurement.

Saved as /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Measurements/DARMOLGTFs/2016-11-16_H1_DARM_OLGTF_4to1200Hz_fasttemplate.xml

12:28 Turned PCal lines back on.

12:57 Observing.

• CHARD P -I had previously made the CHARD cut off more aggresive, because in long locks where our spot positions move a little bit this noise will probably lead to the range fluctuating. I was concerned that this was too agresive, so I reverterd to the old cut off filter tonight and set the gain back up to -0.14, but we should try something intermediate once we have seen that the IFO is stable again.
• Patrick directed me to his conlog test machine (http://conlog-test-replica) and I checked for differences in ASC settings between now and saturday's long lock.  (Note that we have not has a stable long lock since Monday's accidental reboot of everything).  The most suspicous wrong settings were in the refl DC centering loops, I've reverted to the settings in the screenshot attached to 31382.  
• Corey and I did add back in the RF9 modulation depth increase, and locked on the AS36 signal for SRM, and it seems OK so far.  (before doing that we had a couple of locks were switching to AS36 clearly made the build ups worse) I suspect that the funky AS36 input matrix is sensitive to the RF9 modulation depth, so we either need to retune it if we are going to skip the reduction, or just put the reduction back in. 
• We were locked for about an hour like this, with PR3 controlled on POPX instead of REFL WFS.  When we tried to switch over the IFO unlocked. For tonight I am just suggesting that Corey skip the switch and leave the beam diverters open.  We will have to think about a real solution in the morning.  (We have tried measuring the matrix, which seemed to work short term anyway).  Other options would be to try to increase the recycling gain or to see if we can give the PRC2 loops more gain margin. 

Operator information:

I've added the Reduce RF9 modulation depth state back into the normal guardian path, but if you are having locklosses durring this state or right after you can try skipping it.  If you skip it, you might want to keep the beam diverters open so you can see that the SRC1 loops are OK (ie, the ratio of AS90/POP90 is staying reasonably high over the lock). You might need to open the SRC1 loops if you skip reducing RF9 modulation depth.  

I've also moved PR3 REFL WFS out of the normal path, so that it will be skipped for now if you just request nominal low noise.