I took a look at the scattering noise we see in all lock since last night .

I computed the band-limited RMS between 20 ans 120 Hz, and this is a good indicator of the scattering noise level. Then I looked at correlations with all suspension motions (using M0 and M1 signals, as Keita did for the OMC).

So I'm able to reconstruct the noise variation over time, using a linear combination of all the suspension signals and their squared values. However, I'm not able to pick point one single mirror which is moving more, as shown in the ranking of the most important channels for the BLRMS reconstruction.

I compared the suspension motion spectra from tonight (GPS 1123422219) and few days ago (GPS 1123077617). The most relevant difference is that all test masses YAW motion have now a large bump at 3 Hz. ITMY also has large lines at 0.45 and 0.63 Hz. Finally ETMY pitch shows a large line at 6 Hz and some excess noise above that frequency.

Not sure if all of this is really relevant...

   Checked the End-Y building and found no apparent problems with doors, doors seals, or penetrations into the building. Given general air quality (high winds, smoke, dust, and no rain) over the past few of weeks, spikes or upward trends in counts would not be surprising.

   At End-Y, there were 17 spikes over 1000 0.5-micron particles over the last 60-days. The 60-day trends do not show any upward slope. Over the last 24 hours, there were seven spikes over 1000 0.5-micron particle. There were seven recorded entries into End-Y during Tuesday’s maintenance window, at least one where the roll-up door open between receiving and the VEA was open. The 0.5-micron plot shows a sharp spike during the maintenance window, which trends upward, then drops. There is a second sharp spike last night/this morning. There is some coloration with the wind speeds during this period. The air filtration system takes several hours to clean the air within the VEA.

   The alarm level were set much tighter during the vent activities when chambers were open. They will be relaxed to the class-10000 levels for O1.       

Several things to keep in mind:

1). The 227b monitor at End-Y is archaic and not entirely dependable. It is slated for replacement.

2). The 227b samples for 20 seconds then multiples the sample by 30 to correct it to the standard 0.1CFM sample rate. Sample times of less than 60 seconds are known to be less reliable.

3). The VEAs are required to maintain a clean-100000 level. The dust monitors are set to alarm at less than a clean-10000 level. The counts recorded are well below these levels.

4). The reference particle size for a class designation is 0.5-microns not 0.3-microns. The 0.3 particle size counts tend to be 10x those of the 0.5 particle.

5). Based upon particle and air temperature trends the internal air filtration system is working properly when the doors are closed.    

End-Y Measured Particle Counts 08:09 through 08:23 08/12/015

DetChar has requested we generate the front end model ADC channel lists. This is a new RCG feature in which all the ADC channels a model uses are listed along with the name and type of the first connected part in the simulink model. This feature is in the trunk release of RCG and not available in RCG-2.9.6. To generate the lists I performed a "make -i World" in the trunk build area (taking care to save the H1.ipc file before and ensuring it was not modified). I then copied the files from their build area into the location these files will eventually occupy (/opt/rtcds/lho/h1/chans/adc/). I then copied these files over to the exports area of the web server for offsite access:

https://lhocds.ligo-wa.caltech.edu/exports/adc/adclist_11aug2015/

Note that the ADC numbering always starts from zero and is not necessarily the physical card number. For example, h1tcscs.mdl has two adc parts (called ADC0 and ADC1), which are card_num 2 and 3 (the third and fourth ADCs in the chassis). In the h1tcscs_adclist.txt file the cards are referenced as 0 and 1.

- commissioning / testing long locks all shift

- alginment investigation ongoing

--- good test to run today: with IMC locked, change IM(1-3) by some small amount, look for the change on IM4 Trans, alog results

- EY is dusty!

Some random commissioning tasks from tonight:

LSC rephasing

In full lock, the phases of POP9 and POP45 were adjusted to minimize the appearance of PRCL in POP9Q and the appearance of SRCL in POP45Q. Then the input matrix element for POP9I→SRCL was tuned to minimize the appearance of a PRCL excitation in the SRCL error signal. New settings attached.

We should take a sensing matrix measurement sometime soon.

LSC OLTFs

I took OLTFs of PRCL, MICH, and SRCL. The data are attached.

[I also did some noise injections into CARM for frequency budgeting purposes. Those are attached too.]

Front-end LSC triggering

Jamie and I started this a few weeks ago, and now it is completed.

There are occasions when the DOWN state of the ISC_LOCK guardian (which, among other things, turns off feedback to the suspensions) is not run immediately after a lockloss (e.g., because the guardian is paused or in manual mode). Therefore, Jamie and I set up the LSC trigger matrix so that PRCL, MICH, SRCL, DARM, and MCL are turned off if POP DC goes below 100 normalized counts. This is set in the DRMI_ON_POP state.

CARM gain redistribution in the Guardian

The state REFL_IN_VACUO now redistributes the CARM gain slightly in order to improve the noise performance of the CARM loop. This state has not been tested and has been left commented out.

Dan, Cheryl, Evan

Sometime after 6 am local yesterday, we lost the ability to have stable locks with full input power.

It's not clear what about the interferometer changed, but the symptom again seems to be a slow drift of the AS36→SRM yaw loop which causes a sudden lockloss after a few minutes at full power.

In the end we simply retuned the input matrix elements for this loop in order to keep AS90 and POP90 from drifting downward at high power.

Before, the matrix elements were

ASA36I→SRC1: −3

ASB36I→SRC1: +1,

and now they are

ASA36I→SRC1: −3

ASB36I→SRC1: +0.5.

This combination was not chosen particularly carefully, but it is good enough to get to high power. We may want to see if there is a better combination.

The attachment shows the behavior of the four AS36 signals during power up and the subsequent full-power lock.

10 day plot of dust at EY - do we know why EY is so dusty?

Annoying dust alarm at EY silenced with alarm level changes:

- old: 2000 (yellow, dashed line), 3000 (red dahsed line), note that EY routinely goes above these alarm levels

- new (not saved but running tonight): 5000 (yellow solid line), 10000 (red solid line)

Jenne, Sheila, Terra, Cheryl, Corey

Tonight we worked on some ASC (the wind was gusting to 30mph when we started this, the IFO locked just fine but the buildups were fluctating at low frequencies).  At first we wanted to check on CHARD.  We increased the gain for CHARD P by 6dB, and then were able to add a gentle boost (the same MSboost used in DHARD) to increase the gain at low frequencies.  The attched screenshot and template were measured at 3Watts, with the new configuration (which is in guardian) and the ITM oplevs on.  For an old measurement taken at 23 Watts see Evan's alog 19934

Jenne did a similar job for yaw, adding the same gentle boost, and including the 20dB in the guardian. Both the pitch and Yaw loops could have ugfs below 1 Hz as the power increases, but they should be stable.

Once we increased the power to 24 Watts, we found we weren't stable for more than 5 minutes.  This happened both before and after the CHARD changes.  We ran Hang's lockloss script which picked MICH ASC loops as a suspicous channel.  We locked at 15 Watts were we seemed to be indefintely stable, and measured both MICH loops.  They look fine, I'm just attaching them here so we have the templates. 

Roughly from last night (5:00UTC [10pmPT]), EY has been steadily increasing in dust levels (and obviously alarming constantly the whole time).  0.3um counts are over 10,000.  No other VEAs are seeing an increase in dust like this building.  I don't see a temperature increase.  Could a door be open?  HVAC issue?  Something burning? 

(Will send an email to Bubba, Jeff B, John)

V. Sandberg & R. McCarthy

The SUS-TMSX OSEM Satellite Box was driving a ~2kHz oscillation on its DC power line again. (See https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=20428) This time we replaced the satellite box.  Verified that H1:SUS-TMSX_M1_OSEMINF_RT_IN1 and H1:SUS-TMSX_M1_OSEMINF_SD_IN1 were behaving themselves.  Work was done during the interval 18:00 - 18:45 UTC (11:00am - 11:45am PDT).

Apologie: I failed to follow my own rules and neglected to notify the operator on duty before we left and changed out the satellite box at End X.  Shame and humiliation duly noted.  :-(  Fortunately, no damage was done.

h1susex re-install original computer WP5430

Dave, Carlos, Jim:

The original h1susex front end computer was re-installed at EX to fix the glitching seen with the newer faster computers. The script which was clearing the EX glitch errors has been stopped, any FEC errors will now latch on until cleared by the operator.

h1tcscs model change WP5422

Duncan, Nutsinee, Dave:

The new L1 TCS model was installed on h1tcscs. A new TCS_MASTER.mdl was used. The h1tcscs.mdl file was modified to: add the ez_ca_read parts to get TCS CO2 and Ring Heater channels from the Beckhoff computers (corner and end stations) into the model; add new inputs to the CO2 parts for RH input; add ODC output from the CO2 parts; add new ODC block; add SHMEM ODC sender (to be injested by h1odcmaster model).

I discovered that there is a naming mis-match in the Beckhoff Ring Heater channels in the corner station slow controls system. There is no mismatch in the end station Beckhoff systems. I modified h1tcscs use use the H1 names.

Conlog channel reconfiguration

Dave:

After the TCS, CAL and ASC model changes I rescanned the channel lists for Conlog. It still showed a disconnection for the Guardian LSC_CONFIG node, which I tracked down to a very out-of-date autoBurt.req file for h1guardian0 target. I updated the autoBurt.req file and reconfigured Conlog, it is now happy.

H1LSCAUX filter coeff load

Dave:

The h1lscaux model was reporting a modified filter file. I took a look and could not see any difference between the current file and the archived file. I pushed the coeff-load button to clear this.

DAQ Restart

Dave:

After the TCS, CAL and ASC model changes, the DAQ was restarted. There were no GDS frame broadcaster changes made today (ECR is pending).

Sudarshan, Gabriele

Today when the IFO was locked in low noise, we could see the 300-400 Hz peaks in the sensitivity again. Those are know to be due beam jitter caused by the PSL periscope.

We looked into the performance of the ISS second loop, which was closed at the time. The first strange thing that we can't understand is that both the in-loop and out-of-loop signals are dominated by a flat  noise background at a level of 1e-8 /rHz. We would expect the out-of-loop to be at this level, but the in-loop should be squeezed down by the larg loop gain.

We changed the ISS gain, anmd discovered that if we turned down the gain at the minimun (-26-20 dB with respect to nominal), and disengage both boost and integrator, the in and out of loop ISS signals got worse, but the sensitivity got better at the 300-400 Hz peaks. So out guess is that beam jitter on the ISS array is actually causing an excess sensing noise on the ISS diodes, which is then re-injected into the laser beam as real intensity noise when the ISS second loop is closed with high gain.

We tried briefly to optimize the centering of the beam on the ISS array. We couldn't find any spot better than the initial one in terms of power on the diodes. One possible strategy would be to move the beam into the ISS array with the IFO in full lock, and use the coupling of a PZT jitter line to the sensitivity as a figure of merit.

I looked into the glitches created by Robert's dust injections. In brief: some of the glitches, but not all of them, look very similar to the loud glitches we are hunting down

Here is the procedure:

1. select all drops of the range in the two hours of injection
2. for each one, load three minutes of data, compute the 30-300 Hz BLRMS and find the glitch tims as the maximum of the BLRMS peaks

In this way I could detect a total of 42 glitches. The last plot shows the time of each glitch (circles) compared with the time of Robert's taps (horizontal lines). They match quite well, so we can confidently conclude that all the 41 glitches are due to dust. The times of my detected glitches are reported in the attached text file, together with a rough classification (see below)

I then looked at all the glitches, one by one, to classify them based on the shape. My goal was to see if they are similar to the glitches we've been hunting.

A few of them (4) are not clear (class 0), some others (14) are somehow slower than what we are looking for (class 3). Seven of them have a shape very close to the loud glitches we are looking for (class 1), and 16 more are less obvious but they could still be of the same kind, just larger (class 2).

See the attached plots for some examples of classes.

Evan's script to automatically take frequency and intensity transfer functions is now running. 

As a reminder, the summing note B path was repurposed for this run. The interferometer won't relock unless we reconnect them. 

At 4:20 UTC we started changing the TCS X CO2 power from 0.23W to 0.4W. The rotation stage took us on some full circles, but by 04:23 we reached 0.4W. 

At 4:45 I increased the frequency noise drive by a factor of 5 to gain back coherence.

At 6:04 I decreased the power to 0.35W - trying to find the minimal frequency noise point. (The coupling sign had changed.)

At 6:34 I reduced it to 0.3W.