Added the following channels to the exclude list:

H1:SUS-ETMX_PI_OSC_DAMP_OSC_LINE1_COSGAIN
H1:SUS-ETMY_PI_OSC_DAMP_OSC_LINE1_COSGAIN
H1:SUS-ETMX_PI_OSC_DAMP_OSC_LINE2_COSGAIN
H1:SUS-ETMY_PI_OSC_DAMP_OSC_LINE4_SINGAIN
H1:SUS-ETMX_PI_OSC_DAMP_OSC_LINE4_COSGAIN
H1:SUS-ETMY_PI_OSC_DAMP_OSC_LINE3_COSGAIN
H1:SUS-ETMX_PI_OSC_DAMP_OSC_LINE2_SINGAIN
H1:SUS-ETMX_PI_OSC_DAMP_OSC_LINE4_SINGAIN
H1:SUS-ETMY_PI_OSC_DAMP_OSC_LINE3_SINGAIN
H1:SUS-ETMX_PI_OSC_DAMP_OSC_LINE3_COSGAIN
H1:SUS-ETMY_PI_OSC_DAMP_OSC_LINE4_COSGAIN
H1:SUS-ETMX_PI_OSC_DAMP_OSC_LINE3_SINGAIN
H1:SUS-ETMY_PI_OSC_DAMP_OSC_LINE2_SINGAIN
H1:SUS-ETMX_PI_OSC_DAMP_OSC_LINE1_SINGAIN

Re wandering 59Hz bump first seen around 25 May and reported Jun 1: With the DQ channels, I checked to 125Hz and it does not show itself.  Maybe the power cycle cleaned it out.

Otherwise, attached are the CPS spectra for all the BSCs:

The ETMX St1 V1 looks much better now.  The ITMX St2 H3 is a little better but the ITMX St1 V1 is quite noisy now.  I better check this tomorrow to see if it changes.

Routine Maintenance but since the Motor greasing is just an annual event figured it warrented a log entry.  Of note, found that many of the zerk fittings would not open and pass the grease.  So found one that did and installed that one as needed.  Will open an FRS ticket and purchase better zerks to replace the negative function units.

Sheila, Evan, Haocun

We drove the ETM's in pitch and yaw, and took measurements for the HARD loop.

As Evan posted in aLOG 27518, the usual "IN1/IN2" method for FFT-based OLTF measurements were biased because the IN2/EXC coherences were low, so I exported the data of CLTF's using IN1/EXC (whose coherences were higher), and converted them into OLTF's.

The measurements for both pitch and yaw of CHARD and DHARD are plotted together with the modelling curved as attached:

- The measurements were taken under 2W of laser power. The blue curves are the modelling DHARD plots at 2W, and the red or orange dots are measurement values.

- Only values with IN2/EXC coherence higher than 0.4 were used, otherwise the data were dropped.

- I tried to calculate the uncertainties of the measurements using the method in aLOG 10506, shown as error bars on the plots.

- Number of measurements taken:

  CHARD Pitch: 111

  CHARD Yaw: 44

  DHARD Pitch: 121

  DHARD Yaw: 33

We will take more measurements with same UGF values in the model and do more comparasion.

[Dave, Rich, Terra, Carl]

We have removed DAC card_num=7 from h1susitmypi and re-ordered the outputs on DAC card_num=6 in accord with the update to D1500464.
Specifically H1:IOP-SUSB123_MDAC6_TP_CH0-7 now follow the ordering ITMX UR LR UL LL, ITMY UR LR UL LL.

there is a collision of DAC channels on h1iopsusb123, we will rebuild and restart all the models on this frontend when new code is available.

RCG 3.0.3 upgrade.

Jim, Dave:

All the frontends were rebuilt against RCG TAG 3.0.3 on Friday afternoon before the shutdown. The build started with an empty H1.ipc file to clean out any unused IPC chans. After all the frontends were restarted today, they are now running with  3.0.3 

Infrastructure Restart

Richard, Carlos and Jim:

The CDS infrastructure was restarted between 7:00 and 8:30. These include networking, DC power, timing, DNS, DHCP, NTP, NFS, auth.

Front End Startup

Richard, Jim, Dave:

h1boot was started. Then h1psl0 was started as an non-dolphin FEC. This permitted the DAQ to be restarted (needs a running front end). Then the remaining non-dolphin MSR FECs were started. The Richard started EX, EY, MX and MY FECs. Finally we started the MSR dolphin machines. All started up once the fabric was complete.

h1lsc0 reported timing issues. The timing card on this IO Chassis is independently powered, I activated this DC supply and the system started normally.

h1pemmy needed on more IOP restart, as is expected for these non-IRIGB units.

During the startup of the SWWDs, all MSR dolphin channels were found to be not working. We tracked this down to the Dolphin switches not being powered up, this was easily resolved.

Eagle eye-ed Jim noticed the system time on h1psl0 was way off (by 7 hours). We assumed because it was the first to be started soon after h1boot (which perhaps had not NTP synced). We manually set the time and handed control back to NTPD.

EPICS Gateways

Dave:

All the epics gateway processes on cdsegw0 were restared using the start.all script. This started too many gateways resulting in duplicate data paths, the redundent gateways were removed and the script was corrected.

h1hwinj1

Jim, Dave:

We started the PSINJECT process on h1hwinj1. Again the SL firewall prevented EPICS CA access, which we re-remembered and fixed. CW injection to PCAL is running.

Slow Controls SDF

I started Jonathan's SDF monitor pseudo-target on h1build.

Vacuum Controls and FMCS cell phone notification

I got the cell phone alarm texter running again on cdslogin.

PI Model changes

Tega, Dave

A new PI_MASTER.mdl file was created at 15:10 Friday, which just missed the 3.0.3 build cut-off time. We recompiled and restarted the four models which use this file (h1omcpi, h1susitmpi, h1susetmxpi and h1susetmypi). A DAQ restart was also required.

NDS processes not giving trend data

Jeff, Jim, Dave

here was an interesting one, the nds processes were giving real-time data but no archived trend data. The cronjob which was keeping the jobs directory in check by deleting all files older than one day, today cleaned out the directory and then deleted the jobs directory itself. Re-creating the directory and stopping the cronjob from erasing it again fixed the problem.

h1tw0 raid issues

Carlos, Ryan

h1tw0 did not like being power cycled and the new RAID controller card stopped working again. It looks like we are going to have to recreate the raid again tomorrow.

DAQ instability

Dan, Jim, Dave

sadly we leave the system with an unstable h1fw0. Earlier in the day h1fw1 was unstable, then h1fw0 became very unstable. Dan did some QFS diagnostics, I did some NFS diagnostics, we cannot see any reason for the instablities, all NFS/disk access is well within bandwidth with no indication of packet/re-transmission errors.

Kissel started the charge measurements on the SUS ETMs this morning around 8am.  However, I just discovered that both ITM and the ETMx ISI's have been tripped since ~4am, so the ETMx data isprolly junk.  Boo.  Not sure why this wasn't addressed this morning.  ISI's are back up now.

The new idle state, which doesn't do anything (idle), was connected to both DOWN and READY. When the ISC_LOCK Guardian had DOWN requested, it would jump from DOWN to READY as it normally would, and then it would move to IDLE and back to DOWN and repeat. I just removed the path from READY to IDLE to stop this loop, but this makes getting to IDLE a bit akward since it has to pass through DOWN. Whomever made the state may want to reconsider the organization of the path, but this works for now.

   Topped off the PSL Crystal Chiller with 125ml of water. This is a normal top off after swapping the filters yesterday. Both chillers are running well.  

Added H1:SUS-ETMY_PI_OSC_DAMP_OSC_LINE2_COSGAIN and H1:SUS-ETMY_PI_OSC_DAMP_OSC_LINE3_SINGAIN to the exclude list and updated the channel list.

Added 138 channels and removed 56 channels (see attached).

All accumulators  were in good shape with little to zero drop in pressure since last checked--26 Jan 2016.

Of course you can't do this task without impacting the accumulators.  After checking the HAM5 return unit, the valve was leaking upon pulling the gauge and I could not get it to reseat.  The schraeder valve was replaced.  Several units lost more than the usual when the gauge did not come off the valve cleanly(quickly) and subsequently had to be rechanged.  There were several units which were marginal in January and although they were still in okay range, they were charged up to the top of the acceptable range.

The values have been recorded in T1500280 and I will update this on the DCC after today's HEPI maintenance.  Levels I suspect will be different after the full shutdown and additionally I'll do a thorough purge of the resistors which also could affect the Reservoir Levels.  Also, motor greasing is about a year old.

Talked to John about a CP7 Pump Level alarm we were getting.  He advised me to turn the 'Manual Setting' to 72%.

Note: According to Gerardo, who called back after John, he did not get an alarm notification by phone about this as he should have.  Someone needs to check the machine responsible for these calls.

J. Driggers, J. Kissel, J. Warner

While beginning recovery of the IFO, Jenne noticed that the Y arm fiber polarization was high (showing ~24% of input light rejected, where < 5% is where we want to be). We followed instructions similar to what can be found in the OPS Wiki. Since the percent-of-rejection channels are buried deep in the heart of the ALS MEDM screen jungle, I pulled the channels,
      H1:ALS-X_FIBR_LOCK_FIBER_POLARIZATIONPERCENT
      H1:ALS-Y_FIBR_LOCK_FIBER_POLARIZATIONPERCENT
into a StripTool, which made it easier to by-eyeball, hand-tune the value via the tiny CDS laptop we were using. Also, there's no rhyme or reason to which of the three knobs to use; we just slowly turned all the knobs in both directions until we started to see the rejected light value go down sub-5%. While there, we also brought the X-arm below 5%.

The fiber polarization tuning box was turned off once we were done. 

Summary

On Friday, Pcals were turned off for the June 3-5 power outage (LHO alog 27558).

• Today it was verified that PcalX and PcalY settings were restored with the default values stored in the SDF system.
• The PcalX laser was turned on with a switch on the MEDM screen and the power was set to 5.0 V (nominal). Then we closed the OFS loop.
• The PcalY laser switch was also set to ON and laser power was set to 5.0 V (nominal), but the photodetectors' (TxPD, OFS PD and RxPD) readings indicated that the laser was not on. Currently we are investigating the problem, for now the PcalY laser switch was set to OFF.

Details

After finding out that PcalY PDs are not measuring any power I went to the End-Y and checked following:

• all of the power switches on a PcalY modules are set to ON,
• all of the cables are properly connected,
• +12 / -12 V is coming to Pcal laser power cable,
• +24 / -24 V is coming to AOM driver power cable,
• all other power indicator LEDs on the front panels of the modules were on,
• Pcal laser is not on,
• Shutter is not powered (the power indicator LED on the shutter is off).

From this limited information and under the assumption that nothing is broken in the Pcal system, one of possible sources of the issue might be that control signals are not reaching the Pcal Interface module through an EtherCAT connector. The laser on/off and power level (5.0 V) signals should come through this interface (the Pcal Interface Chassis back-side board circuit is given in D1400149).

The issue in currently under investigation.

Related alog: 27053, 25468,

I updated the ETMY L3 stage digital compensation filters (FM2, FM6 and FM7 of ETMY_L3_ESDOUTF_{UL,LL,UR,LR}_GAIN) to the more accurate ones which are based on the recent measurements by Evan and Jeff. The coefficients are already loaded, but we have not gotten a chance to use the ETMY ESD yet.

To minimize possible errors for editing the foton file, I wrote a python script which automatically populate the filters, rather than editing the file by hand. The script is in the SVN at

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER9/H1/Scripts/SUS/setETMYLVVNcompensations.py