40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 60 of 344  Not logged in ELOG logo
ID Date Author Type Category Subjectdown
  7373   Wed Sep 12 08:16:49 2012 SteveConfigurationPEMchamber must be sealed overnight!

Quote:

We conducted a beam scan on the AP table of the AS beam. We used a lens to focus the beam onto a power meter, and slowly moved a razor blade across the beam using a micrometer, vertically and horizontally both in front of and behind the beam. We also had to block the beam next to the AS beam in order to do this, but is unblocked now. Mike will begin curve fitting the data to try and see if there is a different spot size given by the x-axis vs. the y-axis, and if the lens has any effect.

 The vacuum envelope must be sealed with light doors on o-rings to insure a bug free IFO.  This was a violation!

  7327   Fri Aug 31 10:24:36 2012 SteveUpdateVACchamber dog clamps checked

Quote:

I tightened as many of the dog clamps on the bottom of the BS, ITMX and ITMY chambers as I could find.  I used a torque wrench at 45 ft-lbs.  Some of the bolts of the dogs were too long, and I couldn't find an extender thing to accommodate the bolt so I could reach the nut.  None of the bolts moved that I was able to reach.

Steve, we're not doing final final alignment today (we will do it tomorrow), so please go around and double-check my work by checking all of the dogs first thing in the morning.  Thanks.

 Almost all chamber dog clamps on the floor checked. There are a few exception where it is impossible to to get to the nut. 

Only the OOC nuts turned little bit. So our elastomer discs are holding up well. This means that the chamber anchoring to the floor is good.

  5243   Mon Aug 15 21:43:29 2011 Anamaria and KeikoSummaryLockingcentral part ifo locking project

 REFL33 and REFL165 cables were connected from the AP table to the rack.  Cables on the rack for REFL33I, 33Q, 165I, 165Q ports were connected, too. Connections were confirmed by the data viewer. Two SMA cables which will be used for the two PDs on the AP tabl were built. We will be able to place the two PDs tomorrow. The beamsplitters to split the laser to REFL33 and REFL165 ports were mounted and ready to be placed.

  5233   Sun Aug 14 20:04:40 2011 Keiko, Anamaria, Jenne, and KiwamuSummaryLockingcentral part ifo locking plan
GOAL : To lock the central part of ifo

Here is the plan:

Mon - assemble all the cables from PDs and mixers, and check the CDS channels. Prepare the beamsplitters.

Tue - The current paths to REFL11 and REFL55 will be modified to the four paths to REFL11, 33, 55, 165. And the PDs will be placed.
Wed, Thu - during waiting for the ifo available with vacuum, help aligning the POP, POX, POY. In parallel, a simulation to find the PRC length SRC 
length tolerance will be proceeded.

Fri - When the ifo becomes available with vacuum, the sensing signals by 3-f scheme will be obtained with proper demodulation phases.

Sat - Try to lock the central part of the ifo with the new 3-f signals.
  9347   Tue Nov 5 17:12:34 2013 SteveUpdateLSCcentered qpds

 Full list tomorrow: IP-Ang & Pos, ETMY-T, ETMY-Oplev, ETMX-T, IOO-Ang & Pos

 RA: No one in the control room this evening can understand what this ELOG means. Please use more words.

  6700   Tue May 29 10:08:21 2012 steveUpdateIOOcentered IOO monitoring qpds

IOO Angle & IOO Position QPDs centered.

  10461   Fri Sep 5 16:25:36 2014 SteveUpdateSUScenter ITMY oplev

Quote:

The SRM qpd was moved to accommodate the HeNe laser qualification test for LIGO Oplev use.

The qpd was saturating at 65,000 counts of 3 mW

ND1 filter lowering the power by 10 got rid of saturation. I epoxied an adapter ring to the qpd.

Atm3 was taken before saturation was realized with Koji's help.

Atm4 ND1 on SRM qpd. Now it is working and everything is moving.

 

 ITMY oplev should be centered. I worked too much around it.

  3700   Tue Oct 12 22:06:08 2010 yutaUpdateComputerscelan-installed CentOS 5.5 on mafalda

I clean-installed CentOS 5.5(32bit) on mafalda.
No firewalls, no SELinix.

  3701   Tue Oct 12 23:35:12 2010 mafaldaUpdateComputerscelan-installed CentOS 5.5 on mafalda

Quote:

I clean-installed CentOS 5.5(32bit) on mafalda.
No firewalls, no SELinix.

 Yuta has removed my ethernet connection. Help me!!!

rossa:mDV>ping mafalda
PING mafalda.martian (192.168.113.23) 56(84) bytes of data.
From rossa.martian (192.168.113.215) icmp_seq=2 Destination Host Unreachable
From rossa.martian (192.168.113.215) icmp_seq=3 Destination Host Unreachable
From rossa.martian (192.168.113.215) icmp_seq=4 Destination Host Unreachable

--- mafalda.martian ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3999ms
, pipe 3

  10188   Fri Jul 11 22:02:52 2014 Jamie, ChrisOmnistructureCDScdsutils: multifarious upgrades

To make the latest cdsutils available in the control room, we've done the following:

Upgrade pianosa to Ubuntu 12 (cdsutils depends on python2.7, not found in the previous release)

  • Enable distribution upgrades in the Ubuntu Software Center prefs
  • Check for updates in the Update Manager and click the big "Upgrade" button

Note that rossa remains on Ubuntu 10 for now.

Upgrade cdsutils to r260

  • Instructions here
  • cdsutils-238 was left as the default pointed to by the cdsutils symlink, for rossa's sake

Built and installed the nds2-client (a cdsutils dependency)

  • Checked out the source tree from svn into /ligo/svncommon/nds2
  • Built tags/nds2_client_0_10_5 (install instructions are here; build dependencies were installed by apt-get on chiara)
  • ./configure --prefix=/ligo/apps/ubuntu12/nds2-client-0.10.5; make; make install
  • In /ligo/apps/ubuntu12: ln -s nds2-client-0.10.5 nds2-client

nds2-client was apparently installed locally as a deb in the past, but the version in lscsoft seems broken currently (unknown symbols?). We should revisit this.

Built and installed pyepics (a cdsutils dependency)

  • Download link to ~/src on chiara
  • python setup.py build; python setup.py install --prefix=/ligo/apps/ubuntu12/pyepics-3.2.3
  • In /ligo/apps/ubuntu12: ln -s pyepics-3.2.3 pyepics

pyepics was also installed as deb before; should revisit when Jamie gets back.

Added the gqrx ppa and installed gnuradio (dependency of the waterfall plotter)

Added a test in /ligo/apps/ligoapps-user-env.sh to load the new cdsutils only on Ubuntu 12.

The end result:

controls@chiara|~ > z
usage: cdsutils  

Advanced LIGO Control Room Utilites

Available commands:

  read         read EPICS channel value
  write        write EPICS channel value
  switch       switch buttons in standard LIGO filter module
  avg          average one or more NDS channels for a specified amount of seconds
  servo        servos channel with a simple integrator (pole at zero)
  trigservo    servos channel with a simple integrator (pole at zero)
  audio        Play channel as audio stream.
  dv           Plot time series of channels from NDS.
  water        Live waterfall plotter for LIGO data

  version      print version info and exit
  help         this help

Add '-h' after individual commands for command help.
 
 
  10339   Wed Aug 6 13:17:21 2014 ericqOmnistructureCDScdsutils: multifarious upgrades

I've checked out cdsutils-274 to /opt/rtcds/cdsutils, and updated the /ligo/apps/ligoapps-user-env.sh to have the newer machines use it by default. This was to gain access to the cdsutils.Step methods for use in the smooth ASS handoffs script. 

  9924   Wed May 7 22:47:33 2014 ranaUpdateCDScdsutils updated to version 226: not working on pianosa or rossa

 controls@rossa:~ 0$ cdsutils read C1:LSC-DARM_GAIN
Traceback (most recent call last):
  File "/usr/lib/python2.6/runpy.py", line 122, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.6/runpy.py", line 34, in _run_code
    exec code in run_globals
  File "/ligo/apps/cdsutils-226/lib/python2.6/site-packages/cdsutils/__main__.py", line 57, in <module>
    imp.load_module('__main__', f, pathname, description)
  File "/ligo/apps/cdsutils-226/lib/python2.6/site-packages/cdsutils/read.py", line 32, in <module>
    print ezca.Ezca(prefix).read(rest, as_string=args.as_string)
  File "/ligo/apps/linux-x86_64/cdsutils-226/lib/python2.6/site-packages/ezca/cached.py", line 17, in __call__
    key = (args, tuple(kwargs.viewitems()))
AttributeError: 'dict' object has no attribute 'viewitems'

  9922   Wed May 7 16:31:12 2014 jamieUpdateCDScdsutils updated to version 226
controls@pianosa:~ 0$ cd /opt/rtcds/cdsutils/trunk/
controls@pianosa:/opt/rtcds/cdsutils/trunk 0$ svn update
...
At revision 226.
controls@pianosa:/opt/rtcds/cdsutils/trunk 0$ make
echo "__version__ = '226'" >lib/cdsutils/_version.py
echo "__version__ = '226'" >lib/ezca/_version.py
...
controls@pianosa:/opt/rtcds/cdsutils/trunk 0$ make ligo-install
python ./setup.py install --prefix=/ligo/apps/linux-x86_64/cdsutils-226
...
controls@pianosa:/opt/rtcds/cdsutils/trunk 0$ ln -sfn cdsutils-226 /ligo/apps/linux-x86_64/cdsutils
controls@pianosa:/opt/rtcds/cdsutils/trunk 0$ exit
...
controls@pianosa:~ 0$ cdsutils --version
cdsutils 226
controls@pianosa:~ 0$ 

  9923   Wed May 7 17:10:59 2014 ranaUpdateCDScdsutils updated to version 226

 This upgrade from Jamie has given us the new apps (avg, servo, and trigservo). We should figure out if there's a way to integrate Masayuki's work, so that we can have a 'cdsutils demod' function too.

  9926   Wed May 7 23:30:21 2014 jamieUpdateCDScdsutils should be working now

Should be fixed now.  There were python2.6 compatibility issues, which only show up on these old distros (e.g. ubuntu 10.04).

controls@pianosa:~ 0$ cdsutils read C1:LSC-DARM_GAIN
0.0
controls@pianosa:~ 0$ cdsutils --version
cdsutils 230
controls@pianosa:~ 0$ 
  10057   Wed Jun 18 13:39:01 2014 ranaUpdateCDScdsutils reverted to version 238

 

 After some email consult with Jamie, I got cdsutils working again by reverting to v238. The newest versions are not compatible with our python 2.6 on Ubuntu 10. And our Ubuntu 12 machines do not have NDS2 clients that work yet.

The read/write commands work at the moment, but the NDS based ones don't yet work on pianosa due to some NDSSERVER flag/setup issue maybe, Jamie ??

controls@pianosa|~ > z

usage: cdsutils <cmd> <args>

Advanced LIGO Control Room Utilites

Available commands:

    read         read EPICS channel value

  write        write EPICS channel value

  switch       switch buttons in standard LIGO filter module

  avg          average one or more NDS channels for a specified amount of seconds

  servo        servos channel with a simple integrator (pole at zero)

  trigservo    servos channel with a simple integrator (pole at zero)


  version      print version info and exit

  help         this help


Add '-h' after individual commands for command help.

controls@pianosa|~ > z read C1:LSC-DARM_GAIN

0.0

controls@pianosa|~ 2> z avg 3 C1:IOO-MC_F

Error in write(): Connection refused

Error in write(): Connection refused

NDSSERVER variable incorrectly defined, or no NDS servers available.

controls@pianosa|~ 1> echo $NDSSERVER

fb

  10040   Sun Jun 15 14:26:30 2014 JamieOmnistructureCDScdsutils re-installed

Quote:

 CDSUTILS is also gone from the path on all the workstations, so we need Jamie to tell us by ELOG how to set it up, or else we have to use ezcaread / ezcawrite forever.

It's in the elog already: http://nodus.ligo.caltech.edu:8080/40m/9922

But it seems like things still haven't fully recovered, or have recovered to an old state?  Why is the cdsutils install I previously did in /ligo/apps now missing?  It seems like other directories are missing as well.

There's also a user:group issue with the /home/cds mounts.  Everything in those mount points is owned nobody:nogroup.

I also can't log into pianosa and rosalba.

  10041   Sun Jun 15 14:41:08 2014 JamieOmnistructureCDScdsutils re-installed

Quote:

Quote:

 CDSUTILS is also gone from the path on all the workstations, so we need Jamie to tell us by ELOG how to set it up, or else we have to use ezcaread / ezcawrite forever.

It's in the elog already: http://nodus.ligo.caltech.edu:8080/40m/9922

But it seems like things still haven't fully recovered, or have recovered to an old state?  Why is the cdsutils install I previously did in /ligo/apps now missing?  It seems like other directories are missing as well.

There's also a user:group issue with the /home/cds mounts.  Everything in those mount points is owned nobody:nogroup.

I also can't log into pianosa and rosalba.

 I also still think it's a bad idea for everything to be mounting /home/cds from an IP address.  Just make a new DNS entry for linux1 and leave everything as it was.

  9075   Tue Aug 27 19:50:06 2013 JamieConfigurationComputer Scripts / Programscdsutils checked out into /opt/rtcds

I have checked out the new cdsutils repository at:

/opt/rtcds/cdsutils/release

This is a new repository that is intended to hold all of our python libraries and command-line utilities for interacting with the IFO, things like:

  • get/write values EPICS channels
  • interact with filter module switches
  • average a test point for some amount of time
  • etc.

Basically everything that used to be ez* or tds*.

There's not much in there at the moment, but hopefully it will start to get filled in soon.

WARNING:

This code in here will be used by the sites to interact with the real aLIGO IFOs.  Please be careful as you develop things in here, and o so conscientiously.  If you do bad things here and it messes things up at the sites people will be angry.  Particularly me, since I have to support everything in here for Guardian use.

Usage

<cdsutils>/lib/cdsutils is the primary python library.  For each function you want to add, put it in a new file named after the function.  So for instance function "foo" should be in a file called <cdsutils>/lib/cdsutils/foo.py.

There is a command line utility at <cdsutils>/bin/cdsutils.  It will automatically find anything you add to the library and expose it as a sub command (e.g. "cdsutils foo")

We'll try to put together a wiki page describing development and usage of this soon.

  9132   Mon Sep 16 15:29:50 2013 JamieConfigurationComputer Scripts / Programscdsutils checked out into /opt/rtcds

We now have a proper install of cdsutils:

 controls@rossa:~ 0$ cdsutils
 usage: cdsutils <cmd> <args>

 Advanced LIGO Control Room Utilites

 Available commands:

   read         read EPICS channel value
   write        write EPICS channel value
   switch       switch buttons in standard LIGO filter module
   avg          average NDS channels for some amount of time
   servo        simple integrator (pole at zero)

 Add '-h' after individual commands for command help.
 controls@rossa:~ 0$ 

It is installed in /ligo/apps/cdsutils, and should be in the path on all workstations.

The "development" source working directory is currently checked out at /opt/rtcds/cdsutils/trunk.

 

  9133   Mon Sep 16 19:41:01 2013 ranaConfigurationComputer Scripts / Programscdsutils checked out into /opt/rtcds
 controls@rosalba:~ 0$ cdsutils
Traceback (most recent call last):
  File "/ligo/apps/cdsutils/lib/cdsutils/__main__.py", line 7, in <module>
    from cdsutils import CMDS
  File "/ligo/apps/cdsutils/lib/cdsutils/__init__.py", line 4, in <module>
    from servo import servo
  File "/ligo/apps/cdsutils/lib/cdsutils/servo.py", line 1, in <module>
    from epics import PV
ImportError: No module named epics
controls@rosalba:~ 1$
Mon Sep 16 19:40:32 2013 
  11130   Tue Mar 10 20:08:23 2015 ericqUpdateCDScdsRampMuxMatrix Backported to 40m RCG

I have successfully backported the cdsRampMuxMatrix part for use in our RCG v2.5 system. This involved grabbing new files, merging changes, and hacking around missing features from RCG 2.9. 

The added/changed files, with relative paths referred to /opt/rtcds/rtscore/release/src/, are:

  • M include/drv/tRamp.c
    • New C functions to directly report current ramping value and ramping state 
  • M epics/util/feCodeGen.pl
    • Added if statements to main simulink parser to properly handle the part
  • AM epics/util/lib/RampMuxMatrix.pm
    • New Perl script that writes the frontend code for a given ramp matrix
  • A epics/util/mkrampmatrix.pl
    • New perl script that creates the default MEDM screen
  • A epics/simLink/lib/cdsRampMuxMatrix.mdl
    • Simulink block for the part
  • M epics/simLink/CDS_PARTS.mdl
    • Added block and doc for the part (which is missing an underscore in its definition of EPICS field names)

[A means the file was added, M means the file was modified]

Most of the trouble came from the EPICS reporting of the live ramping value and ramping state, since this depended on some future RCG value masking function. I had to rewrite the C-code writing perl script to define and update these EPICS variables in a more old-school way. 

This leaves us vunerable to the fact that a user/program can directly write to the live matrix element and ramping state, which would cause bad and unexpected behavior of the matrix.

So, when using a ramping matrix: NEVER WRITE to [MAT]_[N]_[N] as you would for a normal matrix. Use [MAT]_SETTING_[N]_[M] and trigger [MAT]_LOAD_MATRIX.

Similary, [MAT]_RAMPING_[N]_[N] is off limits. 

I tested the new part in the c1tst model. There are two EPICS input (TST-RAMP1_IN and TST-RAMP2_IN) that are the inputs to a 2x2 ramp matrix called TST-RAMP, and the outputs go to two testpoints (TST-RAMP1_OUT and TST-RAMP2_OUT) and two epics outputs (TST-RAMP1_OUTMON and TST-RAMP2_OUTMON). You can write something to the inputs from ezca or whatever, and use the C1TST_RAMP.adl medm screen in the c1tst directory to try it out. The buttons turn red when you've input a new matrix, yellow when a ramp is ongoing and green when the live value agrees with the setting. 

At this time, I have not rebuilt any of our operational models in search of potential issues.

I have created backups of the files I modified, such that a file such as feCodeGen.pl was renamed feCodeGen.40m.pl, and left next to the modified file. I am open to more robust ways of doing the backup; since our RCG source is an svn checkout of the v2.5 branch (with local modifications, to boot), I suppose we don't want to commit there. Maybe we make a 40m branch? A seperate repo? 

  15905   Thu Mar 11 18:46:06 2021 gautamUpdateCDScds reboot

Since Koji was in the lab I decided to bite the bullet and do the reboot. I've modified the reboot script - now, it prompts the user to confirm that the time recognized by the FEs are the same (use the IOP model's status screen, the GPSTIME is updated live on the upper right hand corner). So you would do sudo date --set="Thu 11 Mar 2021 06:48:30 PM UTC" for example, and then restart the IOP model. Why is this necessary? Who knows. It seems to be a deterministic way of getting things back up and running for now so we have to live with it. I will note that this was not a problem between 2017 and 2020 Oct, in which time I've run the reboot script >10 times without needing to take this step. But things change (for an as of yet unknown reason) and we must adapt. Once the IOPs all report a green "DC" status light on the CDS overview screen, you can let the script take you the rest of the way again.

The main point of this work was to relax the data rate on the c1lsc model, and this worked. It now registers ~3.2 MB/s, down from the ~3.8 MB/s earlier today. I can now measure 2 loop TFs simultaneously. This means that we should avoid adding any more DQ channels to the c1lsc model (without some adjustment/downsampling of others).

Quote:

 Holding off on a restart until I decide I have the energy to recover the CDS system from the inevitable crash.

  15910   Fri Mar 12 03:28:51 2021 KojiUpdateCDScds reboot

I want to emphasize the followings:

  • FB's RTC (real-time clock/motherboard clock) is synchronized to NTP time.
  • The other RT machines are not synchronized to NTP time.
  • My speculation is that the RT machine timestamp is produced from the local RT machine time because there is no IRIG-B signal provided. -> If the RTC is more than 1 sec off from the FB time, the timestamp inconsistency occurs. Then it induces "DC" error.
  • For now, we have to use "date" command to match the local RTC time to the FB's time.
     
  • So: If NTP synchronization is properly implemented for the RT machines, we will be free from this silly manual time adjustment.

 

  15911   Fri Mar 12 11:02:38 2021 gautamUpdateCDScds reboot

I looked into this a bit today morning. I forgot exactly what time we restarted the machines, but looking at the timesyncd logs, it appears that the NTP synchronization is in fact working (log below is for c1sus, similar on other FEs):

-- Logs begin at Fri 2021-03-12 02:01:34 UTC, end at Fri 2021-03-12 19:01:55 UTC. --
Mar 12 02:01:36 c1sus systemd[1]: Starting Network Time Synchronization...
Mar 12 02:01:37 c1sus systemd-timesyncd[243]: Using NTP server 192.168.113.201:123 (ntpserver).
Mar 12 02:01:37 c1sus systemd[1]: Started Network Time Synchronization.
Mar 12 02:02:09 c1sus systemd-timesyncd[243]: Using NTP server 192.168.113.201:123 (ntpserver).

So, the service is doing what it is supposed to (using the FB, 192.168.113.201, as the ntpserver). You can see that the timesync was done a couple of seconds after the machine booted up (validated against "uptime"). Then, the service is periodically correcting drifts. idk what it means that the time wasn't in sync when we check the time using timedatectl or similar. Anyway, like I said, I have successfully rebooted all the FEs without having to do this weird time adjustment >10 times

I guess what I am saying is, I don't know what action is necessary for "implementing NTP synchronization properly", since the diagnostic logfile seems to indicate that it is doing what it is supposed to.

More worryingly, the time has already drifted in < 24 hours.

Quote:

I want to emphasize the followings:

  • FB's RTC (real-time clock/motherboard clock) is synchronized to NTP time.
  • The other RT machines are not synchronized to NTP time.
  • My speculation is that the RT machine timestamp is produced from the local RT machine time because there is no IRIG-B signal provided. -> If the RTC is more than 1 sec off from the FB time, the timestamp inconsistency occurs. Then it induces "DC" error.
  • For now, we have to use "date" command to match the local RTC time to the FB's time.
     
  • So: If NTP synchronization is properly implemented for the RT machines, we will be free from this silly manual time adjustment.
  9321   Thu Oct 31 00:06:45 2013 masayukiUpdateComputer Scripts / Programscds fft,tf,offsets

I wrote the scripts for cdsutils.

1. fft

usage: fft.py [-h] [-c N_CYCL] [-a N_AVG] freq channel [channel ...]

Measures the frequency content of one or more NDS channels
at the specified frequecy.
    The measurement results are  magnitude, phase, real part imaginary part, and the standard deviation of the real and imaginary parts.

positional arguments:
  freq        measurement frequency
  channel     list of measurement channel

optional arguments:
  -h, --help  show this help message and exit
  -c N_CYCL   define number of cycles. Default is 10
  -a N_AVG    define number of average. Default is 100

2. tf

usage: tf.py [-h] [-c N_CYCL] [-a N_AVG] [--dB] freq input output

Measures the transfer funtion of one NDS channels pair  at the specified frequecy.
    The measurement results are the coherence, magnitude, phase, real part, imaginary part, and the standard deviation of the real and imaginary parts.

positional arguments:
  freq        measurement frequency
  input       list of measurement input channel
  output      list of measurement output channel

optional arguments:
  -h, --help  show this help message and exit
  -c N_CYCL   define number of cycles. Default is 10
  -a N_AVG    define number of average. Default is 100
  --dB        print the amplitude in dB

 

3.offsets

usage: offset.py [-h] [-t SECONDS] filterbank [filterbank ...]

Zero the offset of one or more filterbank. Take average of OUT16 channel, and put (-1 * average / gain) into offset.  After change offsets, it will turn on the offset.
    example usage) offset -d 25 C1:LSC-AS55_Q C1:LSC-AS55_I

positional arguments:
  filterbank  list of filterbank to zero offset

optional arguments:
  -h, --help  show this help message and exit
  -t SECONDS  define the averaging time. default value is 10

I put these scripts in /opt/rtcds/cdsutils/trunk/lib/cdsutils.
I couldn't put them into cds library, but I will left tomorrow to Japan...

So please help me Jamie or Joe !!

 

 

By the way,

I modified the LSCoffset script  (script)/LSC/LSCoffsets.py.

usage: LSCoffsets.py [-h] [-d SECONDS] [--PDlist]

 Zero the offsets of LSC PDs. During taking average, we will close the PSL and green shutter. After zeroing, it will turn on the offsets switch.
    example usgae) LSCoffset2.py -d 20    

optional arguments:
  -h, --help  show this help message and exit
  -d SECONDS  define the averaging time. default value is 10
  --PDlist    print PD list for LSC and exit

i made new directory 'offset_backup' for old offset script. I move all old offset script into there.

But unfortunately that cannot use right now, because cds offsets script is not available yet...

  6562   Tue Apr 24 14:55:00 2012 JamieUpdateCDScds code paths (rtscore, userapps) have moved

NOTE: Unless you really care about what's going on under the hood, please ignore this entire post and go here: USE THE NEW RTCDS UTILITY

Quote:

  • the userapps directory is in a new place (/opt/rtcds/userapps).  Not everything in the old location was checked into the repository, so we need to check to make sure everything that needs to be is checked in, and that all the models are running the right code.

 An important new aspect of this upgrade is that we have some new directories and some of the code paths have moved to correspond with the "standard" LIGO CDS filesystem hierarchy:

  • rtscore:      /opt/rtcds/rtscore/release       -->  RTS RCG source code (svn: adcLigoRTS)
  • userapps: /opt/rtcds/userapps/release  -->  CDS userapps source for models, RCG C code, medm screens, scripts, etc (svn: cds_user_apps)
  • rtbuild:       /opt/rtcds/caltech/c1/rtbuild    -->  RCG build directory

All work should be done in the "userapps" directory, and all builds should be done in the build directory.  Some important points:

WARNING: DO NOT MODIFY ANYTHING IN RTSCORE

This is important.  The rtscore directory is now just where the RCG source code is stored.  WE NO LONGER BUILD MODELS IN THE RTS SOURCE  Please use the rtbuild directory instead.

NO MORE MODEL/CODE SYMLINKS

You don't need to link you model or code anywhere to get it to compile.  The RCG now uses proper search paths to source in the RCG_LIB_PATH to find the needed source.  This has been configured by the admin, so as long as you put your code in the right place it should be found.

ALL CODE/MODELS/ETC GO IN USERAPPS

All RTS code is now stored ENTIRELY in the userapps directory (e.g. /opt/rtcds/userapps/release/isc/c1/models/c1lsc.mdl).  This is more-or-less the same as before, except that symlinking is no longer necessary.  I have placed a symlink at the old location for convenience.

BUILD ALL MODELS IN RTSCORE

You can run "make c1lsc" in the rtbuild directory, just as you used to in the old core directory.  However, don't do that.  USE THE NEW RTCDS UTILITY instead.

  7051   Mon Jul 30 15:49:16 2012 steveUpdateVACcc1 switched

Quote:

Our cold cathode 423 gauges are 10 years old. They get insulated by age and show no ionization current.  We should replace them at the next vent. I'm buying 4 at $317ea

 

 We have two CC1 gauges at the pump spool. One is in vertical position and the spare is in horizontal. Today I switched the cable from vertical to horizontal CC1

This one is reading higher pressure. It is an old dirty gauge. It may trigger the RGA protection when it's reading goes above 1e-5 torr

The real pressure is 2e-6 torr

  7056   Tue Jul 31 08:01:22 2012 steveUpdateVACcc1 switched

Quote:

Quote:

Our cold cathode 423 gauges are 10 years old. They get insulated by age and show no ionization current.  We should replace them at the next vent. I'm buying 4 at $317ea

 

 We have two CC1 gauges at the pump spool. One is in vertical position and the spare is in horizontal. Today I switched the cable from vertical to horizontal CC1

This one is reading higher pressure. It is an old dirty gauge. It may trigger the RGA protection when it's reading goes above 1e-5 torr

The real pressure is 2e-6 torr

 cc1h spikes closed VM1 last night. VM1 is opened.

  7363   Fri Sep 7 15:58:29 2012 Rijuparna ChakrabortyUpdate cavitymode scan

 IMC transmission photodiode has been aligned.

  7366   Fri Sep 7 17:37:16 2012 JenneUpdate cavitymode scan

Quote:

 IMC transmission photodiode has been aligned.

 Which PD?  The 'regular' DC one, or the newer one?  Why did it need realigning?  What mirrors did you touch to do the alignment?

Did you do anything else in the last 3 days?  I want to see ALL the gory details, because it can help people doing future measurements, or help us debug if something is wrong with the interferometer later.

MORE WORDS! Thanks.

  7368   Sat Sep 8 00:15:57 2012 Rijuparna ChakrabortyUpdate cavitymode scan

Quote:

Quote:

 IMC transmission photodiode has been aligned.

 Which PD?  The 'regular' DC one, or the newer one?  Why did it need realigning?  What mirrors did you touch to do the alignment?

Did you do anything else in the last 3 days?  I want to see ALL the gory details, because it can help people doing future measurements, or help us debug if something is wrong with the interferometer later.

MORE WORDS! Thanks.

 No, not the "regular DC one", the "newer one"  along with the controls of the corresponding mirror only i touched.

It needed to be realigned cause last week when we fitted a longer cable there, which may reach the network analyzer, it got misaligned since it got touched.

No other component in that box except that PD and the corresponding mirror controls I touched.

For my last 2 days work, I feel my last elog is reliable.

Today other than doing this, I checked for the higher order modes of the cavity, misaligning one of the MC mirror though the software only. I didn't mention it in my elog cause although I saw the presence of the higher order modes I didn't record it, so I can not upload any picture in support of such a statement.

Thanks

  7376   Wed Sep 12 19:26:08 2012 Rijuparna ChakrabortyUpdate cavitymode scan

 Summary: Recorded the presence of higher order modes in IMC

What I did: Misaligned the flat mirror MC1 by small amount in both pitch and yaw (it was needed to be done cause at the beginning of the experiment no higher order modes were present)  and scanned the cavity for frequency-range 32MHz to 45MHz.

I found the presence of higher order modes around 36.7MHz (1st order)  and 40.6MHz (2nd order) along with two other strong modes near 35MHz and 42.5MHz.

 

  7486   Thu Oct 4 23:01:49 2012 RijuparnaConfiguration cavitymode scan

 Here I am attaching the schematic diagram of the experimental set-up for IMC cavitymode scanning. A 30- 45MHz scanning signal generated by Agilent 4395A network analyzer enters EOM, which in turn modulates the laser beam entering IMC. The cavity response can be verified from reflected/transmitted beam.

I worked with the reflected beam last days. But I got no clue about the percentage of  reflected light reaching the photodiode and also the photodiode response. I would like to measure the power reaching photodiode and also would like to perform the test with transmitted beam - on wednesday if possible.

 

  7519   Wed Oct 10 15:31:59 2012 RijuparnaUpdate cavitymode scan

 Rijuparna, Jenne

Today I checked the optical lay-out in MC REFL board of the MC REFL path on the AS table (I will put the updated diagram in a few hours), and took a record of the reflected power of unlocked MC and power entering MC REFL PD. The power coming out of MC cavity when unlocked is 1.25W and power entering REFL PD 112mW (Jenne measured these powers for me). 

I also got a description of the MC demodulation board from Jenne.

(Edits by Jenne)

  7520   Wed Oct 10 15:46:23 2012 JenneUpdate cavitymode scan

Quote:

 Rijuparna, Jenne

Today I checked the optical lay-out in MC REFL board of the MC REFL path on the AS table (I will put the updated diagram in a few hours), and took a record of the reflected power of unlocked MC and power entering MC REFL PD. The power coming out of MC cavity when unlocked is 1.25W and power entering REFL PD 112mW (Jenne measured these powers for me). 

I also got a description of the MC demodulation board from Jenne.

(Edits by Jenne)

 Also, when I walked through the control room later, the WFS were driving the MC crazy.  I turned off / disabled the WFS from the WFS screen.   In my infinite spare time, I need to put in the real-time triggering, so that the WFS turn off as soon as the cavity unlocks. 

  7537   Fri Oct 12 15:31:03 2012 RijuparnaConfiguration cavitymode scan

 Rijuparna, Manasa

Today I have checked the optical layout of the MC transmission RFPD table and measured the laser powers at different points. Manasa helped me for that. I found the power entering the RF photodiode is 0.394mW while the transmitted power of the cavity is 2.46mW. (I will give the diagram later).

  7270   Fri Aug 24 13:22:19 2012 DenUpdateModern Controlcavity simulation

I did a simulation of a cavity, feedback signal was calculated using LQG controller. I assumed that there is not length -> angle coupling and 2 mirrors that form the cavity have the same equation of motions (Q and eigen frequencies are the same). Cost functional was chosen in such a way that frequencies below 15 Hz contribute much more then other frequencies.

model.png             controller.png              cavity.png

Gains in the controller are calculated to minimize the cost functional.

cavity_lqg.png

This technique works well, but it requires full information about the system states. If we do not assume that cavity mirrors have the same equations of motion then we need to apply Kalman filter to approximate the position of one of the mirrors.

  4198   Tue Jan 25 05:26:51 2011 kiwamuUpdateGreen Lockingcavity scan

cavity_scan.png

I scanned the X arm by changing an offset for the feedback to ETMX while the arm stayed locked by the green locking.

But the resultant plot is still far away from a beautiful one.

Changing the offset broke the lock frequently, so eventually I couldn't measure the stability of the IR-PDH signal at the resonance. 

 

 The plot above is a result of the scanning. You can see there is a clear resonance at the center of the plot.

However the lock frequently became unstable when I was changing the offset.

It looked like this unstability came from the end PDH lock. I guess there are two possible reasons:

  (1)  feedback range for the laser PZT is not wide enough. Right now the range is limited by a SR560, which has been used for a summing amplifier.

  (2)  Length to Alignment coupling. Pushing ETMX causes a misalignment.

The issue (1) can be easily solved by engaging the temperature feedback, which helps actuating the laser frequency a lot at DC.

The issue (2) will be also solved by well align the IR beam, the arm cavity and the green beam.

  4205   Wed Jan 26 10:11:47 2011 AidanUpdateGreen Lockingcavity scan

Quote:

cavity_scan.png

 

Whether or not it's as clean as we'd like, it's really nice to see this result with real data.

  6922   Thu Jul 5 13:38:05 2012 yutaSummaryLockingcavity g-factor from mode scan

Cavity g-factor for X arm is 0.3737 +/- 0.002, Y arm is 0.3765 +/- 0.003.
If ITMs are flat and arm length L = 39 +/- 1 m, this means RoC of ETMX and ETMY is 62 +/- 2 m and 63 +/- 2 m respectively.

Calculation:
  Transverse mode spacing is expressed by

nu_TMS / nu_FSR = arccos(sqrt(g1*g2)) / pi

  where g1 and g2 is g-factor

gi = 1 - L/Ri

 of ITM/ETM.

  For mode-scan, we swept laser frequency nu. Let's assume this sweep was linear and we can replace laser frequency with time. From the mode-scan result, TMS can be derived by

  t_TMS = sum((n_i-n)*(t_i-t)) / sum((n_i-n)^2)

  where n_i is the order of transverse mode, n is average of n_i's, t_i is the time i-th order mode appeared and t is average of t_i's.
  Since I could only recognize up to 3rd order mode, this can be rewritten as

  t_TMS = 1.5/5 * t_0 + 0.5/5 * t_1 - 0.5/5 * t_2 - 1.5/5 * t_3

  FSR is time between TEM00s. So, g1*g2 can be calculated by

g1*g2 = (cos(pi*t_TMS/t_FSR))^2


X arm result:

  From the 8FSR mode-scan data (see elog #6859), X arm HOM positions in sec are;

HOM 0    242.00     214.76     187.22     159.27     131.33    102.96     74.61     46.00     17.51
HOM 1    234.29     206.78     179.20     150.96     122.90     94.58     66.27     38.10
HOM 2    226.36     198.91     170.80     142.92     114.62     86.51     58.05     29.65
HOM 3    218.14     190.65     162.71     134.78     106.68     78.27     49.95     21.25


  Calculated FSR and TMS in sec are;

FSR    27.24     27.54     27.95     27.94     28.37     28.35     28.61     28.49
TMS     7.951     8.020     8.193     8.151     8.223     8.214     8.220     8.270

  Calculated cavity g-factor are;

g1*g2    0.3699     0.3720     0.3662     0.3704     0.3761     0.3765     0.3839     0.3748

  By taking average,

g1*g2 = 0.3737 +/- 0.002  (error in 1 sigma)


Y arm result:
  From 8FSR mode-scan data (see elog #6832), Y arm HOM positions in sec are;

HOM 0    246.70     218.15     190.06     161.87     133.26    104.75     76.01     47.19     18.60
HOM 1    238.83     210.55     181.88     153.47     124.93     96.08     67.51     39.01
HOM 2    230.48     202.21     173.64     144.80     116.43     86.17     59.84     31.43
HOM 3    222.15     193.47     165.33     137.13     108.60     80.04     51.17     22.25


  Calculated FSR and TMS in sec are;

FSR    28.55     28.09     28.19     28.61     28.51     28.74     28.82     28.59
TMS     8.200     8.238     8.243     8.289     8.248     8.404     8.219     8.240


  Calculated cavity g-factor are;

g1*g2    0.3841     0.3657     0.3683     0.3765     0.3778     0.3683     0.3904     0.3811

  By taking average,

g1*g2 = 0.3765 +/- 0.003  (error in 1 sigma)


Conclusion:
  If ITMs are flat and arm length L = 39 +/- 1 m, this means RoC of ETMX and ETMY is 62 +/- 2 m and 63 +/- 2 m respectively. Designed RoC is 57.35 m.
  Error of RoC is dominated by arm length error. So, we need more precise measurement of the length. This can be done when scan is calibrated and we can measure FSR in frequency.
  Also, we need evaluation of linearity of the sweep. This also can be done by calibration.

  8586   Wed May 15 23:38:04 2013 ranaUpdateelogcategories trimmed

I deleted a bunch of useless categories from the 40m elogd.cfg file. IF you find your category has been deleted, you can now learn how to categorize yourself into the existing categories. ELOG restarted and log file zeroed.

  12965   Wed May 3 16:12:36 2017 johannesConfigurationComputerscatastrophic multiple monitor failures

It seems we lost three monitors basically overnight.

The main (landscape, left) displays of Pianosa, Rossa and Allegra are all broken with the same failure mode:

their backlights failed. Gautam and I confirmed that there is still an image displayed on all three, just incredibly faint. While Allegra hasn't been used much, we can narrow down that Pianosa's and Rossa's monitors must have failed within 5 or 6 hours of each other, last night.

One could say ... they turned to the dark side cool

Quick edit; There was a functioning Dell 24" monitor next to the iMac that we used as a replacement for Pianosa's primary display. Once the new curved display is paired with Rossa we can use its old display for Donatella or Allegra.

  12966   Wed May 3 16:46:18 2017 KojiConfigurationComputerscatastrophic multiple monitor failures

- Is there any machine that can handle 4K? I have one 4K LCD for no use.
- I also can donate one 24" Dell

  12971   Thu May 4 09:52:43 2017 ranaConfigurationComputerscatastrophic multiple monitor failures

That's a new failure mode. Probably we can't trust the power to be safe anymore.

Need Steve to order a couple of surge suppressing power strips for the monitors. The computers are already on the UPS, so they don't need it.

  12978   Tue May 9 15:23:12 2017 SteveConfigurationComputerscatastrophic multiple monitor failures

Gautam and Steve,

Surge protective power strip was install on Friday, May 5 in the Control Room

Computers not connected to the UPS are plugged into Isobar12ultra.

Quote:

That's a new failure mode. Probably we can't trust the power to be safe anymore.

Need Steve to order a couple of surge suppressing power strips for the monitors. The computers are already on the UPS, so they don't need it.

 

  12993   Mon May 15 20:43:25 2017 ranaConfigurationComputerscatastrophic multiple monitor failures

this is not the right one; this Ethernet controlled strip we want in the racks for remote control.

Buy some of these for the MONITORS.

Quote:

Surge protective power strip was install on Friday, May 5 in the Control Room

Computers not connected to the UPS are plugged into Isobar12ultra.

Quote:

That's a new failure mode. Probably we can't trust the power to be safe anymore.

Need Steve to order a couple of surge suppressing power strips for the monitors. The computers are already on the UPS, so they don't need it.

 

  10938   Fri Jan 23 19:38:02 2015 JenneUpdateLSCcarm_cm_up supports both signs of CARM offset

A small change, but now the carm_up script supports both sides of the CARM offset.  After the arms are locked with ALS it asks for a "+" or a "-", which indicates which sign of digital CARM offset will be added.  In the past, we have been primarily using the "+" sign.
 

  4667   Mon May 9 16:12:49 2011 JamieConfigurationCDScanonicalize paths to core and userapps

I have updated the /opt/rtcds paths to reflect the new specification of the CDS aLIGO code release procedures document.


Path to RTS/opt/rtcds/caltech/c1/core/release

This is where the advLigoRTS front-end code generator is checked out.  The "release" directory is a link to the svn branch from which we are currently running ("trunk" by default).

This used to be at /opt/rtcds/caltech/c1/core/advLigoRTS


Path to userapps: /opt/rtcds/caltech/c1/userapps/release

This is where the cds_user_apps code is checked out.  cds_user_apps is where all of the front-end models, medm screen, scripts, etc. will live.  The "release" directory is a link to the svn branch from which we are currently running ("trunk" by default).

This was most recently at /opt/rtcds/cds_user_apps

 

  14336   Fri Dec 7 19:42:47 2018 ranaFrogselogcan't upgrade DokuWiki because of PHP / SL7

All of our wikis (except the 40m one which unfortunately got turned into ligo.org mess) use DokuWiki. This now has an auto-upgrade feature through the Admin web interface.

I tried this recently and it fails with this message:

DokuWiki 2018-04-22a "Greebo" is available for download.
 You're currently running DokuWiki Release 2017-02-19e "Frusterick Manners".
! New DokuWiki releases need at least PHP 5.6, but you're running 5.4.16. You should upgrade your PHP version before upgrading!

So we'll have to wait until SL7 (which is what NODUS is running).

I DID do a 'yum upgrade' which updated all the packages. I also installed yum-cron so that the RPM listings get updated daily. But sadly, SL7 only has PHP 5.4.16 (which is a June 2013 release):

> Package php-5.4.16-43.el7_4.1.x86_64 already installed and latest version

ELOG V3.1.3-