The summary pages are now online (Daily Summary), and will eventually be found on the 40m Wiki page under "LOGS-Daily Summary". (Currently, the linked website is the former summary page site)

Currently, all of the IFO and Acoustic channels have placeholders (they are not showing the real data yet) and the Weather channels are not working, although the Weather Station in the interferometer room is working (I am looking into this - any theories as to why this is would be appreciated!!).

I am looking for advice on what else to include in these pages.  It would be fantastic if everyone could take a moment to look over what I have so far (especially the completed page from July 23, 2012) and give me their opinions on:

1.  What else you would like to see included

2.  Any specific applications to your area of work that I have overlooked

3.  What the most helpful parts of the pages are

4.  Any ways that I could make the existing pages more helpful

5.  Any other questions, comments, clarifications or suggestions

Finally, are the hourly subplots actually helpful?  It seems to me like they would be superfluous if the whole page were updating every 1-2 hours (as it theoretically eventually will).  These subplots can be seen on the July 24, 2012 page.

My email address is endavison@umail.ucsb.edu.

 Thank you!  

This week, I made several modifications to the Summary page scripts, made preliminary Microphone BLRMS channels and, with Rana's help, got the Weather Station working again. 

I changed the spectrogram and spectrum options in the Summary Pages so that, given the sampling frequency (which is gathered by the program), the NFFT and overlap are calculated internally.  This is an improvement over user-entered values because it saves the time of having to know the sampling frequency for each desired plot.  In addition, I set up another .sh file that can generate summary pages for any given day.  Although this will probably not be useful in the final site, it is quite helpful now because I can go back and populate the pages.  The current summary pages file is called "c1_summary_page.sh" and the one that is set up to get a specific day is called "liz_c1_summary_page.sh".  I also made a few adjustments to the .css file for the webpage so that plots completely show up (they were getting cut off on the edges before) and are easier to see.  I also figured out that the minute and second trend options weren't working because the channel names have to be modified to CHANNEL.mean, CHANNEL.min and CHANNEL.max.  So that is all in working order now, although I'm not sure if I should just use the mean trends or look at all of them (the plots could get crowded if I choose to do this).  Another modification I made to the python summary page script was adding an option to have an image on one of the pages.  This was useful because I can now put requested MEDM screens up on the site.  The image option can be accessed if, in the configuration file, you use "image-" instead of "data-" for the first word of the section header.

I also added a link to the final summary page website on the 40 meter wiki page (my summary page are currently located in the summary-test pages, but they will be moved over once they are more finalized).  I fleshed out the graphs on the summary pages as well, and have useful plots for the OSEM and OPLEV channels.  Instead of using the STS BLRMS channels, I have decided to use the GUR BLRMS channels that Masha made.  I ELOGged about my progress and asked for any advice or recommendations a few days ago (7012) and it would still be great if everyone could take a look at what I currently have up on the website and tell me what they think!  July 22 and 23 are the most finalized pages thus far, so are probably the best to look at.

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

This week, I also tried to fix the problems with the Weather Station, which had not been operational since 2010.  All of the channels on the weather station monitor seemed to be producing accurate data except the rain gauge, so I went on the roof of the Machine Shop to see if anything was blatantly wrong with it.  Other than a lot of dust and spiders, it was in working condition.  I plan on going up again to clean it because, in the manual, it is recommended that the rain collector be cleaned every one to two years...  I also cleared the "daily rain" option on the monitor and set all rain-related things to zero.  Rana and I then traced the cabled from c1pem1 to the weather station monitor, and found that thy were disconnected.  In fact, the connector was broken apart and the pins were bent.  After we reconnected them, the weather station was once again operational!  In order to prevent accidental disconnection in the future, it may be wise to secure this connection with cable ties.  It went out of order again briefly on Tuesday, but I reconnected it and now it is in much sturdier shape!

The most recent thing that I have been doing in relation to my project has been making BLRMS channels for the MIC channels.  With Jenne's assistance, I made the channels, compiled and ran the model on c1sus, made filters, and included the channels on the PEM MEDM screen .  I have a few modifications to make and want to .  One issue that I have come across is that the sampling rate for the PEM system is 2 kHz, and the audio frequencies range all the way up to 20 kHz.  Because of this, I am only taking BLRMS data in the 1-1000 Hz range.  This may be problematic because some of these channels may only show noise (For example, 1-3 and 3-10 Hz may be completely useless).

The pictures below are of the main connections in the Weather Station.  This first is the one that Rana and I connected (it is now better connected and looks like a small beige box), located near the beam-splitter chamber, and the second is the c1pem1 rack.  For more information on the subject, there is a convenient wiki page: https://wiki-40m.ligo.caltech.edu/Weather_Station

The summary pages can now be accessed from the "Daily Summary" link under LOGS on the 40 meter Wiki page.

Over the past week, I have continued refining the summary pages.  They are now online in their final home, and can be easily accessed from the 40 meter Wiki page!  (It can be accessed by the Daily Summary link under "LOGS").  I have one final section to add plots to (the IFO section is currently still only "dummy" plots) but the rest are showing correct data!  I have many edits to make in order for them to be more intelligible, but they are available for browsing if anyone feels so inclined.

I also spent quite a while formatting the pages so that the days are in PDT time instead of UTC time.  This process was quite time consuming and required modifications in several files, but I tracked my changes with git so they are easy to pinpoint.  I also did a bit of css editing and rewriting of a few html generation functions so that the website is more appealing.  (One example of this is that the graphs on each individual summary page are now full sized instead of a third of the size.

This week, I also worked with the BLRMS mic channels I made.  I edited the band pass and low pass filters that I had created last week and made coherence plots of the channels.  I encountered two major issues while doing this.  Firstly, the coherence of the channels decreases dramatically above 40 Hz.  I will look at this more today, but am wondering why it is the case.  If nothing could be done about this, it would render three of my channels ineffective.  The other issue is that the Nyquist frequency is at 1000 Hz, which is the upper limit of my highest frequency channel (300-1000 Hz).  I am not sure if this really affects the channel, but it looks very different from all of the other channels.  I am also wondering whether the channels below 20 Hz are useful at all, or whether they are just showing noise.

The microphone calibration has been something I have been trying to figure out for quite some time, but I recently found a value on the website that makes the EM172 microphones and has a value for their sensitivity.  I determined the transfer factor from this sensitivity as 39.8107 mV/Pa, although I am not sure if all of the mics will be consistent with this.

Previously, medmrun didn't accept arguments to pass along to the script it was going to run.  Jamie has graciously taken a moment from fixing the computer disaster to help me update the medmrun script.

Now the ASS scripts are call-able from the screen.

Please check the summary pages out at the link below and let me know if there are any modifications I should make!  All existing pages are up to date and contain all of the pages I have.

Questions, comments, and suggestions will be appreciated! Contact me at endavison@umail.ucsb.edu

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

Over the past week, I have been working on my progress report and finalizing the summary pages.  I have a few more things to address in the pages (such as starting at 6 AM, including spectrograms where necessary and generating plots for the days more than ~a week ago) but they are mostly finalized.  I added all of the existing acoustic and seismic channels so the PEM page is up to date.  The microphone plots include information about the transfer factor that I found on their information sheet (http://www.primomic.com/).  If there are any plots that are missing or need editing, please let me know!

I also modified the c1_summary_page.sh script to run either the daily plots or current updating plots by taking in an argument in the command line.  It can be run ./c1_summary_page.sh 2012/07/27
 or ./c1_summary_page.sh now to generate the current day's pages.  (Essentially, I combined the two scripts I had been running separately.)  I have been commenting my code so it is more easily understandable and have been working on writing a file that explains how to run the code and the main alterations I made.  The most exciting thing that has taken place this week is that  the script went from taking ~6 hours to run to taking less than 5 minutes.  This was done by using minute trends for all of the channels and limiting the spectrum plot data.

The summary pages for each day now contain only the most essential plots that give a good overview of the state of the interferometer and its environment instead of every plot that is created for that day.

I am waiting for Duncan to send me some spectrogram updates he has made that downsample the timeseries data before plotting the spectrogram.  This will make it run much more quickly and introduce a more viable spectrogram option.

Today's Summary Pages can be accessed by the link on the wiki page or at:

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

Hey, the pages got significantly nicer than before. I will continue to give you comments if I find anything.

So far: There are many 10^-100 in logarithmic plots. Once they are removed, we should be able to see the seismic excitation during these recent earth quakes?

Incidentally, where the script is located? "./" isn't the absolute path description.

I added an indicator to the watch dog screen so that a little "SP" icon appears whenever the SimPlant is on. Since we only have one simplant (ETMX), only ETMX has the simPlant indicator. However, since assymetry is ugly, I moved all of the OL icons over so that they're in a line and so that there is room for future SP icons.

I also fixed the link to the Watchdogs on the main SUS screens (it was dead, but now it is ALIVE).

Over the past week I have been continuing to finalize the daily summary pages, attempting to keep the total run time under half an hour so that they can be run frequently.  I have had many hang ups with the spectrograms and am currently using second trends (with this method, the entire script takes 15 minutes to run).  I also have a backup method that takes 3 minutes of data for every 12 minutes, but could not implement any interpolation correctly.  This might be a future focus, or the summary pages could be configured to run in parallel and full data for the spectrograms can be used.  I configured Steve's tab to include one page of images and one page of plots and fixed the scripts so that it corrects for daylight savings time (at the beginning of the running, the program prints 'DST' or 'Not DST').

Right now, I am focusing on making coherence plots in a spectrogram style (similar to the matlab 'coh_carpet' function) and a spectrogram depicting Gaussianity (similar to the plots made by the RayleighMonitor).  I have also been working on my  final paper and presentation.

I just wrote a short description of how to run the daily summary pages and the configuration process for making changes to the site.  It can be found in /users/public_html/40m-summary and is named README.txt.  If I need to clarify anything, please let me know!  The configuration process should be relatively straightforward, so it will be easy to add plots or change them when there are changes at the 40 meter.

 I noticed that the IFO restore scripts have some problems. They use burt request files to store and restore the settings. However, the request files contain old channel names.

Especially channels with _TRIG_THRES_ON/OFF are now _TRIG_THRESH_ON/OFF, note the extra "H".

These scripts reside in /opt/rtcds/caltech/c1/burt/c1ifoconfigure/.

I fixed the PRMI_SBres and MI scripts. Someone should fix all other files.

 I've noticed that we're experiencing this bug which was previously seen at LHO. We cannot enter 10 digit GPS times into the time fields for DTT due to a limit in TLGEntry.cc, which Jim Batch fixed in September of last year. Seems like we're running an old version of the GDS tools.

I checked the Lidax tool (which you can get from the GDS Mainmenu). It does, in fact, allow 10 digit entries.

Quote:

Raji took the optics over. They were all measured at 0 deg incidence angle, although we will use them at the angles required for the recycling folding mirrors.  Here's the summary from GariLynn: In general all six pieces have a radius of curvature of around -700 meters. They all fall off rapidly past 40 mm diameter.  Within the 40 mm diameter the rms is ~10 nm for most.  I can get finer analysis if you have something specific that you want to know.    All data are saved in Wyko format at the following location: http://www.ligo.caltech.edu/~coreopt/40MCOC/Oct24-2012/ Gari

 After a long search, I've found a way to finally read and analyze(?)  the Wyko opd format data using Image SXM, an image analysis software working only on mac osx.

I am attaching the images (in tiff) and profile plot of all the 6 mirrors.

 Great, however, unless you can save the images in FITS format, we still need another reader for the opd images.

Previous phasemap data and analysis for the new 40m COC are summarized on the following page

https://nodus.ligo.caltech.edu:30889/40m_phasemap/

(Use traditional LVC authentication (not albert.einstein))

The actual instance of the files can also be found on nodus below the following directory:

/cvs/cds/caltech/users/public_html/40m_phasemap

The programs for the analysis are found in

/cvs/cds/caltech/users/public_html/40m_phasemap/40m_PRM/mat

The main program is RunThis.m

Basically this program takes ascii files converted from opd by Vision32.
(i.e. You need to go to Downs)
Then the matlab program takes care of the plots and curvature analyses.

An error this evening on rossa: dataviewer not working due to some font errors:

controls@rossa:~ 0$ dataviewer
Connecting.... done
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning:
    Name: FilterText
    Class: XmTextField
    Character '\52' not supported in font.  Discarded.

Warning:
    Name: FilterText
    Class: XmTextField
    Character '\56' not supported in font.  Discarded.

Warning:
    Name: FilterText
    Class: XmTextField
    Character '\170' not supported in font.  Discarded.

Warning:

etc.............

This is how to post PDF:

From DTT, print the plot as a postscript file.

Then use ps2pdf to make a archival PDF version (the flag is the key!). Example:

ps2pdf -dPDFX /home/controls/Desktop/darm.ps

I fixed the illuminator setup.  ETMY was not hooked up, and the screen wasn't configured quite right.  The ITMX illuminator still needs to be hooked up to the vertex switch.

I made an updated illuminator script that works more like the videoswitch scripts, with a saner interface, and is located here:

/opt/rtcds/caltech/c1/scripts/general/illuminator

I also fixed up the illuminator MEDM interface a bit and added it to the VIDEO screen:

While I was at it, I cleaned up the sitemap a bit:

I hope everyone won't be too confused.

I've added a new program called getdata (to scripts/general/getdata) that will conveniently pull arbitrary data from an NDS server, either DQ or online (ie. testpoints).

Start times and durations may be specified.  If past data is requested, you must of course be requesting DQ channels.  If no start time is specified, data will be pulled "online", in which case you can specify testpoints.

If an output directory is specified, the retrieved data will be stored in that directory in files named after the channels.  If an output directory is not specified, no output will be

Help usage:

controls@pianosa:~ 0$ /opt/rtcds/caltech/c1/scripts/general/getdata --help
usage: getdata [-h] [-s START] [-d DURATION] [-o OUTDIR] channel [channel ...]

Pull online or DQ data from an NDS server. Use NDSSERVER environment variable
to specify host:port.

positional arguments:
  channel               Acquisition channel. Multiple channels may be
                        specified acquired at once.

optional arguments:
  -h, --help            show this help message and exit
  -s START, --start START
                        GPS start time. If omitted, online data will be
                        fetched. When specified must also specify duration.
  -d DURATION, --duration DURATION
                        Length of data to acquire.
  -o OUTDIR, --outdir OUTDIR
                        Output directory. Data from each channel stored as
                        '.txt'. Any existing data files will be
                        automatically overwritten.
controls@pianosa:~ 0$ 

I have uploaded ARBCAV v3.0 to the SVN. The major change in this release, as I mentioned, is the input/output handling. The input and output are now contained in a single 'model' structure. To define the cavity, you fill in the substructure 'model.in' (e.g., model.in.T = [0.01 10e-6 0.01]; etc.) and call the function as:

model = arbcav(model);

Note: the old syntax is maintained as legacy for back-compatibility, and the function automatically creates a ".in" substructure in the output, so that the user can still use the single-line calling, which can be convenient. Then, any individual parameter can be changed by changing the appropriate field, and the function can be rerun using the new, simpler syntax from then on.

The function then somewhat intelligently decides what to compute based on what information you give it. Using a simple option string as a second argument, you can choose what you want plotted (or not) when you call. Alternatively, you can program the desired functionality into a sub-substructure 'model.in.funct'.

The outputs are created as substructures of the output object. Here is an example:

>> th = 0.5*acos(266/271) *180 /pi;

OMC.in.theta = [-th -th th th];

OMC.in.L = [0.266 0.284 0.275 0.271];

OMC.in.RoC = [1e10 2 1e10 2];

OMC.in.lambda = 1064e-9;

OMC.in.T = 1e-6 * [8368 25 8297 33];

OMC.in.f_mod = 24.5e6;

>> OMC

OMC = 

    in: [1x1 struct]

>> OMC = arbcav(OMC,'noplot')

Warning: No loss given--assuming lossless mirrors 

> In arbcav at 274 

OMC = 

         in: [1x1 struct]

        FSR: 2.7353e+08

        Lrt: 1.0960

    finesse: 374.1568

    buildup: 119.6956

         df: [1000x1 double]

      coefs: [1000x4 double]

        HOM: [1x1 struct]

>> OMC.HOM

ans = 

      f: [1x1 struct]

    pwr: [1x1 struct]

>> OMC.HOM.pwr

ans = 

    carr: [15x15 double]

     SBp: [15x15 double]

     SBm: [15x15 double]

Some other notes:

• The annoying Mdo.m has been internalized; it is no longer needed.
• For the next release, I am working on including:
  • Finite mirror thickness/intracavity refractive elements - If, for god knows what reason, you decide to put a mirror substrate within a cavity 
  • Mode overlap - Calculating the overlap of an input beam to the cavity
  • Mode matching - Calculating a mode matching telescope into the cavity for some defined input beam
  • Anything else?

I have added lots of information to the help header, so check there for more details. As always, your feedback is greatly appreciated.

I updated the getdata script so that it can now handle downloading long stretches of data.

  /opt/rtcds/caltech/c1/scripts/general/getdata

It now writes the data to disk incrementally while it's downloading from the server, so it doesn't fill up memory.

I also added a couple new options:

* --append allows for appending to existing data files

* --noplot suppresses plotting during download

I released/updated my secret scripts to real scripts directory.
I checked they run correctly (but maybe not working correctly).


burtlookup.py
  in ./scripts/general/burtlookup.py

  It returns a value of a specified channel in the past using burt snapshots.
  Help is available.


GRtoggler.py
  in ./scripts/ALS/GRtoggler.py

  Toggles green shutter until it locks TEM00.
  Help is available. Threshold setting is critical.


MCbeeper.py
  in ./scripts/MC/MCbeeper.py

  Beeps when MC is unlocked.


yutalib.py
  in ./scripts/pylibs/yutalib.py

  Python library for data loading, saving and plotting.
  I think it's well commented.


pyezcalib.py
  in ./scripts/pylibs/pyezcalib.py

  Python library for ezca stuff.
  It has functions for recording and resetting default channel values in case of interrupt.


./scripts/PRCmodescan
  Python scripts for PRC modescan. Not well commented. Not organized.
  See elog #8012


./scripts/Alignment
  Python and shell scripts for alignment work. Not well commented.
  See elog #8164


./scripts/SUS/OplevCalibration
  Python scripts for oplev calibration. Not well commented.
  See elog #8221


./scripts/dither/gfactormeasurement
  Python scripts for g-factor measurement. Not well commented.
  See elog #8230


./scripts/SUS/ActuatorCalib
  Python scripts for calibrating actuators. Not well commented.
  See elog #8242

To aid in lock-loss studies, I made a new program called 'lookback', similar to 'getdata', to look at past data.

When called with channel name arguments, it runs continuously, storing all channel data in a ring buffer.  When the user hits Ctrl-C, all the data in the ring buffer is displayed.  There is an option to store the data in the ring buffer to disk as well.

controls@rosalba:/opt/rtcds/caltech/c1/scripts/general 0$ ./lookback -h
usage: lookback [-h] [-l LENGTH] [-o OUTDIR] channel [channel ...]

Lookback on testpoint data. The specified amount of data is stored in a ring
buffer. When Ctrl-C is hit, all data in the ring buffer is plotted. Both 'DQ'
and 'online' test point data is available. Use NDSSERVER environment variable
to specify host:port.

positional arguments:
  channel               Acquisition channel. Multiple channels may be
                        specified and acquired at once.

optional arguments:
  -h, --help            show this help message and exit
  -l LENGTH, --lookback LENGTH
                        Lookback time in seconds. This amount of data will be
                        stored in a ring buffer, and plotted on Ctrl-C.
                        Default is 10 seconds
  -o OUTDIR, --outdir OUTDIR
                        Output directory to write data (will be created if it
                        doesn't exist). Data from each channel stored as
                        '<channel>.txt'. Any existing data files will be
                        overwritten.
controls@rosalba:/opt/rtcds/caltech/c1/scripts/general 0$ 

We talked about the thing that watches the scripts for autolocking during the meeting today.

I've resurrected the Perl-Tk GUI that we used through i/eLIGO for watching the IFO and running the appropriate scripts. This is not meant to be a replacement for aLIGO stuff, but just something to get us going for now. I expect that we will make some new fanciness which will eclipse this, but I brought it back so that we don't start off with some 'Advanced' system which is worse than the old one.

You can run it from scripts/c1/ by typing ./AutoRUN.pl. It pops up the GUI and starts in a Disabled mode where it watches and does nothing.

I have done some editing of the GUI's code so that it uses caget / caput instead of ezca binaries. New stuff is in the SVN.

Next up is to start testing it and fixing it up so that it uses the thresholds set in the LSC screens rather than some hardcoded values.

Eventually we should also convert all of its daughter scripts from tcsh to bash to keep Jamie's blood pressure in the low hundreds...

I did a bunch of cleanup work on the netGPIB stuff:

• Removed extensions from all executable scripts (executables should not have language extensions)
• fixed execution permissions on executables and modules
• committed HP8590.py and HP3563A.py instrument modules, which were there but not included in the svn
• committed NWAG4395A (was AG4395A_Run.py) to svn, and removed old "custom" copies (bad people!)
• cleaned up, modernized, and fixed the netgpibdata program
• removed plotting from netgpibdata, since it was only available for one instrument, there's already a separate program to handle it, and it's just plotting the saved data anyway
• added a netgpibcmd program for sending basic commands to instruments.
• added a README

Probably the most noticeable change is removing the extensions from the executables.   There seems to be this bad habit around here of adding extensions to executables.  It doesn't matter to the person running the program what language it was written in, so don't add extensions.  It only matters for libraries.

There are a lot of changes to the ASS stuff that have not been committed to the SVN:

controls@rossa:/opt/rtcds/userapps/release/isc/c1 0$ svn status | grep -v '?'
M       medm/c1als/C1ALS_X_SLOW.adl
D       medm/c1ass/C1ASS_TRY_YAW_LOCKIN.adl
D       medm/c1ass/ASS_SERVOS.adl
D       medm/c1ass/ctrl_yaw_mtrx.adl
D       medm/c1ass/C1ASS_QPDS.adl
D       medm/c1ass/C1ASS_SEN_YAW_MTRX.adl
M       medm/c1ass/C1ASS_XARM_SEN_MTRX.adl
D       medm/c1ass/SITEMODEL_LOCKINNAME.adl
D       medm/c1ass/C1ASS_TRX_YAW_LOCKIN.adl
D       medm/c1ass/C1ASS_LOCKIN1.adl
D       medm/c1ass/C1ASS_LOCKIN2.adl
D       medm/c1ass/C1ASS_LOCKIN3.adl
D       medm/c1ass/C1ASS_LOCKIN4.adl
D       medm/c1ass/C1ASS_LOCKIN5.adl
D       medm/c1ass/C1ASS_LOCKIN6.adl
D       medm/c1ass/C1ASS_LOCKIN7.adl
D       medm/c1ass/C1ASS_LOCKIN8.adl
D       medm/c1ass/C1ASS_LOCKIN9.adl
D       medm/c1ass/C1ASS_REFL11I_PIT_LOCKIN.adl
M       medm/c1ass/C1ASS.adl
D       medm/c1ass/C1ASS_LOCKIN10.adl
D       medm/c1ass/C1ASS_LOCKIN11.adl
D       medm/c1ass/C1ASS_LOCKIN12.adl
D       medm/c1ass/C1ASS_LOCKIN13.adl
D       medm/c1ass/C1ASS_LOCKIN14.adl
D       medm/c1ass/C1ASS_LOCKIN15.adl
D       medm/c1ass/sen_yaw_mtrx.adl
D       medm/c1ass/C1ASS_LOCKIN16.adl
D       medm/c1ass/C1ASS_LOCKIN17.adl
D       medm/c1ass/C1ASS_DOF_YAW.adl
D       medm/c1ass/C1ASS_LOCKIN18.adl
D       medm/c1ass/C1ASS_LOCKIN19.adl
D       medm/c1ass/C1ASS_TRY_PIT_LOCKIN.adl
D       medm/c1ass/ctrl_pit_mtrx.adl
D       medm/c1ass/C1ASS_SEN_PIT_MTRX.adl
D       medm/c1ass/C1ASS_LOCKIN20.adl
D       medm/c1ass/C1ASS_LOCKIN21.adl
D       medm/c1ass/C1ASS_LOCKIN22.adl
D       medm/c1ass/C1ASS_LOCKIN23.adl
D       medm/c1ass/C1ASS_LOCKIN24.adl
D       medm/c1ass/C1ASS_LOCKIN25.adl
D       medm/c1ass/C1ASS_LOCKIN26.adl
D       medm/c1ass/C1ASS_LOCKIN27.adl
D       medm/c1ass/C1ASS_TRX_PIT_LOCKIN.adl
D       medm/c1ass/C1ASS_LOCKIN28.adl
D       medm/c1ass/C1ASS_LOCKIN29.adl
D       medm/c1ass/C1ASS_XARM_QPDS.adl
D       medm/c1ass/C1ASS_YARM_QPDS.adl
M       medm/c1ass/C1ASS_XARM_OUT_MTRX.adl
D       medm/c1ass/ASS_SEN_MTRX.adl
D       medm/c1ass/ASS_LOCKINS.adl
D       medm/c1ass/sen_pit_mtrx.adl
D       medm/c1ass/C1ASS_REFL11I_YAW_LOCKIN.adl
D       medm/c1ass/C1ASS_LOCKIN30.adl
D       medm/c1ass/C1ASS_DOF_PIT.adl
M       models/c1ass.mdl
controls@rossa:/opt/rtcds/userapps/release/isc/c1 0$

I cleaned up a bunch of conlog stuff to make it all a little more sane and simple.  I also fixed the messy startup shenanigans, so that it should now start up sanely and on it's own (using Ubuntu's native upstart system).  The conlog wiki page was updated with all the new info.

 By the way, I also did confirm that it is running and registering EPICS changes.

 Something has happened that all of the C1:LSC-dof_NORM_SQRT_ENABLEs are disabled, but normally some are enabled and others are not.

In the hopes that miraculously this change happened after Jamie restarted the conlog this afternoon, I checked the conlog.  These channels, however, were not recorded. 

Using the instructions on the conlog wiki page, I added the _MON channels to the conlog list.  The one snag I hit was that the medm screen referred to in the wiki isn't usable if you open it by hand using the medm gui, since it needs to know what IFO you're at to fill in the macro expansion variables.  To remedy this, I changed the "FE STATUS" button on the sitemap to "CDS", and added the conlog screen to the list of options.  

Now I see that the conlog at least knows about these channels, for future reference.

I moved the old matlab directory from /cvs/cds/caltech/apps/linux64/matlab_o to /cvs/cds/caltech/apps/linux64/matlab_oo

and moved the previously current matlab dir from /cvs/cds/caltech/apps/linux64/matlab to /cvs/cds/caltech/apps/linux64/matlab_o.

And have installed the new Matlab 2013a into /cvs/cds/caltech/apps/linux64/matlab.

Since I'm not sure how well the new Matlab/Simulink plays with the CDS RCG, I've left the old one and we can easily revert by renaming directories.

I installed ligoDV in the /ligo/apps/ligoDV/

Now, by pointing the tool at the local NDS2 server (megatron:31200) you can access the recent local data (raw, trends, etc.)

by running /ligo/apps/ligoDV/ligodv from the command line.

Be careful with this.  If Matlab starts re-saving models in a new file format that is unreadable by the RCG, then we won't be able to rebuild models until we do an svn revert.  Or the bigger danger, that the RCG *thinks* it reads the file and generates code that does something unexpected.

Of course this all may be an attempt to drive home the point that we need an RCG test suite.

I was receiving missing path error when I was trying to measure the MC spot positions. Jenne pointed out that Koji had moved all the unused scripts in scripts/ASS to /scripts/ASS/OBSOLETE yesterday and in the process one of the scripts that the MC spot position measurement script calls for (MeasureSpotPositions.py) must have also been moved to the OBSOLETE directory. I moved the script to /scripts/ASS/MC so that we know the script is being used and also changed its path in the main script.

JoeB and JamieR are working somewhat coherently on a set of python libraries to fulfill all of our command line CDS wants. This is being done mostly to satisfy The Guardian and the SkunkTools project.

I did an 'svn up' in /opt/rtcds/userapps (it might finish in ~1000 years) to get the things that they have so far (in particular, Joe's 'pyavg'). There's going to be some issues since the pylib stuff written by Yuta/Kiwamu has never been integrated with anything and is imported as 'epics' in many python scripts. As we move over to the new stuff there will be a lot of broken script functions since the new libraries are also used in that way.

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.

Although Matlab 2013 has not been causing any visible trouble so far, it takes a while to startup.

I have added alias 'ml10' to bash to start Matlab 2010 from the terminal for convenience.

[From yesterday] ASS for X arm was behaving slightly funny over the last couple of days. ASS could not correct the BS misalignment. Jenne pointed out that the LSC output matrix on the ASS medm screen set itself to zeroes whenever we ran the ASS_dither_ON script. I checked the burt request file: ASS_DITHER_ON.req  in /opt/rtcds/caltech/c1/scripts/ASS and found that the LSC output matrix channels were not added to it. I added these channels for both the X and Y arm. Following this, I also edited the corresponding snap file as well. This should now set the LSC matrix to the right values everytime we run the script.

Chris Wipf has been developing a new Noise Budget code that allows us to use our existing Simulink models to handle all of the noise transfer functions. This is mainly by being clever about avoiding the numerical pitfalls that we encounter when doing linearization of Simulink models (e.g. linmod or linmod2).

In this model, the optical plant is done with analytic TFs using the formulae from the Sigg Frequency Response doc. The big Orange block has just the DAC and some simple pendulum TFs. The upper section contains the simulated digital system: input matrix, digital filter TFs, and output matrix. The digital filters are just based on my memory of iLIGO. The CARM path is made to be fast to approximate the high gain of the Common Mode servo. Without this high gain the PRC optical plant is unstable due to the right half plane zeros. This simple model is used just so that we could see the NB work on a multi-loop system. For the next steps of getting it to work for the 40m, we will use the Optickle TFs instead of analytic functions and also load the digital filters directly from the FOTON files. For the LLO DRMI, we'll add some simplified version of the SUS Simulink models for triples and quads.

Yesterday, Nic and I took my old iLIGO IFOmodel.mdl Simulink model and added the new NB hooks that allowed us to use the new code. The screenshot below is from a run of this code:

1) Figure 1 shows the DARM Noise budget. So far we have included shot noise in DARM, CARM, MICH, & PRC. Radiation pressure noise on the ITMs and ETMs. Coating thermal noise on all mirrors.

2) Figure 2 shows the breakdown of how each of the shot noises at each port couple to the DARM readout. The RED trace is the AS port DC readout shot noise. The GREEN trace is the MICH shot noise feeding through the MICH loop and being mostly cancelled by the scalar MICHdamp feedforward path.

3) Figure 3 shows that we've set the coating thermal noise to be equal on all 4 TMs.

4) Figure 78754 is a set of Bode plots of the open loop gains of the 4 LSC loops (inferred from the closed loop TF). Also plotted is the residual MICH2DARM TF (with the MICHdamp cancellation path ON).

5) Figure 9911123 are the step responses of the LSC loops: step inserted at the error point and response measured just after the excitation point.

The editor window on the left shows how simple the NB code is to use once the Simulink model has had all the hooks added to it.

Comsol 4.3b is now installed under /cvs/cds/caltech/apps/linux64/COMSOL43b. I've left the existing Comsol 4.2 installation alone; according to the Comsol installation guide [PDF], it is unaffected by the new install. On megatron I've made a symlink so that you can call comsol in bash to start Comsol 4.3b.

The first time I ran comsol server, it asked me to choose a username/password combo, so I made it the same as the combo used to log on to megatron.

Edit: I've also added a ~/.screenrc on megatron (based on this Stackoverflow answer) so that I don't constantly go nuts trying to figure out if I'm already inside a screen session.

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.

 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 

 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 

 I properly installed the python-pyepics package on all the workstations, so this should be working now.

And for posterity, the pyepics source is at:

  pianos:/home/controls/src/pyepics

From this debian packages were built:

  controls@pianosa:~/src/pyepics 0$ debuild -uc -us

The .deb was then moved into the /ligo/apps/deb nfs:

  controls@pianosa:~/src 0$ cp python-pyepics_*_all.deb /ligo/apps/debs/pyepics/

It was then installed on the various workstations:

  controls@rosalba:~ 0$ sudo dpkg -i /ligo/apps/debs/pyepics/python-pyepics*.deb

This will probably need to be repeated any time we upgrade the EPICS install.

 In May of 2013 Den wrote a PMC Autolocker because he ignored / didn't want to read anyone else's code. Later that year Yuta also wrote another one from scratch for the same reasons.

I tried to use both today, but neither one runs. Yuta's one doesn't run because he was using a bunch of private yuta library stuff in the yuta directory. That kind of programming style is pretty useless for us since it never works after some time.

So I re-activated and tested the PMCAutolock bash script (it is actually a symbolic link called "PMCAutolock" which points to AutoLock.sh). These scripts are all basically the same:

They turn off the loop (or turn down the gain) and then scan the PZT, look for a resonance, and then activate the loop.

One problem with the logic has been that turning off the loop makes the gain so low that the peak flashes by too fast. But leaving the loop ON and just sweeping with the gain turned down to -10 dB is also not good. That only reduces the UGF from 1 kHz to ~100 Hz. What we want is more like a 10 Hz UGF while scanning the length. SO, I edited the script to turn down the modulation depth on the EOM by that factor. After acquiring lock, it returns all settings to the nominal levels as defined on the PSL_SETTINGS screen.

I've tested it a few times and it seems to work OK. You can run it from the yellow shabang button on the PMC screen.

I also changed the .bashrc aliases for the MEDM command so that if you type medm_good at the command line you get MEDM screens with scalable fonts. So you can stretch the screens.

I used a script (~PSL/PMC/testAutoLocker.sh) to unlock the PMC and run autlocker ~100 times to see how robust the new autlocker is.

It failed to grab it 2 out of 137 times. During those times it just went on trying to ramp the PZT even after it had gone to a rail. Once someone resurrects Rob's 'trianglewave'  script we should be OK. Even so, I think this is good enough. Please try this out via the yellow button next time the PMC needs to be locked.

It usually takes 10-30 seconds to lock, depending upon where the fringe is compared to the upper voltage rail. Good enough.

Ottavia, Rossa  and Pianosa are running out of storage  space.

Message on 'pianosa':

Failed to fetch http://ppa.launchpad.net/drgraefy/nds2-client/ubuntu/dists/lucid/main/binary-amd64/Packages.gz  404  Not Found

Sorry, that was an experiment to see if I could set up a general-use repository for the NDS packages.  I've removed it, and did an update/upgrade.

The upgrade of megatron broke the nds2 service. I have fixed things by

  1) installing the latest version of framecpp (1.19.32) from the lsc debian repository (this was necessary because I couldn't link to the existing version)

  2) built nds2-server-0.5.11 and installed it in the system directories (/usr/bin)

  3) there were a few scripts/links/etc that didn't seem to be set up correctly and I fixed them to correspond with my preious message.

 nds2 is now running and the channel list should be updated regularly and the service restarted as appropriate.