I have epoxied the final Newtonian noise L4C to the ground.  Note that it is in the walking path from the door to the LVEA over to the HAM6 area, so please be careful.  There is some tape, and a cone to help make it easier to see.

Corey, Sheila

We used to average the value of the POP QPD before engaging the loop that feeds it back to PRM, and not engage the loop if the value was too large.  We have occasionally been getting bogus values from cdsutils average in guardian (30831), which was causing guardian to get stuck here and not engage the loop. 

Since we had set the thresholds to be +-1 anyway, I just removed the averaging and checking from the guardian completely, so this shouldn't happen anymore. 

TITLE: 11/15 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:  Gusts up to 20mph
    Primary useism:  Has been trending slowly up over last 24hrs (not to worrisome levels yet)
    Secondary useism:  --
QUICK SUMMARY:

Received handoff from TJ/Kissel.  And looks like we have a few items on the docket:

• Investigating SRC1 P/Y loops (noticed possible issue last night).  (Sheila)
• ITMy ISI config change to help damp ITMy suspension after locklosses (we are now restored, since we had a lockloss and DOWN script restores us).  Warner notifed me of this.
• ITMy SUS Oplev Open Loop Gain (OLG) measurement being run after lockloss (per Kissel request)
• We had been at the INCREASE POWER state for a while and then PI Modes rang up (28 & then 27).  27 rung up to a point we couldn't damp, so we took the power down to 24W, but unfortunately, H1 dropped out of lock.
• ITMy oplev OLG Run
• Back to the drawing board.

We've set the PI verbal alarm to trigger at 3 now that we're sitting at a lower power. Let me know if that's low enough for damping response time and/or if it's too low and getting triggered unnecessarily. 

WP6314 h1oaf0 stability

Richard, Fil, Daniel, Jim, Dave:

h1oaf0 has been stable since 12:46 Mon 14th PST, no further work was done on this system

WP6312 adding new MD5 DAQ epics channels to the DAQ

Dave:

A new H1EDCU_DAQ.ini file was generated and installed during a DAQ restart at 12:11PST.

WP6315 updated frame-cpp on frame writers

Jim, Jonathan, Dave

The new code (which has been running on h1fw2 for the past week) was installed on h1fw0. Jonathan has test code to look at frames written by fw0 (new) and fw1 (old) to check they are identical. We will test for several days before the decision to upgrade fw1 is made.

WP6318 bug fix in h1susauxb123 model

Jeff:

New code for h1susauxb123.mdl to fix a bug. No DAQ restart required.

WP6324 Extend Remote Access controls to 24/7

Jonathan:

The RACCESS system is now operational 24/7 for the duration of ER10 and O2.

Testing new Hardware Injection data injestion

Keith, Dave, Jim:

New configurations of h1hwinj1 and h1guardian0 permit hw-injection users on h1hwinj1 to svn check-out the injection waveforms and schedules such that the guardian INJ_TRANS node can perform these injections. We had a minor local modification to the INJ_TRANS.py file which was removed and the guardian node code was updated to the latest SVN version. We discovered a slight discrepancy between the code and the schedule file which was resolved. System is ready for injection team to test.

It was found that the default UMASK on the newer Debian workstations were different from the Ubuntu12/14 machines (022 on debian, 002 on ubuntu). This meant that the default file permissions for new files on debian were 644 (rw-r--r--) and therefore not group writable. We are changing the default umask for user-type accounts to be 002 on all machines (via  pam_umask), and I have appended a line to everyone's .bashrc file to set "umask 002" as an OS-agnostic method of ensuring correct permissions.

If you want to check if your account is setup correctly, first check your umask setting by  typing the umask command

david.barker@zotws2: umask
0002

As a further check, create a new file and verify the correct permissions (rw-rw-r--)

david.barker@zotws2: touch testfile
david.barker@zotws2: ls -al testfile
-rw-rw-r-- 1 david.barker controls 0 Nov 15 16:15 testfile
 

and finally verify you belong to the controls group as your secondary group

david.barker@zotws2: groups
david.barker controls
 

WP 6323

The following items were removed from temporary power supplies and connected to 24V DC rack power:

1. Baffle Photodiode Amplifier Units (ITMX/ITMY)
2. RGA unit next to HAM4
3. EtherCAT hub - CU1128

WP 6292

A safety system controls chassis was installed at each end station. As of now, units are not powered on.

WP6324 Fred, Michael, Vern, Keita, Jim, Dave, Jonathan

Now we are in ER10, all CDS remote access logins are controlled by the operators at all times. Prior to this, operator permissions were only required during business hours (8am-4pm Mon-Fri) as the system was being tested.

For Yubikey holders, if you wish to log into LHO CDS remotely you will need to contact the control room operator (phone 509 372 8202) and request an access-permit to be opened for you. During your discussion with the operator, please be sure to cover why access is required, which internal machines you expect to need and the duration of your work. The operator and run management will determine if your task requires a full work-permit. Most access-permits will have a maximum duration of a week.

On a sysadmin note, on cdsssh I have opened sshd_config up to all Yubikey owners now that this is not the principal access control filter.

TITLE: 11/15 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: Maintenance Day. Nothing too crazy today, maintenance actually ended a bit after noon and we were able to almost lock at nominal. Commissioners are currently investigating some SRC1 issues that have been preventing us from having >30min locks.
LOG:
        See attached

I believe that all CP exhaust check-valve bypass-valves are now open?

Isolated PT180 while removing 2.75"CFF-NW40 adapter and installing turbo pump in its place.  Helium leak tested new joint and also the turbo vent valve.  Leaving the turbo isolated and under rough vacuum.  Decoupled fore line from turbo exhaust isolation valve.  Wrapped hardware in Aluminum foil but didn't have the preferred assortment of heat tape lengths to complete the job before maintenance time expired ;  Will still need 1 hour notice before baking can begin as the fore line will need to be connected and the correct length heat tapes still need to be added.

Why bake PT180 hardware?

PT180, PT170 and PT140 are new-to-us Inficon BPG402 Bayard-Alpert wide range gauges that we installed this past spring.  As mentioned by others in previous entries, these three have a positive slope over time which is not reflected in our older cold-cathode gauges which sample the same vacuum volume(s) but at different locations,  Degassing of the new gauge's filaments haven't helped.  The theory now is that this gauge behavior is the result of "wet" components used in the gauges assemblies [(2) new uhv valves, (1) new 1 1/2" CFF Tee and (1) new BPG402 gauge.  

Attached is the graph showing the pressure accumulation, we hope to repeat this accumulation following the bake for comparison:

J. Kissel

Travis was able to grab a PCAL2DARM/DARMOLGTF sensing function transfer function set last night (see LHO aLOG 31485) -- for convenience I reiterate the location here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Measurements/
PCAL/2016-11-15_H1_PCAL2DARMTF_4to1200Hz_fasttemplate.xml
DARMOLGTFs/2016-11-15_H1_DARM_OLGTF_4to1200Hz_fasttemplate.xml
and attach a screen shot. The data has been committed to the CalSVN.

It looks like the DARM cavity pole was low during this lock stretch, but otherwise the optical gain is ~5% low as we've seen in the last of measurement at 30 [W].

We'll get one more of these at 30 [w] for processing and get on with the analysis. Apologies for the delay in analyzing this data -- I'm really struggling for person power beyond me, given the current poor duty cycle and my needs to be the recovery team as well (Kiwamu's in Canada, Evan's helping out LLO).

For the record, we have not added any water to the TCSY chiller for a week, and the indicator only shows a small drop in the level during this week.  Looks like we finally have the system topped off.

...as per WP6316. ≈ -1.6 µrad offset in YAW due to 'kick' when the positioner is turned on/off. Multiple attempts to offset made no difference.

J. Kissel

Getting one more round of calibration reference measurements for ER10/O2. The decision was made to run ER10 / O2 at 30 [W] (as opposed to the 25 [W] we'd been running all week), so I've made sure to get another round of transfer functions. 

In addition I've made a bunch more probing measurements of the L1 / UIM stage above 100 Hz, so that we can create an empirical model of the UIM actuator expanding on what was done in LHO aLOG 24917. Again, here, it's not that the UIM plays a big role in the response function at these frequencies, it's that the deviations at high frequency limit our ability to obtain a clean estimate of the actuation strength. Templates all listed below, analysis will come later.

Sensing Function Data:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Measurements/DARMOLGTFs/
2016-11-12_H1_DARM_OLGTF_4to1200Hz_fasttemplate.xml
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Measurements/PCAL/
2016-11-12_H1_PCAL2DARMTF_4to1200Hz_fasttemplate.xml
We may take a few more of these, just because the IFO input power has changed. Yes, a 25 [W] to 30 [W] is a small change in optical gain, but we want to be sure if detuning comes into play by 30 [W], and also if the cavity pole changes. I've also been told to expect further DC alignment changes before the weekend's out which may also play a role in these kinds of sensing function parameter changes.

Actuation Function Data:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Measurements/FullIFOActuatorTFs/2016-11-12/
2016-11-12_H1SUSETMY_L1_iEXC2DARM.xml
2016-11-12_H1SUSETMY_L1_PCAL2DARM.xml
2016-11-12_H1SUSETMY_L2_iEXC2DARM.xml
2016-11-12_H1SUSETMY_L2_PCAL2DARM.xml
2016-11-12_H1SUSETMY_L3_iEXC2DARM.xml
2016-11-12_H1SUSETMY_L3_PCAL2DARM.xml
This should complete the three suites of measurements we usually do for the actuators. Given the preliminary analysis from Kiwamu (LHO aLOG 31427), I don't see a need for more data here.

Also, I gathered some undisturbed time in between the sensing function measurements and actuation function measurements between 2016-11-12 06:08 UTC and 06:30 UTC so these can be used to convert / compare back against 25 [W] lock stretches. Maybe. Recall the previous two attempts at these measurements to bordered by lock losses caused by the OAF computer crashing, so there may not be a lot of time then against which to compare.

Detailed High-frequency L1/ UIM Actuation Function Data:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Measurements/FullIFOActuatorTFs/2016-11-12/
2016-11-12_L1_iEXC2DARM_HFDynamicsTest_100-250Hz.xml
2016-11-12_L1_iEXC2DARM_HFDynamicsTest_250-350Hz.xml
2016-11-12_L1_iEXC2DARM_HFDynamicsTest_300-500Hz.xml
2016-11-12_L1_iEXC2DARM_HFDynamicsTest_90-400Hz_SweptSine.xml
2016-11-12_L1_PCAL2DARM_HFDynamicsTest_100-250Hz.xml
2016-11-12_L1_PCAL2DARM_HFDynamicsTest_250-350Hz.xml
2016-11-12_L1_PCAL2DARM_HFDynamicsTest_300-500Hz.xml
2016-11-12_L1_PCAL2DARM_HFDynamicsTest_90-400Hz_SweptSine.xml
The *not* labeled SweptSine are broad band injections. The idea is to export the data, filter it by coherence (0.95 should be good enough) and then take the ratio. The broad band TFs are better for characterizing the resonances. The hope is we can stitch all of these data sets together to form one sweeping meta-transfer function that completely maps out the UIM, in detail, out to ~500 Hz. 

J. Kissel, H. Radkins

I'm continuing to investigate why ITMY's pitch mode (at 0.55 Hz) continues to ring much longer than the other QUAD's upon lockloss (see and example attached as 2016-11-08_2151UTC_ITMY_Oplev_Bad_TimeSeries.png). 

Today, I grabbed the open loop gain transfer functions of the M0 DAMP L, the M0 DAMP P, and the L2 OLDAMP P local damping loops on both H1 SUS ETMY and H1 SUS ITMY, to show that the identical settings are producing identical results for QUADs that are essentially physically identical. 

Indeed, the open loop gain transfer functions of both suspensions look the same.

We don't have too many lock loss data points yet since I made the change, but I did discover that the digital output limiter of all QUAD's L2 OLDAMP P bank were different (one as low as 5000, and one as high as 500000, and ITMY was in the middle at 10000). So, I've made all the limits the same, at 40000, in hopes that the problem is with the square-wave that ITMY gets sent during a lock loss. This change is NOT accepted in the SDF, because I'm unsure if it matters yet.

Still unclear what is going on here...

Hugh's taking a look at these same optical lever signals after every lock loss for the past month. Preliminary results show that this behavior is intermittent, but has definitely gotten worse in the past week or two. We hope he can trace this back to some event like a maintenance day to better try to address the problem.

J. Kissel

Though it's been a struggle between all of the H1OAF computer crashing, I've managed to squeak out one more round of calibration measurements today. The data's location is below; analysis to come.

The data lives here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Measurements/
(1a) DARMOLGTFs/2016-11-10_H1_DARM_OLGTF_4to1200Hz_fasttemplate.xml
(1b) PCAL/2016-11-10_H1_PCAL2DARMTF_4to1200Hz_fasttemplate.xml

(2)
FullIFOActuatorTFs/2016-11-10/2016-11-10_H1SUSETMY_L1_iEXC2DARM.xml
FullIFOActuatorTFs/2016-11-10/2016-11-10_H1SUSETMY_L1_PCAL2DARM.xml
FullIFOActuatorTFs/2016-11-10/2016-11-10_H1SUSETMY_L2_iEXC2DARM.xml
FullIFOActuatorTFs/2016-11-10/2016-11-10_H1SUSETMY_L2_PCAL2DARM.xml
FullIFOActuatorTFs/2016-11-10/2016-11-10_H1SUSETMY_L3_iEXC2DARM.xml
FullIFOActuatorTFs/2016-11-10/2016-11-10_H1SUSETMY_L3_PCAL2DARM.xml

J. Kissel

I've taken the first round of all swept sine measurements typically done before an observing run:
(1) Sensing function, C
    (a) DARMOLGTF and Loop Suppression (IN1/IN2 and IN2/EXC); G and 1/(1+G)
    (b) PCAL2DARM (and PCAL2DELTAL); (C/1+G) and [m/m]
(2) Actuation Function, A
    (a) L1 to DARM & associated PCAL2DARM; (C A_uim)/(1+G) and (C/1+G)
    (b) L2 to DARM & associated PCAL2DARM; (C A_pum)/(1+G) and (C/1+G)
    (c) L3 to DARM & associated PCAL2DARM; (C A_tst)/(1+G) and (C/1+G)
where I've taken a separate PCAL2DARM or C/1+G transfer function with every corresponding excitation to destroy any covariance that had plagued us during O1. Also, I've worked to
    (i) reduce the template's measurement time by maximizing drive, 
    (ii) reducing the number of points over all, and
    (iii) keeping integration time in check,
such that each template only takes about 15 minutes. I've also modified the frequency vectors of the actuation functions to go out to 1 kHz, as LLO did for their O1 data sets. In doing so, I made sure to use frequency points that avoided any known high-frequency resonances from wire violin modes (characterized in LHO aLOG 24917). 

There's still some improvements to make, which I'll shoot for in the next round (so don't use/take these templates as cannon yet), but thanks to the high-duty cycle of the IFO, I had the opportunity to make really well-balanced templates tonight.

The data lives here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Measurements/
(1a) DARMOLGTFs/2016-11-07_H1_DARM_OLGTF_4to1200Hz_fasttemplate.xml
(1b) PCAL/2016-11-07_H1_PCAL2DARMTF_4to1200Hz_fasttemplate.xml

(2)
FullIFOActuatorTFs/2016-11-07/2016-11-07_H1SUSETMY_L1_iEXC2DARM.xml
FullIFOActuatorTFs/2016-11-07/2016-11-07_H1SUSETMY_L1_PCAL2DARM.xml
FullIFOActuatorTFs/2016-11-07/2016-11-07_H1SUSETMY_L2_iEXC2DARM.xml
FullIFOActuatorTFs/2016-11-07/2016-11-07_H1SUSETMY_L2_PCAL2DARM.xml
FullIFOActuatorTFs/2016-11-07/2016-11-07_H1SUSETMY_L3_iEXC2DARM.xml
FullIFOActuatorTFs/2016-11-07/2016-11-07_H1SUSETMY_L3_PCAL2DARM.xml

While it'll be days before we have a model and a complete, traceable uncertainty budget, preliminary results show the *mean* of *one measurement* of PCAL's estimated displacement agrees with the front-end calibrated sensitivity to roughly 5% and 5 [deg]. This confirms that the > 50 Hz discrepancies between PCAL and DELTA L EXTERNAL seen while we were at 50 [W] (e.g. LHO aLOGs 30391 and 30431) were likely a function of the poorly controlled signal recycling cavity, and therefore time-dependent RSE cavity pole that was quite low.
Recall that the uncertainty of the PCAL estimation is around 1%. 

We're right on schedule, and things are looking up. We'll see how the modeling goes...