When I run StripTool on Pianosa, I get the following message

==== StripTool Xt Warning Handler ====
warning:         Axis: minVal is greater than or equal to maxVal

And the y-axis scale reverts to 0 -100 regardless of what ever I set in the controls panel

I ssh'ed into rosalba and ran striptool from there and did not face this problem.  So I think pianosa has a problem with Striptool.

I restarted the frame builder at the following times

Tue Sep 13 14:53:49 PDT 2011

Tue Sep 13 16:46:32 PDT 2011

Tue Sep 13 17:24:16 PDT 2011

[Suresh, Jamie]

The new versions of these three models have been committed to the svn.  I copy below the svn log I wrote over there.

I edited three models,namely c1ioo, c1mcs and c1rfm to bring four channels from C1MCS model into the
 C1IOO model through the RFM.

We plan to use the MC2-Trans-QPD as a third sensor in addition to the WFS1 and WFS2 in the ASC system so that we can sense all the six degrees of freedom of the MC.  However the MC2-Trans_QPD is a new incarnation of the old MC2 Oplev QPD and its four segments are are picked up in the c1mcs model running on the C1SUS machine.  Since we need these    in the C1IOO machine we    had to port these signals via the RFM.  The    changes    I made to these    models are described below:
1) c1rfm.mdl -->  I added several cds parts to carry these four    channels from c1mcs to c1ioo via c1rfm

2) c1mcs.adl -->  In the MC2 block of c1mcs I cut out the structure which converts the four segments of the  QPD in the pitch, yaw and sum signals and copied it to the c1ioo model.     In the    c1mcs I  grounded the input of the oplev signals just as they are in    the MC1    and MC2    suspension blocks. I then routed the ADC channels associated with the oplev QPD signals to the rfm model.

3) c1ioo.mdl --> I have made extensive changes to the c1ioo model to include the third sensor in the WFS feedback loop.  The six lockins in the model are used to excite the MC mirrors and the signals from WFS and QPD can be demodulated to determine the input or output matrices in the WFS feedback.  A sensor_demod_array permits us to select the signals we wish to demodulate. The MCL signal, used in the MC_ASS and A2L measurements, is retained as one of the signals.  The MC_TRANS_SUM was used several in  scripts and to preserve the continuity with this channel name we inserted three EPICS parts to generate a slow channel by the same name from this model.

Since the MC_TRANS_SUM is used in the MC-autolocker script we checked to make sure that the script is running after we recompiled all the three models and restarted them.  It is all fine.

I changed a filter bank name (C1IOO-WFS1_PIT) in c1ioo model reverting it to its earlier name.  Had to restart c1ioo model and the fb

I had to change the c1ioo model and restart the fb since the paths allowing us to select various signals to demodulate using the lockins were not correct. The signal selection vector was not flexible enough to permit us to select the signals to demod.

fb was restarted twice at following times.  The changes have been commited to the svn.

Fri Sep 16 13:35:47 PDT 2011

Fri Sep 16 14:36:21 PDT 2011

To look at the WFS servo signals I was using test points in the servo filter banks.  This is not recommended for regular operation since acquiring the testpoint data at 16k loads the fb. Instead, I ran the daqconfig script from the scripts directory and activated the IN1_DQ, IN2_DQ and OUT_DQ channels in all the six servo filter banks (at 2048 Hz sampling rate) and then restarted the fb.   However the c1ioo Sun machine stopped responding after this.  Koji and I went in to see what was going on and the machine was not reponding to a keyboard plugged directly into the machine.  The screen display showed no reponse to our key press.  So we did a hardware reboot with the tiny switch in front of the machine.  It came up okay and all the c1ioo models were back in action.

I then checked with the dataviewer to make sure that I can see the trends on the newly activated DQ channels.  They were all fine.

I changed the names on a switch(SW1) in the C1:PSL-FSS screen.  To do this I had to edit the psl.db database file in the directory /cvs/cds/caltech/target/c1psl.  After this change, when I executed this screen, all fields in the C1PSL_FSS screen went blank.  As the change to database file takes effect only after we restart the C1PSL machine (slow machine) I went ahead and reset the c1psl machine.  I then used the burttoday to locate the most recent snapshot files and then used burtgooey to restore all the values in the c1psl.snap file.

Everything back to normal now.

I have added a switch in series with the WFS_GAIN. And I have also added a LKIN_OUT_MATRX between the lockin-outputs and the MC suspensions.  This will enable us to drive the MC mirrors in any combination so that we can (in principle) attain pure translations and rotations of the MC axis.

I will compile the model later during the day.  This is just in case anyone one else were to compile c1ioo.mdl before then.

.

 I copied the Kissel button generator scripts folder into scripts:

/opt/rtcds/caltech/c1/scripts/KisselButtonGenerator/

Maybe this isn't the most intuitive place ever, since it's a script that only has to do with medm screens, but at least it's better than hidden in the depths of Koji's LSC medm path.....

The MC was not damping earlier this morning around 11:45AM.  The reason was that the INMATRIX on all the three MC1, 2 and 3 were zero.   This was seen earlier when autoburt did not restore this.

This got fixed when I Burt-Restored c1mcsepics.snap

In the afternoon we had to restore c1mcs again to restore the MC_TRANS channels because its INMATRIX was also zero.

Can we do something to make sure this gets done in the autoburt properly?

[Mirko, Kiwamu]

I tried to answer two questions regarding the IMC:

1. What is the coupling of fluctuations in the SB freq. to SB transmitted power?
2. What (if any) is the influence of the IMC on the AM?

I ran into some weird things regarding the corresponding optickle simulations:
1. There seems to be some artifact at the beginning of every simulation sweep.
2. The position of features depends on the parameters of the sweep.

I mailed Matt asking if he sees some error in the simulations

 Doesn't work on pianosa either. Has someone changed the python environment?

pianosa:SUS_SUMMARY 0> ./setSensors.py 1000123215 600 0.1 0.25
Traceback (most recent call last):
  File "./setSensors.py", line 2, in <module>
    import nds
ImportError: No module named nds

 So I found that the NDS2 lib directory in (/ligo/apps/nds2/lib) was completely empty.  I reinstalled NDS2 and pynds, and they are now available again by default on pianosa (it should "just work", assuming you don't break your environment).

Why the NDS2 lib directory was completely empty is definitely a concern to me.  The contents of directories don't just disappear.  I can't imagine how this would happen other than someone doing it, either on purpose or accidentally.  If someone actually deleted the contents of this directory on purpose they need to speak up, explain why they did this, and come see me for a beating.

The "dataviewer" script was still setting the server to fb40m on nodus. I modified it to fb, so that this is the default when you enter "dataviewer" or "dv".

While trying to implement the regular yellow shell script button in MEDM for my new OAF screen, I noticed that the update snapshot stuff in all of the buttons that I checked (including IFO Align and LSC Overview) are pointing to folders in the old /cvs/cds/caltech/ area.  Also, I think some of the folders that it's looking for don't exist anymore, even in the old system.  So.  Has anyone thought about where the snapshots should live in the new world order?  Previously they were in ...../medm/c1/subsystem/ .  Maybe we should make a snapshots folder in each subsystem's medm folder, at the same level as the 'master' folder for the custom screens?  This is my current proposal.

Unless someone objects / has a better plan / knows why they're still pointing to the old place, I'll do this in the morning, and work on changing all the buttons to point to the new place.

The following directory exists. We can apply this convention to all of the models.

/cvs/cds/rtcds/caltech/c1/medm/c1lsc/snap

The MC suspensions were not damping and the reason was traced to the empty imput matrices in the suspension controls.  This has been an issue in the past as well when the sus machine is rebooted some of the burt restore does not populate these matrices.

I ran the burtgooey and restored c1mcs.snap file.  from a couple of hours ago.

 As part of the initiative to get a good daily summary page for aLIGO commissioning, Josh is spearheading his Detector Characterization group to produce such web pages for the 40m.

They're starting out with this launching point and then we can add all kinds of other information and plots as we want (e.g. Vac, PEM, Weather, coffee status). If you have suggestions/ideas, just edit this entry and add them, or email Josh directly.

I tried to run the seismic StripTool tonight, which seems liek a simple task. But instead I fell through the rabbit hole again...

The seismic.stp couldn't be run from zita/op340m because zita doesn't have EPICS or MEDM and because the op340m version of StripTool cannot load the new file format in which rossa/pianosa save their files.

Once I got it running by sshing in to rossa, I noticed that the BLRMS trends didn't make any sense. Correctly guessed that this was because all of the BP and LP filters were off. Why? Because of bad BURT, that's why.

As it turns out (if you look through the autoburt logs), several of our FE machines haven't been correctly saving snapshots because of some channel count mismatch between old and new SNAP files. So we are not getting the settings restored correctly for these systems when they get booted. Probably, someone has got to suss out the source of the BURT snap messages; it may be that we have to rehash the snap process after any substantial model rebuild.

For c1pemepics, I did a manual restore from the time when Mirko last ELOG'd that BLRMS was trending OK (Nov 23 @ 3 AM).

Seems like we should also get some kind of auto email warning if the BURTs fail in this way. Otherwise, we'll lose a lot of work if it goes on for weeks.

Bottom line: fix the autoburt so that it doesn't fail after model rebuilds.

Often people say "I don't use conlog because its real slow". Its a little like not driving because your car has no gas.

I looked into what's going on with conlog. No one has fixed its channel list in ~1 year so it didn't make much sense. Also since Oct 1 of this year, it expired the leap seconds epoch and has been waiting for someone to look at the log file and update the list of leap seconds.

Some issues:

• Don't use the phrases like OUTPUT, OUTMON, OUT16, or INMON as the usual part of a channel name. These are filter modules words which use to exclude channels from conlog. Please fix ALL of the LOCKIN screens to get rid of the OUTPUT filter banks.
• If you use an EPICS channel in a servo so that its getting changed 16 times a second, make sure to add it to the conlog exclude list.

There are a bunch of bad channels which are screwing up various tools (DV, DTT, etc.):

Examples: C1:LSC-Subsystem_NPRO_SW1, C1:-DOF2PD_MTRX_0_0_SW1, C1:BAD-BAR_CRAZY_2_RSET, C1:C1L-DOF2PD_MTRX_3_14_SW2, C1:DUB-SEIS_GUR2_Z_LIMIT, etc.

• There are a bunch of old, unused directories in c1/medm/. EVERYONE take a look in there and delete the OLD dead ones so that we don't keep recording those channels.

 To fix up some of these issues, I have deleted several MEDM directories which I thought were old (there are several extras left from Aidan's Green time). I also have put a bunch of exclude variables into the conlog 'scan_adls' script to prevent it from adding some of the new worthless channels. Finally, I have started this command

../bin/strip_out_channels '.*STAT.*','.*_ALIVE.*','C1:PEM.*','.*_Name.*','C1:UCT.*','C1:MCP.*','C1:SP.*','C1:DU.*','C1:RF.*','C1:NIO.*','C1:TST.*','C1:SUP.*','C1:X.*','C1:FEC.*','.*_LFSERVO.*','.*FSS_SLOWDC.*','C1:LSC-LA_MTRX_21','C1:LSC-PD.*OFFSET','C1:LSC-ETM.*OFFSET' conlog*.log

which should strip lots of the excess conlog data out of the conlog directory. The only downside is that its setting all of the timestamps of the .log files to today instead of the historical times but I don't think we'll care about this too much. Hopefully it will speed things up to have less than 450 GB of conlog files...

update: 12 hours later, its still running and has removed ~100 GB so far. It will probably take the rest of the weekend to finish.

 I moved the following old and obsolete MEDM directories to an archive /cvs/cds/rtcds/caltech/c1/medm

• c1vga
• c1vgl
• c1gpt
• c1gpv
• c1nio
• c1spy
• c1spx

None of these models were present in /cvs/cds/rtcds/caltech/c1/target

Remember that we don't use /cvs/cds/rtcds anymore.  Everything should be in /opt/rtcds now.

 This may or may not be general knowledge already, but Jamie and I added a HowTo explaining how to retrieve channel data from the frame builder via NDS, but off site on one's own computer.  See the Wiki page:

https://wiki-40m.ligo.caltech.edu/How_To/NDS

In order to install the necessary extensions to epics to make the aLIGO conlog work, I have edited one file in the base epics install that affects makefiles:

/cvs/cds/caltech/apps/linux64/epics/base/configure/CONFIG_COMMON

Jamie said he prefers diffs, so I regenerated the original file and did a diff against the current file:

megatron:configure>diff CONFIG_COMMON.orig.reconstructedMar72012 CONFIG_COMMON.bck.Mar72012
206,207c206,210
< USR_CPPFLAGS =
< USR_DBDFLAGS =
---
> USR_CPPFLAGS = -I $(EPICS_BASE)/include
> USR_CPPFLAGS += -I $(EPICS_BASE)/include/os/Linux/
> USR_CPPFLAGS += -I $(EPICS_BASE)/../modules/archive/lib/linux-x86_64/
> USR_DBDFLAGS = -I $(EPICS_BASE)/dbd
> USR_DBDFLAGS += -I $(EPICS_BASE)/../modules/archive/dbd

This is saved in CONFIG_COMMON.diff.Mar72012_1

 After following up with Patrick Thomas for a while trying to make the extensions to epics work within the currently installed epics, he decided that we should just start over with a fresh install of epics 3.14.10.

I am installing this in /ligo/apps/linux-x86_64/epics/base-3.14.10/

Prior to all of this, I had done a lot of installation and configuration of the packages needed to make LAMP work:

sudo apt-get install lamp-server^

sudo apt-get install phpmyadmin

I then continued to follow the instructions on Patrick's wiki:

https://awiki.ligo-wa.caltech.edu/aLIGO/Conlog#EDCU_library

I installed the c_string library into /ligo/apps/linux-x86_64/ according to his instructions.  (prior to my installs, there was no /ligo/ on this machine at all, so I made the needed parent directories with the correct permissions).

That should be everything up to installing epics (working on that now).

Successful? Installation of Fresh EPICS and Extensions

Fresh Copy of EPICS 3.14.10

/ligo/apps/linux-x86_64/epics

/ligo/apps/linux-x86_64/epics/iocs/conlog/iocBoot/iocc1_conlog

Rest of Install

New Install Instructions:

You want to create the EPICS IOC boot directory by doing the following:

In the top level of the IOC (.../epics/iocs/conlog) with the appropriate
paths:

/epics/base/bin/linux-x86_64/makeBaseApp.pl -i -t ioc c1_conlog
What application should the IOC(s) boot?
The default uses the IOC's name, even if not listed above.
Application name? conlog

Then you will have to update the st.cmd it creates. You can compare the
st.cmd and st.cmd.backup files in the other directories to see what needs
to be changed.

I don't know if just copying the directory will work, it might.

You will also probably want to change the following line in
/epics/modules/archive/archiveApp/src/drvArchive.c:

queue = epicsMessageQueueCreate(100000000, sizeof(struct message_type));

and reduce 100000000 to something smaller depending on the amount of ram
available to the computer. I think sizeof(struct message_type) is
something like 112 bytes. Then recompile.

You basically put a file with the list of channels to use in the directory
path for "use channel list filepath" in the following command in st.cmd:
drvArchive_read_channel_list_filepaths <add channel list filepath>,<remove
channel list filepath>,<use channel list filepath>
I can send you the script that I currently use to generate that channel
list if you want, but it may need to be changed for your setup.

Once you start the ioc, open the medm which can be checked out from
subversion here: cds_user_apps/trunk/cds/common/medm/CONLOG.adl
with macro substitution for IFO: medm -x -macro "IFO=C1"
and click on the button for "Use channel list".
The number of monitored channels should increase to the number of channels
in the file.

-Patrick

...

The perl script and example file are attached, just redirect the output of
the perl script to a file. It scans autoBurt.req files in a particular
directory and its subdirectories for channel names that meet certain
criteria. All the file contains is a list of channel names, one on each
line. To start the IOC, go to the target directory and run
./startup.c1conlog.

My Notes Regarding These Instructions:

dbLoadRecords("db/conlog.db","IFO=C1")
drvArchive_mysql "C1_conlog","/data/mysql/C1_conlog_epics_user"
drvArchive_read_channel_list_filepaths "/ligo/caltech/data/conlog/c1/add_channel_names","/ligo/caltech/data/conlog/c1/remove_channel_names","/ligo/caltech/data/conlog/c1/use_channel_names"
drvArchive_write_channel_list_filepaths "/ligo/caltech/data/conlog/c1/channel_names","/ligo/caltech/data/conlog/c1/monitored_channel_names","/ligo/caltech/data/conlog/c1/unmonitored_channel_names"

controls: cd /opt/rtcds/<site>/<ifo>/target/conlog/conlogepics
controls: cp -r /ligo/apps/linux-x86_64/epics/iocs/conlog/db ./
controls: cp -r /ligo/apps/linux-x86_64/epics/iocs/conlog/dbd ./
controls: cp /ligo/apps/linux-x86_64/epics/iocs/conlog/iocBoot/ioc<ifo>_conlog/envPaths ./
controls: cp /ligo/apps/linux-x86_64/epics/iocs/conlog/iocBoot/ioc<ifo>_conlog/st.cmd ./
controls: echo ./bin/linux-x86_64/conlog st.cmd > startup.<ifo>conlog
controls: chmod a+x startup.<ifo>conlog

megatron:~/ryan>diff -u /var/www/conlog/conlog.php /var/www/conlog/conlog.php.bck.Mar82012_1
--- /var/www/conlog/conlog.php  2012-03-08 15:31:53.152547771 -0800
+++ /var/www/conlog/conlog.php.bck.Mar82012_1   2012-03-08 15:28:23.062704171 -0800
@@ -19,7 +19,7 @@
        <form action="query.php" method="post">
                <h3><label for="database">Database:</label></h3>
                <select id="database" name="database">
-                       <option value="C1_conlog">C1</option>
+                       <option value="h2_conlog">h2</option>
                </select>
 
                <h3><label for="included_channels">Included channels:</label></h3>

megatron:~/ryan>diff -u /var/www/conlog/query.php /var/www/conlog/query.php.bck.Mar82012_1
--- /var/www/conlog/query.php   2012-03-08 15:33:45.122550303 -0800
+++ /var/www/conlog/query.php.bck.Mar82012_1    2012-03-08 15:32:31.772554679 -0800
@@ -168,8 +168,8 @@
        }
 
        $database_name = $_POST["database"];
-       if ($database_name == 'C1_conlog') {
-               $server = '192.168.113.209';
+       if ($database_name == 'h2_conlog') {
+               $server = 'cdsconlog';
        }
        else {
                die('Unknown database.');

megatron:~/ryan>diff -u /etc/mysql/my.cnf /etc/mysql/my.cnf.bck.Mar82012_1
--- /etc/mysql/my.cnf   2012-03-08 15:35:57.122548370 -0800
+++ /etc/mysql/my.cnf.bck.Mar82012_1    2012-03-08 15:35:10.652559315 -0800
@@ -49,7 +49,7 @@
 #
 # Instead of skip-networking the default is now to listen only on
 # localhost which is more compatible and is not less secure.
-#bind-address          = 127.0.0.1
+bind-address           = 127.0.0.1
 #
 # * Fine Tuning
 #
megatron:~/ryan>

Conlog Environment

Too Many Fast Changing EPICS in New Conlog

For your mode matching pleasure, I have added a tool called "ModeMatchr" to the SVN under /trunk/zach/tools/modematchr/

It uses the usual fminsearch approach, but tolerates a fully astigmatic input (i.e., w_0ix ≠ w_0iy, z_0ix ≠ z_0iy) and allows for transforming to an elliptical waist  (i.e., w_0fx ≠ w_0fy, but z_0fx = z_0fy). It would be straightforward to allow for z_0fx ≠ z_0fy, but I have never seen a case when we actually wanted this. On the other hand, the elliptical output ability is nice for coupling to wide-angle ring cavities.

It also does the looping through available lenses for you , and retains the best solution for each lens combination in an output cell, which can then be combed with another function (getOtherSol). fminsearch is incredibly fast: with a 10-lens bank, it finds all 100 best solutions on my crappy MacBook in <10s.

I have also included the functionality to constrain the length of the total MMT to within some percentage of the optimal distance, which helps to sift through the muck .

I have added to ModeMatchr the capability to fix the total MMT distance. This is nice if you are coupling to a cavity some fixed distance away. The blurb from the help:

% Note: for any total length constraint dtot_tol > 0, ModeMatchr will use
% fminsearch to find the best solutions near your nominal dtot, and then
% omit solutions whose dtot lie outside your tolerance. For dtot_tol = 0,
% ModeMatchr actively constrains dtot to your value, and then finds the
% best solution. Therefore, set dtot_tol = 0 if you have a fixed distance
% into which to put a MMT.

I have installed ACAD 2002 on one of the Windows machines in the Control Room.    It is on the machine which has Solid Works (called C21530). 

The installation files are in MyDocuments under Acad2002.  This a shared LIGO license which Christian Cepada had with him.

I hope we will be able to open our optical layout diagrams with this and update them even though it is an old version.

I have modified Arbcav to be way cooler than it used to be.

Main modifications:

• Can now truly model an arbitrary cavity geometry
  • The previous version could only handle a few different topologies. In each case, it would unfold the cavity into the equivalent linear cavity and use the g-parameter method to calculate gouy phases, etc.
  • The new model uses the closed cavity propagation matrix to find the supported mode, and then explicitly calculates the accumulated gouy phase by propagating the beam through the full cavity. This is done analytically with z_R, so there is negligible slow-down.
• Now plots a diagram of the cavity geometry, both to help you and for you to verify that it is calculating the right thing (<-- this is the cool part)
  • Plots the beam path and mirror locations
  • Specifies whether mirrors are curved or flat
  • Prints mirror parameters next to them
  • Finds all intracavity waist locations and plots them
  • Gives waist information (size in X, Y)

Since the information is already there, I will have the output structure include things like the input beam q parameter, which could then be fed directly to mode matching tools like ModeMatchr.

The function takes as input the same arguments as before. Example for a square cavity:

out = arbcav([200e-6 50e-6 200e-6 50e-6],[0.75 0.75 0.75 0.75],[1e10 9 1e10 9],[45 45 45 45],29.189e6,10e-6,1064e-9,1000);

i.e.,

out = arbcav(transmissivity_list, length_list, RoC_list, angle_list, modulation_freq, loss_list_or_loss_per_mirror, wavelength, num_pts_for_plot);

If you don't give it a modulation frequency, it will just plot carrier HOMs. If you don't give it RoCs and angles, it will just plot the transmission spectrum.

I'm still fine-tuning some functionality, but I should have it up on the SVN relatively soon. Comments or suggestions are welcome!

Some screenshots:

Cavity geometry plots (linear, triangular, square, bowtie):

Transmission and HOM spectra (these correspond to the square cavity at lower left, above):

C1OAF model, codes and medm screens are updated. All proper files are commited to svn and updated at the new model path.

40m summary webpages

 The aLIGO-style summary webpages are now running on 40m data! They are running on megatron so can be viewed from within the martian network at:

http://192.168.113.209/~controls/summary

At the moment I have configured the 5 seismic BLRMS bands, and a random set of PSL channels taken from a strip tool.

Technical notes

• The code is in python depending heavily on the LSCSoft PyLAL and GLUE modules.
  • /home/controls/public_html/summary/bin/summary_page.py
• The HTML is supported by a CSS script and a JS script which are held locally in the run directory, and JQuery linked from the google repo.
  • /home/controls/public_html/summary/summary_page.css
  • /home/controls/public_html/summary/pylaldq.js
• The configuration is controlled via a single INI format file
  • /home/controls/public_html/summary/share/c1_summary_page.ini

Getting frames

Since there are no segments or triggers for C1, the only data sources are GWF frames. These are mounted from the framebuilder under /frames on megatron. There is a python script that takes in a pair of GPS times and a frame type that will locate the frames for you. This is how you use it to find T type frames (second trends) for May 25 2012:

python /home/controls/public_html/summary/bin/framecache.py --ifo C1 --gps-start-time 1021939215 --gps-end-time 1022025615 --type T -o framecache.lcf

If you don't have GPS times, you can use the tconvert tool to generate them

$ tconvert May 25
1021939215

The available frame types, as far as I'm aware are R (raw), T (seconds trends), and M (minute trends).

Running the code

The code is designed to be fairly easy to use, with most of the options set in the ini file. The code has three modes - day, month, or GPS start-stop pair. The month mode is a little sketchy so don't expect too much from it. To run in day mode:

python /home/controls/public_html/summary/bin/summary_page.py --ifo C1 --config-file /home/controls/public_html/summary/share/c1_summary_page.ini --output-dir . --verbose --data-cache framecache.lcf -SRQDUTAZBVCXH --day 20120525

Please forgive the large apparently arbitrary collection of letters, since the 40m doesn't use segments or triggers, these options disable processing of these elements, and there are quite a few of them. They correspond to --skip-something options in long form. To see all the options, run

python /home/controls/public_html/summary/bin/summary_page.py --help

There is also a convenient shell script that will run over today's data in day mode, doing everything for you. This will run framecache.py to find the frames, then run summary_page.py to generate the results in the correct output directory. To use this, run

bash /home/controls/public_html/summary/bin/c1_summary_page.sh

Configuration

Different data tabs are disabled via command link --skip-this-tab style options, but the content of tabs is controlled via the ini file. I'll try to give an overview of how to use these. The only configuration required for the Seismic BLRMS 0.1-0.3 Hz tab is the following section:

[data-Seismic 0.1-0.3 Hz]
channels = C1:PEM-RMS_STS1X_0p1_0p3,C1:PEM-RMS_STS1Y_0p1_0p3,C1:PEM-RMS_STS1Z_0p1_0p3
labels = STS1X,STS1Y,STS1Z
frame-type = R
plot-dataplot1 =
plot-dataplot3 =
amplitude-log = True
amplitude-lim = 1,500
amplitude-label = BLRMS motion ($\mu$m/s)

The entries can be explained as follows:

1. '[data-Seismic 0.1-0.3 Hz] - This is the section heading. The 'data-' mark identifies this as data, and is a relic of how the code is written, the 'Seismic 0.1-0.3 Hz' part is the name of the tab to be displayed in the output.
2. 'channels = ...' - This is a comma-separated list of channels as they are named in the frames. These must be exact so the code knows how to find them.
3. 'labels = STS1X,STS1Y,STS1Z' - This is a comma-separated list of labels mapping channel names to something more readable for the plots, this is optional.
4. 'frame-type = R' - This tells the code what frame type the channels are, so it can determine from which frames to read them, this is not optional, I think.
5. 'plot-dataplotX' - This tells the code I want to run dataplotX for this tab. Each 'dataplot' is defined in it's own section, and if none of these options are given, the code tries to use all of them. In this configuration 'plot-dataplot1' tells the code I want to display the time-series of data for this tab.
6. 'amplitude-XXX = YYY' - This gives the plotter specific information about this tab that overrides the defaults defined in the dataplotX section. The options in this example tell the plotter that when plotting amplitude on any plot, that axis should be log-scale, with a limit of 1-500 and with a specific label. The possible plotting configurations for this style of option are: 'lim', 'log', 'label', I think.

Other compatible options not used in this example are:

• scale = X,Y,Z - a comma-separated list of scale factors to apply to the data. This can either be a single entry for all channels, or one per channel, nothing in between.
• offset = X,Y,Z - another comma-separate list of DC offsets to apply to the data (before scaling, by default). DAQ noise may mean a channel that should read zero during quick times is offset by some fixed amount, so you can correct that here. Again either one for all channels, or one per channel.
• transform = lambda x: f(x) - a python format lambda function. This is basically any mathematical function that can be applied to each data sample. By default the code constructs the function 'lambda d: scale * (d-offset)', i.e. it calibrates the data by removing the offset an applying the scale.
• band = fmin, fmax - a low,high pair of frequencies within which to bandpass the data. Sketchy at best...
• ripple_db = X - the ripple in the stopband of the bandpass filter
• width = X - the width in the passband of the bandpass filter
• rms_average = X - number of seconds in a single RMS average (combine with band to make BLRMS)
• spectrum-segment-length = X - the length of FFT to use when calculating the spectrum, as a number of samples
• spectrum-overlap = X - the overlap (samples) between neighbouring FFTs when calculating the spectrum
• spectrum-time-step = X - the length (seconds) of a single median-mean average for the spectrogram

At the moment a package version issue means the spectrogram doesn't work, but the spectrum should. At the time of writing, to use the spectrum simple add 'plot-dataplot2'.

You can view the configuration file within the webpage via the 'About' link off any page.

Please e-mail any suggestions/complaints/praise to duncan.macleod@ligo.org.

There is now a job in the crontab that will run the shell wrapper every hour, so the pages _should_ take care of themselves. If you make adjustments to the configuration file they will get picked up on the hour, or you can just run the script by hand at any time.

$ crontab -l
# m h  dom mon dow   command
0 */1 * * * bash /home/controls/public_html/summary/bin/c1_summary_page.sh > /dev/null 2>&1

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

For now,

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

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

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

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

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

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

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

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

retries=5

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

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

if [ -z "$@" ] || [[ "$1" == '-h' ]] ; then
    "$run"
    exit
fi

for try in $(seq 1 "$retries") ; do
    if "$run" "$@"; then
	exit
    else
	echo "retrying ($try/$retries)..." >&2
    fi
done
echo "$(basename $pgm) failed after $retries retries." >&2
exit 1

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

$ EZCA_NORETRY=true ezcaread FOOBAR

A nicer, better maintained version of tconvert is now supplied by the lalapps package.  It's called lalapps_tconvert.  I installed lalapps on all the workstations and aliased tconvert to point to lalapps_tconvert.

I made a python script for relocking PMC.
It currently lives in /opt/rtcds/caltech/c1/scripts/PSL/PMC/PMClocker.py.

I think the hardest part for this kind of locker is the scan speed. I could make the scan relatively fast by using pyNDS.
The basic algorithm is as follows.

1. Turns off the servo by C1:PSL-PMC_SW1.

2. Scans C1:PSL-PMC_RAMP using ezcastep.bin. Default settings for ezcastep is

ezcastep.bin C1:PSL-PMC_RAMP -s 0.1 0.01 10000

So, it steps by 0.01 for 10000 times with interval of 0.1 sec.

3. Get C1:PSL-PMC_PMCTRANSPD and C1:PSL-PMC_RAMP online 1 sec data using pyNDS.

4. If it finds a tall peak in C1:PSL-PMC_PMCTRANSPD, kills ezcastep.bin process, sets C1:PSL-PMC_RAMP to the value where the tall peak was found, and then turns on the servo.

5. If tall peak wasn't found, go back to 3 and get data again.

6. If C1:PSL-PMC_RAMP reaches near -7 V or 0 V, it kills previous ezcastep.bin process and turns the sign of the scan.

I tested this script several times. It sometimes passes over TEM00 (because of the dead time in online pyNDS?), but it locks PMC with in ~10 sec.
Currently, you have to run this to relock PMC because I don't know how to make this an autolocker.

I think use of pyNDS can be applied for finding IR resonance using ALS, too.
I haven't checked it yet becuase c1ioo is down, but ALS version lives in /users/yuta/scripts/findIRresonance.py. ALS may be easier in that we can use fast channels and nice filter modules.

Other scripts:
 I updated /opt/rtcds/caltech/c1/scripts/general/toggler.py. It now has "lazymode". When lazymode, it toggles automatically with interval of 1 sec until you Ctrl-c.

 Also, I moved damprestore.py from my users directory to /opt/rtcds/caltech/c1/scripts/SUS/damprestore.py. It restores suspension damping of a specified mirror when watchdog shuts down the damping.

I made a python script for finding IR resonance using ALS. It currently lives in /opt/rtcds/caltech/c1/scripts/ALS/findIRresonance.py.

The basic algorism is as follows.

1. Scan the arm by putting an offset to the phase output of the phase tracker(Step C1:ALS-BEAT(X|Y)_FINE_OFFSET_OFFSET by 10 deg with 3 sec ramp time).

2. Fetch TR(X|Y) and OFFSET online data using pyNDS during the step.

3. If it finds a tall peak, sets OFFSET to the value where the tall peak was found.

4. If tall peak wasn't found, go back to 1 and step OFFSET again.

The time series data of how he did is plotted below.
I ran the script for Y arm, but it is compatible for both X and Y arm.

I thought we rewrite auto lockers once per year, but this time it took us only a month. I wrote it for PMC on May 24. Is it not working?

Could someone make it more clear why some scripts are written on bash, others on sh or python? I think we should elaborate a strict order. Masha and I can work on it if anyone else considers this issue as a problem.

I know.
I just wanted to use pyNDS for this kind of scanning & locking situation.
c1ioo was down for the weekend and I couldn't test my script for ALS, so I used it for PMC.

But I think PMClocker.py can relock PMC faster because it can sweep C1:PSL-PMC_RAMP continuously and can get continuous data of C1:PSL-PMC_PMCTRANSPD.

I started playing with matlab for the first time, accurately simulated a coupled harmonic oscillator (starting from the basic differential equations, if anyone's curious), wrote a program to get a bode plot out of any simulation (regardless of the number of inputs/outputs), and read a lot.

I'm currently going through the first stage of simulating an ideal Fabry-Perot cavity (I technically started yesterday, but yesterday's work turned out to be wrong, so fresh start!), and other than yesterday's setback, its going okay.

I attached a screenshot of my simulation of the pitch/pendulum motion of one of the mirrors LIGO uses. The bode plots for this one are turning out a little weird, but I'm fairly certain its just a computational error and can be ignored (as the simulation matlab rendered without the coupling was really accurate - down to a floating point error). I have also attached these bode plots. The first bode is based on the force input, while the second is based on the torque input. It makes sense that there are two resonant frequencies, since there ought to be one per input.

I have moved the summary pages stuff that Duncan set up to a new directory that it accessible to the nodus web server and is therefore available from the outside world:

/users/public_html/40-summary

which is available at:

https://nodus.ligo.caltech.edu:30889/40m-summary/

I updated the scripts, configurations, and crontab appropriately:

/users/public_html/40m-summary/bin/c1_summary_page.sh
/users/public_html/40m-summary/share/c1_summary_page.ini

Mike J. came tonight and he fixed Sensoray (elog #6645). He recompiled it and fixed it.

I made a python wrapper script for Sensoray scripts. It currently lives in /users/yuta/scripts/videocapture.py.
If you run something like
  ./videocapture.py AS
it saves image capture of AS to /users/yuta/scripts/SensorayCapture/ directory with the GPS time.
Below is the example output of AS when MI is aligned. We still see some clipping in the right. This clipping is there when one arm is mis-aligned and clipping moves together with the main beam spot. So, this might be from the incident beam, probably at the Faraday.

Currently, videocapture.py runs only on pianosa, since Sensoray 2253S is connected to pianosa. Also, it can only capture MON4. My script changes MON4 automatically.

I have been working on configuration of the Daily Summary webpages and have been attempting to create a "PSL health" page.  This page will display the PMC power, the temperature on the PSL table and the PSL table microphone levels.  Thus far, I have managed to make the extra PSL tab and configure the graph of the interior temperature, using channel C1:PSL-FSS_RMTEMP.

I have been attempting to make a spectrogram for one of the PMC channels, but there is an issue with the spectrogram setup, as Duncan Macleod noted in ELOG 6686:

"At the moment a package version issue means the spectrogram doesn't work, but the spectrum should. At the time of writing, to use the spectrum simple add 'plot-dataplot2'."

Because of this issue, I have also been trying to make the spectrogram plots work.  Thus far, I have fixed the issue with one of the spectrogram plots, but there are several problems with the other four that I need to address.  I have also been looking at the microphone channels and trying to make the plot for them work.  I checked which microphone was on the PSL table and plotted it in matplotlib to make sure it was working.  However, when I tried to incorporate it into the daily summary pages, the script stops at that point!  It might simply be taking an excessively long time, but I have to figure out why this is the case.

                                                 (I am using channel C1:PEM-MIC_6_IN1_DQ, if this is blatantly wrong, please let me know!!)

The main point of this ELOG is that I have working test-daily summary pages online!  They can be found here:

https://nodus.ligo.caltech.edu:30889/40m-summary-test/archive_daily/20120710/

Also, if anyone has more requests for what they would like to see on the finalized summary pages site, please respond to this post or email me at: endavison@umail.ucsb.edu

Over the past week, I have been focusing on the issues I brought up in my last ELOG,  6956.  I spent quite a while attempting to modify the script and create my own spectrogram function within the existing code.  I also checked out the channels on the PSL table for the PSL health page and produced a spectrogram plot of the PMC reflected, transmitted, and input powers, the PZT Voltage and the laser output power.  When I was entering these channels into the configuration script, I came across an issue with the way the python script parses this.  If there were spaces between the channel names (for example: C1:PSL-PMC_INPUT_DC, C1:PSL-PMC_RFPDDC... etc) the program would not recognize the channels.  I made some alterations to the parsing script such that all white spaces at the beginning and end of the channels were stripped and the program could find them.

 The next thing that I worked on was attempting to see if the microphone channels were actually stopping the program or just taking an extraordinarily long time.  I tried running the program with shorter time samples and that seemed to work quite well!  However, I had to leave it running overnight in order to finish.  I am sure that this difference comes from the fact that the microphone channels are fast channels.  I would like to somehow make it run more quickly, and am thinking about how best to do this.

I finally got my spectrogram function to work after quite a bit of trouble.  There were issues with mismatched data and limit sets that I discovered came from times when only a few frames (one or two) were in one block.  I added some code to  ignore small data blocks  like those and the program works very well now!  It seems like the best way to get the right limits is to let the program automatically set the limits (they are nicely log-scaled and everything) but there are some issues that produce questionable results.  I spent a while adding a colormap option to the script so that the spectrogram colors can be adjusted!  This mostly took so long because, on Monday night, some strange things were happening with the PMC that made the program fail (zeros were being output, which caused an uproar in the logarithmic data limits).  I was incredibly worried about this and thought that I had somehow messed up the script (this happened in the middle of when I was tinkering with the cmap option) so I undid all of my work!  It was only when I realized it was still going on and Masha and Jenne were talking about the PMC issues that I figured out that it was an external issue.  I then went in and set manual limits so that a blank spectrogram and redid everything.

The spectrogram is not operational and the colormap can be customized.  I need to fix the problem with the autoscaled axes (perhaps adding a lower bound?) so that the program does not crash when there is an issue.

Yesterday, I spoke with Rana about what my next step should be.  He advised me to look at ELOGs from Steve (6678) and Koji (6675) about what they wanted to see on the site.  These gave me a good map of what is needed on the site and where I will go next.

I need to find out what is going on with the weather channels and figure out how to calibrate the microphones.  I will also be making sure there are correct units on all of the plots and figure out how to take only a short section of data for the microphone channels.  I have already modified the tab template so that it is similar to Koji's ELOG idea and will be making further changes to the layout of the summary pages themselves.  I will also be working on having the right plots up consistently on the site.

WE tried to use the new conlog today and discovered that:

1) No one at the 40m uses conlog because they don't know that it ever ran and don't know how to use regexp.

2) It has not been running since the last time Megatron was rebooted (probably a power outage).

3) We could not get it to run using the instructions that Syracuse left in our wiki.

Emails are flying.