The following that went unnoticed from yesterday were recovered today:

1. ETMX and ETMY 'misalign' scripts weren't running. Troubleshooting showed slow machines c1auxex and c1auxey weren't responding. The machines were reset.

2. PRM oplev gains were zero. Gain values were set looking back at the burt files.

3. X end PZT power supplies were turned ON and set to 100V.

4. X end doubler temperature was reset to the last optimal value on elog (36.35 deg).

Some hitches that should be looked into:

1. Check: ASS for X arm seems not quite doing its job. ETMX has to be moved using sliders to obtain maximum TRX and the arm alignment was seen to be drifting.

2. Check: Status of other slow machines and burt restore whichever needs one.

ETMX ASC output was turned off for whatever reason. Switched it on, ASS is fine.

While I'm looking at the PRM ASC servo model, I tried to use the current servo filters for the ASC
as Manasa aligned the POP PDs and QPD yesterday. (BTW, I don't find any elog about it)

I found no issue for locking PRMIsb with the REFL165I&Q signals if the PRM ASC is employed.
See this entry for the IFO settings.

It is just stable. The IFO is ready for the arm scanning.

=== ASC setting ===

PRCL_PITCH: FM1/3/9 x-0.004
PRCL_YAW: FM1/3/9 x-0.001

The PRM OPLEV has to be off when the PRM ASC is engaged. Actually, it turned out that we don't need OPLEV for locking.

I aligned MC2 suspension by 0.01 in pit and yaw to align the MC better to the PSL beam. Then I turned the WFS back on. The beams are not centered on the WFS heads.

Nic and Gabriele ought to send their SURF some example code (in April) for how to start redesigning the WFS telescopes so that we can order some optics in early June.

I've also turned on the MC2 TRANS path to gather some data over the weekend on how well or bad it works. Please turn it off on Monday.

* EQ Southeast of LA around 45 minutes ago. Callum and I felt it.

* Koji and I came in to recover. MC suspensions had been mis-aligned. ETMs both tripped their watchdogs.

* As before, the ETMX was stuck in its cage and the UR & LR OSEMs were reading zero V.

* We moved the MC sus back to their OSEM values from 2 hours ago. Koji aligned everything else by just using his chee.

* To shake the ETMX loose, I tried a different tactic than the "Great Balls of Fire". I started giving it 20k steps through the ASCYAW filterbank (with ramping OFF). I used the green light in the X arm video to look at the swinging. Using this as a readback I pumped the OFFSET button on ASCYAW to resonantly swing up the yaw motion. I had to turn the watchdog thresh up to 2000 temporarily. After a couple minutes the ETMX was free.

* We then used the bias sliders to steer it back onto the OL center (which Q nicely lined up for us recently) and then X arm locked in green right away.

Fri Mar 28 22:38:04 2014:  We've just ridden through the 5th aftershock. None of the aftershocks have tripped the watchdogs  but they break the IMC lock.

[Koji Rana]

We are looking at NTP settings. I looked at nodus.

- xntpd is running

- We decided to start over the configuration file /etc/inet/ntp.conf

    - The old configuration was moved to ntp.conf.bak

    - The server configuration file was copied from ntp.server to ntp.conf

    - Caltech NTP servers 131.215.239.14 and 131.215.220.22 were selected as the servers we are reffering

    - Commented out the lines for "fudge" and "broadcast"

- xntpd was restarted

    - sudo /etc/init.d/xntpd stop
    - sudo /etc/init.d/xntpd start

- check how the daemon is running
      tail -50 /var/adm/messages

   Mar 28 23:00:49 nodus xntpd[27800]: [ID 702911 daemon.notice] xntpd 3-5.93e Mon Sep 20 15:47:11 PDT 1999 (1)
   Mar 28 23:00:49 nodus xntpd[27800]: [ID 301315 daemon.notice] tickadj = 5, tick = 10000, tvu_maxslew = 495, est. hz = 100
   Mar 28 23:00:49 nodus xntpd[27800]: [ID 798731 daemon.notice] using kernel phase-lock loop 0041
   Mar 28 23:00:49 nodus last message repeated 1 time
   Mar 28 23:00:49 nodus xntpd[27800]: [ID 132455 daemon.error] trusted key 0 unlikely
   Mar 28 23:00:49 nodus xntpd[27800]: [ID 581490 daemon.error] 0 makes a poor request keyid

- check the syncing staus by ntpq -p

        remote           refid      st t when poll reach   delay   offset    disp
   ==============================================================================
   *ntp-02.caltech. .CDMA.           1 u   37   64  377     0.56    3.010    0.08
   +ntp-03.caltech. ntp1.symmetrico  2 u   36   64  377     0.52    2.727    0.12
      this * means nodus is synced to ntp-02. "+" means it is stand by as a valid secondary server.  "when" increases every second.
      When "when" reaches "poll" the clock is synced to the server. These marks are not set at the beginning.
      It was necessary to wait for sometime to get synced to the server.

- Once nodus became a synced server, the realtime systems starts syncing to nodus automatically.

   controls@c1sus ~ 0$ cat /var/log/ntpd
   25 Mar 01:41:00 ntpd[4443]: logging to file /var/log/ntpd
   (...)
   28 Mar 23:13:46 ntpd[4983]: synchronized to 192.168.113.200, stratum 2
   28 Mar 23:14:25 ntpd[4983]: time reset +39.298455 s
   28 Mar 23:14:25 ntpd[4983]: kernel time sync status change 2001
   28 Mar 23:25:19 ntpd[4983]: synchronized to 192.168.113.200, stratum 2
   controls@c1sus ~ 0$ ntpq -p
        remote           refid      st t when poll reach   delay   offset  jitter
   ==============================================================================
   *nodus.martian   131.215.239.14   2 u   42   64  377    0.140   42.222  11.373


FB: /etc/ntp.conf was updated as below such that it refers nodus and also caltech server when nodus is not available

server 192.168.113.200
server 131.215.239.14

ntpd was restarted and

diskless RT machines: they are booted from /diskless/root on fb.
Therefore /diskless/root/etc/ntp.conf was updated in the same way as above.
When the machines are rebooted, this setting will be active.

control machines:

now they are referring nodus and other external servers too.

Local earthquake activity is up. Our suspensions are holding well.    ETMX and ETMY sus damping restored.

 MC2_TRANS path in WFS servo turned OFF.

 Guilty!!

POP path

The POP PD was showing only ~200 counts which was very low compared to what we recollect from earlier PRMI locks (~400 counts). Also, the POP ASC QPD was also not well-aligned.
While holding PRMI lock on REFL55, I aligned POP path  to its PD (maximize POP DC counts) and QPD (centered in pitch and yaw).

X and Y green

The X green totally lost its pointing because of the misaligned PZTs from last week's power failure. This was recovered.
Y arm green alignment was also recovered.

I have included Yarm CESAR to the LSC model. It was just a copy paste of the Xarm CESAR. Since we are now meditating about implementing CCESAR and DCESAR, I did not run or install the model as yet.

Last week, while I had the PRMI locked on REFL33, I did some poking around with mirror excitation to RFPD quadrature transfer functions. I got some indication of weird things with sensing MICH with the 3F REFL signals, but it should be explored more before taken as a real thing. I just figured I would show what I saw. 

With that disclaimer out of the way, here's what I did:

• Locked PRMI on PRCL:REFL33_I and MICH:REFL33_Q, as detailed in my earlier ELOG
• Created PRCL and MICH excitations at two different frequencies, notched said frequencies out of the control filters
• Took transfer functions from mirror LSC output signals to 33 I, 33 Q, 165 I, 165 Q in DTT
• For each DOF, look at the measured transfer functions only at the excitation frequency. (Assuming good coherence, which was there)

The basic idea was, some PRCL motion (for instance), has a transfer function to both the I and Q quadratures at a given PD. As the PRCL excitation sine wave goes through one cycle, the REFL signals at the excitation frequency go through some coherent cycle. Thus, the excitation traces out some trajectory in the I vs. Q plane. I believe this is analogous to the typical "radar plot" that we make for sensing matrix elements. 

However, the straight line that we normally plot in the radar plots assumes a certain phase relationship between the DOF-> I and DOF->Q transfer functions that results in a straight line. Here are the trajectories I actually measured, normalized by the excitation amplitudes.

The plotted traces are (x,y) = (H_prcl->I * prcl, H_prcl->Q * prcl) and  (x,y) = (H_mich->I * mich, H_mich->Q * mich) where H_prcl->I is the measured complex transfer function from prcl to REFL I, for instance, and prcl and mich are the excitation signals, normalized to unit amplitude.

PRCL looks like a nice straight line in both of these, and pretty well phased, but not only is MICH not very orthogonal to PRCL, there is quite a bit of ellipticity present, which means we can't fully decouple the two DOFs, even if they were nominally orthogonal. 

I'm not sure what may cause this. To back up this measurement/interpretation, I tried to take measurements of these transfer functions across different excitation frequencies via swept sine DTT, but seismic activity kept me from staying locked long enough...

I guess that you get an ellipse when the transfer functions to I and Q have a different phase. One mechanism could be that when driving MICH we make some residual PRCL and this couples with a different transfer function to both I and Q. However, I would expect no phase lag in the PRMI configuration, since there is no enough optical delay in the system to give significant dephasing at few hundreds Hz. This effect might come from mechanical resonances.

It is worth measuring the optical transfer functions from both PRCL and MICH to REFL signals at all frequencies, to see if we have strange features in the TFs.

A series of measurements / calculations for the PRM ASC characterization and servo design

1) Actuator characterization

The actuator responses of the PRM in pitch and yaw were measured (attachment figure 1). I believed the calibration of the oplev QPD to be
1 count/urad. The oplev servo loops were turned off at the FM inputs, and the filter banks were turned off so that the response has the open
loop transfer function except for the servo filter.

The measured transfer functions were fitted with LISO. The LISO results (c.f. the source codes) were shown in the figure. The responses also
include the 60Hz comb filter present in the input filters. The responses are well approximated by the single pendulum with f0 of 0.6-0.8 and q of 3.5 and 6.3.

From this measurement, the actuator responses of the PRM at DC are estimated to be 2.2 urad/cnt and 1.8 urad/cnt in pitch and yaw, respectively.

2) Sensor response of the POP QPD

As we already know how the actuators respond, the QPD optical gain can be characterized by measuring the actuator response of the QPD
(attachment figure 2). The QPD signals are such noisy that the response above 1Hz can't be measured with sufficient coherence. Below 1Hz,
the response is well represented by the actuator response measured with the oplev. From this measurement, the optical gains of the QPD
with respect to the PRM motion are 650 cnt/urad and 350 cnt/urad.

3) Open loop transfer function of the current ASC servo

By combining the above information with the servo setting of the servo filters, the open loop transfer functions of the PRM QPD ASC loops
were estimated (attachment figure 3). Actually the expected suppression of the fluctuation is poor. The yaw loop seems to have
too low gain, but in fact increasing gain is not so beneficial as there is no reasonable phase margin at higher frequency.

With the estimated openloop transfer functions and the measured free-running angular fluctuation, the suppressed angular spectra can be
estimated (attachment figure 4). This tells us that the suppression of the angular noise at around 3Hz is not sufficient in both pitch and yaw.
As there is no mechanical resonance in the actuator response at the frequency, intentional placement of poles and zeros in the servo filter is necessary.

4) Newly designed ASC filter

Here is the new design of the QPD ASC servo (attachment figure 5). The target upper UGF is 10Hz with the phase margin of 50 to 60deg.
The servo is AC coupled so that we still can tweak the alignment of the mirror.

As this servo is conditionally stable, at first we should close the loops with stable filter and then some boosts should be turned on.
Estimated suppressed fluctuation is shown in the attachment figure 6. We can see that the fluctuation was made well white between 0.5Hz to 10Hz.

The filter design is shown as follows:

Pitch
FM1: zero at 0Hz, pole at 2000Hz, gain at 2000Hz = 2000

FM3: (boost)
zero: f: 0.5Hz q: 1  /  4.5Hz, q: 1 / f: 1Hz, q: 3
pole: f: 2Hz q: 3  / f: 2.7Hz, q: 2  / f: 1Hz, q: 15

FM9: (HF Roll-off)
pole: f: 40Hz q: 1.7
 
Servo gain: -0.028

Yaw
FM1: zero at 0Hz, pole at 2000Hz, gain at 2000Hz = 2000

FM3: (boost)
zero: f: 0.7Hz q: 2  /  3Hz, q: 7 / f: 2Hz, q: 6
pole: f: 1.02Hz q: 10  / f: 4.5Hz, q: 0.8  / f: 1.5Hz, q: 10

FM9: (HF Roll-off)
pole: f: 40Hz q: 1.7
 
Servo gain: -0.0132

Comsol 4.4 is now installed under /cvs/cds/caltech/apps/linux64/COMSOL44. I've left the other installations alone. I've changed the symlink on megatron so that comsol now starts Comsol 4.4.

The first time I ran comsol server, it asked me to choose a username/password combo, so I made it the same as the combo used to log on to megatron.

We should consider uninstalling some of the older Comsol versions; right now we have 4.0, 4.2, 4.3b, and 4.4 installed.

Koji locked the MC, arms, and PRMI, with no troubles, after the M8.2 earthquake off the coast of Chile, that happened about 4 hours ago.

Koji and I have the PRMI locked right now, and we hear a very strong violin mode ringing up, at 628Hz.  This is, according to Koji's elog 9634, what we expect the PRM's violin mode to be.  However, the current PRM violin mode notch is really more of a bandstop filter, between 622-670Hz.  At 628Hz, it has a suppression of about -20dB.  If I try to increase the width of this notch by making it 612-670Hz, the PRMI won't hold lock.

We're leaving this as a daytime task for tomorrow, since we're in the middle of taking data to show that Koji's new ASC filter design (slightly tuned from his elog 9769) works well.

Edit:  I have moved the PRM violin notch frequency over to 612-660 Hz, and after letting it sit for a while (while locked on PRMI), the violin mode has settled down.  Interestingly, if I compare the spectrum with and without the 1st order violin mode notch, it looks like the 2nd order mode changes from 1256Hz to 1303Hz.  I don't know what is going on here, but we already have notches for both of those frequencies.

[Koji Jenne]

New PRM ASC was implemented. [to be cnt'd]

I was trying to lock PRMI+2 arms, but I'm losing patience with the MC losing lock.  It's mostly well-behaved, but every now and again it'll lose lock, and it always seems to be just when I've gotten to a delicate part.  Anyhow.  I don't think anything needs fixing.

I am not able today to acquire PRMI lock with REFL 165 I&Q, nor am I able to follow Koji's prescription to transition to 165 from 55.  However, I am able to transition to, or just straight-up aquire on, REFL 33 I&Q.  The new ASC is awesome.

Before trying to lock with REFL165, I redid it's demod phase, by actuating on the PRM while locked on REFL 55, and minimizing the PRCL signal in the Q-phase.  Old 165 phase was -83.5 degrees, new is -79.5 degrees.

I then tried the procedure of misaligning the PRM, acquiring ALS lock of both arms, finding the arm IR resonances, and moving the arms off resonance.  Then I restored the PRM, and locked the PRMI on sidebands using REFL33 I&Q. 

Something was a little weird and unexpected:  If the arms were not far, far off resonance, there was a large MICH offset, so that AS was bright, and POP was pretty dark.  If I moved the arms farther from resonance, POP would come back to the "normal" brightness, which was ~460 counts on POP110I.  When POP was dark-ish, POP110I was about 150, although this number could be changed by moving the arms around.  This number was not dependent on PRM alignment.  Also, PRCL was not yet starting to resonate the carrier, because POPDC stayed at its low sideband-lock level of about 90 counts (vs. 2,000+ for a PRMI-only carrier lock), and POP was visually dark on the camera. 

---------------------------------

While playing with PRMI + 2 ALS arms is entertaining for the evening, I don't yet have a plan for dealing with the changing CARM optical plant for IR signals situation.  That's in progress in the daytime.

 Atm2, Chilean 8.2M eq arrived to the 40m 16:57 in 10 minutes. Our OSEMs did not see them.  Hanford got it 2 minutes later.

 We just received the loaner controller that will be swapped in it tomorrow morning.

The vacuum pressure will rise somewhat during this action.

As the designed ASC filters in this entry had too little phase margins (~10deg), I had to compromise the servo design.

The design was modified and tested again. This will be reported by a following entry.

Incidentally, I have adjusted the demodulation phases of REFL33/55/165 for PRMIsb so that the PRCL is eliminated from the Q signals.

REFL33    125.5 deg -> +136.5 deg
REFL55      45.0 deg -> +  25.0 deg
REFL165   -79.5 deg -> +  44.5 deg

This change of the demod phase for REFL165 was a bit surprising.
I did not check the sign, so it could be -135.5 deg. But still this is a bit change.

2 more earthquakes in Chile:  a M6.4 and a M7.8. 

We got them about 15 minutes ago (according to the BLRMS on the wall), but when I go tin, the MC was already locked, and engaging the LSC immediately got me PRMI lock (since that's the alignment state that the IFO was left in).

The new PRM ASC design

Pitch
FM1: zero at 0Hz, pole at 2000Hz, gain at 2000Hz = 2000

FM5: (boost)
zero: f: 0.5Hz q: 1  /  4Hz, q: 2 / f: 1Hz, q: 3
pole: f: 2Hz q: 3  / f: 2.7Hz, q: 2  / f: 1Hz, q: 15

FM9: (HF Roll-off)
pole: f: 40Hz q: 1/Sqrt(2) (2nd order butterworth)

Servo gain: -0.023

Yaw
FM1: zero at 0Hz, pole at 2000Hz, gain at 2000Hz = 2000

FM5: (boost)
zero: f: 0.5Hz q: 1  /  4Hz, q: 2 / f: 1.5Hz, q: 10
pole: f: 1.02Hz q: 10  / f: 3Hz, q: 5  / f: 2Hz, q: 6

FM9: (HF Roll-off)
pole: f: 40Hz q: 1/sqrt(2)
 
Servo gain: -0.027

The loop gains were adjusted to have the UGFs of 10Hz. The measured openloop transfer functions were compared with the model.
The transfer functions for yaw are well matched. However, the pitch ones don't. It seems that the pitch loop has extra low pass
which I can't locate. The possibility is the analog electronics of the pitch loop.

The effect of the control between 0.3Hz to 3Hz are well represented by the model. The attachment 2 shows the free running
angle fluctuation, the ones with the control engaged, and the estimated spectra. Indeed, the estimated spectra well represent
the measured angular spectra.

[EricQ, Jenne]

We started out this evening by locking the PRMI, on different REFL PDs, just to make sure that we could.  We were able to acquire lock (without having to transition) on either REFL55, REFL33 or REFL165 (I&Q phases for each).  By looking at the transfer function between REFL 55 I and REFL 165 I, I determined that the phase of REFL165 needed to be -135.5, not +44.5, so that the gains were the same sign in all REFL PDs (this is in reference to Koji's elog 9777).  The time to acquisition is much shorter with REFL55 than with the other 2 photodiodes.  I'm not sure right now why this is, but it's pretty consistent, and even more so when the arms are held off resonance.  It is also easy to acquire lock with REFL 55 and then transition to either of the 3f diodes.

PRMI settings:

MICH gain = 2.0.  FMs 4, 5 always on.  FMs 2, 3, 6, 7, 9 triggered with 35 up, 2 down.  Trigger servo on POP110I with 100 up, 10 down.

PRCL gain = -0.020.  FMs 4, 5 always on.  FMs 2, 3, 6, 9 triggered with 35 up, 2 down.  Trigger servo on POP110I with 100 up, 10 down.

PRCL ASC triggered with 50 up, 10 down.  Both pitch and yaw servos had FMs 1, 9 always on, and the FM 6 boost turned on by hand after lock acquired.  Pitch gain = -0.023, yaw gain = -0.027.

If using REFL55, PRCL = I = 1 in the input matrix, and MICH = Q = 1 in the input matrix.

If using REFL33, PRCL = I = 3 in the input matrix, and MICH = Q = 3 in the input matrix.

If using REFL165, PRCL = I = 0.15 in the input matrix, and MICH = Q = 0.1 in the input matrix.

We then moved on to trying to do PRMI + 2 arms, but have been plagued a little bit by locklosses, which may be due to the high seismic from the few large and many small Chilean aftershocks. 

Settings:  With the PRM misaligned, we acquired ALS lock in a CARM/DARM fashion.  The Xarm servo was our "darm" proxy, with +1*ALSX and +1*ALSY.  The Yarm servo was our "carm" proxy, with -1*ALSX and +1*ALSY.  The opposite signs from what you might expect is from our having placed the 2 aux laser frequencies on opposite sides of the PSL.  Our DARM (xarm) was actuating +1 on ETMX and -1 on ETMY.  Our CARM (yarm) was actuating +1 on MC2.  Then we put in a CARM offset of ~60 counts.

We then realigned the PRM, and locked the PRMI (settings as above).  It is much easier to acquire lock with REFL55 than it is with REFL33 or REFL165.  Also, when we are locking the PRMI with REFL55, the AS port is dark, and we see bright sideband resonance at the POP port, as we normally expect.  However, as with last night, when we lock the PRMI with either of the 3f PDs, we see a very bright AS port, and a dark POP port.  Tonight, putting in a MICH offset did not seem to make a significant difference.  As with last night, moving the arms farther away from resonance removed this MICH offset.  I am sure that this is not an artifact of the photodiode dark offsets not being set properly, since I rechecked those carefully. 

We have not come to any interesting conclusions about PRMI+2 arms tonight, since we have started losing the MC every few minutes (maybe seismic-related?). 

[EricQ, Jenne]

Much more success later! 

We've had the arms locked on ALS and held off resonance for more than 2 hours now.  That's good.  We've done several trials of locking the PRMI and trying to reduce the ALS CARM offset.  Once we were able to get quite close, but we never achieved zero CARM offset. 

One big finding is that when the TRX and TRY are about 0.1 in the coupled-cavity case, we start to see real length information in the 1/sqrt(trans) signals.  Q will edit this elog, or reply to it, with the data that he has collected.

 The loaner controller is swapped in. It has  520 Hz rotation speed.  This speed use to be 680 Hz with our old one.

So, here's the basic: "We reduced the CARM offset and saw more TRY" plot. 

As Jenne mentioned, we suspected that we were seeing real displacement information in the sqrtInv signals. (We had incidentally hard switched to the transmon QPDs for all of this)

Here's a 2d-histogram of the ALS CARM error signal vs. the sqrtInv CARM signal (i.e. 1/sqrt(TRX) + 1/sqrt(TRY))

This is exactly the shape we expect, which is cool. You can see where we stepped the offsets, too. It looks like the signal gets into it's good linear range when ALS CARM was about -20, which is when TRY was a little under 0.1, which seems pretty early and potentially useful. 

Also, here are snapshots of what REFL11_I and sqrtInv CARM were doing in the last five seconds of time in the above plot, which was shortly before we made the offset push that broke the PRMI lock. If you look really closely, maybe you can convince yourself that there is some common information in them...? It's hard to say. In any case, there is definitely CARM pdh action happening.

 The other day, Jenne and I were comparing my MIST simulation to her Optickle simulation for the CARM transfer functions I posted some days ago. She told me that the arms are not exactly where they should be for the whole "PRC length tuning to account for sideband reflection phase off resonant cavity" deal. 

Specifically, as in the wiki (but with newer modulation frequencies), I calculated the ideal arm length to be 37.795 m some time ago, when doing PRC length simulations, and Jenne has told me that the X arm is more like 37.6m, and Y is 37.9. So, I updated my simulations, and found the following:

This does weird things to the f2 sideband buildup on resonance in the PRFPMI configuration:

(POP is way huger than than the TR's, because the POP pd's are artificially "inside" the cavity, whereas TRX/Y is actually transmitted through an ETM)

This is not necessarily directly something to worry about, but I think the following may be. It looks like this arm length mismatch actually causes the PRCL demodulation phase in REFL 165 to change dramatically with the CARM offset. (REFL33 seems fine, though. 5 degrees causes less than a 1% effective gain change.) 

My simulations don't include any signal recycling yet, so I don't have anything to show if there is a similar effect for SRCL, but it wouldn't surprise me... 

In today's ISC call, Kiwamu was comparing two ways to approach resonance: 

• "C-Type": The scheme we currently think about; zero DARM offset and slowly reduce the CARM offset
• "D-Type": Start with no CARM offset, but a DARM offset and reduce that. 

D-type might be interesting to check out, since things change a little less dramatically when you reduce the DARM offset. Maybe this makes signal hopping easier? Signal recycling may complicate things, though. 

So, I've simulated CARM and DARM offset effects on CARM and DARM signals. (As with the previous plots, this is for the PRFPMI configuration.) From moving both offsets around, it looks like the resonance peak is about 5x wider in DARM than in CARM, so I simulated a 50pm offset range for CARM and a 250pm offset range for DARM. 

Here are some CARM signal transfer functions subject to CARM offsets in the top plot, and DARM offsets in the bottom plot. 

It's looks like the DARM offset changes cause much less dramatic changes in the CARM plant features. It's conceivable that this would make CARM locking easier. 

Here are some DARM plant transfer functions. 

In these plots, I did something kind of artificial: when we move the CARM offset, it changes the proper demodulation phase to get DARM in the Q of the AS 1F RFPDS. So, at each CARM offset, I re-phased the AS 1F demodulators, to show the total DARM information available at the AS RFPDs at each offset, rather than what one would actually see in them with a static demod phase. 

This morning we attempted to replace the c1sus front end machine with a spare that had been given a second CPU, and therefore 6 additional cores (for a total of 12).  The idea was to give c1sus more cores so that we could split up c1rfm into two separate models that would not be running on the hairy edge of their cycle time allocation.  Well, after struggling to get it working we eventually aborted and put the old machine back in.

The problem was that the c1sus model was running erratically, frequently jumping up to 100 usec of a 60 usec clock allocation.  We eventually tracked the problem down to the fact that the CPUs in the new machine are of an inferior and slower model, than what's in the old c1sus machine.  The CPU were running about 30% slower, which was enough to bump c1sus, which nominally runs at ~51 usec, over it's limit.

This is of course stupid, and I take the blame.  I skimped on the CPUs when I bought the spare machines in an attempt to keep the cost down, and didn't forgot that I had done that when we started discussing using one of the spares as a c1sus replacement.

I think we can salvage things, though, by just purchasing a better CPU, one that matches what's currently in c1sus.  I'll get Steve on it:

c1sus CPU: Intel(R) Xeon(R) CPU X5680 3.33GHz

In any event, the old c1sus is back in place, and everything is back as it was.

I played around with the PRMI + 2 arms situation again this evening.  (I'm not ready to call it "PRFPMI" until we're at least partially using IR signals for CARM and DARM control).

I'm still a little bothered by the fact that we lose almost all light in the PRC when we're reducing the CARM offset.  I'm not sure where the light is going, but it's not circulating in the PRC, since I see the POP camera get very dark.  I can bring back light by changing either the PRCL offset, the MICH offset, or to a lesser extent (or maybe I'm not going far enough in offset) the DARM offset.

Tonight, I was using ALS to push on the ETMs in DARM/CARM mode (I didn't push on MC2 today, since it was being finicky and I had a hard time locking CARM with the MC as the actuator today). 

For the PRMI, I was using REFL 33 I&Q.  PRCL gain was -0.04, MICH gain was +0.8.  REFL 33I varied between +2 and +1.2 (smaller gain necessary as CARM offset was reduced, but it's easier to acquire at large CARM offset with larger gain), and REFL 33Q was +1.0.   PRCL has the usual FM 2,3,6,9 triggered, but MICH only had FM 2 triggered.  The others (particularly FM6) make MICH lose lock.  PRCL ASC was engaged, with the PRM oplev off.

Most of what I was trying tonight was to reduce the CARM offset, and then adjust some other offset (MICH, PRCL or DARM) to maximize POP DC.  It's possible that the POP 110 and 22 diodes are changing their optimal demod phases as the optical plant changes, but POPDC is just DC. 

I wasn't able to get the CARM offset below about 40 counts.  At some point I had both CARM and DARM offsets at 50 counts, and had IR resonance in the Xarm, but no resonance in the Yarm.  I guess this is just part of having a simultaneous CARM and DARM offset.

EDIT:  If I leave the CARM offset at 0, and use a large DARM offset (100 counts), I can acquire PRMI lock, but I run into the same problems as I reduce the DARM offset - the POP power decreases, and I lose lock around 45 counts.

Side note: Earlier today I redid the POP 110 and 22 phases.  POP110 was -61 deg, and is not -101 deg.  POP22 was +164 deg, and is now -105 deg.  I'm not sure why they needed such radical changes.  When sideband locked on REFL33, POP110 had an average DC level of 580 cts, while POP22 had a value of 290 cts.

I vaguely remember that the ALS count (Phase Tracker output) is converted to Hz@532nm by a factor  ~20kHz/cnt.
This means the calibration for the IR frequency is 10kHz/cnt.

If this is true 100cnt is 2MHz. Isn't it too big?

Assuming 38.5m for the arm length, FSR is 3.89MHz. (~389cnt)

Our sideband is at integer multiples of 11.03MHz. So...

1xf1 is 0.62MHz (62cnt) away from the carrier
2xf1 is 1.24MHz (124cnt)
3xf1 is 1.86MHz (186cnt)
5xf1=1xf2 is 0.79MHz (79cnt)
10xf1 = 2xf2 is 1.58MHz (158cnt)
15xf1 = 3xf2 is 1.52MHz (152cnt)

So we have to be well with in 62cnt to avoid resonating modulation sidebands.

There maybe some mistake in the factors.
e.g. Phase Tracker calibration is not correct, or CARM ALS OFFSET has factor 2 different calibration from the arm ALS offset.

 Since we don't have an arm length precision measurement (i.e. better than centimeters), why not just do as Koji suggests and use the ALS to get the frequency spacing between a few red FSR and then we have the measurement solid ?

Arm lengths measured using ALS. Both the arms were estimated to have the same length (to the order of a centimeter) 37.51 m

How
I used ALS error signal to lock the arms and scanned the arm to find 4 consecutive IR resonances. From the beat note frequencies measured using the spectrum analyser during IR resonance, the FSR, and hence the length of the arms were calculated.

The estimated lengths are not very precise down to a mm given the resolution of the spectrum analyser. We have brought out the rubidium clock to use as reference for the spectrum analyser to challenge the measurements.

Koji was right, and I was using much too large of a CARM offset.  Tonight, I set either my CARM or DARM offset to 3 counts, and was able to easily acquire PRMI lock using REFL33. 

For either CARM or DARM offset reduction (the other one was kept at zero offset), I was able to get to about 0.5 counts, but I lose lock when I try to go to 0.4 or 0.3 counts.  One time, I tried "jumping over" the resonance, by going from minus 1 to plus 1 in CARM offset.  Plots of this below.

Locking notes

ALS locked with "Xarm" servo as proxy for DARM, and "Yarm" servo as proxy for DARM.  Pushing only on ETMs today, not the MC. 

MICH / PRCL:

Input matrix:  1's in REFL 33 I&Q, if not using power normalization.  200's in REFL 33 I&Q if power normalization used (either POPDC or POP22).  200 used because that's about the average value of POPDC or POP22 when PRMI sideband-only resonant.

Trigger:  POP22, up 100, down 10.

Power normalization:  1's for both MICH and PRCL in POP22I for one trial.  1's for both MICH and PRCL in POPDC for another trial.  Both seemed to work equally well, although that may change when I'm actually getting IR resonance in the cavity.

FM triggers:  MICH = FM2.  PRCL = FMs 2, 3, 6, 9.  Trigger up = 35, down 10.  PRCL delayed by 0.5 sec, MICH delayed by 5 seconds.

Servo gains:  MICH = 0.4, PRCL = -0.01

Observations:

When I approach the situation of both arms resonating, it pretty consistently looks like the PRM is getting pushed in pitch (and not in yaw).  I don't know why this could be, but it seems like this is the big symptom before lockloss - if the POP spot starts moving (and the PRM suspit signal starts moving), PRMI lock is going to be lost.

I don't know if it's imperfect alignment, imperfect mode matching, or something else, but I see lots of high-order higher order modes on both the POP and AS cameras when the CARM or DARM offset is less than 1 count.  I tried to take a video, but the brightness and contrast aren't set as high as on monitors 3 and 5, so it's hard to see the dim stuff.  Youtube.  At the midpoint of the video, you see a lockloss.

Even though I have overridden the transmission triggers so that I only use the QPDs for the transmission signals, I'm only seeing arm transmission values up to about 50 from each arm.  If we had ideal PRC gain, we expect something like 650 or 700. 

A few plots

All of the raw data for these plots, and several other channels, is in /users/jenne/PRFPMI/PRMI_2arms_8Apr2014/m1_to_p1_carmOffset_1081065069.  As mentioned above, "XARM" is CARM, and "YARM" is DARM.  So, the XARM_IN1 tells us about the CARM offset that I was applying.  The start time is 1081065069, and the plots are all 8 seconds long.

First, the transmitted power and the CARM offset.

The REFL_I error signals and the CARM offset.

The RF signals that we will eventually chose from for CARM and DARM control. Note that I'm not sure about the AS55 phase, so I plot both I and Q.

The PRM suspit and sus yaw angular signals and the CARM offset.  I don't see a huge change in the suspit signal, but it does seem to change character once we approach arm resonances.

I have taken EricQ's simulation results for the CARM plant change vs. CARM offset, and put that together with the CM and CARM digital control loops, to see what we have. 

The overall gains here aren't meaningful yet (I haven't set a UGF), but we can certainly look at the phases, and how the magnitude of the signals change with CARM offset.

First, the analog CM servo.  I use the servo shape from Den's elog from December, but only what he calls "BOOST", the regular servo shape, not any of the super boosts, "BOOST 1-3".   No normalization.

Next, the digital LSC CARM servo (same filters as XARM and YARM).  I have used FM4 and FM5, which are the 2 filters that we use to acquire regular LSC arm lock.  For the actuator, I just use a 1Hz pendulum as if I'm pushing only on the ETMs.

I also used the exact same setups as above, but normalized the transfer functions by a DC photodiode output.  The analog CM loops change the least (around a few kHz) if I use POPDC.  The digital CARM loops change the least (around 100Hz) if I use TRX (or, equivalently, TRX + TRY).

Here are the normalized plots:

Either way, with or without normalization, the digital CARM loop will go unstable between 0-10pm, for both the REFL RF photodiodes.  We need to figure out how to get a realistic transfer function out for the 1/sqrt(TRANS) signals, and see what happens with those.  If those also look unstable, then maybe we should consider a DC signal for the analog CM servo to start, since that could have a wider linear range.

[Jenne, EricQ]

This evening we took things a little bit farther than last night (elog 9791) and transitioned CARM to fully IR signals, no ALS at all for CARM error signals!  We were unsuccessful at doing the same for DARM. 

As we discussed at 40m Meeting this afternoon, the big key was to remove the PRCL ASC from the situation.  I don't know specifically yet if it's QPD saturation, or what, that was causing PRM to be pushed in pitch last night, but removing the ASC loops and reengaging the PRM optical lever worked like a dream. 

Since we can now, using ALS-only, get arbitrarily close to the PRMI+2 arm full resonance point, we decided to transition CARM over to the 1/sqrt(transmission) signals.  We have now done this transition 5 or 10 times.  It feels very procedural and robust now, which is awesome!

To make this transition easier, we made a proto-CESAR for the CARM signals in the LSC.  There's nothing automatic about it, it's just (for now) a different matrix. 

ALS lock conventions:

We have (finally listening to the suggestion that Koji has been making for years now....) set a convention for which side of the PSL the X and Y beatnotes should be, so that we don't have to guess-and-check the gain signs anymore.

For the X beatnote, when you increase the value on the slow slider, the beatnote should increase in frequency.  For the Y beatnote, when you increase the value on the slow slider, the beatnote should decrease in frequency. 

The input matrix (the aux input part) should then have +1 from ALSX->carm, and +1 from ALSY->carm.  It should also have -1 from ALSX->darm and +1 from ALSY->darm. 

The output matrix should be carm -> +1's for both ETMs.  darm should be -1 to ETMX and +1 to ETMY.

With these conventions, both carm and darm should have negative signs for their gains. 

Since we don't have (although should whip up) Watch scripts for the CARM and DARM servo filters, we were using the Xarm filterbank for carm, and the Yarm filterbank for darm again.

Transitioning CARM to 1/sqrt(trans) signals:

As with last night, we were able to easily acquire PRMI lock with a CARM offset of 3 counts.  We then moved down to 2 counts, and saw transmission values of 0.1-0.2.  We set the offsets in the TR_SQRTINV filter banks so that the difference between the outputs was zero, and the mean of the outputs was 2 (the same as the CARM offset we had). 

We looked at the relative gain and sign between the ALS and 1/sqrt() signals, and found that we needed a minus sign, and half the gain.  So, we stepped the 1/sqrt() matrix elements from 0 to -0.5 in steps of 0.1, and at the same time were stepping the ALS matrix elements to CARM from +1 to 0, in steps of 0.2.  This was, excitingly, very easy!

The first time we did this successfully, was a few seconds before 1081143556 gps.

Here is a set of spectra from the first time we locked on the 1/sqrt(trans) signals. 

Failure to transition CARM to RF signals, or reduce CARM offset to zero:

While locked on the 1/sqrt(trans) signals, we looked at several RF signals as options for CARM.  The most promising seems to be REFL55, normalized by (TRX+TRY).  The next most promising looks like REFL11 normalized by POPDC.  Note that these are entirely empirical, and we aren't yet at the resonant point, so these may not be truly the best.  Anyhow, we need to reconfigure the LSC input of the normalized error signals, so that they can go into the CESAR matrices.  This was more than we were prepared to do during the nighttime.  However, it seems like we should be about ready to do the transition, once we have the software in place.  Right now, we either normalize both ALS and the RF signal, or we normalize neither.  We want to be able to apply normalization to only the RF signal. 

Just sitting on the tail of the CARM resonance, there were some random times when we seem to have swung through total resonance, and spoiled our 1/sqrt(trans) signals, which aren't valid at resonance, and so we lost lock.  This implies that auto-transitioning, as CESAR should do, will be helpful. 

Attempt at transitioning DARM to AS55:

Next up, we tried to transition DARM to AS55, after we had CARM on the 1/sqrt signals.  This was unsuccessful.  Part of the reason is that it's unclear what the relative gain should be between the ALS darm signals and AS55, since the transfer function is not flat.  Also, we didn't have much coherence between the ALS signals and AS55Q at low frequencies, below about 100 Hz, which is concerning.  Anyhow, more to investigate and think on here. 

Transitioning CARM to 1/sqrt signals, with a DARM offset:

As a last test, Q put in a DARM offset in the ALS control, rather than a CARM offset, and then was still able to transition CARM control to the 1/sqrt signals.  As we expect, when we're sitting on opposite sides of the arm resonances, the 1/sqrt signals have opposite signs, to make a CARM signal. 

Conclusions / path(s) forward:

We need to redo the LSC RF signal normalization, so that the normalized signals can be inputs to CESAR. 

We need to make sure we set the AS55 phase in a sane way.

We need to think about the non-flat transfer function (the shape was 1/f^n, where n was some number other than 0) between the ALS darm signal and AS55.  The shape was the same for AS55 I&Q, and didn't change when we changed the AS55 phase, so it's not just a phasing problem. 

What DC signals can we use for auto-transitioning between error signals for the big CARM CESAR?

[From yesterday]

The MC had not been stable lately with WFS drifting constantly. I checked the servo and found that the MC_TRANS path was still running. It turned out that the autolocker script enables the TRANS path in the locking process. I have turned the MC_TRANS path servo inputs OFF and now it is no more a part of the WFS servo.

P.S. Jenne fixed the PMC alignment mostly in pitch to bring it up to 0.81 from 0.77. But the temperature fluctuations have still not got us to the sweet spot for optimum PMC trans.

[EricQ, Jenne]

We're still working, but I'm really excited, so here's our news:  We are currently holding the IFO on all IR signals.  No green, no ALS is being used at all!!!!  

PRCL and MICH in REFL33, CARM on 1/sqrt(trans), DARM on AS55 Q.

CARM actuating on MC2, DARM actuating +ETMY, -ETMX. 

CARM offset is 1.9 counts, TRX averages about .1 counts. At this offset, we are able to transition CARM from ALS to DC Transmission signals and DARM from ALS to AS55Q. 

[EricQ, Jenne]

A few more details on our work for the evening, of switching the PRFPMI completely to IR signals (although still with a pretty big CARM offset).

We did the same transition for CARM to 1/sqrt(trans) signals, as last night (elog 9793).  The only difference is that for CARM actuation, we were using a -1*MC in the output matrix, rather than +1's for both ETMs. 

We then had a look at the relative sign and gain between the ALS DARM signals, and AS55Q, using a calibration line in DARM.  Before doing so, we used the DARM line (521.3 Hz, 50 counts) to rotate the AS 55 phase from -60.7 degrees to -97.7 degrees, which gave us about 20dB separation between the I and Q signals.  This informed us that we needed a factor of about 400 less gain for AS55Q than for the ALS darm signal, as well as a minus sign, so I put -400 in the DC normalization place in the LSC for AS55, so that my input matrix would go from ALSY-ALSX (1's) to +1 in AS55Q. 

This transition to AS55 was very easy, and once we did it, we held lock for 5 or 10 minutes, until a large earthquake from Papa New Guinea hit us.  Note however, that we still had a large CARM offset, and our TRX and TRY signals were about 0.1 counts, when we expect several hundred at perfect resonance. 

After that, we relocked, made both CARM and DARM transitions again, and tried to look at a CARM calibration line to see if we see CARM information in any of the REFL RF signals.  We lost lock after a few minutes (so, not related to our calibration line), so we didn't finish, but it looks like REFL55I, normalized by TRX+TRY is the most promising.  Also, REFL55's phase was already very good, while REFL11's phase was not. 

There were some moderate changes to the LSC model that happened, and matching screen changes.  I put in a switch just before the input triggering place of the CARM servo.  This allows us to switch from the "regular" input matrix, and a CESAR signal.  The inputs to the CESAR block are sqrtinv(TRX), sqrtinv(TRY), ALSX, ALSY and the output of the CARM row of the input matrix (so that we can have dynamic normalization of the RF signals).  I have exposed all of these changes in the input matrix screens.

I also modified slightly the ALS watch scripts, to include CARM and DARM servo filter watching, so now we can use the actual CARM and DARM servos.  We should make restore configure scripts for these!

The 2 gps times for when we made the transition from ALS DARM to AS55 DARM were 1081238160 and 1081240217.  We want to go back tomorrow, and extract some nice time series.

Here's a spectrum though, of the difference in noise between DARM on ALS, and DARM on AS55.  The CARM was always on 1/sqrt(Trans) signals during these spectra.  We have an enormous gain in high frequency noise performance once we switch to the RF signal, which is great.

 Phenomenal!!  Well done, guys!

 A few time series from last night's data. 

300 seconds, starting from 1081240100, showing that as we move from ALSY-ALSX to AS55Q, the DARM error signal gets smaller.

The same 300 seconds, showing that the CARM error signal, and the arm transmissions, are not perturbed during this transition.

DARM in and out, for 300 seconds, showing that the control output also gets smaller.

A slightly longer time series, ending at about the same time, but starting a few minutes earlier, showing us (1) adding a 3 count CARM offset, (2) locking the PRMI (3) transitioning CARM to sqrtinv signals, and then (4) transitioning DARM to AS55Q.

CARM and DARM in and outs, for the 500 second time chunk showing all the transitions.  Unfortunately, it looks like CARM_OUT is more noisy when it's on the sqrtinv signals, than it was on the ALS signals.  Part of this may be that we have not yet swapped the resistor in the TRY QPD, to improve the SNR in the same way that we have already done for the TRX QPD.  [EDIT, JCD:  Also, we had hard-triggered the Trans switching, so we were only looking at the QPD sum for the TRX and TRY, and the QPDs only have a few ADC counts at low transmissions, so we had poor SNR for that reason too.]

About the ADC range,

According to the elogs, DARM = AS55Q/400. So in the current level, the error has +/-40cntpp (even if I ignore the whitening).

The arm transmission this time was 0.1-0.3. This will go up to 100~300. So we potentially increase the AS55Q optical gain by factor of 1000.

So we get +/-40000. This is already too much. If we consider the whitening, the situation is more tough.

We need to lower the whitening gain. If it is not enough, we need to lower the power on the PD.

How much was the whitening gain for AS55 this time?

 21 dB. We played with the whitening gain a little bit; at around 30dB with the signal levels at TRX = .1ish, we were consistently saturating the ADC. 

It's just one of the stepping stones, but not yet a mile stone.
Keep going forward!

Arm lengths were measured using ALS

X arm length = 37.79 +/- 0.05 m

Y arm length = 37.81 +/- 0.01 m

Whats and whys

We want to measure the arm length with an accuracy of say a mm.

This would mean a measurement precision of 1e-3/40=25ppm. (1mm in 40m)

So the required measurement resolution on the spectrum analyser is 25ppm*4MHz=100Hz (assuming the cavity FSR is roughly 4MHz). 

Although the spectrum analyser does not limit the measurement precision, we are limited by the noise in ALS at 1000Hz rms. So we can use ALS only to measure arm length precise to the order of a few mm.

RXA: Not that we really need to right now, but even with an ALS noise of 1000 Hz, we can can do better just by averaging at each resonance point. And fitting a line as you have already done gets even better:

http://en.wikipedia.org/wiki/Propagation_of_uncertainty

The Spectrum analyser was reference locked to the rubidium clock @10MHz for these measurements.

The FSRs of the arms

X arm = 3.9671e+06 +/- 4.8535e+03 Hz

Y arm = 3.9648e+06 +/- 1.1064e+03 Hz

Attachments:

1&2. Plots representing the arm scans showing the beat frequency for which IR resonates in the arm vs the ALS offset (position of the ETM).

3. Data and code (zip file)

P.S. We had trouble scanning the arms using ALS. This was because the slow servo was not enabled. Hence ALS was losing its PDH lock everytime we scanned past a couple of FSRs.