Kyle, Gerardo
Noticed that the pressure at X-End continued to climb after the power outage, we drove to X-End and found the controller on "standby mode", restarted the HV manually.
We then changed the controller settings for Auto HV Start to "Enabled".
We have begun recovery from an unexpected power outage that occurred at 7:44 PST and lasted for 3 minutes (as noted from the UPS).
These are the 60 day trends for the PSL crystal and diode chillers.
TITLE: Jan 19 EVE Shift 20:00-04:00UTC (12:00-20:00 PDT), all times posted in UTC
STATE Of H1: Locking
SUPPORT: Jenne and Sheila
INCOMING OPERATOR: N/A
SHIFT SUMMARY: Commissioning activities listed from previous log
ACTIVITY LOG:
00:33 Patrick cleared the HEPI accumulators
As per Sheila's request I have started to edit the IFO_ALIGN screen. This involves removing buttons that no longer work (ie. "Save Alignment" and "G"). She also expressed interest in have the border that illuminates while the slider values are ramping such as those in the "Optic Align" sub-windows from the individual SUS medm screens. i'm open to suggestions.
This afternoon I took measurements of the DHARD Yaw loop at different PSL powers. In addition to general characterization of the O1 IFO, I will use this data to verify the ASC loop model. Once we're confident in the loop model at powers that we can measure, we will use it to try to design ASC filters that we can use for high power operation in a few months.
In the first attached screenshot and .xml file, the measurement at 2 W is blue, the measurement at 10 W is orange, and the measurement at 20 W is red.
The 2 W measurement was taken at the DC_READOUT state, and only FM6 of the DHARD Yaw filter bank was engaged. This measurement was taken from a lock stretch earlier in the day, using 40 points at 3 avg each. In the xml file, the 2 W data is saved as references 0-4. In the second screenshot and .xml file, I include some higher resolution measurements of the peaks, with 5 avg for each point.
The 10 W measurement was taken at INCREASE_POWER, and both FM2 and FM6 were engaged. This measurement used 60 points at 5 avg each. In the xml file, the 10 W data is saved as references 5-9. I had modified the lscparams.py guardian code to stop the power increase at 10 W, but I have reverted that change, so everything should still be as normal.
The 20 W measurement was taken at INCREASE_POWER, and both FM2 and FM6 were engaged. This measurement used 60 points at 5 avg each. In the xml file, the 20 W data is the "live" traces.
The 10W and 20W measurements today are broadly consistent with the measurements from 31 July 2015 (alog 20084), which is good.
I have plotted yesterday's Dhard Yaw measurements against the ASC model that I have.
The ASC model seems to be missing some gain related to the laser power, since I need a different fudge factor for each input power to get the upper UGF of the model to match the measurement. This is probably a problem with the Optickle part of the model since that's the only thing that should change very significantly in overall gain as a function of power. The suspension model (which includes radiation pressure) shows the peaks from the lower stages moving to higher frequency with higher input power as expected.
In the individual plots (eg. 2W_only), I show the measurement (dark blue) with some error bars (light blue) derived from the measured coherence plotted against the model (black trace). The 10 W and 20 W measurements match the model pretty well (except for the gain fudge required), but the 2 W measurement doesn't match the model very well below a few Hz. I'm not yet sure why this is.
In the final plot attached, I show all 3 models (solid traces) and all 3 measurements (dotted traces), but without error bars to avoid clutter.
Robert, Sheila, Evan, Gabriele
I tried to look at one of Robert's injections from yesterday, and we noticed a dangerous bug, which had previously been reported by Annamaria and Robert 20410. This is also the subject of https://bugzilla.ligo-wa.caltech.edu/bugzilla3/show_bug.cgi?id=804
When we changed the Stop frequency on the template, without changing anything else, the noise in DARM changes.
This means we can't look at ISI, ASC, PEM, or SUS channels at the same time as DARM channels and get a proper representation of the DARM noise, which is what we need to be doing right now to improve our low frequency noise. Can we trust coherence measurements between channels that have different sampling rates?
This is not the same problem as reported by Robert and Keita alog 22094
people have looked at the DTT manual and speculate that this could be because of the aggressive whitening on this channel, and the fact that DTT downsmaples before taking the spectrum.
If there is no near term prospect for fixing the problem in DTT, then we would want to have less aggressive whitening for CAL_DELTA_L_EXTERNAL
I spent a little time looking into this and added some details to the bug report. As you said, it seems to be an issue of high frequency noise leaking through the downsampling filter in DTT.
Until this gets fixed, any reason you can't use DARM_IN1 instead of DELTAL_EXTERNAL as your DARM channel? It's better whitened, so it doesn't suffer from this problem.
The dynamic range issue in the whitened channel can be improved by switching to five zeros at 0.3 Hz and five poles at 30 Hz.
The current whitening settings (five zeros at 1 Hz, five poles at 100 Hz) produce more than 70 dB of variation from 10 Hz to 8 kHz, and 130 dB of variation from 0.05 Hz to 10 Hz.
The new whitening settings can give less than 30 dB of variation from 10 Hz to 8 kHz, and 90 dB of variation from 0.05 Hz to 10 Hz.
We could also use 6 zeros at 0.3 Hz and 6 poles at 30 Hz, which would give 30 dB of variation from 10 Hz to 8 kHz, and 66 dB of variation from 0.05 Hz to 10 Hz.
The 6x p/z solution was implemented: LHO#25778
At low frequency, DARM is coherent with many ASC and LSC channels. However, ASC channels are not uncorrelated to each other, and the same is true for DRMI LSC channels. So if one wants to use coherence to estimate how much of DARM is explanable with coupling from a set of auxliary channels, it is important to avoid over counting due to the cross coheence between the aux signals.
To cope with this, I wrote a multi-channel cohrence code, which takes into account the cohrence between the aux channels and estimates the total contribution of a set of correlated aux channels to a target channel. The attached script multicoherence.m does this in MATLAB.
I computed this multi-channel coherence (and the projection of noise into DARM) for DRMI LSC signals (plot 1) and all ASC signals (plot 2). In each of those plots, the top panel shows the total coherence of DARM with the set of channels being considered. This coherence is defined as (PSD_DARM - PSD_LINEAR_COMBINATION_AUX) / PSD_DARM and so gives an idea of how well the combination of aux channels can explain the noise we see in DARM. In each plot, the bottom panel shows a coherence-baed projection of the aux channels into DARM.
As expected, we see that the low frequency region of DARM (<20 Hz) is dominated by the sum of all ASC noises. Similarly, the LSC noises are not far from the measured sensitivity (as already known, we need a MICH FF retuning).
I attached a brief not describing how the multi-channel coherence is computed. This kind of computation is not new material, it's been around for a long time.
Reset counters in attached screenshot.
TITLE: 01/19 [DAY Shift]: 16:00-00:00 UTC (08:00-16:00 PDT), all times posted in UTC STATE OF H1: Left IFO at DC readout for Jenne to run tests. Jim's ISI blend filter changes are on all of the BSC chambers. SHIFT SUMMARY: Received SNEWS test alert at ~ 09:00 AM PDT (see attached). The verbal alarms script reported it as a GRB. SUPPORT: Jim W., Jenne, Sheila INCOMING OPERATOR: Ed ACTIVITY LOG: 15:45 UTC Richard set observing bit to commissioning 15:45 UTC Ken to end X air handler room to look at heater wiring 15:50 UTC Chris to X2 for beam tube sealing 16:11 UTC Chistina and Karen to end stations for cleaning 16:28 UTC Joe D. to LVEA to charge forklift batteries 16:30 UTC Ryan B. patching alog 16:47 UTC Filiberto pulling cables in LVEA (WP 5681) 16:56 UTC Kyle to mid Y (alog 25024) 17:05 UTC Karen and Christina from end Y to end X 17:12 UTC LN2 delivery 17:20 UTC Hugh checking HEPI fluid pump levels at end stations 17:26 UTC Joe D. done 17:42 UTC Karen and Christina done 17:45 UTC Jim W. loaded filter for ETMY ISI, filter not on 17:52 UTC Paradise water delivery 17:59 UTC Hugh done at end stations, going to mechanical room 18:04 UTC Ryan B. patching alog, bugzilla, svn 18:08 UTC Hugh done in mechanical room 18:11 UTC US Linen on site 18:14 UTC Ryan B. done 18:14 UTC Jeff B. to end X, end Y and mechanical room to attach fittings to dust monitor vacuum pumps 18:14 UTC Jason resetting PSL WD (alog 25021) 18:19 UTC Lock loss (reason unknown) 18:23 UTC Jason done, going to LVEA to retrieve equipment 18:26 UTC Jeff K. starting charge measurements on ETMX and ETMY 18:29 UTC Jason back from LVEA 18:41 UTC Kyle back from mid Y 18:41 UTC Karen to LVEA to clean 18:54 UTC LN2 truck leaving 18:56 UTC Joe D. to LVEA to unplug forklift batteries 19:08 UTC Jeff B. done 19:08 UTC US Linen leaving site 19:16 UTC Joe D. done 19:25 UTC Coca Cola truck on site 19:26 UTC Dan M. replacing faulty controller on gds-h1 in MSR (WP 5682) 19:42 UTC Jason to LVEA west bay to retrieve part 19:42 UTC Jim W. setting new filters on all BSCs 19:55 UTC Filiberto done for lunch 19:55 UTC Jim W. setting ETMX ISI to damped 19:57 UTC Dan M. done 19:57 UTC Jason done 20:29 UTC Starting lock acquisition to check Jim W.'s change to blend filters Lock loss on engaging BS ISI stage 2 21:13 UTC Locked at DC readout with Jim W.'s filter change. Jenne starting tests. 22:04 UTC Kyle to mid Y 22:07 UTC Filiberto and Ed to LVEA to pull cables Lock loss 22:33 UTC Kyle back 23:09 UTC Filiberto done 23:11 UTC Ken to midY to check grounding 23:33 UTC Ken done
JeffreyK, DarkhanT,
Summary
After taking another set of DARM OLG TF and PCALY to DARM TF measurements on Jan 7, 2016 (see LHO alog 24756) we compared the DARM actuation, sensing and OLG TF measurements against their models (the most recent similar analysis report was posted in LHO alog 24569).
As in the previous similar analysis we see that residuals of the actuation, the sensing and the OLG TF measurements vs. κC and κtst corrected DARM model are smaller compared to residuals against not-kappa-corrected DARM model.
This time we also produced residuals against the full kappa corrected DARM models (κpu, κtst, κC and fc). Sensing function residuals at higher frequencies and actuation function residualsat frequencies close to UGF,as we exptected, became smaller (closer to 1.0).
Details
We produced a comparison plots of DARM OLG TF and PCALY to DARM TF measurements taken during O1. For each of the TF measurements we also took "kappas" (DARM temporal variations) calculated from calibration lines close to times of the TF measurements.
For measurements taken on Jan 7, 2016 the kappa values used in the analysis are 30 minute average values (starting at GPS 1136215829) recorded about two hours before the TF measurements in H1_HOFT_C00 frames. Values were taken only at times when 0:HOFT_OK_BIT in online H1:GDS-CALIB_STATE_VECTOR was set.
par.kappa_tst = 1.059039;
par.kappa_pu = 1.019854;
par.kappa_A = 1.041371;
par.kappa_C = 1.002553;
par.fc = 335.351749; % [Hz]
Coherence of DARM OLG TF measurements at frequencies below crossover, ~30 Hz, is above 0.98, but an accuary of the DARM acutation function model at these frequencies is not very good, it can be seen on the DARM OLG TF measurement vs. all-kappa-corrected model residuals plot (page 9 of the attachment).
The parameter files for these measurements were committed to CalSVN at
CalSVN/aligocalibration/trunk/Runs/PostO1/H1/Scripts/DARMOLGTFs/H1DARMparams_1136225488.m
CalSVN/aligocalibration/trunk/Runs/PostO1/H1/Scripts/DARMOLGTFs/H1DARMparams_1136225488_kappa_corr.m
CalSVN/aligocalibration/trunk/Runs/PostO1/H1/Scripts/DARMOLGTFs/H1DARMparams_1136225488_kappa_corr_full.m
The comparison script and plots were committed to SVN at
CalSVN/aligocalibration/trunk/Runs/PostO1/H1/Scripts/DARMOLGTFs/CompareDARMOLGTFs_O1andPostO1.m
CalSVN/aligocalibration/trunk/Runs/PostO1/H1/Scripts/DARMOLGTFs/CompareDARMOLGTFs_O1andPostO1_full.m
CalSVN/aligocalibration/trunk/Runs/PostO1/H1/Results/DARMOLGTFs/2016-01-07_CompareDARMOLGTFs_O1andPostO1.pdf
Note that DCS/LDAS continues to archive raw (H1_R and L1_R) and aggregated hoft (H1_HOFT_C00 and L1_HOFT_C00) data 24/7. However, DCS/LDAS switched the directory location of the data from O1 to postO1 today at this time: 1137258496 == Jan 19 2016 09:07:59 PST == Jan 19 2016 11:07:59 CST == Jan 19 2016 17:07:59 UTC This switch will be transparent to users using gw_data_find or NDS2 to find the data, but in the directory path to the data, O1->postO1 at the above time.
Hugh worked on a script looking at the ISI T240 centering in alog 24902. I noticed on that list that ETMX had one T240 that had all 3 legs mis-centered. Eager for any straw to grasp on the ETMX ISI ring up, I took a couple of minutes to recenter all of ETMX's T240s. First I repeated Hugh's measurement, using his script from 24902, then I took the ISI down to Damped and opened all three of the T240 filter banks from the overview. I then clicked on FM6 (labeled AutoZ) on the first (X) bank for each T240 for several seconds. This triggers the T240's Auto-zero servo, which centers up the masses. I watched the readouts on the ISI overview and waited for them to settle down to below ~1000 counts, retook the centering measurement, then re-isolated the ISI. This fixed the centering of the out of range T240, according the to voltages Hugh's script read out.
My before measurement of the corner 2 T240 was:
ETMX T240 2 DOF X/U = -1.988 [V]
ETMX T240 2 DOF Y/V = -2.227 [V]
ETMX T240 2 DOF Z/W = -1.135 [V]
After, from Hugh's script is:
ETMX T240 2 DOF X/U = 0.084 [V]
ETMX T240 2 DOF Y/V = 0.065 [V]
ETMX T240 2 DOF Z/W = 0.097 [V]
Much better. It's entirely likely this doesn't matter that much, we'll have to wait and see. I've been watching ETMX all day and it hasn't really rung up, so far.
Today we had a Norco LN2 delivery -> The increase in dewar LN2 column height following the delivery was enough to over fill CP3 by itself (recall that the LLCV is kept 15% open in "MANUAL" mode) -> I went ahead and opened the exhaust check valve bypass and the LLCV bypass to confirm the CP3 is over filled -> closed valves -> OK Next over fill of CP3 is scheduled for Thursday, Jan 21st before 4:00 pm
Today I perfomed several broad-band noise injections to check how large the coupling of MICH, PRCL and SRCL noises are to DARM, and to check if they are stationary.
In summary:
Some more details follow.
While injecting noise in an AUX channel, if the coherence with DARM is good, we can estimate the linear transfer functon TF. Then we can check if the PSD of DARM during the noise injection matches the PSD of AXU times the transfer function: the two should be equal if the coupling is dominated by a linear term. If there is strong non-linearity or strong non-stationarity, the two can be different. This is the case for SRCL (fig. 6).
The plan for the next days is to repeat this same kind of tests with ASC degrees of freedom.
As a side note, while injecting PRCL and SRCL I caused two lock losses. In both cases I'm quite confident that nothing was saturating. However, after the aborted SRCL injection, we relocked and found a mode at 41.02 Hz largely excited (SNR ~ 1000). This mode is unidentified, but seems to roughly match the roll mode of the triple suspensions.
For future reference, attached the logfile of the injections.
Maybe the ring-up hints at the origin of one of the two lines near 41 Hz that we suspect is a roll mode of a triple suspension. This line is discussed in alog 21696 and its comments. We should check that the mode just below 41 Hz is not also rung up. I wasn't immediately able to find which times to compare - could someone post good times to look at?
The line at 40.X Hz was not excited by the injection. Only the line at 41.02 Hz was.
The line at 41.02 Hz was very large during the first lock right after 137193090 Mon Jan 18 14:57:53 PST 2016
TITLE: Jan 19 EVE Shift 20:00-04:00UTC (12:00-20:00 PDT), all times posted in UTC
STATE Of H1: Commissioning
DAY OPERATOR: Patrick
QUICK SUMMARY:
Arrived in time for Journal Club Exodus from the control room but managed to get some preliminary commissioning plans from a few folks.
JEFF K: Reports that he has nothing planned for himself for this evening
JENNE: To take measurements at 2. 10 and 20 W LASER power.; Also, sensing matrix measurement(s)
EVAN:
SHEILA: Darm/actuator/sensor Upconversion studies
ROBERT SCHOFIELD: Reports that he has nothing further to do. PEM injections/measurements are done and he will be going over his data. Any trouble that he would find with his measurements would be the only cause for a re-do.
IFO unlocked for ≈2 hrs prior to my arrival
0915 -0945 hrs local (ran QDP80 and purge air compressors) Recently, Bubba G. had cut out and welded a section of the turbo header in order to create pallet jack access beneath the BT in the Y-mid VEA. -> Now iems can be stored on either side of the BT without the need to crane heavy items over the BT -> Today I pumped purge air through the header for a while and then verified that there weren't any leaks -> Achieved 9.2 x 10-3 torr after 20 minutes -> OK
Evan, Kiwamu,
As some of us have already noticed, there is a broadband noise with a 1/f^{0.5} shape in frequency from 60 to 200 Hz. This noise is unidentified.
Do not believe any statements in this report until futher analaysis. Something is fishy with the claibration of the cross-spectrum.
We are planing to check how stable this noise level is over the course of the entire O1.
The below shows an example spectrum of DARM.
Blue curves are twenty spectra of DARM (aka C01 frame, converted into displacement), each of which is made by the Pwelch with Hanning, detrended, 50% overwrap for a 12 minutes time series. The data starts at a GPS time of 1134604817. Green curves are the square-root of twenty cross-power-spectra of DCPD A and B which are reconstructed from the sum and null streams of the DCPDs. The DARM suppression effect was removed from the sum signal. The cross-spectra are then calibrated to the displacement using the latest O1 DARM model of the calibration group. No time varying correction (i.e. kappas) is applied. Red line is a 1/f^{0.5} line to show how steep the slope of the green curves is. I also attach the fig file.
Gabriele, Evan, Kiwamu
There was a human-error in my code for calibrating the cross-spectrum. It was removing the loop suppression after the power spectrum of the null stream was subtracted from that of the sum stream. This was fixed such that the subtraction happens after the removal of the suppression in the sum spectrum. The below is the latest plot.
The plot shows the ampitude spectral desnsities of the calibrated darm displacement (aka C01) and the calibrated cross-spectrum. The cross-spectrum should represent noises which are coherent between two OMC DCPDs.
As a coarse verification, I have eye-ball-fitted the shot noise level with the fixed cavity pole frequency of 341 Hz (shown as a dotted line in cyan). Then I subtracted the shot noise component quadratically out from the actual displacement spectrum (in black). The residual (in blue) agrees with the estimation from the cross-spectrum. In order to check the slope of the cross-spectrum, I also drew a 1/f line. The cross-spectrum seems to follow 1/f from 50-ish Hz to 150 Hz.
The fig file is attached as well.
An update can be found in entry 25106
A higher resolution version is attached. The frequency resolution is set to 0.1 Hz, 50% overlap with Hanning for 1 hour data. No new findings.
The 1 Hz comb feature (see for example alog 24695) is becoming visible in 20-50 Hz. By the way, the legend in the plot is wrong.
Corey, Adam, We're just about to start a detchar safety injection.
We've finished this injection. I'll post a few more details shortly.
More Details: I injected the waveform from 'https://daqsvn.ligo-la.caltech.edu/svn/injection/hwinj/Details/detchar/detchar_03Oct2015_PCAL.txt'. The injection start time was 1136927627. The log file is checked into the svn - 'https://daqsvn.ligo-la.caltech.edu/svn/injection/hwinj/Details/detchar/O1/log_H1detcharinj_20160115.txt', although for some reason it only shows the start time.
The time noted in the alog entry is incorrect. The correct time from the log is 1136927267. The injections are visible at the corrected time.
J. Kissel, R. Savage, LHO Operators Tallying up the progress so far on the schedule of PCALX excitations at high frequency (see plan in LHO aLOG 24802): Achieved Planned Frequency Amplitude Start Time Stop Time Duration Duration Success? (Hz) (ct) (mm-dd UTC) (mm-dd UTC) (hh:mm) (hh:mm) (Yes / No, reason if no) ------------------------------------------------------------------------------------------------------------------------------ 1001.3 35k 01-09 22:45 01-10 00:05 01:20 01:00 Yes 1501.3 35k 01-09 21:12 01-09 22:42 01:30 01:00 Yes 2001.3 35k 01-09 18:38 01-09 21:03 02:25 02:00 Yes 2501.3 40k 01-09 12:13 01-09 18:31 06:18 02:00 Yes 3001.3 35k 01-10 00:09 01-10 04:38 04:29 04:00 Yes 3501.3 35k 01-10 04:41 01-10 12:07 05:26 06:00 Good Enough! 4001.3 40k 01-09 04:11 01-09 12:04 07:55 08:00 Good Enough! 4501.3 40k 01-10 17:38 01-11 06:02 12:24 12:00 Yes 5001.3 40k 01-11 06:18 on-going (as long as we can get) Thanks to all of the operators who have been dilligently caring for these lines while we sleep! For the record, while these PCALX calibration lines are on, the majority (if not all) of the range is consumed, so we cannot perform PCALX hardware injections.
I used the high frequency calibration lines injected above to estimate the sensing function at those frequencies. For this analysis, SLM Tool was used to obtain the line amplitude and phase of these calibration lines at different relevant channels.
Sensing Function = DARM_ERR[ct] / PCAL_TXPD[m]
The DARM_ERR signal is dewhitened and the PCAL_TXPD is corrected to get metres using the scheme described in G1501518.
Furthermore, ratio of GDS/Pcal is calculated and is included in the attached plot.
A data quality flag has been created to capture times when these extra PCAL lines were in the data. It is H1:DCH-EXTRA_PCAL_LINES:1 and a description of this flag can be found on the detchar wiki.
