IMC_F.png shows the 4 occasions from last night when the noise eater oscillated.  Anecdotally this tends to happen whenever
the IMC is trying to lock.  My conjecture is that rapid transients in the FAST actuator cause larger than normal changes in
the stress-induced refractive index change in the NPRO crystal, which in turn steers the beam out of the crystal a little
differently.  Since the photodiode used for the noise eater is relatively small, the beam could steer off the photodiode.
The reduction in photodiode signal then causes the noise eater to oscillate.  This does not happen all the time however and
I cannot explain why.  Zoomed_IMC_F.png shows that the IMC was not trying to lock at the time.

    Looking at the first time the noise eater misbehaved.  FAST_v_NoiseEater.png indicates that the noise eater oscillation
coincides with the third rapid increase in the FAST actuator output.  The long stretch where the FAST actuator is pegged at
~11.7V indicates that the FSS was not locked at the time.  SLOW_v_RCTPD.png shows that the FSS did not acquire lock at this
time but acquired lock during the second burst group of activity.  Of note is Kiwamu's observation that the FSS acquired lock
at a point outside the range where the SLOW actuator is limited to in software +/- 0.1V.  The FSS acquired with a SLOW
voltage of ~-0.25V.  The delay in settling down is the time taken for the so-called "temp loop" to be activated, presumably
by the autolocker.  Why it acquired outside this range might be due to the noise eater oscillating.

    Perhaps since the autolocker did not acquire on two flashes through the reference cavity, Travis disabled the autolocker
and began the hunt for the fringe manually.  Not realising that ALS likes having the SLOW voltage between -0.1V and +0.1V,
the crystal temperature kept being adjusted until a fringe was found.  The next fringe was found outside this range and the
FSS acquired at -0.25V, at which point the autolocker was re-engaged.

State of H1: in Initial Alignment, struggling to lock arms in green, have only had breif locks of X arm in IR

Details:

• winds between 10mph and 45mph across the site
• BRS at EX and EY turned off
• X arm in green locked but dipping below 0.5
• IMC on relock is pushing on MC2 so much that it's wise to pause in Ready to let it settle
• NPRO Noise Eater had to be reset twice, this seems like a apttern, like possibly the first reset doesn't really restore the system to a nominal state, and another reset is necessary
• useism is high, attampt to change BRS to WINDY_USEISM but didn't work as expected, set X by hand, Y is rung up so not being used
  •  small guardian code issue resolved by TJ, guardian behavior resolved

Site Activities:

• 16:15-16:45UTC - Chandra to both EX and EY VEAs to colect serial numbers
• 16:40UTC - Bubba to EY to add glycol to equipment in the mechanical room
• 16:45UTC - EvanG injected into Pcal
• 17:15UTC - I reset the NPRO Noise Eater
• 17:29UTC - I reset the NPRO Noise Eater
• 17:52UTC - Bubba back from EY

Summary:
The hardware injection inverse actuation filter has the correct amplitude and sign. This is tested using a known sinusoidal waveform and comparing the Pcal RXPD readback with the input to the inverse actuation filter. See attached figure.

Details:
Similar to my investigation of the sign of the inverse actuation filter (LHO aLOG 29072), I injected a 100 Hz signal, 1e-23 in strain amplitude, 0 phase using awgstream into H1:CAL-PINJX_TRANSIENT_EXC.

To verify the injection has the right amplitude and sign, I read out H1:CAL-PINJX_TRANSIENT_IN2 and H1:CAL-PCALX_RX_PD_OUT_DQ. The time-series data for both channels is bandpassed with a filter centered around 100 Hz. In this measurement, I did not turn on the [:1,1] filter (FM7) for the PCAL readback channel. Instead, I scaled the readback signal by -1e-4 (=-100^2). Also, I had to make an offset since there is a DC component to the Pcal signal. The TRANSIENT_IN2 has its time-series scaled by 4000 to convert between strain and meters.

The attached figure shows that the amplitude is nearly spot on, the sign is correct, and the known phase offset (~240 usec) is understood from the inverse actuation filter for the TRANSIENT injection path.

Thus, the inverse actuation filter for hardware injections is correct in amplitude and sign.

In case you need to retune the filter used for subtracting the HPO jitter (DBB QPD) from DARM, here are the steps

1. take some data with the feed forward off (set H1:LSC-JITTERFF_GAIN to 0, the jitter feed forward MEDM screen can be accessed from the LSC menu in the sitemap)
2. use the script attached below to fit the transfer function. Some notes
   1. set the GPS time and duration at the beginning. Typically 10 minutes of data are enough.
   2. the script will shows the measured coherence between DBB Q1Y and DARM, and the measured transfer function. Typically points with coherence above 0.05 are good for the fit
   3. you might have to tweak the frequency range and the coherence threshold for the fit, in order to get a good result
   4. sometimes the fit algorithm add a pole/zero pair with very high Q close to the edges of the fit range. Normally they are fake and you can remove them
3. the script will output the list of poles and zeros, upload them to the LSC-JITTERFF filter bank. Note that there is a gain of 8e14 in the DBB_FF_QPD1Y filter bank. This is added such that the typical gain H1:LSC-JITTERFF_GAIN is close to 1.

Notes:

• the transfer function should be compensated for the DARM closed loop response. For the moment being I haven't done it, since the subtraction matters only above ~100 Hz and there the DARM loop does not have a significant effect, at least not at the level of accuracy needed for the subtraction as done so far.
• the filter which is loaded now (named 16_10_13) was measured after the IFO was locked for few hours. It might be enough to retune a bit the gain to achieve reasonable performances

Last week KrishnaV and I found that there was a high pass  filter in the tilt subtracted sensor correction path that was limiting the endstation ISI performance at the microseism. ConorM-L suggest we try just turning these filters off, as the sensor correction filter is already rolled off pretty well at 8mhz. Cheryl had the endstation sensor correction turned off for a while this morning so I took the opportunity to try this out. So far it seems to be running okay. Attached plot is the EX ISI and ITMY for comparison. Green and pink are the EX ground supersensor and STS, red is the ST1 T240. Black is the ITMY STS, purple is the ITMY ST1 T240. Before the ETMs were getting very little suppression at .1-.2 hz, and now both ETMs are generally doing as well as the corner ISIs. We'll keep an eye on this for the time being, but I think we should run like this.

J. Oberling, B. Weaver

I checked on the TCS chiller this morning and added 350mL of water to bring the level from 5.0 to 8.9.  I then noticed that the mesh filter seemed to by pushing up out of the reservoir by a good bit.  I reseated the filter and noticed the level had dropped to 6.3.  There was still 50mL of water in the cup, so I added that to the chiller and observed the mesh filter.  Sure enough, the filter puffed up.  There is a large air gap between the top of the water in the reservoir and the spot that the filter seats into.  What I think is happening is when we fill the chiller, that air between the water and the filter has no where to escape quickly (probably due to the amount of water moving through the filter).  This creates an air bubble between the water and the filter that then influences the fill reading on the front of the chiller (hence why the reading went down when I simply reseated the filter).  I have a suspicion that the chiller has not been losing water, we just haven't added enough since the system flush to completely fill it, and when we do top it off we're creating an air bubble that influences the fill level reading.  We then think we've topped the chiller off when in actuality we haven't; as that air bubble slowly works its way out the level reading "drops," thereby making us think we're losing water.

I ran this by Betsy and found she was starting to suspect something similar.  We went out and removed the mesh filter and then topped the chiller off, then replaced the filter.  It took 600mL of water to move the indicator from 6.3 to 8.3, which is much less than we've seen in the past; if you look at the log on top of the chiller it can be seen that there are instances where we fill w/ 250mL of water and move the indicator from 5.0 to ~9.0, which is much less than the 600mL is took to go from 6.3 to 8.3.  This suggests that what I wrote above is correct, we haven't been fully topping off the chiller but have been fooled into thinking we have by an air bubble of our own creation influencing the reading of the chiller fill level.  One of us will check the chiller at the end of the day to check the chiller water level and see if we still need to add water (water has been added every morning and evening for every day this week).

Total water added this morning was 1000mL, and this moved the indicator from 5.0 to 8.3.

I copied Gabriele's JITTERFF MEDM screen, replaced H1 with $(IFO), and saved it as $(userapps)/lsc/common/medm/LSC_CUST_JITTERFF.adl.

I added a link to that screen in the LSC overview.

9:30am local

13 sec. to overfill with 1/2 turn open on bypass LLCV. Note LLCV is still set to 16% open. Exhaust piping is completely defrosted. Left bypass exhaust valve open. Next fill due Monday.

14 day plot, upper plot is corner station winds, lower plot is from the PSL, and at about 17mph the peaks in wind match peaks in the PSL dust monitor.

TITLE: 10/14 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Travis
SHIFT SUMMARY:  Very windy (gusts to over 60mph) since near the beginning of my shift with high microseism (~1 um/s).  Not great conditions for locking regardless of other issues we ran into.  Several dust alarms in the PSL and end stations.
LOG:

9:50 DIAG_MAIN notification that the Noise Eater was out of range.  Went to LVEA and reset Noise Eater.  Seemed to fix the issue

10:05 Another notification that Noise Eater is out of range.  Also, both ALS nodes went into fault with the same 'Beat note strengh' error (typo is in Guardian, not my log) that we saw earlier when Kiwamu found the FSS locked on the wrong fringe, aLog 30524.  I again went to the LVEA and reset the Noise Eater, then attempted to toggle the Autolock off/on per Kiwamu's aLog.  This did not fix the FSS issue.  I don't know what else to do here. 

10:23 Put Guardian into DOWN.  WIll require further investigation by PSL crew/commissioners before locking will happen.

 

Kiwamu, Terra

One thought for tracking PI mode frequency drift over a lock stretch (as seen here) is to utilize the drumhead modes: these are reliable in amplitude/presence and by monitoring their freq drift we could predictively change PI filters, etc. to handle drifting of higher modes.

Eigenfrequencies of the test masses have nominally been defined as proportional to square root of Young's modulus: f ~ E^1/2, where E := Young's modulus. The Young's modulus for fused silica has some temperature dependence ( measured to be (dE/dT)/E = 1.52e-4 / K ); as temperature increases, Young's modulus increases, so the mode frequency increases over a lock stretch. In this simple case we would expect all modes in a given test mass to have the same relative drift. Instead we see that del_f has mode dependence as well, i.e. the ~ 15007 Hz differential drumhead mode always drifts more than the ~ 8160 Hz drumhead mode of the same optic (relative to their frequency). I suspect this is due to different modes having more or less torsional versus longitudinal motion and so frequency dependence has both E (Young's) and G (shear) dependence. Peter also suggested nonuniformity of temperature in the test mass volume (as different modal motions interact with certain parts of that volume differently). To this end we define, for an arbitary mode m:

f_m = g(T) , where g is some mode-specific temperature dependent function involving E,G

     ==>  f_m + del_f_m ~= g₀ + g₁del_T + . . .  

     ==> del_f_m / f_m = g₁del_T / g₀ = A * del_T

Similarly, for another mode n: f_n + del_f_m ~= h₀ + h₁del_T  ==>  del_f_n / f_n = B * del_T where h is some function with some different temp dependence

Then the ratio of the change of frequency over frequency of those specific modes is constant: 

(del_f_m/f_m) / (del_f_n/f_n) = A / B = constant

I've quickly looked at three longer recent locks, specifically at change of drumhead modes compared to change of 15007 Hz modes of the ETMS. ETMY seems to agree on a constant while ETMX a bit wandery . I'll look more systematically tomorrow to see if I can narrow it up.

ETMY (del_Drumhead / Drumhead) / (del_15007 / 15007) = 1.38, 1.31, 1.31   |    ETMX (del_Drumhead / Drumhead) / (del_15007 / 15007) = 1.29, 1.45, 2.45

We were basically ready to start TCS tuning tests, but we can't relock the IFO :(  Since it took me a while to get these settings, this will basically be a note-to-self of what I had set up, so that I can do it again more quickly tomorrow. 

AS port OSA

• Sheila helped plug in the OSA that is at the AS port to the roaming wireless router (that belongs with the gpib setup - only having one of these is a problem!).
• We can now use Jamie's script (documented in alog 29563) to pull the data.
  • tektronix download -c 'ch2' ~/LHO_work/2016_10_13_OSA_AS/ 0 60
  • In the above, 0 tells it to keep downloading data until we crtl-c to quit.  60 tells it to get data once every 60 seconds.  The help file is very detailed.
• We forgot to set the vertical axis ranges for channels 2 and 3 differently, so right now we can only see the 45MHz peaks clearly.  We should zoom one of the channels in so that we can see the 9MHz peaks.
• Gabriele has a script that will pull all the data from a folder, find the peak height and plot the peaks as a function of time.
  • Currently it lives in /ligo/home/gabriele.vajente/2016_10_13/sideband_amplitudes.m
  • Give the script the peak location for both upper and lower sidebands in the first data file, as well as about how much they move between data sets, and his script will find the max value in a range based on that. 
  • We ran it for about 45 min while I was still setting up, so without any TCS changes, and saw that the 45MHz sidebands started out pretty imbalanced, but were moving toward being more balanced as the IFO thermalized.
• The goal will be to tune TCS such that the 45MHz peaks are well balanced.

Frequency line

• Similar to what was done in September (alogs 29553, 29509), I used awggui to inject a line at 900Hz into the Refl Servo, 100 counts amplitude.
  • H1:LSC-EXTRA_AO_2_EXC is plugged into Exc A of the Refl Servo's common mode board, and H1:LSC-REFL_SERVO_COMEXCEN is enabled.
• I used the LSC OSC1 to demodulate signals at this frequency.
  • The frequency was set to the same 900 Hz, but the LSC output matrix didn't send the oscillator signal to any optics. 
  • Demod 1 looked at OMC DCPDs, Demod 3 looked at REFL9I, and Demod4 looked at REFL45I (this is the same convention as in alog 29553).
  • cdsutils servos were used to change the phase of the demodulators to zero the Q-phase signal.
    • cdsutils servo -r LSC-LOCKIN_1_DEMOD_1_Q_OUT16 -g -100 LSC-LOCKIN_1_DEMOD_1_PHASE
    • cdsutils servo -r LSC-LOCKIN_1_DEMOD_3_Q_OUT16 -g -100 LSC-LOCKIN_1_DEMOD_3_PHASE
    • cdsutils servo -r LSC-LOCKIN_1_DEMOD_4_Q_OUT16 -g -100 LSC-LOCKIN_1_DEMOD_4_PHASE
• The goal will be to tune TCS such that the frequency line is minimized in DARM.

Intensity line

• I used awggui to inject a line at 860Hz, 10,000counts into the ISS second loop.
  • H1:PSL-ISS_SECONDLOOP_EXCITATION_EXC
  • H1:PSL-ISS_SECONDLOOP_EXC_SWITCH_MON enabled, but first H1:PSL-ISS_SECONDLOOP_REFERENCE_VALUE set to zero so that I wouldn't give the ISS a giant kick. 
• I used the LSC OSC2 to demodulate, but only Demod 1 for OMC DCPDs.  Same situation as the freq line - set the frequency of the LSC oscillator, but don't send the signal anywhere in the output matrix.
  • cdsutils servo -r LSC-LOCKIN_2_DEMOD_1_Q_OUT16 -g -1 LSC-LOCKIN_2_DEMOD_1_PHASE to zero the Q-phase signal.
• The goal will be to tune TCS such that the intensity line is minimized in DARM.

Jitter line (pitch)

• I used awggui to inject a line at 820 Hz, 1000 counts into the PSL PZT in pitch.
  • H1:IMC-PZT_PIT_EXC
• I used the LSC OSC3 to demodulate, but only demod 1 for the OMC DCPDs.
  • Since trying a larger amplitude for this line broke the lock, I didn't set the cdsutils servo.
• The goal will be to tune TCS such that the jitter peak is minimized in DARM.

Obviously, the goal is to find a perfect TCS place where all the couplings are minimized at the same time, and the giant peaks in DARM are minimized.  We'll see if that is possible.

Attached are screenshots of my 3 desktops, to remind myself of any other settings that I've not written down.  Note that the IFO was not locked when the screenshots were taken.

Travis, Jenne, Terra, Kiwamu,

A brief report on a rare fault mode associated with FSS and ALS.

At one point tonight, we noticed that both end station green lasers did not lock to the arms. It turned out that both the end stations lost the beatnote against the PSL light. Looking at various channels, we found that it was actually the reference cavity which locked to a next fringe, resulting in a large shift in the NPRO frequency. This corresponded to a temperate crystal feedback of -0.25 K (compare this to nominal of 0 K). A strange thing is that the temperature sweep for the FSS auto-locker had been set to [-0.1 K 0.1 K] which means that theoretically the chance of hopping to the next fringe is very small. Anyhow, relocking the FSS back to the nominal fringe by disabling/enabling the auto-locker fixed the issue. Both green lasers re-acquired the PLL without an issue.

[Sheila, Jenne, Kiwamu, Patrick]

We lost lock about 8 hours ago, and haven't been able to lock since.  Sheila suggested we look at the Yarm ALS PDH control signal, since that has caused trouble in the past.  Indeed, we saw glitches.

We were looking at H1:ALS-Y_REFL_CTRL_OUT_DQ, and saw very obvious glitches at about a 1Hz rep rate.  At the same time, we see dips in the ALS transmitted power (H1:ALS-Y_TR_A_LF_OUT) down to 0.5 or lower from a nominal locked value of 1.0.  We also see much smaller glitches in the Xarm, often at the same time as the Yarm glitches, but not always. The Xarm power dips are also much smaller than those for the Yarm. The first attachment shows the REFL CTRL signals.  We don't save the transmitted powers, so I don't have a good plot of those. 

We have certainly seen these glitches before, and there are rumors that it seems to happen more often when it's raining.  Not totally clear how that's related - is the extra humidity doing something to us??  Anyhow, in the past the solution has always been to wait it out, and it'll go away.  Colloquially the problem is usually gone by the time anyone drives down to the end station. 

We went down to the end station and tried several things while looking at the PLL beatnote, but none of them changed the glitches.  At a few times, Sheila noted that there were peaks around the beatnote, 8MHz above and below.  We're not totally sure what those are. 

• I changed the temperature of the crystal, and Sheila could see the beatnote moving around, but saw no evidence of mode hopping in the laser.
  • To do this:  On the ALS_Overview screen in the Yarm state machine, select "unlocked". 
  • On the Yarm PLL screen, top left corner, select "off" for the servo.
  • Change the value in H1:ALS-Y_LASER_HEAD_CRYSTALFREQUENCY - this will move the temperature.
  • To go back to regular locking: On the ALS_Overview screen in the Yarm state machine, select "PLL locked".
• We toggled the ALS laser's noise eater, then relocked the green arm.  No change in the glitch behavior.
  • To do this:  From the Yarm PLL screen, top left corner go to ALS Laser sub-screen.  Toggle noise eater button off, then on again.
• We turned off the ALS laser, then turned it back on and relocked the green arm.  Again no change in the glitch behavior.

Suspecting that the PSL was somehow involved since we often see glitches simultaneously in the X and Y arms, we closed the light pipe shutter for the PSL ALS beam that goes to ISCT1.  We were hoping that if there were some kind of feedback from the Yarm to the PSL that was then getting sent to the Xarm through the PLL, this would prevent that.  However, no change.  The light pipe's shutter was re-opened.

We then went back to the Yend to lock the green arm, but bypassing the PLL, thus eliminating the PSL light from the system.  We didn't see any tell-tale dips in the transmitted power while we did this, but when we put the system back to normal, the problem seemed to have already resolved itself.  So, it's not a 100% conclusive test. 

• To do this, we unplugged the PDH common mode board's input (lower of the 2 common mode boards) and plugged it into the PLL common mode board's input (upper of the 2 common mode boards). 
• On the PLL servo board, we changed the Input1 polarity to positive (it's usually negative), and increased the gain to above 10dB.  (16dB worked for a while, but then it seemed like it was too much and causing locklosses).  The arm locked in green very easily.  If it unlocked, sometimes we toggled the polarity, and sometimes it seemed to acquire better if we ramped the gain down then back up again.
• We were locked this way from about 06:42 UTC to 06:50 UTC 14Oct2016. 
• Since the refl control signal wasn't in use, we just monitored the transmitted power and said that we didn't see any dips in the power.
• Assuming that the glitches would have still been there in the normal configuration, we think that this absolves the ALS laser and PDH sensor and PLL servo board from blame. 
• However, when we put things back to normal, the glitches were basically gone.  So, maybe we didn't learn much of anything :/

We're going back to trying to lock for now.

I have changed the whitening filters for the calibrated DRMI spectra. They are changed from zpk([1;1], [100;100], 1) to zpk([0.3; 0.3; 0.3; 0.3; 0.3], [10; 10; 10; 10; 10], 1). The window, which had been flat-top (23090), is now put back to Hann. The dtt template is also update accordingly.

See attached screenshots of OpLev trends. 

Trouble keeping ISS locked through beginning of shift. Had to keep relocking by hand. IMC kept losing lock. Found glitching on H1:ALS-Y_REFL_CTRL_OUT_DQ and H1:ALS-X_REFL_CTRL_OUT_DQ. Jenne, Sheila and Kiwamu tried to isolate the cause. Cause not found, but glitching eventually gone. Attempting to lock. Handing off to Travis.

23:18 UTC restarted video0
23:31 UTC lock loss (Jeff, Jenne)
23:35 UTC Chandra to LVEA, RGA between HAM5 and HAM6
01:16 UTC Initial alignment
01:42 UTC Initial alignment done
02:32 UTC ISI config changed to WINDY_USEISM, never moved past not all nodes arrived
02:46 UTC ISI config changed to USEISM_NOBRSXY
04:31 UTC Jenne and Sheila to end Y to check on ALS laser
05:23 UTC Jenne and Sheila back. Jenne to LVEA to block ALS light pipe.
06:14 UTC Jenne and Sheila at end Y to replace PLL signal with electronics.
07:10 UTC Jenne and Sheila back

FAMIS request 6492

Added 50mL H2O to PSL crystal chiller. It was hard to tell if it needed any as the level was fluctuating quite a bit. No alarms on either the crystal or diode chiller. The water filters appear clean.

Summary:  I have moved the POP_A and SOFT offsets to find better recycling gain (31.2ish rather than the 29.5 we had been getting).  I was hoping that this would help eliminate the peaks in the 200-900 Hz region, and I think it did a bit, although not as much as I'd hoped.  It did help the high frequency noise "tail" though.

History:  Some time ago, Sheila and I moved the POP_A offsets to improve the recycling gain from 25ish, and that worked very well and has been very consistent.  At the time, we stopped where we did because the POP_X centering PZT was hitting its rail, not because we thought we had found the best possible location.  Then, we elected to move on to trying to get to low noise rather than continuing to chase alignment offsets.  Now that we're at low noise though, I wanted to see if continuing to move the QPD offsets would help get rid of some of this jitter / frequency noise coupling. 

What I did:

• Moved POP_A offsets to maximize recycling gain.  Watched to ensure POP_X PZT wasn't railing.  Moved SRM alignment sliders to keep POP90 low.
• Upon relock, let the DRMI ASC move the IFO (including SRM) closer to the place that was good for the new POP_A offsets (i.e., just leave the offsets in permanently).  This was good, and meant that SRM didn't need to be moved by hand later.  I think it does make the CHARD engaging do a little more work, although that can be ameliorated by resetting all of our initial alignment setpoints.
• Upon relock, also noticed that when the SOFT loops came on, we went through a max for the power recycling gain then came down a bit, all before powering up.  This indicated that I needed to move some SOFT offsets.
• Moved the SOFT offsets, while moving SRM to keep POP90 low.
• Went back to re-try POP_A offsets, ended up adjusting pitch a little more.
• Ran A2L for the test masses.

In the end, the power recycling gain is about 31.2, whereas it used to be about 29.5 in NomLowNoise before this work.  Also, as Jeff points out in alog 30481, it looks like this did good things for the DARM cavity pole and the optical gain. 

At about 06:49:15 UTC, I had just about the lowest value for the broad peak at about 440 Hz.  Going back to the offsets I had at the time did not reproduce that low of a peak though and the recycling gain wasn't at its maximum, so I ended up sticking with the offsets that maximized the power recycling gain.  I may go back and look at the alignment of all the optics at that time to see if there was anything drastically different. 

I also turned back on Gabriele's Jitter feedforward with the same gain of -1, and it still seems to be doing quite well.  I haven't looked at the coherence, so I don't know if this is quite as good as when he and I were tuning it earlier today, but it still made a significant improvement in the 80 Hz - 250+ Hz region.  I have this feedforward turning off in the Down state of the ISC_LOCK guardian, but it must still be turned on by hand.  Once we're satisfied that it does good consistently, we can add it to NoiseTunings.

For now, I'm leaving the POP_A offsets in place, but the SOFT offsets will be turned off upon lockloss.  I want to make sure that including them during the acquisition sequence isn't harmful to lock acquisition before accepting them permanently.  I'm hoping though that they're fine, so that the ASC will handle all the SRM moving and we don't have to do anything by hand.  To be checked tomorrow.

Offsets that I like in the end are:

• POP_A_P: 0.52
• POP_A_Y: 0.44
• DSOFT_P: 0.00
• DSOFT_Y: 0.04
• CSOFT_P: 0.06
• CSOFT_Y: -0.04

Ideas: 

• A2L for recycling cavity optics
• Re-look for SRM ASC error signal - maybe there's a bit more hope if the overall IFO alignment is better?

This is a low level sanity check and a part of the recent delay study (e.g. 29259). I have measured a transfer function between DARM2_OUT and SUS-ETMY_L3_ISCINF_IN1 using dtt while the interferometer was locked last night. The measurement agrees with 1 cycle user model delay (=61 usec). See the attached.