40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 216 of 339  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  9515   Thu Jan 2 13:35:06 2014 KojiUpdateVAC vacuum monitor is still blank

We probably need to restart the machine, but I didn't want to touch c1vac1 and c1vac2. 

  9521   Mon Jan 6 18:32:17 2014 RANAUpdateIOOMC1/3 kicked this morning at 8:30

 The trend shows a big jolt to the MC1/3 pointing this morning at 8:30.

Was anyone working anywhere near there today? There is no elog.

If not, we will have to put a 'no janitor' sign on all of the 40m doors permanently to prevent mops misaligning our interferometer.

Attachment 1: kicked.png
kicked.png
  9522   Mon Jan 6 20:52:09 2014 JenneUpdateIOOMC1/3 kicked this morning at 8:30

When I got in this morning at 9-something (9:45 maybe?), Steve was taking dust photos on the AS table, of the MC Refl path.  Other than that, I don't have any information. 

Also, Tuesday is our traditional janitor day, so I'm hesitant to put our blame there.  (I think we've kept Tuesdays, even though we're on a less-often schedule....Steve will have to correct me if I'm wrong on this).

  9523   Mon Jan 6 22:11:46 2014 JenneUpdateLSCPRCL sideband locking still not so happy

 

 The PRCL once again doesn't want to lock on sidebands for me.  I can lock on the carrier just fine (using the IFO Config settings, along with some hand-alignment of the PRM). 

However, I can't convince it to lock on sidebands.  Using the configs that I used on Dec 18th (elog 9491), I'm not getting it.  I've done the arm ASS alignment, and I've run LSCoffsets, both of which seemed to do their things appropriately. 

I'm going to attribute this today to not being in the groove yet, and I'll look at it again in the morning.

  9524   Tue Jan 7 10:44:13 2014 SteveUpdateIOOMC drift

Quote:

 The trend shows a big jolt to the MC1/3 pointing this morning at 8:30.

Was anyone working anywhere near there today? There is no elog.

If not, we will have to put a 'no janitor' sign on all of the 40m doors permanently to prevent mops misaligning our interferometer.

 I was taking pictures at the AP table at the morning and ETMX optical table after noon. There was no activity on the IOO chamber.

 Look at the last 2 hours of  Rana's trend plot. MC1 and MC2 sensor voltage started increasing.

I think it was a drift action.

Attachment 1: 2dTrend.png
2dTrend.png
Attachment 2: driftNotKick.png
driftNotKick.png
  9525   Tue Jan 7 11:11:36 2014 ranaUpdateIOOMC drift

 

 NOT drift. The sudden steps are certainly the result of being kicked. The slow drift at the end of the day might be a slow strain relaxation.

It pays to be careful and not put too much weight or impulsive forces on the chambers or tables.

  9526   Tue Jan 7 16:41:08 2014 manasaUpdateIOOWFS moving MC suspensions

Quote:

 The trend shows a big jolt to the MC1/3 pointing this morning at 8:30.

Was anyone working anywhere near there today? There is no elog.

If not, we will have to put a 'no janitor' sign on all of the 40m doors permanently to prevent mops misaligning our interferometer.

The MC trend for the last 2 days shows that the MC suspensions were kicked again earlier today.  Looking back at the suspension channel INMONs along with the MC trans sum shows that the suspensions get kicked everytime MC locks and unlocks. (Attch:1)

So I checked the effect of WFS on the suspensions by disabling and enabling the WFS feedback servo (Attch:2).

Since the IMC is not at it best pointing, whenever the  MC autolocker runs and enables the WFS, the suspensions look like they are getting kicked.  But really, it's just the WFS doing their job. 

Edit, JCD:  What this really means is that our DC MC pointing is bad, and we need to move the MC suspensions to offload the WFS.  (All of the WFS output numbers for MC1 and 3 were around 100, which is pretty big for those numbers).  We should resurrect the WFS offloading scripts so that we can do this more regularly, and not have to do it by hand.

Attachment 1: 2dayMCtrend.png
2dayMCtrend.png
Attachment 2: WFSvsMCsuspensions.png
WFSvsMCsuspensions.png
  9527   Tue Jan 7 17:16:04 2014 manasaUpdateIOOMC aligned

Quote:

Edit, JCD:  What this really means is that our DC MC pointing is bad, and we need to move the MC suspensions to offload the WFS.  (All of the WFS output numbers for MC1 and 3 were around 100, which is pretty big for those numbers).  We should resurrect the WFS offloading scripts so that we can do this more regularly, and not have to do it by hand.

 Aligned MC to offload the WFS

1. Turned OFF the WFS feedback servo.

2. Aligned the MC suspensions by moving the pit and yaw sliders. MC trans sum brought from ~11000 counts to ~15000 counts. MC RFPD DCMON reads 0.45 counts.

3. Turned ON the WFS servo. The WFS output now reads in the order of 0 to +/-15.

4. Measured the MC spot positions. The spot positions look like they moved for the better compared to what they were yesterday.

 

Attachment 1: MCspots.png
MCspots.png
  9528   Tue Jan 7 20:57:41 2014 JenneUpdateIOOMC aligned

[Rana, Jenne]

We turned off the WFS servos, and looked at the MC REFL DC, and saw that it was still good, so we said that since the MC spots are pretty good, that we'll keep this alignment for now. 

Rana put the beam back on the center of the IOO QPDs on the PSL table.

We switched a steering mirror in the WFS path that was the wrong handed-ness to be the correct handed-ness, then put the beam on the centers of the WFS.  We turned on the WFS, and everything seems good.

While we were out on the table, we also changed the anodized aluminum dump for a razor dump, to catch the reflection from the 2inch lens that is the first thing the MC refl path sees out of vac.

There were no major drifts in the WFS error signals while we were gone for dinner, so the MC seems okay for now.

  9529   Tue Jan 7 21:00:02 2014 JenneUpdateIOOIP POS, IP ANG aligned

After locking the arms (after the MC alignment work), Manasa and I aligned IP POS, IP ANG, and both end transmission QPDs. 

We noticed that IP ANG is clipping in yaw as it comes onto the end table.  It looks to me like it's clipping on the edge of the plastic box's aperture, but I can't guarantee that it's not also clipping elsewhere. 

  9530   Tue Jan 7 22:44:45 2014 JenneUpdateCDSdaqd on fb is segfaulting every ~30 seconds

The daqd process is segfaulting and restarting itself every 30 seconds or so.  It's pretty frustrating. 

Just for kicks, I tried an mxstream restart, clearing the testpoints, and restarting the daqd process, but none of things changed anything.  

Manasa found an elog from a year ago (elog 7105 and preceding), but I'm not sure that it's a similar / related problem.  Jamie, please help us!

Here is a screen dump from the "dtail":

Every 1.0s: dmesg | tail -50                                                                                                                         Tue Jan  7 22:43:23 2014

[   33.498691]  [<ffffffff8104a063>] kthread+0x7a/0x82
[   33.498695]  [<ffffffff81003654>] kernel_thread_helper+0x4/0x10
[   33.498698]  [<ffffffff81049fe9>] ? kthread+0x0/0x82
[   33.498701]  [<ffffffff81003650>] ? kernel_thread_helper+0x0/0x10
[   33.498703] ---[ end trace 6236defa99b3e091 ]---
[   33.498705] mx INFO: Board 0: allocated MSI IRQ 67
[   33.498713] mx INFO: CPU0: PAT = 0x7010600070106
[   33.498715] mx INFO: CPU0: new PAT = 0x1010600070106
[   33.498718] mx INFO: Board 0: Using PAT index 6
[   33.499101] eth0: no IPv6 routers present
[   33.531013] mx INFO: Board 0: device 8, rev 0, 1 ports and 2096896 bytes of SRAM available
[   33.531017] mx INFO: Board 0: Bridge is 10de:005d
[   33.531228] mx INFO: Board 0: MAC address = 00:60:dd:46:ea:ec
[   33.535971] mx INFO: Loaded mcp of len 235448
[   34.489244] mx INFO: Starting usermode mapper at /opt/mx/sbin/mx_start_mapper
[   39.148855] mx INFO: mx0: Link0 is UP
[   39.588511] mx INFO: myri0: Will use skbuf frags (4096 bytes, order=0)
[   39.589299] mx INFO: 1 Myrinet board found and initialized
[  287.706367] daqd used greatest stack depth: 3368 bytes left
[86605.907520] daqd[18407]: segfault at 38b08e4c0 ip 00007f11b3942a6c sp 00007f10b1917d50 error 4
[86605.907530] daqd[18424]: segfault at 38b544f90 ip 00007f11b3942a6c sp 00007f10b12c6d30 error 4 in libc-2.10.1.so[7f11b390e000+14c000] in libc-2.10.1.so[7f11b390e000+14c00
0]
[86605.907544]
[86605.919454] daqd[21319] general protection ip:7f11b3942a6c sp:7f10b1814d30 error:0
[86605.919462] daqd[18442] general protection ip:7f11b3942a6c sp:7f10b0bf4d30 error:0
[86605.919615] daqd[18443]: segfault at 38aee3db0 ip 00007f11b3942a6c sp 00007f10b0b73d50 error 4 in libc-2.10.1.so[7f11b390e000+14c000]
[86605.919694] daqd[18412]: segfault at 38aff35d0 ip 00007f11b3942a6c sp 00007f10b1752d30 error 4
[86605.919701] daqd[18417]: segfault at 38b544f70 ip 00007f11b3942a6c sp 00007f10b154dd50 error 4 in libc-2.10.1.so[7f11b390e000+14c000]
[86605.919708] daqd[18445]: segfault at 38aff35b0 ip 00007f11b3942a6c sp 00007f10b0ab1d50 error 4
[86605.919733] daqd[18429]: segfault at 38b42ae90 ip 00007f11b3942a6c sp 00007f10b10c1d50 error 4 in libc-2.10.1.so[7f11b390e000+14c000]
[86605.919741] daqd[18440]: segfault at 38b08e480 ip 00007f11b3942a6c sp 00007f10b0cb6d30 error 4 in libc-2.10.1.so[7f11b390e000+14c000]
[86605.958551]  in libc-2.10.1.so[7f11b390e000+14c000] in libc-2.10.1.so[7f11b390e000+14c000]
[86605.958557]
[86605.958577]  in libc-2.10.1.so[7f11b390e000+14c000]
[86605.958586]  in libc-2.10.1.so[7f11b390e000+14c000]
[86605.959639] daqd used greatest stack depth: 3160 bytes left
[98139.100888] show_signal_msg: 13 callbacks suppressed
[98139.100895] daqd[23753]: segfault at 39c7363b0 ip 00007f5bf253ba6c sp 00007f5b69b48d30 error 4 in libc-2.10.1.so[7f5bf2507000+14c000]
[98687.815120] daqd used greatest stack depth: 2984 bytes left
[208995.594227] daqd[10386] general protection ip:7f3b7c930a6c sp:7f3a79f09d50 error:0 in libc-2.10.1.so[7f3b7c8fc000+14c000]
[353015.067479] daqd used greatest stack depth: 2880 bytes left
[367406.863618] daqd[13078]: segfault at 41 ip 0000000000000041 sp 00007fb1f0ba2cf8 error 14 in daqd[400000+7c000]
[367406.863833] daqd[13104] general protection ip:7fb2f3018a6c sp:7fb1f01c8d30 error:0
[367406.863877] daqd[13086] general protection ip:7fb2f3018a6c sp:7fb1f089ad30 error:0
[367406.877408] daqd[13080]: segfault at 41 ip 0000000000000041 sp 00007fb1f0ae0ca8 error 14 in daqd[400000+7c000]
[367406.877435]  in libc-2.10.1.so[7fb2f2fe4000+14c000]
[367406.877442] daqd[13100]: segfault at 39ba287b0 ip 00007fb2f3018a6c sp 00007fb1f034cd30 error 4 in libc-2.10.1.so[7fb2f2fe4000+14c000]
[367406.878372]  in libc-2.10.1.so[7fb2f2fe4000+14c000]
[399802.887523] daqd[18295] general protection ip:7fb056a71a6c sp:7faf96125f10 error:0 in libc-2.10.1.so[7fb056a3d000+14c000]
[410595.969327] daqd[22057]: segfault at 3a91f27b0 ip 00007f48e96eea6c sp 00007f47e6c26d50 error 4 in libc-2.10.1.so[7f48e96ba000+14c000]
[410595.988926] daqd[22068]: segfault at 3a91f2790 ip 00007f48e96eea6c sp 00007f47e681bd30 error 4 in libc-2.10.1.so[7f48e96ba000+14c000]

  9531   Tue Jan 7 23:08:01 2014 jamieUpdateCDS/frames is full, causing daqd to die

Quote:

The daqd process is segfaulting and restarting itself every 30 seconds or so.  It's pretty frustrating. 

Just for kicks, I tried an mxstream restart, clearing the testpoints, and restarting the daqd process, but none of things changed anything.  

Manasa found an elog from a year ago (elog 7105 and preceding), but I'm not sure that it's a similar / related problem.  Jamie, please help us

The problem is not exactly the same as what's described in 7105, but the symptoms are so similar I assumed they must have a similar source.

And sure enough, /frames is completely full:

controls@fb /opt/rtcds/caltech/c1/target/fb 0$ df -h /frames/
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              13T   13T     0 100% /frames
controls@fb /opt/rtcds/caltech/c1/target/fb 0$

So the problem in both cases was that it couldn't write out the frames.  Unfortunately daqd is apparently too stupid to give us a reasonable error message about what's going on.

So why is /frames full?  Apparently the wiper script is either not running, or is failing to do it's job.  My guess is that this is a side effect of the linux1 raid failure we had over xmas.

  9532   Tue Jan 7 23:09:10 2014 manasaUpdateIOOMC aligned

Quote:

[Rana, Jenne]

We turned off the WFS servos, and looked at the MC REFL DC, and saw that it was still good, so we said that since the MC spots are pretty good, that we'll keep this alignment for now. 

Rana put the beam back on the center of the IOO QPDs on the PSL table.

We switched a steering mirror in the WFS path that was the wrong handed-ness to be the correct handed-ness, then put the beam on the centers of the WFS.  We turned on the WFS, and everything seems good. 

There were no major drifts in the WFS error signals while we were gone for dinner, so the MC seems okay for now.

 The last 4 hour trend for WFS error signals show some amount of drift. We should still look at the long term trend to solve the issue.

Attachment 1: WFSdrift.png
WFSdrift.png
  9533   Tue Jan 7 23:13:47 2014 jamieUpdateCDS/frames is full, causing daqd to die

Quote:

So why is /frames full?  Apparently the wiper script is either not running, or is failing to do it's job.  My guess is that this is a side effect of the linux1 raid failure we had over xmas.

It actually looks like the wiper script has been running fine.  There is a log from Tuesday morning:

controls@fb ~ 0$ cat /opt/rtcds/caltech/c1/target/fb/wiper.log

Tue Jan  7 06:00:02 PST 2014

Directory disk usage:
/frames/trend/minute_raw 385289132k
/frames/trend/second 100891124k
/frames/full 12269554048k
/frames/trend/minute 1906772k
Combined 12757641076k or 12458633m or 12166Gb

/frames size 13460088620k at 94.78%
/frames is below keep value of 95.00%
Will not delete any files
df reported usage 97.72%
controls@fb ~ 0$

So now I'm wondering if something else has been filling up the frames today.  Has anything changed today that might cause more data than usual to be written to frames?

I'm manually running the wiper script now to clear up some /frames.  Hopefully that will solve the problem temporarily.

  9534   Tue Jan 7 23:24:41 2014 JenneUpdateGeneralIFO plan, list o' things to do

It seems that the most important short-term task we have right now is to figure out what our PRC length is, and what our tolerance from nominal is.  Gabriele and EricQ are going to work on that tomorrow.  If our PRC is of a length that we can't do anything useful for full IFO locking, we need to open up and fix it sooner rather than later.

While we're in there, we need to also put a baffle on the back side of the PRM cage, to protect the OSEMs from stray light.  Den and I discovered before Christmas that turning off the OSEM and OpLev damping to the PRM (while using the POP QPD for ASC) significantly reduced the power fluctuations in the PRC.  We still had arm power fluctuations, but I believe those are likely because our ALS system can't hold an arm precisely at full resonance.  So, putting a black glass baffle with ~2 inch aperture right up against the OSEMs should help a lot.  This week, I'll ask Steve to make me a quickie to-scale cardboard version of the baffles that he has had cut, so I can try securing it to the dirty suspension cage that we have out.  I will also check to make sure I have seen with my own eyes the baffles that I need, and copper wire to tie it to the cage.

Other, lower-priority things that we should do eventually:

* Steve, please find another razor beam dump for the WFS reflections - Rana and I used one of the ones that was there for reflection off the 2 inch lens in the MC refl path (replacing the aluminum dump that has been there for ages).  We also need to label all of our razor dumps with their purpose, with a label on top, so we remember not to remove dumps that are actually in use.

* At some point, we should change the one remaining steering mirror in the main PSL path that is aluminum, to a steel Polaris ("Polanski" or "Polish") mount.  For now, we should just make sure we have one handy.  Hopefully this will help reduce the PMC transmission drift that we see.

* Steve, in the morning sometime this week, can you please do a test of the drift of the IOO QPDs?  We'd like to see a trend that is maybe 30 or 60 minutes long of the QPD signals.  First 10 minutes, all lights in IFO room off.  Then, 10 minutes with the lights in the PSL on.  Then, the rest of the time the PSL lights off.  We want to see if these are hot enough to be causing a big temperature change in the PSL box, which may then be causing some optics to drift.

* QPD code in the simulink models (trans QPDs, but also OpLevs, and anywhere else we do normalization) needs to have anti-divide-by-zero protection.  I'll take care of this, it should be a quick copy of what we have elsewhere in the simulink code.

* Note to self for the future, instead of doing a dither alignment for the ASS for the arms, we can use the IP POS and IP ANG, as well as end transmission QPD signals.  However, for now, the ASS is working just fine.

* We want to go back to the idea of putting a lens into the in-vac IP ANG path, to avoid the clipping that Manasa and I were seeing tonight.  We want something of order 2inch diameter, 1meter focal length.  The material doesn't matter, but we do want it AR coated for 1064nm on both sides.  We also need to make sure that we could use a fixed 2 inch in-vac mirror mount, or something, to hold this lens.  If that won't work, we need to come up with another plan.  Manasa is working on thinking about precisely what lens we want to buy for a nice guoy phase telescope for IPANG, so we'll buy a lens after she puts her conclusions in the elog.

* An idea for the MC spots plot that Rana had was to plot the beam tilt and translation, rather than the raw spot positions on the mirrors.  The point of this would be to make it easier to see what the output beam from the MC looks like.  For MC pointing, we should also think about what our actual tolerances are.  The biggest thing is that we need to get through the Faraday without being too close to any edge, and also the REFL beam needs to come back through without clipping.  For now, we're just visually checking that the POP beam and the REFL beam both look unclipped since we don't have access to good camera views of either side of the Faraday.

  9535   Tue Jan 7 23:50:27 2014 jamieUpdateCDS/frames space cleared up, daqd stabilized

The wiper script is done and deleted a whole bunch of stuff to clean up some space:

controls@fb ~ 0$ /opt/rtcds/caltech/c1/target/fb/wiper.pl --delete

Tue Jan  7 23:09:21 PST 2014

Directory disk usage:
/frames/trend/minute_raw 385927520k
/frames/trend/second 125729084k
/frames/full 12552144324k
/frames/trend/minute 2311404k
Combined 13066112332k or 12759875m or 12460Gb

/frames size 13460088620k at 97.07%
/frames above keep value of 95.00%
Frame area size is 12401156668k
/frames/full size 12552144324k keep 11781098835k
/frames/trend/second size 125729084k keep 24802313k
/frames/trend/minute size 2311404k keep 620057k
Deleting some full frames to free 771045488k
- /frames/full/10685/C-R-1068567600-16.gwf
- /frames/full/10685/C-R-1068567616-16.gwf
...
controls@fb ~ 0$ df -h /frames
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              13T   12T  826G  94% /frames
controls@fb ~ 0$
So it cleaned up 826G of space.  It looks like the fb is stabilized for the moment.  On site folks should confirm...

 

asdfasdfsadf sadf asdf

  9536   Tue Jan 7 23:53:35 2014 JamieUpdateCDSdaqd can't connect to c1vac1, c1vac2

dadq is logging the following error messages to it's log related to the fact that it can't connect to c1vac1 and c1vac2:

CAC: Unable to connect because "Connection timed out"
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "c1vac2.martian:5064"
    Source File: ../cac.cpp line 1127
    Current Time: Tue Jan 07 2014 23:50:53.355609430
..................................................................
CAC: Unable to connect because "Connection timed out"
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "c1vac1.martian:5064"
    Source File: ../cac.cpp line 1127
    Current Time: Tue Jan 07 2014 23:50:53.356568469
..................................................................

 Not sure if this is related to the full /frames issue that we've been seeing.

  9538   Wed Jan 8 13:46:39 2014 JenneUpdateGeneralIFO plan, PRM baffle

Quote:

While we're in there, we need to also put a baffle on the back side of the PRM cage, to protect the OSEMs from stray light.  Den and I discovered before Christmas that turning off the OSEM and OpLev damping to the PRM (while using the POP QPD for ASC) significantly reduced the power fluctuations in the PRC.  We still had arm power fluctuations, but I believe those are likely because our ALS system can't hold an arm precisely at full resonance.  So, putting a black glass baffle with ~2 inch aperture right up against the OSEMs should help a lot.  This week, I'll ask Steve to make me a quickie to-scale cardboard version of the baffles that he has had cut, so I can try securing it to the dirty suspension cage that we have out.  I will also check to make sure I have seen with my own eyes the baffles that I need, and copper wire to tie it to the cage.

Steve may actually be onto something with the clamps that he had made a year and a half ago.  These clamps hold the glass, and then clamp to the base of the suspension cage.  Not the table, but the base of the suspension cage. The drawings are in elog 6344.  I'm not sure that the 1/4-20 holes in the clamp things are exactly where we'll want them, but we should be able to just dog it down to the base of the suspension.  I need to check this, but it may be even easier than tieing the glass to the cage.

Also, something to think about is that the earthquake stop screws extend backwards farther than the OSEMs.  I'm not sure anymore if we have shorter 1/4-20 earthquake stops around (if we do, they should be in the cleanroom shelves), but if we can't swap those out, they'll limit how close we can get to the OSEMs. 

Here's an overhead photo from 6 Sept 2012:

PRMcage_6Sept2012.JPG

  9540   Wed Jan 8 17:53:26 2014 manasaUpdateGeneralIFO plan, IPANG telescope

For the IPANG telescope design, we are in the 'beyond the Rayleigh range' regime. So using a single lens to make the beam small is not a great idea. I have put down a solution where we use a pair of lenses; one of which will be mounted in-vacuum in the ETMY chamber and the other on the endtable.
This way we will also allow have some freedom to configure the layout out-of vacuum in case the need arises. The layout will look something like in the cartoon:
IPANG_layout.png

I also made a choice of using longer focal length lenses (CVI 2" lenses f =1 m). Below is the beam path summary for IPANG telescope. I have used the waist diameter at the ITM for propagation. The endtable is roughly at 41.2m. The QPD will be placed in front of the waist (w0=47um).
IPANG.png 

  9542   Thu Jan 9 10:34:58 2014 SteveUpdatePSLPSL pointing changes in pitch

  IOO QPDs tested in dark, lighted and open PSL enclosure. The created temperature change 0.03 C has  effect on monitoring  in pitch.

 

 Atm1,  all lights off 10 min, PSL enclosure lights on  10 min, all lights off 15 min, open  door # 11 at north east corner of enclosure ( HEPA filters are running at 30V ) for 10 min, closed-dark enclosure 15 min

              dark 10, lighted 10, dark 15, open-dark 10 and closed-dark 15 minutes

 

Atm2, Pitch drift of 24 hours does not recover

Attachment 1: Lfnfdnc.png
Lfnfdnc.png
Attachment 2: 24hPSLpointing.png
24hPSLpointing.png
  9543   Thu Jan 9 17:21:45 2014 ranaUpdateGeneralIFO plan, IPANG telescope

Quote:

For the IPANG telescope design, we are in the 'beyond the Rayleigh range' regime. So using a single lens to make the beam small is not a great idea. I

Can you please explain this? I don't understand what exactly is the issue or 'great idea'.

I think we should be OK with just a single lens in the vacuum. But what we need is the ray tracing analysis to show what the effect will be on the IPANG readout.

  9545   Fri Jan 10 10:28:03 2014 SteveUpdatePSLPSL pointing changes

 

I looked at IOO QPDs again. QPD_POS was clamped by one screw. Dog clamp was added on the unclamped side.

QPD_ANG chassis has no isolation to optical table..._POS has.  QPD_ANG  base was tightened also.

Both QPDs moved a little bit but I did not centered them.  The spot sizes are 2-3 mm  They should be smaller.

How ever, we still can not explane the pitch movement of the IOO beam

 

Razor beam dumps were labeled at the AP table.

 

The 40m roof was cleaned from leafs this morning.

 

 

Attachment 1: clamped.png
clamped.png
  9547   Fri Jan 10 15:33:02 2014 SteveUpdatePSLlaser drift monitor set up idea

this locationQuote:

Quote:

Quote:

I wonder what's drifting between the laser and the PMC? And why is it getting worse lately?

 The PMC refl is bad in pitch today, and the transmission is only 0.76, rather than our usual 0.83ish.

I did a quick, rough tweak-up of the alignment, and now we're at 0.825 in transmission.

 The PMC transmission continuously degrades. In order to see what is really drifting the laser output after PBS was sampled as shown.

 IOO pointing is drifting in pitch. I'd like to use a QPD instead of the paper target to see if the Innolite output is stable. The idea is to move temporarily IOO-QPD_POS to  this location

Attachment 1: 2daysDrift.png
2daysDrift.png
  9549   Mon Jan 13 11:08:48 2014 SteveUpdatePSL3 good days of IOO pointing

 Three good days of IOO pointing: Friday, Sat and Sun    What was changed?  May be the clamping on Friday?

IOO vertical changes recovering as tempeture. IP is clipping at plastic enclosure of ETMY

 

NOTE: ANTS at the PSL optical table.  I will mop with chemicals tomorrow if we see more.

 

Attachment 1: 3gdPSLpointing.png
3gdPSLpointing.png
  9550   Mon Jan 13 16:50:55 2014 SteveUpdateVACMaglev controller needs service

Quote:

 The date is correct on this monitor.

Last stored RGA scan data Dec 20, 2013

IFO pressure at CC1 5.8e-6 Torr

Valve configuration: Vacuum Normal, confirmable only by manual checking of position indicators and pressure gauge controllers  readouts

 

 The Osaka TG390MCAB maglev turbo pump's controller TC010M has passed the 40,000 hrs of operation. This triggered the " alarm" LED  warning light to come on. 

It is normal maintenance.  Maglev TP-1 is running perfectly.  Osaka will send us a loaner-controller that we can use while they do the std maintenance.

I'm thinking of ~ February to do this.

  9552   Tue Jan 14 10:12:12 2014 SteveUpdatePSLlaser drift monitor set up idea

Quote:

this locationQuote:

Quote:

Quote:

I wonder what's drifting between the laser and the PMC? And why is it getting worse lately?

 The PMC refl is bad in pitch today, and the transmission is only 0.76, rather than our usual 0.83ish.

I did a quick, rough tweak-up of the alignment, and now we're at 0.825 in transmission.

 The PMC transmission continuously degrades. In order to see what is really drifting the laser output after PBS was sampled as shown.

 IOO pointing is drifting in pitch. I'd like to use a QPD instead of the paper target to see if the Innolite output is stable. The idea is to move temporarily IOO-QPD_POS to  this location

 I do like to move IOO-QPD_POS temporarily to see that the feedback has anything to do with with the pointing.

Attachment 1: bad4thday.png
bad4thday.png
  9553   Tue Jan 14 10:34:57 2014 SteveUpdatePSLgreen transmission measurment

GariLyn is using our green light on the west side of the PSL table. The green PDA36As were moved and the HEPA turned up to 60V

Attachment 1: greenPickUp.jpg
greenPickUp.jpg
  9556   Wed Jan 15 13:05:30 2014 JenneUpdatePEM4.4 EQ in Fontana, CA

It looks like there was a 4.4 magnitude earthquake near Fontana, CA around 1:30am today.  This tripped all of the suspension watchdogs, which Q has just now re-enabled. 

  9558   Wed Jan 15 18:42:57 2014 JenneUpdateASCPOP ASC QPD offline for a few hours this afternoon

I was in the lab, near the south end of the ITMX oplev table, looking for something, and I bumped the POP ASC QPD's power supply.  I thought that it was fine, but did not adequately check it.  When EricQ asked me just now about why the PRC is so wobbly today, I checked, and the power for the QPD wasn't properly connected (it's kind of a crappy connector, that if you nudge, contacts or loses contact).  Anyhow, I restored power to the QPD, and the PRC looks a little more stable now.  My fault for not checking more carefully, and my apologies to Q and Gabriele for their frustrations this afternoon.

  9559   Thu Jan 16 08:19:29 2014 SteveUpdatePEM4.4 and 3.8M local earth quakes


It looks like there was a 4.4 magnitude earthquake near Fontana, CA around 1:30am today.  This tripped all of the suspension watchdogs, which Q has just now re-enabled. 

   Earth quake shake down yesterday Atm1

Atm2, today's shake

Attachment 1: local4.4eq.png
local4.4eq.png
Attachment 2: local3.8eq.png
local3.8eq.png
  9560   Thu Jan 16 21:38:13 2014 ericqUpdateLSCRepeat of PRC length measurement

[ericq,Jenne]

Since we don't have agreement between the measurements we made the other day and the earlier estimations, I wanted to repeat the demodulation angle measurement. We had to do a few things to keep the PRMI locked, since in the last few days, it hasn't been stable enough.

The mode cleaner had been very fussy lately; the WFS were pushing in a way that caused fast oscillations of the transmission and reflection powers. I turned off the servos, manually aligned the mode cleaner to transmission of about 15k and refl of about .4, centered the beams on the WFS QPDs, and turned the loops back on. Things were much stable after that. Also, Jenne noticed that the PMC loop had walked the laser PZT temperature to a bad place, and fixed it.

After aligning the carrier locked PRMI, the last piece needed to get things stable enough for sideband locking was turning off the angular damping on the PRM suspension screen (this was turned back on when we were done). Waiting until evening noise levels probably helped too. We used a 1000 count MICH excitation in the PRMI case, and recorded data for about a minute in one degree steps around the demodulation phase that looked to put the excitation entirely within the Q of the PD. Also, we notched out the excitation frequency in the MICH servo bank for today's measurement; I think it's outside of the loop bandwidth anyways, but it's good to be sure. 

Jenne and I pondered a bit whether changing the AS55 demodulation phase while it (AS55 Q) is being used as the MICH control signal introduces subtleties that we haven't anticipated, but couldn't come up with anything concrete. Changing the angle from the what maximizes the Q just looks like a slight change in MICH gain, and shouldn't affect the phase of the excitation signal on the PD...

In any case, the data have been recorded, and the results will follow soon. 

  9563   Tue Jan 21 19:41:59 2014 JenneUpdateElectronicsRF distribution box power button fail

Rana, Gabriele and I are trying to measure the FSR of the PRC (elog about that later), and we turned off the power to the RF generation box so that we could switch cables at the EOM combiner.  However, as in elog 9101, the power button won't latch when we try to turn the power back on.  All 3 of us tried, to no avail.  For our measurement, poor Gabriele is standing holding the button pushed in, so that we can have some RF sidebands. 

Tomorrow, we'll have to pull the RF generation box, and put in a better switch.

  9566   Wed Jan 22 16:36:45 2014 ericqUpdateElectronicsRF distribution box power button fail

Quote:

Rana, Gabriele and I are trying to measure the FSR of the PRC (elog about that later), and we turned off the power to the RF generation box so that we could switch cables at the EOM combiner.  However, as in elog 9101, the power button won't latch when we try to turn the power back on.  All 3 of us tried, to no avail.  For our measurement, poor Gabriele is standing holding the button pushed in, so that we can have some RF sidebands. 

Tomorrow, we'll have to pull the RF generation box, and put in a better switch.

I replaced the stupid broken fancy button with a simple sturdy switch. I had to file out the hole in the chassis a bit, but the switch is pressed in tightly and securely. I put the box back in the rack, but the power cable was coming directly from the power supplies with no fuses. The box was drawing ~.9 and 1.5 Amps from two supplies, so I put 2A fuses on both. Plugged everything back in, and the mode cleaner locks, so it looks like all is well.

RXA: When its so close, I prefer to size it up by 1 step. Please change to 5A fuses. Otherwise, we may blow them from power glitches.

Q: 5A fuses have been swapped in

  9567   Wed Jan 22 18:17:46 2014 JenneUpdateCDSfb timing was off

Since this morning, the fb's timing has been off.  Steve pointed it out to me earlier today, but I didn't have a chance to look at it until now. 

This was different from the more common problem of the mx stream needing to be restarted - that causes 3 red blocks per core, on all cores on a computer, but it doesn't have to be every computer.  This was only one red block per core in the CDS FE status screen, but it was on every core on every computer. 

The error message, when you click into the details of a single core, was 0x4000.  I elog searched for that, and found elog 6920, which says that this is a timing issue with the frame builder.  Since Jamie had already set things on nodus' config correctly, all I did was reconnect the fb to the ntp: 

fb$ sudo /etc/init.d/ntp-client restart

As in elog 6920, the daqd stopped, then restarted itself, and cleared the error message. It looks like everything is good again.

I suspect (without proof) that this may have to do with the campus network being down this morning, so the computers couldn't sync up with the outside world.

  9568   Wed Jan 22 20:00:41 2014 JenneUpdateGeneralVENT GO!

Steve, please begin the vent!!

[EricQ, Jenne]

We have followed the pre-vent checklist, and done everything except check the jam nuts (which Steve can do in the morning).

We are ready to vent, so Steve, please begin bringing us up to atmosphere first thing in the morning.

Here is a copy of the list, from the wiki:

 

 

  • Center all oplevs/IPPOS/IPANG
  • Align the arm cavities for IR and align the green lasers to the arms. (Green powers were both ~0.8.  We only touched the Xend PZTs remotely, did not touch Yend).
  • Make a record of the MC pointing
  • Align the beam at the PSL angle and position QPDs (Did not need doing, left QPDs as-is so we keep our long-term trend.)
  • Reduce input power by touching wave plate on the PSL table BEFORE THE PMC.  (HWP was at 269degrees, now at 3 hundred something to make power just before PSL shutter 90mW)
  • Replace 10% BS before MC REFL PD with Y1 mirror and lock MC at low power.
  • Close shutter of PSL-IR and green shutters at the ends
  • Make sure the jam nuts are protecting bellows
  •  

     

    Attachment 1: IFOstatus_lowPower_preVent.png
    IFOstatus_lowPower_preVent.png
      9570   Thu Jan 23 08:04:04 2014 SteveUpdateVACvacuum control screen is blank

     

    There is BLANK VacControl_BAK.adl screen only. 

    I can move a valve by disconnecting it's  solenoid power if it's position is normally open.

    I will close V1 and check computer cable connections and move on with manual - hand disconnect ea valve to be moved into the right position for vent. Valve positions will be confirmed by looking manual indicators on valves.

    Attachment 1: pd76m170d2dRgaOn.png
    pd76m170d2dRgaOn.png
      9571   Thu Jan 23 13:23:10 2014 SteveUpdateVAC40m IFO is at atmosphere

    Quote:

     

    There is BLANK VacControl_BAK.adl screen only. 

    I can move a valve by disconnecting it's  solenoid power if it's position is normally open.

    I will close V1 and check computer cable connections and move on with manual - hand disconnect ea valve to be moved into the right position for vent. Valve positions will be confirmed by looking manual indicators on valves.

     The 40m vacuum envelope vent is completed with instrument grade air.

    Valve configuration: chamber open, RGA is pumped through VM3 by TP3,

      9572   Thu Jan 23 23:10:19 2014 ericq UpdateGeneralVent so far

    [ericq, Manasa, Jenne]

    Summary: We opened up the BS and both ITM chambers today, and put the light doors on. //Edit : Manasa  Post-vent the MC was very much misaligned in yaw. Both the ITMs moved in pitch as inferred from the oplev; but there is still light on the oplev PDs//. We toiled with the PMC and mode cleaner for a while to get reasonable transmission and stability (at least for a period of time). We then tried to lock IR to the y-arm, to no avail. 

    Locking the PMC doesn't seem very robust with the low power level we have; adjusting the gain at all when it's locked throws it right out. The mode cleaner spot was visibly moving around on MC2 as well. We'll continue tomorrow. 

    Details about alignment efforts: Manasa and I tried for a while to try and align the y-arm for IR. Straight out of venting the green TM00 would lock to the y-arm with about .45, as compared to .8 before venting, so it didn't seem to drift too far. The x-arm would even flash any modes, however. For a while, IR was no where to be seen after the mode cleaner. Eventually, we used the tip tilts to bring the AS beam onto the camera, which exhibited fringes, so we knew we were hitting the ITMs somewhere. We wandered around with the ETM to see if any retroflection was happening, and saw the IR beam scatter off of the earthquake stop. We moved it to the side to see it hitting the OSEM holder, and moved down to the bottom OSEM holder to get an idea of where to put pitch to get roughly the center of the ITM, then undid the yaw motion.

    There, we would see very infrequent, weak flashes. We weren't able to distinguish the mode shape though; however, the flashes were coincident with where the green would lock to a very yaw-misaligned fishbone mode, to the lower right of the optic's center. We figured that if we gradually fixed the green alignment with the mode shapes we could see and actually lock on, we could use the tip tilts to adjust the IR pointing and keep it coincident and eventually resonate more. However, this didn't really work out. The flashes were very infrequent, and at this point the PMC/MC were getting very touchy, and would cease to stay locked for more than a minute or two. At this point, we stopped for the day. 

     

      9576   Mon Jan 27 09:08:00 2014 SteveUpdateVAC4 days at atmosphere

     

     

    Attachment 1: day4atm.png
    day4atm.png
    Attachment 2: vent76bgTp3d4.png
    vent76bgTp3d4.png
      9577   Mon Jan 27 12:26:00 2014 KojiUpdateIOOIOO Slow Actuator Servo threshold changed

    In order to activate the slow actuator servo for the MC locking,
    the threshold level for this servo (C1:PSL-FSS_LOCKEDLEVEL) was changed from 10000 to 700.

    Now the servo started to move the PZT fast out to be controlled to 5V.

      9579   Mon Jan 27 21:36:35 2014 ericq UpdateGeneralVent so far

    After turning the slow FSS threshold down, the mode cleaner stays locked enough to do other things. We were able to align the tip tilts to the y-arm such that we were able to get some flashes in what looks like a TM00-ish mode. (It was necessary to align the PRM such that there was some extra power circulating in the PRC to be able to see the IR flashes on the ITMY face camera) This is enough to convince us that we are at least near a reasonable alignment, even though we couldn't lock to the mode. 

    The x-arm was in a hairier situation; since the green beam wouldn't flash into any modes, we don't even know that a good cavity axis exists. So, I used the green input PZTs to shine the green beam directly on the earthquake stops on the ITMX cage, and then inferred the PZT coordinates that would place the green beam roughly on the center of ITMX. I moved the ETMX face camera such that it points at the ETMX baffle. I tried looking for the retroreflected green spot to no avail. Hopefully tomorrow, we can get ourselves to a reasonably aligned state, so we can begin measuring the macroscopic PRC length. 

      9580   Tue Jan 28 09:51:47 2014 SteveUpdateIOOlow power pointing

     

    PSL output is stable.

    Attachment 1: IOO4dlowpr.png
    IOO4dlowpr.png
      9581   Tue Jan 28 11:13:50 2014 KojiUpdateVAC vacuum monitor is still blank

    [Steve Koji]

    We pushed the reset button of c1vac1 and c1vac2 and the vacuum screen is back.

    First, we pushed the reset button of c1vac1 and pushed the one on c1vac2.
    This did not bring c1vac2 up. We pushed the reset of c1vac2 again and now everything of the vacuum screen is back.

      9582   Tue Jan 28 16:26:40 2014 SteveUpdateVAC vacuum computers are back without safety

    Quote:

    [Steve Koji]

    We pushed the reset button of c1vac1 and c1vac2 and the vacuum screen is back.

    First, we pushed the reset button of c1vac1 and pushed the one on c1vac2.
    This did not bring c1vac2 up. We pushed the reset of c1vac2 again and now everything of the vacuum screen is back.

     1, Reset works

     2, Default values are lost. They actually reversed into open and turn on everything when power recycle c1vac1, c1vac2 or 24V dc power supply. This can vent the IFO in an event of power failure!

          It's may be the time to go back to an isolated, vacuum controller only computer.

     

    The present valve configuration at Atm1

    a, all annuloses are vented

    b, valve cables disconnected at: VC1 and 4 IP gate valves

    c, the RGA is off and it is pumped by the Maglev through VM2

    d, cryo pump is being roughed with TP3  It's outgassing rate was 25 mTorr / min

    e, Roughing hose is disconnected

    Attachment 1: c1vac1_vac2areback.png
    c1vac1_vac2areback.png
      9583   Tue Jan 28 22:24:46 2014 ericq UpdateGeneralFurther Alignment

    [Masasa, ericq]

    Having no luck doing things remotely, we went into the ITMX chamber and roughly aligned the IR beam. Using the little sliding alignment target, we moved the BS to get the IR beam centered on ITMX, then moved ITMX to get good michelson fringes with ITMY. Using an IR card, found the retroflection and moved ETMX to make it overlap with the beam transmitted through the ITM. With the PRM flashing, X-arm cavity flashes could be seen. So, at that point, both the y-arm and x-arm were flashing low order modes. 

      9584   Tue Jan 28 23:32:12 2014 KojiUpdateGeneralX/Y arm locked with the IR beam

    [Koji EricQ]

    The both arms have been locked with IR and aligned by ASS.

    The IFO was left with ITMX/Y, ETMX/Y, BS, and PRM aligned, and the PSL shutter closed.


    YARM
    SIGNAL PATH:
    POY11I(+45dB)->YARM(G=+1.0)->ETMY
    NORM: TRYx10
    TRIG: TRY 0.01up/0.005down
    FM TRIG: FM2/3/6/7/8/9 0.01up/0.05down, 0.5 sec delay

    XARM
    SIGNAL PATH:
    POX11I(+45dB)->XARM(G=+4.0)->ETMX
    NORM: TRXx10
    TRIG: TRX 0.01up/0.005down
    FM TRIG: FM2/3/6/7/8/9 0.01up/0.05down, 0.5 sec delay


    For decent locks, it was necessary that the offset of the error signals are trimmed at the input filters
    even after running LSCoffset.py script.

    Once the cavities were aligned for the IR, we could see the green beams are also flashing.
    The Y arm was actually locked with the green with a TEM00 mode

    Attachment 1: good_alignment.png
    good_alignment.png
      9587   Thu Jan 30 11:59:03 2014 manasaUpdateCDSfb timing was off

    Quote:

    Since this morning, the fb's timing has been off.  Steve pointed it out to me earlier today, but I didn't have a chance to look at it until now. 

    This was different from the more common problem of the mx stream needing to be restarted - that causes 3 red blocks per core, on all cores on a computer, but it doesn't have to be every computer.  This was only one red block per core in the CDS FE status screen, but it was on every core on every computer. 

    The error message, when you click into the details of a single core, was 0x4000.  I elog searched for that, and found elog 6920, which says that this is a timing issue with the frame builder.  Since Jamie had already set things on nodus' config correctly, all I did was reconnect the fb to the ntp: 

    fb$ sudo /etc/init.d/ntp-client restart

    As in elog 6920, the daqd stopped, then restarted itself, and cleared the error message. It looks like everything is good again.

    I suspect (without proof) that this may have to do with the campus network being down this morning, so the computers couldn't sync up with the outside world.

    The above timing problem has been repeating (a couple of times this week so far). It does not seem to be related to the campus network.

    The same solution was applied.

      9589   Fri Jan 31 18:41:25 2014 manasaUpdateGeneralIFO alignment update

    [EricQ, Gabriele, Manasa]

    We found we had lost the Y arm pointing from yesterday. We tried to recover the pointing for a couple of hours and finally decided to take the ETMY heavy door off.

    The input beam was aligned to the Y arm. We also got AS and REFL out of vacuum and on the cameras.

    We put back the light doors and tried to lock the arms, but did not succeed as yet.

    Things to do:
    1. Lock arms for IR
    2. Realign POP path
    3. Recenter all oplevs
    4. Try to check the state of PRC after the length change
    5. Take in-vacuum pictures

      9591   Mon Feb 3 10:17:14 2014 SteveUpdatePEMdusty surfaces

    Please wet WIPE before opening chamber or optical table ! ! 

     with methanol soaked kimwipes.

    The Met One particle counter is located on CES wall, just behind ITMX chamber. 

    The numbers are not so bad, but have you ( ...a)  asked the IFO lately?

    Attachment 1: AP-ISCT.jpg
    AP-ISCT.jpg
    Attachment 2: BSC-rim.jpg
    BSC-rim.jpg
    Attachment 3: ITMX-ISCT.jpg
    ITMX-ISCT.jpg
    Attachment 4: 12daysAtm.png
    12daysAtm.png
      9592   Mon Feb 3 15:57:52 2014 SteveUpdateGreen LockingETMX green power

    There was 0.2 mW green at the X end.

    The doubling oven temp was changed from 37.5 to 36 degrees C

    Power at green shutter 3 mW  The alignment was not touched.

    Attachment 1: ETMXgreen.jpg
    ETMXgreen.jpg
    Attachment 2: XgreenOven36C.jpg
    XgreenOven36C.jpg
    ELOG V3.1.3-