40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 295 of 339 Not logged in
ID Date Author Type Category Subject
6721   Wed May 30 22:51:32 2012 DenUpdatePEMguralp isolation box

When I've put Guralps inside the isolation box, the signal from seismometers increased and was out of AA board range. I've reduced the gain of the readout box by a factor of 2. Now R2 for channels 1-6 is (2000, 1050, 1050, 2000, 1050, 1050) Ohm.

The signal increased in the frequency range 30-50 Hz. Guralp noise become better. That's good. However, it is still worse then in the manual.

As Yuta is dancing on the isolation box, Guralp signal is most time out of the AA board range. So I calculated the noise based on 5 min data. This may be enough, but I'll repeat the experiment later with 30 min data.

6696   Tue May 29 00:35:57 2012 DenUpdatePEMguralp readout box

I measured the frequency response of the Guralp readout box and noise by providing sin signal of amplitude 50 mV at 15 Hz for channels 1-3.

It turns out that the gain is ~250, while my liso model simulated it to be 200. This is because it is hard to approximate AD620 amplifier.

Noise of the box does not seem to be too bad at low frequencies.

6618   Mon May 7 21:46:10 2012 DenUpdateCDSguralp signal error

GUR1_XYZ_IN1 and GUR2_XYZ_IN1 are the same and equal to GUR2_XYZ.  This is bad since GUR1_XYZ_IN1 should be equal to GUR1_XYZ.  Note that GUR#_XYZ are copies of GUR#_XYZ_OUT, so there may be (although there isn't right now) filtering between the _IN1's and the _OUT's.  But certainly GUR1 should look like GUR1, not GUR2!!!

Looks like CDS problem, maybe some channel-hopping going on? I'm trying a restart of the c1sus computer right now, to see if that helps.....

Figure:  Green and red should be the same, yellow and blue should be the same.  Note however that green matches yellow and blue, not red.  Bad.

6757   Tue Jun 5 21:09:40 2012 yutaUpdateComputer Scripts / Programshacked ezca tools

Currently, ezca tools are flakey and fails too much.
So, I hacked ezca tools just like Yoichi did in 2009 (see elog #1368).

For now,

/ligo/apps/linux-x86_64/gds-2.15.1/bin/ezcastep
/ligo/apps/linux-x86_64/gds-2.15.1/bin/ezcaswitch
/ligo/apps/linux-x86_64/gds-2.15.1/bin/ezcawrite

are wrapper scripts that repeats ezca stuff until it succeeds (or fails more than 5 times).

Of course, this is just a temporary solution to do tonight's work.
To stop this hack, run /users/yuta/scripts/ezhack/stophacking.cmd. To hack, run /users/yuta/scripts/ezhack/starthacking.cmd.

Original binary files are located in /ligo/apps/linux-x86_64/gds-2.15.1/bin/ezcabackup/ directory.
Wrapper scripts live in /users/yuta/scripts/ezhack directory.

I wish I could alias ezca tools to my wrapper scripts so that I don't have to touch the original files. However, alias settings doesn't work in our scripts.
Do you have any idea?

6768   Wed Jun 6 18:04:22 2012 JamieUpdateComputer Scripts / Programshacked ezca tools

 Quote: Currently, ezca tools are flakey and fails too much. So, I hacked ezca tools just like Yoichi did in 2009 (see elog #1368). For now, /ligo/apps/linux-x86_64/gds-2.15.1/bin/ezcaread /ligo/apps/linux-x86_64/gds-2.15.1/bin/ezcastep /ligo/apps/linux-x86_64/gds-2.15.1/bin/ezcaswitch /ligo/apps/linux-x86_64/gds-2.15.1/bin/ezcawrite are wrapper scripts that repeats ezca stuff until it succeeds (or fails more than 5 times). Of course, this is just a temporary solution to do tonight's work. To stop this hack, run /users/yuta/scripts/ezhack/stophacking.cmd. To hack, run /users/yuta/scripts/ezhack/starthacking.cmd. Original binary files are located in /ligo/apps/linux-x86_64/gds-2.15.1/bin/ezcabackup/ directory. Wrapper scripts live in /users/yuta/scripts/ezhack directory. I wish I could alias ezca tools to my wrapper scripts so that I don't have to touch the original files. However, alias settings doesn't work in our scripts. Do you have any idea?

I didn't like this solution, so I hacked up something else.  I made a new single wrapper script to handle all of the utils.  It then executes the correct command based on the zeroth argument (see below).

I think moved all the binaries to give them .bin suffixes, and the made links to the new wrapper script.  Now everything should work as expected, with this new retry feature.

controls@rosalba:/ligo/apps/linux-x86_64/gds-2.15.1/bin 0$for pgm in ezcaread ezcawrite ezcaservo ezcastep ezcaswitch; do mv$pgm{,.bin}; ln ezcawrapper $pgm; done controls@rosalba:/ligo/apps/linux-x86_64/gds-2.15.1/bin 0$ cat ezcawrapper
#!/bin/bash

retries=5

pgm="$0" run="${pgm}.bin"

if ! [ -e "$run" ] ; then cat <&2 This is the ezca wrapper script. It should be hardlinked in place of the ezca commands (ezcaread, ezcawrite, etc.), and executing the original binaries (that have been moved to *.bin) with$retries
failure retries.
EOF
exit -1
fi

if [ -z "$@" ] || [[ "$1" == '-h' ]] ; then
"$run" exit fi for try in$(seq 1 "$retries") ; do if "$run" "$@"; then exit else echo "retrying ($try/$retries)..." >&2 fi done echo "$(basename $pgm) failed after$retries retries." >&2
exit 1


6769   Wed Jun 6 18:22:52 2012 JamieUpdateComputer Scripts / Programshacked ezca tools

 Quote: I didn't like this solution, so I hacked up something else.  I made a new single wrapper script to handle all of the utils.  It then executes the correct command based on the zeroth argument (see below). I think moved all the binaries to give them .bin suffixes, and the made links to the new wrapper script.  Now everything should work as expected, with this new retry feature.

Yuta and I added a feature such that it will not retry if the environment variables EZCA_NORETRY is set, e.g.

## 27-inch iMac

• Part number: Z0M6

Configuration

• 2.7GHz Quad-Core Intel Core i5
• 16GB 1333MHz DDR3 SDRAM - 4x4GB
• 1TB Serial ATA Drive
• AMD Radeon HD 6770M 512MB GDDR5
• Apple Mouse
• Apple Keyboard with Numeric Keypad (English) & User's Guide
• Accessory Kit
11081   Fri Feb 27 01:59:57 2015 ranaHowToLSCiPython Notebook for LSC Sensing Matrix

I have adapted one of Evan's python scripts into an ipython notebook for calculating our PRMI sensing matrix - the work is ~half done.

The script gets the data from the various PD channels (like REFL33_I) and demdoulates it at the modulation frequencies. At the moment its using just the sensing channels, but with the recent addition of the SUS-LSC_OUT_DQ channels, we can demod the actuation channels as well and not have to hand code the exc amplitudes and the basolute phase. Please ignore the phase for the moment.

The attached PDF shows the demod (including lowpass) outputs for a 2 minute stretch of PRMI locked on f2. Next step is to average these numbers and make the radar plots with the error bars. The script is scripts/LSC/SensingMatrix/PRMIsensMat.ipynb and is in the SVN now.

** along the way, I noticed that the reason this notebook hasn't been working since last night is that someone sadly installed a new anaconda python distro today  without telling anyone by ELOG. This new distro didn't have all the packages of the previous one. I've updated it with astropy and uncertainties packages.

I've fixed the Radar plot making part, so that's now included too. The radial direction is linear, so you can see from the smearing of the blobs that the uncertainty is represented in the graphics due to each measurement being a small semi-transparent dot. Next, we'll put the output of the statistics on the plot: mean, std, and kurtosis.

Attachment 1: Plots_1109056456.pdf
Yesterday, I was trying to install a package with anaconda's package manager, conda, but it was crashing in some weird way. I wasn't able to fix it, which led me to create a fresh installation.