Chris B., Jeff K. We performed a series of single-IFO hardware injections at H1 as a test. The intent mode button was off at the time. All injections were the same waveform from aLog 21744. tinj was not used to do the injections. The command line used to do the injections was: awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 H1-HWINJ_CBC-1126257410-12.txt 0.2 -d -d awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 H1-HWINJ_CBC-1126257410-12.txt 0.5 -d -d >> log.txt awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 H1-HWINJ_CBC-1126257410-12.txt 0.5 -d -d >> log.txt awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 H1-HWINJ_CBC-1126257410-12.txt 0.5 -d -d >> log.txt awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 H1-HWINJ_CBC-1126257410-12.txt 1.0 -d -d >> log.txt I've attached the log (log.txt) which contains the standard output from running awgstream. Taken from the awgstream log the corresponding times are approximates of the injection time: 1126916005.002499000 1126916394.002471000 1126916649.002147000 1126916962.002220000 1126917729.002499000 The expected SNR the waveform is ~18. The scale factors applied by awgstream should change the SNR by a factor of 0.2 and 0.5 when used. I've attached timeseries of the INJ-CAL_HARDWARE and INJ-CAL_TRANSIENT. The injections did not reach the 200 counts limit of the INJ_HARDWARE filterbank that we saw in the past. Watching the live noise curve in the control room we did not notice any strong indication of ETMY saturation which usually manifests itself as a rise in the bucket of the noise curve. But this needs followup. I've attached omegascans of the injections.
It looks like there's a pre-injection glitch in the last spectrogram. Is that understood?
There were no ESD DAC overflows due to any of the injections. The only such overflow was at 1126916343, which was between injections. The glitch before the last injection is not understood. It does not correspond to the start of the waveform, which is at GPS time ___29.75. The glitch is at ___29.87 (see attached scan), and I can't find what feature in the waveform it might correspond to. It may be some feature in the inverse actuation filter. We should repeat this hardware injection to see if the glitch happens again. Subsequent injections should be done with a lower frequency of 15 Hz (this was 30 Hz), to make sure there are no startup effects. This will only make the injection about 3 seconds longer. In the above, I'm assuming that the hardware injection is always synchronized to the GPS second, so that features in the strain file correspond exactly to what is injected, with just an integer offset. I confirmed that by looking at the injection channel, but someone should correct me if the injection code ever applies non-integer offsets.
If you run awgstream without specifying a start time, it chooses a start time on an exact integer GPS second. (On the other hand, if you DO specify a start time, you can give it a non-integer GPS time and it will start the injection on the closest 16384 Hz sample to that time.)
Note that these CBC injections were recorded by ODC as Burst injections (e.g., see https://ldas-jobs.ligo-wa.caltech.edu/~detchar/summary/day/20150922/plots/H1-ALL_893A96_ODC-1126915217-86400.png) because the CAL-INJ_TINJ_TYPE channel was left at its previous setting, evidently equal to 2.
I completed LALInference followup of these events. linked from https://www.lsc-group.phys.uwm.edu/ligovirgo/cbcnote/aLIGOaVirgo/150827092943PEO1%20parameter%20estimation%20procedure#Hardware_Injections
We have finished the hardware injection test. More details to come. Intent mode turned back on.
The intent mode button was turned off at 10:00 UTC. We are starting hardware injections now.
Folks have been complaining that the HAM5-ISI Rogue Excitation monitor is a pain. (see e.g. https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=21474) It looks like the coil-voltage-readback monitor for the V2 coil is busted somewhere, and so the monitor is sitting around -500 counts all the time. Hugh gave me the GPS time for a recent earthquake, and in the attached plot you can see the watchdog trip from normal (state 1) to damp-down (state 2) at T+3 seconds. The coil voltages come down pretty quickly. Then the WD goes to state 4 (full trip) about 3 seconds later and the coil drive monitors (except V2) get quite small. The rogue excitation alarm goes off about 3 seconds after that, because the V2 monitor has not fallen to abs(Vmon) < +100 counts. The V2 monitor just sort of sits at ~-500 counts all the time. I'm pretty sure the V2 coil drive is working, otherwise the HAM5-ISI platform would act very poorly. I'm guessing the problem is somewhere in the readback chain. Note - the channels I use for this are all Epics channels, so the timing is a bit crude and the voltages are sort of jumpy. The channels are: H1:ISI-HAM5_ERRMON_ROGUE_EXC_ALARM H1:ISI-HAM5_CDMON_H1_V_INMON H1:ISI-HAM5_CDMON_H2_V_INMON H1:ISI-HAM5_CDMON_H3_V_INMON H1:ISI-HAM5_CDMON_V1_V_INMON H1:ISI-HAM5_CDMON_V2_V_INMON H1:ISI-HAM5_CDMON_V3_V_INMON H1:ISI-HAM5_WD_MON_STATE_INMON I've also attached screenshots of the "coil drive voltage too big" calculation and the "rogue excitation alarm generation" calculation from the HAM-ISI master model
I've added integration issue 1127 on this https://services.ligo-wa.caltech.edu/integrationissues/show_bug.cgi?id=1127
I think I've got all the colors sorted out and pretty sure it looks like H2 Monitor isn't working either. At first I thought it was just zero on the plot but I don't think so. At least it won't cause this problem and being H2 may help find the problem.
Title: 9/21 Day Shift 15:00-23:00 UTC (8:00-16:00 PST). All times in UTC.
State of H1: Observing
Shift Summary: Locked for most of the first half of my shift until another EQ in Chile took us down. Took a few hours to ring down enough to relock. Relocked once for ~half an hour, lost lock, and relocked again. After performing initial alignment after the first lockloss, I noticed that the ALS-Y_DOF3 gains were once again set to 0.015 rather than 0.030. I reverted them in SDF.
Incoming operator: Jim
Activity log:
14:43 Ryan notices a prop airplane flying over the X arm.
17:53 Lockloss due to EQ in Chile.
19:30 Start initial alignment after EQ has rung down.
19:50 Start lock acquisition.
20:28 Visitor at gate to see Bubba regarding fire inspection.
21:00 ISS diffracted power is reported as being low. I adjust it back to ~8%.
21:55 Locked in Observing. Some work was done by Sheila on PRMI guardian during the downtime.
22:17 Lockloss. ITMx saturation.
22:30 Noticed H1ASC had a red box in the CFC column. Asked Sheila who said she had changed a filter. She loaded the coefficients which greened it back up. She then realized it was incorrect and changed it back. I reloaded the coefficients once again. Took IFO out of Observing Mode for a minute or two for this.
22:40 Lock in Observing.
22:57 DIAG_MAIN node in error.
Evan, Sheila, Travis,
Travis had a problem locking, for a reason that was at first mysterious, the OMC-ASC_MASTERGAIN was set to -0.05. We looked back and this has happend a few times in the last month. Evan looked into the OMC guardian and though that this could be because of a race condition between two cdsutils.ezcasteps in teh DITHER_ON state. We've added two sleeps that should prevent this in the future.
VerbalAlarms reports that DIAG_MAIN guardin node is in error.
Appears to be a standard NDS2 burp:
2015-09-21T22:57:59.11305 File "/ligo/apps/linux-x86_64/guardian-1485/lib/python2.7/site-packages/guardian/worker.py", line 459, in run
2015-09-21T22:57:59.11306 retval = statefunc()
2015-09-21T22:57:59.11306 File "/opt/rtcds/userapps/release/sys/common/guardian/SYS_DIAG.py", line 178, in run
2015-09-21T22:57:59.11307 return SYSDIAG.run_all()
2015-09-21T22:57:59.11307 File "/opt/rtcds/userapps/release/sys/common/guardian/SYS_DIAG.py", line 151, in run_all
2015-09-21T22:57:59.11308 ret &= self.run(name)
2015-09-21T22:57:59.11308 File "/opt/rtcds/userapps/release/sys/common/guardian/SYS_DIAG.py", line 136, in run
2015-09-21T22:57:59.11310 for msg in self[name](**kwargs):
2015-09-21T22:57:59.11311 File "/opt/rtcds/userapps/release/sys/h1/guardian/DIAG_MAIN.py", line 66, in PSL_ISS
2015-09-21T22:57:59.11311 diff_pwr = avg(-10, 'PSL-ISS_DIFFRACTION_AVG')
2015-09-21T22:57:59.11312 File "/ligo/apps/linux-x86_64/cdsutils-497/lib/python2.7/site-packages/cdsutils/avg.py", line 67, in avg
2015-09-21T22:57:59.11312 for buf in conn.iterate(*args):
2015-09-21T22:57:59.11313 RuntimeError: Requested data were not found.
Reloaded.
Having the guardian go into error because of an NDS2 hiccough is kind of irritating.
Based on this StackExchange answer, I added the following handler function to the DIAG MAIN guardian:
def try_avg(*args):
while True:
try:
q = avg(*args)
except RuntimeError:
log('Encountered runtime error while trying to average {}'.format(args[1]))
continue
break
return q
where avg is the cdsutils.avg function.
This is now used for the ISS diffraction and the ESD railing diag tests. If we like it, we should consider propagating it to the rest of the guardian.
This is a fine hack solution for this one case, but please don't propogate this around to all guardian NDS calls. Let me come up with a way to better handle it within the guardian infrastructure, so we don't end up with a lot of cruft in the guardian user code.
I edited the ASC DHARD Yaw filter. I added a less aggresive boost which we should be able to try engaging to see if we can ride out ground motion better (WP 5505). We won't try engaging this filter unless there is an earthquake on the way or if we are locked when LLO is down.
Locked in Observing Mode @ 22:40 UTC.
Lockloss @ 22:17. ITMx saturation?
Locked in Observing Mode @ 21:55 UTC.
We have approval to use the following waveform for testing the hardware injection infrastructure. We want to check that the ODC bits and logging for hardware injections is correct. The single-column ASCII file that can be injected is committed to the SVN. It can be found here: ASCII waveform file The parameters of the waveform can be found in the SVN as well: XML parameter file
It was noted recently elsewhere that there are a pair of lines in DARM near 41 Hz that may be the roll modes of triplet suspensions. In particular, there is a prediction of 40.369 Hz for the roll mode labeled ModeR3. Attached is a zoom of displacement spectrum in that band from 50 hours of early ER8 data. Since one naively expects a bounce mode at 1/sqrt(2) of the roll mode, also attached is a zoom of that region for which the evidence of bounce modes seems weak. The visible lines are much narrower, and one coincides with an integer frequency. For completeness, I also looked at various potential subharmonics and harmonics of these lines, in case the 41-Hz pair come from some other source with non-linear coupling. The only ones that appeared at all plausible were at about 2/3 of 41 Hz. Specifically, the peaks at 40.9365 and 41.0127 Hz have potential 2/3 partners at 27.4170 and 27.5025 Hz (ratios: 0.6697 and 0.6706) -- see 3rd attachment. The non-equality of the ratios with 0.6667 is not necessarily inconsistent with a harmonic relation, since we've seen that quad suspension violin modes do not follow a strict harmonic progression, and triplets are almost as complicated as quads. On the other hand, I do not see any evidence at all for the 4th or 5th harmonics in the data set, despite the comparable strain strengths seen for the putative 2nd and 3rd harmonics. Notes: * The frequency ranges of the three plots are chosen so that the two peaks would appear in the same physical locations in the graphs if the nominal sqrt(2) and 2/3 relations were exact.. * There is another, smaller peak of comparable width between the two peaks near 27 Hz, which may be another mechanical resonance. * The 27.5025-Hz line has a width that encompasses a 25.5000-hz line that is part of a 1-Hz comb with a 0.5-Hz offset reported previously.
We are looking for the source of the 41 Hz noise lines. We used the coherence tool results for a week of ER8, with 1 mHz resolution: https://ldas-jobs.ligo-wa.caltech.edu/~eric.coughlin/ER7/LineSearch/H1_COH_1123891217_1124582417_SHORT_1_webpage/ and as a guide looked at the structure of the 41 Hz noise, as seen in the PSD posted above by Keith. Michael Coughlin then ran the tool that plots coherence vs channels, https://ldas-jobs.ligo-wa.caltech.edu/~mcoughlin/LineSearch/bokeh_coh/output/output-pcmesh-40_41.png and made the following observations Please see below. I would take a look at the MAGs listed, they only seem to be spiking at these frequencies. The channels that spike just below 40.95: H1:SUS-ETMY_L3_MASTER_OUT_UR_DQ H1:SUS-ETMY_L3_MASTER_OUT_UL_DQ H1:SUS-ETMY_L3_MASTER_OUT_LR_DQ H1:SUS-ETMY_L3_MASTER_OUT_LL_DQ H1:SUS-ETMY_L2_NOISEMON_UR_DQ H1:SUS-ETMY_L2_NOISEMON_UL_DQ H1:PEM-CS_MAG_EBAY_SUSRACK_Z_DQ H1:PEM-CS_MAG_EBAY_SUSRACK_Y_DQ H1:PEM-CS_MAG_EBAY_SUSRACK_X_DQ The channels that spike just above 41.0 are: H1:SUS-ITMY_L2_NOISEMON_UR_DQ H1:SUS-ITMY_L2_NOISEMON_UL_DQ H1:SUS-ITMY_L2_NOISEMON_LR_DQ H1:SUS-ITMY_L2_NOISEMON_LL_DQ H1:SUS-ITMX_L2_NOISEMON_UR_DQ H1:SUS-ITMX_L2_NOISEMON_UL_DQ H1:SUS-ITMX_L2_NOISEMON_LR_DQ H1:SUS-ITMX_L2_NOISEMON_LL_DQ H1:SUS-ETMY_L3_MASTER_OUT_UR_DQ H1:SUS-ETMY_L3_MASTER_OUT_UL_DQ H1:SUS-ETMY_L3_MASTER_OUT_LR_DQ H1:SUS-ETMY_L3_MASTER_OUT_LL_DQ H1:SUS-ETMY_L2_NOISEMON_UR_DQ H1:SUS-ETMY_L2_NOISEMON_UL_DQ H1:SUS-ETMY_L2_NOISEMON_LR_DQ H1:SUS-ETMY_L2_NOISEMON_LL_DQ H1:SUS-ETMY_L1_NOISEMON_UR_DQ H1:SUS-ETMY_L1_NOISEMON_UL_DQ H1:SUS-ETMY_L1_NOISEMON_LR_DQ H1:SUS-ETMY_L1_MASTER_OUT_UR_DQ H1:SUS-ETMY_L1_MASTER_OUT_UL_DQ H1:SUS-ETMY_L1_MASTER_OUT_LR_DQ H1:SUS-ETMY_L1_MASTER_OUT_LL_DQ H1:SUS-ETMX_L2_NOISEMON_UR_DQ H1:SUS-ETMX_L2_NOISEMON_LL_DQ H1:PEM-EY_MAG_EBAY_SUSRACK_Z_DQ H1:PEM-EY_MAG_EBAY_SUSRACK_Y_DQ H1:PEM-EY_MAG_EBAY_SUSRACK_X_DQ H1:PEM-CS_MAG_LVEA_OUTPUTOPTICS H1:PEM-CS_MAG_LVEA_OUTPUTOPTICS_QUAD_SUM_DQ The magnetometers do show coherence at the two spikes seen in Keith's plot. The SUS channels are also showing coherence at these frequencies, sometimes broad in structure, sometimes narrow. See the coherence plots below. Nelson, Michael Coughlin, Eric Coughlin, Pat Meyers
Nelson, et. al Interesting list of channels. Though they seem scattered, I can imagine a scenario where the SRM's highest roll mode frequency is still the culprit. All of the following channels you list are the drive signals for DARM. We're currently feeding back the DARM signal to only ETMY. So, any signal your see in the calibrated performance of the instrument, you will see here -- they are part of the DARM loop. H1:SUS-ETMY_L3_MASTER_OUT_UR_DQ H1:SUS-ETMY_L3_MASTER_OUT_UL_DQ H1:SUS-ETMY_L3_MASTER_OUT_LR_DQ H1:SUS-ETMY_L3_MASTER_OUT_LL_DQ H1:SUS-ETMY_L2_NOISEMON_UR_DQ H1:SUS-ETMY_L2_NOISEMON_UL_DQ H1:SUS-ETMY_L2_NOISEMON_LR_DQ H1:SUS-ETMY_L2_NOISEMON_LL_DQ H1:SUS-ETMY_L1_NOISEMON_UR_DQ H1:SUS-ETMY_L1_NOISEMON_UL_DQ H1:SUS-ETMY_L1_NOISEMON_LR_DQ H1:SUS-ETMY_L1_MASTER_OUT_UR_DQ H1:SUS-ETMY_L1_MASTER_OUT_UL_DQ H1:SUS-ETMY_L1_MASTER_OUT_LR_DQ H1:SUS-ETMY_L1_MASTER_OUT_LL_DQ Further -- though we'd have to test this theory by measuring the coherence between, say the NoiseMon channels and these SUS rack magnetometers, I suspect these magnetometers are just sensing the requested DARM drive control signal H1:PEM-EY_MAG_EBAY_SUSRACK_Z_DQ H1:PEM-EY_MAG_EBAY_SUSRACK_Y_DQ H1:PEM-EY_MAG_EBAY_SUSRACK_X_DQ Now comes the harder part. Why the are ITMs and corner station magnetometers firing off? The answer: SRCL feed-forward / subtraction from DARM and perhaps even angular control signals. Recall that the QUAD's electronics chains are identical, in construction and probably in emission of magnetic radiation. H1:PEM-CS_MAG_EBAY_SUSRACK_Z_DQ H1:PEM-CS_MAG_EBAY_SUSRACK_Y_DQ H1:PEM-CS_MAG_EBAY_SUSRACK_X_DQ sound like they're in the same location for the ITMs as the EY magnetometer for the ETMs. We push SRCL feed-forward to the ITMs, and SRM is involved in SRCL, and also there is residual SRCL to DARM coupling left-over from the imperfect subtraction. That undoubtedly means that the ~41 [Hz] mode of the SRM will show up in DARM, SRCL, the ETMs and the ITMs. Also, since the error signal / IFO light for the arm cavity (DARM, CARM -- SOFT and HARD) angular control DOFs have to pass through HSTSs as they come out of the IFO (namely SRM and SR2 -- the same SUS involved in SRCL motion), they're also potentially exposed to this HSTS resonance. We feed arm cavity ASC control signal to all four test masses. That would also explain why the coil driver monitor signals show up on your list: H1:SUS-ITMY_L2_NOISEMON_UR_DQ H1:SUS-ITMY_L2_NOISEMON_UL_DQ H1:SUS-ITMY_L2_NOISEMON_LR_DQ H1:SUS-ITMY_L2_NOISEMON_LL_DQ H1:SUS-ITMX_L2_NOISEMON_UR_DQ H1:SUS-ITMX_L2_NOISEMON_UL_DQ H1:SUS-ITMX_L2_NOISEMON_LR_DQ H1:SUS-ITMX_L2_NOISEMON_LL_DQ The 41 Hz showing up in H1:SUS-ETMX_L2_NOISEMON_UR_DQ H1:SUS-ETMX_L2_NOISEMON_LL_DQ (and not in the L3 or L1 stage) also is supported by the ASC control signal theory -- we only feed ASC to the L2 stage, and there is no LSC (i.e. DARM) request to ETMX (which we *would* spread among the three L3, L2, and L1 stages.). Also note that there's a whole integration issue about how these noise monitor signals are untrustworthy (see Integration Issue #9), and the ETMX noise mons have not been cleared as "OK," and in fact have been called out explicitly for their suspicious behavior in LHO aLOG 17890 I'm not sure where this magnetometer lives: H1:PEM-CS_MAG_LVEA_OUTPUTOPTICS H1:PEM-CS_MAG_LVEA_OUTPUTOPTICS_QUAD_SUM_DQ but it's clear from the channel names that these is just two different versions of the same magnetometer. I'm surprised that other calibrated LSC channels like H1:CAL-CS_PRCL_DQ H1:CAL-CS_PRCL_DQ H1:CAL-CS_PRCL_DQ don't show up on your list. I'm staring at the running ASD of these channels on the wall and there's a line at 41 [Hz] that in both the reference trace and the current live trace (though, because PRCL, SRCL, and MICH all light that bounces off of HSTSs, I suspect that you might find slightly different frequencies in each). "I see your blind list of channels that couple, and raise you a plausible coupling mechanism that explains them all. How good is your hand?!"
I neglected to state explicitly that the spectra I posted are taken from non-overlapped Hann-windowed 30-minute SFTs, hence with bins 0.5556 mHz wide and BW of about 0.83 mHz.
Attached are close-in zooms of the bands around 41 Hz peaks, from the ER8 50-hour data integration, allowing an estimate of their Q's (request from Peter F). For the peak at about 40.9365 Hz, one has: FWHM ~ 0.0057 Hz -> Q = 40.94/.0057 = 7,200 For the peak at about 41.0127 Hz, one has: FWHM ~ 0.0035 Hz -> Q = 41.01/0.0035 = 12,000 Also attached are zooms and close-in zooms for the peak at 41.9365 Hz from 145 hours of ER7 data when the noise floor and the peak were both higher. The 41.0127-Hz peak is not visible in this data set integration. In the ER7 data set, one has for 41.9365 Hz: FWHM ~ 0.0049 Hz -> Q = 40.94/0.0049 = 8,400 Peter expected Q's as high as 4000-5000 and no lower than 2000 for a triplet suspension. These numbers are high enough to qualify.
Andy Lundgren pointed out that there is a line at about 28.2 Hz that might be close enough to 40.9365/sqrt(2) = 28.95 Hz to qualify as the bounce-mode counterpart to the suspected roll mode. So I've checked its Q in the 50-hour ER8 set and the 145-hour ER7 set and am starting to think Andy's suspicion is correct (see attached spectra). I get Q's of about 9400 for ER and 8600 for ER7, where the line in ER7 is much higher than in ER8, mimicking what is seen at 41 Hz.
In an email Gabriele Vajente has stated, "...the noise might be correlated to PRCL." There is a coherence spike between h(t) and H1:LSC-PRCL_OUT_DQ at 40.936 Hz. Here is the coherence for a week in ER8.
Peter F asked if Q of ~ 10,000 for bounce and roll modes was plausible. Answer is yes. We have evidence that the material loss can at least a factor of 2 better than 2e-4 - e.g. see our paper (due to be published soon in Rev Sci Instrum,) P1400229, where we got an average 1.1 x 10^-4 loss for music wire. Q = 1/loss.
[Stuart A, Jeff K, Norna R] After having looked through acceptance measurements, taken in-chamber (Phase 3), for all H1 HSTSs, it should be noted that our focus was on the lower frequency modes of the suspensions, so we have little data to refine the estimates of the individual mode frequencies for each suspension. No vertical (modeV3 at ~27.3201 Hz) or roll (modeR3 at ~40.369 Hz) modes are present in the M1-M1 (top-to-top) stage TFs of the suspensions. Some hints of modes can be observed in M2-M2 and M3-3 TFs (see attached below), as follows:- 1) M2-M2, all DOFs suffer from poor coherence above 20 Hz. However, there are some high Q features that stand out in the L DOF for SRM, at frequencies of 27.46 Hz and 40.88 Hz. In Pitch, there is a high Q feature at 27.38 Hz for PR2. In Yaw, a feature at 40.81 Hz is just visible for MC1. 2) M3-M3, again all DOFs suffer very poor coherence above 20 Hz. However, a feature can be seen standing above the noise at 26.7 Hz for MC2 in the L DOF. Also, a small peak is present at 40.92 Hz for SR2 in the Yaw DOF.
We currently don't have any bandstops for these modes on the tripples, except for in the top stage length path to SRM and PRM. It would not impact our ASC loops to add bandstops to the P+Y input on all triples. We will do this next time we have a chance to put some changes in.
Ryan Derosa mentioned that he took some low resolution measurements that include an L1 SR2 roll mode at 41.0 Hz.
I have now looked at the data for all the MCs, to complement the PRs and SRs above in log 21741. Screenshots of the data are attached, a list of the modes found are below.
H1
SUS bounce (Hz) roll (Hz)
MC1 27.38 40.81
MC2 27.75 40.91
MC3 27.43? 40.84
L1
SUS bounce (Hz) roll (Hz)
MC1 27.55? 40.86
MC2 --- 40.875
MC3 27.53 40.77
Error bars of +- 0.01 Hz.
I am not sure about the bounce modes for H1 MC3 and L1 MC1 since the peaks are pretty small. I couldn't find any data on L1 MC2 showing a bounce mode.
Expanding the channel list to include all channels in the detchar O1 channel list:
https://wiki.ligo.org/DetChar/O1DetCharChannels
I ran a coherence study for a half our of data towards the end of ER8.
I see particularly high coherence at 40.93Hz in many channels in LSC, OMC, ITM suspensions, and also a suspension for PR2. It seems to me like this particularly strong line is probably due to PR2 based on these results, Keith's ASDs, and Brett's measurements, and it seems to be very highly coherent.
Full results with coherence matrices and data used to create them (color = coherence, x axis = frequency, y axis = channels) broken down roughly by subsystem can be found here:
https://ldas-jobs.ligo-wa.caltech.edu/~meyers/coherence_matrices/1126258560-1801/bounce_roll4.html
Attached are several individual coherence spectra that lit up the coherence matrices with the frequency of maximum coherence in that range picked out.
-Pat
I've quantified the changes that will take place in the GDS calibration correction filters when the ER8/O1 update occurs. A summary of the changes are:
In total:
The attached plots illustrate the changes described above.
I have also plotted the h(t) spectrum for the ER7 and ER8/O1 GDS filters. Attached are plots of the spectrum on top of each other and of the residual between the two. Overall, the ER8/O1 GDS filter updates average ~a few percent corrections to h(t).
I took higher resolution spectra of the supposed 41Hz HSTS roll mode tonight (see first attachment). There are 2 peaks, however only the first peak has any coherance with anything. The 2 peaks are at:
40.9375 Hz (lots of DARM-PRC-SRC coherence)
41.0117 Hz (no coherence with anything I looked at)
The second attachment shows the set of 41Hz peaks in 3 of the last lock stretches. I attempted to use the ASC signals to check for coherence with DARM, but:
- the OSEM sensors on the HSTS suspensions are too noise, so see no coherence
- there is coherence with BOTH SRC and PRC, unfortunately, so hard to pin point where
- there is coherence with SRC1 which talks to SRM - is it cross-coupling thru ASC/LSC?
- there is no coherence with SRC2 likely because it is a noisy detector (AS DC), so can't tell if the SRM and SR2 combination that it talks to contribute to the 41Hz
- PRC1 not plotted, no ASC drive there, but witnessed that there is no coherence there
- PRC2 goes to PR3, so while there is coherence there (not plotted) it is likely because it is cross-coupling from SRC to PRC
- IMC_TRANS_P not plotted, but witnessed no coherence, again too noisy of a detector?
This is also close to the third harmonic of the Roll modes as seen at 41.25Hz at LLO 20737 though this is probably only relevant to highly excited roll modes.
The 40.9375 Hz mode is consistent with the PR2 M2 to M2 TFs, where a 40.93 +- 0.01 Hz mode was seen. See log 21741.
And just to clarify. This is not a third harmonic. It is the third (and highest) of the three roll modes of the HAM small triple suspension (HSTS).