The HV voltage for the ESD in EX was turned on this afternoon ~3:00PM. Richard spoke to Kyle regarding the vacuum pressure before enabling the HV. Filiberto C, Richard M.
Kyle, Gerardo Y-end turbo+QDP80 pumps valved-out but left running for now
The temperature sensor box for the reference cavity temperature stabilisation was swapped out. old: S1400577 new: S1107831 The old one had a suspected blown regulator.
The two uncontrolled degrees of freedom in the mode cleaner ( MC1 - MC3 in pitch and MC1 + MC3 in yaw) are now under control. These two degrees of freedom result in motion of beam spots on the ASC_IMC WFS sensors. The beam spot on the WFS_B_DC sensor is now controlled with the DOF_4 servo loop in the ASC_IMC model.
This scheme avoids two potential problems which could arise if we use IM4_TRANS as the sensor of choice for controlling these two degrees of freedom.
a) IM4 TRANS QPD is affected by the longterm drifts of IM1,2 and 3. We would be folding these drifts back into IMC alignment if we use this sensor.
b) These drifts could further result in a drift of the spots on the WFS (since this is not a controlled parameter) and that could generate RIN due to spurious offsets in RF WFS signals.
During the course of this work I have made the following changes:
1) Offloaded the servo loop outputs using the Offload_WFS script
2) unlocked the mode cleaner and misaligned the MC2_PIT (to prevent flashing of the IMC)
3) centered the prompt reflection on the IMC WFS
4) realigned the MC2 and relocked the mode cleaner
5) the extinguished field landing on the IMC_WFS QPD generates a random offset due to the wierd pattern of the HOM. This was zeroed out using offsets in the WFS A and B, DC (PIT and YAW) sensors. (Had to fix some macro entries in medm screens of the PIT and YAW filter banks so that we can get at the offsets)
6) adjusted the output matrices to 0.5*(MC1-MC3) in Pitch and 0.5*(MC1+MC3) in Yaw. Attached screen shots show the situation before and after these changes to the input and output matrices.
7) Checked the stability of the servos.
8) There has been no significant shift of the beam on pointing into the IFO as a result of this work. Attached pic shows the time trends of IM4_TRANS_PIT and YAW
9) The UGF of these loops is about 100 mHz (a factor three lower than other loops in the ASC_IMC)
10) Next I will look into determining the DC offsets which minimise the jitter to RIN coupling.
11) I have modified some of the indicators in WFS_MASTER medm screen so that the switching on and off of the servo loops by IMC Guardian is apparent on the screen.
Havent had a chance to see the effects of some of these changes since the mode cleaner has not been locking in the past couple of hours due to ongoing work in the PSL ref cavity alignment.
Hugh and I were concerned that safe.snaps were not current for all the chambers, so I took the disruptions caused by the PSL work as an opportunity to update I/ETMX, and HAMs 4,5&6, ISI's and HEPI's. HAM5 ISI has some weird masterswitch/dackill coupling, which we've seen before, but I paid more attention to what I had to do to make it work this time. Closing the master switch trips the dackill and the rogue excitation wd. The only way to recover the ISI is to turn on the masterswitch, reset the rogue excitation wd, then reset the dackill. Then guardian can take over and bring the chamber up. None of the other chambers I did required this. Very weird.
Clean up after Dec. 24 power glitch: Restarted 3 front end computers that rebooted before the boot server was ready (they couldn't find the PXE boot image), restarted 2 other computers that had bad DAQ and timing status on all models. All restarted normally. Checked status of frame writer/data concentrator, it was OK. The DTS should be functional at this point.
no restarts reported
I was in the Control Room Sat, Sunday 2 - 7 PM reading ALOGS full screen. Alone; all quiet; no obvious pblms. Main gate refused to operate till wiggled, persuaded. DickG
no restarts, both days
Heard report of EQ in Idaho and checking the systems sure enough one of the SEIs had a trip. Just the one though. See the attached: The GS13 shows the arrival but didn't exceed trip limits until some secondary waves. The vertical sensors are noticably much quieter than the horizontals. The trip was 2 minutes after the event so this seems the reasonable cause. ITMX back to fully isolated no problems.
1305 - 1310 hrs. local -> In and out of Y-end VEA 1320 - 1325 hrs. local -> In and out of X-end VEA
I was onsite to day to give my family a tour. I took the through the LVEA for approximately half an hour. Evan was here and hadn't begun work yet and gave us the go ahead.
The dc voltage on the refcav transmission PD has again dropped below 0.4 V, which is the usual threshold for the autolocker to consider the refcav locked. For the time being, I've turned down the threshold to 0.2 V.
Attached is the transmission PD dc voltage over the last 60 days. The jump on 2014-11-19 corresponds to the last time the refcav pointing was touched up (LHO#15188).
no restarts reported both days.
Checking systems out found all HEPI Pump Stations Running fine and all HEPI platforms operating with no saturations--Seismic environment is pretty quiet.
Found HAM6 ISI tripped on CPS but I see no 20000 count excursion on the CPS plot, hmmm--see attached. This trip occurred yesterday 0740utc. Also on this snap shot are the ISI overviews: everyone is running very nicely green on the blrms for what that is worth--check out HAM4!
no restarts reported
model restarts logged for Mon 29/Dec/2014
2014_12_29 06:29 h1fw1
one unexpected restart.
Elli, Evan, Dave:
cdsfs0 (the /ligo file server) locked up this evening sometime after 18:43 PST. It was completely unresponsive, so Elli and Evan (with myself on the phone) power cycled the machine using the front panel button. It came back up with no problems and I was able to log into a control room workstation remotely. The system logs dont show any indication of the problem, it locked up silently. The attached logs show the last good log at 18:43 and the start of the reboot following power restoration at 19:17
Dec 29 18:43:58 cdsfs0 mountd[1623]: authenticated mount request from 10.22.0.141:1022 for /ligo (/ligo)
Dec 29 19:17:20 cdsfs0 kernel: imklog 4.2.0, log source = /proc/kmsg started.
I was not getting data at home from the external epics gateway, so I restarted this process. Also, I noticed a timing error on h1asc state word, which I cleared with a DIAG_RESET so it most probably was just a glitch on CPU_MAX.
Elli, Evan
For the past week or so I've noticed that initial alignment of the corner optics has become much more painful:
The second of these problems was traced to the LSC_CONFIGS guardian: the threshold for LSC-ASAIR_A_LF_NORM_MON was too high (300 ct), so that even if the lock was broken, the guardian would not register it. This would leave the MICH loop trying to acquire lock with two integrators on and no limiter on BS-M3_ISCINF_L. I've turned the threshold down to 30 ct. The MICH locking seems more sluggish than it did a few weeks ago, but now it locks instead of wandering off.
Elli and I tried for a while to fix the first problem, but nothing we tried seem to work. Turning up the gain only made the PRX lock oscillate. Turning off the slow pitch/yaw bleed to the M1 stage seemed to have no effect. Different combinations of REFL_A and REFL_B WFS seemed to have no effect. So this will require some more attention.
Today I was able to get good buildup in PRX (ASAIR_LF of about 4500 ct). In order to do so I had to adjust both PRM (by tens of counts) and PR3 (by a few counts). Since the WFS loop only touches PRM, it is not so surprising that it cannot always achieve good PRX buildup. In the past we usually haven't had to touch PR3 for day-to-day alignment, but since it's now used for DRMI/PRMI ASC loops, its pointing is now more variable.
Once PR3 has been touched up by hand, the WFS loop can take care of the rest. However, since it involves a very slow bleed-off from PRM M2 to PRM M1, we may want to find something faster for initial alignment.
One point I am not clear on is why PRM M1 P/Y and SRM M1 P/Y now have different filter settings. PRM M1 has a 1/f shape everywhere; SRM M1 has a flat gain of order unity. This makes SRM M1 more prone to getting kicked when M1 feedback is turned on or receives a sudden change in input; at one point it caused the HAM5 ISI to trip.
