ID |
Date |
Author |
Type |
Category |
Subject |
413
|
Thu Apr 3 19:27:50 2008 |
Andrey | Summary | Photos | Tour for prospective grad students |
Last Friday (March 28), there was a tour of 40-meter lab for prospective graduate students.
Rana showed to the prospective students the interferometer. See pdf-attachment with pictures (two pictures of Rana with undergraduates (I took them) and two old pictures which I discovered on the memory card of Nikon d-40, it was not me who took those two last pictures). |
Attachment 1: Rana_Lecturing.pdf
|
|
414
|
Fri Apr 4 16:54:06 2008 |
Andrey | Summary | Environment | Weather station is fully alive |
After today's trip to the roof of our building the weather station seems to be completely resurrected!
We went to the roof together with Steve Vass, and we discovered that:
(1) Sensors of wind speed, wind direction and the bowl that measures the amount of precipitation do not have any visible defects, so there is no problem with all those sensors even after being outside for seven years.
(2) We discovered that there are cable junctions located on the roof, and those junctions were located close to the rim (edge) of the roof, before the cables go inside of 40-meter lab room. The taping in the place of the junction was not good due to the age, and the connections between the cables were disrupted (cable endings were out of the connectors). Therefore, no signal from the roof sensors could be transferred to the 'Weather Monitor'. It was not wise from the person who installed the weather station to leave the fragile cable connections outside, on the roof, because the length of the cables allowed to locate those three connectors inside of the building.
See the attached PDF-file with pictures.
(3) After the cables were plugged into the connectors, these cable junctions were gently pulled into the inside of the 40-meter interferometer room. These cable junctions should not be located outside of the building!
Immediately after all the above-mentioned steps, the reasonable indications of outside temperature, humidity, pressure, wind speed and direction appeared on the 'Weather Monitor'.
In order to see if there is any problem of communication between the 'Weather Monitor' and UNIX control computers through 'c1pem1', I rolled out two brand new black cat-5 ethernet cables on the floor of the interferometer room (they are on the floor temporarily, the ethernet cable will go from the floor into the ceiling cable tray eventually), connected the two cables together through freshly purchased from Caltech bookstore cable connectors, and thus connected the 'Weather Monitor' to the processor 'c1pem1'.
Result: Now we can see reasonable indications of outside temperature, pressure, amount of precipitation, wind speed and direction on the EPICS screen! Moreover, these indications are changing with time.
As a reminder for everyone: standard atmospheric pressure is about 101kPa, so the indications of pressure as 99900Pa is quite reasonable.
One thing is not clear for me yet: wind speed on the 'Weather Monitor' is fluctuating between 2 and 4 mph, while MEDM EPICS-screen values are fluctuation in the range between 0 and 3mph.
Many thanks to Steve Vass and Alexander Ivanov for their help. |
Attachment 1: Work_on_the_Roof.pdf
|
|
420
|
Wed Apr 16 09:47:35 2008 |
Andrey | Summary | PEM | Weather Station |
The weather station is functional again.
The long ethernet Cat5 cable connecting 'WeatherLink' and processor 'c1pem1' was repaired yesterday, namely the RJ45 connector was replaced,
and information about weather conditions is now again continuously being transferred from the 'Weather Monitor' to the control UNIX computers. We can see this information in 'c0Checklist.adl' screen and in Dataviewer.
Below are the two sets of trends for the temperature, wind speed and direction, pressure and the amount of precipitation.
The upper set of trends ("Attachment 1") is "Full Data" in Dataviewer for the 3 hours from 6.30AM till 9.30AM this morning,
and the lower set of trends ("Attachment 2") is "Minute Trend" in Dataviewer for 15 hours from 6.30PM yesterday till 9.30AM this morning.
I also updated the wiki-40 page describing the Weather Station and added to there a description of the process of attaching the RJ45 connector to the end of ethernet Cat5 cable. To access the wiki-40 page about the "weather station" you should go from the main page to "PEM" section and click on "Weather Station". |
Attachment 1: Weather-FullData_3hrs.png
|
|
Attachment 2: Weather_Trend_15hrs.png
|
|
421
|
Wed Apr 16 10:20:01 2008 |
Andrey | Update | Computers | Rosalba and linux3 |
Quote: | There is a new computer in the control room -- its called Rosalba,
in keeping with our naming convention. Its a quad-core machine that
Dmass found for cheap somewhere; we've installed the CentOS on it
that Alex recommended.
Its a 64-bit Linux and so that may cause some problems. Alex has done this
before and so we have some confidence that we can get our regular tools (DTT, Dataviewer)
to run on it.
I have made a new apps tree for all of our future 64-bit Linux machines. So far, there is
a 64-bit firefox and a 64-bit matlab in there. As we start using this machine some more, we
will be forced to install more 64-bit Linux stuff.
We also didn't have enough network cables to run to both linux3 and rosalba. Andrey has decided that we
should not ditch linux3 and so he will run another cable for it tomorrow. |
The ethernet cable for linux3 was installed on Wednesday morning. Now linux3 has Internet connection again. |
424
|
Thu Apr 17 20:17:37 2008 |
Andrey | Update | PEM | Two issues with our weather station |
I encountered two difficulties working with the "Weather Station".
(1) It turns out that there is no indication for "outside humidity" on the "weather monitor" (a small black box located on the north wall of the interferometer). I realized that "outside humidity" is absent in our system when I tried to see the Dataviewer trend and real-time value from the channel "C1: PEM-weather-outsideHumid". It shows impossible number 128%.
It follows from the "Davis" technical documentation that the outside sensor can be of two types: either "External Temperature Sensor" or "External Temperature/Humidity Sensor". I suspect (I do not know for sure) that we have the first type of sensor "external temperature only" and therefore we in principle cannot have information about outside humidity. I propose to Steve to climb to the roof on Friday to resolve this uncertainty looking at the sensor.
(2) I wanted to change the units of pressure from "Pascal" (force/area) to other units, "mbar" for example. For this purpose I need to edit the file "Weather.st" in the directory /cvs/cds/caltech/target/c1pem1 (this file is run on the VME processor "c1pem1"). Unfortunately, when I try to open the file with emacs, I get the message that the file exists but protected from modifications. I do not know how to unblock the file "Weather.st". I need some help with that.
I thought that switching-off the processor "c1pem1" could resolve the issue, so I switched-off the whole crate where the processor "c1pem1" is installed for about 5 minutes, turning the metallic key. As it did not make any difference for the accessibility of the file "Weather.st", I switched-on the crate after 5 minutes. There are other processors besides "c1pem1", so they were turned-off for several minutes earlier today.
Also, I created a new MEDM screen which has information about weather only, a smaller version of the "C0Checklist.adl" MEDM screen. Both screens are now located under the most top-left button "Checklist" of the main MEDM screen. |
427
|
Fri Apr 18 16:48:13 2008 |
Andrey | Update | PEM | Rain collector of weather station |
Today the rain collector of our weather station was cleaned. As a result, we checked that the rain indication on the weather monitor and on the MEDM screens is alive and working properly. I am adding some details about the roof sensors to the wiki-40 page about the weather station. See especially the link "More description of the roof sensors and their interaction with UNIX computers" from the main Weather Station page in wiki-40.
Pictures of the rain collector before (dirty, the opening is fully clogged with dust and dirt) and after (clean opening in the bottom of the bowl) the cleaning are attached. |
Attachment 1: DSC_0520--before.JPG
|
|
Attachment 2: DSC_0537--after.JPG
|
|
440
|
Wed Apr 23 22:39:54 2008 |
Andrey | DAQ | Computer Scripts / Programs | Problem with "get_data" and slow PEM channels |
It turns out that I cannot read minute trends for the slow weather channels for more than 1000 seconds back (roughly more than 15 minutes ago) using "get_data" script.
For comparison, I tried MC1 slow channels, and similar problem did not arise there. Probably, something is wrong with the memory of slow weather channels. At the same time, I can see minute-trends in Dataviewer as long ago as I want.
In response to
>>get_data('C1: PEM-weather_outsideTemp', 'minute', gps('now') - 3690, 3600);
I get the error message:
"Warning: Missong C1: PEM-weather_outsideTemp M data at 893045156". |
444
|
Thu Apr 24 22:06:47 2008 |
Andrey | Summary | Computers | Ethernet Cables and Hubs |
Today in the morning (between 8.30AM and noon) Joe and I were working on understanding which ethernet cables connect "processors controlling the work of equipment in the interferometer room" and "Internet hub in the computer room".
Firstly, we took off several times the blue ethernet cables from the router located near ETMX in the morning. We were trying to understand which port in the hub is responsible for the interaction with that processor.
Secondly, we were working on reviving the connection with the computer controlling vacuum in the interferometer.
Later in the middle of the day (around 2PM) Joe continued some work with ethernet cables without me. We plan on continuing the cable work on Friday morning. A better and more detailed elog will appear then. |
447
|
Fri Apr 25 11:33:40 2008 |
Andrey | Configuration | Computers | Computer controlling vaccum equipment |
Old computer (located in the south-end end of the interferometer room) that was almost unable to fulfill his duties of controlling vacuum equipment has been replaced to "Linux-3". MEDM runs on "Linux-3".
We checked later that day together with Steve Vass that vacuum equipment (like vacuum valves) can be really controlled from the MEDM-screen 'VacControl.adl'.
Unused flat LCD monitor, keyboard and mouse (parts of the former LINUX-3 computer) were put on the second shelf of the computer rack in the computer room near the HP printer. |
448
|
Fri Apr 25 13:20:04 2008 |
Andrey | Update | PEM | Microphone test |
In response to Rana's request, I tested the microphone (if it is alive or not) by clapping my hands and speaking aloud nearby.
The microphone is alive, see the attached "Full Data" for 5 minutes from Dataviewer. |
Attachment 1: Microphone.png
|
|
452
|
Sat Apr 26 01:45:38 2008 |
Andrey | Summary | PEM | Weather Station enhancement |
Two more things concerning weather monitoring have been done during this week.
1) A Dataviewer template was created, so that it allows to see "real-time" information from weather channels immediately, without adding many channels "manually".
If one wants to use this template,
open Dataviewer -> "File" -> "Restore Settings", /cvs/cds/caltech/users/Templates/Dataviewer_Templates/Weather.xml.
2) I wrote a couple of Matlab scripts that allow to read data (minute trends) from the Dataviewer channels over some time in the past, save the received data in mat-files, and plot those minute-trends. Thus, one can get plots that are very much similar to what one can see in Dataviewer. These two Matlab files are located in the directory
"/cvs/cds/caltech/users/weather_station". File "WeatherReading.m" allows reading from the weather channels (paths to mDV directory must be configured before using my script), file "WeatherTrends.m" allows plotting of those minute trends.
Unfortunately, hardware problems arise very often if we want to read for a somewhat long time in the past, so until now I have not succeeded in getting trends for more than 20 minutes. As an example, see the attached png-file with the 20-minutes trends of data from Thursday evening.
3) So far I did not have success in learning how to recalculate pressure from Pascals to mbars in EPICS (although I tried google-search).
4) I am making every effort in recent weeks not to put any personal or non-scientific information into elog, but this message could be important for all of us, so I cannot resist:
a shark in the Pacific Ocean has killed a swimmer near San-Diego (I saw this in russian news and then made a quick google-search).
http://latimesblogs.latimes.com/lanow/2008/04/this-just-in-fa.html |
Attachment 1: Matlab_Weather_Trends.png
|
|
458
|
Mon Apr 28 23:44:33 2008 |
Andrey | Update | Computer Scripts / Programs | Weather.db |
I was trying to figure out how to modify the file "Weather.db" so that the atm.pressure would be recalculated from Pa to bar before appearing in the EPICS screen, but so far I did not succeed. I restarted processor "c1pem1" several times. I will continue this tomorrow, and also I will modify the nmaes of the weather channels. |
460
|
Tue Apr 29 21:30:49 2008 |
Andrey | Update | PEM | In the process of renaming channels for Weather Station |
I startted renaming channels for the weather station, and I will continue this tomorrow, on Wednesday.
I have restarted 'c1pem1' several times and reconfigured "C0DCU1" on the framebuilder MEDM screen.
Framebuilder now does not work. |
461
|
Wed Apr 30 20:48:58 2008 |
Andrey | Summary | PEM | New Weather Channels |
I created the new channels for the weather station, all letters are capital ones. They are of the form "C1 : PEM-WS_PARAMETER" where "PARAMETER" is temperature, pressure, wind,... characteristics (names are self-obvious).
These new weather channels are indicated on the "Weather Checklist" MEDM screen. Also, units of pressure were changed from Pascal to torr and mbars.
The new weather channels are also visible in Dataviewer. I updated the template, and as an example of Dataviewer data I attach the following 5-hour trends of weather parameters from 3.30PM to 8.30PM on April 30th. |
Attachment 1: April30-5hours.png
|
|
476
|
Wed May 14 13:14:19 2008 |
Andrey | Summary | Computers | Reflective Memory Network is restored |
Reflective Memory Network is restored, all watchdogs and oplevs are returned to the "enabled" state.
In order to revive the computers, several things were done.
1) Following Mr. Adhikari's elog entry #353, I walked around the interferometer room, and switched off the power keys in all crates with computers whose names are contained in the MEDM Reflective Memory screen, including the rack with the framebuilder. By the way, it was nontrivial to find the switch in the 1Y4 crate that would shut off/on processors "c1susvme1" and "c1susvme2": the switch turned out to be located at the rear side of the crate, and it is not a key but it is a button.
2) I was trying to follow wiki-40 computer restart procedures, but every time that I was trying to run "startup.cmd" screen from the corresponding target subdirectory, I got the error message "Device or resource busy".
By the way, one more thing was learned: if you firstly open in terminal burtgooey, select the snap file, then reboot the processor, and then will try to burt-restore it, you will get the message "Status Not OK". In order to really burt-restore the processor which was recently rebooted, you need to close the terminal with burtgooey and open burtgooey in a new terminal window which should be opened after rebooting the processor.
Feeling that my activities according to wiki-40 procedures do not revive computers, I invited Alex Ivanov.
3) Alex tried to touch the memory card in "c1iovme" in rack 1Y2, because once before this card failed causing network problems, but this did not help.
4) We shutted off and restarted again (pressing the power-switching button) the black Linux machine "c1dcuepics" (located in the very bottom below the framebuilder). Alex says that this machine is responsible for all EPICS. It was not restarted for 182 days, and probably some process there went wrong.
After restarting this machine "c1dcuepics" we were able to follow wiki-40 procedures for restarting all other computers (whose names are on the MEDM RFM network). We ran correcponding "startup.cmd" files and burt-restored them without error messages.
Now all the computers work and communicate in a proper way.
Mr. Joseph Betzwiezer was helping me with all these activities (we decided that it is more important that cameras for now), thanks to him. But our joint skills turned out to be insufficient, so Alex Ivanov's contribution was the most important. |
477
|
Wed May 14 14:05:40 2008 |
Andrey | Update | Computers | Computer Linux-2, MEDM screen "Watchdogs" |
Computer "Linux-2", MEDM screen "C1SUS_Watchdogs.adl": there is no indication for ETMY watchdogs, everything is white. There is information on that screen "C1SUS_Watchdogs.adl" about all other systems (MC, ETMX,...), but something is wrong with indicators for ETMY on that particular control computer. |
483
|
Fri May 16 17:27:55 2008 |
Andrey | Omnistructure | General | Toilets are broken, do not use them !!! |
Both toilets in 40-meter were constantly flushing, the leaking water was on the floor inside of the restrooms, so
BOTH RESTROOMS ARE CLOSED TILL MONDAY
I have heard the constant loud sound of flushing water, opened the door, and was unpleasantly surprised because all the floor was under the layer of water and the toilets were constantly flushing. I called security at X5000, a plumber came in and told that a team of plumbers needs to repair the flushing system after the weekend. The plumber today just shut off the flushing water, wiped off the floor and told not to use the restrooms in the weekend. We should expect a team of plumbers on Monday.
Sinks are working, so you can wash your hands. |
512
|
Tue Jun 3 02:15:29 2008 |
Andrey | Summary | Cameras | Fitting results |
There have been a lot of work going on related to the processing of images captured by the cameras GC-650 and GC-750 recently.
In the end of the week of May 30 Joseph and me (Andrey) installed the two cameras capturing the images of the pick-off of the main beam on the PSL optical table. The cameras are located after the picked-off beam going towards the "PSL position QPD", after the 33-66 beamsplitter (33% of reflection and 66% of transmission).
Initially (on May 30) the GC-650 camera was taking the images of reflected beam, while the camera GC-750 was taking images of transmitted beam. On Monday June 2 we switched the positions of the cameras, so GC-650 appeared to be on the path of the transmitted beam and GC-750 on the path of the reflected beam.
I (Andrey Rodionov) was able in the weekend to succeed in writing a Matlab program that performs the two-dimensional Gaussian fitting of the captured images, and I used that program to fit the images from the cameras.
The program fits the camera data by a two-dimensional Gaussian surface:
Z = A * exp[ - 2 * (X - X_Shift)^2 / (Waist_X)^2 ] * exp[ - 2 * (Y - Y_Shift)^2 / (Waist_Y)^2 ] + CONST_Shift,
where A, X_Shift, Waist_X, Y_Shift, Waist_Y, CONST_Shift are 6 parameters of the fit.
Attached are the pdf-files showing the results: images taken with our cameras, the 2-dimensional Gaussian fit for these images and the surfaces of residuals. Residuals are differences between the exact beam profile and the result of fitting. In normalized version of residual graph I normalize it by the first coefficient of fitting A, the factor in front of the exponents. |
Attachment 1: May30-GC650.pdf
|
|
Attachment 2: May30-GC750.pdf
|
|
Attachment 3: June02-GC650.pdf
|
|
Attachment 4: June02-GC750.pdf
|
|
515
|
Tue Jun 3 12:33:36 2008 |
Andrey | Update | Cameras | Andrey, Josephb |
Continuing our work with cameras,
1) we removed both cameras from their places on Monday afternoon, and were taking the beam-scans with a special equipment (see elog-entry 511) from Bridge bld.,
2) and on Tuesday morning we putted back the GC-750 camera into the transmitted beam path, camera GC-650 into the reflected beam path. We plan to compare the images from the "reflection camera" for several different angles of tilt of the camera. |
10101
|
Wed Jun 25 14:52:22 2014 |
Andres Medina | Update | elog | Placing a lens between the steering mirrors and another lens between the second steering mirror and the cavity |
I was asked to calculate the lenses that we need in order to obtained a Gouy phase close to 90 degrees between the two mirrors that are in the Xend green. Yesterday, I measured the distances between the mirrors, and the distance between the mirror relative to the cavity as illustrate in the image attached below. I looked in to the 40m elog and Manasa did the last update on the length of the cavity. She measured 37.7 + 0.05m. The waist size of the beam that was measured by Annalisa in ID 8637 after the Faraday was w0=2.943e-5m @ -0.039m. I calculated the waist size inside the cavity, and I found a waist of w0=2.2 mm. My plan this week is to keep working in the calculation and finish all the calculation this week so that next week I can go inside and place the lenses. |
Attachment 1: SchematicForXendGreenGoingToTheCavity.pdf
|
|
10130
|
Sat Jul 5 04:18:45 2014 |
Andres | Update | 40m Xend Table upgrade | Adding Two Lenses After the Second Steering Mirror in Order Two Increase the Gouy Phase Difference Between the Sterring Mirrors |
I had been working on the Xend table optical layout update. Since the two steering mirrors in the Xend green are too close to each, there is a very small Gouy Phase different between these two mirrors. It was suggested to place two lenses so that we can increase the Gouy Phase. I have been working with Nick on this problem, and we had found a solution by using a la mode. We had written an a la mode code that optimize the Gouy Phase and the Mode Matching at the same time. After trying different lenses, we found the following results: a mode matching of 0.9939 as it is show in the first attachment below, and we found a Gouy Phase different between the two mirrors of about 60 degrees. I took photos of the Xend Table. The first photo is the Xend table as we had it right now. In the second photo, I moved the 2nd lens, and I placed the two more lenses that we need it, with more or lenses the correct position where they will be placed. The three old lenses will be replaced by three lenses of different focal length as it can be seen in the first attachment below. The first lens and third lens will stay in the same position where the old first lens and old third lens are, and the second lens will be moved by about half of an inch. We might have one or two of the lenses that we need, but we will have to order the rest of the lenses that need. My plan is to verify the lenses that we already have. Then, I need to let Nick know with lenses we need to order. Hopefully, we will be able to update the table by the end of this week if everything turn out fine. |
Attachment 1: OverlapAndComponentsOfTheSolution.png
|
|
Attachment 2: CloseLookToTheGouyPhaseBetweenMirr1AndMirr2.jpg
|
|
Attachment 3: EntireRangeOfBeamPath.jpg
|
|
Attachment 4: XendTableWithTwoNeedLensesAdding.JPG
|
|
Attachment 5: SchematicOfSolutionForTheLensesGouyPhase.jpeg
|
|
Attachment 6: XendGreenModeMatchingAndGouyPhaseOptimization.m
|
clear all
% In this code we are using a la mode to optimatize the mode matching and
% to optimatize the Gouy phase between mirror 1 and mirror 2. All the units
% are in meter
w0=2.943*1e-5; % The Waist of the laser measured before the faraday
z0_laser=-0.039; % position measured where the waist is located
lamb= 532*10^-9; % wavelength of green light in mm
lFaraday=.0638; % Length of the faraday
... 148 more lines ...
|
Attachment 7: BeforeIncludingLensesORMovingLenses.JPG
|
|
10191
|
Sun Jul 13 17:06:35 2014 |
Andres | Update | 40m Xend Table upgrade | Xarm Table Upgrade Calculation and Diagrams of possible new table layout |
Current Mode Matching and Gouy Phase Between Steering Mirrors
We found in 40m elog ID 3330 ( http://nodus.ligo.caltech.edu:8080/40m/3330) a documentation done by Kiwamu, where he measured the waist of the green. The waist of the green is about 35µm. Using a la mode, I was able to calculate the current mode matching, and the Gouy phase between the steering mirrors. In a la mode, I used the optical distances,which is just the distance measured times its index of refraction. I contacted someone from ThorLabs (which is the company that bought Optics For Research), and that person told that the Faraday IO-5-532-LP has a Terbium Gallium Garnet crystal of a length of 7mm and its index of refraction is 1.95. The current mode matching is 0.9343, and the current Gouy phase between steering mirrors is 0.2023 degrees. On Monday, Nick and I are planning to measure the actual mode matching. The attached below is the current X-arm optical layout.
Calculation For the New Optical Layout
Since the current Gouy phase between the steering mirror is essentially zero, we need to find a way how to increase the Gouy Phase. We tried to add two more lenses after the second steering mirror, and we found that increasing the Gouy phase result in a dramatically decrease in mode matching. For instance, a Gouy phase of about 50 degrees results in a mode matching of about .2, which is awful. We removed the first lens after the faraday, and we added two more mirrors and two more lenses after the second steering mirror. I modified the photo that I took and I place where the new lenses and new mirrors should go as shown in the second pictures attached below. Using a la mode, we found the following solution:
label z (m) type parameters
----- ----- ---- ----------
lens 1 0.0800 lens focalLength: 0.1000
First mirror 0.1550 flat mirror none:
Second mirror 0.2800 flat mirror none:
lens 2 0.4275 lens focalLength: Inf
lens 3 0.6549 lens focalLength: 0.3000
lens 4 0.8968 lens focalLength: -0.250
Third mirror 1.0675 flat mirror none:
Fourth mirror 1.4183 flat mirror none:
lens 5 1.6384 lens focalLength: -0.100
Fifth mirror 1.7351 flat mirror none:
Sixth mirror 2.0859 flat mirror none:
lens 6 2.1621 lens focalLength: 0.6000
ETM 2.7407 lens focalLength: -129.7
ITM 40.5307 flat mirror none:
The mode matching is 0.9786. The different Gouy phase different between Third Mirror and Fourth Mirror is 69.59 degrees, Gouy Phase between Fourth and Fifth 18.80 degrees, Gouy phase between Fifth and Sixth mirrors is 1.28 degrees, Gouy phase between Third and Fifth 88.38 degrees, and the Gouy phase between Fourth and Sixth is 20.08 degrees. Bellow attached the a la Mode code and the Plots.
Plan for this week
I don't think we have the lenses that we need for this new setup. Mostly, we will need to order the lenses on Monday. As I mention, Nick and I are going to measure the actual mode matching on Monday. If everything look good, then we will move on and do the Upgrade.
|
Attachment 1: CurrentOpticalLayout.png
|
|
Attachment 2: NewSetUp.PNG
|
|
Attachment 3: AlaModeSolutionplots.png
|
|
Attachment 4: EntireScaleRangeAlaModeSolution.png
|
|
Attachment 5: NewXarmOptimizationFromFaraday.m
|
close all
clear all
% In this code we are using a la mode to optimatize the mode matching and
% to optimatize the Gouy phase between mirror 1 and mirror 2. All the units
% are in meter
w0=(50*1e-6)/sqrt(2); % The Waist of the laser measured after SHG
z0_laser=-0.0083; % position measured where the waist is located
lamb= 532*10^-9; % wavelength of green light in mm
lFaraday=.0638; % Length of the faraday
... 209 more lines ...
|
10195
|
Mon Jul 14 16:19:41 2014 |
Andres | Update | 40m Xend Table upgrade | Took the measurement for the Mode Matching |
Nick and I measured the reflected power of the green light in locked and unlocked. I'm working on the calculation of the mode matching. Tonight, I'll be posted my calculation I'm still working on it.
JCD: Andres forgot to mention that they closed the PSL shutter, so that they could look at the green light that is reflected off the harmonic separator toward the IR trans path. Also, the Xarm (and the Yarm) were aligned to IR using the ASS, and then ASX was used to align the green beam to the cavity. |
10207
|
Tue Jul 15 22:23:51 2014 |
Andres | Update | 40m Xend Table upgrade | Scan the Xarm for the mode matching |
Nick and I with the help of Jenne scan the green light when the cavity is unlocked. Nick placed a Beam dump on the IR so that we can just scan the green, but it was removed as soon as we finished with the measurement. I'm working on the calculation, and i'll be posted solution tonight. |
10226
|
Thu Jul 17 02:57:32 2014 |
Andres | Update | 40m Xend Table upgrade | FInish Calculation on Current X-arm mode Matching |
Data and Calculation for the Xarm Current Mode Matching
Two days ago, Nick, Jenne, and I took a measurement for the Green Transmission for the X-arm. I took the data and I analyzed it. The first figure attached below is the raw data plotted. I used the function findpeaks in Matlab, and I found all the peaks. Then, by taking close look at the plot, I chose two peaks as shown in the second figure attached below. I took the ratio of the TEM00 and the High order mode, and I average them. This gave me a Mode Matching of 0.9215, which this value is pretty close to the value that I predicted by using a la Mode in http://nodus.ligo.caltech.edu:8080/40m/10191, which is 0.9343. Nick and I measured the reflected power when the cavity is unlocked and when the cavity is locked, so we measured the PreflUnLocked=52+1µW and PreflOnLocked=16+2µW and the backgroundNoise=0.761µW. Using this information we calculated Prefl/Pin=0.297. Now, since Prefl/Pin=|Eref/Ein|2, we looked at the electric fields component by using the reflectivity of the mirror we calculated 0.67. The number doesn't agree, but this is because we didn't take into account the losses when making this calculation. I'm working in the calculation that will include the losses.
Today, Nick and I ordered the lenses and the mirrors. I'm working in putting together a representation of how much improvement the new design will give us in comparison to the current setup.
|
Attachment 1: RawDataForTheModeGreenScan.png
|
|
Attachment 2: ResultForModeMatching.png
|
|
Attachment 3: DataAndCalculationOfModeMismatch.zip
|
10237
|
Fri Jul 18 16:52:56 2014 |
Andres | Update | 40m Xend Table upgrade | FInish Calculation on Current X-arm mode Matching |
Quote: |
Data and Calculation for the Xarm Current Mode Matching
Two days ago, Nick, Jenne, and I took a measurement for the Green Transmission for the X-arm. I took the data and I analyzed it. The first figure attached below is the raw data plotted. I used the function findpeaks in Matlab, and I found all the peaks. Then, by taking close look at the plot, I chose two peaks as shown in the second figure attached below. I took the ratio of the TEM00 and the High order mode, and I average them. This gave me a Mode Matching of 0.9215, which this value is pretty close to the value that I predicted by using a la Mode in http://nodus.ligo.caltech.edu:8080/40m/10191, which is 0.9343. Nick and I measured the reflected power when the cavity is unlocked and when the cavity is locked, so we measured the PreflUnLocked=52+1µW and PreflOnLocked=16+2µW and the backgroundNoise=0.761µW. Using this information we calculated Prefl/Pin=0.297. Now, since Prefl/Pin=|Eref/Ein|2, we looked at the electric fields component by using the reflectivity of the mirror we calculated 0.67. The number doesn't agree, but this is because we didn't take into account the losses when making this calculation. I'm working in the calculation that will include the losses.
Today, Nick and I ordered the lenses and the mirrors. I'm working in putting together a representation of how much improvement the new design will give us in comparison to the current setup.
|
We want to be able to graphically see how much better it is the new optical table setup in comparison to the current optical table setup. In other words, we want to be able to see how displacement of the beam and how much angle change can be obtained at the ETM from changing the mirrors angles independently. Depending on the spread of the mirrors' vectors we can observe whether the Gouy phase is good. In the plot below, the dotted lines correspond to the current set up, and we can see that the lines are not spread from each other, which essentially mean that changing the angles of the two mirrors just contribute to small change in angle and in the displacement of the beam at the ETM, and therefore the Gouy phase is not good. Now on the other hand. The other solid lines correspond to the new setup mirrors. We can observe that the spread of the line of mirror 1 and mirror 4 is almost 90 degrees, which just implies that there is a good Gouy phase different between these two mirrors. For the angles chosen in the plot, I looked at how much the PZT yaw the mirrors from the elog http://nodus.ligo.caltech.edu:8080/40m/8912. In this elog, they give a plot in mrad/v for the pitch and yaw, so I took the range that the PZT can yaw the mirrors, and I converted into mdegrees/v and then I plotted as shown below. I plot for the current setup and for the new setup in the same plot. The matlab code is also attached below. |
Attachment 1: OldAndNewSetupPlotsOfDisplacementAndAngleAtTheETM.png
|
|
Attachment 2: OldSetUpDisplacementAndNewSetup.m.zip
|
10290
|
Tue Jul 29 20:14:08 2014 |
Andres | Update | 40m Xend Table upgrade | Xarm Green steering mirror upgrade |
Xarm Green Steering Mirror Upgrade
Nick and I did the upgrade for the green steering mirror today. We locked in the TEM00 mode.
We placed the shutter and everything. We move the OL, but we placed it back. Tonight, I'll be doing a more complete elog with more details. |
10296
|
Wed Jul 30 10:16:54 2014 |
Andres | Update | 40m Xend Table upgrade | Green Steering Mirror Upgrade completed |
Green Steering Mirror Update
Yesterday, Nick and I completed the green steering mirrors upgrade. I attached the file that contained the procedure that we plan before we did the upgrade. We placed an iris at the input of the OL and we place another iris before the harmonic separator. We did not use the beam scanner because someone was using it, so what we did was to assume that the cavity is well align and place the iris so that we can recover the alignment. We used the measuring tape to approximate as close as we could the position where the lenses were supposed to go. I did a measurement of the derivative of the waist size in terms of the position of the lens and the derivative of the waist Position in terms of the lenses position at the optimum solution that a la mode give us. Because of this plot, we decide to mount lens 3 and lens 5 into translational stages. After mounting each lenses and mirrors we worked on the alignment of the beam into the cavity. We were able to align the green into the cavity and we were able to locked the cavity to the TEM00 mode. We started to work on the optimization of the mode matching. However, the maximum mode matching that we got was around 0.6, which we need to work a little bit more on the tuning of the mode matching. We leave the iris mounted on the table. I took a picture of the table, and I attached below. For the OL, we just make sure that the output where somehow hitting the QPD, but we didn't really I aligned it. We need to work a little bit more on the alignment of the OL and the tuning of the mirror to maximize the green mode matching. |
Attachment 1: XarmUpgrade.pdf
|
|
Attachment 2: dWaistSize_dlensVsdWaistPosition_dlens.png
|
|
Attachment 3: XarmNewOpticalSetup.PNG
|
|
10374
|
Wed Aug 13 10:50:04 2014 |
Andres | Update | IMC | Calculation for the input mode cleaner |
Calculation for the input mode cleaner
I have been working on the calculation for the input mode cleaner. I have come out with a new optical setup that will allow us increase the Gouy phase different between the WFS to 90 degrees. I use a la mode to calculate it. The a la mode solution :
label z (m) type parameters
----- ----- ---- ----------
MC1 0 flat mirror none:
MC3 0.1753 flat mirror none:
MC2 13.4587 curved mirror ROC: 17.8700
Lens1 29.6300 lens focalLength: 1.7183
BS2 29.9475 flat mirror none:
First Mirror 30.0237 flat mirror none:
WFS1 30.2269 flat mirror none:
Second Mirror 30.2650 flat mirror none:
Third Mirror 30.5698 flat mirror none:
Lens2 30.9885 lens focalLength: 1
Fourth Mirror 31.0778 flat mirror none:
Lens3 31.4604 lens focalLength: 0.1000
Fifth Mirror 31.5350 flat mirror none:
Sixth Mirror 31.9414 flat mirror none:
WFS2 31.9922 flat mirror none:
I attached a pictures how the new setup is supposed to look like. |
Attachment 1: ModeCleanerSetup0.PNG
|
|
Attachment 2: alaModeModeCleanersolution.png
|
|
10384
|
Thu Aug 14 15:10:47 2014 |
Andres | Update | IMC | Calculation for the input mode cleaner |
Quote: |
Can you please give us some more details on how this design was decided upon? What were the design considerations?
It would be nice to have a shorter path length for WFS2. What is the desired spot size on the WFS? How sensitive are they going to be to IMC input alignment? Are we still going to be recentering the WFS all the time?
|
I did the calculation, and I reduced the beam Path. In my calculation, I restricted the waist size at the WFSs to be between 1mm-2mm also the other parameter is that the Gouy Phase different between the WFSs have to be 90 degrees. I also try to minimize the amount of mirrors used. I found the Gouy phase to be 89.0622 degrees between the WFSs and the following table shows the solution that I got from a la mode:
label z (m) type parameters
----- ----- ---- ----------
MC1 0 flat mirror none:
MC3 0.1753 flat mirror none:
MC2 13.4587 curved mirror ROC: 17.8700 (m)
Lens1 28.8172 lens focalLength: 1.7183(m)
BS2 29.9475 flat mirror none:
First Mirror 30.0237 flat mirror none:
Lens3 30.1253 lens focalLength: -0.100 (m)
Lens2 30.1635 lens focalLength: 0.1250(m)
WFS1 30.2269 flat mirror none:
Second Mirror 30.2650 flat mirror none:
Third Mirror 30.5698 flat mirror none:
Lens4 30.8113 lens focalLength: -0.075 (m)
WFS2 31.0778 flat mirror none:
In the first image attached below is the a la mode solution that show the waist size in the first WFS, and I used that solution to calculate the solution of the waist size for the second WFS, which is shown in figure 2. I photoshop a picture to illustrate how the new setup it supposed to look like. |
Attachment 1: SolutionForTheModeCleanerSetup00.png
|
|
Attachment 2: SolutionForTheModeCleanerSetup11.png
|
|
Attachment 3: PossibleSetupForModeCleaner.PNG
|
|
Attachment 4: alaModeSolution.zip
|
10410
|
Tue Aug 19 21:40:44 2014 |
Andres | Update | IMC | New Optical Setup for the IMC |
IMC Calculation and Setup
I have been working in the calculation for improving the Gouy Phase separation between the WFSs. I tried different possible setup, but the three big constrains in choosing a good optical table setup are to have a Waist size that range from 1mm-2mm, the Gouy Phase between the WFSs have to be greater than 75 degrees and there has to be a steering mirror before each WFS. I will be showing the best calculation because that calculation complies with Rana request of having both WFSs facing west and having the shortest beam path. I approximate the distances by measuring with a tape the distance where the current optics are located and by looking at the picture that I took I approximated the distance where the lenses will be placed. I'm using a la mode for calculating the gouy phase different. I attached a picture of the current optical table setup that we have. Using a la mode, I found that the current gouy phase that we have is 49.6750 degrees.
Now, for the new setup, a run a la mode and found a Gouy phase of 89.3728 degrees. I have to create a two independent beam path: one for the WFS1 and another one for WFS2. The reason for this is that a la mode place everything in one dimension so and since the WFS1 will have a divergence lens in order to increase the waist size, and since that lens should not be interacting with the waist size in the WFS2. We need two beam path for each WFS. A la mode give us the following solution:
For the beam path of the WFS1
label z (m) type parameters
----- ----- ---- ----------
MC1 0 flat mirror none:
MC3 0.1753 flat mirror none:
MC2 13.4587 curved mirror ROC: 17.8700 (m)
Lens1 29.3705 lens focalLength: 1.0201 (m)
BS2 29.9475 flat mirror none:
First Mirror 30.0237 flat mirror none:
Lens3 30.2000 lens focalLength: -0.100 (m)
WFS1 30.4809 flat mirror none:
For the beam path of the WFS2
label z (m) type parameters
----- ----- ---- ----------
MC1 0 flat mirror none:
MC3 0.1753 flat mirror none:
MC2 13.4587 curved mirror ROC: 17.8700 (m)
Lens1 29.3705 lens focalLength: 1.0201 (m)
BS2 29.9475 flat mirror none:
Second Mirror 30.2650 flat mirror none:
Lens2 30.4809 lens focalLength: -0.075 (m)
Third Mirror 30.5698 flat mirror none:
WFS2 30.6968 flat mirror none:
I attached bellow how the new setup should look like in the second picture and also I include and attachment of the a la mode code.
I used Mist to be able to see the read out that we get in the WFSs that take the Mode Cleaner Reflection and the QPD that take the transmitted from MC2. In the following, plots I'm misaligned the each mirrors: MC1, MC2 and MC3. The misalignment are in Yaw and Pitch. I'm dividing the WFSs reading by the total power reflect power, and I'm dividing the QPD for the MC2 transmission by the total transmitted power. In my Mist model, I have a laser of 1W and my EOM is modulated at 30MHz instead of 29.5MHz and the modulation depth was calculating by measuring the applied voltage using and Spectrum analyzer. I using Kiwamu measurement of modulation depth efficiency vs the applied voltage, https://dcc.ligo.org/DocDB/0010/G1000297/001/G1000297-v1.pdf, I got a modulation depth of 0.6 mrad. I put this modulation depth and I got the following plots: The fourth and fifth attachment are for the current optical setup that we have. The sixth and seventh attachment is for the new optical setup. The eighth attachment is showing the mode cleaner cavity resonating. The last attachment contains the plots of WFS1 vs WFS2, MC2_QPD vs WFS1, MC2_QPD vs WFS3 for each mirror misaligned. The last two attachment are the MIST code for the calculation.
We have all the lenses that we need. I checked it last Friday and if everything is good we will be ready to do the new upgrade this coming Friday. For increasing the power, I check and we have different BS so we can just switch from the current setup the BS. Can you let me know if this setup look good or if I need to chance the setup? I would really love to do this upgrade before I leave.
|
Attachment 1: ModeCleanerSetup.PNG
|
|
Attachment 2: NewOpticalTableSetupForTheModeCleaner.PNG
|
|
Attachment 3: ReduceWFSPathWorkingOn.m.zip
|
Attachment 4: MIST_WFSsAndQPDReadingForYaw.png
|
|
Attachment 5: MIST_WFSsAndQPDReadingForPitch.png
|
|
Attachment 6: MIST_WFSsAndQPDReadingForYawNewSetup.png
|
|
Attachment 7: MIST_WFSsAndQPDReadingForPitchNewSetup.png
|
|
Attachment 8: MISTResonanceCavityReflectionAndTransmissionNewSetup.png
|
|
Attachment 9: 2Dplots.zip
|
Attachment 10: ModeCleanerCurrentOpticalTableMIST.zip
|
Attachment 11: ModeCleanerNewSetupMIST.zip
|
10427
|
Fri Aug 22 18:05:02 2014 |
Andres | Update | IMC | Upgrade of the IMC WFSs for the reflection |
Upgrade of IMC Reflection Optical Setup
Nick and I upgrade the IMC. We move both WFSs and placed them facing west. When aligning the beam into the WFS, we make sure that the beam were hitting the center of the mirrors and then we placed the lenses in their corresponding position. We used the beam scanner to measure the waist and the waist in the second WFS was bigger than 1mm, and the second WFS was a little bit below than 1mm. We center the beam in the WFSs and in the PD. We did haven't measure whether we have a good Gouy Phase. Below I attached the picture of how the new setup look like.
|
Attachment 1: ModeCleanerUpgrade.PNG
|
|
17633
|
Fri Jun 16 14:03:08 2023 |
Andrei | Update | PEM | Lab temperature psd |
[andrei, advait]
I have analyzed the temperature data that we have collected for the past 10 days or so from the X-end temperature sensor that is accessible via Acromag.

The average temperature was 20.74 Celsius, noticeably cooler than the average 24 Celsius in the control room. The day-night temperature variations are clearly visible.

And here is the power spectrum density of these variations:

The red line indicates the frequency of the day-night cycle (1/24hrs), while the green line indicates twice the frequency of the day-night cycle. We can see that the two lines align fairly well with the peaks, which is to be expected. Here I used n_avg=3 in Paco's spec_dens() function, but I am not sure this is the right value to use. Please let me know if you have suggestions in this regard.
As for the noise estimates of the detector used to collected these data, I am not sure how to get those. The above temperature data was collected using a detector that no one knows where exactly it is in the lab, and I don't even know what type of sensor it is. Perhaps there is a way to get a noise estimate from the data that I collected? Again, please let me know.
However, we have a rough estimate for the noise of the AD590 sensor made by Kira that we calibrated and used for the step response test. We estimated this by calculating the standard deviation of the signal measured from the 0 C ice bath. This translates to 0.0134 C. We will probably repeat this measurement in a better way (once we build our own version of the sensor) because the duration of the actual 0 C measurement was just around 2 minutes. |
17644
|
Wed Jun 21 11:16:19 2023 |
Andrei | Update | PEM | Ambient Temperature sensor noise measurements |
I found the sensor that we used to measure the tmeperature in the lab. It is a SensorGateway (BASE-WIRED) and according to its datasheet it has a temperature resolution of 0.1 Celsius and an accuracy of 1 Celsius. Regardless, I also let it collect some data overnight to get a better grasp of the noise.
I put the sensor in a box, wrapped around two towels. I tried closing the box as much as possible, but the cables connecting to the sensor prevented me from closing the box all the way. I put the box in the same spot where the sensor sat when the environment data was collected. Here is the picture of the device:

I started the data collection yesterday at around 5pm. Here is the raw temperature data collected by the sensor:

The temperature first increased due to the heat put out by the sensor unit itself (this is a server temp sensor, which has its network server for easy access among other features). We can see that the temperature peaked around 4 hours after the experiment started, which is to be expected, around that time (9pm) the temperature in the lab starts to decrease dramatically. The sensor reached a fairly stable equilibrium around hour 10 which would translate to around 3am, which is again to be expected considering our environment temperature measurements. I used the stable region between hours 10 and 13 for noise estimates:

We can see here that the sensor kept "jumping" between two values: 30.9592 Celsius and 30.8967 Celsius. The difference between these readings is 0.0625 Celsius, and it can be seen that there are no intermediary values between these 2 values. I also performed a spectrum analysis just to see what happens:

The dip at around 0.9 Hz is also visbile in the environment temperature spectrum. |
17649
|
Thu Jun 22 14:21:17 2023 |
Andrei | Update | PEM | Lab temperature psd |
I connected
Quote: |
[andrei, advait]
I have analyzed the temperature data that we have collected for the past 10 days or so from the X-end temperature sensor that is accessible via Acromag.

The average temperature was 20.74 Celsius, noticeably cooler than the average 24 Celsius in the control room. The day-night temperature variations are clearly visible.

And here is the power spectrum density of these variations:

The red line indicates the frequency of the day-night cycle (1/24hrs), while the green line indicates twice the frequency of the day-night cycle. We can see that the two lines align fairly well with the peaks, which is to be expected. Here I used n_avg=3 in Paco's spec_dens() function, but I am not sure this is the right value to use. Please let me know if you have suggestions in this regard.
As for the noise estimates of the detector used to collected these data, I am not sure how to get those. The above temperature data was collected using a detector that no one knows where exactly it is in the lab, and I don't even know what type of sensor it is. Perhaps there is a way to get a noise estimate from the data that I collected? Again, please let me know.
However, we have a rough estimate for the noise of the AD590 sensor made by Kira that we calibrated and used for the step response test. We estimated this by calculating the standard deviation of the signal measured from the 0 C ice bath. This translates to 0.0134 C. We will probably repeat this measurement in a better way (once we build our own version of the sensor) because the duration of the actual 0 C measurement was just around 2 minutes.
|
|
17655
|
Fri Jun 23 10:55:08 2023 |
Andrei | Update | PEM | Lab temperature psd |
On Wednesday, Rana showed me that there are two AD590 sensors in the PSL/FSS refcav. It seems that one of the sensors is inside a box which is insulated with foam, while the other sensor is just outside the foam. It is likely that even the sensor outside the foam is not reading the environment temperature, but the difference between the two sensors gives us a good idea of the effects of the foam. Here are the plots:

As you can see, RCTEMP seems to have higher variations than RMTEMP. There is also an offset, probably due to the heat disippated by the hardware inside the box. In the freuquency domain:

where we can clearly see that there is a big difference in intensity at frequencies higher than 0.01 Hz. Moreover, RMTEMP (which is indside the box) has the lower intensity, thus showing that the foam is a low-pass filter. The same story can be seen in the coherence plot:

I have since wanted to hopefully use RCTEMP's readings to make a frequency spectrum like the one I made before using the server temperature sensor. However, I am still struggling to download the data from the channel for periods larger than a few hours. I would need data for at least 5 days in order to capture the very low end like 1/24hr.
Quote: |
[andrei, advait]
I have analyzed the temperature data that we have collected for the past 10 days or so from the X-end temperature sensor that is accessible via Acromag.

The average temperature was 20.74 Celsius, noticeably cooler than the average 24 Celsius in the control room. The day-night temperature variations are clearly visible.

And here is the power spectrum density of these variations:

The red line indicates the frequency of the day-night cycle (1/24hrs), while the green line indicates twice the frequency of the day-night cycle. We can see that the two lines align fairly well with the peaks, which is to be expected. Here I used n_avg=3 in Paco's spec_dens() function, but I am not sure this is the right value to use. Please let me know if you have suggestions in this regard.
As for the noise estimates of the detector used to collected these data, I am not sure how to get those. The above temperature data was collected using a detector that no one knows where exactly it is in the lab, and I don't even know what type of sensor it is. Perhaps there is a way to get a noise estimate from the data that I collected? Again, please let me know.
However, we have a rough estimate for the noise of the AD590 sensor made by Kira that we calibrated and used for the step response test. We estimated this by calculating the standard deviation of the signal measured from the 0 C ice bath. This translates to 0.0134 C. We will probably repeat this measurement in a better way (once we build our own version of the sensor) because the duration of the actual 0 C measurement was just around 2 minutes.
|
|
16190
|
Mon Jun 7 15:37:01 2021 |
Anchal, Paco, Yehonathan | Summary | Cameras | Mon 7 in Control Room Died |
We found Mon7 in control room dead today afternoon. It's front power on green light is not lighting up. All other monitors are working as normal.
This monitor was used for looking at IMC camera analog feed. It is one of the most important monitors for us, so we should replace it with a different monitor.
Yehonathan and Paco disconnected the monitor and brought it down. We put it under the back table if anyone wants to fix it. Paco has ordered a BNC to VGA/HDMI converter to put in any normal monitor up there. It will happen this Wednesday. Meanwhile, I have changed the MON4 assignment from POP to Quad2 to be used for IMC. |
16112
|
Mon May 3 17:28:58 2021 |
Anchal, Paco, Rana | Update | LSC | IMC WFS noise contribution in arm cavity length noise |
Rana came and helped us figure us where to inject the noise. Following are the characteristics of the test we did:
- Inject normal noise at C1:IOO-MC1_PIT_EXC using AWGGUI.
- Excitation amplitude of 54321 in band 12-37Hz with Cheby1 8th order bandpass filter with same limits.
- Look at power spectrum of C1:IOO-MC_F_DQ, C1:IOO-WFS1-PIT_OUT_DQ and the C1:IOO-MC1_PIT_EXC itself.
- Increased the gain of the noise excitation until we see some effect in MC_F.
- Diaggui also showed coherence plot in the bottom, which let's us have an estimate of how much we need to go further.
Attachment 1 shows a screenshot with awggui and diaggui screens displaying the signal in both angular and longitudinal channels.
Attachment 2 shows the analogous screenshot for MC2.
|
Attachment 1: excitationoftheMCanglessothatwecanseesomethingdotpng.png
|
|
Attachment 2: excitationoftheMCanglessothatwecanseesomethingdotpngbutthistimeitsMC2.png
|
|
16228
|
Tue Jun 29 17:42:06 2021 |
Anchal, Paco, Gautam | Summary | LSC | MICH locking tutorial with Gautam |
Today we went through LSC locking mechanics with Gautam and as a "Hello World" example, worked on locking michelson cavity.
MICH settings changed:
- Gautam at some point added 9 dB attenuation filters in MICH filter module in LSC to match the 9 dB pre-amplifier before digitization.
- This required changing teh trigger thresholds, C1:LSC-MICH_TRIG_THRESH_ON and C1:LSC-MICH_TRIG_THRESH_OFF.
- We looked at C1:LSC-AS55_Q_ERR_DQ and C1:LSC-ASDC_OUT_DQ on ndscope.
- The zero crossings in AS55_Q correspond to ASDC going to zero. We found the threshold values of ASDC by finding the linear region in zero crossing of AS55_Q.
- We changed the thresold values to UP: -0.3mW and DOWN -0.05mW. The thresholds were also changed in C1LSC_FM_TRIG.
- We also set FM2,3,6 and 8 to be triggered on threshold.
We characterized the loop OLTF, found the UGF to be 90 Hz and measured the noise at error and control points.
gautam: one aim of this work was to demonstrate that the "Lock Michelson (dark)" script call from the IFOconfigure screen worked - it did, reliably, after the setting changes mentioned above. |
16237
|
Fri Jul 2 12:42:56 2021 |
Anchal, Paco, Gautam | Summary | LSC | snap file changed for MICH |
We corrected the MICH locking snap file C1configure_MI.req and saved an updated C1configure_MI.snap. Now the 'Restore MICH' script in IFO_CONFIGURE>!MICH>Restore MICH works. The corrections included adding the correct rows of PD_DOF matrices to be at the right settings (use AS55 as error signal). The MICH_A_GAIN and MICH_B_GAIN needed to be saved as well.
We also were able to get to PRMI SB resonance. PRM was misalgined earlier from optimal position and after some manual aligning, we were able to get it to lock just by hitting IFO_CONFIGURE>!PRMI>Restore PRMI SB (3f). |
16239
|
Tue Jul 6 16:35:04 2021 |
Anchal, Paco, Gautam | Update | IOO | Restored MC |
We found that megatron is unable to properly run scripts/MC/WFS/mcwfsoff and scripts/MC/WFS/mcwfson scripts. It fails cdsutils commands due to a library conflict. This meant that WFS loops were not turned off when IMC would get unlocked and they would keep integrating noise into offsets. The mcwfsoff script is also supposed to clear up WFS loop offsets, but that wasn't happening either. The mcwfson script was also not bringing back WFS loops on.
Gautam fixed these scripts temprorarily for running on megatron by using ezcawrite and ezcaswitch commands instead of cdsutils commands. Now these scripts are running normally. This could be the reason for wildly fluctuating WFS offsets that we have seen in teh past few months.
gautam: the problem here is that megatron is running Ubuntu18 - I'm not sure if there is any dedicated CDS group packaging for Ubuntu, and so we're using some shared install of the cdsutils (hosted on the shared chiara NFS drive), which is complaining about missing linked lib files. Depending on people's mood, it may be worth biting the bullet and make Megatron run Debian10, for which the CDS group maintains packages.
Quote: |
MC was unlocked and struggling to recover this morning due to misguided WFS offsets. In order to recover from this kind of issue, we
- Cleared the bogus WFS offsets
- Used the MC alignment sliders to change MC1 YAW from -0.9860 to -0.8750 until we saw the lowest order mode transmission on the video monitor.
- With MC Trans sum at around ~ 500 counts, we lowered the C1:IOO-WFS_TRIGGER_THRESH_ON from 5000 to 500, and the C1:IOO-WFS_TRIGGER_MON from 3.0 to 0.0 seconds and let the WFS integrators work out some nonzero angular control offsets.
- Then, the MC Trans sum increased to about 2000 counts but started oscillating slowly, so we restored the delayed loop trigger from 0.0 to 3.0 seconds and saw the MC Trans sum reach its nominal value of ~ 14000 counts over a few minutes.
The MC is now restored and the plan is to let it run for a few hours so the offsets converge; then run the WFS relief script.
|
|
16241
|
Thu Jul 8 11:20:38 2021 |
Anchal, Paco, Gautam | Summary | LSC | PRFPMI locking attempts |
Last night Gautam walked us through the algorithm used to lock PRFPMI. We tried it several times with the PSL HEPA filter off between 10:00 pm July 7th to 1:00 am July 8th. None of our attempts were successful. In between, we tried to do the locking with old IMC settings as well, but it did not change the result for us. In most attempts, the arms would start to resonate with PRMI with about 200 times the power than without power recycling while the arms are still controlled by ALS beatnote. The handover of lock controls "CARM+DARM locked to ALS beatnote" to "Main laser + IMC locked to the CARM+DARM" would always fail. More specifically, we were seeing that as soon as we hand over the DC control of CARM from ALS beatnote to IR by feeding back to MC2, the lock would inevitably fail before the rest of the high-frequency control can be transferred over.
Nonetheless, Paco and I got a good demo of how to do PRFPMI locking if the need appears. With more practice and attempts, we should be able to achieve the lock at some point in the future. The issues in handover could be due to any of the following:
- Although it seems like ALS beatnote fed control of arms keep them within the CARM IR linewidth as we see the IR resonating, there still could be some excess noise that needs to be dealt with.
- Gautam conjectures, that the presence of high power in the arms connects the ITMs and the ETMs with an optical spring changing the transfer function of the pendula. This in turn changes the phase margin and possibly makes the CARM loop in IR PRFPMI unstable.
- We should also investigate the loop transfer functions near the handover point for the ALS beatnote loop and the IR CARM loop and calculate the crossover frequency and gain/phase margins there.
More insights or suggestions are welcome.
Note; An earthquake came around lunch time and tripped all watchdogs. Most suspensions were recovered without issues, but ITMX appeared to be stuck. We tried the shaking procedure, but after this we couldn't restore the XARM lock. From alignment, we tried optimizing the TRX but we only got up to ~0.5 and ASS wouldn't work as usual. In the end the issue was that we had forgotten to enable the LL coil output so after we did this, we managed to recover the XARM. |
15851
|
Mon Mar 1 11:40:15 2021 |
Anchal, Paco | Summary | IMC | getting familiar with IMC controls |
[Paco, Anchal]
tl;dr: Done no harm, no lasting change.
Learn burtgooey
- Use /cvs/cds/caltech/target/c1psl/autoBurt.req as input to test snapshot "/users/anchal/BURTsnaps/controls_1210301_101310_0.snap" on rossa after not succeeding in donatella
- Browse /opt/rtcds/caltech/c1/burt/autoburt/snapshots/TODAY just to know where the snapshots are living. Will store our morning work specific snapshots in local user directories (e.g. /users/anchal/BURTsnaps)
Identifying video monitors
- Switched channels around on video controls; changed C1:VID-MON7 to 16, back to 30, then C1:VID-QUAD2_4 to 16, to 18, then 20, back to 16, to 14 (which identified as PMCT), to 1 (IMC). Anyways, looks like IMC is locked.
[Yehonathan, Paco, Anchal]
Unlocking MC
- From IOO/LockMC, MC_Servo, FSS --> closed PSL shutter, reopen it and see the lock recovers almost instantly. Try MCRFL shutter, no effect. Toggled PSL shutter one more time, lock recovered.
- From IOO/LockMC, MC_Servo, toggle OPTION (after IP2A), lose and recover lock in similar fashion. MCRFL gets most of the light.
- Looked at IFO_OVERVIEW just to get familiar with the various signals.
|
15982
|
Wed Mar 31 22:58:32 2021 |
Anchal, Paco | Update | SUS | MC2 Coil Balancing Test |
A cross-coupling test has been set to trigger at 05:00 am on April 1st, 2021. The script is waiting on tmux session 'cB' on pianosa. /scripts/SUS/OutMatCalc/MC2crossCoupleTest.py is being used here. The script will switch on oscillator in LOCKIN1 of MC2 at 13 Hz and 200 counts and would send it along the POS, PIT and YAW vectors on output matrix one by one, each for 2 minutes. It will take data from C1:IOO-MC_F_DQ, C1:IOO-MC_TRANS_PIT_ERR and C1:IOO-MC_TRANS_YAW_ERR and use it to measure 'sensing matrix' S. Sensing matrix S is defined as the cross-coupling between excited and sensed DOF and we ideally want it to be an identity matrix. The code will use the measured S to create a guess matrix A which on being multiplied by ideal coil output matrix would give us a rotated coil output matrix O. This guess O will be applied and the measurement will be repeated. On each iteration, next, A matrix is defined by:

This recursive algorithm converges A to the inverse of initial S. The above relation is derived by noticing that in steady state . I've taken this idea from a mathematics paper I found on some more complex stuff (c.f. https://doi.org/10.31219/osf.io/yrvck).
At each iteration, all three matrices A, O and S will be stored in a text file for analysis later.
The code has the error-catching capability and would restore the optic to the status quo if an error occurs or watchdogs trip due to earthquakes. |
15984
|
Thu Apr 1 13:56:49 2021 |
Anchal, Paco | Update | SUS | MC2 Coil Balancing Test Results |
The coil balancing attempt failed. The off-diagonal values in the measured sensing matrices either remained the same or increased.
The attempt in the morning was too slow. By the time we reached, it had reached to iteration 7 only and still nowhere near optimum sensing matrix had reached. We still needed to see if the optimum would eventually reach if more iterations happened.
<Radhika came for shadowing us and learning about 40m>
So we worked a bit on speeding up the data loading process and then ran the code again which now was running much faster. Still within 1 hr or so, we saw it had reached to iteration 7 with no sign of sensing matrix getting any better.
<Paco left for vaccination>
To determine if the method would work in principle, I decided to stop the current run and start with a 0.5 Hz bandwidth run (so about 7 averages with 8s duration data and welch method). This completed 20 iterations before Gautum came. But it was clear now that the method is not converging to a better solution. Need to find a bug in the implementation of the algorithm mentioned in last post or find a better algoritm.
Attachment 1 is the plot of how the sensing matrix's distance from the identity matrix increased over iterations in the last run.
Attachment 2 is the plot for different off-diagonal terms in the sensing matrix. It is clear that POS->PIT,YAW coupling is not being measured properly as it remains constant.
Attachment 3 Gautum told us that there is some naming error in nds and MC_TRANS_PIT/YAW can be read through C1:IOO-MC_TRANS_PIT_ERR and C1:IOO-MC_TRANS_YAW_ERR channels instead. To test if they indeed point to same values, we did a test of exciting YAW degree through LOCKIN1 and seeing if the peaks are visible in the channels. This was also done to give Radhika an opportunity to do something I could confidently mentor about. and to experience using diaggui. |
Attachment 1: SDistanceFromIdentity.pdf
|
|
Attachment 2: SmatIterations.pdf
|
|
Attachment 3: TestingExcitationAlongYAW.pdf
|
|
15985
|
Thu Apr 1 18:01:06 2021 |
Anchal, Paco | Update | SUS | MC2 Coil Balancing Test Results Success?? |
After fixing a few things we felt were wrong in our implementation of the algorithm, we ran the coil balancing for 12 iterations with just 11s per excitation and still taking CSD with 0.1 Hz bandwidth. This time we saw the distance of sensing matrix from identity going down.
Performance Analysis
- Attachment 1 shows the trend of distance of Sensing matrix from identity matrix over iterations.
- Attachment 2 shows the trend of off-diagonal terms in sensing matrix over iterations.
- Attachment 3 shows the ASD for the different sensed DOF when excited in different DOFs with the new output matrix. This is the better truth of what happened by the end. The true sensing matrix is proportional to the peak heights in this plot. Rows are different sensed DOFs (POS, PIT, YAW) and columns are excited DOFs (POS, PIT, YAW). The black dotted curves are ASD when no excitation was present.
Next step
- We want to run it for longer, more iterations and more duration to get better averaging. Hopefully, this will do a better job. We'll try running this new code tomorrow at 5:00am.
- We'll work on using uncertainties of measured data.
- Use awg to excite all DOF together at different frequencies and make the code faster.
|
Attachment 1: SDistanceFromIdentity.pdf
|
|
Attachment 2: SmatIterations.pdf
|
|
Attachment 3: MC2CoilCrossCoupling_opt.png
|
|
15995
|
Mon Apr 5 08:25:59 2021 |
Anchal, Paco | Update | General | Restore MC from early quakes |
[Paco, Anchal]
Came in a little bit after 8 and found the MC unlocked and struggling to lock for the past 3 hours. Looking at the SUS overview, both MC1 and ITMX Watchdogs had tripped so we damped the suspensions and brought them back to a good state. The autolocker was still not able to catch lock, so we cleared the WFS filter history to remove large angular offsets in MC1 and after this the MC caught its lock again.
Looks like two EQs came in at around 4:45 AM (Pacific) suggested by a couple of spikes in the seismic rainbow, and this. |
16001
|
Tue Apr 6 18:46:36 2021 |
Anchal, Paco | Update | SUS | Updates on recent efforts |
As mentioned in last post, we earlier made an error in making sure that all time series arrays go in with same sampling rate in CSD calculation. When we fixed that, our recursive method just blew out in all the efforts since then.
We suspect a major issue is how our measured sensing matrix (the cross-coupling matrix between different degrees of freedom on excitation) has significant imaginary parts in it. We discard the imaginary vaues and only use real parts for iterative method, but we think this is not the solution.
Here we present cross-spectral density of different channels representing the three sensed DOFs (normalized by ASD of no excitation data for each involved component) and the sensing matrix (TF estimate) calculated by normalizing the first cross spectral density plots column wise by the diagonal values. These are measured with existing ideal output matrix but with the new input matrix. This is to get an idea of how these elements look when we use them.
Note, that we used only 10 seconds of data in this run and used binwidth of 0.25Hz. When we used binwidth of 0.1 Hz, we found that the peaks were broad and highest at 13.1 Hz instead of 13 Hz which is the excitation frequency used in these measurements.
How should we proceed?
- We feel that we should figure out a way to use the imaginary value of the sensing matrix, either directly or as weights representing noise in that particular data point.
- Should we increase the excitation amplitude? We are currently using 500 counts of excitation on coil output.
- Are there any other iterative methods for finding the inverse of the matrix that we should be aware of? Our current method is rudimentary and converges linearly.
- Should we use the absolute value of the sensing matrix instead? In our experience, that is equivalent to simply taking ratios of the PSD of each channel and does not work as well as the TF estimate method.
|
Attachment 1: FirstMeasurementPlots.pdf
|
|
16007
|
Thu Apr 8 17:04:43 2021 |
Anchal, Paco | Update | SUS | First Successful Coil Balancing |
Today, we finally crossed the last hurdle and got a successful converging coil balancing run. 
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
|
|
Attachment 2: SmatIterations.pdf
|
|
Attachment 3: SmatrixPlots.pdf
|
|
16009
|
Fri Apr 9 13:13:00 2021 |
Anchal, Paco | Update | SUS | Faster coil balancing |
We ran again this method but with the 'b' parameter as a matrix instead. This provides more gain on some off-diagonal terms than others. This gave us a better convergence with the code reaching to the tolerance level provided (0.01 distance of S matrix from identity) within 16 iterations (~17 mins).
Attachment 1 again shows how the off-diagonal terms go down and how the overall distance of sensing matrix from identity goes down. This is 'Cross coupling budget' of the coils as iterations move forward.
Jumping to near zero-crossing:
- Rana mentioned a ezlockin code which first makes 5 step changes in output matrix without using feedback and calculates the changes required to reach zero-crossing in the behavior of the off-diagonal terms during these steps.
- This is similar to what we did above by hand where we increased the value of b for slowly converging off-diagonal elements.
- We plan to implement this 'jump' to near zero-crossing method next. Aim is to get a coil balancing code that does the job in ~5 min.
- We have been throwing away imaginary part of sensing matrix so far. We wanted to get to some owrking solution before we try more complex stuff. We have to figure out global phases in each transfer function estimate to rotate the measured transfer function appropriately.
|
Attachment 1: SmatIterations.pdf
|
|
Attachment 2: MC2AllOutmat.txt
|
1.027604652272846142e+00 1.193175249772460367e+00 1.091939557371080394e+00
1.010054273887021292e+00 1.156057452309880551e+00 -8.392112351146234772e-01
9.895057930131009316e-01 -7.685799469766890768e-01 6.200896409311776880e-01
9.719554146272761930e-01 -8.056977444392685594e-01 -1.311061151554526294e+00
|