A    c1/lsc/help/C1LSC_LA_SET.txt
svn: In directory 'c1/lsc/help'
svn: Can't copy 'c1/lsc/help/.svn/tmp/text-base/C1LSC_RFadjust.txt.svn-base' to 'c1/lsc/help/.svn/tmp/C1LSC_RFadjust.txt.tmp.tmp': No such file or directory

I found a strange jump of value in my data taken with tdsdata.
I couldn't find same jump in a playback of DataViewer, so I think this is a problem of tdsdata.
Be careful when you use tdsdata!

The attached file is an example of jumped data.
I try to get data with allegra and op440m, and both has same kind of jump.
(A downsampling or interpolation may be wrong.)

Rana said there is a fixed version of tdsdata in some PC, but 64bit linux may not have.
I try it tomorrow.

 Both the Upgrade and the Old40m's signals look anomalous since the zero-crossing point does not change with the demodulation phases.

I suspect there's is a problem with the optickle model of the 40m.

Matt logged in and rebuilt the TDS stuff for us on Mafalda in /cvs/cds/caltech/apps/linux/tds_090304.

He says that he can't build his stuff on 64-bit because there's not a sanctioned 64-bit build of GDS yet.

This should have all the latest fixes in it. I tried using both the old and new code from allegra and they both are fine:

./tdsdata 16384 2 C1:IOO-MC_F > /users/rana/test.txt

I loaded the data I got with the above command and there were no data dropouts. Possibly the dropout problem is only

associated with testpoints and so we have to wait for the TP fix.

I tested new tdsdata and found it was working well.

I excited C1:SUS-ITMY_SUSPIT_EXC with tdssine, and get data from C1:LSC-TRY_OUT (testpoint) and C1:SUS- ITMY_OPLEV_PERROR (recorded point) with new and old tdsdata.

With old tdsdata (/cvs/cds/caltech/apps/linux/tds/bin/tdsdata), I found some jumps of datapoint, which is a same problem with before (Attachment 1).

With new tdsdata (/cvs/cds/caltech/apps/linux/tds_090304/bin/tdsdata), there looks to be no jumps (Attachment 2; taken about 10 minutes after Attachment 1).

The problem of old tdsdata looks to be remaining even for recordedpoints.

You should use /cvs/cds/caltech/apps/linux/tds_090304/bin/tdsdata.

We confirmed that new tds(/cvs/cds/caltech/apps/linux/tds_090304/) works well on linux 64, and replaced it to /cvs/cds/caltech/apps/linux/tds/

The old /cvs/cds/caltech/apps/linux/tds is put in /cvs/cds/caltech/apps/linux/tds.bak

 The tdscntr.pl in the new tds was probably the one from LLO, which is actually the version I sent to Tobin. It had paths and channel names defined for the LLO. So I copied back my original 40m version.

The ndsproxy tcl task on nodus was eating up all the CPU and making the elog slow. I killed it and restarted it.

It looks like it hasn't been making a log file since January. Someone who has some skill in decoding the cryptic csh stdout redirection

syntax should look into this (its in target/ndsproxy/)

I edited the configure scripts (those called from the C1IFO_CONFIGURE screen) for restore XARM and YARM.  These used to misalign the ITM of the unused arm, which is totally unnecessary here, as we have both POX and POY.  They also used to turn off the drive to the unused ETM.  I've commented out these lines, so now running the two restores in series will leave a state where both arms can be locked.  This also means that the ITMs will never be deliberately mis-aligned by the restore scripts.

I added op540m's display 0 (the northern-most monitor in the control room) to the MEDM screens webpage: https://nodus.ligo.caltech.edu:30889/medm/screenshot.html

Now we can see the StripTool displays that are usually parked on that screen.

I started two scripts, senseDRM and loadDRMImatrixData.m, which Peter will bang on until they're correct.  They're in the $SCRIPTS/LSC directory.  The first is a perl script which uses TDS tools to drive the DRM optics and measure the response at the double demod photo-detectors, and write these results to a series of files loadable by matlab.  The second loads the output from the first script, inverts the resulting sensing matrix to get an input matrix, and spits out a tdswrite command which can be copied and pasted into a terminal to load the new input matrix values. 

What's left is mainly in figuring out how to do the matrix inversion properly.  Right now the script does not account for the output matrix, the gains in the feedback filters at the measurement frequency, or the fact that we'll likely want the UGF of our loops to be less than the measurement frequency.  Peter's going to hash out these details.

I am attempting to use the DTT program to look at the coherence of the individual accelerometer signals with the MC_L signal. Rana suggested that I might break up the XYZ configuration, so i wanted to see how the coherence changed when I moved things around over the past couple of weeks, but I keep getting a synchronization error every time I try to set the start time to more than about 3 days ago. I tried restarting the program and checking the "reconnect" option in the "Input" tab, neither of which made any kind of difference. I can access this data with no problem from the Data Viewer and the Matlab scripts, so I'm not really sure what is happening. Help?

EDIT: Problem solved - Full data was not stored for the time I needed to access it for DTT.

I ran the start Apache script as described by Yoichi in the WIki. SVN back up.

Lately I've been trying to sort out the problem of the discrepancy that I noticed between the values read on the spectrum analyzer's display and what we get with the GPIB interface.

It turns out that the discrepancy originates from the two data vector that the display and the GPIB interface acquire. Whereas the display shows data in "RAW" format, the GPIB interface, for the way the netgpibdata script is written, acquires the so called "error-corrected data". That is the GPIB downloaded data is postprocessed and corrected for some internal calibration factors of the instrument.

 I noticed that someone, that wasn't me, has edited the wiki page about the netgpibdata under my name saying:

 " [...]

* A4395 Spectrum Units
Independetly by which unites are displayed by the A4395 spectrum analyzer on the screen, the data is saved in Watts/rtHz"

 The elog crashed when I was uploading a photo just now. I logged into nodus and restarted it.

I've installed COMSOL 4.0 for 32/64 bit Linux in /cvs/cds/caltech/apps/linux64/COMSOL40/

It seems to work, sort of.

Notes:

1. It did NOT work according to the instructions. The CentOS automount had mounted /dev/scd0 on /media/COMSOL40. In this configuration, I was getting a permission denied error when trying to run the default setup script. I did a 'sudo umount /dev/scd0' to get rid of this bad mount and then remounted using 'sudo mount /dev/dvd /mnt'. After doing this, I ran the setup script '/mnt/setup' and got the GUI which started installing as usual.
2. I also pointed it at the linux64/matlab/ installation.
3. It seems to not work right on Rosalba because of my previous java episode. The x-forwarding from megatron also fails. It does work on allegra, however.

I placed a script for killing all instances of the dataviewer program on the current computer in /cvs/cds/caltech/scripts/general/.  Its called killdataviewer.  This is intended to get rid of a bunch of zombie dataviewer processes quickly.  These processes get into this bad state when the dataviewer program is closed in any way other than the graphical menu File -> Exit option.

Its contents are very simple:

#/bin/bash

kill `ps -ef | grep dataviewer | grep -v grep | grep -v killdataviewer | awk '{print $2}'`

Someone had left a typo in the MC autolocker script recently while trying to set the lock threshold to 0.09. As a result, the autlocker wouldn't run.

I repaired it, made a few readability improvements, and checked in the new version to the SVN. If you make script changes, check them in. If you think its too minor of a change for a SVN checkin, don't do it at all.

I made some changes to the elog on nodus:

• Made a backup of /cvs/cds/caltech/elog/elog-2.7.5/elogd.cfg called elogd.cfg.bk.20100407 in the same directory
• Added a folder: /cvs/cds/caltech/elog/elog-2.7.5/logbooks/EAGER_Lab
• Restarted the elog daemon via the start-elog-nodus script in the elog-2.7.5 directory

I saw that the current version of the elog seems to be in the svn, so tried to svn the changes from nodus via ssh, but got this message:

"svn: This client is too old to work with working copy '/cvs/cds/caltech/elog/elog-2.7.5'; please get a newer Subversion client."

I feel I should svn this but don't want to *&#@ the svn/elog up.

For now I will leave it alone and ask a question: Is the folder /cvs/cds/caltech/elog/elog-2.7.5/ under SVN control? Is it also under CVS control?

TL;DR:  New tab added to elog.

I've wheeled the old HP audio frequency signal analyzer into the control room to debug the GPIB/python interface. The wireless setup was getting more than 80% packet loss in the office area.

I also noticed that we have multiple and competing copies of the netgpib package installed. Kiwamu is going to merge them soon. Pleae only use the official location:

scripts/general/netgpibdata/

which is also the SVN working copy. Committ all changes periodicallty so that we can share the updated versions between sites.

Joe and I were looking at the RCG VCO algorithm to determine if we could adapt it to run at a faster rate (you can currently change its frequency at 1Hz). I noticed that the algorithm that is used to calculated the values of sine and cosine at time T1  is a truncated Taylor series which uses the values of sine and cosine calculated at time T1 - Delta t . I was concerned that there would be an accumulating phase error so I tested the algorithm in MATLAB and compared it to a proper calculation of sine and cosine. It turns out that at a given 'requested' frequency there is a constantly accumulating phase error - which means that the 'actual' frequency of the RCG VCO is incorrect. So I have plotted the frequency error vs requested VCO frequency. It gets pretty bad!

 Here's the code I used:

dt = 1/16384;

diffList = [];
% set the frequencies
flist = 1:5:8192;
for f = flist;
   
    % get the 'accurate' values of sine and cosine
    tmax = 0.05;
    time1 = dt:dt:tmax;
    sineT = sin(2.0*pi*f*time1);
    cosineT = cos(2.0*pi*f*time1);
   
    % determine the phase change per cycle
    dphi = f*dt*2*pi;
    cosT1 = 1:numel(time1);
    sinT1 = 0*(1:numel(time1));
   
    % use the RCG VCO algorithm to determine the values of sine and cosine
    for ii = 1:numel(time1) - 1;                 
        cosNew = cosT1(ii)*(1 - 0.5*dphi^2) ...
                      - (dphi)*sinT1(ii);
        sinNew = sinT1(ii)*(1 - 0.5*dphi^2) ...
                      + (dphi)*cosT1(ii);
                 
       
        cosT1(ii+1) = [ cosNew];
        sinT1(ii+1) = [ sinNew];
       
    end
    % extract the phase from the VCO values of sine and cosine
    phaseT = unwrap(angle(cosineT + i* sineT));
    phaseT1 = unwrap(angle((cosT1 + i*sinT1)));
   
    % determine the phase error for 1 cycle
    diff = phaseT1 - phaseT;
    % determine the frequency error
    slope = (diff(2) - diff(1))/(dt);
   
    diffList = [diffList, slope];
    disp(f)
    pause(0.001)
end

% plot the results
close all
figure
orient landscape
loglog(flist, abs(diffList/(2.0*pi)))
xlabel('Requested VCO Frequency (Hz)')
ylabel('Frequency error (Hz)')
grid on

print('-dpdf', '/users/abrooks/VCO_error.pdf')


I added an alias to the sitemap MEDM screen in /cvs/cds/caltech/target/cshrc.40m

Now you can enjoy launching sitemap from a terminal.

alias sitemap 'medm -x /cvs/cds/rtcds/caltech/c1/medm/sitemap.adl'

I thought that "m40m" was the traditional alias for the sitemap...

rossa:~>alias
...

m40m ${medm_base} ${medm_newtail} &
...
sitemap medm -x /cvs/cds/rtcds/caltech/c1/medm/sitemap.adl

rossa:~>set|grep medm
medm_base       medm
medm_newtail    -x /opt/rtcds/caltech/c1/medm/sitemap.adl
medm_tail       -x /cvs/cds/caltech/medm/sitemap.adl

I have made a python script to generate the button designed by Jeff Kissel for his ISI screen.

It is currently located at the following location:
/cvs/cds/rtcds/caltech/c1/medm/c1lsc_tst/master/KisselButtonGenerator/generate_KisselButton.py
but should be relocated to somewhere appropriate.
It also uses fragmented medm files named "MATRIX*.adl_parts".

# Jamie, could you suggest the right place?

The parameters are assigned at the beggining of the script.
This script print the result to stdout. So you need to redirect the output into a file.
e.g.
> ./generate_KisselButton.py >tmp.adl


The script should be modified such that it accepts the command line options.
It needs more python learning for me.

# Number of the column
mat_h = 20;

# Number of the row
mat_v = 10;

# horizontal pixel size of the rectangular display for each matrix element
button_width = 8;

# vertical pixel size of the rectangular display for each matrix element
button_height = 8;

replace_dict = {
# Title
    '${DISPLAY_LABEL}':'ITMX_INMATRIX', 
# Path of the MEDM file to be open by clicking the button
    '${DISPLAY_NAME}':'/cvs/cds/rtcds/caltech/c1/medm/c1sus/master/C1SUS_ITMX_INMATRI
X_MASTER.adl',
# The channel name of the matrix element
# ($V and $H are replaced to the numbers i.e. "_3_4")
    '${MATRIX_CHAN}':'C1:SUS-ITMX_INMATRIX_$V_$H'
    };

Now the Kissel-button generator takes the command line arguments and options.
The script is fully documented by the usage message of the script itself.
It still needs the external supporting files "MATRIX*.adl_parts".

Now the LSC screen has these buttons for the input and output matrices.
The command lines to generate those buttons are listed at the end of this entry as the examples.

>pwd
/opt/rtcds/caltech/c1/medm/c1lsc_tst/master/KisselButtonGenerator


>./generate_KisselButton.py -h
usage:
generate_KisselButton.py [options]  end_row end_column matrix_ch_name

This generates an MEDM screen of a button with the style designed by
Jeff Kissel for his ISI screens. This button has a display of a matrix
elements. If the matrix element is non-zero it glows in green. Otherwise
its color is dark. Usually the button created by this script
is to be copy-pasted to other screens.

Three arguments have to be given:
  end_row         the number of the row at the end
  end_column      the number of the column at the end
  matrix_ch_name  the channel name of the matrix to be monitored
                  e.g. give C1:LSC-OUTPUT_MTRX for C1:LSC-OUTPUT_MTRX_1_1, ...

There are options prepared in order to control the parameters of the button.

example:
generate_KisselButton.py 6 6 C1:LSC-OUTPUT_MTRX
      6x6 matrix for C1:LSC-OUTPUT_MTRX


options:
  -h, --help          show this help message and exit
  --sr=START_ROW      specify the starting row number for the button array.
                      [default: 1]
  --sc=START_COLUMN   specify the starting column number for the button array.
                      [default: 1]
  --bw=BUTTON_WIDTH   specify the pixel width of the small button. [default:
                      8]
  --bh=BUTTON_HEIGHT  specify the pixel height of the small button. [default:
                      8]
  --dl=DISPLAY_LABEL  specify the button label. [default: channel name]
  --sn=SCREEN_NAME    specify the file name of the screen opened when one
                      click the button. The relative or absolute path can be
                      included. [default: a name guessed from the channel
                      name. e.g. C1LSC_OUTPUT_MTRX.adl for C1:LSC-OUTPUT_MTRX]


>./generate_KisselButton.py --bw=3 --bh=4 --dl="RFPD InMTRX" 16 8 C1:LSC-PD_DOF_MTRX > rfpd_mtrx.adl

>./generate_KisselButton.py --sc=21 --bw=6 --bh=4 --dl="DCPD InMTRX" 27 8 C1:LSC-PD_DOF_MTRX > dcpd_mtrx.adl

>./generate_KisselButton.py --bw=4 --bh=4 --dl="Trig MTRX" 11 8 C1:LSC-TRIG_MTRX > trig_mtrx.adl

>./generate_KisselButton.py --bw=4 --bh=4 --dl="Out MTRX" 9 10 C1:LSC-OUTPUT_MTRX > output_mtrx.adl

This CSHRC mangling on Feb 4 did more than re-arrange FB binaries.

It broke the path to MEDM for the 32-bit machines in the lab (e.g. mafalda) and stopped the MEDM snapshots from being posted onto our MEDM Status Web Page.

This is because, in addition to the paths mentioned in the above elog, the paths to the EPICS directories were also commented out. I've re-inserted them into our

.cshrc file in the 32-bit section; the statScreen CRON that Yoichi set up is now back in business.

* for some reason, the 'cronjob.sh' script is wiping out its own log file. It would be great if someone who understands stderr output re-direction can fix it so that the log-file from each run is retained until the next time cron runs.

I found a mode matching solution to match the beam coming to the PSL table from the AP table so that I can lock the laser beam coming onto the PSL table to the reference cavity on the table. I determined that at the polarizing beam splitter, I want a beam with a q=(147+25.1i)mm (w0=58mm). This came from applying the ABCD matrices for three distances,

• d1=693 mm,
• d12=660.4 mm, and
• d2=393.7 mm, separated
• an f=229.1 mm planoconvex lens and
• an R=300 mm curved mirror.

to a beam with q0 = 406.4i mm (w0=0.371 mm at the PMC).

I obtained the following mode matching solution, which I will try to implement on the PSL table:

The beam I have has waist 0.281 mm at -2.74 m (I set my origin at the polarizing beam splitter--the spot where I want my beam to match the beam coming from the PMC, so all waists are behind that point). These numbers  come from the beam-profiling and MATLAB-fitting I did (see 5015).

The solution I chose was: f = 1145.6 mm at -0.95 m and f = 572.7 mm at -0.62 m. This may need to be changed however, if I need to add in some beam steering, which would increase the path length traveled by the beam.

A new offset-zeroing script has been developed and it is ready to run.

 The motivation is to replace the old zeroing script called offset by a better one because this old script somehow failed to revert the gain settings on a given filter bank.

The new script, named offset2, does the same job, but uses tdsavg instead of using ezcaservo. So it doesn't screw up the gain settings.

Additionally the structure of the script is much simpler than the old offset script, and fewer ezca-functions.

I will modify some scripts which use the old offset script so that all the offset-zeroing is done by offset2.

P.S.

Useful scripts are listed on the 40m wiki

http://blue.ligo-wa.caltech.edu:8000/40m/Computers_and_Scripts/All_Scripts

I ended up having to switch to a different mode-matching solution, because I was unable to find the f = 572.7 mm lens. See my next elog entry (5069).

Josh Smith, Fabian Magana-Sandoval, Jackie Lee (Fullerton)

Thanks to Jamie and Jenne for the tour and the input on the pages.

We had a look at the GEO summary pages and thought about how best to make a 40m summary page that would eventually become and aligo summary page. Here's a rough plan:

- First we'll check that we can access the 40m NDS2 server to get data from the 40m lab in Fullerton.

- We'll make a first draft of a 40m summary page in python, using pynds, and base the layout on the current geo summary pages.

- When this takes shape we'll iterate with Jamie, Jenne, Rana to get more ideas for measurements, layout.

Other suggestions: Jenne is working on an automated noisebudget and suggests having a placeholder for it on the page. We can also incorporate some of the features of Aidan's 40m overview medm screen that's in progress, possibly with different plots corresponding to different parts of the drawing, etc. Jenne also will email us the link of once per hour medm screenshots.

elog died b/c someone somewhere did something which may or may not have been innocuous. I ran the script in /cvs/cds/caltech/elog to restart the elog (thrice).

I have now banned Warren from clicking on the elog from home

Restarted elog 9:11PM 9/5/11