ISS is stable now and the REFSIGNAL is set to -2.12 for 6.5% AOM diff power

Visitors: Arnaud, Katie (SURF student), Ivan (STAR program) Gary T. and Danny S., Stefan from Columbia U(timing system), Curtis Rau (SURF Student)

SEI: General maintanance. Also supporting the Vent activities.

VAC: Kyle preparing for End Station vents. Doors should be off by this afternoon. ALS LASERS will need to be turned off.

SUS: Danny S and Gary T on site to assist with discharging tests masses and working on EX pitch issues.

FAC: Clean Rooms and Dust Monitors are running - second cleaning of End Sytations in progress. Beam Tube cleaning is on ongoing.

I think that's it?

This is a minor update to those discussed in log 18987. In addition to importing live damping filters from the sites into the model (with a 5 min delay), you can now request damping filters from a specific gps time. So svn up ../SusSVN/sus/trunk/QUAD/Common/MatlabTools/QuadModel_Production.

The requirements are the same for reading live damping filters: you must have nds2 and various corners of the noise budget svn on your computer. See the notes at the bottom of this log.

The model script, generate_QUAD_Model_Production, has instructions on how to run the model with all the various features. An example of generating a model with damping filters from a specific gps time is show here:

quadModel = generate_QUAD_Model_Production(frequency_vector,'h1etmy',[],0,true,'gps1118413940h1etmy',0,0,true,8);

* frequency_vector is some frequency vector you specify.

* 'h1etmy' is the customized H1 ETMY parameter file ('quadopt_fiber' is the general quad file). All other quads have parameter files now too, but h1etmy is the only unique one at this point.

* true (the first one) says you want damping

* 'gps1118413940h1etmy' says you want the damping filters from H1 ETMY that were running at gps time 1118413940. The 'gps' prefix is what triggers the flag to read from the given gps time.

* true (the second one) says you want violin modes

* 8 says you want the first 8 violin modes in the model (2 is the default if not specified)

I am not sure how this does foton file version control when reading the filters. It claims it is loading the foton file from the given gps time, but for all I know it is actually loading the current foton file and simply displaying the gps time you gave it. One of the noise budget experts may know more about this (the site filter reading code is adapted from the noise budget stuff, courtesy of Chris Wipf).

In general, let me know if any of these new feature do not work properly, or should be modified in any way. They have been tested on my laptop, but there could be something I have missed.

The generate script has instructions for setting up your computer to get the running damping filters from the sites (either live or from a gps time). This text is copied here:

> Follow noise budget SVN checkout instructions here

https://awiki.ligo-wa.caltech.edu/aLIGO/NoiseBudget

Checkout the following addpath paths:

svnDir = '../NbSVN/aligonoisebudget/trunk/'   (the '..' must be the same as for the SusSVN, e.g. /ligo/svncommon/)    

addpath(genpath([svnDir 'Externals/SimulinkNb/']))

addpath([svnDir 'Common/Utils/NoiseModel/'])

addpath([svnDir 'Common/Utils/'])

> Follow NDS2 install instructions here

https://wiki.ligo.org/viewauth/RemoteAccess

Matlab should be pointed to this version of liveparts.m:

../NbSVN/aligonoisebudget/trunk/Externals/SimulinkNb/SimulinkNb/liveParts.m

Came into the control room this morning to find that the laser had tripped.  Went to
see the Beckhoff PC and the status indicator showed "Power error (WD)" illuminated.
Not sure what caused the the reduction in power.  I do know that this morning the
lights in my office flickered a couple of times, which may or may not coincide with
the laser's power demise.  We will check the UPS log and see if it registered a switch
to batteries or something like that.

Scott L. Ed P.

6/11/15
Cleaned 43 meters ending 16.7 meters north of HNW-4-072.

6/12/15
Cleaned 30 meters ending 6.8 meters north of HNW-074.
Cleaning progress has slowed as we are trying to make as little noise as possible during ER-7.

Sheila, Dan, Evan

ETMY ring heater on, operating at 22 Watts input power

I turned on the ETMY ring heater with the same settings as the ETMX one, 0.5 Watts on the top and bottom.  Since then we've been locking with 22 Watts, we haven't had any long stretches but that is probably because of other activities.  

A2L tuning for test masses L2

I injected an excitation at 12 Hz into L2 of each test mass pitch and yaw, and tuned the A2L coefficents until the coupling became bilinear.  The gains that I ended up with are shown in the attached screenshots.  I also chanmged the ramp times on all of these filter modules and accepted all of these changes into SDF.  The gains may need to be retuned in the future but they seemed to stay stable over several locks today.  Screenshot attached. 

ETMX roll mode could be damped with AS 45Q Yaw

With the improvement in the sensitivity below 20 Hz, the ETMX roll mode was again more than an order of magnitude above the DARM noise floor.  We cannot improve anymore by increasing the damping gain using the AS 45Q pitch signals, the mode is now in the noise of those signals.  However, the AS 45Q YAW signals both see this mode with an SNR of better than 100.  Durring the vent we can expand the matrix used to send ASC signals to the suspensions so that we can try using YAW.  

SRCL FF

With the reduced noise from A2L the coherence with SRCL increased, so I made another attempt at SRCL FF.  Evan called and told me about a filter that he made last night, which is intended for use in feeding SRCL to ITMY L2.  I used this filter, and found that with a gain of -0.5 this works well. The second attached screenshot shows the coupling from SRCL out to DARM IN with no feedforward, and with the feedforward engaged.  The coupling is reduced by 6dB at 20 Hz, and more at ghier frequencies although the measurement lost coherence.  The last attached spectrum shows the sensitivity improvement due to both A2L and SRCL FF.  The calibration may be off here because the ESD drive strength changed.

The bad news is that we seem to loose lock a few minutes after engaging this feedforward, and we are having a good deal of difficulty relocking today. 

New nominal state for guardian,

I added a new state to the gaurdian, which does nothing other than check for lock.  It is called NOMINAL_LOW_NOISE, the index is 600, and I hope that we can add any additional states before it from now on, to minimize confusion.  Also, it is handy to have a state which does nothing.  

No inital alingment needed for 24 hours.

I came in this morning to find the IFO still locked, it had been locked for nearly 12 hours.  After it dropped lock (probably my fault) I didn't do any inital alingment, and I haven't done it since, so the alignment has not been done for about 20 hours now and things seem OK.  I think that over the engineering run we were probably doing inital alingment much more often than necessary, it would be good to keep track of how often we really need to do it.  

Locklosses in switching to DC readout

 We've had several TR_CARM locklosses and a new type of lockloss that seems to have shown up in the last 2 days, durring the switch over to DC readout. Dan and I commented out the DARM boost that gets tured on as the first thing in the DC_READOUT state of the ISC_LOCK guardian, we are engaging it by hand after the transition for now.  unclear...

1315 hrs. local -> Leaving site now

Kyle enterd the X end VEA at 17:00 UTC, according to Gerardo.  I set the intent bit to commisioning a few minutes later, but the data should be considered potentially disturbed from 17:00 UTC.

model restarts logged for Sat 13/Jun/2015

no restarts reported

End of Engineering Run 7.

All was quite for my shift after the measurements. The range shows many glitches, but a nice, long lock. Keeping the Intent Bit on Undisturbed until Im told otherwise.

(times in PST)

0:04 - Locked @ LSC_FF, started PCAL swept line measurement

0:29 - PCAL measurment done, started DARM OLGTF measurement

0:50 - Both measurements done and no more for now it seems, Intention Bit set to Undisturbed

There were eight separate locks during this shift, with typical inspiral ranges of 60 - 70 Mpc. Total observation time was 28.2 hours, with the longest continuous stretch 06:15 - 20:00 UTC on June 11. Lock losses were typically deliberate or due to maintenance activities.

The following features were investigated:

1 – Very loud (SNR > 200) glitches
Omicron picks up roughly 5-10 of these per day, coinciding with drops in range to 10 - 30 Mpc. They were not caught by Hveto and appear to all have a common origin due to their characteristic OmegaScan appearance and PCAT classification. Peak frequencies vary typically between 100 - 300 Hz (some up to 1 kHz), but two lines at 183.5 and 225.34 Hz are particularly strong. These glitches were previously thought to be due to beam tube cleaning, and this is supported by the coincidence of cleaning activities and glitches on June 11 at 16:30 UTC. However, they are also occurring in the middle of the night, when there should be no beam cleaning going on. Tentative conclusion: they all have a common origin that is somehow exacerbated by the cleaning team's activities.

2 – Quasi-periodic 60 Hz glitch every 75 min
Omicron picks up an SNR ~ 20 - 30 glitch at 60Hz which seems to happen periodically every 70 - 80 min. Hveto finds that SUS-ETMY_L2_WIT_L_DQ is an extremely efficient (use percentage 80-100%) veto, and that SUS-ETMY_L2_WIT_P_DQ and PEM-EY-MAG-EBAY-SEIRACK-X_DQ are also correlated. This effect is discussed in an alog post from June 6 (link): "the end-Y magnetometers witness EM glitches once every 75 minutes VERY strongly and that these couple into DARM".  Due to their regular appearance, it should be possible to predict a good time to visit EY to search for a cause. Robert Schofield is investigating.

3 – Non-stationary noise at 20 - 30Hz
This is visible as a cluster of SNR 10 - 30 glitches at 20 - 30 Hz, which became denser on June 11 and started showing up as short vertical lines in the spectrograms as well. The glitches are not caught by Hveto. Interestingly, they were absent completely from the first lock stretch on June 10, from 00:00 – 05:00 UTC. Daniel Hoak has concluded that this is scattering noise, likely from alignment drives sent to OMC suspension, and plans to reduce the OMC alignment gain by a factor of two to stop this (link to alog).

4 – Broadband spectrogram lines at 310 and 340 Hz
A pair of lines at 310 and 340 Hz are visible in the normalized spectrograms, strongest at the beginning of a lock and decaying over a timescale of ~1 hr as the locked interferometer settles into the nominal alignment state. According to Robert Schofield, these are resonances of the optic support on the PSL periscope. The coupling to DARM changes as the alignment drifts in time (peaks decay beacuse the alignment was tuned to minimize the peaks when the IFO is settled.) Alogs about this: link, link, link.

There are lines of Omicron triggers at these frequencies too, which interestingly are weakest when the spectrogram lines are strongest (probably due to a 'whitening' effect that washes them out when the surrounding noise rises). Robert suspects that the glitches are produced by variations in alignment of the interferometer (changes in coupling to the interferometer making the peaks suddenly bigger or smaller).

5 – Wandering 430 Hz line
Visible in the spectrograms as a thin and noisy line, seen to wander slightly in Fscan. It weakened over the course of the long (14h) lock on June 11. Origin unknown.

6 – h(t) calibration
Especially noisy throughout the shift, with the ASD ratio showing unusually high variance. May be related to odd broadband behavior visible in the spectrogram. Jeff Kissel and calibration group report that nothing changed in the GDS calibration at this time. Cause unknown.

Attached PDF shows some relevant plots.

More details can be found at the DQ shift wiki page.

Times UTC

3:12 Locked LSC_FF @ 23W by request of Evan. Evan running measurments.

4:00 Lockloss.

6:00 Locked LSC_FF.  Still at 23W and Evan and Dan still taking measurements.

6:55 Back to LSC_FF @ 16W.  Starting remaining PCal and OLGTF measurements.

7:00 Handing off to TJ to bring ER7 home.

Times UTC

23:00 Still locked LSC_FF.

23:05 Jeff K taking OLGTF measurements and working on OMC calibration.

23:23 Jeff K taking PCal measuements.

0:05 Lockloss.  Appears to be due to EQ in Canada.

0:45 Lockloss on the way up at BOUNCE_VIOLIN_MODE_DAMPING. 

0:51 GRB/SN alarm.  Unfortunately, not locked at the time.

1:22 Paused locking sequence at DC_READOUT_TRANSITION so Dan can take some OMC measurements.

3:00 Dan done with measurements.

J. Kissel, T. Sadecki, D. Hoak, E. Merilh

As a last ditch effort to be able to recocile the calibration for the rest of the run, given the drastic change to the ETMY ESD, I've completed a DARM OLGTF, and also tuned and completed a PCAL EX to DARM transfer function. I got halfway through the same transfer function using PCAL EY, but the lock broke from some sort of seismic disturbance. The interferometer was at 17 [W] requested input power for all of the below measurements, I attach the relevant digital parameters that are relevant (sadly the list is growing! as so many things are changing!).

Analysis to come, but the measurements have been committed to the CalSVN repo here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Measurements/DARMOLGTFs
2015-06-13_H1_DARM_OLGTF_LHOaLOG19128_ETMYL3LPOFF.xml

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER7/H1/Measurements/PCAL_TRENDS
2015-06-13_H1PCALEX_2_DARM.xml
2015-06-13_H1PCALEX_2_DARM_stronger.xml

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER7/H1/Measurements/PCAL_TRENDS
2015-06-13_H1PCALEY_2_DARM_stronger.xml

For the PCAL sweeps, I've modified the following settings from what Sudarshan had set up (2015-06-12_pcal_sweep_X.xml in the same folder) such that (a) the measurement would complete in a reasonable amount of time, (b) we'd get coherence over the entire band of measurement, and (c) that the frequency vector would match the DARM OLGTF:
- Changed the frequency range to 5 to 5000 [kHz]
- Changed the frequency vector from linear to logarithmic
- Changed the user-defined amplitude format to Envelope
- Increased the number of cycles to 25
- Increased the duration of a cycle to 1 [sec]
- Increase the drive strength in various frequency bands where there remained no coherence

15:58PDT

Jeff K in the control room wants to take a DARM loop open gain and correct the calibration. Will wait to go into science mode. Handing of to Travis.

We had four known reasons for having difficulty locking today, one is an unsolved mystery that might be hurting us more often than we realize.

• The BS limiter was off durring DRMI lock acquisition, this is turned on and off by guardian.  I've attached a screenshot of the gaurdian log.  The code should have returned true imediately after having turned off the limiter, and proceeded onto the next state, however, it ran the LOCK_DRMI_1F run again.  The requested state at this time was DRMI_1F_OFFLOADED, which means that this guardian should have moved onto the next state.  Is there a way to search the Guardian logs to see if we have had other instances of this?
  • we have seen this behavoir in the past, and Jamie suggested that this could have been because the state LOCK_DRMI_1F was requested.  I know that was not the issue today, but I changed the state so that it is no longer a requestable state anyway, since it should never be requested.
• The roll mode damping for ETMY was switched off at the output.  All the roll mode damping settings are now enforced by the guardian, using ezca.get_LIGOFilter().only_on.  

I reloaded both ISC_DRMI and ISC_LOCK guardians today, to incorporate these changes.  

• We had difficulty transitioning to ETMY ESD, evan is writting an alog about what we think is the solution
• Now the winds are quite high, the forecast says they will die down around 1 am.  

Good luck TJ!