TITLE: 07/06 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Earthquake
INCOMING OPERATOR: Cheryl
SHIFT SUMMARY: Bad earthquake recovery
LOG:
See my log earlier. In addition to that recovery, we've spent the last four hours damping suspensions. Jeff got bounce and roll modes under control, we were working on violins at the last lock loss. No show stoppers, just annoying.
Also, Hanford Emergency called and the robot said not to use the regular emergency line. I didn't catch the office number it said to use, but for cell phone it said to use regular 9-1-1.
FAMIS 6530 Added 50 mL H2O to the crystal chiller. The fault light on the diode chiller is not lit and the water level indicator displays 'OK'. Both canister filters appear clear.
Still recovering from the earthquake, currently waiting for Jeff to damp down bounce modes in ALS diff. Corey had started, but there was no light visible on a lot of cameras (notably ALSX/Y had no spots), the AS spot looked bad.
What we've done so far:
1. Use the drift mon page looking back to the last lock to get most of the suspensions close. Corey had done some IMC alignment and the modecleaner was locked, so the MCs and IMs are not in exactly the same spots, but MC2 trans and IM4 trans were close.
2. ETM oplevs were way off, and the green WFS had no light on them, so we used the oplevs as a new reference and moved the ETMs until the green WFS were happy. ALS spots were still not visible.
3. We tried using the ditherAlign.py script, but it seemed to have only worked for TMSX & the script changes the TEST offsets (used for misaligning the quads) which caused problems for us later. Kiwamu & Keita think the TMSY alignment was too bad for even the ditheralign script to work. At the end of the dither of TMSY, we saw a spot move across the ITMY camera, so Kiwamu used that camera to find the ALSY spot and move TMSY to a rough alignment.
4. At about the same time as 3. we moved PR3 to recover the ALSX spot on the camera.
5. Similarly, we moved SR3 to recover that AS camera spot position.
6. Hand alignment of ALSX and ALSY (the usual ETM/ITM/TMS tweaking to get ALS TRX/Y power up to some level high enough to engage the loops). Then finish usual ALS initial alignment.
7. During input align, we restored PRM and SRM to their alignment from the previous lock. We then noticed fringey bad crap on the AS camera. This is when we realized/remembered that the ditheralign script changes the TEST OFFSETS on the ITMs. This needs to be changed because it made input alignment impossible, because ITMY was getting misaligned enough with the new offsets. We also had to temporarily increase the LSC Xarm loop gain. I think Kiwamu said by a factor of 2.
8. During PRM align we restored PR2 alignment from the previous lock.
9. Getting Mich dark locked required taking the ALIGN_IFO guardian down and doing a rough alignment of the BS, making the AS spot and smooth and round as possible before requesting Mich dark.
10. SRC align required a large realignment of SRM. The ASC wouldn't engage until the SRM was close enough, but we didn't have to do anything special. Request SRC align and pushed SRM around until the ASC grabbed it. It was difficult to see any improvements on the AS camera and SRM has to move a lot.
11. When we got back to locking, ALSY was being difficult and the camera loops was pulling the arm out of alignment. Jeff cleared the history with the script on the ALS overview, that seemed to fix it.
12. Jeff expected bounce modes to be high, so we spent ~1.5 hrs sitting on ALS diff while he gingerly damped them down.
After that, we had problems moving past ALS diff, so we re-did initial alignment. We're now at DRMI, moving to RF_DARM to see what other beasts are waiting for us.
DQ Shifter: Alan Weinstein, Email: ajw@ligo.caltech.edu
LSC Fellow: Paul Marsh, Email: paul.mecheng@gmail.com
Full summary is here.
at 08:01:00 PDT h1iopsusex reported a very long ADC holdtime of 77uS at 08:01:00 PDT. This caused the IOP to lose synchronization of its 18bit DAC channels and it reverted to the safe state of zeroing all DAC outputs. I restarted the IOP model, which of course required restart of all the SUS models. Jim first put the EX seismic into a safe state to allow this.
I verified the 18bit -DAC AUTOCAL reported success for all DACs, I reset the IPC errors and cleared the DAQ-CRC counters.
Here is the adc hold time information from /proc/h1iopsusex/status:
adcHoldTimeEverMax=77
adcHoldTimeEverMaxWhen=1183388478
here is the AUTOCAL data
[5393357.982766] h1iopsusex: DAC AUTOCAL SUCCESS in 5384 milliseconds
[5393363.341051] h1iopsusex: DAC AUTOCAL SUCCESS in 5346 milliseconds
[5393369.127216] h1iopsusex: DAC AUTOCAL SUCCESS in 5331 milliseconds
[5393374.485325] h1iopsusex: DAC AUTOCAL SUCCESS in 5346 milliseconds
[5393379.843006] h1iopsusex: DAC AUTOCAL SUCCESS in 5398 milliseconds
Created FRS Ticket 8458 for the record, but filled out details and marked it ready for closure.
TITLE: 07/06 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: EARTHQUAKE (recovery)
INCOMING OPERATOR: Jim
SHIFT SUMMARY:
Issue #1: IMC
A bit of a rough shift with recovery from a rare large earthquake in Montana keeping us down. Able to untrip Watchdogs within the first 90min or so, but a large part of the night was focused on restoring the basics from the ground up.
Getting the IMC to relock was not trivial. The first time I finally got it to lock I steered mainly the MC2, but after chatting with Cheryl she suggested I back out the change I made to MC2 and then focus instead on the PZT mirror (and then MC1, MC2 next). After restoring MC1-3 to their WITNESS values before the EQ, tweaked the PZT as much as I could for locking, but I then resorted to mostly using MC2 to get the IMC locked.
NOTE: With IMC locked, I do not see an MC Trans video spot (but AS AIR showed a 00 mode).
Issue #2: ALS....but probably alignment
Both ALSX & Y have low REFL A power.
Issue #3: SUSETMX Computer
Jim noticed that the ETMx had a computer issue. He is now on the phone with Dave addressing it.
Have left the OBSERVATORY MODE in Earthquake.
Input Mirrors Restored
Went though the recovery procedure for the IM mirrors after HAM2 SEI trips & they are now at their nominal values. (remember: These are downstream of the IMC...I always need to remind myself.)
IMC Status: Not Locking
As noted above, the IMC Refl video spot looked to be off in pitch & a little off in yaw with regards to the MC REFL camera (attached). I have to be honest that I don't know what the location of this spot looks like for a nominal state because the IMC usually quickly locks up.
After Clearing Histories (noted above), the IMC PZT values stepped to new values. (6-hr trend attached).
Approaching limit of what I can do without the help of an expert. My guess is that the PZT mirrors would be a remaining knob I have not tried, but I would prefer to NOT touch those mirrors without an expert. (Will go through alogs to see if I can find more help.)
TITLE: 07/06 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Earthquake
OUTGOING OPERATOR: Cheryl
CURRENT ENVIRONMENT:
Wind: 6mph Gusts, 4mph 5min avg
Primary useism: 0.31 μm/s
Secondary useism: 0.64 μm/s
Large & local EQ hit us an hour ago as Cheryl notes.
QUICK SUMMARY:
Most SUS & SEI systems are tripped. Also see RED DACKILL on CDS Overview for SUS. Observatory Mode was switched to EARTHQUAKE at about 7:20utc (but we've been in this state since 6:32utc).
8:21utc (1:21am) Update:
TITLE: 07/06 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 0Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY: locked, and then not - 5.8M in Montana
LOG:
Beat all of our sensors hear and looks like it's off the top of the seismic plot already.
Everything is tripped!
F-E Region: Montana
Time: 2017-07-06 06:30:16.5 UTC
Magnitude: 5.8
Epicenter: 112.32°W 47.06°N
Depth: 10 km
Status: A - automatic
20 day trend attached - changes in Y_QPD_A might be OK, but are larger than other changes in the plot
TITLE: 07/06 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 65Mpc
OUTGOING OPERATOR: Jim
CURRENT ENVIRONMENT:
Wind: 14mph Gusts, 12mph 5min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.06 μm/s
QUICK SUMMARY:
TITLE: 07/05 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 66Mpc
INCOMING OPERATOR: Cheryl
SHIFT SUMMARY: Relatively easy maintenance day.
LOG:
15:00 Karen to EY, JeffB & ChrisS to HAM6, Robert setting up injection in the corner, JohnW and Bubba to the roof
15:45 Richard to LVEA, Marc to LVEA
16:00 Fil to EY
16:15 Robert done, Jason doing HPO measurements, we were locked until Jason requested IFO down
16:15 Christina to EX
16:30 ChrisS to MY
16:30 Marc to mids/ends
17:00 Timing glitch kills EY, Dave restarts all EY models
18:30 Rick to EX
18:30 Starting initial alignment
19:30 We find SUS IM models are dead, Dave restarts remotely
20:43 Lockloss from reverting ASC-Y TR offsets to old values
21:14 Back Observing
After Kyle attempted to tighten HAM 11 and 12 south door bolts (they were already tight) last week, I leak checked the annulus again. Leak is still e-5 Torr-L/s of He range on HAM 11 south door. I didn't thoroughly check HAM 12 door again since background was high. Last week it measured e-7 Torr-L/s of He range. Connected aux cart and leak checker with hung turbos to HAM 11 and 12 and approached ~1e-5 Torr by noon. HAM 11 AIP still read overpressure with aux cart assistance. HAM 12 AIP read 6 mA range with assistance and 7 mA with aux carts valved out. I turned both AIPs off to preserve them, until we can vent the diagonal to remove and repair the door seals.
Looks like we replaced HAM 11 AIP in May AND Nov. 2016?!
https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=31724
SudarshanK, RickS
To study the downconversion of Pcal excitation we used a DB9 breakout at the back of the Pcal chassis and routed the excitation channel through H1:CAL-PCALX_WS_PD for now. This will be returned to its original configuration once the investigation is complete.
The PcalX is still fully functional and hardware injection can be carried out if needed. The WS_PD channel through which the excitation channel is routed is a spare channel that is only used during the end-station PD calibration.
Summary:
We have established that most of these down converted lines (the one that hurts us) reported in alog 36959 arise from the aliasing of the harmonics of the injected high frequency calibration lines. The lines that have the possibility to show up in the DARM are the ones that lie between 10 Hz to few hundred Hz. We can avoid these lines by selecting the high frequency calibration lines such that the aliased lines are not in the given low frequency region.
Details:
We ran into issues with low frequency lines (in 100 Hz range) showing up in DARM when we were running high frequency calibration lines in the region of 5.5 - 6 kHz. This was first noticed in this LHO alog 36959 and LLO alog 34346. To understand this problem we wanted to find where these lines were being produced, photon calibrator itself or the data acquisition system. We disconnected the cable that inputs the excitation to the Pcal electronics and used a DB9 breakout box to acquire the excitation signal so that we were getting these signal before it enters the Pcal system. We rerouted this signal through the H1:CAL-PCALX_WS_PD channel which was one of the unused Pcal channel.
The first plot shows the spectrum with a 5036 Hz excitation line (in blue) and without an excitation (in red). Some of the extra lines seen in the blue spectra are the result of aliasing of the higher order harmonics of the injected as well as the imaged lines (imaging happens when going from 16khz to 64 kHz). In this particular case the 68 Hz line is the aliasing of the 13th order harmonic of 5036 Hz injected line. The second plot shows the predicted aliased lines (based on harmonics and upsampling) that would be produced for 5036 Hz injected line. Some of the predicted lines show up in the actual spectrum but not all and not all line that are present in the spectra are predicted. However, the lines that show up above few hundred Hz will be well below the DARM signal as the actuation transfer function goes as 1/f^2. Shivaraj, at LLO has taken some additional measurement to see if we can find the source of all the aliased lines. Report to follow.
Tagging DetChar and CDS on this, so that the CW group can follow up with them to understand how to flag the data for this known issue.
RickS, SudarshanK,
The breakout box used to acquire the analog excitation signal on X-end Pcal has been removed and the Pcal configuration is now back to normal. During the visit, Rick repeated some measurement that reproduced the 86 Hz line when a Pcal line was injected at 5950 Hz with an excitation amplitude of 25000 cts. This measurement was made at the DAC (analog) output using SR785. The 86 Hz line is about 70dB below the injected line. This still does not explain why we don't see 86 Hz line in analog output in the measurement (LLO alog 34495) that Shivaraj made using Agilent signal analyzer. :(
On Jeff's request, I am putting down the empirical formula that predicts the lowest frequency down-converted lines for each high frequency excitation.
DCF = 2^16 - EF * n, where DCF is the down converted frequency, EF is the excitation frequency and n is the harmonic number. For frequencies around 4-6 kHz, the harmonic number that produces the line in the bucket are between 11 and 13.
I don't have a physical intuition on why this happens. If we were looking at the resampled 16 kHz signals, the presence of these lines would not be surprising because these would be produced because of aliasing but we see these low frequency lines on the DAC output, measured using the analog spectrum analyzer. Plots showing the same are attached.
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