Per JimW's suggestion, I had a look at our beam spot positions on the test masses for now (last A2L measurement from this morning, before maintenence) versus a time on 17 June 2017 (16 June local) right after Sheila moved spots to drastically improve our range.
In the attached plot, the green squares are the old good times, and red circles are the latest measurement. Listed in the title for each optic is the total distance between the old and current spots. You can see that ETMY is basically in exactly the same place, both ITMs have moved a little bit, but ETMX has moved a lot.
So, one thing we should try today is moving the POP QPD and SOFT offsets such that we get closer to these old spots, and see if that improves our range.
Is it not possible that the change in IMC alignment / spot positions after the Montana EQ (see LHO aLOG 37363) has also decreased (or at least changed) the PSL jitter suppression, and therefore also showing up as poor range? If so, we should try moving the IMC to its pre-EQ position as as well.
I have updated GDS to version 2.18.0 (along with nds2 and gstlal packages dependent on gds) on the DMT test computer, h1dmt3, for further testing. This should have no impact on the control room or production running of the DMT.
The time of the 3 slow control machines had been off sync for some time, variation fluctuate from 1 sec to 15+ seconds between them, due to that problem I research and downloaded a third party software called NetTime, this tool allow us to resync all windows clock simultaneously with our local NTP server.
yesterday's change which unmonitored the CW GAIN and TRAMP channels was removed, we are once again monitoring these channels.
WP7066 Kiwamu, Dave:
a new h1asc model was installed, replacing RF90 with RF72. The DAQ was restarted soon afterwards.
DAQ Changes:
Fast Channels Added (2048Hz)
+: fast channel H1:ASC-AS_A_RF72_I_PIT_OUT_DQ added to the DAQ
+: fast channel H1:ASC-AS_A_RF72_I_SUM_OUT_DQ added to the DAQ
+: fast channel H1:ASC-AS_A_RF72_I_YAW_OUT_DQ added to the DAQ
+: fast channel H1:ASC-AS_A_RF72_Q_PIT_OUT_DQ added to the DAQ
+: fast channel H1:ASC-AS_A_RF72_Q_SUM_OUT_DQ added to the DAQ
+: fast channel H1:ASC-AS_A_RF72_Q_YAW_OUT_DQ added to the DAQ
+: fast channel H1:ASC-AS_B_RF72_I_PIT_OUT_DQ added to the DAQ
+: fast channel H1:ASC-AS_B_RF72_I_SUM_OUT_DQ added to the DAQ
+: fast channel H1:ASC-AS_B_RF72_I_YAW_OUT_DQ added to the DAQ
+: fast channel H1:ASC-AS_B_RF72_Q_PIT_OUT_DQ added to the DAQ
+: fast channel H1:ASC-AS_B_RF72_Q_SUM_OUT_DQ added to the DAQ
+: fast channel H1:ASC-AS_B_RF72_Q_YAW_OUT_DQ added to the DAQ
Fast Channels Removed (2048Hz)
-: fast channel H1:ASC-AS_A_RF90_PIT_OUT_DQ removed from DAQ
-: fast channel H1:ASC-AS_A_RF90_YAW_OUT_DQ removed from DAQ
-: fast channel H1:ASC-AS_B_RF90_PIT_OUT_DQ removed from DAQ
-: fast channel H1:ASC-AS_B_RF90_YAW_OUT_DQ removed from DAQ
Slow Channel Stats: 1060 channels Added, 356 channels Removed
DIAG_MAIN guardian code changed
The RF90 channels on the front end h1asc were renamed to RF72 this morning, but their Beckhoff equivalent channels retained their RF90 naming. This upset DIAG_MAIN, which checks for setting equivalency between Beckhoff whitening and h1asc anti-whitening. The code loops through channels assuming an identical core name.
I modified sys/h1/guardian/DIAG_MAIN.py to remove ASC-AS_A_RF90 from the generic loop. I added a new tuple to cover the ASC exception that RF72_AWHITEN_SET on the front end maps to RF90_WHITEN_FILTER in Beckhoff land.
Here is the SVN differences for the changes I made:
Index: DIAG_MAIN.py
===================================================================
--- DIAG_MAIN.py (revision 15816)
+++ DIAG_MAIN.py (working copy)
@@ -859,10 +859,10 @@
'ASC-POP_X_RF',
'ASC-AS_A_RF45',
'ASC-AS_A_RF36',
- 'ASC-AS_A_RF90',
+ #'ASC-AS_A_RF90', DB LHO 11july2017
'ASC-AS_B_RF45',
'ASC-AS_B_RF36',
- 'ASC-AS_B_RF90',
+ #'ASC-AS_B_RF90', DB LHO 11july2017
'ASC-POP_A',
'ASC-POP_B',
'ASC-OMC_A',
@@ -904,8 +904,10 @@
'ASC-Y_TR_B',
]
+ # DB LHO 11july2017: h1asc model changed RF90 to RF72, Beckhoff retained RF90 names. Make exception for AS_[A,B]_RF90/72 mapping
+ rf72_tups = [('ASC-AS_{}_RF90_WHITEN_FILTER_{}'.format(ab,i), 'ASC-AS_{}_RF72_AWHITEN_SET{}'.format(ab,i)) for ab in ['A', 'B'] for i in range(1,4)]
omc_tups = [('OMC-DCPD_A_WHITEN_SET_{}'.format(i),'OMC-DCPD_B_WHITEN_SET_{}'.format(i)) for i in range(1,4)]
- all_dem_tups = [('{}_WHITEN_FILTER_{}'.format(pre,i), '{}_AWHITEN_SET{}'.format(pre,i)) for pre in prefix for i in range(1,4)] + omc_tups
+ all_dem_tups = [('{}_WHITEN_FILTER_{}'.format(pre,i), '{}_AWHITEN_SET{}'.format(pre,i)) for pre in prefix for i in range(1,4)] + omc_tups + rf72_tups
for x in all_dem_tups:
if ezca[x[0]] != ezca[x[1]]:
I have made a number of medm screens for this new system. The attached are screenshots of a couple of the new medms. When we locked the interferometer with a low power (~2W) after the maintenance today, I briefly tried phase-locking the audio modulation signal at 205 Hz, but didn't really succeed. We will continue commissioning them later.
Additionally, I have edited the ISC_DRMI guardian so that it doesn't look at ASAIR_B_RF90 any more when checking whether the ASCs needs to be slowly engaged or not. With this modification in it, we succeeded in locking the interferometer multiple times today. So it seems functioning as expected. After the test today, we restored the RF hardware back to nominal -- no 72 MHz source and very small 118 MHz modulation.
TITLE: 07/11 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
Wind: 6mph Gusts, 5mph 5min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.05 μm/s
QUICK SUMMARY:
Maintenance Day
LASER is OFF. LASER crew is in the enclosure.
TITLE: 07/11 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Earthquake
INCOMING OPERATOR: Ed
SHIFT SUMMARY: 6.6M earthaquake at the start of my shift left us waiting for a few hours, then some trouble keeping the mode cleaner locked after initial alignment, followed by ETMX violin mode 507.194hz ringing up. With +60 phase and +0.25 gain it seems to be stable(ish) at an RMS of 7. The OMC trans camera has a lot of movement, it seems to really be struggling, and the OMC_LOCK Guardian will not get to READY_FOR_HANDOFF presumably from this high violin mode.
LOG:
Attached are plots of the flow rates through heads [1,4] for the last 12 hours and the last hour. Apart from the initial restart period, the flow rates more or less settled down and looked reasonably clean. However in the last hour they took a downturn back to rates similar to when the chiller was restarted last night. The crystal chiller flow rate appears constant at this point in time, at least within the minute trend data. The crystal chiller flow rate has a resolution of about -/+ 0.1 lpm. The observed decrease in the flow rate to the heads is ~ -0.025 lpm. So in retrospect, perhaps the observed decrease in the head flow rates is due to a reduced flow from the crystal chiller.
After the 6.6M New Zealand quake I ran an initial alignment with no issues, but then it would lose lock very randomly. I couldn't make it past DRMI for a long time, with the FSS oscillating often on lock losses.
I have finally made it to DC_READOUT_TRANSITION but the 507.194hz ETMX mode has been ringing up with the current settings from Guardian. Changing the phase from +60 to -60 started to help, but now it seems that to have flattened out. There are no +/-30deg filters in that bank so I'm pretty limited, but a smaller positive gain (~5) with -60 gain seems to be my best option.
That mode was definitely being rang up by something. I had to change phases and gains once a minute or so or it would begin to ring up. With the bank turned off it would ring up pretty fast and at 6.9RMS already it was dangerous. Since I was running out of ideas I went to increase the power but it died immediately upon entering DC_READOUT. Expected when the mode is that high.
TITLE: 07/11 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Earthquake
OUTGOING OPERATOR: Patrick
CURRENT ENVIRONMENT:
Wind: 8mph Gusts, 6mph 5min avg
Primary useism: 1.74 μm/s
Secondary useism: 0.10 μm/s
QUICK SUMMARY: When I got here Patrick was battling some PI's while sitting at INCREASE_POWER. DCPD saturations were continuous and DARM looked bad. With neither of us finding the problem, seismon reported an incoming earthquake that just broke the lock.
TITLE: 07/11 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC STATE of H1: Earthquake INCOMING OPERATOR: TJ SHIFT SUMMARY: Peter and Jason brought the PSL back. I ran an initial alignment and made it to NLN. Sat at NLN trying to damp 507.194 Hz and 1463.09 Hz violin modes. I think the later was starting to come down after setting ITMX mode 3 to only FM4 and FM5 and a gain of 100. I think I might have made the former worse by playing around with EMTX mode 6 and 7. Eventually lost lock, possibly changing gain of ETMX mode 7, but I had done this many times before. Upon starting INCREASE_POWER during relocking I started getting constant OMC DCPD saturations and a whole series of peaks in an elevated DARM. Eventually the lock broke at LOWNOISE_ESD_ETMY. Relocked again and it happened again but I stopped the guardian at the completion of INCREASE_POWER. Sitting there now with constant OMC DCPD saturations and same elevated DARM. Have had to damp a whole series of PI modes and now riding through a 6.6 mag earthquake in South New Zealand. LOG: 23:10 UTC Robert to LVEA to setup equipment for tomorrow (Tuesday) 23:42 UTC Cheryl out of optics lab 00:16 UTC Robert and Pep to end Y 00:27 UTC GRB 01:14 UTC Robert and Pep done 01:28 UTC Restarted video4 01:36 UTC Peter and Jason out of PSL enclosure. Report bad pressure regulator and no immediately available spare. Managed to get flow rate back to what it was before the trip, but may not last. 01:38 UTC Starting to relock 01:54 UTC Starting initial alignment 02:35 UTC Initial alignment done 03:28 UTC NLN 03:40 UTC Running a2l 03:45 UTC a2l done 03:48 UTC Changed filters and gain for ITMX mode 3 03:50 UTC Damped PI mode 28 03:53 UTC Changing gain for ITMX mode 3 to 10 04:18 UTC Changed gain for ITMX mode 3 to 15 04:20 UTC Changed gain for ITMX mode 3 to 50 04:22 UTC Changed gain for ITMX mode 3 to 100 04:32 UTC Changed gain for ETMX mode 7 from 15 to 20 04:32 UTC Changed gain for ETMX mode 7 to 50. Jump in DARM. 04:38 UTC Changed gain for ETMX mode 7 back to 15 04:55 UTC Changed gain for ETMX mode 7 to 0 05:08 UTC Changed gain for ETMX mode 7 to -100 05:10 UTC Changed gain for ETMX mode 7 to 0 05:15 UTC Changed gain for ETMX mode 6 from -100 to -80 05:16 UTC Changed gain for ETMX mode 6 to 0 05:17 UTC Changed gain for ETMX mode 6 to -150 05:18 UTC Changed gain for ETMX mode 7 to 15 05:22 UTC Changed gain for ETMX mode 6 to -100 05:25 UTC Changed gain for EMTX mode 6 and 7 to 0 05:26 UTC Changed gain for EMTX mode 6 to -100 and 7 to 15 05:32 UTC Reverted ETMX SUS SDF differences -> jump up in ETMX mode 5 rms mon, set back, jumped up again 05:40 UTC Changed gain for ETMX mode 7 to 150 05:45 UTC Changed gain for ETMX mode 7 to 15. Lock loss Constant OMC DCPD saturations after INCREASE_POWER. Huge series of peaks in DARM 06:14 UTC Lock loss from LOWNOISE_ESD_ETMY with constant OMC PD saturations 06:42 UTC Going to increase power. OMC DCPD saturations again. Stopping at completion of INCREASE_POWER. 06:54 UTC Damped PI mode 27 and 19 by changing sign of gain and then had to change it back. 06:59 UTC Damped PI mode 28 07:01 UTC Damped PI mode 27 and 19 again. This time needed change of phase. 07:04 UTC Damped PI mode 28 and 20. Damped more PI modes.
Finished and sitting at INCREASE_POWER. Second time in a row this happened. First time lost lock trying to go further.
Tried setting ETMX violin mode 6 and mode 7 gain to 0. Did not help.
Made it to NLN at 03:28 UTC. Current range around 49 MPc. Snapshot of DARM spectrum attached.
Ran a2l and changed filters and gain for ITMX mode 3. Turned on just FM4 and FM5 and set gain to 10. (I switched the filters first during which time the gain was left large, then changed the gain to 1 and then later to 10.)
J. Kissel, Operators Where we left off on Friday: - We were battling 2 (actually 4) modes, ETMY: 1008.4502 & 1008.4938 Hz (Mode separation: 0.0436 Hz) Unknown: 1463.0974 & 1463.1005 Hz (Mode separation: 0.00309 Hz) For the the later unknown modes, I tried the following: - Driving ITMX or ITMY, and even Both Simultaneously and for each of those configurations: - Multiple bandwidth sizes - Driving in Pitch, Length, and Yaw - Gains from very little to about to saturate the DAC - The usual phase rotation game I attach a StripTool that shows the control signals of the damping filters all I was ever able to get was the beatnote between the two frequencies, with a period of 5.3 minutes. That extra long beat-note envelope makes it extra time-consuming to try new configurations, because one has to wait for one, if not several peaks of the envelope to assess whether a positive (or negative) change has been made. - We also has somehow managed to ring up > 1.5 kHz harmonics, especially some 6 kHz mode Where we pick-up today: See attached spectra. These same modes mentioned about continue to dominate the RMS, along with another set of modes (1475.2520 & 1475.0984 Hz) that has rung up again over the weekend, where the latter of the two (1475.0984 Hz) is also one for which we've not yet identified a filter and/or settings. We're otherwise keeping the Violin Mode Table as up-to-date as possible with any success we have.
I have edited the Violin mode tables you linked to which it had already the mode 1463.097 identified as ITMX, I can confirm that the other pair mode 1463.1005 is also associated to the same mass actually to the same fibre. UPDATE: I have been asked to provide some evidence of this affirmation, so here it is. A couple of year ago (during O1) Evan Hall and myself were allowed to drive the PUMs of each test mass individually with the damping filters turned off for fundamental and higher harmonics, while the detector was locked (see original alog here). Next a reminder of times of injections:
Injection on ITMX: from 2015-10-28 20:39:44 to 2015-10-28 20:44:13, channel H1:SUS-ITMX_L2_DAMP_MODE5_GAIN
Injection on ITMY: from 2015-10-29 20:22:51 to 2015-10-29 20:31:17, channel H1:SUS-ITMY_L2_DAMP_MODE8_GAIN
Injection on ETMX: from 2015-10-29 20:37:20 to 2015-10-29 20:45:37, channel H1:SUS-ETMX_L2_DAMP_MODE5_GAIN
Injection on ETMY: from 2015-10-29 20:52:36 to 2015-10-29 20:59:11, channel H1:SUS-ETMY_L2_DAMP_MODE6_GAIN
Then I monitored change of amplitude and phase of the violin modes and harmonics before and after the injection (for each injection). I attach the plots for the harmonic lines at 1463.097 and 1463.1005 Hz. The injection starts at about second 1200 on these plots. It is unquestionable the huge difference observed when the injection was applied to ITMX respect to all the other cases.
UPDATE2: While I am 100% sure that 1463.097 and 1463.100 are associated to ITMX however my confidence of them being associated to the same fibre is not that high, I just made an obvious conclusion based on the fact that they are the closest pair of modes for the 3rd harmonic, by an order of magnitude!
They are 0.003Hz apart while the next adjacent pair of modes for the 3rd harmonic are 0.05Hz apart. Maybe actually the fact that they are much closer than any other pair shows the opposite conclusion, that they actually correspond to different fibres. In a way that one of the modes of each pair happens to be incredibly close.
And actually looking to the original identification of the fundamental mode to actual fibres (https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=17610) this may actually be the case. Look at the identification of modes 501.208 (associated to ITMX FR) and 501.254 (associated to ITMX BL), they are 0.046Hz apart, closer than any other pair of modes on ITMX. A difference in inharmonicity of the 2 fibres may explain why their 3rd harmonics are much closer than their fundamentals.
It may be worth trying to damp these modes by acting on those 2 fibres.
The other 2 modes you are having problems with; 1475.2520 it is unquestionable ETMX, and 1475.09 most probably is also associated to the same mass (probably a pair mode) but notice that this mode did not have a noticeable change in amplitude when driving any of the PUMs associated to QUADs, which means is weakly coupled explaining why you are having issues with damping filter settings.
CW GAIN issue has been resolved. The CW_GAIN and CW_TRAMP values were being monitored by Guardian, which forced the IFO out of observing when those values changed; those values were changed due to a loss of hardware injections and subsequent restart by the psinject script. Dave Barker and I have changed the gain and ramp to be unmonitored channels again. Notes attached.
Change undone after the decision was made that losing IFO lock was the desired behavior and issue was mitigated by sparse nature of psinject reset. See aLOG 37447.