#!/bin/bash   ### this is a comment  PATH=$PATH:/home/user/path    echo "How cool is this?" 

EDIT: it looks like the code highlighting is sort of broken :-(.

 Here is the logic that I have been using to calculate the transimpedence of PDs. Please let me know if you think anything is wrong.

The RF multiplexer is configured as shown in the figure. It is now effectively a 15x1 RF mux.

To select a required channel:

Run the script as shown below 

/opt/rtcds/caltech/c1/scripts/general/rfMux.py

>python rfMux.py ch11

For channel 10 to 16, you can just enter the required channel number and it is routed to the output.

For channel 1 to 8, you only need to input the required channel number as above. No need to run the code again to select ch9 after selecting ch1-8

How the NI-8100 controller works:

Whenever any channel of one switch is selected, the output of the other switch is set to its ch0 (ch1 and ch9 in the figure).

So selecting ch1-8 will automatically select ch9 as output for the other switch. IF you send a command to select ch9 afterwards, the first switch will be automatically set to ch1 and not stay on what you had selected before.

The script for running continuous scans on HP 8591E spectrum analyzer is located at scripts/general/netgpibdata/HP8591E_contdScan.py

Give the file HP8591E_param.yml as an argument when running the script. This contains the sweep parameters: Start and stop frequencies along with the place where the plot is stored as a PDF.

The default PDF is located on the Desktop and is named HP8591E_View.pdf     Open this using okular and then run the script.  (Okular pdf viewer automatically reloads the PDF as and when a new one is created)

What the script does:

1) Set the start and stop frequencies as given in the .yml file

2) Take a data trace and plot it in a PDF.

3) Repeat taking traces and update the PDF. Untill Ctrl+C is pressed (PDF refresh rate: approximately every 3 seconds )

4) Exit smoothly after the keyboard interrupt.

Other details:

This spectrum analyzer is connected to a GPIB - Ethernet controller that is configured as santuzza.martian (192.168.113.109)

I have currently stolen the wireless modem from the spectrum analyzer inside the lab (vanna.martian) and using it for this one. *poker face*

To improve:

Get the plot to show where the two biggest peaks are located. Currently it recognizes only the biggest one.

Possibly have makers on the two peaks.

PFA a sample pdf

There was no such script in the directory when I looked today, but I found one called HP8591E. Of course, it didn't run because it hadn't been tested from the scripts directory and pointed to some /users/nichin/ stuff.

I modified a couple of lines and then committed it and the default .YML parameter file to the SVN. It runs and produces plots continuously from the scripts directory.

*** also, as you can see, we have mostly recovered the green beat amplitudes after yesterday's FLL attack on the ALS ***

 When the IMC locks, we want the FAST OUT of the TTFSS box to be close to zero volts. We also want the control signal from the MC Servo board to be close to 0 V. How to set this up?

With the IMC locked, we just servo the FSS input offset to minimize the MC board output :

ezcaservo -r C1:IOO-MC_FAST_MON -g 0.1 -t 10 C1:PSL-FSS_INOFFSET

I would have used "CDSUTILS", but that seems to have some sort of ridiculous bug where we can't have prefixes on channel names, even on the command line. 

Attached is an example script showing how to access 40m data remotely. The only two nonstandard python modules you need are the nds2 client module and astropy (used for time conversion). For mac users, both of these are available via macports (nds2-client and, e.g. py27-astropy). Otherwise, check out their websites:

https://www.lsc-group.phys.uwm.edu/daswg/projects/nds-client.html

https://github.com/astropy/astropy

Have fun!

 I hereby confess to having a secret script.  But it is secret no longer!

It's a "goLock" script, and it is now in the path from any terminal.  It kills any open medm sessions (to clean up desktops), and then opens a palette of screens that I find useful.  It also starts up the CARM and DARM ALS watch scripts, and the toggle shutter scripts.  It then leaves the terminal in .../scripts/PRFPMI/ , which is where the carm_cm_up.sh script that we've been using lives.

I also made tonight a "goHome" script, but all that one does so far is set the LSC mode to OFF.  The other thing that this could / should do is restore all optics so we don't have hysteresis problems.

Also, also, my "new" misalign / restore scripts had a bug, in that they were always switching oplevs for the PRM, no matter what optic was requested.  This sometimes caused the PRM oplev to be engaged while the optic was misaligned, so the PRM would get rung up.  This has been fixed.

• Suppose you have a dtt template name test.xml
• The file test.dtt
  
  open
restore test.xml
run -w
save test2.xml
quit
 
• Run diag < test.dtt
• The result is saved in test2.xml

Following this entry, I have made the same change in the controls account on rossa:

In the ~/.grace/gracerc file (create one if it doesn't exist), put in a line which reads:

PAGE LAYOUT FREE

Now we can scale our dataviewer live and playback plots by stretching the window with our mouse. The attached screenshot shows how I filled up one of the vertical monitors with a DV window for arm locking.

I have adapted one of Evan's python scripts into an ipython notebook for calculating our PRMI sensing matrix - the work is ~half done.

The script gets the data from the various PD channels (like REFL33_I) and demdoulates it at the modulation frequencies. At the moment its using just the sensing channels, but with the recent addition of the SUS-LSC_OUT_DQ channels, we can demod the actuation channels as well and not have to hand code the exc amplitudes and the basolute phase. Please ignore the phase for the moment.

The attached PDF shows the demod (including lowpass) outputs for a 2 minute stretch of PRMI locked on f2. Next step is to average these numbers and make the radar plots with the error bars. The script is scripts/LSC/SensingMatrix/PRMIsensMat.ipynb and is in the SVN now.

** along the way, I noticed that the reason this notebook hasn't been working since last night is that someone sadly installed a new anaconda python distro today  without telling anyone by ELOG. This new distro didn't have all the packages of the previous one. I've updated it with astropy and uncertainties packages.

I've fixed the Radar plot making part, so that's now included too. The radial direction is linear, so you can see from the smearing of the blobs that the uncertainty is represented in the graphics due to each measurement being a small semi-transparent dot. Next, we'll put the output of the statistics on the plot: mean, std, and kurtosis.

If it all possible, don't use links to your home directory. Its not robust. It would be like if you clicked on your Google Music and it told you to ask me to sing that song to you. Imagine that on auto-repeat next time your fancy-bone itches.

I have set up new summary pages for the 40m: http://www.ligo.caltech.edu/~misi/summary/
This website shows plots (time series, spectra, spectrograms, Rayleigh statistics) of relevant channels and is updated with new data every 30 min.

The content and structure of the pages is determined by configuration files stored in nodus:/users/public_html/gwsumm-ini/ . The code looks at all files in that directory matching c1*.ini. You can look at the c1hoft.ini file to see how this works. Besides, a quick guide to the format can be found here http://www.ligo.caltech.edu/~misi/iniguide.pdf

Please look at the pages and edit the config files to make them useful to you. The files are under version control, so don’t worry about breaking anything.

Do let me know if you have any questions (or leave a comment in the pages).

How to get your own web page running on Nodus

1. On any martian machine, put your stuff in /users/public_html/$MYPAGE/
2. On Nodus, run: ln -s /users/public_html/$MYPAGE /export/home/
3. Your site is now available at https://nodus.ligo.caltech.edu:30889/$MYPAGE/
4. If you want to allow straight up directory listing to the entire internet, on Nodus run: sudoedit /etc/sites-available/nodus, and add the following lines towards the bottom:

Also, EQ gave us a better (and not pwd protected) URL for the summary pages. Please replace your previous links with this new one:

https://nodus.ligo.caltech.edu:30889/detcharsummary/

Like Steve pointed out, the summary pages show that the y-arm transmission drifts a lot when locked. The OL summary page shows that this is all due to ITMY yaw.

Could be either that they coil driver / DAC is bad or that the suspension is poorly built. We need to dig into ITMY OL trends over long term to see if this is new or now.

Also, weather station needs a reboot. And does anyone know what the MC_F calibration is?

I have created a wiki page with introductory info about the summary page configuration: https://wiki-40m.ligo.caltech.edu/Daily summary help

We can also use that to collect tips for editing the configuration files, etc.

The CDSUTILS package has a feature where it substitutes in a C1 or H1 or L1 prefix depending upon what site you are at. The idea is that this should make code portable between LLO and LHO.

Here at the 40m, we have no need to do that, so its better for us to be able to copy and paste channel names directly from MEDM or whatever without having to remove the "C1:" from all over the place.

the way to do this on the command line is (in bash) to type:

export IFO=''

To make this easier on us, I have implemented this in our shared .bashrc so that its always the case. This might break some scripts which have been adapted to use the weird CDSUTILS convention, so beware and fix appropriately.

This makes things act weird:

controls@pianosa|MC 1> z avg 1 "C1:LSC-TRY_OUT"
IFO environment variable not specified.

Too weird. I undid me changes. We'll have to make the C1: stuff work inside each python script.

LLO Operator Tips:

koji.arai@cr9:/opt/rtcds/userapps/trunk/asc/l1/scripts/initial_alignment$ cat autostart_strips.sh 
 

#!/bin/bash

# Baffle window setup 1500x480

StripTool -xrm 'StripTool.StripGraph.geometry:1500x470+0+24' /opt/rtcds/userapps/trunk/asc/l1/scripts/initial_alignment/baffle_pd.stp &
sleep 1

# DC signals setup

StripTool -xrm 'StripTool.StripGraph.geometry:1500x470+0+470' /opt/rtcds/userapps/trunk/asc/l1/scripts/initial_alignment/dc_signals.stp &
sleep 1

# WFS prx mich sry setup

StripTool -xrm 'StripTool.StripGraph.geometry:1500x470+0-24' /opt/rtcds/userapps/trunk/asc/l1/scripts/initial_alignment/wfs_prx_mich_sry.stp &
sleep 1

exit

In order to do online static IIR Wiener filtering one needs to do the following,

1) Get data for FIR Wiener filter witnesses and target.

2) Measure the transfer function (needs to be highly coherent, ~ 0.95 for all points) from the actuactor to the control signal of interest (ie. from MC2_OUT to MC_L).

3) Invert the actuator transfer function.

4) Use Vectfit or (LISO) to find a ZPK model for the actuator transfer and inverse transfer functions.

5) Prefilter your witness data with the actuator transfer function, to take into account the actuator to control transfer function when designing the offline Wiener FIR filter.

6) Calculate the frequency response for each witness from the FIR coefficients.

7) Vectfit the frequency reponses to a ZPK model, this is the FIR to IIR Wiener conversion step.

8) Now, either, divide the IIR transfer function by the actuator transfer function or more preferably, multiply by the inverse transfer function.

9) Use Quack to make SOS model of the IIR Wiener filter and inverse transfer function product that goes into foton for online implementation.

10) Load it into the system.

The block diagram below summarizes the steps above.

Frustrated by the single pixel width of the windows and how hard that makes it to drag things around, I explored StackExchange:

which showed how there is a .xml file which can be edited to increase this. I've changed the border size to 4 pixels on Rossa - its nice.

Herein, I will describe the current settings and procedures used to achieve the DRFPMI lock, cobbled together from scripts, burts and such. 

Initial Alignment

1. With arms POX/POY locked, run dither alignment servos. Set transmon QPD offsets here
2. Restore "PRMI Carrier" configuration, run BS and PRM dither alignment servos simultaneously. (Note: this sacrifices some X arm alignment for better dark port alignment. In practice no appreciable loss of TRX is observed)
3. Misalign PRM, align SRM and tune SRM alignment by eye while looking at AS camera. 
4. Restore POX/POY arm lock, lock green to arms, check that powers are high enough and align if neccesary.

Initial Configuration

CARM, DARM

For CARM and DARM, the A channels are used for the ALS signals, whereas the B channels are used for blending the RF signals. 

ALS

• BEATX and BEATY, I and Q channels: +0dB Whitening Gain, Whitening Filters ON
• Green beatnotes somewhere between 20-80MHz, following sign convention of temperature slider UP makes beat freq go UP.  Check spectrum of PHASE_OUT_HZ vs references in ALS_outOfLoop_Ref.xml. The locking script automatically sets the correct phase tracker gain, so no need to adjust manually.
• CARM_A = -1.0 x ALSX + 1.0 x ALSY, G=1.0
• DARM_A = 1.0 x ALSX + 1.0 x ALSY, G=1.0

RF

• CM Board: REFL11 I daugher board output -> IN1, IN1 Enabled, -32dB input gain, 0.0V offset, all boosts off, AO polarity positive, AO gain +0dB
• MC Board: IN2 disabled, -32dB input gain
• CM_SLOW: +0dB Whitening Gain, Whitening ON, LSC-CM_SLOW_GAIN = -5e-4 (Though, it would be good to reallocate this gain to the input matrix element)
• CARM_B = 1.0 x CM_SLOW, FM4 FM10 ON, G=0 (FM4 = LP700 for AO crossover stability, FM10 = 120:5k for coupled cavity pole compensation)
• AS55: +9dB Whitening Gain, Whitening filters manual, Demod angle -37.0
• DARM_B = -1e-4 x AS55 Q, G=0

DRMI 3F

For the DRMI, the A channels are used for the 1F signals, whereas the B channels are used for the 3F signals. The settings for transitioning to 1F after locking the DRFPMI have not yet been determined. 

These settings are currently saved in the DRMI configurator, but the demod angles are set for DRFPMI lock, so the settings don't reliably work for misaligned arms. 

• REFL33: +30dB Whitening Gain, Whitening filters trigger on DRMI lock, Demod angle: 136.0
• REFL165: +24dB Whitening Gain, Whitening filters trigger on DRMI lock, Demod angle: -111.0
• POP22: +15dB Whitening Gain, Whitening filters OFF, Demod angle: -114.0
• AS110: +36dB Whitening Gain, Whitening filters OFF, Demod angle: -116.0
• POPDC: +0dB Whitening Gain, Whitening filters OFF (used as a supplemental trigger signal when CARM and DARM are buzzing and POP22 fluctuates wildly)
• MICH_B = 6.0 x REFL165Q, offset = 15.0
• PRCL_B = 5.0 x REFL33I, offset = 45.0
• SRCL_B = -0.6 x REFL165I + 0.24 x REFL33 I, offset=0

The REFL33 element in SRCL_B is to reduce the PRCL coupling, was found empirically by tuning the relative gains with the arms misaligned and looking at excitation line heights. The offsets were found by locking the DRMI on 1F signals with arms misaligned, and taking the average value of these 3F error signals.  

Servo filter configuration

The CARM and DARM ALS settings are largely scripted by scripts/ALS/Transition_IR_ALS.py, which takes you from arms POX/POY locked to CARM and DARM ALS locked. The DRMI settings are usually restored from the IFO_CONFIGURE screen. 

• CARM: FM[1, 2, 3, 5, 6] , G=4.5, Trigger forced on, no FM triggers, output limit 8k
• DARM: FM[1, 2, 3, 5, 6] , G=4.5, Trigger forced on, no FM triggers, output limit 8k
• MICH: FM[4, 5], G= -0.03, Trigger POP22 I x 1.0 [50, 10], FM[2, 3, 7] triggered [50, 10], output limit 20k
• PRCL: FM[4, 5], G= -0.003, Trigger POP22 I x 1.0 [50, 10], FM[1, 2, 8, 9] triggered [50, 10], output limit 8k
• SRCL: FM[4, 5], G= -0.4, Trigger AS110 Q x 1.0 [500, 100], FM[2, 7, 9] triggered [500, 100], output limit 15k

Actuation Output matrix

• MC2 = -1.0 x CARM
• ETMX = -1.0 x DARM
• ETMY = 1.0 x DARM
• BS = 0.5 x MICH
• PRM = 1.0 x PRCL - 0.2655 MICH
• SRM = 1.0 x SRCL + 0.25 MICH (The mich compensation is very roughly estimated)

Locking Procedure

When arms are POX/POY locked, and the green beatnotes are appropriately configured, calling scripts/DRFPMI/carm_cm_up.sh initiates the following sequence of events:

• Turn ON MC length feedforward and PRC angle feedforward
• Set ALS phase tracker UGFs by looking at I and Q magnitudes
• Set LSC-ALSX and LSC-ALSY offsets by averaging, ramp CARM+DARM gains up, XARM+YARM gains down, engage CARM+DARM boosts, now ALS locked
• Move CARM away from resonance, offset = -4.0 (DRMI locks quicker on this side for whatever reason)
• Restore PRM, SRM alignment. Set DRMI A FM gains to 0, B FM gains to 1.0. Enable LSC outputs for BS, PRM, SRM
• When DRMI has locked, add POPDC trigger elements to DRMI signals and transition SRCL triggering to POP22I. NB: In the c1lsc model, the POPDC signal incident on the trigger matrix has an abs() operator applied to it first. 
  • MICH Trig = 1.0 x POP22 I + 0.5 x POPDC, [50, 10]
  • PRCL Trig = 1.0 x POP22 I + 0.5 x POPDC, [50, 10]
  • SRCL Trig = 10.0 x POP22 I + 5 x POPDC, [500, 100]
• Reduce POX, POY whitening gains from their nominal +45dB to +0dB, so there aren't railing channels making noise in the whitening chassis and ADCs
• DC couple ITM oplevs (average spot position, set FM offset, turn on DC boost filter, let settle)
• With an 8 second ramp, reduce CARM offset to 0 counts. 
• MANUALLY adjust CARM_A and DARM_A offsets to where CARM_B_IN and DARM_B_IN are seen to fluctuate symetrically around their zero crossing.
  • Note: Last week, this adjustment tended to be roughly the same from lock to lock, unlike the PRFPMI which generally didn't need much adjustment. Also, by jumping from CARM offset of -0.4 to 0.4, it could be seen that the zero crossing in  CARM_B aka CM_SLOW aka REFL11 had some offset, so CARM_B_OFFSET was set to 0.005, but this may change. 

When CARM and DARM are buzzing around true zero, powers maximized:

• CARM and DARM FM1 (18,18:1,1 boosts) OFF
• CARM_B_GAIN 0.0 -> 1.0, FM7 ON (20:0 boost)
• DARM_B_GAIN 0.0 -> 0.015, FM7 ON (20:0 boost) 
• MC servo board IN2 ENABLE, IN2 gain -32dB -> -16dB
• Turn ALL MC2 violin filters OFF (smoothen out AO crossover)
• If stable, CM board IN1 gain -32dB -> -10dB (This is the overall CARM gain, the arm powers stabilize within the last few dB of this transition)
• CARM_A_GAIN 1.0 -> 0.7
• CARM_A FM9 ON (LP1k), sleep, FM 1 ON (1:20 deboost), sleep, FM 2 ON (1:20 deboost), HOLD OUPUT, CARM now RF only
• DARM_B_GAIN 0.015 -> 0.02, sleep, DARM_A_GAIN 1.0 -> 0.0 (This may not be the ideal final DARM_B gain, UGF hasn't been checked yet)

IFO is now RF only!

• Turn on transmon QPD servos.
• Adjust comm/diff QPD servo offsets to correct any problems evident on AS/REFL cameras. This usually brings powers from ~100-120 to ~130-140. 

This is as far as we've taken the DRFPMI so far, but the CARM bandwidth is still only at a few kHz. Based on PRFPMI locking, the next steps will be:

• CM BOARD +12dB or so additional IN1 gain, more AO gain may be needed to get crossover to final position of ~100Hz
• MC2 viollin filters back on
• CM boost(s) on
• AS55 whitening on
• Transition DRMI to 1F

Today image capture did not work again, though it had worked 3 days before. I also found that red indicator light on the front pannel of SENSORAY was not turned on, which had been turned on 3 days before (you can find SENSORAY on the floor near Pianosa). Possible reason that it did not work again was I restarted Pianosa last night. Anyway, it works now. Here I report what I did to make it work.

I ran thes commands in shell, following the instruction of the manual of SENSORAY 2253 (Page 5; link or you can find the manual in /users/sensoray; I put it there). 

> cd /users/sensoray/sdk_2253_1.2.2_linux

> make all

> sudo make install

> modprobe s2253

Then the red light got turned on, and image capture worked.

If you recieve an error like "No such file or directory: /dev/video0" at the beginning of the error message when you run image capture scripts from the medm screen, or if you notice that the red indicator light of SENSORAY is not on, this procedure could help you. 

Do we need "make" everytime? Do you mean just running "modprobe" didn't work?

I don't know if just running "modprobe" will work or not, because I didn't try it...  When the same problem happens again, we can try just running "modprobe" first.

The door was not locked this morning.

Please do not use this door if you can not close it!

Last person leaving the lab should check that the latch is cut by the strike plate.

This is one of those unsolved door lock acquisition problems. Its been happening for years.

Please ask facilities to increase the strength of the door tensioner so that it closes with more force.

It was requested this morning.

The attached file is a python notebook that you can use to get data. Minimal syntax.

Minute trend data seems not available using the NDS2 server. Its super slow using dataviewer from the control room.

Did some digging into the NDS2 config on megatron. It hasn't been updated in 2 years.

All of the stuff is run by the user 'nds2mgr'. The CronTab for this user was running all the channel name updates and server restarts at 3 AM each day; I've moved it to 5:05 AM. I don't know the password for this user, so I just did 'sudo su nds2mgr' to become him.

On megatron, in /home/nds2mgr/nds2-megatron/ there is a list of channels and configs. The file for the minute trend (C-M-ChanList.txt), hasn't been updated since Nov-2015. ???

Summary:

I have written a code(a basic one which needs a lot of improvements, but still does the job) for taking multiple measurements from the AG4395A. I have also written a separate code for plotting the data taken from the previoius code along with the error bars upto 1 standard deviation.

Details on How To Operate AG4395A:

1. Under 'Measurement' tab, press the 'Meas' button and select the Analyzer Type (Network Analyzer or Spectrum Analyzer).
2. Then under the same options select which 'ratio' needs to be measured (A/R, B/R or A/B).
3. Then press the 'Format' button to select what needs to be measured (Eg - Log|Mag|, Phase, etc.).
4. In order to measure and see two channels at the same time (Eg - Log|Mag| and Phase), press the 'Display' button and select 'Dual Channel'.
5. Using the 'Scale' button we can set the scale/div or use autoscale and also set the attenuator values of the different channels.
6. The 'Bw/Avg' option gives us an averaging option which averages few sets of data to produce the result. In doing this we lose quiet a lot of data and the resulting plot isn't able to give us the information on the statistical errors.
7. This option also allows us to set the 'Intermediate Frequency' Bandwidth. This basically dictates the sampling rate of the Analyzer. The lower the IF bw, the higher is lesser is the noise (due to less uncertainty in Frequency).
8. The 'Cal' button helps us calibrate the Analyzer to the current connections and signals. This is done because there is usually a difference in the 'cable lengths' for the two channels which introduces an extra phase term depnding upon the rf frequency. The calibration can be simply done by removing the Device Under Test (DUT) and diectly connecting the coaxial cables to the channels. After this the 'Calibrate Menu' allows us to calibrate the response using the short, open and thru methods.
9. Now, under the 'Sweep' tab, the 'Sweep' button allows us to select various sweep options such as 'Sweep Time' (Auto, or set a time), 'Number of Points' (b/w 201-801) and 'Sweep Type' (Linear, Log, List Freq. etc.).
10. Using the 'Source' button we can set the source power in dBm units (Usually kept as -20 to -10 dBm).
11. The Scan Range can be set in a few ways such as using the start and end points or using the center and span range/width.
12. After setting up all of the above, we can take the measurement either from the analyzer itself or using one of the control PCs. The command to download the data from AG4395A is netgpibdata -i 192.168.113.105 -d AG4395A -a 10 -f [filename].

Brief Details on How the 'AGmeasure' command works:

AGmeasure is a python script developed by some of the people who work at 40m. It is set as a global command and can be used from within any directory. The source code is in the scripts folder on the network, or else it can also be found in Eric Quintero's git repository. This command accepts at the very least a parameter file. This is supposed to be a .yml file. A template (TFAG4395Atemplate.yml) can be found in the scripts folder or in Eric's repo. There are some other options that can be passed to this command, see the help for more details.

The Multi_Measurement Script:

This script calls the 'AGmeasure' command repetitively and keeps storing the data files in a folder. Right now, the script needs to be fed in th template file manually at prompt.

The Test_Plotting Script:

This script plots the a set of data files obtained from the above mentioned script and produces a plot along with the errors bands upto 1 standard deviation of the data. The format (names) and total number of text files need to be explicitly known, for now at least.

Attachments:​

1. The output test files and the two scripts.
2. This is the 'Bode Plot' for a data set made using the above two scripts.

To Do:

• Improve upon the two scripts to be as compatible as the AGmeasure function itself.
• Try and incorporate the whole script into AGmeasure itself along with improving upon the templates.
• The above details, with some edits perhaps, can go into the 40m wiki too(?).

Update: Increased the font size in the plot. Added a few comments to the two scripts

To Do: Need to consider the transfer function as a single physical quantity (both the magnitude and phase) and then take the averages and calculate the standard deviation and then plot these results. 

EDIT:

The attachment with the test files and the code now also contains a pdf with all the relations/equations I have used to calculate the averages and errors.

Summary:

The following elog describes the procedure followed for generating a sample simulation for a cavity scan, fitting an actual cavity scan and calculating the relevant paramaters using the cavity scan and fit data.

1. Cavity Scan Simulation:

1. First, we define the sample cavity parameters, i.e., the reflectivitie,transmissivities of the mirrors, the RoCs of the mirrors and the absolute cavity length.
2. We then define a frequency range using numpy.linspace function for which we want to take a scan.
3. We then define a function that returns the tranmission power output of a Fabry-Perot cavity using the cavity equations as follows:  where P_t is the transmission power ratio of the output power to input power, t₁,t₂,r₁,r₂ are the transmissivities and reflectivities of the two mirrors, L is the absolute cavity length, f is the frequency of the input laser, c is the speed of light,  is the gouy phase shift with g₁,g₂ being the g-factors for the two cavity mirrors(g=1-L/R). 'n' and 'm' correspond to the TEM_nm higher order mode.
4. We now obtain a cavity scan by giving the above defined function the cavity parameters and by adding the outputs for different higher order mode('n', 'm' values). Appropriate factors for the HOMs need to be chosen. The above function with appropriate coefficients can be used ti also add the modulated sidebands to the total transmission power.
5. To this obtained total power we can add some random noise using numpy modules random.normal function. We need to normalise the data with respect to the max. power transmission ratio.
6. We can now perform fitting on the above data using the procedure stated in the next section and then plot the two data sets using matplotlib module.
7. A similar code to do the above is given here.

2. Fitting a Cavity Scan:

1. The actual data for a cavity scan can be found in this elog entry or attached below in the zip folder.
2. We read this data and separate the frequency data and the transmission data.
3. Using the peakutils module's indexes function, we find the indices of the various peaks in the data set.
4. These peaks are from the fundamental resonances, sideband resonances(both 11MHz and 55MHz) as well as a few HOMs.
5. Each of these resonances follows the cavity equations and hence can be modelled as Lorentzian within small intervals around the peak frequencies. A detailed description of how this is possible is given here and is in the atached zip folder('Functionsused.pdf').
6. We define a Lorentzian function which returns the follows:  where 'a' is the peak transmission value, 'b' is the 'linewidth' of the Lorentzian and  is the peak frequency  about which the cavity equations behave like a lorentzian.
7. We now, using the Lorentzian function, fit the various identified peaks using the curve_fit function of the scipy module. Remember to turn the 'absolute_sigma' parameter to 'True'.
8. The parameters now obtained can be evaluated using the procedure given in the next section.
9. The total transmission power is evaluated by feeding in the above obtained parameters back into the Lorentzian function and adding it for each peak.
10. We can plot the actual data set and the data obtained using the fit of different peaks in a plot using matplotlib module. We can also plot the residuals for a better depiction of the fit quality.  
11. The code to analyse the above mentioned cavity scan data is given here and attached below in the zip folder.

3. Calculating Physically Relevant Parameters:

1. The data obtained from the fitting the peaks in the previous section now needs to be analysed in order to obtain some physically relevant information such as the FSR value, the TMS value, the modulation depths of the sidebands and perhaps even the linear caliberation of the frequency.
2. First we need to identify the fundamental, TEM₀₀ resonances among all the peaks. This we do by using the numpy.where function. We find the peaks with transmission values more than 0.9(or any suitable value).
3. Using these indices we will now calculate the FSR and the Finesse of the peaks. A description of the correlation between the Fit Parameters and the FSR and Finesse is given here.
4. We define a Linear fitting function for fitting the frequency values of the fundamental resonances against the i^th fundamental resonance. The slope of this line gives us the value of FSR and the error in it.
5. The Finesse can be calculated by fitting the linewidth with a constant function.
6. The cavity length can be calculated using the FSR values as follows: .
7. Now, the approximate positions of the sideband frequncies is given by 11*10⁶%FSR and 55*10⁶%FSR away from the fundamental, carrier resonances.
8. The modulation depth, 'm', is given as  where P_c is the carrier transmission power, Ps is the transmission power of the sideband and J_v is the Bessel Function of order 'v'.
9. We define a function 'Bessel Ratio' using which we'll fit the transmission power ratio of the carrier to the sideband for the multiple sideband resonances.
10. We also check for the Linearity in frequency data by plotting Fitting the frequencies corresponding to peaks in the actual data to ones obtained after fitting.
11. After this we attempt to identify the other HOMs. For this we first determine a rough estimate for the value of TMS using the already known parameters of the mirrors,i.e., the RoC. We then look in small intervals (0.5 MHz) around frequencies where we would expect the HOMs to be, i.e., 1*TMS, 2*TMS, 3*TMS... away from the fundamental resonances. These positions are all modulo FSR.
12. After identifying the HOMs, we take the difference from the fundamental resonance and then study these modulo the FSR.
13. We perform a Linear Fit between these obtained values and (n+m).  As 'n','m' are degenerate, we can simply perform the fit against some variable 'k' and obtain the value of TMS as the slope of the linear fit.
14. The code to do the above stated analysis is given here.

Most of the above info and some smaller details can be found in the markdown readme file in this git repo.

I've modified the __init.py__ file located at /ligo/apps/linux-x86_64/cdsutils-480/lib/python2.7/site-packages/cdsutils/__init__.py so that you can now simply import pyawg from cdsutils. On the control room workstations, iPython is set up such that cdsutils is automatically imported as "cds". Now this import also includes the pyawg stuff. So to use some pyawg function, you would just do (for example):

One could also explicitly do the import if cdsutils isn't automatically imported:

pyawg-away!

Linking this useful instructional elog from Chris here: https://nodus.ligo.caltech.edu:8081/Cryo_Lab/1748

?  Why aren't you able to just import 'awg' directly?  You shouldn't have to import it through cdsutils.  Something must be funny with the config.

Going through some astronomy CCD calibration resources ([1]-[3]), I gather that there are in general 3 distinct types of correction that are applied:

1. Dark frames --- this would be what we get with a "zero duration" capture, some documents further subdivide this into various categories like thermal noise in the CCD / readout electronics, poissonian offsets on individual pixels etc.
2. Bias frames --- this effect is attributed to the charge applied to the CCD array prior to the readout.
3. Flat-field calibration --- this effect accounts for the non-uniform responsivity of individual pixels on the CCDs. 

The flat-field calibration seems to be the most complicated - the idea is to use a source of known radiance, and capture an image of this known radiance with the CCD. Then assuming we know the source radiance well enough, we can use some math to back out what the actual response function of individual pixels are. Then, for an actual image, we would divide by this response-map to get the actual image. There are a number of assumptions that go into this, such as: 

• We know the source radiance perfectly (I guess we are assuming that the white paper is a Lambertian scatterer so we know its BRDF, and hence the radiance, perfectly, although the work that Jigyas and Amani did this summer suggest that white paper isn't really a Lambertian scatterer). 
• There is only one wavelength incident on the CCD.
• We can neglect the effects of dust on the telescope/CCD array itself, which would obviously modify the responsivity of the CCD, and is presumably not stationary. Best we can do is try and keep the setup as clean as possible during installation.

I am not sure what error is incurred by ignoring 2 and 3 in the list at the beginning of this elog, perhaps this won't affect our ability to estimate the scattered power from the test-masses to within a factor of 2. But it may be worth it to do these additional calibration steps. 

I also wonder what the uncertainty in the 1.5V/A number for the photodiode is (i.e. how much do we trust the Ophir power meter at low power levels?). The datasheet for the PDA100A says the transimpedance gain at 60dB gain is 1.5 MV/A (into high impedance load), and the Si responsivity at 1064nm is ~0.25A/W, so naively I would expect 0.375 V/uW which is ~factor of 4 lower. Is there a reason to trust one method over the other?  

Also, are the calibration factor units correct? Jigyasa reported something like 0.5nW s / ct in her report.

References:

[1] http://www.astrophoto.net/calibration.php

[2] https://www.eso.org/~ohainaut/ccd/

[3] http://www.astro.ufl.edu/~lee/ast325/handouts/ccd.pdf

Disclaimer: Wrong calibration factors! See https://nodus.ligo.caltech.edu:8081/40m/13391

The factors were indeed enormously off. The correct table reads:

I did subtract a 'dark' frame from the images, though not in the sense of your point 1, just an exposure of identical duration with the laser turned off. This was mostly to reduce the effect of residual light, but given similar initial conditions would somewhat compensate for the offset that pre-existing charge and electronics noise put on the pixel values. The white field is of course a difference story.

I wonder how close we can get to a white field by putting a thin piece of paper in front of the camera without lenses and illuminate it from the other side. A problem is of course the coherence if we use a laser source... Or we scrap any sort of screen/paper and illuminate directly with a strongly divergent beam? Then there wouldn't be a specular pattern.

I'm not sure I understand your point about the 1.5V/A. Just to make sure we're talking about the same thing I made a crude drawing:

The PD sees plenty of light at all times, and the 1.5V/uW came from a comparative measurement PD<-->Ophir (which took the place of the CCD) while adjusting the power deflected with the AOM, so it doesn't have immediate connection to the conversion gain of silicon in this case. I can't remember the gain setting of the PD, but I believe it was 0dB, 20dB at most.

I calculated a better lens solution for the ETMX side view with the simple python script that's attached. The camera is still not as close to the viewport as we would like, and now the front lens is almost all the up to the end of the tube. With a little more playing around there maybe a better way, especially if we expand the repertoire of focal lengths. Using Steve's wonderful camera fixture I put the beam spot in focus. I turned the camera sideways for better use of the field of view, and now the beam spot actually fills the center area of the beam, to the point where we probably don't want more magnification or else we start losing the tails of the Gaussian.

We'll take a serious of images tomorrow, and will have an estimate of the scatter loss by the end of tomorrow.

 Telescope front lens to wall distance 25 cm,  GigE camera lenght 6 cm and cat6 cable 2cm

 Atm3,   Existing short camera  can has 16cm  lenght to lexan guard on viewport. Available 2" od periscope tube lenght is 8cm. The one in use 16 cm long.

             Note: we can fabricate a lite cover with tube that would accomodate longer telescope.

             Can we calibrate the AR coated M5018-SW and compare it's performance agains the 2" periscope

             Look at the Edmond Optics 3" od camera lens with AR

This lower priced   1" apeture Navitar lens  can be an option too.

 Atm1,   Now I can see dust. This is much better. The focus is not right yet.

Atm2,   Chamber viewport wiped and image refocused. Actually I was focusing on the dust.

We don't really have to calibrate the lens, just the CCD, which we've done. It's more about knowing the true aperture size to know how much solid angle you're capturing to infer the total amount of scatter. For our custom lens tubes this is the ID of the retaining ring.

The Edmund Optics lens tube looks tempting, but itcomes at a price. Thorlabs sells lens tubes that offer a more flexibility than what we have right now, so I bought a few different ones, and also more 150mm 2" lenses. This will allow for more compact solutions and offer some in-situ focusing ability that doesn't require detaching the lens tube like now. Should be here in a couple of days, then we'll be able to enclose the GigE camera in the viewport can with a similar field of view we have now.

I also bought a collimation package for the AS port fiber stuff so we can move ahead with the ringdown measurements and also mode spectroscopy.

The units were still off in my previous post. Here's the corrected, sanity-checked version:

I estimated the uncertainties based on a linear fit to the data I recorded with 75nW incident on the CCD and assumed a 5% uncertainty in that number. This is just an upper limit, to be safe. I had calibrated the power reading placing the Ophir power meter where the CCD would otherwise be and comparing it to the PD voltage of a picked off beam. In my previous figures the axes were mislabeled, so I reproduce them here:

Using the current camera position I recorded 50 exposures both with and without beam (XARM locked vs PSL shutter closed) and averaged the images to see how much the reading fluctuates. The exposure time was 10 ms, which left the maximum reported pixel value in all exposures below 3800 out of 4096. The gain setting was 100, which is what I used to calibrate the CCDs.

(*) I calculated the lens positions to focus at a plane 65cm from the front lens. We're pretty close to that, but I can't confirm the actual distance easily, so I assumed a 5cm error on the distance, which is where most of the error is coming from. This is also assuming uniform scatter.

(**) This is assuming 10W of circulating power

Since we're getting ready to put the replacement slow DAQ for c1auxex in I wanted to bring the IFO back to operating condition after the PMC hasn't been locked for days. Something seems wrong with the CDS system though, many of the frontent models have red background and don't seem to be responsive. I followed the instructions laid out in https://wiki-40m.ligo.caltech.edu/Computer_Restart_Procedures.

In the attached screenshot, initially all c1ioo models were red, and on c1iscex only c1x01 was blue, the other ones red. I was able to ssh into both machines and tried to restart indivitual models, which didn't work and instead turned their background white. Still following the wiki page, I restarted both machines but they don't respond to pinging anymore and thus I cannot use ssh to reach them. Not sure what to do, I also rebooted fb over telnet.

So far I couldn't find any records of how to fix this situation.

Once a realtime machine was rebooted, it did not come back. I suspect that the diskless hosts have a difficulty to boot up.

[Koji, Johannes]

The issue was partially fixed and the interferometer is in workable condition now.

What -probably- fixed it was restarting the dhcp server on chiara

Afterwards the frontends were restarted one by one. SSH access was possible and the essential models for IFO operation were started.

c1iscex reported initially that no DAQ card was found, and inside the IO chassis the LED indicator strip was red. Turning off the machine, checking the cables and rebooting fixed this.

Summary:

I checked the calibration of the Oplevs for both ITMs, both ETMs and the BS. The table below summarizes the old and new cts->urad conversion factors, as well as the factor describing the scaling applied. Attachment #1 is a zip file of the fits performed to calculate these calibration factors (GPS times of the sweeps are in the titles of these plots). Attachment #2 is the spectra of the various Oplev error signals (open loop, so a measure of seismic induced angular motion for a given optic, and DoF) after the correction. Loop TF measurements post calibration factor update and loop gain adjustment to be uploaded tomorrow.

Motivation:

We'd like for the Oplev calibration to be a reliable readback of the optic alignment. For example, a calibrated Oplev would be a useful diagnostic to analyze the drifting (?) ETMX.

Details:

1. I locked and dither aligned the individual arms.
2. I then used a 60 second ramp time to misalign <optic> in {ITMX, ITMY, BS, ETMX, ETMY} one at a time, and looked at the appropriate arm cavity transmission while the misalignment was applied. The amplitude of the misalignment was chosen such that in the maximally misaligned state, the arm cavity was still locked to a TEM00 mode, with arm transmission ~40% of the value when the cavity transmission was maximized using the dither alignment servos. The CDS ramp is not exactly linear, it looks more like a sigmoid near the start and end, but I don't think that really matters for these fits.
3. I used the script OLcalibFactor.py (located at /opt/rtcds/caltech/c1/scripts/OL) to fit the data and extract calibration factors. This script downloads the arm cavity transmission and the OL error signal during the misalignment period, and fits a Gaussian profile to the data (X=oplev error signal, Y=arm transmission). Using geometry and mode overlap considerations, we can back out the misalignment in physical units (urad).

Comments:

1. For the most part, the correction was small, of the order of a few percent. The largest corrections were for the ETMs. I believe the last person to do Oplev calibration for the TMs was Yutaro in Dec 2015, and since then, we have certainly changed the HeNes at the X and Y ends (but not for the ITMs), so this seems consistent.
2. From attachment #2, most of the 1Hz resonances line up quite well (around 1-3urad/rtHz), so gives me some confidence in this calibration.
3. I haven't done a careful error analysis yet - but the fits are good to the eye, and the residuals look randomly distributed for the most part. I've assumed precision to the level of 1 urad/ct in setting the new calibration factors.
4. I think the misalignment period of 60 seconds is sufficiently long that the disturbance applied to the Oplev loop is well below the lower loop UGF of ~0.2Hz, and so the in loop Oplev error signal is a good proxy for the angular (mis)alignment of the optic. So no loop correction factor was applied.
5. I've not yet calibrated the PRM and SRM oplevs.

​Now that the ETMX calibration has been updated, let's keep an eye out for a wandering ETMX.

Gautam and Steve,

We have calibrated the load  cells. The support beams height monitoring is almost ready.

The danger of this measurment that  the beams height changes can put shear and torsional forces on this formed (thin walled) bellow

They are designed for mainly axial motion.

The plan is to limit height change to 0.020" max

0, center oplev at X arm locked

1, check that  jack screws are carrying full loads and set height indicator dials to zero ( meaning: Stacis is bypassed )

2, raise beam height with aux leveling wedge  by 0.010"  on all 3 support point and than raise it an other 0.005"

3, replace levelling wedge with load cell that is centered and shimmed.     Dennis   Coyne pointed out that the Stacis foot has to be loaded at the center of the foot and formed bellow can shear at their limits.

4, lower the support beam by 0.005" ......now full load on the cells

Note: jack screw heights will not be adjusted or  touched.......so the present condition will be recovered

[ Dennis Coyne'  precision answer ]

Differential Height between Isolators

According to a note on the bellows drawing (D990577-x0/A), the design life of the bellows at ± 20 minutes rotational stroke is 10,000 cycles. A 20 minute angular (torsional) rotation of the bellows corresponds to 0.186" differential height change across the 32" span between the chamber support beams (see isolator bracket, D000187-x0/B).

Another consideration regarding the bellows is the lateral shear stress introduced by the vertical translation. The notes on the bellows drawing do not give lateral shear limits. According to MDC's web page for formed bellows in this size range the lateral deflection limit is approximately 10% of the "live length" (aka "active length", or length of the convoluted section). According to the bellows drawing the active length is 3.5", so the maximum allowable lateral deflection should be ~0.35".

Of course when imposing a differential height change both torsional and lateral shear is introduced at the same time. Considering both limits together, the maximum differential height change should be < 0.12".

One final consideration is the initial stress to which the bellows are currently subjected due to a non-centered support beam from tolerances in the assembly and initial installation. Although we do not know this de-centering, we can guess that it may be of the order of ~ 0.04". So the final allowable differential height adjustment from the perspective of bellows stress is < 0.08".   Steve:  accumulated initial stress is unknown.  We used to adjust the original jack screws for IFO aligment in the early days of ~1999. This kind of adjustment was stopped when we realized how dangereous it can be. The fact is that there must be unknown amount of accumulated initial stress. This is my main worry but I'm confident that 0.020" change is safe.

So, with regard to bellows stress alone, your procedure to limit the differential height change to <0.020" is safe and prudent.

However, a more stringent consideration is the coplanarity requirement (TMC Stacis 2000 User's Manual, Doc. No. SERV 04-98-1, May 6, 1991, Rev. 1), section 2, "Installation",which stipulates < 0.010"/ft, or < 0.027" differential height across the 32" span between the chamber support beams. Again, your procedure to limit the differential height change to < 0.02" is safe.

Centered Load on the STACIS Isolators

According to the TMC Stacis 2000 User's Manual (Document No. SERV 04-98-1, May 6, 1991, Rev. 1), section 2, "Installation", typical installations (Figure 2-3) are with one payload interface plate which spans the entire set of 3 or 4 STACIS actuators. Our payload interface is unique.

Section 2.3.1, "Installation Steps": "5. Verify that the top of each isolator is fully under the payload/interface plate; this is essential to ensure proper support and leveling. The payload or interface plate should cover the entire top surface of the Isolator or the entire contact area of the optional jack."

section 2.3.2, "Payload/STACIS Interface": "... or if the supporting points do not completely cover the top surface of each Isolator, an interface plate will be needed."

The sketch in Figure 2-2 indicates an optional leveling jack which appears to have a larger contact surface area than the jacks currently installed in the 40m Lab. Of course this is just a non-dimensioned sketch. Are the jacks used by the 40m Lab provided by TMC, or did we (LIGO) choose them? I beleive Larry Jones purchased them.

A load centering requirement is not explicitly stated, but I think the stipulation to cover the entire top surface of each actuator is not so much to reduce the contact stress but to entire a centered load so that the PZT stack does not have a reaction moment.

From one of the photos in the 40m elog entry (specifically jack_screw.jpg), it appears that at least some isolators have the load off center. You should use this measurement of the load as an opportunity to re-center the loads on the Isolators.

In section 2.3.3, "Earthquake Restraints" restraints are suggested to prevent damage from earth tremors. Does the 40m Lab have EQ restraints? Yes, it has

Screw Jack Location

I could not tell where all of the screw jacks will be placed from the sketch included in the 40m elog entry which outlines the proposed procedure.

Load Cell Locations

The sketch indicates that the load cells will be placed on the center of the tops of the Isolators. This is good. However while discussing the procedure with Gautam he said that he was under the impression that the load cell woudl be placed next to the leveling jack, off-center. This condition may damage the PZT stack. I suggest that the leveling jack be removed and replaced (temporarily) with the load cell, plus any spacer required to make up the height difference. Yes

If you have any further question, just let me know.

    Dennis

Dennis Coyne
Chief Engineer, LIGO Laboratory
California Institute of Technology
MC 100-36, 1200 E. California Blvd.

follow up email from Dennis 5-13-2018. The last line agrees with the numbers in elog13821.

I copied the netgpibdata folder onto rossa (under the directory ~/Agilent/), which contains all the necessary scripts and templates you'll need to remotely set up, run, and download the results of measurements taken on the AG4395A network analyzer. The computer will communicate with the network analyzer through the GPIB device (plugged into the back of the Agilent, and whose communication protocol is found in the AG4395A.py file in the directory ~/Agilent/netgpibdata/).

The parameter template file you'll be concerned with is TFAG4395Atemplate.yml (again, under ~/Agilent/netgpibdata/), which you can edit to fit your measurement needs. (The parameters you can change are all helpfully commented, so it's pretty straightforward to use! Note: this template file should remain in the same directory as AGmeasure, which is the executable python script you'll be using). Then, to actually set up, run, and download your measurement, you'll want to navigate to the ~/Agilent/netgpibdata/ directory, where you can run on the command line the following: python AGmeasure TFAG4395Atemplate.yml

The above command will run the measurement defined in your template file and then save a .txt file of your measured data points to the directory specified in your parameters. If you set up the template file such that the data is also plotted and saved after the measurement, a .pdf of the plot will be saved along with your .txt file.

Now if you want to just download the data currently on the instrument display, you can run: python AGmeasure -i 192.168.113.105 -a 10 --getdata

Those are the big points, but you can also run python AGmeasure --help to learn about all the other functions of AGmeasure (alternatively, you can read through the actual python script).

Happy remote measuring! :)