Mark B. Commencing another round of Matlab TFs on PR3.
Mark B. I committed a handy Matlab script to the SUS SVN that automates the process of creating safe.snap files for SUS: ^/trunk/Common/MatlabTools/save_safe_snap.m Typical usage is >>save_safe_snap('H1','ITMY') It backs up the current state to a temp file in /opt/rtcds/userapps/release/sus/${ifo}/burtfiles/, puts the suspension into the safe state by switching off the master switch, test filters, damping filters, lock filters and alignment offsets, makes the safe.snap file, restores the suspension to the saved original state, and deletes the temp file. It's fairly verbose and describes in detail what it's doing, so if it should hit an unexpected condition and stop it should be fairly obvious how far it got and how to recover. At the end of its output it supplies the text of an svn commit command that can be copied and pasted into the Matlab command line to commit the new file. It supports QUAD, BSFM, HLTS, HSTS and HAUX, and has been tested on all of those on H1. For HAUX, you can specify a single optic, e.g., 'IM1' but since there's only one model for IM1-4, it necessarily does them all. It assumes that the safe.snap files are symlinks pointing into the userapps SVN, according to the scheme imposed on H1 by Jeff K in alog 5133. If/when LLO adopts the same layout, the script should work there as well.
Mark B. The PR3 TFs that failed before (5191) ran fine when restarted with the typo fixed (the call to Matlab_TFs() had invoked model hsts_metal, not hlts metal): Undamped: ^/trunk/HLTS/H1/PR3/SAGM1/Data/2013-01-21-1042830122_H1SUSPR3_M1_0p01to50Hz_tf.mat Damped: ^/trunk/HLTS/H1/PR3/SAGM1/Data/2013-01-21-1042852645_H1SUSPR3_M1_0p01to50Hz_tf.mat The damped plots are all fine. The undamped plots are rather noisy in L, P and Y, and the fundamental pitch mode (0.66 Hz) has pretty much disappeared in P and L. Probably needs a look over and another round of TFs.
Mark B. Per alog 5200, starting DTT TFs on ITMy. Will do M0 and R0 in parallel.
Mark B. Plots for both chains were very messy, especially in pitch, so Travis has gone out to hunt for interferences, with particular attention to the flags between the chains.
Mark B. Travis found a UIM flag that wasn't clearly touching but was a bit close for comfort and corrected it, so I'm starting another round of TFs. I probably won't finish before quitting time in which case I'll continue in the morning.
ITMy in BSC1 is now suspended. Mark is running a set of quick TFs to check for rubbing, and once deemed healthy, we are back to alignment for both SEI and SUS.
The H1 DAQ SATABOY disk raid system in the MSR failed at 01:27 local time Sunday morning (the Sunday gremlin?). From that time onwards h1fw1 has not been able to write frames. We will leave the system in its broken state for LDAS to do some forensics. This is the system that was upgraded to Sol11 on Thursday, we are investigating if that had anything to do with the failure.
Yesterday we measured again the MC2/MC3 crossover frequency. Again, tecnical problems prevented us from going all the way to the actual crossover frequency, but we were close enough to estimate confidently it to be close to 100 mHz. See attached plot.
Because of the peak right above 1 Hz and the observed instability if we try to increase the MC2 path gain, Matt designed a new filter to replace the elliptical one and roll off the gain before the offending peak (basically a LP filter at 1 Hz with at attenuation of at least 20 dB at 1.2 Hz, where the peak is). We then increased the MC2 loop gain by a factor to (0.005->0.01)
As a follow up to Hugh's post on Friday, I am posting some numbers to substantiate our claim that the BSC has not moved much from it's pre-move position. The attached DTT trends show the vertical CPS readouts from Jan 8th, after the chamber was vented, but prior to the initial ISI lock-up, up to our work on the 18th. Final cps numbers are kind of lost in the noise at the end, so final numbers are noted on the right side of each plot.
This weekend, I glued the second primary prism to the PR3 optic (the 3rd of its 4 prisms). I'll note here that the temperature of the room was higher than normal due to the fact that the original air bake oven was moved into the cleanroom and started for a 200 deg bake load over the weekend (Greg/TCS, see alog below). I used the Fluke probe and measured the RT to be 26.6 degC. Our optic bonds specify a 6 hour 34 degC air bake in the new custom oven, so we'll need to watch dor dualing air bake ovens in the future. I think we should start pulling work permits for this (and probably should have been in the past.)
The document contains a report on the recent measurements of hydrocarbons at the y end. The principal results are the attenuation of the hydrocarbon pressure with time and their significance for the future.
Test of an alog submission, reports of full disk problems.
Too many backups had accumulated. This has been rectified and a new backup routine will be implemented.
Test of an alog submission, reports of full disk problems.
[Paul, Cheryl, Giacomo]
Yesterday (Friday) evening the reading from WFS_A and WFS_B didn't quite seem to make sense, despite them having been aligned a few hours before by Cheryl. Paul and I went back to the IO table to do some more systematic testing. Bottom line is that quadrant 3 of WFS_A seems defective. It has a large offset and possibly a reduced sensitivity (although the fact that it has some sensitivity might be partially good news).
Note that this is the same unit that showed the anomalous heating described in entry 5131. The tests performed in that occasion were too superficial to notice the defect.
Although it might be initially possible to still use this sensor for some ASC test (by compensating for the offset and sensitivity in software), we will eventually need to remove WFS_A from the table and test it. To our knowledge, no spare is readily available.
This is the set of measurements we performed (values are in adc counts). We first (column 2) measured the dark current (note that for some reason the single quadrants have a sign inversion wrt the sum), then centered the beam on the WFS witht he IMC locked (column 3), then intentionally unlocked the IMC (column 4), then realigned the beam again (column 5) and finally re-locked the IMC (column 6). Note that the change in reading between IMC locked/unlocked in not necessarily due to beam wondering, as the shape of the beam itself is very different between the unlocked (mostly gaussian) and locked (mostly junk) states.
Dark | IMC Locked, centered | IMC Unlocked | IMC Unlocked, centerd | IMC locked | |
WFSA_SUM | -1215 | 500 | 9700 | 9350 | 750 |
WFSA_Q1 | -0.5 | -450 | -1200 | -2750 | -650 |
WFSA_Q2 | -3.75 | -450 | -6600 | -3000 | -225 |
WFSA_Q3 | 1220 | 875 | -1200 | -1000 | 925 |
WFSA_Q4 | -0.3 | -400 | -600 | -2600 | -900 |
WFSB_SUM | 21 | 2000 | 11250 | 11250 | 2250 |
WFSB_Q1 | -10.75 | -500 | -2750 | -3350 | -550 |
WFSB_Q2 | -5.5 | -500 | -5050 | -2300 | -300 |
WFSB_Q3 | -3 | -475 | -2650 | -3050 | -650 |
WFSB_Q4 | -1.75 | -475 | -725 | -2350 | -750 |
I measured the noise spectra of both DC and RF channels with no light on the sensors (IOT1 enclosure closed and lightpipe shutter closed). The defective channel doesn't show any noticeable excess noise (although some other wierdness is going on in the RF channels of WFS_B).
Also, we found the test document of the "defective" WFS_A unit (LIGO-S1203264-v2) and realized that it shows a dark current of quadrant 3 much higher (~45 mA) than all the others quadrants of both this and its twin (~1 mA). This is not quiet the factor ~1000 difference wrt the other quadrants that we observe now, but I guess a small offset somewhere could easily change that ratio.
The question at this point is if this offset has been deemed acceptable at some point, and we should just consider the unit as "normal"...
Attached are plots of dust counts > .3 microns and > .5 microns in particles per cubic foot from approximately 5 PM Jan. 17 to 5 PM Jan. 18. Also attached are plots of the modes to show when they were running/acquiring data. Dust monitor 10 in the H1 PSL enclosure is still indicating a calibration failure. The plots of the status gave a 'No data output' error, but I'm not sure what it means, since plots were generated and look reasonable.
Mark B. Deepak centered the OSEMs on PRM and PR3 so I rechecked settings and got the damping working. I noticed that the WD thresholds had not been set nor the filters enabled, so I fixed that and redid the safe.snap files. Damped and undamped TFs for both will commence shortly and continue through the night. The respective Measurement Status indicators will light when a measurement is in progress.
Mark B. The PRM TFs went fine: Undamped: 2013-01-18-1042586592_H1SUSPRM_M1_0p01to50Hz_tf.mat Damped: 2013-01-18-1042606494_H1SUSPRM_M1_0p01to50Hz_tf.mat Plots look good. The PR3 TFs aborted due to a dumb typo of mine in the top-level script and were restarted at 11:01 am on 1/21.
The IMC lost lock tonight at about 4:00 AM local time. It is not clear why (no big drift in the control channels).
We had trouble recovering lock this morning, unitl we discovered that there were problems with the windows machine controlling the slow digital system.
After we reset the system, restore the working settings on the common mode board and readjusted the delay line value (I'm stressing this as the default setting after a reset of the system results in almost all the signal being in the Q quadrature, with a consequently unusable error signal... good to keep in mind!), we were able to reacquire lock very easily.
For future reference, the delay line pahse is set to 243.42 Deg (and can be read by the H1:IMC-REFL_A_PHASE_PHASEDEG channel)