(Kyle, Gerardo)

Y-End station:
Connected and ran leak detector at turbo's exhaust in place of scroll pump, sprayed new, untested, conflats with 20 seconds of audible helium flow.
No leaks detected.
Turbo pump restored to original configuration.
Pump down continues.

Conflats tested: new Inficon gauge for ESD interlock, NEG pump 10" gate valve conflat only, Old TMDS valve + blank on middle port north door, New TMDS valve + elbow + blank on south door, and new blank for the removal of the old type gauge for ESD interlock.

Local controller shows correct voltage and current -> The signal wiring for this unit has never been correct since an additional terminal strip box was added to facilitate moving the original ion pump controller rack as required by the placement of the HEPI pump stations -> I'll consult with the EE folks

I've seen and noted this before.  It has been present since early Feb when the sensors were quieted and the noise dropped enough.

If you look at trends, there is a brief upward spike on all the pressure sensor channels at the EndY HEPI Pump System that occurs everyday at 0329utc +- seconds!.  Additionally, there is a weekly (Sunday) double glitch.  The first glitch of the Sunday double occurs at the same time as the daily and looks similar and a second (slightly different) hits 20minutes later followed by a downward glitch 10 minutes later.  Yes, every day and every Sunday.

The pressure does cause the pressure servo to react--see the CONTROL_VOUT.  The glitch is actually a 40 second climb of the pressure which the servo attempts to counter with a reduction of the drive output.  If the servo was driving the pressure, the sign would be reversed.

The glitches don't show in the position controllers or the inertial out of loop hepi sensors.  The Actuator performance must not be that sensitive to the absolute or differential pressure.  So, this really is not an IFO issue but we should figure out what is causing this.  This is not seen in the other Pump Station's pressures but they may be currently too noisy.

Attached are 2 hour second trends of the daily and weekly glitches.  Posting this here for the record and will open an integration issue.

Anyone else see anything at this time?

Danny Sellers, LLO Laser Safety Officer, unplugged and locked out the PSL HPO diode box power supplies to prevent the accidental activation of the High Power Oscillator. 

See photo. The appropriate laser safety documentation concerning the operation of the PSL is being reviewed and updated to reflect the implementation of this new administrative/ engineering control

Note: Having the HPO diode box power supplies off does not interfere in the operation of the 35W Front End laser. 

Also note that LHO made the same change today.

Don't forget laser goggles!

Posted below are the data from DB1, DB4, and 3IFO-DES-CAB long term storage cabinets. All data are with normal ranges and expected patterns. The dip in RH recorded for 3IFO-DES-CAB starting on 06/23/15 is from the Dewar being filled. Greater pressure in the Dewar meant more flow through the cabinet, resulting in a lower RH. In short, the cabinets are working as expected.     

maintenance day restart log:

model restarts logged for Tue 30/Jun/2015
2015_06_30 11:25 h1iopsush2b
2015_06_30 11:25 h1iopsush56
2015_06_30 11:25 h1susim
2015_06_30 11:25 h1sussrm
2015_06_30 11:26 h1iopsush56
2015_06_30 11:26 h1susomc
2015_06_30 11:26 h1sussr3
2015_06_30 11:26 h1sussrm
2015_06_30 11:28 h1iopsusb123
2015_06_30 11:28 h1susbs
2015_06_30 11:28 h1susitmx
2015_06_30 11:28 h1susitmy
2015_06_30 11:29 h1iopsush2a
2015_06_30 11:29 h1iopsush56
2015_06_30 11:29 h1susmc1
2015_06_30 11:29 h1susmc3
2015_06_30 11:29 h1suspr3
2015_06_30 11:29 h1susprm
2015_06_30 11:47 h1hpiitmy
2015_06_30 11:47 h1iopseib1
2015_06_30 11:47 h1iopsush56
2015_06_30 11:47 h1isiitmy
2015_06_30 11:47 h1susomc
2015_06_30 11:47 h1sussr3
2015_06_30 11:47 h1sussrm
2015_06_30 12:05 h1iopsush56
2015_06_30 12:05 h1susomc
2015_06_30 12:05 h1sussr3
2015_06_30 12:05 h1sussrm
2015_06_30 12:07 h1iopseib2
2015_06_30 12:07 h1isibs
2015_06_30 12:08 h1hpibs
2015_06_30 12:08 h1hpiham1
2015_06_30 12:08 h1hpiitmx
2015_06_30 12:08 h1iopseib3
2015_06_30 12:08 h1iopseih16
2015_06_30 12:08 h1isiitmx
2015_06_30 12:10 h1hpiham2
2015_06_30 12:10 h1hpiham3
2015_06_30 12:10 h1hpiham4
2015_06_30 12:10 h1hpiham5
2015_06_30 12:10 h1hpiham6
2015_06_30 12:10 h1iopseih23
2015_06_30 12:10 h1iopseih45
2015_06_30 12:10 h1iopsush34
2015_06_30 12:10 h1isiham2
2015_06_30 12:10 h1isiham3
2015_06_30 12:10 h1isiham4
2015_06_30 12:10 h1isiham6
2015_06_30 12:10 h1susmc2
2015_06_30 12:10 h1suspr2
2015_06_30 12:10 h1sussr2
2015_06_30 12:12 h1iopasc0
2015_06_30 12:12 h1ioplsc0
2015_06_30 12:12 h1isiham5
2015_06_30 12:12 h1lsc
2015_06_30 12:14 h1ascimc
2015_06_30 12:14 h1asc
2015_06_30 12:14 h1calcs
2015_06_30 12:14 h1iopoaf0
2015_06_30 12:14 h1lscaux
2015_06_30 12:14 h1oaf
2015_06_30 12:14 h1odcmaster
2015_06_30 12:14 h1omc
2015_06_30 12:14 h1pemcs
2015_06_30 12:14 h1susauxasc0
2015_06_30 12:14 h1sushtts
2015_06_30 12:14 h1tcscs
2015_06_30 12:24 h1iopsush56
2015_06_30 12:24 h1sussrm
2015_06_30 12:25 h1iopsush56
2015_06_30 12:25 h1sussrm
2015_06_30 12:26 h1calcs
2015_06_30 12:26 h1susomc
2015_06_30 12:26 h1sussr3
2015_06_30 12:50 h1lsc
2015_06_30 14:02 h1omc
2015_06_30 14:27 h1nds0
2015_06_30 14:28 h1nds0
2015_06_30 14:36 h1fw0
2015_06_30 15:57 h1broadcast0
2015_06_30 15:57 h1dc0
2015_06_30 15:57 h1fw0
2015_06_30 15:57 h1fw1
2015_06_30 15:57 h1nds0
2015_06_30 15:57 h1nds1
2015_06_30 15:58 h1nds0
2015_06_30 16:06 h1fw1
2015_06_30 16:50 h1broadcast0
2015_06_30 16:50 h1dc0
2015_06_30 16:50 h1fw0
2015_06_30 16:50 h1fw1
2015_06_30 16:50 h1nds0
2015_06_30 16:50 h1nds1
2015_06_30 16:55 h1broadcast0
2015_06_30 16:55 h1dc0
2015_06_30 16:55 h1fw0
2015_06_30 16:55 h1fw1
2015_06_30 16:55 h1nds0
2015_06_30 16:55 h1nds1

I reported suspisions about the ETF (Stanford) Seismometer that is now wired up as the STS2-A or HAM2 ground sensor.  That was ten days ago and here is another look from earlier this morning.  Pretty much same conclusion:  The ITMY and HAM5 units show very good coherence even though they are separated by 30meters.  The HAM2 & ITMY sensors are just a couple meters apart and they are no showing the coherence they should: and the HAM2 & HAM5 sensors coherence is similarly poor..

While the problem may be cable or setup (level or igloo rubbing) I suspect the unit itself.

BTL: Any word on these instruments from your experiences?

Morning Meeting

• Things have been going well
• New person on site. Welcome Jenny the Postdoc!
• ~1 week before ion pump HAM6

Safety Meeting

• Firework = Grass fire!
• busy road, 100+ degree. Tire pressure important when hot.
• If (car) heat goes up, reduce speed, turn off AC.
• Elk spotted on 240!

Happy Holiday!

h1sush56 18bit DAC upgrade

Dave, Jim

We swapped all 5 DAC cards in h1sush56 with the upgraded firmware versions. The DAC cards were moved within the IO Chassis left by 4 slots to distance them from the new DC power board (D1301004). The 4th DAC card failed its autocal. We replaced this card with a new one, and it also failed autocal. We swapped the 4th and 3rd cards to see if this is a card or slot issue, now the 3rd card failed autocal. We put another new card into the 3rd slot and this time the calibration worked, so two cards which fail autocal have been detected.

h1guardian0 reboot

Dave

I rebooted h1guardian0 because its load average had risen into the 30's. This time the load average started around 12 instead of 7 before, so Ganglia was immediately complaining about overloading. It has since risen into the 20's, so rebooting is now short term relief.

h1sush2b reboot

Jim, Dave

h1sush2b had frozen up around 6pm last night. It required a reboot, which we knew would glitch all Dolphin connected computers so it was delayed until today's restarts. When we rebooted it this morning, we then restarted all corner station SUS, SEI and ISC. This in turn performed the autocal of all 18bit DACs which we indended to do today.

PEM ADC DQ channels

Dave

General ADC channels for occassional PEM work are being written to the frame. I set their gains to 0.0 to ensure they compress out in the frame when not in use. I changed SDF accordingly.

h1lsc new filters

The pending filter module change for h1lsc was applied today after the Dolphin glitch. The filter module H1LSC_SRCLFF has a rolloffs fllter,  which moved from the 5th to 10th location within the filter module.

GRB/SN notification code

Dave

This code has crashed when the offsite networking went down. I upgraded h1fescript0 and restarted the code.

Leap Second

Stefan, Greg, Patrick, Jim, Dave

we tested that the CDS systems handled the leap second addition correctly. All systems did so, but surprisingly conlog crashed (Patrick is investigating). Greg confirmed frames and correct. Dave and Jim check NDS clients dtt and dataviewer.

I sent a small excitation into MC2 M3 LL last night (29/06/2015 22:37 UTC) and again today after the autocalibration was done (7/1/2015 00:35 UTC). 

The attached screenshot shows the voltmon channel, both before and after.  There isn't a clear difference, it seems like there could be a discontinuity at the zero crossing in both cases, but it is not obvious from the time series if things are better or not after the autocalibration.  

(jim nic)

We've implemented the ISI CPS -> MICH feedforward (MICH freeze). It was a fairly simple process:

We installed the feedforward coefficients that Ryan suggests in his writeup. These could be re-measured to potentially improve the subtraction.

Then we compared the spectrum of the feedfoward signal and the MICH control signal. We saw a relative gain of 188, so this was added to a filter bank in the feedforward path.

We added a 50Hz low pass to the feedforward path so we aren't injecting too much noise.

When the feedforward path is enabled, we have a reduction in the MICH control signal RMS by a factor of 2-3. See attached figure (reference traces are with FF turned off).

The CPS has a 9Hz feature. Jim says it's from HEPI. This is injected into the MICH control signal, but the change to the RMS is insignificant.

Also attached is the settings of the MEDM screens. Several of these are 'hidden' because they have only been autogenerated and not added to the main screens.

Finally, the easy way to turn on and off the feedforward is by setting the channel H1:LSC-CPSFF_GAIN to 0 (off) or 1 (on). It has a 10 second ramp.

Jun 30 16:59:59 h1conlog1-master kernel: [12118377.100031] Clock: inserting leap second 23:59:60 UTC
Jun 30 17:00:11 h1conlog1-master conlog: ../conlog.cpp: 301: process_cac_messages: MySQL Exception: Error: Duplicate entry 'H1:ASC-ODC_CHANNEL_OUTMON-1435708800004681820-3' for key 'PRIMARY': Error code: 1062: SQLState: 23000: Exiting.
Jun 30 17:00:12 h1conlog1-master conlog: ../conlog.cpp: 331: process_cas: Exception: boost: mutex lock failed in pthread_mutex_lock: Invalid argument Exiting.

Hugh and I went to HAM3 this morning to see if we could find the cause of the 23 hz line. Finding nothing at the chamber, we decided to start turning stuff off to see if we could get it to go away. Taking the ISI and HEPI down did nothing, but turning the suspension off made the line go away. I then started turning the SUS back on and as soon as I took MC2 to aligned, the 23hz peak showed up. Jeff said that it was likely the sat amplifier needed power cycled, so Hugh is filing an FRS and this is being handed off to Richard. Attached image shows HAM3 GS-13s between 20 and 30 hz. Red is from last night, when everything was on, blue is everything off, green is MC2 aligned (everything else off).  HEPI L4Cs and both SUS also saw the peak.