I ran my (now 3x faster) BruCo script using a lock stretch that Dan pointed to me, from last Friday (GPS time 1107840506 + 600 s). The report can be found at the following address:
https://ldas-jobs.ligo.caltech.edu/~gabriele.vajente/bruco_1107840506/
Here is an excerpt, but yuo should definitely read the whole book:
The second bullet is indeed very strange since it seems that SRCL/PRCL contributes pretty much uniformly to the DARM background. It seems rather strange to me that sensing noie of SRCL/PRCL can couple up to those frequencies. One simple way to test it would be to add a band-stop filter at 1-2 kHz in PRCL and SRCL loops, and see if the coherence with DARM gets reduced. If not, it means that the same souce of noise contributes in a similar way to both RF signals (used for PRCL and SRCL) and DC signals at the AS port. I can imagine things like: high order modes and RF modulation amplitude noise...
J. Kissel, S. Aston As per ECR E1500090, Integration Issue 1015, and Work Permit 5069 we are preparing to copy LLO's infrastructure implementation of using AS_A_RF45_Q_PIT (i.e. the pitch signal calculated from the Q phase of the 45 [MHz] demodulated signal from the AS A WFS in HAM6, see D1200666 and T1100472) to damping the four QUAD's roll mode. However, we found ourselves asking many questions of the implementation, namely if blindly copying is the right thing to do, mostly because of it requiring Reflected Memory (RFM) IPC connections between the ASC model and QUAD models. We think the answer is the blindly copying is NOT the right thing to do. We think we have a better sensor that is more suitable to how the roll modes appear in the H1 ASC sensors, and we think we don't have enough IPC head room. See discussion below. Please tell us your thoughts on this. If we don't hear any push back by ~9a PT tomorrow morning, we're going forward with the changes to the scheme as decided below. (1) Recently, LHO has pushed forward many different ways to *reduce* the number of ISC to ETM reflectec memory (RFM) communications: (a) We have split the ISC end-station models into two parts, an ALS and ISC model (LHO aLOG 16443) (b) We've moved the RFM connection for differential tidal control from being sent directly to the ETMs to being sent to the end-station ISC models first, and then sent to the SUS models via Dolphin PCIE. (T1400733) (c) Removed the SEI EX / EY computers from the RFM Loop (LHO aLOG 16775) (d) We will be (also tomorrow) re-distributing our corner-station LSC front end models to move the DARM path from the h1lsc.mdl to the h1omc.mdl (E1500041) Indeed, even LLO -- though they've only found to have *intermittent* IPC errors -- is testing out a faster CPU for their LSC computer to decrease the clock cycle turn around time. ... so, for the two new ASC to ETM RFM connections that LLO has added, should we do the same thing at (2) and feed the RFM connections to the end-station ISC models, and then to the SUS via Dolphin PCIE? Here is the current status of relevant IPC errors / clock-cycle turnaround time: Avg Clock Cycle IPC Receiving Channels Error Rate (CPU Max, [usec]) Errors? [n errors/sec] LLO LSC 35 No ASC 161 No ISCEX 27 No ISCEY 25 No [ALSEX] [does not exist] [ALSEY] [does not exist] SUSETMX 50 Intermittent L1:LSC-ETMX_[DARM_ERR,L_SUSETMX] less than 1 SUSETMY 49 Intermittent L1:LSC-ETMY_[DARM_ERR,L_SUSETMX] less than 1 LHO LSC 36 Yes H1:ALS-[X,Y]_ARM_RFM X: 100 to 1000, Y: 1-10 ASC 160 Yes H1:ALS-[X,Y]_REFL_SLOW_RFM 2048 ISCEX 5 No ISCEY 5 No ALSEX 32 No ALSEY 31 No SUSETMX 48 Yes H1:LSC-ETMX_[DARM_ERR,L_SUSETMX] 1 to 25, 5 to 40 SUSETMY 49 Yes H1:LSC-ETMY_[DARM_ERR,L_SUSETMX] 10 to 120, 5 to 60 Reminders: - all of the above models are running at a sampling rate of 16384 [Hz], so they have 60 [usec] to complete their clock cycle - all IPCs have a delay of 1 clock-cycle built in, but if all the computations do not complete, or just barely have enough time to complete, then the IPC misses the even the 1 clock-cycle and throws an error - The RFM loops (there are separate loops for each end station) is now LSC -> SUSETM[X,Y] -> ISCE[X,Y] -> OAF -> ASC -> LSC where the delay between the LSC and SUSETM[X,Y], as well as the ISCE[X,Y] and OAF, is the one-way four [km] light travel time through a glass fiber, n * L / c = 1.5 * 3995 [m] / 3e8 [m/s] = 20 [usec] and the delay between nodes in the same building is believed to be dt = 0.7 [usec]. This means from the LSC back to LSC delay is 2 * n * L / c + 3 * dt = 2 * 1.5 * 3995 [m] / 3e8 [m/s] + 3 * 0.7e-6 [s] = 42 [usec]. (2) The roll coupling to specifically AS_RF45_Q_PIT is the *only* feedback sensor that's piped to the SUS. But the coupling is a dirt effect do to imperfections in the real system. What guarantee do we have that we'll have equal success with this and only this sensor? To help answer the question, I took a look at 5 of the more recent times when the IFO was fully locked on DC readout, (a) 2015-02-12 07:35:56 UTC (b) 2015-02-13 05:23:45 UTC (c) 2015-02-21 01:53:30 UTC (d) 2015-02-21 03:08:20 UTC, and there doesn't appear to be a pattern on where they appear. For example, (e) 2015-02-23 09:14:31 UTC in which the there are one of two roll modes visible in DARM: 13.18 [Hz] in (a) and (b), 13.81 [Hz] in (b), (c), (d), and (e). At these times, I've taken a 0.05 [Hz] resolution amplitude spectral density of DARM and *every* ASC channel, i.e. AS A -- 45 and 36, I and Q, PIT and YAW AS B -- 45 and 36, I and Q, PIT and YAW REFL A -- 45 and 9, I and Q, PIT and YAW REFL B -- 45 and 9, I and Q, PIT and YAW TRX -- A and B, PIT and YAW TRY -- A and B, PIT and YAW POP -- A and B, PIT and YAW, or 52 channels plus DARM, and compared the amplitude and coherence to DARM in these channels for the 5 times. For each lock stretch, when either the 13.18 [Hz] mode or the 13.81 [Hz] mode is visible, it has an amplitude of ~2e-8 [ct] in DARM. After staring at the plots for an hour or three, I've convinced myself (and Stuart) that in 4 out of the 5 lock stretches, either AS B RF45 Q PIT or YAW is the sensor channel that sees both modes reliably *not* AS A RF 45 Q PIT. Further, observability does not preclude controllability, so it's not immediately clear which of the sensor signals will actually serve well for feedback. Finally, in the 5 lock stretches, only two of the four possible QUAD's highest roll modes have appeared. BUT I tested the hypothesis "does the lower frequency mode appear only in the TRs, and the higher in POP?" on the hunch that those two signals would be able to distinguish between an ETM roll mode or an ITM roll mode: again, I've convinced myself that the lower frequency mode (13.18 [Hz]) is only ever visible in POP -- implying its an ITM -- and the higher frequency mode is visible in the TRs -- implying it's an ETM. Maybe. Here's my point: if we want to be able to damp both of these modes, then just one ASC sensor isn't the right answer, and which sensor sees the mode the best is IFO dependent.
Comparisng two stretches of lock that Dan pointed to me (one from Friday, good stable sensitivity, and one from last night, worse sensitivity), I find a clear non-stattonary behavior of the sensitivity, see the first two plots, which are spectrograms of ten minutes of data during each lock.
Analyzing last night's lock, I computed the band-limited RMS between 100 and 300 Hz and it indeed shows an almost regular oscillation at about 120-140 mHz. I compared this oscillation with few auxiliary channels, and found out good correlation with the SRM angular motion (third plot), and expecially with AS_RF36 WFS signals (fourth plot).
The last two plots show my usual least square fit of the BLRMS using a set of auxiliary channels:
In summary, I think we need to commission an angular control for the SRM, and it seems we have good signals from AS_RF36. The main motion is in pitch.
= Ops Summary =
== Morning Meeting ==
Visitors: Stuart, Gabriele, Ken, Myron. Welcome to Tumbleweed Land.
SEI (Hugh) Things seems okay. Platform survived the weekend.
SUS (Betsy) I can't hear you. Sorry :-(
ISC *silence*
CDS (Richard) Things are somewhat stable. Loading/unloading ldas racks.
Vacuum ...
== Activities ==
9:58 Elli and Dave to IOT2R
*Difficulty requesting MICH_DARK_LOCKED. The beam was too low and the PD wasn't picking up all the signal. Alexa adjusted SR2 - All is well (for now)*
10:49 Mitchell to Mid X
11:54 Mitchell back
12:36 Got an automated call from Hanford Emergency System saying the alarm will go off at some point...
12:40 Elli and Dave back
13:38 Myron and Ken to Mid X
15:04 Myron and Ken back
Jodi - The big truck that supposed to come move the racks is not coming today.
Laser Status: SysStat is good Output power is 28.7 W (should be around 30 W) FRONTEND WATCH is RED HPO WATCH is RED PMC: It has been locked 1 day, 2 hr 34 minutes (should be days/weeks) Reflected power is 2 Watts and PowerSum = 24.4 Watts. (Reflected Power should be <= 10% of PowerSum) FSS: It has been locked for 0 h and 44 min (should be days/weeks) Threshold on transmitted photo-detector PD = 0.70 V (should be 0.9V) ISS: The diffracted power is around 13.8% (should be 5-15%) Last saturation event was 1 d 2 h and 4 minutes ago (should be days/weeks)
Added 250mL of water.
As I logged Friday (16836,) I set the minor alarm point to +- 2psi but that is just too tight for the EndY where the pressure sensor channels are the most noisy (by 4 to 10x.) I opened the non-alarm pressure to +-3psi. Please note if these alarms continue. The trends suggest that still might be just a tad too close.
Attached is 5 seconds of full data where the ISC sent a whole bunch (5e5nm) of LONG output to the HEPI all at once. The fast channels (shown on HPI ISO X) triggered the HEPI watchdog and the slow channels never see a thing. Why would ISC do such a thing?
Patrick T., Cyrus R. The work described under permit 5066 is complete. No issues came up.
A late entry with data: It doesn't look like the ETMx offsets that Keita (alog 16591) implemented in an attempt to decouple the large pitch of the main chain from the reaction chain was doing much.
Attached are Pitch transfer functions of the top, middle, and lower stages of the ETMx comparing various times when the large pitch bias and the Keita offsets were on and off. Not much change in any of the configurations in any of the 3 stages of the ETMx. Note, according to Jeff's alog 16824, the Keita offsets were all turned off last Thur night.
After clearing all the SEI Overflows on the GDS_TP medms Friday, this morning some have and some don't report new overflows. Where do this come from?
Okay--No Overflows reported over the weekend on:
HEPI: HAMs 2, 4 & 5, BSCs ITMY, ITMX, BS, ETMY; ISIs: HAMs 2, 4, 5, ITMY, ITMX, ETMY.
So that leaves Overflows did occur on:
HPIs HAMs 3, 6, & BSC ETMX and ISIs HAM3, HAM6, BS, & ETMX.
Okay so there is almost a complete pattern here. The BS is the only platform that had overflows on the ISI but not on the HEPI.
So for the overflows, on the ISIs, HAM3, HAM6, ETMX and the BS have overflows on the GS13s, the L4Cs, and on the DACs.
For HEPI there are overflows on the ETMX DAC; but, strangely, while the GDS-TP Overflows (e.g.:H1:FEC-55_ACCUM_OVERFLOW) have non-zero numbers, non of the ADC or DAC accumulators show any totals on the HAM3 or HAM6 (e.g.:H1:FEC55_ADC_OVERFLOW_ACC_2_9)...
See the attached for the inconsistant circled numbers: there are overflow totals on the overflow but non on the ADCs or DAC to support where they originate.
So next, I'll try to put a reason for the Overflows: maay an earthquake or a trip (although I don't believe we had any trips. HAM6 with the Fast Shutter may be the only platform with a valid reason for overflows. And, why does the HAM3 and HAM6 HEPI overflows don't show from where they came.
model restarts logged for Sat 21/Feb/2015
no restarts reported
model restarts logged for Sun 22/Feb/2015
2015_02_22 03:42 h1fw0
one unexpected restart.
Dan, Sheila
OP Lev Damping on ETMs
We have turned the op lev damping for the ETMs off completely after the interferometer is locked. This is now in the gaurdian. The attached spectra show the witness sensors with oplev damping on (dashed lines) and off (solid lines). We knew these loops were not good, but this clearly shows it. The bottom right plot shows the DHARD WFS error signal with the oplev damping on and off.
DHARD WFS
The DHARD loop, which was designed based on measurements made at a carm offset of about 50 picometers with high op lev damping gain (see alog 16501 comment) , needs to be redesigned to take into account changes in the plant on resoannce and with the op lev damping off or reduced. The attached plots show the change in the transfer function, the first one shows the open loop gain in the situation where the loop was designed, the transfer function on resonance, and a partial measurement of the TF with oplev damping gain reduced. You can see this loop becomes unstable, which explains why we have had to reduce the gain several times in the last few weeks. After turning off the op lev damping, we attempted to take some measurements which could be used to design a new loop, these are shown in the last screen shot and can be found in my directory under /Alingment/DHARD_WFS_NO_OPLEV_WHITE_NOISE.xml While the cohernce is not good at some frequencies, this should be better than what we have now.
Attachments:
1) Spectra showing that op Lev damping was imposing noise, and is now off
2) Swept sine measurements showing that DHARD PIT becomes unstable as we go on resonance and reduce Op Lev gains.
3) swept sine measurements of DHARD Pit plants on resonance and with reduced op lev gain
4) noise injection measurements of DHARD plant with op lev damping off.
Other locking notes from tonight:
- The ETMY violin modes were higher tonight than Friday by a factor of several. I made +/-60deg filters in the ETMY_L2_DAMP_MODE2 filter bank and toyed with the gain and phases. With a gain of 500k and no phase shift the peak height decreased by ~20% in half an hour. So, perhaps some progress.
- On Friday there was some coherence above 100Hz with the OMC ASC loops while the dither was on, I installed some more aggressive butterworth rolloff filters into the dither error signal filter banks. Also I added some poles and zeros to the POSX filter bank to counteract a somewhat poor job of plant inversion for this d.o.f. Tonight the dither alignment was robust, but the IFO itself was quite noisy, so it's not clear whether this was a measureable improvement over Friday.
- Progress was made on the OMC autolocker code. The challenge here is that there is no high-frequency readback of PZT2, only the DC monitor channel is recorded at >16Hz. There is some lag between the PZT2 output and the DC monitor readback, so while the code can find the mode (by sweeping the cavity), the voltage it expects the mode to be at isn't the same as the PZT slider value. This needs some work, more fast DQ channels in the OMC model would be helpful.
We made it to low noise a couple of times, but the pitch motion at the AS port was so bad that the DC lock was not very stable.
J. Kissel While reducing the EPICs sampling rate, and adjusting the servo PID parameters has killed most coupling to the SEI systems at the end stations, in the DOFs that it does remain, there is still a significant amount of coherence. The table below summarizes the remaining coupling: Freq Coherence EX Z L4Cs 0.2 - 1 [Hz] ~0.7 T240s 30-150 [mHz] ~0.85 0.2 - 1 [Hz] ~0.7 RZ L4Cs (none -- sensor noise limited) T240s 40-150 [mHz] ~0.7 HP L4Cs 30-180 [mHz] ~0.85 0.2-0.8 [Hz] ~0.85 T240s (no such sensor) EY Z L4Cs 70-150 [mHz] ~0.6 0.2-0.9 [Hz] ~0.9 T240s 60-150 [mHz] ~0.8 200-450 [mHz] ~0.9 0.5-0.9 [Hz] ~0.85 HP L4Cs 20-700 [mHz] ~0.9 T240s (no such sensor) Indeed the coupling looks strikingly like what's left over in the Beam Splitter. I wonder -- since the differential pressure is being measured by sensors right on BSC2 if the measurement of coherence is better than with the rest of the tanks in the corner. In other words, if you measure the differential pressure noise at the tank where your sensors are, you may get a better measurement of the noise coupling. The pump pressure noise (or the ADC noise) is significantly larger in amplitude at both end stations, and it even appears as though EY isn't getting any suppression at all. Further, because the "SMOO" low-pass filter has been removed, the noise above 100 [mHz] is larger than before. Looking at the HP ASDs, you can see a clear, order of magnitude reduction in the resulting noise in the platform, but at least EY still looks largely dominated by the pump pressure noise between 0.01 and 1 [Hz]. Looks like there's still some commissioning to do on these end station servos. Booooo. We'll have measure the voltage input noise on the pressure sensors like we've done with the corner station sensor, to make sure this isn't real pressure noise, and if it isn't -- this gives warrant to accelerate the development of an alternative readout system with lower noise. Further, we'll have to see why EY isn't getting any suppression at all.
Dave, Jeff, Rick, Alexa, Sheila, Elli
This morning we discovered the PSL watchdog had tripped last night aroun 9.40 UTC. Sheila says this was not a flow error, but we don't know what caused the trip. To recover the PSL we did the following steps:
...
-With Rick's help over the phone, we restarted PSL at 12.15 in the fiber room. We then set about waiting an hour for the laser temperature to settle before we turned the PSL watcdogs back on.
-During this hour, we observed an oscillation build up in IMC-MC2_TRANS_SUM_OUTPUT trace. This built up to oscillations between 300-990 counts with a 30 sec period over the hour (see picture). IMC_PWR_IN_OUT16 also oscillating, suggesting a problem downstream of the IMC. (We eventually fixed this by changing the H1:PSL-ISS_REFSIGNAL so that the diffracted power was around 8%.)
-We noticed BS ISI tripped at 6.41 PST and Ham3 ISI triped at 12.06 PT, so we reset these watchdogs.. Big Earthquake at 6am PST which caused the BS trip.
-At this point we turned off IMC WFS by switching H1:IMC-WFS_GAIN from 0.1 to 0, and took the IMC lock guardian from locked to down, and turned off Input 1 on IMC servo board. We cleared the history of the IMC_ASC MC1,MC2,MC3 and PZT loops. As it later turned out, clearing the PZT history was not helpful as clearing this hstory removed a necessary alignment offset.
-We looked at the ISS. Diffracted pw in % ( H1:PSL-ISS_DIFFRACTION_AVG) was also spiking in a saw-toothed wave shape (see picture). We turned off autolock and IMC input power settled down. We reduced H1:PSL-ISS_REFSIGNAL from -2.11V to -2.07V, untill the H1:PSL-ISS_DIFFRACTION_AVG was around 8%. Before this change the diffracted power was getting close to 0%. This changed fixed the strange oscillations we were seeing in IMC-MC2_TRANS_SUM.
-Once the ISS was behaving again, we re-locked theIMC and turned the IMC WFS back on. Because we had cleared the PZT history, turning on the WFS did not bring us back to full IMC power buildup. The beams on WFS-A and WFS-B were not centered, again because the IMC PZT mirror was not correctly aligned. We adjusted PZT H1:IMC-PZT_PIT_OFFSET ( from 2650 to 3535) and H1:IMC-PZT_YAW_OFFSET (from 5774 to 5970) to compensate for the history we cleared. This brought the IMC-IM2_TRANS power back up to its expected value, and WFS-A and WFS_B were again centered.
...
At the end of all this, we think we have recovered the PSL and IMC alignments to where we were at the start.
Ellie, Evan and Dave It has been noticed that the H1 Inteferometer has a tendency to spatial mode-hope between TEMOO and TEMO1 modes whilst L1 does not have this tendency. We have been setting up to characterize the SRC cavity length and Gouy phase to see whether it differs from the design settings. To do this we set-up the auxillary laser and improved the focusing of the light onto the high speed 1611 diode of ISCT6 on the OMC_REFl_Air periscope. As a first step we repeated the previous measurement describe in AlOG 16084 with considerably higher signal to noise. With a bright Michelson lock we observed the reflection maximum on the either side of the Michelson. By eyeballing this data we can see that these occurred at -790+/-10 MHz and 905 +/- 10 MHz. Assuming that these are difference because of an offset in lock. The Michelson Reflection Dip is peaked at 847 MHz +/- 7 MHz. This corresponds to a Schnupp Asymetry = 8.9 cm +/- 1mm. A more rigorous analysis of this data will follow.
Here is a simple parabolic fit to the data, which sets the Schnupp asymmetry to 8.7cm (with an error of +/- 0.2mm. This error is calculated using error propagation of least-squares fitting with cross-correlation terms included, but it seems likely this statistical analysis underrepresenting the true error.) The upper- and lower- zero crossings are at 806MHz and 917MHz. Last December we measured Scnipp asymmetry at 9.05cm.
Improvements to this could be made by: -Measureing cable loss/frequency response (the beat note on IOT2R is fed to ISCT6 with a looong cable), -Correcting for photodiode frequency response curve, -Checking if auxiliary laser power has a frequency dependence.
We have removed the 1611 photodiode frequency response from the data and refitted the beat-note minima. We calculate a revised Schnupp asymmetry of 8.9cm (with an error of 0.1mm, which was calculated using least squares fitting error propagation with cross-correlation terms included).
J. Kissel, S. Dwyer During the earthquake we captured new safe.snaps for the ETMs. Note that in doing so, I brought the SUSs to "safe" by hand, then requested the guardian to go to "SAFE", and vice versa brought the sus to "ALIGNED" via guardian, then restored everything that the guardian didn't touch -- all because I finally wanted to compare what my impression of what the guardian should be doing is different from what the guardian currently does after months of neglect from me, and commissioning by others. Most notably, it DOES NOT touch any part of the locking filters, and it DID turn on BOTH degrees of freedom of optical lever damping. For the record, the safe I gathered, I turned OFF ALL euler basis output switches: LOCK, DITHER, DAMP, OL DAMP, DARM DAMP, etc. Further, I've turned OFF the large offsets installed by Keita reference in LHo aLOG 16591. Those offsets, and all the expected LOCK filter banks and optical lever Pitch damping has been turned back ON. I've committed the new safe.snap the the userapps repo. Currently, we want optical lever damping to be either under human control or ISC guardian control, so we have commented out the lines in the INIT and ENGAGE_DAMPING states with call the function susobj.olDampOutputSwitchWrite to turn the levers ON. I've commited SUS.py to the userapps repo.
J. Kissel, B. Weaver The above log is a unclear regarding Keita's offsets. I had turned the offsets in M0 DRIVEALIGN L2L, L2P, and L2Y, as well as the R0 TEST L OFF while capturing the safe.snap and have LEFT them OFF since. Repeat: the M0 DRIVEALIGN L2L, L2P, and L2Y, as well as the R0 TEST L are now OFF and should remain OFF because they have proven to be ineffective (Betsy's posting an aLOG with the proof shortly).
The attached PDFs show the resistance measurements for all RHs and the relative resistance vs time for the RHs as 1W is applied to each segment. All segments are operating within nominal parameters.
The resistances for the segments are:
Segment | Resistance (Ohms) |
ITMX UPPER | 44.0 |
ITMX LOWER | 42.4 |
ITMY UPPER | 40.7 |
ITMY LOWER | 42.5 |
ETMX UPPER | 41.9 |
ETMX LOWER | 41.0 |
ETMY UPPER | 42.2 |
ETMY LOWER | 43.6 |
Just for reference, here is the transient thermal lens in ITMX, as measured by the HWS, from this morning's 2W RH test (~1800s of applied power).
A follow-up. The data from the RTD temperature sensors for each RH is plotted in the attaced PDF.
The ETMY and ITMX RH RTDs are non-responsive.