J. Kissel, K. Izumi, K. Kawabe

Corrections to gamma calculation
After battling through a little bit of complex number analysis in Simulink, I was able to create a revised calculation of the slowly, time-varying, optical gain correction to the IFO's DARM sensing function for the production of calibrated DARM displacement in the front end. What I had originally implemented (see LHO aLOG 17102) had ignored that the change in open loop gain transfer function at the calibration line frequency is a complex number and so what just, in general wrong. 

See attached screenshot 2015-03-05_CAL_CS_GAMMA_LINE1.png for the current implementation, and see the bottom half of LHO aLOG 17102, which is still valid, for what we intend to *do* with the infrastructure.

Notes:
- GAMMA is the ratio of the current DARM open loop gain transfer function at a given calibration line frequency, G, and the same transfer function at a reference time, G0, is ideally real and unity. It is this real part of GAMMA that is fed into the DARM block to correct the fluctuation in optical gain.
- Ideally, the GAMMA should be frequency independent, and we've implemented the correction as though it were frequency independent, i.e. the output of GAMMA calculated for ONE line should be selected in the GAMMA_MATRIX. However, offline, we'll want to *confirm* that the correction is frequency independent, so all four calibration lines have EPICS outputs and Fast Channel Test Points (even though at the moment, we're only planning to turn on two; see LLO aLOG 15870).
- The AMP EPICs input of each line (which again should be synchronized with that line's DEMOD's OSC CLK GAIN) should be in units of DARM_CTRL counts; Joe's matlab script referenced in LLO aLOG 15944 should take care of converting the desired amplitude to get an SNR of 30 in whatever current DARM sensitivity we have.

Updates to CAL_CS_MASTER
- I've cleaned up the DARM block in the CAL_CS_MASTER block, and added descriptive text that describes the output as we're currently intending to use it, i.e. as what's described in LLO aLOG 16421. See 2015-03-06_CAL_CS_DARM.png.
- I've added a DAQ channel list that will now store channels for the auxiliary degrees of freedom which we'll eventually calibrate. The policy is to store all ERR, CTRL, and SUM signals at the full data rate, but only store the SUM in the science frames. I had considered storing the CTRL channels at a lower rate in the commissioning frames, but since they're only used for commissioning the channels, and one almost always wants to put both CTRL and ERR on the same plot, out to the frequency desired for the ERR signal, I leave them sampled at the same rate. Again, this only impacts the commissioning frames. See 2015-03-06_CAL_CS.png
- I've added whitening filters for all of the auxiliary DOFs CTRL, ERR, and SUM channels. If we have dynamic range / double precision issues with DARM, I'm sure we'll eventually have similar problems with these DOFs.
- I've added EPICs readback of all ERR, CTRL, and SUM channels, and changed the naming convention to "MON" instead of "SLOW." This is so we can get displays of these channels on the overview screen which we'll evenutally have to create.

Added HARDWARE_INJ Library Part to Top Level h1calcs.mdl
I've updated the 
${userapps}/cal/common/models/ 
directory, such that we've received the new Hardware Injection library part. It's as described in LLO aLOG 17120, but in summary, the new feature is an ODC bit.

Summary--Looking closer shows that the disturbance seen on the dofs are occurring before the loops are driving; what the hay?  GS13 switching very likely the thing.

Details: Hugo gave me some changes for the guardian and it does as expected but that did not correct the problem.  There was some suspicion that Guardian may have been doing things at the same time and I think these result bear this out but I ignored one thing I should have ruled out first.

The first attachment shows a manual isolation turn on from Tuesday.  This is a zoom in from alog 17042.  MICH is NOT on.  First I use the Reset CPS offset button on the medm which gets 12 samples over 3 seconds for an average (T=1).  It then loads a ramp time of 5 seconds, puts the average values determined into the SETPOINT_NOW, and, the model takes over from there loading the SETPOINT_NOW into the Current Setpoint (BIAS_RAMPMON) over the prescribed 5 seconds.  The next step is turning on the Z Isolation Loop.  It is only the vertical we are engaging and I do this with the Command script (with boost, T=2.)  Notice that nothing shows up on the RZ_LOCATIONMON until T=3 when I start the RZ loop.  This all looks reasonable.

The second attachment is a few minutes later using the guardian to isolate state2, MICH is still NOT in the picture.  T=1 shows that Guardian does not use a TRAMP and the front end puts it in with no delay.  Theoretically, this should not be any problem as again, the loops are not on yet.  However, at T=2, RZ and Z channels start to show motion, even though the loop switches are on until T=3, about 5 seconds later!  T=2 is hard to pinpoint but it is looks to be 2 or 3 seconds after T=1. 

The 3rd attachment is from this afternoon and now MICH is Dark Locked.  I've modified the Guardian to do a 4 second ramp of the Setpoint to RAMPMON.  You can see this as the RESIDUALMON goes to zero as well as the RAMPMON.  Then, 1 or 2 seconds after the RAMPMON is finished, the RZ starts moving, again, all before the Z-loops engage.  With Mich though, the lock breaks (see Watchdog upper right) and who knows after that.

What is the Guardian doing before this... aha!  The switching of the GS13 is being done by the guardian and although it would not impact the CPS_Z_LOCATIONMON, it may glitch the damping loop enough.  Yup, there it is.  The last plot I've added the GS13 SWSTAT and it corresponds to the time the RZ_LOCATION starts to drive off.

Until the Isolation loops are adjusted to work with the MICH LOCK, we should keep the GS13 gains in whitened low gain.  And, unless we make the gain switching even smoother, there needs to be more settling time after the gain switching when we do switch.

Follow up from alog16977 to see if there are any DAC glitches seen during the full interferometer lock. No DAC glitches seen so far. I have also attached the spectrogram and the time series plot of DARM_OUT_DQ in case you're curious... 

These are the OpLev trends for the last 24 hours. All appear to operating normally. Have also included zoom plots.  

The nds2-client software for x1work (Ubuntu 12.04) has been updated to 0.11.4 for testing.

Scott L. Ed P. Chris S.

The cleaning crew relocated the lights, generator and related washing equipment this morning to beam tube section from single door to X-1-5 double doors. Sampled dirty sections and re-cleaned 2 sections previously cleaned earlier in the week, charts show specific sections. 15 meters cleaned and servicing of diesel generator is ongoing.

Sudarshan, Rick

We saw some transient in Pcal laser power in our recent observation. The power variation in these transients are about 20% at its max. We are working on to find where the issue is. Until then, donot trust Pcal calibartion to more than 50% (over-estimation) of what it reports.

After correcting some operational problems and resolving file access issues, I have rerun the PSL DBB for this week. We will review the plots at the weekly PSL meeting.

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)

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.