40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 42 of 339  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  476   Wed May 14 13:14:19 2008 AndreySummaryComputersReflective Memory Network is restored

Reflective Memory Network is restored, all watchdogs and oplevs are returned to the "enabled" state.

In order to revive the computers, several things were done.

1) Following Mr. Adhikari's elog entry #353, I walked around the interferometer room, and switched off the power keys in all crates with computers whose names are contained in the MEDM Reflective Memory screen, including the rack with the framebuilder. By the way, it was nontrivial to find the switch in the 1Y4 crate that would shut off/on processors "c1susvme1" and "c1susvme2": the switch turned out to be located at the rear side of the crate, and it is not a key but it is a button.

2) I was trying to follow wiki-40 computer restart procedures, but every time that I was trying to run "startup.cmd" screen from the corresponding target subdirectory, I got the error message "Device or resource busy".
By the way, one more thing was learned: if you firstly open in terminal burtgooey, select the snap file, then reboot the processor, and then will try to burt-restore it, you will get the message "Status Not OK". In order to really burt-restore the processor which was recently rebooted, you need to close the terminal with burtgooey and open burtgooey in a new terminal window which should be opened after rebooting the processor.

Feeling that my activities according to wiki-40 procedures do not revive computers, I invited Alex Ivanov.

3) Alex tried to touch the memory card in "c1iovme" in rack 1Y2, because once before this card failed causing network problems, but this did not help.

4) We shutted off and restarted again (pressing the power-switching button) the black Linux machine "c1dcuepics" (located in the very bottom below the framebuilder). Alex says that this machine is responsible for all EPICS. It was not restarted for 182 days, and probably some process there went wrong.

After restarting this machine "c1dcuepics" we were able to follow wiki-40 procedures for restarting all other computers (whose names are on the MEDM RFM network). We ran correcponding "startup.cmd" files and burt-restored them without error messages.

Now all the computers work and communicate in a proper way.

Mr. Joseph Betzwiezer was helping me with all these activities (we decided that it is more important that cameras for now), thanks to him. But our joint skills turned out to be insufficient, so Alex Ivanov's contribution was the most important.
  480   Thu May 15 14:39:33 2008 CarynSummaryPEMfiltering mode cleaner with mic
Tried filtering for mode cleaner data(C1:IOO-MC_L) using a siso-firwiener filter and microphone data(C1:PEM-AS_MIC) for noise input. The noise reduction in mode cleaner data using the microphone-filter is comparable to the noise reduction when an accelerometer(C1:PEM-ACC_MC1_X) filter is used. See attached graphs.
Attachment 1: MC_L_with_PEM-AS_MIC_filter.pdf
Attachment 2: MC_L_with_PEM-ACC_MC1_X_filter.pdf
  481   Thu May 15 16:24:18 2008 josephbSummaryCameras 
The GC750 camera is currently looking at a very small pickoff of the PSL output (transmission of a Y1-1037-45-S mirror). The plan is to take images tomorrow with it and the GC650 from the same spot and do comparisons.

For those interested, the camera can be run with two codes, from mafalda. Use ssh -X mafalda to login, to allow the live stream to work with the SampleViewer code. The codes can be found in:




Type Snap --help for a list of options for that program. Click the circle looking thing in SampleViewer to start the live stream. Note only 1 of the two programs can be running at a time, and the only way to change settings (such as exposure length) is with Snap at the moment.
  482   Fri May 16 14:38:50 2008 josephbSummaryCamerasTwo cameras setup
I've changed the pickoff setup from yesterday for the GigE cameras to include a 33% beam splitter (first one I could find). The reflection is going to the GC650 (CCD camera) while the transimission is going to the GC750 CMOS camera. This means the CMOS camera has roughly twice the light incident as the GC650 and should be kept in mind in all comparisons. The distances from the beam splitter are approximately the same both cameras, but some more accurate positioning might be useful.

Its very easy to get the GC650 camera into a bad state where you need to go out and cycle the power (simply unplug and re-plug in the power supply either at the camera or outlet). If the ListCamera program doesn't see it, this is probably necessary.

Andrey added at 6.30PM: Actually the 650 camera keeps crashing constantly. Every time I attempt to capture an image, the camera fails.
  484   Sun May 18 18:14:30 2008 ranaSummaryComputer Scripts / Programsautlockers and cron
Today I noticed that the MC was unlocked, the MC autolocker was off, the PSL autolocker was off,
and the PSL Slow loop was off.

Reading through .log files and our elog it seems like things have been this way since Tuesday
when Andrey went around rebooting computers to bring things back.

And it looks like the ETMY optical lever is dead.

I restarted the PSL & MC scripts on op340m. I also locked and aligned the X arm to verify that
not everything is broken. The Y Arm is unalignable until we replace the HeNe.
  485   Sun May 18 18:44:48 2008 ranaSummarySUSOptical Lever SUM Trend - 80 days
I used the OL-Trend.xml dataviewer template to make this plot. Looks like the ETMY optical lever
slowly degraded over the last few months and then finally died 10 days ago. Would someone please
replace this laser and tune the lens position to minimize the spot size on the quad?
Attachment 1: e.pdf
  494   Fri May 23 21:21:52 2008 CarynSummaryGeneralfiltering mode cleaner with wiener filter
I tried filtering some saved MC_L data (from Mon May19 4:30pm) with multiple MISO filters of different orders, with various sampling rates, at different times. Plotted the max rms error (where error is signal minus signal-estimate). 2min of data (around Mon May19 4:30pm) were used to calculate each filter. And each filter was applied to data at later times to see how well it performed as time progressed. Plots are attached. There appears to have been a disturbance during the 3rd hour. Rana pointed out perhaps it would be better to use data from the evening rather than during the day.
Attachment 1: error_vs_N_for_different_times_64Hz.pdf
Attachment 2: error_vs_N_for_different_times_128Hz.pdf
Attachment 3: error_vs_N_for_different_times_256Hz.pdf
Attachment 4: error_vs_N_for_different_times_512Hz.pdf
Attachment 5: error_vs_srate_for_different_times_256.pdf
Attachment 6: error_vs_srate_for_different_times_512.pdf
Attachment 7: error_vs_srate_for_different_times_1024.pdf
Attachment 8: error_vs_time_for_different_srates_256.pdf
Attachment 9: error_vs_time_for_different_srates_512.pdf
Attachment 10: error_vs_time_for_different_srates_1024.pdf
  497   Sun May 25 20:30:25 2008 ranaSummaryPSLPMC Mode Matching
I checked the PMC mode matching by ramping the gain down to -10 dB (from +20 dB) and
moving the DC offset around until it caught lock on the different HOMs. Then I recorded
the output power (PMCTRANSPD). The DC offset on this EPICS channel was -0.013 V, so I
used its AOFF field to zero this out. Here is a list of the power in the largest modes:
Mode    Power (V)
----    ---------
00        2.7
10        0.2
04        0.04
02        0.02
BE        0.36      **Bull's Eye mode is TEM02 + TEM20. This can be fixed by lens adjustment.

N.B. To make a PNG file with DTT, just make an EPS file -- then use the eps2png perl script.
Attachment 1: pmc.png
  503   Thu May 29 15:58:44 2008 JohnSummaryIOOMC realignment
I repeatedly adjusted the yaw of the upper mirror on the input periscope and re aligned the MC. With the PRM aligned I tried to optimise MC transmission and DC refl simultaneously. I subsequently centred the beams on WFS1/2. Attached is a 30 day trend of MC alignment and transmission.
  512   Tue Jun 3 02:15:29 2008 AndreySummaryCamerasFitting results

There have been a lot of work going on related to the processing of images captured by the cameras GC-650 and GC-750 recently.

In the end of the week of May 30 Joseph and me (Andrey) installed the two cameras capturing the images of the pick-off of the main beam on the PSL optical table. The cameras are located after the picked-off beam going towards the "PSL position QPD", after the 33-66 beamsplitter (33% of reflection and 66% of transmission).

Initially (on May 30) the GC-650 camera was taking the images of reflected beam, while the camera GC-750 was taking images of transmitted beam. On Monday June 2 we switched the positions of the cameras, so GC-650 appeared to be on the path of the transmitted beam and GC-750 on the path of the reflected beam.

I (Andrey Rodionov) was able in the weekend to succeed in writing a Matlab program that performs the two-dimensional Gaussian fitting of the captured images, and I used that program to fit the images from the cameras.

The program fits the camera data by a two-dimensional Gaussian surface:

Z = A * exp[ - 2 * (X - X_Shift)^2 / (Waist_X)^2 ] * exp[ - 2 * (Y - Y_Shift)^2 / (Waist_Y)^2 ] + CONST_Shift,

where A, X_Shift, Waist_X, Y_Shift, Waist_Y, CONST_Shift are 6 parameters of the fit.

Attached are the pdf-files showing the results: images taken with our cameras, the 2-dimensional Gaussian fit for these images and the surfaces of residuals. Residuals are differences between the exact beam profile and the result of fitting. In normalized version of residual graph I normalize it by the first coefficient of fitting A, the factor in front of the exponents.
Attachment 1: May30-GC650.pdf
May30-GC650.pdf May30-GC650.pdf May30-GC650.pdf May30-GC650.pdf May30-GC650.pdf May30-GC650.pdf
Attachment 2: May30-GC750.pdf
May30-GC750.pdf May30-GC750.pdf May30-GC750.pdf May30-GC750.pdf May30-GC750.pdf May30-GC750.pdf
Attachment 3: June02-GC650.pdf
June02-GC650.pdf June02-GC650.pdf June02-GC650.pdf June02-GC650.pdf June02-GC650.pdf June02-GC650.pdf
Attachment 4: June02-GC750.pdf
June02-GC750.pdf June02-GC750.pdf June02-GC750.pdf June02-GC750.pdf June02-GC750.pdf June02-GC750.pdf
  518   Wed Jun 4 16:25:06 2008 CarynSummaryPEMmicrophone moved
The microphone 'C1:PEM-AS_MIC' has been moved right a bit. This change didn't seem to have much effect on filtering the 'C1:IOO-MC_L' signal, at least not compared to how the filter changes with time. Also used microphone data to filter MC_L data using firwiener filter/levinson. The N(order) and sample rate were varied to see how the filter changed. Attached are graphs of the max(rms(noise_estimate)) vs N or IR for varying srate. Note that filtered_signal=signal-noise_estimate. So, the larger the noise_estimate, the more the filter subtracts from the signal.
Green-filtered signal
blue-noise estimate
red-MC_L signal
note decreasing sample rate is more effective than increasing N (higher N takes more time to compute)
note sample rate doesn't change the max(rms(noise_estimate)) very much if impulse response time remains constant
note the 64hz, N=7000 (impulse response about 110s) filter is a better filter than the 512Hz, N=7000(impulse response about 14s)
Attachment 1: 1_MC_L.pdf
1_MC_L.pdf 1_MC_L.pdf 1_MC_L.pdf 1_MC_L.pdf
  522   Fri Jun 6 11:19:13 2008 CarynSummaryPEMFiltering MC_L and MC_F with PEM:ACC and microphone
Tried to filter MC_L and MC_F with acc/seis data and microphone data using wiener filter (levinson)

-Used get_mic_data.m and miso_filter_lev.m to make SISO filter for 2 minutes of IOO-MC_F data. Used PEM-AS_MIC signal as noise input data. Filters calculated at initial time were applied to later data in 1 hour intervals.
-microphone filter did not seem to filter MC_F very well in high frequency range using this filtering procedure.
-residual is larger than est (see MC_F pdf)
-Used do_all_time_lev.m to make graph of max(rms(residual)) to N(order) for different times.(note for each N, filter was calculated for initial time and then applied to data at other times).
-relation of max(rms(residual)) to N(order) is time sensitive (note-on graph, time interval is 1hour) (see MC_F pdf)
-Presumably, max(rms(residual)) should decrease as N increases and increase as time increases since the filter probably becomes worse with time. I think the reason this isn't always true in this case is that the max(rms(residual)) corresponds to a peak (possibly a 60Hz multiple) and the wiener filter isn't filtering out that peak very well.

-Used get_z_data.m and miso_filter_lev.m to make MISO filter for 2 minutes of IOO-MC_L used the following signals as noise input data
-Filter was applied to later data in 2hour intervals.
-Used do_all_time_lev.m to make graph of max(rms(residual)) to N(order) for different times.(note for each N, filter was calculated for initial time and then applied to data at other times).
-acc/seis filter seemed to filter MC_L OK for 128,256,512Hz srates. 64 Hz wasn't ok for certain N's after a period of time.
-residual is smaller than est for srates not 64Hz (see MC_L pdf)
-residual is larger than est for 64Hz at N=1448 for later times (see MC_L pdf)
-relation of max(rms(residual)) to N is not as time sensitive for higher sample rates (note-on graph, time interval is 2hours) (see MC_L pdf). Perhaps the levinson 64Hz sample rate filter doesn't do as well as time passes for these signals. When the filter didn't do well, the max(rms(residual)) seemed to increase with N.
-For 512Hz sample rate filter the max(rms(residual)) decreased with time. If the max(rms(residual)) were an indication of filter performance, it would mean that the 512Hz filter calculated at the initial time was performing better later as hours passed by! Perhaps max(rms(residual)) isn't always great at indicating filter performance.

Programming notes
-I had to modify values in do_all_time_lev.m to get the program to loop over the srates,N's,times I wanted
-do_all_time_lev.m is not as clean as do_all_lev.m
-for making the plots do_all_lev.m (which isn't really a procedure and is messy) has some examples of how to plot things from do_all_time_lev.m.
Attachment 1: MC_F.pdf
MC_F.pdf MC_F.pdf MC_F.pdf
Attachment 2: MC_L.pdf
MC_L.pdf MC_L.pdf MC_L.pdf MC_L.pdf MC_L.pdf MC_L.pdf MC_L.pdf MC_L.pdf
Attachment 3: miso_filter_lev.m
function [s] = miso_filter_lev(N,srate,rat,z)
%MISO_FILTER_LEV(N,srate,z) uses miso_firlev to get levinson
%   FIR Wiener filter of order N-1, using impulse response of 
%   N/srate. z is a structure gotten from the get_data function. 
%   z(end) is the signal which is filtered using z(i) for all i.
%   'rat' is the fraction of z which will be put into filter
%   funtion. The data from z is downsampled using srate and 
%   detrended. Let rat=1. I don't have that part working yet.

... 107 more lines ...
Attachment 4: get_mic_data.m
%get_mic_data gets data for'C1:IOO-MC_F', 'C1:PEM-AS_MIC,
% Example:  z = get_mic_data('now',120,60)
%  start time is 't- d_t' so  d_t should be given in seconds. t should be given
%  as a number like 893714452. d is duration in seconds. get_mic_data saves
%  data to a file in current directory named 'temp_mic'. You will be asked to
%  save file as 'mic_(start_time)_(duration)'.

duration = d;

... 32 more lines ...
Attachment 5: do_all_time_lev.m
function[r] = do_all_time_lev(n,t0,int,duration,N,srate,rat,order,time,MC_L,MC_F,sample_rate)
%do_all_time explores how filter performance changes with time, sample rate,
%and order of filter. Outputs data,noise estimate, structure of max
%rms error and other info. It uses get_data, miso_filter_lev, and miso_filter_int and retrives
%MC_Ldata or MC_Fdata for multiple times, calculates a miso_filter for initial-time data
%file, applies filter to the other data files, and keeps track of the...
%max(rms(residual)) for each filter. n+1 is number of data files. int is time interval between
%data files, t0 is start time, duration is duration of each data file, srate
%is the sample rate for which filter is calculated, n_N is number of orders
%of the filter you want the program to calculate,int_N is interval by which N
... 215 more lines ...
Attachment 6: do_all_lev.m
function[r] = do_all_lev(n,t0,int,duration,n_N,int_N,n_srate,int_srate,rat,MC_L,MC_F)
%do_all_lev explores how filter performance changes with time, sample rate,
%and order of filter. Outputs data,noise estimate, structure of max
%rms error and other info. It uses get_data, miso_filter_lev, and miso_filter_int and retrives
%MC_Ldata or MC_Fdata for multiple times, calculates a miso_filter for initial-time data
%file, applies filter to the other data files, and graphs the rms of the cost
%function vs time. n+1 is number of data files. int is time interval between
%data files, t0 is start time, duration is duration of each data file, srate
%is the sample rate for which filter is calculated, n_N is number of orders
%of the filter you want the program to calculate,int_N is interval by which N
... 283 more lines ...
Attachment 7: do_all_plot.m
function[r] = do_all_plot(r,x,v)
 %do_all_plot plots variables contained in r(structure from
 %do_all_time_lev).Plots error(r.B.y) vs x. x can be
 %'s'(srate),'N'(order),'t'(time),'p'(impulse response). v can be 's','N','t'. 
 %example: do_all_plot(r,'s','t') makes a plot of error vs srate for
 %different times.


... 388 more lines ...
Attachment 8: miso_filter_int.m
function [s] = miso_filter_int(s,y)
%miso_filter_int inputs a filter and a structure array of data sets y, applies filter to data, and
%outputs a structure with fields: ppos(signal frequ spectrum),perr(cost
%function frequ spectrum),pest(signal estimate frequency
%spectrum),f(frequency),target(signal),est_darm(noise estimate),t(time).
%data file for which filter has been calculated is s (obtained using miso_filter). 
%y consists of data structures which will be filtered using
%filter from s. Then the power spectrum of the difference between signal and filtered-data is
%graphed for all the data files of y for comparison too see how well filter performs
%over time. Note if you want to create a y, take z1,z2,z3,etc. structures
... 120 more lines ...
  538   Wed Jun 18 16:07:57 2008 robSummaryComputersRFM network down

The RFM network tripped off around noon today. It's still down. The problem appears to be with the EPICS interface (c1dcuepics). Trying to restart one of the end stations yields the error: No response from EPICS.

Possible causes include (but not limited to): busted RFM card on c1dcuepics, busted PMC bus on c1dcuepics, busted fiber from c1dcuepics to the RFM switch. We need Alex.
  554   Mon Jun 23 19:48:28 2008 rana,albertoSummaryIOOStochMon trends (80 days)
Here's a StochMon plot showing the RFAM after the MC. Remember that in these units, 2V means no RFAM
and 0 V means lots of RFAM. Alberto says "the calibration is in Tiramisu". So there you go.
Attachment 1: e.png
  557   Tue Jun 24 15:15:09 2008 JohnSummaryLSCLocking efforts
Rob, Rana, John

In the past week or so we've been working on reducing the CARM offset using a DC signal (SPOB DC).
We were able to get up to arm powers of around 30 (where a single arm cavity lock is a power of 1)
before instability set in and we would lose lock for, as yet, unknown reasons.

In recent nights locking efforts have taken a few backward steps.

Since last Thursday engaging the AO path has proved troublesome, i.e. engaging it would instantly
cause loss of lock. This seems to be related to problems with the mode cleaner servo. For the past
few nights it has been behaving strangely and could not be operated with the usual super boost stages.
Last night the situation was improved. MC boost stages could be used and the AO path engaged. The
cause of this problem and its spontaneous resolution are not understood.

Last night we were unable to switch CARM to SPOB DC. I've attached a spectrum of the MC2 length signal.
This path is being used for CARM and so gives an indication of the frequency noise after the mode
cleaner. At the moment the plot is calibrated in units of Rana's gut feeling. We already tested to see if
any of the excess noise was introduced by the WFS. No evidence was found. We'll try to make a useful
calibration soon and see if our problems are related to excess frequency noise.

Another realisation from last night was the effect of arm detuning on the analogue CARM path. When CARM is detuned
the coupled cavity pole removes an extra 90 degrees of phase. The digital path has the `moving zero' to compensate
for this. The analogue path has no such compensation and can therefore become unstable at moderate detunings.
We propose trying to reduce the CARM offset further before engaging the analogue path. This will give higher
gain and move the UGF to a region of increased phase margin.
Attachment 1: mcl080623.png
  560   Tue Jun 24 22:43:23 2008 ranaSummarySEIStack TF
Attachment 1: Screenshot.png
  561   Wed Jun 25 00:35:40 2008 KojiSummaryGeneralOptical Layout on the AP table
I have visited the AP table in order to investigate where we are going to put the optical setup for the abs. length meas.
I have attached the PNG and PDF files to share the optical layout. It is not complete. Any comments or corrections are welcome.
Attachment 1: optical_layout_ap_table.png
Attachment 2: optical_layout_ap_table.pdf
  562   Wed Jun 25 01:30:19 2008 JohnSummaryIOOFrequency noise after the MC
I made some (very) rough estimates of the contribution made to the noise after the mode cleaner by three sources.

Seismic noise - how much of the signal is due to the mode cleaner compenstaing for seismic disturbance of CARM.
Actuator noise - coil drivers and DAC noise.
MC_F - estimate of MC_F suppressed by the loop gain.
Attachment 1: MC2noise080623.png
  566   Wed Jun 25 12:25:28 2008 EricSummaryCameras2D Gaussian Fitting Code
I initially wrote a script in MATLAB that takes pictures of the laser beam's profile and fits them to a two dimensional gaussian in order to determine the position and width of the beam. This code is now (mostly) ported to C so that it can be imbedded in the camera software package that Joe is writing. The fitting works fairly well for pictures with the beam directly incident on the camera, and less well for pictures of scatter off the end mirrors of the arms, since scatter from defects in the mirror have intensities much greater than the intensity of the beam's gaussian profile.

The next steps are to finish up porting the fitting code to C, and then modify it so it can better handle the images off the end mirror. Some thoughts on how to do this are to use a fourier transform and a low pass filter, or to simply use a center-of-mass calculation (with the defect peaks reduced in intensity), since position is more important than beam width in this calculation. The eventual goal is to include the edge of the optic in the picture and use the fit of the beam position in comparison to the optic's position to find the beam's location on the mirror.
  568   Wed Jun 25 13:56:56 2008 JohnSummaryLockingTuesday night locking
Rob, John

Worked to try and reduce the CARM offset using the dc arm transmissions before changing to SPOB DC. This proved somewhat unsuccessful, the offset couldn't be reduced to more than five (arms storing 5x more power than single arm cavity lock).
  573   Thu Jun 26 12:30:40 2008 JohnSummaryLockingCARM on REFL_DC

Try REFL_DC as the error signal for CARM rather than PO_DC.


The PO signal is dominated by sideband light when the arms are detuned so that any misalignment in the recycling cavity introduces spurious signals. Also, the transfer function from coupled cavity excitation to REFL signal is not so steep and hence REFL should give a little more phase. Finally, the slope of the REFL signal should make it easier to hand over to RF CARM.


The REFL signal showed no clear improvement over PO signals. We've gone back to PO.

During the night we also discovered that the LO for the MC loop is low.
  582   Fri Jun 27 14:36:39 2008 JohnSummaryLocking 
Rob, Yoichi, John

Some progress last night:

Switched back to SPOB_DC for CARM.

Shaped the MC LSC loop to reduce excess noise in the 20-30Hz band. Likely the most significant change.
Could this be due to fan noise from the laptop on the SPOB table?

Brought in the AO path earlier (at low gain).

Reduced offset to 6 and increased MC gain before handing off to SPOB. Ramped up AO and MC gain then switched off the
moving zero.

Looks like PD11 is the most promising candidate for RF CARM although the demod phase needs attention.
Attachment 1: gettingcloser.png
  591   Sun Jun 29 11:31:52 2008 JohnSummaryPSLISS
I reduced the gain of the ISS (C1: PSL-ISS_VGAGAIN) from 5dB to 2dB. Any higher and it constantly saturates.
  593   Sun Jun 29 18:58:43 2008 ranaSummaryComputers1e20 is too big for AWG and/or IOVME
While testing out my matlab/awgstream based McWFS diagnostic script I accidentally put a
huge excitation into
. This went to 1e20 and then caused
some SUS to trip and c1susvme2 to go red. I tried booting it via the normal procedures
but it wouldn't come back, even after 2 crate power cycles. I also tried booting AWG
via the vmeBusReset, but that didn't do it. Then I booted c1iovme from the telnet prompt
and then I could restart c1susvme2 successfully.

The reason the excitation was so large is that the following filter command is unstable:
[b,a] = butter(4,[0.02 30]/1024);

The low pass part is OK, but it looks like making such a low frequency digital filter
is not. Que lastima. On the bright side, the code now has some excitation amplitude
  594   Sun Jun 29 19:19:47 2008 ranaSummaryIOOTrends of the PSL/IOO Quads over 1000 days
Only IOO POS has been working for the past 2 years. I guess we should recommission the IOO ANG and REFL QPDs
Attachment 1: a.png
  595   Sun Jun 29 19:53:26 2008 JohnSummaryPSLISS

I reduced the gain of the ISS (C1: PSL-ISS_VGAGAIN) from 5dB to 2dB. Any higher and it constantly saturates.

Seemed to go back to normal after the frame builder came back.
  596   Sun Jun 29 20:09:40 2008 JohnSummaryIOOmcup and mcdown indicators
I edited the mcup and mcdown scripts so that C1IFO_STATE shows when these scripts are running.

I also added indicators to the LockMC screen.
Attachment 1: mcscreen.png
Attachment 2: ifostate.png
  604   Mon Jun 30 15:08:52 2008 JohnSummaryPSLMZ alignment
I adjusted the alignmnet of the Mach-Zehnder's two North mirrors (downstream of the EOMs).

MZ REFL is reduced from 0.54 to 0.43. The largest improvement was due to pitch on the PZT mirror.
Attachment 1: mzalign.png
  613   Tue Jul 1 12:51:34 2008 JohnSummaryGeneralIFO alignment
Rana, Rob, Yoichi, John

The recent computer problems and MZ work had disturbed the alignment of the interferometer.

We adjusted the MC alignment back to nominal positions using old OSEM values. We then walked
the input beam to match the MC. Coupling into the interferometer has increased noticeably.
The rest of the IFO was then aligned to the new input beam.

Proceeding to full IFO locking we were able to engage the AO path and hand off CARM to SPOBDC.
Arm powers got up to 4.

If the new alignment proves successful we will centre all QPDs etc so we can easily return to
this state.
Attachment 1: align080701.png
  622   Wed Jul 2 10:35:02 2008 EricSummaryCamerasGeneral Summary
I finished up the 2D Gaussian fitting code, and, along with Joe, integrated into the Snap software so that it automatically does a fit to every 100th image. While the fitting works, it is too slow for use in any feedback to the servos. I put together a center of mass calculation to use instead that is somewhat less accurate but much faster (almost instantaneous versus 5-10 seconds). This has yet to be added to the Snap software, but doing so would not be difficult.

I put together a different fitting function for fitting the multiple lorentzian resonance peaks in a power spectrum that would result from sweeping the length of any of the mode cleaners. This simply doesn't work. I tested it on some of Josh Weiner's data collected on the OMC last year, and the data fits poorly. Attempting to fit it all at once requires fitting 80000 data points with 37 free parameters (12 peaks at 3 parameters per peak and 1 offset parameter), which cannot be done in any reasonable time period. Attempting to fit to one specific peak doesn't work due to the corruption of the other nearby peaks, even though they are comparatively small. The fit places the offset incorrectly if given the opportunity (green line in attemptedSinglePeakFitWithoutOffset.tiff and attemptedSinglePeakFitWithoutOffsetZoomed.tiff). Removing this as a parameter causes the fit to do a much better job (red line in these two graphs). The fit still places the peak 0.01 to the right of the actual peak, which worse than could simply be obtained by looking at the maximum point value. Additionally, this slight shift means that attempting to subtract out the peak so that the other peaks are accessible doesn't work -- the peaks are so steep that the error of 0.01 is enough to cause significant problems (red in attemptedPeakSubtraction.tiff is the attempted subtraction). Part of the problem is that the peaks are far from perfect lorentzians, as seen by cropping to any particular peak (OMCSweepSinglePeak.tiff ). This might be corrected in part by correcting for the conversion from PZT voltage to position, which isn't perfectly linear; though I doubt it would remove all the irregularities. At the moment, the best approach seems to be simply using a center of mass calculation cropped to the particular peak, though I have yet to try this.

Changing Josh's code to work for the digital cameras and the PMC or MC shouldn't be difficult. Changing to the MC or PMC should simply involve changing the EPICs tags for the OMC photodiodes and PZTs to those of the PMC or MC. Making the code work for the digital cameras should be as simple as redirecting the call to the framegrabber software to the Snap software.
Attachment 1: attemptedSinglePeakFitWithoutOffset.tiff
Attachment 2: attemptedSinglePeakFitWithoutOffsetZoomed.tiff
Attachment 3: attemptedPeakSubtraction.tiff
Attachment 4: OMCSweepSinglePeak.tiff
  625   Wed Jul 2 17:19:03 2008 JohnSummaryComputersop440m - shutdown and restarted
After 160days op440m was getting a little slow.
  629   Thu Jul 3 12:36:05 2008 JonhSummarySUSETMY watchdog
ETMY watchdog was tripped. I turned it off and re-enabled the outputs.
  632   Thu Jul 3 16:18:51 2008 robSummaryLockingspecgrams
I used ligoDV to make some spectrograms of DARM_ERR (1), QPDX (2), and QPDY (3). These show the massive instability from 30-40Hz growing in the XARM in the last two minutes of a reasonably high power lock (arm powers up to 30). It's strange that it only shows up in one arm.

CARM is on PO-DC, for both the MCL and the AO path.
DARM is on AS166Q.
Attachment 1: darm_specg.png
Attachment 2: qpdx_specg.png
Attachment 3: qpdy_specg.png
  633   Thu Jul 3 16:57:23 2008 JohnSummaryGeneralFSS_RMTEMP
The FSS room temp alarm has been beeping a lot recently. I altered the FSS_RMTEMP alarm levels using the
same method as Rana.

The alarm is still souding so, at least by my calculations, it must be colder than usual.
Attachment 1: FSStime.png
Attachment 2: FSSalarm.png
  644   Tue Jul 8 00:14:28 2008 JohnSummaryComputersAlarm handler
Rob thought it would be nice to have some alarms on the cpu loads and FE syncs.
I added all these channels to the alarm handler config file and wrote a script
which would set their values (HIHI,HIGH etc).

Ezcawrite allowed me to set the alarm levels (and ezcaread would give the correct
value) but no matter what I set the value to the alarm wouldn't sound.

After experimenting with a few other channels it appears that the alarm handler will
not show alarms if the alarm levels are absent from the db file (even though ezca
gives a value).

I edited the following files so we can have alarms on the cpus.

In c1iscepics:

In c1losepics:

I saved backups in the appropriate folders.

Next time we have a bootfest please also do c1iscepics and c1losepics so these changes
will be implemented.
  648   Tue Jul 8 12:25:54 2008 JohnSummaryPSLISS gain set to 2dB
  653   Wed Jul 9 17:58:19 2008 JohnSummaryGeneralIlluminator alarms
This morning some time was wasted on alignment due to the illuminators.

I added the illuminators to the alarm handler. They will give a RED alarm whenever
they are turned on. You can find the alarms in 40M->Misc->Illuminators.

To do this I edited the Illuminators.db file and restarted c1aux by telneting and typing Ctl-X.
I then added the groups and channels to 40M.alhConfig.
  663   Sun Jul 13 17:19:29 2008 ranaSummaryPSLMOPA SLOWM Calibration
John, Rana

We first unlocked the FSS and ramped the SLOW actuator. With the PMC locked we observed the PMC PZT voltage
as a function of SLOWM (SLOW loop actuator voltage). We believed this to be ~1-5 GHz / V. Since this is
not so precise we then ran a slow (2 min. period) triangle wave into the slow actuator and looked at the
ref cav transmission peaks to calibrate it.

Plot is attached>

We assume that the reference cavity length = 203.2 mm then the FSR = 737.7 MHz. So looking at the plot
and using our eye to measure the SLOWM calibration is 1054 +/- 30 MHz/V. This is probably dominated by
our eye method.

Note: we tried to get the length from T010159-00-R (Michele, Weinstein, Dugolini). In that doc,
the length used is 203.3 mm whereas its 203.2 mm in the PSL FDD (?). The calculation of the FSR is also
incorrect (looks like they used c = 299460900 instead of 299792458 m/s). We took the length from the PSL FDD
(T990025-00-D) but not the FSR, since they also did not find the right value of 'c'. I guess that the speed
of light just ain't what it used to be.
Attachment 1: SLOWDCcalibration.png
  664   Sun Jul 13 22:39:16 2008 JohnSummaryGeneralEdited medm screens
I've edited the FSS and PMC screens so that red boxes are shown around the appropriate slider if a gain or offset is not within the limits defined in C1PSL_SETTINGS_SET.adl

With the current setting of 0 V the FSS input offset is red. According to the settings screen the nominal value is 0.3 +/- 0.050. Are there any objections to editing the nominal value?

I changed the LockMC screen so that red boxes are not shown when the up/down scripts are not running; when they are active you should see a green box.
  665   Mon Jul 14 00:36:19 2008 JohnSummaryPSLSlow sweep of laser temp - PMC PZT response
John, Rana

Follow up to # 663

Top trace: C1: PSL-PMC_PZT

The only calibration I could find for the PMC PZT (LLO e-log Sep 3 2003 - 23 MHz/V) predicts 31V for an FSR. I did a rough calibration and got our FSR to be around 210 V. I assumed 713 MHz for an FSR and applied this calibration (~3.4 MHz/ V) to the PZT data.

In terms of volts per metre our PZT gives 2.54 nm/ V whereas the LLO PZT is 17.16 nm/ V.
Attachment 1: SlowTsweep.png
  667   Mon Jul 14 12:43:07 2008 JohnSummaryComputersRestarted fb40m, tpman and c1ass
  675   Tue Jul 15 12:44:08 2008 JohnSummaryLockingDRFPMI with DC readout
Rob, John

Last night, despite suspect alignment, we were again able to reduce the CARM offset to zero using
the RF signal.We were also able to transfer to dc readout taking calibrated spectra in both states.
DC readout shows a marked improvement over RF above ~1kHz but introduces some noise around 100Hz.
Broadband sensitivity appears to be more than ten times worse than previously. The calibration
being used remains to be confirmed.

Engaging the ETMY dewhitening caused lock to be lost. We'll check this today. The OMC alignment loops
may also need some attention.

We looked at REFL_166 as a candidate for CARM, at present POX still looks better.

The DARM filters were modified to reduce excess noise around 3Hz. Updating filter coefficients does
not cause loss of lock.
  676   Tue Jul 15 19:15:57 2008 ranaSummarySUSETMX Dewhitening characterization
Since the boys found that the ETM dewhitening transient was kicking the IFO out of lock we
decided to investigate.

First, we wrote a script to diagnose and then tune the DC gain of the dewhitening filters'
digital compensation filter (a.k.a. FM9 or SimDW). It is in the scripts/SUS/ directory
and is called dwgaintuner. It puts in an offset on each coil's DAC channel and
then reads back the Vmon on the coil driver with the DWF on and off. It reports the ratio of these
voltages which you can then type into the FM9/SimDW filter's gain field. We learned that the
difference between the analog DWF path and the bypass path was ~3% (which is consistent with
what you expect from the use of 1% resistors). We need to repeat this for all of the rest of
the suspended optics except for MC1 and MC3.

This Vmon method is better than what's used at the sites so we will export this new technology.

The attached plot shows some switching transients with only the local damping on:
BLUE:   Output of filter bank during an FM9 turn off. This is the transient which goes to the DAC.
        The transients are mostly of the same magnitude as this.
RED:    This is the input of the filter module during another such transient.
GREEN:  Tried another switch; this time I filtered the time series in DTT by typing the SimDW into
        the Triggered Time Series filter field. This should be simulating what comes out of the
        output of the DW board - to convert to volts multiply by 15/32768.
PURPLE: Same kind of filtering as the GREEN, but with also a double 30 Hz highpass to remove the low
        frequency damping control signals. You can see that the total transient is only ~5 counts
        or ~1 mV at the coil driver output. This is comparable to the relative offset in the bypass
        and filter paths.
Attachment 1: etmx-dw-transient.pdf
  678   Wed Jul 16 10:50:55 2008 EricSummaryCamerasWeekly Summary
Finished unwrapping, cleaning, baking, wrapping, wrapping again, packing, and shipping the baffles.

Attempted to set up the Snap software so that it could talk directly to EPICS channels. This is not currently working due to a series of very strange bugs in compiling and linking the channel access libraries. Alex Ivanov directed Joe and me to a script and makefile that are similar to what we're trying to do and it may solve our problem, but at the moment this still doesn't work. We're currently using a workaround that involves making unix system calls to ezca command line tools, but this is too hacky to leave in the final program.

Attempted to fit Josh's PZT voltage vs power plot of the OMC (from about a year ago) to lorentzians in order to try to develop fitting tools for more recent data. This isn't working, due to systematic error distorting the shapes of the peaks. Good fits can be obtained by cutting the number of points to a very small number around the peak of resonance, but this leads to such a small percentage of the peak being used that I don't trust these results either. (In the graph (shows the very top of the tallest peak): blue is Josh's original data, green is a fit to this peak using the top 66% of the peak and arbitrary, equal values for the error on each point, red is Josh's data averaged over bins of size 0.005, teal is a fit to these bins where the error on each point is the standard deviation of each bin, and magenta is a fit to these same bins, except cropped to the top ~10% of the peak, x-axis is voltage, y-axis is transmission power). Rana suggested that I take my own sweeps of the PMC using scripts that are already written: I'm currently figuring out where these scripts are and how to use them without accidently breaking something.

We've begun running the Snap software for long periods of time to see how stable it is. Currently, its only problem appears to be that it memory leaks somewhat: it was up 78% memory usage after a little over an hour. It doesn't put much strain on the computer, using only ~20% CPU. Stress put on the network from the constant transfer of images from the camera to the computer is not yet known.
Attachment 1: AttemptedPeakFit3.tiff
  687   Thu Jul 17 00:59:18 2008 JenneSummaryGeneralFunny signal coming out of VCO
While working on calibrating the MC_F signal, Rana and I noticed a funny signal coming out of the VCO. We expect the output to be a nice sine wave at about 80MHz. What we see is the 80MHz signal plus higher harmonics. The reason behind the craziness is to be determined. For now, here's what the signal looks like, in both time and frequency domains.

The first plot is a regular screen capture of a 'scope. The second is the output of the SR spectrum analyzer, as seen on a 'scope screen. The leftmost tall peak is the 80MHz peak, and the others are the harmonics.
Attachment 1: VCOout_time.PNG
Attachment 2: VCOout_freq.PNG
  690   Thu Jul 17 13:08:37 2008 JohnSummaryLSCHOM resonances in the arms
On Tuesday night we attempted to lock the full DRFPMI in the optical spring configuration with the +f2 sideband resonant in the SRC.
Despite having no problems locking on the +f2 in a DRM we couldn't lock the full IFO.

There was some discussion about whether a +f2 higher order mode resonance in the arms could cause this problem.

I calculated the positions of the first six higher order modes for the carrier and all sidebands (using Siegman p 762 (23) with a plus sign).
Plot attached. Colors indicate different frequency components, numbers are the mode index (m+n). Thick lines are fundamental modes of
the sidebands. Heights of HOM indicators have been scaled by 1/(m+n)^2.

It appears that the first order transverse mode of the +166 is indeed partially resonant. We might try to tweak the sideband frequencies a
little to see if this helps us. It would probably be prudent to measure the MC length first.

Numbers used:

L = 38.5750; %average of Alberto's recent measurements elog #556
Retm = 57.375;
f166 = 165.977195e6;
f33 = 33.195439e6;
Attachment 1: HOMresonances.png
  707   Mon Jul 21 14:26:11 2008 MaxSummaryPEMAdded Channels
The following channels have been added.

Channel Name DAQ port

Jenne and I ran the wires from near the beam splitter chamber (as described in a previous elog) to the rack Y7 and plugged the labeled BNC's into ports 27-29. The computer was c0dcu1. John then restarted the frame builder and Alberto and I restarted the front end of c0dcu1 as per the wiki's instructions. The channels seem to be working. - Max.
  722   Wed Jul 23 12:42:23 2008 EricSummaryCamerasWeekly Summary
I finally got the ezcaPut command working. The camera code can now talk directly to the EPICS channels. However, after repeated calls of the ezcaPut function, the function begins claim to time out, even though it continues to write values to the channel successfully (EPICS is successfully getting the new value for the channel, but failing to reply back to the program in time, I think). It has seg-faulted once as well, so the stability cannot yet be trusted for running long term. For now, however, it works well enough to test a servo in the short term. The current approach simply uses a terminal running ezcaservo with the pitch and yaw offset channels of the ETMX, as well as the channels that the camera code output to. This hasn't actually been tested since we haven't had enough time with the x-arm locked.

Tested various fixed zoom lens on the camera, since the one we were previously using was too heavy for its mount and likely more expensive than necessary. The 16mm lens gets a good picture of the beam and the optic together, though the beam is a little too small in the picture to reliably fit a gaussian to. The 24mm lens zooms too much to see the whole optic, but the beam profile itself is much clearer. The 24mm lens is currently on the camera.

Scanned the PZT voltage of the PMC across its full offset range to gain a plot of voltage vs intensity. I used DTT's triggered time series response system to measure the outputs of the slow PZT voltage and transmission intensity channels, and used the script triangle wave to drive the PZT ramp channel slowly over its full range (I couldn't get DTT to output to the channel). Clear resonances did appear (PMCScanWide.tif), but the number of data points per peak was far too small reliably fit a lorentzian to (PMCScanSinglePeak.tif). When I decreased the scanning range and increased the time in order to collect a large number of points on a few peaks, the resulting data was too messy to fit to a lorentzian (PMCSlowSinglePeak.tif).
Attachment 1: PMCScanSinglePeak.tif
Attachment 2: PMCScanWide.tif
Attachment 3: PMCSlowSinglePeak.tif
  734   Thu Jul 24 11:49:07 2008 MashaSummaryAuxiliary lockingbelated weekly summary
I designed a high pass filter to whiten the spectrum from the Mach Zehnder to optimize the
input into the ADC. The swept sine response measurement and the effect of the filter on the
spectrum are attached. If I start using the digital system (it is currently down in Bridge),
I will decide if the filter needs to be improved/better matched to the ADC there.

I moved from the 40m to Rana's lab in bridge. I am making a new and improved Mach Zehnder
setup with a 50m fiber in one arm; currently the transmission through the fiber is 44%. I
am working out how to mode match the laser to the fiber to improve this number.
Attachment 1: filter_tr_function.pdf
Attachment 2: filtered_spectr0724.pdf
  737   Thu Jul 24 21:53:00 2008 ranaSummaryTreasureHigh School Tour group and the PMC
There was a tour today of 40 high school kids. I warned them that the lasers could burn out their
, that the vacuum could suck them through the viewports like tubes of spaghetti and that the
high voltage amps would fry their hair off.

One of them was taking a picture of the SOS in the flow bench and another one was whispering what
a dumb idea it was to leave a sensitive clean optic out where people might breathe on it. I told
one them to cover his mouth. The other one asked what was the glass block behind the SOS.

It was a spare PMC! s/n 00-2677 with a 279 nF capacitance PZT. I guess that this is the one that
Go brought from MIT and then left here. So we don't have to take the one away from Bridge in the
35 W laser lab.

We can swap this one in in the morning while the FSS people work on the reference cavity
alignment. Please email me if you object to this operation.
ELOG V3.1.3-