40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 239 of 344 Not logged in
ID Date Author Type Category Subject
5408   Wed Sep 14 20:04:05 2011 jamieUpdateCDSUpdate to frame builder wiper.pl script for GPS 1000000000

I have updated the wiper.pl script (/opt/rtcds/caltech/c1/target/fb/wiper.pl) that runs on the framebuilder (in crontab) to delete old frames in case of file system overloading.  The point of this script is to keep the file system from overloading by deleting the oldest frames.  As it was, it was not properly sorting numbers which would have caused it to delete post-GPS 1000000000 frames first.  This issue was identified at LHO, and below is the patch that I applied to the script.

--- wiper.pl.orig  2011-04-11 13:54:40.000000000 -0700 +++ wiper.pl       2011-09-14 19:48:36.000000000 -0700 @@ -1,5 +1,7 @@  #!/usr/bin/perl   +use File::Basename; +  print "\n" .  date . "\n";  # Dry run, do not delete anything  $dry_run = 1; @@ -126,14 +128,23 @@ if ($du{$minute_trend_frames_dir} >$minute_frames_keep) { $do_min = 1; }; +# sort files by GPS time split into prefixL-T-GPS-sec.gwf +# numerically sort on 3rd field +sub byGPSTime { + my$c = basename $a; +$c =~ s/\D+(\d+)\D+(\d+)\D+/$1/g; + my$d = basename $b; +$d =~ s/\D+(\d+)\D+(\d+)\D+/$1/g; +$c <=> $d; +} + # Delete frame files in$dir to free $ktofree Kbytes of space # This one reads file names in$dir/*/*.gwf sorts them by file names  # and progressively deletes them up to $ktofree limit sub delete_frames { ($dir, $ktofree) = @_; # Read file names; Could this be inefficient? - @a= <$dir/*/*.gwf>; -       sort @a; +       @a = sort byGPSTime <$dir/*/*.gwf>;$dacc = 0; # How many kilobytes we deleted         $fnum = @a;$dnum = 0; @@ -145,6 +156,7 @@           if ($dacc >=$ktofree)  { last; }           $dnum ++; # Delete$file here +         print "- " . $file . "\n"; if (!$dry_run) {                  unlink($file); } 5424 Thu Sep 15 20:16:15 2011 jamieUpdateCDSNew c1oaf model installed and running [Jamie, Jenne, Mirko] # New c1oaf model installed We have installed the new c1oaf (online adaptive feed-forward) model. This model is now running on c1lsc. It's not really doing anything at the moment, but we wanted to get the model running, with all of it's interconnections to the other models. c1oaf has interconnections to both c1lsc and c1pem via the following routes: c1lsc ->SHMEM-> c1oaf c1oaf ->SHMEM-> c1lsc c1pem ->SHMEM-> c1rfm ->PCIE-> c1oaf  Therefore c1lsc, c1pem, and c1rfm also had to be modified to receive/send the relevant signals. As always, when adding PCIx senders and receivers, we had to compile all the models multiple times in succession so that the /opt/rtcds/caltech/c1/chans/ipc/C1.ipc would be properly populated with the channel IPC info. ## Issues: There were a couple of issues that came up when we installed and re/started the models: ### c1oaf not being registered by frame builder When the c1oaf model was started, it had no C1:DAQ-FB0_C1OAF_STATUS channel, as it's supposed to. In the daqd log (/opt/rtcds/caltech/c1/target/fb/logs/daqd.log.19901) I found the following: Unable to find GDS node 22 system c1oaf in INI files It turns out this channel is actually created by the frame builder, and it could not find the channel definition file for the new model, so it was failing to create the channels for it. The frame builder "master" file (/opt/rtcds/caltech/c1/target/fb/master) needs to list the c1oaf daq ini files: /opt/rtcds/caltech/c1/chans/daq/C1OAF.ini /opt/rtcds/caltech/c1/target/gds/param/tpchn_c1oaf.par These were added, and the framebuilder was restarted. After which the C1:DAQ-FB0_C1OAF_STATUS appeared correctly. ### SHMEM errors on c1lsc and c1oaf This turned out to be because of an oversight in how we wired up the skeleton c1oaf model. For the moment the c1oaf model has only the PCIx sends and receives. I had therefore grounded the inputs to the SHMEM parts that were meant to send signals to C1LSC. However, this made the RCG think that these SHMEM parts were actually receivers, since it's the grounding of the inputs to these parts that actually tells the RCG that the part is a receiver. I fixed this by adding a filter module to the input of all the senders. Once this was all fixed, the models were recompiled, installed, and restarted, and everything came up fine. All model changes were of course committed to the cds_user_apps svn as well. 5651 Tue Oct 11 17:32:05 2011 jamieHowToEnvironment40m google maps link Here's another useful link: http://maps.google.com/maps?q=34.13928,-118.123756 5710 Thu Oct 20 09:54:53 2011 jamieUpdateComputer Scripts / Programspynds working on pianosa again  Quote: Doesn't work on pianosa either. Has someone changed the python environment? pianosa:SUS_SUMMARY 0> ./setSensors.py 1000123215 600 0.1 0.25 Traceback (most recent call last): File "./setSensors.py", line 2, in import nds ImportError: No module named nds So I found that the NDS2 lib directory in (/ligo/apps/nds2/lib) was completely empty. I reinstalled NDS2 and pynds, and they are now available again by default on pianosa (it should "just work", assuming you don't break your environment). Why the NDS2 lib directory was completely empty is definitely a concern to me. The contents of directories don't just disappear. I can't imagine how this would happen other than someone doing it, either on purpose or accidentally. If someone actually deleted the contents of this directory on purpose they need to speak up, explain why they did this, and come see me for a beating. 5736 Tue Oct 25 18:09:44 2011 jamieUpdateCDSNew DEMOD part I forgot to elog (bad Jamie) that I broke out the demodulator from the LOCKIN module to make a new DEMOD part: The LOCKIN part now references this part, and the demodulator can now be used independently. The 'LO SIN in' and 'LO COS in' should receive their input from the SIN and COS outputs of the OSCILLATOR part. 5755 Fri Oct 28 12:47:38 2011 jamieUpdateCDSCSS/BOY installed on pianosa I've installed Control System Studio (CSS) on pianosa, from the version 3.0.2 Red Hat binary zip. It should be available as "css" from the command line. CSS is a new MEDM replacement. It's output is .opi files, instead of .adl files. It's supposed to include some sort of converter, but I didn't play with it enough to figure it out. Please play around with it and let me know if there are any issues. links: 5833 Mon Nov 7 15:43:25 2011 jamieUpdateLSCLSC model recompiled  Quote: While trying to compile, there was something wrong with the lockins that were there...it complained about the Q OUTs being unconnected. I even reverted to the before-I-touched-it-today version of c1lsc from the SVN, and it had the same problem. So, that means that whomever put those in the LSC model did so, and then didn't check to see if the model would compile. Not so good. Anyhow, I just terminated them, to make it happy. If those are actually supposed to go somewhere, whoever is in charge of LSC lockins should take a look at it. This was totally my fault. I'm very sorry. I modified the lockin part to output the Q phase, and forgot to modify the models that use that part appropriately. BAD JAMIE! I'll check to make sure this won't bite us again. 5834 Mon Nov 7 15:49:26 2011 jamieUpdateIOOWFS output matrix measured (open loop)  Quote: The scripts used to make the WFS outmatrix measurement live in /cvs/cds/rtcds/caltech/c1/scripts/MC/WFS I assume you mean /opt/rtcds/caltech/c1/scripts/MC/WFS. As I've tried to reitterate many times: we do not use /cvs/cds anymore. Please put all new scripts into the proper location under /opt/rtcds. 5836 Mon Nov 7 17:27:28 2011 jamieUpdateComputersISCEX IO chassis timing slave dead It appears that the timing slave in the c1iscex IO chassis is dead. It's front "link" lights are dark, although there appears to be power to the board (other on-board leds are lit). These front lights should either be on and blinking steadily if the board is talking to the timing system, or blinking fast if there is no connection to the timing distribution box. This likely indicates that the board has had some sort of internal failure. Unfortunately Downs has no spare timing slave boards lying around at the moment; they're all stuffed in IO chassis awaiting shipping. I'm going to email Rolf about stealing one, and if he agrees we'll work with Todd Etzel to pull one out for a transplant 5845 Wed Nov 9 10:35:30 2011 jamieUpdateSUSETMX oplev is down and sus damping restored  Quote: The ETMX oplev returning beam is well centered on the qpd. We lost this signal 2 days ago. I will check on the qpd. ETMX sus damping restored As reported a couple days ago, the ETMX IO chassis has no timing signal. This is why we there is no QPD signal and why we turned off the ETMX watchdog. In fact, I believe that there is probably nothing coming out of the ETMX suspension controller at all. I'm working on getting the timing board replaced. Hopefully today. 5854 Wed Nov 9 18:02:42 2011 jamieUpdateCDSISCEX front-end working again (for the moment...) The c1iscex IO chassis seems to be working again, and the iscex front-end is running again. However, I can't say that I actually fixed the problem. Originally I thought the timing slave board had died by the fact that the front LED indicators next to the fiber IO were out. I didn't initially consider this a power supply problem since there were other leds on the board that were lit. I finally managed to track down Rolf to give downs the OK to pull the timing boards out of a spare IO chassis for us to use. However, when I replaced the timing boards in the chassis with the new ones, they showed the exact same behavior. I then checked the power to the timing boards, which comes off a 2-pin connector from the backplane board in the back of the IO chassis. Apparently it's supposed to be 12V, but it was only showing ~2.75V. Since it was showing the same behavior for both timing boards, I assumed that the issue was on the IO chassis backplane. I (with the help of Todd Etzel) started pulling cards out of the IO chassis (while power cycling appropriately, of course) to see if that changed anything. After pulling out both the ADC and DAC cards, the timing system then came up fine, with full power. The weird part is that everything then stayed fine after we started plugging all the cards back in. We eventually got back to the fully assembled configuration with everything working. But, nothing was changed, other than just re-seating all the cards. Clearly there's some sort of flaky connection on the IO chassis board. Something is prone to shorting, or something, that overloads the power supply and causes the voltage supply to the timing card to drop. All I can do at this point is keep an eye on it and go through another round of debugging if it happens again. If it does happen again, I ask that everyone please not touch the IO chassis and let me look at it first. I want to try to poke around before anyone giggles any cables so I can track down where the issue might be. 5873 Fri Nov 11 13:26:24 2011 jamieUpdateSUSMusings on SUS dewhitening, and MC ELP28's  Quote: For the whitening on the OSEM sensor input, FM1 is linked to the Contec binary I/O. FM1 is the inverse whitening filter. Turn it on, and the analog whitening is on (bit in the binary I/O screen turns red). Turn it off, and the analog whitening is bypassed (bit in the binary I/O screen turns gray). Good. Makes sense. Either way, the net transfer function is flat. The dewhitening is not so simple. In FM9 of the Coil Output filter bank, we have "SimDW", and in FM10, we have "InvDW". Clicking SimDW on makes the bit in the binary I/O screen gray (off?), while clicking it off makes it red (on?). Clicking InvDW does nothing to the I/O bits. So. I think that for dewhitening, the InvDW is always supposed to be on, and you either have Simulated DW, or analog DW enabled, so that either way your transfer function is flat. Fine. I don't know why we don't just tie the analog to the InvDW filter module, and delete the SimDW, but I'm sure there's a reason. The input/whitening filters used to be in a similarly confused state as the output filters, but they have been corrected. There might have been a reason for this setup in the past, but it's not what we should be doing now. The output filters all need to be fixed. We just haven't gotten to it yet. As with the inputs, all output filters should be set up so that the full output transfer function is always flat, no matter what state it's in. The digital anti-dewhitening ("InvDW") and analog dewhitening should always be engaged and disengaged simultaneously. The "SimDW" should just be removed. This is on my list of things to do. 5896 Tue Nov 15 15:56:23 2011 jamieUpdateCDSdataviewer doesn't run  Quote: Dataviewer is not able to access to fb somehow. I restarted daqd on fb but it didn't help. Also the status screen is showing a blank while form in all the realtime model. Something bad is happening. So something very strange was happening to the framebuilder (fb). I logged on the fb and found this being spewed to the logs once a second: [Tue Nov 15 15:28:51 2011] going down on signal 11 sh: /bin/gcore: No such file or directory [Tue Nov 15 15:28:51 2011] going down on signal 11 sh: /bin/gcore: No such file or directory [Tue Nov 15 15:28:51 2011] going down on signal 11 sh: /bin/gcore: No such file or directory [Tue Nov 15 15:28:51 2011] going down on signal 11 sh: /bin/gcore: No such file or directory [Tue Nov 15 15:28:51 2011] going down on signal 11 sh: /bin/gcore: No such file or directory [Tue Nov 15 15:28:51 2011] going down on signal 11 sh: /bin/gcore: No such file or directory [Tue Nov 15 15:28:51 2011] going down on signal 11 sh: /bin/gcore: No such file or directory [Tue Nov 15 15:28:51 2011] going down on signal 11 sh: /bin/gcore: No such file or directory [Tue Nov 15 15:28:51 2011] going down on signal 11 sh: /bin/gcore: No such file or directory  Apparently /bin/gcore was trying to be called by some daqd subprocess or thread, and was failing since that file doesn't exist. This apparently started at around 5:52 AM last night: [Tue Nov 15 05:46:52 2011] main profiler warning: 1 empty blocks in the buffer [Tue Nov 15 05:46:53 2011] main profiler warning: 0 empty blocks in the buffer [Tue Nov 15 05:46:54 2011] main profiler warning: 0 empty blocks in the buffer [Tue Nov 15 05:46:55 2011] main profiler warning: 0 empty blocks in the buffer [Tue Nov 15 05:46:56 2011] main profiler warning: 0 empty blocks in the buffer ... [Tue Nov 15 05:52:43 2011] main profiler warning: 0 empty blocks in the buffer [Tue Nov 15 05:52:44 2011] main profiler warning: 0 empty blocks in the buffer [Tue Nov 15 05:52:45 2011] main profiler warning: 0 empty blocks in the buffer GPS time jumped from 1005400026 to 1005400379 [Tue Nov 15 05:52:46 2011] going down on signal 11 sh: /bin/gcore: No such file or directory [Tue Nov 15 05:52:46 2011] going down on signal 11 sh: /bin/gcore: No such file or directory  The gcore I believe it's looking for is a debugging tool that is able to retrieve images of running processes. I'm guessing that something caused something int the fb to eat crap, and it was stuck trying to debug itself. I can't tell what exactly happend, though. I'll ping the CDS guys about it. The daqd process was continuing to run, but it was not responding to anything, which is why it could not be restarted via the normal means, and maybe why the various FB0_*_STATUS channels were seemingly dead. I manually killed the daqd process, and monit seemed to bring up a new process with no problem. I'll keep an eye on it. 5908 Wed Nov 16 10:13:13 2011 jamieUpdateelogrestarted  Quote: Basically, elog hangs up by the visit of googlebot. Googlebot repeatedly tries to obtain all (!) of entries by specifying "page0" and "mode=full". Elogd seems not to have the way to block an access from the specified IP. We might be able to use http-proxy via apache. (c.f. http://midas.psi.ch/elog/adminguide.html#secure) There are much more simple ways to prevent page indexing by googlebot: http://www.google.com/support/webmasters/bin/answer.py?answer=156449 However, I really think that's a less-than-idea solution to get around the actual problem which is that the elog software is a total piece of crap. If google does not index the log then it won't appear in google search results. But if there is one url that when requested causes the elog to crash then maybe it's a better solution to cut of just that url. 5979 Tue Nov 22 18:15:39 2011 jamieUpdateCDSc1iscex ADC found dead. Replaced, c1iscex working again c1iscex has not been running for a couple of days (since the power shutdown at least). I was assuming that the problem was recurrence of the c1iscex IO chassis issue from a couple weeks ago (5854). However, upon investigation I found that the timing signals were all fine. Instead, the IOP was reporting that it was finding now ADC, even though there is one in the chassis. Since I had a spare ADC that was going to be used for the CyMAC, I decided to try swapping it out to see if that helped. Sure enough, the system came up fine with the new ADC. The IOP (c1x01) and c1scx are now both running fine. I assume the issue before might have been caused by a failing and flaky ADC, which has now failed. We'll need to get a new ADC for me to give back to the CyMAC. 6037 Tue Nov 29 15:30:01 2011 jamieUpdateCDSlocation of currently used filter function So I tracked down where the currently-used filter function code is defined (the following is all relative to /opt/rtcds/caltech/c1/core/release): Looking at one of the generated front-end C source codes (src/fe/c1lsc/c1lsc.c) it looks like the relevant filter function is: filterModuleD()  which is defined in: src/include/drv/fm10Gen.c  and an associated header file is: src/include/fm10Gen.h  6124 Thu Dec 15 11:47:43 2011 jamieUpdateCDSRTS UPGRADE IN PROGRESS ### I'm now in the middle of upgrading the RTS to version 2.4. All RTS systems will be down until futher notice... 6125 Thu Dec 15 22:22:18 2011 jamieUpdateCDSRTS upgrade aborted; restored to previous settings Unfortunately, after working on it all day, I had to abort the upgrade and revert the system back to yesterday's state. I think I got most of the upgrade working, but for some reason I could never get the new models to talk to the framebuilder. Unfortunately, since the upgrade procedure isn't document anywhere, it was really a fly by the seat of my pants thing. I got some help from Joe, which got me through one road block, but I ultimately got stumped. I'll try to post a longer log later about what exactly I went through. In any event, the system is back to the state is was in yesterday, and everything seems to be working. 6302 Tue Feb 21 22:06:18 2012 jamieUpdateLSCbeatbox DFD installed in 1X2 rack I have installed a proto version of the ALS beatbox delay-line frequency discriminator (DFD, formally known as MFD), in the 1X2 rack in the empty space above the RF generation box. That empty space above the RF generation box had been intentionally left empty to provide needed ventilation airflow for the RF box, since it tends to get pretty hot. I left 1U of space between the RF box and the beatbox, and so far the situation seems ok, ie. the RF box is not cooking the beatbox. This is only a temporary arrangement, though, and we should be able to clean up the rack considerably once the beatbox is fully working. For power I connected the beatbox to the two unused +/- 18 V Sorensen supplies in the OMC power rack next to the SP table. I disconnected the OMC cable that was connected to those supplies originally. Again, this is probably just temporary. Right now the beatbox isn't fully functioning, but it should be enough to use for lock acquisition studies. The beatbox is intended to have two multi-channel DFDs, one for each arm, each with coarse and fine outputs. What's installed only has one DFD, but with both coarse and fine outputs. It is also intended to have differential DAQ outputs for the mixer IF outputs, which are not installed in this version. The intended design was also supposed to use a comparator in the initial amplification stages before the delay outputs. The comparator was removed, though, since it was too slow and was limiting the bandwidth in the coarse channel. I'll post an updated schematic tomorrow. I made some initial noise measurements: with a 21 MHz input, which corrseponds to a zero crossing for a minimal delay, the I output is at ~200 nVrms/\sqrt{Hz} at 5 Hz, falling down to ~30 nVrms about 100 Hz, after which it's mostly flat. I'll make calibrated plots for all channels tomorrow. The actual needed delay lines are installed/hooked up either. Either Kiwamu will hook something up tonight, or I'll do it tomorrow. 6318 Fri Feb 24 19:25:43 2012 jamieUpdateLSCALS X-arm beatbox added, DAQ channels wiring normalized I have hooked the ALS beatbox into the c1ioo DAQ. In the process, I did some rewiring so that the channel mapping corresponds to what is in the c1gcv model. The Y-arm beat PD is going through the old proto-DFD setup. The non-existant X-arm beat PD will use the beatbox alpha. Y coarse I (proto-DFD) --> c1ioo ADC1 14 --> C1:ALS_BEATY_COARSE_I Y fine I (proto-DFD) --> c1ioo ADC1 15 --> C1:ALS_BEATY_FINE_I X coarse I (bbox alpha)--> c1ioo ADC1 02 --> C1:ALS_BEATX_COARSE_I X fine I (bbox alpha)--> c1ioo ADC1 03 --> C1:ALS_BEATX_FINE_I  This remapping required coping some filters into the BEATY_{COARSE,FINE} filter bank. I think I got it all copied over correctly, but I might have messed something up. BE AWARE. We still need to run a proper cable from the X-arm beat PD to the beatbox. I still need to do a full noise/response characterization of the beatbox (hopefully this weekend). 6325 Mon Feb 27 18:33:11 2012 jamieUpdatePSLwhat to do with old PSL fast channels It appears that the old PSL fast channels never made it into the new DAQ system. We need to figure out what to do with them. A D990155 DAQ Interface card in far right of the 1X1 PSL EuroCard ("VME") crate is supposed output various PMC/FSS/ISS fast channels, which would then connect to the 1U "lemo breakout" ADC interface chassis. Some connections are made from the DAQ interface card to the lemo breakout, but they are not used in any RTS model, so they're not being recorded anywhere. An old elog entry from Rana listing the various PSL DAQ channels should be used as reference, to figure out which channels are coming out, and which we should be recording. The new ALS channels will need some of these DAQ channels, so we need to figure out which ones we're going to use, and clear out the rest. 6327 Mon Feb 27 19:04:13 2012 jamieUpdateCDSspontaneous timing glitch in c1lsc IO chassis? For some reason there appears to have been a spontaneous timing glitch in the c1lsc IO chassis that caused all models running on c1lsc to loose timing sync with the framebuilder. All the models were reporting "0x4000" ("Timing mismatch between DAQ and FE application") in the DAQ status indicator. Looking in the front end logs and dmesg on the c1lsc front end machine I could see no obvious indication why this would have happened. The timing seemed to be hooked up fine, and the indicator lights on the various timing cards were nominal. I restarted all the models on c1lsc, including and most importantly the c1x04 IOP, and things came back fine. Below is the restart procedure I used. Note I killed all the control models first, since the IOP can't be restarted if they're still running. I then restarted the IOP, followed by all the other control models. controls@c1lsc ~ 0$ for m in lsc ass oaf; do /opt/rtcds/caltech/c1/scripts/killc1${m}; done controls@c1lsc ~ 0$ /opt/rtcds/caltech/c1/scripts/startc1x04
c1x04epics C1 IOC Server started
* Stopping IOP awgtpman ...                                                                      [ ok ]
controls@c1lsc ~ 0$for m in lsc ass oaf; do /opt/rtcds/caltech/c1/scripts/startc1${m}; done
c1lscepics: no process found
ERROR: Module c1lscfe does not exist in /proc/modules
c1lscepics C1 IOC Server started
* WARNING:  awgtpman_c1lsc has not yet been started.
c1assepics: no process found
ERROR: Module c1assfe does not exist in /proc/modules
c1assepics C1 IOC Server started
* WARNING:  awgtpman_c1ass has not yet been started.
c1oafepics: no process found
ERROR: Module c1oaffe does not exist in /proc/modules
c1oafepics C1 IOC Server started
* WARNING:  awgtpman_c1oaf has not yet been started.
controls@c1lsc ~ 0 6348 Fri Mar 2 18:11:50 2012 jamieSummarySUSevaluation of eLIGO tip-tilts from LLO [Suresh, Jamie] Suresh and I opened up and checked out the eLIGO tip-tilts assemblies we received from LLO. There are two, TT1 and TT2, which were used for aligning AS beam into the OMC on HAM6. The mirror assemblies hang from steel wires suspended from little, damped, vertical blade springs. The magnets are press fit into the edge of the mirror assemblies. The pointy flags magnetically attach to the magnets. BOSEMS are attached to the frame. The DCC numbers on the parts seem to all be entirely lies, but this document seems to be close to what we have, sans the vertical blade springs: T0900566 We noticed a couple of issues related to the magnets and flags. One of the magnets on each mirror assembly is chipped (see attached photos). Some of the magnets are also a bit loose in their press fits in the mirror assemblies. Some of the flags don't seat very well on the magnets. Some of the flag bases are made of some sort of crappy steel that has rusted (also see pictures). Overall some flags/magnets are too wobbly and mechanically unsound. I wouldn't want to use them without overhauling the magnets and flags on the mirror assemblies. There are what appear to be DCC/SN numbers etched on some of the parts. They seem to correspond to what's in the document above, but they appear to be lies since I can't find any DCC documents that correspond to these numbers: TT1: D070176-00 SN001 mirror assembly: D070183-00 SN003 TT2: D070176-00 SN002 mirror assembly: D070183-00 SN006  6468 Thu Mar 29 20:13:21 2012 jamieConfigurationPEMPEM_SLOW (i.e. seismic RMS) channels added to fb master I've added the PEM_SLOW.ini file to the fb master file, which should give us the slow seismic RMS channels when the framebuilder is restarted. Example channels: [C1:PEM-RMS_ACC6_1_3] [C1:PEM-RMS_GUR2Y_0p3_1] [C1:PEM-RMS_STS1X_3_10] etc.  I also updated the path to the other _SLOW.ini files. ### I DID NOT RESTART FB. I will do it first thing in the am tomorrow, when Kiwamu is not busy getting real work done. Here's is a the diff for /opt/rtcds/caltech/c1/target/fb/master:h controls@pianosa:/opt/rtcds/caltech/c1/target/fb 1 diff -u master~ master
--- master~	2011-09-15 17:32:24.000000000 -0700
+++ master	2012-03-29 19:51:52.000000000 -0700
@@ -7,11 +7,12 @@
/opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini
/opt/rtcds/caltech/c1/chans/daq/C1MCS.ini
/opt/rtcds/caltech/c1/target/gds/param/tpchn_c1mcs.par
-/cvs/cds/rtcds/caltech/c1/chans/daq/SUS_SLOW.ini
-/cvs/cds/rtcds/caltech/c1/chans/daq/MCS_SLOW.ini
-/cvs/cds/rtcds/caltech/c1/chans/daq/RMS_SLOW.ini
-/cvs/cds/rtcds/caltech/c1/chans/daq/IOP_SLOW.ini
-/cvs/cds/rtcds/caltech/c1/chans/daq/IOO_SLOW.ini
+/opt/rtcds/caltech/c1/chans/daq/SUS_SLOW.ini
+/opt/rtcds/caltech/c1/chans/daq/MCS_SLOW.ini
+/opt/rtcds/caltech/c1/chans/daq/RMS_SLOW.ini
+/opt/rtcds/caltech/c1/chans/daq/IOP_SLOW.ini
+/opt/rtcds/caltech/c1/chans/daq/IOO_SLOW.ini
+/opt/rtcds/caltech/c1/chans/daq/PEM_SLOW.ini
/opt/rtcds/caltech/c1/target/gds/param/tpchn_c1rfm.par
/opt/rtcds/caltech/c1/chans/daq/C1RFM.ini
/opt/rtcds/caltech/c1/chans/daq/C1IOO.ini
controls@pianosa:/opt/rtcds/caltech/c1/target/fb 1   6484 Wed Apr 4 13:25:29 2012 jamieConfigurationPEMPEM_SLOW (i.e. seismic RMS) channels aquiring  Quote: I've added the PEM_SLOW.ini file to the fb master file, which should give us the slow seismic RMS channels when the framebuilder is restarted. Example channels: [C1:PEM-RMS_ACC6_1_3] [C1:PEM-RMS_GUR2Y_0p3_1] [C1:PEM-RMS_STS1X_3_10] etc.  The framebuilder seems to have been restarted, or restarted on it's own, so these channels are now being acquired. Below is a minute trend of a smattering of the available RMS channels over the last five days. 7114 Wed Aug 8 10:15:13 2012 jamieUpdateEnvironmentAnother earthquake, optics damped There were another couple of earthquakes at about 9:30am and 9:50am local. All but MC2 were off the watchdogs. I damped and realigned everything and everything looks ok now. 7142 Fri Aug 10 11:05:33 2012 jamieConfigurationIOOMC trans optics configured Quote: Quote:  Quote: The PDA255 is a good ringdown detector - Steve can find one in the 40m if you ask him nicely. We found a PDA255 but it doesn't seem to work. I am not sure if that is one you are mentioning...but I'll ask Steve tomorrow! I double checked the PDA255 found at the 40m and it is broken/bad. Also there was no success hunting PDs at Bridge. So the MC trans is still in the same configuration. Nothing has changed. I'll try doing ringdown measurements with PDA400 today. Can you explain more what "broken/bad" means? Is there no signal? Is it noisy? Glitch? etc. 7143 Fri Aug 10 11:08:26 2012 jamieUpdateComputersFE Status  Quote: The c1lsc and c1sus screens are red in the front-end status. I restarted the frame builder, and hit the "global diag reset" button, but to no avail. Yesterday, the only thing Den and I did to c1sus was install a new c1pem model. I got rid of the changes and switched to the old one (I ran rtcds build, install, restart), but the status is still the same. The issue you're seeing here is stalled mx_stream processes on the front ends. On the troublesome front ends you can log in and restart the mx_streams with the "mxstreamrestart" command. 7161 Mon Aug 13 16:58:07 2012 jamieUpdateCDSmysterious stuck test points on c1spx model We were not able to open up any test points in the revived c1spx model (dcuid 61). Looking at the GDS_TP screen we found that every test point was being held open (C1:FEC-61_GDS_MON_?). Tried closing all test points, awg and otherwise, with the diag comnand line (diag -l), but it would crash when we attempted to look at the test points for node 61. Rebuild, install, restart of the model had no affect. As soon as awgtpman came back up all the testpoints were full again. I called Alex and he said he had seen this issue before as a problem with the mbuf kernel module. Somehow the mbuf module was holding those memory locations open and not freeing them. He suggested we reboot the machine or restart mbuf. I used the following procedure to restart mbuf: • log into c1iscex as controls • sudo /etc/init.d/monit stop (needed so that monit doesn't auto-restart the awgtpman processes) • rtcds stop all • sudo /etc/init.d/mx_stream stop • sudo rmmod mbuf • sudo modprobe mbuf • sudo /etc/init.d/mx_stream start • sudo /etc/init.d/monit start • rtcds start all Once this was done, all the test points were cleared. Alex seems to think this issue is fixed in a newer version of mbuf. I should probably rebuild and install the updated mbuf kernel module at some point soon to prevent this happening again. Unfortunately this isn't the end of the story, though. While the test points were cleared, the channels were still not available from c1spx. I looked in the framebuilder logs to see if I could see anything suspicious. Grep'ing for the DCUID (61), I found something that looked a little problematic: ... GDS server NODE=25 HOST=c1iscex DCUID=61 GDS server NODE=28 HOST=c1ioo DCUID=28 GDS server NODE=33 HOST=c1ioo DCUID=33 GDS server NODE=34 HOST=c1ioo DCUID=34 GDS server NODE=36 HOST=c1sus DCUID=36 GDS server NODE=38 HOST=c1sus DCUID=38 GDS server NODE=39 HOST=c1sus DCUID=39 GDS server NODE=40 HOST=c1lsc DCUID=40 GDS server NODE=42 HOST=c1lsc DCUID=42 GDS server NODE=45 HOST=c1iscex DCUID=45 GDS server NODE=46 HOST=c1iscey DCUID=46 GDS server NODE=47 HOST=c1iscey DCUID=47 GDS server NODE=48 HOST=c1lsc DCUID=48 GDS server NODE=50 HOST=c1lsc DCUID=50 GDS server NODE=60 HOST=c1lsc DCUID=60 GDS server NODE=61 HOST=c1iscex DCUID=61 ...  Note that two nodes, 25 and 61, are associated with the same dcuid. 25 was the old dcuid of c1spx, before I renumbered it. I tracked this down to the target/gds/param/testpoint.par file which had the following: [C-node25] hostname=c1iscex system=c1spx ... [C-node61] hostname=c1iscex system=c1spx  It appears that this file is just amended with new dcuids, so dcuid changes can show up in duplicate. I removed the offending old stanza and tried restarting fb again... Unfortunately this didn't fix the issue either. We're still not seeing any channels for c1spx. 7162 Mon Aug 13 17:31:19 2012 jamieUpdateCDSmysterious stuck test points on c1spx model  Quote: Unfortunately this didn't fix the issue either. We're still not seeing any channels for c1spx. So I was wrong, the channels are showing up. I had forgotten that they are showing up under C1SUP, not C1SPX. 7163 Mon Aug 13 18:00:30 2012 jamieUpdateGenerallarger optical tables at the ends  Quote: I'm proposing larger optical tables at the ends to avoid the existing overcrowding. This would allow the initial pointing and optical level beams to set up correctly. The existing table is 4 x 2 would be replaced by 4' x 3' We would lose only ~3" space toward exist door. I'm working on the new ACRYLIC TABLE COVER for each end that will cost around4k ea.  The new cover should fit the larger table. Let me know what you think.

I'm not sure I see the motivation.  The tables are a little tight, but not that much.  If the issue is the incidence angle of the IP and OPLEV beams, then can't we solve that just by moving the table closer to the viewport?

The overcrowding alone doesn't seem bad enough to justify replacing the tables.

7165   Mon Aug 13 20:12:29 2012 jamieUpdateCDSc1sup model moved to c1lsc machine

I moved the c1sup simplant model to the c1lsc machine, where there was one remaining available processor.  This requires changing a bunch of IPC routing in the c1sus and c1lsp models.  I have rebuilt and installed the models, and have restarted c1sup, but have not restarted c1sus and c1lsp since they're currently in use.  I'll restart them first thing tomorrow.

7188   Wed Aug 15 09:09:45 2012 jamieUpdateLSCLSC whitening triggers

 Quote: I'm ~30% of the way through implementing LSC whitening filter triggers.  I think that everything I have done should be compile-able, but please don't compile c1lsc tonight.  I haven't tested it, and some channel names have changed, so I need to fix the LSC screen when I'm not falling asleep. Also, Rana pointed out that we may not want the whitening to trigger on immediately upon acquiring lock - if there are other modes ringing down in the cavity, or some weird transients, we don't want to amplify those signals.  We want to wait a second or so for them to die down, then turn on analog whitening.  Jamie - do you know how long the "unit delay" delays things in the RCG?  Do those do what I naively think they do?  I'll ask you in the morning.

The unit delay delays for a single cycle, so I think that's not what you want.  I'm not sure that there's an existing part to add delays like that.

We also need to be a little clever about it, though, since we'll want it to flip off if we loose lock during the delay.

7191   Wed Aug 15 11:44:35 2012 jamieSummaryLSCntp installed on all workstations

 Quote: 5) DTT wasn't working on rossa. Used the Date/Time GUI to reset the system time to match fb and then it stopped giving 'Test Timed Out'. Jamie check rossa ntpd.

ntp is now installed on all the workstations.  I also added it to the /users/controls/workstation-setup.sh script

7197   Wed Aug 15 17:23:22 2012 jamieUpdateCDSfront end IOP models changed to reflect actual physical hardware

As Rolf pointed out when he was here yesterday, all of our IOPs are filled with parts for ADCs and DACs that don't actually exist in the system.  This was causing needless module error messages and IOP GDS screens that were full of red indicators.  All the IOP models were identically stuffed with 9 ADC parts, 8 DAC parts, and 4 BO parts, even though none of the actual front end IO chassis had physical configurations even remotely like that.  This was probably not causing any particular malfunctions, but it's not right nonetheless.

I went through each IOP, c1x0{1-5}, and changed them to reflect the actual physical hardware in those systems.  I have committed these changes to the svn, but I haven't rebuilt the models yet.  I'll need to be able to restart all models to test the changes, so I'm going to wait until we have a quiet time, probably next week.

7249   Wed Aug 22 15:47:34 2012 jamieSummaryGeneralvent prepartion for fast-track vent

We are discussing venting first thing next week, with the goal of
diagnosing what's going on in the PRC.

Reminder of the overall vent plan:

https://wiki-40m.ligo.caltech.edu/vent

Since we won't be prepared for tip-tilt installation (item 2), we should
focus most of the effort on diagnosing what's going on in the PRC.  Of
the other planned activities:

(1) dichroic mirror replacement for PR3 and SR3

Given that we'll be working on the PRC, we might consider going ahead
with this replacement, especially if the folding mirror becomes
suspect for whatever reason.  In any case we should have the new
mirrors ready to install, which means we should get the phase map
measurements asap.

(3) black glass beam dumps:

Install as time and manpower permits.  We need to make sure all needed
components are baked and ready to install.

(4) OSEM mount screws:

Delay until next vent.

(5) new periscope plate:

Delay until next vent.

(6) cavity scattering measurement setup

Delay until next vent.

7287   Mon Aug 27 17:14:00 2012 jamieUpdateCDSc1oaf problem

 Quote: I came in to the lab in the evening and found c1lsc had "red" for FB connection. I restarted c1lsc models and it kept hung the machine everytime. I decided to kill all of the model during the startup sequence right after the reboot. Then run only c1x04 and c1lsc. It seems that c1oaf was the cause, but it wasn't clear.

The "red for FB connection" issue was probably a dead mx_stream on c1lsc.  That can usually be fixed by just restarting mx_stream.

There is definitely a problem with c1oaf, though.  It crashes immediately after attempting to start.  kernel log for a crash included below.

We will leave c1oaf off until we have time to debug.

[83752.505720] c1oaf: Send Computer Number  = 0
[83752.505720] c1oaf: entering the loop
[83752.505720] c1oaf: waiting to sync 19520
[83753.207372] c1oaf: Synched 701492
[83753.207372] general protection fault: 0000 [#2] SMP
[83753.207372] last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:2e:01.0/class
[83753.207372] CPU 4
[83753.207372] Modules linked in: c1oaf c1ass c1sup c1lsp c1cal c1lsc c1x04 open_mx dis_irm dis_dx dis_kosif mbuf [last unloaded: c1oaf]
[83753.207372]
[83753.207372] Pid: 0, comm: swapper Tainted: G      D    2.6.34.1 #5 X7DWU/X7DWU
[83753.207372] RIP: 0010:[<ffffffffa1bf7567>]  [<ffffffffa1bf7567>] T.2870+0x27/0xbf0 [c1oaf]
[83753.207372] RSP: 0000:ffff88023ecc1aa8  EFLAGS: 00010092
[83753.207372] RAX: ffff88023ecc1af8 RBX: ffff88023ecc1ae8 RCX: ffffffffa1c35e48
[83753.207372] RDX: 0000000000000000 RSI: 0000000000000020 RDI: ffffffffa1c21360
[83753.207372] RBP: ffff88023ecc1bb8 R08: 0000000000000000 R09: 0000000000175f60
[83753.207372] R10: 0000000000000000 R11: ffffffffa1c2a640 R12: ffff88023ecc1b38
[83753.207372] R13: ffffffffa1c2a640 R14: 0000000000007fff R15: 0000000000000000
[83753.207372] FS:  0000000000000000(0000) GS:ffff880001f00000(0000) knlGS:0000000000000000
[83753.207372] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[83753.207372] CR2: 000000000378a040 CR3: 0000000001a09000 CR4: 00000000000406e0
[83753.207372] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[83753.207372] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[83753.207372] Stack:
[83753.207372]  ffff88023ecc1ab8 0000000000000096 0000000000000019 ffff88023ecc1b18
[83753.207372] <0> 0000000000014729 0000000000032a0c ffff880001e12d90 000000000000000a
[83753.207372] <0> ffff88023ecc1bb8 ffffffffa1c06cad ffff88023ecc1be8 000000000000000f
[83753.207372] Call Trace:
[83753.207372]  [<ffffffffa1c07ae3>] feCode+0xd63/0x129b0 [c1oaf]
[83753.207372]  [<ffffffffa1c00dc6>] ? T.2888+0x1966/0x1f10 [c1oaf]
[83753.207372]  [<ffffffffa1c1b3bf>] fe_start+0x1c8f/0x3060 [c1oaf]
[83753.207372]  [<ffffffff8104cd8b>] ? enqueue_hrtimer+0x65/0x72
[83753.207372]  [<ffffffff8104d8f6>] ? __hrtimer_start_range_ns+0x2d6/0x2e8
[83753.207372]  [<ffffffff8104d91b>] ? hrtimer_start+0x13/0x15
[83753.207372]  [<ffffffff81001c38>] cpu_idle+0x46/0x8d
[83753.207372]  [<ffffffff814ec523>] start_secondary+0x192/0x196
[83753.207372] Code: 1f 44 00 00 55 66 0f 57 c0 48 89 e5 41 57 41 56 41 55 41 54 53 48 8d 9d 30 ff ff ff 48 8d 43 10 4c 8d 63 50 48 81 ec e8 00 00 00 <66> 0f 29 85 30 ff ff ff 48 89 85 18 ff ff ff 31 c0 48 8d 53 78
[83753.207372] RIP  [<ffffffffa1bf7567>] T.2870+0x27/0xbf0 [c1oaf]
[83753.207372]  RSP <ffff88023ecc1aa8>
[83753.207372] ---[ end trace df3ef089d7e64971 ]---
[83753.207372] Kernel panic - not syncing: Attempted to kill the idle task!
[83753.207372] Pid: 0, comm: swapper Tainted: G      D    2.6.34.1 #5
[83753.207372] Call Trace:
[83753.207372]  [<ffffffff814ef6f4>] panic+0x73/0xe8
[83753.207372]  [<ffffffff81063c19>] ? crash_kexec+0xef/0xf9
[83753.207372]  [<ffffffff8103a386>] do_exit+0x6d/0x712
[83753.207372]  [<ffffffff81037311>] ? spin_unlock_irqrestore+0x9/0xb
[83753.207372]  [<ffffffff81037f1b>] ? kmsg_dump+0x115/0x12f
[83753.207372]  [<ffffffff81006583>] oops_end+0xb1/0xb9
[83753.207372]  [<ffffffff8100674e>] die+0x55/0x5e
[83753.207372]  [<ffffffff81004496>] do_general_protection+0x12a/0x132
[83753.207372]  [<ffffffff814f17af>] general_protection+0x1f/0x30
[83753.207372]  [<ffffffffa1bf7567>] ? T.2870+0x27/0xbf0 [c1oaf]
[83753.207372]  [<ffffffffa1c07ae3>] feCode+0xd63/0x129b0 [c1oaf]
[83753.207372]  [<ffffffffa1c00dc6>] ? T.2888+0x1966/0x1f10 [c1oaf]
[83753.207372]  [<ffffffffa1c1b3bf>] fe_start+0x1c8f/0x3060 [c1oaf]
[83753.207372]  [<ffffffff8104cd8b>] ? enqueue_hrtimer+0x65/0x72
[83753.207372]  [<ffffffff8104d8f6>] ? __hrtimer_start_range_ns+0x2d6/0x2e8
[83753.207372]  [<ffffffff8104d91b>] ? hrtimer_start+0x13/0x15
[83753.207372]  [<ffffffff81001c38>] cpu_idle+0x46/0x8d
[83753.207372]  [<ffffffff814ec523>] start_secondary+0x192/0x196


7289   Mon Aug 27 18:59:24 2012 jamieUpdateIOOMC ASC screen was confusing - Jenne is not stupid

 Quote: We have figured out that some of these measurements, those with the WFS off, were also not allowing the dither lines through, so no dither, so no actual measurement. Jamie is fixing up the model so we can force the WFS to stay off, but allow the dither lines to go through.  He'll elog things later.

In the c1ioo model there were filter modules at the output of the WFS output matrix, right before going to the MC SUS ASCs but right after the dither line inputs, that were not exposed in the C1IOO_WFS_OVERVIEW screen (bad!).  I switched the order of these modules and the dither sums, so these output filters are now before the dither inputs.  This will allow us to turn off all the WFS feedback while still allowing the dither lines.

I updated the medm screens as well (see attached images).

7291   Tue Aug 28 00:16:19 2012 jamieUpdateGeneralAlignment and vent prep

I think we (Jenne, Jamie) are going to leave things for the night to give ourselves more time to prep for the vent tomorrow.

We still need to put in the PSL output beam attenuator, and then redo the MC alignment.

The AS spot is also indicating that we're clipping somewhere (see below).  We need to align things in the vertex and then check the centerings on the AP table.

So I think we're back on track and should be ready to vent by the end of the day tomorrow.

7296   Tue Aug 28 17:02:16 2012 jamieUpdateGeneralsvn commit changes

I just spent the last hour checking in a bunch of uncommitted changes to stuff in the SVN.  We need to be MUCH BETTER about this.  We must commit changes after we make them.  When multiple changes get mixed together there's no way to recover from one bad one.

7309   Wed Aug 29 17:09:57 2012 jamieUpdateSUSETMX OK, free swinging

ETMX appears to be fine.  It was stuck to its OSEMs in the usual way.  I touched it and it dislodged and is now swinging freely.  Damping loops have been re-engaged.

7314   Thu Aug 30 00:08:34 2012 jamieUpdateGeneralIn vac plans for tomorrow, 8/30

 Quote: We need to check spot centering on PRM with camera tomorrow. Suresh checked that we're not clipped by IP ANG/POS pickoff mirrors, but we haven't done any alignment of IP ANG/POS.

I think we should NOT do any adjustment of IP ANG/POS now.  We should in fact try to recover them when doing the PRM spot centering

 Quote: Tomorrow:  Open ITMX door.  Check with Watek that we're hitting center of PRM.  Then look to see if we're hitting center of PR2.  Then, continue through the chain of optics.

The motivation for removing the ITMX door was so that the scatter measurement team could check alignment of the new viewing mirror next to ETMX.  After discussion today we decided that everything can be done at the X end.  They can inject a probe beam into the ETMX chamber, bounce it off of ITMX and align the viewing mirror with the reflection.  So we'll leave ITMX door on for now.

We should, however, inspect the situation ITMY and make sure we have good clearance in the Y arm part of the Michaelson.  Koji previously expressed suspicion that we might have clipping on the southern edge of the POY steering mirror, so we need to check that out.

Koji and I discussed the situation for getting camera face views of BS and PRM.  Koji said the original idea was to see if we could install something at the south-east view port of ITMX chamber.  Steve also suggested utilizing the "ceiling" camera mounted on the top of the IOO chamber.

• check spot centering in PRM
• check that REFL is getting cleanly to the AP table
• check IPPOS and IPANG - we should be adjusting IPPOS or IPANG at this point
• check spot centering on BS
• remove ITMY north door
• check clearance of POY steering mirror
• ...

in parallel:

• Steve will inspect the situation for getting a camera view of BS and PRM face, either through IOO or ITMX.

• install baffle
• install "permanent" ITMX viewing mirror, on west side of ETMX - this might require moving ETMX SUS cable bracket south
• install temporary steering mirror for probe laser on south-east side of ETMX
• at some point the scatter guys can also do transmission measurements of the ETMX view ports
• ...
7318   Thu Aug 30 13:10:41 2012 jamieUpdateCamerasETMX

 Quote: We have done some work at ETMX today. We installed the baffle and placed two mirrors on the table. The baffle position/orientation still needs to be checked more thoroughly to make sure that the beam will pass through the center of the baffle hole.

I must say that I am not at all happy with the baffle situation.  It is currently completely blocking our camera view of the ETMX face.  Here's a video capture of the ETMX face camera:

The circle is the baffle hole, through which we can see just the bottom edge of the test mass.  I don't think whatever benefit the baffle gives out weights the benefit of being able to see the spot on the mirror.

This afternoon we will try to adjust the baffle, and maybe the camera view mirror, to see if we can get a better shot of the center of the TM.  If we can see the beam spot through the hole we can probably live with it.  If not, I think we should remove the baffle.

7324   Thu Aug 30 20:35:09 2012 jamieUpdateSUStarget installed on PRM, temporary earthquake stops in place

We installed beam targets on PRM and BS suspension cages.

On both suspensions one of the screw holes for the target actually houses the set screw for the side OSEM.  This means that the screw on one side of the target only goes in partial way.

The target installed on BS is wrong!  It has a center hole, instead of two 45 deg holes.  I forgot to remove it, but it will obvious it's wrong to the next person who tries to use it.  I believe we're supposed to have a correct target for BS, Steve?

The earthquake stop screws on PRM were too short and were preventing installation of the PRM target.  Therefore, in order to install the target on PRM I had to replace the earthquake stops with ones Jenne and I found in the bake lab clean room that were longer, but have little springs instead of viton inserts at the ends.  This is ok for now, but

### WE NEED TO REMEMBER TO REPLACE EARTHQUAKE STOPS ON PRM WHEN WE CLOSE UP.

We checked the beam through PRM and it's a little high to the right (as viewed from behind).  Tomorrow we're going to open ITMX chamber so that we can get a closer look at the spot on PR2.

7341   Tue Sep 4 20:20:47 2012 jamieUpdateGeneralproblematic tip-tilts

 Quote: We clearly need a better plan for adjusting the tip tilts in pitch, because utilizing their hysteresis is ridiculous.  Koji and Steve are thinking up a set of options, but so far it seems as though all of those options should wait for our next "big" vent.  So for now, we have just done alignment by poking the tip tilt. Tomorrow, we want to open up the MC doors, open up ETMY, and look to see where the beam is on the optic.  I am concerned that the hysteresis will relax over a long ( >1hour ) time scale, and we'll loose our pointing.  After that, we should touch the table enough to trip the BS, PRM optics, since Koji is concerned that perhaps the tip tilt will move in an earthquake.  Jamie mentioned that he had to poke the tip tilt a pretty reasonable amount to get it to change a noticeable amount at ETMY, so we suspect that an earthquake won't be a problem, but we will check anyway.

I'm very unhappy with the tip-tilts right now.  The amount of hysteresis is ridiculous.  I have no confidence that they will stay pointing wherever we point them.  It's true I poked the top more than it would normally move, but I don't actually believe it wouldn't move in an earthquake.  Given how much hysteresis we're seeing, I expect it will just drift on it's own and we'll loose good pointing again.

And as a reminder, IPPOS/ANG don't help us here before the tip-tilts are in the PRC after the IP pointing sensors.

I think we need to look seriously at possible solutions to eliminate or at least reduce the hysteresis, by either adding weight, or thinner wire, or something.

7342   Tue Sep 4 20:25:22 2012 jamieOmnistructureVACbetter in-air "lite" access connector needed

We really need something better to replace the access connector when we're at air.  This tin foil tunnel crap is dumb.  We can't do any locking in the evening after we've put on the light doors.  We need something that we can put in place of the access connector that allows us access to the OMC and IOO tables, while still allowing IMC locking, and can be left in place at night.

7344   Wed Sep 5 10:50:15 2012 jamieOmnistructureVACbetter in-air "lite" access connector needed

Quote:

 Quote: We really need something better to replace the access connector when we're at air.  This tin foil tunnel crap is dumb.  We can't do any locking in the evening after we've put on the light doors.  We need something that we can put in place of the access connector that allows us access to the OMC and IOO tables, while still allowing IMC locking, and can be left in place at night.

It is in the shop. It will be ready for the next vent. Koji's dream comes through.

Can we see the full design?  If we can't lock the mode cleaner with this thing on then it's really of no use.  We want it to be equivalent to the light doors, but allow us to keep the mode cleaner locked.  That's the most important aspect.

7345   Wed Sep 5 13:11:43 2012 jamieOmnistructureVACbetter in-air "lite" access connector needed

Quote:

Quote:

 Quote: We really need something better to replace the access connector when we're at air.  This tin foil tunnel crap is dumb.  We can't do any locking in the evening after we've put on the light doors.  We need something that we can put in place of the access connector that allows us access to the OMC and IOO tables, while still allowing IMC locking, and can be left in place at night.

It is in the shop. It will be ready for the next vent. Koji's dream comes through.

Can we see the full design?  If we can't lock the mode cleaner with this thing on then it's really of no use.  We want it to be equivalent to the light doors, but allow us to keep the mode cleaner locked.  That's the most important aspect.

It also needs to be wide enough that the MMT beam can go through, so that we can not only lock the MC, but also work on the rest of the IFO.

7442   Wed Sep 26 16:59:30 2012 jamieUpdateIOOIPANG ND filter installed

 Quote: [Whomever took away this ND filter without elogging it was BAD!!!  (Jamie, when we first found IPANG coming out of the vacuum during this vent, we moved some of the mirrors on the out-of-vac table in the IPANG path.  Was the ND filter removed at that time?  Or has it been out for much longer, and we never noticed because IPANG wasn't coming nicely out of the vacuum / was clipping on the oplev lens?)

I do not remember removing anything from that setup.  We just moved some mirrors and lenses around

7457   Mon Oct 1 16:05:01 2012 jamieUpdateCDSmx stream restart required on all front ends

For some reason the frame builder and mx stream processes on ALL front ends were down.  I restarted the frame builder and all the mx_stream processes and everything seems to be back to normal.  Unclear what caused this.  The CDS guys are aware of the issue with the mx_stream stability and are working on it.

ELOG V3.1.3-