40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 297 of 341 Not logged in
ID Date Author Type Category Subject
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
11084   Fri Feb 27 11:20:49 2015 ericqUpdateComputer Scripts / ProgramsiPython Notebook for LSC Sensing Matrix
 Quote: ** 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.

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.

4742   Wed May 18 18:48:46 2011 kiwamuUpdateElectronicsidentification of RFPD interface cables

[Haixing / Kiwamu]

As a part of the Wednesday's cabling work, we spent some times for identifying the RFPD interface cables.

The RFPD interface cables are made of a 15 pin flat cable, containing DC power conductors for the RFPDs and the DC signal path.

The list below is the status of the interface cables.

- - - - RFPD name, (cable status) - - - -

- REFL11 (identified and labeling done)

- REFL33 (identified and labeling done)

- REFL55 (identified and labeling done)

- REFL165 (no cable found)

- AS55 (identified and labeling done)

- AS165 (identified and labeling done)

- POP22/110 (identified and labeling done)

- POX11 (identified and labeling done)

- POY11 (identified and labeling done)

- POY55 (identified and labeling done)

We still have two cables which are not yet identified. Their heads are around the LSC rack and labeled 'unidentified'

7676   Tue Nov 6 18:39:16 2012 DenUpdatedigital noiseifo checking system

Matlab version of ifo digital noise estimation code is almost ready. It estimates digital noise introduced by each filter bank in each model. I'm waiting for NDS group to complete function to download online data to Matlab. Now code downloads data from the past that is not great because not all _IN1 channels are recorded and some of them are recorded at lower frequencies.

There might be some useful functions in this code for other applications as I've heard during the meetings. This is what it does

• reads model names from the input list
• for each model
• finds corresponding Foton file and extracts modules with sos filters and sampling rate of the model
• finds corresponding MDL file and makes a search for subsystems with "top_names" tag and "biquad=1" tag
• creates _IN1 channel names using module names and subsystems with "top_names" tag
• for each channel inside the model
• reads filter bank parameters (which filters are ON, switches, limit, offset...)