Title:  09/20/2016, Evening Shift 23:00 – 07:00 (16:00 - 00:00) All times in UTC (PT)
State of H1: IFO is down due to a problem with the Guardian. CDS is working on the resolution.      
Commissioning: 
Outgoing Operator:  Ed
 
Activity Log: All Times in UTC (PT)

23:00 (16:00) Start of shift
23:35 (16:35) Rick & Travis – Back from End-X
23:37 (16:37) Ben – Going into LVEA to look for tools
23:42 (16:42) Ben – Out of the LVEA
00:05 (17:05) Kiwamu & Nutsinee – Out of LVEA
00:07 (17:07) Dave – DAQ restart (WP #6174)


Title: 09/20/2006, Evening Shift 23:00 – 07:00 (16:00 – 00:00) All times in UTC (PT)
Support:  Jenne, Sheila, Lisa, Kiwamu      
Incoming Operator: N/A

Shift Detail Summary: Ran initial alignment after Guardian fixed and people out of LVEA and End-X. Commissioning and relocking took up the bulk of the shift. Environmental conditions of light winds and low seismic activity all shift. 

The End-X BRS was rung up all shift. Using ISI_CUST_CHAMBER_GND_BRS.adl to monitor. No change in signals during the shift, so per Jim W. did not make any adjustments or changes.

Jeff K, Dave B, Darkhan T,

Overview

Coherence calculation settings were updated today's after a minor bug fix in CAL-CS.

We discovered that some of the reference EPICS records that are used for calculation of kappas in the front-end were not set (or lost after a DAQ restart). The records were populated with values calculated from the DARM model for ER9.

Details

• Today we modified CAL-CS synchronized oscillator demodulation for DARM_LINE1 to include an ability to set a desired phase (LHO alogs 29852, 29853). After this update the replica of the DARM_LINE1 excitation, used for calculation of time-dependent parameters ("kappas"), uses SINGAIN and COSGAIN settings of the synchronized oscillator (which weren't set before). Both of these gains must be set to be the same as CLKGAIN.

Similarly, SUS_LINE1 synched oscillator SINGAIN and COSGAIN values must be set to be $(IFO):SUS-ETMY_L3_CAL_LINE_CLKGAIN multiplied by DAQ downsampling TF magnitude at this frequency (35.9 Hz at LHO). Synched OSC phase must be set to the DAQ downsampling TF phase at the line frequency (not sure if we need to put positive or negative phase). Previously SUS_LINE1 synched OSC parameters were not set properly and the coherence was not calculated (see attachment 4, coherences calculated during last 4 days).

Both DARM_LINE1 and SUS_LINE1 oscillator parameters were updated, the changes were accepted in SDF_OVERVIEW.

• We updated the EPICS records that are used for calculation of κ_c and f_c, H1:CAL-CS_TDEP_PCALY_LINE2_REF_A_USUM_(REAL|IMAG) and H1:CAL-CS_TDEP_CAVITY_POLE_PCAL_FREQ:

Old : H1:CAL-CS_TDEP_PCALY_LINE2_REF_A_USUM_REAL 0
New : H1:CAL-CS_TDEP_PCALY_LINE2_REF_A_USUM_REAL -1.73852e-19

Old : H1:CAL-CS_TDEP_PCALY_LINE2_REF_A_USUM_IMAG 0
New : H1:CAL-CS_TDEP_PCALY_LINE2_REF_A_USUM_IMAG -1.03541e-19

• The oscillator phase field was added to the MEDM screen CAL_CS_TDEP_DARM_LINE and some minor fixes were made to the CAL_CS_TDEP_OVERVIEW screen. The changes were committed to cds_user_apps repo, r14297.

J. Kissel, S. Dwyer, L. Barsotti

At the advice of DetChar (LHO aLOG 29828) we've balanced the DCPDs, which indeed hasn't been done since the new breadboard and PDs were installed (LHO aLOG 28862). Unlike the previous pair of DCPDs which were out-of-the-box perfectly balanced (see LHO aLOG 17650), the current pair has an imbalance of 2.1106%. This value has been entered into H1:OMC-DCPD_BALANCE, and accepted into the SDF "down" state for the h1omc model.

Method:
For the DCPD sum, we take an average of the two: A/2 + B/2.
The h1omc front-end infrastructure is built such that the percentage imbalance, e, is applied to both equally: A*(1 + e)/2 + B(1 - e)/2
So, the transfer function measurement of DCPD A/B is (1+e)/(1-e) ~ 1 + 2e. Since the transfer function magnitude is 0.957788, then the imbalance we enter will be e = ((A/B) - 1) / 2 = 0.021106 = -2.1106%.

We also found this value gradually (because we weren't sure how the infrastructure worked), by confirming the imbalance that minimized the DCPD NULL stream (and the coherence drops to zero). Overshooting the imbalance (e.g. by entering in -4.2%) shows a clear sign flip from the reference trace where there is 0% imbalance compensation.

Ben Keita Daniel

We updated the ISS box:

• Gain of 1/10 in the excitation input. This should allow us to leave this path enabled for a fine adjusting the offset.
• Boost moved to 4kHz (from 500Hz)
• Analog outputs added to the front panel
• Removed the old ISS and cabled all PDs of the ISS array into the new chassis. PD1-4 are now correctly read as PD1-4 in the model.

We made the following model updates:

• The legacy second loop ISS code was removed
• The "outerloop" ISS was renamed to secondloop ISS
• The QPD was moved over as well as a reference servo for the diffraction power
• The ISS second loop enable button in the first loop is now binary EPICS channel
• medm, sdf and filter files were updated to reflect these changes.

D. Tuyenbayev, J. Kissel

Darkhan had noticed that we are demodulating the ETMY SUS calibration line (which determines the test mass (L3) stage actuation strength change, kappa_{TST}) differently than that which is injected just after the DARM bank from the CAL-CS model (which determines the PUM+UIM (L1+L2) stage actuation strength change, kappa_{PU}), after we upgraded the font-end DARM loop parameter time-dependence calculations (see e.g. LHO aLOGs 29231, 29740, and 29744). In short, for the DARM line, he discovered we're not able tune the phase of the oscillator for this new time dependent analysis. If we keep this, then we'd have to maintain two sets of DARM loop model EPICs records to calculate these actuation strength changes, because offline construction of kappas must include the phase destortion of DAQ downsampling filters at the calibration line frequency, where any front-end calculation does not. Also, it seems unnecessarily confusing to demodulate various lines differently.

As such, for the DARM_LINE_MONITOR block in the 
/opt/rtcds/userapps/release/cal/common/models/CAL_LINE_MONITOR_MASTER.mdl
library, we've broken the DARM_LINE_DEMOD tee-off of the CLK output of the oscillator, and replaced it with the I phase output of a phase rotation block, which picks up the SIN and COS outputs of the oscillator.

These changes have been committed to the userapps repo.

new h1calcs model WP6174

Jeff, Darkhan, Dave:

new h1calcs model installed. DAQ restart combined this and the last h1psliss changes.

h1psliss model WP6172

Daniel, Keita, Ben, Dave:

h1psliss was restarted several time, first to primarily replace OUTERLOOP with SECONDLOOP naming. Subsequent restart for minor name tweaks. Several DAQ restarts

Clone h1fw1 WP6171

Carlos, Dave

NDS were switch to using h1fw0's frames. h1fw1 was shutdown and its boot disk is being cloned. Due to its size (1TB) this will take overnight.

Reboot h1guardian0

TJ, Dave

We did a reboot of h1guardian0, later attemps to lock the mode cleaner showed connection errors for Beckhoff channels. Running caget on h1guardian0 did get the data, but showned two paths (direct and via epics-gateway). Stop-start of the node did not force the connection. We turned off the gateway (h1slow-h1fe) and rebooted guardian. Some nodes still showed connection errors, again caget connected. Finally we started the gateway and all the connections completed. Need further investigation with Jamie.

h1guardian0 was updated prior to the reboot, we think this may have broken INJ_TRANS node.

TCS CO2 chiler tests

Dave, Nutsinee:

Confirmed that pulling the chiller cable in preparation for a power cycle of h1oaf0 IOChassis trips the CO2 lasers and should not be done.

Remove old PT140 channels from Vacuum Controls WP6166

Patrick, Dave:

After Patrick had made the Beckhoff changes, I imported his latest h0vaclx.ini file into H0EDCU_VAC.ini This went in on later DAQ restart

Add h1fw2's new diag epics channels to DAQ WP6173

Dave:

h1fw2 is running Jonathan's RCG3.2 daqd with improved diagnostics. These additional channels were added to H1EDCU_DAQ.ini and went in on a DAQ restart.

h1susprocpi model

Terra, Dave:

Terra added epics input channels for state definition. Model was changed and DAQ was restarted. Small number of slow channels were added to DAQ.

DAQ restarts

Dave:

Several DAQ restarts during the day to support the above activities. Most went cleanly, two had minor issues

On one I needed to restart the mxstream from both h1pemmx and h1pemmy

On another I need to restart the mxstream on h1sush56

An idea was proposed to eliminate the possibility that charge build up on optics could be due to UV photons from new hot ion gauges installed at end stations. We (Jeff K., Betsy W., and I) may pursue this during O2 break by turning off IGs for extended periods of time while measuring charge rate.

Attached is a schematic showing the location of the two new hot ion gauges (IG) at each end station (and one 250 meters down on each arm) AND now we have a updated VE GUI on MEDM, thanks to Gerardo, showing these gauges (names have changed):  X4,Y4 are attached to the top of the very end BSC. X5,Y5 are right next to NEG pump, which is at about head level, also bolted to the very end BSC. X4 and Y4 are interlocked with high voltage, so if we turn them off, we need to  immediately turn HV back on manually. We can leave the gauges off for a week or more; however, we lose HV safety interlocks. X5,Y5 next to NEGs can be turned off for as long as we need. 

X6,Y6 are 250 meters down from end stations next to the ion pumps (IP) that were installed to compensate for the valved out large IP at end station. Those IPs and IGs should be far enough away to avoid charging issues, but they are on valves and we could valve the pump out for a day if we absolutely need to (we will see a pressure rise but it will recover when we turn pump back on).

Re-plumbed exhaust flow meter on CP4 incorporating a "trap" to protect flow meter from LN2. Only the finest flex tube and zip ties were used.

Fault 6024  Work Permit 6105

Continued troubleshooting the Demodulator readback signals for the green WFS at the end stations. Traced issues to faulty Beckhoff analog input terminals - EL3104.

EY - EL3104 Terminals 6 and 9 were replaced

EX - EL3104 Terminals 6, 7, 8 , and 9 were replaced. I don't expect all four units to be bad, but was easier to replace all four at once.

Units removed will be tested to see if we can reproduce/diagnose the problem. 

One thing to note is that the RF Mon channels at EY were not as stable as EX. The LO mon signals at EY (15dB) had a 3dB difference than EX (18dB). Not sure if this is an issue or just the state of each end station at the time of testing.

Maintenance Day

• The LASER tripped off again this morning
• DOH paid a visit to inspect for radiation

15:03 Ben Abbott out to LVEA to pull out ISS chassis

15:04 Patrick executing WP#6166

15:07 Joe into LVEA for weekly inspections of batteries, etc.

15:09 Cleaning crew dispersing to End Stations

15:17 Ben out of LVEA

15:21 Kyle outo EX

15:30 Fil to EY to troubleshoot WFS readbacks

15:40 BRS at both ends turned off

15:51 Kiwamu to squezer bay

16:00 Kiwamu out

16:06 Jim to EY to check on ion pump for BRS

16:07 Christina leaving EX

16:11 Gerardo out to LVEA to power up PT140

16:14 LASER tripped

16:29 Jim back

16:33 Karen leaving EY

16:35 Kyle and Fil back

16:37 Travis back from EY

16:38 Jason starting to bring the LASER back up

16:39 LN2 Delivery arrived

16:55 Karen into LVEA

17:01 Alfredo into Biergarten to install 24V junction boxes on top of racks.

17:16 Jason into LVEA to reset Noise Eater

17:19 Hugh and Chris out to EY mechanical room with the big truck

17:21 Mike L into LVEA for a quick tour

17:28 Richard out to reset theHV interlock that tripped during vaccuum system reboot

17:29 Kiwamu and Nutsinee into optics lab

17:39 Richard out

17:48 Nutsinee doing TCS work

17:52 Joe into LVEA for his usual weekly checks

17:54 Ben returning the ISS chassis to the LVEA

17:54 Travis, Rick and co. to EX for Pcal work

17:55 EX transitioning o LASER HAZARD

17:57 Betsy out

17:59 Gerardo out of LVEA.

18:01 Nutsi out to LVEA (TCS)

18:24 Cheryl ad Kiwamu into PSL enclosure for WP#6165

18:37 Chandra going for a jog along the X-arm

19:35 Fil to EX

19:40 Chandra back

20:02 Kyle to EX

20:17 Richard into CER to install reset buttons on HV interlock boxes

20:21 Richard back

20:39 DAQ restart ( 3 times)

20:45 DAQ is back (3 times)

21:02 DOH onsite for John W

21:07 John and DOH into LVEA

21:32 Rick and Travis headed back to EX

22:47 Fil back from EX

22:57 Handing of to Jeff B

Today, Carlos P. fixed the LAN setup IP address issue for me and I was able to connect to the X-end RGA electronics using the dedicated laptop.  This allowed me to confirm that the RGA still functioned following its removal and re-installation the other day (prerequisite to performing the bake operation).  I then wrapped the whole assembly in aluminum foil (it's an art - performed by artists).  At the next opportunity, I will wrap the assembly in heat tapes (also and art - performed by artists!) followed by the final layer of aluminum foil.  At that point, it will sit idle awaiting the next 5-day window of IFO down time to perform the actual bake.

A reminder that we are in the testing phase of operator control of remote access to LHO CDS. This is a soft roll-out, it is only in effect while an operator is on duty and it does not kill any running sessions. 

Here is part of an email which was sent to remote access users on 8/30

Dear All,

this email is being sent to everyone who has logged remotely into LHO CDS in the past calendar year. Starting today we are testing an enhanced security system which requires remote users to call the control room operator before remote access is permitted. During this testing phase the additional restrictions will only be in place when an operator is on shift, 8am to 4pm Pacific Local Time Monday through Friday. Outside of these times, access will be unrestricted. Open sessions which span these time boundaries are unaffected.

Note that this applies to secure copy (scp) as well as secure shell (ssh) sessions.

The operator’s phone number is (509) 372 8202

Dave, Nutsinee

Today we did a little test to confirm that there's no way to aviod CO2 laser tripping when oaf computer and IO chasis are bering restarted by unplugging the chillers from the front end which we thought might have worked at one point. Turned out as soon as the chillers were unplugged from the cables the CO2 controller box tripped immediately and the drawn currents went down to 0.7 A for TCSX and 0.8 A for TCSY (from their nominal at ~22A). Funny thing is when I went back to restart the controller boxes after plugging the chillers back in there're no red lights indicating that they had been tripped. They simply stopped lasing. The laser status looks like it's never tripped. So if somebody unplug the chillers and the lasers don't work, there's currently no obvious way to know from the control room that the chiller(s) have been unplugged (except that TCS laser locking guardian might throw fist and unreasonable DAC outputs).

Before I went out to the mezzanine I paused TCS guardian so that they won't try to talk to the chillers when they're disconnected. As soon as the chillers were disconnected (10:52 AM local) DAC output 1(ITMX pzt), 4(ITMX chiller), 9(ITMY pzt), 12(ITMY chiller) freaked out and dropped/jumped far from nominal. They didn't come back to their nominal values until I restarted the TCS laser locking guardian nodes after bringing everything back to normal.

We need Alastair's magic box to prevent TCS from tripping everytime oaf/dac is powered down.

TCS CO2 system layout can be fround here

WP6171: Ryan, Carlos, Dave:

h1fw0 writes data to the /ldas-h1-frames QFS disk system (located in warehouse)

h1fw1 writes data to the /cds-h1-frames QFS disk system (located in OSB-MSR)

both h1nds0 and h1nds1 were serving /cds-h1-frames (historic from when h1fw0 was unstable).

This morning I reconfigured both nds servers to serve h1fw0's frames(ldas-h1-frames). We then powered down h1fw1 started cloning its boot drive. Since this is 1TB this may take a few hours.

Reset HAM2 and ITMX.

The 56.8406 Hz comb that Keith pointed to in recent data shows up in End-X magnetometers, and seems to be an isolated spike repeating at that rate.

Keith's recent alog 29783 points to a comb with a spacing of 56.8406 Hz that has been seen before in ER9 and in the one-arm tests. TJ's Bruco results in alog 29828 show that the 56 Hz region of DARM is coherent with the SEIRACK and FLOOR magnetometers. The first plot shows the coherence just at the fundamental frequency.

The line seems strongest in SEIRACK_Y, so I tried folding the channel. The frequency doesn't seem to be an exact multiple of anything digital. But taking 1153 samples at 8192 Hz comes very close to 8 times the comb spacing, so I used that. The result is in plot two, which is four hours of mag data from today folded over 1153 samples. Eight spikes show up very clearly, so there does seem to be some kind of spike happening every 0.01759 seconds.

There are some other channels showing up in Bruco that may not be connected to anything - PEM-EX_ADC_{8,12,13}. I think these are spares. At EY there are some magnetometers on these channels but these look too dead for that. They seem to see the same line, so maybe this really is some kind of DAC problem, or maybe there's just some electronic pickup.

We should get an independent magnetometer out to EX and look around for this comb, and also just confirm that it's not native to the DAC.

We can rule out any mechanical mode around 17.7 kHz causing instability. Any mode around 17.7 kHz does not have good overlap with 3rd order mechanical mode. It most probably aliased mode from ~ 47.7 kHz. Interestingly, according to my FEA model of ETM, there are three candidates: 47.767 kHz, 47.811 kHz, and 47.827 kHz mode. These modes corresponds to the mode number #542, #544, and #545, respectively. Mode shapes are attached. All of them have reasonably high overlap factor:  
#     freq, kHz       TEM    Overlap ITM    Overlap ETM  
542    47.767          02     0.028            0.026
544    47.811          02     0.057            0.050
545    47.827          02'    0.026            0.024

'-see figure
The overlap with 2nd order confirms that one of these modes must ring up. The parametric gain for tuned ETM is shown in attached figure. It is not possible to pinpoint  which  of these modes is observed. According to the overlap value there is slightly better chance that this mode belongs to ITM and it's mode #544. However, mode #542 is the closest to the observed frequency (I do not expect to see error of computed frequency larger than 0.1% at 50 kHz range).  Using ring heater we should be able to rule out at leas one of the three modes. 

Matt, Terra

We have 2 modes which are very close in frequency (both around 15540kHz) and we have had some trouble damping them.  To help with this, I modified the PLL filters for these modes to support a lower bandwidth loop, which I hope will be less easily "distracted" by the nearby mode.  The low-pass in FREQ_FILT1 (usually a 1Hz pole) is a modified elliptic which provides significant attentuation at 0.5Hz (ELF0.5), and requires a UGF of about 100mHz.  To support this, the integrator in FREQ_FILT2 is moved down to 30mHz and the gain is reduced to 0.3.  (Note that ELF0.5 has a gain of 0.5 below the cutoff.  This helps to move the UGF down when this filter is on.)

So far this configuration has been working, but should it prove problematic the old filters can be moved back from FM2 to FM3 (which is the FM operated by the guardian).

J. Kissel

Now that we're approaching ER10, and the noise is getting back to O1 levels, we need to start tracking the time dependence of the SRCL detuning in the DARM response. As such, with only intuition to guide, I've added a new calibration line at 7.83 Hz, driven by PCALY at a requested amplitude of 20000 [ct] (corresponds to a DAC [ct/rtHz] of 28909, and 8.8e-13 [m/rtHz] of DARM displacement). For a 10 [sec] FFT, with the current sensitivity, this has about an SNR of 10. We can explore driving the line harder, but let's see what we get out of this -- we're already close to the limit of the PCAL AOM, and that's what I used to tune the excitation amplitude. Also note that, although we often use a 10 [sec] FFT as our SNR metric, in practice, we often use 60 or 120 [sec] FFTs (i.e. the time scale on which we expect optical plant parameters to vary), so we'll win there.

I've checked to make sure that this new line
- Does not saturate the PCALY DAC
- Does not saturate the PCALY OFS
- Does not saturate the DARM actuator when trying to control this line (ETMY SUS) 
- Does not generate any substantial harmonics or other non-linear noise in DARM

And I've also accepted the settings for this new line in the safe and OBSERVE snaps for PCALY.

Let's get this line into SLM tool and start analyzing to see if the SRC detuning moves!

P.S. We expect fisher-matrix back-up that this is roughly the "optimal" location for the SRCL line, given that we suspect the optical spring frequency to be around 9.8 [Hz]. Of course, we cannot put the line right on 9.8 [Hz], since that's exactly the frequency of the QUAD's highest vertical mode (a.k.a. "bounce" mode). I've compared 7.93 [Hz] against all of the "do not put a line here" criteria used for the original calibration lines (see LLO aLOG 15870), and this frequency does indeed satisfy those criteria especially since the line is below the astrophysical analysis band.