New and improved plots for the He-Ne profiling experiment 

Font size has been increased to 30. 

The plots are maximum size (Following Rana's advice, I saved the plots as eps files(maximized) and converted them to pdf later).

There is a shaded region around the trendline that represents the parameter error. 

Function that I fit my data to (should have mentioned this in my earlier elog entries) 

Description of my error analysis -

1. I have assumed a 20% deviation from markings in the micrometer error. 

2. Using the error in the micrometer, I have calculated the propogated error in the beam power :

I added this error to the stastistical error due to the fluctuation of the oscilloscope reading to obtain the total error in power. 

3. I found the Fisher Matrix by numerically differentiating the function at different data points  with respect to the parameters    and .

I then found the covariance matrix by inverting the Fisher Matrix and found the error in spot size estimation. 

EDIT : Residuals added to plots and all axes made equal 

The Elog started crashing last night. It turns out I was the culprit, and whenever I tried to upload a certain 500kb .png picture, it would die. It has happened both when choosing "upload" of a picture, and when choosing "submit" after successfully uploading a picture. Both culprits were ~500kb .png files.

The beam scan (which has been living in the bridge subbasement for a bit now) is in a state of imperfection.

I noticed that:

• The waist reading seems to change by not insignificant amounts as you move the spot across the head, even for just small perturbations about the center.
• None of the features which require two slits seem to be working (unsure if this is software or hardware related)

I took some pictures to try and illuminate the situation - The inverted images are included to make it easier to see the flecks (?) in the slits

I am not sure how to figure out if any bit of the scan is/has been fried.

Pending further investigation, enjoy large error bars in your scan measurements!

PICTURES OF BOTH SLITS ON THE BEAMSCAN HEAD:

I came into the 40m to sign things out briefly then swiftly return them, and the alarms were going off on op540m at 1am.

The cat and donkey? were making much noise.

I am trying to get an actual complete install of the 40m svn on my machine. It keeps stopping at the same point:

I do a

svn checkout --username svn40m https://nodus.ligo.caltech.edu:30889/svn /Users/dmass/svn

A blah blah blah many files

...

A    /Users/dmass/svn/trunk/medm/c1/lsc/C1LSC_ComMode.adl.28oct06
svn: In directory '/Users/dmass/svn/trunk/medm/c1/lsc'
svn: Can't copy '/Users/dmass/svn/trunk/medm/c1/lsc/.svn/tmp/text-base/C1LSC_MENU.adl.svn-base' to '/Users/dmass/svn/trunk/medm/c1/lsc/.svn/tmp/C1LSC_MENU.adl.tmp.tmp': No such file or directory

I believe I have always had this error come up when trying to do a full svn install. Any illumination is welcome.

 An entry on the 40m wiki page might serve you better, and be easier to sift through once all is said and done

 It seems like you might inherit an offset by using step (3) b/c of the temperature gradient between the crystal and the sensing point. Depending on how large this gradient is you could increase the linear coupling from temperature to intensity noise from zero to a significant number. Phase noise should not be effected.

SInce these things (ovens) are so low time constant, shouldn't we

1. Lock to a temperature
2. Let the oven equilibrate for however long - a few tau maybe - my oven has a time constant of 60 sec, don't know if this is fast or slow compared to that
3. Measure P_532/P_1064
4. Change the setpoint
5. Go back to step 1

I borrowed the Olympus and forgot to leave a note - I should have it for at most a day. dmassey@ligo if you need it urgently

What did you use to filter the 2f components from your error signal? A homemade low pass or what?

Kiwamu:

I am using a homemade low pass filter.

It's just a RC passive LPF with the input impedance of 50 Ohm.

If I understand your elog, you are just calculating the the offset in position space that you get by having a refractive index.

Did you end up changing the mode matching so that the rayleigh range (which changes with refractive index) was confocally focused inside the crystal (e.g. Zr = 15 mm?

 I thought we cared about satisfying the confocal focusing parameter, that is to say we want to set Zr = 2L_crystal. If Zr changes inside the crystal, this is the number we care about..isn't it NOT the waist size, but the rayleigh range we care about? I am not entirely sure what youre response is saying you did...

1. Calculate Zr = pi * wo^2/(lamba/n)
2. Do mode matching to get this wo in free space
3. Calculate the offset you need to move the oven by using n
4. Move hte ovens

OR

1. Calculate Zr = pi*wo^2/(lamba)
2. Do mode matching to get this in free space
3. Calculate the offset you need to move your ovens using n
4. Move your ovens

I guess the waist size would also let me know - are you using 69 um or 53 um waist size?

I made some changes to the elog on nodus:

• Made a backup of /cvs/cds/caltech/elog/elog-2.7.5/elogd.cfg called elogd.cfg.bk.20100407 in the same directory
• Added a folder: /cvs/cds/caltech/elog/elog-2.7.5/logbooks/EAGER_Lab
• Restarted the elog daemon via the start-elog-nodus script in the elog-2.7.5 directory

I saw that the current version of the elog seems to be in the svn, so tried to svn the changes from nodus via ssh, but got this message:

"svn: This client is too old to work with working copy '/cvs/cds/caltech/elog/elog-2.7.5'; please get a newer Subversion client."

I feel I should svn this but don't want to *&#@ the svn/elog up.

For now I will leave it alone and ask a question: Is the folder /cvs/cds/caltech/elog/elog-2.7.5/ under SVN control? Is it also under CVS control?

TL;DR:  New tab added to elog.

Do we know what causes the crashes for definite? Let's give the whole knowledge gathering a shot. Surfs welcome to post. Please follow the format and keep it brief. P.S. if the elog stops responding or hangs while you're trying to edit a post or write a post, you may have crashed it.

Person

• Crashes

Dmass

• I have crashed the elog with downsized jpegs (~300-900kB).
• I see jpegs on the front page of the 40m (which seem to have not crashed it?)
• I have posted pdf's with and without png thumbnails (associated automatically via the Mac program preview) without problem.

Edit this post to add your own experience using the above format

elog crashed on an upload. restarted and it worked fine with the same file.

 Again. Resubmitted an old entry with just text changes. Elog hung for 5 min +.

I had a number of delinquent items on the sign out list from the 40m. I returned about half, and ordered replacements for most of the other half.

I put the photodiodes on the SP table, and the 560 on the electronics  bench.

To aid Jenny's valiant attempt to finish her SURF project, I did some things with the front end system over the last couple days, largely tricking Jamie into doing things for me lest I ruin the 40m RCG system. Several tribulations have been omitted.

We stole a channel in the frontend, in the proccess:

1. Modified the C1GFD simulink model (now analog) to be "ADC -> TMP -> DAC" where TMP is a filter bank
   • C1GFD_TMP.adl (in /opt/rtcds/caltech/c1/medm/c1gfd) is the relevant part which connects the ADC to the DAC in the frontend
2. Confirmed that the ADC was working by putting a signal in and seeing it in the frontend
3. Could not get a signal out of the anti aliasing board
4. Looked sad until Kiwamu found a breakout board for the SCSI cable coming from the DAC
5. Used SR560 to buffer DAC output
   • drove a triangle wave with AWG into the TMP EXC channel (100 counts 1 Hz) and looked at it after the ~25 ft of BNC cable running between the DAC and the NRPO driver
   • wave looked funny (not like a triangle wave), maybe the DAC is not meant to push a signal so far, so added buffer
6. Took the control signal going to the fast input of the NPRO driver (using the 500 Ohm SR560 output - see Jenny's diagram) and put it into the anti aliasing board of the ADC
7. Added switchable integrator to filter bank with Foton
   • I couldn't get the names to display in the filter bank, so I looked sad again
   • Jamie and Koji both poked at the "no name displayed" problem but had no conclusions, so I decided to ignore it
   • I confirm that when the two filters were toggled "on" that the transfer function was as expected: simple integrator with a unity gain at ~10mHz - agrees with what Foton's Bode Plot tool says it should be (see attached DTT plot)
8. I got Jamie to manually add the two epics channels from the TMP model to the appropriate .ini file so they would be recorded
   • C1:GFD-TMP_OUTPUT  (16 Hz)
   • C1:GFD-TMP_INMON    (16 Hz)
9. RefCav heater servo seems to still be set up, so we can use existing channels:
   • C1:PSL-FSS_RCPID_SETPOINT (temp setpoint - will do +/-1C steps about 35 C)
   • C1:PSL-FSS_MINCOMEAS (In loop temp sensor - in C)
   • C1:PSL-FSS_RCTEMP (out of loop temp sensor - in C)
   • C1:PSL-FSS_TIDALSET (Voltage to heater - rails @ +/- 2V)
10.  Closed loop on the control signal for the NPRO driver with an integrator, saw error signal go to zero
    • Turned up gain a little bit, saw some oscillations, then turned gain down to stop them, final gain = 2
11. Left system on for Jenny to come in and do step responses

elog died b/c someone somewhere did something which may or may not have been innocuous. I ran the script in /cvs/cds/caltech/elog to restart the elog (thrice).

I have now banned Warren from clicking on the elog from home

Restarted elog 9:11PM 9/5/11

Elog went nonreponsive. SSH'ed into nodus to run restart script. Elog came back ~15 minutes later.

I broke a small bit while using the 40m drill press to vent some 1/4-20 screws for the cryo experiment.

I replaced it and refilled the small bit row in the bit index I was using; there were ~10 missing sizes

Please!

Don't put laptops on the ISC Tables!

 This is totally non-sensical statement, of course.

We might also say that the DARM loop totally squishes the GW signal and so its better not to have any feedback in the interferometer.

40m summary webpages

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

http://192.168.113.209/~controls/summary

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

Technical notes

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

Getting frames

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

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

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

$ tconvert May 25
1021939215

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

Running the code

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

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

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

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

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

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

Configuration

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

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

The entries can be explained as follows:

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

Other compatible options not used in this example are:

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

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

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

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

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

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

vanna --> QIL.

gautam 20190804: The GPIB module + power supply were returned to me by Duo ~5pm today at the 40m.

Riju, Elli

Today tried to take our first cavity scan.  We unplugged the 55MHz sideband input from the RF combiner on the PSL table, and connected a network analyser instead.  Using the network analyzer we injected a 12dBm signal (swept from 32MHz to 45MHz) through the RF combiner into the EOM to create our swept sidebands.  We measured the  MC cavity response by looking at the signal comming out of the RF photodiode on the MC2 table.  I replaced the BNC cable connected to the RF PD with a longer BNC cable that could reach our network analyzer next to the PSL table.  Riju will post a diagram of our setup.

We didn't see the expected carrier resonances when we performed a cavity scan.  The light incident on the RF PD is around 0.7micro Watts and we are still thinking about whether this is strong enough to see our signal above the noise.  We also want to work out what the strength of our swept sidebands is.  We will attempt to do a 'real' cavity scan tomorrow.

Koji, Riju, Elli

This morning Koji discovered that the 55MHz input into the RF combiner that I disconnected yesterday wasn't terminated properly, so it was reflecting power back into the amplifier in the signal generation unit.    We turned off the signal generation unit and checked that the amplifier was still working properly- it was.  A 50 ohm terminator was attached to the end of the 55MHz cable so that it is now terminated properly.

When we tried to turn the signal generator box back on we discovered the switch is broken (the box will only stay on while you hold down the on switch) and will need to be replaced.  In order to create the 29.5MHz sidebands to lock the mode cleaner, we bypassed the signal generation unit which won't stay on (unplugging '29.5 MHZ out' cable from the frequency generation unit), and instead sent a 0.39V 29.5MHz signal from a function generatior into 'RF input' on the 'RF AM Stabiliser' board.

We also increased the power coming exiting the PSL table and going into the cavity from 11 microwatts to 20 microwatts by adjusting the polariser at the end of the table slightly.  The power has been set to 20 microwatts using the polariser a few days ago but had drifted down since then.

 Riju, Elli

Today we prepared our experimental setup to take a cavity scan of the input mode cleaner, which we want to measure in the next day or so.  Attached is a diagram of our setup.

What we want to do is to inject a set of sidebands into the PSL and sweep their frequency from 32-45 MHz (a range just over one fsr of the mode cleaner- vfsr=11MHz).  We will measure the power transmitted out of the MC using a photo-diode and demodulate this signal with our input signal from the Marconi.  From this we should be able to see the resonant frequencies of the carrier and the higher order modes.

One aspect we spent some time thinking about; whether we would be able to inject a signal into an EOM given the EOM and the Marconi are not perfectly impedance matched.  Based on Kiwamu’s previous e-log entries designing the EOM, we decided that injecting a signal in 32-45 MHz region at 15dBm is similar to injecting the 29.5MHz sideband (at the same power level with very similar input impedance.) Fingers crossed we don’t blow anything up first week on the job.

I took back he VCO driver that Reetika brought over to the 40m from the PSL lab.  

I unlocked the PMC and swept over C1:PSL-PMC_RAMP's full range a couple of times this morning.  The PMC should now be relocked and returned 
to normal.

I tracked the tendency for ezcaPut to fail and sometimes seg-fault in the camera code to a conflict between the camera API and ezca, either on the 
network level or the thread level.  Since neither are sophisticated enough to provide controls over how they handle these two things, I instead 
separated the call to ezcaPut out into a small, separate script (a stripped down ezcawrite), which the camera code calls at the system level.  This is a 
bit hacky of a solution, but its the only thing that seems to work.

I've developed a transformation based on Euler angles that should be able to take the 4 OSEMs in a picture of the end mirror and use their relative 
positions to determine the angle of the camera to the optic.  This would allow the position data determined by the fitting software to be converted 
from pixels to meaningful lengths, and should aid any servo-ing done on the beams position.  I've yet to actually test if the equations work, though.

The servo code needs to have slew rate limiters and maximums/minimums to protect the mirrors written in to it before it can be tested again, but I 
have no idea what reasonable values for these limits are.

Joe and I recently scanned the PMC by driving C1:PSL-PMC_RAMP with the trianglewave script over a range of -3.5 to -1.25 (around 50 to 150 volts 
to the PZT) and read out C1:PSL-ISS_INMONPD to measure the transmission intensity.  This included slightly under 2 FSRs.  For slow scans (covering 
the range in 150 to 300 s), the peaks were very messy (even with the laser power at 1/6 its normal value), and it was difficult to place where the 
actual peak center occurred.  For faster sans (covering the range in 30 seconds or so), the peaks were very clean and nearly symmetric, but were 
not placed logically (the same peak showed up at two very different values for the PZT voltage in two separate runs).  I don't have time to put 
together graphs of the scans at the moment; I'll have that up sometime this afternoon.

I started work familiarizing myself with the ELOG and some of the control systems at the 40m. I spent a fair bit of time gaining some general knowledge of the interferometer, control systems, calibration, null instruments, etc. On Friday, June 22 Yaakov and I spent the afternoon pulling cables for the beatbox that Jamie had finished up. We were able to get the cables from the rack containing the beatbox routed to the control room.

Then I started work on calibrating the beatbox. I set up the function generator to send a sine wave into the beatbox, then sent the signal from the beatbox to the oscilloscope. I compared both the input sine wave and the output from the beatbox at many frequencies, taking peak to peak measurements. I'm working on using the data to calibrate the beatbox now.

Here's what I accomplished since my last elog:

I continued working on the beatbox calibration. Instead of using the function generator for an input signal,
I used the network analyzer because it can generate higher frequencies that are of more interest to us. I ran
the network analyzer output into the RF in port, and took voltage measurements from the Q port using the
oscilloscope. The frequency range I focused on was 100 - 200 MHz, and I also took more closely spaced measurements
from 180 - 200 MHz. The data is recorded on the computer now, and I will analyze it more fully in the future.

I also edited the Calibration page on the LIGO 40 m wiki. Rana showed me the page on calibration, but there was
limited information there, so he recommended that I post my work there as well. Right now I haven't posted much,
but I will likely add some information on the Simulink model I'm working on and results of measurements to be
taken as the project progresses.

The majority of my work has been on developing a Simulink model in Matlab of the differential arm length sensing
and control loop. I am using Figure 6-1 from Rana's thesis as a guide on important components to include in the
model. Some of the details on the transfer functions of components need to be worked out, but a basic framework has
been established. Right now the transfer function of the arm cavity is being approximated as a single pole, but
we may integrate the calibration model I'm working on with Sasha's work on the arm cavity. I have also begun to
implement the length response function in the model. I believe it is giving correct results at frequencies up to
100 Hz, but is off at higher frequencies. This might be fixed after I continue to fill in the transfer functions
of the digital components; they are currently set to 1 until I find more information on them.