40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 72 of 335  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  10210   Wed Jul 16 01:27:01 2014 NichinHowToComputer Scripts / ProgramsHP8591E spectrum analyzer remote scan

The script for running continuous scans on HP 8591E spectrum analyzer is located at scripts/general/netgpibdata/HP8591E_contdScan.py

Give the file HP8591E_param.yml as an argument when running the script. This contains the sweep parameters: Start and stop frequencies along with the place where the plot is stored as a PDF.

The default PDF is located on the Desktop and is named HP8591E_View.pdf     Open this using okular and then run the script.  (Okular pdf viewer automatically reloads the PDF as and when a new one is created)

What the script does:

1) Set the start and stop frequencies as given in the .yml file

2) Take a data trace and plot it in a PDF.

3) Repeat taking traces and update the PDF. Untill Ctrl+C is pressed (PDF refresh rate: approximately every 3 seconds )

4) Exit smoothly after the keyboard interrupt.

Other details:

This spectrum analyzer is connected to a GPIB - Ethernet controller that is configured as santuzza.martian (192.168.113.109)

I have currently stolen the wireless modem from the spectrum analyzer inside the lab (vanna.martian) and using it for this one. *poker face*

To improve:

Get the plot to show where the two biggest peaks are located. Currently it recognizes only the biggest one.

Possibly have makers on the two peaks.

PFA a sample pdf

Attachment 1: HP8591E_View.pdf
HP8591E_View.pdf
  10217   Wed Jul 16 17:06:41 2014 NichinUpdateComputer Scripts / ProgramsHP8591E spectrum analyzer remote scan

Updated script does the following:

1) Gets the highest 2 peaks

2) Puts a marker on the peaks. Now it looks very similar to the spectrum analyzer display.

3) The refresh rate is still 3 seconds. It might become better if the analyzer was hooked up to a wired martian LAN port rather than the wireless module I am using now.

PFA a sample pdf

Attachment 1: HP8591E_View.pdf
HP8591E_View.pdf
  10236   Fri Jul 18 15:21:12 2014 ericqUpdateComputer Scripts / ProgramsLocal Chiara backups

Quote:

I've also written a backup script at scripts/backup/rsync_chiara.backup which keeps its books in scripts/backup/rsync_chiara.backup.log 

I'm adding a entry to the root crontab on chiara to execute the script every day at 7am. 

 I had some syntax errors in the script that prevented the script from doing the right thing. The backup is now up to date, and the cronjob should work. 

  10279   Sat Jul 26 15:30:15 2014 Joseph AreedaUpdateComputer Scripts / ProgramsNDS2 server propem on megatron

The NDS2 server on megatron was unresponsive for what i think was the last couple of days.

The NDS the log file (~nds2mgr/logs/nds2-201407151045.log) started reporting "Stage: parser output queue is full." at 2014.7.24 14:47:54 also there are 16 connections still not closed with LindmeierLaptop.cacr.caltech.edu (131.215.146.102) with 15 of them in CLOSE_WAIT. 

To identify these zombie sockets we use "netstat -an | grep 31200"

The server was in a condition that /etc/init.d/nds2 stop didn't work and the process had to be manually kill -9'ed and then about 3 or 4 minutes later the zombie sockets were gone at /etc/init.d/nds2 start was used to restart the server.

The LindemejerLaptop was using pynds to get a bunch of channels at once to test drive a streaming visualization code for glitches.  It's unclear whether this bumped into a server limitation.  We have seen similar states in ldvw that seem to be the result of errors which result in client-server connections not being closed properly, leaving data in an output buffer causing Linux to wait for the other side to empty the buffer.

  10288   Tue Jul 29 18:58:57 2014 NichinUpdateComputer Scripts / ProgramsPDFR update and Test run

The PDFR system's interface and scripts have been updated to include quite a few more features.

On the interface side, there are buttons to open the previous plot for each PD and also a single button to run the scans on all PDs sequentially. The previous plot buttons actually open a softlink that is updated each time a measurement is taken.

Running a scan now pops up a terminal window to show messages that help understand whats going on.

16.png

In the background, the script now takes in the transfer function of the demodulator board in ZPK format and calibrates it out of each measurement. The parameters are given .dat files making it easier to replace the transfer function. (Remember my last elog which showed that the fitting of transfer functions were not really great and that I am going to use it anyway to get the script updated.)  Also, the script now takes the delay in the RF cables and calibrates out that as well. So we no longer have the huge phase variations and the phase related to transimpedance are visible.

A test run was conducted today. Plots attached.

NOTE: The test can be conducted only on REFL 11,33,55,165 , AS55, and POX11.

POY11 has an optical fiber routed from this system, but there is no space to actually illuminate this PD. So it is currently not included in our system, even though there is a button for this.

POP22 has a fiber illuminating it, but its a unknown broadband PD. I do not know it's DC transimpedance or other values. Its just of matter of updating a few files that feed it's parameters into PDFR.

However, for the above PDs, the demodulator boards have been fit to a transfer function and the script is ready to go as soon as the above problems are fixed.

Conclusion: The plots look noisy. But, the transimpedance now resembles the one on 40-m wiki for all the PDs, both the shape and values.

There will be some errors that are induced because of improper demodulator TF fitting. This has to be taken care of eventually.

Work remaining: Create a canonical set of plots for each PD and set them as the baseline. These canonical plots will be plotted along with each measurement for easy comparison.

A well documented manual for the whole system clearly explaining where and how it takes all the parameters into account so that anybody can easy update just the essential information.

Attachment 2: PDFR_testRun_29-07-2014.pdf
PDFR_testRun_29-07-2014.pdf PDFR_testRun_29-07-2014.pdf PDFR_testRun_29-07-2014.pdf PDFR_testRun_29-07-2014.pdf PDFR_testRun_29-07-2014.pdf PDFR_testRun_29-07-2014.pdf
  10292   Tue Jul 29 21:34:41 2014 ericqUpdateComputer Scripts / ProgramsSVN bulletin

A heads up to anyone using SVN with computers on the Martian network:

When we moved the svn repository on nodus to /export, we set it up such that the internet-facing svn URL was unchanged. However, it turns out that the martian network machines (i.e. Stuff mounted on the NFS share) were still pointing to the old svn files in /cvs/cds/caltech/svn, and thus not seeing new revisions made in /export/home/svn. If your martian network svn'd files got weird, this is why. 

I'm relocating the root svn URLs on the martian machines' checkouts to point to the nodus https address as I find them, to make them robust against future local movement of the svn files. 

Peoples' user files should be fine, this looks like it'll only really affect things such as scripts and medm screens, etc. 

  10305   Thu Jul 31 12:01:35 2014 NichinUpdateComputer Scripts / ProgramsPDFR update

The Transimpedance plots of PDFR now have a reference plot or baseline plot along with the current measurement, for easy comparision.

Current Work: Getting Matlab's vectfit3 to work simultaneously on the transimpedance readings and print the zeros and poles alongside the plots. 

Attachment 1: REFL11_31-07-2014_115010.pdf
REFL11_31-07-2014_115010.pdf
  10313   Thu Jul 31 23:19:22 2014 KojiUpdateComputer Scripts / ProgramsSVN bulletin

Did this break "netgpibdata"?

I couldn't download data from SR785. Downloading from AG4395A was OK.

The cause seemed the module for SR785

-rw-rw-r-- 1 controls controls   24225 2014-07-30 18:36 SR785.py

I had a local copy of this file and replaced it with mine. Now netgpibdata start working.
The old one is named SR785.py_bak

-rwxr-xr-x   1 controls staff      12944 Jul 31 23:08 SR785.py

The file size is significantly different from the one we had.

  10323   Fri Aug 1 15:32:07 2014 ericqUpdateComputer Scripts / ProgramsElog and svn backups

Koji and Evan have both brought up a good point that we may not be backing up the svn and ELOG properly.

I have modified the rsync.backup script that nodus' cron runs every night that backs up /cvs/cds to what I presume are the tape backups at ldas-cit.ligo.caltech.edu.

Specifically, I added two rsync commands that grab the svn and elog directories from /export/home and copy them to their old locations in /cvs/cds/caltech. This way, the old locations are updated, and the tape backups stay current.

  10332   Tue Aug 5 17:24:37 2014 NichinUpdateComputer Scripts / ProgramsPDFR update

The PDFR system now has the capability to automatically run vectfit3.mat using a wrapper script named vectorfitzpk.m

This is done via a shell script being called from inside python that inturn runs the matlab script.

  10346   Thu Aug 7 13:39:41 2014 NichinUpdateComputer Scripts / ProgramsWrapping up PDFR

1)The PDFR scripts have all been migrated into /scripts/PDFR/

2) The MEDM screen to run PDFR is /medm/MISC/PDFR.adl

3) A new button has been added on sitemap to open the above medm window.

4) All data and plots generated will sit in /scripts/PDFR/"PD Name"/

5) All features are working after the migration and absolute file paths are being used.

Work Remaining : Manual for others to make changes and keep using my system.

 

  10352   Fri Aug 8 14:27:18 2014 AkhilUpdateComputer Scripts / ProgramsFOL Scripts

 The scripts written for interfacing the FC with R Pi, building EPICS database, piping data into EPICS channels,PID loop for FOL are contained in :

 /opt/rtcds/caltech/c1/scripts/FOL 

The instructions to run these codes on R Pi( controls@domenica) will be available on FOL 40m wiki page.

Also instructions regarding EPICS installation on R Pi and building an EPICS SoftIoc to streamline data from hardware devices into channels will be updated shortly.

 

 

 

 

 

 

  10381   Wed Aug 13 23:58:49 2014 ranaHowToComputer Scripts / ProgramsHP8591E spectrum analyzer remote scan

Quote:

The script for running continuous scans on HP 8591E spectrum analyzer is located at scripts/general/netgpibdata/HP8591E_contdScan.py

There was no such script in the directory when I looked today, but I found one called HP8591E. Of course, it didn't run because it hadn't been tested from the scripts directory and pointed to some /users/nichin/ stuff.

I modified a couple of lines and then committed it and the default .YML parameter file to the SVN. It runs and produces plots continuously from the scripts directory.

*** also, as you can see, we have mostly recovered the green beat amplitudes after yesterday's FLL attack on the ALS ***

Attachment 1: HP8591E_View.pdf
HP8591E_View.pdf
  10421   Thu Aug 21 22:10:52 2014 ranaSummaryComputer Scripts / Programsnetwork movements

 To help development of the data visualization project, we've assigned the .101 and .102 IP to DataVis. This is being used by the iMac in the control room via port 8 of the CDS switch near the Blue Plataeu Tournant.

We tried using one of the free ports, but Jamie realized that we had to use one of the already assigned ones due to some 'Smart' switch management software. So for the moment, please leave the iMac alone so that Bill can use it.

  10456   Fri Sep 5 03:36:00 2014 ranaUpdateComputer Scripts / Programsmartian wireless tweak

 I changed the Martian wireless router to use channel 10 instead of something random (as it was). Using the Android app 'Wifi Analyzer' we could see that the usual channels are dominated by FlumeLab and Caltech Beaver.

The range from 9-13 looked clean so we put it up there. Also, the signal strength drops from -45 to -70 dBm as we walk from the BS down to the ends. We need to tweak the router position and orientation to give us another 10 dB so that we can reliably run the laptops at the ends.

  10467   Mon Sep 8 08:24:49 2014 SteveUpdateComputer Scripts / Programspreparing vac system to reboot

Q and Steve will follow elog 10028 entry to prepare the vacuum system for safe reboot

  10468   Mon Sep 8 11:10:26 2014 ericqUpdateComputer Scripts / Programspreparing vac system to reboot

Quote:

Q and Steve will follow elog 10028 entry to prepare the vacuum system for safe reboot

Here's the sequence of the morning so far:

  • I aligned the IFO (IR arms with ASS, X green with PZTs, PRM with PRMI locked on REFL33)
  • I closed the PSL shutter, and went inside to align PRM and both ITM oplevs (all others were within 10urad of zero in both directions)
  • While aligning those oplevs, I noticed the smell of burnt electronics. We tracked it down to the +15V sorensen in the rack nearest the PSL table
    • I claim the precipitating event was PSL shutter activity. If I recall correctly, the seismic rainbow traces went bonkers around the same time as the shutter was closed. There is a Guralp interface in the rack powered by the failed sorensen, so this would explain the erratic seismometer signals correlated with the power supply failure. We will look into potential shorts caused by the shutter. (Steve looked up the PMC trans and Guralp DQ channels, and confirmed the temporal coincidence of the events.)
  • We shut off all of the sorensens so that electronics were not being driven asymmetrically. 
  • Steve and I secured the vacuum system for computer reboots, as referred to in Steve's elog. Some combination of Jenne, Rana and Manasa shut down the control room computers, and turned off the watchdogs. 
  • Manasa and I moved Chiara inside, next to Mafalda, along with its backup HDs. It has been labeled. 
  • Booted up control room machines, they came up happy. 
  • FB and front-ends didn't need reboot, for some lucky reason. Watchdogs came back happily, oplev spots didn't move noticeably. 

The IFO is still down, as the PMC won't lock without the rack power, and we haven't pinned down the shorting mechanism. We don't want the replacement sorensen to immediately blow when plugged in. 

  10469   Mon Sep 8 11:34:47 2014 ranaUpdateComputer Scripts / Programspreparing vac system to reboot

FYI: in that rack, the +15V pulls ~0.5 A more than -15V usually. I think this is due to some RF amplifiers which are powered by this (e.g. the AOM that Manasa set up). The Sorensen's can source ~30A in principle, so we should make sure to set the current limit appropriately so as to not overheat them when there is a short.

Was this power supply not fused for all of its connections? I remember that this was connected to at least one un-fused connection in the past year.

  10470   Mon Sep 8 12:11:36 2014 manasaUpdateComputer Scripts / Programspreparing vac system to reboot

Quote:

FYI: in that rack, the +15V pulls ~0.5 A more than -15V usually. I think this is due to some RF amplifiers which are powered by this (e.g. the AOM that Manasa set up). The Sorensen's can source ~30A in principle, so we should make sure to set the current limit appropriately so as to not overheat them when there is a short.

Was this power supply not fused for all of its connections? I remember that this was connected to at least one un-fused connection in the past year.

 +15V supply powers the following (from what I see):

1. PMC and MC boards on the rack.

2. RF amplifiers on the rack for the beat signals from the green beat PDs.

3. Beatbox itself.

The beatbox was the one that had an un-fused connection last year. I re-did it properly to go through a fuse quite sometime ago.

I dont see any other un-fused connections now from the +15V supply right now.
 

P.S. AOM driver takes a 0 to +28V power supply and not connected to the +15V

  10472   Mon Sep 8 15:50:47 2014 ericqUpdateComputer Scripts / Programs+15V PSL Sorensen replaced

We replaced the +15V sorensen at 1X1, and brought the power supplies back up symmetrically, and everything seems fine. I noted that a quarter turn counter-clockwise took the current limit down by one amp, so I set the knob to just letting 2.8A (the nominal current), and then added one half turn, shooting for ~4A current limit. 

In doing so, we had to cut power to the c1psl VME box. It didn't come back happily. We had to do the chiara /etc/hosts things, like we did for c1auxexx, to get it back.

  10473   Mon Sep 8 16:23:25 2014 LarryHowToComputer Scripts / Programsaccessing 40m data remotely with python

 

Attached is an example script showing how to access 40m data remotely. The only two nonstandard python modules you need are the nds2 client module and astropy (used for time conversion). For mac users, both of these are available via macports (nds2-client and, e.g. py27-astropy). Otherwise, check out their websites:

https://www.lsc-group.phys.uwm.edu/daswg/projects/nds-client.html

https://github.com/astropy/astropy

 

Have fun!

 

 

Attachment 1: get40mData.ipynb.gz
  10477   Tue Sep 9 14:18:40 2014 SteveUpdateComputer Scripts / Programspreparing vac system to reboot

Quote:

Quote:

Q and Steve will follow elog 10028 entry to prepare the vacuum system for safe reboot

Here's the sequence of the morning so far:

  • I aligned the IFO (IR arms with ASS, X green with PZTs, PRM with PRMI locked on REFL33)
  • I closed the PSL shutter, and went inside to align PRM and both ITM oplevs (all others were within 10urad of zero in both directions)
  • While aligning those oplevs, I noticed the smell of burnt electronics. We tracked it down to the +15V sorensen in the rack nearest the PSL table
    • I claim the precipitating event was PSL shutter activity. If I recall correctly, the seismic rainbow traces went bonkers around the same time as the shutter was closed. There is a Guralp interface in the rack powered by the failed sorensen, so this would explain the erratic seismometer signals correlated with the power supply failure. We will look into potential shorts caused by the shutter. (Steve looked up the PMC trans and Guralp DQ channels, and confirmed the temporal coincidence of the events.)
  • We shut off all of the sorensens so that electronics were not being driven asymmetrically. 
  • Steve and I secured the vacuum system for computer reboots, as referred to in Steve's elog. Some combination of Jenne, Rana and Manasa shut down the control room computers, and turned off the watchdogs. 
  • Manasa and I moved Chiara inside, next to Mafalda, along with its backup HDs. It has been labeled. 
  • Booted up control room machines, they came up happy. 
  • FB and front-ends didn't need reboot, for some lucky reason. Watchdogs came back happily, oplev spots didn't move noticeably. 

The IFO is still down, as the PMC won't lock without the rack power, and we haven't pinned down the shorting mechanism. We don't want the replacement sorensen to immediately blow when plugged in. 

Vacuum safe reboot required one hour of no pumping of the vac envelope.

Attachment 1: v1closedfor1h.png
v1closedfor1h.png
  10511   Tue Sep 16 17:02:41 2014 SteveUpdateComputer Scripts / ProgramsPSL output shutter is floating

Quote:

Quote:

Q and Steve will follow elog 10028 entry to prepare the vacuum system for safe reboot

Here's the sequence of the morning so far:

  • I aligned the IFO (IR arms with ASS, X green with PZTs, PRM with PRMI locked on REFL33)
  • I closed the PSL shutter, and went inside to align PRM and both ITM oplevs (all others were within 10urad of zero in both directions)
  • While aligning those oplevs, I noticed the smell of burnt electronics. We tracked it down to the +15V sorensen in the rack nearest the PSL table
    • I claim the precipitating event was PSL shutter activity. If I recall correctly, the seismic rainbow traces went bonkers around the same time as the shutter was closed. There is a Guralp interface in the rack powered by the failed sorensen, so this would explain the erratic seismometer signals correlated with the power supply failure. We will look into potential shorts caused by the shutter. (Steve looked up the PMC trans and Guralp DQ channels, and confirmed the temporal coincidence of the events.)
  • We shut off all of the sorensens so that electronics were not being driven asymmetrically. 
  • Steve and I secured the vacuum system for computer reboots, as referred to in Steve's elog. Some combination of Jenne, Rana and Manasa shut down the control room computers, and turned off the watchdogs. 
  • Manasa and I moved Chiara inside, next to Mafalda, along with its backup HDs. It has been labeled. 
  • Booted up control room machines, they came up happy. 
  • FB and front-ends didn't need reboot, for some lucky reason. Watchdogs came back happily, oplev spots didn't move noticeably. 

The IFO is still down, as the PMC won't lock without the rack power, and we haven't pinned down the shorting mechanism. We don't want the replacement sorensen to immediately blow when plugged in. 

 The Uniblitz shutter is insulated at the optical table. I only realized it when it was in my hand. The 3"x2" base plate is black DELRIN !

 In the future we must label black Delrin base plate where it is used. Now we have  white Delrin and light bran PEEK  base plates  for the same function.

  10540   Thu Sep 25 15:41:15 2014 ericqUpdateComputer Scripts / ProgramsRossa having a better day

 

I think I found out why rossa was mad. 

An apt-get update on the 18th downloaded kernel 2.6.32-65-generic, so 2.6.32-58-generic, which what was previously chosen as a working kernel, had moved down in the grub ordering.

It turns out the grub configuration accepts strings, so I changed it to GRUB_DEFAULT="Ubuntu, with Linux 2.6.32-58-generic", ran sudo update-grub, and Rossa now seems to boot happily. 

  10543   Fri Sep 26 11:44:55 2014 nicolasFrogsComputer Scripts / ProgramsLoaded larry's fake filter into C1:ALS-OFFSETTER2

 Larry and Nicolas

Larry's transfer function measurements suddenly started returning 0dB 0degrees when before there was some fake filter in the C1:ALS-OFFSETTER2 filter bank.

We looked in the filter bank and his filter was gone. So I created a new filter called LARRYP in FM2. We also disabled the output so he could drive the filter bank and test his TF code.

  10604   Mon Oct 13 21:59:47 2014 ranaUpdateComputer Scripts / ProgramsWhich side of optical spring are we on? (No progress)

 

 Since no one was here, I started the Ubuntu 10 - 12 upgrade on Rossa. It didn't run at first because it wanted to remove 'update-manager-kde' even though it was on the blacklist. I removed it from the command line and now its running. Allegra, OTOH, refuses to upgrade. Someone please ask Diego to wipe it and then install Ubuntu 12 LTS on there in the morning...its a good way to learn the Martian CDS setup.

  10605   Tue Oct 14 17:38:31 2014 ericqUpdateComputer Scripts / ProgramsRossa and Allegra wiped, Ubuntu 12.04 installed

When I came in, Rossa was booted to Ubuntu 10. I tried rebooting to select 12, but couldn't ever successfully boot again. Since Diego was setting up Allegra from scratch, I've wiped and done the same with Rossa. 

  10606   Tue Oct 14 23:44:42 2014 diegoUpdateComputer Scripts / ProgramsRossa and Allegra wiped, Ubuntu 12.04 installed

Allegra and Rossa wiped and updated to Ubuntu 12.04.5 by me and Ericq; the following procedure was followed:

1) create "controls" user with uid=1001, gid=1001
2) setup network configuration (IP, Mask, Gateway, DNS), .bashrc, /etc/resolv.conf
3) add synaptic package manager (Ubuntu Software Center used by default)
4) add package nfs-common (and possibly libnfs1) to mount nfs volumes; mount nfs volume adding the line "chiara:/home/cds/       /cvs/cds/       nfs     rw,bg   0    0" in /etc/fstab
5) add package firmware-linux-nonfree, needed for graphics hardware recognition (ATI Radeon HD 2400 Pro): due to kernel and xorg-server versions of 12.04.5, and because ATI dropped support for legacy cards in their proprietary driver fglrx the only solution is to keep Gallium drivers
6) add packages libmotif3 grace, needed by dataviewer
7) add repository from https://www.lsc-group.phys.uwm.edu/daswg/download/repositories.html (Debian Squeeze); install lcssoft-archive-keyring as first package or apt-get will complain
8) add package lscsoft-metaio libjpeg62, needed by diaggui/awggui (Ericq: used lalmetaio on rossa)
9) add packages python-numpy python-matplotlib python-scipy ipython
10) change ownership of /opt/ to controls:controls
11) add csh package
12) add t1-xfree86-nonfree ttf-xfree86-nonfree xfonts-75dpi xfonts-100dpi, needed by diaggui/awggui (needs reboot)
13) add openssh-server

 

Ubuntu creates the first user during installation with uid=1000 and gid=1000; if needed, they could be changed afterwards using a second user account and the following procedure (twice, if the second users gets the 1001 uid and gid):

sudo usermod -u <NEWUID> <LOGIN>   
sudo groupmod -g <NEWGID> <GROUP>
sudo find /home/ -user <OLDUID> -exec chown -h <NEWUID> {} \;
sudo find /home/ -group <OLDGID> -exec chgrp -h <NEWGID> {} \;
sudo usermod -g <NEWGID> <LOGIN>

  10611   Wed Oct 15 17:18:10 2014 JenneUpdateComputer Scripts / ProgramsDataviewer fix with Ubuntu 12.04

 

 I have modified the Dataviewer launcher (which runs when you either click the icon or type "dataviewer" in the terminal).  

A semi-old problem was that it would open in the file /users/Templates, but our dataviewer templates start in /users/Templates/Dataviewer_Templates.  Now this is the folder that dataviewer opens into.  This was not related to the upgrade to Ubuntu 12, but will be overwritten any time someone does a checkout of the /ligo/apps/launchers folder.

A problem that is related to the Ubuntu 12 situation, which we had been seeing on Ottavia and Pianosa for a few weeks, was that the variable NDSSERVER was set to fb:8088, which is required for cdsutils to work.  However, dataviewer wants this variable to be set to just fb.  So, locally in the dataviewer launcher script, I set NDSSERVER=fb.  NB: I do not export this variable, because I don't want to screw up the cdsutils.  This may need to be undone if we ever upgrade our Dataviewer.

  10628   Tue Oct 21 17:44:28 2014 jamieOmnistructureComputer Scripts / Programsnew version of cdsutils (351) installed

I just installed cdsutils r351 at /ligo/apps/linux-x86_64/cdsutils.  It should be available on all workstations.

It includes a bunch of bug fixes and feature improvements, including the step stuff that Rana was complaining about.

  10655   Thu Oct 30 16:25:22 2014 ericqOmnistructureComputer Scripts / Programsnew version of cdsutils (361) installed

Quote:

I just installed cdsutils r351 at /ligo/apps/linux-x86_64/cdsutils.  It should be available on all workstations.

It includes a bunch of bug fixes and feature improvements, including the step stuff that Rana was complaining about.

Cdsutils r361 installed, for the "avg" updates. aLOG  

 

 

  10667   Tue Nov 4 19:17:53 2014 ericqUpdateComputer Scripts / ProgramsAnaconda + CDSutils

I've fallen down the rabbit hole of trying to reconcile our desire for newer versions of the Numpy and Scipy python packages with the use of our handy cdsutils tools. 


I've set up an installation of Anaconda python in /ligo/apps/anaconda. Installing pyepics, nds2, and cdsutils was straightforward, but there were a myriad of odd python packages that cdsutils depends on, that are typically installed at the OS level (python-gst, gobject, glib) which I just manually copied over to the anaconda directories. Also, the version of readline that anaconda ships with is somewhat borked (dark voodoo fix was found here: github link. The issue mentioned there wasn't why I needed the fix. Somehow libreadline was causing pyepics initialization to fail). 

I was initially hoping this kind of exercise would be useful, as having a separate python environment that we control buffers us from the system installation and allows us to use whatever version of packages we want, but the amount of hackery I did to get to get cdsutils to work probably didn't result in the most robust solution. (Maybe there was a better way!)

In any case, I have not changed any of our machines' default paths or environment variables. Instead, I have simply created an alias that points to Anaconda python: "apython"


Example:

controls@pianosa|scriptTesting > cat foo.py
import scipy as sp
import sys
from ezca import Ezca
ez=Ezca()
print 'Python Version: '+ sys.version
print 'ez.read test:' + str(ez.read('LSC-TRY_OUT16'))
print 'Scipy Version: '+sp.__version__
 
controls@pianosa|scriptTesting > python foo.py
Python Version: 2.7.3 (default, Feb 27 2014, 19:58:35)
[GCC 4.6.3]
ez.read test:0.0154613731429
Scipy Version: 0.9.0
 
controls@pianosa|scriptTesting > apython foo.py
Python Version: 2.7.8 |Continuum Analytics, Inc.| (default, Aug 21 2014, 18:22:21)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)]
ez.read test:0.00307549210265
Scipy Version: 0.14.0

Thus, Diego should now be able to complete his script that needs the newer Scipy, as well as CDSutils. 

Final note: I've tested z (read|write|avg) with $PATH modified to have /ligo/apps/anaconda/bin at the start, and they seem to work. If things seem to hold up, maybe we can replace the default command-line python, but its not strictly necessary. 

  10688   Sat Nov 8 11:31:51 2014 ranaUpdateComputer Scripts / ProgramsAnaconda + CDSutils

Quote:

I've fallen down the rabbit hole of trying to reconcile our desire for newer versions of the Numpy and Scipy python packages with the use of our handy cdsutils tools. 

 Avoid rabbit holes! What I did at LLO which works is to install an Anaconda in some shared directory and then just make an alias which puts that directory at the head of the path when running the more advanced SciPy installs. It works fine and cannot interfere with our usual operation since its only sourced when running peak find.

  10697   Tue Nov 11 19:46:35 2014 diegoUpdateComputer Scripts / ProgramsStatus of the new nodus

The new nodus machine is being brought to life; until installation is finished and everything is fine, the old nodus will be unharmed. For future reference:

New Nodus hardware:

Case: SuperMicro SC825MTQ-R700U

M/B: SuperMicro X8DTU-F

CPU: 2x Intel Xeon X5650

RAM: 3x Kingston KVR1333D3S8R9S (2GB)

         3x Samsung M393B5673EH1-CH9 (2GB)

           Total 12 GB

HDD: Seagate ST3400832AS (400GB)

 

Current software situation and current issues :

1) Ubuntu Server 12.04.5 is installed and updated

2) The usual 'controls' user is present, with UID=1001 and GID=1001

3) Packages installed: nfs-common, rpcbind, ntp, dokuwiki, apache2, php5, openssh-server, elog-2.8.0-2 [from source], make, gcc, libssl-dev [dependencies for elog], subversion

4) Network: interface eth0 is set up (static IP and configuration in /etc/network/interfaces); eth1 is recognized and added, but not configured yet

5) DNS: configuration is in /etc/resolvconf/resolv.conf.d/base (since /etc/resolv.conf is overwritten by the resolvconf program using the 'base' database)

6) ntp is installed and (presumably) configured, but ntpd misbehaves (namely, all the servers are found, but a 

tail /var/log/syslog

shows that no actual synchronization is performed, and the daemon keeps

Listening on routing socket on fd #22 for interface updates

7) dokuwiki apache2 php subversion elog are installed but not configured yet (I need info about their current state, configuration and whereabouts)

8) I copied and merged the old nodus' .bashrc and .cshrc into new nodus' .bashrc, need to know if something has to be added

9) backup frames, backup user dirs and 40m public_html are not set yet, as in #7

 

Is there something missing?

If there is something missing from here (ligo/cds software, smartmontools/hddtemp and similar, or anything else) tell me and I'll set them up.

  10751   Wed Dec 3 21:41:12 2014 JenneUpdateComputer Scripts / ProgramsMatlab license updated

It seems that the old Matlab servers went down a week or so early, so I have updated the Matlab license information in 

/cvs/cds/caltech/apps/linux64/matlab/licenses/

per the instructions on https://www.imss.caltech.edu/content/updating-matlab-license-file

EDIT: Q did this also for the control room iMac

  10759   Fri Dec 5 15:41:45 2014 JenneUpdateComputer Scripts / ProgramsNodus on fast GC network

Apparently, some time ago Larry Wallace installed a new, fast ethernet switch in the old nodus rack. Q and I have just now moved nodus' GC ethernet cable over to the new switch.  Dan Kozak is going to use this faster connection to make the data flow over to the cluster not so lag-y.

  10772   Wed Dec 10 14:22:37 2014 diegoUpdateComputer Scripts / ProgramsStatus of the new nodus

[Diego, Steve]

We ran a Cat 6+ Ethernet cable from the 1X7 rack (where the new nodus is located) to the fast GC switch in the control room rack; now I will learn how to setup the 'outside world' network, iptables, and the like.

 

I remind that the current hardware/software status is posted in elog 10697 ; if additions or corrections are needed, let me know.

 

After I check a couple of things, we can use the new nodus (which is currently known in the martian network as rosalba) as a local test to see that everything is working. After that (and, mostly, after I'll have the network working), we will sync the data from the old nodus to the new one and make the switch.

  10779   Thu Dec 11 12:39:31 2014 diegoUpdateComputer Scripts / ProgramsFrequency Offset Locking scripts status

 I finished the polishing in the scripts/FOL directory, this is the current status and this post replaces my two previous posts on the subject:

  • the Raspberry Pi operates locally: everything is in its /opt/FOL directory, which is a mirror of /opt/rtcds/caltech/c1/scripts/FOL/ ; some backup/sync scripts should be set up, tell me what kind (sync direction, place to call the script from, etc..) is recommended and I'll set it up;

 

  • the /opt/FOL directory contains:
    • ADC_interface                 : Akhil's ADC interface software and dependencies;
    • akhilTestCodes                : Akhil's work directory with his programs and data;
    • backup                             : two zip files with a full backup of the FOL stuff for both chiara and domenica at 2014/12/08, before my work on the directory;
    • fcreadoutApp                   : the EPICS app compiled on domenica. I didn't modify anything in particular here, as I don't know much about EPICS Apps; I'm not even sure if it is used by now, as I launch EPICS manually by just giving him a .db file (see below).
    • armFC*                        : it is the single program that constantly fetches data for the channels: it takes as arguments the RPi device (/dev/hidraw0 for the X arm, and /dev/hidraw1 for the Y arm) and the value to write into the frequency counter (0x3 for initialization and 0x2 for actual use); hence, there is no more need for recompilation!
    • epics_channels.py :  this is the new version of the old codetorun.py script; it handles the initialization and the availability of the two beatnote channels;
    • fcreadout / freqCountIOC : these are the binaries of the EPICS apps that I found on chiara/domenica; they are not used as of now, but could be useful;
    • fcreadout.db           : it is the database file that is loaded by EPICS to handle the channels;
    • FOLPID.pl              : the Perl PID controller; it is still the old version, we will work on this one later on (see Manasa's schedule at elog 10760 for info)

 

  • Domenica's environment:
    • as I said, everything runs locally from /opt/FOL;
    • in particular, I added in /etc/inittab two lines that launch EPICS and the python script for the channels; respawn is supported so these processes should always be available. For this to happen, DO NOT MOVE armFC, epics_channels.py and fcreadout.db from the /opt/FOL directory on domenica!
    • I added a udev rule in /etc/udev/rules.d/98-hidraw-permissions.rules to let the controls user access the /dev/hidraw* devices without having to sudo all the time;
    • I updated the ~/.bashrc and /opt/epics/epics-user-env.sh files to fix syntax errors and add some aliases we usually use.
  10783   Thu Dec 11 17:45:54 2014 ericqUpdateComputer Scripts / ProgramsLockloss plotting

 With some advice from Jamie, I've gotten the lock loss plotting script that is used at LHO working on our machines. The other night, I modified the ALSwatch.py script to log lockloss times. Tying it together, I've written a small wrapper script that grabs the last time from the lockloss log, and plots it. 

It is: scripts/LSC/LocklossData/lastlock.sh

Jamie's going to make an adjustment to the pydv codebase that will let me implement the auto y-scaling that we like. We also will need to get a feel for the right timing window, once we see what kind of delay in the ALSwatch script is typical. 

Here's an example of the output, with the window of [-10,+2] seconds from the logged GPS time:

figure.png

 

  10784   Thu Dec 11 18:00:43 2014 ericqUpdateComputer Scripts / ProgramsMC error signal monitoring

The other day, I hooked up the agilent analyzer to OUT2 of the MC board, which is currently set to output the MC refl error signal.  I've written a GPIB-based program that continuously polls the analyzer, and plots the live spectrum, an exponentially weighted running mean, and the first measured spectrum. 

The intended use case is to see if the FSS or MC loops are going crazy when we're locking. Sometimes the GPIB interface hangs/loses its connection, and the script needs a restart.

The script lives in scripts/MC/MCerrmon

 

 

  10793   Fri Dec 12 19:38:49 2014 diegoUpdateComputer Scripts / ProgramsStatus of the new nodus

Quote:

[Diego, Steve]

We ran a Cat 6+ Ethernet cable from the 1X7 rack (where the new nodus is located) to the fast GC switch in the control room rack; now I will learn how to setup the 'outside world' network, iptables, and the like.

 

I remind that the current hardware/software status is posted in elog 10697 ; if additions or corrections are needed, let me know.

 

After I check a couple of things, we can use the new nodus (which is currently known in the martian network as rosalba) as a local test to see that everything is working. After that (and, mostly, after I'll have the network working), we will sync the data from the old nodus to the new one and make the switch.

[Diego, EricQ]

Update: work is almost completed; the old nodus is still online, as I don't feel confident to make the switch and leave it on its own for the weekend. However, the new nodus is online with the IP address 131.215.114.87, so everyone can check that everything works. From my tests I can say that:

After everything will be in place, I will save every reasonably important configuration file of nodus into the svn.

 

I remind that every change made while accessing the 131.215.114.87 machine will be purged during the sync&switch

 

  10797   Mon Dec 15 12:53:13 2014 ericqUpdateComputer Scripts / ProgramsStatus of the new nodus

 Nodus (solaris) is dead, long live Nodus (ubuntu).

Diego and I are smoothing out the Kinks as they appear, but the ELOG is running smoothly on our new machine. 

SVN is working, but your checkouts may complain because they expect https, and we haven't turned SSL on yet...

  10798   Mon Dec 15 16:27:57 2014 diegoUpdateComputer Scripts / ProgramsStatus of the new nodus

Quote:

 Nodus (solaris) is dead, long live Nodus (ubuntu).

Diego and I are smoothing out the Kinks as they appear, but the ELOG is running smoothly on our new machine. 

SVN is working, but your checkouts may complain because they expect https, and we haven't turned SSL on yet...

 [Diego, EricQ]

SSL, https and backups are now working too!

A backup of nodus's configuration (with some explaining) will be done soon.

  10805   Tue Dec 16 20:49:25 2014 diegoUpdateComputer Scripts / ProgramsStatus of the new nodus

Quote:

Quote:

 Nodus (solaris) is dead, long live Nodus (ubuntu).

Diego and I are smoothing out the Kinks as they appear, but the ELOG is running smoothly on our new machine. 

SVN is working, but your checkouts may complain because they expect https, and we haven't turned SSL on yet...

 [Diego, EricQ]

SSL, https and backups are now working too!

A backup of nodus's configuration (with some explaining) will be done soon.

 Nodus should be visible again from outside the Caltech Network; I added some basic configuration for postfix and smartmontools; configuration files and instructions for everything are in the svn in the nodus_config folder

  10815   Thu Dec 18 15:41:30 2014 ericqUpdateComputer Scripts / ProgramsOffsite backups of /cvs/cds going again

Since the Nodus switch, the offsite backup scripts (scripts/backup/rsync.backup) had not been running successfully. I tracked it down to the weird NFS file ownership issues we've been seeing since making Chiara the fileserver. Since the backup script uses rsync's "archive" mode, which preserves ownership, permissions, modification dates, etc, not seeing the proper ownership made everything wacky. 

Despite 99% of the searches you do about this problem saying you just need to match your user's uid and gid on the NFS client and server, it turns out NFSv4 doesn't use this mechanism at all, opting instead for some ID mapping service (idmapd), which I have no inclination of figuring out at this time. 

Thus, I've configured /etc/fstab on Nodus (and the control room machines) to use NFSv3 when mounting /cvs/cds. Now, all the file ownerships show up correctly, and the offsite backup of /cvs/cds is churning along happily. 

  10816   Thu Dec 18 16:21:08 2014 ericqUpdateComputer Scripts / Programsscripts not being backed up!

 I just stumbled upon this while poking around:

Since the great crash of June 2014, the scripts backup script has not been workingon op340m. For some reason, it's only grabbing the PRFPMI folder, and nothing else. 

Megatron seems to be able to run it. I've moved the job to megatron's crontab for now.

  10817   Fri Dec 19 14:25:48 2014 diegoUpdateComputer Scripts / Programselog restarted

elog was not responding for unknown reasons, since the elogd process on nodus was alive; anyway, I restarted it. 

  10819   Fri Dec 19 16:39:25 2014 ericqUpdateComputer Scripts / Programselog autostart

I've set up nodus to start the ELOG on boot, through /etc/init/elog.conf. Also, thanks to this, we don't need to use the start-elog.csh script any more. We can now just do:

controls@nodus:~  $ sudo initctl restart elog

I also tweaked some of the ELOG settings, so that image thumbnails are produced at higher resolution and quality. 

  10820   Fri Dec 19 16:59:32 2014 ericqUpdateComputer Scripts / ProgramsFSS Slow servo moved to megatron

Given that op340m showed some undesired behavior, and that the FSS slow seems prone to railing lately, I've moved the FSS slow servo job over to megatron in the same way I did for the MC autolocker. 

Namely, there is an upstart configuration (megatron:/etc/init/FSSslow.conf), that invokes the slow servo. Log file is in the same old place (/cvs/cds/caltech/logs/scripts), and the servo can be (re)started by running: 

controls@megatron|~ > sudo initctl start FSSslow

Maybe this won't really change the behavior. We'll see

  10824   Fri Dec 19 20:44:23 2014 JenneUpdateComputer Scripts / ProgramsFSS Slow servo moved to megatron

Today Q moved the FSS slow servo over to some init thing on megatron, and some time ago he did the same thing to the MC auto locker script.  It isn't working though.

Even though megatron was rebooted, neither script started up automatically.  As Diego mentioned in elog 10823, we ran sudo initctl start MCautolocker and sudo initctl start FSSslow, and the blinky lights for both of the scripts started.  However, that seems to be the only thing that the scripts are doing.  The MC auto locker is not detecting lockloses, and is not resetting things to allow the MC to relock.  The MC is happy to lock if I do it by hand though.  Similarly, the blinky light for the FSS is on, but the PSL temperature is moving a lot faster than normal.  I expect that it will hit one of the rails in under an hour or so. 

The MC autolocker and the FSS loop were both running earlier today, so maybe Q had some magic that he used when he started them up, that he didn't include in the elog instructions?

ELOG V3.1.3-