ID |
Date |
Author |
Type |
Category |
Subject |
8116
|
Wed Feb 20 18:35:42 2013 |
Jenne | Update | Alignment | New in-vac alignment procedure |
I have updated the vacuum checklist for in vacuum alignment. Please take a look (https://wiki-40m.ligo.caltech.edu/vent/checklist) and see if I missed anything. My goal was to make it incredibly step-by-step so there can be no mistakes. |
8117
|
Wed Feb 20 18:53:48 2013 |
Jenne | Update | Alignment | IFO ready for doors, then pumping |
[Yuta, Manasa, Sendhil, Jenne, Steve, Jamie, Koji, Evan]
The interferometer is well-aligned, and ready for pump-down. The access connector is in place, as are the ETM heavy doors. We will do ITM and BS doors tomorrow, then begin pumping.
Before we redid the ITM pointing, I confirmed that I could see both POX and POY on their respective tables, on a camera, unclipped. I should check again quickly now that the ITM pointing has been finalized.
We went back to the arms, to perfect the ITM pointing. Input beam was already centered at ETMY. ETMY was pointing so that beam reflected to ITMY. ITMY was adjusted a few (less than 4?) steps of 1e-3 size, to make reflected beam hit center of ETMY.
BS was already pointing so beam hit center of ETMX. ETMX was pointing to hit center of ITMX. ITMX was adjusted a few (less than 4 again?) steps of 1e-3 size to make reflected beam hit center of ETMX.
Checked centering on AS path. AS beam comes out of the vacuum a little low, but this wasn't discovered until after the access connector was in place. We could adjust PZT3 (last AS mirror on BS table that sends beam over to OMC table), but we don't want to do this since we won't be able to re-confirm centering on the 3 mirrors on the OMC table.
Green beams (first Y, then X) were aligned using out-of-vac steering mirrors until beams were flashing in their respective arm cavities. Green Y is a little close to the edge of the bottom periscope mirror, on the "up" periscope. Since there is no steering between the arm and this periscope, fixing it would require moving the periscope. We leave this to the next vent, when we finally install the BS table extension. We were flashing a higher order yaw mode (5ish nodes) for the Y arm, and the very edge of the higher order mode on one side was a little bit clipped after reflecting off the steering mirror on the OMC table. This is happening because that mirror is in the mount backwards (so we have access to the knobs). We are confident that the straight-through beam is well centered on that mirror, so once we get it aligned to TEM00, there will be no clipping. We then did the X arm green, which was flashing a pitch higher order mode (again 5ish nodes). The very edge of the higher order mode is clipping a little bit on the top mirror of the "down" periscope on the IMC table, but again the straight through beam is okay, and we're confident that the TEM00 mode will make it unclipped. We could have touched some steering mirrors on the BS table, but since this was once upon a time well aligned, we don't want to futz with it.
Corner oplevs are all centered on their QPDs. (The ETM oplevs were centered a few days ago).
Access connector and ETM doors are on.
The last 3 vertex doors will go on tomorrow when Steve gets in, and then we'll start pumping.
There are no in-vac PZTs that need to be turned on (we've been using the output steering PZTs as non-energized fixed mirrors for some time), so we can lock at our leisure tomorrow afternoon. |
8118
|
Wed Feb 20 19:20:50 2013 |
Evan | Update | Alignment | AS camera alignment |
[Manasa, Evan]
Manasa and I are trying to get the AS beam onto the AS camera with a focusing lens. Currently, the mirror immediately preceding the camera has been removed and the camera and lens are sitting directly behind the BS. |
8119
|
Wed Feb 20 19:48:16 2013 |
yuta | Update | Alignment | BS table oplev re-arranged |
[Sendhil, Yuta]
After aligning IFO and putting the access connector on, we also centered IPANG/IPPOS and all oplevs (except SRM).
To avoid clipping of PRM/BS oplevs, we re-arranged oplev steering mirrors on BS table.
What we did:
1. Checked IPANG comes out unclipped after putting on the access connector.
2. Centered IPANG on its QPD.
3. Checked oplevs beams for ITMX/ITMY centered on in-vac mirrors, and centered them on their QPDs.
4. Checked IPPOS beam is centered on the mirrors inside BS chamber, and centered IPPOS on its QPD.
5. Tweaked oplev mirrors on BS chamber to make PRM/BS oplev beam unclipped and centered on mirrors, and centered them on their QPDs. To avoid clipping of oplev beams in BS table, we re-arranged oplev steering mirrors on BS table (outside the vaccum).
Current status:
QPD values, IFO_ALIGN/MC_ALIGN screens, OSEM values attached.
- IR incident beam and IFO aligned
- X/Y end green coming out to PSL table (in higher order modes)
- IPANG/IPPOS available
- All oplevs available
- AS/REFL/POP cameras ready
- access connector, ETMX/ETMY heavy doors on
- ITMX/ITMX/BS heavy doors are not on
- AS/REFL/POP PDs not centered
- POX/POY/TRX/TRY not aligned
- AS beam coming out of the OMC chamber low by ~ 1 beam diameter (my bad)
Tomorrow:
- Align AS/REFL/POP PD and lock PRMI
- Take pictures of ITMX/ITMY/BS stacks
- Put heavy doors on ITMX/ITMY/BS chambers
- Start pumping down |
Attachment 1: IFOALIGN_QPDs_OSEMs.png
|
|
8120
|
Wed Feb 20 19:58:59 2013 |
rana | Update | Alignment | BS table oplev re-arranged |
Please confirm the SRM OL beam is not too bad and also find where the mis-aligned SRM puts its beam. WE want to be sure that there is not too much unwanted scattering from SRM into the PRFPMI. |
8121
|
Wed Feb 20 20:15:29 2013 |
yuta | Update | Alignment | SRM oplev status |
Currently, SRM is misaligned in pitch so that SRM reflected beam hits on the top edge of SR3 (not on the mirror, but on the cage holding the mirror).
We also confirmed that SRM oplev beam is coming out from the chamber unclipped, and centered on QPD when SRM is "aligned". |
8122
|
Wed Feb 20 20:58:37 2013 |
yuta | Update | Alignment | clipping centering checklist |
Blue ones are the ones we checked yesterday.
Green ones are the ones we checked today.
Red ones are the ones we couldn't check.
We noticed mis-centering on green optics and partial clipping of higher order modes, but we did not touch any green optics in-vac. This is because green beam from Y end and X end has different spot positions on the green optics after periscopes. We confirmed that direct green beam from ends are not clipped.
I believe we have checked everything important. Any other concerns?
|
Attachment 1: ClippingCenteringChecklist.pdf
|
|
8123
|
Wed Feb 20 21:12:37 2013 |
rana | Update | Alignment | clipping centering checklist |
Is the beam going towards the OMC going to cause backscatter because of uncontrolled OMC or can we park that beam somewhere dark? |
8124
|
Wed Feb 20 21:56:08 2013 |
yuta | Update | Alignment | clipping centering checklist |
I'm not sure about the OMC situation at 40m. I think there are no direct beam reflected back into IFO from OMC path. There must be some backscatter, but we have to open OMC chamber again to put a beam dump.
I don't think we want to put one in OMC path for this pump-down, but we can put a beam dump to dump reflected beam from mis-aligned SRM tomorrow, if available. |
8126
|
Thu Feb 21 12:56:38 2013 |
Jenne | Update | CDS | c1iscex dead again |
c1iscex is dead again. Red lights, no "breathing" on the FE status screen. |
8127
|
Thu Feb 21 13:34:35 2013 |
Jenne | Update | Treasure | IR card removed |
Quote: |
The sensor card on the bottom of the chamber was not salvaged yet.
|
Yuta retrieved the IR card that had fallen to the bottom of the IOO chamber, just before we put on the access connector yesterday. The clean "pickle picker" long grabber tool worked wonders. |
8128
|
Thu Feb 21 14:32:02 2013 |
Jamie | Update | CDS | c1iscex models restarted |
Quote: |
c1iscex is dead again. Red lights, no "breathing" on the FE status screen.
|
The c1iscex machine itself wasn't dead, the models were just not running. Here are the last messages in dmesg:
[130432.926002] c1spx: ADC TIMEOUT 0 7060 20 7124
[130432.926002] c1scx: ADC TIMEOUT 0 7060 20 7124
[130433.941008] c1x01: timeout 0 1000000
[130433.941008] c1x01: exiting from fe_code()
I'm guessing maybe the timing signal was lost, so the ADC stopped clocking. Since the ADC clock is the everything clock, all the "fe" code (ie. models) aborted. Not sure what would have caused it.
I restarted all the models ("rtcds restart all") and everything came up fine. Obviously we should keep our eyes on things, and note if anything strange was happening if this happens again. |
8129
|
Thu Feb 21 15:21:07 2013 |
yuta | Update | VAC | all heavy doors on, started pumping down annulus |
[Steve, Manasa, Jenne, Sendhil, Evan, Yuta]
We put heavy doors on ITMX/ITMY/BS chamber and started pumping down from annulus.
What we did:
1. Replaced POP55 with AS55 back, because it was not broken.
2. Centered on AS55, REFL55, REFL11, POPDC PD.
3. Tried to lock PRMI, but I couldn't lock even MI stably for more than 1 min. I believe this is because it was noisy this morning. But I checked again that REFL/POP/AS beams are coming out without clipping and we have some error signals.
4. Noticed AS beam has less range in left (on AS camera), so we tweaked OM4 a little to make more room.
6. Took pictures inside ITMX and BS chambers
7. Put heavy doors on ITMX/ITMY/BS chambers.
8. Started pumping down annulus.
9. Recentered IPANG/IPPOS and oplevs on their QPDs.
POP, REFL, AS:
|
8130
|
Thu Feb 21 16:53:37 2013 |
Manasa | Update | PSL | PSL shutter |
[Steve, Jenne, Yuta, Manasa]
We have kept the laser ON at low power through the pump down process. As we pumped down, at around 400torr, we found that the PSL mech shutter closed. Steve explained that it was due to an interlock with a pressure gauge. To keep the IFO running, we switched the shutter from N.C (normally close) to N.O (normally open). This should be undone after the pumpdown.
In the process of figuring out, we reset the shutter and switched it ON and OFF a couple of times. |
8131
|
Thu Feb 21 18:01:27 2013 |
Steve | Update | VAC | pumpdown at 230 Torr |
We are pumping down with RP1 & RP3 oily roughing pumps at 3 Torr/min speed. The butterfly valve was just removed.
The PSL shutter is open to vacuum at ~100 mW 1064 nm. The inter lock should close it at ~5 mTorr.
Rana will shut down pumping tonight.
He will close V3 from screen, close RV1 valve with torque wheel, turn off roughing pumps and disconnect hose between RV1 and roughing pumps.
I will restart pumping early morning tomorrow.
|
8132
|
Thu Feb 21 18:10:13 2013 |
rana | Update | SEI | Pump Down misalignments |
This plot shows the trend of the OL during the past several hours of roughing pumping.
The big steps at the start of the pump down is NOT due to the pumping, but is instead the "recentering" that Yuta did. Looks like he was unable to find zero on the ETMY.
Some of the rest of the drift is probably just the usual diurnal variation, but there does seem to be some relation to the pumping trend. I guess that the shift of ~0.3 in the ITMX and ITMY pitch is real and pressure related.
We need to figure out how to put the OL calibration factor into the SUS-OL screens.
|
Attachment 1: OL.png
|
|
8133
|
Thu Feb 21 19:55:02 2013 |
Manasa | Update | Locking | Green locking in arms |
[Yuta, Manasa]
We have aligned the Y-arm to lock in green. The green beams at the PSL table were clipping at the attenuation optics we installed for the vent (HWP-PBS-HWP). We had to move the polarization changing wave plate to get the green beam on the steering mirror. We installed the GRNT camera on the PSL table and aligned the arms to get TEM00 flashing. Green TRX PD was then installed and the trans power was brought to a maximum of 210uW.
We will use this to align the IR to the arm when we are back in full power tomorrow. |
Attachment 1: ETMYF_1045540570.png
|
|
8134
|
Thu Feb 21 21:12:42 2013 |
Koji | Update | VAC | pumpdown at 230 Torr |
[Rana, Yuta, Koji]
21:05 at the pressure of 10torr
V3 closed. RV1 manually closed. RPs were turned off. And the bellows between RV1 and the rughing pumps are disconnected. |
8135
|
Fri Feb 22 08:01:25 2013 |
Steve | Update | VAC | pumpdown continuous |
Pump down is restarted after 10.5 hrs stop overnight. |
Attachment 1: 16hrs_pd75.png
|
|
8136
|
Fri Feb 22 11:12:16 2013 |
Steve | Update | VAC | pumpdown completed |
IFO P1 pressure is 1 mTorr. It is ready for high power light.
The Maglev took over the pumping at 500 mTorr
|
Attachment 1: mag60min.png
|
|
Attachment 2: pd75at20h.png
|
|
8137
|
Fri Feb 22 13:03:49 2013 |
Manasa | Update | | MC REFL PD murder |
[Yuta, Manasa]
We turned IFO power back to 1.25W by removing the attenuator and forgot that the Y1 mirror before the REFL PD must be replaced with BS 10% before getting to full power. The PD is dead and now we are in the process of fixing it. Forgive us for all our sins!
On the other note, we have changed the mech shutter mode from N.O back to N.C. So the shutter now works as usual from the medm screen.

|
8138
|
Fri Feb 22 17:33:25 2013 |
Manasa | Update | Electronics | MC REFL PD back from the dead |
[Yuta, Manasa]
We replaced the dead photodiode on MC REFL PD with a new one (GAP 2000). We measured the frequency response of the PD and tuned the resonant frequency using inductor L5 (in the circuit diagram) to be 29.575MHz - over an average of 10 measurements.
Riju is measuring the characteristics of the PD and will be posting an elog in detail. |
8139
|
Fri Feb 22 17:33:38 2013 |
Chloe | Update | | QPD circuit diagram |
Today I tested the circuitry within the QPD to make sure I had put it back together correctly. The output was able to detect when a laser pointer was shone on different quadrants of the QPD when hooked up to the oscilloscope, so fixing the QPD worked!
Following this, I spent awhile understanding what was going on with the circuit reading from the QPD. I concluded that the opamp on the QPD circuit acted as a low pass filter, with corner frequency of about 17 kHz, which serves our purposes (we are only interested in frequencies below 1 kHz). I diagrammed the circuit that I plan to build to give pitch and yaw (attached). It will be necessary to make small modifications to the circuitry already built (removing some resistors), which I have started on.
Next time, I will construct the circuit that adds/subtracts signals on a breadboard and test it with the QPD circuit that is already built. |
Attachment 1: IMG_0377.JPG
|
|
8140
|
Fri Feb 22 20:28:17 2013 |
Jamie | Update | Computers | linux1 dead, then undead |
At around 2:30pm today something brought down most of the martian network. All control room workstations, nodus, etc. were unresponsive. After poking around for a bit I finally figured it had to be linux1, which serves the NFS filesystem for all the important CDS stuff. linux1 was indeed completely unresponsive.
Looking closer I noticed that the Fibrenetix FX-606-U4 SCSI hardware RAID device connected to linux1 (see #1901), which holds cds network filesystem, was showing "IDE Channel #4 Error Reading" on it's little LCD display. I assumed this was the cause of the linux1 crash.
I hard shutdown linux1, and powered off the Fibrenetix device. I pulled the disk from slot 4 and replaced it with one of the spares we had in the control room cabinets. I powered the device back up and it beeped for a while. Unfortunately the device was requiring a password to access it from the front panel, and I could find no manual for the device in the lab, nor does the manufacturer offer the manual on it's web site.
Eventually I was able to get linux1 fully rebooted (after some fscks) and it seemed to mount the hardware RAID (as /dev/sdc1) fine. The brought the NFS back. I had to reboot nodus to get it recovered, but all the control room and front-end linux machines seemed to recover on their own (although the front-ends did need an mxstream restart).
The remaining problem is that the linux1 hardware RAID device is still currently unaccessible, and it's not clear to me that it's actually synced the new disk that I put in it. In other words I have very little confidence that we actually have an operational RAID for /opt/rtcds. I've contacted the LDAS guys (ie. Dan Kozak) who are managing the 40m backup to confirm that the backup is legit. In the mean time I'm going to spec out some replacement disks onto which to copy /opt/rtcds, and also so that we can get rid of this old SCSI RAID thing. |
Attachment 1: FX-606-U4_1205.pdf
|
|
8141
|
Sat Feb 23 00:34:28 2013 |
yuta | Update | Computers | crontab in op340m deleted and restored (maybe) |
I accidentally overwrote crontab in op340m with an empty file.
By checking /var/cron in op340m, I think I restored it.
But somehow, autolockMCmain40m does not work in cron job, so it is currently running by nohup.
What I did:
1. I ssh-ed op340m to edit crontab to change MC autolocker to usual power mode. I used "crontab -e", but it did not show anything. I exited emacs and op340m.
2. Rana found that the file size of crontab went 0 when I did "crontab -e".
3. I found my elog #6899 and added one line to crontab
55 * * * * /opt/rtcds/caltech/c1/scripts/general/scripto_cron /opt/rtcds/caltech/c1/scripts/MC/autolockMCmain40m >/cvs/cds/caltech/logs/scripts/mclock.cronlog 2>&1
4. It didn't run correctly, so Rana used his hidden power "nohup" to run autolockMCmain40m in background.
5. Koji's hidden magic "/var/cron/log" gave me inspiration about what was in crontab. So, I made a new crontab in op340m like this;
34 * * * * /opt/rtcds/caltech/c1/scripts/general/scripto_cron /opt/rtcds/caltech/c1/scripts/MC/autolockMCmain40m >/cvs/cds/caltech/logs/scripts/mclock.cronlog 2>&1
55 * * * * /opt/rtcds/caltech/c1/scripts/general/scripto_cron /opt/rtcds/caltech/c1/scripts/PSL/FSS/RCthermalPID.pl >/cvs/cds/caltech/logs/scripts/RCthermalPID.cronlog 2>&1
07 * * * * /opt/rtcds/caltech/c1/scripts/general/scripto_cron /opt/rtcds/caltech/c1/scripts/PSL/FSS/FSSSlowServo >/cvs/cds/caltech/logs/scripts/FSSslow.cronlog 2>&1
00 * * * * /opt/rtcds/caltech/c1/burt/autoburt/burt.cron >> /opt/rtcds/caltech/c1/burt/burtcron.log
13 * * * * /cvs/cds/caltech/conlog/bin/check_conlogger_and_restart_if_dead
14,44 * * * * /opt/rtcds/caltech/c1/scripts/SUS/rampdown.pl > /dev/null 2>&1
6. It looks like some of them started running, but I haven't checked if they are working or not. We need to look into them.
Moral of the story:
crontab needs backup. |
8143
|
Sat Feb 23 07:14:58 2013 |
yuta | Update | LSC | can't lock Y arm |
I tried to align and lock Y arm for the first time after pumping.
But I couldn't lock Y arm for more than ~1 sec. Why?
What I did:
1. Centered IPANG/IPPOS using input TT1/TT2.
2. Restored ITMY/ETMY slider values when it was aligned before pumping. I saw tiny flashes in TRY PD at this point.
3. Replaced Ygreen REFL camera with ETMYT camera to see transmitted beam mode.
4. Used TT1/TT2 and ITMY/ETMY to get ~ 0.4 peak in normalized TRY PD output (C1:LSC_TRY_OUT).
5. Centered POY beam on POY11 PD.
6. Changed I/Q mixing angle (C1:LSC-POY11_PHASE_R) from -61 deg to -16 deg to get good PDH signal in I_ERR (attached).
7. Ran LSCoffsets script (now on LSC_OVERVIEW screen) to adjust PD offsets.
8. Tried to lock Yarm with different gains, but failed. When lock is acquired, TRY fluctuates ~50 % and unlocks suddenly.
What I found:
1. There was some OFFSETs left turned on in suspension screens. Don't leave them on!! They change alignment of the optics. I will leave it on until we complete Yarm alignment.
2. C1:SUS-(ITMY|ETMY)_ASC(PIT|YAW) was kept oscillating the optic since Dec 17, 2013. I think this is from interrupted ASS script. Your script should restore everything when interrupted!
Next:
- Beamspot on ITMY looks off-centered. Maybe A2L is causing unstable lock?
- Maybe F2A is causing unstable lock?
- More alignment?
- FSS related? crontab related? |
Attachment 1: TRYPOY.png
|
|
8144
|
Sat Feb 23 14:04:07 2013 |
Koji | Update | Computers | apache retarted (Re: linux1 dead, then undead) |
apache has been restarted.
How to: search "apache" on the 40m wiki
Quote: |
I had to reboot nodus to get it recovered
|
|
8145
|
Sat Feb 23 14:52:03 2013 |
Jenne | Update | LSC | ETMYT camera back to normal |
Quote: |
3. Replaced Ygreen REFL camera with ETMYT camera to see transmitted beam mode.
|
The camera that Yuta means in his elog from last night/this morning is the scattering camera at the Yend. The reason (I think) that he had to do this is that Manasa and Jan took the cable for the ETMYT camera, and were using it for their scattering camera. They mention in elog 8072 that they installed a camera, but they didn't say anything about having taken the ETMYT cable. This is the kind of thing that is useful to elog!
Anyhow, I have removed the Watec that belongs with the scattering setup, that Yuta borrowed, and put it back on the scattering table-on-a-pedestal. I then realigned the usual ETMYT camera (that Yuta moved out of the way to install the borrowed Watec), and put the ETMYT cable back to its usual place, connected to the Sony camera's box on the floor.
tl;dr: ETMYT camera is back to original state.
EDIT later: I put the Watec back, since it is more sensitive to IR, so now we have a Watec in the regular ETMYT place. |
8146
|
Sat Feb 23 15:26:26 2013 |
yuta | Update | Computers | crontab in op340m updated |
I found some daily cron jobs for op340m I missed last night. Also, I edited timings of hourly jobs to maintain consistency with the past. Some of them looks old, but I will leave as it is for now.
At least, burt, FSSSlowServo and autolockMCmain40m seems like they are working now.
If you notice something is missing, please add it to crontab.
07 * * * * /opt/rtcds/caltech/c1/burt/autoburt/burt.cron >> /opt/rtcds/caltech/c1/burt/burtcron.log
13 * * * * /opt/rtcds/caltech/c1/scripts/general/scripto_cron /opt/rtcds/caltech/c1/scripts/PSL/FSS/FSSSlowServo >/cvs/cds/caltech/logs/scripts/FSSslow.cronlog 2>&1
14,44 * * * * /cvs/cds/caltech/conlog/bin/check_conlogger_and_restart_if_dead
15,45 * * * * /opt/rtcds/caltech/c1/scripts/SUS/rampdown.pl > /dev/null 2>&1
55 * * * * /opt/rtcds/caltech/c1/scripts/general/scripto_cron /opt/rtcds/caltech/c1/scripts/MC/autolockMCmain40m >/cvs/cds/caltech/logs/scripts/mclock.cronlog 2>&1
59 * * * * /opt/rtcds/caltech/c1/scripts/general/scripto_cron /opt/rtcds/caltech/c1/scripts/PSL/FSS/RCthermalPID.pl >/cvs/cds/caltech/logs/scripts/RCthermalPID.cronlog 2>&1
00 0 * * * /var/scripts/ntp.sh > /dev/null 2>&1
00 4 * * * /opt/rtcds/caltech/c1/scripts/RGA/RGAlogger.cron >> /cvs/cds/caltech/users/rward/RGA/RGAcron.out 2>&1
00 6 * * * /cvs/cds/scripts/backupScripts.pl
00 7 * * * /opt/rtcds/caltech/c1/scripts/AutoUpdate/update_conlog.cron |
8147
|
Sat Feb 23 15:46:16 2013 |
rana | Update | Computers | crontab in op340m updated |
According to Google, you can add a line in the crontab to backup the crontab by having the cronback.py script be in the scripts/ directory. It needs to save multiple copies, or else when someone makes the file size zero it will just write a zero size file onto the old backup. |
8148
|
Sat Feb 23 16:16:11 2013 |
Max Horton | Update | Summary Pages | Multiprocessing |
Calendars: The calendar issue discussed previously (http://nodus.ligo.caltech.edu:8080/40m/8098) where the numbers are squished together is very difficult for me to find. I am not going to worry about it for the time being.
Multiprocessing: Reviewed the implementation of Multiprocessing in python (using Multiprocessing package). Wrote a simple test function and ran it on megatron, to verify that multiprocessing could successfully take advantage of megatron’s multiple cores – it could. Now, I will work on implementing multiprocessing in the program. I began testing at a section in the program where a for loop calls process_data() (which has a long runtime) multiple times. The megatron terminals I had open began to run very slowly. Why? I believe that the process_data() function loads data into global variables to accomplish its task. The global variables in the original implementation were cleared before the subsequent calls to process_data(). But in the multiprocessing version, the data is not cleared, meaning the memory fills quickly, which drastically reduces performance. In the short term, I could try generating fewer processes at a time, wait for them to finish, then clearing the data, then generating more processes, etc. This will probably generate a nominal performance boost. In the long-term, restructuring of the way the program handles data may help (but not for sure). In the coming week I will experiment with these techniques and try to decrease the run time of the program. |
8149
|
Sat Feb 23 16:54:24 2013 |
Jenne | Update | LSC | can't lock Y arm |
I'm not sure that Yuta had found the real Yarm flashes last night. When I came in today, the Yarm would flash. However I found that the SRM was aligned, and if I misaligned it, the Yarm flashes would disappear. So somehow the beam getting into the cavity was related to the reflection off of the SRM.
Later, I moved the TTs, leaving ITMY and ETMY alone, after having misaligned SRM (and ITMX) and I found flashes. This wasn't ideal though, since the beam was much, much too high on IPANG (beam was half falling off the top of the lens, although yaw was pretty good). That was also when I changed out the ETMYT camera the first time around. The flashes on the new camera were visible, but much dimmer than with the Watec.
I tried locking the Yarm in this state, but I could never achieve a lock, even momentarily. It almost seemed like I wasn't sending actuation signal out to the coils, although signal appeared all the way through the chain until the LSC signal summed with the local damping signal. I also switched the LSC output matrix to try actuating on the ITM, but I was also not able to lock then. I have switched it back to have Yarm actuate on ETMY. I could see a nice PDH signal on POY, and nice flashes on TRY, but no lock at all. The trigger was triggering, but still no catching of the lock. I'm not really sure what's up.
After playing with a non-locking, poorly aligned Yarm, I started over by recentering the beam on IPPOS and IPANG using the TTs, but have not been able to get flashing in the cavity again. After much fitzing around, I put the Watec back at ETMYT, in hopes that we can see flashes again at some point, since it's more sensitive than the old Sony. Still no flashes though.
I have to leave, but Yuta and Manasa are here, and so I'm leaving the IFO in their custody. |
8150
|
Sat Feb 23 17:14:59 2013 |
yuta | Update | LSC | can't lock Y arm |
Jenne found that;
0. If all mirrors are "aligned," Yarm flashes.
1. If SRM is misaligned, Yarm doesn't flash.
2. If BS is misaligned, Yarm doesn't flash.
3. If ITMX is misaligned, Yarm still flashes.
So, my hypothesis from this is that I was playing with " TT1 -> TT2 -> ITMY -> BS -> SRM -> BS -> Yarm " configuration last night.
This hypothesis can explain;
1. Why I could not get TRY peak more than 0.5 (additional BS reflection makes incident power to Yarm less).
2. Why I had to change POY11 I/Q mixing angle by ~ 45 deg (because EOM to Yarm length changed).
3. Why I couldn't lock Yarm stably (additional reflection by BS and SRM made too much beam jitter?).
We are now trying to get "real" Yarm flash. |
8152
|
Sun Feb 24 00:14:28 2013 |
Manasa | Update | SUS | SUS Summary |
I tried to fix the alarms for sensors on the SUS summary screen. I checked earlier elogs and found the setSensors.py script.
I received errors while running the script and pianosa was refused connection to nds. Yuta suspects problems with the lib directory.
Jamie! Can you fix this? |
8154
|
Sun Feb 24 17:54:34 2013 |
rana | Update | SUS | SUS Summary |
I asked John Z to talk with Jamie and then install a new NDS2 server software for us. Jamie may know if this happened or was foiled by the linux1 RAID failure.
In any case, our pyNDS stuff ought to be able to talk to NDS2 or our old NDS1 stuff, I hope. |
8155
|
Mon Feb 25 08:22:03 2013 |
Steve | Update | VAC | pumpdown at day 4 |
All normal, IFO pressure 1.5e-5 Torr
RGA is pumped by TP-3 in back ground mode.
|
Attachment 1: 4d.png
|
|
Attachment 2: 66d@atm.png
|
|
8157
|
Mon Feb 25 15:30:29 2013 |
yuta | Update | Alignment | Y arm locked, both colors |
[Koji, Yuta]
We aligned Y arm to Y green and tweaked TT1/TT2 to get IR locked in Y arm.
Alignment procedure:
1. Align ETMY/ITMY to maximize TEM00 green transmission to PSL table. We reached ~240 uW.
2. Aligned PRM and TT2 so that PRM reflected beam go through FI and get ITMY-PRM cavity flashing. This is to coarsely align input pointing to Y arm. After this alignment, we got tiny Y arm flash. Input pointing to IPANG QPD was lost.
3. Aligned TT1/TT2 to maximize TRY in TEM00. We reached ~0.92.
Failed procedure:
I was struggling with finding Y arm flash. I was using IPPOS/IPANG as input pointing reference, and slider values (C1:SUS-(ITMY|ETMY)_(PIT|YAW)_COMM) or OSEM values (C1:SUS-(ITMY|ETMY)_SUS(PIT|YAW)_IN1) before pumping for Y arm alignment reference. But it was a lot more easier if Y arm is aligned to green and having Yarm cavity axis assured.
Next:
- X arm flash in IR
- Steer X end green
- If X arm or AS looks bad, adjust IR input pointing and Y arm alignment. We have to steer Y end green afterwards. |
8158
|
Mon Feb 25 17:58:28 2013 |
rana | Update | Alignment | Y arm locked, both colors |
That's good news. I was ready to give up and say we should vent and remove the baffles. It will be interesting if you can find out how much the sensors and OL and IPANG are off from their pre-pump values. We should think about how to have better references.
Also, what is the story with the large drift we are seeing in IPANG? |
8159
|
Mon Feb 25 20:04:22 2013 |
Jamie | Update | SUS | suspension controller model modifications in prep for global damping initiative |
[Jamie, Brett, Jenne]
We made some small modifications to the sus_single_control suspension controller library part to get in/out the signals that Brett needs for his "global damping" work. We brought out the POS signal before the SUSPOS DOF filter, and we added a new GLOBPOS input to accommodate the global damping control signals. We added a new EPIC input to control a switch between local and global damping. It's all best seen from this detail from the model:

The POSOUT goto goes to an additional output. As you can see I did a bunch of cleanup to the spaghetti in this part of the model as well.
As the part has a new input and output now we had to modify c1sus, c1scx, c1scy, and c1mcs models as well. I did a bunch of cleanup in those models as well. The models have all been compiled and installed, but a restart is still needed. I'll do this first thing tomorrow morning.
All changes were committed to the userapps SVN, like they should always be. 
We still need to update the SUS MEDM screens to display these new signals, and add switches for the local/global switch. I'll do this tomorrow.
During the cleanup I found multiple broken links to the sus_single_control library part. This is not good. I assume that most of them were accidental, but we need to be careful when modifying things. If we break those links we could think we're updating controller models when in fact we're not.
The one exception I found was that the MC2 controller link was clearly broken on purpose, as the MC2 controller has additional stuff added to it ("STATE_ESTIMATE"):

I can find no elog that mentions the words "STATE" and "ESTIMATE". This is obviously very problematic. I'm assuming Den made these modifications, and I found this report: 7497, which mentions something about "state estimation" and MC2. I can't find any other record of these changes, or that the MC2 controller was broken from the library. This is complete mickey mouse bullshit. Shame shame shame. Don't ever make changes like this and not log it.
I'm going to let this sit for a day, but tomorrow I'm going to remove replace the MC2 controller with a proper link to the sus_single_control library part. This work was never logged so it didn't happen as far as I'm concerned.
|
8160
|
Mon Feb 25 20:25:33 2013 |
Brett | Update | SUS | New Global Damping MEDM Screens |
Global damping screens are in progress for the new global damping infrastructure Jamie discussed in log #8159. The main overview screen is /opt/rtcds/caltech/c1/medm/c1sus/master/C1SUS_GLOBAL.adl. The overview screen links to a few sub-screens in the same directory called C1SUS_GLOBAL_DAMPFILTERS.adl, C1SUS_GLOBAL_GLOBALTOLOCAL.adl, and C1SUS_GLOBAL_LOCALTOGLOBAL.adl.
This global damping is in intended to damp the 4 test masses along global interferometer degrees of freedom that are orthogonal to the cavity signals. Ideally the result will be that OSEM sensor noise from the damping loops is invisible to the cavity signals. Mismatches in the suspensions' dynamics and gains will cause some noise to leak through anyway, but we should be able to tune some of this out by carefully scaling the drives to each suspension. |
8161
|
Mon Feb 25 20:49:07 2013 |
Brett | Update | SUS | Minor Mod made to SUS_GLOBAL block |
I made a minor modification to install some output filters in the new global damping GLOBAL box in c1sus.mdl. These will be needed for tuning the suspension drives to compensate for mismatches in the pendulums.
I recompiled and installed the model, but did not start it. Basically same as Jamie left it in 8159. Interestingly, I did not see the new POSOUT that was put in before the SUSPOS DOF filter. I made sure to reopen the .mdl file fresh before making more mods, but for some reason I do not see that update... |
8162
|
Mon Feb 25 21:25:14 2013 |
yuta | Update | Alignment | both arms locked in IR |
[Jenne, Evan, Yuta]
After Y alignment, X arm is aligned to IR and we got both arms locked in IR.
There's some dift (input pointing?) and this made aligning both arms tough. I will elog about it later.
Attached is ETMYF. ETMXF, ITMYF, ITMXF when both arms are locked by IR.
Alignment Procedure:
1. Algined BS/ITMX to get MI fringe in AS. We got X arm flashing at this point.
2. Use BS/ITMX/ETMX to get TRX maximized, without losing good MI fringe in AS. We reached 0.75.
3. There was clipping of TRX beam at Xend optics. Since whole IFO alignment is started from Y green, this clipping is because of poor Y green pointing. But we needed clear TRX for aligning Xarm, so we re-arranged Xend TRX path to avoid clipping.
X arm issues:
- Beam motion at TRX is larger than TRY. Turning off clean table air didn't help. Maybe we need BS oplev on or ETMX coil gain balancing.
- X green scatters into TRX PD and ETMXT camera. Fix them. |
Attachment 1: QUAD1_1045890588.png
|
|
8165
|
Tue Feb 26 01:49:27 2013 |
Jenne | Update | Locking | PRMI locked |
[Jenne, Yuta]
We began the evening, after alignment of all optics was good (arms flashing, PRC flashing, assumed SRM last saved alignment was okay), centering all oplevs and aligning beam onto AS55, REFL11, REFL55 and REFL33 and POPDC.
After a quick check to make sure that the input pointing was still okay for Yarm (TRY was 0.88 when we began PRMI work, which we called okay), we aligned and locked the Michelson with AS55Q. We were able to use a gain as large (abs val) as -15 before the loop started oscillating. (ETMs, PRM, SRM all misaligned during this). We measured the UGF of the MICH loop to be 170Hz, with phase margin of 40 degrees.
We then restored the PRM, and tweaked the pointing until the PRC beam at AS overlapped the MICH beam.
We then started playing with locking. We were not very successful in using REFL 11 or REFL 55 (I for both, although we also tried 11Q just for kicks). We then switched to using REFL33I, and had success!! We are reliably able to lock to the "sideband", and not so reliably lock to the carrier (by flipping the sign of the PRCL loop gain). I say "sideband" with quotes, since we aren't sure that it is the sideband. We are, however, confident that it is locking, and it's certainly not locked to the carrier. Videos are at the bottom of the entry.
A list of some values:
Camera state |
MICH gain |
PRCL gain |
POP DC |
AS DC |
REFL DC |
AS bright, POP bright |
-0.045 |
-4.000 |
1000 +/- 200 |
4 +/- 0.5 |
480 |
AS dark, POP bright |
-0.045 |
+4.000 |
300 +/- 20 |
0.03 +/- 0.02 |
552 +/- 2 |
AS, POP flashing |
loop off |
loop off |
flash 25,000 or more |
~5 |
~550 |
Other notes: We changed AS55's demod phase back to 24.5, from it's atmosphere half-cavity value. The change from the original value was recorded in elog 8030.
We changed REFL11's demod phase back to 150, which is the value that it was when we had PRMI locked on ~July 10th, 2012. (We looked up the burt snapshot to check).
FI back, upper right is POP, lower left is REFL, lower right is AS. It seems as though we may need to redo coil balancing now that we're at vacuum / with the current OSEM values. |
8166
|
Tue Feb 26 02:04:51 2013 |
Koji | Update | Locking | PRMI locked |
One of the biggest issues we had was that any Q signals (i.e. the quadrature where PRCL is absent.) of REFL11/33/55/(165) haven't been consistent each other.
i.e. We never had reliable lock of MICH with REFL_any_Q, regardless of the resonant condition. This is definitely one of the things to be tried in order to prepare for the full lock.
We don't trust any demodulation phases of any PDs any more as the previous PRC mode (or say, absence of the stable mode) was unreasonable to determine any of the demodulation phases.
I remember that the POP DC saturates at 27000. You may need to reduce the gain switch again.
The AS OSA and/or POP BBPD would be useful for the sideband PR gain estimation. |
8167
|
Tue Feb 26 09:55:46 2013 |
Steve | Update | SAFETY | Evan receives safety training |
Evan got 40m specific safety training today. |
8168
|
Tue Feb 26 10:17:44 2013 |
Jamie | Update | SUS | removed global/local switch from sus_single_control |
[jamie, brett]
Yesterday we added some new control logic to the sus_single_control part to allow for global damping. Today we decided that a binary switch between local/global damping was probably a bit extreme since we might want to smoothly ramp between them, instead of just hard switching. So we removed this switch and are now just summing the control inputs from global and local damping right before the output matrix.
Changes were committed to the SVN, and all suspension models were recompiled/installed/restarted.
|
8169
|
Tue Feb 26 10:20:31 2013 |
Jamie | Update | SUS | MC2 suspension controller reverted to library part |
I made good on my threat from yesterday to convert the MC2 suspension controller to the library part. Whatever changes were in MC2 were thrown out, although they are archived in the SVN. Again, this kind of undocumented breaking is forbidden.
Change was committed to SVN, and c1mcs was recompiled/installed/restarted. |
8170
|
Tue Feb 26 11:55:11 2013 |
Manasa | Update | Locking | FPMI locked |
[Yuta, Manasa]
FPMI locked.
Alignment and lock acquisition
1. Use ITMY/ETMY to maximize green transmission in Y arm (to get closer to arm alignment).
2. Use TT1/TT2 to align arms to IR to the Y-arm (Maximum TRY = 0.84)
3. Use BS/ITMX/ETMX to align IR to the X-arm.
4. Use POY11_I and POX11_I to lock Yarm and Xarm.
5. Use ASDC to lock MI.
Modified
1. X-arm trans camera settings changed.
2. Blocked stray green from reaching TRX PD and camera.
P.S. TRX seems to be moving less on the camera because of the oplevs centered and working from last night.
Plan
Lock green to X arm.
|
8171
|
Tue Feb 26 15:32:47 2013 |
Jenne | Update | Locking | FPMI locked |
Quote: |
P.S. TRX seems to be moving less on the camera because of the oplevs centered and working from last night.
|
Ah, yes. I forgot to mention in my elog last night that Yuta and I found that the ITMX oplev servo had been on, even though the oplev beam was blocked, so ITMX was noisier than it should have been. |
8172
|
Tue Feb 26 16:13:18 2013 |
Brett | Update | SUS | ITMY and ETMY mysterious loop gain difference of 2.5 |
While doing initial measurements for the new global damping infrastructure I discovered that the ETMY loop between the OSEM actuation and the OSEM sensors has a gain that is 2.5 times greater than the ITMY. The result is that to get the same damping on both, the damping gain on the ETMY must be 2.5 times less than the ITMY. I do not know where this is coming from, but I could not find any obvious differences between the MEDM matrices and gains.
I uploaded a screenshot of measured transfer functions of the damped ITMY and ETMY sus's. Notice that the ETMY measurement is 2.5 times higher than the ITMY. The peak also has a lower Q, despite having the same damping filters running because of this mysterious gain difference. Lowering the damping gain of the ETMY loop by this 2.5 factor results in similar Q's. |
Attachment 1: Screenshot.png
|
|