edmond.merilh@LIGO.ORG - posted 10:08, Monday 15 June 2015 - last comment - 10:06, Monday 22 June 2015(19147)
NPRO Tripped again
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.
Trend data suggests the laser tripped - for reasons unknown at the moment - just after 6 am.
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.
actually, the data from 9 am local time (16 UTC) should be considered suspect, the X end cleanroom has been on for part of this time.
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
The transfer functions that TJ measured for us have been renamed to be more obvious names as follows:
According to trend data, both mesurements seemed to have done at 17 W. The first file currently resides in aligocalibration/trunk/Runs/PreER7/H1/Measurements/DARMOLGTFs. The other one is in aligocalibration/trunk/Runs/ER7/H1/Measurements/PCAL_TRENDS.
By the way, according to what we had in the calibration svn, TJ must have accidently updated Jeff's DARM OL and Pcal Y sweep measurements with the above latest measurements. I restored Jeff's two measurements back to the previous revisions in the svn. So we now have both Jeff's and TJ's measurements checked in the SVN.
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.
I believe the 430 Hz wandering line is the same line Marissa found at 415 Hz (alog18796). Which turns out, as Gabriele observed, to show coherence with SRCL/PRCL.
Ross Kennedy, my Ph.D. student, implemented tracking of this line over 800 seconds using the iWave line tracker. Overlaid with a spectrogram, you can see that there is quite good agreement as the frequency evolves. We're working on automating this tool to avoid hand-tuning parameters of the line tracker. It would also be interesting to track both this line and PSL behaviour at the same time, to check for correlation. In the attached document there are two spectrograms - in each case the black overlay is the frequency estimate from iWave.
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
I took one more DARM OLG at 22.1 Watts, it is in the svn at /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Measurements/DARMOLGTFs/2015-06-14_H1_DARM_OLGTF_LHOaLOG191138_ETMYL3LPOFF.xml
The calibratinon is wrong at the moment, I think the OMC's automatic scaling during the hand off failed. Dan confirms that he's changed the order o power scaling / gain matching yesterday. On the phone with sheila, I measure the DARM OLG, to be a factor of 0.63 too low, so with her advice, I've rescaled the sensing gain (in the LSC input matrix) by that same factor, 13.20723*1.5737 = 20.78447 then reconfirmed that both the DARM UGF is correct, as well as the DARM ASD on the wall matches the reference, and we're back in the reasonable Mpc range of ~55 [Mpc]. I'm now taking the full DARM OLGTF sweep, and if that's successful, I'll get the PCAL sweep as well.
Just to clarify - while the DARM OLG did change due to the OMC-READOUT_ERR_GAIN setting, this wasn't due to edits to the OMC_LOCK code. It's not clear why the gain-matching calculation missed on this lock, it worked fine for subsequent locks. Looks like a one-off error.
I'm told this was intentional. I wasn't informed.
This was actually completely accidental. Peter and I went out to see if we could pull a log off of the NPRO UPS as part of our investigation into this morning's NPRO trip. Turns out that when you plug in a DB9 cable to the back of the UPS, the UPS shuts off. We did not know this. Now we do. Note to self...
In other news we were not able to establish communication between the laptop and the UPS, not sure why. Will continue to investigate.
That make me feel much better about not having gone out there alone to try it!