Displaying report 1-1 of 1.
Reports until 22:07, Friday 17 July 2015
H1 ISC (ISC)
stefan.ballmer@LIGO.ORG - posted 22:07, Friday 17 July 2015 - last comment - 00:31, Saturday 18 July 2015(19727)
h1lsc modification (work permit #5358)
Sheila, Stefan

Our first version of this fix had a bug: the linear fit below the sqrt limiter meant that there is a non-zero chance to drive the arm in the wrong direction, resulting in a DRMI lock-loss. We addressed this in the next version of the code with a quadratic fit:
 - The initial limiter is set at l=1e-4. Above it (x>l), we still simply have sqrt(x) for CARM_TR.
 - Below x<-3*l, we have TR_CARM=0
 - Between -3*l<x<l we add the 2nd path f=A*(x-x0) + f0, with
      - f0=-sqrt(l)        = -0.01
      - x0=-3 l            = -3e-4
      - A = 1/(16*l^(3/2)) = 62500
 - The sum of the two paths gives a smooth interpolation. We tested this code and verified that the FE code does what it should.
 - Next we wanted to optimize the threshold limit l:
   - Looking  at past locks, the pk2pk during PREP_TR_CARM in TR_CARM is about 0.1 cts
   - Thus the following parameters might be even better:
      - l=0.01
      - f0=-sqrt(l)        = -0.1
      - x0=-3 l            = -3e-2
      - A = 1/(16*l^(3/2)) = 62.5
 - We installed this as version V2 of this code.
 - Due to the earthquake we have not yet tested this yet.

Images attached to this report
Comments related to this report
stefan.ballmer@LIGO.ORG - 00:31, Saturday 18 July 2015 (19729)
Evan, Stefan

After the earthquake we had a chance to test the code:
- The good news: the smooth turn-on of TR_CARM described above seems to work just fine - every time.
- The bad news:  we still sometimes lost it sometimes 13 seconds after we grabbed TR_CARM.
- Attached are traces of TR_CARM_INMON for one failed attempt, and 2 successful attempts.
- At any rate - the lock losses happen when we are already clean on the sqrt(x) part - so we will keep the code change.


The lock loss happens most likely during the engaging of LSC-MCL FM3 (BounceRG):
Guardian line 642:
        ezca.switch('LSC-MCL', 'FM3', 'ON')
Guardian log:
2015-07-18T07:58:51.84052 ISC_LOCK [PREP_TR_CARM.main] ezca: H1:LSC-MCL => ON: FM3

We moved the LSC-MCL FM3 engaging to the end of CARM_ON_TR (line 733):
                ezca.switch('LSC-MCL', 'FM3', 'ON')

This seems to have fixed the problem - at least as far as we can tell,, (we are at 2 out of 2 for this type of lock loss...)

We also moved the zeroing of REFL_BIAS matrix elements to the DOWN state. 
Images attached to this comment
Displaying report 1-1 of 1.