40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 53 of 337  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  6756   Tue Jun 5 20:42:59 2012 SureshSummaryIOOTip-Tilt Cabling

I have made a preliminary sketch of the cabling involved in connecting the Tip-tilt coil drivers.   This is a preliminary document. 

40m_Tip-tilt_cabling.png

 

 

  Required parts Quantity Solution
1) DAC Card inserted into C1IOO machine 1 buy or borrow from Cymacs
2) SCSI cable from DAC to D080303 box 1 buy or find at the 40m
3) D080303 box (SCSI to IDC breakout box) 1 Jay may have had spare, if not we have to make one
4) 40 pin IDC cables from D080303 to AntiImaging filter 2 Jay may have kept some stock if not make them
5) 10 pin IDC cables from Anti Imaging filters to Whitening filters 2 make
6) sma to lemo cables from Whitening to coil drivers 4x4=16 buy
7) 15pin IDC to 25pin DSub cables from drivers to feedthroughs on the chambers 4  (length?) make
8) 25pin DSub feedthrough on OMC chamber 1 check in 40m stock else buy
9) 25pin DSub  Kapton strip cable from OMC wall to table top 1 check if any spare are available in aLIGO stock
10) 25pin DSub Kapton strip cable from post to tip-tilt 4 aLIGO team said they have a few to spare if not buy
10) Quadrapus cables on the tip-tilts 4 Jamie is negotiating with aLIGO cable team

 

  6759   Tue Jun 5 22:39:06 2012 JenneSummaryIOOTip-Tilt Cabling

2 questions (so far) regarding your diagram / doc:

We are using 3 of the feed-throughs on the BS chamber, and 1 on the OMC chamber, even though we have 2 TTs on the BS table, 1 on the OMC table, and 1 on the IMC table? Just wanted to check.

Does your list / table at the bottom include all of the cables we already have, as well as the ones we need?  (Or maybe we just have nothing so far, so this is a moot question).

  6762   Wed Jun 6 01:23:32 2012 SureshSummaryIOOTip-Tilt Cabling

Quote:

2 questions (so far) regarding your diagram / doc:

We are using 3 of the feed-throughs on the BS chamber, and 1 on the OMC chamber, even though we have 2 TTs on the BS table, 1 on the OMC table, and 1 on the IMC table? Just wanted to check.

Does your list / table at the bottom include all of the cables we already have, as well as the ones we need?  (Or maybe we just have nothing so far, so this is a moot question).

 The scheme currently is to run a 25pin Kapton strip cable from BS to IMC table inside the chamber.  However we cannot do the same for the OMC table since it will cross the bellows which we often remove.  So we need to supply the one tip-tilt on the OMC table from outside.  I could not spot a spare unused feedthough on the OMC chamber.  We will have to swap one of the blank flanges for one with a few feed throughs.

We do not have any of the cables.   So everything listed has to be arranged for.   The pics are from the existing coil driver system on the SUS machine.

 

  6770   Wed Jun 6 19:46:46 2012 SureshSummaryIOOTip-tilt assembly: current status and work remaining

 

Recent History

The lower blades which I had given to the Physics Workshop for making a vacuum relief hole (using a sinker-EDM process) came back about ten days ago.   Merih Eken <meken@caltech.edu>,  the supervisor at the Physics Dept workshop, handled this matter for us.  The blades were sent to a local EDM machineshop and returned in about three working days ( a weekend intervened). 

IMG_0685.JPG  IMG_0687.JPG

Bob cleaned and handed them over to me yesterday evening.  

Current status

Today I have reassembled the four tip-tilts.  I have repacked them in clean bags (double bagged) shifted them to Clean Optics Cabinet (near the ETMX chamber).  The four tip-tilts are in the bottom-most shelf in the cabinet.  There are also some tip-tilt spares in a separate envelope.

Note:  The mirror holder is now held tightly by the eddy current dampers.  This was done for safety of the wires during transportation from LHO.  The eddy current damper in the front of the mirror has to be retracted to allow the mirror holder to swing free.  It has be to about 1mm away from the suspended mirror holder

Work Remaining

1) We need to install the quadrapus cables.  The connector placement on the BOSEM side will have some issues.  It is best to loosen the BOSEM seating as well as the connector seating screws and then push the cable connector into place.  Caution:  when the connector seating screws on the BOSEM are loosened the flexible ckt could be damaged by the loose connector.

2) Insert the mirrors into the mirror holders and balance the suspension such that the mirror's hang vertical and do not have a large yaw offset.

3) Adjust the wire suspension point height so that the flags are in the center of the BOSEM aperture.  Else they will strike against the

4) We need to adjust the position of the BOSEMs such that the shadow sensor signals are at 50%.  This ensures that all the magnets hang at an appropriate distance from their respective coils.

5) To do (3) we need to set up a shadow sensor read-out set-up for one tip-tilt (four sensors)

 

Attachment 2: IMG_0687.JPG
IMG_0687.JPG
  6775   Thu Jun 7 01:46:05 2012 yutaSummaryGreen LockingY green beat - found it!!

I found the big big Y green beat. Details will be posted later.

CIMG1504.JPG

  6817   Thu Jun 14 04:53:39 2012 yutaSummaryGreen Lockingdesigning ALS loop for mode scan

[[Requirement]]
 Arm cavity FWHM for IR is

  FWHM = FSR / F = c/(2LF) = 8 kHz.

 In cavity length, this is

  L/f * FWHM = 40m/(c/1064nm) = 1.2 nm

 So, to do mode scan nicely, arm length fluctuation during resonant peak crossing should be much less than 1.2 nm.


[[Diagram]]
 Let's consider only ADC noise and seismic noise.
ALSloop.png

* S: conversion from Y arm length to the beat frequency

  dL/L = df/f

 So,

  S = df/dL = f/L = c/532nm/40m = 1.4e7 MHz/m


* W: whitening filter

 We set it to flat gain 50. So,

  W = 50


* D: AD conversion of voltage to counts

 D = 2^16counts/20V = 3300 counts/V


* B: frequency to voltage conversion of the beatbox.

 We measured BWD(elog #6815). When we measured this, W was 10. So, the calibration factor at 0 crossing point(~ 50 MHz) is

  B = 1400*0.048/10/D = 0.0021 V/MHz


* A: actuator transferfunction

 I didn't measure this, but this should look like a simple pendulum with ~ 1 Hz resonant frequency.


* n_ADC: ADC noise

 ADC noise is about

  n_ADC = sqrt(2*LSB^2*Ts) = sqrt(2*(20V/2^14)**2*1/64KHz) = 1.6 uV/rtHz


* n_seis: seismic noise

 We measured this by measuring C1:ALS-BEATY_COARSE_I_IN1. This is actually measuring

  D(WBSn_seis + n_ADC)

 Calibrated plot is the red spectrum below.


* F: servo filter (basically C1:ALS-YARM)

 We need to design this. Stabilized arm length fluctuation is

  x_stab = 1/(1+G)*n_seis + G/(1+G)*n_ADC/(WBS)

 where openloop transferfunction G = SBWDFA.
 Below ~ 50 Hz, n_seis is bigger than n_ADC/(WBS). We don't want to introduce ADC noise to the arm. So, UGF should be around 50 Hz. So, we need phase margin around 50 Hz.
 We also need about 10^3 DC gain to get the first term comparable to the second term.

 Considering these things, openloop transferfunction should look like the below left. Expected error signal when ALS on is the below right. I put some resonant gain to get rid of the peaks which contribute to the RMS (stack at 3.2Hz, bounce at 16.5 Hz).
 Inloop RMS we get is about 0.3 nm, which is only 4 times smaller than FWHM.
ALSopenloop.pngyarmlength.png



[[Discussion]]
 We need to reduce RMS more by factor of ~ 30 to get resolusion 1% of FWHM.
 Most contributing factor to the RMS is power line noise. We might want comb filters, but it's difficult because UGF is at around this region.

 So, I think we need more fancy whitening filters. Currently, we can't increase the gain of the whitening filter because SR560 is almost over loading. Whitening filter with zero at 1 Hz might help.

  6828   Mon Jun 18 02:31:43 2012 yutaSummaryGreen Lockinganalysis of mode scan data

I analyzed mode scan data from last week.
Mode matching ratio for Y arm is 86.7 +/- 0.3 %. Assuming we can get rid of TEM01/10 by alignment, this can be improved up to ~ 90%.

Peak search, peak fitting and finnesse calculation:
  I made a python script for doing this. It currently lives in /users/yuta/scripts/modescanresults/analyzemodescan.py.
  What it does is as follows

  1. Read mode scan data(coarse5FSRscan.csv, fine1FSRscan.csv). Each column in the data file should be

[time] [some thing like C1:ALS-BEAT(Y|X)_(COARSE|FINE)_(I|Q)_IN1] [C1:LSC-POY11_I_ERR] [C1:LSC-TRY_OUT]

Each separated by comma. Currently, this script uses only TRY, but it reads all anyway

  2. Find peak in TRY data. For the peak search, it splits data in 1 sec and find local maximum. If the local maximum is higher than given threshold, it recognize it as a peak. If two peaks are very close, it uses higher one. This sometimes fails, because mode scan data we have is not so nice.

  3. Fit each peak with Lorentzian function,

TRY = a*b/(4*(t-c)^2+b^2) + d  (a>0, b>0)

  where a/b is a peak height, b is a linewidth (FWHM), c is a peak position in time, and d is a offset.
  I don't like this, but currently, a/b+c is fixed to the maximum value of TRY data used for fitting. This is because sometimes TRY data is so bad and I couldn't get the peak height correctly. Each points of TRY data doesn't have same error because cavity length is fluctuating and relation between cavity length and TRY is not linear. I think I should use some weighting for the fit, but currently, I just use least squares.

  4. Find TEM00 and calculate FSR in "seconds". I just used "seconds" assuming we did a linear sweep. This script recognize TEM00 from the given threshold.

  5. Calculate finesse using FSR and linewidth of the closest TEM00.

  Below are the result plots from this analysis. Calculated finesse looks quite high (~1000). I think this is from non-linearity in the sweep and error in "measured" line width.
coarse5FSRscan.pngfine1FSRscan.png


Higher order modes and RF sidebands:

  Assuming the curvature of ITMY/ETMY are flat/57.5 m, Y arm length is 38.6 m(FSR 3.9 MHz), positions of HOMs and RF sidebands(11/55 MHz) in frequency domain should look like the plot below.
  The script for calculating this currently lives in /users/yuta/scripts/modescanresults/HOMRFSB.py, inspired by Yoichi's script for KAGRA
HOMRFSB.png

Mode-matching ratio:
  By comparing mode scan data and HOM/RF SB positions in a sophisticated way, you can tell which peak is which.
coarse5FSRscanHOMRFSB.png


  From COARSE 5FSR measurement, peak heights are

TEM00 0.884, 0.896, 0.917, 0.905, 0.911
TEM01 0.040, 0.037, 0.051, 0.054, 0.062
TEM02 0.083, 0.078, 0.079, 0.071, 0.078
TEM03 0.018, 0.015, 0.013, 0.015, 0.014

  So the mode-matching ratio is

MMR = 86.2 %, 87.3 %, 86.5 %, 86.6 %, 85.5 %

  From FINE 1FSR measurement, peak heights and mode matching ratio is

TEM00 0.921
TEM01 0.031
TEM02 0.078
TEM03 0.014

MMR = 88.2 %

  Assuming each measurement had same error, mode-matching ratio from these 6 values is

MMR = 86.7 +/- 0.3 %  (error in 1 sigma)

  This can be improved by ~5% by alignment because we still see ~5% of TEM01/10. Study in systematic errors on going.

  6830   Mon Jun 18 17:28:03 2012 yutaSummaryComputersbugs in CDS_PARTS/simLinkParts/Fcn

Fcn module in CDS_PARTS is used to include a user defined function in a model.
We should be able to use this by entering desired function, but I found some bugs.

BUG1: Fcn doen't work without ";"

If you put ";" after the function, we can compile.

 sin(u[1]);

But if you put without ";", like

 sin(u[1])

you get the following error message when compiling.

controls@c1ioo
~ 0$ rtcds make c1gcv
### building c1gcv...
Cleaning c1gcv...
Done
Parsing the model c1gcv...
Done
Building EPICS sequencers...
Done
Building front-end Linux kernel module c1gcv...
echo >> target/c1gcvepics/README.making_changes
echo 'Built on date' `date` >> target/c1gcvepics/README.making_changes
make[1]: Leaving directory `/opt/rtcds/caltech/c1/rtbuild'

make[1]: Entering directory `/opt/rtcds/caltech/c1/rtbuild/src/fe/c1gcv'
make -C /lib/modules/2.6.34.1/build SUBDIRS=/opt/rtcds/caltech/c1/rtbuild/src/fe/c1gcv modules
make[2]: Entering directory `/usr/src/linux-2.6.34.1-cs'
  CC [M]  /opt/rtcds/caltech/c1/rtbuild/src/fe/c1gcv/c1gcv.o
make[2]: Leaving directory `/usr/src/linux-2.6.34.1-cs'
make[1]: Leaving directory `/opt/rtcds/caltech/c1/rtbuild/src/fe/c1gcv'
/opt/rtcds/caltech/c1/rtbuild/src/fe/c1gcv/c1gcv.c: In function 'feCode':
/opt/rtcds/caltech/c1/rtbuild/src/fe/c1gcv/c1gcv.c:615: error: expected expression before ';' token
make[3]: *** [/opt/rtcds/caltech/c1/rtbuild/src/fe/c1gcv/c1gcv.o] Error 1
make[2]: *** [_module_/opt/rtcds/caltech/c1/rtbuild/src/fe/c1gcv] Error 2
make[1]: *** [default] Error 2
make: *** [c1gcv] Error 1


BUG2: sindeg doesn't work properly

sindeg should work as cosine with input in degrees.
I made a simple model to test this(below).
model_sindegbug.png


Output of the filter module C1:ALS-BEATY_FINE_PHASE goes to "PHASE_in"
sindeg of this goes to C1:ALS-BEATY_FINE_I_ERR
cosdeg of this goes to C1:ALS-BEATY_FINE_Q_ERR

If you sweep the phase input, you should get sin and cos, but you get the following.
cosdeg (C1:ALS-BEATY_FINE_Q_ERR) looks OK, but sindeg (C1:ALS-BEATY_FINE_I_ERR) looks funny. It looks like ~20000 is its period.

dv_sindegbug.png

  6839   Wed Jun 20 18:00:10 2012 ranaSummaryPSLsummaries

 Nice PSL summaries from LHO:

https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=3187

  6861   Sat Jun 23 19:57:22 2012 yutaSummaryComputersc1ioo is down

I tried to restart c1ioo becuase I can't live without him.

I couldn't ssh or ping c1ioo, so I did hardware reboot.
c1ioo came back, but now ADC/DAC stats are all red.

c1ioo was OK until 3am when I left the control room last night. I don't know what happened, but StripTool from zita tells me that MC lock went off at around 4pm.

  6865   Mon Jun 25 10:35:59 2012 JenneSummaryComputersc1ioo is down

Quote:

I tried to restart c1ioo becuase I can't live without him.

I couldn't ssh or ping c1ioo, so I did hardware reboot.
c1ioo came back, but now ADC/DAC stats are all red.

c1ioo was OK until 3am when I left the control room last night. I don't know what happened, but StripTool from zita tells me that MC lock went off at around 4pm.

 c1ioo was still all red on the CDS status screen, so I tried a couple of things.

mxstreamrestart (which aliases on the front ends to sudo /etc/init.d/mx_stream restart) didn't help

sudo shutdown -r now didn't change anything either....c1ioo came back with red everywhere and 0x2bad on the IOP

eventually doing as Jamie did for c1sus in elog 6742, rtcds stop all, then rtcds start all fixed everything.  Interestingly, when I tried rtcds start iop, I got the error
Cannot start/stop model 'iop' on host c1ioo, so I just tried rtcds start all, and that worked fine....started with c1x03, then c1ioo, then c1gcv.

  6867   Mon Jun 25 11:27:13 2012 JamieSummaryComputersc1ioo is down

Quote:

Quote:

I tried to restart c1ioo becuase I can't live without him.

I couldn't ssh or ping c1ioo, so I did hardware reboot.
c1ioo came back, but now ADC/DAC stats are all red.

c1ioo was OK until 3am when I left the control room last night. I don't know what happened, but StripTool from zita tells me that MC lock went off at around 4pm.

 c1ioo was still all red on the CDS status screen, so I tried a couple of things.

mxstreamrestart (which aliases on the front ends to sudo /etc/init.d/mx_stream restart) didn't help

sudo shutdown -r now didn't change anything either....c1ioo came back with red everywhere and 0x2bad on the IOP

eventually doing as Jamie did for c1sus in elog 6742, rtcds stop all, then rtcds start all fixed everything.  Interestingly, when I tried rtcds start iop, I got the error
Cannot start/stop model 'iop' on host c1ioo, so I just tried rtcds start all, and that worked fine....started with c1x03, then c1ioo, then c1gcv.

There seems to be a problem with how models are coming up on boot since the upgrade.  I think the IOP isn't coming up correctly for some reason, which is then preventing the rest of the models from starting since they depend on the IOP.

The simple way to fix this is to run the following:

ssh c1ioo
rtcds restart all

The "restart" command does the smart thing, by stopping all the models in the correct order (IOP last) and then restarting them also in the correct order (IOP first).

  6870   Mon Jun 25 16:21:10 2012 KojiSummaryIOOSelection of motorized mirror mounts

I am considering to have 3 to 6 motorized optical mounts at the PSL and end tables for remote beam steering.

Question 1:

Was there any issue on the PI 3-axis PZT on the PSL?
Why was it disabled (even before the PSL upgrade)?


Question 2:

Do we need two mount at a place? Or we do have one instead?

- Comparing the distance of the steering mirrors and that from the steering mirror to the cavity waist, induced shift
is mostly cancelled by angle adjustemnts of a either of the mounts.
i.e. Induced misalignments by the steering mirrors are nearly degenerated.

We need to move two steering mirrors only for the initial installation, but any drift felt by a cavity can be compensated by a single mirror.

Question 3:
Do we like PI-style 2 or 3 axis PZT mount with analog inputs on the HV amp?
Or do we like "Newport Agilis" style controller with USB connection?

Any opinion?

  6874   Tue Jun 26 01:30:13 2012 yutaSummaryGreen Lockingsimultaneous hold and release of the arm (aka two arm ALS)

To get the feeling of the master of IFO, I;

1. Stabilized both arm length using ALS.

2. Ran findIRresonance.py for both arms and find what offset gives me IR resonances.

3. Holded X arm to IR resonance, holded Y arm to IR resonance, and released both arms.

Below is the time series data of what I did.
ALSboth20120625_2withAS.png


Issues:
 - Currently ALS is not stable enough. It only stays for about few minutes. I think it is because of the bad alignment of green from each end.
 - We can't tell end green frequency is higher or PSL green frequency is higher. So, the sign of the servo filter sometimes flips.
 - Wobbliness of X end green transmission beam spot was from the ETMX oplev. When the oplev servo is on, it got more wobbly when X end table is opened. But when the oplev servo was off, wobbliness was same even if the presence of air flow.
 - MICH contrast in plot above seems like it somehow got better when two arms are at resonance by ALS. I think this is not real because reflection from both arms at AS port was not well aligned and beam was clipped. Koji and I measured contrast of FPMI and MI(ETMs misalined), and they were 99.6 % and 99.9 % respectively. Beam clipping seems like it comes from some where between BS to AS port. We need to figure out where and fix this.

Things need to be done to make ALS more concrete:
 - Align Y end green beam!
 - Look into Y end green frequency servo
 - How do we hand-off servo using ALS to IR lock?
 - Noise budgeting for new phase tracker scheme
 - Linearity check of the beat box and phase tracker

  6876   Wed Jun 27 03:43:52 2012 yutaSummaryIOOhow to improve mode matching to arms

From the mode scan measurements of the arms(elog #6859), ~6% of mode-mismatch comes from 2nd-order mode. That means we have longitudinal mismatch.

Suppose every mirrors are well positioned and well polished with designed RoC, except for the MMT1-MMT2 length. To get ~6% of mode-mismatch, MMT1-MMT2 length should be ~28cm longer (or ~26cm shorter) than designed value.
I don't know whether this is possible or not, but if they are actually longer(or shorter), we should fix it on the next vent.
I found some related elog on MMT (see #3088).

modematchMCtoARM_design.pngmodematchMCtoARM_MMT1MMT2longer.png


RoC and length parameters I used is below. They maybe wrong because I just guessed them. Please tell me the actual values.
Mirror thickness and effect of the incident angle is not considered yet.

== RoCs ==
MC2 19.965 m (???)
PRM 115.5 m (not used in calculation; just used to guess MC parameters)
ITM flat
ETM 57.37 m

== Lengths ==
MC round trip 27.084 m (???)
MC1 - MC3  0.18 m (???)
MC3 - MMT1 0.884+1.0442 m
MMT1 - MMT2 1.876 m
MMT2 - PRM 2.0079+0.4956 m
PRM - ITM 4.4433+2.2738 m
ITM - ETM 39 m

  6877   Wed Jun 27 10:27:09 2012 ranaSummaryIOOhow to improve mode matching to arms

The MC waist is correct as is the arm RoCs. Most likely the error is in the telescope length or its distance from the MC. Jenne probably has all the numbers and can give us a surface plot showing how the MM degrades as a function of those two parameters.

  6880   Wed Jun 27 11:35:06 2012 SashaSummaryComputer Scripts / ProgramsSURF - Week 1 - Summary

I started playing with matlab for the first time, accurately simulated a coupled harmonic oscillator (starting from the basic differential equations, if anyone's curious), wrote a program to get a bode plot out of any simulation (regardless of the number of inputs/outputs), and read a lot.

I'm currently going through the first stage of simulating an ideal Fabry-Perot cavity (I technically started yesterday, but yesterday's work turned out to be wrong, so fresh start!), and other than yesterday's setback, its going okay.

I attached a screenshot of my simulation of the pitch/pendulum motion of one of the mirrors LIGO uses. The bode plots for this one are turning out a little weird, but I'm fairly certain its just a computational error and can be ignored (as the simulation matlab rendered without the coupling was really accurate - down to a floating point error). I have also attached these bode plots. The first bode is based on the force input, while the second is based on the torque input. It makes sense that there are two resonant frequencies, since there ought to be one per input.

 

Attachment 1: Screen_Shot_2012-06-27_at_11.27.10_AM.png
Screen_Shot_2012-06-27_at_11.27.10_AM.png
Attachment 2: Screen_Shot_2012-06-27_at_11.26.57_AM.png
Screen_Shot_2012-06-27_at_11.26.57_AM.png
Attachment 3: Screen_Shot_2012-06-27_at_11.27.29_AM.png
Screen_Shot_2012-06-27_at_11.27.29_AM.png
  6881   Wed Jun 27 14:12:44 2012 EricSummaryGeneralSURF Week 1

I started work familiarizing myself with the ELOG and some of the control systems at the 40m. I spent a fair bit of time gaining some general knowledge of the interferometer, control systems, calibration, null instruments, etc. On Friday, June 22 Yaakov and I spent the afternoon pulling cables for the beatbox that Jamie had finished up. We were able to get the cables from the rack containing the beatbox routed to the control room.

Then I started work on calibrating the beatbox. I set up the function generator to send a sine wave into the beatbox, then sent the signal from the beatbox to the oscilloscope. I compared both the input sine wave and the output from the beatbox at many frequencies, taking peak to peak measurements. I'm working on using the data to calibrate the beatbox now.

  6882   Wed Jun 27 14:18:30 2012 Yaakov SummarySTACISFirst week summary

The beginning of my first week was spent at various orientations and safety meetings, some for general SURF and some more specific to LIGO and the lab. In between these I started  work.

Jenne and I took out the spare STACIS and took it apart, taking out the circuit boards. I've spent some time looking through the boards and sketching various parts of the board in trying to understand the exact function without any useful technical diagrams (STACIS supplied us only with a picture of the board without components, not all that helpful). I think I now at least understand the basic block diagram of the circuitry: the STACIS geophone signal goes through a preamplifier and filters (the semi-circular board), and converts it into a signal for the PZT stacks. This signal then goes through a high voltage amplifer, and then goes to the five PZTs (3 in the z, one each in the x and y direction). The unit I am looking at has an extension board, which allows us to tap into the signal going into the preamp and the one leaving it. This should allow us to input our own signal instead of the geophone signal, and thereby drive the PZTs ourselves.

My next step, once I get a resistor to replace a burnt one on the high voltage amplifier, is to take a transfer function of the STACIS and see if it is possible to drive the PZT stacks with the cables from the extension board. If that does not work, I'll have to keep tracing the circuit to determine where to input our own signal.

  6900   Sun Jul 1 23:48:15 2012 yutaSummaryGeneralclipping at BS, my plan

[Koji, Yuta]

We aligned PRMI and inspected BS chamber. Last inspection by Jamie and I (see elog #6897) was done when nothing is aligned, so I wanted to see the difference.
Aligning PRMI at low power was difficult for me, because I see no fringe at ASDC PD nor REFLDC PD. I just aligned them by looking at AS/REFL camera. The beam shape at AS looked as bad as when the usual power.

No significant change was found inside the vacuum. We still see clipping at the Faraday, and also, we saw clipping by BS coil holder. Using PZT1, we could make it better, but this might be causing PRC problem -- BS is inside the PRC, too.

We also took some pictures of PR3 and PRM(attached). The arrow pointing HR is correctly pointing inside the PRC. Seeing is believing.

Yuta's plan:
  We might have to avoid clipping at BS (and Faraday) by aligning input optics inside the vacuum. If we are going to align them, I think we should start from centering MC beam spot positions and the whole alignment could take more than a week. I don't want to spend too much time on the alignment. Also, we are going to install tip-tilts on the next big vent, so we have to redo the alignment anyway.
  So, my plan is as follows;

1. Take lots of photos and close the door on Monday(June 2).

2. Pump on Tuesday(June 3).

3. Restart working on ALS. For example, demonstration of FPMI using ALS.

4. We also can do some characterization of PRC, like measuring power recycling gain for PRMI/PRFPMI, mode scan for PRC using AUX laser from AS port, and so on. We need some calculation for clipping tolerance, too.

  Any objections?

Attachment 1: PR3.JPG
PR3.JPG
Attachment 2: PRM.JPG
PRM.JPG
  6901   Mon Jul 2 00:41:13 2012 ranaSummaryGeneralclipping at BS, my plan

 

 Start pumping on Monday before Steve goes home.

  6902   Mon Jul 2 10:45:25 2012 JenneSummaryGeneralclipping at BS

Quote

No significant change was found inside the vacuum. We still see clipping at the Faraday, and also, we saw clipping by BS coil holder. Using PZT1, we could make it better, but this might be causing PRC problem -- BS is inside the PRC, too.

 Yuta just told Jamie and I that when he and Koji were looking at things yesterday, they saw that the beam spot was roughly at the center of the PRM, but was clipping on the lower OSEM holder plate on the BS.  This indicates that the beam spot on the BS is much too low.  The easiest way I can see this happening is poor pitch pointing with the tip tilts, which we unfortunately don't have active control over.

Recall elog 3425, where I mentioned some pretty bad pitch pointing after a TT was moved from the cleanroom, to the chamber, back to the cleanroom.  I think that we may need to check the pitch pointing at the chamber before installing tip tilts in the future.

  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.

  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.

  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.

  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.

  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)

  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

  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
  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
  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.

  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
  6984   Wed Jul 18 09:44:13 2012 MashaSummaryGeneralWeek Summary

This week, I continued to work with my Artificial Neural Network. Specifically, I implemented a 3-hidden layer sigmoidal, gradient-descent supervised network, with 3 neurons in the final output layer, since I have introduced a new class, trucks. I have overcome my past data limitation, since I observed that there is a multitude of trucks that comes between 9 and 10 am, and thus I have observed a bunch of trucks after the fact (their seismic patterns are rather distinct, and thus there could prove to be a very large supply of this data - I have gathered data on the past 50 days so far, and have gathered 60+ truck patterns).

With 3 classes, the two-layer network converges in ~200 epochs, while the 3-layer network takes around ~1200 (and more time per iteration). Since the error gradients in the stochastic gradient descent are recursively calculated, the only real time limitation in the algorithm is just lots of multiplication of weight / input vectors, lots of computation of sigmoidal functions, and lots of data I/O (actually, since the sigmoidal function is technically an exponentiation to a decimal power and a division, I would be curious to know if theory or Matlab has any clever ways of computing this faster that can be easily implemented - I will look into this today). Thus, the networks take a long time to train. I'm currently looking at optimizing the number of layers / number of neurons, but this will be a background process for at least several days, if not the next week. In the greater scope of things, however, training time isn't really a problem, since the actual running of the algorithm requires only one pass through the network, and the network should be as well-trained as possible. However, due to the fact that I am only here until the end of August, it would be nice to speed things up.

As far as other classifications, I can simulate signals either by dropping the copper block from the Stacis experiment, or by applying transfer functions to general seismic noise. However, I would like more real data on noise sources, but the only other one plausible to LIGO that I can currently think of (cars don't show up very well) is the LA Metro. Perhaps I will take a day to clock trains as they come in (since the schedule is imprecise) and see if there is any visible seismic pattern.

I also, with the help of Yaakov, Jenne, and Den, now have three working, triangulated seismometers, which can now begin taking triangulation data (the rock tumblers are still working, so there should be opportunities to do this), both to find hot-spots as Rana suggested, and to measure the velocity and test out my algorithm, as Den suggested.

 

  6985   Wed Jul 18 09:53:20 2012 SashaSummarySimulationsSURF - Week 4 - Summary

This past week, I've been working on moving forward with the basic cavity model I developed last week (for future reference, that model was FP_3, and I am now working on FP_4) and refining the suspensions. I added three degrees of freedom to my simulation (such that it now consists of yaw, pitch, displacement, and side-to-side motion) and am attempting to integrate them with the OSEMS. I have also added mechanical damping for all degrees of freedom, and am adding electric damping and feedback. Concerning that, are all of the degrees of freedom locally damped in addition to being actuated on by the control system? Or does the control system do all of the damping itself? The first is the way I'm working on setting it up, but can easily change this if needed.

The next iteration of FP (FP_5) will replace my complicated OSEM --> Degrees of Freedom and vice versa system with the matrix system (see the poster Jenne and Jamie made, "Advanced Suspension Diagnostic Procedure"), as well as adding bounce/roll, yaw/y coupling, various non-damping filters as needed (i.e. the a2f filters), and noise sources. However, I'll only move on to that once I'm sure I have FP_4 working reasonably well. For now at least, the inputs/outputs look fine, and some of the DOF show resonance peaks. I'll become more concerned about where these resonance peaks actually are once I add damping.

Attached is a screenshot my work in progress. Only one of the suspensions has a basic feedback/damping loop going (as a prototype). It looks complicated now, but will simplify dramatically once I have damping worked out. Pink inputs are noises (will probably replace those with noise generators in FP_5) and green inputs are the OSEMS. The red output is the displacement of the cavity from resonance. The blue boxes are suspensions.

Attachment 1: Screen_Shot_2012-07-18_at_9.50.26_AM.png
Screen_Shot_2012-07-18_at_9.50.26_AM.png
  6990   Wed Jul 18 15:38:05 2012 EricSummarySimulationsSURF Update

Most of my work has been on continuing to develop the Simulink model of the differential arm length control loop.
I have filled in transfer functions for the digital components after looking up the configuration of filters and
gains on the control screens. Filters that were active at the time included 1:50 and 1000:10 on C1LSC_YARM and
C1LSC_POY11 with a gain of 0.1. Jamie also introduced me to foton so that I could obtain the transfer functions
for the necessary filters. I have also continued to work on obtaining the open loop gain and length response
function from the model. The majority of the work now is to refine what I've accomplished so far. Adding details
to the arm cavity and the optics is one potential area for improvement.

I have also spent some time looking at real-time calibration methods from GEO and a proposal for a similar system
on LIGO in P040057-x0 from the DCC. While the work for this project may follow a different path for a real-time
calibration, having a sense for what's been accomplished so far should be helpful in working on a new system.

  7001   Mon Jul 23 07:39:55 2012 Ryan FisherSummaryComputer Scripts / ProgramsAlterations to base epics install for installing aLIGO conlog:
Note: The Conlog install instructions that I started from were located here:
https://awiki.ligo-wa.caltech.edu/aLIGO/Conlog
  7022   Wed Jul 25 10:31:33 2012 SashaSummarySimulationsSURF - Week 5 - Summary

This week I've been working on refining my simulation and getting it ready to be plugged into the control system. In particular, I've added a first attempt at a PDH control system, matrix conversion from OSEMs to DOF and back, and all necessary DAC/ADC/AA/AI/whitening/dewhitening filters. Most of these work well, but the whitening filters have been giving me trouble. At one point, they were amplifying the signal instead of flatting it out, such that my simulation started outputting NaN (again).

This was wholeheartedly depressing, but switching out the whitening filters for flat ones seemed to make the problem go away, but brought another problem to light. The output to input ratio is minuscule (as in 10^-300/10^243, see Attachment 3 for the resulting bode plot between a force on the suspension pt in the x-direction and my two outputs - error signal and length signal, which is pretty much what you would expect it to be). I suspect that its related to the whitening filter problem (perhaps the dewhitening filter is flattening the signal instead of amplifying?). If that is the case, then switching the whitening/dewhitening filters ought to work. I'll try today and see what happens. The white/dewhite filters together result in a total gain of 1, which is a good fundamental test, but could mean absolutely nothing (i.e. they could both be wrong!). Judging from the fact that we want to flatten out low frequency signal when it goes through the whitening filter, the filters don't look switched (see Attachment 4 for a bode plot of white and dewhite).

The only other source of problems (given that the suspensions/local damping have been debugged extensively throughout this process - though they could bug out in conjunction with the cavity controls?) is the PDH system. However, separating each of the components showed that the error signal generated is not absurd (I haven't tested whether it makes sense or not, but at any rate it doesn't result in an output on the order of 10^-300).

In summary, I've made progress this week, but there is still far to go. Attachment 1 is my simulation from last week, Attachment 2 is my simulation from this week. A talk with Jamie about the "big picture" behind my project helped tremendously.

Attachment 1: Screen_Shot_2012-07-24_at_10.46.05_AM.png
Screen_Shot_2012-07-24_at_10.46.05_AM.png
Attachment 2: Screen_Shot_2012-07-24_at_10.45.43_AM.png
Screen_Shot_2012-07-24_at_10.45.43_AM.png
Attachment 3: Screen_Shot_2012-07-25_at_10.16.58_AM.png
Screen_Shot_2012-07-25_at_10.16.58_AM.png
Attachment 4: Screen_Shot_2012-07-25_at_10.25.27_AM.png
Screen_Shot_2012-07-25_at_10.25.27_AM.png
  7025   Wed Jul 25 11:34:31 2012 EricSummarySimulationsSURF Update

I am continuing work on simulating the DARM control loop. There is now a block for the length response
function
that allows one to recover the h(t) GW input to the model. However, in order to add this
block I had to add some artificial poles to the length response function beacuse Simulink gave me errors
when the transfer function had more zeros than poles. The artificial poles are at 10^6 Hz and higher, so
that they should not affect the response function at the lower frequencies of interest. This approach
appears a bit computationally unstable though because without changing any parameters and re-running
the simulation, a different magnitude for h(t) would be calculated sometimes. A different method may be
necessary to get this working more accurately
.

By looking through the C1LSC Simulink model and the C1LSC control screens, Jenne helped me determine
which digital filters are active while the interferometer is locked
. To do this, open the C1LSC control
screen, then open the trigger matrix. Inside the trigger matrix window there is a button titled Filter
Module Triggers which opens another window that indicates which filters are triggered for a given channel,
and what values trigger them. For the y arm servo filters FM2, 3, 6, 7, 8 are triggered while in lock and
FM4 and 5 are controlled manually; I am including all of these in the model now. 

I have changed the way I manipulate the output from the model for analysis, using Rana's advice. I also
improved the plotting code, now using a custom Bode plot instead.

Attached is a screenshot of the Simulink model as it currently stands, and an older implementation of the
open loop gain
. I am in the process of updating the servo filters now, and what is shown in the plot does
not include all the filter modules for the servo filter.

 

 

Attachment 1: DARM_control_loop_hendries.PNG
DARM_control_loop_hendries.PNG
Attachment 2: OLG_old_hendries2.png
OLG_old_hendries2.png
  7028   Wed Jul 25 14:35:45 2012 SashaSummarySimulationsSURF - Week 5 - Summary

Quote:

This week I've been working on refining my simulation and getting it ready to be plugged into the control system. In particular, I've added a first attempt at a PDH control system, matrix conversion from OSEMs to DOF and back, and all necessary DAC/ADC/AA/AI/whitening/dewhitening filters. Most of these work well, but the whitening filters have been giving me trouble. At one point, they were amplifying the signal instead of flatting it out, such that my simulation started outputting NaN (again).

This was wholeheartedly depressing, but switching out the whitening filters for flat ones seemed to make the problem go away, but brought another problem to light. The output to input ratio is minuscule (as in 10^-300/10^243, see Attachment 3 for the resulting bode plot between a force on the suspension pt in the x-direction and my two outputs - error signal and length signal, which is pretty much what you would expect it to be). I suspect that its related to the whitening filter problem (perhaps the dewhitening filter is flattening the signal instead of amplifying?). If that is the case, then switching the whitening/dewhitening filters ought to work. I'll try today and see what happens. The white/dewhite filters together result in a total gain of 1, which is a good fundamental test, but could mean absolutely nothing (i.e. they could both be wrong!). Judging from the fact that we want to flatten out low frequency signal when it goes through the whitening filter, the filters don't look switched (see Attachment 4 for a bode plot of white and dewhite).

The only other source of problems (given that the suspensions/local damping have been debugged extensively throughout this process - though they could bug out in conjunction with the cavity controls?) is the PDH system. However, separating each of the components showed that the error signal generated is not absurd (I haven't tested whether it makes sense or not, but at any rate it doesn't result in an output on the order of 10^-300).

In summary, I've made progress this week, but there is still far to go. Attachment 1 is my simulation from last week, Attachment 2 is my simulation from this week. A talk with Jamie about the "big picture" behind my project helped tremendously.

 Here's a screenshot of what's going on inside the cavity (Attachment 1). The PDH/mixer system outputs 0 for pretty much everything except really high numbers, which is the problem I'm trying to solve now. I assumed that the sidebands were anti-resonant, calculated reflection coefficient F(dL) = Z * 4pi * i/(lambda), where Z = (-r_1 + r_2*(r_1^2 + t_1^2)/(1 - r_1*r_3)), then calculated P_ref = 2*P_s - 4sqrt(P_c*P_s) * Im(F(dL)) * sin(12.5 MHz * t) (this is pictured in Attachment 2), then mixed it with a sin(12.5MHz * t) and low-passed it to get rid of everything but the DC term (this is pictured in Attachment 3), which is the term that then gets whitened/anti-aliased/passed through the loop.

 

Attachment 1: Screen_Shot_2012-07-25_at_2.20.01_PM.png
Screen_Shot_2012-07-25_at_2.20.01_PM.png
Attachment 2: Screen_Shot_2012-07-25_at_2.20.15_PM.png
Screen_Shot_2012-07-25_at_2.20.15_PM.png
Attachment 3: Screen_Shot_2012-07-25_at_2.20.29_PM.png
Screen_Shot_2012-07-25_at_2.20.29_PM.png
Attachment 4: Screen_Shot_2012-07-25_at_2.23.05_PM.png
Screen_Shot_2012-07-25_at_2.23.05_PM.png
  7064   Wed Aug 1 10:38:11 2012 EricSummaryGeneralSURF Update

Since my last update I have modified the DARM control loop model to the extent that it resembles the
measured open loop transfer function much more closely
. The phase especially is much more accurate, with
a phase margin of about 35 degrees at the unity gain frequency of 156 Hz. Right now I'm normalizing to
the unity gain frequency still to adjust the gain properly. Using the length response function from the
model, I can calibrate the error signal as well to find the simulated h(t) output. There were a number of
computational problems in calculating the length response function, but I eventually found a work-around.
Attached is an updated plot of the open loop transfer function and the length response function of the model.

This week Jamie showed me around the real-time Simulink models as well. The one specific to my project
is c1cal.mdl
. It takes the output in the form of the error and control signals from c1lsc.mdl as its
input and produces the calibrated signal as output. In order to produce the calibrated signal we need the actuation
function and the inverse of the sensing function for the model as it stands now. We also built, installed,
and restarted the c1cal model because no data was showing up in data viewer, but the problem remained
after this attempt. 

Jamie and I also started on calibrating the interferometer in the traditional way. Jamie aligned the beam
splitter and the input test masses so we could take free-swinging Michelson measurements. However, taking
the data with the nds system appears to be giving different results than what is showing up in data viewer.
The goal of this measurement is to get a value for the peak to peak amplitude of the Michelson error signal.

Attachment 1: OLG_hendries.png
OLG_hendries.png
Attachment 2: Length_response_hendries.png
Length_response_hendries.png
  7065   Wed Aug 1 10:45:38 2012 SashaSummarySimulationsSURF - Week 6 - Summary

This week, I worked on transferring my Simulink simulation to the RCG. I made all relevant library parts, now under "SASHA library" in the main Simulink library browser. My main concern has been noises - I've added some rudimentry shot noise, amplitude noise, phase noise, and intensity noise. I have yet to add local oscillator noise, and plan to upgrade the existing noises to actually have the PSD they should (using equations from Rana's and Robb Ward's theses). I'm fairly certain this can be achieved by applying the correct transfer function to white noise (a technique I learned from Masha this week!), so the RCG should be able to handle it (theoretically).

I've also been tweaking my main simulation. After a brief (but scary) attempt at adding optical levers, I decided to shelve it in order to focus on noises/RCG simulating. This is not permanent, and I plan to return to them at some point this week or next. My main problem with them was that I knew how to get from optical lever input to pitch/yaw, but had no idea how to get from pitch/yaw to optical lever input. If I had a complete basis for one in terms of the other, I'd be able to, but I don't think this is the way to go. I'm sure there is a good way to do it (it was done SOMEHOW in the original simulation of the suspensions), I just don't know it yet.

In the aftermath of the optical lever semi-disaster, my simulation is once again not really outputting anything, but since it actually worked before adding the optical levers, I'm pretty sure I can get it to work again (this is why its important to use either git or BACKUPS, >.< (or both)).

We also wrote our progress reports this week. Mine includes some discussion on the basics of cavities/the mechanics of the suspensions/brief intro to PDH, and I'll add a section on noises in the next draft. Maybe this'll be of some use to someone someday? One can only hope.

 

 

  7066   Wed Aug 1 11:46:16 2012 MashaSummaryGeneralWeek Summary

 A lot of my time this week was spent struggling with implementing my neural network code in Simulink in order to experiment with using neural network control systems, as Rana suggested. Perhaps I'm inept at S-Functions, but I decided try to use the Model Reference Controller block in Simulink instead of my own code, and experiment with using that to control a driven, damped harmonic oscillator with noise. The block consists of two neural networks, one which is trained on a model of the plant to simulate the plant, and one that it trained on a reference model (which, in my case, is just input -> gain 0 -> output since my desired signal for now is 0. So far, I have managed to adjust the parameters enough to stop the neural network controller from outputting too much force (this causing the amplitude of the oscillator to increase with each iteration), but outputting enough to keep the plant oscillating with a maximal displacement of 2 m/s (with 30 neurons, 100 reference time delays, and 100 plant output time delays). I will continue to work on this, especially with added noise sources, and see how feasible it is to train such a controller to actually perform well.

control.png

20-100-100-Perform.png

As far as classification, I took up that project again, and realized that I have been approaching it the wrong way the whole time - instead of using a neural network to classify an entire time series, I could just classify it online using a recurrent neural network. This, however, meant that my data (which used to be in packets of 900 seconds) had to be parsed through to generate time-dependent desired output vectors. I did this last night, and have been trying various combinations of neuron numbers, time delays, and learning parameters this morning. Below is my current best result for mean square error with time, obtained with 1 neuron in the hidden layer, 50 time delays (so that there are actually 51 neurons feeding into the hidden layer, and a subnetwork of 50 neurons connected to 50 neurons, and learning parameter 0.7). The peak is due to the fact that a large amount of sharp earthquakes occur around that time, essentially giving the neural network a surprise, and causing it to rapidly learn. However, I suspect this sharp rise would decrease if I were to stop decimating my data by a factor of 256, and using all of the inputs as they come in (this, however would be drastically slower). Currently, I have a massive loop running which tries different combinations of neurons and time delays.

1-50-0.7.png

 

In terms of other lab stuff, Jenne and I ordered parts to make a cable for Gurlap-1, and I updated the pin map for Gurlap-1. Also, I wrote my progress report.

 

  7068   Wed Aug 1 11:54:59 2012 YaakovSummarySTACISGeophone calibration and open loop gains

This week I've looked into finding an accurate sensitivity for the geophones in the STACIS. I found that when placing a geophone and accelerometer side by side, and using the sensitivity values I had from spec sheets, the readings were very different (see eLog 7054: http://nodus.ligo.caltech.edu:8080/40m/7054).

I cut the shunt resistor off one of the STACIS geos and found it to be 4000 Ohm, which is one of the standard values for this geophone model. When it is connected to the geophone the net resistance is 2000 Ohm (I took a more careful measurement, I took the geophone out). Then the internal coil resistance should be 4000 Ohm, if they are connected in parallel. However, the geophone spec sheet does not have a sensitivity value for this exact scenario, so I'll have to find a different way to determine the calibration (maybe by putting it next to a seismometer with a known sensitivity). So I know for sure that the sensitivity value I was originally using is wrong, because it assumed an internal coil resistance of 380 Ohm, but I have to check if the value I found by forcing the geophones to agree with the accelerometers (eLog 7054 --> 0.25 (m/s)/V) is correct.

I've also been looking again at the open loop gains of the STACIS (see eLog 7058: http://nodus.ligo.caltech.edu:8080/40m/7058). Attached is what TMC, which makes the STACIS, says it should look like (with a 4000 lb load on the STACIS). Today I am taking the open loop gains into higher frequencies to get a better comparison, but the plots look quite similar to what I have so far. So if it is an unstable open loop gain, then it's at least not new.

Attachment 1: 08011201.pdf
08011201.pdf 08011201.pdf
  7078   Thu Aug 2 11:09:52 2012 EricSummaryLSCFree-Swinging Michelson Measurements

To take the free swinging Michelson measurements for the interferometer calibration Jamie aligned the beam splitter with ITMX and ITMY. I recorded the GPS time (1027827100 and for several hundred seconds later) when the Michelson was aligned in order to look at the correct data. I then copied the python script nds-test.py from Jamie, and modified it to take and plot data from C1:LSC-AS55_Q_ERR_DQ offline. I used dataviewer to verify that C1:LSC-AS55_Q_ERR_DQ and C1:LSC-AS55_Q_ERR were recording the same signal, and to check that I was taking the correct data with NDS. Taking data online worked as well, but it was easier to use a time when the Michelson was known to be free-swinging and take data offline. Attached is some sample data while free-swinging, with time in GPS time.

Attachment 1: free_swing_MICH.png
free_swing_MICH.png
  7116   Wed Aug 8 11:16:06 2012 SashaSummarySimulationsSURF - Week 7 - Summary

This week, I brought my c1lsp model online and fixed up some the medm screens for c1spx. Along the way, I ran into a few interesting problems (and learned a bit about bash scripting and emacs! :D). The screens for the main TM_RESP matrix are not generating automatically, and the medm screens don't want to link to the channels, for some reason. I don't have this problem with the other matrices (i.e. C2DOF and SEN_OUT), so I think it has something to do with TM_RESP being a filter matrix (which the others are not). In addition, the noise overview medm screens for c1spx are practically nonexistent - someone just copied the file for the SUS-ETMX screens into the master directory for c1spx, so they need a complete overhaul. I am willing to do this, but Jamie told me to focus my attentions elsewhere.

So I went back to noise generation. I've been using Matlab to figure out how to recreate the various noise sources (laser amplitude noise, local oscillator phase/amplitude noise, and 60 Hz/ADC. Frequency noise will be added some time this week and seismic noise should be already covered in Jamie's suspension model) in my c1lsp model. I'm doing it the way the RCG does it - by applying a filter to white noise. I'm generating white noise by just using a random number generator and pwelch-ing it to get the power spectral density.

For the filters themselves, I picked z, p, k such that it shaped the white noise PSD to look like the PSD of the noise in question. This was fairly straightforward once I figured out how zeroes and poles affected PSD. Once I'd picked zpk, I applied a bilinear transform to get a discrete zpk out, then converted to a second order section to make computation faster. I then applied that to the white noise (matlab has a convenient "sosfilt" function) and pwelch-ed/graphed it to get the result.

Attached is my attempt at filtering white noise to look like 60 Hz. noise. I can't seem to find a way to pick z and p such that the peak is more narrow (i.e. other than having two complex conjugated poles at 60 Hz.). I took the spectrum of 60 Hz. noise from a terminated ADC channel (Masha kindly let me borrow one of her GURALP channels).

EDIT: I also remembered that I've been looking for how to get a good power spectrum for the rest of the noises. Jenne referred me to Kiwamu's work on this, and I'm mostly going off elog #6133. If you have any other good elogs/data on noises, please feel free to send them my way.

I then measured the PSD of the sensors on the real suspended optics and a PSD of the suspension model. It looks like the OSEMs on the suspension model are only reading white noise, which probably means a lost connection somewhere (Attachment 2 is what the model SHOULD produce, Attachment 3 is what the model ACTUALLY produces). I perused Jamie's model, but couldn't find anything. Not sure where else to check, but I'll continue thinking about it/trying to fix it.

Attachment 1: Screen_Shot_2012-08-06_at_9.20.02_PM.png
Screen_Shot_2012-08-06_at_9.20.02_PM.png
Attachment 2: Screen_Shot_2012-08-08_at_11.13.55_AM.png
Screen_Shot_2012-08-08_at_11.13.55_AM.png
Attachment 3: Screen_Shot_2012-08-08_at_11.08.23_AM.png
Screen_Shot_2012-08-08_at_11.08.23_AM.png
  7117   Wed Aug 8 11:46:09 2012 MashaSummaryGeneralWeek Summary

The main thing that I did this week was write a C block that, given static weights, would classify seismic signals (into one of three categories - Earthquake, Truck, Quiet). I have successfully debugged the C block so that it works without segmentation faults, etc, and have made various versions - one that uses a recurrent neural network, and one that uses a time-delayed input vector (rather than keeping recurrent weights). I've timed my code, and it works very fast (to the point where clock() differences in <time.h> are 0.000000 seconds per iteration). This is good news, because it means that operations can be performed in real-time, whether we are sampling at 2048 Hz, or, as Rana suggested, 256 Hz (currently, my weights are for 256 Hz, and I can decimate the incoming signal which is at 2048 Hz right now).

In order to optimize my code, since at the core it involves a lot of matrix multiplications, I considered how the data is actually stored in the computer, and attempted to minimize pointer movement. Suppose you have an array in C of the form A[num_row][num_col] - the way this array is actually stored on the stack or heap is row_1 / row_2 / row_3 / ... / row_num_row, so it makes sense to move across a matrix from left to right and then down (as though reading on a page). Likewise, there's no efficient algorithm for matrix multiplication which is less that O(N^2) (I think), so it's essentially impossible to avoid double for loops (however, the way I process the matricies, as mentioned before, minimizes this time).

The code is also fast because, rather than using an actual e^-u operation for the sigmoidal activation function, it uses a parametrized hyperbola - this arithmetic operations are the only ones that occur, and this is much faster than exponentiation (which I believe is just computer by Taylor series in the C math library..)

The weight vectors for this block are static (since they're made from training data where the signal type is already known). I am not currently satisfied with the performance of the block on data read from a file, so I am retraining my network. I realized that what is currently happening is that, given a time-dependent desired output vector, the network first trains to output a "quiet" vector, then a "disturbance" vector, and then retrains again to output a "quiet vector" and completely forgets how to classify disturbance. Currently, I am trying to get around this problem by shifting my earthquake data time-series, so that when I train in batch (on all of my data), there is probably an earthquake at all time points, so that the network does not only train on "quiet" at certain iterations. Likewise, I realized that I should perform several epochs (not just one) on the data - I tried this last night, and training performance MSE decreased by a factor of 1 per iteration (when on average, it's about 40, and 20 at best).

After I input the static weight vectors (which shouldn't take long since my code is very generalized), the C block can be added to the c1pem frame, and a channel can be made for the seismic disturbance class. I've made sure to keep with all of the C block rules when writing my code (both in terms of function input/output, and in terms of not using any C libraries).

As for neural networks for control, I talked to Denis about the controller block, and he realized that we should, instead of adding noises, at first attempt to use a reference plant with a lower Q pendulum and a real plant with a higher Q pendulum (since we want pendulum motion to be damped). I've tried training the controller block several times, but each time so far the plant pendulum has started oscillating greatly. My current guess at fixing this is training more.

Also, Jenne and I made a cable for Guralp 1 (I soldered, she explained how to do it), and it seems to work well, as mentioned in my previous E-log. Hopefully it can be used to permanently keep the seismometer all the way down the arm.

  7118   Wed Aug 8 11:47:52 2012 YaakovSummarySTACISWeekly summary

As Rana pointed out (http://nodus.ligo.caltech.edu:8080/40m/7112), the geophone/accelerometer noise lines from my last eLog (http://nodus.ligo.caltech.edu:8080/40m/7109) were dominated by ADC noise. I checked this today by terminating the ADC channels with 50 Ohm terminators and measuring the noise. The ADC noise line is included on the plot below, and it is clearly dominating the sensor noise data.

budget_with_adc.pngbudget_with_adc.fig

I set the accelerometer gain to 100, and will hook up the geophones to the SR560 pre-amp today- this should put both signals above the ADC noise, and I can calculate the sensor noises without the ADC noise being significant.

I have also begun to make some progress in understanding the pre-amp circuitry, and I will post a schematic when I've sketched it all.

Another issue that seems increasingly relevant to me is the power supply to the high voltage amplifier. It appears to go into the high voltage board from the power supply, then into the geophone pre-amp, then back into the high voltage board (see block diagram below). I tested this by inputting a signal after the pre-amp, with the geophones disconnected- the signal only drives the PZT if the pre-amp is plugged in, so the power that returns from the pre-amp must be powering some chips on the high voltage amplifier.

 

Power flow through the STACIS :

power_diagram.png

This is somewhat inconvenient, because it means if I want to provide external feedback (with accelerometers, for example) or actuation (such as feedforward), which I want to input after the geophone pre-amp, the pre-amp still needs to be plugged in for the high voltage amplifier to work and drive the PZTs.  I am cataloging all of the pins on the high voltage amplifier and pre-amp so I can figure out how to reroute the power and cut out the geophone pre-amp entirely if necessary. I'll include a pin diagram with the pre-amp circuit sketch.

  7119   Wed Aug 8 13:16:58 2012 EricSummaryGeneralSURF Update

This week I spent most of my time learning about how the interferometer is calibrated and working on the calibration itself. I also looked more into the Pound-Drever-Hall technique.

Continuing work on the free-swinging Michelson measurements, I changed the signal that I was using to C1:LSC-ASDC_OUT_DQ. This is a proper power signal so that the peak-to-peak amplitude of this error signal can be directly read off the graph. The motivation to measure this amplitude is that it must be known in order to calibrate the actuation of the input and end test masses.

Next I looked into using DTT to make some measurements. I ran the Michelson restore script in the IFO Configure screen to adjust the optics to be near alignment. Then I tweaked the precise settings in the IFO Align screen of pitch and yaw for the ITMX, ITMY, and BS. The goal with this was to minimize the magnitude of the C1:LSC-ASDC_OUT_DQ signal. After it was well-aligned, back in DTT I sent in a sine wave excitation and used a Triggered Time Response measurement to see the output. As a first test I put the excitation signal in the ASDC channel and I was able to plot the resulting OUT signal in DTT. The amplitude was different than I input due to gains between the excitation and the point of measurement, but this can easily be accounted for by adjusting the amplitude in DTT accordingly.

The next step is to work on measurements of a single arm cavity, introducing excitations there and measuring the response.

  7128   Thu Aug 9 00:14:02 2012 EricSummaryLockingYARM Locking and Calibration

Today I spent time locking the YARM in order to calibrate the arm cavity. Here's what I did:

1. Misalign all optics other than the beam splitter, ITMY, ETMY and PZT2

2. Restore BS, ITMY, ETMY, and PZT2

3. Open Dataviewer and run /users/Templates/JenneLockingDataviewer/Yarm.xml from the Restore Settings. This opens the signals C1:LSC-POY11_I_ERR (the Pound-Drever-Hall error signal for this measurement) and C1:LSC-TRY_OUT (the light transmitted through ETMY) in the plot window.

4. Adjust ITMY and ETMY pitch and yaw using the video screens looking at AS and ETMYT as a first, rough guide. It can be helpful at first to increase the gain on the YARM servo filter module in the C1LSC control screen to about 0.3 and decrease it back down to 0.1 as the beam becomes better aligned. You know when to decrease this gain when fuzzy, small oscillations appear on the C1:LSC-TRY_OUT signal. If the mode cleaner is locked you should see a bright spot on the AS camera.

5. Tinker with pitch and yaw while looking at the AS screen until you see a reasonably good circular spot without other fringes extending from a bright center.

6. The overall goal is to maximize C1:LSC-TRY_OUT because the power transmitted through EMTY is proportional to the power within the cavity. A decent target value is 0.85 and today I was able to get it to just over 0.80 at best. At first there will probably be small spikes in C1:LSC-TRY_OUT. You want to adjust pitch and yaw until the deviation in the signal from zero is no longer just a spike, but a sustained, flat signal above zero. By this time there should be light showing up on the ETMYT camera as well.

7. Once that happens, continue to successively adjust ITMY and ETMY doing the pitch adjustments on both first, and then the yaw adjustments, or vice versa. You can also tweak the PZT2 pitch and yaw. Once you've got C1:LSC-TRY_OUT as large as possible, you've locked the cavity.

I saved the pitch and yaw settings I ended up with for ITMY, ETMY, BS and PZT2 in the IFO_ALIGN screen. Before the end of the day I think Jenne restored the rest of the previously misaligned optics because they were restored when I got back from dinner.

 

 

I also worked on calibrating the YARM. I opened up DTT using C1:LSC-POY11_I_ERR as the measurement channel and C1:SUS-ITMY_LSC_EXC as the excitation channel. I ran a logarithmic swept sine response measurement with 100 points and an amplitude of 25. The mode cleaner kept losing its lock all day, and if this happened while making this measurement I tried to pause the sweep as quickly as possible. I analyzed the the transfer function and the coherence function that the sweep produced, and thought that some of the odd behavior was due to losing the lock and getting back to a slightly different locked state when resuming the measurement. The measured transfer function and coherence plots are attached below. Both the transfer function and the coherence look good above roughly 30 Hz, but do not look correct at low frequencies. There's also a roll-off in the measured transfer function around 200 Hz, while in the model the magnitude of the transfer function drops only after the corner frequency of the cavity, around several kHz. I have attached a plot of the roughly analogous transfer function from the DARM control loop model (the gains are very large due to the large arm cavity gain and the ADC conversion factor of 2^16/(20 V) ). The measured and the modeled transfer functions are slightly different in that the model does not include the individual mirrors, while the excitation was imposed on ITMY for the measurement.

 

The next steps are to figure out what's happening in DTT with the transfer function and coherence at low frequencies, and to understand the differences between the model and the measurement.

Attachment 1: cal_swept_sine3_tfmag
Attachment 2: cal_swept_sine3_tfph
Attachment 3: cal_swept_sine3_coh
Attachment 4: sensing_func_model.png
sensing_func_model.png
  7130   Thu Aug 9 00:35:53 2012 JenneSummaryLockingYARM Locking and Calibration

Quote:

 Once you've got C1:LSC-TRY_OUT as large as possible, you've locked the cavity.


 Both the transfer function and the coherence look good above roughly 30 Hz, but do not look correct at low frequencies. There's also a roll-off in the measured transfer function around 200 Hz, while in the model the magnitude of the transfer function drops only after the corner frequency of the cavity, around several kHz. I have attached a plot of the roughly analogous transfer function from the DARM control loop model (the gains are very large due to the large arm cavity gain and the ADC conversion factor of 2^16/(20 V) ). The measured and the modeled transfer functions are slightly different in that the model does not include the individual mirrors, while the excitation was imposed on ITMY for the measurement.

 

The next steps are to figure out what's happening in DTT with the transfer function and coherence at low frequencies, and to understand the differences between the model and the measurement.

 The cavity is actually "locked" as soon as the feedback loop is successfully closed.  One easy-to-spot symptom of this is that, as you mentioned elsewhere in your post, TRY is a ~constant non-zero, rather than spikey (or just zero).  Once you've maximized TRY, you've got the cavity locked, and the alignment optimized.

We didn't get to this part of "The Talk" about the birds, the bees, and the DTTs, but we'll probably need to look into increasing the amplitude of the excitation by a little bit at low frequency.  DTT has this capability, if you know where to look for it.

It would be great to see the model and your measurement overlayed on the same plot - they're easier to compare that way.  You can export the data from DTT to a text file pretty easily, then import it into Matlab and plot away.  Can you check and maybe repost your measured plots?  I think they might have gotten attached as text files rather than images.  At least I can't open them. 

ELOG V3.1.3-