40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 82 of 339  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  14947   Tue Oct 8 03:19:14 2019 KojiUpdateCDSFinal incarnation of latch.py

Now with the CM board tested with the signal injected, it turned out that the latch logic was flipped. As the default state locked the digital levels, the buttons other than the mbbo channels were inactive.

By giving 0 to C1:LSC-CM_LATCH_ENABLE, the modification of the digital state is enabled. And with the value of 1, the digital bits on the board is locked.

In order to reflect this, latch.py was modified and now the controls are all activated.

  941   Thu Sep 11 11:29:14 2008 josephbConfigurationComputersFinal netgear switch in place in 1Y2
I've placed the final (of 4) Netgear prosafe 24 port switch at the very top of 1Y2. At that location, there are no holes left to screw into, so it has 4 rubber feet and is sitting on the top most signal generator. It has been plugged in and connected to the control room hub with a labeled cat6 ethernet cable.

Its IP address has been set to 131.215.113.253, and has the usual controls password if using the "Smart Wizard Discovery Tool" which comes on the Netgear CD. The CD can be found in the Equipment manuals filing cabinet under Netgear. This program unfortunately only runs on a window PC.

To Do: Fix the C1:ASC ethernet connection which is currently coming straight out the front door and connected to the 1X4 switch (again through the front door).
  8961   Fri Aug 2 21:59:36 2013 CharlesUpdateISSFinalized ISS Schematic (hopefully)

Attached is the finalized schematic. The general circuit topology should remain the same from this point forward, although individual component values are subject to change. I will also be adding some more annotations to ensure everything on the board is clear.

In general, I have finally included all of the correct components (i.e. front panel switches are now actually switches and front panel LEDs are now included). I also added an external 'Boost' switch, which can be used to enable or disable the boosts. The motivation for including this switch is that one might want to test functionality of the ISS without using the 'fancy' RMS detection and triggering circuitry. Additionally, one can disable the boosts when all the circuitry is stuffed in order to troubleshoot, so it essentially grants the board some flexibility in its operation.

I am now working on the PCB layout and I should hopefully have that done next week. 

Attachment 1: ISS_v3.pdf
ISS_v3.pdf ISS_v3.pdf ISS_v3.pdf ISS_v3.pdf ISS_v3.pdf
Attachment 2: ISS_v3-Power_Reg.pdf
ISS_v3-Power_Reg.pdf
  16988   Mon Jul 11 19:29:23 2022 PacoSummaryGeneralFinalizing recovery -- timing issues, cds, MC1

[Yuta, Koji, Paco]

Restarting CDS

We were having some trouble restarting all the models on the FEs. The error was the famous 0x4000 DC error, which has to do with time de-synchronization between fb1 and a given FE. We tried a combination of things haphazardly, such as reloading the gpstime process using

controls@fb1:~ 0$ sudo systemctl stop daqd_*
controls@fb1
:~ 0$ sudo modprobe -r gpstime
controls@fb1:~ 0$ sudo modprobe gpstime
controls@fb1:~ 0$ sudo systemctl start daqd_*
controls@fb1:~ 0$ sudo systemctl restart open-mx.service

without much success, even when doing this again after hard rebooting FE + IO chassis combinations around the lab. Koji prompted us to check the local times as reported by the gpstime module, and comparing it to network reported times we saw the expected offset of ~ 3.5 s. On a given FE ("c1***") and fb1 separately, we ran:

controls@c1***:~ 0$ timedatectl
  Local time: Mon 2022-07-11 16:22:39 PDT
  Universal time: Tue 2022-07-11 23:22:39 UTC
       Time zone: America/Los_Angeles (PDT, -0700)
       NTP enabled: yes
       NTP synchronized: no
 RTC in local TZ: no
       DST active: yes
 Last DST change: DST began at
                  Sun 2022-03-13 01:59:59 PST
                  Sun 2022-03-13 03:00:00 PDT
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2022-11-06 01:59:59 PDT
                  Sun 2022-11-06 01:00:00 PST
controls@fb1:~ 0$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 192.168.123.255 .BCST.          16 u    -   64    0    0.000    0.000   0.000

which meant a couple of things:

  1. fb1 was serving its time (broadcast to local (martian) network)
  2. fb1 was not getting its time from the internet
  3. c1*** was not synchronized even though fb1 was serving the time

By looking at previous elogs with similar issues, we tried two things;

  1. First, from the FEs, run sudo systemctl restart systemd-timesyncd to get the FE in sync; this didn't immediately solve anything.
  2. Then, from fb1, we tried pinging google.com and failed! The fb1 was not connected to the internet!!!

We tried rebooting fb1 to see if it connected, but eventually what solved this was restarting the bind9 service on chiara! Now we could ping google, and saw this output

controls@fb1:~ 0$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+tor.viarouge.ne 85.199.214.102   2 u  244 1024  377  144.478    0.761   0.566
*ntp.exact-time. .GPS.            1 u   93 1024  377  174.450   -1.741   0.613
 time.nullrouten .STEP.          16 u    - 1024    0    0.000    0.000   0.000
+ntp.as43588.net 129.6.15.28      2 u  39m 1024  314  189.152    4.244   0.733
 192.168.123.255 .BCST.          16 u    -   64    0    0.000    0.000   0.000 

meaning fb1 was getting its time served. Going back to the FEs, we still couldn't see the ntp synchronized flag up, but it just took time after a few minutes we saw the FEs in sync! This also meant that we could finally restart all FE models, which we successfully did following the script described in the wiki. Then we had to reload the modbusIOC service in all the slow machines (sometimes this required us to call sudo systemctl daemon-reload) and performed burt restore to a last Friday's snap file collection.


IMC realign and MC1 glitch?

With Koji's help PMC locked, and then Yuta and Paco manually increased the input power to the IFO by rotating the waveplate picomotor to 37.0 deg. After this, we noticed that the MC REFL spot was not hitting the camera, so maybe MC1 was misaligned. Paco checked the AP table and saw the spot horizontally misaligned on the camera, which gave us the initial YAW correction on MC1. After some IMC recovery, we saw only MC1 got spontaneously kicked along both PIT and YAW, making our alignment futile. Though not hard to recover, we wondered why this happened.

We went into the 1X4 rack and pushed MC1 suspension cables in to disregard loose connections, but as we came back into the control room we again saw it being kicked randomly! We even turned damping off for a little while and this random kicking didn't stop. There was no significant seismic motion at the time so it is still unclear of what is happening.

  2983   Tue May 25 16:40:27 2010 josephb, alexUpdateCDSFinally tracked down why new models wouldn't talk to each other

The problem with the new models using the new shared memory/dolphin/RFM defined as names in a single .ipc file.

The first is the no_oversampling flag should not be used.  Since we have a single IO processor handling ADCs and DACs at 64k, while the models run at 16k, there is some oversampling occuring.  This was causing problems syncing between the models and the IOP.

It also didn't help I had a typo in two channels which I happened to use as a test case to confirm they were talking.  However, that has been fixed.

  17006   Fri Jul 15 16:20:16 2022 Cici HannaUpdateGeneralFinding UGF

I have temporarily abandoned vectfit and aaa since I've been pretty unsuccessful with them and I don't need poles/zeroes to find the unity gain frequency. Instead I'm just fitting the transfer function linearly (on a log-log scale). I've found the UGF at about 5.5 kHz right now, using old data - next step is to get the Red Pitaya working so I can take data with that. Also need to move this code from matlab to python. Uncertainty's propagated using the 95% confidence bounds given by the fit, using curvefit - so just from the standard error, and all points are weighted equally. Ideally would like to propagate uncertainty accounting for the coherence data too, but haven't figured out how to do that correctly yet.

 

[UPDATE 7/22/2022: added raw data files]

Attachment 1: UGF_4042.png
UGF_4042.png
Attachment 2: UGF_5650.png
UGF_5650.png
Attachment 3: TFSR785_29-06-2022_114042.txt
# SR785 Measurement - Timestamp: Jun 29 2022 - 11:40:42
# Parameter File: TFSR785template.yml
#---------- Measurement Setup ------------
# Start frequency (Hz) = 100000.000000
# Stop frequency (Hz) = 100.000000
# Number of frequency points = 30
# Excitation amplitude (mV) = 10.000000
# Settling cycles = 5
# Integration cycles = 100
#---------- Measurement Parameters ----------
... 52 more lines ...
Attachment 4: TFSR785_29-06-2022_115650.txt
# SR785 Measurement - Timestamp: Jun 29 2022 - 11:56:50
# Parameter File: TFSR785template.yml
#---------- Measurement Setup ------------
# Start frequency (Hz) = 100000.000000
# Stop frequency (Hz) = 2000.000000
# Number of frequency points = 300
# Excitation amplitude (mV) = 5.000000
# Settling cycles = 5
# Integration cycles = 200
#---------- Measurement Parameters ----------
... 322 more lines ...
  16993   Tue Jul 12 18:35:31 2022 Cici HannaSummaryGeneralFinding Zeros/Poles With Vectfit

Am still working on using vectfit to find my zeros/poles of a transfer function - now have a more specific project in mind, which is to have a Red Pitaya use the zero/pole data of the transfer function to find the UGF, so we can check what the UGF is at any given time and plot it as a function of time to see if it drifts (hopefully it doesn't). Wrestled with vectfit more on matlab, found out I was converting from dB's incorrectly (should be 10^(dB/20)....) Intend to read a bit of a book by Bendat and Piersol to learn a bit more about how I should be weighting my vectfit. May also check out an algorithm called AAA for fitting instead.

  8322   Thu Mar 21 09:53:46 2013 AnnalisaUpdateLockingFinding the beat note

 Yesterday I tried to find the beat note between the main PSL and the auxiliary NPRO, but I didn't :( 

Today I will do a better alignment of the two beams in the PD and try again.

  8323   Thu Mar 21 10:19:28 2013 KojiUpdateLockingFinding the beat note

Give us more info on the elog:
What PD are you using? How much power the beams on the recombining BS are? What kind of BS is it?
How are you looking for the beat note? (on the scope? or spectrum analyzer?)
What was the scanned temp range?

Three points to be checked:

- Polarization

- Alignment

- Temperature

  8327   Thu Mar 21 13:11:42 2013 AnnalisaUpdateLockingFinding the beat note

Quote:

Give us more info on the elog:
What PD are you using? How much power the beams on the recombining BS are? What kind of BS is it?
How are you looking for the beat note? (on the scope? or spectrum analyzer?)
What was the scanned temp range?

Three points to be checked:

- Polarization

- Alignment

- Temperature

Experimental Setup

I'm using a 1611 New Focus PD (1 GHZ, with maximum input power 1mW), and the total power hitting on the PD is of about 0.650 mW.

The current of the NPRO laser is set to 1.38 A, so that the input power is 19 mW. The beam is initially damped by a 10% reflection BS and then it hits a 33% reflection BS (where it recombines with the PSL pick-off beam) with 2 mW power.

After this second BS the power is reduced to 0.592 mW.

The PSL pick-off hits on the 33% reflection BS with 65.5 uW power, and it exit with a 47 uW power.

I connected a power supply to apply a Voltage to the slow frequency BNC, in way to tune the laser frequency.

I'm using the AGILENT 4395A Spectrum analyzer to make the measurement. I tried to use the HEWELETT PACKARD 8591E spectrum analyzer, but the monitor didn't turn on.

The temperature spanned until now in only of about 10 deg C, because I realized that I needed a better alignment, so I added a lens in front of the PD and I did a better alignment. 

Moreover, the current of the laser is too low, so I need to increase it and add more beam splitters in the beam path to dump the beam, in way to don't reach the PD threshold.

I knew that both the beams are s-polarized, but maybe I can check it again.

Attachment 1: Beat_note_setup.jpg
Beat_note_setup.jpg
  541   Wed Jun 18 18:26:19 2008 YoichiUpdatePSLFinding the optimal operation temperature for the NPRO by the slow act scan
Being suspicious of the temperature stabilization of the NPRO crystal, I ran the slow scan script written by Rana to find the suitable operation temperature.
The procedure is the same as the one explained in the entry below:
http://www.ldas-sw.ligo.caltech.edu/ilog/pub/ilog.cgi?group=40m&task=view&date_to_view=09/04/2006&anchor_to_scroll_to=2006:09:04:22:23:56-rana
The attached plots show the results. By looking at C1:PSL-126MOPA_126MON, I set the slow slider voltage to 0.
This time, it looks like the temperature control of the NPRO crystal is working fine.
Obviously, PMC picks up many higher order modes. I will try to mode match/align the PMC later.
Attachment 1: FSS-slow-scan.pdf
FSS-slow-scan.pdf
  7953   Tue Jan 29 14:20:02 2013 KojiUpdateGeneralFiner rotation stage for optics characterization

A rotation stage has been ordered.

Newport Rotation Stage, 360° Coarse, 5° Fine Rotation, Micrometer  Newport 481-A
Newport Solid Insert for RSP-1T Rotation Stage Newport RSA-1TI
Newport Universal Mounting Plate, 2.56 in. x 2.56 in. x 0.5 in., 1/4-20 Thread  Newport UP-1A

Specification: Newport 481-A

  • Sensitivity: 15 arcsec
  • Graduations: 1 deg
  • Vernier: 5 arcmin
  • Fine travel range: 5 deg
  • With Micrometer
  15618   Thu Oct 8 08:37:15 2020 gautamUpdateComputer Scripts / ProgramsFinesse GUI

This looks cool, we should have something similar, can be really useful.

  15621   Thu Oct 8 18:40:42 2020 KojiUpdateComputer Scripts / ProgramsFinesse GUI

Is it better than Luxor? https://labcit.ligo.caltech.edu/~jharms/luxor.html

  14057   Thu Jul 12 14:06:39 2018 keerthanaUpdateelogFinesse and Analytical solution - Comparison

I tried to compare the cavity scan data we get from the Finesse simulation and that we expect from the Analytical solution. The diagram of the cavity I defined in Finesse is given below along with the values of different quantities I used. For the analytical solution I have used two different equations and they are listed below.

Analytical 1 - Blue Graph

\phi = \frac {2.L.\Omega_1}{c}

t_{cav} = \frac{t_e. t_f \exp^{-i\frac{\phi}{2}}}{1- r_f. r_e \exp^{-i\phi} }

T_{cav} = \left|{t_{cav}} \right|^2

 

Analytical 2 - Red Graph

F = \frac {4. r_f.r_e}{(1-r_f.r_e )^2}

\phi = \frac {2.L.\Omega_1}{c}

T_{cav} = \left|{t_{cav}} \right|^2 = \frac {(t_e.t_f)^2}{(1 - r_f . r_e)^2} \frac{1}{1+F(\sin\frac {\phi}{2})^2}

The graph obtained from both these solutions completely matches with each other.

Finesse Solution

The cavity which I defined in Finesse is shown below. The solution from Finesse and the Analytical solution also matches with each other. Another plot is made by taking the difference between Finesse solution and Analytical solution. The difference seems to be of the order of \approx 10^{-19}.

The Difference plot is also attached below.

Attachment 1: finesse_cavity.png
finesse_cavity.png
Attachment 2: Analytical1.pdf
Analytical1.pdf
Attachment 3: Finesse_Analytical.pdf
Finesse_Analytical.pdf
Attachment 4: Difference.pdf
Difference.pdf
  13915   Mon Jun 4 19:41:01 2018 keerthanaUpdate Finesse code for cavity scan

The cavity scan data obtained from the Finesse simulation is attached here. Fig1 indicates the cavity scan data in the absence of induced misalignment. In that case only the fundemental mode is resonating. But when a misalignment is induced, higher order modes are also present as seen in Fig2. This is in the absence of surface figure error in the mirrors. Now I am trying to provide perturbations to the mirror surface in the form of zernike polynomials and get the scan data fom the simulation. These cavity scan data can be used to develop fitting models. Once we have a model, we can use it to analyse the data from the experimental cavity scan.

Attachment 1: Fig1.png
Fig1.png
Attachment 2: Fig2.png
Fig2.png
  13956   Wed Jun 13 18:08:36 2018 keerthanaUpdate Finesse code for cavity scan

The unit mentioned in the x-axis was wrong. So I have remade the graphs. The point where frequency equals to zero is actually the frequency corresponding to the laser, which is in the range of 1014 Hz and it caliberated as zero.

Quote:

The cavity scan data obtained from the Finesse simulation is attached here. Fig1 indicates the cavity scan data in the absence of induced misalignment. In that case only the fundemental mode is resonating. But when a misalignment is induced, higher order modes are also present as seen in Fig2. This is in the absence of surface figure error in the mirrors. Now I am trying to provide perturbations to the mirror surface in the form of zernike polynomials and get the scan data fom the simulation. These cavity scan data can be used to develop fitting models. Once we have a model, we can use it to analyse the data from the experimental cavity scan.

finesse1.pdffinesse2.pdf

Attachment 1: finesse1.pdf
finesse1.pdf
Attachment 2: finesse2.pdf
finesse2.pdf
  12120   Wed May 18 01:10:22 2016 gautamUpdateCOCFinesse modelling

I've been working on putting together a Finesse model for the current 40m configuration. The idea was to see if I could reproduce a model that is in agreement with what we have been seeing during the recent DRFPMI locks. With Antonio and EricQs help, I've been making slow progress in my forays into Finesse and pyKat. Here is a summary of what I have so far.

  • Arm lengths were taken from some recent measurements done by yutaro and me 
  • Recycling cavity lengths were taken from Gabriele's elog 9590 - it is likely that the lengths I used have errors ~1cm - more on this later. Furthermore, I've tried to incorporate the flipped RC folding mirrors - the point being to see if I can recover, for example, a power recycling gain of ~7 which is what was observed for the recent DRFPMI locks.
  • I used Yutaro's most recent arm loss numbers, and distributed it equally between ITM and ETM for modeling purposes. 
  • For all other optics, I assumed a generic loss number of 25ppm for each surface

Having put together the .kat file (code attached, but this is probably useless, the new model with RC folding mirrors the right way will be what is relevant), I was able to recover a power recycling gain of ~7.5. The arm transmission at full lock also matches the expected value (125*80uW ~ 10mW) based on a recent measurement I did while putting the X endtable together. I also tuned the arm losses to see (qualitatively) that the power recycling gain tracked this curve by Yutaro. EricQ suggested I do a few more checks:

  1. Set PRM reflectivity to 0, scan ETMs and look at the transmission - attachment #1 suggests the linewidth is as we expect 
  2. Set ETM reflectivity to 0, scan PRM - attachment #2 suggests a Finesse of ~60  for the PRC which sounds about right
  3. Set ETM reflectivity to 0, scan SRM and verify that only the 55 MHz sidebands resonate - Attachment #3

Conclusion: It doesn't look like I've done anything crazy. So unless anyone thinks there are any further checks I should do on this "toy" model, I will start putting together the "correct" model - using RC folding mirrors that are oriented the right way, and using the "ideal" RC cavity lengths as detailed on this wiki page. The plan of action then is

  • Evaluating the mode-matching integrals between the PRC and the arm cavities as a function of the radius of curvature of PR2 and PR3
  • Same as above for the SRC
  • PRC gain as a function of RoC of folding mirrors
  • Mode overlap between the modes from the two arm cavities as a function of the RoC of the two ETMs (actually I guess we can fix RoC of ETMy and just vary RoC of ETMx).

Sidenote to self: It would be nice to consolidate the most recent cavity length measurements in one place sometime...

Attachment 1: arms.pdf
arms.pdf
Attachment 2: PRC.pdf
PRC.pdf
Attachment 3: SRC.pdf
SRC.pdf
Attachment 4: Finesse_model.zip
  12130   Tue May 24 22:49:02 2016 gautamUpdateCOCFinesse modelling - mode overlap scans

Summary:

Having played around with a toy finesse model, I went about setting up a model in which the RC folding mirrors are not flipped. I then repeated the low-level tests detailed in the earlier elog, after which I ran a few spatial mode overlap analyses, the results of which are presented here. It remains to do a stability analysis.

Overview of model parameters (more details to follow):

  • PRC length = 6.7727m (chosen using l_{PRC} = (N+\frac{1}{2})\frac{c}{2f_1}, N=0 - I adjusted the position of the PRM to realize this length in the model, while leaving all the other vertex optics in the same positions as in elog 9590
  • SRC length = 5.4182 (chosen using l_{SRC} = M\frac{c}{2f_2} but not l_{SRC} = N\frac{c}{2f_1}, M and N being integers, for M=2 - as above, I adjusted the position of the SRM to realize this in the model, while leaving all other vertex optics in the same positions as in elog 9590. It remains to be verified if it is physically possible to realize these dimensions in vacuum without any beam clipping etc but I think it should be possible seeing as the PRM and SRM had to be moved by less than 2cm from their current positions..
  • For the losses, I used the most recent numbers we have where applicable, and put in generic 25ppm loss for all the folding mirrors/BS/AR surfaces of arm cavity mirrors/PRM/SRM. Arm round trip loss was equally distributed between ITMs and ETMs
  • Arm lengths used: L_X = 37.79m, L_Y = 37.81m
  • To set the "tunings" of the various mirrors, I played around with a few configurations to see where the various fields resonated - it turns out that for PRM, ITMX, ITMY, ETMX and ETMY, the "phase" in the .kat file can be set as 0. while that for the SRM can be set as 90. In the full L1/H1 interferometer .kat files, these are tuned even further to the (tenth?!) decimal place, but I think these values suffice for out purposes.

Results (general note: positive RoC in these plots mean a concave surface as seen by the beam):

  • Attachments #1, #2 and #3 reproduce the low-level tests performed earlier for this updated model - i.e. I look at the arm transmission with no PRM/SRM, circulating PRC power with no ETMs, and circulating SRC power with no ETMs. Everything looks consistent here... In Attachment #2, there is no legend, but the (almost overlapping) red and green lines are meant to denote the +f1 and +f2 sidebands.
  • Attachments #4 and #5 are a summary of the mode-overlap scans for the PRC and SRC. What I did was to vary the radius of curvature of the RC mirrors (finesse only allows you to vary Rcx and Rcy, so I varied both simultaneously) and calculate the mode overlap between the appropriate pairs of cavities (e.g. PRX and XARM) in the tangential and saggital planes. The take-away here is that there is ~5% mode-mismatch going from an RoC of 1000m to 300m. I've also indicated the sag corresponding to a given RoC - these are pretty tiny, I wonder if it is possible to realize a sag of 1um? I suppose it is given that I've regularly seen specs of surface roughness of lambda/10?
  • Attachment #6 shows the PRC gain (calculated as T_PRC * (transmitted arm power with PRM / transmitted arm power without PRM) as a function of the RoC of PR2 and PR3. As a sanity check, I repeated this calculation with lossless HR surfaces (but with nominal 25ppm losses for AR surfaces of ITMs, and BS etc), shown in Attachment #7. I think these make sense too...
  • Attachment #8 - in order to investigate possible mode mismatch between the arm modes due to different radii of curvature of the ETMs, I kept the ETMY RoC fixed at 57.6m and varied the ETMY RoC between 50m and 70m (here, I've plotted the mode matching efficiency as a function of the RoC of the ETM in the X and Y directions separately - the mode overlap is computed as \frac{1}{\sqrt{2}}(x^2 + y^2) where x and y denote the overlap in the tangential and saggital planes respectively. It would seem that we only lose at most a couple of percent even if the RoCs are mismatched by up to 10m...
  • Attachment #9 - .kat file and the various pykat scripts used to generate these plots...

Next step is to carry out a stability analysis...

Attachment 1: armTransmission.pdf
armTransmission.pdf
Attachment 2: prcFSR.pdf
prcFSR.pdf
Attachment 3: srcTransmission.pdf
srcTransmission.pdf
Attachment 4: modeMatchPRX.pdf
modeMatchPRX.pdf
Attachment 5: modeMatchSRX.pdf
modeMatchSRX.pdf
Attachment 6: PRCgainScan.pdf
PRCgainScan.pdf
Attachment 7: PRCgainLossless.pdf
PRCgainLossless.pdf
Attachment 8: armModeMatchScan.pdf
armModeMatchScan.pdf
Attachment 9: Finesse_files.zip
  12131   Tue May 24 23:17:37 2016 ericqUpdateCOCFinesse modelling - mode overlap scans

I think you should use the current actual PRC & SRC cavity lengths as measured, as it would be simplest to simply replace the folding mirror optics without changing the macroscopic lengths / optic positions. (EDIT: Gautam rightly points out that we have to move things around regardless, since our current lengths include propagation through the folding mirror subtrates)

Moreover, the recycling cavity lengths you posted are not the right "ideal" lengths to use, as they do not account for the complex reflectivities of the sidebands off of the arm cavities (I have made this mistake myself). See this 40m wiki page for details.

In short, given our current modulation frequency, the ideal lengths to use would be:

  • Ideal arm length of 37.795 m
  • Ideal PRC length of 6.753 m
  • Ideal SRC length of 5.399 m

These are the lengths that the recycling cavity optics were positioned for (though we did not achieve them perfectly). If you do a finer PRC/SRC length scan around the DRFPMI resonance of your model, you would presumably see some undesired sideband splitting. 

  2903   Mon May 10 17:47:16 2010 josephbSummaryCDSFinished

So I finished writing a script which takes an .ipc file (the one which defines channel names and numbers for use with the RCG code generator),  parses it, checks for duplicate channel names and ipcNums, and then parses and .mdl file looking for channel names, and outputs a new .ipc file with all the new channels added (without modifying existing channels). 

The script is written in python, and for the moment can be found in /home/controls/advLigoRTS/src/epics/simLink/parse_mdl.py

I still need to add all the nice command line interface stuff, but the basic core works.   And already found an error in my previous .ipc file, where I used the channel number 21 twice, apparently.

Right now its hard coded to read in C1.ipc and spy.mdl, and outputs to H1.ipc, but I should have that fixed tonight.

  2908   Mon May 10 20:33:29 2010 KojiSummaryCDSFinished

This IPC stuff looks really a nice improvement of CDS.

Please just maintain the wiki updated so that we can keep the latest procedures and scripts to build the models.

Quote:

So I finished writing a script which takes an .ipc file (the one which defines channel names and numbers for use with the RCG code generator),  parses it, checks for duplicate channel names and ipcNums, and then parses and .mdl file looking for channel names, and outputs a new .ipc file with all the new channels added (without modifying existing channels). 

The script is written in python, and for the moment can be found in /home/controls/advLigoRTS/src/epics/simLink/parse_mdl.py

I still need to add all the nice command line interface stuff, but the basic core works.   And already found an error in my previous .ipc file, where I used the channel number 21 twice, apparently.

Right now its hard coded to read in C1.ipc and spy.mdl, and outputs to H1.ipc, but I should have that fixed tonight.

 

  16499   Fri Dec 10 15:59:23 2021 PacoUpdateBHDFinished Coil driver (even serial number) units tests

[Paco, Anchal]

We have completed modifications and testing of the HAM Coil driver D1100687 units with serial numbers listed below. The DCC tree reflects these changes and tests (Run/Acq modes transfer functions).

SERIAL # TEST result
S2100608 PASS
S2100610 PASS
S2100612 PASS
S2100614 PASS
S2100616 PASS
S2100618 PASS
S2100620 PASS
S2100622 PASS
S2100624 PASS
S2100626 PASS
S2100628 PASS
S2100630 PASS
S2100632 PASS
S2101648** FAIL (Ch1, Ch3 run mode)
S2101650** FAIL (Ch3 run mode)
S2101652** PASS
S2101654** PASS

** A fix had to be done on the DC power supply for these. The units' regulated power boards were not connected to the raw DC power, so the cabling had to be modified accordingly (see Attachment #1)

Attachment 1: dc_fail.jpg
dc_fail.jpg
  16514   Thu Dec 16 15:32:59 2021 AnchalUpdateBHDFinished Coil driver (odd serial number) units tests

We have completed modifications and testing of the HAM Coil driver D1100687 units with serial numbers listed below. The DCC tree reflects these changes and tests (Run/Acq modes transfer functions).

SERIAL # TEST result
S2100609 PASS
S2100611 PASS
S2100613 PASS
S2100615 PASS
S2100617 PASS
S2100619 FAIL (CH2 phase)
S2100621 PASS
S2100623 PASS
S2100625 PASS
S2100627 PASS
S2100629 PASS
S2100631 PASS
S2100633 Waiting for more components
S2101649** PASS
S2101651** PASS
S2101653** PASS
S2101655** PASS

** A fix had to be done on the DC power supply for these. The units' regulated power boards were not connected to the raw DC power, so the cabling had to be modified accordingly.

Further, Paco fixed the two even serial number units (S2101648, S211650) that failed the test. The issues were minor soldering mistakes that were easily resolved.

  16517   Thu Dec 16 17:57:17 2021 AnchalUpdateBHDFinished Coil driver (odd serial number) units tests

S2100619 was fixed by Koji and it passed the test after that.

Quote:
SERIAL #  
S2100619 FAIL (CH2 phase)

 

  12329   Mon Jul 25 10:54:55 2016 PrafulUpdateComputer Scripts / ProgramsFinished MEDM Tab on Summary Pages

The MEDM screen capture tab is now working and up on the summary pages: https://nodus.ligo.caltech.edu:30889/detcharsummary/day/20160725/medm/

Please let me know if you have any suggestions or notice any issues.

  12330   Mon Jul 25 12:22:18 2016 ranaUpdateComputer Scripts / ProgramsFinished MEDM Tab on Summary Pages

Looks pretty great. However, there's two problems:

1) Some of the MEDM screens don't show the time. You can fix this by editing the screens and copy/paste from screens which have working screens.

2) The snapshot script seems to not grab the full MEDM screen sometimes.

These are not a very big deal, so you can get the microphones working first and we can take care of this afterwards.

  12439   Wed Aug 24 23:47:30 2016 PrafulUpdateElectronicsFinished Prototype Box

Gautam helped me drill holes in a metal box and I set up my circuit inside. Everything seems to be working so far. Tomorrow I'll be suspending the box near the PSL and setting up a data channel. Attached are some pictures of the box- sorry some of the angles turned out weird.

Attachment 1: out1.pdf
out1.pdf
Attachment 2: out2.pdf
out2.pdf
Attachment 3: out3.pdf
out3.pdf
Attachment 4: in1.pdf
in1.pdf
Attachment 5: in2.pdf
in2.pdf
  3116   Thu Jun 24 16:59:24 2010 josephbUpdateVACFinished restoring the access connector and door

[Jenne,  Kiwamu, Steve, Sharmila, Katherine, Joe]

We finished bolting the door on the new ITMX (old ITMY) and putting the access connector section back into place.  We finished with torquing all the bolts to 40 foot-pounds.

  2597   Fri Feb 12 13:56:16 2010 josephbUpdateComputersFinishing touches on IP switch over

The GPIB interfaces have been updated to the new 192.168.113.xxx addresses, with Alberto's help.

Spare ethernet cables have been moved into a cabinet halfway down the x-arm.

The illuminators have a white V error on the alarm handler, but I'm not sure why.  I can turn them on and off using the video screen controls (except for the x arm, which has no computer control, just walk out and turn it on).

There's a laptop or two I haven't tracked down yet, but that should be it on IPs. 

At some point, a find and replace on 131.215.xxx.yyy addresses to 192.168.xxx.yyy should be done on the wiki.  I also need to generate an up to date ethernet IP spreadsheet and post it to the wiki.

 

  4056   Wed Dec 15 12:46:18 2010 KojiSummaryIOOFinishing up the vac work

What else?

v: Edit on Dec 15 10PM
v: Edit on Dec 16 10PM

JD:  We should check OSEMs for all optics *after* table leveling.  Some of them (esp. BS and ITMX) are currently close to their limits right now.

KA: Check green alignment.

Take photos of the tables.

Fix the leveling weights



Location    Optics            Action
--------------------------------------------------------------
@ITMX -     v POX             alignment
            v POP1/POP2       alignment
            v Table Leveling

@ITMY -     POY               mirror replacement (45deg->0deg) / alignment
            v SR2-TT          alignment
            v SRM Tower       alignment / EQ-stop release
            v SRM             alignment
            v SRM OSEM
            vvSRM OPLEV (X2)  install (VIS)/ alignment
            v ITMY OPLEV (X2)   install (VIS)/ alignment
            v OM1/OM2         install (DLC 45deg)/ alignment       
            v Table Leveling

@BSC -      v OM3             install (DLC 45deg/ alignment)
            v OM4(PZT)          neutralize, adjustment
            IPPOS steering    alignment
            v BS OPLEV        alignment
           
v PRM OPLEV(x2)     alignment
            Beam dumps
            Table Leveling

@IMC -      v REFL              mirror replacement (45deg->0deg)

@ETMX -     Al foil removal
            Table Leveling

@ETMY -     ETMY damping
            OSEM
            OPLEV
            Al foil removal
            Table Leveling

@OMC -      v OM5(PZT)        neutralize, adjustment

@ITM/ETM -  Mirror Wiping

  15490   Thu Jul 16 14:41:22 2020 gautamUpdateGeneralFire extinguisher inspection

The (masked) tech accessed all areas in the lab (office area, control room, VEA) between ~230pm-3pm. The laser safety goggles he used have been kept aside for appropriate sanitaiton.

  15530   Mon Aug 17 21:24:43 2020 gautamUpdateGeneralFire extinguisher inspection

A technician came to the lab today at ~4pm. He entered the VEA (with booties and googles), and also the clean and bake lab. The whole procedure lasted ~10 minutes. I did not follow him around, but was available in the control room throughout the process. I think the whole episode went without incident.

BTW, this guy didn't ring the doorbell, I just happened to be here when he came by. I don't know if this is usual practise - are we happy with the technicians entering the VEA and/or clean and bake labs without supervision? AFAIK, this wasn't scheduled.

  1940   Tue Aug 25 02:37:53 2009 ranaConfigurationComputer Scripts / ProgramsFirefox 3.5 installed for 64 bit linux in apps/
Attachment 1: DSC_0620.JPG
DSC_0620.JPG
  5863   Thu Nov 10 16:26:46 2011 MirkoUpdateComputersFirefox kills elog

Had to restart the elog many times. For some reason firefox 8 on Win 7 kills the elog pretty consistently when trying to make a new entry. IE9 works fine ....

  14010   Sat Jun 23 13:08:41 2018 JonUpdateAUXFirst Coherent AUX Scan of PRC Using AM Sidebands

[Jon, Keerthana, Sandrine]

Thu.-Fri. we continued with PRC scans using the AUX laser, but now the "scanned" parameter is the frequency of AM sidebands, rather than the frequency of the AUX carrier itself. The switch to AM (or PM) allows us to coherently measure the cavity transfer as a function of modulation frequency.

In order to make a sentinel measurement, I installed a broadband PDA255 at an unused pickoff behind the first AUX steering mirror on the AS table. The sentinel PD measures the AM actually imprinted on the light going into the IFO, making our measurement independent of the AOM response. This technique removes not only the (non-flat) AOM transfer function, but also any non-linearities from, e.g., overdriving the AOM. The below photo shows the new PD (center) on the AS table.

With the sentinel PD installed, we proceeded as follows.

  • Locked IFO in PRMI on carrier.
  • Locked AUX PLL to PSL.
  • Tuned the frequency of the AUX laser (via the RF offset) to bring the carrier onto resonance with the PRC.
  • Swept the AOM modulation frequency 0-60 MHz while measuring the AUX reflection and injection signals.

The below photo shows the measured transfer function [AUX Reflection / AUX Injection]. The measurement coherence is high to ~55 MHz (the AOM bandwidth is 60 MHz). We clearly resolve two FSRs, visible as Lorentzian dips at which more AUX power couples into the cavity. The SURFs have these data and will be separately posting figures for the measurements.

With the basic system working, we attempted to produce HOMs, first by partially occluding the injected AUX beam with a razor blade, then by placing a thin two-prong fork in the beam path. We also experimented with using a razor blade on the output to partially occlude the reflection beam just before the sensor. We were able to observe an apparent secondary dip indicative of an HOM a few times, as shown below, but could not repeat this deterministically. Besides not having fine control over the occlusion of the beams, there is also large few-Hz angular noise shaking the AS beam position. I suspect from moment to moment the HOM content is varying considerably due to the movement of the AS beam relative to the occluding object. I'm now thinking about more systematic ways to approach this.

 

  14011   Sat Jun 23 20:54:35 2018 KojiUpdateAUXFirst Coherent AUX Scan of PRC Using AM Sidebands

How much was the osc freq of the marconi? And then how much was the resulting freq offset between PSL and AUX?

Are we supposed to see two dips with the separation of an FSR? Or four dips (you have two sidebands)?

And the distance between the dips (28MHz-ish?) seems too large to be the FSR (22MHz-ish).
cf https://wiki-40m.ligo.caltech.edu/IFO_Modeling/RC_lengths

  14017   Tue Jun 26 10:06:39 2018 keerthanaUpdateAUXFirst Coherent AUX Scan of PRC Using AM Sidebands

(Jon, Keerthana, Sandrine)

I am attaching the plots of the Reflected and transmitted AUX beam. In the transmission graph, we are getting peak corresponding to the resonance frequencies, as at that frequency maximum power goes to the cavity. But in the Reflection graph, we are obtaining dips corresponding to the resonance frequency because maximum power goes to the cavity and the reflected beam intensity becomes very less at those points.

 

Attachment 1: TRANS.pdf
TRANS.pdf
Attachment 2: REFL.pdf
REFL.pdf
  7860   Wed Dec 19 21:35:33 2012 KojiSummaryGeneralFirst Contact Training with Margot

[Koji, Steve]

First Contact Training with Margot

  12223   Tue Jun 28 20:43:23 2016 KojiSummaryCOCFirst Contact cleaning practice

Made a dry run of the in-situ cleaning for a 3inch optic.

Attachment 1: The Al dummy mass is clamped in the suspension cage.
Attachment 2: The front surface was painted. The nominal brush with the FC bottle was used.
Attachment 3: Zoom in of the front surface.
Attachment 4: The back surface was painted.
Attachment 5: The back surface was peeled.
Attachment 6: The front surface was peeled too.
Attachment 7: The peeled layers.

Findings:

1. To paint a thick layer (particlarly on the rim) is the key to peel it nicely.

2. It was helpful for easier peeling to have mutiple peek tabs. Two tabs were sufficient for ~1" circle.

3. The nominal brush with the bottle was OK although one has to apply the liquid many times to cover such a large area. A larger brush may cause dripping.

4. The nominal brush was sufficiently long once the OSEMs are removed. In any case it is better to remove the OSEMs.

Attachment 1: IMG_20160628_170335196.jpg
IMG_20160628_170335196.jpg
Attachment 2: IMG_20160628_171547769.jpg
IMG_20160628_171547769.jpg
Attachment 3: IMG_20160628_171607802.jpg
IMG_20160628_171607802.jpg
Attachment 4: IMG_20160628_172328190.jpg
IMG_20160628_172328190.jpg
Attachment 5: IMG_20160628_174541960.jpg
IMG_20160628_174541960.jpg
Attachment 6: IMG_20160628_174556004.jpg
IMG_20160628_174556004.jpg
Attachment 7: IMG_20160628_174617198.jpg
IMG_20160628_174617198.jpg
  7388   Fri Sep 14 16:39:14 2012 ericq, jenneUpdateGeneralFirst In Vac Picture

After much fussing, we got a picture of MMT1 with the beam.

Using the iris doesn't seem feasible. Since it has to be significantly separated from the optic, it is hard to judge whether it is centered, especially in yaw.

It took ~30 min to get this picture. Comments on whether this kind of picture is good enough are welcomed, since there are many more to be taken.

Attachment 1: mmt1.jpg
mmt1.jpg
  7389   Fri Sep 14 18:15:43 2012 ranaUpdateASCFirst In Vac Picture

 

 Looks good. Any way that you can tell in an unambiguous way, where the beam is, is very good. Ideally we want to have1-2 mm accuracy.

  2964   Fri May 21 00:51:06 2010 JenneUpdateIOOFirst MC mode measuring (hopefully) done

[Jenne, Kiwamu, Steve]

Round 1 of measuring the MC mode is pretty much done.  Yay.

Earlier today, Steve and I launched the MC beam off the flat mirror just after the Faraday, and sent it down toward ETMY(new convention). We ended up not being able to see it all the way at the ETM because we were hitting the beam tube, but at the ITM chamber we could see that the beam looked nice and circle-y, so wasn't being clipped in the Faraday or anywhere else.  To do this we removed 2 1inch oplev optics.  One was removed from the BS table, and wrapped in foil and put in a plastic box.  The other was just layed on its' side on the BS table. 

I then took the beam out of the BS chamber, in order to begin measuring the mode.  I left the flat fixed mirror in the place of what will be PZT SM1, and instead used the PZT mirror to turn the beam and get it out the BS chamber door.  (Thoughts of getting the beam to the BS oplev table were abandoned since this was way easier, since Kiwamu and Steve had made the nifty table leg things.)  Kiwamu and I borrowed an 2inch 45P Y1 optic from the collection on Koji's desk (since we have ZERO 2inch optics on the random-optic-shelf....no good), to shoot the beam down the hallway of the Yarm (new convention).  We used the beam scan on a rolling cart to measure the beam at various distances.  I made some sweet impromptu plum bobs to help make our distance measurements a bit more accurate.

We stopped at ~25 feet from the BS chamber, since the spot was getting too big for the beam scanner.  If it turns out that I can't get a good fit with the points I have, I'll keep everything in-chamber the same, and do the farther distances using the good ol' razor blade technique.

I have measurements for the distances between the beam scan head and the opening of the BS chamber.  Tomorrow, or very soon after, I need to measure the distances in-chamber between the MC and the BS chamber opening.  Plots etc will come after I have those distances.

Next on the to-do list:

1.  Measure distances in-chamber for first mode scan.

2.  Plot spot size vs. distance, see if we need more points. Take more points if needed.

3.  Put in MMT1, repeat measurements.

4.  Put in MMT2, rinse and repeat.

5.  Move the PZT mirror to its new place as SM1, and figure out how to connect it.  Right now the little wires are hooked up on the BS table, but we're going to need to make / find a connector to the outside world from the IOO table. This is potentially a pretty big pain, if we don't by happenstance have open connectors on the IOO table.

  5727   Fri Oct 21 18:20:54 2011 MirkoUpdateCDSFirst OAF version running

[Jenne, Jamie, Mirko]

We got the first version of the oaf code based on Matt"s code running!! :-)
Produces already data for e.g. MICH DOF. But don"t trust that. It's only 10 taps long and delay is not adjusted.

  16007   Thu Apr 8 17:04:43 2021 Anchal, PacoUpdateSUSFirst Successful Coil Balancing

Today, we finally crossed the last hurdle and got a successful converging coil balancing run. laugh


What was the issue with POS?

  • Position of the MC2 mirror is being sensed using C1:IOO-MC_F_DQ channel which is proportional to the resonant frequency of the locked IMC.
  • However, this sensor is always 180 degrees out of phase of our actuator, the coils.
  • When the coils push the mirror forward, the length of the cavity actually decreases.
  • We added an extra option of providing a sign to the sensors such that -1 will be multiplied to sensed values for sensors which measure in opposite direction to the actuation.
  • This is important, because the feedback is applied to the coil output matrix assuming a particular direction of acctuation.
  • When we gave negative sign for the position sensor, it all started making sense and the algorithm started converging.

First run parameters:

  • We used binwidth of 0.25 Hz and duration of excitation as 41s. This would give welch and csd averaging of 19. We used median averaging to ignore outliers.
  • This iteration was run after PIT and YAW were separetly uncoupled before. We'll post a clean start to end run results in near future.
  • The iteration works in following manner:
    • Define a constant coil matrix C = [[1, 1, 1], [1, 1, -1], [1, -1, 1], [1, -1, -1]] which is ideal coil output matrix.
    • In each iteration, the output matrix Ok is defined as (note @ is the matmul operator):
      Ok = C @ Ak
      where Ak is a 3x3 matrix. A-1 is identity matrix.
    • At the end of each iteration, a sensing matrix is calculated in dimensions sensedDOF x excitedDOF, Sk
    • For next iteration, Ak+1 is calcualted by:
      Ak+1 = Ak - b * (Sk - I)
      where I is the identity matrix.
    • At convergence, the sensing matrix would become same as identity and matrix A will stop updating.
  • For this run, we kept the parameter b to be 0.05. This is similar to the KP parameter in PID loops. It should be between 0 and 1.
  • Since b value was small enough to allow for convergence from the inital point, but later it slowed down the process a lot.
  • Ideally, we should figure out a way to increase this paramter when the coil has been balanced somewhat, to increase the speed of the algorithm.
  • Secondly, we have a code which excites all DOFs at different frequencies directly using excitation channels in coil output matrix using awg.py. But for some reason, the excitation channel for 4th row in the output matrix column only connects intermittantly. Because of this, we can't use this method reliably yet. We can investigate more into it if suggested.

Balancing characteristics:

  • Attachment 1 shows how the distance of sensing matrix falls as iterations increase. We only ran for 50 iterations.
  • Attachment 2 shows how different off-diagonal terms of sensing matrix decreased.
    • Note that POS -> PIT, POS -> YAW and PIT-YAW have settled down to the noise floor.
    • The noise floor can be improved by increasing the excitation amplitude and/or increasing the duration of measurement.
  • Attachment 3 shows the evolution of sensing matrix as iterations move.

Final balanced output matrix:

Final balanced output coil matrix for MC2
POS PIT YAW COILS
1.02956 1.13053 1.19116 UL
1.01210 1.09188 -0.74832 UR
0.98737 -0.85502 0.70485 LR
0.96991 -0.89366 -1.23463 LR
Final Sensing Matrix
  Exc POS Exc PIT Exc YAW
Sens POS 1 -2.96e-2 8.00e-3
Sens PIT 8.58e-4 1 -4.84e-3
Sens YAW 5.97e-4 -1.15e-3 1

Code features and next:

  • Majority of the code is in two files: scripts/SUS/OutMatCalc/MC2crossCoupleTest.py and scripts/SUS/OutMatCalc/crossCoupleTest.py .
  • The code runs from start to end without human involevement and restores the state of channels in any case (error, kyboard interrupt, end of code) using finally statement.
  • Currently, each excitation is done one at a time through LockIn1. As mentioned above, this can be sped up 3 times if we get the awg.py to work reliably.
  • The complete code is in python3 and currently is run through native python3 on allegra (a new debian10 workstation with latest cds-workstation installed).
  • The code can be easily generalized for balancing any optic. Please let us know if we should work on making the generalized optic.
  • We're also working on thinking about increasing b as iterations move forward and the error signal becomes smaller.
  • We can also include the uncertainty in the Sensing matrix measurement to provide a weighted feedback. That way, we can probably increase b more.
Attachment 1: SDistanceFromIdentity.pdf
SDistanceFromIdentity.pdf
Attachment 2: SmatIterations.pdf
SmatIterations.pdf
Attachment 3: SmatrixPlots.pdf
SmatrixPlots.pdf SmatrixPlots.pdf SmatrixPlots.pdf SmatrixPlots.pdf SmatrixPlots.pdf SmatrixPlots.pdf SmatrixPlots.pdf SmatrixPlots.pdf
  565   Wed Jun 25 11:36:14 2008 Max JonesUpdateComputer Scripts / ProgramsFirst Week Update
For the first week I have been modifying the noise budget script in caltech/NB to run with 40 m parameters and data. As per Rana's instructions, I have tried to run the script with only seismic and Darm sources. This involves identifying and changing channel names and altering paramter files (such as NB/ReferenceData/C1IFOparams.m). To supply the parameter files, I have copied the H1 files with (as yet only) slight modification. The channel name changes have been made to mirror the sites for the most part. Two figures are attached which show the current noise budget. The Day plot was taken 6/23/08 at ~10:30 am. The night plot was taken 6/22/08 at ~11:00 pm . Note that the SRD curve is for the sites and not for the 40 m (I hope to change that soon). Also in one of the plots the DARM noise signal is visible. Obviously this needs work. A list of current concerns is

1) I am using a seismic transfer function made by previous SURF student Ryan Kinney to operate with channels of the form C1:PEM_ACC-ETMY_Y (should I be using C1:DMF-IX_ACCY?) and the channels I am currently using are the acceleraometers for the mode cleaner with names of the form C1:PEM_ACC-MC1_X. Rana said that he thinks these may be the same but I need to be sure.

2) We don't have a DARM_CTRL channel but the code requires it, currently I am using DARM_ERR as a substitute which is probably partly responsible for the obvious error in DARM noise.

Any suggestions are appreciated. Max.
Attachment 1: C1_NoiseBudgetPlot_Day.eps
C1_NoiseBudgetPlot_Day.eps
Attachment 2: C1_NoiseBudgetPlot_Night.eps
C1_NoiseBudgetPlot_Night.eps
  6879   Wed Jun 27 11:33:28 2012 MashaUpdateGeneralFirst Week Update

This week I wrote Matlab code, most of which can be found in /users/masha

First, I wrote a simulation seismicFilter.m which filters noisy seismic noise with a desired signal of non-seismic noise. The signals are purely simulated, so I played around with zero-pole-gain generation of transfer functions to obtain them. The function takes the number of taps, the filter type (Wiener or adaptive nlms) as well as an iteration step size and number of iterations, and generates PSD plots of the witness signal, the desired signal, the estimated (filtered) signal, and the error. I'm not sure that I am properly implementing the Wiener part of the code, and I assume the line "[W, R, P] = miso_firlev(TAPS, noisySeismicSignal1, seismicSignal2); " generates W, a filter with TAPS number of weights, but  then "[y, error] = filter(W, 1, noisySeismicSignal1);" generates an error signal of size TAPS rather than N, the size of the original signal. Perhaps I should calculate error using e(t) = d(t + a) - w(t)*x(t), where "a" is the delay.

I have various screenshots in my directory of what seismicFilter.m generates, and I will take a larger screenshot, as well as generate a learning curve (for error vs. number of taps) when I can use Sasha's computer for a bit, since it both has more computing power and a larger screen.

The funciton filterConvergence.m, meanwhile, is similar, except it takes two file names as real data, and uses realDataFilter.m to run the filtering. Currently, I am working with data from C1:IOO-MC_F_DQ-Online  and C1:PEM-SEIS_GUR1_X_IN1_DQ-Online, and I will include screenshots of these once I get on Sasha's computer.

In order to generate the data, meanwhile, I had to modify the python script, and thus wrote mashaImportingData.py for myself. Likewise, plotSignalFromFile.m visualizes this data, both in the time domain and in the frequency domain.

On the side, I wrote an NLMS filter in adaptiveFilterSimulationNLMS.m, and compared is to Matlab's NLMS filter in NLMStest.m (using generated data) and adaptiveFilterSimulation.m using twn input signals. Right now, it's faster on smaller inputs and smaller tap sizes, but then begins to choke and run slower than the Matlab one when these get to big. In order to improve it, I have to develop a better method of generating the initial weights.

As far as machine learning goes, once I find the number of taps for the convergence of both the Wiener filter and the NLMS filter, I will email Denis for further instructions. At some point, however, I should generate learning sets from the seismometers and the MCL (or the DARM), and thus have to find adequate times at which I can take data (probably not from the DARM, however, because it was rarely on).

Thanks for reading!

  6878   Wed Jun 27 11:27:49 2012 LizUpdate First Week Update!

This week, the other SURF students and I got acquainted with the caltech campus, LIGO 40m lab and the expectations of the SURF program.  We went to a lot of safety meetings and lectures that established a framework for the jobs we will be doing over the course of the summer.  I went on several tours of the 40m interferometer (one each with Jenne, Jamie and Steve) to get an overview of the layout and specifics of the setup.  I read parts of R. Ward and A. Parameswaran's theses and Saulson's book in order to prepare myself and gain a broader understanding of the purpose of LIGO.

I also began working in Python this week, primarily graphing PSDs of data from the C1:SUS-ETMY_SENSOR_LR, C1:SUS-ETMY_SENSOR_LL, C1:SUS-ETMY_SENSOR_UR, and C1:SUS-ETMY_SENSOR_UL channels.  I will eventually be using Python to generate the plots for the summary pages, so this is good practice.  The code that I have been working on can be found in /users/elizabeth.davison/script5.py.  Additionally, I have been going through the G1 summary pages and attempting to understand the plots available on them and the code that is available.

My plans for the upcoming week begin with modifying my code and potentially calibrating the channel data so that it is in units of length instead of counts.  I will also access the code from the G1 pages and go over it in depth, hopefully gaining insight into the structure of the website.

  3099   Tue Jun 22 20:07:08 2010 JenneUpdate40m UpgradingFirst attempt at Tip Tilt hanging

[Jenne, Steve, Nancy, Gopal]

We made an attempt at hanging some of the Tip Tilt eddy current dampers today. 

Photo 1 shows the 2 ECDs suspended.

Procedure:

(1) Loosen the #4-40 screws on the side of the ECDs, so the wire can be threaded through the clamps.

(2) Place the ECDs in the locator jigs (not shown), and the locator jigs in the backplane (removed from main TT structure), all laying flat on the table.

(3) Get a length of Tungsten wire (0.007 inch OD = 180um OD), wipe it with acetone, and cut it into 4 ~8cm long segments (long enough to go from the top of the backplane to the bottom).

(4) Thread a length of wire through the clamps on the ECDs, one length going through both ECDs' clamps.

(5) One person hold the wire taught, and straight, and as horizontal as possible, the other person tightened the clamping screws on the ECDs.

(6) Again holding the wire in place, one person put the clamps onto the backplane (the horizontal 'sticks' with 3 screws in them).

(7) The end. In the future, we'll also clip off extra pieces of wire.

When we held up the backplane to check out our handy work, it was clear that the bottom ECD was a much softer pendulum than the top one, since the top one has the wire held above and below, while the bottom one only has the wire held on the top.  I assume we'll trim the wire so that the upper ECD is only held on the top as well?

Lessons learned:

* This may be a 3 person job, or a 2 people who are good at multitasking job.  The wire needs to be held, the ECDs need to be held in place so they don't move during the screwing/clamping process, and the screws need to be tightened.

* Make sure to actually hold the wire taught. This didn't end up happening successfully for the leftmost wire in the photo, and the wire is a bit loose between the 2 ECDs.  This will need to be redone.

* We aren't sure that we have the correct screws for the clamps holding the wire to the backplane.  We only have 3/16" screws, and we aren't getting very many threads into the aluminum of the backplane.  Rana is ordering some 316 Stainless Steel (low magnetism) 1/4" #4-40 screws.  We're going for Stainless because Brass (the screws in the photo), while they passed their RGA scan, aren't really good for the vacuum.  And titanium is very expensive.  

The 2nd photo is of the magnet sticking out of the optic holder.  The hole that the magnet is sitting in has an aluminum piece ~2/3 of the way through.  A steel disk has been placed on one side, and the magnet on the other.  By doing this, we don't need to do any press-fitting (which was a concern whether or not the magnets could withstand that procedure), and we don't need to do any epoxying.  We'll have to wait until the ECDs are hung, and the optic holder suspended, to see whether or not the magnet is sticking out far enough to get to the ECDs. 

Attachment 1: 2_ECDs_small.jpg
2_ECDs_small.jpg
Attachment 2: MagnetStickingOutFar_small.jpg
MagnetStickingOutFar_small.jpg
  5639   Sun Oct 9 17:13:46 2011 kiwamuUpdateLSCFirst attempt to estimate mode matching efficiency using interferometer

The efficiency of the mode matching (MM) to PRC (Power-Recycling Cavity) has been estimated by using the interferometer.

The estimated MM efficiency is about 74 % when losses in the cavity are assumed to be zero.

 

(Motivation)

 There had been an issue that the recycling gain didn't go to the designed high value of about 42  (#5541).
One of the possibilities is a low efficiency in the MM to PRC (also see #5541).
Although the MM efficiency had been measured using a beam scan ( see a summary on the wiki) a long time ago, it haven't been verified.
Therefore the MM has to be reviewed by using the real interferometer.

(Measurement)

 The concept of this measurement is observe the amount of the reflected light from a power-recycled cavity and estimate the MM efficiency based on the measured reflectivities.
 Since using the real PRC (consisting of BS, ITMs and PRM) could be a too complicated system for this measurement,
simpler cavities, namely Power-Recycled ITMX and ITMY (PRX and PRY), were used to examine the MM efficiency.
 The measurement goes in the following order :
    (1) Measurement of the amount of the single-bounce reflection from PRM with BS and ITMs misaligned.
    (2) Lock PRX or PRY to carrier resonance.
    (3) Alignment of PRX/Y to maximize the intracavity power. This time ASDC was used as a monitor of the intracavity power.
    (4) Measurement of the amount of the reflected light when the cavity is in resonance. The value in REFLDC was averaged in 100 sec.
     => done by tdsavg 100 C1:LSC-REFLDC_OUT
The same measurement was performed for both PRX and PRY.
 
 - locking parameters -
  Sensor = REFL11_I
  Whitening gain = 10 (30 dB)
  PRCL_GAIN = 2
  UGF ~ 200 Hz

(Analysis)

In order to estimate the relation between the MM efficiency vs. the reflected light, two models are considered:
   (1) simple model => no loss and no sidebands
   (2) sideband-included model => no loss but sidebands are taken into the account of the reflection.
 
(1) In the simple model the reflectivity Prefl / Pin is expressed by
         [Reflectivity]  = Prefl / Pin = Z * Rcav +  (1- Z) * Rprm
 
where Z is MM efficiency and Rprm is the reflectivity of PRM
and Rcav is the reflectivity of PRX/Y when it's resonance and it is defined by
         Rcav = | rprm - ritm t2BS|2 / |1 -rprm ritm t2BS |2
 
Tprm = 5.75% and Titm = 1.4 % are assumed in all the calculations.
In the first equation the first term represents the mode matched light and hence it couples with the cavity through Rcav.
The second term is the non-mode-matched light and because they are not interacting with the cavity they will be simply reflected by PRM through Rprm.
 
(2) In reality two phase-modulated light (11 MHz and 55 MHz) will behave differently from the carrier.
For example when the carrier is in resonance the sidebands will be anti-resonance against the cavity.
So that the amount of REFLDC will be slightly bigger because of the reflection of the sidebands.
 
      Prefl = Z * Rcav * Pc + Z * Ranti * Ps +  (1- Z) * Rprm * (Pc + Ps)
 
where Pc and Ps are the power in the carrier light and the sidebands respectively.
And Ranti is the reflectivity of the anti-resonance PRX/Y, which can be obtained by replacing the minus sign by the plus sign in the equation of Rcav shown above.
It is assumed that the sum of the carrier power and sidebands power is the incident power Pin = Pc + Ps.
The power in the carrier and the sidebands were estimated based on the OSA measurement (#5519), so that
          Pc / Pin = |J0(0.14)|2 * |J0(0.17)|2 =  0.976
          Ps / Pin = 2 * |J1(0.14)|2 + 2 * |J1(0.17)|2 =  0.024
 

(Results)

Here are the measured values in REFLDC

 -- Measurement 1 : PRX
    Single bounce from PRM = 4802.27 counts
       ==> the incident power = 5095.25 counts
    Reflected light from PRX = 4433.88 counts
      ==> Reflectivity = 0.8702
 
-- Measurement 2 : PRY
    Single bounce from PRM = 4833.05 counts
       ==> the incident power = 5127.05 counts
    Reflected light from PRX = 4444.48 counts
      ==> Reflectivity = 0.86672
 
On average the reflectivity of power-recycled ITM cavity was 0.868 with a standard deviation of  0.001744.
Actually the standard deviation estimated here is not fair because the measurement was done by only twice,
but my intention was that I wanted to see how the error can affect the estimation of the MM efficiency.
Here is a plot comparing the model curves and the measured values with 5 sigma error box (5 times of measured standard deviation).

mm_reflection.png

It is shown that the mode matching efficiency is 73.7 % when the sideband-included model is considered.
With the 5 sigma deviation it can go from 65% to 82% but it is still low and lower than the beam scan measurement ( see a summary on the wiki). 

Anyways the estimated MM efficiency with the sidebands effect included and without loss effect is

        MM efficiency = 73.7 +/- 1.7 % (1 sigma error)  or +/- 8.7 % (5 sigma error)

ELOG V3.1.3-