A while ago I made a "complete" violin mode table here. Matt and Jeff was curious whether or not the frequencies belong to correct test mass. So, I went through the violin mode damping filters and see which one works and which doesn't. So far I was able to confirm that 24 out of 32 frequencies belong to the correct test masses. The filters were able to damp most of them. Three frequencies got rung up. The rest were still inconclusive (either the damping phases were off by 90 degrees or the test masses were wrong).

Below is the table of the violin mode damping filters used by Guardian and the frequencies they (supposed to) damp:

Both tables are included in the excel file attached below.

Guardian core upgraded to fix "double main" execution bug.

I have just installed a new version of Guardian core:

guardian r1449

It address the "double main" execution bug that was been has been plaguing the system.  See guardian bug 879, ECR 1078.

The new version is in place, but none of the guardian nodes have been restarted yet to pull in the new version.

You can either manually restart the nodes with 'guardctrl restart', or just try rebooting the whole guardian machine.  I might start with the former, to just target the important lock acquisition nodes (ISC_LOCK, etc.), and wait until Tuesday maintenance for a full restart of the Guardian system.

Chris S. Joe D.

The crew installed metal strips on the top of 350 meters of tube enclosure joints this week for a total of 1075 meters of enclosure from the corner station on the X-Arm. 

APOLOGIZES FOR NOT REPORTING FOR THE PAST WEEK

Scott L. Ed P. Rodney H.

This report will cover 7/13-7/17 dates inclusive.

 The crew cleaned a total of 358.7 meters of tube this week. Test results for the week also shown here.

 We added another generator that we had on site to the cleaning operation so the third man could be vacuuming the support tubes and pre-cleaning the egregiously dirty areas of the tube. This has seemed to increase productivity as seen by the almost 72 meter a day average.

Scott L. will be on vacation next week so to hopefully keep up with the current pace I am bringing out another Apollo employee who is very familiar with the site. Mark Layne will be filling in for Scott next week.  
 

These are NOT the cathodes used as interlocks for the high voltage.

For both end stations:
I logged into the Beckhoff computer. I went to the 'CoE - Online' tab for the Inficon gauge labeled 'Pressure Gauge NEG (BPG 402)' in the system manager. In index FB44:01, 'Emission ON / OFF Command: Command', I entered 00 02 in the Binary box. I then verified that index 6015:05, 'Input Hot Cathode Ion: Emission Status Off/On Module 2' had changed from TRUE to FALSE.

This was done around 11:35 PDT.

Richard will go to the end stations and verify that they are off on Monday.

Cheryl, Patrick, TJ, Ed

The ETMY LR RMS WD was tripped when I came in. I reset it by writing 0 and then 1 to it. Jim W. and I switched the ITMY, ITMX and BS ISI blends from Windy_90 to Quite_90. The mode cleaner was not locking because the input power was low. I had to do a search for home with the rotation stage. Spent most of the day keeping the IFO at DC power for commissioners. Reloaded Guardian a couple of times for script changes. 

09:18 Richard to roof
09:24 Jason and Peter taking diode box into PSL diode room
09:35 Richard off roof
09:43 Jason and Peter done
09:50 ETMX ISI WD tripped, indicated payload trip, but no WD trip on SUS or TMS
10:51 Richard to roof
11:35 I remotely turned off the cathodes at both end stations (WP 5363)
12:09 Pepsi truck through gate
15:44 Dave installing h1susetmypi model (WP 5365)
15:48 Jeff K. restarting h1susomc model (WP 5366)

Currently Stefan has the IFO and is working on ASC.

J. Kissel, S. Dwyer
WP #5366

Continuing to pursue OMC ASC diagonalization (see LHO aLOG 19691), I've made changes to the top level of the OMC SUS front end model such that the ISC signals go through the originally intended ISC path, i.e. through the ISCINF, LOCK, and DRIVEALIGN banks. This is such that we can *use* the drivealign matrix to decouple L, P and Y drive. I've made the change in such a way that this is only a top-level model change, and does not impact any library parts. Sadly this means that the implementation is rather ugly, but if the new scheme is successful, we'll submit an ECR to clean up the model and install the scheme properly during a maintenance day. 

I've saved, compiled, installed, restarted the model, confirmed that all settings have been restored as expected, confirmed alignment sliders at the same value, and that the "new" (or remapped) drive signals arrive in the expected banks as expected. Since the former paths were not disconnected, this change is entirely backward compatible; all previous alignment schemes will still work.

The development of the control filter implementation has now been handed off to Sheila.

Starting late last night the front end channel access freeze ups are now fairly regular and hourly (in the 30-40 minutes of the hour). In the past few hours they have only occured in the 37th minute of the hour. I have checked all the usual suspects (hourly rsync, autoburt, etc.) and not found any correlation so far. I have also checked Ganglia and Observium logs, no obvious computing or networking events happen at this time of the hour.

Matt found some data from last night that looks pretty good - I'm not sure what the state of the IFO was at this particular time, so I won't say.

Because of Robert's interest in the HAM6 ISI spring flexure to DARM coupling, I dug up a spare blade left over from aLIGO assembly and rigged it up on a table in the staging building. It's very rough, but intended only as a first look. Hopefully, Robert will attach his test results.

One of the corner station HEPI pumps is making noise and not putting out as much pressure as the others. Hugh would like to address it next Tuesday.

No suspensions work scheduled today or over the weekend.

Richard working on roof for PEM.

PMC alignment scheduled for next Tuesday.

Carpenter shop rollup door was left open.

Electric Health will look at malfunctioning LSB lift pumps.

Richard and Patrick to attempt to remotely turn off hot cathode gauges at end stations.

The following are a list of lock loss messages in the Guardian log. We've had a bunch of locklosses during the transition from locked to low noise this evening. As you can see there are a few different culprits, but one of the big ones is LOWNOISE_ESD_ETMY. It would be handy if someone can check out these lock losses and home in on what precisely went bad during this transition (e.g. ramping, switching, etc.). Then we can get back to SRCL FF tuning.

2015-07-17 06:47:05.694550  ISC_LOCK  LOWNOISE_ESD_ETMY -> LOCKLOSS

2015-07-17 06:48:22.162260  ISC_LOCK  LOCKING_ARMS_GREEN -> LOCKLOSS

2015-07-17 07:14:34.431170  ISC_LOCK  NOMINAL_LOW_NOISE -> LOCKLOSS

2015-07-17 07:26:40.249110  ISC_LOCK  CARM_10PM -> LOCKLOSS

2015-07-17 07:34:59.720030  ISC_LOCK  PREP_TR_CARM -> LOCKLOSS

2015-07-17 07:42:08.269350  ISC_LOCK  LOCKING_ALS -> LOCKLOSS

2015-07-17 08:02:41.773620  ISC_LOCK  LOWNOISE_ESD_ETMY -> LOCKLOSS

2015-07-17 08:21:58.665420  ISC_LOCK  LOWNOISE_ESD_ETMY -> LOCKLOSS

2015-07-17 08:31:29.035330  ISC_LOCK  REDUCE_CARM_OFFSET_MORE -> LOCKLOSS

2015-07-17 08:48:32.514870  ISC_LOCK  LOWNOISE_ESD_ETMY -> LOCKLOSS

We were locked at 24 Watts for just over 2 hours before we rang up a PI that shows up in the Y arm QPDs at 15734 Hz.  I increased the ring heater power (for both arms )from 0.5 to 0.6 Watts.  template with the QPD IOP channels is attached.  I tried to reduce the power, but we lost lock when I did that perhaps because the ISS second loop was on.  The lockloss was at about 3:00 UTC on July 17

I wrote the script for the OPLEV charge measurements which sets most of the settings and easy-to-use. It works for ~ 2.5 hours.
If you are the last person who leaving the LHO in the night - please, run it!

Instructions:
1. Set ISC_Lock state to DOWN
2. Set both ETMs to "ALIGNED" state
3. Align Optical levers (pitch and yaw) for both arms to 0 +/-.5 urad
4. Run the scripts: scripts directory is /ligo/svncommon/SusSVN/sus/trunk/QUAD/Common/Scripts
run the python files: ./ESD_Night_ETMX.py and the second script in another terminal: ./ESD_Night_ETMY.py

If it works, it:
a) In first ~ 30 seconds sets the channels and can warn about troubles with ESD or Alignment. If it happens - check this system and press 
b) During the measurements it should once a second print "Receiving data for GPS second: 1234567" 
c) After all the measurements it should restore all the settings back.

If it gives the errors but still receive some data - let it work.
If it obviously not work, you can try to run it again. If it does not help - please, restore all settings running ./ESD Restore_Settings.py . 

Due to it is first try, today I will be very thankful if you'll check after running the scripts :
1. L3 Lock:
   Bias Voltage - 0
   Offset - green light
   Ramp time - 5s
2. ESD linearization:    Bypass - ON
3. For ETMY:   turned on Hi-voltage driver.
Just in case: scripts modify only this settings.

Earlier today, I wrote a couple out of loop feedforward filters to the BS ISI foton file using Foton. When I hit the load coefficients button (while the ISI was isolated, the ff paths were off, so it shouldn't have done anything), the ISI tripped, hard. It rang up the T240's pretty bad and I couldn't isolate the ISI for several minutes after. Worried I had inadvertantly written some other filter I ran a diff on the most recent archived file and the file created yesterday when Jeff restarted the models. This showed a whole bunch of filter coefficient differences, which shouldn't have been there (as reported by a diff of the two archive files, I don't know exactly what changed, see attached). Talking to Jim, Dave and Jeff, it sounds like the glitch was probably caused by my having used Quack recently (June 22nd) to load some blend filters. Jeff's model restart (and even a prior model restart on June 30) simply inherited that quack-written file. Today was the first time the BS's foton file was opened and saved in Foton. Quack can apparently load coefficients with higher precision than Foton will accept, so when you open and save a "too high" precision filter with Foton, it rounds the coefficients off. Sudden change in precision of SOS coefficients in the blend filters = bad for isolation loops = bad trip.

We've seen this Foton vs. Quack Rounding problem before -- see e.g. https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=3553 -- and it's still biting us.

This sounds like a relatively easy thing to control for, I can think of two ways:

- getting Quack to check and do the rounding on it's own before writing to the Foton file.

- have the post-build script run a "foton -c" on all filter files before the model gets restarted.

Is there someone in the CDS group who can fix this? Maybe it has been? There are several versions of Quack running around, June was my first attempt with it, maybe I used the wrong one.

I used /ligo/svncommon/SeiSVN/seismic/Common/MatlabTools/autoquack.m

 https://svn.ligo.caltech.edu/svn/seismic/Common/MatlabTools/autoquack.m

Last Changed Author: brian.lantz@LIGO.ORG
Last Changed Rev: 7939
Last Changed Date: 2014-02-14 15:38:15 -0800 (Fri, 14 Feb 2014)
Text Last Updated: 2014-02-14 15:48:16 -0800 (Fri, 14 Feb 2014)