ID |
Date |
Author |
Type |
Category |
Subject |
9156
|
Tue Sep 24 20:43:45 2013 |
masayuki | Summary | SUS | optical levers centering |
I centered optical levers of ITMX,BS,ETMY. I also change the position of optical levers of ITMX, ETMY, ITMY, BS on Friday night(9/21), of ITMX, ETMY, BS on Monday night. Both are around 6:00 ~ 7:00.But centering on Monday was totally wrong, because I centered with not good IFO alignment.
The attachment is the 5 days trend of the opt lev of ITMX. First gap is alignment on Friday and Second gap is the alignment on Monday. Now I centered after locking the FPMI.
The attachment 2 is the last 6 hours data. The gap on 9/25 00:00 and 1:30(UTC) is because the alignment of the cavity and the last gap is because of centering of the optical lever. |
Attachment 1: Screenshot-Untitled_Window.png
|
|
Attachment 2: Screenshot-Untitled_Window-1.png
|
|
9155
|
Tue Sep 24 10:55:45 2013 |
rana | Update | PSL | PMC re-aligned |
After relocking the PMC at a good voltage, Steve and I re-aligned the beam into the PMC by walking the last two steering mirrors. After maximizing the power, we also aligned the reflected beam by maximizing the PMC_REFL_DC with the unlocked beam.
Transmission is back to 0.84 V. We need Valera mode matching maintenance to get higher I guess. Maybe we can get a little toaster to keep the PMC PZT more in the middle of its range? |
Attachment 1: psl-trend.png
|
|
9154
|
Sun Sep 22 23:04:52 2013 |
rana | Update | PEM | Guralp needs recentering |
After seeing all of these spikes in the BLRMS at high frequency for awhile, I power cycled the Guralp interface box (@ 10:21 PM) to see if it would randomly recenter in a different place and stop glitching.
It did - needs to be better centered (using the paddle). Plot shows how the Z channel gets better after power cycle. |
Attachment 1: seis.pdf
|
|
9153
|
Sun Sep 22 22:54:28 2013 |
rana | Update | IOO | mode cleaner not locking |
Having trouble again, starting around 1 hour ago. No one in the VEA. Adjusted the offset -seems to be OK again. |
9152
|
Sun Sep 22 22:05:10 2013 |
rana | Update | SUS | oplev XY-plots reflect new calibration |
The ETMX oplev signal looks kind of dead compared to the ETMY. It has no features in the spectra and the SUM is pretty low.
I noticed that the cal fields are still set to 1. To get it close to something reasonable, I calibrated it vs. the SUSPIT and SUSYAW values by giving it a step in angle and using 'tdsavg' plus some arithmetic.
OLPIT = 45 urads/ count
OLYAW = 85 urads / count
These are very rough. I don't even know what the accuracy is on the OSEM based calibration, so this ought to be redone in the way that Jenne and Gabriele did before.
The attached image shows the situation after "calibration" of ETMX. This OL system needs some noise investigation. |
Attachment 1: noise.png
|
|
9151
|
Sun Sep 22 21:28:53 2013 |
rana | Update | SUS | set OL T RAMP values (they are not visible on the OL screens) |
controls@rosalba:/opt/rtcds/caltech/c1/scripts/SUS 0$ ./setOLtramps
Old : C1:SUS-ETMX_OLPIT_TRAMP 0
New : C1:SUS-ETMX_OLPIT_TRAMP 2
Old : C1:SUS-ETMX_OLYAW_TRAMP 0
New : C1:SUS-ETMX_OLYAW_TRAMP 2
Old : C1:SUS-ETMY_OLPIT_TRAMP 2
New : C1:SUS-ETMY_OLPIT_TRAMP 2
Old : C1:SUS-ETMY_OLYAW_TRAMP 2
New : C1:SUS-ETMY_OLYAW_TRAMP 2
Old : C1:SUS-ITMX_OLPIT_TRAMP 0
New : C1:SUS-ITMX_OLPIT_TRAMP 2
Old : C1:SUS-ITMX_OLYAW_TRAMP 0
New : C1:SUS-ITMX_OLYAW_TRAMP 2
Old : C1:SUS-ITMY_OLPIT_TRAMP 0
New : C1:SUS-ITMY_OLPIT_TRAMP 2
Old : C1:SUS-ITMY_OLYAW_TRAMP 0
New : C1:SUS-ITMY_OLYAW_TRAMP 2
Old : C1:SUS-BS_OLPIT_TRAMP 0
New : C1:SUS-BS_OLPIT_TRAMP 2
Old : C1:SUS-BS_OLYAW_TRAMP 0
New : C1:SUS-BS_OLYAW_TRAMP 2
Old : C1:SUS-PRM_OLPIT_TRAMP 0
New : C1:SUS-PRM_OLPIT_TRAMP 2
Old : C1:SUS-PRM_OLYAW_TRAMP 0
New : C1:SUS-PRM_OLYAW_TRAMP 2
Old : C1:SUS-SRM_OLPIT_TRAMP 0
New : C1:SUS-SRM_OLPIT_TRAMP 2
Old : C1:SUS-SRM_OLYAW_TRAMP 0
New : C1:SUS-SRM_OLYAW_TRAMP 2
Done setting TRAMPs |
9150
|
Sun Sep 22 21:03:15 2013 |
rana | Configuration | SUS | Tuned bounce and roll mode of ETMY suspension |
Today I noticed that there was a lot of noise at the Bounce and Roll eigenfrequencies for ETMY. I found that the bandstop filter were set at completely the wrong frequencies, so I've remade them.
The filters were last tuned by Leo in May of 2011. Even so, he left the frequencies at the frequencies of the old MOS suspensions which had f_bounce ~ 12 Hz.
The FOTON plot shows the OLD ones versus the NEW ones. The DTT spectra shows the oplev error signals in the usual state. I have also copied these over to the SUSPOS,PIT,YAW, and SIDE filter banks and turned them all ON.
I also turned OFF and deleted the 3 Hz RG filter that was there. There's no such peak in the error signal and even if one wanted to compensate for the stack mode, it should be a low Q filter, not this monster. |
Attachment 1: etmy-error.png
|
|
Attachment 2: notches.pdf
|
|
9149
|
Fri Sep 20 22:49:10 2013 |
Masayuki | Update | LSC | LSC calibration screen |
Quote: |
I update the LSC calibration screen. This screen is for real time calibration of each DOF with using error signal and control signal. The formula of the calibration is
x_dis = V_err/H + A V_fb
,where x_dis is the disturbance without surpression, V_err and V_fb are error signal and control signal, H is the transfer function from the displacement to output and A is the efficiency of the actuator.
I will put the filter of 1/H into the CINV filter bank and actuator efficiency into the A filter bank.
|
I fixed the filter of the MICH real-time calibration. You can find C1CAL screen from the LSC menu 'calibration' of sitemap.
*Filter explanation
C1CAL_MICH_CINV : the servo to convert the error signal to displacement.
Sen_MICH :
the inverse of the transfer function from the distance to the error signal, which has the unit of count/m. In the formula this filter is represented by 1/H.
I assume this H is independent of frequency and time, and I calculated by the amplitude of the fringe of error signal. But it may change every day by drift of laser intensity and so on. So we should follow the actual H somehow. The temporary value of H is 3.76*10^7 count/m .
C1CAL_MICH_A : the servo to convert the feedback signal to displacement. In formula This transfer function is represented by A
SUS_BS;
the transfer function of the suspension of the BS. This is modeled from the measurement in elog#9127. The resonant frequency is 1.029 Hz and Q is 12.25.
Res_A :
the response of the actuator on BS_SUS, which has the unit of m/count. The value is 1.99*10^-8 m/count. This value is measured in the measurement in elog#9121.
C1CAL_MICH_W : the servo to handle the calibrated signal.
m->um ;
the filter to convert the unit of signal from m to um. When this filter is on, the output is written in unit of um.
*Measurement
I measured the power spectrum of the calibrated free running noise. The measured port was C!CAL_MICH_W_OUT. The result is in attachment 1. Also in this figure there are the plots of the Verr/H and Vfb*A.
In low frequency region, where control loop suppresses the disturbance, you can see that the displacement is equal to the displacement of actuation (I'm not sure what happens at the point of 0.03Hz), and in high frequency region, where control loop doesn't work, the displacement is equal to the value of the Verr divided by MICH sensitivity. Also this result is similar to the my calibration result.elog#9131 |
Attachment 1: plot.pdf
|
|
9148
|
Fri Sep 20 20:27:18 2013 |
rana | Update | IOO | mode cleaner not locking |
I used our procedure from this entry to set the IMC board offset as well as the FSS board offset.
I found this afternoon that the MC was having trouble locking: the PC path was railing as soon as the boost was engaged. Could be that there's some misalignment on the PSL which has led to some RAM having to be canceled by this new offset. Let's see if its stable for awhile. |
9147
|
Fri Sep 20 20:14:52 2013 |
rana | Summary | General | /home/cds nearly full |
Quote: |
One of the reasons that our disk is getting full is due to the scripts_archive directory. A backup script runs on op340m and makes a tar.bz2 file of the scripts directory and puts it in scripts_archive every morning at 6 AM.
On Oct 7, 2011, Koji fixed this script to point at our new scripts directory instead of the old /cvs/cds/caltech/scripts directory. Since then, however, no one has fixed the exclude file to NOT back up the junk that's in that directory. Its a 1.6 GB directory so its full of it.
I've deleted a bunch of junk from the scripts directory: this directory is for scripts, not for your personal home movies or junk data files. Put those in your USER directory. Put temporary data files in /tmp/. I've also added a few more patterns to the exclude file so that less .mpg, .png, .pdf, .dat, etc get stored every day. The new daily .tar.bz2 file wil be ~25 MB instead of 770 MB.
(also fixed the backup script to use 'env' to setup the perl environment and removed the hard-coded path to tar)
|
OUr disk was getting full again. Turned out my "fix" to 25 MB was only a fix to 250 MB. Since we were getting disk full warnings on our Ubuntu workstations, I deleted some COMSOL.dmg files from users/zach/ and then started deleting every other tarball from the scripts_archive directory. ~221 GB are now free. Still need to fix the exclude file for scripts better. |
9146
|
Fri Sep 20 16:37:30 2013 |
Steve | Update | VAC | vertex crane folding arm is back on |
Quote: |
The folding beam removed as shown. Two man supporting it while I hammering it out. Pin was dry and it gulled into supporting hinges.
The rotating hinge will be machined and bushing will be added with Zerk fitting or similar. This will allow lubrication in the future.
see elog #9111
|
Atm1, The folding arm is back on with 0.1" misalignment at no load in the trolly's way. The other side of the I beam is 0.02" higher than the main beam.. New bushing and pin were greased up with Krytox before installation.
The axial Zerk 1/8" pipe in the pin upper end can not take any fitting. There is no room. It is taped off.
This gap comes down to ~ 1/16" at fully extended arm with 225 lbs load at the end of it.
The present plan is to grind down the the misalignment of 0.1" for a slow-loaded trolly.
Steve Baker of Konacranes will be back to grind down this ridge and load test at 500 lbs on Tuesday, OCT 1, 2013
|
Attachment 1: bushingBottom.jpg
|
|
Attachment 2: foldingI.jpg
|
|
Attachment 3: noLoadGap.jpg
|
|
Attachment 4: trollyway.jpg
|
|
Attachment 5: trollySee.jpg
|
|
9145
|
Fri Sep 20 09:49:06 2013 |
Steve | Update | SUS | Optical Lever Trend for 180 days: bad ETMY & PRM |
I'm working on it. |
Attachment 1: ETMYoplevPRM.png
|
|
9144
|
Fri Sep 20 08:15:30 2013 |
Steve | Update | Computer Scripts / Programs | Ottavia, Rossa and Pianosa |
Ottavia, Rossa and Pianosa are running out of storage space. |
Attachment 1: Ottavia.png
|
|
Attachment 2: Rossa.png
|
|
Attachment 3: Pianosa.png
|
|
9143
|
Thu Sep 19 21:42:18 2013 |
rana | Update | SUS | Optical Lever Trend for 90 days: ETMX and PRM are the bad ones |
|
Attachment 1: OLtrend_2013.png
|
|
9142
|
Thu Sep 19 21:15:44 2013 |
rana | Update | Computer Scripts / Programs | PMC locker |
I used a script (~PSL/PMC/testAutoLocker.sh) to unlock the PMC and run autlocker ~100 times to see how robust the new autlocker is.
It failed to grab it 2 out of 137 times. During those times it just went on trying to ramp the PZT even after it had gone to a rail. Once someone resurrects Rob's 'trianglewave' script we should be OK. Even so, I think this is good enough. Please try this out via the yellow button next time the PMC needs to be locked.
It usually takes 10-30 seconds to lock, depending upon where the fringe is compared to the upper voltage rail. Good enough. |
Attachment 1: Untitled.pdf
|
|
9141
|
Thu Sep 19 18:48:24 2013 |
rana | Update | Computer Scripts / Programs | PMC locker |
In May of 2013 Den wrote a PMC Autolocker because he ignored / didn't want to read anyone else's code. Later that year Yuta also wrote another one from scratch for the same reasons.
I tried to use both today, but neither one runs. Yuta's one doesn't run because he was using a bunch of private yuta library stuff in the yuta directory. That kind of programming style is pretty useless for us since it never works after some time.
So I re-activated and tested the PMCAutolock bash script (it is actually a symbolic link called "PMCAutolock" which points to AutoLock.sh). These scripts are all basically the same:
They turn off the loop (or turn down the gain) and then scan the PZT, look for a resonance, and then activate the loop.
One problem with the logic has been that turning off the loop makes the gain so low that the peak flashes by too fast. But leaving the loop ON and just sweeping with the gain turned down to -10 dB is also not good. That only reduces the UGF from 1 kHz to ~100 Hz. What we want is more like a 10 Hz UGF while scanning the length. SO, I edited the script to turn down the modulation depth on the EOM by that factor. After acquiring lock, it returns all settings to the nominal levels as defined on the PSL_SETTINGS screen.
I've tested it a few times and it seems to work OK. You can run it from the yellow shabang button on the PMC screen.
I also changed the .bashrc aliases for the MEDM command so that if you type medm_good at the command line you get MEDM screens with scalable fonts. So you can stretch the screens. |
Attachment 1: pmc.png
|
|
9140
|
Thu Sep 19 10:24:58 2013 |
Steve | Update | PEM | PRM damping restored after earth quake |
Local m3.8 eq shakes PRM lose. |
Attachment 1: eq3.8mLaVerne.png
|
|
9139
|
Wed Sep 18 14:57:12 2013 |
Steve | Update | VAC | vertex crane folding arm removed |
The folding beam removed as shown. Two man supporting it while I hammering it out. Pin was dry and it gulled into supporting hinges.
The rotating hinge will be machined and bushing will be added with Zerk fitting or similar. This will allow lubrication in the future.
see elog #9111 |
Attachment 1: manPower.jpg
|
|
Attachment 2: rotatingHinge.jpg
|
|
Attachment 3: supportingHinge.jpg
|
|
Attachment 4: gullingPin.jpg
|
|
9138
|
Wed Sep 18 11:52:53 2013 |
Jamie | Update | CDS | Dataviewer cannot connect to fb |
Quote: |
Masayuki pointed out that dataviewer wasn't connecting to the fb this morning.
When I started dataviewer from the terminal I obtained the following error:
controls@pianosa:~ 0$ dataviewer
Can't find hostname `fb:8088'
Can't find hostname `fb:8088'; gethostbyname(); error=1
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Error in obtaining chan info.
Can't find hostname `fb:8088'
Can't find hostname `fb:8088'; gethostbyname(); error=1
I checked the CDS FE status screen and it looks normal. I could ping the fb and ssh to it as well.
I restarted fb to see if it made any difference. telnet fb 8088
It hasn't helped. Anything else that can be done??
|
I've fixed the problem. This was due to a change I made in the NDSSERVER environment variable so that it would work with cdsutils. I didn't realize there was an incompatibility with how dataviewer parses NDSSERVER. Joe and I will have to figure it out.
In the mean time I've changed things back so that that dataviewer should now work as expected. You might have to log out and back in for it to work (or at least open a new terminal). |
9137
|
Wed Sep 18 11:29:43 2013 |
manasa | Update | CDS | Dataviewer cannot connect to fb |
Masayuki pointed out that dataviewer wasn't connecting to the fb this morning.
When I started dataviewer from the terminal I obtained the following error:
controls@pianosa:~ 0$ dataviewer
Can't find hostname `fb:8088'
Can't find hostname `fb:8088'; gethostbyname(); error=1
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Error in obtaining chan info.
Can't find hostname `fb:8088'
Can't find hostname `fb:8088'; gethostbyname(); error=1
I checked the CDS FE status screen and it looks normal. I could ping the fb and ssh to it as well.
I restarted fb to see if it made any difference. telnet fb 8088
It hasn't helped. Anything else that can be done??

|
9136
|
Tue Sep 17 18:44:29 2013 |
Masayuki | Update | LSC | LSC calibration screen |
I update the LSC calibration screen. This screen is for real time calibration of each DOF with using error signal and control signal. The formula of the calibration is
x_dis = V_err/H + A V_fb
,where x_dis is the disturbance without surpression, V_err and V_fb are error signal and control signal, H is the transfer function from the displacement to output and A is the efficiency of the actuator.
I will put the filter of 1/H into the CINV filter bank and actuator efficiency into the A filter bank.
|
Attachment 1: calibration_screen.png
|
|
9135
|
Tue Sep 17 17:55:42 2013 |
Jamie. | Configuration | Computer Scripts / Programs | pyepics configured |
Quote: |
controls@rosalba:~ 0$ cdsutils Traceback (most recent call last): File "/ligo/apps/cdsutils/lib/cdsutils/__main__.py", line 7, in <module> from cdsutils import CMDS File "/ligo/apps/cdsutils/lib/cdsutils/__init__.py", line 4, in <module> from servo import servo File "/ligo/apps/cdsutils/lib/cdsutils/servo.py", line 1, in <module> from epics import PV ImportError: No module named epics controls@rosalba:~ 1$
Mon Sep 16 19:40:32 2013
|
I properly installed the python-pyepics package on all the workstations, so this should be working now.
And for posterity, the pyepics source is at:
pianos:/home/controls/src/pyepics
From this debian packages were built:
controls@pianosa:~/src/pyepics 0$ debuild -uc -us
The .deb was then moved into the /ligo/apps/deb nfs:
controls@pianosa:~/src 0$ cp python-pyepics_*_all.deb /ligo/apps/debs/pyepics/
It was then installed on the various workstations:
controls@rosalba:~ 0$ sudo dpkg -i /ligo/apps/debs/pyepics/python-pyepics*.deb
This will probably need to be repeated any time we upgrade the EPICS install. |
9134
|
Tue Sep 17 00:50:42 2013 |
Masayuki | Update | LSC | MICH calbration |
I found the bug in my calibration code, and I fixed it.
And I put the white Gaussian noise on the BS actuator, and calibrated to the differential length with my new code. We already know the efficiency of the actuator(elog#8242), so I could estimate how much I put the disturbance and compare the two values. The result is in attachment 1. x_exc means the value of the disturbance.
You can see the PSD of the differential motion decrease factor of 3 by decreasing the disturbance by factor of 3 (except for the region from 1 Hz to 5 Hz), and the value at lower frequency than resonant frequency of the suspension is comparable to the value estimated with the actuator efficiency. Also there is no dip when I put the larger disturbance than free running noise.
Between 1 Hz and 5 Hz there seems to be a resonance of something (seismic stack?). And also on resonance of the suspension there seems to be some other noise source. One possibility is the active damping of each suspension.
Actually still there seems to be a dip between 0.1 Hz and 1 Hz. But if you consider about those effect, I think this result doesn't seems to be so strange. But according to the documentation of LIGO document-T000058, which I found the seismic motion in 40 m Lab is written in, the seismic motion at 0.1 Hz is 10^-7. I'm not sure about this factor of 10 difference. One possibility is the geophone doesn't have good sensitivity at low frequency. I'm still not sure this result is really collect.
|
Attachment 1: noise.PNG
|
|
9133
|
Mon Sep 16 19:41:01 2013 |
rana | Configuration | Computer Scripts / Programs | cdsutils checked out into /opt/rtcds |
controls@rosalba:~ 0$ cdsutils Traceback (most recent call last): File "/ligo/apps/cdsutils/lib/cdsutils/__main__.py", line 7, in <module> from cdsutils import CMDS File "/ligo/apps/cdsutils/lib/cdsutils/__init__.py", line 4, in <module> from servo import servo File "/ligo/apps/cdsutils/lib/cdsutils/servo.py", line 1, in <module> from epics import PV ImportError: No module named epics controls@rosalba:~ 1$
Mon Sep 16 19:40:32 2013 |
9132
|
Mon Sep 16 15:29:50 2013 |
Jamie | Configuration | Computer Scripts / Programs | cdsutils checked out into /opt/rtcds |
We now have a proper install of cdsutils:
controls@rossa:~ 0$ cdsutils
usage: cdsutils <cmd> <args>
Advanced LIGO Control Room Utilites
Available commands:
read read EPICS channel value
write write EPICS channel value
switch switch buttons in standard LIGO filter module
avg average NDS channels for some amount of time
servo simple integrator (pole at zero)
Add '-h' after individual commands for command help.
controls@rossa:~ 0$
It is installed in /ligo/apps/cdsutils, and should be in the path on all workstations.
The "development" source working directory is currently checked out at /opt/rtcds/cdsutils/trunk.
|
9131
|
Mon Sep 16 14:11:47 2013 |
rana | Update | LSC | MICH calbration |
There doesn't seem to be any coherence among the different directions of ground motion (as expected from seismic theory), so I am suspicious of such a low MICH noise. |
Attachment 1: Screen_Shot_2013-09-16_at_2.10.31_PM.png
|
|
Attachment 2: Screen_Shot_2013-09-16_at_2.18.47_PM.png
|
|
9130
|
Mon Sep 16 13:11:15 2013 |
Evan | Update | Computer Scripts / Programs | Comsol 4.3b upgrade |
Comsol 4.3b is now installed under /cvs/cds/caltech/apps/linux64/COMSOL43b. I've left the existing Comsol 4.2 installation alone; according to the Comsol installation guide [PDF], it is unaffected by the new install. On megatron I've made a symlink so that you can call comsol in bash to start Comsol 4.3b.
The first time I ran comsol server, it asked me to choose a username/password combo, so I made it the same as the combo used to log on to megatron.
Edit: I've also added a ~/.screenrc on megatron (based on this Stackoverflow answer) so that I don't constantly go nuts trying to figure out if I'm already inside a screen session. |
9129
|
Mon Sep 16 10:57:11 2013 |
Steve | Update | VAC | RGA scan at day 41 |
Quote: |
Valve configuration: Vacuum Normal
|
Finally we reached 1.0e-5 Torr, cc1 (h) at day 41. There must be a leak or cold cathode gauge is not reading correctly. The gauge is new. It should not take this long.
All chamber annulos pressures are normal. |
Attachment 1: pd76m41dRGA.png
|
|
Attachment 2: pd76m41d.png
|
|
9128
|
Fri Sep 13 19:22:01 2013 |
Masayuki | Update | LSC | MICH calbration |
I made sure the yesterday's result was collect. I measured not only the error signal but also the feedback signal. And I compared those signals and measured the TF in order to confirm my servo filter model is not wrong.
The reason of dip at low frequency region is maybe the coherence of the ground motion. The ITMX and ITMY suspensions are put close. If ground motion has coherence, the mirrors move in common mode. That will suppress the free running noise. The attachment is the free running noise of Sep 13rd and Sep 12nd. |
Attachment 1: noise.PNG
|
|
9127
|
Thu Sep 12 23:36:25 2013 |
Masayuki | Update | LSC | MICH calbration |
For Modelling of the OLTF, I measured the response of the BS suspension. I used the OSEM sensor for measurement. The attatchment1 is the measured TF from C1:SUS-BS_LSC_EXC to C1:SUS-BS_SUSPOS_IN1 with exciting with random force. The measured data was fitted and the resonant frequency is 1.029(±0.005) Hz and quality factor is 12.25 (± 0.2). Additionally I did same measurement for ITMX and ITMY. The attachment 2 and 3 are the results for ITMX and ITMY. Each eigenfrequency and Q are 1.063 (±0.008) Hz and 7.33 (±0.13) (ITMX), 1.022 (±0.005) Hz and 9.41 (±0.09) (ITMY).
After that, I locked the MICH with AS55, and measured the PSD of error signal. I compensated the that PSD by the modelled OLTF with this suspension TF and the servo TF. The result is in attachment 4. Above 1 Hz it is quite close to the previous data by Keiko (elog#6385) But below 1 Hz there is a large dip. The error signal has also this dip. I looked for a integral filter between 0.2 Hz and 1 Hz, but I connot find a such filter. And when I locked MICH with using ASDC, there was same dip at same frequency. I don't think it's true free running noise, and I will try to fix it.
I completely forgot to mention that I fitted the modelled OLTF into the measured OLTF. I used the fitted OLTF for compensation.
|
Attachment 1: BSsus.PNG
|
|
Attachment 2: ITMXsus.PNG
|
|
Attachment 3: ITMY.PNG
|
|
Attachment 4: free_running.PNG
|
|
9126
|
Thu Sep 12 01:06:09 2013 |
Jenne | Update | ASC | SRCL ASS implemented |
I have modified the ASS model to also have an ASS for SRCL. The input options are POPDC, POP110, AS110. I suppose I could/should have included ASDC.
Screens are modified / made. I haven't finished setting the servo gains and oscillator amplitudes, and all that jazz yet.
Using the parameters that Koji had in elog 9116, I was able to get nice long DRMI locks (several on a ~10 minute time scale).
I tried some pseudo-ANDing for the triggers, to no avail. I was trying to have the trigger matrix row for the SRCL loop have 1*POP22 and 0.02*AS110, where the 0.02 is to scale AS110 so that it has a similar amplitude to POP22. I then set threshold levels to ~250 for up, and 100 for down (I tried several different values for the up threshold). I was watching the TRIG_MON_FAST channels for both PRCL and SRCL, and I wasn't able to get SRCL to be triggered only at the same times as PRCL using this technique. Since we can get the DRMI to lock, perhaps my AND logic for the triggers is a low priority, but I think we'll need something like that if we want real logic.
|
9125
|
Thu Sep 12 00:07:26 2013 |
Masayuki | Summary | Green Locking | ALS locking in both arms |
Quote: |
What was the beat freq for each arm?
The HF noise level depends on the frequency of the beat note.
As the BBPD has the freq dependent noise level. (See this entry)
|
I'm not sure about the actual number of the beat frequency, but the beat frequency was almost same in both arms. And I took this measurement sometimes with slightly different beat frequency but the noise level didn't change so much. |
9124
|
Wed Sep 11 23:43:10 2013 |
Koji | Summary | Green Locking | ALS locking in both arms |
What was the beat freq for each arm?
The HF noise level depends on the frequency of the beat note.
As the BBPD has the freq dependent noise level. (See this entry) |
9123
|
Wed Sep 11 23:34:37 2013 |
Masayuki | Summary | Green Locking | ALS locking in both arms |
[manasa, masayuki]
We locked the XARM and YARM with using ALS control loop and we succeeded to lock stably both arms. The performance of the ALS was tested with a measurement of the calibrated error signal. (attachment 1)
- red and blue : the in-loop noise of ALS of each arm.
- green and purple:Stability of the beat-note frequency with the MC and the arm freely running.
Discussion
In the high frequency region, YARM has larger noise than XARM, and these noises were not there in previous measurements by Koji and Manasa (elog8865). You can see that in both of in-loop noise and free running noise. These noises may be caused by the Green PDH servo or hte phase tracker servo or any other electrical staff. We will start noise budget of these servo.
At higher frequency than UGF of ASL control loop, the loop does not suppress the noises at all, but the inloop and free running noise are not equivalent. I have no idea about that so far.
|
Attachment 1: noise.pdf
|
|
9122
|
Wed Sep 11 17:35:38 2013 |
Jenne | Update | LSC | ALS requirement |
I have done a quickie look at Optickle to see how the linewidth of an arm cavity changes versus the configuration.
To do this, I make different configurations, and do a sweep of ETMX. For each configuration, I find the max peak value, and then find the points that are at half that value. The distance between them is the full width at half max.
I get:
FWHM_DRFPMI = 3.8750e-11 meters
FWHM_PRFPMI = 3.8000e-11 meters
FWHM_SRFPMI = 2.3200e-09 meters
FWHM_FPMI = 1.1900e-09 meters
So, for the ALS to hold within 1/10th of a linewidth for the full IFO configuration, we want the ALS noise to be on the order of 3 picometers RMS. If I recall correctly, that's about an order of magnitude better than we currently have.

use LOG y-scale
EDIT 8 Nov 2013, JCD: New log-y plot:

|
9121
|
Tue Sep 10 17:35:50 2013 |
Masayuki, Manasa | Update | LSC | MICH calbration |
Quote: |
[Manasa, Masayuki]
We took a bunch of measurements. Transfer function and power spectrum using DTT. They will be used to obtain calibrated MICH in-loop and free-running noise. Detail Elog with plots will follow very soon.
|
[Masayuki, Manasa]
Estimation of free-running MICH displacement noise:
Method 1. Assuming AS55_Q_err to be a linear sensor, as shown in (1) of figure below, free-running MICH noise (V_d) can be estimated by measuring V_err and the OLTF G. H can be estimated by using method explained in elog
Method 2. Considering that the AS55_Q signal might be distorted or saturated, method 1 may not be precise. In method 2, we will use the ASDC as the sensor (S' in (3)) instead and lock MICH using ASDC in mid-fringe to calibrate the ITM actuators.
Figure:1
Schematic:

What we did:
1. Estimate H' from free-running ASDC signal (bright to dark fringe).
2. With MICH locked on ASDC, give an excitation signal to C1:LSC-SUS_XXXX_EXC (XXXX could be ITMX or ITMY) and measure R'. [(3) of schematic]
3. Measure OLTF of MICH locked on ASDC (hence estimate L). [(3) of schematic]
4. With MICH locked on AS55_Q, give an excitation signal to C1:LSC-SUS_XXXX_EXC (XXXX could be ITMX or ITMY) and measure R1. [(2) of the schematic]
Results/Plots:
Figure:2
OLTF of MICH locked on ASDC

Figure2:
Actuator excitation to MICH transfer function (MICH locked using ASDC)

* y axis (no units)
Figure 3:
Actuator excitation to MICH transfer function (MICH locked using AS55Q)
* y axis (no units)
Figure 4:
Free-running MICH noise
Discussion:
1. By using the second sensor, we also eliminate the effect of the MICH servo loop locked on AS55_Q (Estimated V_d does not depend on G but only on G').
2. The free-running MICH noise is still suppressed at 1Hz. This should be coming from the effect of the UGF of the loop at ~10Hz and the vicinity to the pendulum frequency at 1Hz.
Edit/Masayuki// This noise curve is not collect, especially in low frequency region. We used the measured OLTF for compensating the free running noise, but that is not collect in low frequency region. So we should model the OLTF and fit that into the measured OLTF. We will fix this soon.
|
9120
|
Tue Sep 10 15:43:01 2013 |
Steve | Update | VAC | TP3' dry pump is replaced |
Quote: |
TP3 foreline's dry pump is getting noisier and noisier. Turbo TP3 is pumping on the annulos. The foreline pressure is 7.2 mTorr and it is not degrading. It was swapped in March 5, 2013
The seal is very good, but the bearing is dying.
|
The drypump is replaced at 95,781 hrs on TP3 controller time. The foreline pressure is 30 mTorr and dropping.
It is 13 mTorr after 17 hours of pumping. |
9119
|
Tue Sep 10 09:18:22 2013 |
Steve | Update | VAC | dry pump is getting loud |
TP3 foreline's dry pump is getting noisier and noisier. Turbo TP3 is pumping on the annulos. The foreline pressure is 7.2 mTorr and it is not degrading. It was swapped in March 5, 2013
The seal is very good, but the bearing is dying.
|
9118
|
Mon Sep 9 20:46:28 2013 |
Masayuki | Update | LSC | MICH calbration |
[Manasa, Masayuki]
We took a bunch of measurements. Transfer function and power spectrum using DTT. They will be used to obtain calibrated MICH in-loop and free-running noise. Detail Elog with plots will follow very soon. |
9117
|
Mon Sep 9 15:33:06 2013 |
Steve | Update | VAC | vertex crane repair is scheduled |
Quote: |
[Fred Goldbar, Mike Gerfen, Dennis Coyne and Steve]
We inspected the hinge, 1.25" cross pin and I-beams. It is hard to explain what is causing the folding I-beam corner to jam against the main I-beam.
To limit the motion of the folding I-beam cross pin bushing will be added. This will take a week to complete.
|
KoneCrane contact John McDaniel (562) 903 - 1371,
Wednesday, September 18, folding I-beam will be removed. KoneCrane will start working at 7:30am and they should be out by 12:30pm
Friday, September 20, reinstalling machined hinge on the I-beam. Same timing schedule as Wednesday. |
9116
|
Fri Sep 6 23:01:08 2013 |
Koji | Update | LSC | Stable DRMI lock was recovered from the impact on the RF system modification |
Summary
Stable DRMI lock was recovered. The AS110 phase was adjusted. PRCL and MICH were locked with REFL33I and REFL165Q.
Still SRCL is controlled with REFL55Q.
PRMI sensing matrix
Thursday night, Jenne and I found DRMI can not be locked at all. Also the PRMI lock with REFL55 showed change in the optical gain.
In order to investigate what is happening, the PRMI sensing matrix was measured and compared with the previous one taken in the night of 8/26.
VS
It shows that some signals are unchanged, some are partial change, and some are completely different.
My intuition saids something is wierd with the sensing matrix measurement.
Right now I can't trust these plots.
- Jenne and I have adjusted REFL55 demod angle so that REFL55Q has no PRCL. And I have confirmed with DTT that this is still true.
However, the radar chart shows that REFL55Q is almost correct phase for PRCL instead of MICH.
- REFL11 shows the same amplitude and angle as before. But POX11/POY11 shows different MICH angle.
- I have rotated REFL55 demod phase and remearsured the sensing matrix. Evrything else looked same but REFL55.
Since REFL55I&Q were not used for the control for this measurement, what we expect is to see no change of the sensing matrix and
only see the angle of "I"&"Q" rotates. But the result was different from the expectation.
DRMI locking
Since no real info was obtained from the sensing matrix, I had to make a fight without any weapon.
After sevral hours of work, stable DRMI lock was recovered.
Basically I gave larger gains to REFL55 signals: REFL55I for SRCL was 100 instead of 1, and REFL55Q for MICH was 2 instead of 0.1.
This was enough to get a second locking. Using this short sections, I have optimized the FM triggers and the gain boosts (i.e. FM1)
as well as the mirror alignment.
Then, PRM ASS was left running during the lock. This actually stabilized the lock a lot.
This made thee lock indefinite.
The demod phase of AS110I was adjusted so that AS110Q fluctuates around zero.
In this condition, the nominal AS110I was 7300 with the whitening gain of 30dB.
Note that the AS110I&Q were also measured with PRMI. With the same phase and gains, AS110I and Q were -35, -170, respectively.
Do we expect to have this phase shift? If I believe these numbers, the aplitude of 110MHz at the optimal phase is 173,
The ratio of AS110 between DRMI and PRMI is 7300/173 = 42. This corresponds to the ratio of the 110MHz sideband power at the AS port.
According to the wiki, this ratio shoud be ~160.
AS110I was in fact glitchy as you can see in the StripTool chart. I wonder this signal is suitable for the normalization or not.
=== SENSING ===
REFL11 -67deg / whitening gain 0dB
REFL33 -20deg / whitening gain 30dB
REFL55 45deg / whitening gain 6dB
REFL165 96deg / whitening gain 45dB
POP110 69deg whitening on / 15dB
POP22 102.2deg whitening on / 21dB
AS110 145deg whitening off / 30dB (seems to be related to AS11 whitening setting)
=== INPUT MATRIX ===
REFL11I x -0.125 => PRCL (REFL33I x 2.5 was also OK)
REFL55I x 100 => SRCL
REFL55Q x 2 => MICH (REFL165Q x 0.1 was also OK)
=== NORMALIZATION / TRIGGER ===
No normalization
Trigger settings
MICH POP22I UP:50 DOWN:10
PRCL POP22I UP:50 DOWN:10
SRCL POP22I UP:50 DOWN:25
=== SERVO FILTERS ===
MICH x -0.8 FM4/5 ON, no limitter
FM Trigger: delay 2sec, FM1 (modified from 6dB to 20dB), FM2, FM3
PRCL x +0.035 FM4/5 ON, no limitter
FM Trigger: delay 0.5sec, FM2/3/6
SRCL x -0.1 FM4/5 ON, no limitter
FM Trigger: delay 5sec, FM1, FM2
=== OUTPUT FILTERS ===
MICH => PRM -0.267 / BS +0.5
PRCL => PRM +1.0
SRCL => SRM +1.0
=== VIOLIN FILTER TRIGGER ===
delay 1sec: FM1/FM2/FM3/FM6
=== ASC/ASS ===
PRM ASC UP:50 DOWN:25
PITCH&YAW: FM1/9 (ALWAYS ON) + FM2/3 (turned on by the up-script)
PRM ASS left turned on for slow tracking |
Attachment 1: DRMI.png
|
|
9115
|
Fri Sep 6 09:27:10 2013 |
Steve | Update | VAC | 31 days after pumpdown |
Quote: |
Valve configuration: Vacuum Normal
|
|
Attachment 1: day31vac.png
|
|
9114
|
Thu Sep 5 21:07:09 2013 |
Jenne | Update | LSC | Started work on logic for triggering |
I want something like an "AND" for the degree of freedom triggers. Koji and I talked through an idea, and I have it running in the c1tst model, but the logic isn't working like I expect, so I need to look into it more before I can put it into the lsc model. |
9113
|
Thu Sep 5 15:18:41 2013 |
Jenne | Update | LSC | Free swinging DRMI power buildups |
I have the DRMI free swinging right now, since it's not really locking. Looking at these time series in the attached pdf, particularly around time=1.15, it would be super handy to trigger the SRCL degree of freedom on AS110 after the PRMI is triggered on POP22. |
Attachment 1: DRMI_free_swing_power_buildups.pdf
|
|
9112
|
Thu Sep 5 11:19:33 2013 |
Jenne | Update | SUS | PRM side |
Quote: |
I think the crane repair guy accidentally stepped on the BS support beam.
PRM side is not coming down.
|
Seems fine now. |
9111
|
Thu Sep 5 10:47:58 2013 |
Steve | Update | VAC | vertex crane folding issue |
[Fred Goldbar, Mike Gerfen, Dennis Coyne and Steve]
We inspected the hinge, 1.25" cross pin and I-beams. It is hard to explain what is causing the folding I-beam corner to jam against the main I-beam.
To limit the motion of the folding I-beam cross pin bushing will be added. This will take a week to complete.
|
Attachment 1: 5mmLess.jpg
|
|
9110
|
Thu Sep 5 10:28:17 2013 |
Steve | Update | SUS | PRM side |
I think the crane repair guy accidentally stepped on the BSC support beam.
PRM side is not coming down. |
Attachment 1: craneguywashere.png
|
|
9109
|
Thu Sep 5 01:55:29 2013 |
Jenne | Update | LSC | LSC model upated to have AS110 channels, violin filter triggering |
I have modified the c1lsc model so that I have access to the AS110 channels in the triggering and power normalization matrices.
I also put in a few blocks so that we can have triggering on the violin notches that we moved to the LSC model a week or so ago.
Here is my svn comment, so I don't have to retype things:
2 changes: AS110 channels added, and Violin filter triggers added.
AS110: We recently installed a new demod board and PD for an AS110 signal. Since we will not be using AS11 in the forseeable future, the AS110 demod board outputs use the former AS11 channels. I have left the AS11 channels in the model so that we can easily add them back if we want to, but they are grounded rather than connected to the ADC. I've added digital demodulation for AS110, power normalization, and then added the I&Q signals to both the trigger matrix and the main power normalization matrix. NOTE that these slide the matrix columns around. Since the AS110 is also using the former AS11 whitening channels, swapped those on the BIO block also.
Violins: Recently, Rana and I moved the SUS LSC violin filters from the individual suspension models over to the LSC model. Giving every optic every optics' violin notch helps eliminate bad cross-coupling between servo loops. Here, I have enabled triggering for these notches, so that the violin filters can come on after a cavity is locked. Since the filter banks SHOULD BE THE SAME for all LSC_SUS banks, the "mask" is common to all optics.
I also edited several medm screens, to show the new changes: the lsc overview screen has a button to the violin notch triggering screen, in addition to being able to get to the new screen from the regular triggering matrix screen. I made the trigger and normalization matrix screens bigger, since there are now 2 new columns.
I added AS110 to both the LSCoffsets script, and Masayuki's new, better, LSCoffsets2.py.
I added new lines to the .req files for the ifo configure burt restores for the new matrix columns, and the violin triggering.
I restored, checked out, and saved the Xarm, Yarm, MICH, PRM_sb, and DRM configurations.
I tried locking the DRMI, but haven't really been successful. I'm not 100% sure how to do the phasing for AS110, so that could be a problem. For POP, I can watch POPDC to see if something is a carrier or a sideband flash, but I don't have something quite as convenient at the AS port. I have set the AS110 phase to 60 degrees for now, since during free swinging DRMI flashes, it looks like most of the buildup is in the I phase with 60 degrees. Even with the same configurations as a week or so ago, I'm not getting much more than ~1 second locks.
I also tried locking the SRMI, but am not getting anything at all. I think I need to go back to simulation-land to figure out what good signals might be.
Other thoughts:
Stefan modified the LSC filter module triggering blocks, so now we have a new epics variable, "_INVERT", which sends the trigger through a NOT or not. I think that we want to keep this variable set to 0 to be the same as things were, but I do need to expose this new variable on the screens.
The trigger and normalization matrices pictured on the LSC overview screen need to be expanded by the 2 new columns. The actual matrix screens are good, but I forgot to fix up the little Kissel buttons.
When I have a free swinging SRMI, MICH and SRCL should have the same sign for the gain, if I'm using AS55 I&Q for locking.
LLO is using REFL 9I for SRCL, and ASDC for MICH for the SRMI, but I don't have any REFL beam with a misaligned PRM, so I don't think I can copy what Den and Lisa did on Monday night.
I have figured out / rediscovered why the "sqrt" buttons on the power normalization screen aren't restored when you restart the LSC model - They are controlled by momentary epics records, which go to embedded c-code to do some toggling. I don't know yet of a good way to save the configuration of these guys for burt restore-type restoration. This will be a problem for anything that is using these toggle c-codes. |
9108
|
Thu Sep 5 00:40:33 2013 |
rana | Update | SUS | MC2 tickler turned OFF |
You're right - down turns it on. Still, the fact that the same tickle recently causes a problem and didn't make 20% power fluctuations until now tells me that its not that the tickle amplitude is too large. Whatever changed recently is the problem. |
9107
|
Wed Sep 4 22:14:35 2013 |
Jenne | Update | SUS | MC2 tickler turned OFF |
Quote: |
Sounds like this was just incidental, since the MC locked fine also with the tickler enabled for weeks.
The tickle is disabled by the down script, but there's no way to correctly handle all possible button pushes. If you want to disable the autolocker for some reason you should run mcdown before trying to lock. This will set up things with the correct settings.
|
Isn't that backwards? Shouldn't the tickler be enabled by the down script, and disabled by the up script? Either way, the problem was that, after I acquired lock, the tickler was causing the transmitted power to fluctuate by ~20%, and often the MC would lose lock after a minute or so. Also, the WFS definitely couldn't be enabled by hand.
Anyhow, I'll try to keep in mind that this exists, so I'm not stymied by it again. |