(As Jenne requested) To avoid the confusion, the control room OBSERVE banner on Ops Overview will no longer show if the intent bit is not set. The banner will show only when both "Ops Observatory Mode (Observing)" and "Undisturbed" buttons are engaged.
Betsy, Nutsinee
LLO recently found their HWS mirrors to be contaminated (LLOalog27041). So we went to the table to take a look at our mirrors and took some pictures.
The mirrors are dusty overall and periscope mirrors show sign of coating degradation (I assume that the watermark-looking patterns are coating defects) Betsy later explained to me those marks are leftover marks from First Contact. See below:
HWSX bottom periscope mirror
HWSX top periscope mittor (sorry I wasn't able to get a good shot)
HWSX STEER M7 and STEER M8
HWSX STEER M6 with flash light shined through the back.
HWSY bottom periscope mirror
HWSY top periscope mirror
HWSY periscope mirror with flash light shined through the back
HWSX return beam (without Hartmann plate)
HWSY return beam
HWSX has been giving us data that makes sense. HWSY data however makes no sense. I forgot to stop the code when I took the Hartmann plate out and in and somehow that caused the scripts to think that there were only few hundred peak counts when everything was closed out. I re-initialized the reference images for both HWSX and HWSY. Every necessary optics were aligned and CO2 heating power was set for 2 W PSL input.
Following the same idea as elog 28442, here is a script for moving the beam spot position on PRM (prmspotmove.py).
It monitors IM3 slides, and moves IM4, PRM and PR2 sliders in such a way the the beam spot positions on PR2 and PR3 don't change.
The script was tuned in INPUT_ALIGN (for IM4 and PR2 matrix elements) and PRM_ALIGN (for PRM matrix elements).
Matrix elements (in rad /rad IM3)
pitIM3toPR2=+0.0022;
yawIM3toPR2=+0.0055;
pitIM3toIM4=-1.3;
yawIM3toIM4=+0.92;
pitIM3toPRM=-0.009;
yawIM3toPRM=+0.031;
Also attached is the python script used for finding the matrix element, getMx.py.
Here is the theoretical matrix for this move (note that signs will vary for pitch and yaw):
IM4/IM3=-1.022385686091801*tim3;
PR2/IM3=0.069871106113604*tim3;
PRM/IM3=-0.350788523435222*tim3;
This was calculated with the following data (in meters):
RPRM=-11;
RPR2=-4.555;
RPR3=36.0;
RITM=1939;
LPRM=16.6128;
LPR2=16.1551;
LPR3=24.88797;
LARM=3994.5;
LIM4=0.413;
LIM3=1.17;
n=1.45;
f=-RITM/(n-1); # thin lens approximation
fm=-RPRM/(n-1); # thin lens approximation
Decreased CP3 LLCV from 24 to 21% open
TITLE: 07/25 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Travis
SHIFT SUMMARY: After performing initial alignment this morning, locking was difficult. And earthquakes. And Stefan.
17 seconds to overfill CP3 with LLCV bypass valve half turn open NOTE: as soon as I opened the bypass exhaust valve vapor and liquid poured out, even before opening LLCV bypass valve We will most likely need to reduce the LLCV % open tomorrow when CP3 Dewar gets filled.
On the run up to ER10 and O2, I am regularly reviewing code which is locally modifed and not committed to the SVN repository. I have cleared out most of the outstanding mods for: front end source code, filter module files and guardian code. Items which are scheduled for install tomorrow have been kept locally modified for now.
I noticed that not all matlab mdl source files have been generated with matlab version 2012b (v 8.0). Here are the ones which are different:
2010a /opt/rtcds/userapps/release/isi/common/models/Offset_DOF.mdl
2015b /opt/rtcds/userapps/release/isc/h1/models/h1oaf.mdl
2015b /opt/rtcds/userapps/release/isi/h1/models/h1isietmx.mdl
2015b /opt/rtcds/userapps/release/isi/h1/models/h1isietmy.mdl
The version can be found by running my script which_matlab_version.py
I did a quick test to see if matlab 2015b produces the same binary code as 2012b. I used h1pemmx as the test model. On my ubuntu14 workstation running matlab2015b, I opened h1pemmx.mdl and then saved it making no file changes. The 2015b file was compiled on h1build (but not installed). The h1pemmx.ko files in the target area (2012b) and the build area (2015b) were compared. They have the same size but different checksums. Converting binary to strings using the string command shows the only differences are the build datetime which is encoded into the binary.
This is not an exhausive test, h1pemmx is a very simple model. Users are reporting much less graphical issues running matlab 2015b on iMacs, perhaps we should consider upgrading?
ITMX tripped 26 June on Stage1 Actuators at 1209 utc. A 6.4EQ in Kyrgystan at 1117 is a good candidate.
Attachment 1 shows 5 seconds of the MASTER_dof_DRIVE--the output from the model; and, the three horizontal inputs to the model control loops. Note the H2 drive going fuzzy just after T=29sec. Any output from the model pushing H2 would also drive H1 and H3 which don't see any drive. The bottom plot shows the RZ and X motion increasing at the same time while Y motion is unaffected. A drive only on H2 alone would produce little if any Y motion (on this platform.)
On attachment 2, the horizontal coil monitor currents and voltages are plotted on the middle and lower graphs. Different time scale with 30 seconds here but T=0 is the same. Note at T=20 the H2 current does an ugly reverse and hump for a few seconds and then goes back to looking normal. The H2 Drive and the plant response does not see any of this so it would seem this does not actually get to the Actuator. The monitors do appear pretty normal until just before T=30 when it goes flat. This when the H2 DRIVE has shot to narnia. Note the WD does not trip until almost T=32 after the 8192 model cycles.
While the coil driver monitors show a different behavior here compared to the 13 July EQ trip discussed in 28567, the same arguements hold: 1) no model output only drives H2. 2) H2 only actuation would be sensed most by RZ and X; and, mostly not sensed by Y. 3) The H2 current monitor behavior several seconds before the badness must be suspect. The voltage trend of H2 is trending higher at the time the extreme RZ and X response starts but it isn't a crazy number especially when compared to H1 voltage at the same time. The 13 July event sees the H2 current ramping to high levels as the RZ and X sensors respond.
HWS code stopped during the weekend because the disk ran out of space. I deleted some of the old data and the scripts are running again. I'm working on a script that will delete old data automatically.
Status / Work Permit review
SEI - nothing to report. Tues plans to examine the IMTY coild driver
SUS - No report
CDS - (for Tues)ITMY SEI coil driver investigation/ITM cameras. May restart baffle PD boxes
PSL - ongoing chiller flow sensor errors causing laser trips.
VAC - BSC Ion pump repcaement scheduled for Tues
FAC - Divers on site to inspect fire water tank.
Software - revisions to be made to GDS programs. Additional framewriter to be added to collect data from concentrator.
A TV crew froim Hong Kong will be on site tomorrow
According to T1500556, current settings for test mass oplevs are:
Whitening gain | Number of active whitening filters | oplev SUM counts | |
ETMX | 18dB | 1 | 40500 |
ETMY | 0dB | 2 | 28000 |
ITMX | 0dB | 2 | 2400 |
ITMY | 0dB | 0 | 5400 |
ITMY oplev PIT noise is close to the DAQ noise floor at about 3Hz, and the DAQ noise dominates the RMS down to 0.7Hz or so. ITMX is OK for RMS due to double 1:10 whitening, but not much better at 3Hz. Not good for oplev damping.
Also it seems totally fine to use two stages of whitening filters for ETMX.
We can set things up like this (changes in bold font):
Whitening gain | Number of active whitening filters | 4000*10^(24/20)oplev SUM counts | |
ETMX | 18dB | 2 | 40500 |
ETMY | 0dB | 2 | 28000 |
ITMX | 21dB | 2 | 27000 |
ITMY | 15dB | 2 | 30000 |
The filter gains for the high power oscillator monitoring diodes were switched back from 1 to their old values that were recorded under 20599 Jason/Peter
The IOC for h1cam18 was not running properly, an old image was being displayed and centroid values were frozen. Tried restarting the IOC, it didn't clear the problem. Tried rebooting h1digivideo1, it came back OK, but the IOC for h1cam18 wouldn't run. Tried deleting all of camera 18's log files and restarting, still wouldn't run. Logged on to network switch to power cycle the h1cam18, then restarted the IOC and it appears to be behaving OK now.
Multiple LASER trips are evident in the trends. Also, apparently, H1:PSL-OSC_DB3_CUR is reporting 100A. This is inconsistent and virtually impossible. Something wrong with the channel. FRS# 5955 filed.
Came in to find that the laser had tripped. Error messages were as before. Found that although I could reset the laser I could not turn it on without rebooting the Beckhoff computer. All the TwinCAT channels were live and so on. When the command was issued to turn on the pump diodes, the pump diode current(s) did not increase. The crystal chiller displays "Error Flow - sensor 1", as before, even though the laser is up and running. One other observation is that the mouse on the Beckhoff computer appears to be dead. Whilst its LED is on, moving the mouse does not move the cursor. Not sure that the two problems are related but it certainly doesn't help.
I have been taking spectra from the SR785 (WP6005) whenever I get a chance over the last week to see if there is any evidence of three mode interactions in the 60kHz to 70kHz region that we will not be sensitive to with the aliased OMC DCPD HF channels that we normally analyze.
There is a consistent peak at 62935Hz, this peak is present with no optical power in the arm cavities.
There are several other more transient peaks, one of the times several had large amplitudes is shown in the first figure.
The largest peak is at 63776Hz The maximum amplitude seen was 5E-6 This is about the same as the 18040Hz mode when it is 2 orders of magnitude above thermal noise and 2 orders of magnitude under unlocking the cavity.
The second largest is at 70160Hz and the third largest at 62336.
There is no evidence of peaks in DARM at this time at the expected aliased frequencies 1760Hz, 3200Hz or 4624Hz and the peaks that appear in the HF channels that do not appear in the normal DCPD channels do not coincide in frequency, see the second image.
We disconnected this SR785 around 11am local time today. This closed work permit #6005.
J. Kissel, T. Hardwick We've taken the liberty of rifling through Carl's home directory in hopes to find the raw data from this entry to re-plot for clarity. We found it! The newly attached plot now highlights the PI modes that Carl mentions in his aLOG, and also shows the anticipated ADC noise. Thus, any modes below 6.3e-6 [V/rtHz] should not be resolved by the ADC, and therefore will show up aliased into digitized signals in the detection band. Terra notes that the mode Carl mentions at 70160 Hz is the largest of several peaks at 69.84, 69.95, and 70.03 kHz (not highlighted), which is likely a mode cluster. Other details: The raw data lives here (determined by Terra knowing that Carl keep his GPIB data in his home folder, then lining up the data on the figure with the filename): /ligo/home/carl.blair/gpib/netgpibdata/dataSPSR785_24-07-2016_212424.txt This data (as described in the referenced work permit 6005), is the raw analog output of the TMSY's red QPD's whitening chassis. This data also happens to cover the frequency region surrounding the 65536 [Hz] native sampling frequency of the General Standards ADC, and the corresponding notch in all Anit-Aliasing (AA) chassis. One can see, delightfully, that there is very little noise or lines in this frequency band on this channel that might also otherwise be aliased down to low frequency. We should perform a similar spectral analysis of the OMC DCPD whitening chassis output voltage to check if their AA chassis is also sufficiently notched so as to not contribute noise in to the DARM sensitivity.
[Matt, Carl]
The phase lock loop is now installed as an optional tool in the PI armory. I have used the settings and method Matt demonstrated to me on the test stand to lock onto OMC PI signals in the last 50W lock. I tried locking onto QPD signals but was unable to at quiescent amplitudes. The phase locked loop in the locked state is shown in the first image. It is tracking a 15521Hz ITMX mode (sorry for the poor labeling in the figure, there's still a few bugs in medm screens).
The settings used were:
Filter I - 100Hz LP Gain 1
Filter Q - 100Hz LP Gain 1
Freq Filter 1 - gain 1
Freq Filter 2 – gain 0.02, 20mHz integrator + low pass see below
FC Count - 10mHz low pass (this was not low enough as the frequency estimate was still fluctuating by 20Hz
Ampl Filt er - 1Hz low pass gain 1
Lock Filter - 1Hz low pass gain 1
Lock was acquired by setting a set frequency close to the mode frequency observed in a spectrum of the OMC HF channels. The loop was engaged with a 100Hz low-pass in Freq Filter 2 then put in a narrow band mode by engaging a 1Hz low-pass in Freq Filter 2, the loop lost lock when I tried to further reduce its bandwidth by either reducing the gain of decreasing the frequency of the low-pass. The figure is in the high bandwidth mode. The PLL and iwave can be accessed from the mode block for any mode and a matrix is used to select a control signal, see the second image.
I think the best way to transition from PLL "aquisition mode" (high-gain and wide-band) is:
This should keep the output of FF2 (which contains an integrator) fairly constant, and thus keep the PLL locked during the transition.
Well, step 1 was supposed to read:
start with gain of 1 in FREQ_FILT1 and FREQ_FILT2 (FF1 and FF2), no filtering in FF1, and Int20mHz + LP10 in FF2
Executive summary: * Good news - as expected, the 16-Hz comb due to the OMC length dither is gone (at least at this sensitivity level) * Bad news - low-frequency 1-Hz combs remain, and some new low-frequency combs & lines have appeared Some details:
I analyzed the 56.8406Hz comb with coherence tool and here are the results. The same structure is found to be significant in 35 channels in ER9, distributed in ISI, SUS, PEM and LSC subsystems. Among all the 35 channels, 22 of them does not have a range up to its 11th harmonic, 625.25 Hz.
Keith indicated in his slog entry that a DAQ malfunction is suspected to be the ultimate source of this, and these findings suggest it's in an EX electronics crate.
Here are a few interesting observations:
The 9th harmonic at 511.56Hz is the weakest in most channels, sometimes buried in noises.
In some PEM channels, there are missing lines at low frequency (< 200 Hz) and high frequency (> 500 Hz).
In PEM and ISI channels, there seems to be another comb structure with a frequency slightly larger than 56.8406Hz coexists. That one is usually most significant at its third harmonics.
Generally, the structure is more clearly seen in LSC, SUS and ISI channels
Sample plots from each subsystem:
Figure 1: We can see the 56.8406Hz comb structure exists with its 9th harmonic weakest in ISI.
Figure 2: PEM channels have more noises and, as in ISI channels, the other comb structure coexists.
Figure 3: SUS channels do not have enough range up its 11th harmonic but we can see its first and second harmonic here.
Figure 4: There is only one channel from LSC but the structure is very clear.
All plots and a list of channels are attached in the zip file.
Just to be clear. Here are the channels that the coherence tool is finding the comb. This is what is supporting Keith's assumption that the problems could be in an EX electronics crate. Channels List: H1:ISI-ETMX_ST2_BLND_RX_GS13_CUR_IN1_DQ_data H1:ISI-ETMX_ST2_BLND_RY_GS13_CUR_IN1_DQ_data H1:ISI-ETMX_ST2_BLND_RZ_GS13_CUR_IN1_DQ_data H1:ISI-ETMX_ST2_BLND_X_GS13_CUR_IN1_DQ_data H1:ISI-ETMX_ST2_BLND_Y_GS13_CUR_IN1_DQ_data H1:ISI-ETMX_ST2_BLND_Z_GS13_CUR_IN1_DQ_data H1:LSC-X_TR_A_LF_OUT_DQ_data H1:PEM-EX_ACC_BSC9_ETMX_Y_DQ_data H1:PEM-EX_ACC_BSC9_ETMX_Z_DQ_data H1:PEM-EX_ACC_ISCTEX_TRANS_X_DQ_data H1:PEM-EX_ACC_VEA_FLOOR_Z_DQ_data H1:PEM-EX_MIC_VEA_MINUSX_DQ_data H1:PEM-EX_MIC_VEA_PLUSX_DQ_data H1:ISI-ETMX_ST1_BLND_Y_T240_CUR_IN1_DQ_data H1:ISI-ETMX_ST1_BLND_Z_T240_CUR_IN1_DQ_data H1:ISI-GND_STS_ETMX_X_DQ_data H1:ISI-GND_STS_ETMX_Y_DQ_data H1:PEM-EX_MAINSMON_EBAY_1_DQ_data H1:PEM-EX_MAINSMON_EBAY_2_DQ_data H1:PEM-EX_MAINSMON_EBAY_3_DQ_data H1:PEM-EX_SEIS_VEA_FLOOR_X_DQ_data H1:PEM-EX_SEIS_VEA_FLOOR_Y_DQ_data H1:SUS-ETMX_L1_WIT_Y_DQ_data H1:SUS-ETMX_L2_WIT_L_DQ_data H1:SUS-ETMX_L2_WIT_P_DQ_data H1:SUS-ETMX_L2_WIT_Y_DQ_data H1:SUS-ETMX_M0_DAMP_L_IN1_DQ_data H1:SUS-ETMX_M0_DAMP_P_IN1_DQ_data H1:SUS-ETMX_M0_DAMP_T_IN1_DQ_data H1:SUS-ETMX_M0_DAMP_V_IN1_DQ_data H1:SUS-ETMX_M0_DAMP_Y_IN1_DQ_data
I chased Comb 23 (type K) in Keith’s post, shown in Keith's original post as
This comb has an offset of 153.3545 Hz and a fundamental frequency of 0.0884Hz. It starts at 153.3545 Hz and goes up to its 11th harmonic, 154.3272 Hz. As is listed in Keith's txt file:
Comb 23 (type K, offset=153.354500): Frequency (offset + harmonic x fund freq) Ampl (m/rtHz) Bar (logarithmic) K 153.3545 ( 0 X 0.0884) 1.844961e-19 **** K 153.4429 ( 1 X 0.0884) 1.949756e-19 **** K 153.5314 ( 2 X 0.0884) 2.165192e-19 ***** K 153.6198 ( 3 X 0.0884) 2.181833e-19 ***** K 153.7082 ( 4 X 0.0884) 2.457840e-19 ***** K 153.7966 ( 5 X 0.0884) 2.243089e-19 ***** K 153.8851 ( 6 X 0.0884) 2.709562e-19 ***** K 153.9735 ( 7 X 0.0884) 2.499596e-19 ***** K 154.0619 ( 8 X 0.0884) 2.562208e-19 ***** K 154.1503 ( 9 X 0.0884) 1.945817e-19 **** K 154.2388 ( 10 X 0.0884) 1.951777e-19 **** K 154.3272 ( 11 X 0.0884) 1.703353e-19 ****
I found the comb structure in two channels of ISI subsystem.
Figure 1 shows the plot of channel H1:ISI-HAM6_BLND_GS13RZ_IN1_DQ. Descriptions of this channel can be found here:
https://cis.ligo.org/channel/314371
Figure 2 shows the plot of channel H1:ISI-HAM6_BLND_GS13Z_IN1_DQ. Descriptions of this channel can be found here:
https://cis.ligo.org/channel/314374
In the plots of both channels, we can see a comb structure stands out at the positions of harmonics. We are wondering about the reason for this:
Why these seismic isolation channels?
This post is supplementary to the first post about coherence analysis result for the 56.8406Hz Comb at
https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=28619
The first post is addressing the 56.8406Hz comb found in Keith's original post (marked as D comb):
https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=28364
Information about this comb from the txt file in Keith's post:
Comb 35 (type D, offset=0.000000): Frequency (offset + harmonic x fund freq) Ampl (m/rtHz) Bar (logarithmic) D 56.8406 ( 1 X 56.8406) 3.968800e-17 *********** D 113.6811 ( 2 X 56.8406) 1.773964e-17 ********** D 170.5217 ( 3 X 56.8406) 7.121580e-18 ********* D 227.3622 ( 4 X 56.8406) 3.232935e-18 ******** D 284.2028 ( 5 X 56.8406) 1.166094e-18 ******* D 341.0433 ( 6 X 56.8406) 1.007273e-18 ******* D 397.8839 ( 7 X 56.8406) 5.962059e-19 ****** D 454.7245 ( 8 X 56.8406) 3.752194e-19 ***** D 511.5650 ( 9 X 56.8406) 2.577108e-19 ***** D 568.4056 ( 10 X 56.8406) 1.964393e-19 **** D 625.2461 ( 11 X 56.8406) 1.891774e-19 **** --------------------------------------------------------------
Besides the 35 channels found in the original post, 7 more channels are found to be relevant to the 56.8406Hz Comb. Two new subsystems, ASC and HPI are involved.
These new channels are:
H1:ASC-X_TR_A_NSUM_OUT_DQ
H1:ASC-X_TR_B_NSUM_OUT_DQ
H1:HPI-ETMX_BLND_L4C_Y_IN1_DQ
H1:HPI-ETMX_BLND_L4C_Z_IN1_DQ
H1:PEM-EX_ACC_BSC9_ETMX_X_DQ
H1:SUS-ETMX_L1_WIT_L_DQ
H1:SUS-ETMX_L1_WIT_P_DQ
So updated channel list is (42 channels in total):
H1:ASC-X_TR_A_NSUM_OUT_DQ
H1:ASC-X_TR_B_NSUM_OUT_DQ
H1:HPI-ETMX_BLND_L4C_Y_IN1_DQ
H1:HPI-ETMX_BLND_L4C_Z_IN1_DQ
H1:ISI-ETMX_ST1_BLND_RX_T240_CUR_IN1_DQ
H1:ISI-ETMX_ST1_BLND_RY_T240_CUR_IN1_DQ
H1:ISI-ETMX_ST1_BLND_RZ_T240_CUR_IN1_DQ
H1:ISI-ETMX_ST1_BLND_X_T240_CUR_IN1_DQ
H1:ISI-ETMX_ST1_BLND_Y_T240_CUR_IN1_DQ
H1:ISI-ETMX_ST1_BLND_Z_T240_CUR_IN1_DQ
H1:ISI-ETMX_ST2_BLND_RX_GS13_CUR_IN1_DQ
H1:ISI-ETMX_ST2_BLND_RY_GS13_CUR_IN1_DQ
H1:ISI-ETMX_ST2_BLND_RZ_GS13_CUR_IN1_DQ
H1:ISI-ETMX_ST2_BLND_X_GS13_CUR_IN1_DQ
H1:ISI-ETMX_ST2_BLND_Y_GS13_CUR_IN1_DQ
H1:ISI-ETMX_ST2_BLND_Z_GS13_CUR_IN1_DQ
H1:ISI-GND_STS_ETMX_X_DQ
H1:ISI-GND_STS_ETMX_Y_DQ
H1:LSC-X_TR_A_LF_OUT_DQ
H1:PEM-EX_ACC_BSC9_ETMX_X_DQ
H1:PEM-EX_ACC_BSC9_ETMX_Y_DQ
H1:PEM-EX_ACC_BSC9_ETMX_Z_DQ
H1:PEM-EX_ACC_ISCTEX_TRANS_X_DQ
H1:PEM-EX_ACC_VEA_FLOOR_Z_DQ
H1:PEM-EX_MAINSMON_EBAY_1_DQ
H1:PEM-EX_MAINSMON_EBAY_2_DQ
H1:PEM-EX_MAINSMON_EBAY_3_DQ
H1:PEM-EX_MIC_VEA_MINUSX_DQ
H1:PEM-EX_MIC_VEA_PLUSX_DQ
H1:PEM-EX_SEIS_VEA_FLOOR_X_DQ
H1:PEM-EX_SEIS_VEA_FLOOR_Y_DQ
H1:SUS-ETMX_L1_WIT_L_DQ
H1:SUS-ETMX_L1_WIT_P_DQ
H1:SUS-ETMX_L1_WIT_Y_DQ
H1:SUS-ETMX_L2_WIT_L_DQ
H1:SUS-ETMX_L2_WIT_P_DQ
H1:SUS-ETMX_L2_WIT_Y_DQ
H1:SUS-ETMX_M0_DAMP_L_IN1_DQ
H1:SUS-ETMX_M0_DAMP_P_IN1_DQ
H1:SUS-ETMX_M0_DAMP_T_IN1_DQ
H1:SUS-ETMX_M0_DAMP_V_IN1_DQ
H1:SUS-ETMX_M0_DAMP_Y_IN1_DQ
Attached images are sample plots from ASC and HPI subsystem.
Full results are also attached.
Here are the coherence search results of all the single lines in ER9 data, which are listed in Keith’s post. I found 29 of all the 198 lines on the list and posted the results on my homepage here:
https://ldas-jobs.ligo-wa.caltech.edu/~duo.tao/ER9_single_lines/index.html