It appears to be coincident with noise in the FSS (see attached plot). It may be that the IMC feeds back to the FSS though?
I guess this was a red herring. I cleared the history on all of the IMC WFS DOF and it locked right up. The FSS signal quieted after the IMC locked.
I'm not sure if Patrick used my IMC wiki page, but it's called "Diagnosing IMC locking issues" and it's found on the OPS Wiki page.
TITLE: 11/13 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Aligning
INCOMING OPERATOR: Patrick
SHIFT SUMMARY: Purring along until the lockloss from a large earthquake. It took a while to ring down with many aftershocks. I just finished initial alignment and starting to lock again, but things are still shakey.
LOG:
7.8M Earthquake in New Zealand. Terramon still hasnt reported it. I put the SEI_CONF to Earthquake V2 but platforms are still tripping, it may be a bit before locking can happen again.
@Jim I guess that was me (see my shift summary alog from Saturday). Sorry. I restarted nuc5 and followed the instructions more carefully this time. As a side note it took me some time to realize that the television monitors had turned off when I restarted the computer.
Sadly, someone has screwed up the seismic FOM display, preventing the screen capture from working. So if you're offsite, you can't view them on the LHO Control Room Screen Shots page. Please, if you feel the need to mess with the displays, follow the directions in the wiki for setting up them up.
TOday I did another round of noise budget measurements at 30Watts input power with the IMC DOF4P alinged to minize the jitter peak at 260Hz. I don't have a plot ready but got measurements for the standard things but not frequency noise. I thought that the noise from 20-40 Hz was mostly explained, and that we could gain some range by improving there, but there must be an additional noise source at those frqeuencies.
So now SRCL and both CHARD control noises should be at least a factor of 5 or more below DARM around 30Hz, but the DARM noise hasn't improved, so there must be another noise source there. I checked MICH ASC (P is not a problem except maybe at 18Hz, yaw could be limiting us at 20Hz but not 30Hz), and PRC2 ASC (the loop from REFL WFS to PR3) which is not a problem.
TITLE: 11/13 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC STATE of H1: Noise tunings INCOMING OPERATOR: Nutsinee SHIFT SUMMARY: Had to restart OAF twice. Had to damp PI modes 3, 27 and 28. Two tours came through the control room. Had some possible misunderstanding about the BRS. At end Y it went into damping and so Sheila and I moved the configuration there to BLEND_Quite_250_SC_useism. I later talked with Jim on the phone and he said it should be fine to use the BRS while it is damping as long as the velocity is not on the order of 5000 counts or so. We are currently stopped at noise tunings at Sheila's request. LOG: Inheriting IFO in observing at NLN (30W). ISI config is at WINDY. 16:35 UTC Diag reset of H1SUSITMPI 16:36 UTC Diag reset of H1OMC 16:37 UTC Diag reset of H1IOPOAF0 16:40 UTC OAF glitch. Restarting with script. Automatically taken out of observing. 16:48 UTC OAF back. Ran 'Press All Diag Reset Buttons' and 'DAQ Clear Accumulated CRC'. 16:50 UTC Clicked on observing. Could not go to observing because TCS_ITMY_CO2 node is at FIND_LOCK_POINT instead of LASER_UP. 16:52 - 17:07 UTC Stepped out. Came back and mode 3 was slowly ringing up. Changed sign of gain. 17:13 UTC Set gains of all PI modes except 3, 26, 27 and 28 to 0 per Terra's alog request. 17:20 UTC Set to observing. 18:32 UTC Earthquake plots on top monitor of nuc5 just disappeared. Bottom seismic plots and RF spectra are still updating. 18:43 UTC Restarted earthquake plots. Strangely I could not do this from vncviewer. Typing in the terminal produced capitals. Setting caps lock on produced lower case, however with or without caps lock on the slashes in the directory path I entered turned into question marks. Used the keyboard and mouse already attached and ran 'dmtviewer /home/controls/Seismic_FOM_STS.xml' in the existing terminal as per the wiki instructions. 20:16 - 20:22 UTC Stepped out. Came back and ITMX, ITMY, ETMX and ETMY were saturating. Started saturating at 20:21:55 and stopped at 20:22:10. Bit of a spike in the 0.03 - 0.1 Hz seismic trace at end Y. 20:47 UTC Another burst of saturations. 20:49 UTC OAF glitch. Taken out of observing by TCS node. Restarted OAF using script. Ran 'Press All Diag Reset Buttons' and 'DAQ Clear Accumulated CRC'. 21:06 UTC Went to set to observing mode and noticed that the BRS at end Y is in the damping state. Trending back it has been damping since 20:43:18 UTC. Since this does not seem to prevent me from hitting the observing bit, I am. Well, I was. Just dropped back to commissioning by TCS ITMY CO2 node. 21:18 UTC More glitches. 21:22 UTC Damped mode 3. Changed end Y ISI to BLEND_Quite_250_SC_useism 21:50 UTC Lock loss 21:54 UTC Set ISI at end Y back to BRS. It did not want to go back, 'waiting for BRS to settle'. Eventually enough different guardian clicks seemed to work. 22:25 UTC PRMI to DRMI transition succeeded 22:49 UTC Stopping at Noise Tunings. Sheila dithering PR3 to measure WFS response. 23:07 UTC Damped mode 27 by changing phase 23:09 UTC Damped mode 28 by changing phase 23:12 UTC Redamped mode 27 23:13 UTC Sheila switching PRC2 Pitch. Lock loss. SUS and ISI tripped at end Y. 23:43 UTC PRMI to DRMI transition succeeded 00:02 UTC Stopping at Noise Tunings again
Locked at NLN since beginning of shift. Currently in observing mode. Had to restart OAF once. Damped PI mode 3 once. All gains for PI modes except 3, 26, 27 and 28 are set to 0 per Terra's request.
TITLE: 11/12 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 69 Mpc
INCOMING OPERATOR: Patrick
SHIFT SUMMARY: 14 hour lock, OAF crashed 4 times in about a span of an hour, but then that was it. I did not turn the gains off for the PIs because I didnt have any ring up, besides a very slow mode 3 once, and I didnt want to mess anything up for this long lock. Dust counts have set off alarms for EX, CS, and PSL as soon as the wind picked up, might be slowly settling now but it would be good to keep an eye on them.
LOG:
None of the PI modes requested to have gain set to zero should ring up quickly; if they started to ring up there should be plenty of time to put in a gain and damp as usual. Operators: Please set PI gains to zero as requested in alog 31428 (set gain to zero for all modes except 3, 26, 27, 28). We have some longer locks that indicate only Modes 3, 26, 27, 28 need damping, but would be much more confident if we had been able to prove that over the long lock stretch last night if the gains had been kept at zero. We need these long locks of more active watching before we just set these gains off.
Also, please note in your log any time you changed a PI damping setting while in Observe. TJ, did you end up changing any settings to damp Mode 3 last night?
I set all the gains to 0 except for modes 3, 26, 27 and 28 at 17:13 UTC. I was not in observing mode when I did so. The only mode that has rung up so far is mode 3. I was also not in observing mode when I damped it around 17:07 UTC by changing the sign of the gain.
Sorry, that never made it into my log. We were not Observing at the time, but I changed the phase for mode 3 from 0 to +50 (12:15 UTC).
9.5 hour lock at 68Mpc. We have been observing since 09:48, but just now the OAF crashed and it took 2 restarts to get it going again.
J. Kissel Getting one more round of calibration reference measurements for ER10/O2. The decision was made to run ER10 / O2 at 30 [W] (as opposed to the 25 [W] we'd been running all week), so I've made sure to get another round of transfer functions. In addition I've made a bunch more probing measurements of the L1 / UIM stage above 100 Hz, so that we can create an empirical model of the UIM actuator expanding on what was done in LHO aLOG 24917. Again, here, it's not that the UIM plays a big role in the response function at these frequencies, it's that the deviations at high frequency limit our ability to obtain a clean estimate of the actuation strength. Templates all listed below, analysis will come later. Sensing Function Data: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Measurements/DARMOLGTFs/ 2016-11-12_H1_DARM_OLGTF_4to1200Hz_fasttemplate.xml /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Measurements/PCAL/ 2016-11-12_H1_PCAL2DARMTF_4to1200Hz_fasttemplate.xml We may take a few more of these, just because the IFO input power has changed. Yes, a 25 [W] to 30 [W] is a small change in optical gain, but we want to be sure if detuning comes into play by 30 [W], and also if the cavity pole changes. I've also been told to expect further DC alignment changes before the weekend's out which may also play a role in these kinds of sensing function parameter changes. Actuation Function Data: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Measurements/FullIFOActuatorTFs/2016-11-12/ 2016-11-12_H1SUSETMY_L1_iEXC2DARM.xml 2016-11-12_H1SUSETMY_L1_PCAL2DARM.xml 2016-11-12_H1SUSETMY_L2_iEXC2DARM.xml 2016-11-12_H1SUSETMY_L2_PCAL2DARM.xml 2016-11-12_H1SUSETMY_L3_iEXC2DARM.xml 2016-11-12_H1SUSETMY_L3_PCAL2DARM.xml This should complete the three suites of measurements we usually do for the actuators. Given the preliminary analysis from Kiwamu (LHO aLOG 31427), I don't see a need for more data here. Also, I gathered some undisturbed time in between the sensing function measurements and actuation function measurements between 2016-11-12 06:08 UTC and 06:30 UTC so these can be used to convert / compare back against 25 [W] lock stretches. Maybe. Recall the previous two attempts at these measurements to bordered by lock losses caused by the OAF computer crashing, so there may not be a lot of time then against which to compare. Detailed High-frequency L1/ UIM Actuation Function Data: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Measurements/FullIFOActuatorTFs/2016-11-12/ 2016-11-12_L1_iEXC2DARM_HFDynamicsTest_100-250Hz.xml 2016-11-12_L1_iEXC2DARM_HFDynamicsTest_250-350Hz.xml 2016-11-12_L1_iEXC2DARM_HFDynamicsTest_300-500Hz.xml 2016-11-12_L1_iEXC2DARM_HFDynamicsTest_90-400Hz_SweptSine.xml 2016-11-12_L1_PCAL2DARM_HFDynamicsTest_100-250Hz.xml 2016-11-12_L1_PCAL2DARM_HFDynamicsTest_250-350Hz.xml 2016-11-12_L1_PCAL2DARM_HFDynamicsTest_300-500Hz.xml 2016-11-12_L1_PCAL2DARM_HFDynamicsTest_90-400Hz_SweptSine.xml The *not* labeled SweptSine are broad band injections. The idea is to export the data, filter it by coherence (0.95 should be good enough) and then take the ratio. The broad band TFs are better for characterizing the resonances. The hope is we can stitch all of these data sets together to form one sweeping meta-transfer function that completely maps out the UIM, in detail, out to ~500 Hz.
J. Kissel, K. Izumi We discovered today (see LHO aLOG 31427) that the previously most recent tag of the H1 SUS ETMY dynamical model, /ligo/svncommon/SusSVN/sus/trunk/Common/SusModelTags/Matlab/ quadmodelproduction-rev7995_ssmake4pv2eMB5f_fiber-rev3601_h1etmy-rev7915_released-2016-06-15.mat has a bug ** in which the ~1 Hz dynamics of the suspensions are junk. While exploring, we also found that the L1 SUS ETMY model tagged at the same time, /ligo/svncommon/SusSVN/sus/trunk/Common/SusModelTags/Matlab/ quadmodelproduction-rev7995_ssmake4pv2eMB5f_fiber-rev3601_l1etmy-rev7914_released-2016-06-15.mat did not include UIM-to-PUM wire violin modes. As such, I've tagged two new dynamical models, using the current damping settings at BOTH sites for ETMY (*including* optical lever damping at LHO, since we're now using Pitch damping during nominal low noise), and including upper-stage wire violin mode dynamics, /ligo/svncommon/SusSVN/sus/trunk/Common/SusModelTags/Matlab/ quadmodelproduction-rev8274_ssmake4pv2eMB5f_fiber-rev3601_h1etmy-rev7915_released-2016-11-11.mat quadmodelproduction-rev8274_ssmake4pv2eMB5f_fiber-rev3601_l1etmy-rev7914_released-2016-11-11.mat I attach plots of the transfer functions from UIM, PUM, and TST to TST in the longitudinal direction for both interferometers, comparing all ETMY-specific tags in the repo. Details ::::::::::::::::::::::: The damping loop settings for both sites were captured at the same time, while both IFOs were in nominal low noise. These filters are captured here: /ligo/svncommon/SusSVN/sus/trunk/QUAD/Common/MatlabTools/QuadModel_Production/ dampingFilters_h1etmy_20161111.mat dampingFilters_l1etmy_20161111.mat The wire violin mode frequencies are currently the same for both sites, taken from LHO aLOG 24917. There're not actually the same, but LLO hasn't measured theirs yet, so this'll have to do for now. Remember, - the calibration group has an external SVN link to this directory of model tags here: /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/externals/SUSdynamModelTags/ so they don't have to download the whole SUS svn just to use these tags. I suggest the ISC group do the same, though I haven't made new tags for any of the other three QUADs in either IFO. - Models are tagged using the function /ligo/svncommon/SusSVN/sus/trunk/Common/MatlabTools/tagsusdynamicalmodel.m ** I've traced the bug back to the addition of Sus. Point to TOP Mass violin modes. If you call /ligo/svncommon/SusSVN/sus/trunk/QUAD/Common/MatlabTools/QuadModel_Production/ generate_QUAD_Model_Production.m and insist that it includes all of the QUAD's violin modes, >> quadModel = generate_QUAD_Model_Production(freq,buildType,svnDir,plotFlag,isDamped,filterFile,useModalDamping,modalDOFs,includeViolinModes,nViolinModes) where includeViolinModes = true; nViolinModes = [25 25 25 25]; then it destroys the low frequency response. But, if you don't include any Sus. Point to TOP Mass violins by setting nViolinModes = [25 25 25 0]; then the low frequency response remains intact. This is likely a problem with the numbering of connections, and the requested transfer functions are no longer picking out the right degree of freedom. I'll have Brett take a look at this. Since the Sus. Point to TOP mass wire frequencies don't get excited when the UIM or lower stages are driven, then there's no urgency to fix the bug.
I have just discovered that some hang-ups in the calibration pipeline are due to dataValid errors in many CAL and PEM channels. a partial list of the channels that have errors (dataValid code 19373) are: H1:PEM-CS_ACC_BEAMTUBE_MCTUBE_Y_DQ H1:PEM-CS_ACC_BEAMTUBE_XMAN_Y_DQ H1:PEM-CS_ACC_BEAMTUBE_YMAN_X_DQ H1:PEM-CS_ACC_BSC1_ITMY_X_DQ H1:PEM-CS_ACC_BSC1_ITMY_Y_DQ H1:PEM-CS_ACC_BSC1_ITMY_Z_DQ H1:PEM-CS_ACC_BSC2_BS_Y_DQ H1:PEM-CS_ACC_BSC3_ITMX_X_DQ H1:PEM-CS_ACC_BSC3_ITMX_Y_DQ H1:PEM-CS_ACC_EBAY_FLOOR_Z_DQ H1:PEM-CS_ACC_HAM2_PRM_Y_DQ H1:PEM-CS_ACC_HAM2_PRM_Z_DQ H1:PEM-CS_ACC_HAM3_PR2_Y_DQ H1:PEM-CS_ACC_HAM4_SR2_X_DQ H1:PEM-CS_ACC_HAM5_SRM_X_DQ H1:PEM-CS_ACC_HAM6_OMC_X_DQ H1:PEM-CS_ACC_HAM6_OMC_Z_DQ H1:PEM-CS_ACC_IOT1_IMC_X_DQ H1:PEM-CS_ACC_IOT1_IMC_Y_DQ H1:PEM-CS_ACC_IOT1_IMC_Z_DQ H1:PEM-CS_ACC_IOT2_INPUTOPTICS_Y_DQ H1:PEM-CS_ACC_ISCT1_REFL_Y_DQ H1:PEM-CS_ACC_ISCT6_OMC_X_DQ H1:PEM-CS_ACC_LVEAFLOOR_BS_X_DQ H1:PEM-CS_ACC_LVEAFLOOR_BS_Y_DQ H1:PEM-CS_ACC_LVEAFLOOR_BS_Z_DQ H1:PEM-CS_ACC_LVEAFLOOR_HAM1_Z_DQ H1:PEM-CS_ACC_LVEAFLOOR_XCRYO_Z_DQ H1:PEM-CS_ACC_LVEAFLOOR_YCRYO_Z_DQ H1:PEM-CS_ACC_OPLEV_ITMX_Y_DQ H1:PEM-CS_ACC_OPLEV_ITMY_X_DQ H1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ H1:PEM-CS_ACC_PSL_TABLE1_X_DQ H1:PEM-CS_ACC_PSL_TABLE1_Y_DQ H1:PEM-CS_ACC_PSL_TABLE1_Z_DQ H1:PEM-CS_ACC_PSL_TABLE2_Z_DQ H1:PEM-CS_ACC_PSL_TABLE3_Z_DQ H1:PEM-CS_ADC_4_29_2K_OUT_DQ H1:PEM-CS_LOWFMIC_LVEA_VERTEX_DQ H1:PEM-CS_MAG_EBAY_LSCRACK_QUAD_SUM_DQ H1:PEM-CS_MAG_EBAY_LSCRACK_X_DQ H1:PEM-CS_MAG_EBAY_LSCRACK_Y_DQ H1:PEM-CS_MAG_EBAY_LSCRACK_Z_DQ H1:PEM-CS_MAG_EBAY_SUSRACK_QUAD_SUM_DQ H1:PEM-CS_MAG_EBAY_SUSRACK_X_DQ H1:PEM-CS_MAG_EBAY_SUSRACK_Y_DQ H1:PEM-CS_MAG_EBAY_SUSRACK_Z_DQ H1:PEM-CS_MAG_LVEA_INPUTOPTICS_QUAD_SUM_DQ H1:PEM-CS_MAG_LVEA_INPUTOPTICS_X_DQ H1:PEM-CS_MAG_LVEA_INPUTOPTICS_Y_DQ H1:PEM-CS_MAG_LVEA_INPUTOPTICS_Z_DQ H1:PEM-CS_MAG_LVEA_OUTPUTOPTICS_QUAD_SUM_DQ H1:PEM-CS_MAG_LVEA_OUTPUTOPTICS_X_DQ H1:PEM-CS_MAG_LVEA_OUTPUTOPTICS_Y_DQ H1:PEM-CS_MAG_LVEA_OUTPUTOPTICS_Z_DQ H1:PEM-CS_MAG_LVEA_VERTEX_QUAD_SUM_DQ H1:PEM-CS_MAG_LVEA_VERTEX_X_DQ H1:PEM-CS_MAG_LVEA_VERTEX_Y_DQ H1:PEM-CS_MAG_LVEA_VERTEX_Z_DQ H1:PEM-CS_MAINSMON_EBAY_1_DQ H1:PEM-CS_MAINSMON_EBAY_2_DQ H1:PEM-CS_MAINSMON_EBAY_3_DQ H1:PEM-CS_MAINSMON_EBAY_QUAD_SUM_DQ H1:PEM-CS_MIC_EBAY_RACKS_DQ H1:PEM-CS_MIC_LVEA_BS_DQ H1:PEM-CS_MIC_LVEA_HAM7_DQ H1:PEM-CS_MIC_LVEA_INPUTOPTICS_DQ H1:PEM-CS_MIC_LVEA_OUTPUTOPTICS_DQ H1:PEM-CS_MIC_LVEA_VERTEX_DQ H1:PEM-CS_MIC_LVEA_XMANSPOOL_DQ H1:PEM-CS_MIC_LVEA_YMANSPOOL_DQ H1:PEM-CS_MIC_PSL_CENTER_DQ H1:PEM-CS_RADIO_EBAY_NARROWBAND_1_DQ H1:PEM-CS_RADIO_EBAY_NARROWBAND_2_DQ H1:PEM-CS_RADIO_LVEA_NARROWBAND_1_DQ H1:PEM-CS_RADIO_LVEA_NARROWBAND_2_DQ H1:PEM-CS_RADIO_ROOF1_BROADBAND_DQ H1:PEM-CS_RADIO_ROOF2_BROADBAND_DQ H1:PEM-CS_RADIO_ROOF3_BROADBAND_DQ H1:PEM-CS_RADIO_ROOF4_BROADBAND_DQ H1:PEM-CS_SEIS_LVEA_VERTEX_QUAD_SUM_DQ H1:PEM-CS_SEIS_LVEA_VERTEX_X_DQ H1:PEM-CS_SEIS_LVEA_VERTEX_Y_DQ H1:PEM-CS_SEIS_LVEA_VERTEX_Z_DQ H1:PEM-CS_TEMPERATURE_BSC1_ITMY_DQ H1:PEM-CS_TEMPERATURE_BSC3_ITMX_DQ H1:PEM-CS_TILT_LVEA_VERTEX_T_DQ H1:PEM-CS_TILT_LVEA_VERTEX_X_DQ H1:PEM-CS_TILT_LVEA_VERTEX_Y_DQ H1:TCS-ITMX_CO2_ISS_IN_AC_OUT_DQ H1:TCS-ITMX_CO2_ISS_OUT_AC_OUT_DQ H1:TCS-ITMY_CO2_ISS_IN_AC_OUT_DQ H1:TCS-ITMY_CO2_ISS_OUT_AC_OUT_DQ H1:TCS-ODC_CHANNEL_OUT_DQ H1:ODC-MASTER_CHANNEL_OUT_DQ H1:CAL-CS_TDEP_REF_INVA_CLGRATIO_TST_REAL H1:CAL-CS_TDEP_REF_INVA_CLGRATIO_TST_IMAG H1:CAL-CS_TDEP_REF_CLGRATIO_CTRL_REAL H1:CAL-CS_TDEP_REF_CLGRATIO_CTRL_IMAG H1:CAL-CS_TDEP_PCALY_LINE2_REF_D_REAL H1:CAL-CS_TDEP_PCALY_LINE2_REF_D_IMAG H1:CAL-CS_TDEP_PCALY_LINE2_REF_C_NOCAVPOLE_REAL H1:CAL-CS_TDEP_PCALY_LINE2_REF_C_NOCAVPOLE_IMAG H1:CAL-CS_TDEP_PCALY_LINE2_REF_A_USUM_REAL H1:CAL-CS_TDEP_PCALY_LINE2_REF_A_USUM_IMAG H1:CAL-CS_TDEP_PCALY_LINE2_REF_A_TST_REAL H1:CAL-CS_TDEP_PCALY_LINE2_REF_A_TST_IMAG H1:CAL-CS_TDEP_ESD_LINE1_REF_C_IMAG H1:CAL-CS_TDEP_DARM_LINE1_REF_A_USUM_REAL H1:CAL-CS_TDEP_DARM_LINE1_REF_A_USUM_INV_REAL H1:CAL-CS_TDEP_DARM_LINE1_REF_A_USUM_INV_IMAG H1:CAL-CS_TDEP_DARM_LINE1_REF_A_USUM_IMAG H1:CAL-CS_TDEP_DARM_LINE1_REF_A_TST_REAL H1:CAL-CS_TDEP_DARM_LINE1_REF_A_TST_IMAG H1:CAL-CS_TDEP_DARM_LINE1_UNCERTAINTY H1:CAL-CS_TDEP_PCALY_LINE1_UNCERTAINTY H1:CAL-CS_TDEP_PCALY_LINE2_UNCERTAINTY H1:CAL-CS_TDEP_PCALY_LINE3_UNCERTAINTY H1:CAL-CS_TDEP_SUS_LINE1_UNCERTAINTY H1:CAL-CS_CARM_DELTAF_DQ H1:CAL-CS_LINE_SUM_DQ H1:CAL-DARM_CTRL_WHITEN_OUT_DBL_DQ H1:CAL-DARM_ERR_WHITEN_OUT_DBL_DQ H1:CAL-DELTAL_CTRL_DBL_DQ H1:CAL-DELTAL_CTRL_PUM_DBL_DQ H1:CAL-DELTAL_CTRL_TST_DBL_DQ H1:CAL-DELTAL_CTRL_UIM_DBL_DQ H1:CAL-DELTAL_EXTERNAL_DQ H1:CAL-DELTAL_RESIDUAL_DBL_DQ H1:CAL-INJ_ODC_CHANNEL_OUT_DQ This seems to be going on and off. The channel list above was generated from data from gps 1162941549 (November 11, 2016 23:18:52UTC = ~15:19PST). This may be related to the oaf work. at the time.
Sheila and Daniel pointed out that we could try using the uncontrolled IMC degree of freedom to mimic the WFS offset, without actually misaligning the cavity. I was able to do this for pitch, but was unsuccessful for yaw. Also, I didn't seem to affect the PZT excitation much, but I did get rid of much of the 260 Hz peak.
To DC couple the ISS, I held the output of the 2nd loop: H1:PSL-ISS_SECONDLOOP_AC_COUPLING_DRIVE hold switch on.
In the end, I have an offset in H1:IMC-DOF_4_P_OFFSET of -240. I tried offsets for the equivalent yaw from -200 to +250, and never saw a noticeable change in the ~150 Hz peak, ~350 Hz peak, or my PZT yaw excitation. The input to both DOF4's is off, no filter modules are engaged, and the filter modules have a gain of 1. These settings are accepted in SDF.
In the attached screenshot, Ref0 in green is with no offsets, but a pitch excitation on the PSL PZT from 400-450Hz. The live red trace is about half an hour after tuning the offset, so the offset still seems pretty good, although it's very slightly worse than the very best. The difference is almost imperceptible in the spectrum though, so I'm not worried about it.
The IMC WFS aren't as well centered now as they normally are, so at some point we should go in and center them. Since I have never been on the table where the WFS are, I'm not going to do this right now.
This is the output of the move monitor script. I modified a version for myself slightly such that it is looking at the OSEM witnesses, so these are different numbers than what Sheila has been reporting.
START:
SUS-MC1_M1 -77.7139982167 -1402.28670285
SUS-MC2_M1 621.824242608 -413.66036576
SUS-MC3_M1 -295.471270998 -1542.00494924
SUS-IM1_M1 182.246573766 1119.70220065
SUS-IM2_M1 606.630602164 -207.775211709
SUS-IM3_M1 1934.44031578 150.121067417
SUS-IM4_M1 -3856.74268732 -393.785840775
SUS-PR3_M1 -814.949561082 234.55559486
SUS-PR2_M1 2282.16934135 3242.24543291
SUS-PRM_M1 -1409.3910444 385.240469094
SUS-SR3_M1 -99.7398765539 587.461403381
SUS-SR2_M1 2972.21277609 317.397060269
SUS-SRM_M1 -1729.03418399 1251.99422647
SUS-ITMX_M0 344.119433308 -16.9095533593
SUS-ITMY_M0 996.548899622 83.349298391
SUS-ETMX_M0 -43.4443293476 12.7830931998
SUS-ETMY_M0 -113.192781573 -74.8803343133
SUS-BS_M1 418.802101563 -304.67337983
PIT: SUS-MC1_M1 -84.4985341486
PIT: SUS-MC2_M1 6.57551296647
PIT: SUS-MC3_M1 84.6476471949
PIT: SUS-IM1_M1 0.176299200236
PIT: SUS-IM2_M1 0.159609803854
PIT: SUS-IM3_M1 0.0532221860708
PIT: SUS-IM4_M1 -2.72033242382
PIT: SUS-PR3_M1 -0.482648507537
PIT: SUS-PR2_M1 -4.51434128357
PIT: SUS-PRM_M1 -2.14778485358
PIT: SUS-SR3_M1 -0.307467265582
PIT: SUS-SR2_M1 1.69735082572
PIT: SUS-SRM_M1 -4.77278126446
PIT: SUS-ITMX_M0 0.266663186344
PIT: SUS-ITMY_M0 0.50801149203
PIT: SUS-ETMX_M0 1.04999779019
PIT: SUS-ETMY_M0 0.445617164846
PIT: SUS-BS_M1 1.27672698516
YAW: SUS-MC1_M1 0.762530780343
YAW: SUS-MC2_M1 0.684821504178
YAW: SUS-MC3_M1 -1.60849376182
YAW: SUS-IM1_M1 -0.0294054532108
YAW: SUS-IM2_M1 0.322776681474
YAW: SUS-IM3_M1 0.103454831846
YAW: SUS-IM4_M1 1.48293048173
YAW: SUS-PR3_M1 -0.150923145111
YAW: SUS-PR2_M1 -0.0132833502485
YAW: SUS-PRM_M1 0.341160068319
YAW: SUS-SR3_M1 0.243808779206
YAW: SUS-SR2_M1 -1.30058543927
YAW: SUS-SRM_M1 0.199403791284
YAW: SUS-ITMX_M0 -0.139022372494
YAW: SUS-ITMY_M0 0.105286976283
YAW: SUS-ETMX_M0 0.201915126583
YAW: SUS-ETMY_M0 0.160323724745
YAW: SUS-BS_M1 -0.0897574699579
If this is really a better alignment for the IMC, we should move the DOF_4 offsets into the suspension biases.
There are picomotors to center the IMC WFS. This doesn't effect the length PD, so it needs to be checked on the table. It would also be interesting to know what effect re-centering has on the 260 Hz peak. I find it somewhat puzzling that a pure shift of the beam into the interferometer has such a larger effect on the acoustic peak coupling.
One possibility is that there is some clipping towards the second loop ISS array. Does moving DOF_4 beyond the -240 offset make it worse again?
Nutsinee and I moved jenne's pitch offset to the alignement slides for MC1 +MC3. MC1 moved from 1273.5 urad to 1180.4 urad, MC3 moved from -677. to -599.7
Nutsinee redid initial alingment, and we had no trouble relocking. The recycling gain at 2 Watts was just below 32 (31.8 ish) at 30 Watts input power it is 31.3
The 260 peak was high when we first locked (10^-19m/rtHz) but has been getting better over the first 15 minutes of the lock.
We haven't moved the picomotors on the IMC WFS or checked the IMC length diode.