40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 314 of 339  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  8201   Thu Feb 28 14:19:20 2013 Max HortonUpdateSummary PagesMultiprocessing Implementation

Okay, more memory would definitely be good.  I don't think I have been using MEDM (which Jamie tells me is the controls interface) so making a cronjob would probably be a good idea.

  8218   Mon Mar 4 10:41:18 2013 Max HortonUpdateSummary PagesMultiprocessing Implementation

Update:

Upon investigation, the other methods besides process_data() take almost no time at all to run, by comparison.  The process_data() method takes roughly 2521 seconds to run using Multiprocessing with eight threads.  After its execution, the rest of the program only takes 120 seconds to run.  So, since I still need to restructure the code, I won't bother adding multiprocessing to these other methods yet, since it won't significantly improve speed (and any improvements might not be compatible with how I restructure the code).  For now, the code is just about as efficient as it can be (in terms of multiprocessing).  Further improvements may or may not be gained when the code is restructured.

  8227   Mon Mar 4 21:05:49 2013 Max HortonUpdateSummary PagesMultiprocessing and Crontab

Multiprocessing:  In its current form, the code uses multiprocessing to the maximal extent possible.  It takes roughly 2600 seconds to run (times may vary depending on what else megatron is running, etc.).  Multiprocessing is only used on the process_data() function calls, because this by far takes the longest.  The other function calls after the process_data() calls take a combined ~120 seconds.  See http://nodus.ligo.caltech.edu:8080/40m/8218 for details on the use of Multiprocessing to call process_data().

Crontab:  I also updated the crontab in an attempt to fix the problem where data is only displayed until 5PM.  Recall that previously (http://nodus.ligo.caltech.edu:8080/40m/8098) I found that the crontab wasn't even calling the summary_pages.py script after 5PM.  I changed it then to be called at 11:59PM, which also didn't work because of the day change after midnight.

I decided it would be easiest to just call the function on the previous day's data at 12:01AM the next day.  So, I changed the crontab.

Previous Crontab:

59 5,11,17,23 * * * /users/public_html/40m-summary/bin/c1_summary_page.sh 2>&1

New Crontab:

0 6,12,18 * * * /users/public_html/40m-summary/bin/c1_summary_page.sh 2>&1
1 0 * * * /users/public_html/40m-summary/bin/c1_summary_page.sh $(date "+%Y/%m/%d" --date="1 days ago") 2>&1

For some reason, as of 9:00PM today (March 4, 2013) I still don't see any data up, even though the change to the crontab was made on February 28.  Even more bizarre is the fact that data is present for March 1-3.  Perhaps some error was introduced into the code somehow, or I don't understand how crontab does its job.  I will look into this now.

Next:

Once I fix the above problem, I will begin refactoring the code into different well-documented classes.

  8273   Mon Mar 11 22:28:30 2013 Max HortonUpdateSummary PagesFixing Plot Limits

Quick Note on Multiprocessing:  The multiprocessing was plugged into the codebase on March 4. Since then, the various pages that appear when you click on certain tabs (such as the page found here: https://nodus.ligo.caltech.edu:30889/40m-summary/archive_daily/20130304/ifo/dc_mon/ from clicking the 'IFO' tab) don't display graphs.  But, the graphs are being generated (if you click here or here, you will find the two graphs that are supposed to be displayed).  So, for some reason, the multiprocessing is preventing these graphs from appearing, even though they are being generated.  I rolled back the multiprocessing changes temporarily, so that the newly generated pages look correct until I find the cause of this.

Fixing Plot Limits:  The plots generated by the summary_pages.py script have a few problems, one of which is: the graphs don't choose their boundaries in a very useful way.  For example, in these pressure plots, the dropout 0 values 'ruin' the graph in the sense that they cause the plot to be scaled from 0 to 760, instead of a more useful range like 740 to 760 (which would allow us to see details better).

The call to the plotting functions begins in process_data() of summary_pages.py, around line 972, with a call to plot_data().  This function takes in a data list (which represents the x-y data values, as well as a few other fields such as axes labels).  The easiest way to fix the plots would be to "cleanse" the data list before calling plot_data().  In doing so, we would remove dropout values and obtain a more meaningful plot.

To observe the data list that is passed to plot_data(), I added the following code:

      # outfile is a string that represents the name of the .png file that will be generated by the code.
      print_verbose("Saving data into a file.")
      print_verbose(outfile)
      outfile_mch = open(outfile + '.dat', 'w')

      # at this point in process_data(), data is an array that should contain the desired data values.
      if (data == []):
          print_verbose("Empty data!")
      print >> outfile_mch, data
      outfile_mch.close()

When I ran this in the code midday, it gave a human-readable array of values that appeared to match the plots of pressure (i.e. values between 740 and 760, with a few dropout 0 values).  However, when I let the code run overnight, instead of observing a nice list in 'outfile.dat', I observed:

[('Pressure', array([  1.04667840e+09,   1.04667846e+09,   1.04667852e+09, ...,
         1.04674284e+09,   1.04674290e+09,   1.04674296e+09]), masked_array(data = [ 744.11076965  744.14254761  744.14889221 ...,  742.01931356  742.05930208
  742.03433228],
             mask = False,
       fill_value = 1e+20)
)]

I.e. there was an ellipsis (...) instead of actual data, for some reason.  Python does this when printing lists in a few specific situations.  The most common of which is that the list is recursively defined.  For example:

INPUT:
a = [5]
a.append(a)
print a

OUTPUT:
[5, [...]]

It doesn't seem possible that the definitions for the data array become recursive (especially since the test worked midday).  Perhaps the list becomes too long, and python doesn't want to print it all because of some setting.

Instead, I will use cPickle to save the data.  The disadvantage is that the output is not human readable.  But cPickle is very simple to use.  I added the lines:

      import cPickle
      cPickle.dump(data, open(outfile + 'pickle.dat', 'w'))

This should save the 'data' array into a file, from which it can be later retrieved by cPickle.load().

Next:
There are other modules I can use that will produce human-readable output, but I'll stick with cPickle for now since it's well supported.  Once I verify this works, I will be able to do two things:
1) Cut out the dropout data values to make better plots.
2) When the process_data() function is run in its current form, it reprocesses all the data every time.  Instead, I will be able to draw the existing data out of the cPickle file I create.  So, I can load the existing data, and only add new values.  This will help the program run faster.

  8286   Wed Mar 13 15:30:37 2013 Max HortonUpdateSummary PagesFixing Plot Limits

Jamie has informed me of numpy's numpy.savetxt() method, which is exactly what I want for this situation (human-readable text storage of an array).  So, I will now be using:

      # outfile is the name of the .png graph.  data is the array with our desired data.
      numpy.savetxt(outfile + '.dat', data)

to save the data.  I can later retrieve it with numpy.loadtxt()

  8414   Thu Apr 4 13:39:12 2013 Max HortonUpdateSummary PagesGraph Limits

Graph Limits: The limits on graphs have been problematic.  They often reflect too large of a range of values, usually because of dropouts in data collection.  Thus, they do not provide useful information because the important information is washed out by the large limits on the graph.  For example, the graph below shows data over an unnecessarily large range, because of the dropout in the 300-1000Hz pressure values.

Time series data from frames

The limits on the graphs can be modified using the config file found in /40m-summary/share/c1_summary_page.ini.  At the entry for the appropriate graph, change the amplitude-lim=y1,y2 line by setting y1 to the desired lower limit and y2 to the desired upper limit.  For example, I changed the amplitude limits on the above graph to amplitude-lim=.001,1, and achieved the following graph.

Time series data from frames

The limits could be tightened further to improve clarity - this is easily done by modifying the config file.  I modified the config file for all the 2D plots to improve the bounds.  However, on some plots, I wasn't sure what bounds were appropriate or what range of values we were interested in, so I will have to ask someone to find out.

Next:  I now want to fix all the funny little problems with the site, such as scroll bars appearing where they should not appear, and graphs only plotting until 6PM.  In order to do this most effectively, I need to restructure the code and factor it into several files.  Otherwise, the code will not only be much harder to edit, but will become more and more confusing as I add on to it, compounding the problems that we currently have (i.e. that this code isn't very well documented and nobody knows how it works).  We need lots of specific documentation on what exactly is happening before too many changes are made.  Take the config files, for example.  Someone put a lot of work into them, but we need a README specifying which options are supported for which types of graphs, etc.  So we are slowed down because I have to figure out what is going on before I make small changes.

To fix this, I will divide the code into three main sectors.  The division of labor will be:
- Sector 1: Figure out what the user wants (i.e. read config files, create a ConfigParser, etc...)
- Sector 2: Process the data and generate the plots based on what the user wants
- Sector 3: Generate the HTML

  8476   Tue Apr 23 15:02:19 2013 Max HortonUpdateSummary PagesImporting New Code

Duncan Macleod (original author of summary pages) has an updated version that I would like to import and work on.  The code and installation instructions are found below.

I am not sure where we want to host this.  I could put it in a new folder in /users/public_html/  on megatron, for example.  Duncan appears to have just included the summary page code in the pylal repository.  Should I reimport the whole repository?  I'm not sure if this will mess up other things on megatron that use pylal.  I am working on talking to Rana and Jamie to see what is best.

http://www.lsc-group.phys.uwm.edu/cgit/lalsuite/tree/pylal/bin/pylal_summary_page
https://www.lsc-group.phys.uwm.edu/daswg/docs/howto/lal-install.html
  8496   Fri Apr 26 15:50:48 2013 Max HortonUpdateSummary PagesImporting New Code

 

I am following the instructions here:

https://www.lsc-group.phys.uwm.edu/daswg/docs/howto/lal-install.html#test

But there as an error when I run the ./00boot command near the beginning.  I have asked Duncan Macleod about this and am waiting to hear back.

For now, I am putting things into /home/controls on allegra.  My understanding is that this is not shared, so I don't have a chance of messing up anyone else's work.  I have been moving slow and being extra cautious about what I do because I don't want to accidentally nuke anything.

  8504   Mon Apr 29 15:35:31 2013 Max HortonUpdateSummary PagesImporting New Code

 

 I installed the new version of LAL on allegra.  I don't think it has interfered with the existing version, but if anyone has problems, let me know.  The old version on allegra was 6.9.1, but the new code uses 6.10.0.1.  To use it, add . /opt/lscsoft/lal/etc/lal-user-ench.sh to the end of the .bashrc file (this is the simplest way, since it will automatically pull the new version).

I am having a little trouble getting some other unmet dependencies for the summary pages such as the new lalframe, etc.  But I am working on it.

Once I get it working on allegra and know that I can get it without messing up current versions of lal, I will do this again on megatron so I can test and edit the new version of the summary pages.

  8523   Thu May 2 14:14:10 2013 Max HortonUpdateSummary PagesImporting New Code

 

 LALFrame was successfully installed.  Allegra had unmet dependencies with some of the library tools.  I tried to install LALMetaIO, but there were unmet dependencies with other LSC software.  After updating the LSC software, the problem has persisted.  I will try some more, and ask Duncan if I'm not successful.

Installing these packages is rather time consuming, it would be nice if there was a way to do it all at once.

  8536   Tue May 7 15:09:38 2013 Max HortonUpdateSummary PagesImporting New Code

 

 I am now working on megatron, installing in /home/controls/lal.  I am having some unmet dependency issues that I have asked Duncan about.

  8572   Tue May 14 16:14:47 2013 Max HortonUpdateSummary PagesImporting New Code

I have figured out all the issues, and successfully installed the new versions of the LAL software.  I am now going to get the summary pages set up using the new code.

  11411   Tue Jul 14 16:47:18 2015 EveUpdateSummary PagesSummary page updates continue during upgrade

I've continued to make changes to the summary pages on my own environment, which I plan on implementing on the main summary pages when they are back online.

 

Motivation:

I created my own summary page environment and manipulated data from June 30 to make additional plots and change already existing plots. The main summary pages (https://nodus.ligo.caltech.edu:30889/detcharsummary/ or https://ldas-jobs.ligo.caltech.edu/~max.isi/summary/) are currently down due to the CDS upgrade, so my own summary page environment acts as a temporary playground to continue working on my SURF project. My summary pages can be found here (https://ldas-jobs.ligo.caltech.edu/~eve.chase/summary/day/20150630/); they contian identical plots to the main summary pages, except for the Summary tab. I'm open to suggestions, so I can make the summary pages as useful as possible.

 

What I did:

  • SUS OpLev: For every already existing optical lever timeseries, I created a corresponding spectrum, showing all channels present in the original timeseries. The spectra are now placed to the right of their corresponding timeseries. I'm still playing with the axes to make sure I set the best ranges.
  • SUSdrift: I added two new timeseries, DRMI SUS Pitch and DRMI SUS Yaw, to add to the four already-existing timeseries in this tab. These plots represent channels not previously displayed on the summary pages
  • Minor changes
    • Added axis labels on IOO plot 6
    • Changes axis ranges of IOO: MC2 Trans QPD and IOO: IMC REFL RFPD DC
    • Changes axis label on PSL plot 6

 

Results:

So far, all of these changes have been properly implemented into my personal summary page environment. I would like some feedback as to how I can improve the summary pages.

 

 

  11414   Tue Jul 14 17:14:23 2015 EveSummarySummary PagesFuture summary pages improvements

Here is a list of suggested improvements to the summary pages. Let me know if there's something you'd like for me to add to this list!

  • A lot of plots are missing axis labels and titles, and I often don't know what to call these labels. I could use some help with this.
  • Check the weather and vacuum tabs to make sure that we're getting the expected output. Set the axis labels accordingly. 
  • Investigate past periods of missing data on DataViewer to see if the problem was with the data requisition process, the summary page production process, or something else.
  • Based on trends in data over the past three months, set axis ranges accordingly to encapsulate the full data range.
  • Create a CDS tab to store statistics of our digital systems. We will use the CDS signals to determine when the digital system is running and when the minute trend is missing. This will allow us to exclude irrelevant parts of the data.
  • Provide duty ratio statistics for the IMC.
  • Set triggers for certain plots. For example, for channels C1:LSC-XARM OUT DQ and page 4 LIGO-T1500123–v1 C1:LSC-YARM OUT DQ to be plotted in the Arm LSC Control signals figures, C1:LSCTRX OUT DQ and C1:LSC-TRY OUT DQ must be higher than 0.5, thus acting as triggers.
  • Include some flag or other marking indicating when data is not being represented at a certain time for specific plots.
  • Maybe include some cool features like interactive plots.
  11437   Wed Jul 22 22:06:42 2015 EveSummarySummary PagesFuture summary pages improvements

- CDS Tab

We want to monitor the status of the digital control system.

1st plot
Title: EPICS DAQ Status
I wonder we can plot the binary numbers as statuses of the data acquisition for the realtime codes.
We want to use the status indicators. Like this:
https://ldas-jobs.ligo-wa.caltech.edu/~detchar/summary/day/20150722/plots/H1-MULTI_A8CE50_SEGMENTS-1121558417-86400.png

channels:
C1:DAQ-DC0_C1X04_STATUS
C1:DAQ-DC0_C1LSC_STATUS
C1:DAQ-DC0_C1ASS_STATUS
C1:DAQ-DC0_C1OAF_STATUS
C1:DAQ-DC0_C1CAL_STATUS

C1:DAQ-DC0_C1X02_STATUS
C1:DAQ-DC0_C1SUS_STATUS
C1:DAQ-DC0_C1MCS_STATUS
C1:DAQ-DC0_C1RFM_STATUS
C1:DAQ-DC0_C1PEM_STATUS

C1:DAQ-DC0_C1X03_STATUS
C1:DAQ-DC0_C1IOO_STATUS
C1:DAQ-DC0_C1ALS_STATUS

C1:DAQ-DC0_C1X01_STATUS
C1:DAQ-DC0_C1SCX_STATUS
C1:DAQ-DC0_C1ASX_STATUS

C1:DAQ-DC0_C1X05_STATUS
C1:DAQ-DC0_C1SCY_STATUS
C1:DAQ-DC0_C1TST_STATUS

1st plot
Title: IOP Fast Channel DAQ Status
These have two bits each. How can we handle it?
If we need to shrink it to a single bit take "AND" of them.
C1:FEC-40_FB_NET_STATUS (legend: c1x04, if a legend placable)
C1:FEC-20_FB_NET_STATUS (legend: c1x02)
C1:FEC-33_FB_NET_STATUS (legend: c1x03)
C1:FEC-19_FB_NET_STATUS (legend: c1x01)
C1:FEC-46_FB_NET_STATUS (legend: c1x05)

3rd plot
Title C1LSC CPU Meters
channels:
C1:FEC-40_CPU_METER (legend: c1x04)
C1:FEC-42_CPU_METER (legend: c1lsc)
C1:FEC-48_CPU_METER (legend: c1ass)
C1:FEC-22_CPU_METER (legend: c1oaf)
C1:FEC-50_CPU_METER (legend: c1cal)
The range is from 0 to 75 except for c1oaf that could go to 500.
Can we plot c1oaf with the value being devided by 8? (Then the legend should be c1oaf /8)

4th plot
Title C1SUS CPU Meters
channels:
C1:FEC-20_CPU_METER (legend: c1x02)
C1:FEC-21_CPU_METER (legend: c1sus)
C1:FEC-36_CPU_METER (legend: c1mcs)
C1:FEC-38_CPU_METER (legend: c1rfm)
C1:FEC-39_CPU_METER (legend: c1pem)
The range is be from 0 to 75 except for c1pem that could go to 500.
Can we plot c1pem with the value being devided by 8? (Then the legend should be c1pem /8)

5th plot
Title C1IOO CPU Meters
channels:
C1:FEC-33_CPU_METER (legend: c1x03)
C1:FEC-34_CPU_METER (legend: c1ioo)
C1:FEC-28_CPU_METER (legend: c1als)
The range is be from 0 to 75.

6th plot
Title C1ISCEX CPU Meters
channels:
C1:FEC-19_CPU_METER (legend: c1x01)
C1:FEC-45_CPU_METER (legend: c1scx)
C1:FEC-44_CPU_METER (legend: c1asx)
The range is be from 0 to 75.

7th plot
Title C1ISCEY CPU Meters
channels:
C1:FEC-46_CPU_METER (legend: c1x05)
C1:FEC-47_CPU_METER (legend: c1scy)
C1:FEC-91_CPU_METER (legend: c1tst)
The range is be from 0 to 75.

=====================

IOO

We want a duty ratio plot for the IMC. C1:IOO-MC_TRANS_SUM >1e4 is the good period.

Duty ratio plot looks like the right plot of the following link
https://ldas-jobs.ligo-wa.caltech.edu/~detchar/summary/day/20150722/lock/segments/

=====================

SUS: OPLEV

OL_PIT_INMON and OL_YAW_INMON are good for the slow drift monitor.
But their sampling rate is too slow for the PSDs.
Can you use
C1:SUS-ETM_OPLEV_PERROR
C1:SUS-ETM_OPLEV_YERROR
etc...
For the PSDs? They are 2kHz sampling DQ channels. You would be able to plot
it up to ~1kHz. In fact, we want to monitor the PSD from 100mHz to 1kHz.
How can you set up the resolution (=FFT length)?

=====================

LSC / ASC / ALS tabs

Let's make new tabs LSC, ASC, and ALS

LSC:

We should have a plot for
C1:LSC-TRX_OUT_DQ
C1:LSC-TRY_OUT_DQ
C1:LSC-POPDC_OUT_DQ
It's OK to use the minute trend for now.
You can check the range using dataviewer.

ASC:

Let's use
C1:SUS_MC1_ASCPIT_OUT16 (legend: IMC WFS)
C1:ASS-XARM_ITM_YAW_OSC_CLKGAIN (legend: XARM ASS)
C1:ASS-YARM_ITM_YAW_OSC_CLKGAIN (legend: YARM ASS)
C1:ASX-XARM_M1_PIT_OSC_CLKGAIN (legend: XARM Green ASS)
as the status indicators. There is no YARM Green ASS yet.

ALS:

Title: ALS Green transmission
We want a time series of
ALS-TRX_OUT16
ALS-TRY_OUT16

Title: ALS Green beatnote
Another time series
ALS-BEATX_FINE_Q_MON
ALS-BEATY_FINE_Q_MON

Title: Frequency monitor
We have frequency counter outputs, but I have to talk to Eric to know the channel names

  11448   Mon Jul 27 17:51:06 2015 EveUpdateSummary PagesNew summary page tabs and other improvements

The summary pages can still be found at https://nodus.ligo.caltech.edu:30889/detcharsummary/ (EDIT: in an older version of this post I listed an incorrect url). They are operational and include data from some channels for intermittent periods of time.

 

Motivation: to make the summary pages more informative and useful for all

 

What I did:

I have added tabs for ALS, ASC, and LSC subsystems. While there is currently no data on the plots, I plan on checking all channels with DataViewer to set appropriate axis ranges so that we can actually see the data.

I altered which channels are used to represent spectra for OpLev systems to more appropriately provide PSDs.

I've changed the check code status page to include "warning" labels. Previously, when the summary pages ran, resulting in a warning message, the check code status page would list this as an "error", implying that the summary pages were not properly produced.

 

Results:

All features were implemented, but I need to investigate some of these channels to understand why we aren't seeing many channels in the plots. I am working on some other changes to the summary pages, including providing a Locked status which will only show data in a timeseries for a selected period of time.

  11467   Thu Jul 30 14:27:18 2015 EveUpdateSummary PagesALS, ASC, LSC Summary Pages

I've switches the ALS, ASC, and LSC plots on the summary pages from plotting raw frames, to plotting minute trends, instead. Now, the plots contain information, instead of being completely blank, but data is not recorded on the plots after 12UTC.

Typically, I make changes to the summary pages on my own version of the pages, found at https://ldas-jobs.ligo.caltech.edu/~eve.chase/summary/day/, where I change the summary pages for June 30 and then import such changes into the main summary pages. 

 

  11474   Sat Aug 1 17:04:29 2015 EveUpdateSummary PagesStates and Triggers in SPs

I've added states to the summary pages to only show data for times at which one certain channel is above a specified threshold. So far, I've incorporated states for the IOO tab to show when the mode cleaner is locked.

You can see these changes implemented in the IOO tab of my personal summary pages for June 30: https://ldas-jobs.ligo.caltech.edu/~eve.chase/summary/day/20150630/ioo/.

I've written a description of how to add states to summary pages here: https://wiki-40m.ligo.caltech.edu/DailySummaryHelp#How_to_Define_and_Implement_States.

  11480   Wed Aug 5 17:15:08 2015 EveUpdateSummary PagesFixed ASC Tab

I've fixed the ASC tab on the summary pages to populate the graphs with data without causing an error.

Motivation: The ASC tab was showing no data. It resulted in a name error when generated.

What I did:

A name error indicates a bad channel name in the plot definition. I identified two errors in the code:

  1. I said C1:SUS_MC1_ASCPIT_OUT16.mean instead of C1:SUS-MC1_ASCPIT_OUT16.mean (underscore should be dash)
  2. The channel C1:ASX-XARM_M1_PUT_OSC_CLKGAIN was resulting in a name error. I removed it.

Results:

The plots are not processing without error. However, no titles or axis labels are present on the plots- I'll work on adding these.

 

  11585   Wed Sep 9 11:33:58 2015 ranaUpdateSummary PagesSummary Page updates
  • Made most plots in IOO tab only plot when MC_TRANS > 10000 using Eve's MC_LOCK state definition.
  • added the 0.03 - 0.1 Hz and 10-30 Hz bands to the PEM SEIS BLRMS tab and set the y-scales to the same as SeismicRainbowSTS.stp
  • set state PMC_LOCK in PSL tab and made some of those plots only plot when PMC trans > 0.6.
  • SUS-OL page showed me that the ETM yaw spectrum was wacky, which lead me to find that it was completely uncentered. Stop leaving the room lights ON Steve!!  angry I also set the quadrant offsets by blocking the QPD with a piece of metal (teflon doesn't work).
  • set c1summary to only plot some when X or Y arms are locked
  12703   Wed Jan 11 19:20:23 2017 Max IsiUpdateSummary PagesDecember outage

The summary pages were not successfully generated for a long period of time at the end of 2016 due to syntax errors in the PEM and Weather configuration files.

These errors caused the INI parser to crash and brought down the whole gwsumm system. It seems that changes in the configuration of the Condor daemon at the CIT clusters may have made our infrastructure less robust against these kinds of problems (which would explain why there wasn't a better error message/alert), but this requires further investigation.

In any case, the solution was as simple as correcting the typos in the config side (on the nodus side) and restarting the cron jobs (on the cluster side, by doing `condor_rm 40m && condor_submit DetectorChar/condor/gw_daily_summary.sub`). Producing pages for the missing days will take some time (how to do so for a particular day is explained in the wiki https://wiki-40m.ligo.caltech.edu/DailySummaryHelp).

RXA: later, Max sent us this secret note:

However, I realize it might not be clear from the page which are the key steps. These are just running:

1) ./DetectorChar/bin/gw_daily_summary --day YYYYMMDD --file-tag some_custom_tag To create pages for day YYYYMMDD (the file-tag option is not strictly necessary but will prevent conflict with other instances of the code running simultaneously).

2) sync those days back to nodus by doing, eg: ./DetectorChar/bin/pushnodus 20160701 20160702

This must all be done from the cluster using the 40m shared account.
  12709   Thu Jan 12 23:22:34 2017 ranaUpdateSummary PagesDecember outage

Pages still not working: PEM and MEDM blank.

  • Committed existing MEDM grabbing scripts to SVN. Ran the cron job on megatron by hand. It grabs PNG files, but somehow its not getting into the summary pages.
  • Changed the MEDM grabbing scripts to use '/usr/bin/env'.
  • GW summary log files were numbering in the many thousands, so I moved everything over 320 days old into the OLD/ sub-directory using 'find . -type f -mtime +320 -exec mv {} OLD/ \;' (the semi-colon is needed)
  • Did apt-get upgrade on Megatron.
  • pinged Max
  • Stared at GWsumm docs to see if there's a clue about what (if anything) is wrong with the .ini file.
  12713   Fri Jan 13 14:33:00 2017 MAX (not Rana)UpdateSummary PagesDecember outage

PEM config file was also lacking a section named "summary", which is necessary for all parent tabs; this has now been solved. I have deactivated the MEDM pages because Praful's screencap script seemed to be broken (I should have logged this, I apologize).

Quote:

Pages still not working: PEM and MEDM blank.

  • Committed existing MEDM grabbing scripts to SVN. Ran the cron job on megatron by hand. It grabs PNG files, but somehow its not getting into the summary pages.
  • Changed the MEDM grabbing scripts to use '/usr/bin/env'.
  • GW summary log files were numbering in the many thousands, so I moved everything over 320 days old into the OLD/ sub-directory using 'find . -type f -mtime +320 -exec mv {} OLD/ \;' (the semi-colon is needed)
  • Did apt-get upgrade on Megatron.
  • pinged Max
  • Stared at GWsumm docs to see if there's a clue about what (if anything) is wrong with the .ini file.

 

  12749   Tue Jan 24 07:36:56 2017 Max IsiUpdateSummary PagesCluster maintenance
System-wide CIT LDAS cluster maintenance may cause disruptions to summary pages today. 
  12752   Wed Jan 25 09:00:39 2017 Max IsiUpdateSummary PagesCluster maintenance
LDAS has not recovered from maintenance causing the pages to remain unavailable until further notice.

> System-wide CIT LDAS cluster maintenance may cause disruptions to summary pages today. 
  12787   Thu Feb 2 11:25:45 2017 Max IsiUpdateSummary PagesCluster maintenance
FYI this issue has still not been solved, but the pages are working because I got the software running on an
alternative headnode (pcdev2). This may cause unexpected behavior (or not).

> LDAS has not recovered from maintenance causing the pages to remain unavailable until further notice.
> 
> > System-wide CIT LDAS cluster maintenance may cause disruptions to summary pages today. 
  12831   Wed Feb 15 22:16:05 2017 Max IsiUpdateSummary PagesNew condor_q format

There has been a change in the default format for the output of the condor_q command at CIT clusters. This could be problematic for the summary page status monitor, so I have disabled the default behavior in favor of the old one. Specifically, I ran the following commands from the 40m shared account: mkdir -p ~/.condor echo "CONDOR_Q_DASH_BATCH_IS_DEFAULT=False" >> ~/.condor/user_config This should have no effect on the pages themselves.

  12870   Mon Mar 6 14:47:49 2017 gautamUpdateSummary PagesCode status check script modified

For a few days now, the "code status" page has been telling us that the summary pages are DEAD, even though the pages themselves seemed to be generating plots. I logged into the 40m shared account on the cluster and checked the status of the condor job (with condor_q), and did not find anything odd there. I decided to consult Max, who pointed out that the script that checks the code status (/home/40m/DetectorChar/bin/checkstatus) was looking for a particular string in the log files ("gw_daily_summary"), while the recent change in the default output of condor_q meant that the string actually being written to the log files was "gw_daily_summa". This script has now been modified to look for instances of "gw_daily" instead, and so the code status indicator seems to be working again...

The execution of the summary page scripts has also been moved back to pcdev1 (from pcdev2, where it was moved to temporarily because of some technical problems with pcdev1).

  13049   Wed Jun 7 14:27:23 2017 SteveUpdateSummary Pagessummery pages not working

Last good page May 18, 2017

Not found, error message May 19 - June 4,2017

Blank plots,  June 5, 2017

  224   Thu Jan 3 12:38:49 2008 robBureaucracyTMISore throat

Quote:

I did not feel anything wrong yesterday, but unfortunately I have a very much sore throat today. I need to drink warm milk with honey and rinse my throat often today. So far I do not have other illness symptomes (no fever), so I hope that this small disease will not last for a long time, but I feel that it is better for me to cure my sore throat today at home (and probably it is safer for others in 40-m).

I took yesterday the book "Digital Signal Processing", so I have it for reading at home.

Hope to see you tomorrow.


I've added a new category--TMI--for entries along these lines.
  229   Wed Jan 9 20:29:47 2008 DmassAoGTMICoffee Carafe
If you have been using the coffee machine in the 40m, you may have noticed small brown flecks in your coffee mug. The carafe in the 40m has accumulated a layer of what is presumed to be old dried up coffee. When a small amount of water is swirled around in the bottom, flecks of the brown layer come off. Pictures below are of the inside of the carafe.

But does it provide adequate protection from 1064 light?
Attachment 1: DSC_0363.JPG
DSC_0363.JPG
Attachment 2: DSC_0365.JPG
DSC_0365.JPG
Attachment 3: DSC_0368.JPG
DSC_0368.JPG
  279   Mon Jan 28 12:42:48 2008 DmassBureaucracyTMICoffee
There is tea in the coffee carafe @ the 40m. It is sitting as though it were fresh coffee. There is also nothing on the post it.
  341   Tue Feb 26 20:24:04 2008 AndreySummaryTMISorrow
As for that plot of three-dimensional surface, I indeed was wrong with the axis "Q_ETMX-Q_ITMX" (I put there wrong string "Q_ITMX-Q_ETMX"). On Friday plot there were values 10^(-12) on the z-axis, and that should be really meters, but the point that as I realized on Monday, I have never calibrated experimental measurement results from counts to meters , that's why it is this difference between 10^(-6) and 10^(-12). I still did not find the way to compare experim. and theoretical plots, because even if I leave "counts" on both plots, so that I have scale 10^(-6) on both plots, then the change in theoretical plot is just 0.02*10^(-6) for the range of Q-factors change, while the change in experimental measurements is an order of magnitude more 0.4*10^(-6), so the surface for theretical plot would be almost flat in the same axes as experimental results.
  2887   Thu May 6 17:47:01 2010 Alberto, kiwamu, Jc The 3rd (aka The Drigg)OmnistructureTMIMinutes from the Lab Organization Commitee meeting

Today we met and we finally come up with a lot of cool, clever, brilliant, outstanding ideas to organize the lab.

You can find them on the Wiki page created for the occasion.

http://lhocds.ligo-wa.caltech.edu:8000/40m/40m_Internals/Lab_Organization

Enjoy!

  2888   Thu May 6 17:54:44 2010 Zach Korth -- Committee Oversight (Fun Division)OmnistructureTMIMinutes from the Lab Organization Commitee meeting

Where are we going to put the tiki bar? The ice cream machine? I am disappointed in the details that appear to have been glossed over..

Quote:

Today we met and we finally come up with a lot of cool, clever, brilliant, outstanding ideas to organize the lab.

You can find them on the Wiki page created for the occasion.

http://lhocds.ligo-wa.caltech.edu:8000/40m/40m_Internals/Lab_Organization

Enjoy!

 

  14041   Fri Jul 6 12:12:09 2018 AnnalisaConfigurationThermal CompensationThermal compensation setup

I tried to put together a rudimentary heater setup. 

As a heating element, I used the soldering iron tip heated up to ~800°C.

To make a reflector, I used the small basket which holds the cork of champains battles (see figure 1), and I covered it with alumnum foil. Of course, it cannot be really considered as a parabolic reflector, but it's something close (see figure 2).

Then, I put a ZnSe 1 inch lens, 3.5 inch FL (borrowed from TCS lab) right after the reflector, in order to collect as much as possible the radiation and focus it onto an image (figure 3). In principle, if the heat is collimated by the reflector, the lens should focus it in a pretty small image. Finally, in order to see the image, I put a screen and a small piece of packaging sponge (because it shouldn't diffuse too much), and I tried to see the projected pattern with a thermal camera (also borrowed from Aidan). However, putting the screen in the lens focal plane didn't really give a sharp image, maybe because the reflector is not exactly parabolic and the heater not in its focus. However, light is still focused on the focal plane, although the image appears still blurred. Perahps I should find a better material (with less dispersion) to project the thermal image onto. (figure 4)

Finally, I measured the transmitted power with a broadband power meter, which resulted to be around 10mW in the focal plane. 

Attachment 1: IMG_1887.jpg
IMG_1887.jpg
Attachment 2: IMG_1884.jpg
IMG_1884.jpg
Attachment 3: IMG_1883.jpg
IMG_1883.jpg
Attachment 4: IR20180706_0358_labels.png
IR20180706_0358_labels.png
  14043   Sat Jul 7 19:50:38 2018 AnnalisaConfigurationThermal CompensationStudy about the Thermal projection setup and its effect on the cavity

I made some simulation to study the change that the heater setup can induce on the Radius of Curvature of the ETM.

Heat pattern

First, I used a non-sequential ray tracing software (Zemax) to calculate the heat pattern. I made a CAD of the elliptical reflector and I put a radiative element inside it (similar to the rod-heater 30mm long, 3.8mm diameter that we ordered), placing it in such a way that the heater tip is as close as possible to the ellipse first focus. (figure 1)

Then, by putting a screen at the second focus of the ellipse (where we suppose to place the mirror HR surface), I could find the projected heat pattern, as shown in figure 2 and 3 (section). Notice that the scale is in INCH, even if the label says mm. As you can see, the heat pattern is pretty broad, but still enough to induce a RoC change. 

Mirror deformation

In order to compute the mirror deformation induced by this kind of pattern, I used this map produced with Zemax as absorption map in COMSOL. I considered ~1W total power absorbed by the mirror (just to have a unitary number).

The mirror temperature and deformation maps induced by this heat pattern are shown in figures 4 and 5. 

RoC change evaluation

Then I had to evaluate the RoC change. In particular, I did it by fitting the Radius of Curvature over a circle of radius:

r = w_{00} * \sqrt{n}

where w_{00} is the waist of tha Gaussian mode on the ETMY (5mm) and n is the mode order. This is a way to approximately know which is the Radius of Curvature as "seen" by each HOM, and is shown in figure 6 (the RoC of the cold mirror is set to be 57.37m). Of course, besides being very tiny, the difference in RoC strongly depends on the heat pattern.

Gouy phase variation

Considering this absorbed power, the cavity Gouy phase variation between hot and cold state is roughly 15kHz (I leave to the SURFs the details of the calculation).

Unanswered points

So the still unaswered questions are:

- which is the minimum variation we are able to resolve with our measurement

- how much heating power do we expect to be projected onto the mirror surface (I'll make another entry on that)

Attachment 1: reflector.png
reflector.png
Attachment 2: heat_pattern_-_f2.png
heat_pattern_-_f2.png
Attachment 3: heat_pattern_-_f2_-_cross_section.png
heat_pattern_-_f2_-_cross_section.png
Attachment 4: ETMtemperature.png
ETMtemperature.png
Attachment 5: ETMdeformation.png
ETMdeformation.png
Attachment 6: RoC_variation.png
RoC_variation.png
  14050   Tue Jul 10 23:44:23 2018 AnnalisaConfigurationThermal CompensationHeater setup assembly

[Annalisa, Koji]

Today both the heater and the reflector were delivered, and we set down the setup to make some first test.

The schematic is the usual: the rod heater (30mm long, 3.8 mm diameter) is set inside the elliptical reflector, as close as possible to the first focus. In the second focus we put the power meter in order to measure the radiated power. The broadband power meter wavelength calibration has been set at 4µm: indeed, the heater emits all over the spectrum with the Black Body radiation distribution, and the broadband power meter measures all of them, but only starting from 4µm they will be actually absorbed my the mirror, that's why that calibration was chosen.

We measured the cold resistance of the heater, and it was about 3.5 Ohm. The heater was powered with the BK precision DC power supply 1735, and we took measurements at different input current.

Current [A] Voltage [V] Measured radiated power [mW] Resistance [Ohm]
0.5 2.2 20 4.4
0.8 6 120 7.5
1 11 400 11
1.2 18 970 15

We also aimed at measuring the heater temperature at each step, but the Fluke thermal camera is sensitive up to 300°C and also the FLIR seems to have a very limited temperature range (150°C?). We thought about using a thermocouple, but we tested its response and it seems definitely too slow. 

Some pictures of the setup are shown in figures 1 and 6.

Then we put an absorbing screen in the suspension mount to see the heat pattern, in such a way to get an idea of the heat spot position and size on the ETMY. (figure 2)

The projected pattern is shown in figures 3-4-5

The optimal position of the heater which minimizes the heat beam spot seems when the heater inserted by 2/3 in the reflector (1/3 out). However, this is just a qualitative evaluation.

Finally, two more pictures showing the DB connector on the flange and the in-vacuum cables.

Some more considerations about in-vacuum cabling to come.

Steve: how are you going to protect the magnets ?

Attachment 1: IMG_1992.jpg
IMG_1992.jpg
Attachment 2: IMG_2002.jpg
IMG_2002.jpg
Attachment 3: IR20180710_0364a.png
IR20180710_0364a.png
Attachment 4: IR20180710_0368.png
IR20180710_0368.png
Attachment 5: IR20180710_0360.png
IR20180710_0360.png
Attachment 6: IMG_1993.jpg
IMG_1993.jpg
Attachment 7: IMG_5322.JPG
IMG_5322.JPG
Attachment 8: IMG_5321.JPG
IMG_5321.JPG
  14071   Fri Jul 13 23:39:46 2018 AnnalisaConfigurationThermal CompensationThermal compensation setup - power supply

[Annalisa, Rana]

In order to power the heater setup to be installed in the ETMY chamber, we took the Sorensen DSC33-33E power supply from the Xend rack which was supposed to power the heater for the seismometer setup.

We modified the J3 connector behind in such a way to allow a remote control (unsoldered pins 9 and 8). 

Now pins 9 and 12 need to be connected to a BNC cable running to the EPICS.


RXA update: the Sorensen's have the capability to be controlled by an external current source, voltage source, or resistive load. We have configured it so that 0-5V moves the output from 0-33 V. There is also the possibility to make it a current source and have the output current (rather than voltage) follow the control voltage. This might be useful since out heater resistance is changing with temperature.

Attachment 1: IMG_2012.jpg
IMG_2012.jpg
Attachment 2: IMG_2013.jpg
IMG_2013.jpg
Attachment 3: 20180713_213818.jpg
20180713_213818.jpg
  14078   Tue Jul 17 17:37:46 2018 Annalisa, TerraConfigurationThermal CompensationHeaters installation

Summary

We installed two heaters setup on the ETMY bench in order to try inducing some radius of curvature change and therefore HOMs frequency shift.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

We installed two heaters setup.

Elliptic reflector setup (H1): heater put in the focus of the elliptical reflector: this will make a heat pattern as descirbed in the elogs #14043 and #14050. 

 

Lenses setup (H2): heater put in a cylndrical reflector (made up with aluminum foil) 1'' diameter, and 2 ZnSe lenses telescope, composed by a 1.5'' and a 1'' diameter respectively, both 3.5'' focal length. The telescope is designed in such a way to focus the heat map on the mirror HR surface. For this latter the schematic was supposed to be the following: 

This setup will project on the mirror a heat pattern like this:

which is very convenient if we want to see a different radius of curvature for different HOMs. However, the power that we are supposed to have absorbed by the mirror with this setup is very low (order of 40-ish mW with 18V, 1.2A) which is probably not enough to see an effect. Moreover, mostly for space reasons (post base too big), the distances were not fully kept, and we ended up with the following setup:

In this configuration we won't probably have a perfect focusing of the heat pattern on the mirror.

In vacuum connections

See Koji's elog #14077 for the final pin connection details. In summary, in vacuum the pins are:

13 to 8 --> cable bunch 0

7 to 2 --> cable bunch 2

25 to 20 --> cable bunch 1

19 to 14 --> cable bunch 3

where Elliptic reflector setup (H1) is connected to cables 0 and 1, and the lenses setup is connected to cables 2 and 3.

Installed setup

This is the installed setup as seen from above:

Attachment 5: IMG_5380.JPG
IMG_5380.JPG
  14086   Thu Jul 19 04:44:09 2018 Annalisa, TerraSummaryThermal Compensationfrequency shift observed with heating!

Annalisa, Gautum, Koji, Terra

Summary: with the reflector setup, we measured a frequency shift of the first and second order modes! First looks of shifts show 1st HOM shift ~-10 kHz, 2nd HOM shift ~-18 kHz (carrier ~4 kHz). We saw no shift with the cylinder/lenses set up.

- - - - -

Tonight we modified the cavity scan setup: the LO is provided by the Marconi which, at the same time, is also used to scan the AUX laser frequency instead of the Agilent. In order to get rid of the free running noise between Marconi and Agilent, the Marconi frequency was scanned and, point by point, the Agilent center frequency was changed accordingly. In order to speed up the process, the whole procedure was automated. The script is called AGfast.py and can be found in /users/annalisa/postVent.

One thing that helped in improving the data quality of the phase information was to set the Agilent IF bandwidth @1kHz. Not yet clear why, but it was better than having a lower bandwidth. To be further investigated.

With this setup, we made some coarse scan of the full FSR and then we "zoomed" around the main peaks in order to increase the resolution and get a more precise information about the peak frequency.

Here are the frequency ranges that we scanned:

  • carrier - central frequency: 31.73MHz; range: [31.68MHz - 31.78MHz]
  • HOM1 - central frequency: 32.88MHz; range: [32.84MHz - 32.93MHz]
  • HOM2 - central frequency: 34.03MHz; range: [33.95MHz - 34.06MHz]
  • HOM3 - central frequency: 35.18MHz; range: [35.09MHz - 35.25MHz]

We powered the heater of the lenses setup @4:55 am at 14.4V and 0.9A. Then we slightly increased the power @5:05am and the final "hot state" configuration is with heater powered at 16V and 0.9A.

With this setup we couldn't see any frequency shift

Then, at around 6:30 am we turned on the reflector setup and we measured a frequency shift of the first and second order modes. First scans show 1st HOM shift ~10 kHz, 2nd HOM shift ~18 kHz. First attachment shows carrier hot/cold, second attachment shows HOM2 hot/cold. We started to get plauged by high seismic noise. Heaters turned off at 7:45 am. Lots of scans and actual analysis to go.


gautam: about the questionable plotting -

  • 10 faint (alpha~0.3) lines are individual measurements with the reflector doing its heating. (AG4395A, 0 span, single frequency measurements plotted together).
  • charcoal line, labelled mean, is the mean of the 10 above lines.
  • bright green ("Reference") is the mean of a coarse scan (cold ETM) overlaid for comparison. 
  • "cold" - self explanatory.

My personal favourite plot is Attachment #3, which is a 5 MHz scan (cold) to identify positions of the various peaks. The power of including phase information in the analysis is clear. The second FSR on the right edge of the plot is not as prominent as the first is because the arm transmission was degrading throughout the measurement. For future measurements, we should consider locking the IMC length to the arm cavity - this would eliminate such alignment drifts, and maybe also make the PLL control signal RMS smaller. 

Attachment 1: scanning_fine_2018-07-19-07-32-08_parsed.pdf
scanning_fine_2018-07-19-07-32-08_parsed.pdf
Attachment 2: scanning_fine_2018-07-19-06-57-47_parsed.pdf
scanning_fine_2018-07-19-06-57-47_parsed.pdf
Attachment 3: Yscan_scanning_parsed_2am.txt.pdf
Yscan_scanning_parsed_2am.txt.pdf
  14094   Sat Jul 21 01:06:49 2018 gautamSummaryThermal CompensationY arm locking

I implemented this today. For now, the LSC output matrix is set to actuate on MC2 for Y arm locking. As expected, the transmission was much more stable, and the PLL control signal RMS was also reduced by factor of ~3. MC2 control signal does pick up a large (~2000 cts) DC component over a few hours, so we need to relieve this periodically.

Now that we have a workable ASS for the Y arm as well, we should be able to have more confidence in returning to the same beam spot position on the ETM and staying there during a scan using this technique.

The main improvement to be trialled next in the scanning is to improve the speed of scanning. As things stand, my script takes ~2.5 seconds per datapoint. If we can cut this in half, that'd be huge. On Wednesday night, we were extraordinarily lucky to avoid MC3 glitching, EPICS/slow machine failures, and GPIB freezes. Today, the latter reared its head. Fortunately, since I'm dumping data to file for each datapoint, this means we at least have data till the GPIB freeze.

Quote:

For future measurements, we should consider locking the IMC length to the arm cavity - this would eliminate such alignment drifts, and maybe also make the PLL control signal RMS smaller. 


Not related to this work: Terra, Sandrine, Keerthana and I cleaned up the lab a bit today, and made better cable labels. Aaron and I have to clean up the OMC area a bit. Huge thanks to Steve for taking care of our mess elsewhere in the lab!

  14096   Sat Jul 21 14:03:19 2018 KojiSummaryThermal CompensationY arm locking

Ah. With MC2 feedback, we have about 3 times smaller "optical gain" for the ASS A2L. We have same dither, same actuator, but we need only 1/3 actuation of the MC2 compared to the ETMY case.
We had to reduce the ASS spot servo from 1 to 0.3 to make is stable, so this means that the ASS is really merginally stable.

  14103   Wed Jul 25 14:45:59 2018 SandrineSummaryThermal CompensationETM Y Table AUX read out

Attached is a photo of the set up of the ETM Y table showing the AUX read out set up. 

Currently, the flip mount sends the AUX to the PDA255. Terra inserted a razor blade so the PDA255 will witness more HOMs. The laser is also sent to the regular PD and the CCD.

Attachment 1: EY_table_.JPG
EY_table_.JPG
  14105   Thu Jul 26 01:52:01 2018 terraUpdateThermal Compensationheater work update

Just a quick update: over the past few days we've taken (at least) 5 scans around each peak [carrier - HOM3] at 9.4V/0.8A, 4 scans around [carrier - HOM5] at 12V/0.9A hot state with the reflector setup. We also have (at least) 5 scans of carrier - HOM5 in cold state. I attach a rough overview of the peak magnitude shifts in the first attachment. Analysis ongoing. All data stored in annalisa/postVent/{date}

Initial shifts just based on rought peak placement in the meantime:

            [9.4V/0.8A]   [12V/0.9A]

HOM1    10 kHz         20 kHz

HOM2    18 kHz         28 kHz

HOM3     30 kHz        40 kHz

HOM4     N/A             26 kHz

HOM5     N/A             35 kHz

I also attach the heating thermal transient from today (12V/0.9A) as seen by the opLevs. We see a shorter time constant for pitch, longer for yaw, preceeded by a dip in yaw. Similar behavior yesterday for slightly less heating, though less pronounced pre-dip. The heater is offcentered on the optic horizontally; likely this is part of the induced yaw. The spikey stuff i removed is from people walking around inside during the transient.

I've left the heater and LSC off for the night. Heater off at 2:07 am local time.

Please don't touch the oplevs; we're taking a cool down measurement.

Attachment 1: OpLev_thermal_drift.pdf
OpLev_thermal_drift.pdf
Attachment 2: hotColdAll.pdf
hotColdAll.pdf
  14109   Fri Jul 27 17:16:14 2018 SandrineUpdateThermal CompensationCopied working scripts for mode spectroscopy into new directory (modeSpec)

The scripts: AGfast.py, make HDF5.py, plotSpec_marconi.py, and SandrineFitv3.py were copied into the new directory modeSpec.

The path is: /opt/rtcds/caltech/c1/scripts/modeSpec

These scripts can still be found under Annalisa's directory under postVent.

  14110   Sat Jul 28 00:45:11 2018 terra, sandrineSummaryThermal CompensationHeater measurements overview

[Sandrine, Koji, Terra]

Summary: We completed multiple scans at different heating powers for the reflector set up, observing unique HOM peak shifts of tens of kHz. We also observed HOM5 shifts with the cylinder set up. Initial Lorentzian fittings of the magnitude give tens of Hz resolution. I summarize the main week's work below. 

Set-up

Heater set-up is described in several previous elogs, but attachments #1 and #2 show the full heater set-up and wiring/pinouts in and out of vacuum, since we're all intimately aware of how confusing in-vacuum pinouts can be. We are not using the Sorenson power supply (as described in 14071); we just have the BKPrecision power supply 1735 sitting next to the ETMY rack and are manually going out to turn on/off. 

We've continued to use the scan setup described in elog 14086, which is run using /users/annalisa/postVent/AGfast.py. Step by step notes for setting up the scan, running the scans, and processing the scans are attached in notes.txt.

Inducing/witnessing HOMs

The aux input beam was already clipped and on wednesday (after Trans was centered, 14093) we also clipped the output aux beam with razor blade (angled vertically and horizontally, elog 14103) before PDA255; we clipped ~1/3 of the output beam. Attachment #3 shows before and after clipping output, where orange 'cold' == unclipped, black 'mean' == clipped (all in cold state). Up to HOM5 is visible. 

Measurements

Below is a summary of the available scan data. We also have cold (0A) scans CAR-HOM5 and full FSR scans for most configurations. 

Elliptic Reflector
current[A] voltage[V] power[W] scans
0.4 2 0.8 CAR-HOM3(x1)
0.5 3.4 1.7 CAR-HOM3(x1)
0.6 5 3.0 CAR-HOM3(x1)
0.8 9.4(9.7) 7.5(7.8) CAR-HOM5(>x5)
0.9 12 10.8 CAR-HOM5(x4)
1.09 17 18.5 CAR-HOM3

 

 

 

 

 

 

 

Cylinder + Lenses
current[A] voltage[V] power[W] scans
0.9 15 13.5 CAR-HOM5(odds x4)

We tried the cylinder set-up again tonight for the first time since inital try and can see shifts of HOM5 - see attachment #5; we haven't looked in detail yet, but it looks like odd modes are more effected, suggesting the ring heat pattern is off centered from the beam axis. 

Scan data is saved in the following format: users/annalisa/postVent/scandata/{reflector,cylinder}/{parsed,unparsed}/{CAR,HOM1,HOM2,HOM3,HOM4,HOM5}{_datetime}{_parsed,_unparsed}.{txt,pdf}

Minimum heating

On 7/26 we increased the power to the elliptical reflector heater in steps to find the minimum heater power required to see frequency shifts with our measurement setup. Lowest we can resolve is a shift in HOM3 with 1.7W (0.5A/3.4V). According to Annalisa's measurements in elog 14050, this would be something like 30-60 mW radiated power hitting the test mass. We only looked at CAR - HOM3 for this investigation; data for scans at 0.4A, 0.5A, 0.6A is available as indicated above.

Lorentizian Fitting

The Lorentzian fitting was done using the equation a + b / sqrt(1+((x-c)/d*2), where a = constant background, b = peak height above background, c = peak frequency, d = full width at half max. 

The fitting is still being edited and optimized. We will crop the data to zoom in around the peak more.

The Lorentzian fit of the magnitude shows ~10Hz of resolution. (See attachment 6 for the carrier at 8A and attachment 7 for HOM 1 at 9A)

We're working on fitting the full complex data.

 

 

Attachment 1: heater_setup.jpg
heater_setup.jpg
Attachment 2: heater_wiring.jpg
heater_wiring.jpg
Attachment 3: notes.txt
Notes for running scans:
1. when first turning on Agilent, set initial stuff
    > cd /users/annalisa/postVent/20180718
    > AGmeasure TFAG4395Atemplate.yml
2. tweak arm alignment and offset PLL
    > sitemap (then IFO --> ALIGN and also PSL --> AUX)
    > to increase 
3. make sure X-arm is misagligned (hit '! Misalign' button for ITMX, ETMX) 
3. run scan
    > python AGfast.py startfreq stopfreq points
... 36 more lines ...
Attachment 4: FSR_clipped.pdf
FSR_clipped.pdf
Attachment 5: cylinderHOM5.pdf
cylinderHOM5.pdf
Attachment 6: pt8A_CAR.pdf
pt8A_CAR.pdf
Attachment 7: pt9A_HOM1.pdf
pt9A_HOM1.pdf
  14405   Fri Jan 18 15:34:37 2019 gautamUpdateThermal CompensationElliptical reflector part number

Nobody documented this, but here is the part number with mechanical drawings of the elliptical reflector installed at EY: Optiforms E180. Heater is from Induceramics, but I can't find the exact part which matches the dimensions of the heater we have (diameter = 3.8mm, length = 30mm), perhaps it's a custom part?

The geometry dictates that if we want the heater to be at one focus and the ETM to be at the other, the separation has to be 7.1 inches. It certainly wasn't arranged this way before. It seems unrealistic to do this without clipping the main beam, I propose we leave sufficient clearane between the main beam and the reflector, and accept the reduced heating efficiency. 

Thanks to Steve for digging this up from his secret stash.

  14545   Mon Apr 15 22:55:34 2019 gautamFrogsThermal CompensationLab thermostat adjusted

It is feeling cold in the office area. According to the digital wall clock near the coffee machine, it is 19C. Rana bumped the thermostat setpoint up by 2F (from 75F to 77F). We need to setup long-term monitoring.

  7924   Tue Jan 22 09:18:50 2013 SteveUpdateTip - Tilttip tilt bases ordered

The corrected drawing base for tip tilt with coils are going to the shop. The will be back by the end of the week.

Attachment 1: TTbc.PDF
TTbc.PDF
ELOG V3.1.3-