jeffrey.bartlett@LIGO.ORG - posted 13:32, Thursday 26 February 2015 (16951)
24 Hour OpLev Trend
Took 24 hour OpLev trend measurements.
Images attached to this report
Took 24 hour OpLev trend measurements.
Altough the high frequency is kind of screwed up by the wandering line, we can get some interesting information about the lower frequencies.
The full report can be found at the following address:
https://ldas-jobs.ligo.caltech.edu/~gabriele.vajente/bruco_1108981336/
The most interesting coherence is with SUS-BS_M1_ISIWIT_PIT_DQ, which seems enough to explain most of the noise up to 100 Hz. This is consistent with what Sheila told me, i.e. that we're not fully using BS ISI.
For those interested in the BruCo details, I managed to reduce a lot the time needed to analyze the data, basically with the following modifications: split coherence computation into the single FFT computations, to reduce redundancy; parallelize the computation and expcially the disk access using all available processors. This brought down the typical execution time to analyze 10 minutes of data from 8 hours to about 20-30 minutes. The new code is attached.
Here are all the files needed to run BruCo:
bruco.py: main file to execute, see inside for instructions and configurations
functions.py: some auxiliary functions are defined here
markup.py: a library to create HTML pages
bruco_excluded_channels.txt: list of all channels that must be excluded from the coherence computation
J. Kissel, K. Izumi,
Regrettably, I have to put this work on hold for the weekend, but it turns out calibration of the IMC in the new CAL-CS infrastructure will be more involved that I thought.
(1) I've managed to install the frequency dependence of the suspensions. Sadly, I've given up (once again) on developing an automated way to generate a photon design string from our matlab dynamical state space models of the suspension. Instead, I used zpkdata on the state space model, and by-hand-cancel all poles and zeros that were obviously the same (for some reason minreal can't do this for me). The end result is happily what I expect -- see first attachment.
Here're the final filters as implemented in foton, which have been stuck in FM5:
"M1toM3"
zpk([0.018585-i*3.410679;0.018585+i*3.410679;1.606379;0.044818-i*1.036165;0.044818+i*1.036165;
0.118436-i*0.689908;0.118436+i*0.689908],
[0.264197-i*3.085648;0.264197+i*3.085648;0.019394-i*3.411951;0.019394+i*3.411951;1.586567;
0.103907-i*1.688080;0.103907+i*1.688080;0.085448-i*0.524339;0.085448+i*0.524339;
0.043202-i*0.791714;0.043202+i*0.791714;0.043839-i*1.040618;0.043839+i*1.040618], 5.070123e+05,
"n")
gain(1.97234e-06)
"M2toM3"
zpk([0.018965-i*3.411371;0.018965+i*3.411371;0.383092-i*2.775995;0.383092+i*2.775995;
0.109233-i*0.626005;0.109233+i*0.626005;0.045076-i*1.037432;0.045076+i*1.037432;1.595790],
[0.264197-i*3.085648;0.264197+i*3.085648;0.019394-i*3.411951;0.019394+i*3.411951;1.586567;
0.103907-i*1.688080;0.103907+i*1.688080;0.085448-i*0.524339;0.085448+i*0.524339;
0.043202-i*0.791714;0.043202+i*0.791714;0.043839-i*1.040618;0.043839+i*1.040618], 2.394780e+03,
"n")gain(0.000417575)
"M3toM3"
zpk([0.019384-i*3.411943;0.019384+i*3.411943;0.268344-i*3.080800;0.268344+i*3.080800;1.587283;
0.119880-i*1.524350;0.119880+i*1.524350;0.105649-i*0.583444;0.105649+i*0.583444;
0.046372-i*1.036411;0.046372+i*1.036411],
[0.019394-i*3.411951;0.019394+i*3.411951;0.264197-i*3.085648;0.264197+i*3.085648;1.586567;
0.103907-i*1.688080;0.103907+i*1.688080;0.085448-i*0.524339;0.085448+i*0.524339;
0.043202-i*0.791714;0.043202+i*0.791714;0.043839-i*1.040618;0.043839+i*1.040618], 2.462902e+01,
"n")
gain(0.0406025)
Again, the design script can be found here:
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/MC2/Common/H1SUSMC2_GlobalTFs_to_Foton_20150224.m
(2) The DC gain of the actuation chain -- the M3 (optic) displacement in [m] per (M1, M2, M3) LOCK L drive [ct] gain of the actuation function have not been updated to reflect that we've increase the drive range of the M2 stage. So these should be recalculated.
(3) In the current calibration scheme, we use the error point * 1 / (the sensing function) + the control signal * actuation function. However, the IMC's sensing function will vary with input power, because it doesn't get normalized with ever level of input power. We need to think about how to continually compensate for the optical gain change due to input power change.
(4) In the calibration current scheme, where we use the IMC error point AND control signals to reconstruct the mode cleaner length isn't properly supported with the current LSC infrastructure. Namely, the error point of the IMC control loop is an analog signal that's *before* the control signal is split into the FAST and SLOW paths. See attached screenshot. The signal is already digitized in the LSC frontend, as "H1:IMC-I_OUT_DQ," but it is not sent over IPC to the CAL-CS model. Further, for the control signal, we need both the FAST and SLOW actuator paths (which *are* already sent to the CAL-CS model). So, if we want to continue with the new CAL-CS calibration scheme, we need send the output of the IMC_I filter bank to the CAL-CS model -- which requires a modification to the LSC model and to the CALCS model.
So.... more work to do on this than I had initially planned and hoped for. We'll get back to it on Monday. *Maybe* I can convince people to make the front end model change on next Tuesday.
I just pushed a patch to cdsutils (now r441) that includes improved CDSMatrix support:
See the built-in help for full documentation:
jameson.rollins@operator1:~ 0$ guardian -i
--------------------
aLIGO Guardian Shell
--------------------
ezca prefix: H1:
In [1]: from cdsutils import CDSMatrix
In [2]: help(CDSMatrix)
Last night we noticed, looking at the real time spectrum of DARM, that there was a wandering line. The attached spectrograms show the peculiar behavior: about every 270 seconds (not regular) this line enter the spectrum from the high frequency range and moves down in a quite repetible way (the frequency has quite perfect exponential evolution with time). Then there is some sort of burst of noise before the line starts again from the high frequency.
This behavior seems different from the wandering line related to IMC-F seen at Livingston.
I was just looking at the same feature. The burst of noise looks like a beatnote whistle, similar to what we saw at Livingston with IMC-F. At first glance, it looks like the whistle is occuring when the drifting signal crosses through the OMC length dither at 3.3kHz. I'm attaching a few spectrograms zoomed on to various levels to look more closely at the feature. The frequencies look discrete when you zoom in, it doesn't seem to be a continuous signal. Was there some kind of swept sine injection that was unintentionally left on during the lock?
I plotted a spectrum long enough to catch all of the frequencies of the signal as it swept down. The placement of frequencies seems more sparse at higher frequencies and becomes more densely packed as it dips below the kHz range.
The feature is visible in REFL signals as well, hinting in the direction of something going on in the laser. It's visible as well in LSC-IMCL and LSC-REFL_SERVO_ERR
This feature is showing up in MICH, SRCL, and PRCL. It's more faint in MICH, but is very strong in PRCL and SRCL. It's also showing up in the input to BS M3 LOCK filter for the length DoF, but it looks like MICH was being used to feed back on the BS position. I didn't see any evidence of the signal in MC2 trans, IM4 trans, IMC-F, or the IMC input power.
Problem solved: a SR785 was connected to the excitation input of the common mode board, and the excitation was on. We disabled the excitation input from the common board medm screen
The dmtviewer on projector0 used up all available memory on projector0 (it takes over a month to do this), so I rebooted the computer and restarted the dmtviewer display of seismic data.
End X PCal camera lost connection last night. The camera control software crashed and didn't detect the camera when I restarted the software. I went in to restart the communication unit this morning and that solved the problem.
Jason spotted the RefSignal voltage was 2.07V and Diffracted power was over 14%. I adjusted the RefSignal voltage to 2.13V bringing diffracted power to ~ 7.5%
model restarts logged for Tue 24/Feb/2015
2015_02_24 05:42 h1fw0
2015_02_24 09:03 h1lsc
2015_02_24 09:03 h1omc
2015_02_24 09:09 h1alsex
2015_02_24 09:09 h1iscex
2015_02_24 09:11 h1alsey
2015_02_24 09:11 h1iscey
2015_02_24 09:16 h1omc
2015_02_24 09:31 h1omc
2015_02_24 09:39 h1asc
2015_02_24 09:49 h1lsc
2015_02_24 09:51 h1susmc2
2015_02_24 09:56 h1calcs
2015_02_24 10:06 h1lsc
2015_02_24 10:14 h1asc
2015_02_24 10:19 h1susetmy
2015_02_24 10:19 h1susitmx
2015_02_24 10:24 h1susitmx
2015_02_24 10:26 h1susetmx
2015_02_24 10:28 h1oaf
2015_02_24 10:28 h1susitmy
2015_02_24 10:34 h1susbs
2015_02_24 10:38 h1dc0
2015_02_24 10:38 h1fw0
2015_02_24 10:38 h1fw1
2015_02_24 10:38 h1nds0
2015_02_24 10:38 h1nds1
2015_02_24 10:39 h1broadcast0
2015_02_24 12:01 h1pemex
2015_02_24 12:16 h1omc
2015_02_24 12:32 h1lsc
2015_02_24 12:35 h1omc
2015_02_24 12:52 h1pemex
2015_02_24 12:57 h1pemex
2015_02_24 13:34 h1broadcast0
2015_02_24 13:34 h1dc0
2015_02_24 13:34 h1fw0
2015_02_24 13:34 h1fw1
2015_02_24 13:34 h1nds0
2015_02_24 13:34 h1nds1
one unexpected restart. Maintenance day: work on ISC and SUS and CAL. PEM restart for RFM testing. Two related DAQ restarts.
model restarts logged for Wed 25/Feb/2015
2015_02_25 06:45 h1fw0
2015_02_25 10:18 h1fw0
two unexpected restarts.
04:57 Turned on the HEPA fans in the H1 PSL Laser Room. I would like to run this test for at least
a couple of hours.
It is noticeable that as soon as the fans are turned on, the minimum and maximum values of the
ISS percent diffraction vary by ~1%.
06:55 Turned off HEPA fans.
In running this test, I had forgotten that running the HEPA fans generates heat, and is not a good
idea without turning on the air conditioning. I switched on the air conditioning to bring the
temperature back down and switched it off after about 40 minutes.
Attached is the output of the quadrant photodiode that is located inside the power stabilisation
photodiode box. Assuming that DY is vertical and DX is horizontal, it appears that the vertical
alignment does not recover, whilst the horizontal alignment does.
Also attached is the reference cavity transmission signal during the same period. It seems to
recover.
Attached is the temperature rise during the period concerned. Of note is that the reference cavity transmission recovered whilst the pitch alignment into the power stabilisation photodiode box did not.
Sheila, Alexa, Gabriele, Evan
In addition to the differential ETM loops, we now have closed the common ETM degrees of freedom using REFLA9I + REFLB9I. These loops are slow, with bandwidths of a few tens of millihertz.
Previously (LHO#16883), we had closed loops around IM4 in order to reduce the amount of reflected light into REFL_A_LF. However, tonight we decided instead to close the common ETM DOF, so that the ETMs are nominally controlled in all four angular degrees of freedom. This (hopefully) leaves us free to pursue more loop-closing with the corner optics.
The common ETM loops are implemented in the CHARD filter modules. These modules are stuffed with the same filters as for their DHARD counterparts.
This is a screen shot of QPDs durring a well aligned lock tonight.
Since about 10:22 UTC Feb 26th, the IFO has been locked on DC readout with 4 ASC loops closed : DHARD PIT+YAW and CHARD PIT and YAW.
We are leaving this locked with the intent bit undisturbed.
For the records, ~3h lock
For this lock stretch the ETM ASC loop settings were a bit different from what I said above:
Gabriele, Sheila, Evan, Alexa
We now have new green alignment references for the WFS that should bring us to a better alignment while on resonance.
Now that we have enaged more ASC loops and touched up the alignment while on resonance (i.e. we acheived a recycling gain of 29), I have updated the green QPD offests and the ITM camera nominal positions in hope that this will improve our initial alignment. For reference, I have also included the old values that we have been using.
| Y-ARM | OLD | NEW |
| QPDA P | 0.0 | 0.3 |
| QPDA Y | 0.5 | 0.1 |
| CAMERA P | 229.9 | 216.5 |
| CAMERA Y | 315.2 | 302.6 |
| X-ARM | OLD | NEW |
| QPDA P | 0.0 | -0.08 |
| QPDA Y | 0.0 | 0.09 |
| CAMERA P | 248.3 | 241.3 |
| CAMERA Y | 354.8 | 369.6 |
Note: we had touched up the ITMX camera nominal position once before (LHO#16825). After one of our locklosses we ran the green wfs on the y-arm ONLY with this new configuration, and went through our inital alignment procedure. These new values seemed to be good. After another locklos, we then ran the green wfs on the x-arm to test this new configuration, and went through the inital alignment once again. This also seemed to be fine.