The current of the REFLAIR diode while in lock is about a factor of 10 below where shot noise is equivalent to dark noise.
In order to better understand the out-of loop behavior of the Common Mode loop, I did a lightbulb test on the REFLAIR_A diode. The thermal radiation from the lightbulb acts like a quantum limited light source at 9MHz.

The light was powered by a benchtop DC power supply. I mounted the bulb right in front of the diode and varied the DC light level (as seen by the REFLAIR_LF channel) and recorded the noise floor in the REFLAIR 9MHz demodulated channels. The whitening gain was temporarily changed from 12dB to 42dB for this test to overcome the ADC noise level.
The attached pdf file shows the noise vs current curve, and a fit. EDIT: apparently the LF channel is already calibrated in milliWatts. The 9MHz channel is not calibrated to physical units (though the calibration could be determined from the shot noise). As one can see, the light level we use in lock is about 10 times smaller than where shot noise starts to overcome dark noise.
REFLAIR also has an ND filter stack screwed directly on the diode box. Since we have so little light, maybe we should remove it.
data files
The amount of rf coming out of REFL9 in full lock (at 20+ W) is about −10 dBm, or 70 mV. It should be fine to switch over.
PCAL Laser were turned back on yesterday after the vent recovery at endstations and now the pcal calibration lines are turned on as well.
Sheila, Kiwamu, Chris, Hang
An update of LHO's noise budget is attached ('NB07082015.png'). It used the data from 06/07/2015, at 4:00:00 am UTC, whose predicted BNS inspiral range should be ~60 Mpc according to the summary page.
Some major updates are:
1. in SUS/ETMY, updated the ESD driver gain and the TST filter.
2. in LSC Digital, replaced the OMC Front End block.
3. in addition to those already existed 'mystery' gain blocks, some new ones were added. In order to make the NB predicted data match the measured ones (at least at high frequencies) while maintaining each DOF's open loop transfer function consistent with the measurement ('LoopGain07082015.png'), those blocks had to be added before the injection of quantum vacuum noises to have the proper suppression. This seemed indicating that the optickle model was not working perfectly?
4. A new front end calibration model was built to replace the old OAF.mdl. A comparison between the FE cal and NB was shown in 'FEcheck07082015.png'. In the plot all the blue curves were obtained from the FE Cal and green ones from the NB.
Besides, I also included two plots showing the coupling from MICH (SRCL) to DARM predicted by the NB model, which was generated by measuring TF from MICH (SRCL) control signal (in [ct]) to DARM sensor (in [ct]), then dividing it by the TF from DARM cal (in [m]) to DARM sensor, so the transfer function's unit was [m/ct]. See 'MICH2DARM07082015.png' and 'SRCL2DARM07082015.png'.
* 07/09/2015: font size increased. Sorry for the previous tiny font size...
After turning the HEPI loops on, noticed the drives to the ISI vertical Actuators are running about 10x higher than usual (compared to the other ISIs.) Based on the Isolation loops output, these appear to be primarily from the Z dof. I can't say how much displacement this represents but I'm sure the alignment will be fine if this offset where zero'd.
VE is done with climbing on the chamber and a lock loss provided a window. No issues unlocking and things look clear but I have not run a range of motion check. Maybe should be done but I'll think it can wait til Tuesday.
Alignment restored to historic position--that is, the reference/target position is unchanged.
Please mind the signs on the HEPI Housings
I've posted a note in the DCC with some information about our duty cycle durring ER7, and some of the causes of downtime.
https://dcc.ligo.org/DocDB/0120/T1500368/001/ER7DutyCycleNote.pdf
I will possibly update this with more information about DRMI locking durring high winds and when it is and is not necessary to wait for bounce and roll modes to ring down in the coming days.
Sheila, Elli
I moved the ITMs to improve the recycling gain, as well as the PRM. To get from a recylcing gain of just under 36 to 39 I mostly moved ITMY in yaw. This may be a different alignment than what we were using durring ER7, but it seems to be an improvement over the alingments we had yesterday, so we have updated references for now. The green alignment in the X arm did not change, but Elli and I redid the green QPD offsets and camera position for the Y arm. We lost lock and relocked allowing the ASC to engage with the guardian using these new IR QPD offsets, which was fine and brought us to a recycling gain of 39 again. For now the many people who want to do things incompatible with full locking have taken over the IFO.
Old offsets:
sheila.dwyer@opsws3:~/StripTools$ caget H1:ASC-Y_TR_A_PIT_OFFSET H1:ASC-Y_TR_A_YAW_OFFSET H1:ASC-Y_TR_B_PIT_OFFSET H1:ASC-Y_TR_A_PIT_OFFSET
In addition, ASC-Y_TR_B_YAW_OFFSET was changed from -0.237 to -0.318.
Elli, Hannah
To create a reference of the ITMX Green for locking.
Using singleImage_checkSaturation.m (/ligo/home/eleanor.king/scattering/singleImage_checkSaturation.m) we took images of the ITMX/Y Green cameras from ER7 ( /ligo/data/camera/archive/2015/06/05 "H1 ITMY Green (h1cam24)_2015-06-05-16-30-58.tiff" and "H1 ITMX Green (h1cam22)_2015-06-05-15-16-43.tiff)
Compared them with pictures taken today. (/ligo/data/camera "ITMY_green_illuminator_H1 ITMY Green (h1cam24)_2015-07-09-16-03-52.tff" and "IMTX_green_illuminator_H1 ITMX Green (h1cam22)_2015-07-09-16-03-43.tiff")
The cameras appear stable. We determined this by looking at the relative position of prominant features of the scattering.
FYI:
The lock-out on the L1 PSL is now released.
All conditions in the original memo have been met.
The release memo is here: https://dcc.ligo.org/M1500231
Kiwamu, Stefan
We noticed that in full lock (before power up) we again have questionable WFS. Indeed it seems to again be SRCL1 YAW that runs away - slowly at low power, but rapidly at high power. This is all a deja-vu, see elogs 18442, 18923, 18931.
More investigation suggested that it is actually the QPD loops that pull us into a regime where the other loops are not stable. So for now we changed the QPD loop offsets at low power to just keep us at the same location:
New values: H1:ASC-X_TR_A_PIT_OFFSET H1:ASC-X_TR_B_PIT_OFFSET H1:ASC-X_TR_A_YAW_OFFSET H1:ASC-X_TR_B_YAW_OFFSET
-0.084
-0.212
-0.023
0.006
Old values: H1:ASC-X_TR_A_PIT_OFFSET H1:ASC-X_TR_B_PIT_OFFSET H1:ASC-X_TR_A_YAW_OFFSET H1:ASC-X_TR_B_YAW_OFFSET
-0.029
-0.158
-0.007
0.105
However we still lost it on POWER UP. More work needed here.
We also reverted the changes from earlier today (alog 19511): ETMX ISCINF gain back to 1, and the L1 gain back to 0.28. This now gave us a lower peak-peak ESD drive and - unlike earlier today - ALS DIFF engaged just fine... (no idea why it acted up earlier...)
Evan, Nic, Stefan, Elli, Sheila
After spending some time to recover alignment, fiber polarization, turn TCS back on, ect, we have started to attempt locking.
The first problem we ran into was that ALS DIFF was not locking, the first problem we found was that the linearization was off. In addition, it seems that the ESD gain has been reduced by a factor of 2 after the vent and discharging. The attached screenshots show the OLG and crossover measurements with a factor of 2 added in drivealign, they match the references well this way. The green reference in the OLG measurement shows the gain when we managed to lock with the nominal settings from before the vent.
We have edited the guardian to add a factor of 2 gain in ETMX ISCINF, and reduced the L1 gain from 0.28 to 0.14 to keep the crossover around 1 Hz. The drives with DIFF locked are attached.
We were able to lock on DC readout, but Evan found that the DARM gain was 4dB too high, so he reduced the gain in the DARM filter bank to 900 from 1200. We made it to DC readout and lost lock durring the power up.
More charge measurements on ETMs. Plots are attached. Still no charges.
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)
we should use the readfoton script to read and plot the installed filter, i can do that
I suspect that the problem appears because a change (however small) in the filter coefficients causes the filters to reset (clear history, start over) and reset of the filter history = glitch in the output. It is easy to image this glitch being quite large for a ISI loop which is holding a static offset. I am working on an update to autoquack which will have it automatically call foton -c so that the filter updates happen in a deterministic way, and there is a log file telling you which filters have been touched.
filed ECR https://services.ligo-wa.caltech.edu/integrationissues/show_bug.cgi?id=1077 testing of possible solution, see https://alog.ligo-la.caltech.edu/SEI/index.php?callRep=789 -Brian
Following up this earlier report on pre-ER7 narrow lines in H1 DARM, attached is a corresponding list of early ER7 lines and some spectra for 30.5 hours of data from May 31 through June 4 at 13:00 UTC, based on FScans SFTs generated as of Thursday morning. Figure 1 shows the 0-2000 Hz spectrum for the early ER7 data with line labels according to the same scheme as before. Figure 2 shows the mid-May and early ER7 spectra overlain without line label clutter. Attachment 1 is the early ER7 line list (nearly identical in line frequencies but not strengths to that of mid-May) Attachment 2 is a zipped tar file of 27 sub-band spectra for early ER7 with lines labeled. Attachment 3 is a zipped tar file of 27 sub-band spectra comparing mid-May to early ER7 without labels. I haven't yet digested all of the changes from mid-May to the early ER7A data (what I call ER7A here), but here are things that are immediately apparent::
We used the coherence tool to try and see if there was a coherence between h(t) and other channels for this 36.9725 Hz noise line and its harmonics. There is a coherence between the h(t) channel and ... H1:PEM-CS_MAG_EBAY_SUSRACK_Z_DQ at 36.9725 Hz * 2 = 73.9450 Hz (definitely) 36.9725 Hz * 3 = 110.9175 Hz (barely above background) 36.9725 Hz * 4 = 147.89 Hz (definitely) 36.9725 Hz * 5 = 184.8625 Hz (above background) 36.9725 Hz * 6 = 221.8350 Hz (definitely) ... For whatever reason the even harmonics are stronger. The mat file for the coherence is here: https://ldas-jobs.ligo-wa.caltech.edu/~eric.coughlin/ER7/LineSearch/H1_COH_1116633616_1118275216_SHORT_1_webpage/data/H1:PEM-CS_MAG_EBAY_SUSRACK_Z_DQ_data.mat For H1:PEM-CS_MAG_EBAY_SUSRACK_X_DQ there is a coherence with h(t) at 36.9725 Hz * 4 = 147.89 Hz (barely about background) See https://ldas-jobs.ligo-wa.caltech.edu/~eric.coughlin/ER7/LineSearch/H1_COH_1116633616_1118275216_SHORT_1_webpage/data/H1:PEM-CS_MAG_EBAY_SUSRACK_X_DQ_data.mat For For H1:PEM-CS_MAG_EBAY_SUSRACK_Y_DQ there is a coherence with h(t) at 36.9725 Hz * 2 = 73.9450 Hz (barely above background) 36.9725 Hz * 4 = 147.89 Hz (above background) 36.9725 Hz * 5 = 184.8625 Hz (barely above background) 36.9725 Hz * 6 = 221.8350 Hz (above background) ... See https://ldas-jobs.ligo-wa.caltech.edu/~eric.coughlin/ER7/LineSearch/H1_COH_1116633616_1118275216_SHORT_1_webpage/data/H1:PEM-CS_MAG_EBAY_SUSRACK_Y_DQ_data.mat Nothing in the other magnetometers. Nelson, Eric Coughlin, Michael Coughlin
Attached is a pre-ER7 list of narrow lines seen above 5 Hz in recent H1 DARM data, along with spectra containing labels for the lines. The spectra used for line-hunting are from 18 hours of DC-readout conditions on May 17. Most of the lines were also seen in the early-May mini-run data, but are more exposed in the more sensitive May 17 data (see figure 1) Notable combs / lines:
I meant to attach the excited violin mode spectrum stack from the mini-run, not from the mid-May data, to illustrate the harmonicity of the upconversion. Here is the right plot.
We used the coherence tool on the full ER7 data to try and find coherence between h(t) and other channels for the 99.9989 Hz line and its harmonics. There is a coherence between h(t) and ... H1:PEM-CS_MAG_EBAY_SUSRACK_Z_DQ at 99.9989*1= 99.9989 Hz with coherence of 0.038 99.9989*2 = 199.9978 Hz with coherence of 0.03 99.9989*3 = 299.9967 Hz with coherence of 0.11 99.9989*4 = 399.9956 Hz with coherence of 0.11 99.9989*5 = 499.9945 Hz with coherence of 0.022 99.9989*10 = 999.989 Hz with coherence of 0.13 Similar results for H1:PEM-CS_MAG_EBAY_SUSRACK_X_DQ H1:PEM-CS_MAG_EBAY_SUSRACK_Y_DQ H1-PEM-CS_MAG_LVEA_OUTPUTOPTICS_X_DQ H1-PEM-CS_MAG_LVEA_OUTPUTOPTICS_Y_DQ H1-PEM-CS_MAG_LVEA_OUTPUTOPTICS_Z_DQ H1:PEM-CS_MAG_LVEA_VERTEX_X_DQ H1-PEM-EY_MAG_EBAY_SUSRACK_Y_DQ H1-PEM-EY_MAG_EBAY_SUSRACK_Z_DQ H1-PEM-EX_MAG_EBAY_SUSRACK_X_DQ H1-PEM-EX_MAG_EBAY_SUSRACK_Y_DQ H1-PEM-EX_MAG_EBAY_SUSRACK_Z_DQ The coherence is present but less strong in H1:PEM-CS_MAG_LVEA_VERTEX_Z_DQ 99.9989*10 = 999.989 Hz with coherence of 0.06 Not really visible in H1:PEM-CS_MAG_LVEA_VERTEX_Y_DQ We don't see this line in H1-PEM-EY_MAG_EBAY_SUSRACK_X_DQ H1-PEM-EX_MAG_VEA_FLOOR_Z_DQ H1-PEM-EX_MAG_VEA_FLOOR_Y_DQ H1-PEM-EX_MAG_VEA_FLOOR_X_DQ H1-PEM-EY_MAG_VEA_FLOOR_X_DQ H1-PEM-EY_MAG_VEA_FLOOR_Y_DQ H1-PEM-EY_MAG_VEA_FLOOR_Z_DQ Nelson, Eric Coughlin, Michael Coughlin