Not sure if this was looked at earlier in the day, but CP4 has been in alarm off and on since 7:44AM PT.
Plot attached shows MX, CP5, not in alarm, on the left, and MY, CP4, going in and out of alarm on the right.
Second attachment is the alarm log.
This is not normal behavior. Thank you for alerting me via text. TJ noted that CP4 generated an alarm yesterday morning too. The liquid level in the pump is sporadically noisy and causes the LLCV to jump up or down as a response. This noise seems to be real since we see it in the magnehelic pressure gauge at the pump. We will continue to monitor.
The DBB shutter was opened to allow for more jitter measurements. The measurements are:
There is clear correlation where the alignment with higher recycling gain has a higher jitter coupling. There also seems to be some thermal effect where the interferometer initially has a lower coupling.
The calibration of the DBB QPD jitter is just the inverse of the sum divided by 60 to account for the PMC transmission. The jitter measured by the IMC WFS DC was scaled by 1/3 to match the measurement when the IMC was unlocked.
Looking at the comparison of jitter during O1 and now (alog 30581) as measured by the IMC WFS DC, one might expect that the HPO jitter can explain all excess low frequency jitter below 70 Hz. This seems to work fine for pitch, but not very well for yaw. The coherence between WFS B DC yaw with the DBB QPD channels isn't higher than 0.3.
The effect of the alignment change on the DARM jitter coupling makes one wonder, if there isn't a Gouy phase conspiracy, where the coupling of the periscope peak is mostly independent. The Gouy phase difference between the periscope peak and the HPO jitter seems to be roughly 120°, if we believe the WFS DC readbacks. MC_F and REFL_SERVO_CTRL mainly see jitter peaks after the PMC. The auxiliary length dofs don't see much more than the periscope peak itself. Only DARM seems to be sensitive to the HPO jitter.
State of H1: in DC readout, measured a2l, NLN, measured a2l
Activities:
4:10pm local Took 2 min. to overfill from control room by increasing LLCV from 16% to 50%. I raised nominal to 17% for weekend.
first attempt stoped for file edit: 0:35UTC
running a2l, started at 00:36UTC
Jim is doing some testing/studies on the tilt ISO dofs. Please let these 10 diffs remain for now. Be mindful of other changes of course but none should come up.
Attached are the ISC relief to HEPI; units are nanometers. Finally, a complete tide cycle! If only we had the iLigo predictor running.
Looks like we had plenty of head room on HEPI but it is interesting that the Yarm never went negative like the Xarm. Not sure that means much at a day plus stretch. Maybe some initial grab residual. I expect it would start behaving after a few days lock
TITLE: 11/19 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Cheryl
SHIFT SUMMARY: 26.6hr Lock ended 30min before the end of my shift. While it was locked we ran a2L a few times and Commissioners did some work when they could.
LOG:
J. Kissel, D. Tuyenbayev Analyzing the high-frequency data for the UIM that we took last night (LHO aLOG 31601), we find -- as previously suspected -- there is lots of dynamical resonant features in the UIM / L1 actuation stage; it definitely does NOT fall as f^6 to infinity as one might naively suspect. There are even more features than the (now anticipated; LHO aLOG 31432) broad impacts of the violin modes of the Sus Point-to-TOP wires (~311 Hz), and UIM-to-PUM wires (~420 Hz). We had seen hints of these features previously (LHO aLOG 24917), but here they are fully characterized out to 500 Hz with a combination of swept-sine (SS) and broad-band (BB) transfer function ratios (the calibration standard measurements of PCAL2DARM = C / (1+G) and iEXC2DARM = C A_i / (1+G)). The measurements yield the actuation strength of the UIM stage, in terms [m] of test mass displacement per [ct] of drive from the L1_TEST_L bank, which is the Euler-basis equivalent to DAC [ct]. To scale to [m/N], is a mere scale factor, measured to be 20/2^18 [V/ct] 0.62e-3 [A/V]* 1.7082 [N/A] = 8.08e-8 [N/ct] (see LHO aLOG 31344). Via private communication in January this year, Norna suspects that 111 Hz feature is the first internal mode of the UIM blades, backed by a bench test of the blades at CIT which revealed a resonance at 109 Hz. No ideas on the 167 Hz mode though. These high frequency dynamics continue to plague the estimate of the UIM actuation strength at DC using the traditional frequency-dependent sweep method, because these high frequency dynamics begin to affect the actuation strength at as low a frequency as ~30 Hz (LHO aLOG 31427), and any model fitting code gets totally distracted by these features. A challenge to the CSWG team: fit this transfer function above 20 Hz and create a set of zeros and poles that can be used as a "correction" filter to a model that falls off as f^6. This filter need not perfectly resolve the details of all of the high-Q features, but it must track the overall frequency dependence over the 20 - 500 Hz region well. I attach all of the measurements compressed onto one (discontinuous) frequency vector as an ascii in the standard DTT form of [freq re(TF) im(TF)]. To use: >> foo = load('2016-11-17_H1SUSETMY_L1_Actuation_HighFreqChar_asciidump.txt') >> figure; loglog(foo(:,1), abs( foo(:,2)+1i*foo(:,3) )) This data is also committed to the CalSVN repo here: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Results/Actuation/2016-11-17_H1SUSETMY_L1_Actuation_HighFreqChar_asciidump.txt Kiwamu has already tried to create such a filter from the previous data (LHO aLOG 28206), but was limited by that measurement's high-frequency bound falling between the 111, 137, and 167 Hz features. Details: Analysis code: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Scripts/FullIFOActuatorTFs/process_H1SUSETMY_L1_HFDynamicsTest_20161117.m Config files: IFOindepPars = '../../../Common/params/IFOindepParams.conf'; IFOdepPars = {'../../params/H1params.conf'}; IFOmeasPars = {'../../params/2016-11-12/H1params_2016-11-12.conf'}; PCALPars = {'../../params/2016-11-12/measurements_2016-11-12_ETMY_L1_actuator.conf'}; Model: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/DARMmodel/src/computeDARM.m Will post the data for the fitting challenge later this afternoon.
I made an update to the quad matlab model to account for these mystery features. See CSWG log 11197.
I describe my use of the Frequency Domain System Identification toolbox (FDIDENT) to fit this transfer function in CSWG elog #11205. FDIDENT is a third party Matlab toolbox which provides tools for identifying linear dynamic single-input/single-output (SISO) systems from time response or frequency response measurements. The toolbox is free for non-profit use.
https://www.mathworks.com/products/connections/product_detail/product_35570.html
http://home.mit.bme.hu/~kollar/fdident/
A stable, but non-minimum phase, model without delay – compatible with a Linear Time Invariant (LTI) representation -- results in a best fit for a 22 order numerator and 28 order denominator model, m2228. The model is compared to the measurement data in the attached bode plot.
I attach several new parts of this high frequency characterization in order to facilitate incorporating the uncertainty in any future transfer function fitting. I attach three new text files: "..._tf.txt" -- a copy of the originally attached text file, columns are [freq re(A) im(A)] "..._coh.txt" -- an export of the (prefiltered) coherence, columns are [freq iEXCCoh PCALCoh] "..._relunc.txt" -- an export of the combined relative uncertainty on the transfer function, columns are [freq sigma_A] Computing the uncertainty on this actuation strength was a bit of a challenge. Remember, the above measure of the actuation strength of the UIM stage, A, is a combination of two transfer functions, as described in P1500248, Section V. In this aLOG they're referred to as "PCAL2DARM" where we use the photon calibrator as a reference actuator, and "iEXC2DARM" where the suspension stage under test is used as the actuator. Typically, the iEXC2DARM transfer function has the lowest coherence. Even worse, I've combined many data sets of both transfer functions covering different frequency regions each with a different number of averages. Thus form the uncertainty, I've taken each frequency region's data set, and - Filtered both iEXC and PCAL transfer functions for data points in which the iEXC TF has coherence greater than 0.95, - Created a relative uncertainty vector for each iEXC and PCAL transfer functions using the standard B&P equation, sigma_TF(f) / TF = sqrt( (1-C(f)) / (2 N C(f)) ) where C(f) is the coherence, and N is the number of averages (N was 10 for swept sine TFs, 25 for broad band TFs) - Concatenated the data sets to form the overall transfer function, A, - Combined the two uncertainty vectors in the standard way, sigma_A / A = sqrt((sigma_iEXC / iEXC)^2 + (sigma_PCAL / PCAL)^2) - Sorted the collection of [frequency complextf iexccoh pcalcoh sigma_A] by frequency. - Exported the uncertainty. Note that one only needs one column of uncertainty, for the absolute uncertainty in magnitude is just |sigma_A| = abs(A) * (sigma_A / A) and the absolute uncertainty in phase is /_ sigma = 180/pi * (sigma_A / A) I attach a plot of the magnitude and its uncertainty for demonstrative purposes, so that when the files are used, you can compare your plots of this against mine to be sure you're using the data right. Note that I've multiplied the uncertainty by a factor of 10 for plotting only so that it's visible. I've updated and committed the function that's used to process this data, and it can be found here: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Scripts/FullIFOActuatorTFs/ process_H1SUSETMY_L1_HFDynamicsTest_20161117.m
Ed M., T.J.
22:28UTC
ED M., T.J S.
A test candidate was sent. The Audible alarm announced in the control room at 22:03UTC. The H1 Operator Sign-Off on the GracedB system was entered as "NOT OK" Status and the comment was "TEST"
For the record: The GraceDB trigger used to do this test, https://gracedb.ligo.org/events/view/G262286 , is a fake trigger (and clearly labeled as such in the log) inserted into GraceDB by Mina Cho and Peter Shawhan with group="Burst" and pipeline="CWB2G". That's the same we we did periodic testing of control-room audio alerts during O1. In this case the H1OPS and L1OPS labels were added by hand.
J. Kissel There's been renewed excitement about the relationship between the 1083.7 Hz calibration line and the surrounding, non-stationary PSL intensity/jitter noise coupling into the sensitivity. Namely, DetChar has seen glitching "around the 1 kHz calibration line." I had looked at this relationship briefly a few moons ago (see LHO aLOG 31035) and concluded these features were unrelated, and did not impact the use of the 1083.7 Hz line due to the intensity/jitter noise's convenient double-peak shape. I had thought I'd run an on/off test during that study, but rather than dig up the history, I find it easier to just run a new on/off test. As such, I've turned OFF the 1083.7 Hz calibration line at Nov 18 2016 21:33:40 UTC, Nov 18 2016 13:33:40 PST, GPS 1163540037. If we survive the EQ that's now hitting as I type this aLOG, I'll leave it OFF for an hour or two.
WP 6328 This morning we turned ON filaments of RGAs at EY and corner......from the control room! Gerardo will set the IP address for EX to complete WP. I was disappointed to find that we cannot connect to multiple devices at one time to monitor multiple scans in RGA software. Contacted vendor about this. Analog signal monitoring via CDS will help (ECR 1600307).
We just needed the multiplexer software key so now we are connected to multiple RGA devices!
JeffK & HughR
This is to be ready for changes resulting from the A2L running on a regular basis. While at it I snapped a view of the TMs L2 Drive Align L2P filter banks.
These channels should probably be re-monitored. You've unmonitored the L2Ps, when it's actually the P2Ls (and Y2Ls) that will change when we run A2L. The P2L and Y2L gains are already not monitored for all the test masses. I have re-monitored the L2P gains.
Doh! Smackforehead.
Whoever is in the chair next when we have to relock (days from now I'm sure...), please:
Thanks a bunch - the past few days of everyone helping play this long timescale PI game has been super helpful.
When you say a2l, do you mean the trio of them or just the one original, main one?
Ya just the main one: a2l_min_LHO. Thanks Ed.
General comment for operators:
when you run a2l make sure you take the observatory mode to commisioning first, then you can put it back when the script finishes. This way we can avoid confusing people. Once we have SDF tied into the intention bit this would automatically drop us out of observing.
Beautifully high duty cycle over the past few says. Nice work team! Current Schedule Status: Frequency Planned Amplitude Planned Duration Actual Amplitude Start Time Stop Time Achieved Duration (Hz) (ct) (hh:mm) (ct) (UTC) (UTC) (hh:mm) --------------------------------------------------------------------------------------------------------------------------------------------------------- 1001.3 35k 02:00 39322.0 Nov 11 2016 21:37:50 UTC Nov 12 2016 03:28:21 UTC ~several hours @ 25 W 1501.3 35k 02:00 39322.0 Oct 24 2016 15:26:57 UTC Oct 31 2016 15:44:29 UTC ~week @ 25 W 2001.3 35k 02:00 39322.0 Oct 17 2016 21:22:03 UTC Oct 24 2016 15:26:57 UTC several days (at both 50W and 25 W) 2501.3 35k 05:00 39322.0 Oct 12 2016 03:20:41 UTC Oct 17 2016 21:22:03 UTC days @ 50 W 3001.3 35k 05:00 39322.0 Oct 06 2016 18:39:26 UTC Oct 12 2016 03:20:41 UTC days @ 50 W 3501.3 35k 05:00 39322.0 Jul 06 2016 18:56:13 UTC Oct 06 2016 18:39:26 UTC months @ 50 W 4001.3 40k 10:00 39322.0 Nov 12 2016 03:28:21 UTC Nov 16 2016 22:17:29 UTC days @ 30 W (see LHO aLOG 31546) 4301.3 40k 10:00 39322.0 Nov 16 2016 22:17:29 UTC Nov 18 2016 17:08:49 UTC days @ 30 W 4501.3 40k 10:00 39322.0 Nov 18 2016 17:08:49 UTC 4801.3 40k 10:00 5001.3 40k 10:00
The 1083.7 Hz calibration line was turned OFF for a brief period (~1-2 hours) during this current 4501.3 Hz stretch. See LHO aLOG 31610 for details.
1083.7 Hz calibration line restored just after the lock loss at 2016-11-18 23:30 UTC.
First attachment is the ASC changes accepted. All the ones accepted are gains that have been rounded off to 4 places rather than 10. I did miss one matrix value (circled) but I've corrected that in the file directly and reloaded that to the FE. The 23 remaining differences are filters, offsets and matrix changes requiring more scrutiny.
For the LSC, the same applies. There is one offset difference remaining--see attached.
The one channel remaining in the LSC SDF was H1:PSL-POWER_SCALE_OFFSET, which is changed by the LASER_PWR guardian as it changes the PSL power into the vacuum. This will be different every lock, so I have un-monitored it in the Observe.snap file. Also, TJ has changed the guardian to round it to 4 decimal places, which is more than plenty of precision.
Looking right now, everything left in the ASC SDF is stuff that is actively being worked on (SOFT offsets, input matrix for PRC2, etc), so we don't know yet what we'll run with for O2. These should all stay monitored.
All of the filters in the DC loops were notches that were turned on for a sensing matrix measurement, and should have been turned off. When I turned the notches off, the diffs went away, so we already had the correct settings accepted.
Thanks for the fine-tuning and details--just what we need for good control--Thanks Jenne--H
J. Kissel, P. Thomas, J. Warner We're having trouble get ALS locked after the corner station crashed this morning, so we took a look at the percentage of wrong polarization in the ALS fiber transmissions. Y was at an acceptable 2%, while X was a boardline 12%. Just to make ourselves feel better, Jim and Patrick adjusted and reduced the percentage to under 5% for both arms. Out of curiousity, to see how often this needs doing, I took a 1 year trend. I don't have much to say about the results, hopefully someone who knows more about this system can draw conclusions. Also, there is interest in moving the fiber polarization adjustment out of the CER.
A. Staley (posted by J. Kissel on her behalf) Alexa -- still looking out for us -- had sent me an email about the above trend. Thanks Alexa (and Zsuzsa for prompting her to look)! I quote it below: The fiber polarization controller drifted quite a bit -- Sheila, Evan, and I would post alogs about it keep track of the drift. There are a couple of things worth noting: We discovered that the fiber polarization controller creates a peak in the green locking noise at 27 kHz (LHO aLOG 10275). So we decided to keep the polarization controller off. We didn't spend time characterizing how much the wave plates would drift with the controller off. We ensured the drift/hysteresis of the polarization wasn't drastic over a period of a day or so, but were still expecting some drift over time. We also know that the fiber polarization drifts with temperature in the MSR (LHO aLOG 7023, LHO aLOG 11509) and the temperature is not very well controlled in that room. A bit unrelated, but I had also seen funny behavior with the motorized polarization controller (MPC) upon turning it off and on (LHO aLOG 11505). I am not sure if anyone went into more detail than that to characterize this drift or mitigate it -- it was always pretty trivial to adjust. The DCC has the manual (T1200496), which states the expected rotational drift of the wave plates over time--this is very small. Between that variation, temperature drifts, and drifts in the laser out SOP, I would expect some drift in the polarization. Again, I don't think this has been characterized or quantified and compared with the trends we've seen.