40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 206 of 344  Not logged in ELOG logo
ID Date Author Type Category Subject
  6965   Thu Jul 12 02:12:42 2012 yutaUpdateSUSBS 3.3 Hz motion

I tried to reduce BS 3.3 Hz motion with local damping. 3.3 Hz probably comes from the stack, but I want to reduce this because PRMI beam spot is moving in this frequency.
I tried it by putting some resonant gains to oplev servo and OSEM damping servo, but failed.

What I learned:
  1. BS OSEM input matrix diagonalization looks impressively good. Below is the spectra of oplev pitch/yaw and OSEM pos/pit/yaw/side comparing with and without damping (REF is without). You can see mechanical resonances are well separated. Also, damping servos don't look like they are adding noise at 3.3 Hz.
BSdam.png

  2. 3.3 Hz motion is not stationary. Amplitude is sometimes high, but sometimes low. Amplitude changes in few seconds. You can even see 3.3 Hz in the dataviewer, too.

  3. I set new oplev gains. I lowered them so that UGFs will be ~ 2.5 Hz. I turned ELP35 on.

C1:SUS-BS_OLPIT_GAIN = 0.2 (was 0.6)
C1:SUS-BS_OLPIT_GAIN = -0.2 (was -0.6)

  4. All OSEM sensors feel about the same amount of 3.3 Hz motion.

  5. OLPIT and OLYAW reduces if you put 3.3 Hz resonant gain to oplev servo, but it is maybe not true since they are in-loop error signals. You can't see the difference from OSEM sensors. Below is oplev pitch/yaw and OSEM pos/pit/yaw/side comparing with and without 3.3 Hz resonant gain (REF is without).
BSOLSUSresonantgain.png

  6964   Wed Jul 11 16:19:08 2012 yutaUpdateSUSoplev servo phiology

I heard that Steve did great work on oplev in Feb 2012.
Here's summary what happened to oplev since then.
Someone changed oplev filters and gain. I couldn't find elog about it. Does anyone know?

Quadrant sum:
  Quadrant sum (C1:SUS-XXX_OLSUM) for each optic now and in Feb 2012 is

  ITMX   ITMY   ETMX   ETMY     BS    PRM    SRM
  2456  14630   1476  14885   3650   4302   2937   counts (now)
  1300  14500    900   9000   3500   4000   2600   counts (Feb 6, 2012 elog
#6256)
 0.025  0.3    0.2    0.2    0.05   0.06   0.04    mW on QPD (Feb 6, 2012 elog
#6256)
  1350  15000   1500  15500   3500   4000   2600   counts (Feb 23, 2012 elog
#6744)

  ETMX oplev laser was replaced on May 22, 2012, and quadrant sum was 20500 counts at that time (elog #6656).


Oplev servo openloop transfer functions:
  In Feb 2012, gains were adjusted and filter settings are recorded by Steve.
  For all pitch OLTF, see elog #6309.
  For all yaw OLTF, see elog #6323.

  All the filters in Feb is listed in elog #6744.
  Filters now are messed up, as Jamie pointed out in elog #6743.
  Below is the current filter settings.

  I turned ELP and RLP filters on, which wasn't on to cut-off noises at higher frequencies.
  I left resonant gains of ETMs because I don't know what they are for.
  I put ELP35 for ITMs, BS, PRM and SRM. I put RLP80 for BS, PRM and SRM.
  I will leave ELP35 off for BS and SRM because they oscillate currently. ELP50 and ELP40 is on for a substitution. I will readjust them soon.

  I don't know who changed all gains (except for PRM, which I adjusted in elog #6952). It doen't look like it is because of change in quadrant sum.
  I also don't know who deleted 3.3 Hz resonant gain for BS.

  I put all similar filters in same place to make it organized. Now, basic fitlers are organized. We may need some resonant gains for each optics.

OPLEV SERVO 300^2:0 BR ELP RLP RES GAIN QPD counts
filter position FM1 FM5 FM9 FM4 FM3, FM4    
ETMY pit 300^2:0 BR 35 80

0.5 (off)

-0.2 (was -1.5) 14,900
ETMY yaw 300^2:0 BR 35 80 0.6 (off) -0.2 (was -1.0)  
ETMX pit 300^2:0 BR 35 80 0.5 (off) 0.5 1,500
ETMX yaw 300^2:0 BR 35 80 0.6 (off) 0.6 (was 1.0)  
ITMY pit 300^2:0 BR 35 80   2.1 (was 2.0) 14,600
ITMY yaw 300^2:0 BR 35 80   -2.0 (was -4.0)  
ITMX pit 300^2:0 BR 35 80   2.6 (was 1.0) 2,500
ITMX yaw 300^2:0 BR 35 80   -1.6 (was-2.0)  
BS pit 300^2:0 BR 50 (FM10) 80   0.6 (was 0.5) 3,700
BS yaw 300^2:0 BR 50 (FM10) 80 (3.3 is some how deleted) -0.6 (was -1.0)  
PRM pit 300^2:0 BR 35 80 3.3 (off) 0.15 (was 1.0) 4,300
PRM yaw 300^2:0 BR 35 80 3.3 (off),  4 (off) -0.2 (was 0.5)  
SRM pit 300^2:0 BR 40 (FM10) 80   -2.0 2,900
SRM yaw 300^2:0 BR 40 (FM10) 80   2.0  

  I also found Kiwamu's angular motion measurement during PRMI lock (elog #6320). They look different with my measurement yesterday (elog #6954).

  6963   Wed Jul 11 14:27:29 2012 YaakovSummarySTACISCurrent STACIS Status

The X and Y directions in the STACIS still both oscillate uncontrollably in closed loop, so I'll be doing my testing in Z for now. If I need to use the other axes I'll lower their gain with the pots and add weight to the STACIS platform to try to make it more stable.

Measurements I've taken for Z:

--Open loop gain, taken by driving the PZTs with a swept sine signal and measuring with both internal geophones and external accelerometers. These measurements look a lot like the plots supplied by the STACIS manufacturer, with a resonance at 15-16 Hz (X and Y also look good). Figure below was taken with geophones:

geo_open_z2.png

--Open loop gain, where the input is ambient seismic noise measured by one set of accelerometers on the floor and one set on top of the STACIS:

 ambient_open_z.png

--Closed loop gain, where the input is ambient seismic noise, and feedback is supplied by the geophones (like normal STACIS operation). There's a definite drop in the transfer function, as expected:

ambient_closed_z_geoFeed.png

--Open and closed loop transfer functions superimposed (the higher one is open):

openVclosed.GIF

I am currently working on using the less-noisy accelerometers to provide feedback instead of the geophones. I have found the right point before the extension board to input the accelerometer signal which is NOT the same as the Signal IN/OUT cables- those are at the end of the board, after amplifying and filtering. I want the accelerometer signal to go through the same circuitry as the geophone signal so that the noise of the sensors themselves can be compared.

Problem: Coherence isn't great between the accelerometer sets at low frequencies, which leads to a not very smooth transfer function. I might try using the shaker, because the larger motion may lead to better coherence between the accelerometers on top of the STACIS and at its base.

 

 

Attachment 1: geo_open_z.png
geo_open_z.png
  6962   Wed Jul 11 14:22:54 2012 EricSummaryGeneralSURF Update

Here's what I accomplished since my last elog:

I continued working on the beatbox calibration. Instead of using the function generator for an input signal,
I used the network analyzer because it can generate higher frequencies that are of more interest to us. I ran
the network analyzer output into the RF in port, and took voltage measurements from the Q port using the
oscilloscope. The frequency range I focused on was 100 - 200 MHz, and I also took more closely spaced measurements
from 180 - 200 MHz. The data is recorded on the computer now, and I will analyze it more fully in the future.

I also edited the Calibration page on the LIGO 40 m wiki. Rana showed me the page on calibration, but there was
limited information there, so he recommended that I post my work there as well. Right now I haven't posted much,
but I will likely add some information on the Simulink model I'm working on and results of measurements to be
taken as the project progresses.

The majority of my work has been on developing a Simulink model in Matlab of the differential arm length sensing
and control loop
. I am using Figure 6-1 from Rana's thesis as a guide on important components to include in the
model. Some of the details on the transfer functions of components need to be worked out, but a basic framework has
been established. Right now the transfer function of the arm cavity is being approximated as a single pole, but
we may integrate the calibration model I'm working on with Sasha's work on the arm cavity. I have also begun to
implement the length response function in the model
. I believe it is giving correct results at frequencies up to
100 Hz, but is off at higher frequencies. This might be fixed after I continue to fill in the transfer functions
of the digital components; they are currently set to 1 until I find more information on them.

  6961   Wed Jul 11 13:45:01 2012 JenneUpdatePEMmore seismic noise next week

Quote:
 
   The fabricators of the big flume in the CES lab have begun testing the sediment feed system which is the noisiest component and plan to test off and on during the day for the next week.
   Please let me know if you detect the noise or have any issues.
 
 
Brian Fuller

phone: 626-395-2465

 Masha and Yaakov - this is an excellent opportunity for you guys to test out your triangulation stuff!  Also, it might give a lot of good data times for the learning algorithms.

Maybe you should also put out the 3 accelerometers that Yaakov isn't using (take them off their cube, so they can be placed separately), then you'll have 6 sensors for vertical motion.  Or you can leave the accelerometers as a cube, and have 4 3-axis sensors (3 seismometers + accelerometer set).

  6960   Wed Jul 11 13:36:58 2012 yutaUpdateSUSOSEM and oplev spectra of optics

Below is angular spectra of every suspended core optics.
As you can see, there's a peak at 3.3 Hz for BS and PRM angular motion. Compared with other optics, they look large.

I briefly checked suspension filters and found that BounceRoll filters and f2a filters are not turned on for BS.
I checked elog and there was no reason for them to be off, so I turned them on. It didn't change angular spectra very much, though.

I'm going to check BS suspension damping and see where 3.3 Hz peak comes from.

Note that oplev quadrant sums are different for every optics, so we can't simply compare angular motion between optics from OLPIT/OLYAW. But for OSEMs, there are "cnt2um" which calibrate sensor outputs into um. and input matrix should be normalized, so we can compare SUSPIT/SUSYAW with other optics.

I centered all oplevs to do this measurement.
Quadrant sum (C1:SUS-XXX_OLSUM) for each optic now is

ITMX   ITMY   ETMX   ETMY     BS    PRM    SRM
2456  14630   1476  14885   3650   4302   2937   (counts)


OLPITYAW.png   SUSPITYAW.png

  6959   Wed Jul 11 11:18:21 2012 steveUpdatePEMmore seismic noise next week
 
   The fabricators of the big flume in the CES lab have begun testing the sediment feed system which is the noisiest component and plan to test off and on during the day for the next week.
   Please let me know if you detect the noise or have any issues.
 
 
Brian Fuller

phone: 626-395-2465

  6958   Wed Jul 11 11:00:45 2012 MashaSummaryGeneralWeek Summary

This week, my work fell into two categories: Artificial Neural Networks and lab-related projects.

Artificial Neural Networks

- I played around with radial basis functions and k-means classification algorithms for a bit in order to develop an algorithm to pick out various features of seismic signals. However, I soon realized that k-means is an extremely slow algorithm in practice, and that radial basis functions are thus difficult to implement since their centers are chosen by the k-means algorithm in practice.

- Thus, I moved on to artificial neural networks. Specifically, I chose to implement a sigmoidal neural network, where the activation function of each neuron is f(u) = 1/ (1 + e-u/T), T constant, which is nice because it's bounded in [0, 1]. Classification, then, is achieved by generating a final output vector from the output layer of the form [c1, c2, c3, ..., cN] where N is the number of classes, ci = 1 (ideally) if the input is of class i, and ck = 0 otherwise.

- First, I built a network with randomly generated weights, ten neurons in the one hidden layer, and two output neurons - to simply classify [1, 0] (earthquake) and [0, 1] (not an earthquake). I ran this on fake input I generated myself, and it quickly converged to error 0. Thus, I decided to built a network for real data.

- My current network is a 2-layer, 10 neuron / 2 neuron sigmoidal network that also classified earthquake / not an earthquake. It trains in roughly 80 - 100 iterations (it's learning curve on training data it attached). It decimates full data from DataViewer by a factor of 256 in order to run faster.

- Next steps: currently, my greatest limitation is data - I can use US Geological Survey statistics to classify each earthquake (so that N = 10, rather than 2, for example), but I would like definite training data on people, cars, trucks, etc. for supervised learning, in order to develop those classes. Currently, however, the seismometers are being used for mine and Yaakov's triangulation project, so this may have to wait a few days.

Lab-Related Projects

- I apologize for all of the E-logs, but I changed the filters in the RMS system (to elliptic and butterworth filters) and changed the seismic.strip display file.

- I repositioned the seismometers so that Yaakov and I can triangulate signals and determine seismic noise hot-spots (as a side-project).

Right now I'm going to try for more classes based on USGS statistics, and I will also explore other data sources Den suggested.

 

Thanks for your help, everybody in 40m!

 

Attachment 1: Error.fig
  6957   Wed Jul 11 10:17:18 2012 SashaSummarySimulationsSURF - Week 2 and 3 - Summary

These past two weeks, I've been working on simulating a basic Fabry-Perot cavity.  I finished up a simulation involving static, non-suspension mirrors last week. It was supposed to output the electric field in the cavities given a certain shaking (of the mirrors), and the interesting thing was that it outputted the real and imaginary components seperately, so I ended up with six different bode plots. Since we're only interested in the real part, bodes 2, 4, and 6 can be discarded (see attachment 1). There was a LOT of split-peak behavior, and I think it has to do either with matlab overloading or with the modes of the cavity being very close together (I actually think the first is more likely since a smaller value of T_1 resulted in actual peaks instead of split ones).

At any rate, there really wasn't much I could improve on that simulation (neither was there any point), but I attach the subsystem governing the electric field in the cavity as a matter of academic interest (see attachment 2). So I moved onto simulations where the mirrors are actually suspended pendulums as they are in reality.

 

A basic simulation of the suspended mirrors gave me fairly good results (see attachment 3). A negative Q resulted in a phase flip, detuning the resonance from the wrong side resulted in a complete loss of the resonance peak, and the peak looked fairly consistent with what it should be. The simulation itself is pretty bare bones, and relies on the two transfer functions P(s) and K(s); P(s) is the transfer function for translating the force of the shaking of the two test masses (lumped together into one transfer function) into actual displacement. Note that s = i*w, where w is the frequency of the force being applied. K(s), on the other hand, is the transfer function that feeds displacement back into the original applied force-based shaking. Like I said, pretty bare bones, but working (see attachment 4 for a bode plot of a standard detuning value and positive Q). Tweaking the restoring (or anti restoring, depending on the sign of the detuning) force constant (K_0 for short) results in some interesting behavior. The most realistic results are produced for K_0 = 1e4, when the gain is much lower overall but the peak in resonance gets you a gain of 100 in dB.  For those curious as to where I got P(s) and K(s), see "Measurement of radiation-pressure-induced optomechanical dynamics in a suspended Fabry-Perot cavity" by Thomas Corbitt, et. al.

I'm currently working on a more realistic simulation, with frequency and force noise as well as electronic feedback (via transfer functions, see attachment 5). The biggest thing so far has been trying to get the electronic transfer functions right. Corbitt's group gave some really interesting transfer functions (H_f(s) and H_l(s) for short; H_f(s) gives the frequency-based electronic transfer function, while H_l(s) gives the length-based electronic transfer function), which I've been trying to copy so that I can reproduce their results (see attachment 6). It looks like H_l(s) is a lowpass Butterworth filter, while H_f(s) is a Bessel filter (order TBD). Once that is successful, I'll figure out what H_f(s) and H_l(s) are for us (they might be the same!), add in degrees of freedom, and my first shot at the OSEM system of figuring out where the mirror's position is.

 

Attachment 1: Screen_Shot_2012-07-11_at_9.44.34_AM.png
Screen_Shot_2012-07-11_at_9.44.34_AM.png
Attachment 2: Screen_Shot_2012-07-05_at_2.15.33_PM.png
Screen_Shot_2012-07-05_at_2.15.33_PM.png
Attachment 3: Screen_Shot_2012-07-11_at_9.56.27_AM.png
Screen_Shot_2012-07-11_at_9.56.27_AM.png
Attachment 4: Screen_Shot_2012-07-11_at_9.56.15_AM.png
Screen_Shot_2012-07-11_at_9.56.15_AM.png
Attachment 5: Screen_Shot_2012-07-11_at_10.12.15_AM.png
Screen_Shot_2012-07-11_at_10.12.15_AM.png
Attachment 6: Screen_Shot_2012-07-11_at_10.09.13_AM.png
Screen_Shot_2012-07-11_at_10.09.13_AM.png
  6956   Wed Jul 11 09:48:24 2012 LizSummaryComputer Scripts / ProgramsUpdate/daily summary testing

I have been working on configuration of the Daily Summary webpages and have been attempting to create a "PSL health" page.  This page will display the PMC power, the temperature on the PSL table and the PSL table microphone levels.  Thus far, I have managed to make the extra PSL tab and configure the graph of the interior temperature, using channel C1:PSL-FSS_RMTEMP.

I have been attempting to make a spectrogram for one of the PMC channels, but there is an issue with the spectrogram setup, as Duncan Macleod noted in ELOG 6686:

"At the moment a package version issue means the spectrogram doesn't work, but the spectrum should. At the time of writing, to use the spectrum simple add 'plot-dataplot2'."

 

 

Because of this issue, I have also been trying to make the spectrogram plots work.  Thus far, I have fixed the issue with one of the spectrogram plots, but there are several problems with the other four that I need to address.  I have also been looking at the microphone channels and trying to make the plot for them work.  I checked which microphone was on the PSL table and plotted it in matplotlib to make sure it was working.  However, when I tried to incorporate it into the daily summary pages, the script stops at that point!  It might simply be taking an excessively long time, but I have to figure out why this is the case.

                                                 (I am using channel C1:PEM-MIC_6_IN1_DQ, if this is blatantly wrong, please let me know!!)

 

The main point of this ELOG is that I have working test-daily summary pages online!  They can be found here:

https://nodus.ligo.caltech.edu:30889/40m-summary-test/archive_daily/20120710/

Also, if anyone has more requests for what they would like to see on the finalized summary pages site, please respond to this post or email me at: endavison@umail.ucsb.edu

  6955   Wed Jul 11 03:53:41 2012 yutaUpdateLSCBS 3.3 Hz motion on MI

It is not as dramatic as PRMI, but I could see BS 3.3 Hz motion at AS and REFL when MI is locked at dark fringe.
Below is uncalibrated spectra of REFLDC and ASDC when
  Red: MI is locked at dark fringe
  Blue: there's no light (PSL shutter closed)

We have to do something to get rid of this.

REFLDCASDCMIlocked.png

  6954   Wed Jul 11 02:25:11 2012 yutaUpdateLSCPRMI beam spot motion might be from PRM/BS motion

My hypothesis from the measurements below, to explain PRMI beam spot motion is;

  Stack motion at 3.3 Hz largely couples to BS and PRM angular motion.
  LSC for PRMI try to compensate this 3.3 Hz motion because they appear in the error signal.
  But since it's not length, failing and even adding more angular motion.

Some plots:
  1. Uncalibrated spectra of POPDC and ASDC when PRMI is locked. This tells you that beam motion seen at POP is 3.3 Hz.

  2. Uncalibrated spectra of feedback signal to BS and PRM. This tells you that LSC is actuating BS and PRM mainly at 3.3 Hz. I think this is because beam spot on PD moves at 3.3 Hz and so faking the error signal.

  3. Below left is uncalibrated spectra of BS, ITMX, ITMY, PRM (and ETMY) angular motion measured using oplevs. I centered oplevs on these optics (except ETMY, which was mis-aligned during PRMI lock). It looks like BS and PRM motion at 3.3 Hz is larger than other optics. Also, there's some coherence between POPDC and BS/PRM motion. We see some coherence with ITMs and even with ETMY, which is completely independent from PRMI. I think this is because 3.3 Hz motion is originated from the ground (stack) motion.

  left:  OLPITYAWandPOPDC4.png          right: OLPITYAWandPOPDCunlocked.png

  4. Above right is the same spectra, but when PRMI is not locked. It looks like there's no big change compared with PRMI locked. When locked, there's some excess for BS and PRM at ~1-3 Hz. I think this is from LSC feedback, which in principle, doesn't affect any angular motion.

Next:
  - Why BS and PRM has large 3.3 Hz peak compared with other optics?
  - Is 3.3 Hz peak effecting MI lock or arm lock?
  - How can we monitor PR2/3 angular motion?

Attachment 1: POPDCASDC4.png
POPDCASDC4.png
Attachment 2: Feedback4.png
Feedback4.png
  6953   Tue Jul 10 21:37:05 2012 yutaUpdateLSCPRMI glitch study

PRMI glitch certainly comes from power recylcing gain fluctuation.
I confirmed this by
  - Reading the value of POPDC at the time when there's glitch in error signals
      -> There was some threshold for POPDC to make a glitch
  - Look closer to the glitch
      -> It was oscillation in ~400Hz, where we have phase flip in PRCL/MICH servo

Next is to find why we have power recycling gain fluctuation. I want to see the correlation between alignment fluctuation of optics and POPDC.

Glitch analysis:
  Below is the plot of
   Red   PRCL error signal (C1:LSC-REFL33_I_ERR)
   Green MICH erorr signal (C1:LSC-AS55_Q_ERR)
   Blue  PRC intra-cavity power (C1:LSC-POPDC_OUT)
  when PRMI is carrier locked.

PRMIgilitch20120709.pngPRMIgilitch20120709_closer.png

  Time when there is a glitch in error signal is marked. Value of POPDC at that time is also marked. It looks like there's some threshold (dotted blue line).
  It sometimes doesn't show glitch even if POPDC is above the "threshold". It is maybe because of alignment fluctuation. Intra-cavity power gets high, but power at PDs get low, or vice versa.

  Right plot is closer look. Glitch is a sudden oscillation at ~400 Hz. It is the frequency where we have phase flip in PRCL/MICH openloop transfer function now(see elog #6950).

  6952   Tue Jul 10 17:47:55 2012 yutaUpdateSUSPRM oplevs fixed

I centetered PRM oplev, lowered gain and PRM oplev servo is not oscillating any more.
It is OK for more than a softball practice.

C1:SUS-PRM_OLPIT_GAIN = 0.15  (was 0.5)
C1:SUS-PRM_OLYAW_GAIN = -0.3  (was 0.7)

Openloop transfer function:
  Oplev Pitch: gain ~ 12 at 0.69 Hz resonance
  Oplev Yaw: gain ~ 18 at 0.83 Hz resonance
PRMoplevpitOLTF.pngPRMoplevyawOLTF.png

  I adjusted the gain so that oplev damps resonance as much as possible, but not introduce additional noise. I did no calculation, but just measured OSEM spectra (SUSPIT and SUSYAW). Below, you can see the noise reduces at resonance when oplev servo is on, and not increasing at other frequencies. It was introducing noise before. Someone should do more systematic adjustment of oplev servos for all the optics.

PRMOplevSpectra20120710.png
 

  6951   Tue Jul 10 10:50:02 2012 JamieConfigurationGeneralSeismometer repositioning

Quote:

Today I REPOSITIONED THE SEISMOMETERS in order to triangulate noise sources (as Rana suggested).

I re-levelled all of them, locked them, and turned them on. They should be located out of sight, but just in case:

GUR 1 IS DOWN THE X-ARM, behind the interferometer.

GUR 2 IS BETWEEN THE TWO ARMS, BEHIND THE CABLE TRAP THAT RUNS PARALLEL TO THE X-ARM.

STS 1 IS DOWN THE Y-ARM behind the interferometer.

I'll wait a day for them to stabilize (continuing to reset STS-1 every hour or so) and then begin taking data tomorrow morning, depending on the condition of the signal.

Ideally, I'd like a few days' worth of data, so I'll update when I've changed the configuration back to the way it was prior.  

 Highlighting good, ALL CAPS LESS SO!

  6950   Tue Jul 10 03:16:17 2012 yutaUpdateLSCPRMI got more stable a bit

I modified filiters for LSC_MICH and LSC_PRCL again to cope with power recycling gain fluctuation.
After some more alignment, power recycling gain increased (but still ~3.7). It fluctuates more than a factor of 2, and I began to see glitches again. So I needed more gain margin, as Koji pointed out.

I played around with filters, but I couldn't remove all the glitches. Gain margin now look OK in principle.
It looks like PRM motion is related. Since PRM doesn't have oplev now, I will see PRM oplev tomorrow.

New openloop transfer function:
 LSC_MICH
   UGF ~100 Hz, phase margin ~ 50 deg
   no phase flip in less than factor of ~5 gain change
   550 usec delay
 LSC_PRCL
   UGF ~100 Hz, phase margin ~ 70 deg (phase bump at UGF)
   no phase flip in less than factor of ~5 gain change
   550 usec delay
LSCMICHOLTF.pngLSCPRCLOLTF.png

Power recylcing gain:
  It is now ~3.7. It fluctuates pretty much. See time series data below when I locked PRMI. MICH and PRCL locks at the same time.

G = (1600-244)/(266-244)*0.06 = 3.7

PRMI20120709_2.png
 

  6949   Tue Jul 10 01:52:47 2012 KojiUpdateLSCPRMI got more stable a bit

The phase margins looks still too small.

Do You need such high gain at LF? This is not a high finesse cavity so can we sacrifice
some DC gain while gaining more phase around UGFs?

Otherwise, the gain fluctuation should be nicely compensated (i.e. fancy normalization).

  6947   Mon Jul 9 23:18:09 2012 yutaUpdateLSCPRMI got more stable a bit

I modified filiters for LSC_MICH and LSC_PRCL.
Although modes we can see at POP and AS look still bad, error signals are less glitchy than I see before (elog #6886).

Measured power recylcing gain for PRMI was 1.6 (??)

Openloop transfer function for LSC_MICH:
  UGF ~130Hz, phase margin ~30 deg
  550 usec delay
LSCMICHOLTF.png

APOLOGIES: I forgot "pi" in previous delay calculation. (I put notes on elogs #6940 and #6941)

Openloop transfer function for LSC_PRCL:
  UGF ~130Hz, phase margin ~30 deg
  550 usec delay
  A bump cam be seen in ~200 Hz. Coupling of DOFs?
LSCPRCLOLTF.png

Beam shape and motion:
   Below left is the Sensoray capture of AS/REFL/POP when PRMI is carrier locked.
ALL_1025928219_PRMIlocked3.pngPRMIbeammotion20120709.png

  Beam spot motion looks less bouncy than before, but it still shows motion mostly at ~3.3Hz. This might be from PRM motion. Above right is uncalibrated spectra of POPDC and REFLDC. You can see 3.3 Hz peak. This peak has some coherence with PRM motion measured by oplevs. I centered BS/PRM oplev to do this measurement.

Power recycling gain:
 - Definition and designed value
  Power recylcing gain is

G = (PRC intracavity power) / (incident power)

  When MI is perfectly symmetric, this can be written as

G  = (t_PRM/1-r_PRM*r_ITM)**2

  where t_i, r_i is amplitude transmissivity, reflectivity. Inserting the designed values;

 t_PRM = sqrt(0.0575)
 r_ITM = sqrt(1-0.014)

  designed power recycling gain for PRMI is

G = 44

 - Measurement
  POP power when PRM is misaligned and MI is locked at dark fringe is

P_mis = P_in * T_PRM * (1-T_PR3) * (1-T_ITM) * T_PR3

  POP power when PRMI is locked is

P_PR = P_intra * T_PR3

  So,

G = P_intra / P_in = (P_PR / P_mis) * T_PRM * (1-T_PR3) * (1-T_ITM) ~ (P_PR / P_mis) * 0.06

  I measured power of POP using C1:LSC-POPDC_OUT. It was 268 when PRM is misalined and MI is locked at dark fringe. Also, it was ~850 when PRMI is carrier locked. When closing PSL shutter, it was ~246. So,

G_PR = (850-246)/(268-246) * 0.06 = 1.6

  It looks too small.

  6946   Mon Jul 9 16:28:13 2012 MashaConfigurationGeneralSeismometer repositioning

Today I REPOSITIONED THE SEISMOMETERS in order to triangulate noise sources (as Rana suggested).

I re-levelled all of them, locked them, and turned them on. They should be located out of sight, but just in case:

GUR 1 IS DOWN THE X-ARM, behind the interferometer.

GUR 2 IS BETWEEN THE TWO ARMS, BEHIND THE CABLE TRAP THAT RUNS PARALLEL TO THE X-ARM.

STS 1 IS DOWN THE Y-ARM behind the interferometer.

I'll wait a day for them to stabilize (continuing to reset STS-1 every hour or so) and then begin taking data tomorrow morning, depending on the condition of the signal.

Ideally, I'd like a few days' worth of data, so I'll update when I've changed the configuration back to the way it was prior.

 

  6945   Mon Jul 9 15:05:00 2012 JenneUpdatePEMSeismometers being moved, new safety shower

[Masha, Jenne]

Masha is moving the seismometers, so they are all off right now.  Were they on, they would see a bunch of noise from the guy outside the 40m front door who is installing a safety shower.

  6944   Mon Jul 9 11:27:27 2012 JenneUpdateComputersc1oaf has been down for several days - BURT restore wasn't done correctly on startup

The c1oaf model hasn't been running for a few days (since the leap second problems we were having last week).  I had looked into it, but finally figured it out (with Jamie's help) today. 

The BURT restore has to be given to the model during startup, but for whatever reason it wasn't BURT restoring until *after* the model had already failed to start.  The symptoms were:  no 'heartbeat' for the oaf model, no connection to the fb, NO SYNC on the GDS screen, 0x4000.  the BURT restore button was green, which threw me off the scent, but that's just because it did, in fact, get set, just way too late.

I ended up looking in the dmesg of the lsc computer, and the last set of stuff was several lines of "[3354303.626446] c1oaf: Epics burt restore is 0".  Nothing else was written after that.  Jamie pointed out that this meant the BURT restore wasn't getting sent before the model unloaded itself and decided not to run.

The solution:  restart the model, and manually click the BURT restore button as soon as you're able (after everything comes back from being white).  We used to have to do this, but then there was a "fix", which apparently isn't super robust and failed for the oaf (even though it used to work just fine).  Bugzilla report submitted.

  6943   Mon Jul 9 10:52:48 2012 MashaUpdatePEMStripTools on Wall

The RMS signals generated by the updated filtering process are now on the wall. The NaN issue is gone it seems, and the template has been changed. Thanks for your help, Jenne. 

  6942   Mon Jul 9 05:15:46 2012 yutaUpdateGreen Lockinglocked MI while ALS using ASDC

I locked MI while both arm length are stabilized at IR resonance. This could be done using DC READOUT, in other words, use AS_DC as MICH error signal.
Lock using RF signals are still not successful.

FPMIALStrial20120709.png

  6941   Mon Jul 9 05:02:58 2012 yutaUpdateLockingadjusted ALS filters, current RMS

I adjusted filters of ALS to give more phase margin.
RMS of stabilized X/Y arm length is 97 pm and 65 pm respectively.

X arm ALS:
- Openloop transfer function
UGF ~160 Hz, phase margin 30 deg
1600 usec delay (LSC-XARM had 1800 usec delay)     500 usec delay (LSC-XARM had 570 usec delay) - Edited by Yuta on July 9

ALSXarmOLTF.png

- Arm length spectra
   Red is the free run spectrum. Measured using C1:ALS-BEATX_FINE_PHASE_OUT. Calibration factor is 1.32 nm/deg.
   Green is the out-of-loop spectrum. Measured using C1:LSC-POX11_I_ERR. Calibration factor is 3.8e12 counts/m.
   Blue is the in-loop spectrum. Measured using C1:ALS-BEATX_FINE_PHASE_OUT.
   Black is the expected spectrum from openloop transfer function, such as (free run)/|1+G|.
ALSXarmLengthspectra20120708.png


   Out-of-loop estimation of RMS during X ALS is 97 pm.
   RMS mostly comes from 1 Hz and 3.3 Hz peak.
   Out-of-loop and in-loop agrees at around 10-20 Hz.

Y arm ALS:
- Openloop transfer function
UGF ~130 Hz, phase margin 20 deg
2400 usec delay (LSC-XARM had 1800 usec delay)     760 usec delay (LSC-XARM had 570 usec delay) - Edited by Yuta on July 9

ALSYarmOLTF.png

- Arm length spectra
   Red is the free run spectrum. Measured using C1:ALS-BEATY_FINE_PHASE_OUT. Calibration factor is 1.30 nm/deg.
   Green is the out-of-loop spectrum. Measured using C1:LSC-POY11_I_ERR. Calibration factor is 1.4e12 counts/m.
   Blue is the in-loop spectrum. Measured using C1:ALS-BEATY_FINE_PHASE_OUT.
   Black is the expected spectrum from openloop transferfunction, such as (free run)/|1+G|.
ALSYarmLengthspectra20120708.png

   Out-of-loop estimation of RMS during X ALS is 65 pm.
   RMS mostly comes from 1 Hz and 3.3 Hz peak.
   Out-of-loop and in-loop agrees at around 3-40 Hz.

  6940   Sun Jul 8 19:31:53 2012 yutaUpdateLockingcharacterizing LSC arm lock by ALS error signal

RMS of X/Y arm length using POX/POY lock is <160 pm and <120 pm respectively. RMS of free swinging X/Y arm length is both 0.17 um.

I used ALS error signal for out-of-loop evaluation of IR lock. We can even use ALS error signal when arm is free swinging because phase tracking ALS error signal is linear to arm length.
ALS error signal might not be as good as POX/POY. So, this out-of-loop estimation might be not so good.

X arm lock using POX11:
- Openloop transfer function
   I adjusted filter (C1:LSC-XARM) gain and now, UGF ~150 Hz, phase margin ~20 deg.
  570 usec delay (number in the figure is wrong) - Edited by Yuta on July 9
LSCPOXarmIRlockOLTF.png

- Arm length spectra
   Red is the free run spectrum. Measured using C1:ALS-BEATX_FINE_PHASE_OUT, calibration factor in frequency is 9.81 kHz/deg (see elog #6938), so calibration factor is 1.32 nm/deg.
   Green is the out-of-loop spectrum. Measured using C1:ALS-BEATX_FINE_PHASE_OUT.
   Blue is the in-loop spectrum. Measured using C1:LSC-POX11_I_ERR, calibration factor is 3.8e12 counts/m (see elog #6841).
   Black is the expected spectrum from openloop transfer function, such as (free run)/|1+G|.
XarmLengthspectra20120708.png


  Out-of-loop estimation of RMS during POX lock is 160 pm. But since this looks too large, ALS error signal might not see actual arm length change when arm length is locked.
  Also, it is interesting that ALS error signal sees 24 Hz peak, but POX doesn't. Roll mode coupling to green?

Y arm lock using POY11:
- Openloop transfer function
   I adjusted filter (C1:LSC-YARM) gain and now, UGF ~150 Hz, phase margin ~20 deg.
  570 usec delay (number in the figure is wrong) - Edited by Yuta on July 9
LSCPOYarmIRlockOLTF.png

- Arm length spectra
   Red is the free run spectrum. Measured using C1:ALS-BEATY_FINE_PHASE_OUT, calibration factor in frequency is 9.65 kHz/deg (see elog #6938), so calibration factor is 1.30 nm/deg.
   Green is the out-of-loop spectrum. Measured using C1:ALS-BEATY_FINE_PHASE_OUT.
   Blue is the in-loop spectrum. Measured using C1:LSC-POY11_I_ERR, calibration factor is 1.4e12 counts/m (see elog #6834).
   Black is the expected spectrum from openloop transferfunction, such as (free run)/|1+G|.
YarmLengthspectra20120708.png


  Out-of-loop estimation of RMS during POY lock is 120 pm. But since this looks too large, ALS error signal might not see actual arm length change when arm length is locked.
  Also, it is interesting that ALS error signal sees 16.5 Hz peak, but POY doesn't. Bounce mode coupling to green?

Next:
  - Noise budgeting of phase tracking ALS
  - Is it possible to lock MI when RMS of arm length during POX/POY lock increased to ~100pm?

  6939   Sun Jul 8 00:58:08 2012 KojiSummaryLockingcalibrating phase tracking mode scan data

Quote:

FSR for X/Y arm are 3.97 +/- 0.03 MHz and 3.96 +/- 0.02 MHz respectively. This means X/Y arm lengths are 37.6 +/- 0.3 m and 37.9 +/- 0.2 m respectively.

These aren't so bad. (Look at this entry)

And interestingly the ETM curvatures are closer to ATF measurements than Coastline's measurement. (Look at wiki)

  6938   Sun Jul 8 00:27:54 2012 yutaSummaryLockingcalibrating phase tracking mode scan data

FSR for X/Y arm are 3.97 +/- 0.03 MHz and 3.96 +/- 0.02 MHz respectively. This means X/Y arm lengths are 37.6 +/- 0.3 m and 37.9 +/- 0.2 m respectively.
I calibrated the mode scan results using 11MHz sideband as frequency reference.
Calibration factor between the phase of the phase tracker and IR frequency is 9.81 +/- 0.05 kHz/deg for X arm, 9.65 +/- 0.02 kHz/deg for Y arm.

Calculation:
  For the mode scan measurements, we swept the phase of the phase tracker linearly with time. Previous calculation was done without calibrating seconds into actual IR frequency. The first order calibration can be done using modulation frequency as reference. Note that I'm still assuming our sweep was linear here.

  Relation between FSR and modulation frequency can be written in

f_mod = n * nu_FSR + nu_f

  where f_mod is the modulation frequency, n is an integer, nu_f = mod(nu_FSR,f_mod).
  nu_FSR and nu_f are measurable values (in seconds) from the mode scan. We know that f_mod = 11065910 Hz (elog #6027). We also know that nu_FSR is designed to be ~3.7 MHz(=c/2L). So, n = 2.
  We can calculate f_mod in seconds, so we can calibrate seconds into IR frequency.


Calibrating X arm mode scan:
  From the 8FSR mode-scan data (see elog #6859), positions of TEM00 and upper/lower 11 MHz sidebands in seconds are;

TEM00    242.00     214.76     187.22     159.27     131.33     102.96     74.61     46.00     17.51
upper    236.70     209.05     181.36     153.42     125.06      96.86     68.43     40.20
lower    220.35     192.96     165.03     136.98     108.92      80.65     52.25     23.90


  So, FSR and nu_f in seconds are;

FSR    27.24     27.54     27.95     27.94     28.37     28.35     28.61     28.49
nu_f   21.80     21.82     22.14     22.19     22.26     22.28     22.40     22.40


  By using formula above, modulation frequency in seconds are;

f_mod    76.28    76.90    78.04    78.07    79.00    78.98    79.62    79.38

  By taking average, FSR and f_mod in seconds are

FSR    28.1 +/- 0.2
f_mod    78.3 +/- 0.4

  We know that f_mod = 11065910 Hz, so conversion constant from seconds to frequency is

k1 = 0.1413 +/- 0.0007 MHz/sec

  We swept the phase by 3600 deg in 250 sec, so conversion constant from degree to frequency is

k2 = 9.81 +/- 0.05 kHz/deg

  Also, using k1, FSR for X arm is

FSR = 3.97 +/- 0.03 MHz

  This means, X arm length is

L = c/(2*FSR) = 37.6 +/- 0.3 m


Calibrating Y arm mode scan:
  From the 8FSR mode-scan data (see elog #6832), positions of TEM00 and upper/lower 11 MHz sidebands in seconds are;

TEM00    246.70     218.15     190.06     161.87     133.26     104.75     76.01     47.19     18.60
upper    240.86     212.78     184.32     155.73     127.23      98.48     69.78     41.26
lower    224.53     195.73     167.31     139.13     110.81      82.27     53.60     24.50


  So, FSR and nu_f in seconds are;

FSR    28.55     28.09     28.19     28.61     28.51     28.74     28.82     28.59
nu_f   22.44     22.57     22.60     22.61     22.47     22.48     22.50     22.68


  By using formula above, modulation frequency in seconds are;

f_mod    79.54    78.75    78.98    79.825    79.485    79.955    80.14    79.855


  By taking average, FSR and f_mod in seconds are

FSR    28.5 +/- 0.1
f_mod    79.6 +/- 0.2

  We know that f_mod = 11065910 Hz, so conversion constant from seconds to frequency is

k1 = 0.1390 +/- 0.0003 MHz/sec

  We swept the phase by 3600 deg in 250 sec, so conversion constant from degree to frequency is

k2 = 9.65 +/- 0.02 kHz/deg

  (k2 of X arm and Y arm is different because delay-line lengths are different)
  Using k1, FSR for X arm is

FSR = 3.96 +/- 0.02 MHz

  This means, X arm length is

L = c/(2*FSR) = 37.9 +/- 0.2 m


Summary of mode scan results:
X arm
  Mode matching    MMR = 91.2 +/- 0.3 % (elog #6859) Note that we had ~2% of 01/10 mode.
  FSR         FSR = 3.97 +/- 0.03 MHz (this elog)
  finesse    F = 416 +/- 6 (elog #6859)
  g-factor    g1*g2 = 0.3737 +/- 0.002 (elog #6922)

  length        L = 37.6 +/- 0.3 m (this elog)
  ETM RoC  R2 = 60.0 +/- 0.5 m (this elog and #6922; assuming ITM is flat)

Y arm
  Mode matching    MMR = 86.7 +/- 0.3 % (elog #6828) Note that we had ~5% of 01/10 mode.
  FSR         FSR = 3.96 +/- 0.02 MHz (this elog)
  finesse    F = 421 +/- 6 (elog #6832)
  g-factor    g1*g2 = 0.3765 +/- 0.003 (elog #6922)

  length       L = 37.9 +/- 0.2 m (this elog)
  ETM RoC R2 = 60.7 +/- 0.3 m (this elog and #6922; assuming ITM is flat)

  I think these are all the important arm parameters we can derive just from mode scan measurement.

  Every errors shown above are statistical error in 1 sigma. We need linearity check to put systematic error. Also, we need more precise calibration after that, too, if the sweep has considerably large non-linearity. To do the linearity check, I think the most straight forward way is to install frequency divider to monitor actual beat frequency during the sweep.

  6936   Sat Jul 7 17:28:11 2012 MashaUpdatePEMPEM no longer freaking out (as much).

Quote:

Hi everybody,

Sorry for flooding the ELOG about the PEM channels. Today I

- Changed all of the GUR1 and GUR2 filters to elliptic, and lowered the orders of their low-pass filters.

- Lowered the order of the low-pass filters on the STS channels

- Changed the parameters in seismic.strip, which I saved as MashaTemplate2.

 

Attached is the most recent status of the channels as seen with StripTools:

I'm not currently sure how to apply my template to seismic.strip shown on the wall (I saved it as seismic.strip on Pianossa and copied the old file to seismic.stripOld). I understand the job is being run on Megatron. I'll play around with this later tomorrow. (In other words, the display currently on the wall, while it does not have the Nan spikes like yesterday and this morning does not currently display the template I made).

  6935   Sat Jul 7 16:34:41 2012 MashaUpdatePEMPEM no longer freaking out (as much).

Hi everybody,

Sorry for flooding the ELOG about the PEM channels. Today I

- Changed all of the GUR1 and GUR2 filters to elliptic, and lowered the orders of their low-pass filters.

- Lowered the order of the low-pass filters on the STS channels

- Changed the parameters in seismic.strip, which I saved as MashaTemplate2.

 

Attached is the most recent status of the channels as seen with StripTools:

Attachment 1: Masha.png
Masha.png
  6934   Sat Jul 7 15:48:00 2012 MashaUpdatePEMCurrent PEM status

Quote:

Quote:

Hi everybody,

Last night I (with the help of Jenne and Jenne's advice - not to implicate her in this or anything) changed the filters for GUR1, GUR2, and STS in C1:PEM-RMS, adding a butterworth bandpass filter at each corresponding frequency band as well as a gain to convert from counts to micros/sec, and then adding a low pass filter in case of aliasing upon squaring.

Currently the seismic signals are going crazy, and producing "Nan" output on the strip graph (which leads to the instantaneously sharp spikes - which leads to the entire signal being filled on the visualizer on the wall). I checked the DataViewer output and the tdsdata output using both grep and wc, and it seems that both every single signal point is present and is a real number (also not a small real number, thereby debunking floating-point error). I'm currently not sure why seismic-strip reads out 'Nan' - perhaps because it's taking the log of 0, taking a negative log, taking the root of a negative number, or dividing by zero.

Does anyone know if the seismic-strip Nan issue is a program bug? If it's not (and therefore a filter bug), please let me know as well.

I'll be in lab for the rest of the night changing the butterworth filters to odd-order elliptic filters (at Rana's suggestion), as well as changing the cut-off frequency for the low-pass filters.

I'll E-log about it when I'm done.

Just to be sure that my numbers are correct - The STS, GUR1, and GUR2 channels all have gain 10, right? (I parsed through the e-log, and these seem to be the most recent numbers

Thanks for your help,

Masha

 

UPDATE: I changed all of the GUR1Z channels to order-5 elliptic filters. I approximated the attenuation for each one by setting the integral from _CutoffFrequency to 10^3 Hz of 10^(-Percent(f)/20) df to 0.01, where Percent(f) is a linear approximation of the relationship between the log of the frequency and the dB level (with the attenuation defining one of the points). Right now the Nan problem continues to persist, even after I loaded the coefficients. In Dataviewer, the channels look relatively normal for the past 10 minutes, as does the data when viewed with tdsdata.

 

 FIGURED IT OUT - THERE WAS A PROBLEM WITH THE LOW PASS FILTERS (TOO HIGH ORDER). FIXING IT NOW, SHOULD BE GOOD IN AN HOUR. 

  6933   Fri Jul 6 22:30:14 2012 MashaUpdatePEMCurrent PEM status

Quote:

Hi everybody,

Last night I (with the help of Jenne and Jenne's advice - not to implicate her in this or anything) changed the filters for GUR1, GUR2, and STS in C1:PEM-RMS, adding a butterworth bandpass filter at each corresponding frequency band as well as a gain to convert from counts to micros/sec, and then adding a low pass filter in case of aliasing upon squaring.

Currently the seismic signals are going crazy, and producing "Nan" output on the strip graph (which leads to the instantaneously sharp spikes - which leads to the entire signal being filled on the visualizer on the wall). I checked the DataViewer output and the tdsdata output using both grep and wc, and it seems that both every single signal point is present and is a real number (also not a small real number, thereby debunking floating-point error). I'm currently not sure why seismic-strip reads out 'Nan' - perhaps because it's taking the log of 0, taking a negative log, taking the root of a negative number, or dividing by zero.

Does anyone know if the seismic-strip Nan issue is a program bug? If it's not (and therefore a filter bug), please let me know as well.

I'll be in lab for the rest of the night changing the butterworth filters to odd-order elliptic filters (at Rana's suggestion), as well as changing the cut-off frequency for the low-pass filters.

I'll E-log about it when I'm done.

Just to be sure that my numbers are correct - The STS, GUR1, and GUR2 channels all have gain 10, right? (I parsed through the e-log, and these seem to be the most recent numbers

Thanks for your help,

Masha

 

UPDATE: I changed all of the GUR1Z channels to order-5 elliptic filters. I approximated the attenuation for each one by setting the integral from _CutoffFrequency to 10^3 Hz of 10^(-Percent(f)/20) df to 0.01, where Percent(f) is a linear approximation of the relationship between the log of the frequency and the dB level (with the attenuation defining one of the points). Right now the Nan problem continues to persist, even after I loaded the coefficients. In Dataviewer, the channels look relatively normal for the past 10 minutes, as does the data when viewed with tdsdata.

 

Attachment 1: MashaDV.png
MashaDV.png
  6932   Fri Jul 6 20:54:54 2012 MashaUpdatePEMCurrent PEM status

Hi everybody,

Last night I (with the help of Jenne and Jenne's advice - not to implicate her in this or anything) changed the filters for GUR1, GUR2, and STS in C1:PEM-RMS, adding a butterworth bandpass filter at each corresponding frequency band as well as a gain to convert from counts to micros/sec, and then adding a low pass filter in case of aliasing upon squaring.

Currently the seismic signals are going crazy, and producing "Nan" output on the strip graph (which leads to the instantaneously sharp spikes - which leads to the entire signal being filled on the visualizer on the wall). I checked the DataViewer output and the tdsdata output using both grep and wc, and it seems that both every single signal point is present and is a real number (also not a small real number, thereby debunking floating-point error). I'm currently not sure why seismic-strip reads out 'Nan' - perhaps because it's taking the log of 0, taking a negative log, taking the root of a negative number, or dividing by zero.

Does anyone know if the seismic-strip Nan issue is a program bug? If it's not (and therefore a filter bug), please let me know as well.

I'll be in lab for the rest of the night changing the butterworth filters to odd-order elliptic filters (at Rana's suggestion), as well as changing the cut-off frequency for the low-pass filters.

I'll E-log about it when I'm done.

Just to be sure that my numbers are correct - The STS, GUR1, and GUR2 channels all have gain 10, right? (I parsed through the e-log, and these seem to be the most recent numbers

Thanks for your help,

Masha

  6931   Fri Jul 6 14:10:31 2012 yutaSummaryLSCcalculation of FPMI using ALS

From calculation, phase fluctuation of reflected beam from length stabilized arm is not disturbing MI lock.

Easy calculation:
  The phase PD at AS port sense is

phi = phi_x - phi_y = 2*l_MICH*omega/c + (phi_X - phi_Y)

  where l_MICH is the Michelson differential length change, omega is laser frequency, phi_X and phi_Y are phase of arm reflected beam. From very complicated calculation,

phi_X ~ F/2 * Phi_X

  at near resonance. Where F is arm finesse, Phi_X is the round trip phase change in X arm. So,

phi = 2*l_MICH*omega/c + F/2 * 2*L_DARM*omega/c

  Our ALS stabilizes arm length in ~ 70 pm(see elogs #6835#6858). Finesse for IR is ~450. Considering l_MICH is ~ 1 um, MICH signal at AS port should be larger than stabilized DARM signal by an order of magnitude.

Length sensing matrix of FPMI:
  Calculated length sensing matrix of 40m FPMI is below. Here, I'm just considering 11 MHz modulation. I assumed input power to be 1 W, modulation index 0.1i, Schnupp asymmetry 26.6 mm. PRM/SRM transmissivity is not taken into account.

[W/m]     DARM      CARM      MICH
REFL_I    0         1.69e8    0
REFL_Q    7.09e1    0        -3.61e3
AS_I      0         0         0
AS_Q      1.04e6    0         3.61e3


  Maybe we should use REFL_Q as MICH signal, but since IQ separation is not perfect, we see too much CARM. I tried to lock MI with REFL11_Q yesterday, but failed.

  6930   Fri Jul 6 09:52:35 2012 steveUpdateVACpump down hick up

 I can not understand what really happened here with CC1 gauge or there was really a pressure glitch.

 

attachment 1,  pump down day 3 with 4th of July fireworks in the lab

attachment 2,  before and after vent in 9 days

 

 

Attachment 1: d3wFireworks.png
d3wFireworks.png
Attachment 2: pdhickup.png
pdhickup.png
  6929   Fri Jul 6 09:27:40 2012 steveUpdateVAC4 days at atm

 I'm looking for some movement indicators of the vent-pump down events.

 

Attachment 1: vent_moves.png
vent_moves.png
  6928   Fri Jul 6 09:00:34 2012 not ZachUpdateComputersNDS2 client now working on Ubuntu machines

Quote:

From my conversations with JZ and Leo, it seemed there was no package that generated the appropriate mex files. It was clear that the right ones weren't there from the absence of a /cvs/cds/caltech/apps/linux64/lib/matlab2010b directory. I'm sorry if I screwed anything up with pynds, but I have repeatedly asked for help with NDS2+matlab and no one has done anything.

It would be nice to do it via apt if there indeed is a versioned package that can make the mexs. Sorry again if I jumped the gun, but I didn't think anyone was going to do anything.

There is a package that provides the mex source, but it doesn't actually provide the mex binaries.  The problem is that the binary depends on the matlab version, so you can't possibly provide binaries for every version.

The solution is to just build the binaries from the source package.  We should put together a nice script that builds the binaries from the source, and installs them in the directory of your choosing.  If we get something nice working, we can probably get them to include it with the package, to make it easier in the future.

Here's what's included in the source package:

controls@pianosa:~ 0$ sudo apt-get install nds2-client-matlab
...
controls@pianosa:~ 0$ dpkg -L nds2-client-matlab | sort
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/nds2-client-matlab
/usr/share/doc/nds2-client-matlab/changelog.Debian.gz
/usr/share/doc/nds2-client-matlab/changelog.gz
/usr/share/doc/nds2-client-matlab/copyright
/usr/share/matlab
/usr/share/matlab/NDS2_GetChannels.m
/usr/share/matlab/NDS2_GetData.m
/usr/share/matlab/NDS_GetChannels.m
/usr/share/matlab/NDS_GetData.m
/usr/share/matlab/NDS_GetMinuteTrend.m
/usr/share/matlab/NDS_GetSecondTrend.m
/usr/share/matlab/src
/usr/share/matlab/src/NDS2_GetChannels.c
/usr/share/matlab/src/NDS2_GetData.c
/usr/share/matlab/src/NDS_GetChannels.c
/usr/share/matlab/src/NDS_GetData.c
/usr/share/matlab/src/nds_mex_utils.c
/usr/share/matlab/src/nds_mex_utils.h
controls@pianosa:~ 0$ 
  6927   Fri Jul 6 08:38:04 2012 steveUpdateComputerstime out

Why do we have these timing blanks?

Attachment 1: timingblanks.png
timingblanks.png
  6926   Fri Jul 6 02:46:03 2012 yutaUpdateLockingY arm ALS handing off to LSC

Handing off the servo from ALS to LSC for one arm is quite easy because servo filters are pretty much same for ALS and LSC. I demonstrated it Y arm during MI is locked.
We need DARM/CARM-kind of handing off in the near future.

What I did:
  1. Brought both arms to IR resonance.
  2. Brought X arm to off resonance.
  3. Locked MI in bright fringe(why can't I lock in dark fringe, when one arm is on resonance?) using AS55_Q and BS.
  4. Ran /opt/rtcds/caltech/c1/scripts/ALS/handofftoLSC.py Yarm to handoff. It decreases ALS gain and increases LSC gain in 30 sec ramp time. It also turns on some filters for LSC. Make sure you turn off filter triggers for LSC.

 Below is the plot of what I did. You can see LSC feedback signal gradually increasing and TRY getting more stable.
 I was dissapointed with ALS not having any DQ channels for feedback signal. I will make them DQ channels tomorrow.

handofftoLSC20120706.png

  6925   Fri Jul 6 01:39:56 2012 yutaUpdateLockingMI + Y arm ALS succeed, but not both

MI with X arm length stabilized off resonance and Y arm length stabilized at resonance using ALS succeed, but I couldn't bring X arm to IR resonance. This maybe because of too much phase fluctuation. I will calculate it later.

What I did:
  1. Brought X arm to IR resonance.
  2. Brought Y arm to IR resonance.
  3. Brought X arm to off-resonance.
  4. Brought Y arm to off-resonance. (1-4 are to play with arms)
  5. Locked MI in dark fringe using AS55_Q as error signal and BS as actuator.
  6. Brought Y arm to IR resonance. This flips sign, so MI lock will be bright fringe.
  7. Brought X arm to IR resonance. This destroys MI lock.

  Below is the plot showing what I did
FPMIALStrial20120706.png

  I also tried to lock MI after both arms are stabilized at resonance, but it failed, too.
  MI + X arm ALS fails. I think this is from too much BS motion to compensate phase fluctuation of arm reflected beam.
  MI + Y arm ALS fails when I want to lock in dark fringe. Only bright fringe works.


New compact MEDM screen for ALS:

  It has (almost) everything you need for ALS. It lives in /opt/rtcds/caltech/c1/medm/c1gcv/master/C1ALS_COMPACT.adl.
  Features;

  - Button for turning on/off ALS. It even does "clear history"!
      (light brown button "ON plus", "ON minus", "OFF"; runs /opt/rtcds/caltech/c1/scripts/ALS/easyALS.py; Currently, you have to guess the sign of gain. Ctrl-C if the sign was wrong. It will be nice if script can handle this. Use lockin to detemrine the sign?)

  - Button for finding IR resonance.
      (pink button "IRres"; runs /opt/rtcds/caltech/c1/scripts/ALS/findIRresonance.py)

  - Button for bringing arm length to off-resonance.
      (pink button "-10", "+10"; steps +/- 10 deg offset)

  - Button for toggling green shutters.
      (green button "shutter"; runs /opt/rtcds/caltech/c1/medm/c1gcv/cmd/toggle(X|Y)Shutter.py)

  - Button for switching monitors.
      (grey button "Video (X|Y)arm"; runs /opt/rtcds/caltech/c1/scripts/general/Video_(X|Y)arm.csh)

  - Slider for changing temperature of end lasers. You can also open temperature servo screens from orange "(X|Y)SLOW" button.

newALSMEDMscreen.png

  6924   Fri Jul 6 01:12:02 2012 JenneUpdateComputersc1sus is fine

Quote:

I was trying to use a new BLRMs c-code block that the seismic people developed, instead of Mirko's more clunky version, but putting this in crashed c1sus.

I reverted to a known good c1pem.mdl, and Jamie and I did a reboot, but c1sus is still funny - none of the models are actually running. 

rtcds restart all - all the models are happy again, c1sus is fine.

But, we still need to figure out what was wrong with the c-code block.

Also, the BLRMS channels are listed in a Daq Channels block inside of the (new) library part, so they're all saved with the new CDS system which became effective as of the upgrade.  (I made the Mirko copy-paste BLRMS into a library part, including a DAQ channels block before trying the c-code.  This is the known-working version to which I reverted, and we are currently running.)

 The reason I started looking at BLRMS and c1sus today was that the BLRMS striptool was totally wacky.  I finally figured out that the pemepics hadn't been burt restored, so none of the channels were being filtered.  It's all better now, and will be even better soon when Masha finishes updating the filters (she'll make her own elog later)

  6923   Thu Jul 5 16:49:35 2012 JenneUpdateComputersc1sus is funny

I was trying to use a new BLRMs c-code block that the seismic people developed, instead of Mirko's more clunky version, but putting this in crashed c1sus.

I reverted to a known good c1pem.mdl, and Jamie and I did a reboot, but c1sus is still funny - none of the models are actually running. 

rtcds restart all - all the models are happy again, c1sus is fine.

But, we still need to figure out what was wrong with the c-code block.

Also, the BLRMS channels are listed in a Daq Channels block inside of the (new) library part, so they're all saved with the new CDS system which became effective as of the upgrade.  (I made the Mirko copy-paste BLRMS into a library part, including a DAQ channels block before trying the c-code.  This is the known-working version to which I reverted, and we are currently running.)

  6922   Thu Jul 5 13:38:05 2012 yutaSummaryLockingcavity g-factor from mode scan

Cavity g-factor for X arm is 0.3737 +/- 0.002, Y arm is 0.3765 +/- 0.003.
If ITMs are flat and arm length L = 39 +/- 1 m, this means RoC of ETMX and ETMY is 62 +/- 2 m and 63 +/- 2 m respectively.

Calculation:
  Transverse mode spacing is expressed by

nu_TMS / nu_FSR = arccos(sqrt(g1*g2)) / pi

  where g1 and g2 is g-factor

gi = 1 - L/Ri

 of ITM/ETM.

  For mode-scan, we swept laser frequency nu. Let's assume this sweep was linear and we can replace laser frequency with time. From the mode-scan result, TMS can be derived by

  t_TMS = sum((n_i-n)*(t_i-t)) / sum((n_i-n)^2)

  where n_i is the order of transverse mode, n is average of n_i's, t_i is the time i-th order mode appeared and t is average of t_i's.
  Since I could only recognize up to 3rd order mode, this can be rewritten as

  t_TMS = 1.5/5 * t_0 + 0.5/5 * t_1 - 0.5/5 * t_2 - 1.5/5 * t_3

  FSR is time between TEM00s. So, g1*g2 can be calculated by

g1*g2 = (cos(pi*t_TMS/t_FSR))^2


X arm result:

  From the 8FSR mode-scan data (see elog #6859), X arm HOM positions in sec are;

HOM 0    242.00     214.76     187.22     159.27     131.33    102.96     74.61     46.00     17.51
HOM 1    234.29     206.78     179.20     150.96     122.90     94.58     66.27     38.10
HOM 2    226.36     198.91     170.80     142.92     114.62     86.51     58.05     29.65
HOM 3    218.14     190.65     162.71     134.78     106.68     78.27     49.95     21.25


  Calculated FSR and TMS in sec are;

FSR    27.24     27.54     27.95     27.94     28.37     28.35     28.61     28.49
TMS     7.951     8.020     8.193     8.151     8.223     8.214     8.220     8.270

  Calculated cavity g-factor are;

g1*g2    0.3699     0.3720     0.3662     0.3704     0.3761     0.3765     0.3839     0.3748

  By taking average,

g1*g2 = 0.3737 +/- 0.002  (error in 1 sigma)


Y arm result:
  From 8FSR mode-scan data (see elog #6832), Y arm HOM positions in sec are;

HOM 0    246.70     218.15     190.06     161.87     133.26    104.75     76.01     47.19     18.60
HOM 1    238.83     210.55     181.88     153.47     124.93     96.08     67.51     39.01
HOM 2    230.48     202.21     173.64     144.80     116.43     86.17     59.84     31.43
HOM 3    222.15     193.47     165.33     137.13     108.60     80.04     51.17     22.25


  Calculated FSR and TMS in sec are;

FSR    28.55     28.09     28.19     28.61     28.51     28.74     28.82     28.59
TMS     8.200     8.238     8.243     8.289     8.248     8.404     8.219     8.240


  Calculated cavity g-factor are;

g1*g2    0.3841     0.3657     0.3683     0.3765     0.3778     0.3683     0.3904     0.3811

  By taking average,

g1*g2 = 0.3765 +/- 0.003  (error in 1 sigma)


Conclusion:
  If ITMs are flat and arm length L = 39 +/- 1 m, this means RoC of ETMX and ETMY is 62 +/- 2 m and 63 +/- 2 m respectively. Designed RoC is 57.35 m.
  Error of RoC is dominated by arm length error. So, we need more precise measurement of the length. This can be done when scan is calibrated and we can measure FSR in frequency.
  Also, we need evaluation of linearity of the sweep. This also can be done by calibration.

  6921   Thu Jul 5 13:12:12 2012 ZachUpdateComputersNDS2 client now working on Ubuntu machines

From my conversations with JZ and Leo, it seemed there was no package that generated the appropriate mex files. It was clear that the right ones weren't there from the absence of a /cvs/cds/caltech/apps/linux64/lib/matlab2010b directory. I'm sorry if I screwed anything up with pynds, but I have repeatedly asked for help with NDS2+matlab and no one has done anything.

It would be nice to do it via apt if there indeed is a versioned package that can make the mexs. Sorry again if I jumped the gun, but I didn't think anyone was going to do anything.

I guess the only 32-bit machine I can think of is mafalda.

About tconvert, I think the best solution is to make a new wrapper M-file. gps was just a convenient remnant of mDV, but all that we need is some matlab function that can output a GPS time given a date/time string. We can use whatever command-line utility you want.

  6920   Thu Jul 5 12:27:05 2012 JamieUpdateCDSfront-end/fb communication lost, likely again due to timing offsets

Quote:

All the front-ends are showing 0x4000 status and have lost communication with the frame builder.  It looks like the timing skew is back again.  The fb is ahead of real time by one second, and strangely nodus is ahead of real time by something like 5 seconds!  I'm looking into it now.

This was indeed another leap second timing issue.  I'm guessing nodus resync'd from whatever server is posting the wrong time, and it brought everything out of sync again.  It really looks like the caltech server is off.  When I manually sync form there the time is off by a second, and then when I manually sync from the global pool it is correct.

I went ahead and updated nodus's config (/etc/inet/ntp.conf) to point to the global pool (pool.ntp.org).  I then restarted the ntp daemon:

  nodus$ sudo /etc/init.d/xntpd stop
  nodus$ sudo /etc/init.d/xntpd start

That brought nodus's time in sync.

At that point all I had to do was resync the time on fb:

  fb$ sudo /etc/init.d/ntp-client restart

When I did that daqd died, but it immediately restarted and everything was in sync.

  6919   Thu Jul 5 12:06:35 2012 JamieUpdateComputersNDS2 client now working on Ubuntu machines

What I did

NDS2 was not working on any of the machines, so the first thing I did was simply to install the newest version. I downloaded the latest tarball (0.9.1) from the LDAS Wiki, unzipped and installed it

/users/zach $ tar -xvf nds2-client-0.9.1.tar

/users/zach $ cd nds2-client-0.9.1

/users/zach $ sudo ./configure --prefix=/cvs/cds/caltech/apps/linux64 --with-matlab=/cvs/cds/caltech/apps/linux64/matlab/bin/matlab

/users/zach $ sudo make

/users/zach $ sudo make install

No no, this is totally unnecessary.  NDS2 was already installed on every machine from the official packaged releases (apt-get install nds2-client), and it's known to work fine. We use it with pynds all the time. If the matlab component is not working we should figure out the right way to fix it with the existing packages.

In general, please only manually install software as a very last resort.  Manually installed software doesn't get maintained, where as the officially packaged stuff is being actively maintained by the collaboration. If there is a problem with the distributed packaging we should report it and get it fixed (and hint I was the one who built the original Debian packaging for nds2, so I know how to fix all the issues).  I'm trying to bring the 40m out of the dark days of complete chaos, where random software was installed in random locations.

Even with the new version, it still didn't work. 

That's because this wasn't the problem!

Solution: The main problem was that the cyrus-sasl-gssapi authentication protocol was not installed on these machines, so that even with a kerberos ticket the datalink could not be established. Using information from the LDAS Wiki, I used aptitude to install it as:

$ sudo aptitude install lscsoft-auth

This group installs both the SASL protocol and the package python-kerberos

I also needed to update the kerberos config file for each machine, which is located at /etc/krb5.conf. I found that ottavia had a nice one with many realms, so I copied that one over to the other machines. In any case where there was an old config file overwritten, it is now /etc/krb5.conf.old.

Finally, the matlab path for NDS2 was still set to the old 2010a directory (/cvs/cds/caltech/apps/linux64/lib/matlab2010a) that was created by the NDS2 install when Rana originally did it. The new install I made above created the appropriate 2010b mexa64 files, so I changed the matlab path within matlab to this one:

>> rmpath /cvs/cds/caltech/apps/linux64/lib/matlab2010a

>> addpath /cvs/cds/caltech/apps/linux64/lib/matlab2010b

>> savepath

This sounds like it's more likely the issues. You did the right thing by going to apt to fix the authentication packages.  It's curious to me that you did that here, whereas you went totally out of band for the nds2 client stuff.  Why?

The matlab mex files are the other problem.  But there is also a nds2-client-matlab Debian/Ubuntu package for that as well.  The problem is that the package just distributes the source, and it needs to be compiled.  I'll help figure out a good way to do that.

  • I would like to extend this to the 32-bit machines, but I have to figure out the best way to install the proper NDS2 client without interfering with the 64-bit version. I think it is just a matter of specifying the matlabroot in the .../linux/ instead of .../linux64/

Again, this is handled by the packaging!  Just use apt and the right architecture is installed automatically.

But what 32 bit machines are you referring to?  I think basically everything is 64 bit nowadays.

  • It would be nice to find a way that the nice tool gps('MM/DD/YYYY XX:XX:XX UTC'), which calls the ligotool executable tconvert, can be automatically usable when calling NDS2 functions. Right now, there seems to be an issue preventing that: even though tconvert can be run in the terminal, gps() returns an error and even directly running unix('tconvert now') or !tconvert returns the same error. I have emailed Peter Shawhan to see if he has any advice. 

We are now using lalapps_tconvert for tconvert.  We're not using that ligotools crap anymore.  I've aliased that to tconvert on the command line, but maybe matlab isn't getting the message.  I'll try to think of a more robust solution (e.g. make a wrapper script).

  6918   Thu Jul 5 11:12:53 2012 JenneUpdateCDSfront-end/fb communication lost, likely again due to timing offsets

Quote:

All the front-ends are showing 0x4000 status and have lost communication with the frame builder.  It looks like the timing skew is back again.  The fb is ahead of real time by one second, and strangely nodus is ahead of real time by something like 5 seconds!  I'm looking into it now.

 I was bad and didn't read the elog before touching things, so I did a daqd restart, and mxstream restart on all the front ends, but neither of those things helped.  Then I saw the elog that Jamie's working on figuring it out.

  6917   Thu Jul 5 10:49:38 2012 JamieUpdateCDSfront-end/fb communication lost, likely again due to timing offsets

All the front-ends are showing 0x4000 status and have lost communication with the frame builder.  It looks like the timing skew is back again.  The fb is ahead of real time by one second, and strangely nodus is ahead of real time by something like 5 seconds!  I'm looking into it now.

  6916   Thu Jul 5 01:34:11 2012 yutaUpdateLockingMI with X arm ALS

I tried to lock FPMI using ALS, but I could not take care of ALS for both arms + MI. So, I decided to try one arm + MI.
I don't know why, but I couldn't make it. We need investigation.

Procedure I took:

  1. Align FPMI.

  2. Misalign ETMY.

  3. Press CLEAR HISTORY for C1:ALS-BEATY_FINE_PHASE filter module.
    Are there any command to do this?

  4. Stabilize X arm length.
    I made a script for turning on ALS servo nicely. It currently lives in /users/yuta/scripts/easyALS.py. You have to specify the arm(X or Y) and sign of the gain. It needs to be refined.

  5. Sweep the offset and stabilize X arm lenth to IR resonance.
   (Ran /opt/rtcds/caltech/c1/scripts/ALS/findIRresonance.py Xarm)

  6. Tried to lock MI. I tried to do this by feeding back the signal to BS or ITMs. Both worked fine when ALS holds X arm to IR off-resonance, but I couldn't lock MI when ALS holds X arm to IR resonance. This may come from too much phase fluctuation from X arm reflection. We should investigate this.

Handing off the servo from ALS to LSC:

  I made a script to do this. It just decreases ALS gain and increases LSC gain with 30 sec ramp time. It needs to be refined, so it currently lives in /users/yuta/scripts/handofftoLSC.py. It worked fine without loosing IR transmission.

ALS stability:
  Current stabiliy of the ALS servo is not enough. It doesn't stay for more than ~ 10min. I suspect this is from frequency servo of end lasers losing lock, or beat signals being too small for the beat box because of intensity fluctuation of green transmission. We definitely need to align end greens, but it is painful.

  6915   Thu Jul 5 01:20:58 2012 yutaSummaryCDSslow computers, 0x4000 for all DAQ status

ALS looks OK. I tried to lock FPMI using ALS, but I feel like I need 6 hands to do it with current ALS stability. Now I have all computers being so slow.

It was fine for 7 hours after Jamie the Great fixed this, but fb went down couple times and DAQ status for all models now shows 0x4000. I tried restarting mx_stream and restarting fb, but they didn't help.

  6914   Wed Jul 4 21:11:53 2012 yutaUpdateLockingFPMI in vacuum is back

I aligned FPMI and greens. There's no recognizable difference between before and after the vent.

What I did:
  1. Aligned Y arm to maximize Y green transmission.
  2. Used PZT1/2 to maximize TRY. But since PZT1 doesn't work so much, I had to align Y arm, too (mostly ETMY). This decreases green transmission, but I will leave it.
  3. Aligned BS and X arm to maximize TRX
  4. Fine tune them to minimize ASDC during FPMI lock, without decreasing TRX
  5. Aligned X end green to get TEM00 transmission.

Now, TRY and TRX are both  ~0.89.
Green transmission from Y and X arm are ~123 uW and ~275 uW respectively. Their max we got so far was ~200 uW and ~255 uW.
I still see clipped beam at AS, which I think is from the Faraday edge, as we found in elog #6897.
Below is the Sensoray capture of some ports, and MEDM screen shots to compare with before vent(see #6893).
There are two AS captures, one is without MI lock and the other is with MI lock. Note that PRM/SRM is misalined.

ALL_1025495266.pngMEDMscreenshotswithCOW_20120704.png


Next:
 - I will check ALS
 - I keep Y end green optics untouched since elog #6776, to use it as a reference. We need to realign them if tip-tilts are installed in vacuum, or PZTs are installed in both ends.

ELOG V3.1.3-