Replaced our aging NTP server with an new unit that has the ability to provide more protocols. New Antenna on roof also.
Per work permit 5741 began the process of modifying all Suspension Satellite Amplifiers. Drawing D0901284-v4 calls for the addition of Cap C601(10uF) and C602 (.1uF) between the -17V to Ground around U503 the Negative Regulator VEE1. Today with Ed M. Soldering away in the lab we were able to complete all of Han2 units. Complete are: MC1, MC3, PRM, PR3, MMT1, MMT2, SM1, SM2 All Stages. We did have a problem with two Sat Amps. One shared between MC1 and MC3 and the one for MMT2,a trace blew when it was powered up. So replaced SN 1100117 with SN S1000287 and SN1100068 with SN1100066.
Peter Shawhan, Carlos, Jim, Dave:
FRS4412, WP5740
Summary of problem, IERS (international earth rotation and reference systems) web page which announces future leap seconds addtions to UTC (called the Bulletin C page http://www.iers.org/SharedDocs/News/EN/BulletinC.html) was being accessed by LHO CDS several times per second.
We had two problems: h1hwinj1 machine accessing the web page every 10 seconds, h1guardian0 machine accessing the web page on average several times per second. In both cases it was a non-bash-shell process calling the tconvert program.
tcleaps.txt data file
A new location outside of the apps area is now used to hold the tcleaps.txt datafile which provides tconvert with the history of leap seconds. The new location is /ligo/data/tcleaps/tcleaps.txt. This directory is referenced by the environment variable TCLEAPSDIR.
h1hwinj1:
Fix was to change the standard environment as defined by the files /ligo/cdscfg/lho/h1/stddir_linux.sh and stdrc_linux.sh. Rebooted h1hwinj1 machine.
h1guardian0:
Guardian nodes call tconvert via the cdsutils-gpstime utility. Fix was to change /ligo/apps/linux-x86_64/cdsutils/etc/cdsutils-user-env.sh. Rebooted h1guardian0 machine.
Verification:
Before and after the changes we ran tcpdump on the main CDS NAT router to verify web access to the Bulletin C page went from several per second to zero. During normal operation, this web page should only be accessed twice a year.
This morning I closed GV 5 & 7 so I could crane the snorkel lift over the Y beam tube in the LVEA. Valve closure and opening times are as follows: GV5 closed @ 10:34 PT GV7 closed @ 10:36 PT. GV 5 opened @ 11:24 PT and GV 7 opened @ 11:26 PT.
DaveB restarted the guardian computer to correct a tconvert issue, WP 5740.
After this, every HEPI platform guardian reports this error:
2016-02-23T17:52:24.50084 HPI_HAM1 [ROBUST_ISOLATED.enter]
2016-02-23T17:52:24.57873 HPI_HAM1 W: Traceback (most recent call last):
2016-02-23T17:52:24.57874 File "/ligo/apps/linux-x86_64/guardian-1485/lib/python2.7/site-packages/guardian/worker.py", line 459, in run
2016-02-23T17:52:24.57875 retval = statefunc()
2016-02-23T17:52:24.57875 File "/ligo/apps/linux-x86_64/guardian-1485/lib/python2.7/site-packages/guardian/state.py", line 240, in __call__
2016-02-23T17:52:24.57876 main_return = self.func.__call__(state_obj, *args, **kwargs)
2016-02-23T17:52:24.57876 File "/ligo/apps/linux-x86_64/guardian-1485/lib/python2.7/site-packages/guardian/state.py", line 240, in __call__
2016-02-23T17:52:24.57877 main_return = self.func.__call__(state_obj, *args, **kwargs)
2016-02-23T17:52:24.57877 File "/opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/decorators.py", line 86, in wrapper
2016-02-23T17:52:24.57878 return func(*args, **kwargs)
2016-02-23T17:52:24.57878 File "/opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/decorators.py", line 86, in wrapper
2016-02-23T17:52:24.57879 return func(*args, **kwargs)
2016-02-23T17:52:24.57879 File "/ligo/apps/linux-x86_64/guardian-1485/lib/python2.7/site-packages/guardian/state.py", line 240, in __call__
2016-02-23T17:52:24.57880 main_return = self.func.__call__(state_obj, *args, **kwargs)
2016-02-23T17:52:24.57880 File "/ligo/apps/linux-x86_64/guardian-1485/lib/python2.7/site-packages/guardian/state.py", line 240, in __call__
2016-02-23T17:52:24.57881 main_return = self.func.__call__(state_obj, *args, **kwargs)
2016-02-23T17:52:24.57882 File "/opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/isolation/states.py", line 490, in run
2016-02-23T17:52:24.57882 if (iso_const.ISOLATION_CONSTANTS['SWITCH_GS13_GAIN']) & (self.has_requested_gs13_gain_switch == False) & (top_const.CHAMBER_TYPE != 'BSC_ST1'):
2016-02-23T17:52:24.57883 KeyError: 'SWITCH_GS13_GAIN'
2016-02-23T17:52:24.57883
2016-02-23T17:52:24.57888 HPI_HAM1 [ROBUST_ISOLATED.run] USERMSG: USER CODE ERROR (see log)
2016-02-23T17:52:24.62596 HPI_HAM1 ERROR in state ROBUST_ISOLATED: see log for more info (LOAD to reset)
I've reloaded and restarted both HAM1 and HAM6 and the error returns. It sure looks like it is related to the updates to get the ISI guardian to switch the GS13 gains depending on the state. I can not find documentation (logs) that the HPI nodes have been restarted since the gain switching updates which were intended for the ISI.
I've elected to not attempt any code corrections at this time; I suspect Hugo will correct this easily. Meanwhile, I don't know if the guardian will actually function if it trips. This can be done easily however with the command scripts isolating to level1.
II 1206 FR 4418
Code oversite fixed. Guardian restarted. All HPIs are good. Tested on HAM6, positive function. ISI guardians not restarted--should do next Tuesday to confirm no issues there.
files updated:
hugh.radkins@operator3:~ 0$ userapps
hugh.radkins@operator3:release 0$ cd isi/common/guardian/
hugh.radkins@operator3:guardian 0$ svn up
U isiguardianlib/isolation/const.py
U isiguardianlib/isolation/states.py
U isiguardianlib/damping/states.py
Updated to revision 12715.
Attached are 7 day pitch, yaw, and sum trends for all active H1 optical levers. Closing FAMIS #4393.
Notes:
Everything here looks good. We need to keep an eye on the HAM2 oplev (assuming anyone is actually using it), it is getting close to the edge of its linear operating range (~±30 µrad).
We'll keep an eye on ETMy yaw as well. Its linear operating range is large (on the order of ±50 µrad) so a re-zeroing is strictly necessary, but it is used for weekly SUS charge measurements so a tighter operating range might be desirable.
Planned outage for WP #5736 is complete (8AM-8:10AM Pacific). Optical taps were installed between LHO border router and our ISP.
FE watchdog was reset at 16:15UTC.
FAMIS: https://ligo-wa.accruent.net/LB_Request_Update.asp?RequestID=3586
Den, Sheila, Evan
~> We tried reverting to the old QPD offsets (the ones we used throughout O1) for the soft loops and the PRM pointing loops. These seemed to make the recycling gain slightly worse, and did not improve the jitter coupling. This indicates that (as we had suspected) these offsets are no longer good to use.
~> We measured the 9 MHz oscillator phase noise coupling into DARM. This had been done previously (19911), but with a suspicious calibration and in a way that also drove the 45 MHz phase. This time, we used the OCXO to drive both the harmonic generator (bypassing the 9 MHz distribution amplifier) and to serve as a reference for an IFR/OCXO PLL with a >40 kHz bandwidth. The IFR is used to drive the 9 MHz distribution amplifier. The error point of the PLL was offset in order to maintain the relative time delay of the 9 MHz and 45 MHz signals. When we relocked, we found that the 18 MHz and 27 MHz signals had flipped sign, but otherwise the interferometer locked normally. However, there was a great excess of 45 MHz noise in DARM (worse even than before we installed the 9 MHz bandpass). Nevertheless, we were able to drive enough to see the effect of 9 MHz phase modulation in DARM. The coupling is roughly 2–4×10−6 mA/Hz above 100 Hz.
Also, twice last night (while locked on the IFR) we were battling a 900 Hz line in DARM that increased over the duration of the lock, and eventually caused EY to saturate.
We suspected PI, but this line was also present at 900 Hz in the DCPD IOP channels. So it is not folding around the 8 kHz Nyquist of the digital downsampling.
This line does not appear in the IOP channels for the end station QPDs. (2 W, dc readout)
It's the third harmonic of the beamsplitter violin mode. Den added a stopband filter to the BS M2 length drive, and the line went down.
Unclear why this had not been a problem before.
TITLE: 2/23 eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
QUICK SUMMARY: Commissioners doing their thing for my whole shift.
Log:
Following up on Andy's earlier posting and building on data-folding infrastructure he has been developing, Weigang Liu has tried folding the same three channels Andy examined, but folding daily and monthly over most of the O1 data set (ignoring January data to avoid confusion from calibration / post-O1 studies). Weigang sees similar behavior in each channel to what Andy found in a half-hour sample, but with some variations during the course of the run. In brief, Weigang uses a Matlab script to read in full PEM data or observing-mode DARM-related channels, folds it upon itself in 4-second intervals, computes an FFT of the folded data, excises unwanted bands, then inverts the FFT to get a band-passed/low-passed/high=passed time series. Discontinuities at starts of science segments are handled with a smooth ramping, and the 4-second intervals are shifted by a half-second to avoid artifacts on integer-second boundaries due to the data processing. All 4-second intervals are synchronized to be commensurate over gaps in data. Attached below and linked here are summary plots for Sept-Dec 2015 for two magnetometer channels (40-Hz low-pass): H1:PEM-EY_MAG_EBAY_SUSRACK_QUAD_SUM_DQ H1:PEM-EY_MAG_EBAY_SEISRACK_QUAD_SUM_DQ and a summary plot for Sept-Dec 2015 for the DARM-related suspensions channel (10-50 Hz band-pass): H1:SUS-ETMY_L3_MASTER_OUT_LL_DQ Corresponding monthly and daily plots can be found by drilling down at these links: H1:PEM-EY_MAG_EBAY_SUSRACK_QUAD_SUM_DQ H1:PEM-EY_MAG_EBAY_SEISRACK_QUAD_SUM_DQ H1:SUS-ETMY_L3_MASTER_OUT_LL_DQ
1730 - 1742 hrs. local -> To and from Y-mid Took 2 min 30 secs to fill @ 1/2 turn open. Next overfill to be Wed., Feb. 24th before 4:00 pm (local) No vacuum people on site during the day today -> Good catch by the aware operator - TJ -thanks TJ
C. Cahillane I have removed a double-counting error found in the final total uncertainty budget. All of the original fits for each component remain the same, but the final budget is reduced for each actuation stage and the sensing function by a little under a factor of sqrt(2). I have posted the new results below for C01, C02, and C03. You can run the updated code at the calibration SVN: aligocalibration/trunk/Runs/O1/Common/MatlabTools/strainUncertainty_Final_O1.m For the equivalent LLO Budget please see aLOG 24915.
I have subtracted SRCL coupling from DARM, and found that residual noise has the shape of 1/f4-5 at 15-30Hz. I remember when L2 was in acquire state we could see actuator noise in this frequecy band in DARM. For this reason I decided to look into L2 noise again even though actuators are in the low noise (state 3) during current locks.
All 16 actuators show similar noise levels. Attached plot shows spectra for one of them (ITMX LL) in different states. When there is no control signal, actuator noise in low noise state is a factor of 10 smaller compared to acquire state in the frequency range 10-30Hz. However, if a small (few counts) low frequency excitation is applied, then actuator noise increases by a factor of 10. The noise increases almost by the same level if a large excitation is applied. I decided to check if upconversion happens in DAC, actuator or noise monitor. Control signal was shifted by a DC offset (10000 cnts) and actuator noise has reduced by a factor of 2-3. From this measurement one might conclude that DAC is responsible for extra noise. Also, we run oplev servo on the ITMs and even though control signal is aggressively low passed, actuator noise still increases above 10Hz.
Since L2 actuator noise depends on the low frequency control signal (or DC offset), then actuator noise may or may not be coherent to DARM at 10-30Hz. However, when we looked at DARM spectrum with bandwidth of 1Hz, we saw that noise goes up and down by a factor of 1.5 at 10-30Hz.
We have measured the differential actuator noise in low noise by notching ETMX control signal at 20Hz. Spectrum is 0.1 cnts/sqHz and is consistant with the noise when small low frequency excitation is applied (and a factor of 10 higher compared to the case when no excitation is applied). Total noise from L2 is 1.4e-19 m/sqHz at 10Hz and from L1 is 2.2e-18 m/sqHz at 10Hz. This result is consistant to the previous measurement using pringles technique (Chris alog 21070).
Evan, Kiwamu, Den
We measured L2 actuator noise directly from the coils on ITMX. We did not find any irregular noises, current noise looks normal. We have also measured the noise on each coil end relative to the ground. At 20Hz the noise level is 4uV/sqHz. We drive one of the coils in common relative to the ground with 300uV at 30Hz but did not see any noise in DARM.
Kiwamu, Den
Tonight we have shut down ITMX and ITMY L2 drivers while in low noise to double check that these drivers do not cause extra noise at 15-30Hz. We did not see any change in DARM. We would like to do the same test for ETMs.
Den, Kiwamu, Evan
We continued investigations into locking robustness and low-frequency noise.
Notes on robustness:
>> Engaging the soft loops is still painful, particularly in yaw. When the loops are ramped up to their nominal gains (a few tens of millihertz bandwidth), the SRM yaw loop misaligns the SRM in yaw, which causes POP90 to rise and causes lockloss after about 1 minute. If the SRM yaw loop is turned off, this misalignment does not occur. So far, the most reliable way to engage the ASC is to (1) engage the soft loops with the −20 dB filters, and let them run for a few minutes, (2) turn off the SRM yaw loop, (3) turn off the −20 dB filters in the soft loops, and then (4) once the soft loop error points have reached 0, turn the SRM yaw loop back on. This has not been added to the guardian.
>> Den retuned the PR2 actuator feedforward which decouples MICH from PRCL, but this has not been added to the guardian yet.
Notes on noise:
>> Similar to yesterday's frequency noise test, we injected high-frequency noise into the ISS first-loop error point. We drove several volts (both sine waves and broadband noise) up to 10 MHz, but we did not see any nonlinear coupling.
>> As noted previously, the input jitter coupling into DARM is worse than before, particularly in pitch. Den opened the SRM angular loops and moved SRM to minimize the coupling. However, this seemed to make the noise worse in other places. In particular, the region from 35 Hz to 70 Hz swas dominated by some kind of nonstationary excess (perhaps scattering in HAM6). Also, there appeared to be a slight excess frequency noise above 5 kHz.
>> We drove the ITM ring heaters (upper and lower) in common-mode in order to measure the voltage-to-displacement coupling in DARM. By driving a few lines at 250 mVpk between 80 and 160 Hz, we could see that the coupling goes like 1/f2. The levels at 160 Hz are as follows:
| Upper (m/V) | Lower (m/V) | |
| IX | 2.1×10−17 | 4.6×10−17 |
| IY | 0.27×10−17 | 1.0×10−17 |
>> We flipped the sign of the DARM offset. Normally we run with the X arm shorter than the Y arm (i.e., a positive offset is applied at the DARM error point, and DARM is Lx − Ly); so here we are running with X arm longer than Y arm. This is achieved with the ISC_LOCK paramter lscparams.omc_sign that is applied at the appropriate points during the dc readout handoff. The sign of the SRCL feedforward also has to be flipped, and the SRCL FF filters that we normally use cause some 1 Hz instability that unlocks the interferometer. We installed a more aggressive AC coupling filter (FM8), and this solved the issue. DARM has a small amount of excess noise with this new offset, but the SRCL coherence does not seemed to have changed much after FF retuning. Good time to look at is 2016-02-21 21:44:40 (bruco).
Measured coupling of ETM ring heater potential to DARM at 162Hz
| Upper (m/V) | Lower (m/V) | |
| EX | 2.0 ×10-17 | 2.2 ×10-17 |
| EY | 2.1 ×10-16 | 2.3×10-16 |
This measurement shows that EX potential coupling to DARM is similar to IX and IY. However, EY coupling is higher by a factor of 10.
One interesting conclusion is that the coupling of EY potential is similar to LLO (alog 16619) before this TM was discharged. At the same time oplev measurements show small charge on the surface.
Attached plot shows reduction of PRCL control signal when MICH feedforward is running. We actuate on PR2 M2 with gain of 0.24 and assume that BS and PR2 actuators have the same frequency response above 5Hz.
Attached plot shows reduction of input jitter noise seen in DARM after SRC alignment.
We drove IM4 and SRM in angle and measured first and second harmonics of the drive in arm transmission power, POP_DC, AS_DC and OMC_DC. This measurement has shown that PRC and arm misalignment is small (2.3e-3 of divergence angle) and SRC for sideband is also good (0.06 and 0.1 of divergence angle for yaw and pitch), but can be better. Since we could clearly see some misalignment on the camera, we opened SRC1 loop and moved SRM manually by 10urad. SASY90 has increased by 3% and jitter coupling has reduced by a factor of 5. We also noticed that for particular SRM alignments DARM noise increases by a factor of 2-3 in the frequency range 40-80Hz.
Tomorrow we plan to continue investigations on alignment and on potential coupling to DARM.
Higher coupling of ETMY RH potential to DARM is not surpring since ESD bias was equal to 400V during the measurement.
The attachment shows the DARM offset flip test with SRCL control noise removed. It seems that the positive sign is still slightly worse than the usual negative sign.
Yesterday, I switch the HAM3 ISI to use the "HAM5" STS (now, actually in the biergarten), did an initial measurement to make sure the ISI was performing okay, then left it overnight. This morning I compared it's performance to HAM2, and I think we should switch all of the ISIs to used this seismometer. Attached 3 spectra show the GS13 spectra for X,Y and Z over a ~1 hour period overnight. In all DOF's over most frequencies, HAM3 does better than HAM2 now, where previously they had performed similarly (excepting HAM3's transient .6hz mystery line). Most important, HAM3 does much better where sensor correction gets us most of our isolation (~.1-1hz). This is an easy change, and should be totally transparent.
I can't do more than just speculate at the moment, but I wonder if HAM3's better performance of the sensor correction than HAM2 isn't because the sensor is better but because HAM3 is ~15 [m] closer than HAM2. Is HAM2 using the "HAM2" STS-A, and is it still right under HAM2? I've lost track of Hugh's STS juggling...
All corner station platforms were using the ITMY (STS2-B) sensor, but Jim has been switching the platforms over to the HAM5 (STS2-C) sensor which has been moved to the BierGarten near STS2-B.
Tracking Names: SM1 = IM1, PMMT1 (MMT1) = IM2, PMMT2 (MMT2) = IM3, SM2 = IM4
UPDATE:
As of today all HAM3, HAM4 and EX Amps have been modified. HAM2 amps will have to be re-addressed due to an error in installation of the mod. 3IFO boxes are in process.
- Ed