Kiwamu, Daniel, Elli

Yesterday we made some changes to SRMI locking and were able to stay locked much more reliablly. In this configuration I was able to take multiple measurements of SRC length without worrying about keeping lock (I'll have more to say on these results shortly..).  Lock stretches lasted for ~1hr provided noone was walking around the LVEA.  SRMI would regain lock by itself when left in the following configuration:

IMC input power 5W.  ASC master gain 0.  H1:SUS-SRM_M2_LOCK_OUTSW_L set to OFF.  H1:SUS-BS_M3_ISCINF_L_LIMIT set to 50000.

MICH input ASAIR_A_LF intrix value 0.25, MICH gain 800, MICH offset -200, MICH fliters FM7 (150^3:1), FM9(ELP40) always on and FM2 (1:0) triggered, MICH signal going to BS with outrix value 1.

SRCL input REFLAIR_A_RF9_I intrix value -3.75, SRCL gain -40000, SRCL offset 0, SRCL filters FM9(cntrl) and FM10(CLP300) always on and FM2(1:0)and FM3(4:0) triggered, SRCL signal going to SRM with outrix value 1.

(Set all other LSC matrix elements to zero.  Set power scale to 5W.  Turn on H1:LSC-CONTROL_ENABLE.)

MICH triggers on ASAIR_A_DC matrix valuen 1, upper threshold 1000, lower threshold 400.  MICH FM2(1:0) filter triggers after 0.4 sec upper threshold 1000 lower threshold 400.

SRCLtriggers on ASAIR_A_DC matrix valuen 1, upper threshold 800, lower threshold 300.  MICH FM2(1:0) filter triggers after 0.2 sec upper threshold 300 lower threshold 300.

The x1nds0 computer has been started and configured to run branch-2.9 daqd, r3970. This will allow testing of a bug fix to the daqd (CDS Bugzilla 811). The daqd protocol version on x1nds0 is 12.2. 

The default x1nds1 computer is still running the NDS1 12.1 protocol, which has the bug discussed in CDS Bugzilla 811.

model restarts logged for Wed 04/Mar/2015
2015_03_04 00:41 h1fw0

model restarts logged for Thu 05/Mar/2015
2015_03_05 00:43 h1fw0
2015_03_05 09:41 h1fw0
2015_03_05 12:31 h1fw1

all unexpected restarts.

I am leaving the IFO locked at 2.8 W on dc readout. The intent bit is set to 'undisturbed'.

J. Kissel, K. Izumi

Motivated by recent confusion about calibration because changes in the optical gain, Kiwamu and I took a long hard look at a front-end implementation of computing slowly-time-varying optical gain correction to the IFO's DARM sensing function, traditionally called 'gamma' among the Calibration group. Re-convincing ourselves of what we want to do, based on how gamma has been computed in the past, and how aLIGO's *offline* GDS code is still doing it (see T1300088, L1400081, LHO aLOG 16926), we've decided to try the following attached configuration.

We have not yet done anything with this new version of the h1calcs.mdl (no compile, no svn commit, no nothing), I just want to document what we've done for discussion (though there should be no harm in committing to the repo and just installing this model since its independent of any control system, and we've made sure that the configuration control for the EPICs records for this model are now sound -- see LHO aLOG 17037).

There're lots of changes to what was implemented BEFORE, (i.e. the first crack at it):
- The BEFORE implementation had fed DARM_ERR into the GAMMA block for calculation... that was just wrong, so we fixed it.
- The calibration line's oscillator parts, the filtering of DARM_CTRL, and the phasing and filtering of the I and Q outputs have all been brought together into one block -- the already existing library part for a demodulator,
${userapps}/cds/common/models/lockin.mdl.
The advantage is that there's already canned, generic, MEDM screens pre-made for such a tool, so we don't have to re-invent that wheel. This changes the individual calibration line's channel names from
${IFO}:CAL-CS_LINEn_LO 
to
${IFO}:CAL-CS_GAMMA_LINEn_DEMOD_LO
where n = 1,2,3,4. The former wasn't stored in the frames and now screens have been made using them, or to our knowledge even measured once as a test point, so I don't think this channel change matters much. The overall sum of lines is still, the perhaps more transparent,
${IFO}:CAL-CS_LINE_SUM
- Surrounding the DEMOD library part, is the actual calculation of gamma. In this calculation, we've found the need to create two new EPICs records: 
${IFO}:CAL-CS_GAMMA_LINEn_REF_OLG
and
${IFO}:CAL-CS_GAMMA_LINEn_AMP
the former is to be the reference, DARM open loop gain transfer function magnitude or real part at the calibration line frequency, and AMP is the calibration line amplitude. It would be best is AMP was taken directly from the output of the OSC part in the DEMOD block, but unfortunately that front-end code accessibility is not a feature yet built into the part. We'll ask Rolf about adding it, but of course, the OSC part is used in LOTS of other places, so the headache may be better dealt with by keeping two EPICs records synchronous than to terminate the output of every one else's oscillator parts in every other model literally world-wide. This new library block lives in
${userapps}/cal/common/models/CAL_GAMMA_CALC_MASTER.mdl
- There had been 4 calibration lines, which means one could potentially calculate a gamma from any of these lines -- but only one should be used to correct the DARM calibration time series. So, we've installed the infrastructure to calculate a gamma for every line, but sent the output into a 4x1 matrix, so we can choose which gamma to use "on the fly," or at least without have to change the front-end code.

Comments on what we intend to *do* with the infrastructure:
- Make / Improve the CAL-CS overview screen to include the GAMMA calculation as well as a display of the calibration lines.
- We'll install two DARM calibration lines at 34.7 and 538.1 [Hz] as described in LLO aLOG 15870.
- We'll set the amplitude such that we have an SNR of 30 as described in LLO aLOG 15944, and make sure to copy the CLK_GAIN over to the AMP EPICs record and update the records in the CAL-CS SDF system.
- We'll use some reasonably aggressive band-pass at the given line's frequency in the DEMOD_SIG bank, and install a low-pass filter with a corner frequency at 0.01 [Hz] in the I and Q. The corner frequency is chosen to represent a 100 [sec] "average." In S5 and S6, recall that the offline calibration correction was computed by averaging over one minute (60 [sec]) and applied on the minute. Over the entire two year run of S5, this correction factor did not deviate from unity by more than 5% (see P0900120). Indeed, in S5, a study was done the compute this factor faster, every second, and it was deemed unnecessary (I think this study was posted on Myungkee Sung's personal webpage or on a S5 Review wiki page or something, I'm not gunna bother finding it. #trustme #doctor). So, in aLIGO, where we believe the optical gain is *more* stable, we'll chose an averaging time of 100 [sec] for now.

Last night we had a lot of troubles in closing the ASC loops in DRMI configuration, just after we tried to move by hand SR2. Basically, the MICH loop has a large offset.

One of the suspects is that we ended up in a different alignment condition for the SRC that might cause a bad behavior of MICH error signal, even though we don't have any good explanation.

I looked into the SR2, SRM and BS positions during all our DRMI locks. In the two attached plots, the top panel shows the relevant DRMI powers, and the bottom panel the local sensors for the mentioned optics. All signals have been rescaled arbitrarly to fit into the plot.

From the first plot we can see that:

• Before time ~8 h, everything is working fine, and we could close MICH, PRC1, PRC2 and INP1 loops, improving the build ups.
• The lock loss at about time 8 h is caused by our trial to move SR2 and see what happens to the WFS signals
• After that, MICH is no more working
• The local sensor signals are quite reliable on a time scale of few hours (no major drifts)

The second plot is a zoom of the last four hours, when we were having ASC troubles. It seems to me that in all those trials, we never really reverted the SR2 position to its original value (blue trace in the bottom plot). So my guess is that we were in a different alignment configuration for the SRC, and this might explain our problems (we know that the MICH error signal is strongly coupled to SRC dofs)

Removed this channel from the exclude list and regenerated the channel list to add it to Conlog.

All of the other ODC channels are removed pending resolution of the garbled string issue: alog 16054

Investigating alternative to craning Genie over XBM and YBM -> Am considering scaffolding+plank catwalk etc.  (TCS table on south side of BSC1 is impeding access)

Kyle, Gerardo 

Moved pump cart from X-end and added to HAM1 -> Pumped HAM1/HAM2 annulus from HAM1 pump port and HAM2 pump port -> Pumped BSC3 annulus 

1530 hrs. local -> Shut down annulus pumping (continue during Tuesday maintenance)

Scott L. Ed P. Chris S.

Cleaning is complete from single door between X-1-4/5 to X-1-4 double doors. Cleaning report to follow tomorrow and relocation of equipment to begin cleaning from single door to X-1-5 double doors.
Continuous monitoring of the beam tube pressures by control room. 

Summary--No answers yet but, Guardian still kicks RZ when Z ISO loop is started, command scripts don't; Guardian ST2 gain/whitening scheme still not right(believe we have corrected this now;) Isolation Loop Spectra amplified with MICH engaged.

1) See first attachment of 8 minutes of second trend.    T=1 is when the guardian turns on the Z Isolation loop as evidenced by the start of non-zero _Z_OUT16.  Notice above this channel, the _RZ_OUT16 is not on.  Notice though on the upper left plot how the RZ_INMON is influenced by the Z loop turn on at T=1.  About 30 seconds after T=1, the RZ loop turns on with a large spike.    At T=2, the Z loop is started with the command script and while the INMONs before the start times are different, the Z turn on does not do near the abuse to RZ as does the Guardian.  See the attachment of aLOG 17402 17042 for several more comparisons where the turn on is not possibly contaminated by watchdog trips and MICH influence.

Still, my conclusion, Guardian does something abusive when clearly it isn't necessary.

2) I need to have more time to understand exactly what guardian is doing during the steps but when Mich is locked and Guardian moves the ISI toward HIGH_ISOLATED, the gain/whitening of the Stage2 GS13 are switched to an analog whitened high gain state and trips immediately.  Again, I need to study this exactly as it isn't verbose in the Guardian Graph but this is my observation recollection.  With the MICH locked and the Stage2 tripped (which it did many times,) the ISI could not be untripped as the MICH was pushing the ST2 too much.  Maybe it would do it in low gain but I'm not sure I even tried that with Guardian doing its own thing.  I finally did get the guardian to leave the GS13 gains alone, obvious now to me, by using the command scripts where I could leave the GS13 in analog whitened low gain.

Conculsion: More test time needed but for now it seems the GS13 must be kept in whitened low gain when MICH comes on.  ADD ON--We found a spot in the Guardian and corrected this-see aLOG 17092.

3) By using the command scripts, I was able to turn on the Z and RZ ISO loops with Boost of ST2.  I then turned on the Y dof without boost and it managed to stay Isolated long enough to get reasonable looking spectra.

See second attachment: The lighter colored thicker reference traces were collected yesterday morning when I engaged all 4 loops without the MICH locked.  I can't recall now if I did this with the guardian or not.  This morning, finally with MICH locked, I got the loops on while running a 3 average exponential ASD.  The thin dark current traces are the Z RZ and Y Isolation OUTs.  I managed to pause the measurement before the trip contaminated these spectra.  Maybe the traces were settling down still at the time this spectra was frozen but, the Z RZ & Y loops were on for 180 135 & 45 seconds respectively before the measurement stopped.  Still, clearly, there is much elevation in the drive spectra from several 100hz down to 1 to 20 hz depeneding on the DOF.  Around 70-80hz, the increase is 2+ orders of magnitude.

Further conclusions w/JeffK--We will try to do similar with the Actuator Outputs (no  DQ channels.)  Otherwise, with this isolation output elevation and the shapes of the Actuator output filters, it isn't surprising that we could be near DAC saturation.

While looking for my Guardian -vs- Command Script Isolation turn on problem, we (JeffkK & JimW) spotted the GS-13 gain switch error.  So we changed guardian code to reflect the correct GS13 gain switching.

changed

/opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/isolation/util.py

WHAT IT WAS

######################## HP 12/04/14 ########################
# Added to allow T240 gain switch on BS
def switch_gs13_inf(command):
    #command is 'HighGain' or 'LowGain'
    ez_ca = myEzca()
    chamber_type = top_const.CHAMBER_TYPE
    chamber = top_const.CHAMBER
    for ddd in iso_const.ISOLATION_CONSTANTS_ALL['BSC_ST1']['LOC_DOF']:
        if command == 'HighGain':
            ez_ca.switch( 'ISI-' + chamber + '_ST2_GS13INF_' + ddd, 'FM5', 'ON', 'FM4', 'OFF')
        if command == 'LowGain':
            ez_ca.switch( 'ISI-' + chamber + '_ST2_GS13INF_' + ddd, 'FM4', 'ON', 'FM5', 'OFF')
    wait(3) # To account for the 2s zero-crossing timeout
#############################################################

WHAT IT IS NOW

######################## HP 12/04/14 ########################
# Added to allow T240 gain switch on BS
def switch_gs13_inf(command):
    #command is 'HighGain' or 'LowGain'
    ez_ca = myEzca()
    chamber_type = top_const.CHAMBER_TYPE
    chamber = top_const.CHAMBER
    for ddd in iso_const.ISOLATION_CONSTANTS_ALL['BSC_ST1']['LOC_DOF']:
        if command == 'HighGain':
            ez_ca.switch( 'ISI-' + chamber + '_ST2_GS13INF_' + ddd, 'FM4', 'OFF', 'FM5', 'OFF')
        if command == 'LowGain':
            ez_ca.switch( 'ISI-' + chamber + '_ST2_GS13INF_' + ddd, 'FM4', 'ON', 'FM5', 'ON')
    wait(3) # To account for the 2s zero-crossing timeout
#############################################################

So this sets the "HighGain" state to FM4 & 5 off which gives us non-whitened high analog gain, and,

the "LowGain" had FM4 and 5 on giving us analog whitened low gain.

Attached are the current PSL DBB scans. We will review in the PSL meeting. 

Gabriele, Elli, Dan, Sheila

Today we worked on ASC for DRMI + arms off resonance.  

• Changes to input matrix-
  • Gabriele made a nice script that measures the sensing matrix.  (alog 17085 )
  • Previously we had simply copied the input matrix that livingston used, which was close enough to let us close several loops, but clearly was not the best choice of signals for us.
  • Based on the measured sensing matrix we changed our input matrix so that we are using REFL A 9I for PR2 and POP A for PRM.   Both of these choices seem like clear improvements over what we did in alog 17028, with about 20 times more signal in POP A than POP B for PRM.

• Higher bandwidth PRC loops
  • both PRC1+PRC2 loops were ridiculusly slow in our first attempt at these loops.  We have added pairs of poles at 0.3 Hz to each of these loops, which allow us to increase the gain to have UGFs of around 100 mHz.  PRC1 is still slower that PRC2.  This helped make the AS_C signal seem more sensible, before it seemed to be contaminated by PRC fluctuations.  
  • We also moved gains into filter modules, screen shot of all of these changes attached.   
  • After these changes we were able to close the PRC1, PRC2, MICH, and INP1 loops several times and at first things seemed to be better. We were engaging BS first, then IM4, then PR2, and PRM last.  

• demod phase of AS 36 WFS is very sensitive to SR2 alingment
  • we then ran into trouble, and found that we weren't able to engage the BS WFS (they would come on and reduce the sideband build ups.) We redid the initial alingment, but this was still true.  The BS WFS had seemed reliable since the rephasing described in 17005,
  • Gabriele rephased AS36 B carefully, quadrant by quadrant, to minimize the SRM signal seen in the Q phase.  After this we saw that there is still an offset between the WFS signal zero and a good buildup in DRMI.  
  • We moved SR2 by ~4 urad, and saw that the carefull phasing we had just done was wrong by 70-90 degrees.  We also see that we can mode hop by moving SR2 by a couple of microradians, even though based on the DRMI build ups we seem to be in a good alignment tonight.  
  • It could be that servoing to AS_C could help this problem, but we need to think about how to set the centering onto AS_C to accomplish this, since the method Elli and I used was not precise to the level of a micro radian (17085. )

In response to Evan's alog (alog 17065), I took a look at the DARM spectra. Here are conclusions at the moment:

• In the 2.8 W configuration, the optical gain seems to have decreased by approximately 9% compared with the noise curve from Feb. 26th (alog 16982) with the assumption that the high frequency band is limited by shot noise. This resulted in a too-good noise curve last night.

• The origins of this discrepancy is not clear.
  • Note that the arm build up (e.g. ASC_TR_X(Y)_B_QPD_SUM) were lower than that of Feb. 26 th only by 1-2% which is not big enough to explain the discrepancy. See the attached trends for more details.
  • One possible factor can be different sensing gain in the digital system such as OMC-READOUT_SCALE and LSC input matrix which the midnight lockers change every time they are transitioning to DC readout. I did not get chance to carefully go through these values yet.

• In the 8 W configuration, the 9% discrepancy was inherited and hence too good noise again by 9% above 1 kHz. On the other hand the power scaling from 2.8 to 8 W seems to have been done precisely.

• A strange thing is that the noise curve at around 2.8 kHz became further too low for some reason in the 8 W configuration. This can not be explained by the 9% overall discrepancy factor. The noise in this region seems lower by 10-ish% than the GWINC curve.

(Noise spectra)

The data sets that I used are from:

• 2015-02-26 10:2:50 (at 2.8 W)
• 2015-03-04 10:08:55 (at 2.8 W)
• 2015-03-04 14:03:55 (at 8 W)

Here is a comparison of all three curves with the GWINC theoretical curves above 400 Hz up to 7600 Hz.

As Evan reported, indeed the measured curves from last night are lower than the GWINC curve in 1 - 4 kHz band while the one from Feb-26 looks fine.

(Discrepancies between the curves)

Now, I want to answer how much the Mar-4 data differed from the one from Feb-26th by taking the ratio between them. I divided the Feb-26th by Mar-4th spectra in 400-7600 Hz band. Then I convert it into a histogram to see how they differ on average. Since there were many peaks whose amplitude varied as a function to time, I excluded them by limiting the histogram range from 0 to 2. The ratio is shown as red bars in the below plot.

Note that I could have done a fancy Gaussian fit for it, but for now I picked the highest bar in the histogram in order to coarsely estimate the ratio. As shown in the plot, the Feb-26 data had a higher noise level by a factor of 1.09 on average.

Then I did the same ratio analysis for the 2.8 W and 8 W data of Mar-4th. It is shown as blue bars in the same histogram plot. Picking the highest bar, I measured the ratio to be 0.58 which agrees with what we expected i.e. sqrt( 2.8W / 8W) = 0.59. So the power scaling from 2.8 W to 8 W seems to have been done correctly last night.

(Unexplainable dip at around 2.8 kHz in the 8 W data)

However, it is not the end of the story yet. The noise curve of the Mar-4 at 8 W had a funny feature at around 2.8 kHz where the noise go down below the GWINC curve even if i apply the 9 % correction.

The below plot shows "normalized" spectra of all the three data sets. In order to line up all the spectra at the same level, I "normalized" the Mar-4th-2.8W data by multiplying a factor of 1.09. In a similar manner, I "normalized" the Mar-4th-8W data by a factor of 1.09/0.59. In this way I checked the shape of all the spectra.

The Mar-4th-8W data was lower by the rest of the two curves by 10-ish %. I did not do a serious histogram analysis.

Finally , if I apply only the 1.09 correction factor to the data from last night, they look like this:

Apparently the Mar-4-8W data is lower at around 2.8 kHz than the GWINC curve.

The attached plot shows the frequency of the IMC VCO, when the common tidal feedback path to the ETMs is running. At the beginning of the plot the offset in the IMC_F filter module was set to zero. This then puts the IMC VCO in average ~150 kHz below the fixed frequency oscillator which drives the fiber EOM. In the second half of the plot the offset was changed to -3500 counts and the IMC VCO shifted to ~200 kHz above the AOM frequency. Under nominal conditions the offset is at –1750 counts, which corresponds to roughly zero offset at the output of the filter module.

The important thing is to avoid a frequency crossings of these two RF sources, since this is one of the reasons for RF crosstalk into the laser frequency noise. We should probably try to move the IMC VCO frequency up by another 100 kHz to make sure we stay away from zero.

The COMM and DIFF VCOs are running at nominal 78.92 MHz. Since they implement two stages of the frequency-difference-divider, their range is no larger than ±150 kHz. Hence, they cannot reach the AOM frequency—or the IMC VCO frequency when it is above the AOM one. Once we are in full lock and the green beams are turned off, we need to make sure that these two VCOs are at least 10 kHz apart from each other. This should then prevent RF crosstalk by the VCOs from reaching the detection band.

Kiwamu, Dave, Evan, Betsy, Elli

Today we locked SRMI in preparation for measuring the SRCL guoy phase.  The lock is not particularly robust, but we are hoping it will be good enough to takea preliminary measurement...

Initial settings:

MICH is locked to LSC-ASAIR_A_LF with input matrix value 0.25, a H1:LSC-MICH_OFFSET offset of -200, a gain of H1:LSC-MICH_GAIN 1600 (or locking with  gain 800 then ramping up to 1600 also works), and an output matrix value of 1 going to BS. FM7 (zpk([1],[150;75+i*129.904;75-i*129.904,1,"n")) and FM9  (ELP40) are on in the MICH loop.

SRCL is locked to LSC-REFLAIR_RF9_I with an input matrix value -3.75, H1:LSC-SRCL_GAIN gain of -50000, a SRCL offset of 0 and an output matrix value of 1 going to SRM.  FM9 (zpk([10],353.553+i*353.553;353.553-i*353.553,1,"n")gain(10)) and FM10 (cheby1('LowPass",2,1,300)) are on in the SRCL loop.

Trigger settings are:

MICH: triggered by ASAIR_A_DC gain 1, upper thereshhold 1000, lower threshold 400.  Filter trigger thresholds On:1000 Off:400, 1seconds, FM2 triggered. (FM2 is zp1:0)

SRCL: triggered by ASAIR_A_DC  gain 1, upperthreshold -1000 lower threshold -1000.  Filter trigger threshold On:400 Off:400, 0.2seconds, FM2 and FM3 triggered. (FM2 is zp1:0 FM3 is zpk([1],[0.1],10,'n')resgain(0.684,3,10).)

Aquiring lock:

We are kind of triggreing the whole thing manually by setting up the above initial settings, and then turning off H1:LSC-CONTROL_ENABLE so no control signals are passed from the LSC output matrix to the suspensions.  If we don't do thisthe optics get kicked around and we don't lock.  We wait untill the AS_AIR flashes look slow (~1Hz) and then turn on H1:LSC-CONTROL_ENABLE.  About 20% of the time we then aquire lock (or we try again).  It is taking <1min to lock.

After aquiring lock:

Engage FM4 (zp 4:0).  Lock stretches are lasting for a few minutes  in this configuration, longest locks~10 mins.

Also: 

-The MICH bounce mode keeps ringing up at 17Hz so we have been damping it every now and then using by turning H1:SUS-BS_M2_VRDAMP_P filter.

-Flashes of SRMI were reaching the H1:ASC-OMC_A/B qpds which was moving OM3.  We disabled the feedback to OM3 by setting the H1:OMC-ASC_POS gains to zero. These gains have been returned to their previous values.