ID |
Date |
Author |
Type |
Category |
Subject |
2369
|
Wed Dec 9 00:23:28 2009 |
Koji | Update | SUS | free swinging spectra of ETMY and ITMX |
Where is the plot for the trend?
It can be either something very important or just a daydream of you.
We can't say anything before we see the data.
We like to see it if you think this is interesting.
... Just a naive guess: Is it just because the seismic level got quiet in the night?
P.S.
You looks consistently confused some words like damping, Q, and peak height.
- Q is defined by the transfer function of the system (= pendulum).
- Damping (either active or passive) makes the Q lower.
- The peak height of the resonance in the spectrum dy is determined by the disturbance dx and the transfer function H (=y/x).
dy = H dx
As the damping makes the Q lower, the peak height also gets lowered by the damping.
But if the disturbance gets smaller, the peak height can become small even without any change of the damping and the Q.
Quote: |
By the way I found a trend, which can be seen in all of the data taken today and yesterday.
The resonances of pitch and yaw around 0.5Hz look like being damped, because their height from the floor become lower than the past.
I don't know what goes on, but it is interesting because you can see the trend in all of the data.
|
|
2370
|
Wed Dec 9 09:07:32 2009 |
steve | Update | PEM | high seismic activity |
The construction activity is shaking the tables in the control room. The compactor- large remote controlled jackhammer is in the bottom of the 16-17 ft deep hole 15 ft east of ITMY in CES bay. The suspensions are holding OK. PRM, MC1 and MC3 are effected mostly. |
Attachment 1: seis24d.png
|
|
Attachment 2: seis4h.png
|
|
Attachment 3: P1050833.JPG
|
|
Attachment 4: P1050836.JPG
|
|
2371
|
Wed Dec 9 10:53:41 2009 |
josephb | Update | Cameras | Camera client wasn't able to talk to server on port 5010, reboot fixed it. |
I finally got around to taking a look at the digital camera setup today. Rob had complained the client had stopped working on Rosalba.
After looking at the code start up and not complain, yet not produce any window output, it looks like it was a network problem. I tried rebooting Rosalba, but that didn't fix anything.
Using netstat -an, I looked for the port 5010 on both rosalba and ottavia, since that is the port that was being used by the camera. Ottavia was saying there were 6 established connections after Rosalba had rebooted (rosalba is 131.215.113.103). I can only presume 6 instances of the camera code had somehow shutdown in such a way they had not closed the connection.
[root@ottavia controls]#netstat -an | grep 5010
tcp 0 0 0.0.0.0:5010 0.0.0.0:* LISTEN
tcp 0 0 131.215.113.97:5010 131.215.113.103:57366 ESTABLISHED
tcp 0 0 131.215.113.97:5010 131.215.113.103:58417 ESTABLISHED
tcp 1 0 131.215.113.97:46459 131.215.113.97:5010 CLOSE_WAIT
tcp 0 0 131.215.113.97:5010 131.215.113.103:57211 ESTABLISHED
tcp 0 0 131.215.113.97:5010 131.215.113.103:57300 ESTABLISHED
tcp 0 0 131.215.113.97:5010 131.215.113.103:57299 ESTABLISHED
tcp 0 0 131.215.113.97:5010 131.215.113.103:57315 ESTABLISHED
I switched the code to use port 5022 which worked fine. However, I'm not sure what would have caused the original connection closure failures, as I test several close methods (including the kill command on the server end used by the medm screen), and none seemed to generate this broken connection state. I rebooted Ottavia, and this seemed to fix the connections, and allowed port 5010 to work. I also tried creating 10 connections, which all seem to run fine simultaneously. So its not someone overloading that port with too many connections which caused the problem. Its like the the port stopped working somehow, which froze the connection status, but how or why I don't know at this point. |
2372
|
Wed Dec 9 17:51:03 2009 |
kiwamu | Update | SUS | watchdogs |
Please do not touch the watchdogs for all SUSs except for MCs,
because I am going to measure the free swinging spectra for ITMs, ETMs, BS, PRM, SRM tonight.
Today, it is good chance to summarize those data under atmospheric pressure.
thank you.
|
2373
|
Wed Dec 9 18:01:06 2009 |
Koji | Update | COC | Wiping finished |
[Kiwamu, Jenne, Alberto, Steve, Bob, Koji]
We finished wiping of four test masses without any trouble. ITMY looked little bit dusty, but not as much as ITMX did.
We confirmed the surface of the ITMX again as we worked at vertex a lot today. It still looked clean.
We closed the light doors. The suspensions are left free tonight in order to check their behavior.
Tomorrow morning from 9AM, we will replace the door to the heavy ones. |
2374
|
Wed Dec 9 21:09:28 2009 |
kiwamu | Update | SUS | Re: free swinging spectra of ETMY and ITMX |
Okay, now the data are attached. At that time I just wanted to say like the follower.
- - -
In the free-swinging spectra around ~0.5Hz, you can see the two resonances, which come from pitch and yaw mode of the pendulum.
Note that, the vertical and the horizontal axis are adjusted to be the same for the two plots in the figure .
And I found that
* the floor levels are almost the same (the factor of about 1.5 or something like that) compared to the past.
* however the peak heights for two resonances are several 10 times smaller than the past.
* this tendency are shown in all of the data (ITMX, ETMX, ETMY).
If such variation of the peak heights is cased by the seismic activity, it means the seismic level change by several 10 times. It sounds large to me.
Quote: |
Where is the plot for the trend?
It can be either something very important or just a daydream of you.
We can't say anything before we see the data.
Quote: |
By the way I found a trend, which can be seen in all of the data taken today and yesterday.
The resonances of pitch and yaw around 0.5Hz look like being damped, because their height from the floor become lower than the past.
I don't know what goes on, but it is interesting because you can see the trend in all of the data.
|
|
|
Attachment 1: Pitch-Yaw_modes.png
|
|
2375
|
Thu Dec 10 00:46:15 2009 |
Koji | Update | SUS | Re: free swinging spectra of ETMY and ITMX |
Well, I get the point now. It could be either seismic or change in the suspension Q.
The pendulum memorizes its own state for a period of ~ Q T_pend. (T_pend is the period of the pendulum)
If the pendulum Q is very high (>104), once the pendulum is excited, the effect of the excitation can last many hours.
On the other hand, in our current case, we turned on the damping once, and then turned off the damping.
Again it takes ~Q T_pend to be excited.
In those cases, the peak height is not yet before in equilibrium, and can be higher or lower than expected.
So, my suggestion is:
Track the peak height along the long time scale (~10hrs) and compare between the previous one and the current one.
This may indicate whether it is equilibrium or not, and where the equilibrium is.
Quote: |
If such variation of the peak heights is cased by the seismic activity, it means the seismic level change by several 10 times. It sounds large to me.
|
|
2376
|
Thu Dec 10 08:40:12 2009 |
Alberto | Update | Computers | Fronte-ends down |
I found all the front-ends, except for C1SUSVME1 and C0DCU1 down this morning. DAQAWG shows up green on the C0DAQ_DETAIL screen but it is on a "bad" satus.
I'll go for a big boot fest. |
2378
|
Thu Dec 10 08:50:33 2009 |
Alberto | Update | Computers | Fronte-ends down |
Quote: |
I found all the front-ends, except for C1SUSVME1 and C0DCU1 down this morning. DAQAWG shows up green on the C0DAQ_DETAIL screen but it is on a "bad" satus.
I'll go for a big boot fest.
|
Since I wanted to single out the faulting system when these situations occur, I tried to reboot the computers one by one.
1) I reset the RFM Network by pushing the reset button on the bypass switch on the 1Y7 rack. Then I tried to bring C1SOSVME up by power-cycling and restarting it as in the procedure in the wiki. I repeated a second time but it didn't work. At some point of the restarting process I get the error message "No response from EPICS".
2) I also tried rebooting only C1DCUEPICS but it didn't work: I kept having the same response when restarting C1SOSVME
3) I tried to reboot C0DAQCTRL and C1DCU1 by power cycling their crate; power-cycled and restarted C1SOSVME. Nada. Same response from C1SOSVME.
4) I restarted the framebuilder; power-cycled and restarted C1SOSVME. Nothing. Same response from C1SOSVME.
5) I restarted the framebuilder, then rebooted C0DAQCTRL and C1DCU, then power-cycled and restarted C1SOSVME. Niente. Same response from C1SOSVME.
Then I did the so called "Nuclear Option", the only solution that so far has proven to work in these circumstances. I executed the steps in the order they are listed, waiting for each step to be completed before passing to the next one.
0) Switch off: the frame builder, the C0DAQCTRL and C1DCU crate, C1DCUEPICS
1) turn on the frame builder
2) reset of the RFM Network switch on 1Y7 (although, it's not sure whether this step is really necessary; but it's costless)
3) turn on C1DCUEPICS
4) turn on the C0DAQCTRL and C1DCU crate
5) power-cycle and restart the single front-ends
6) burt-restore all the snapshots
When I tried to restart C1SOSVME by power-cycling it I still got the same response: "No response from EPICS". But I then reset C1SUSVME1 and C1SUSVME2 I was able to restart C1SOSVME.
It turned out that while I was checking the efficacy of the steps of the Grand Reboot to single out the crucial one, I was getting fooled by C1SOSVME's status. C1SOSVME was stuck, hanging on C1SUSVME1 and C1SUSVME2.
So the Nuclear option is still unproven as the only working procedure. It might be not necessary.
Maybe restating BOTH RFM switches, the one in 1Y7 and the one in 1Y6, would be sufficient. Or maybe just power-cycling the C0DAQCTRL and C1DCU1 is sufficient. This has to be confirmed next time we incur on the same problem. |
2379
|
Thu Dec 10 09:51:06 2009 |
rob | Update | PSL | RCPID settings not saved |
Koji, Jenne, Rob
We found that the RCPID servo "setpoint" was not in the relevant saverestore.req file, and so when c1psl got rebooted earlier this week, this setting was left at zero. Thus, the RC got a bit chilly over the last few days. This channel has been added.
Also, RCPID channels have been added (manually) to conlog_channels. |
2381
|
Thu Dec 10 09:56:32 2009 |
Koji | Update | PSL | RCPID settings not saved |
Note: The set point C1:PSL-FSS_RCPID_SETPOINT is 37.0 on C1PSL_FSS_RCPID.adl.
Now the temp is recovering with its full speed. At some point we have to restore the value of the FSS SLOW DC as the temp change drag it up.
Quote: |
Koji, Jenne, Rob
We found that the RCPID servo "setpoint" was not in the relevant saverestore.req file, and so when c1psl got rebooted earlier this week, this setting was left at zero. Thus, the RC got a bit chilly over the last few days. This channel has been added.
Also, RCPID channels have been added (manually) to conlog_channels.
|
|
Attachment 1: RC_TEMP.png
|
|
2382
|
Thu Dec 10 10:01:16 2009 |
Jenne | Update | Computers | Fronte-ends down |
All the front ends are back up.
Quote: |
Quote: |
I found all the front-ends, except for C1SUSVME1 and C0DCU1 down this morning. DAQAWG shows up green on the C0DAQ_DETAIL screen but it is on a "bad" satus.
I'll go for a big boot fest.
|
Since I wanted to understand once for all what's the faulting system when these situations occur, I tried to reboot the computers one by one.
1) I reset the RFM Network by pushing the reset button on the bypass switch on the 1Y7 rack. Then I tried to bring C1SOSVME up by power-cycling and restarting it as in the procedure in the wiki. I repeated a second time but it didn't work. At some point of the restarting process I get the error message "No response from EPICS".
2) I also tried rebooting only C1DCUEPICS but it didn't work: I kept having the same response when restarting C1SOSVME
3) I tried to reboot C0DAQCTRL and C1DCU1 by power cycling their crate; power-cycled and restarted C1SOSVME. Nada. Same response from C1SOSVME.
4) I restarted the framebuilder; power-cycled and restarted C1SOSVME. Nothing. Same response from C1SOSVME.
5) I restarted the framebuilder, then rebooted C0DAQCTRL and C1DCU, then power-cycled and restarted C1SOSVME. Niente. Same response from C1SOSVME.
The following is the so called "Nuclear Option", the only solution that so far has proven to work in these circumstances. Execute the following steps in the order they are listed, waiting for each step to be completed before passing to the next one.
0) Switch off: the frame builder, the C0DAQCTRL and C1DCU crate, C1DCUEPICS
1) turn on the frame builder
2) reset of the RFM Network switch on 1Y7 (although, it's not sure whether this step is really necessary; but it's costless)
3) turn on C1DCUEPICS
4) turn on the C0DAQCTRL and C1DCU crate
One other possibility remains to be explored to avoid the Nuclear Option. And that is to just try to reset both RFM Network switches: the one in 1Y7 and the one in 1Y6.
|
|
2383
|
Thu Dec 10 10:31:18 2009 |
Jenne | Update | Computers | Fronte-ends down |
Quote: |
All the front ends are back up.
Quote: |
Quote: |
I found all the front-ends, except for C1SUSVME1 and C0DCU1 down this morning. DAQAWG shows up green on the C0DAQ_DETAIL screen but it is on a "bad" satus.
I'll go for a big boot fest.
|
Since I wanted to understand once for all what's the faulting system when these situations occur, I tried to reboot the computers one by one.
1) I reset the RFM Network by pushing the reset button on the bypass switch on the 1Y7 rack. Then I tried to bring C1SOSVME up by power-cycling and restarting it as in the procedure in the wiki. I repeated a second time but it didn't work. At some point of the restarting process I get the error message "No response from EPICS".
2) I also tried rebooting only C1DCUEPICS but it didn't work: I kept having the same response when restarting C1SOSVME
3) I tried to reboot C0DAQCTRL and C1DCU1 by power cycling their crate; power-cycled and restarted C1SOSVME. Nada. Same response from C1SOSVME.
4) I restarted the framebuilder; power-cycled and restarted C1SOSVME. Nothing. Same response from C1SOSVME.
5) I restarted the framebuilder, then rebooted C0DAQCTRL and C1DCU, then power-cycled and restarted C1SOSVME. Niente. Same response from C1SOSVME.
The following is the so called "Nuclear Option", the only solution that so far has proven to work in these circumstances. Execute the following steps in the order they are listed, waiting for each step to be completed before passing to the next one.
0) Switch off: the frame builder, the C0DAQCTRL and C1DCU crate, C1DCUEPICS
1) turn on the frame builder
2) reset of the RFM Network switch on 1Y7 (although, it's not sure whether this step is really necessary; but it's costless)
3) turn on C1DCUEPICS
4) turn on the C0DAQCTRL and C1DCU crate
One other possibility remains to be explored to avoid the Nuclear Option. And that is to just try to reset both RFM Network switches: the one in 1Y7 and the one in 1Y6.
|
|
I burtrestored all the snapshots to Dec 9 2009 at 18:00. |
2385
|
Thu Dec 10 13:13:08 2009 |
Jenne | Update | Computers | fb40m backup restarted |
The frame builder was power cycled during the morning bootfest. I have restarted the backup script once more. |
2386
|
Thu Dec 10 13:50:02 2009 |
Jenne | Update | VAC | All doors on, ready to pump |
[Everybody: Alberto, Kiwamu, Joe, Koji, Steve, Bob, Jenne]
The last heavy door was put on after lunch. We're now ready to pump. |
2387
|
Thu Dec 10 15:18:55 2009 |
Jenne | Update | VAC | seisBLRMS |
last 20 days - including the pounding from next door |
Attachment 1: Untitled.png
|
|
2388
|
Thu Dec 10 16:51:35 2009 |
steve | Update | VAC | pumpdown will start tomorrow morning |
The vacuum system is at 760 torr All chambers with doors on and their annuloses are pumped down.
PSL output shutter is still closed. We are fully prepared to star slow pump down tomorrow.
The plan is to reach 1 torr ~ in 6 hrs without a creating a sand storm. |
2391
|
Thu Dec 10 17:13:36 2009 |
kiwamu | Update | SUS | Free swiging spectra under the atmospheric pressure |
The free swinging spectra of ITMs, ETMs, BS, PRM and SRM were measured last night in order to make sure that nothing wrong have happened by the wiping.
I think there are nothing wrong with ITMs, ETMs, BS, PRM and SRM successfully.
For the comparison, Yoichi's figure in his elog entry of Aug.7 2008 is good, but in his figure somehow PRM spectrum doesn't look correct.
Anyway, compared with his past data, there are no significant changes in the spectra. For PRM which has no counterpart to compare with, its shape of spectra looks similar to any other spectra. So I think PRM is also OK. The measured spectra are attached below.
Indeed the current data are still showing smaller peak height for their pitch and yaw modes (roughly factor of 10 ).
|
Attachment 1: summary_freeswing.pdf
|
|
2392
|
Thu Dec 10 18:27:48 2009 |
Mott | Update | General | Updated R & T Measurements |
Attached are updated plots of the T&R Measurements for a variety of mirrors, and diagrams for the setup used to make the measurements.
T is plotted for the 1064 nm measurement, since these mirrors are highly reflective at 1064, and either R or R&T are plotted for the 532 nm measurement, depending on how larger the R signal is.
As with the previous set of plots, the error bars here are purely statistical, and there are certainly other sources of error not accounted for in these plots. In general, the T measurement was quite stable, and the additional errors
are probably not enormous, perhaps a few percent.
The mirrors are:
Y1-1037-00.50CC
Y1-2037-45S
Y1-2037-45P
Y1S-1025-0
Y1S-1025-45
|
Attachment 1: Y1S-0.png
|
|
Attachment 2: Y1S-45.png
|
|
Attachment 3: Y45P.png
|
|
Attachment 4: Y45S.png
|
|
Attachment 5: Y150CC.png
|
|
Attachment 6: Setup.png
|
|
2401
|
Fri Dec 11 17:36:37 2009 |
kiwamu | Update | General | IFO restoring plan |
Alberto, Jenne, Kiwamu
We together will lead the IFO restoring and the following is our plan.
- - - - -|- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
#.0 | measuring the free swinging spectra (weekend by kiwamu) DONE
#.1 | turn ON the PZTs for steering mirror and so on. (Dec.14 Mon.) DONE
#. 1 | lock around PSL DONE
#.2 | deal with mechanical shutter (Dec.14 Mon.)DONE
#.3 | lock MCs (Dec.14 Mon.)DONE
#.4 | align the IFO (Dec.15 Tue.)DONE
#.5 | lock full IFO (Dec.15 Tue.)DONE
- - - - -|- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Thank you. |
2405
|
Sun Dec 13 17:43:10 2009 |
kiwamu | Update | SUS | free swinging spectra (vacuum) |
The free swinging spectra of ITMs, ETMs, BS, PRM and SRM were measured under the vacuum-condition. The attachment are measured spectra.
It looks there are nothing wrong because no significant difference appear from the past data and the current data (under atmosperic pressure).
So everything is going well. |
Attachment 1: summary_FreeSwinging_vacuum.pdf
|
|
2410
|
Mon Dec 14 12:13:52 2009 |
Jenne | Update | Treasure | We are *ROCKSTARS* ! IFO is back up |
[Jenne, Kiwamu, Koji]
We got the IFO back up and running! After all of our aligning, we even managed to get both arms locked simultaneously. Basically, we are awesome.
This morning, we did the following:
* Turned on the PZT High voltages for both the steering mirrors and the OMC. (For the steering mirrors, turn on the power, then hit "close loop" on each. For the OMC, hit Output ON/OFF).
* Looked at the PZT strain gauges, to confirm that the PZTs came back to where they had been. (Look at the snapshot of C1ASC_PZT_Al)
* Locked all components of the PSL (This had already been done.)
* Removed beam dump which was blocking the PSL, and opened the PSL mechanical shutter. Light into the IFO!
* Locked the Mode Cleaner. The auto-locker handled this with no problem.
* Confirm that light is going through the Faraday. (Look at the TV sitting on top of MC13 tank...it shows the Faraday, and we're hitting the input of the Faraday pretty much dead-on).
* Look at IP_ANG and IP_POS. Adjust the steering mirrors slightly to zero the X&Y readings on IP_ANG. This did not change the PZTs by very much, so that's good.
* Align all of the Core Optics to their OpLev positions.
* On the IFO_Align screen, save these positions.
* Run the IFO_Configure scripts, in the usual order. (Xarm, Yarm, PRM, DRM). Save the appropriate optics' positions after running the alignment scripts. We ended up running each alignment script twice, because there was some residual misalignment after the first iteration, which we could see in the signal as viewed on DataViewer (Either TRX, TRY, or SPOB, for those respective DoFs).
* Restore Full IFO.
* Watch the beauty of both arms and the central cavity snapping together all by themselves! In the attached screenshot, notice that TRX and TRY are both ~0.5, and SPOB and AS166Q are high. Yay!
Conclusions:
* The wiping may have helped. While aligning X and Y separately, TRX got as high as ~1.08, and TRY got as high as 0.98 This seems to be a little bit higher than it was previously.
* Since everything locked up in pretty short order, and the free swinging spectra (as measured by Kiwamu in elog 2405) looks good, we didn't break anything while we were in the chambers last week. Excellent.
* We are now ready for a finesse measurement to tell us more quantitatively how we did with the wiping last week.
|
Attachment 1: Jenne14Dec09_IFOlocked.png
|
|
2411
|
Mon Dec 14 13:08:33 2009 |
Koji | Update | Treasure | LOCKSTARS |
Good job guys. What I did was saying "I don't know", "Maybe", and "Ants...".
Now you can proceed to measurements for the visibility and the cavity pole!
Quote:
|
[Jenne, Kiwamu, Koji]
We got the IFO back up and running! After all of our aligning, we even managed to get both arms locked simultaneously.
|
|
2412
|
Mon Dec 14 13:17:33 2009 |
rob | Update | Treasure | We are *ROCKSTARS* ! IFO is back up |
|
Attachment 1: two-thumbs-up.jpeg
|
|
2413
|
Mon Dec 14 14:16:14 2009 |
Alberto | Update | Treasure | LOCKSTARS |
Quote: |
Good job guys. What I did was saying "I don't know", "Maybe", and "Ants...".
Now you can proceed to measurements for the visibility and the cavity pole!
Quote:
|
[Jenne, Kiwamu, Koji]
We got the IFO back up and running! After all of our aligning, we even managed to get both arms locked simultaneously.
|
|
I'm going to do it right now. |
2414
|
Mon Dec 14 15:18:18 2009 |
Jenne | Update | lore | armLoss script ran....results confidential |
I ran the armLoss script for both Xarm and Yarm. The results are confidential, pending the completion of Alberto's cavity pole/finesse measurement due to the 'bet' as to what the new losses are after the drag wiping.
If you're the kind of person who likes to look at their Chrismas presents, the log files with the results are in the usual place for this script: /scripts/LSC/loss-ARM-GPStime.log (loss-Y-944865071.log and loss-X-944865946.log) |
2415
|
Mon Dec 14 19:33:04 2009 |
Alberto | Update | General | Arm Cavity Poles measured again after cleaning the optics last week |
Last week we vented and we cleaned the main optics of the arm cavities.
I measured the frequency of the cavity poles for both the arm cavities to see how they changed (see previous elog entry 2226). These the results:
fp_X = 1616 +/- 14 Hz
fp_Y = 1590 +/- 4 Hz
The error is the statistical error that I got with the Matlab NonLinearLeastSquare fitting function.
I calculated the cavity pole frequencies by measuring the transfer function between a photodiode located at the end of the arms (either X or Y) and another photodiode placed after the mode cleaner. Both diodes where Thorlabs PDA255.
(Last time, I had measured that the pair of diode had a flat calibration).
With the SR785 I measured the transfer function by exciting the OMC_ISS_EXC input cable.
For both arms I set to 1V the excitation amplitude. I repeated the measurements for different excitation amplitudes without observing any changes.
I then fitted the data with the NonLinearLeastSquare function of matlab. The script I wrote to do that is attached to this entry in a compressed file.
The files also contains the PDF with the output plots and the data from both set of measurements performed before and after the cleaning.
The data is commented in a file called measurements.log.
In the end I disabled again the test switch on the ISS MEDM screen.
I disconnected the excitation cable from the OMC_ISS_EXC input cable.
I removed the photodiode that measured the Mode Cleaner transmission from the PSL clearing the way for the beam to get back to its path to the RFAM photodiode. |
Attachment 1: XarmTF01_fit.pdf
|
|
Attachment 2: YarmTF01_fit.pdf
|
|
Attachment 3: ArmCavityFinesseMeasurment.tar.gz
|
2416
|
Mon Dec 14 22:32:56 2009 |
Koji | Update | General | Arm cavity loss ~ result |
I like to ask someone to review the calculation on the wiki.
In the calculation, the round trip loss and the front mirror T are the unknown variables.
The end mirror T of 10ppm was assumed. (End mirror T)+(Round trip loss) is almost invariant, and T_end does not change the other results much.
Arm cavity loss measurement (Dec. 14, 2009)
X Arm:
- Arm visibility (given): 0.897 +/- 0.005 (20 pts) (2.5%UP!!)
- Cut off freq (given): 1616 +/- 14 [Hz] (2.1%UP!!)
- Finesse (derived): 1206 +/- 10 (2.1%UP!!)
- Round Trip loss (estimated): 127 +/- 6 [ppm] (28%DOWN!!)
- Front Mirror T (estimated): 0.00506 +/- 0.00004
Y Arm:
- Arm visibility (given): 0.893 +/- 0.004 (20 pts) (2.1%UP!!)
- Cut off freq (given): 1590 +/- 4 [Hz] (8.2%UP!!)
- Finesse (derived): 1220 +/- 3 (8.2%UP!!)
- Round Trip loss (estimated): 131 +/- 6 [ppm] (37%DOWN!!)
- Front Mirror T (estimated): 0.00500 +/- 0.00001
Previous measurement (Oct 07, 2009 & Nov 10, 2009)
X Arm:
- Arm visibility (given): 0.875 +/- 0.005 (34 pts)
- Cut off freq (given): 1650 +/- 70 [Hz]
- Finesse (derived): 1181 +/- 50
- Round Trip loss (estimated): 162 +/- 10 [ppm]
- Front Mirror T (estimated): 0.0051 +/- 0.0002
Y Arm:
- Arm visibility (given): 0.869 +/- 0.006 (26 pts)
- Cut off freq (given): 1720 +/- 70 [Hz]
- Finesse (derived): 1128 +/- 46
- Round Trip loss (estimated): 179 +/- 12 [ppm]
- Front Mirror T (estimated): 0.0054 +/- 0.0002
|
2417
|
Tue Dec 15 00:02:10 2009 |
rana | Update | PEM | Noise of the Ranger SS-1 Seismometer |
I wanted to see what the noise of the Ranger seismometer should be. I used LISO and file ranger.fil (in our LISO SVN) to calculate the voltage noise referred to the input. In this model, we represent the EMF from the moving magnet in the coil as a voltage source at 'nin' which drives the coil impedance. This is the same approach that Brian Lantz uses in his noise modeling of the GS-13 (PDF is on our Ranger wiki page).
In the simulation, I used the OP27 as a placeholder for the SR560 that we use (I don't know the current noise of the SR560). To do this, I use the new 'inputnoise' feature in LISO (its in the README, but not in the manual).
You can see that we would be limited by the input current noise of the OP27. So we would do a lot better if we used an FET based readout amp like the AD743 (or equivalent) or even better using the new multi-FET readout circuit that Rich Abbott has developed. Clearly, its also silly to have a load resistance in there - I put it in because the manual says to do it, but all it does is damp the mass and reduce the size of the signal.
# Noise sim for the Ranger SS-1 seismometer
#
# \
# | \
# n2- - - ---- - | \
# | | | op1>-- n4 - r4 -- no
# Rg RL n3- | / |
# n1 - | | | | / |
# Lg | | / |
# | | | - - - R2 - -
# nin gnd R1
# |
# gnd
We previously measured the Ranger's self noise by locking it down.
The 1/f^3 noise that we see below 1 Hz is roughly consistent with the noise model: to get from my plot into meters you have to multiply by:
(1 + f)^2
----------
340 * f^2
P.S. Secret PDF handshake: You can make your non-compliant applications like LISO or DTT produce a thumbnailing PDF by using Acrobat to open the file and export it as PDF/A.
In the second attachment, I have used an OPA827 (new low-noise FET input amp from TI) as the readout amplifier. This seems like a good choice - main drawback is that Digikey backordered my OPA827s by 19 weeks! |
Attachment 1: rangerx.pdf
|
|
Attachment 2: ranger827.pdf
|
|
2418
|
Tue Dec 15 05:29:31 2009 |
Alberto | Update | General | Arm Cavity Poles measured again after cleaning the optics last week |
The Y arm cavity pole moved down by 130 Hz, whereas the X arm moved by only 34 Hz. I wonder if that is because Kiwamu spent much more time on cleaning ITMY than on any other optic. |
2419
|
Tue Dec 15 17:16:22 2009 |
Koji | Update | General | Table distance measurements |
During the vent we have tried to measure the distances of the optical tables for BS-ITMX and BS-ITMY.
We need to take into account the difference between the AutoCAD drawing and the reality.
X direction distance of the table center for BS and ITMX:
84.086" (= 2135.8mm)
(This is 84.0000" in AutoCAD drawing)
Y direction distance of the table center for BS and ITMX:
83.9685" (= 2132.8mm)
(This is 83.5397" in AutoCAD drawing)
We used two scales attached each other in order to measure the distance of the certain holes on the tables.
We got more numbers that were estimated from several separated measurements.
I think they were not so accurate, but just as a record, I also put the figure as an attachment 2. |
Attachment 1: Table_distance_by_metal_scale.pdf
|
|
Attachment 2: Table_distance_by_chambers.pdf
|
|
2420
|
Tue Dec 15 21:39:34 2009 |
Alberto | Update | ABSL | brief summary of this afternoon's measurements |
I took measurements of the open loop gain of the AbsL PLL with the old Universal PDH Box.
I Also measured the filter shape of both the new and the old PDH box.
I'm going to plot the results in a nice form tomorrow morning.
For who's interested, the PLL UGF was at 10KHz.
I can't lock the PLL with the new PDH box. Measuring its filter's shape, as suggested by Koji, I found out that it differs from the old one. That despite the fact that the two boxes should share the same circuit schematic. O,r at least, that is what it looks like from the schematics in the DCC.
I need to understand whether that is intentional and, if that was the case, what kind of use Rich Abbott designed it for.
Tomorrow I'm going to post in the elog the filter's transfer functions too.
Before leaving the lab I closed the auxiliary laser's mechanical shutter. |
2421
|
Wed Dec 16 11:21:20 2009 |
Alberto | Update | ABSL | Universal PDH Box Servo Filters |
Yesterday I measured the shape of the servo filter of both the old and the new Universal PDH boxes.
Here they are compared.

The way the filter's transfer function has been measured is by a swept sine between the "SERVO INPUT" and the "PIEZO DRIVE OUTPUT" connection on the box front panel. The spectrum analyzer used for the measurement is the SR785 and the source amplitude is set at 0.1V.
The two transfer functions are clearly different. In particular the old one looks like a simple integrator, whereas the new one already includes some sort of boost.
That probably explains why the new one is unable to lock the PLL. Indeed what the PLL needs, at least to acquire lock, is an 1/f filter.
I thought the two boxes were almost identical, at least in the filter shapes. Also the two schematics available in the DCC coincide. |
Attachment 1: NewandOlfFilterTF.png
|
|
2422
|
Wed Dec 16 11:46:25 2009 |
Alberto | Update | ABSL | Absl PLL Open Loop Gain |
Yesterday I measured the Open Loop Gain of the PLL in the absolute length experiment. The servo I used was that of the old Universal PDH box.
The OLG looks like this:

The UGF is at 10 KHz. |
2423
|
Wed Dec 16 11:55:47 2009 |
rana | Update | ABSL | Universal PDH Box Servo Filters |
To me, they both look stable. I guess that the phase has to go to -180 deg to be unstable.
Why does the magnitude go flat at high frequencies? That doesn't seem like 1/f.
How about a diagram of what inputs and outputs are being measured and what the gain knob and boost switch settings are? |
2424
|
Wed Dec 16 20:29:08 2009 |
rana | Update | COC | ETM Coating study |
This plot shows the Transmission for 532 and 1064 nm as a function of the thickness of the SiO2 layer.
i.e. the thickness is constrained so that the optical thickness of the SiO2 and Ta2O5 pair is always 1/2 of a wavelength.
The top layer of the mirror is also fixed in this plot to be 1/2 wave.
This plot shows the result for 17 pairs. For 16 pairs, we are unable to get as low as 15 ppm for the 1064 nm transmission. |
Attachment 1: layerfrac.png
|
|
2425
|
Thu Dec 17 02:57:08 2009 |
Jenne | Update | WienerFiltering | L1 DARM Static Wiener Filtered data |
This is perhaps best put in the LLO elog, but I'm not yet a 'person' there, so I can't write to their elog (yet another thing for the eternal to-do list). So for now, we're putting things here...
This isn't totally finalized, but I do want to get what I have posted before I hop on a plane in the morning. Mostly it just needs more time to run, to make the plot longer. Hopefully I'll be able to edit this in the morning and have a longer-duration plot.
What's plotted:
This spectrogram shows the amplitude spectra of L1:LSC-DARM_CTRL, after being subtracted via a Static Wiener Filter. Each spectra is normalized by the very first one, which was created from the same data that was used to determine the Wiener Filter. The X-axis is time. The Y-axis is frequency, and the Color/Z-axis is amplitude in dB. I'm only looking at Science Mode time, so other times when the IFO isn't in science mode, I plot a black stripe to fill in the plot. The start time of the plot is 83675598, which is Jul 08 2006 06:33:04 UTC.
Why?
The idea is to see that the filter does equally well a long time after it was created, as when it was initially made. This will help tell us how often it is useful to recompute the Wiener filters. Less often is nice, because redoing the Wiener filters may also include remeasuring the high precision transfer functions...if the filter isn't working as well anymore it may be because the transfer function has changed ever so slightly.
How the plot is created / the background story:
I use one hour of DARM_CTRL data and the following seismometer channels to create an optimal Wiener Filter (pem indicates L0:PEM- , sei indicates L1:SEI- , and lsc indicates L1:LSC- ) :
chans = {[pem 'EX_SEISX'],...
[pem 'EX_SEISY'],...
[pem 'EX_SEISZ'],...
[pem 'EY_SEISX'],...
[pem 'EY_SEISY'],...
[pem 'EY_SEISZ'],...
[pem 'LVEA_SEISX'],...
[pem 'LVEA_SEISY'],...
[pem 'LVEA_SEISZ'],...
[sei 'LVEA_STS2_X'],...
[sei 'LVEA_STS2_Y'],...
[sei 'LVEA_STS2_Z'],...
[sei 'ETMX_STS2_X'],...
[sei 'ETMX_STS2_Y'],...
[sei 'ETMX_STS2_Z'],...
[sei 'ETMY_STS2_X'],...
[sei 'ETMY_STS2_Y'],...
[sei 'ETMY_STS2_Z'],...
[lsc 'DARM_CTRL']};
I then apply this one filter to ten minute chunks of science mode data, for some long period of time. The game plan is to have a month long plot, but it takes a while to fetch all of the data in separate 10min intervals (~45sec per iteration, times ~3000 iterations), so this plot isn't a full month. Even if I don't get a chance to plot a full month by Thursday morning, it'll go up here within the next few days. The particular times chosen have the most science mode data within a 30 day period. I can easily run the code for some other time, if there is a known time (or season) which might be more interesting. For the spectrogram plot, I then normalize each amplitude spectra by the first one, which comes from the first ten minutes in the hour which was used to make the filter. This makes it easier to see how the filter's efficacy changes over time.
The analogous analysis for Hanford is in the 40m elog: 1606. The Hanford stuff in the elog has some cool BLRMS plots also, but I'm not sure that they're so helpful when I only have a few days of L1 data so far. I'll do those and add them later.
Conclusions:
I can't really say anything yet about the long-term efficacy of a Wiener Filter for LLO yet, since my code hasn't finished filtering my one month of S5 L1 data. It definitely looks like (so far) that there was a big seismic event around the (arbitrarily defined) 'Day 4'. |
Attachment 1: L1darmCompPlot_17Dec2009_4daysLong.png
|
|
2426
|
Thu Dec 17 07:47:29 2009 |
Jenne | Update | WienerFiltering | L1 DARM Static Wiener Filtered data |
This surface plot is the same as the previous one, with a little more data than I had previously.
This time around, I also include the "BLRMS" plots for this data. The first one takes each residual and normalizes it by the DARM_CTRL signal at that time, separates the spectra into bands, and integrates underneath the spectra within that band. The second one is the raw DARM_CTRL signal's spectra at each time, and integrates under the spectra for each band, and the third BLRMS plot does the same thing for the residuals. Unfortunately, these plots don't have the same handy black stripe during time which I don't analyze that the spectrogram utilizes.
From the second BLRMS plot we can see that the large red splotch in the spectrogram is due to higher noise in the DARM spectrum, and that (by looking at the Ratio BLRMS plot) the Wiener filter still does a pretty good job during this time. I expect that for later times when the seismic (or something) event is gone, the Wiener filter will continue performing almost as well as it had been initially.
Again, once the script finishes applying the filter to the many ten minute chunks (the huge time drain is the data fetching, so this shouldn't be a limiting factor for using Wiener filters online), I'll post a final plot. |
Attachment 1: L1darmComp_17Dec2009_6day_residualsNormSurfacePlot.png
|
|
Attachment 2: L1darmComp_17Dec2009_6day_ratioBLRMS.png
|
|
Attachment 3: L1darmComp_17Dec2009_6day_rawBLRMS.png
|
|
Attachment 4: L1darmComp_17Dec2009_6day_residualsBLRMS.png
|
|
2430
|
Thu Dec 17 23:27:23 2009 |
rana | Update | PEM | Ranger Noise: sim w. Rai FET box as readout |
I have started measuring the low frequency noise of the FET front end + LT1128 low noise preamp from Rai Weiss. It has a very low input current noise because its FET based, which is not surprising. It is also a fairly low voltage noise box - the best measured ones have an input referred noise of ~0.35 nV/rHz.
Today I measured the noise of the one we have down to 0.1 Hz. It looks like a good candidate for a Geophone readout (e.g. Ranger or GS-13 or perhaps the L-4C). Because I didn't thermally shield any of this stuff, the broadband noise is ~0.8 nV/rHz. The low frequency corner is ~15 Hz.
I attach the LISO simulation of the voltage noise referred to the input. The circuit is described in this entry.
We can probably do better than this if we package it a little better or give it time to warm up or use metal film resistors inside. Even as it is, however, it would allow us to reach the thermal noise of the Ranger (or GS-13) down to 0.1 Hz.
This should be ~1.5 or 2x better than the LT1012 based readout at 1 Hz and 10x better down at 0.1 Hz (c.f. T0900457). |
Attachment 1: ranger.pdf
|
|
2431
|
Fri Dec 18 15:40:33 2009 |
Koji | Update | IOO | MC2 spot centered / MCT QPD issue |
This afternoon I felt like saying hello to the input mode cleaner. So I decided to center the spot on MC2.
Motivation
MC has 6 alignment dofs. 4 of them are controlled by the WFSs. Remaining 2 appears at the spot position on MC2.
If the spot on the MC2 is fixed, the beam hits the same places of three mirrors. If the mirrors are completely fixed
in terms of the incident beam, I suppose the reflected beam is also fixed. This makes the WFS spots more stable.
Then I feel better.
Today's goal is to confirm the behaviour of MC such as dithering amplitude, response of the couplings to the alignment,
behavior of the WFS, and the transmitted power.
Method
1) Turned off MC auto locker. Turned off MC WFS as the WFS servos disturbs my work.
2) Dithered MC2 in Pitch and Yaw using DTT. There looks elliptic filter (fc=28Hz) in the ASC path, I used 20Hz-ish excitations.
- C1:SUS-MC2_ASCPIT_EXC 100cnt_pk@19Hz
- C1:SUS-MC2_ASCYAW_EXC 100cnt_pk@22Hz
3) Looked at C1:SUS-MC2_MCL_OUT to find the peaks at 19Hz and 22Hz. These are caused by alignment-length coupling.
If they are minimized I assume the spot is somehow centered on MC2.
Note: This may not be the true center. The suspension response should be investigated. But this is a certain reporoducible spot position.
Note: I should use ezcademod in order to obtain the phase information of the dither result.
4) Move MC2 Pitch for certain amount (0.01cnt) by the alignment slider. Align MC1/MC3 to have max transmittion.
5) If the Pitch peak got lower, the direction of 4) was right. Go further.
5') If the Pitch peak got higher, the direction of 4) was wrong. Go the other direction.
6) Repeat 4)&5) for Yaw.
Result
After the adjustment, the couplings got lower about 10 times. (Sorry! The explanation is not so scientific.)
Next time I (or someone) should make a script to do it and evaluate the coupling by the estimated distance of the spot from the center of the mirror (the center of the rotation).
I have not seen visible change in the spectrum of C1:SUS-MC2_MLC_OUT.
MCT QPD issue
By the spot centering, I could expected to see some improvement of the transmittion. But in reality, there was no change.
In fact, the transmittion power was getting down for those weeks.
I checked WFS and MCT paths. Eventually I found that a couple of possible problems:
1) MCT Total output varies more than 10% depending on the spot position on MCT QPD.
2) Just before the QPD, there is a ND1 filter.
This may suggest that:
a) Four elemtns of the MCT QPD have different responses.
b) The ND filter is causing a fringe.
So far I aligned the ND filter to face the beam. The reflection from the filter was blocked at a farther place.
Still the output varies on the spot position. Probably I have to look at the QPD someday.
So far the spot on the QPD was defined so that I get the maximum output from the QPD. This is about 8.8.
As I touched the steering mirrors, the X and Y outputs of the QPD are no longer any reference.
For now, I closed the PSL table. The full IFO was aligned. |
2433
|
Sun Dec 20 14:34:24 2009 |
Koji | Update | SUS | ETMY watchdog tripped Sunday 5:00AM local |
It seemed that the ETMY watchdog tripped early Sunday morning.
The reason is not known. I just looked at ETMX, but it seemed fine.
I called the control room just in case someone is working on the IFO.
Also I did not see any elog entry to indicate on going work there.
So, I decided to reset the watchdog for ETMY. And it is working fine again. |
Attachment 1: Y.png
|
|
2434
|
Sun Dec 20 21:39:40 2009 |
rana, jenne, kiwamu | Update | ASS | OAF Model update and build instructions |
After a lot of headache, I got the OAF working again - read on for details.....................
Sometime last week, Jenne, Kiwamu, and I tried to update the OAF model to include the IIR "feed-around" path.
This path is in parallel to the existing FIR-based adaptive FXLMS stuff that Matt put in earlier. The reason for the
new path is that we want to try emulating the same FF technology which has been successful lately at LLO.
However, we were unable to make the ASS work after this work. Mostly, the build stuff worked fine, but we couldn't get DTT
to make a transfer function. The excitation channels could be selected and the excitation would actually start and get all the
way into MC1, but DTT would just hang on the first swep-sine measurement with no time-out error. Clearly our ASS building
documentation is no good. We tried using the instructions that Koji gave us for AAA, but that didn't completely work.
In particular, the 'make-uninstall-daq-ass' command gave this command:
[controls@c1ass advLigo]$ make uninstall-daq-ass
grep: target/assepics/assepics*.cmd: No such file or directory
Please make ass first
make: *** [uninstall-daq-ass] Error 1
re-arranging the order to do 'make-ass' first fixes this issue and so I have fixed this in the OAF Wiki.
The there's the whole issue with the tpchn_C3.par file. This contains all the test point definitions for the ASS/OAF machine. The main
IFO numbers are all in tpchn_C1.par and the OMC is all in tpchn_C2.par. When we do the usual build, in the 'make install-daq-ass' part:
[controls@c1ass advLigo]$ make install-daq-ass
Installing GDS node 3 configuration file
/cvs/cds/caltech/target/gds/param/tpchn_C3.par
Updating DAQ configuration file
/cvs/cds/caltech/chans/daq/C1ASS.ini
we get this .par file installed in the target area. The ACTUAL param file seems to actually be in /cvs/cds/caltech/gds/param !!
Of course, it still doesn't work. That's because the standard build likes to point to /cvs/cds/caltech/gds/bin/awgtpman and the one that runs on
linux is actually /opt/gds/awgtpman. So I've now made a file called startup_ass.cmd.good which runs the correct one. However, the default build
will try to start the wrong one and we have to fix the 'startass' script to point to the correct one on each build. Running the correct awgtpman
allows us to get the TP data using tools like tdsdata, so far no luck with DTT.\
UPDATE (23:33): It turns out that it was my old nemesis, NTPD. c1ass had a /etc/ntp.conf file that was pointing at an ntp server called rana113. I
am not an NTP server; I don't even know what time it is. I have fixed the ntp.conf file by making it the same ass c1omc (it now points to nodus). After
this I set the date and time manually (sudo date -s "20 DEC 2009 23:27:45" ) and then restarted NTPD. It should now be fine even when
we reboot c1ass.
After all of this nonsense, I am able to get TP data from c1ass and take transfer functions between it and the rest of the world ! |
2435
|
Sun Dec 20 23:42:44 2009 |
Jenne | Update | IOO | New Input Mode Matching Telescope |
I've got most of the new Mode Matching Telescope figured out. The scripts and an example result are at: MMT09 wiki (Rather, the scripts are in the svn: MMT svn)
Issues still to be resolved:
* We're getting pretty iffy 'angles' between tilt and translation when using the mode matching mirrors for steering.
* I haven't taken into account the astigmatism which occurs when you tilt the mode matching mirrors.
The nifty thing about these scripts is that they take a look at the mode matching overlap: For each possible mode matching solution it adds noise to all of the distances and radii of curvature during ~10,000 iterations and plots a histogram of the overlap so that we can see which solutions have a better chance of giving us the optimal overlap, even if we place the optics in slightly the wrong place.
I'd like to update the overlap part of the script with the astigmatism business: do we lose goodness of overlap if we tilt the mirrors by a bit? I think this will require redoing the overlap part with the X and Y directions separate. Koji has done this in the past. My current code assumes that the beam is always symmetric in X and Y. |
2437
|
Mon Dec 21 02:22:31 2009 |
rana, jenne, kiwamu | Update | ASS | OAF Model update and build instructions |
This allowed measuring the MC1 -> MCL TF finally. Its mostly flat. Data saved as Templates/OAF/OAF-MCLTF.xml |
Attachment 1: Untitled.png
|
|
2438
|
Mon Dec 21 07:30:58 2009 |
??? | Update | ASS | OAF Model update and build instructions |
What does OAF stand for? The entry doesn't say that. Also the acronym is not in the abbreviation page of the wiki.
Can anyone please explain that? |
2440
|
Mon Dec 21 10:09:06 2009 |
jenne | Update | ASS | OAF Model update and build instructions |
OAF stands for Online Adaptive Filtering. We use the same computer which was once the ASS. One of these days, we'd like to completely be rid of all things which refer to ASS, and make even the computer's name OAF. |
2441
|
Mon Dec 21 19:24:29 2009 |
rana | Update | ASS | OAF Model update and build instructions |
I fit the MC1 -> MCL TF using vectfit4.m (from mDV). The wrapper file is mDV/extra/C1/ fitMC12MCL.m .
Plotted here are the data (RED), the fit (BLUE), and the residual x10 (GREEN).
For the magnitude plot, residual is defined as ------ res = 1 - fit / data
For the phase plot the residual is defined as ------- res = phase(data)-phase(fit)
You can see that the agreement is very good. The phase match is better than 5 deg everywhere below 10 Hz.
This TF is so smooth that we could have probably done without using this, but its good to excercise the method anyway. |
Attachment 1: mc12mcl.png
|
|
2442
|
Tue Dec 22 02:50:09 2009 |
rana, kiwamu, jenne | Update | ASS | OAF Feedaround ON and doing something good |
Kiwamu made the OAF screen functional today - screenshot attached.
After this, I used the measured TF of the MC1 to MCL to filter the signals from the Wilcoxon accelerometers and feed them into the MC.
The noise at 3 Hz went down by a factor of ~3. There's a little excess created at 100 Hz. Its good to see that our intuition about feed-forward is OK.
I did all of the filter calculations by adapting the scripts that Haixing, Valera, and I got going at LLO. They're all in the mDV/extra/C1 SVN.
The Wiener code predicts much better performance from using more than just 2 horizontal accelerometers, but I was too lazy to do more channels today.
I also added the Rai box to the Ranger readout today - the noise at 0.1 Hz went down by a factor of 10 and the noise at 1 Hz is close to 10^-11 m/rHz. |
Attachment 1: oaf.png
|
|
Attachment 2: oaf.png
|
|
2444
|
Tue Dec 22 11:23:51 2009 |
kiwamu, Steve | Update | IOO | MC relocked |
In this morning I found MC unlocked.
Steve restored the watchdogs before I found that.
Then I relocked MC and now MC is locked and working well.
The reflected DC power is ~0.38, which is usual number.
|
2446
|
Tue Dec 22 15:49:31 2009 |
kiwamu | Update | General | e-log restarted |
I found the e-log has been down around 3:40pm, then I restarted the e-log. Now it's working.
Thanks. |