Sheila told me that there were two kinds of mysterious events in IMC

1. IMC unlocked during ALS diff
2. MC1 and MC3 suspensions tripped for some reason

So I looked into these two kinds of incidents. Here is a summary of my understanding of what were happening, although they are not 100% understood yet.

(IMC unlocking events)

This was due to saturation in the longitudinal drive at the M3 stage of the MC2 suspension. I picked up two unlocking events from this after noon at  around 22:24 and 22:53 UTC respectively. Both unlocking events were caused by saturation in the M3 stage of the MC2 suspension. I attach a screenshot of the lockloss analyzer for the 2nd event:

In the upper right panel of the attached lock loss, it is clearly seen that the M3 longitudinal drive hit the limiter (which had been set to be close to the DAC saturation counts). According to T1300079-v2, the range of the M3 stage is about 0.5 um in peak. Therefore, roughly speaking, the IMC cavity must have moved more than 0.5 um in order to saturate the DACs.

On the other hand, we have no idea of why the IMC length motion (or perhaps PSL frequency) moved by such amount on a time scal of 200 msec or so.

We switched the coil driver setting to "Acq on, LP off" to see if it helps, but we then had another incident which was also caused by the same issue. We then turn them back into the low noise mode i.e. state request=1.

(MC1 and 3 tripping)

At the beggining, I was imagining that the MC1 and MC3 suspensions were kicked by the ASC loops right after the IMC unlocked. However, carefully looking into them, I found that they tripped some times after a lock loss. In a case, they tripped ~40 seconds after the lock loss event at around 22:53 UTC. According to various IMC ASC data, it seems that DOF4 gave a huge impulse (~10⁷ cnts ! ) to the MC1 and MC3 suspensions. This happened when the IMC LOCK guardian catched a fringe and hence a high build up. See the attached below:

It looks as if the DOF4 maintained a large number during they were off and then released it when the ASC was triggered. A strange point is that any of the IMC ASC loops, including this DOF4, should not maintain the past values as all the intergrators are cleared by the filter trigger in every lock loss. We double-checked the history handling of the integrators in foton, but they were set right -- no history maintained. Also, we reloaded the latest filters in order to be 100% sure that the filters in the front end are actually the ones in the latest foton file.

P.S.

We hoped that the issue would be gone by loading the latest foton file, but it seems to still persist. We had another incident where the MC1 and MC3 suspensions were tripped again when the IMC lost the lock. The lock loss was initated by saturation in the M3 stage of the MC2 suspension. Almost at the same time as the lock loss, the DOF4 kicked the MC1 and MC3 suspensions again. Hmmmm.... We need to further investigate this issue.

I updated the generate_QUAD_Model_Production.m function so that you can now specify a foton filter for the damping loops. Oplev damping is not yet supported.

The generate script is in

.../SusSVN/sus/trunk/QUAD/Common/MatlabTools/QuadModel_Production

You will also need to svn up

.../SusSVN/sus/trunk/Common/MatlabTools

since this is where the foton file reading functions are located (imported from the SeiSVN)

You can still specify the usual .mat struct file as before. The generate script looks for the .txt extension to determine if you are sending it a foton file.

Here is an example of how to make a model with damping filters read from foton:

quadmodel = generate_QUAD_Model_Production(frequency_vector_for_plots, 'fiber' , [] , 0 , 1 ,'/opt/rtcds/lho/h1/chans/H1SUSETMX.txt');

The function has more instructions commented into its header.

While answering questions that Jim Warner had about the front end monitoring in the 2.9 rcg, we noted that he wanted a better way to set the monitored bit than a text editor.

So I updated the sdf_set_monitor script to optionally limit the list of channels it operates on. Now you can build a list of channels that you want to (un)monitor, save it as a file and quickly change the monitoring flag in the safe.snap file.

Examples:

Set all channels to be monitored:

sdf_set_monitor 1 safe.snap

Set all channels to not be monitored:

sdf_set_monitor 0 safe.snap

Set some channels to be monitored (leaving the rest as is):

sdf_set_monitor -c ~/monitor_list.txt 1 safe.snap

Set some channels to not be monitored (leaving the rest as is):

sdf_set_monitor -c ~/dont_monitor_list.txt 0 safe.snap

You need to create a file with the list of channels.  It reads one channel per line, and only reads until the first space, tab, ... so you can actually hand it lines from a snap file and it will extract the channels you give it.

This change is LHO only right now as I lack commit rights to the proper svn repository.

See Jamie's log at: https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=15907.

The following microphones were powered and connected to the PEM AA chassis in the CER. 
HAM2 MIC
BEER GARDEN MIC
CER MIC

The electrical grounding situation in the HEPI Pump Station controller/servo is not robust.  See the attached where while fussing about in the area in early December I somehow disrupted the ground.  The pumps went down at this transition (not necessarily causal) but when the platfoms comeback under control, the local sensors will usually have some offset.  What I done in the grace window is repeat the channels in 2 & 3 and 4 & 5 and zoomed into them to a similar level to see if the position sensor is noisier after the increase in noise on the pressure channel (trace1.)  I'd say the answer is maybe..maybe not.  Maybe JeffK will suggest a better way to study this.  I can alwasy just switch the servo into manual mode and that way the drive to the pump station will be unchanging and not effected by the controllers response to the pressure channel noise.

Meanwhile, we should continue to get back to the quiet signal time however that may be achieved.

Based on my measurements this morning, it seems when the coupling is as small as it is for ITMX HEPI Z to ISI RX, the numbers we calculate are not accurate enough to use.  A much more resolved measurement with many more averages may be required to calculate the correction factor directly.  Otherwise the proper value may be found with an iterative approach and may frankly not be worth the effort.

Origins

See Fabrice's logs 8280 & 8284 for some informative references.  The problem is (can be if the coupling is large enough) vertical motion on HEPI is not perfect likely caused by imperfect actuation on the four corners gives a tilt (RX & RY) to the ISI.  Why would this be if the RX & RY loops are closed..error of Inductive Position Sensor??  The Trilliums feel this tilt and it shows as Y & X translation at low frequencies <<0.01hz.  We much prefer to use this interial sensor at those frequencies and will be injecting noise into the ISI motion without correcting for this. 

See alogs 15808, 15746, 15729,  & 15726 for measurements collected for calculating the correction value for the H1 BSCs.  The BS had the largest coupling in the Z to RX of 1.7% (see Krishna's 15745).  ITMY Z to RX and BS Z to RY had the next largest couplings of .49 & .38%.  Looking at logs 15726 & 15745, the amount of improvement based on the calculated coupling factor is still pretty clear.  However, the amount of coupling for ITMX Z to RX & RY and ITMY Z to RY is much smaller.  I calculated and implemented the correction ITMX Z to RY in alog 15729 but this 0.15% decoupling is difficult to assess as successful.

Now

Given the need to run many averages at 0.004hz bw, I never installed the other small corrections on the ITMs.  I had the data to calculate them and I did that this morning.  The process is drive the HEPI in Z and measure the T240 X & Y response.  The low frequency (<.0.01hz) response is tilt especially if it is not falling off toward lower frequencies.  We then drive HEPI in tilt (RX & RY separately) to get the actual tilt of the ISI when HEPI tilts.  Fabrice's alog 8284 details this and we divide the induced tilt by the direct tilt to get the correction.  Fabrice proposed that the sign of the correction was determined by the phase of the these two--if the phase are the same, the sign is positive.  This has seemed to hold up for the larger coupling situations.

If you look at the right column of plots in the attached ddt you'll see the crossline coupling (that is Z to RX for ITMX) data.  The blue traces are the undecoupled z drive data and the green trace is the HEPI RX tilted data, all collected before Christmas.  Dividing the magnitudes of the blue by the green traces between 30 & 90 mhz gives a correctioin factor of 0.0010 to 0.0017 averaging out to 0.0013.  The sign seems like it should be positive as the phase at low frequencies is similar and certainly not 180 degrees out.

Okay, with the correction factor of +0.0013 installed, another HEPI Z to ISI tilt was measured and the pink curve results.  It was looking pretty consistantly wrong so I aborted the measurement after 6 averages.  Not many averages for this measurement I agree but it wasn't jumping about, it was pretty steady bad.  Notice the phase of the pink here, now that is 180 degrees out.  Okay so I switched the sign and again after 6 averages the measurement (red traces) was aborted and it looks as equally bad as the pink.

Interestingly, in the right column of the DTT plots(HEPI Z to ISI RY), the correction factor calculated (0.0015[similar magnitude]) and affect measured(alog 15729, Dec18, brown traces) would suggest that maybe at least it did no harm(Magnitude may be lower and the coherence is lower) and remeasureing again today (red trace,) suggests it isn't unstable.

Conclusion/Next

This leads me to the conclusion that some detail of the plant condition/measurement set up is just not consistant enough to give a robust calculation at these coupling levels.

I think the next step is to remove the coupling factor and remeasure this Z to RX and see if it is similar to the blue.  If it is similar, then good, things are maybe stable with time.  And if we care, figure our a more robust measurement setup, or fish around with the coupling factor and find the minimum by search.  This of course will be slow, painful and have the platform unusable for a few to several hours.

The likely course will be that we don't care about the coupling at this level and leave them unpopulated for now.

An update on the DCS construction. The duct work is 98% complete, waiting on registers and grills. The condensate lines are complete. Exhaust hoods installed on the outdoor units. Electrical is ongoing.

Nergis, Evan

The ETMX oplev was badly miscentered in yaw. We have recentered it.

We did not make any changes to the whitening board settings. A picture is attached.

Sudarshan, Keita, Evan, et al.

The source of excess power on ISS PD is  Aux laser at IOT2R.

We were seeing a lot of power on the ISS PD than usual. This power level in the PD changed (went up significantly- about a factor of 4) sometime around 12/11/2014. I was trying to figure out if this was the real signal or something in the electronics went bad but with no luck. However I noticed that the power level on ISS PD was reasonable since 3:30 on Wednesday. These power level on PD corresponded with the power on IM4_TRANS_QPD as well (See trend plots below).

Yesterday after looking through a lot of possible explanation about the power level changes in IM4_TRANS_QPD with Keita and coimmissioning crew, we realized this excess power was coming from the Aux Laser setup on IOT2R for Schnupp asymmetry. The power level change coincides with the timeline of Schnupp measurment setup (alog 15566), and on Wednesday at 3:30 PM  Evan blocked this aux laser beam with the beam dump. Evan and I went down to IOT2R this morning to do a sanity check if this was indeed the source and no surprise.

Attached are trends of the vertical ETM OSEMS for the past 64 and 4 days, respectively.

Last night we saw ETMX had large 0.43 and 0.5 Hz modes in the oplev, despite the damping. These are long-pitch modes.

To investigate I made some top mass measurements. See the osem centering image. The M0 F1 (top left speed dial) is far from center, with the large alignment offsets. It might be beyond the linear range. I measured some TFs on the top mass. See the second image. Black and read are undamped, without and with the offsets. The these should match, but they don't at the first two modes. Blue and cyan are the same, but with damping. They should match, but they don't. It might be that the first two modes are dipping into the non-linear range. This could limit the damping, and permit these modes to ring up.

model restarts logged for Wed 14/Jan/2015
2015_01_14 06:42 h1fw0
2015_01_14 12:06 h1dc0
2015_01_14 12:08 h1broadcast0
2015_01_14 12:08 h1fw0
2015_01_14 12:08 h1fw1
2015_01_14 12:08 h1nds0
2015_01_14 12:08 h1nds1
2015_01_14 12:51 h1iscey
2015_01_14 17:41 h1fw0
2015_01_14 19:04 h1fw0
2015_01_14 19:28 h1fw1
2015_01_14 20:27 h1fw1

Several unexpected fw restarts. New h1iscey code with associated preceding DAQ restart.

model restarts logged for Thu 15/Jan/2015
2015_01_15 09:52 h1fw0
2015_01_15 19:26 h1fw1

Two unexpected fw restarts.

J. Kissel, T. Sadekci, B. Weaver

We've made a first attempt to use the State Definition File (SDF, see e.g. LLO aLOG 15907, or G1500060) system on H1SUSMC2. You can find a play-by-play below, but most importantly, we think we've found a major flaw in the system. 
Here's the use case:
Taking MC2 from SAFE to ALIGNED using the SUS guardian, then using the IMC_LOCK guardian to lock the IMC, uses several _SW1S or _SW2S channels (i.e. those bit words that define the first and second halves of the switchable buttons in a filter bank) in H1 SUS MC2 -- for the exact list, see first attached screenshot. For example, in the M1_LOCK_L bank, the input, and FM1 are regularly switched ON and OFF by guardian, but FM2 should always be ON. As such, we'd want the SDF system to monitor FM2, but not FM1 or the input switch. The second attachment, captured *after* we changed all settings to being monitored, and then brought the SUS up from SAFE to the IMC LOCKED, shows this. BUT, all three are controlled by the SW1S channel, which we must chose to be *either* monitored or not. So, if we chose to not monitor the input and FM1, we loose the ability to monitor FM2.

Jonathan and Dave inform me that monitoring each bit individually has been considered, but not yet implemented. I think this IMC use case scenario (which is representative of a LOT of suspension and ISC filter banks) demonstrates that we DEFINITELY need a bit-by-bit monitoring system before we can reliably roll out the SDF system for filter banks. Note -- for EPICs channels with unique identifiers, like the a GAIN, MASTERSWITCH, or matrix elements, the SDF system is already great.


Play-by-play:
- Find the directory in which a given user front end code's safe.snap lives:
    jeffrey.kissel@opsws8:~$ cd /opt/rtcds/lho/h1/target/h1susmc2/h1susmc2epics/burt/
    jeffrey.kissel@opsws8:/opt/rtcds/lho/h1/target/h1susmc2/h1susmc2epics/burt$ pwd
    /opt/rtcds/lho/h1/target/h1susmc2/h1susmc2epics/burt
- Make sure it's a soft link to the userapps repo:
    jeffrey.kissel@opsws8:/opt/rtcds/lho/h1/target/h1susmc2/h1susmc2epics/burt$ ls -l safe.snap
    lrwxrwxrwx 1 controls controls 63 Jan 11 15:19 safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susmc2_safe.snap
- Add a "1" to the end of the line for all EPICs settings channels in the safe.snap file, such that all settings go from being unmonitored to monitored -- do so using Jamie's USERAPPS/sys/common/scripts/sdf_set_monitor, documented in LLO aLOG 15907:
    jeffrey.kissel@opsws8:/opt/rtcds/lho/h1/target/h1susmc2/h1susmc2epics/burt$ sdf_set_monitor 1 safe.snap
- Try to be too clever, and use the command line to push the "LOAD Table Only" button:
    jeffrey.kissel@opsws8:/opt/rtcds/lho/h1/target/h1susmc2/h1susmc2epics/burt$ caput H1:FEC-39_SDF_RELOAD 1
    Old : H1:FEC-39_SDF_RELOAD           0
    New : H1:FEC-39_SDF_RELOAD           1
- Watch with sadness at the MC2 suspension get immediately forced to a safe.snap and the IMC lose lock. Why? Because *all three* SDF load buttons are the same channel, but a request of "1" performs the "Load Settings and Table" action. Too greedy.
- Use SUS guardian (just because that's the screen I had open) to request ALIGNED again, so no action, realized it was because MC2 was managed by the IMC_LOCK manager, which eventually requested the same, and restored the IMC.
- Begin to hand edit the modified safe.snap
    jeffrey.kissel@opsws8:/opt/rtcds/lho/h1/target/h1susmc2/h1susmc2epics/burt$ gedit safe.snap&
- Get scared that you're not changing the right channel, make a few mistakes, hit the reload button, eventually run into the fundamental flaw described above and stop.

Sheila, Kiwamu, Evan, Nergis, Alexa,

Since we got ALS diff working again, we moved onto the full lock attempt. So far we got back to a point where DRMI was locked with the arm cavities held by ALS at a off resonance. We locked DRMI twice this evening and each time DRMI dropped the lock right after the ASC loops came in. We need to look into this issue.

Even though we had aligned the DRMI before attempting the full lock, the DRMI looked misaligned a lot when we restored PRM and SRM. It seems that we ran a wrong ASC offloading script by accident in the initial alignment process which left a unneccessary offset in the M2 stage of PRM. We realigned PRM by misaligning SRM and locking PRMI while keeping the arm cavities locked. This gave us back good alignment in DRMI. However it took more than 15 minutes to get DRMI locked for some reason in both times. The DRMI unllocked right after the ASC loops came in both times. According to a brief look at the first lock loss, it seems that all three DRMI length error signals showed monotonically-increasing-oscillation for 0.5 sec before it unlocked (see the attached 0.5 -ish sec time series). Interestingly, IMC transmitted power increased at the same time by 10% or so. It is unclear what was going on at this point. Another thing is that it seems that the DRMI pulled ALS diff down when it unlocked and therefore this resulted in unlock of IMC.

[Koji, Dan]

This is a followup entry for LHO ALOG 16034.

Summary

- The OMC cavity was locked with PDH locking by implementing a bypass optical path from at the OMC REFL to the AS resonant RF PD.
- The OMC cavity length displacement was measured. It is found in the 4th attachment.
- It is mostly consistent with Zach’s measurement LLO ALOG 8674 and has x3 better floor level at some frequencies.
- There is a forest of peaks above 400Hz to 1.3kHz. They were very easily excited by light tapping on the HEPI crossbars

Motivation

- The length noise of the Output Mode Cleaners at LHO and LLO were so far locked with the transmission DCPDs with length dither or mid fringe with CDS.
- The measurement bandwidth with these techniques was limited by the CDS bandwidth (8kHz) or the dither frequency (2~3kHz). The cavity length noise above these frequencies wer e unknown.
- The measurements were also prone to the intensity noise on the beam. As the base band is at audio frequency in either cases, it is hard to be shot noise limited without proper setting of the intensity stabilization. Some features in the spectrum were not distinguishable from the intensity noise.

- PDH locking of the OMC was expected to provide an independent measurement of the OMC length noise with possibly better sensitivity, as the PDH locking is in principle insensitive to the intensity noise.
- In fact, the most of the conmponents for the PDH locking were already there. If we use the single bounce beam from one of the ITMs, the beam is already phase modulated. An RF PD is at the same table with the OMC REFL beam. The detection system and actuator are on the field racks next to HAM6. Therefore the effort of the PDH locking was minimal.

Configuration

- The ITMY single bounce beam was guided to the OMC. i.e PRM/SRM/ITMX/ETMX/ETMY were misaligned.
- The beam alignment to the OMC was controlled using OMC QPDs. The dither alignment servo has not been configured and was not functional at the time.
- The OMC REFL beam was aligned to the OMCR path on ISCT6 by moving an in-vacuum picomotor as Dan described as Dan described.

- The OMCR beam was introduced to ASAIR_A PD without moving existing optics on the table. As found in the figure (attachment 1), an additional optical path was added to the OMCR path. The OMCR beam was deflected between two lenses and brought to AS45 PD going through the space between the mirrors in the AS path. The beam on the PD was focused by a lens with the focal length of 150mm. This made the spot sufficiently small for the 2mm aperture of the PD.

- With the single bounce configuration, the optical power from the chamber was ~10mW.

- The servo configuration is found in the figure (attachment 2). The AS 45MHz demodulator was used for the PDH sensing (i.e. no rewiring was necessary). We found our bad luck that the proper demodulation phase was about 45 deg off and the signal size in the I and Q phases were almost the same with opposite sign. This meant that we could combine these two with another SR560. But we decided to use the I signal for the error signal.

- Since there is no digital signal path from LSC outputs to the OMC PZT, we implemented an analog servo. The error signal from the demodulator I-phase monitor channel was fed to an SR560 with gain of -2 and LPF (-16dB/Oct, fc=300Hz). The 50 Ohm output of this SR560 was fed to another SR560 with the gain of the unity. The second SR560 was used as a summing point for an openloop TF measurement. The 50Ohm output of the second SR560 was connected to an aux drive port of the HV driver.

Servo modeling

- You may wonder how just a 300Hz 2nd order LPF could make the servo stable!? In fact, we could lock the cavity even with gain of -1 with flat response. This is a subtle combination of the dewhitening and the poles and zeros formed by the PZT capacitance and the output RC network of the driver.

- The open loop transfer function of the servo was measured (attachment 3) by injecting the excitation at the second SR560 while the "after sum" (denominator) and "before sum" (numerator) signals were observed with SR785.

- Driver/actuator response: The HV Piezo driver (D060283) has two dewhitening stages and an output RC network. The dewhitening stage, which are common for the digital and external analog inputs, have two poles at 0.923Hz and two zeros at 10.15Hz with the DC gain of the unity. Note that the signal is reduced by a factor of 0.9989, as the input impedance of the driver (47.5kOhm) and the 50Ohm output impedance of the SR560 form a voltage divider. The main HV stage has the gain of 10. The output stage has the output series resister of 50k (R51) and then the parallel capacitors including the PZT capacitance of 0.51uF (Noliac NAC2124). (C11 - 0.47uF // C26+R55 - 0.47uF // Cpzt - 0.51uF). This imposes two poles at 2.19Hz and 502.1Hz, and one zero at 338.6Hz. Finally the OMC PZT2 has the calibration of 12.9nm/V (measured at Caltech), and the beam incident angle of theta = 4.04deg, and parasitic mechanical resonance of the PZT tombstone (pole at 9.5kHz Q=100 and zero at 11kHz Q=100). Don't forget that the factor of 2 i.e. cavity length change = 2/cos(theta) * PZT displacement

- The model of the openloop transfer function agrees exteremely well with the measurement. From this model, we determined the slope of the PDH signal to be 4.0e9 V/m.

Cavity displacemen noise

- Calibrated cavity displacement noise is found in attachment 4.
- The red curve is the error signal calibrated in the unit of displacement. The compensation of the loop supression was applied to this red curve in order to obatin the "estimated free running motion" of the cavity (Blue curve).
- The estimated cavity displacement seems to have better floor level by a factor ~3 compared to the half-fringe measurement at LLO. Also the spectrum below 300Hz looks cleaner and smoother. We wonder what is the cause of this noise.
- Similar to the LLO measurement, the spectrum has forest of peaks from 400Hz to 1.3kHz. There is very eminent peak at 9.5kHz which is associated with the prism resonances of the cavity.

- The dark noise was estimated to be 3.3x10^-17m/rtHz. I made the simplest estimation of the shot noise level. The dark noise was assumed to be limited by the PD noise. The shot noise intercept current is 2mA and the photocurrent was ~8mA. Therefore the shot noise level was estimated to be 3.3x10^-17x Sqrt(8/2) = 6.6x10^-17 m/rtHz.

Peaks between 400Hz and 1.3kHz

- It is unlikely that the OMC cavity itself has such many mechanical resonances from 400Hz to 1.3kHz. It is known that the OMC cavity has one high Q resonance at 1kHz (body bending mode). But any other resonances are above 3kHz.

- We tapped the ISCT6 tables, theHEPI crossbars, and chambers in order to see if we can excite these forest somehow.
- Basically everything is accoustically coupled. But we dare to say that the table does not excite the noise much. The most sensitive one was the HEPI crossbars. Just light touch of a HEPI cross bar excited the modes nearly x100 (attachment 5). This excitation was more eminent at the HEPI crossbars than at the chamber or the flange for the windows.

Still to do

- The displacement data is to be compared with the measurements with the other techniques.
- The displacement with PDH while the cavity is locked with the dither locking.
- Noise coupling from the OMC ASC.
- Evaluate frequency noise coupling.
- Actuator noise from the PZT driver.

Alexa, Kiwamu, Sheila, Koji, Evan

DRMI ASC

Finally we were able to lock DRMI with the high-bandwidth ASC loops.

The key here was to move IM4 so as to center the forward-transmitted beam on POP B. In addition to reducing the amount of offset for the INP error signals, we believe (based on camera images) that this reduced the amount of light scattered on the PR2 baffle.

After moving IM4, we then adjusted PRM and PR2 so that PRX would lock again. We then proceeded with the usual initial alignment of the corner optics.

Once DRMI had locked, we engaged the MICH, SRC1, and SRC2 loops without issue, and then transitioned them to high bandwidth (by turning off the -20 dB filters and ramping down the BS oplev damping).

Then we were able to engage the PRC1_P and PRC2_P loops without issue, and transition them to high bandwidth (by turning off the -20 dB filters, and turning on the PRM M1 and PR3 M1 locking filters).

Initially we had difficulty turning on PRC1_Y and PRC2_Y. However, we found that we could get them to work by engaging them in close succession. Kiwamu conjectures that there may be some gain heirarchy at work here.

Then we were able to engage INP1_P. Initially we put in an offset at the error point so that the loop would not immediately try to integrate away the error signal dc value. However, we were able to turn the offset off without issue.

The only tricky business here was INP1_Y. At one point (before working on the PRC loops), we turned it on (with an offset) and found that we had to flip the sign of the gain (from 300 ct/ct to -300 ct/ct) to keep the POP buildup stable. However, once we engaged it last (after all the other loops), we found that the original gain works fine. It's still unclear what's going on here.

The new slider values for IM4 are outside the "safe" range found by Keita and Alexa (LHO#). But since the IMC pointing has been changed since then, it's not clear that these safe values are still valid.

We started a (hopefully) long DRMI1f+ASC lock at 2015-01-10 05:21:00 UTC.

DRMI lock acquisition

When DRMI locking becomes sluggish, we found it is helpful to misalign the SRM, then wait for PRMI to lock, then adjust PRM and BS to maximize POPAIR_B_RF18. Then upon breaking the lock an realigning SRM, DRMI appears to lock more quickly.