JIMS Channels in PEM Model

The PEM model has been modified now to include the JIMS(Joint Information Management System) channel processing. Additionally Jim added test points at the outputs of the BLRMS.

For each seismometer channel, five bands are compared to threshold values to produce boolean results.  Bands with RMS below threshold produce bits with value 1, above threshold results in 0.  These bits are combined to produce one output channel that contains all of the results.

A persistent version of the channel is generated by a new library block that called persist which holds the value at 0 for a number of time steps equal to an EPICS variable setting from the time the boolean first drops to zero. The persist allows excursions shorter than the timestep of a downsampled timeseries to be seen reliably.

The JIMS Channels are being recorded and written to frames:

The two JIMS channels at 2048:
[C1:PEM-JIMS_CH1_DQ] Persistent version of JIMS channel. When bit drops to zero indicating something bad (BLRMS threshold exceeded) happens the bit stays at zero  for >= the value of the persist EPICS variable.
[C1:PEM-JIMS_CH2_DQ] Non-persistent version of JIMS channel.

And all of the BLRMS channels at 256:
Names are of the form:
[C1:PEM-RMS_ACC1_F0p1_0p3_DQ]
[C1:PEM-RMS_ACC1_F0p3_1_DQ]

For additional details about the JIMS Channels and the implementation, please see the previous elog entries by Jim.

Conlog

I have a working aLIGO Conlog/EPICS Log installed and running on megatron.

Please see this wiki page for the details of use:
https://wiki-40m.ligo.caltech.edu/aLIGO%20EPICs%20log%20%28conlog%29

I also edited this page with restart instructions for megatron:
https://wiki-40m.ligo.caltech.edu/Computer_Restart_Procedures#megatron

Please see Ryan's previous elog entries for installation details.

Future Work

• Determine useful thresholds for each band
• Generate MEDM Screens for JIMS Channels
• Add a decimation option to channels
• Add EPICS Strings in PEM model to describe bits in JIMS Channels
• Add additional JIMS Channels: Testing additional characterization methods
• Implement a State Log on Megatron: Will Provide a 1Hz index into JIMS Channels
• Generate a single web page that allows access to aLIGO Conlog/EPICS Log and State Log

I accidently shut off the laser at 19:34 with the emergency shutoff button while trying to tap into a video line for the Sensoray device.

We reset the interlock and restarted the PSL.  The end AUX lasers seem to have come back online fine.  PMC and mode cleaner locked back up quickly.

This morning I installed Ubuntu 10.04 on rosalba.  This is the same version that is running on pianosa.  The two machines should be identically configured, although rosalba may be missing some apt-getable packages.

[Jenne/Den/Koji]

We locked Xarm/Yarm and manually alignmed ITMX/ITMY/BS/ETMX/ETMY/PZT1/PZT2.

ITMY OPLEV was largely misaligned ==> The beam was centered on the QPD.

----

Then we aligned PRM using SB locking PRMI.

We noticed that OPLEV servo does not work. It made the PRM just noiser.

We went into the PRM table and found that the OPLEV beam was clipped in the vacuum chamber.
We tried to maximize the reflected beam from the window by touching the steering mirrors at the injection side.

Then the reflected beam was introduced to the center of the QPD.

After the alignment, the OPLEV QPD SUM increased to 4000ish from 200ish.
According to the OPLEV trend data, this is a nominal value of the QPD SUM.

Now the OPLEV servo does not go crazy.

 --

BS OPLEV beam was centered on the QPD.

Top tab categolies:

• Summary
• CDS
  • CDS Status
• PEM
  • Seismic 24h trend
  • Accoustic 24h trend
  • Weather/Temp/Barometer/etc 24h trend
• PSL/IOO
  • PSL summary trend / duty ratio
  • IOO summary (MC Health Check/IOO QPD trends / IFO QPD trends / Transmon QPD trends) duty ratio
• SUS
  • Summary
  • OSEM PSD/trend
  • OPLEV PSD/trend
• IFO
  • DC Mon
  • RF ports
  • OMC
• Steve
  • Vacuum
• Misc.

IFO

• DC Monitors
  • Incident beam power trend (24h)
  • AS/REFL/POP/TRX/TRY bean power trend (24h)
  • AS/POP RF beam power trend (24h)
• RF port
  • DARM sensitivity PSD (mean/min/max/reference) for an hour
  • DARM/CARM/PRCL/MICH/SRCL PSD
  • DARM/CARM/PRCL/MICH/SRCL (freq vs Gaussianity)
  • DARM/CARM/PRCL/MICH/SRCL calibration trend
• OMC
  • TBD

   Here is the suggested layout of the MC health check web page layout. I will update the Omnigraffle file as people comment and suggest changes.  If you want the file let me know.

40m summary webpages

 The aLIGO-style summary webpages are now running on 40m data! They are running on megatron so can be viewed from within the martian network at:

http://192.168.113.209/~controls/summary

At the moment I have configured the 5 seismic BLRMS bands, and a random set of PSL channels taken from a strip tool.

Technical notes

• The code is in python depending heavily on the LSCSoft PyLAL and GLUE modules.
  • /home/controls/public_html/summary/bin/summary_page.py
• The HTML is supported by a CSS script and a JS script which are held locally in the run directory, and JQuery linked from the google repo.
  • /home/controls/public_html/summary/summary_page.css
  • /home/controls/public_html/summary/pylaldq.js
• The configuration is controlled via a single INI format file
  • /home/controls/public_html/summary/share/c1_summary_page.ini

Getting frames

Since there are no segments or triggers for C1, the only data sources are GWF frames. These are mounted from the framebuilder under /frames on megatron. There is a python script that takes in a pair of GPS times and a frame type that will locate the frames for you. This is how you use it to find T type frames (second trends) for May 25 2012:

python /home/controls/public_html/summary/bin/framecache.py --ifo C1 --gps-start-time 1021939215 --gps-end-time 1022025615 --type T -o framecache.lcf

If you don't have GPS times, you can use the tconvert tool to generate them

$ tconvert May 25
1021939215

The available frame types, as far as I'm aware are R (raw), T (seconds trends), and M (minute trends).

Running the code

The code is designed to be fairly easy to use, with most of the options set in the ini file. The code has three modes - day, month, or GPS start-stop pair. The month mode is a little sketchy so don't expect too much from it. To run in day mode:

python /home/controls/public_html/summary/bin/summary_page.py --ifo C1 --config-file /home/controls/public_html/summary/share/c1_summary_page.ini --output-dir . --verbose --data-cache framecache.lcf -SRQDUTAZBVCXH --day 20120525

Please forgive the large apparently arbitrary collection of letters, since the 40m doesn't use segments or triggers, these options disable processing of these elements, and there are quite a few of them. They correspond to --skip-something options in long form. To see all the options, run

python /home/controls/public_html/summary/bin/summary_page.py --help

There is also a convenient shell script that will run over today's data in day mode, doing everything for you. This will run framecache.py to find the frames, then run summary_page.py to generate the results in the correct output directory. To use this, run

bash /home/controls/public_html/summary/bin/c1_summary_page.sh

Configuration

Different data tabs are disabled via command link --skip-this-tab style options, but the content of tabs is controlled via the ini file. I'll try to give an overview of how to use these. The only configuration required for the Seismic BLRMS 0.1-0.3 Hz tab is the following section:

[data-Seismic 0.1-0.3 Hz]
channels = C1:PEM-RMS_STS1X_0p1_0p3,C1:PEM-RMS_STS1Y_0p1_0p3,C1:PEM-RMS_STS1Z_0p1_0p3
labels = STS1X,STS1Y,STS1Z
frame-type = R
plot-dataplot1 =
plot-dataplot3 =
amplitude-log = True
amplitude-lim = 1,500
amplitude-label = BLRMS motion ($\mu$m/s)

The entries can be explained as follows:

1. '[data-Seismic 0.1-0.3 Hz] - This is the section heading. The 'data-' mark identifies this as data, and is a relic of how the code is written, the 'Seismic 0.1-0.3 Hz' part is the name of the tab to be displayed in the output.
2. 'channels = ...' - This is a comma-separated list of channels as they are named in the frames. These must be exact so the code knows how to find them.
3. 'labels = STS1X,STS1Y,STS1Z' - This is a comma-separated list of labels mapping channel names to something more readable for the plots, this is optional.
4. 'frame-type = R' - This tells the code what frame type the channels are, so it can determine from which frames to read them, this is not optional, I think.
5. 'plot-dataplotX' - This tells the code I want to run dataplotX for this tab. Each 'dataplot' is defined in it's own section, and if none of these options are given, the code tries to use all of them. In this configuration 'plot-dataplot1' tells the code I want to display the time-series of data for this tab.
6. 'amplitude-XXX = YYY' - This gives the plotter specific information about this tab that overrides the defaults defined in the dataplotX section. The options in this example tell the plotter that when plotting amplitude on any plot, that axis should be log-scale, with a limit of 1-500 and with a specific label. The possible plotting configurations for this style of option are: 'lim', 'log', 'label', I think.

Other compatible options not used in this example are:

• scale = X,Y,Z - a comma-separated list of scale factors to apply to the data. This can either be a single entry for all channels, or one per channel, nothing in between.
• offset = X,Y,Z - another comma-separate list of DC offsets to apply to the data (before scaling, by default). DAQ noise may mean a channel that should read zero during quick times is offset by some fixed amount, so you can correct that here. Again either one for all channels, or one per channel.
• transform = lambda x: f(x) - a python format lambda function. This is basically any mathematical function that can be applied to each data sample. By default the code constructs the function 'lambda d: scale * (d-offset)', i.e. it calibrates the data by removing the offset an applying the scale.
• band = fmin, fmax - a low,high pair of frequencies within which to bandpass the data. Sketchy at best...
• ripple_db = X - the ripple in the stopband of the bandpass filter
• width = X - the width in the passband of the bandpass filter
• rms_average = X - number of seconds in a single RMS average (combine with band to make BLRMS)
• spectrum-segment-length = X - the length of FFT to use when calculating the spectrum, as a number of samples
• spectrum-overlap = X - the overlap (samples) between neighbouring FFTs when calculating the spectrum
• spectrum-time-step = X - the length (seconds) of a single median-mean average for the spectrogram

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

You can view the configuration file within the webpage via the 'About' link off any page.

Please e-mail any suggestions/complaints/praise to duncan.macleod@ligo.org.

There is now a job in the crontab that will run the shell wrapper every hour, so the pages _should_ take care of themselves. If you make adjustments to the configuration file they will get picked up on the hour, or you can just run the script by hand at any time.

$ crontab -l
# m h  dom mon dow   command
0 */1 * * * bash /home/controls/public_html/summary/bin/c1_summary_page.sh > /dev/null 2>&1

 We have placed some sweet giant strawberries in the fridge; free for eating for anyone working in the lab today or tomorrow:

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

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.

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

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)

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

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


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




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

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.



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


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



  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.

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



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.

 Nice PSL summaries from LHO:

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

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

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?

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.



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

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




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

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.

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.

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.

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.

[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?

 Start pumping on Monday before Steve goes home.

 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.

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.

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.

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.

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.

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)

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

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.

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!

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.

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:

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

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

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

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.

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.

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.

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.

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.

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.