I edited lscparams.py to set the initial alignment X arm IR gain higher, to match the gains we're having to enter manually to get the arm to lock in red.
Included below are the line I changed, and the previous comments.
arm_IR_gain['X'] = 0.15 # was 0.05 and doesn't lock, bumped up to 0.15, CV 18 Nov 2015
#was 0.08 until August 18 2015 # was 0.12 as of Apr-16-2015 and bit too high
#arm_IR_gain['X'] = 0.2 #should be 0.2 to acquire lock
Upon relocking this morning, after a long night of super-winds, Keita and Patrick immediately found that the ETMs were way off in alignment. We sleuthed around in the trends and can re-tell some of the confusion from yesterday's lunch time:
After Keita/Kiwamu took a break from phase measurments using a Michaelson lock, I used the lunch hour to take charge measurements. Although set to ALIGN at the start of the measurements, during them, I noticed that something was telling the ETMs to go to the MISALIGN state, even though all top guardians were set to DOWN. We ended up PAUSING some of them and then did not witness any problems afterwards. From trends we can now see that the during the full set of measurements (automated 5 sets during ~1hour) the charge script used the OPTICALIGN sliders to return the optic pointing to zero on the oplev while the optic was MISALIGNed via the normal TEST OFFSETs. A measurement later, we had reset the guardian to ALIGN and so the script drove the OPTICALIGN sliders back to nominal (again returning to zero on the oplev). However, because the optic had so far to move, it bounced for a bit and the script "timed out", resetting the OPTICALIGN to it's script-restored bad pointing values. These values were written into subsequent restore files by the script and therefore the optic never returned to the nominal pointing once the script concluded like it should.
Long story short - while there are a few places in the charge script which look for the guardian state to be correct, it may not always get returned, so watch it. In the above case, we could increase the amount of "tries" it uses for the optic to quit swinging while zeroing on the oplev (which is short when in-between measurements).
Earthquake band has settled down. Attempting to relock.
Modes at locking DRMI look bad. Attempting to lock PRMI.
Locked PRMI and aligned BS/PRM. Aligning PRM seemed to be the only thing that helped. Attempting to lock DRMI.
Starting initial alignment again. Spot on AS AIR port looks high and is not flashing well.
Got a virtual circuit disconnect for guardian and the ISC_LOCK node request is at NONE.
2015-11-18T21:57:44.47380 ISC_LOCK stopping daemon... 2015-11-18T21:57:44.59302 ISC_LOCK daemon stopped. 2015-11-18T21:58:11.57521 Traceback (most recent call last): 2015-11-18T21:58:11.57525 File "/usr/lib/python2.7/runpy.py", line 162, in _run_module_as_main 2015-11-18T21:58:11.58327 "__main__", fname, loader, pkg_name) 2015-11-18T21:58:11.58330 File "/usr/lib/python2.7/runpy.py", line 72, in _run_code 2015-11-18T21:58:11.58332 exec code in run_globals 2015-11-18T21:58:11.58334 File "/ligo/apps/linux-x86_64/guardian-1485/lib/python2.7/site-packages/guardian/__main__.py", line 262, in2015-11-18T21:58:11.59775 guard.run() 2015-11-18T21:58:11.59783 File "/ligo/apps/linux-x86_64/guardian-1485/lib/python2.7/site-packages/guardian/daemon.py", line 457, in run 2015-11-18T21:58:11.60796 raise GuardDaemonError("worker exited unexpectedly, exit code: %d" % self.worker.exitcode) 2015-11-18T21:58:11.60806 guardian.daemon.GuardDaemonError: worker exited unexpectedly, exit code: 1 2015-11-18T21:58:12.16625 guardian process stopped: 255 0 2015-11-18T21:58:18.52504 ISC_LOCK Guardian v1485 2015-11-18T21:58:18.52516 ISC_LOCK EZCA v497
I've tested a new set of 10 CBC waveforms for testing with the PCAL inverse acutation filter. The waveform parameter XML files can be found here: https://daqsvn.ligo-la.caltech.edu/svn/injection/hwinj/Details/Inspiral/coherentbbh${NUM}_1128678894.xml Where ${NUM} is between 10 and 19. The single-column ASCII files can be found here: https://daqsvn.ligo-la.caltech.edu/svn/injection/hwinj/Details/Inspiral/${IFO}/coherentbbh${NUM}_1128678894_${IFO}.out Where ${IFO} is either H1 or L1. I've attached time series of the counts after being filtered with the PINJX inverse actuation filter. The maximum number of counts in the set of 10 waveforms is 4000 counts.
Just started them on ETMx and ETMy. We'll see what they look like...
Cheryl, Patrick It appears that earthquake drove the IMC WFS to a position where the IMC could no longer lock. I cleared the histories on all degrees of freedom on the IMC WFS master screen using the small CH button in the bottom right of each filter bank. This brought MC2 back to a position where the IMC could lock. Plots attached.
ISI ITMX, HAM5 SUS SRM Eathquake band seismic now above 10 um/s. See attached.
O1 day 61
model restarts logged for Tue 17/Nov/2015
2015_11_17 08:02 h1broadcast0
2015_11_17 13:33 h1broadcast0
2015_11_17 13:33 h1dc0
2015_11_17 13:33 h1nds0
2015_11_17 13:35 h1nds1
2015_11_17 13:35 h1tw0
2015_11_17 13:35 h1tw1
2015_11_17 16:41 h1ioplsc0
2015_11_17 16:41 h1lsc
2015_11_17 16:41 h1omc
2015_11_17 16:42 h1ioplsc0
2015_11_17 16:42 h1lscaux
2015_11_17 16:42 h1lsc
2015_11_17 16:42 h1omc
2015_11_17 16:49 h1iopiscey
2015_11_17 16:49 h1iscey
2015_11_17 16:49 h1pemey
2015_11_17 16:50 h1alsey
2015_11_17 16:50 h1caley
2015_11_17 16:50 h1iopiscey
2015_11_17 16:50 h1iscey
2015_11_17 16:50 h1pemey
2015_11_17 16:57 h1dc0
2015_11_17 16:58 h1broadcast0
2015_11_17 16:58 h1nds0
2015_11_17 16:58 h1nds1
2015_11_17 16:58 h1tw0
2015_11_17 16:58 h1tw1
2015_11_17 17:03 h1sysecatc1plc1sdf
2015_11_17 17:03 h1sysecatc1plc2sdf
2015_11_17 17:05 h1sysecatc1plc3sdf
2015_11_17 17:05 h1sysecatx1plc1sdf
2015_11_17 17:05 h1sysecatx1plc2sdf
2015_11_17 17:06 h1sysecatx1plc3sdf
2015_11_17 17:08 h1sysecaty1plc1sdf
2015_11_17 17:08 h1sysecaty1plc2sdf
2015_11_17 17:08 h1sysecaty1plc3sdf
Maintenance day followed by wind induced power glitch. DAQ restarts in morning for maintenance changes. h1lsc0 and h1iscey restarts due to power glitch. DAQ restart due to LSC reconfiguration. Started Beckhoff SDF systems.
6.8 119km SW of Dadali, Solomon Islands 2015-11-18 18:31:04 UTC 10.8 km deep Spike above 1 um/s in both earthquake and microseism bands.
USGS updated it 7.0 122km SW of Dadali, Solomon Islands 2015-11-18 18:31:04 UTC 10.9 km deep
(Borja, Vinny Roma)
This is a continuation of the work started yesterday here. Today, during maintenance, we worked all morning on the hunting of the 60Hz glitch noise and we can now confirm that the issue was identified and solved.
At 2015-11-17 17:10 (UTC) we arrived at the EndY station. We noticed an aircon unit outside of the building (although different model to that reported at Livingston) also used for cooling old clean rooms and no longer in use. We were sure that it was not running at the times that we observed the 60Hz bursts. We also noticed a fridge ON as we came in...more on this later.
We carried portable magnetometers similar to the ones used at the sites but plugged into oscilloscopes for portability. The area we concentrated most of our noise hunting was the electronics bay (EBAY) as from previous measurements we noticed that the bursts were stronger at the magnetometers located there (MAG_SUSRACK and MAG_SEISRACK) in comparison with MAG_VEA (see attached figure 'Comparison_MAGs_QUAD_SUM.png'). Looking at the spikes in more detail (see 'Zoom-spikes_Mag_VEA_and_EBAYs.png') we observe that while the spikes in MAG_VEA has a frequency of 60Hz, the spikes on MAG_EBAY_SUS and MAG__EBAY_SEI has double the frequency. This seems to be cause to a non-linear response of the transducer to the magnetic field, stronger in MAG_SEI than in MAG_SUS as both are identical sensors we assume the magnetic field from the spike is stronger at the SEI magnetometer.
Another clue that pointed to EBAY as the area of interest is the coherent plot attached of the MIC_EBAY and MIC_VEA_MINUSY with MAG_EBAY_SEI, we can clearly see correlations at 60Hz and harmonics being always stronger at MIC_EBAY. Notice however that we were never able to hear the burst so we assume the microphones pick them up electromagnetically.
In order to confirm that the bursts were actually real signals (instead of rack related issues) we swapped the axes of both magnetometers on EBAY as we observed they had different signal strenght. The change in the observed signal strength after the swap was compatible with the axes changes. Notice that we undid these changes after the morning work, so now is all back to normal.
Then we moved the portable magnetometer around the EBAY racks and noticed no strong magnetic noise anywhere with the exception of the 'PEM Endevco Power supply' which powers the accelerometers. The magnetic field around this box was very strong and MAG_EBAY_SEI is not far away from it. We also noticed that this was the only device connected to the wall AC power supply (see attached pictures) and this is also the case anywhere this PEM power supply is used.
We attach a time plot of EY_MAG_EBAY_SEI during the whole morning working period and we can see several things:
1) The time interval between bursts is much shorter and less regular than before (this was also observed previously when work was done at the End station). Compare attached plots from yesterday night ('Latest-60Hz_Bursts', very regular 85minutes separation between spikes) and today ('Morning_60Hz_timeplot_MAG', totally irregular with as short separation as 3 minutes).
2) The burst structure is different than the one previously related to 60Hz glitch noise (see here). For instance see the red circled area. During this time the vacuum cleaner was on near EBAY.
At this point we realized human activity with electric devices plugged to the wall at the station was involved with the generation of 60 Hz bursts although with a different signature to the bursts we knew and came to hunt.
Suddently for almost an hour (between hours 1.7 and 2.5 in plot 'Morning_60Hz_timeplot_MAG') we saw nothing. Then the burst became more spaced so after a while we tried to reproduce the vacuum cleaner burst signature by switching it on. The vacum cleaner was in the same room as the fridge and we noticed that the fridge was now turned OFF (we later learned that John and Bubba turned it OFF).
Then everything started to make sense...the fridge compresor only needs to be on when the temperature inside the fridge drops below a threshold which it can happen every 1.5 to 2 hours or longer depending on the environment temperature and quality of the fridge insulation. Notice that the interval between burst was shorter in summer than current months. Then the compresor is usually on for a few tens of minutes until the temperature is winthing desired range and then the compresor turns off. So in order to confirm the fridge as the cause of our 60Hz burst and glitches we tested turning it ON and we saw a burst (circled green on the previous plot at hour 3.5). And as we turned it OFF then the 60Hz burst dissapeared.
It appears that the fridge was ON the whole O1, this will no longer happen. But notice that any device drawing current from the mains seem to generate 60Hz bursts at least picked up by the magnetometers in EBAY, so soon we thought that maybe this is relared with the only device in that room that is plugged to the mains and that has a considerable Magnetic contamination...the 'PEM Endevco Power supply'.
So after lunch we went back to EndY station (arriving at UTC 23:07:00) with the intention of checking if unplugging the PEM Power Supply from the wall would be enough for the EBAY magnetometers not seeing the current draw by the fridge as this was turned on and off on 1 minute intervals for 3 times. For comparison we did the same test before with the Power supply still plugged and turned on. Unfotunatelly we see no difference between these two cases on MAG_EBAY_SEI as per attached plot 'Checking_PEM_Power_Supply_Coupling.png' magenta circle is with PEM Power Supply ON and brown is with the Power supply OFF. Interestingly however we can see a small spike at about UTC (23:34:00) when the turned off the Power supply and at 23:55:00 when we turned it back on.
Notice the spikes at the beginning correspond to our arrival to End station probably due to switching ON the shoe cleaner at the entrance and the desktop computer at EBAY.
As a follow up from yesterday entry. I attach a time plot of MAG_EBAY_SEIRACK at EndY for the last 19 hours after yesterday fix of the 60Hz bursts. We can see that the regular 60Hz burst are no longer happening. The only spike in that 19 hours period took place at UTC 2015-11-18 16:41:30 which is 8:41:30 am local time which agrees perfectly with the time at which several people went into the building to look at some ESD tripping related issues. Therefore as expected the spike is related to current draw at the building due to human activity.
A final follow up on the FIX of the 60Hz glitches.
Now that LHO has been looked for quite some time I decided to compare Omicron triggers spectrograms before and after the fix. The evidence is clear that the regular 60Hz gliches are now gone.
Later today, we set the gain back to the nominal of 0.05 since it was too high and the servo ran in to a loop instability. See alog 23543.