40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 320 of 339  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  11966   Mon Feb 1 14:08:06 2016 SteveUpdatePEMroof condtion is good

It rained hard yesterday. We have not had this strong downpoor for years. We got 0.7" and the roof did not leak.

  3495   Tue Aug 31 13:31:00 2010 steveUpdatePEMroom temp lowered

I lowered room 101 thermostat setting from 74F to 72F

  3497   Tue Aug 31 15:26:46 2010 ranaUpdatePEMroom temp lowered

And I raised it back to 73F. The thermometers on the wall show 74-75F as the actual room temp. The dial on the temperature controller is not calibrated.

  2646   Sun Feb 28 23:47:52 2010 ranaUpdateComputersrosalba

Since Rosalba wanted to update ~500 packages, I let it do it. This, of course, stopped the X server from running. I downloaded and installed the newest Nvidia driver and its mostly OK.

The main problem with the auto-update on our workstations is that we've updated some packages by hand; i.e. not using the standard CentOS yum. So that means that the auto-update doesn't work right. From now on, if you want to install a fancier package than what CentOS distributes, you should commit to handle the system maintenance for these workstations for the future. Its not that we can't have new programs, we just have to pay the price.

 

At 23:45 PST, I also started a slow triangle wave on the AOM drive amplitude. This is to see if there's a response in the FSS-FAST which might imply a coupling from intensity noise to frequency noise via absorbed power and the dn/dT effect in the coatings.

Its a 93 second period triangle modulating the RC power from 100% down to 50%.

  6573   Thu Apr 26 16:35:34 2012 JamieSummaryCDSrosalba now running Ubuntu 10.04

This morning I installed Ubuntu 10.04 on rosalba.  This is the same version that is running on pianosa.  The two machines should be identically configured, although rosalba may be missing some apt-getable packages.

  6653   Mon May 21 19:16:55 2012 KojiUpdateGeneralrossa X config

I rebooted rossa and the X sever has stalled.

  14780   Fri Jul 19 17:42:58 2019 gautamUpdateGeneralrossa Xdisp bricked

For some reason, rossa's Xdisplay won't start up anymore. This happened right after the UPS reset. Koji and I tried ~1.5 hours of debugging, got nowhere.

  14794   Sun Jul 21 22:16:34 2019 ranaUpdateGeneralrossa Xdisp bricked

"bricked" is to mean that it has the functionality of a brick and can be tossed. But rossa seems to have just gotten some software config corruption. I spent a couple hours reinstalling SL7 today as per my previous elog notes and the X display seems to work as before.

i.e. it was fine with the default setup, except for the ole "X chrashes if the mouse goes to left side of screen". As before, I

  1. blacklisted the nouvaeu driver (which is used by default)
  2. download the NVIDIA driver as per the link
  3. run its installation from the no-X terminal

left side of screen is safe again

This time I installed SL7.6 and followed the K Thorne wiki. But its having trouble installing cds-root because it can't find root.frown

 

  16075   Thu Apr 22 14:49:08 2021 gautamUpdateComputer Scripts / Programsrossa added to RTS authorized keys

This is to facilitate running of scripts like the CDS reboot script, mx_stream restart, etc, from rossa, without being pwd prompted every time, whereas previously it was only possible from pianosa. I added the public key of rossa to FB and the RT FE servers. I suppose I could add it to the Acromag servers too, but I haven't yet.

  14784   Sat Jul 20 11:24:04 2019 gautamUpdateGeneralrossa bricked

Summary:

SnapPy scripts made to work on Pianosa.

Details:

Of course rossa was the only machine in the lab that could run the python scripts to interface with the GigE camera. And it is totally bricked now. Lame.

So I installed several packages. The key was to install pypylon - if you go to the basler webpage, pypylon1.4.0 does not offer python2.7 support for x86_64 architecture, so I installed pypylon1.3.0. Here are the relevant lines from the changelog:

gstreamer-plugins-bad-0.10.23-5.el7.x86_64    Sat 20 Jul 2019 11:22:21 AM PDT
gstreamer-plugins-good-0.10.31-13.el7.x86_64  Sat 20 Jul 2019 11:22:11 AM PDT
gstreamer-plugins-ugly-0.10.19-31.el7.x86_64  Sat 20 Jul 2019 11:20:08 AM PDT
gstreamer-python-devel-0.10.22-6.el7.x86_64   Sat 20 Jul 2019 10:34:35 AM PDT
pygtk2-devel-2.24.0-9.el7.x86_64              Sat 20 Jul 2019 10:34:34 AM PDT
pygobject2-devel-2.28.6-11.el7.x86_64         Sat 20 Jul 2019 10:34:33 AM PDT
pygobject2-codegen-2.28.6-11.el7.x86_64       Sat 20 Jul 2019 10:34:33 AM PDT
gstreamer-devel-0.10.36-7.el7.x86_64          Sat 20 Jul 2019 10:34:32 AM PDT
gstreamer-python-0.10.22-6.el7.x86_64         Sat 20 Jul 2019 10:34:31 AM PDT
gtk2-devel-2.24.31-1.el7.x86_64               Sat 20 Jul 2019 10:34:30 AM PDT
libXrandr-devel-1.5.1-2.el7.x86_64            Sat 20 Jul 2019 10:34:28 AM PDT
pango-devel-1.42.4-1.el7.x86_64               Sat 20 Jul 2019 10:34:27 AM PDT
harfbuzz-devel-1.7.5-2.el7.x86_64             Sat 20 Jul 2019 10:34:26 AM PDT
graphite2-devel-1.3.10-1.el7_3.x86_64         Sat 20 Jul 2019 10:34:26 AM PDT
pycairo-devel-1.8.10-8.el7.x86_64             Sat 20 Jul 2019 10:34:25 AM PDT
cairo-devel-1.15.12-3.el7.x86_64              Sat 20 Jul 2019 10:34:25 AM PDT
mesa-libEGL-devel-18.0.5-3.el7.x86_64         Sat 20 Jul 2019 10:34:24 AM PDT
libXi-devel-1.7.9-1.el7.x86_64                Sat 20 Jul 2019 10:34:24 AM PDT
pygtk2-doc-2.24.0-9.el7.noarch                Sat 20 Jul 2019 10:34:23 AM PDT
atk-devel-2.28.1-1.el7.x86_64                 Sat 20 Jul 2019 10:34:21 AM PDT
libXcursor-devel-1.1.15-1.el7.x86_64          Sat 20 Jul 2019 10:34:20 AM PDT
fribidi-devel-1.0.2-1.el7.x86_64              Sat 20 Jul 2019 10:34:20 AM PDT
pixman-devel-0.34.0-1.el7.x86_64              Sat 20 Jul 2019 10:34:19 AM PDT
libXinerama-devel-1.1.3-2.1.el7.x86_64        Sat 20 Jul 2019 10:34:19 AM PDT
libXcomposite-devel-0.4.4-4.1.el7.x86_64      Sat 20 Jul 2019 10:34:19 AM PDT
libicu-devel-50.1.2-15.el7.x86_64             Sat 20 Jul 2019 10:34:18 AM PDT
gdk-pixbuf2-devel-2.36.12-3.el7.x86_64        Sat 20 Jul 2019 10:34:17 AM PDT
pygobject2-doc-2.28.6-11.el7.x86_64           Sat 20 Jul 2019 10:34:16 AM PDT
pygtk2-codegen-2.24.0-9.el7.x86_64            Sat 20 Jul 2019 10:34:15 AM PDT

Camera server is running on a tmux session on pianosa. But it keeps throwing up some gstreamer warnings/errors, and periodically (~every 20 mins) crashes. Kruthi tells me that this behavior was seen on Rossa as well, so whatever the problem is, doesn't seem to be because I missed out on installing some packages on pianosa. Moreover, if the server is in fact running, I am able to take a snapshot - but the camera client does not run.

  6662   Tue May 22 20:24:06 2012 JamieUpdateComputersrossa is now running Ubuntu 10.04

Now same as pianosa and rosalba.  I'll upgrade allegra on Friday.

  3524   Sun Sep 5 21:35:41 2010 ranaConfigurationComputersrossa notes

**** Deleted
apps/emacs
apps/linux64/firefoxold
apps/linux64/comsol      (old v. 3.5)

* running up2date on rossa

* rossa needs to be able move windows between monitors: Xinerama?

* there are permissions problems: controls on rossa can't
make and delete directories made by 'controls' elsewhere.
Some sort of user# or group issue?

  3531   Tue Sep 7 10:50:53 2010 josephbConfigurationComputersrossa notes

The controls group is user id 500 by default on most new machines. Unfortunately, the user ID used across the already existing machines is 1001. One method of doing this switch is in this elog.  You can also do the change of the controls ID by becoming root and using the graphical command system-config-users.  This will  let you change the user ID and group ID for controls to 1001.  This graphical interface also lets you change the login shell.

Unfortunately, I had some minor difficulty and I ended up removing the old controls and creating a new controls account with the correct values and using tcsh.  The .cshrc file has been recreated to source cshrc.40m.  The controls account now has correct permissions, although some of the preferences such as background will need to be reset.

 

 

Quote:

**** Deleted
apps/emacs
apps/linux64/firefoxold
apps/linux64/comsol      (old v. 3.5)

* running up2date on rossa

* rossa needs to be able move windows between monitors: Xinerama?

* there are permissions problems: controls on rossa can't
make and delete directories made by 'controls' elsewhere.
Some sort of user# or group issue?

 

  3539   Tue Sep 7 23:17:45 2010 sanjitConfigurationComputersrossa notes

Quote:

* rossa needs to be able move windows between monitors: Xinerama?

 Xinerama support has been enabled on rossa using nvidia-settings.

  3557   Sat Sep 11 03:16:51 2010 ranaConfigurationComputersrossa notes

I wiped out the old CentOS install on rossa and installed CentOS 5.5 on there. The DVDs are on a spindle in the control room; there were 2 iso's, but I only needed the first to install most things.

It still needs to get all of the usual stuff (java, flash, nvidia) installed as well as setting up the .cshrc and the NFS mount of /cvs/cds. The userID and groupID are set to 1001 as before. Whoever

sees Sanjit first should steer him towards this elog entry.

 

  3559   Sun Sep 12 22:36:03 2010 ranaConfigurationComputersrossa notes

I found Sanjit's instructions for doing the Nvidia settings too complicated and so I followed these instructions from Facebook:

http://www.facebook.com/notes/centos-howtos/installing-nvidia-display-drivers-on-centos-55/399295987425

After installations, the monitors were autodetected and the Xinerama effect is working.

  3517   Thu Sep 2 21:22:31 2010 Sanjit, KojiConfigurationComputersrossa nvidia driver and dual monitor configuration

 

Simple steps (but don't try these on a working computer without getting some experience on a spare one, you may find it difficult to restore the system if something goes wrong):

  1. download the appropriate driver from NVIDIA website for this computer
    • we did: NVIDIA GeForce 310 64bit Linux, version: 256.53, release date 2010.08.31
  2. keep/move the driver in /root (use "sudo" or "su")
  3. reboot the computer in "single user" mode
    • in the GRUB screen edit the boot command by pressing the appropriate key listed in the screen
    • in the boot command-line put " single" in the end (no other change is normally needed), don't save
    • press ENTER and the system will reboot to a root shell (# prompt)
  4. cd /root
  5. run the NVIDIA driver script
  6. exit the shell (ctrl-d), let the system reboot
    • it should flash (mostly green) "nvidia" screen before starting X
    • in case of problems run system-config-display and revert to vesa driver
  7. login as "root" and run "nvidia-settings" from command line or GUI menu to add/configure display

 

  3518   Thu Sep 2 23:35:33 2010 ranaConfigurationComputersrossa nvidia driver and dual monitor configuration

Why are we running CentOS 4.8 instead of 5.5 ?    What runs at LLO?     What runs in Downs?

  3521   Fri Sep 3 11:23:16 2010 josephbConfigurationComputersrossa nvidia driver and dual monitor configuration
At LLO the machines are running Centos 5.5. A quick login confirms this. Specifically the release is 2.6.18-194.3.1.el5.

Quote:

Why are we running CentOS 4.8 instead of 5.5 ?    What runs at LLO?     What runs in Downs?

 

  15447   Wed Jul 1 18:16:09 2020 gautamUpdateComputersrossa re-re-revival

In an effort to make a second usable workstation, I did the following (remotely) on rossa today (not necessarily in this order, I wasn't maintaining a live log so I forgot):

  1. Fixed /etc/resolv.conf, so that the other martian machines can be found.
  2. Copied over .bashrc file, and the appropriate lines from /etc/fstab from pianosa to rossa.
  3. Ran sudo apt install nfs-common. Then ran sudo mount -a to get /cvs/cds mounted.
  4. Made symlinks for /users and /opt/rtcds , and /ligo. All of these are used by various environment-setting scripts and I chose to preserve the structure, though why we need so many symlinks, I don't know...
  5. Set up the shell variable $NDSSERVER using export NDSSERVER=fb:8088. I'm not sure how, but I believe DTT, awggui etc use this on startup to get the channel list (any
  6. Followed instructions from Erik von Reis at LHO to install the cds workstation packages and dependencies. Worked like a charm 🎃
  7. As a test, I plotted the accelerometer spectra in DTT, see Attachment #1. I also launched foton from inside awggui, and confirmed that the sample rate is inherited and I could designate a filter. But I haven't yet run the noise injection to test it, I'll do that the next time I'm in the lab.
  8. Also checked that medm, StripTool and ndscope, and anaconda python all seem to work 👍🏾.

So, in summary, rossa is now all set up for use during lock acquisition. However, until this machine has undergone a few months of testing, we should freeze the pianosa config and not mess with it.

Note that this version of the "crtools" is rather new. Please, use them and if there is an issue, report the errors! I am going to occassionally try lock acquisition using rossa. 

Quote:

wiped and install Debian 10 on rossa today

still to be done: config it as CDS workstation

please don't try to "fix" it in the meantime

Attachment 1: MCacc.pdf
MCacc.pdf
  15449   Sun Jul 5 16:14:41 2020 ranaUpdateComputersrossa re-re-revival

maybe we should make a "dd" copy of pianosa in case rossa has issues and someone destroys pianosa by accidentally spilling coffee on it.

So, in summary, rossa is now all set up for use during lock acquisition. However, until this machine has undergone a few months of testing, we should freeze the pianosa config and not mess with it.

  14925   Wed Oct 2 20:45:18 2019 ranaUpdateComputersrossa revival

Formatted and re-installing OS on rossa for the 3rd or 4th time this year. I suggest that whoever is installing software and adjusting video settings please stop.

If you feel you need to tinker deeply, use ottavia or zita and then be prepared to show up and fix it.

While I was moving the UPS around, the network lights went out for Rossa, so I may have damaged the network interface or cable. Debugging continues.

  14935   Thu Oct 3 21:50:22 2019 ranaUpdateComputersrossa revival

Got the network to work again just by unplugging the power cord and letting it sit for awhile. But corrupted OS by trying to install Nvidia drivers.

https://www.advancedclustering.com/act_kb/installing-nvidia-drivers-rhel-centos-7/

  14994   Mon Oct 28 18:55:06 2019 ranaUpdateComputersrossa revival

back on new Rossa from Xi computing

  1. switched to using Display Port for video; this works. The DVi, HDMI, VGA ports are connected to the motherboard rather than the video card, so they are not active.
  2. runs super slow w/ SL 7.6; maybe some service is running after startup?
  3. install repos and update according to LLO CDS wiki
  4. add controls user and group according to LLO wiki
  5. remove gstreamer ugly because it breaks yum update
  6. run 'yum update --skip-broken' because GDS doesn't work
  7. turn off old selinux stuff
  8. modify fstab to get NFS

Next:

  1. finish mounting
  2. xfce
  3. figure out why the LLO install instructions can't install any CDS software (e.g. root, DTT, etc)

Update: Sun Nov 3 18:08:48 2019

  1. moved the SL7 fresh install repos back into etc/yum.repos.d/. The LLO instructions has me remove them, but the LLO supplied repos are no good for standard apps. After putting these back was able to install standard apps (terminator, root, diaggui)
  2. copied over /etc/fstab lines from pianosa sothat the NFS mounts work correctly
  3. added symlinks so that the NFS dirs mount in the right dirs
  4. symlink libsasl2.so.3 -> libsasl2.so.2 and now DTT runs and can get data now and in the past
  5. install XFCE
  6. sitemap / MEDM works
  7.  Did "sudo ln -s /usr/lib64/libXm.so.4 /usr/lib64/libXm.so.3" to enable StripTool.

Update: Fri Nov 15 00:00:26 2019:

  1. random hanging of machine while doing various window moving or workspace switching
  2. turned off power management in XFCE
  3. turned off power management on monitor
  4. disabled SELINUX
  5. firewalld was already off
  6. installed most, pdftk, htop, glances, qtgrace, lesstif
  7. dataviewer now works and QTgrace is much nicer than XMGrace
  15141   Wed Jan 22 16:38:01 2020 ranaUpdateComputersrossa revival

wiped and install Debian 10 on rossa today

still to be done: config it as CDS workstation

please don't try to "fix" it in the meantime

  13487   Mon Dec 18 17:48:09 2017 ranaUpdateComputersrossa: SL7.3 upgrade continues

Following instructions from LLO-CDS fo the rossa upgrade. Last time there were some issues with not being to access the LLO EPEL repos, but this time it seems to be working fine.

After adding font aliases, need to run 'sudo xset fp rehash' to get the new aliases to take hold. Afterwards, am able to use MEDM and sitemap just fine.

But diaggui won't run because of a lib-sasl error. Try 'sudo yum install gds-all'.

diaggui: error while loading shared libraries: libsasl2.so.2: cannot open shared object file: No such file or directorycrying (have contacted LLO CDS admins)

X-windows keeps crashing with SL7 and this big monitor. Followed instructions on the internet to remove the generic 'Nouveau' driver and install the proprietary NVDIA drivers by dropping to run level 3 and runnning some command line hoodoo to modify the X-files. Now I can even put the mouse on the left side of the screen and it doesn't crash. laugh

  14023   Tue Jun 26 22:06:33 2018 ranaUpdateComputersrossa: SL7.3 upgrade continues: DTT is back

I used the following commands to get diaggui to run on rossa/SL7:

controls@rossa|lib64> ls -lrt libsasl*
-rwxr-xr-x. 1 root root 121296 Feb 16  2016 libsasl2.so.3.0.0
lrwxrwxrwx. 1 root root     17 Dec 18  2017 libsasl2.so -> libsasl2.so.3.0.0
lrwxrwxrwx. 1 root root     17 Dec 18  2017 libsasl2.so.3 -> libsasl2.so.3.0.0
controls@rossa|lib64> sudo ln -s libsasl2.so.3.0.0 libsasl2.so.2
controls@rossa|lib64> ls -lrt libsasl*
-rwxr-xr-x. 1 root root 121296 Feb 16  2016 libsasl2.so.3.0.0
lrwxrwxrwx. 1 root root     17 Dec 18  2017 libsasl2.so -> libsasl2.so.3.0.0
lrwxrwxrwx. 1 root root     17 Dec 18  2017 libsasl2.so.3 -> libsasl2.so.3.0.0
lrwxrwxrwx. 1 root root     17 Jun 26 22:02 libsasl2.so.2 -> libsasl2.so.3.0.0

 

Basically, I have set up a symbolic link to point sasl2.so.2 to sasl2.so.3.0.0. I've asked LLO again for some guidance on whether or not to find some backport in a non-standard SL7 repo. IF they reply, we may later replace this link with a regular file.

For the nonce, diaggui runs and is able to show us the spectra. We also got swept sine to work. But the FOTON launched from inside of AWGGUI doesn't inherit the sample frequency of the excitation channel so we can't filter noise injections from awggui yet.

  14025   Wed Jun 27 19:05:20 2018 ranaUpdateComputersrossa: SL7.3 upgrade continues: DTT is back

UNELOGGED: someone has changed Pianosa from Ubuntu/Dumbian into SL7. Might be hackers.

Donatella is now the only Ubuntu machine in the control room. I propose we keep it this way for another month and then go fully SL7 if we find no bugs with Pianosa/Rossa.

  15463   Thu Jul 9 16:16:20 2020 gautamUpdateComputersrossa: graphics driver issues?

I noticed these streaky lines again today (but they were not a problem last night). It is annoying if we have to reboot this machine all the time. I wonder if this has something to do with missing drivers. When I ran sudo apt update && sudo apt upgrade, I got several lines like (this isn't the whole stack trace)

W: Possible missing firmware /lib/firmware/nvidia/gp108/acr/ucode_unload.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gp108/acr/ucode_load.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gp108/acr/unload_bl.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gp108/acr/bl.bin for module nouveau

Is this indicative of the graphics drivers being installed incorrectly? I am hesitant to mess with this because I think in the past, it was always trying to update some graphics driver that crashed the whole machine into some weird state where we have to wipe the drive and do a fresh re-install of the OS.

Should we just follow these instructions? The graphics card is apparently Quadro P400, which is one of the supported ones according to the list of supported devices.

Or just swap donatella and rossa monitors and defer the problem for later?

Quote:

yes, I rebooted yesterday to fix the 'steaking white lines' problem in the video/display

  15452   Mon Jul 6 00:37:28 2020 gautamUpdateComputersrossa: lib symlink

This is strange - I was definitely able to launch medm when I was working on this machine remotely on Friday. But now, there does seem to be a problem with this shared library being missing.

First of all, I installed mlocate to find where the shared library files are installed. Then I made the symlink, and now sitemap seems to work again.

Weirdly, my changes to /etc/resolv.conf got overwritten somehow. Was this machine rebooted? Uptime suggests it's only been running for ~6 hours at the time of writing of this elog.

sudo apt install mlocate
sudo updatedb
sudo ln -s /usr/lib/x86_64-linux-gnu/libreadline.so.7 /usr/lib/x86_64-linux-gnu/libreadline.so.6
Quote:

when I try 'sitemap' on rossa I get:

medm: error while loading shared libraries: libreadline.so.6: cannot open shared object file: No such file or directory

  15454   Mon Jul 6 12:43:02 2020 ranaUpdateComputersrossa: lib symlink

yes, I rebooted yesterday to fix the 'steaking white lines' problem in the video/display

maybe we're supposed to edit something besides resolv.conf since that gets over-written on boot for some linux OS

  15469   Sat Jul 11 00:10:22 2020 gautamUpdateComputersrossa: more developmental work

After some consultation with Erik von Reis at LHO, this workstation is progressing towards being usable for most commissioning tasks. DTT, awggui, foton, and MEDM are all now working well. The main limitation now comes from the fact that many of our python scripts are written for python2, and rossa doesn't have many dependencies installed for python2. I see no reason to build these dependencies on rossa for python2, we should not have to work with an unsupported language. But at the same time, I don't want to completely wipe all our python2 scripts, and make them python3, because this would involve a lot of tedious testing that I'm not prepared to undertake at the moment (the problem is compounded by the fact that pianosa does not have many dependencies installed for python3).

So what I have done in the interim is make python3 versions of the most important scripts I need to get the PRFPMI locking working - they are in the scripts directory and have the same names as their python2 counterparts, but have a 3 appended to their names. So when working on rossa, these are the scripts that are called. Eventually, after a lot more testing, we can depracate the old scripts. Currently, where applicable, the MEDM screens allow for either the python2 or python3 version of the script to be called.

Please, for the time being, do not try and install any new packages on rossa unless you are prepared to debug any problems caused and return the machine to a workable state. If you find some issue with a missing package on rossa, (i) make a note of it on the elog, and (ii) if possible, set up your own conda environment for testing and install dependencies to that environment only.

  15473   Mon Jul 13 11:33:18 2020 ranaUpdateComputersrossa: more developmental work

I too, would prefer py3 for everything, but aren't all the cdsutils / gaurdian things still python2?

Is it possible to just make a python2 conda environment on rossa? I would guess that its simple and won't interfere with the regular operation of that machine.

  15475   Mon Jul 13 12:37:05 2020 gautamUpdateComputersrossa: more developmental work

In fact, all these utilities are now available in python3. There may be some bugs (e.g. this), but I've checked basic functionality and things look usable enough for development to proceed. While we can have a python2 env on rossa, I think it's unnecessary.

Quote:

I too, would prefer py3 for everything, but aren't all the cdsutils / gaurdian things still python2?

  15460   Wed Jul 8 22:50:33 2020 gautamUpdateComputersrossa: more symlinks

I wanted to try using rossa as my locking workstation today. However, a few problems became quickly evident. Basically, any of our scripts that rely on the cdsutils package (there are MANY) will not work on rossa, because of some library error. This machine is running Debian 10, while the cdsutils package is being loaded from a pre-compiled install on the shared drive, so perhaps this isn't surprising?

Digging a little more, I found that actually, a version of cdsutils that actually works with python3 is actually shipped with the standard cds-workstation meta-package. This is great news, and we should try and use this where possible I guess. Deferring further debugging for daytime work.

Anyway, I added a symlink: sudo ln -s /usr/lib/x86_64-linux-gnu/libncurses.so.6 /usr/lib/x86_64-linux-gnu/libncurses.so.5, and installed wmctrl using sudo apt install wmctrl

  15451   Sun Jul 5 18:39:57 2020 ranaUpdateComputersrossa: printer

I did

sudo usermod -a -G lpadmin controlscheeky

and then was able to add Grazia to the list of printers for Rossa by following the instructions on the 40m Wiki. yes


I installed color syntax highlighting on Rossa using the internet (https://superuser.com/questions/71588/how-to-syntax-highlight-via-less). Now if you do 'less genius_code.py', it will be highlighting the python syntax.


when I try 'sitemap' on rossa I get:

medm: error while loading shared libraries: libreadline.so.6: cannot open shared object file: No such file or directory
 

  15455   Mon Jul 6 12:51:41 2020 gautamUpdateComputersrossa: resolvconf installed

Indeed, this is now fixed by following instructions from here. I rebooted rossa at ~1250 PDT and confirmed that resolv.conf didn't get overwritten. The resolv.conf file also now has the following useful lines at the head:

~>cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
Quote:

yes, I rebooted yesterday to fix the 'steaking white lines' problem in the video/display

maybe we're supposed to edit something besides resolv.conf since that gets over-written on boot for some linux OS

  13044   Mon Jun 5 21:53:55 2017 ranaUpdateComputersrossa: ubuntu 16.04

With the network config, mounting, and symlinks setup, rossa is able to be used as a workstation for dataviewer and MEDM. For DTT, no luck since there is so far no lscsoft support past the Ubuntu14 stage.

  6205   Tue Jan 17 03:10:27 2012 kiwamuConfigurationIOOrotated lambda/2 plate

I have slightly rotated the lambda/2 plate, which is used for attenuating the REFL beam's power on the AS table

because the plate had been at an unusual angle for investigation of the glitches since last Thursday.

It means the laser power going to the coating thermal noise setup has also changed. Just keep it in mind.

Quote from #6198

So today we set up the Jenny RC temperature setup to lock the LWE NPRO to the RC and then set up the beat note with the IFO REFL beam on the AS table. By using the 2 laser beat, we are avoiding the VCO phase noise issue which used to limit the PSL frequency noise at ~0.01 Hz/rHz. To do this we have reworked some of the optics on the PSL and AS tables, but I think its been done without disturbing the beams for the regular locking. Beat note has been found, but the NPRO has still not been locked to the RC - next we setup the lockin amp, dither the PZT, and then use the New Focus lock box to lock it to the RC.

  7990   Mon Feb 4 10:45:51 2013 JamieSummaryGeneralrough analysis of aligned PRM-PR2 mode scan

Here's a sort of rough analysis of the aligned PRM-PR2 cavity mode scan.

On Friday we took some mode scan measurements of the PRM-PR2 cavity by pushing PRM (C1:SUS-PRM_LSC_EXT) with a 0.01 Hz, 300 count sine wave.  We looked at the transmitted power on the POP DC PD and the error signal on REFL11_I.

Below is a detail of the scan, chosen because the actuation was in its linear region and there were three relatively ok looking transmission peaks with nice PDH response curves:

scan-labeled.pdf

The vertical green lines on the bottom plot indicate the rough averaged separation of the 11 MHz side-band resonances from the carrier, at +- 0.0275 s.  If we take this for our calibration, we get roughly 400 MHz / second.

The three peaks in top plot have an average FWHM of 0.00381 s.  Given the calibration above, the average FWHM = ~1.52 MHz.

If we assume a cavity length of 1.91 m, FSR = 78.5 MHz.

Putting this together we get a finesse = ~51.6.

Analysis of misaligned mode scans to follow.

  7991   Mon Feb 4 11:10:59 2013 KojiSummaryGeneralrough analysis of aligned PRM-PR2 mode scan

The expected finesse is 100ish. How much can we beleive the measured number of 50?
From the number we need to assume PR2 has ~93% reflectivity.
This does not agree with my feeling that the cavity is overcoupled.
Another way is to reduce the reflectivity of the PRM but that is also unlikely from the data sheet.

The scan passed the peak in 4ms according to the fitting.
How do the analog and digital antialiasing filters affect this number?

  7994   Mon Feb 4 19:33:19 2013 yutaSummaryGeneralrough analysis of aligned PRM-PR2 mode scan

[Jenne, Yuta]

We redid PRM-PR2 cavity scan because last one (elog #7990) was taken with the sampling frequency of 2 KHz. We have also done TMS measurement.

Method:
 1. Align input TTs and PRM to align PRM-PR2 cavity.
 2. Sweep cavity length using C1:SUS-PRM_LSC_EXC.
 3. Get data using Jamie's getdata and fitted peaks using /users/jrollins/modescan/prc-pr2_aligned/run.py
 4. Calculated cavity parameters

Results:
 Below is the figure containing peaks used to do the calculation.

3peakdata.png

 From 11 MHz sidebands, calibration factor is 462 +/- 22 MHz/sec (supposing linear scan around peaks)
 FWHM is 1.45 +/- 0.03 MHz.
 TMS is 2.64 +/- 0.05 MHz.
 Error bars are statistical errors of the average over 3 TEM00 peaks.

 If we believe cavity length L to be 1.91 m, FSR is 78.5 MHz.
 So, Finesse will be 54 +/- 1 and cavity g-factor will be 0.9944 +/- 0.0002. 0.9889 +/- 0.0004   (Edited by YM; see elog #8056)
 If we believe RoC of PRM is exactly +122.1 m, measured g-factor insists RoC of PR2 to be -187 +/- 4.
 If we believe RoC of PR2 is exactly -600 m, measured g-factor insists RoC of PRM to be 218 +/- 6.

Discussion:
 1. Finesse is too small (expected to be ~100). This time, data was taken 16 KHz. Cut-off frequency of the digital antialiasing filter is ~ 5 kHz (see /opt/rtcds/rtscore/release/src/fe/controller.c). FWHM is about 0.003 sec, so it should not effect much according to my simulation.

 2. I don't know why FWHM measurement from the last one is similar to this one. The last one was taken 2 KHz, this means anti-aliasing filter of 600 Hz. This should double FWHM.

 3. Oscilloscope measurement may clear anti-aliasing suspicion.

  7997   Tue Feb 5 02:04:44 2013 yutaSummaryGeneralrough analysis of aligned PRM-PR2 mode scan

I redid PRM-PR2 cavity scan using oscilloscope to avoid anti-aliasing effect.
Measured Finesse was 104 +/- 1.

Method:
 1. Splitted POP DC output into three and plugged two into oscilloscope TDS 3034B. Ch1 and Ch2 was set to 1 V/div and 20 mV/div respectively to take the whole signal and higer resolution one at the same time (Koji's suggestion). Sampling frequency was 50 kHz. Sweeping time through FWHM was about 0.001 sec, which is slow enough.
 2. Took mode scan data from the oscilloscope via network.

Preliminary results:
 Below is the plot of the data for one TEM00 peak.
PRMPR2scan.png

 The data was taken twice.
 Measured FWHM was 0.764 MHz and 0.751 MHz. By taking the average, FWHM = 0.757 +/- 0.005 MHz.
 This gives you Finesse = 104 +/- 1, which is OK compared with the expectation.

What I need:
 I need better oscilloscope so that we can take longer data (~1 sec) with higher resolution (~0.004 V/count, ~50kHz).
 TDS 3034B can take data only for 10 ksamples, one channel by one!  I prefer Yokogawa DL750 or later.

  7998   Tue Feb 5 03:16:51 2013 KojiSummaryGeneralrough analysis of aligned PRM-PR2 mode scan

0.764 and 0.751 do not give us the stdev of 0.005.

I have never seen any Yokogawa in vicinity.

Quote:

 Measured FWHM was 0.764 MHz and 0.751 MHz. By taking the average, FWHM = 0.757 +/- 0.005 MHz.
 This gives you Finesse = 104 +/- 1, which is OK compared with the expectation.

What I need
 I need better oscilloscope so that we can take longer data (~1 sec) with higher resolution (~0.004 V/count, ~50kHz).
 TDS 3034B can take data only for 10 ksamples, one channel by one!  I prefer Yokogawa DL750 or later.

 

  8000   Tue Feb 5 10:09:08 2013 yutaSummaryGeneralrough analysis of aligned PRM-PR2 mode scan

stdev of [0.764, 0.751] is 0.007, but what we need is the error of the averaged number. Statistical error of the averaged number is stdev/sqrt(n).

Quote:

0.764 and 0.751 do not give us the stdev of 0.005.

  8002   Tue Feb 5 11:30:19 2013 KojiSummaryGeneralrough analysis of aligned PRM-PR2 mode scan

Makes sense. I mixed up n and n-1

Probability function: X = (x1 + x2 + ... + xn)/n, where xi = xavg +/- dx

Xavg = xavg*n/n = xavg

dXavg^2 = n*dx^2/n^2
=> dXavg = dx/sqrt(n)

Xavg +/- dXavg = xavg +/- dx/sqrt(n)

  8074   Wed Feb 13 01:26:08 2013 yutaSummaryGeneralrough analysis of aligned PRM-PR2 mode scan

Koji was correct.

When you estimate the variance of the population, you have to use unbiased variance (not sample variance). So, the estimate to dx in the equations Koji wrote is

dx = sqrt(sum(xi-xavg)/(n-1))
   = stdev*sqrt(n/(n-1))


It is interesting because when n=2, statistical error of the averaged value will be the same as the standard deviation.

dXavg = dx/sqrt(n) = stdev/sqrt(n-1)

In most cases, I think you don't need 10 % precision for statistical error estimation (you should better do correlation analysis if you want to go further). You can simply use dx = stdev if n is sufficiently large (n > 6 from plot below).
unbiased.png



Quote:

Makes sense. I mixed up n and n-1

Probability function: X = (x1 + x2 + ... + xn)/n, where xi = xavg +/- dx

Xavg = xavg*n/n = xavg

dXavg^2 = n*dx^2/n^2
=> dXavg = dx/sqrt(n)

Xavg +/- dXavg = xavg +/- dx/sqrt(n)

 

  11857   Mon Dec 7 11:11:25 2015 yutaroSummaryLSCround trip loss of X arm

On the day before yesterday and in this morning, I measured loss map of ETMX. I reported the method I used to change the beam spot on ETMX below.

Round trip loss was measured for 5 x 5 points. The result is below.

(unit: ppm)

455.4 +/- 21.1       437.1 +/- 21.8       482.3 +/- 21.8       461.6 +/- 22.5       507.9 +/- 20.1      
448.4 +/- 20.7       457.3 +/- 21.2       495.6 +/- 20.2       483.1 +/- 20.8       472.2 +/- 19.8      
436.9 +/- 19.3       444.6 +/- 19.7       483.0 +/- 19.5       474.9 +/- 20.9       498.3 +/- 18.7      
454.4 +/- 18.7       474.4 +/- 20.6       487.7 +/- 21.4       482.6 +/- 20.7       487.0 +/- 19.9      
443.7 +/- 18.6       469.9 +/- 20.2       482.8 +/- 18.7       480.9 +/- 19.5       486.1 +/- 19.2 

The correspondence between the loss shown above and the beam spot on ETMX is shown in the attached figure. In the figure, "up" and "right" indicate direction of shift of the beam spot when you watch it via the camera (ex. 455.4 ppm corresponds to the highest and rightest point in the view via the camera). 

This result is consistent withe previous result of 561.19 +/- 14.57 ppm ericq got with ASDC and reported in elog 10248 if the discussion I reported in 11819 is taken into account. Elog 11819 says in short that the strange behavior of ASDC could give us 60-70 ppm error.

The reason why the error is larger than that of the measurement for ETMY is that the noise of POX is larger than that of POY. But I am not sure to what extent the statistical error needs to be reduced.

How I shifted the beam spot on ETMX:   

Basically, the method was same as one used for Y arm. Different point is: for Y arm we have two steering mirrors TT1&2, but for X arm we have only one steering mirror BS. Then in order to shift incident beam so that the beam spot on ITMX does not change, I ran the dithering of X arm as well as that of Y arm and added offsets to both dither loops that caused same amount of shift on ETMX and ETMX. Thanks to the symmetry between X arm and Y arm, the dithering of Y arm ensured that the beam spot on ITMX was unchanged as well as that of ITMY. The idea of this method is schematically shown in Attachment 2. 

The calibration of how much the beam spot shifted is based on the results of elog 11846 . The offset was [-15,-7.5,0,7.5,15]x[-5,-2.5,0,2.5,5] for pitch and yaw, respectively.  

 

Attachment 1: image1-2.JPG
image1-2.JPG
Attachment 2: symmetry.png
symmetry.png
  11810   Wed Nov 25 16:40:32 2015 yutaroUpdateLSCround trip loss of Y arm

I measured round trip loss of Y arm. The alignment of relevant mirrors was set ideal with dithering (no offset).

Summary:

 round trip loss of Y arm: 166.2 +/- 9.3 ppm

(In the error, only statistic error is included.)

How I measured it: 

I compared the power of light reflected by Y arm (measured at AS) when the arm was locked (P_L) and when ETMY was misaligned (P_M). P_L and P_M can be described as 

P_M=P_0(1-T_\mathrm{ITM})

P_L=P_0\left[1-(1-\alpha)\frac{4T_\mathrm{ITM}}{T_\mathrm{tot}^2}T_\mathrm{loss}\right].

The reason why P_L takes this form is: (1-alpha)*4T_ITM/(T_tot)^2 is intracavity power and then product of intracavity power and loss describes the power of light that is not reflected back. Here, alpha is power ratio of light that does not resonate in the arm (power of mismatched mode and modulated sideband), and T_tot is T_ITM+T_loss. Transmissivity of ETM is included in T_loss. I assumed alpha = 7%(mode mismatch) + 2 % (modulation) (elog 11745)

After some calculation we get

1-P_L/P_M\simeq \frac{4(1-\alpha) T_\mathrm{loss}}{T_\mathrm{ITM}}-T_\mathrm{ITM}.

Here, higher order terms of T_ITM and (T_loss/T_ITM) are ignored. Then we get

(1-\alpha) T_\mathrm{loss}=\frac{T_\mathrm{ITM}}{4}(1-P_L/P_M+T_\mathrm{ITM}).

Using this formula, I calculated T_loss. P_L and P_M were measured 100 times (each measurement consisted of 1.5 sec ave.) each and I took average of them. T_ETM =13.7 ppm is used.

Discussion: 

-- This value is not so different from the value ericq reported in July (elog 10248).

-- This method of measuring arm loss is NOT sensitive to T_ITM.  In contrast, the method in which loss is obtained from finesse (for example, elog 11740) is sensitive to T_ITM.

In the method I'm now reporting, 

\Delta T_\mathrm{loss}/T_\mathrm{loss}\simeq\Delta T_\mathrm{ITM}/T_\mathrm{ITM},

but in the method with finesse,

\Delta T_\mathrm{loss}\simeq\Delta T_\mathrm{ITM}.

In the latter case, if relative error of T_ITM is 10%, error of T_loss would be 1000 ppm.

So it would be better to use power of reflected light when you want to measure arm loss.  

  11816   Wed Nov 25 23:34:52 2015 yutaroUpdateLSCround trip loss of Y arm

[yutaro, Koji]

Due to the strange behavior (elog 11815) of ASDC level, we checked if it is possible to use POYDC instead of ASDC to measure the power of reflected light of YARM. Attached below is the spectrum of them when the arm is locked. This spectrum shows that it is not bad to use POYDC, in terms of noise. The spectrum of them when ETMY is misaligned looked similar.

So I am going to use POYDC instead of ASDC to measure arm loss of YARM. 


Ed by KA:
The spectra of POYDC and ASDC were measured. We foudn that they have coherence at around 1Hz (good).
It told us that POYDC is about 1/50 smaller than ASDC. Therefore in the attached plot, POYDC x50 is shown.
That's the meaning of the vertical axis unit "ASDC".

Attachment 1: 14.png
14.png
ELOG V3.1.3-