We had set up a DARM cavity pole tracker last night (alog 18401). The plot below shows a first result from the cavity pole tracker which showed very interesting results.

Punchlines

• The DARM cavity pole became stable after Evan and Stefan put the offset in ASC-SRC1_YAW.
• Before the offset was introduced, it showed slow dfift which decreased the pole frequency from 350 to 290-ish Hz on a time scale of 20 minutes.

[Tracker setup]

We set up a lockin oscillator in the LSC front end model at 322.1 Hz (alog 18401). The excitation amplitude was set to 2 counts at the LSC DARM output. Through the LSC output matrix it excites ETMX and ETMY with outmatrix elements of +1 and -1 respectively. Since we use one ETM at a time for controlling DARM, this setup excites just one ETM by 2 counts. The audio demod phase was initially set to 0 deg so that we can double-check the phase rotation later on. The demodulation cos and sin gains are set to 1. In the I and Q demodulators, I put a 260 dB gain such that the outputs are human-readable. The low-passes are 0.1 Hz 4th order butterworth currently. The notch has been on all the time (alog 18401) so that the excitation is insensitive to the control loop.

[Calibration of the audio demodulation phase]

According to the DARM loop model, I was expecting a phase rotation of about +80 deg including the known time delay of 219 usec at the excitation frequency of 322.1 Hz. By the way, 219 usec is the total delay of the DARM open loop. However, for some reason, I measured the phase rotation to be -128.4 [deg]. The math I got this number is  phi = atan(measured Q phase / measured I phase). So something is not right. Due to this unknown phase rotation error, I ended up calibrating the audio demod phase using the information that the cavity pole was at 355 Hz at a particular time (alog 18420).

In the post-process, I rotated the demod phase by multiplying a rotation matrix to the I and Q signals such that the demodulated signals has the effect only from the DARM optical plant, or in other words, I subtracted the phase rotation which is not from the DARM plant. I had to rotate them by -86.2 deg in order to get 355 Hz for the data points at around May-15-2015 9:21:34 UTC which is the time when Jeff estimated the cavity pole to be 355 Hz. The advantage of doing this rotation business is that is makes the math easier. In this condition, in-phase signal should be

(in-phase) = G / (1 + (omega / omega_0)^2),

where G, omega and omega_0 are the optical gain, excitation frequency and cavity pole frequency, respectively. Similiarly, the Q phase is also easy;

(q-phase) = - (omega/omega_0) * G / (1 + (omega / omega_0)^2).

Taking the ratio of the two demodulated signal, one can obtain a clean quantity;

(in-phase / q-phase) =  - omega_0 / omega.

This essentially corresponds to doing some atan calculation to derive the phase angle. From this quantity, I computed the DARM cavity pole rfequency as a functin of time as shown in the above plot. I attach a second trend of some relevant channels in the same period.

Also, I changed the audio demod phase in the realtime system to -86.2 deg such that I don't have to do the same post data-massage.

Stefan, Dan

We have edited the common OMC model to enable the READOUT path that performs dynamic normalization as a function of DARM offset and input power.  The changes have been committed to the SVN.  The goal here is to allow changes to input power and DARM offset after we have switched to DC readout, so the power ramp-up and experiments to the DARM offset can be performed after we handoff to the OMC.

Essentially everything in the OMC-READOUT block has been modified, although the overall calculations still match those in T0900023 (except for corrections for the math errors found therein).  The changes are:

• All channels have been replaced with cdsfilt modules to enable ramping on the offsets.
• The switch between the simple scaling and the fringe scaling path has been removed.  We didn't like the hard switch -- our preferred replacement would be a ramping matrix of the sort found in the LSC model, but a change of this magnitude was a little intimidating, so we settled for two filter banks whose output is summed.  Now, to switch from one path to the other, we will ramp the gain on the filter modules for a smooth transition.  This isn't something we necessarily expect to do, but the option is there.
• Upper and lower hard-coded saturation limits were changed to be either very big or very small, so we don't wind up hitting our heads/toes on these hidden gotchas.

A screengrab of the new model block is attached.

We also edited h1omc.mdl to enable the power normalization inputs.  There are two power-related inputs to the linked omc.mdl library from h1omc.mdl, "TRX_IN" and "TRY_IN".  These inputs were grounded.  Instead of using the normalized arm powers (which is what we think was intended), we have routed the requested PSL power (PSL-POWER_SCALE, although this is called LSC-OMC_POWER_REQUEST in the top level of the model) to both inputs.  This channel was already available in the model, the arm powers weren't, we didn't want to add any IPC sender/receiver pairs today.

Models were rebuilt, restarted, and the DAQ was restarted as described by Dave.

One thing we forgot to add are some additional epics readbacks in between terms of the calculation, as sanity checks that everything is acting as we expect.  We'll edit the model later.

Dan, Jim, Dave

Two OMC model changes were made. Both required a DAQ restart.

The first DAQ restart proceeded normally, the second did not complete. h1dc0 reported a bad master file in its log files. In fact it appears that around this time h1dc0 attempted to start three times, each time creating a running configuration with either missing or corrupted master files.

We logged into h1dc0 as root and restarted the daqd process manually. This time the master file was read correctly and the DAQ restarted normally. We are unsure of the original problem, possibly an NFS issue between h1dc0 and h1boot?

Note that on both DAQ startups today, the broadcaster was the last to start. Normally it is the first to start.

Day's Activities

• 8:30-8:40:  Peter/Jeff moving chiller back from Large Equip to Receiving
• 8:34:  Hugh removing STS2 from beer garden
• 8:45-8:55:  Jeff inventory work in Cleaning Area
• 10:06:  Pepsi on site
• 10:10:  Nutsinee checking to see if irises were left closed at Hartman Sensor Table (at HAM4)
• 10:15- afternoon:  MX cleaning Christina/Karen
• 10:46:  MY trip for Jodi
• 11:00:  Ops Training
• 12:15:  Possible nds0 reboot by Dave/Dan M
• 1:45:  Filiberto roll up door
• 2:13:  Filiberto at MX
• 2:57:  DAQ restart (Dave)
• Robert had a few trips out to EY throughout the day

H1 Operator Locking Notes For Today

Came in to find the Arms not locking on GREEN in the morning.  Alignment was OK, but when I tweaked up alignment and engaged WFS & this would drop the arm powers.  With Daniel & Ellie's help (& Evan's alog), saw that there were issues with the Pit/Yaw M0 Lock Filters for the ITMs.  So Inputs were disabled, Cleared Histories & turned off FM2 (+20dB) & FM3 ("empty") filters for ITMx & ITMy.  After this we were able to take the arms to "Locked_No_Slow", and then walked through the rest of Initial Alignment.

When we went to locking the full ifo, the first steps is "Check IR" via ISC Lock Guardian Node.  We had nice ALS arm powers, but when we got to the "Find IR" state, the arms would break lock and the MC would break lock (not sure of the order though).  I believe Sheila caught the issue here (she noticed Tidal issues and then some filters being turned OFF on the ETMs).

Following up what reported by Jeff about the DARM pole frequency, the attached plot shows a simulation of the change in the pole frequency when the SRM is misligned. To move the pole down to 290 Hz we would need a misalignment of about 30 microradians. It seems a large misalignment to me, but at least in simulation it's not affecting much the error signals or the power buildups.

The license server for Matlab has been changed to the CDS network license server for Scientific Linux 6 and Ubuntu 14.04 workstations.  This should really only affect people working with the hardware injection computers, making more licenses available.

Dan, Greg, Jim, Dave

Perhaps coincidentally, but since the LDAS tape robot was relocated late Tuesday h1fw0 has been unstable. Its log files suggest a slow disk system is causing the problems.

We were given permission to reboot the h1ldasgw0 Solaris QFS/NFS server, and Dan took the opportunity to upgrade this Solaris system (last upgrade 9/11/2014).

The only potential problem with unmounting the disk system from h1nds0 is with the SYS_DIAG Guardian node. It is performing regular NDS requests for the past 30 seconds of BRS data to determine if the data is not flatlined. Since this data should be served by the daqd process from memory, and not the nds process from disk, we are confident this will not cause any problems for the node.

Procedure is:

h1fw0: stop monit, stop daqd process (via telnet), un-mount h1ldasgw0

h1nds0: stop monit, stop nds process (via init.d script), un-mount h1ldasgw0

h1ldasgw0: perform upgrades, reboot, share QFS via NFS

h1fw0: mount h1ldasgw0, start monit (which in turn starts daqd)

h1nds0: mount h1ldasgw0, start nds process via init.d script, start monit.

This has not helped, h1fw0 has restarted twice since this was done.

Elli, Nutsinee

The return SLED beam is now centered on the ITMX HWS. The QPD1 sum reads 1.71 (mean) and the QPD2 sum reads 1.32 (mean). Green light was resonates in both arms during the time of the measurement.

The current position of the HWSX lower periscope mirror is X: -286 Y: -927 and the current position of the HWSX upper periscope mirror is X: 300 Y: -300.

The Hartmann plate is off at the moment.

Attached are this week's PSL DBB/ISS scans.

J. Kissel

I've compared many different IFO parameters which we suspected might contribute to the change in DARM Coupled Cavity Pole (DCCP) Frequency against the most recent 11 measurements,
Meas Num    Date                          DCCP Freq
    [ 2]    'Apr 02 2015 08:34:20 UTC'    [320]
    [ 3]    'Apr 06 2015 23:45:13 UTC'    [320]
    [ 4]    'Apr 13 2015 04:15:43 UTC'    [290]
    [ 5]    'Apr 13 2015 06:49:40 UTC'    [290]
    [ 6]    'Apr 15 2015 07:53:56 UTC'    [290]
    [ 7]    'May 01 2015 18:52:59 UTC'    [355]
    [ 8]    'May 02 2015 20:35:54 UTC'    [355]
    [ 9]    'May 06 2015 11:37:31 UTC'    [270]
    [10]    'May 07 2015 07:08:12 UTC'    [260]
    [11]    'May 11 2015 15:50:43 UTC'    [303]
    [12]    'May 14 2015 09:21:34 UTC'    [355] << -- This one is new, it was put under my pillow by the DCCP fairies last night
And they're summarized in the following attached plots. 

The message -- still no clear correlation between any of these parameters and the DCCP frequency.

Details:
For each measurement data, I gather the following collections of EPICS channels for the duration of the measurement, and take the mean to represent the value of the parameter during the measurement:
_RCGs.pdf : 
Transmitted ARM Power (for carrier recycling gain), POPAIR 18 I (for 9[MHz] power recycling gain), POPAIR 90 I (for 45 [MHz] sideband SRC "reflectivity"), ASAIR 90 I (for 45 [MHz] sideband "DRMI" recycling gain)
_ITMCTRL.pdf  : 
ITM Alignment control (Using the DSOFT and CSOFT filter banks) and ITM optical levers
_Oplev(Pit/Yaw).pdf  : 
Pitch and Yaw of all other core opic optical levers
_IFOPWR.pdf  : 
Pre-PSL-periscope IOO BBPD (for power into the IMC), MC2TRANS (for MC1 to MC2 intracavity power), IM4TRANS (for power into PRM)
_FF.pdf  : 
MICH and SRCL FF subtraction gains and output (to indicate whether they were in use)
_TCS.pdf  : 
ETMX Ring Heater Power, ITMX CO2 Laser POWER
Virtually all of these parameters were stable over the course of them measurement, so I'm comfortable with using the mean as representative. The only which were not are the optical levers (no surprise), so I show them with an error bar that is the std deviation over the duration. For all of these, the error bar is much smaller than the variation between measurements, so I still think they're a good representation of the alignment. Not great, thought -- this drift could still be a result of the optical lever drifting and not the actual optic alignment change, so take it with a grain of salt.

The remaining attachments are the time series of data during each measurement, so you can just for yourself if you believe that taking the mean is representative.

Specific parameters that *don't* apparently have a correlation that we expected to reveal something:
POP90 -- (look at _RCGs.pdf, bottom left panel) 
Remember, our intuition says this is a proxy for the effective "reflectivity" of the SRC, and because the SRC is a signal extraction cavity (i.e. over coupled), the lest reflection the better. The three measurements where we had a highest cavity pole frequency at 355 [Hz] (two during the minirun, and one last night) had a POP90 value of 16.02, 16, and 12.28 [uw/W], which is inconsistent, BUT, one could argue that the other measurements where the cavity pole was lower, POP90 was higher -- except for measurement 11 which is slightly lower than 16, and has a DCCP frequency of 303. Further, when the DCCP frequency stays the same, the POP90 value is varying -- take the first three measurements -- DCCP frequency of 320, 320, and 290 [Hz] against POP90 value of 16.64, 18.26, and 21.11 [uw/W]. Not a consistent story here.

Carrier Power Recycling Gain -- (look at _RCGs.pdf, middle left panel) 
This one's a little confusing because Elli/Sheila has renormalized the end-station QPDs to the red single arm power at measurement 9, and the power recycling gain improved two measurements before they did so (see measurements 7 and 8). However, it's still clear where the consistent improvement in recycling gain happened -- between measurement 6 and 7 (the renormalization only results in an ~5% change in reported value for those two measurements, as opposed to the 25% increase in gain). All this taken into account, the "high" recycling gain period sees the entire range of DCCP frequencies from 355 to as low as 260 [Hz].

ITM pitch and Yaw -- (look at _ITMCTRL.pdf) 
No clear correlation between DCCP frequency and the state of ITM alignment. In fact -- as I mentioned the other day, this gift from the DCCP fairies (measurement 12) is the only measurement in which the ITMs were under control, and the alignment to which the DSOFT and CSOFT loops steered the optic which acheieved a high recycling gain seems no more remarkable than when it was high during the mini-run.

PR3/SR3 alignment -- (look at _Oplev(Pit/Yaw).pdf) 
I know the scale is a little rough here (the optical levers were probably centered between measurement 2 and 3), but I've zoomed in the .png, and I still don;'t see a correlation.

Input power -- (look at _IFOPWR.pdf)
no correlation here: consistent power for the past 4 measurements, in consistent DCCP frequency.

MICH/SRCL -- (look at _FF.pdf)
there is a distinct similarity here -- whenever the SRCL FF is OFF, the DCCP is high. I'm not sure what drives the commissioning vanguard to have this on or off, but maybe there's a clue there, given that we're having so much trouble with the stationarity of the SRCL to DARM coupling as well.

TCS -- (look at _TCS.pdf)
no correlation here, but last night's measurement did have a significant change in ITMX CO2 laser power... I'll have to have a conversation with the team about this, 'cause I don't see anything in the log about it

So ... yeah ... no strong conclusions in any direction ... yet. Maybe folks can make better sense of the data than I can...

STS2-A is out for service.  B is actually the vault destined STS2 and Robert is moving it toward its home.  STS2-C remains in service and all sensor correction paths are using the HAM5 unit.

Stefan, Evan

Summary

Adding an offset to the error point of the ASB36I→SRM yaw loop reduces the SRCL→DARM coupling by 10 dB. It seemingly has the added benefit of fixing the slow drift in POP90.

Details

SRM yaw loop offsets

After several days of trying to do SRCL feedforward on a moving target, we decided to try attacking the SRCL→DARM coupling itself.

We started by applying offsets to the dETM loops, since Gabriele's simulation seemed to indicate that this could cause an increase in the high-frequency coupling. We applied offsets of several hundred counts (both signs) to dETM pitch and yaw, and then injected broadband noise in SRCL. We saw a reshaping of the noise (see attachments), but no overall improvement.

Then we moved on to offsets in the SRM WFS yaw loop. Here we saw a more promising improvement with a positive offset at the error point (see attachment). In the end we found that an offset of 2100 ct works best in terms of reducing the coupling at high frequencies. This also seems to coincide with minimal power in POP90.

POP90 stabilization

With this yaw offset engaged, it seems that the drift in POP90 mostly went away when the SRM yaw offset was engaged around 09:14:00 (attachment). There is still some drifting, but the timescale is much longer. Perhaps we are closer to optimal coupling of the 45 MHz sidebands into the SRC. This particular lock lasted for about 2.5 hours (it broke for unrelated reasons) and showed no sign of the POP90/ASB36I instability that we've seen this past week.

DARM offset and calibration

For some additional reduction in SRCL coupling, we tried locking with a smaller DARM offset (14 pm, not 7 pm as I said before) and then updated the calibration (FM10 in the sensing inversion of CAL-CS). However, I have reverted these changes. This means that in general you should not believe the recorded inspiral range for most of the night.

Guardian changes, other configuration changes

If LSC_FF is requested, the Guardian will proceed from DC_READOUT to LOWNOISE_ESD_ETMY to LSC_FF. If desired, one can make a pit stop at COIL_DRIVERS before going through LSC_FF.

I had wanted to add some Guardian code that steps down the TRX/TRY QPD whitening gains by 6 dB before the ASC comes on (and then adjusts digital gains accordingly), since the QPDs will saturate when powering up beyond 10 W. But it seems this makes the ITM loops unstable somehow. So I've left some commented-out code in DRMI_ON_POP and in the DOWN state.

In the ITM M0 lock filters, I moved the integrators from FM2 to FM4 and stuck +20 dB gains in FM2. Now we have some room to adjust the offloading speed.

We repeatedly had problems with engaging ASC loops to the bottom or penultimate mass that have a top stage relieve loop.

In a nutshell, the problem comes with engaging the loop with a relatively big initial misalignment. The fast loop to PUM or TST does the right thing, but saturates its drive stage before the top mass relieve can kick in. Increasing the top mass relief doesn't always work because different loops feed the same test mass.

The ideal approach would be a saturable integrator in the ASC filter banks. Since this this would require a front-end code change, I wrote a python version that watches filter module output and input, and simply turns the input off if the integrator exceeded the limit and the error signal would drive it further away.

The code relies on guardian decorators. I.e. it should be added to any state during which this logic should be active. The decorator is defined in ISC_library.py, and can be called as:

    @FM_limit_checker_decorator(ListOfFIlterModulePrefixes_pos_gain,+1)
    @FM_limit_checker_decorator(ListOfFIlterModulePrefixes_neg_gain,-1)

Example:
    @FM_limit_checker_decorator({'ASC-SRC2_P','ASC-SRC2_Y','ASC-DSOFT_Y','ASC-CSOFT_Y'},+1)
    @FM_limit_checker_decorator({'ASC-DSOFT_P','ASC-CSOFT_P'},-1)

Positive and negative gain characterizes the overall gain of all engaged filters, i.e.
 - +1 : positive input signal leads to growing output signal and vice versa
 - -1 : positive input signal leads to shrinking  output signal and vice versa



Current testing:
================
 - For initial testing we added the decorator to

i) DRMI guardian ENGAGE_DRMI_RUN state:
    @FM_limit_checker_decorator({'ASC-SRC2_P','ASC-SRC2_Y'},+1)

ii) ISC guardian ENGAGE_ASC run state:
    @FM_limit_checker_decorator({'ASC-SRC2_P','ASC-SRC2_Y','ASC-DSOFT_Y','ASC-CSOFT_Y'},+1)
    @FM_limit_checker_decorator({'ASC-DSOFT_P','ASC-CSOFT_P'},-1)

Known bugs:
===========
 - Currently the filter module will be left in whatever state it was when the decorator ran for the last time. It is up to the user to assure the filter module is actually on in the end.


The full code in ISC_library.py is:
---------------------------------------------------------------------------------------------------
def FM_limit_checker_decorator(FMlist,sign):
    class FM_limit_checker(GuardStateDecorator):
        """Check for FM reaching limiters - if so, turn of input"""
        def pre_exec(self):
            for FM in FMlist:
                if  ((-ezca[FM+'_OUTMON'] >= ezca[FM+'_LIMIT']) and (-ezca[FM+'_INMON']*sign> 0)) or
                    (( ezca[FM+'_OUTMON'] >= ezca[FM+'_LIMIT']) and ( ezca[FM+'_INMON']*sign> 0)) :
                    ezca.switch(FM, 'INPUT', 'OFF') 
                else:
                    ezca.switch(FM, 'INPUT', 'ON')   
    return FM_limit_checker

Thomas, Stefan, Jeff, Kiwamu, Elli

Continuing along the same line as yesterday's work on PR3 (alog 15727), we have designed high-bandwidth (<10Hz) actuation filters for the PRM.  These filters are applied to H1ASC-PRC1P and H1ASC-PRC1Y in the central part of the ASC WFS servo.

The filters added to ASC WFS central are called 'PRM^-1' and are:
H1:ASC-PRC1_P:   zpk([0.2+i+0.9;0.2-i*0.9;0.05+i*3.41;0.05-i*3.41],
                [0;0.2+i*2.75;0.2-i*2.75;0.125+i*9.99922;0.125-i*9.99922],1,"n")
H1:ASC-PRC1_Y:     zpk([0.04+i*1.08;0.04-i*1.08;0.1+i*2.08;0.1-i*2.08;0.05+i*3.43;0.05-i*3.43],
                [0;0.15+i*1.8;0.15-i*1.8;0.05+i*3.3;0.05-i*3.3],1,"n")
Some old unused filters were also removed.

Low-pass filters called 'RLP17' were added to the PRM M3 locking filters in pitch and yaw:
H1:SUS-PRM_M3_LOCK_P:  zpk([4+i*119.933;4-i*119.933],[6.78887+i*13.9134;6.788887-i*13.9134],1,"n")
H1:SUS-PRM_M3_LOCK_y:  zpk([4+i*119.933;4-i*119.933],[6.78887+i*13.9134;6.788887-i*13.9134],1,"n")