40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 212 of 344  Not logged in ELOG logo
IDup Date Author Type Category Subject
  10613   Wed Oct 15 20:10:29 2014 ericqUpdateLSCInterim DARM Signal

I've done some preliminary modeling to see if there is a good candidate for an IR DARM control signal that is available before the AS55 sign flip. From a DC sweep point of view, ASDC/(TRX+TRY) may be a candidate for further exploration. 


As a reminder, both Finesse and MIST predict a sign flip in the AS55 Q control signal for DARM in the PRFPMI configuration, at a CARM offset of around 118pm.

dcAS55_DARM.pdfAS55Flip.pdf

The CARM offset where this sign flip occurs isn't too far off of where we're currently losing lock, so we have not had the opportunity to switch DARM control off of ALS and over to the quieter IR RF signal of AS55. 


Here are simulated DC DARM sweep plots of our current PRFPMI configuration, with a whole bunch of potential signals that struck me. 

Although the units of most traces are arbitrary in each plot (to fit on the same scale), each plot uses the same arbitrary units (if that makes any sense) so slopes and ratios of values can be read off. 

dcDARMSweep-300.pdfdcDARMSweep-120.pdfdcDARMSweep-50.pdfdcDARMSweep-0.pdf

In the 300 and 120pm plot, you can see that the zero crossing of AS55 is at some considerable DARM offset, and normalizing by TRX doesn't change much about that. "Hold on a second," I hear you say. "Your first plots said that the sign flip happens at around 120pm, so why does the AS55 profile still look bad at 50pm?!" My guess is that, probably due to a combination of Schnupp and arm length asymmetry, CARM offsets move where the peak power is in the DARM coordinate. This picture makes what I mean more clear, perhaps:

2dSweep.pdf

Thus, once we're on the other side of the sign flip, I'm confident that we can use AS55 Q without much problem. 


Now, back to thoughts about an interim signal:

ASDC by itself does not really have the kind of behavior we want; but the power out of AS as a fraction of the ARM power (i.e. ASDC/TRX in the plot) seems to have a rational shape, that is not too unlike what the REFLDC CARM profile looks like.

Why not use POPDC or REFLDC? Well, at the CARM offsets we're currently at, POPDC is dominated by the PRC resonating sidebands, and REFLDC has barely begun to decline, and at lower CARM offsets, they each flatten out before the peak of the little ASDC hill, and so don't do much to improve the shape. Meanwhile, ASDC/TRX has a smooth response to points within some fraction of the DARM line width in all of the plots. 

Thus, as was discussed at today's meeting, I feel it may be possible to lock DARM on ASDC/(TRX+TRY) with some offset, until AS55 becomes feasible.

(In practice, I figure we would divide by the sum of the powers, to reduce the influence of the DARM component of just TRX; we don't want to have DARM/DARM in the error signal for DARM)

Two caveats are:

  • The slope of this signal actually looks more quadratic than linear. Is this ok/manageable?
  • I have not yet made any investigation into the frequency dependent behavior of this thing. Transmission in the denominator will have the CARM pole in it, might get complicated. 

[Code and plots live in /svn/trunk/modeling/PRFPMI_radpressure]

 

  10614   Wed Oct 15 22:39:17 2014 JenneUpdateLSCThe Plan

 [Rana, Jenne]

We're summarizing the discussions of the last few days as to the game plan for locking.  

  1. PRMI on REFL165.  The factor of 5 in frequency will give us more MICH signal.    We want this.
    1. Drive CARM, measure coupling to PRCL, MICH while locked on REFL33.
    2. Switch to REFL165, re-measure CARM coupling.
    3. Hopefully this will reduce the AS port fluctuations, and reduce the POP22 power decrease as CARM offset decreases. 
  2. DARM transition from ALSdiff to an intermediate signal.  Simulate, and try empirically.
    1. Maybe try ASDC normalized by sum of transmissions?
    2. Maybe try difference of transmissions divided by sum of transmissions?  
  3. Look at data on disk.
    1. Do we have anything specific causing our locklosses (lately there haven't been obvious loop instabilities causing the locklosses)?
    2. How much do we think our lengths are actually changing right now (particularly DARM on ALSdiff)?
    3. Are there better ways of combining error signals that could be useful?
    4. Do we need to work on angular loops?
      1. Oplevs
      2. POP ASC for sidebands
      3. POP QPD or Trans QPDs for arms
  4.  Think about what could be causing ETMX to be annoying.  The connection that is most suspect has been ziptied, but we're still seeing ETMX move either at locklosses or sometimes just spontaneously.
  5.  RAM.  What kind of RAM levels do we have right now, and how do they affect our locking offsets?  Do we have big offsets, or negligible offsets?
  10615   Thu Oct 16 03:13:23 2014 JenneUpdateLSCPRMI on REFL165, and more

 The first thing I looked at tonight was locking the PRMI on REFL 165.

I locked the PRMI (no arms), and checked the REFL 165 demod phase. I also found the input matrix configuration that allowed me to acquire PRMI lock directly on REFL165.  After locking the arms on ALS, I tried to lock the PRMI with REFL 165 and failed.  So, I rechecked the demod phase and the relative transfer functions between REFL 165 and REFL 33.  The end of the story is that, even with the re-tuned demod phase for CARM offset of a few nanometers, I cannot acquire PRMI lock on REFL 165, nor can I transition from REFL 33 to REFL 165.  We need to revisit this tomorrow.

IFO configuration CARM offset [cts] REFL 165 demod phase [deg]
Found as-is N/A +145
PRMI, no arms N/A -135
PRFPMI +3 +110
PRFPMI +2 +110
PRFPMI +1 +110
PRFPMI +0.5 +120

 

IFO configuration REFL 33 I / REFL 165 I (PRCL) REFL 33 Q / REFL 165 Q (MICH)
PRMI, no arms +0.1 +0.22, although easier to acquire lock with +0.1
PRFPMI, CARM offset = +3 -0.09  (TF measured, no lock) +0.033  (TF measured, no lock)

For the PRMI-only case, I ended up using 0.1's in the input matrix, and I added an FM 1 to the MICH filter bank that is a flat gain of 2.2, and then I had it trigger along with FM2.

I turned this FM1 off (and no triggering) while trying to transition from REFL33 to REFL165 in the PRFPMI case, but that didn't help.  I think that maybe I need to remeasure my transfer functions or something, because I could put values into the REFL165 columns of the input matrix while REFL33 was still 1's, but I couldn't remove (even if done slowly) the REFL33 matrix elements without losing lock of the PRMI.  So, we need to get the input matrix elements correct.


I also recorded some time series for a quick RAM investigation that I will work on tomorrow.  

I left the PRM aligned, but significantly misaligned both ITMs to get data at the REFL port of the RAM that we see.  I also aligned the PRMI (no arms) and let it flash so that I can see the pk-pk size of our PDH signals.  I need to remember to calibrate these from counts to meters.  

Raw data is in /users/jenne/RAM/ .


I have not tried any new DARM signals, since PRMI wasn't working with 3f2.  

We should get to that as soon as we fix the PRMI-3f2 situation.

  10616   Thu Oct 16 03:18:48 2014 JenneUpdateCDSDaqd segfaulting again

 The daqd process on the frame builder looks like it is segfaulting again.  It restarts itself every few minutes.  

The symptoms remind me of elog 9530, but /frames is only 93% full, so the cause must be different.  

Did anyone do anything to the fb today?  If you did, please post an elog to help point us in a direction for diagnostics.

Q!!!!  Can you please help?  I looked at the log files, but they are kind of mysterious to me - I can't really tell the difference between a current (bad) log file and an old (presumably fine) log file.  (I looked at 3 or 4 random, old log files, and they're all different in some ways, so I don't know which errors and warnings are real, and which are to be ignored).

  10617   Thu Oct 16 12:22:43 2014 ericqUpdateCDSDaqd segfaulting again

I've been trying to figure out why daqd keeps crashing, but nothing is fixed yet. 

I commented out the line in /etc/inittab that runs daqd automatically, so I could run it manually. Each time I run it ( with ./daqd -c ./daqdrc while in c1/target/fb), it churns along fine for a little while, but eventually spits out something like:

[Thu Oct 16 12:07:23 2014] main profiler warning: 1 empty blocks in the buffer
[Thu Oct 16 12:07:24 2014] main profiler warning: 0 empty blocks in the buffer
[Thu Oct 16 12:07:25 2014] main profiler warning: 0 empty blocks in the buffer
GPS time jumped from 1097521658 to 1097521660
Segmentation fault
 
Or:
 
[Thu Oct 16 11:43:54 2014] main profiler warning: 1 empty blocks in the buffer
[Thu Oct 16 11:43:55 2014] main profiler warning: 0 empty blocks in the buffer
[Thu Oct 16 11:43:56 2014] main profiler warning: 0 empty blocks in the buffer
[Thu Oct 16 11:43:57 2014] main profiler warning: 0 empty blocks in the buffer
[Thu Oct 16 11:43:58 2014] main profiler warning: 0 empty blocks in the buffer
[Thu Oct 16 11:43:59 2014] main profiler warning: 0 empty blocks in the buffer
[Thu Oct 16 11:44:00 2014] main profiler warning: 0 empty blocks in the buffer
[Thu Oct 16 11:44:01 2014] main profiler warning: 0 empty blocks in the buffer
[Thu Oct 16 11:44:02 2014] main profiler warning: 0 empty blocks in the buffer
GPS time jumped from 1097520250 to 1097520257
FATAL: exception not rethrown
Aborted

I looked for time disagreements between the FB and the frontends, but they all seem fine. Running ntpdate only corrected things by 5ms. However, looking through /var/log/messages on FB, I found that ntp claims to have corrected the FB's time by ~111600 seconds (~31 hours) when I rebooted it on Monday.

Maybe this has something to do with the timing that the FB is getting? The FE IOPs seem happy with their sync status, but I'm not personally currently aware of how the FB timing is set up. 


Addendum:

On Monday, Jamie suggested checking out the situation with FB's RAID. Searching the elog for "empty blocks in the buffer" also brought up posts that mentioned problems with the RAID. 

I went to the JetStor RAID web interface at http://192.168.113.119, and it reports everything as healthy; no major errors in the log. Looking at the SMART status of a few of the drives shows nothing out of the ordinary. The RAID is not mounted in read-only mode either, as was the problem mentioned in previous elogs. 

  10618   Thu Oct 16 16:21:42 2014 ericqUpdateLSCInterim DARM Signal

I've added (TRX-TRY)/(TRX+TRY) to the DC DARM sweep plots, and it looks like an even better candidate. The slope is closer to linear, and it has a zero crossing within ~10pm of the true DARM zero across the different CARM offsets, so we might not even need to use an intentional DARM offset. 

dcDARMSweep-300.pdfdcDARMSweep-120.pdfdcDARMSweep-50.pdfdcDARMSweep-0.pdf

 

  10619   Thu Oct 16 21:20:59 2014 ranaUpdateLSCmisleading modelling

 I think these are all very helpful and interesting plots. We should see some better performance using either of the DC DARM signals.

BUT, what we really need (instead of just the DC sweeps) is the DC sweep with the uncertainty/noise displayed as a shaded area on the plot, as Nic did for us in the pre-CESAR modelling.

Otherwise, the DC sweeps mistakenly indicate that many channels are good, whereas they really have an RMS noise larger than 100 pm due to low power levels or normalization by a noisy signal.

  10620   Thu Oct 16 22:35:05 2014 ranaUpdateLSCCARM W/N TFs

In my last CARM loop modelling, all of the plots are phony, so don't trust them. The invbilinear function inside of StefanB's onlinefilter.m was making bogus s-domain representations of the digital filter coefficients.

So now I've just plotted the frequency response directly from the z-domain SOS coeffs using MattE's readFilterFile.m and FotonFilter.m.

Conclusions are less rosy. The anti-spring side is still easier to compensate than the spring side, but it starts to get hopeless below ~130 pm of offset, so there we really need to try to get to REFL_11/(TRX+TRY), pending some noise analysis.

** In order to get the 80 and 40 pm loops to be more stable I've put in a tweak filter called Boost2 (FM8). As you can see, it kind of helps for 80 pm, but its pretty hopeless after that.

Attachment 1: carm_spring.pdf
carm_spring.pdf
Attachment 2: carm_antispring.pdf
carm_antispring.pdf
  10621   Fri Oct 17 03:05:00 2014 ericqUpdateLSCDARM locked on DC Transmission difference

 I've been able to repeatedly get off of ALS and onto (TRY-TRX)/(TRY+TRX). Nevertheless, lock is lost between arm powers of 10 and 20. 

I do the transition at the same place as the CARM->SqrtInv transition, i.e. arm powers about 1.0 Jenne started a script for the transition, and I've modified it with settings that I found to work, and integrated it into the carm_cm_up script. I've also modified carm_cm_down to zero the DARM normalization elements. 

I was thwarted repeatedly by the frequent crashing of daqd, so I was not able to take OLTFs of CARM or DARM, which would've been nice. As it was, I tuned the DARM gain by looking for gain peaking in the error signal spectrum. I also couldn't really get a good look at the lock loss events. Once the FB is behaving properly, we can learn more. 

Turning over to difference in transmission as an error signal naturally squashes the difference in arm transmissions:

TRdifflock.png


I was able to grab spectra of the error and control signals, though I did not take the time to calibrate them... We can see the high frequency sensing noise for the transmission derived signals fall as the arm power increases. The low frequency mirror motion stays about the same. 

Oct17lock.pdf


So, it seems that DARM was not the main culprit in breaking lock, but it is still gratifying to get off of ALS completely, given its out-of-loop-noise's strong dependence on PSL-alignment. 

  10622   Fri Oct 17 13:19:48 2014 JenneUpdateLSCPOP22 ?!?!

We've seen this before, but we need to figure out why POP22 decreases with decreased CARM offset.  If it's just a demod phase issue, we can perhaps track this by changing the demod phase as we go, but if we are actually losing control of the PRMI, that is something that we need to look into.

In other news, nice work Q!

Quote:

TRdifflock.png

 

  10623   Fri Oct 17 15:17:31 2014 jamieUpdateCDSDaqd "fixed"?

I very tentatively declare that this particular daqd crapfest is "resolved" after Jenne rebooted fb and daqd has been running for about 40 minutes now without crapping itself.  Wee hoo.

I spent a while yesterday trying to figure out what could have been going on.  I couldn't find anything.  I found an elog that said a previous daqd crapfest was finally only resolved by rebooting fb after a similar situation, i.e. there had been an issue that was resolved, daqd was still crapping itself, we couldn't figure out why so we just rebooted, daqd started working again.

So, in summary, totally unclear what the issue was, or why a reboot solved it, but there you go.

  10624   Fri Oct 17 16:54:11 2014 jamieUpdateCDSDaqd "fixed"?

Quote:

I very tentatively declare that this particular daqd crapfest is "resolved" after Jenne rebooted fb and daqd has been running for about 40 minutes now without crapping itself.  Wee hoo.

I spent a while yesterday trying to figure out what could have been going on.  I couldn't find anything.  I found an elog that said a previous daqd crapfest was finally only resolved by rebooting fb after a similar situation, i.e. there had been an issue that was resolved, daqd was still crapping itself, we couldn't figure out why so we just rebooted, daqd started working again.

So, in summary, totally unclear what the issue was, or why a reboot solved it, but there you go.

Looks like I spoke too soon.  daqd seems to be crapping itself again:

controls@fb /opt/rtcds/caltech/c1/target/fb 0$ ls -ltr logs/old/ | tail -n 20
-rw-r--r-- 1 4294967294 4294967294    11244 Oct 17 11:34 daqd.log.1413570846
-rw-r--r-- 1 4294967294 4294967294    11086 Oct 17 11:36 daqd.log.1413570988
-rw-r--r-- 1 4294967294 4294967294    11244 Oct 17 11:38 daqd.log.1413571087
-rw-r--r-- 1 4294967294 4294967294    13377 Oct 17 11:43 daqd.log.1413571386
-rw-r--r-- 1 4294967294 4294967294    11481 Oct 17 11:45 daqd.log.1413571519
-rw-r--r-- 1 4294967294 4294967294    11985 Oct 17 11:47 daqd.log.1413571655
-rw-r--r-- 1 4294967294 4294967294    13219 Oct 17 13:00 daqd.log.1413576037
-rw-r--r-- 1 4294967294 4294967294    11150 Oct 17 14:00 daqd.log.1413579614
-rw-r--r-- 1 4294967294 4294967294     5127 Oct 17 14:07 daqd.log.1413580231
-rw-r--r-- 1 4294967294 4294967294    11165 Oct 17 14:13 daqd.log.1413580397
-rw-r--r-- 1 4294967294 4294967294     5440 Oct 17 14:20 daqd.log.1413580845
-rw-r--r-- 1 4294967294 4294967294    11352 Oct 17 14:25 daqd.log.1413581103
-rw-r--r-- 1 4294967294 4294967294    11359 Oct 17 14:28 daqd.log.1413581311
-rw-r--r-- 1 4294967294 4294967294    11195 Oct 17 14:31 daqd.log.1413581470
-rw-r--r-- 1 4294967294 4294967294    10852 Oct 17 15:45 daqd.log.1413585932
-rw-r--r-- 1 4294967294 4294967294    12696 Oct 17 16:00 daqd.log.1413586831
-rw-r--r-- 1 4294967294 4294967294    11086 Oct 17 16:02 daqd.log.1413586924
-rw-r--r-- 1 4294967294 4294967294    11165 Oct 17 16:05 daqd.log.1413587101
-rw-r--r-- 1 4294967294 4294967294    11086 Oct 17 16:21 daqd.log.1413588108
-rw-r--r-- 1 4294967294 4294967294    11097 Oct 17 16:25 daqd.log.1413588301
controls@fb /opt/rtcds/caltech/c1/target/fb 0$

The times all indicate when the daqd log was rotated, which happens everytime the process restarts.  It doesn't seem to be happening so consistently, though.  It's been 30 minutes since the last one.  I wonder if it somehow correlated with actual interaction with the NDS process.  Does some sort of data request cause it to crash?

 

  10625   Fri Oct 17 17:52:55 2014 JenneUpdateLSCRAM offsets

Last night I measured our RAM offsets and looked at how those affect the PRMI situation.  It seems like the RAM is not creating significant offsets that we need to worry about.


Words here about data gathering, calibration and calculations.

Step 1:  Lock PRMI on sideband, drive PRM at 675.13Hz with 100 counts (675Hz notches on in both MICH and PRCL).  Find peak heights for I-phases in DTT to get calibration number.

Step 2:  Same lock, drive ITMs differentially at 675.13Hz with 2,000 counts.  find peak heights for Q-phases in DTT to get calibration number.

Step 3:  Look up actuator calibrations.  PRM = 19.6e-9/f^2 meters/count and ITMs = 4.68e-9/f^2 meters/count.  So, I was driving PRM about 4pm, and the ITMs about 20pm.

Step 4:  Unlock PRMI, allow flashes, collect time series data of REFL RF siganls.

Step 5: Significantly misalign ITMs, collect RAM offset time series data.

Step 6: Close PSL shutter, collect dark offset time series data.

Step 7: Apply calibration to each PD time series.  For each I-phase of PDs, calibration is (PRM actuator / peak height from step 1).  For each Q-phase of PDs, calibration is (ITM actuator / peak height from step 2).

Step 8:  Look at DC difference between RAM offset and dark offset of each PD.  This is the first 4 rows of data in the summary table below.

Step 9:  Look at what peak-to-peak values of signals mean.  For PRCL, I used the largest pk-pk values in the plots below.  For MICH I used a calculation of what a half of a fringe is - bright to dark.  (Whole fringe distance) = (lambda/2), so I estimate that a half fringe is (lambda/4), which is 266nm for IR.  This is the next 4 rows of data in the table.

Step 10: Divide.  This ratio (RAM offset / pk-pk value) is my estimate of how important the RAM offset is to each length degree of freedom. 


Summary table:

  PRCL (I-phase) MICH (Q-phase)
RAM offsets    
11 4e-11 m 2.1e-9 m
33 1.5e-11 m ~2e-9 m
55 2.2e-11 m ~1e-9 m
165 ~1e-11 m ~1e-9 m
Pk-pk (PDH or fringes) PDH pk-pk from flashes MICH fringes from calculation
11 5.5e-9 m 266e-9 m
33 6.9e-9 m 266e-9 m
55 2.5e-9 m 266e-9 m
165 5.8e-9 m 266e-9 m
Ratio: (RAM offset) / (pk-pk)    
11 7e-3 8e-4
33 2e-3 7e-3
55 9e-3 4e-3
165 2e-3 4e-3

 


Plots (Left side is several PRMI flashes, right side is a zoom to see the RAM offset more clearly):

RAM_PRMI_PRMIflashing_REFL11I.pdfRAM_PRMI_Zoom_REFL11I.pdf

RAM_PRMI_PRMIflashing_REFL11Q.pdfRAM_PRMI_Zoom_REFL11Q.pdf

RAM_PRMI_PRMIflashing_REFL33I.pdfRAM_PRMI_Zoom_REFL33I.pdf

RAM_PRMI_PRMIflashing_REFL33Q.pdfRAM_PRMI_Zoom_REFL33Q.pdf

RAM_PRMI_PRMIflashing_REFL55I.pdfRAM_PRMI_Zoom_REFL55I.pdf

RAM_PRMI_PRMIflashing_REFL55Q.pdfRAM_PRMI_Zoom_REFL55Q.pdf

RAM_PRMI_PRMIflashing_REFL165I.pdfRAM_PRMI_Zoom_REFL165I.pdf

RAM_PRMI_PRMIflashing_REFL165Q.pdfRAM_PRMI_Zoom_REFL165Q.pdf

  10626   Mon Oct 20 17:50:30 2014 JenneUpdateLSCCARM W/N TFs (Others were all wrong!)

I realized today that I had been plotting the wrong thing for all of my transfer functions for the last few weeks! 

The "CARM offsets" were correct, in that I was moving both ETMs, so all of the calculations were correct (which is good, since those took forever). But, in the plots I was just plotting the transfer function between driving ETMX and the given photodiode.  But, since just driving a single ETM is an admixture of CARM and DARM, the plots don't make any sense.  Ooops.

In these revised plots (and the .mat file attached to this elog), for each PD I extract from sigAC the transfer function between driving ETMX and the photodiode.  I also extract the TF between driving ETMY and the PD.  I then  sum those two transfer functions and divide by 2.  I multiply by the simple pendulum, which is my actuator transfer function to get to W/N, and plot.

The antispring plots don't change in shape, but the spring side plots do.  I think that this means that Rana's plots from last week are still true, so we can use the antispring side of TRX to get down to about 100 pm.

Here are the revised plots:

TFs_TRX_vsCARMoffset_PRFPMI_antispring.pngTFs_TRX_vsCARMoffset_PRFPMI_spring.png

TFs_REFLDC_vsCARMoffset_PRFPMI_antispring.pngTFs_REFLDC_vsCARMoffset_PRFPMI_spring.png

TFs_REFL11I_vsCARMoffset_PRFPMI_antispring.pngTFs_REFL11I_vsCARMoffset_PRFPMI_spring.png

Attachment 1: PDs_vsCARMoffset_20Oct2014.mat.zip
  10627   Tue Oct 21 00:38:40 2014 ericqUpdateLSCsweep + RMS as uncertainty

Quote:

BUT, what we really need (instead of just the DC sweeps) is the DC sweep with the uncertainty/noise displayed as a shaded area on the plot, as Nic did for us in the pre-CESAR modelling.

I've taken a first stab at this. Through various means, I've made an estimation of the total noise RMS of each error signal, and plotted a shaded region that shows the range of values the error signal is likely to take, when the IFO is statically sitting at one CARM offset. 

I have not included any effects that would change the RMS of these signals in a CARM-offset dependent way. Since this is just a rough first pass, I didn't want to get carried away just yet. 


For the transmission PDs, I measured the RMS on single arm lock. I also measured the incident power on the QPDs and thorlabs PDs for an estimate of shot noise, but this was ridiculously smaller than the in-loop RIN. I had originally though of just plotting sensing noise for the traces (i.e. dark+shot), because the amount of seismic and frequency noise in the in-loop signal obviously depends on the loop, but this gives a very misleading, tiny value. In reality we have RIN from the PRC due to seismic noise, angular motion of the optics, etc., which I have not quantified at this time. 

So: for this first, rough, pass, I am simply multiplying the single transmission noise RMSs by a factor of 10 for the coupled RMS. If nothing else, this makes the SqrtInv signal look plausible when we actually practically find it to be plausible. 


For the REFL PDs, I misaligned the ITMs for a prompt PRM reflection for a worst-case shot noise situation, and took the RMS of the spectra. (Also wrote down the dark RMSs, which are about a factor of 2 lower). I then also multiplied these by ten, to be consistent with the transmission PDs. In reality, the shot noise component will go down as we approach zero CARM offset, but if other effects dominate, that won't matter. 


Enough blathering, here's the plot:

dcCARMSweep_uncertainties.png

Now, in addition to the region of linearity/validity of the different signals, we can hopefully see the amount of error relative to the desired CARM offset. (Or, at least, how that error qualitatively changes over the range of offsets)


This suggests that we MAY be able to hop over to a normalized RF signal; but this is a pretty big maybe. This signal has the response of the quotient of two nontrivial optical plants, which I have not yet given much thought to; it is probably the right time to do so...

  10628   Tue Oct 21 17:44:28 2014 jamieOmnistructureComputer Scripts / Programsnew version of cdsutils (351) installed

I just installed cdsutils r351 at /ligo/apps/linux-x86_64/cdsutils.  It should be available on all workstations.

It includes a bunch of bug fixes and feature improvements, including the step stuff that Rana was complaining about.

  10629   Tue Oct 21 18:40:46 2014 manasaUpdateGeneralEnd laser fiber setup

 [Manasa, Diego]

This is our first time touching tables for Frequency Offset Locking. 

The goal was to couple the 1064nm that leaks after the SHG crystal and couple it into the fiber before we run it along the length of the arm. 

The fiber has been mounted at the end but there is no light coupled into the fiber as yet.

In the process, the following were done:

1. ETMY oplev servo disabled. This was enabled after the work.
2. NPRO laser power was reduced so that nothing gets burnt accidently while putting things on the table. This was also reset after the work.

The arms could be locked to green and IR after the work. So I am hoping today's work will not affect locking.

  10630   Wed Oct 22 02:35:45 2014 JenneUpdateLSCEfforts at hopping PRMI to REFL165

[EricQ, Jenne]

The first half of our evening was spent working on CARM and DARM in PRFPMI, and then we moved on to the PRMI part.

I moved the DARM ALSdiff -> TransDiff transition to be after the CARM ALScomm -> SqrtInvTrans transition in the carm_cm_up script.  After I did that, I succeeded every time (at least  10?  We did it many times) to get both CARM and DARM off of the ALS signals. 

We tried for a little while looking at transitioning to REFL11 normalized by the sum of the transmissions, but we kept losing lock.  We also several times lost lock at arm powers of a few, when we thought we weren't touching the IFO for any transitions.  Looking at the lockloss time series did not show any obvious oscillations in any of the _IN1 or _OUT channels for the length degrees of freedom, so we don't know why we lost lock, but it doesn't seem to be loop oscillations caused by changing optical gain.  Also, one time, I tried engaging Rana's "Lead 350" filter in FM7 of the CARM filter bank when we were on sqrtInvTrans for CARM, and the arm powers were around a few, but that caused the transmission signals to start to oscillate, and after one or two seconds we lost lock.  We haven't tried the phase lead filter again, nor have we tried the Boost2 that is in FM8. 

We increased the REFL11 analog gain from 0dB to 12dB, and then reset the dark offsets, but still weren't able to move CARM to normalized REFL11. Also, I changed the POP22 demod phase from 159 degrees to 139 degrees. This seems to be where the signal is maximized in the I-phase, while the arms are held off resonance, and also partway up the resonance peak. 

We then decided that we should go back to the PRMI situation before trying to reduce the CARM offset further.  We can robustly and quickly lock the PRMI on REFL33 while the arms are held off resonance with ALS.  So, we have been trying to acquire on  REFL33 I&Q, and then look at switching to REFL 165 I&Q.  It seems pretty easy to get PRCL over to REFL165 I (while leaving MICH on REFL33 I).  For REFL33, both matrix elements are +1.  For PRCL on REFL165, the matrix element is -0.08.  We have not successfully gotten MICH over to REFL 165 ever this evening. 

We went back and set the REFL165 I&Q offsets so that the outputs after the demod phase were both fluctuating around 0.  I don't know if they were around +/-100 because our dark offsets were bad or what, but we thought this would help.  We were still able to get PRCL transitioned no problem, but even after remeasuring the MICH REFL33 vs. REFL165 relative gains, we still can't transition MICH.  It seems like it's failing when the REFL33Q matrix element finally gets zeroed out, so we're not really getting enough signal in REFL165Q, or something like that, and throughout the rest of the transition we were depending entirely on REFL33Q. 

So. Plan:

  • Get PRMI on REFL165 while arms are held off resonance. 
    • May require PRCL-MICH FF decoupling, by combining error signals?
    • May require looking back at simulations to see what we expect the relative gains and signs to be.
  • Look at CARM loop stability in simulation for REFLDC, REFL11, and normalized REFL11.  Is there a stable loop path from about 100pm down to 0pm on normalized REFL11?
  10631   Wed Oct 22 06:32:29 2014 ranaUpdateLSCsweep + RMS as uncertainty

 

 This is looking very useful. It will be useful if you can upload some python code somewhere so that I can muck with it.

I would guess that the right way to determine the trans RMS is just to use the single arm lock RIN and then apply that as RIN (not pure TR RMS) to the TR signals before doing the sqrt operation.

  10632   Wed Oct 22 21:06:33 2014 ChrisUpdateDAQ40m frames onto the cluster

Quote:

 Dan Kozak is rsync transferring /frames from NODUS over to the LDAS grid. He's doing this without a BW limit, but even so its going to take a couple weeks. If nodus seems pokey or the net connection to the outside world is too tight, then please let me and him know so that he can throttle the pipe a little.

The recently observed daqd flakiness looks related to this transfer. It appears to still be ongoing:

nodus:~>ps -ef | grep rsync
controls 29089   382  5 13:39:20 pts/1   13:55 rsync -a --inplace --delete --exclude lost+found --exclude .*.gwf /frames/trend
controls 29100   382  2 13:39:43 pts/1    9:15 rsync -a --delete --exclude lost+found --exclude .*.gwf /frames/full/10975 131.
controls 29109   382  3 13:39:43 pts/1    9:10 rsync -a --delete --exclude lost+found --exclude .*.gwf /frames/full/10978 131.
controls 29103   382  3 13:39:43 pts/1    9:14 rsync -a --delete --exclude lost+found --exclude .*.gwf /frames/full/10976 131.
controls 29112   382  3 13:39:43 pts/1    9:18 rsync -a --delete --exclude lost+found --exclude .*.gwf /frames/full/10979 131.
controls 29099   382  2 13:39:43 pts/1    9:14 rsync -a --delete --exclude lost+found --exclude .*.gwf /frames/full/10974 131.
controls 29106   382  3 13:39:43 pts/1    9:13 rsync -a --delete --exclude lost+found --exclude .*.gwf /frames/full/10977 131.
controls 29620 29603  0 20:40:48 pts/3    0:00 grep rsync

Diagnosing the problem:

I logged into fb and ran "top". It said that fb was waiting for disk I/O ~60% of the time (according to the "%wa" number in the header). There were 8 nfsd (network file server) processes running with several of them listed in status "D" (waiting for disk). The daqd logs were ending with errors like the following suggesting that it couldn't keep up with the flow of data:

[Wed Oct 22 18:58:35 2014] main profiler warning: 1 empty blocks in the buffer
[Wed Oct 22 18:58:36 2014] main profiler warning: 0 empty blocks in the buffer
GPS time jumped from 1098064730 to 1098064731

This all pointed to the possibility that the file transfer load was too heavy.

Reducing the load:

The following configuration changes were applied on fb.

Edited /etc/conf.d/nfs to reduce the number of nfsd processes from 8 to 1:

OPTS_RPC_NFSD="1"

(was "8")

Ran "ionice" to raise the priority of the framebuilder process (daqd):

controls@fb /opt/rtcds/rtscore/trunk/src/daqd 0$ sudo ionice -c 1 -p 10964

And to reduce the priority of the nfsd process:

controls@fb /opt/rtcds/rtscore/trunk/src/daqd 0$ sudo ionice -c 2 -p 11198

I also tried punishing nfsd with an even lower priority ("-c 3"), but that was causing the workstations to lag noticeably.

After these changes the %wa value went from ~60% to ~20%, and daqd seems to die less often, but some further throttling may still be in order.

  10633   Thu Oct 23 01:39:34 2014 JenneUpdateCDSDaqd "fixed"?

Merging of threads. 

ChrisW figured out that it looks like the problem with the frame builder is that it's having to wait for disk access.  He has tweaked some things, and life has been soooo much better for Q and I this evening!  See Chris' elog at elog 10632.

In the last few hours we've had 2 or maybe 3 times that I've had to reconnect Dataviewer to the framebuilder, which is a significant improvement over having to do it every few minutes.

Also, Rossa is having trouble with DTT today, starting sometime around dinnertime.  Ottavia and Pianosa can do DTT things, but Rossa keeps getting "test timed out". 

  10634   Thu Oct 23 02:08:40 2014 JenneUpdateLSCIncreased DARM gain

I changed the carm_cm_up.sh script so that it requires fewer human interventions.  Rather than stopping and asking for things like "Press enter to confirm PRMI is locked", it checks for itself.  The sequence that we have in the up script works very reliably, so we don't need to babysit the first several steps anymore. 

Another innovation tonight that Q helped put in was servoing the CARM offset to get a certain arm power.  A failing of the script had been that depending on what the arm power was during transition over to sqrtInvTrans, the arm power was always different even if the digital offset value was the same.  So, now the script will servo (slowly!!) the offset such that the arm power goes to a preset value.

The biggest real IFO progress tonight was that I was able to actually measure the CARM and DARM loops (thanks ChrisW!), and so I discovered that even though we are using (TRX-TRY)/(TRX+TRY) for our IR DARM error signal, we needed to increase the digital gain for DARM as the CARM offset was reduced.  For ALS lock and DC trans diff up to arm powers of 3, we use the same ol' gain of 6.  However, between 3 - 6, we need a gain of 7.  Then, when we go to arm powers above 6 we need a gain of 7.5.  I was also measuring the CARM loop at each of these arm powers (4, 6, 7, 8, 9), but the gain of 4 that we use for sqrtInvTrans was still fine. 

So, the carm_cm_up script will do everything that it used to without any help (unless it fails to find IR resonance for ALS, or can't lock the PRMI, in which case it will ask for help), and then once it gets to these servo lines to slowly increase the arm power and increase the DARM gain, it will ask you to confirm before each step is taken.  The script should get you all the way to arm powers of 9, which is pretty much exactly 100pm according to Q's Mist plot that is posted.

The CARM and DARM loops (around the UGFs) don't seem to be appreciably changing shape as I increase the arm powers up to 9 (as long as I increase the DARM loop gain appropriately).  So, we may be able to go a little bit farther, but since we're at about 100pm, it might be time to look at whether we think REFL11 or REFLDC is going to be more promising in terms of loop stability for the rest of the way to resonance.


Here are some plots from this evening. 

First, the time I was able to get to and hold at arm powers of 9.  I have a striptool to show the long time trends, and then zooms of the lockloss.  I do not see any particular oscillations or anything that strikes me as the cause for the lockloss.  If anyone sees something, that would be helpful.

ArmPowers9_1am_22Oct2014.png

Lockloss_ArmsAt9_1am_22Oct2014.png

LocklossZoom_ArmsAt9_1am_22Oct2014.png

This next lockloss was interesting because the DARM started oscillating as soon as the normalization matrix elements were turned on for DARM on DC transmissions.  The script should be measuring values and putting in matrix elements that don't change the gain when they are turned on, but perhaps something didn't work as expected.  Anyhow, the arm powers were only 1ish at the time of lockloss.  There was some kind of glitch in the DARM_OUT (see 2nd plot below, and zoom in 3rd plot), but it doesn't seem to have caused the lockloss.

Lockloss_ArmsAt1ish_TransOscillation_110am_22Oct2014.png

LocklossZoom_ArmsAt1ish_TransOscillation_110am_22Oct2014.png

LocklossZoomGlitch_ArmsAt1ish_TransOscillation_110am_22Oct2014.png

  10635   Thu Oct 23 13:08:55 2014 ericqUpdateGeneralGap in local Chiara backups

After the second of the two recent power outages, the outlet powering Chiara's external drive for local backups didn't come back. The modification to the backup script I made correctly identified that the drive wasn't mounted, and happily logged its absence and didn't try to stuff the internal drive with a copy of itself. However, I hadn't checked the logs to see if the backups were proceeding until today... maybe I should set up an email alert for these, too. 

I plugged the external drive into a live outlet, and mounted the 40mBackup drive with: sudo udisks --mount /dev/sdc1, which is a helpful command that puts the drive at /media/40mBackup as it should be, based on the drive label. 

The /cvs/cds backup is now proceeding, to make up for lost time. 

  10636   Thu Oct 23 17:45:54 2014 JenneUpdateGeneralPianosa frozen

Not sure why, but Pianosa was frozen.  Also couldn't ssh or ping.  So, I hard power cycled it.

  10637   Fri Oct 24 02:14:05 2014 JenneUpdateLSCIncreased DARM gain even more

[Jenne, Diego]

We spent the afternoon working on the new scan for IR resonance script.  It is getting much closer, although we need to work on a plan for the fine scanning at the end - so far, the result from the wavelet thing mis-estimates the true peak phase, and so if we jump to where it recommends, we are only at about half of the arm resonance.  So, in progress, but moving forward.

Tonight we repeated the process of reducing the CARM offset and measuring the DARM loop gain as we went.  I'm not sure if I just had the wrong numbers yesterday, or if the gains are changing day-by-day.  The gains that it wanted at given arm buildups were constant throughout this evening, but they are about a factor of 2 higher than yesterday.  If they really do change, we may need to implement a UGF servo for DARM.  New gains are in the carm_cm_up script.

We also actually saved our DARM loop measurements as a function of CARM offset (as indicated by arm buildups).  The loop stays the same through arm powers of 4.  However, once we get to arm powers of 6, the magnitude around 100 Hz starts to flatten out, and we get some weird features in the phase.  It's almost like the phase bubble has a peak growing out of it.  I saw these yesterday, and they just keep getting more pronounced as we go up to arm powers of 7, 8 and 9 (where we lost lock during the measurement).  The very last point in the power=9 trace was just before/during the lockloss, so I don't know if we trust it, or if it is real and telling us something important.  But, I think that it's time to see about getting both CARM and DARM onto a different set of error signals now that we're at about 100pm.

 DARM_23Oct2014.pdf

  10638   Fri Oct 24 10:08:24 2014 manasaUpdateGeneralY AUX laser - fiber coupled

The Y end aux laser light leaking after the doubling crystal has been coupled into the 70m long PM fiber. 

Input power = 250mW;  Output after 70m = 20mW

The poor efficiency is partially due to the ellipticity of the beam itself and partially due to the compromise I had to make using a single lens to couple the light into the fiber (given the limitations in space). But 20mW should be more than sufficient for a beat note setup.

Light propagates as follows after the doubling crystal:

Doubler ---> Harmonic Separator (45deg) ---> Lens (f=12.5cm) --> Steering mirror (Y1) --> Fiber collimator ( Thor labs CFC-2X-C) --> FIber end

I will update photos of the setup shortly.

I have left the 70m fiber in its spool sitting at the Y end and blocked the light before the last Y1 steering mirror in the above setup. So it should be safe.

Other:

Through the course of the work, I disabled the ETMY oplev and enabled it before closing the enclosure. I also reduced the AUX laser power and brought it back up after the work.
I did a check to see if the arms are locking in both IR and green and they did.
 

  10639   Fri Oct 24 18:53:23 2014 ranaUpdateGeneralY AUX laser - fiber coupled

 10% seems like a pretty bad coupling efficiency, even for a single lens. I know that the NPRO itself isn't so elliptical as that. Where is the other 230 mW going? random scattering?

Given that this is such an invasive process and, since its so painful to lose a whole night of locking due to end table business, I suggest that you always measure the out-of-loop ALS noise at the end of the end table work. Just checking that the green laser is locked to the arm is not sufficient to prove that the end table work won't prevent us from locking the interferometer.

We should insist on this anytime someone works on the optics or electronics at EX or EY. Don't have enough time to do an out-of-loop ALS spectrum? Then don't work at the end tables at all that day. We've got PZT alignment and mode matching work to do, as well as the rebuild of the EX table enclosure, so this is a good discipline to pick up now.

  10640   Mon Oct 27 12:17:46 2014 manasaUpdateGeneralY AUX laser coupling telescope design

Since I obtained a poor coupling efficiency from the earlier setup, I went back to calculate the coupling efficiency of the current setup.

For the current setup, I took the average of the x and y waist of the input beam and calculated the distance at which the input beam diameter would match the (fiber +collimator) beam diameter.

Average waist = 40.2um @-3.3mm from face of doubling crystal

(Fiber PM980 + Collimator f=2.0mm) beam waist = 205um

Distance(z) at which the input beam waist is 205um = 11.9cm

The closest available lens was f = 12.5cm. So I used it to couple the input beam by placing it at z ~12.5cm on a micrometer stage.

Since this gave only 10% coupling, I went back to calculate (using 'a la mode') the best possible coupling that can be obtained taking into consideration the ellipticity of the beam.

The maximum obtainable coupling (mode overlap) is 14.5%  which is still poor.

 

Redesign

Taking into account the ellipticity of the input beam, the available lenses and the space restrictions (lens can be placed only between z= 8 to 28cm), I calculated the best possible coupling efficiency (using 'a la mode').

The maximum possible mode overlap that can be obtained is 58.6% (matlab code and plot attached)

>>auxmode

modematching = 0.58632 

Optimized Path Component List:

    label    z (m)     type    parameters         

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

    L1       0.0923    lens    focalLength: 0.0750

 

Attachment 1: AUXmode.zip
Attachment 2: AUXmode.png
AUXmode.png
  10641   Mon Oct 27 19:15:54 2014 ericqUpdateLSCTrying to PRMI on 165

I spent some time trying to debug our inability to get MICH onto REFL165Q while the arms are held off with ALS, to no real success. 

I set up our usual repeatable situation of PRMI on 33 I&Q, arms held off with ALS. I figured that it may help to first sideband lock on REFL55, since 165 is looking for the f2 sidebands and maybe there is some odd offset between the locking points for f1 and f2 or other weirdness. 


REFL 55 settings:

Demod angle 98->126 (was previously set for PRY locking)

PRCL = 0.5 * REFL55 I (UGF of ~200 Hz) (FM gain unchanged from REFL33 situation of -0.02)

MICH = 0.125 * REFL55 Q (UGF of ~60Hz) (same FM gain as 33)

Some REFL55 offset adjusting had to be done in order to not disturb the 33-initiated lock when handing off. 

I also adjusted POP110 phase to zero the Q when locked, and switched the triggering over to 110I


The PRMI can acquire lock like this with arms held off with ALS, no problem. 

Here, I tried to hop over to 165. PRCL was no problem, needing a +1 on 165I. However, I had no success in handing off MICH.   I twiddled many knobs, but none that provably helped. 

I saw indications that the sensing angle in 165 is small (~20deg), which is not consistent with current knowledge of the cavity lengths. We last interferometrically measured the PRC length by letting the PRMI swing and looking at sideband splitting in POP110. At LLO, they did a length measurement by looking at demod angle differences in PRMI carrier vs. sideband locking. (alog8562) This might be worth checking out...

  10642   Mon Oct 27 22:19:17 2014 JenneUpdateCDSc1iscex restarted

I'm not sure why, but c1iscex did not want to do an mxstream restart.  It would complain at me that  "* ERROR:  mx_stream is already stopping."
Koji suggested that I reboot the machine, so I did.  I turned off the ETMX watchdog, and then did a remote reboot.  Everything came back nicely, and the mx_stream process seems to be running.

  10643   Tue Oct 28 01:12:57 2014 JenneUpdateSUSETMX bad :(

ETMX is misbehaving again.  I went to go squish his cable at the rack and at the satellite box, but it still happened at least once.

Anecdotally and without science, it seems to happen when ETMX is being asked to move a "big" amount.  If I move the sliders too quickly (steps of 1e-3, but holding down the arrow key for about 1 second) or if I offload the ASS outputs when they're too large (above 10ish?), ETMX jumps so that it's about 50 urad off in yaw according to the oplev (sometimes right, more often left), and either 0 or 50urad off in pitch (up if right in yaw, down if left in yaw). 

So far, by-hand slowly offloading the ASS outputs using the sliders seems to keep it happy.

I would ask if this is some DAC bit flipping or something, but it's happening for outputs through both the fast front ends (ASS offloading) and the slow computers (sliders moved too fast).  So.  I don't know what it could be, except the usual cable jiggling out issue.

Anyhow, annoying, but not a show stopper.

  10644   Tue Oct 28 02:44:08 2014 JenneUpdateSUSETMX bad :(

Okay, now ETMX's badness is a show-stopper.  I'm not sure why, but after this last lockloss, ETMX won't stay put.  Right now (as opposed to earlier tonight) it seems to only be happening when I enable LSC pushing on the SUS.  ETMX is happy to sit and stay locked on TEM00 green while I write this entry, but if I go and try to turn on the LSC it'll be wacky again.  Daytime work.

Anyhow, this is too bad, since I was feelin' pretty good about transitioning DARM over to AS55. 

I had a line on (50 counts at 503.1 Hz pushing differentially on the ETMs), and could clearly see the sign flip happen in normalized AS55Q between arm powers of 4 and 6.  The line also told me that I needed a matrix element of negative a few x10^-4 in the AS55Q -> DARM spot.  Unfortunately, I was missing a zero (so I was making my matrix element too big by a factor of 10) in my ezcastep line, so both times I tried to transition I lost lock. 

So.  I think that we should put values of 0.5 into the power normalization for our test case (I was using SRCL_IN1 as my tester) since that's the approximate value that the DCtrans uses, and see what size AS55Q matrix element DARM wants tomorrow (tonight was 1.6-3 x 10^-4, but with 1's in the normalization matrix).  I feel positive about us getting over to AS55. 

Also, Q is (I assume) going to work some more tomorrow on PRMI->REFL165, and Diego is going to re-test his new IR resonance finding script.  Manasa, if you're not swamped with other stuff, can you please see if you can have a look at ETMX?  Maybe don't change any settings, but see what things being turned on makes ETMX crazy (if it's still happening in the morning). 

  10645   Tue Oct 28 11:45:21 2014 manasaUpdateSUSETMX - observation

I looked at what are the situations that make ETMX lose alignment.

This is not occur all that often this morning; less than 10 times in may be the last 4 hours of poking the X arm. I found that the bad behavior of ETMX also exists in certain other cases apart from the case when we enable LSC.

(I) Even the MISALIGN and RESTORE scripts for the suspensions make the suspension behave bad. The RESTORE script while in the process of  bringing back the suspension to the place where it was, kicks it to some place else sometimes (even with LSC disabled)

(II) The suspension also gets kicked while realigning ETMX manually using sliders at 10^-3 (pace of 2-3 steps at a time).

I am suspecting something wrong right at the coil inputs and gains of the suspension.

Also, I recollect that  we haven't done a check on the X arm LSC limiters and filters ramping times like it was done for the Y arm ( Elog 9877 ). We should do this check to be sure that we are not seeing a mixed puddle of problems from 2 sources.

  10646   Tue Oct 28 14:07:28 2014 KojiUpdateIOOIMC WFS sensing matrix measurement

Last night the sensing matrix for IMC WFS&QPD were measured.

C1:IOO-MC(1, 2, 3)_(ASCPIT, ASCYAW)_EXC were excited at 5.01Hz with 100 count
The output of the WFS1/WFS2/QPD were measured. They all looked well responding
i.e. Pitch motion shows pitch error signals, Yaw motion shows yaw error signals.

The below is the transfer function from each suspension to the error signals

MC1P      MC2P     MC3P
-3.16e-4  1.14e-2  4.62e-3 -> WFS1P
 5.43e-3  8.22e-3 -2.79e-3 -> WFS2P
-4.03e-5 -3.98e-5 -3.94e-5 -> QPDP

MC1Y      MC2Y     MC3Y
-6.17e-4  6.03e-4  1.45e-4 -> WFS1Y
-2.43e-4  4.57e-3 -2.16e-3 -> WFS2Y
 7.08e-7  2.40e-6  1.32e-6 -> QPDY

Taking the inverse of these matrices, the scale was adjusted so that the dc response.

Attachment 1: 00.png
00.png
  10647   Tue Oct 28 15:27:25 2014 ericqUpdateIOOIMC WFS sensing matrix measurement

 I took some spectra of the error signals and MC2 Trans RIN with the loops off (blue) and on (red) during the current conditions of daytime seismic noise.

45.png

 

  10648   Tue Oct 28 20:47:08 2014 diegoUpdateIOOIMC WFS sensing matrix measurement

Today I started looking into the WFS problem and improvement, after being briefed by Koji and Nicholas. I started taking some measurements of open loop transfer functions for both PIT and YAW for WFS1, WFS2 and MC2_TRANS. For both WFS1 and 2 there is a peak in close proximity of the region with gain>1, and the phase margin is not very high. Tomorrow I will make measurements of the local damping open loop transfer functions, then we'll think how to improve the sensors' behaviour.

Attachment 1: 141028_MCWFS_WFS1_PIT_OL.pdf
141028_MCWFS_WFS1_PIT_OL.pdf
Attachment 2: 141028_MCWFS_WFS1_YAW_OL.pdf
141028_MCWFS_WFS1_YAW_OL.pdf
Attachment 3: 141028_MCWFS_WFS2_PIT_OL.pdf
141028_MCWFS_WFS2_PIT_OL.pdf
Attachment 4: 141028_MCWFS_WFS2_YAW_OL.pdf
141028_MCWFS_WFS2_YAW_OL.pdf
Attachment 5: 141028_MCWFS_MC2_TRANS_PIT_OL.pdf
141028_MCWFS_MC2_TRANS_PIT_OL.pdf
Attachment 6: 141028_MCWFS_MC2_TRANS_YAW_OL.pdf
141028_MCWFS_MC2_TRANS_YAW_OL.pdf
  10649   Wed Oct 29 03:33:38 2014 ericqUpdateLSCTrying to PRMI on 165

 

Short report: Further frustrated by 165 tonight. The weird thing is, the procedure I'm trying with the arms held off on ALS (i.e. excitation line in MICH and PRCL, adjust relative gains to make the signs and magnitudes mach, ezcastep over) works flawlessly with the ETMs misaligned. One can even acquire SB PRMI lock on 165 I&Q, with 80-90 degrees of demod angle between MICH and PRCL. The only real difference in REFL55 settings for misaligned vs. ALS-offset arms is an extra factor of two in the FM gains to maintain the same UGF, so I hoped that the matrix elements for 165 with misaligned arms would hold for ALS-offset arms. 

Alas, no such fortune. I still have no clear explanation for why we can't get MICH on 165Q with the arms held off on ALS. 

I also gave a quick try to measuring the PRCL->REFL55 demod phase difference between carrier and sideband lock (with arms misaligned), and got something on the order of 55 degrees, which really just makes me think I wasn't well set up / aligned, rather than actually conveying information about the PRC length...

  10650   Wed Oct 29 11:45:11 2014 manasaUpdateGeneralY AUX laser - fiber coupled (52%)

Quote:

Redesign

Taking into account the ellipticity of the input beam, the available lenses and the space restrictions (lens can be placed only between z= 8 to 28cm), I calculated the best possible coupling efficiency (using 'a la mode').

The maximum possible mode overlap that can be obtained is 58.6% (matlab code and plot attached)

>>auxmode

modematching = 0.58632 

Optimized Path Component List:

    label    z (m)     type    parameters         

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

    L1       0.0923    lens    focalLength: 0.0750

 

I used the above configuration and was able to obtain ~52% coupling.

Input power = 250mW
Output power with absorptive ND 1.0 = 13 mW

I used the absorptive ND filter before the lens to keep the coupled output power within the range of fiber power meter and also avoid scattering of enormous amount of uncoupled light all over the table.

I have attached the screenshot of the out of loop ALS noise before opening the table (BLUE) and after closing down (MAGENTA). The beat note frequency and amplitude before and after were (14.4MHz/-9.3dBm) and (20.9MHz/-10 dBm).

Attachment 1: 31.png
31.png
  10651   Wed Oct 29 18:07:28 2014 manasaUpdateGeneralDiode laser test preparation

I ran 3 BNC cables from the SP table to 1X7 rack so that we can have 16 bit channels for the Ontrak PD that will be used to test oplev lasers. The BNC cables are plugged to the Ch 29, 30 & 31 that were already created for this purpose (elog 10488)

  10652   Thu Oct 30 01:21:37 2014 JenneUpdateLSCNo MICH in REFL165

[Koji, Jenne, Diego]

Summary:  We really don't have any MICH signal in REFL 165.  Why is still a mystery.

We made several transfer function measurements while PRMI was locked on REFL33 with the arms held off resonance, and compared those to the case where the ETMs are misaligned.  We fine-tuned the REFL165 demod phase looking at the transfer function between 10-300 Hz (using bandpassed white noise injected in the MICH FF filter bank and looking at REFL165Q), rather than just a single line.  We did that at CARM offset of 3 counts (ALS locked), and then saw that as we reduced the CARM offset, the coherence between MICH injection and REFL165Q just goes down.  Any signal that is there seems to be dominated by PRCL. 

So, we're not sure why having the arms eats the MICH 165 signal, but it does.  Everyone should dream tonight about how this could happen. 

Koji suggested that if the signal is just lost in the noise, perhaps we could increase our modulation depth for 55MHz (currently at 0.26, a pretty beefy number already).  Alternatively, if instead the problem is that the MICH signal has rotated to be in line with the PRCL signal, there may be no hope (also, why would this happen?).

Anyhow, we'd like to understand why we don't have any MICH signal in REFL165 when the arm cavities are involved, but until we come up with a solution we'll stick with REFL33 and see how far that gets us. 

The only really worthwhile plot that I've got saved is the difference in these transfer functions when PRMI-only locked and PRMI+arms locked.  Green is PRMI-only, with the demod phase optimized by actuating on PRM and minimizing the peak in the Q signal.  Blue is PRMI with the arms held off resonance using the ALS signals, with the demod phase set again, in the same way.  We were expecting (at least, hoping) that the blue transfer function would have the same shape as the green, but clearly it doesn't.  The dip that is around 45 Hz can be moved by rotating the demod phase, which changes how much PRCL couples into the Q phase.  Weird.  At ~3nm we had somewhat reasonable coherence to RELF165Q, and were able to pick -102deg as the demod phase where the dip just disappears.  However, as the CARM offset is reduced, we lost coherence in the transfer functions.

MICH_to_REFL165_29Oct2014.pdf

  10653   Thu Oct 30 02:12:59 2014 diegoUpdateIOOIMC WFS sensing matrix measurement

[Diego,Koji]

Today we took some measurements of transfer functions and power spectra of suspensions of the MC* mirrors (open loop), for all the DOFs (PIT, POS, SIDE, YAW); the purpose is to evaluate the Q factor of the resonances and then improve the local damping system.

Attachment 1: MC1_OL_PIT.pdf
MC1_OL_PIT.pdf
Attachment 2: MC1_OL_POS.pdf
MC1_OL_POS.pdf
Attachment 3: MC1_OL_SIDE.pdf
MC1_OL_SIDE.pdf
Attachment 4: MC1_OL_YAW.pdf
MC1_OL_YAW.pdf
Attachment 5: MC2_OL_PIT.pdf
MC2_OL_PIT.pdf
Attachment 6: MC2_OL_POS.pdf
MC2_OL_POS.pdf
Attachment 7: MC2_OL_SIDE.pdf
MC2_OL_SIDE.pdf
Attachment 8: MC2_OL_YAW.pdf
MC2_OL_YAW.pdf
Attachment 9: MC3_OL_PIT.pdf
MC3_OL_PIT.pdf
Attachment 10: MC3_OL_POS.pdf
MC3_OL_POS.pdf
Attachment 11: MC3_OL_SIDE.pdf
MC3_OL_SIDE.pdf
Attachment 12: MC3_OL_YAW.pdf
MC3_OL_YAW.pdf
  10654   Thu Oct 30 02:54:38 2014 diegoUpdateLSCIR Resonance Script Status

[Diego, Jenne]

The script is moving forward and we feel we are close, however we still have a couple of issues, which are:

1) some python misbehaviour between the system environment and the anaconda one; currently we call bash commands within the python script in order to avoid using the ezca library, which is the one complaining;

2) the fine scan is somewhat not so robust yet, need to investigate more; the main suspects are the wavelet parameters given to the algorithm, and the Offset and Ramp parameters used to perform the scan.

Here is an example of a best case scenario, with 20s ramp and 500 points:

 

Attachment 1: AllPython_findIRresonance_WL_X_ramp_20_500_2.png
AllPython_findIRresonance_WL_X_ramp_20_500_2.png
Attachment 2: AllPython_findIRresonance_WL_Y_ramp_20_500_2.png
AllPython_findIRresonance_WL_Y_ramp_20_500_2.png
Attachment 3: AllPython_findIRresonance_WL_ramp_20_500_2.png
AllPython_findIRresonance_WL_ramp_20_500_2.png
  10655   Thu Oct 30 16:25:22 2014 ericqOmnistructureComputer Scripts / Programsnew version of cdsutils (361) installed

Quote:

I just installed cdsutils r351 at /ligo/apps/linux-x86_64/cdsutils.  It should be available on all workstations.

It includes a bunch of bug fixes and feature improvements, including the step stuff that Rana was complaining about.

Cdsutils r361 installed, for the "avg" updates. aLOG  

 

 

  10656   Fri Oct 31 02:19:37 2014 ericqUpdateLSCSome SRMI progress

Earlier today, I did some simulations that suggested that PRC lengths on the order of a cm from our current estimated one could result in degenerate PRCL and MICH signals in REFL165 at 3nm CARM offset. I attempted more demod-angle derived cavity PRC length measurements with REFL11 and REFL55, but they weren't consistent with each other...

In any case, adding dual recycling, even with a SRC length off by 1cm in either direction, doesn't seem to exhibit the same possibility, so I spent some time tonight seeing if I could make any progress towards DRMI locking. 

I was able to lock SRY using AS55 in a very similar manner to PRY, after adjusting the AS55 demod angle to get the error signal entirely in I. I used this configuration to align the SRM to the previously aligned BS and ITMY. Oddly, I was not able to do anything with SRX as I had hoped; the error signal looks very strange, looking more like abs(error signal). 

I then was able to lock the SRMI on AS55 I & Q, the settings have been saved in the IFO configure screen.  I've used AS55Q for PRMI locking with a gain of -0.2, so I started with that; the final gain ended up being -0.6. PRMI/PRY gain for prcl is something like 0.01, so since I used a gain of 2 for locking SRX, I started the SRCL gain around 0.02, the final gain ended up being -0.03. I basically just guessed a sign for AS110 triggering. Once I lucked upon a rough lock, I excited the PRM to tune the AS55 angle a few degrees; it was luckily quite close already from the SRY adjustment. AS110 needed a bigger adjustment to get the power into I. (AS55: -40.25->-82.25, AS110: 145->58, but I put AS55 back for PRMI)

I briefly tried locking the DRMI, but I was really just shooting in the dark. I went back and measured various sensing amplitudes/angles in SRMI and PRMI configurations; I'm hoping that I may be able to simulate the right gains/angles for eventual DRMI locking.

  10657   Fri Oct 31 11:46:15 2014 manasaUpdate Rattling HEPA : Eventually stops

The PSL HEPA stopped working while it was running at 80%. I have closed the PSL enclosure.

Steve is working to fix this.

  10658   Fri Oct 31 15:34:47 2014 SteveUpdatePSLPSL HEPAs are running again

Quote:

The PSL HEPA stopped working while it was running at 80%. I have closed the PSL enclosure.

Steve is working to fix this.

 The Variac burned out and it was replaced. Each unit was checked out individually. HEPA -north is still noisy at full speed.

Attachment 1: HepaVariac.jpg
HepaVariac.jpg
  10659   Fri Oct 31 19:59:26 2014 KojiUpdateGeneralSome locking work / PRMI analysis

Preparations

- According to Diego's report, the MC WFS gains were too high. We'll fix this later by tweaking the servo shapes.
But for now, all of the WFS gains were reduced by 40%.
i.e. WFS(1|2)(PIT|YAW) gains from 5 to 3, MC2TRANS(PIT|YAW) gains from 50 to 30.

- Aligned IMC carefully and ran the offset nulling script. MC REFL became 0.435~0.445 and MC TRANS was ~16600.

- Locked the arms and ran ASS.


PRMI

- Started locking PRMI. I just used REFL33I&Q as suggested by the configure script. The PRMI locking was not so robust.
Particularly, the third violin mode of PRM and BS seemed to get excited and dominated the signals.
I modified Vio3 filter in the violin filter for BS and PRM to include zero at 1921Hz where the growing peak was seen.

- We probably want to start from the 1f signals for DRMI lock acquisition. So I wanted to check how REFL11s are.
Measured the demod phase and relative gain between 33I and 11I. (By the way, REFL11I whitening gain was lowered to 0dB).
REFL11I had about x10 gain and the same phase compared to REFL33I. The demod phase for REFL11 was +21deg.
Also checked REFL55 phase and gain. 55Q has almost the same gain as 33Q. And the adjusted phase was 25deg.
These were just rough adjustment of the demod phases.

- Then the servo configuration was transtioned to Configuration 1 (below), and then Configuration 2.

- This configuration was very stable and the PRMI stayed locked about ~1 hour. During this long lock, I could measure 
PSDs, sensing matrix, and etc. Also I could play with the PRM ASC. I wasn't sure if the POP is actually stabilized or not.
(I have no data)

- I noticed that something was ringinging up at 1883Hz. Another 3rd order viloin mode???

- The lock was lost due to too strong injection. But also it reacquired without touching.

- Precise demod phase adjustment has been done by elliminating PRCL from the Q signals.

REFL11 16.75
REFL33 133.0
REFL55 31.0
REFL165 -142 
AS55 -53

- Configiration1 (REFL11I&REFL55Q)

REFL11: WTN 0dB PHASE 21deg, REFL11I x0.1 -> PRCL
REFL33: WTN 30dB PHASE 145deg
REFL55: WTN 21dB PHASE 25deg, REFL55Q x1 -> MICH

PRCL: GAIN -0.04 FM4/5 ON, Triggered FM 2/3/6/9, Servo trigger: POP22I 50up 10down, No Normaization.
MICH: GAIN 10 FM4/5 ON, Triggered FM 2/3/6/9, Servo trigger: POP22I 50up 10down, No Normaization.

PRCL -> PRM +1
MICH -> PRM -0.2625, BS +0.50 BS

- Configuration 2 (REFL11I&Q)

Same as above except:
REFL11Q x-0.1 -> MICH


Calibration

Let's use these entries 

PRM: http://nodus.ligo.caltech.edu:8080/40m/8255
PRM:  (19.6 +/- 0.3) x 10^{-9} (Hz/f)^2 m/counts

BS/ITMs http://nodus.ligo.caltech.edu:8080/40m/8242
BS     = (20.7 +/- 0.1)    x 10 -9 / f2
ITMX = (4.70 +/- 0.02)  x 10 -9/ f2
ITMY = (4.66 +/- 0.02) x 10 -9/ f2

- PRCL Calibration

Lockin oscillator module 675.13Hz 100 -> +1 PRM

Measurement bandwidth 0.1Hz -> Signal power BW 0.471232 (FLATTOP window)

C1:SUS-PRM_LSC_IN1: 118.99 cnt/rtHz => 5.12pm/rtHz
REFL11I: 17.84  cnt/rtHz => 3.49e12 cnt/m
REFL33I:  2.28  cnt/rtHz => 4.46e11 cnt/m
REFL55I:  0.158 cnt/rtHz => 3.09e10 cnt/m
REFL165I: 1.63  cnt/rtHz => 3.19e11 cnt/m


- MICH Calibration

Lockin oscillator module 675.13Hz 100 -> -1 ITMX +1 ITMY

Measurement bandwidth 0.1Hz -> Signal power BW 0.471232 (FLATTOP window)

C1:SUS-ITMX_LSC_IN1: 121.79 cnt/rtHz => 1.26pm/rtHz
C1:SUS-ITMY_LSC_IN1: 121.79 cnt/rtHz => 1.25pm/rtHz
REFL11Q:  0.0329   cnt/rtHz => 1.32e10 cnt/m (PRCL/MICH ratio 265)
REFL33Q:  0.00773  cnt/rtHz => 3.09e9  cnt/m (144)
REFL55Q:  0.001645 cnt/rtHz => 6.58e8  cnt/m (47)
REFL165Q: 0.00374  cnt/rtHz => 1.50e9  cnt/m (213) !?
AS55Q:    0.0696   cnt/rtHz => 2.78e10 cnt/m

Openloop TF measurements
Servo filter TF measuremnts

The UGFs were ~250Hz for PRCL and ~120Hz for MICH, respectively.
The OLTF was modelled by the servo and violin filters TF from foton, estimated TF of the AA/AI filters, and the constant time delay.

Displacement spectra measurement

SELF NOTE: DON'T FORGET TO TURN ON the whitening of the unused signals! (USE MC DOF or manual switch)

- PRCL

The PRCL displacement was measured with REFL I signals. In the attachment 3, the in-loop and free-run equivalent displacements are shown (red and blue).
Other out-of-loop sensors (33/55/165) were also plotted together.

FIrst of all, the uncompensated displacement noise level of PRCL is around 1e-7 m/rtHz. This is a good indication that the calibration was not crazy.

The sensing noise of REFL11 seems to be 1e-15~1e-16 m/rtHz at high frequency which is enough for now.
As expected, REFL11I has the best noise level among the REFLs. At low frequency, it seemed that the noise level is limited by something at 1e-12 m/rtHz.
Of course, we can't say this is just the sensing noise of the other REFLs or the noise of the REFL11I. But this noise level is enough small for the locking of
the low finesse (F<100) PRCL cavity.

Remembering we had no trouble locking PRCL with REFL33/55/165, this plot indicates that the PRCL was suppressed too much below 2Hz.
And we want more supression between 5Hz to 30Hz. We have resonant gains in ther PRCL servo but not sure how effective they were.
If we consider the contamination of PRCL in MICH, we should try to optimize the PRCL servo.

- MICH

The MICH displacement was similary calibrated to PRCL. The signal sources were the REFL Qs and AS55Q.
In the attachment 4, the in-loop and free-run equivalent displacements are shown (red and blue).
Other out-of-loop sensors were also plotted together.

The problem here is that the out-of-loop levels (REFL33/55/165 and AS55) show almost the same levels
and thus it is likely that the actual (out-of-loop) stability of MICH is this kind of level. If we believe it, we only have
~1/100 supression between 1-10Hz and ~1/10Hz below 0.5Hz.
The strong servo control does nothing to stablize
MICH. From the out-of-loop noise level of MICH, this comes for the contamination from leakage PRCL.
We really need to improve the signal quality of MICH.

The MICH servo filter has quite complicated shape, but is not necessary according to the estimated free-runing MICH.

The MICH free-running motion is quieter than the PRCL one between 1Hz to 30Hz. The reasonable explanation is
that it comes from poor vibration isolation of the tip-tilts. It means that SRCL also has the similar noise level to PRCL.

Attachment 1: PRMIsb_PRCL_OLTF.pdf
PRMIsb_PRCL_OLTF.pdf
Attachment 2: PRMIsb_MICH_OLTF.pdf
PRMIsb_MICH_OLTF.pdf
Attachment 3: PRMIsb_PRCL_SPE.pdf
PRMIsb_PRCL_SPE.pdf
Attachment 4: PRMIsb_MICH_SPE.pdf
PRMIsb_MICH_SPE.pdf
  10660   Sat Nov 1 02:13:11 2014 KojiConfigurationLSCLSC settings

I'm leaving the iFO now. It is left with the IR arm mode.

I pretty much messed up LSC configurations for my DRMI locking. If one needs to recover the previous setting, use burtrestore.
I have all records of my LSC settings, so you don't need to preserve it. (Of course we can always use the hourly snapshots
to come back this DRMI setting)

 

  10661   Sat Nov 1 16:06:32 2014 KojiConfigurationLSCDRMI locked

Continued from ELOG 10659


DRMI locking

Following Jenne's elog entry in Aug 2013 (9049), DRMI was configured and locked. The lock was stable, indefinite, and repeatitive.

- DRMI Configuration

Demod phases has not been changed from PRMI

REFL11: WTN 0dB PHASE 21deg, REFL11I x0.1 -> PRCL
REFL55: WTN 21dB PHASE 25deg, REFL55Q x1 -> MICH, REFL55I x1 -> SRCL

AS110 phase was adjusted to maximize Q during the lock: +1deg (AS110Q_ERR was +4400 ~ +5500)

PRCL: GAIN -0.05 FM4/5 ON, Triggered FM 2/3/6/9, Servo trigger: POP22I 20up 10down, No Normaization.
MICH: GAIN +1 FM4/5 ON, Triggered FM 2/3/6/9, Servo trigger: POP22I 20up 10down, No Normaization.

SRCL: GAIN +2 FM4/5 ON, Triggered FM2/3/6/8/9, Servo trigger: AS110Q up 500 down 5, No Normaization.
(FM8 was set to be x2.5 flat gain such that the gain is increased after the lock)

MICH actuation is still BS+PRM and does not include SRCL decoupling yet.
This should be fixed ASAP.

DRMI Calibration

Let's use these entries 

SRM: http://nodus.ligo.caltech.edu:8080/40m/10664
SRM = (19.0 +/- 0.7) x 10 -9/ f2

PRM: http://nodus.ligo.caltech.edu:8080/40m/8255
PRM:  (19.6 +/- 0.3) x 10 -9 / f2 m/counts

BS/ITMs http://nodus.ligo.caltech.edu:8080/40m/8242
BS     = (20.7 +/- 0.1)    x 10 -9 / f2 m/counts
ITMX = (4.70 +/- 0.02)  x 10 -9/ f2
m/counts
ITMY = (4.66 +/- 0.02) x 10 -9/ f2
m/counts

- PRCL Calibration

Lock-in oscillator module 675.13Hz 100 -> +1 PRM

Measurement bandwidth 0.1Hz -> Signal power BW 0.471232 (FLATTOP window)

C1:SUS-PRM_LSC_IN1: 97.45 cnt/rtHz => 4.19 pm/rtHz

REFL11I: 12.55   cnt/rtHz => 3.00e12 cnt/m
REFL11Q:  0.197  cnt/rtHz => 4.70e10 cnt/m
=> 0.90 deg rotated! (GOOD)

REFL33I:  1.63   cnt/rtHz => 3.89e11 cnt/m
REFL33Q:  0.196  cnt/rtHz => 4.68e10 cnt/m
=> 8.32 deg rotated!

REFL55I:  0.0495 cnt/rtHz => 1.18e10 cnt/m
REFL55Q:  0.548  cnt/rtHz => 1.31e11 cnt/m => 84.8 deg rotated! (WHAT!)

REFL165I: 1.20   cnt/rtHz => 2.86e11 cnt/m
REFL165Q: 0.458  cnt/rtHz => 1.09e11 cnt/m
=> 20.9 deg rotated!

- MICH Calibration

Lock-in oscillator module 675.13Hz 100 -> -1 ITMX +1 ITMY

Measurement bandwidth 0.1Hz -> Signal power BW 0.471232 (FLATTOP window)

C1:SUS-ITMX_LSC_IN1: 121.79 cnt/rtHz => 1.26pm/rtHz
C1:SUS-ITMY_LSC_IN1: 121.79 cnt/rtHz => 1.25pm/rtHz

AS55Q:   12.45   cnt/rtHz => 4.96e12 cnt/m (STRONG)

REFL11I:  0.0703 cnt/rtHz => 2.80e10 cnt/m
REFL11Q:  0.0142 cnt/rtHz => 5.66e09 cnt/m
=> 78.5 deg rotated! (WHAT!)

REFL33I:  0.0473 cnt/rtHz => 1.88e10 cnt/m
REFL33Q:  0.0291 cnt/rtHz => 1.16e10 cnt/m => 58.4 deg rotated!

REFL55I:  0.00668cnt/rtHz => 2.66e09 cnt/m
REFL55Q:  0.0261 cnt/rtHz => 1.04e10 cnt/m => 14.4 deg rotated! (OK)

REFL165I: 0.0233 cnt/rtHz => 9.28e09 cnt/m
REFL165Q: 0.0512 cnt/rtHz => 2.04e10 cnt/m => 24.5 deg rotated! (GOOD)

- SRCL Calibration

Lock-in oscillator module 675.13Hz 100 -> SRM

Measurement bandwidth 0.1Hz -> Signal power BW 0.471232 (FLATTOP window)

C1:SUS-SRM_LSC_IN1: 121.77 cnt/rtHz => 5.08pm/rtHz

AS55I:    0.256   cnt/rtHz => 5.05e10 cnt/m
AS55Q:    0.3498  cnt/rtHz => 6.90e10 cnt/m

REFL11I:  0.00624 cnt/rtHz => 1.23e09 cnt/m
REFL11Q:  0.00204 cnt/rtHz => 4.02e08 cnt/m

REFL33I:  0.00835 cnt/rtHz => 1.65e09 cnt/m
REFL33Q:  0.0659  cnt/rtHz => 1.30e10 cnt/m

REFL55I:  0.0201  cnt/rtHz => 3.97e09 cnt/m
REFL55Q:  0.01505 cnt/rtHz => 2.97e09 cnt/m

REFL165I: 0.0238  cnt/rtHz => 4.69e09 cnt/m
REFL165Q: 0.0247  cnt/rtHz => 4.87e09 cnt/m

DRMI Openloop measurements
Servo filter TF measurements

The UGFs were ~250Hz for PRCL and ~100Hz for MICH, and ~250Hz for SRCL, respectively.
MICH showed (presumably) crosscoupling related peak ~350Hz. SRCL had small deviation from the model.
This may also be related to the cross couplig.

The OLTF was modelled by the servo and violin filters TF from foton, estimated TF of the AA/AI filters, and the constant time delay.

Displacement spectra measurement

- PRCL

The OLTF compensation was not actually succesfull at 300Hz, but otherwise the situation is very similar to the one with PRMI.

- MICH

Again the servo compensation at 300Hz was not successful. If we believe that AS55Q is the best MICH sensor, the out-of-loop
noise level of MICH was quite similar to the one in PRMI. We should try to use AS55Q for DRMI MICH for investigation purpose
to see which REFL signal has the best MICH quality. REFL165 seems to be iproved in the signal amplitude. Can we use this
for locking now?

- SRCL

It is in fact difficult to tell what is the correct out-of-loop noise level. AS55I has too much contamination from MICH and is not indicating
useful info. This measurement should be tried once the sensor diagonalization is done.

REFL55I is not seeing anything real abobe 30Hz. We should be able to reduce the UGF and the servo gain.

The absolute motion level of SRCL is something similar to PRCL, rather than MICH.

 

Attachment 1: DRMI_PRCL_OLTF.pdf
DRMI_PRCL_OLTF.pdf
Attachment 2: DRMI_MICH_OLTF.pdf
DRMI_MICH_OLTF.pdf
Attachment 3: DRMI_SRCL_OLTF.pdf
DRMI_SRCL_OLTF.pdf
Attachment 4: DRMI_PRCL_SPE.pdf
DRMI_PRCL_SPE.pdf
Attachment 5: DRMI_MICH_SPE.pdf
DRMI_MICH_SPE.pdf
Attachment 6: DRMI_SRCL_SPE.pdf
DRMI_SRCL_SPE.pdf
  10662   Mon Nov 3 17:14:00 2014 ericqUpdateASCIMC to IFO angular motion

Something to note, as we have the IMC angular controls under consideration:

Jenne has the DRMI locked right now. I took a look at the coherence between the POP QPD and MC2 transmission QPDs. (Since she's using ASC, I also included those control signals. The coherences are about the same, unsurprisingly)

Based on the observed coherences, from about 1 to 6Hz, IMC motion is responsible for a fair amount of the DRMI angular motion. Also, PIT and YAW couple differently. 

2014-10-03-MC2T_to_POPQPD.pdf

ELOG V3.1.3-