40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 283 of 344 Not logged in
ID Date Author Type Category Subject
10405   Fri Aug 15 20:38:17 2014 ericqUpdateGeneralELOG dump

A few things that I have neglected to ELOG yet:

• scripts/offsets/LSCoffsets is a new script that uses ezcaservo to set FM offsets of our LSC PDs. It still warns about large changes, and lets you revert. It reads the FM gain to pick the right gain for the ezcaservo call.

• MC refl DC was all over the place today, and has recently been "fuzzier" on the wall StripTool than I like. I touched the MC2 pointing a little bit, and the WFS seemed to find a sweet spot where the refl got steady back at around and under 0.5. I then ran "offload WFS" to try and stay there.

• Incidentally, the PMC transmission drifted up to 0.81 at some point today. This is weird, since not too long ago, we were not able to reach this level even with careful alignment. This coincided with the MC power being back up to ~17k, and arms locking at around 0.95.

• Last week I quickly tried cranking up the x-end green modulation frequency to ~1.3MHz (corresponding to a notch in the PZT AM response), and using a 550k lowpass on the mixer output, instead of a 70k, to try to buy more phase and increase the UGF. It didn't work. I didn't have a way to tune the mixer phase angle, and the mixer output was super noisy, but there were instants where I could convince myself that a mode was briefly locked to the arm... I'm going to do the Right Thing and characterize the loop properly, to figure out how to get at least 10kHz of control bandwidth out of these things.

1119   Thu Nov 6 22:07:56 2008 ranaConfigurationComputersELOG compile on Solaris
From the ELOG web pages:

Solaris:

Martin Huber reports that under Solaris 7 the following command line is needed to compile elog:

gcc -L/usr/lib/ -ldl -lresolv -lm -ldl -lnsl -lsocket elogd.c -o elogd

With some combinations of Solaris servers and client-side browsers there have also been problems with ELOG's keep-alive feature. In such a case you need to add the "-k" flag to the elogd command line to turn keep-alives off.
10877   Thu Jan 8 03:40:50 2015 ericqUpdateComputer Scripts / ProgramsELOG 3.0

I've installed the very fresh ELOG 3.0, for nothing else than the new built in text editor which has a LATEX capable equation editor built right in.

Check out this sweet limerick:

$\int_{1}^{\sqrt[3]{3}}t^2 dt\, \textbf{cos}(\frac{3\pi}{9}) = \textbf{ln}(\sqrt[3]{e})$

10878   Thu Jan 8 09:24:40 2015 jamieUpdateComputer Scripts / ProgramsELOG 3.0
 Quote: I've installed the very fresh ELOG 3.0, for nothing else than the new built in text editor which has a LATEX capable equation editor built right in.  Check out this sweet limerick:  $\int_{1}^{\sqrt[3]{3}}t^2 dt\, \textbf{cos}(\frac{3\pi}{9}) = \textbf{ln}(\sqrt[3]{e})$

$\int \omega \epsilon \varepsilon \Gamma$

3784   Tue Oct 26 10:50:08 2010 KojiConfigurationelogELOG 2.8.0 -> ELOG 2.7.5 -> ELOG 2.8.0

ELOG restarted with 2.8.0 again.

- moved elog-2.8.0/script dir to elog-2.8.0/script.orig

- copied elog-2.7.5/script to elog-2.8.0/script

- /cvs/cds/caltech/elog/start-elog.csh reconfigured to launch 2.8.0

- /cvs/cds/caltech/elog/elog is linked to ./elog-2.8.0

- logbooks on 25th and 26th were copied from 2.7.5 to 2.8.0.

3780   Mon Oct 25 23:59:37 2010 KojiConfigurationelogELOG 2.8.0 -> ELOG 2.7.5

ELOG reverted to 2.7.5 due to editing difficulties

- /cvs/cds/caltech/elog/start-elog.csh reconfigured to launch 2.7.5

- /cvs/cds/caltech/elog/elog is linked to ./elog-2.7.5

- logbook dir of 2.8.0 was copied in the dir of 2.7.5. The old and obsolete 2.7.5 was discarded.

3783   Tue Oct 26 07:02:05 2010 AlbertoConfigurationelogELOG 2.8.0 -> ELOG 2.7.5

 Quote: ELOG reverted to 2.7.5 due to editing difficulties - /cvs/cds/caltech/elog/start-elog.csh reconfigured to launch 2.7.5 - /cvs/cds/caltech/elog/elog is linked to ./elog-2.7.5 - logbook dir of 2.8.0 was copied in the dir of 2.7.5. The old and obsolete 2.7.5 was discarded.

I think I had the same problem when I switched to 2.75 from 2.65.

Then the problem was FCKeditor.

We should try the solution I put in the elog page of the wiki.

3772   Sun Oct 24 19:23:41 2010 ranaConfigurationelogELOG 2.8.0
I stopped the ELOG and restarted us on 2.8.0.

To make sure nothing got lost, I killed the old process, copied over the logbooks/, themes/, and elogd.cfg to the new 2.8.0/ directory before starting the new Daemon.

To restart the ELOGD on NODUS, you now type '/cvs/cds/caltech/elog/start-elog.csh'.
I also added ELOG to the man pages in /usr/local/man/ on nodus by putting the *.1 files in man1/ and the *.8 files into man8/.
3775   Mon Oct 25 02:23:47 2010 KojiConfigurationelogELOG 2.8.0
When I push the reply button, the raw html shows up in the edit window and have to use HTML to write the entry.
Does this happen only to me???

 Quote: I stopped the ELOG and restarted us on 2.8.0. To make sure nothing got lost, I killed the old process, copied over the logbooks/, themes/, and elogd.cfg to the new 2.8.0/ directory before starting the new Daemon. I encountered the same Administrator bug as Joe had before. I delete all the old Admin passwords to bypass the issue. To restart the ELOGD on NODUS, you now type '/cvs/cds/caltech/elog/start-elog.csh'. I also added ELOG to the man pages in /usr/local/man/ on nodus by putting the *.1 files in man1/ and the *.8 files into man8/.
11238   Thu Apr 23 08:43:40 2015 SteveUpdateElectronicsEG&G InGaAs diodes in stock

RFpds box is moved from RF cabinet E4 to clean cabinet S15

Inventory updated at https://wiki-40m.ligo.caltech.edu/RF_Pd_Inventory

Large Area InGaAs PIN Photodiode -- C30642GH      6 pieces in stock

## Product Details in: Photodiodes

Large Area InGaAs PIN Photodiode with a 2,0 mm active diameter chip in TO-5 package with flat glass window

Large area InGaAs PIN photodiode with useful diameter of 2,0 mm in a T0-5 package with a flat glass window. The C30642GH provides high quantum efficiency from 800nm to 1700nm. It features high responsivity, high shunt resistance, low dark current, low capacitance for fast response time and uniformity within 2% across the detector active area.

7916   Fri Jan 18 00:41:34 2013 JenneUpdateLockingDust?

I was thinking tonight about more possible reasons that our PRC sucks, and I wonder if dust on the BS could create the problem.

Historically, Kiwamu and I found a few dust particle scattering centers every time we inspected the test masses before drag wiping. Sometimes, there would be one frustratingly close to the center of the optic. I'm not sure if we ever made note of how many we saw and where they were, except out loud to the assembled crowd.

Anyhow, the BS is the only IFO optic that was not replaced, so I'm not sure how long it has been since it was cleaned. If the PR-flat cavity looks okay and we take out the BS to do a PRM-ITMY cavity, we should inspect the beam splitter.

Also, the PRM could need cleaning, but at least it has been drag wiped within recent memory.

My question is, could a few scattering centers cause the behavior that we are seeing?

EDIT:  List o' elogs....

Elog 5301 - Some details on dust seen on ITMs and ETMs, Aug 2011.

Elog 4084 - Kiwamu's in-situ drag wiping how-to, with details on some of the dust we saw. Dec 2010.

Elog 3736 - PRM drag wiped before suspension (Oct 2010)

Elog 3111 - June 2010, BS drag wiped.

7918   Fri Jan 18 12:08:08 2013 KojiUpdateLockingDust?

No

 Quote: My question is, could a few scattering centers cause the behavior that we are seeing?

5563   Wed Sep 28 07:46:42 2011 steveUpdateSUSDsub connections at the back of 1X5 are fixed

I'm turning  the sus damping  off for Dsub connection fix at  the back of 1X5 rack

The plan is to install 4-40 jack screws to lock connector positions.

All dewittening(or called coil driver) and wittening D sub connectors are locked with two 4-40 socket head screws

2538   Thu Jan 21 11:08:30 2010 kiwamu, steveUpdateVACDry Pump replacement

This morning I and Steve replaced  the dry fore pump of TP3, which is located under the y-arm.

After replacing it we confirmed vacuum normal condition. The fore line pressure of TP3 went down to 11 mTorr from 750 mTorr

Attached picture is new pump after setup.

1158   Sat Nov 22 10:55:51 2008 CarynConfigurationIOODrum modes Lock-In settings changed
I unhooked the MC Demod Board's Qmon signal from the Lock-In. Set the demodulation frequency to 31.11Hz with 1V amplitude, and
put the output into MC_DRUM1. DTT showed a ~30Hz peak. Dataviewer showed signal with amplitude ~20,000.
Otherwise the settings were as Rana had them: Time Constant-100us,24dB/Sensitivity-200us/Low Noise
Want to check if Lock-In frequency drifts.
1142   Mon Nov 17 20:47:19 2008 CarynSummaryGeneralDrove MC at 28kHz to excite drum modes
Rana, Alberto and I observed drum mode frequencies at 23.221kHz(MC1), 28.039kHz(MC2), 28.222kHz(MC3) while driving the mode cleaner. We observed no peaks when we didn't drive the mode cleaner. We used the SR785 to send a ~80mV noise signal in the 28-28.2kHz band to the mode cleaner mirrors via 1Y4-MC1,2,3-POSIN. Then we looked at 1Y2-Mode Cleaner-Qmon on the SR785 and saw peaks.
9686   Mon Mar 3 21:50:35 2014 JenneUpdateComputer Scripts / ProgramsDropbox installed on Workstations

I have installed Dropbox on the 40m workstations, using the foteee account.

I put it in /users/Dropbox.

As a side note, I did the install while sitting on Pianosa, but since I put the folder on the mounted hard drive, I think we should be able to use it from any workstation, although I have not yet confirmed this.

8804   Mon Jul 8 13:45:19 2013 gautamConfigurationendtable upgradeDriver board verification

With the help of an expansion card,  I verified that the + 15V and + 24V from the eurocrate in the slot I've identified for the PZT driver boards are making their way to the board. The slot is at the right-most end of the eurocrate in 1Y4, and the rack door was getting in the way of directly measuring these voltages once I hooked up the driver board to the expansion card. So I just made sure that all the LEDs on the expansion card lit up (indicating that the eurocrate is supplying + 5, + 15 and + 24V), and then used a multimeter to check continuity between the expansion card and the driver board outside of the eurocrate. The circuit only uses + 15V and + 24V, and I checked for continuity at all the IC pins marked with these voltages on the schematic.

Since the whole point of this test was to see if the slot I identified was delivering the right voltages, I think this is sufficient. I will now need to fashion a cable that I can use to connect a DC power supply to the PZT driver boards so that these can be tested further.

The high voltage points (100V DC) remain to be tested.

2180   Thu Nov 5 16:24:40 2009 JenneUpdateGeneralDrill Press is down for the count

The on/off switch for the drill press is broken.  Replacement parts should be here tomorrow.

2218   Mon Nov 9 15:21:37 2009 JenneUpdateGeneralDrill Press is down for the count

 Quote: The on/off switch for the drill press is broken.  Replacement parts should be here tomorrow.

Drill press is all better now.  A spare switch is in the top drawer with the drill bits.

31   Tue Oct 30 16:55:40 2007 tobinRoutine Drag-wiping perfected
Steve, Tobin

Steve procured an assortment of syringes from the bio storeroom and we practiced drag-wiping the SOS in the flow bench. Using a 50 microliter Hamilton syringe to deliver 16 microliters of methanol seems perfect for drag-wiping the small optics. Drag-wiping in the downward direction seems to work very well, since we can squirt the optic directly in the center, and the (half) piece of kodak lens tissue fits easily between the bottom two earthquake stops.
5301   Thu Aug 25 13:10:42 2011 JenneUpdateSUSDrag wiping

As we have seen in the past, both of the ITMs were more dusty than the ETMs, presumably because we have the vertex open much more often than the ends.  Kiwamu and I wiped all of the optics until we could no longer see any dust particles within a ~1.5 inch diameter area around the center.

Since we have ITMX out for magnet gluing, I'll probably drag wipe both front and back surfaces before putting it back in the suspension cage.  All of the optics have clear dust on the AR surfaces, but we can't get to that surface while the optics are suspended.  For the ETMs this isn't too big of a deal, but it does concern me a bit for the ITMs and other transmissive optics we have.  I don't think it's bad enough yet though to warrant removing optics from suspensions just to wipe them.

5805   Fri Nov 4 00:25:49 2011 ZachUpdateSUSDr. SUS paths updated--question of human oversight remains
• I have replaced all instances of /cvs/cds/rtcds with /opt/rtcds in the Dr. SUS code.
• We discussed placing a human in charge of whether or not the input matrices get written to the frontend. I am not sure if we reached a definitive conclusion. Currently, the code is set to write the matrices automatically. What to do?
• If we decide that oversight is necessary, I suggest that we leave the publishing of the results to the elog intact. This way, it will be someone's job to read the weekly Dr. SUS diagnosis on Sunday night (or Monday morning), and run a simple script that writes the matrices. This seems like the most reasonable solution.

I await responses...

5814   Fri Nov 4 19:30:06 2011 ranaUpdateSUSDr. SUS paths updated--question of human oversight remains

My inclination is to not do the writing of the matrices automatically nor to do the weekly kicks. Its nice to have long locks of the MC, etc.

I suggest just making the kick on Sundays when someone intentionally asks for it (e.g. by pressing a button on Friday). The free-swinging ringdown ought to be a opt-in kind of feature, not opt-out.

5822   Sat Nov 5 21:19:08 2011 ZachUpdateSUSDr. SUS paths updated--question of human oversight remains

Ok, here's the deal:

• For the time being, I have written a "doirun" bit into runDrSUS (i.e. it runs if doirun is 1 and doesn't if it's 0). This is a bad way of doing this, so in the end I think we should put a switch on the IFO MEDM and have the script read the value when the cron job is run. If you want it to be an opt-in rather than a toggle, we can have the script write it back to 0 every time. I don't know how to do this yet because I am an MEDM n00b, but I will do it soon.
• Since we have decided to keep a human in the loop on the writing to the frontend, I have kept the elog results push.
• I have also edited diagAllSUS.m so that it archives all computed matrices (hierarchy: .../scripts/SUS/peakFit/inMats/(gps_time_of_kick)/inMat(optic_name).mat). There is a 'writematrices' bit in the M-file, currently set to 0.
• I have written the script 'writeAllInMats' and the accompanying M-file 'writeAllInMats.m'. This allows the user to write whichever set of input matrices he or she desires (syntax: writeAllInMats (gps_time_of_kick)). If no argument is given, then it reads the most recent kick time from 'kickAll.time' and writes the corresponding matrices.

So, here is an example of how this works:

1. Someone decides to do a diagonalization on a particular weekend, (eventually) clicking a switch in MEDM
2. Cron runs runDrSUS at 8am that Sunday. This:
1. Kicks all the optics, lets them swing for 5 hours, then reengages the watchdogs. The kick time is saved in kickAll.time, and an alert is posted to the elog
2. Runs diagAllSUS, which computes and saves all matrix data. A report of the results is posted to the elog.
3. On Monday morning---or whenever---someone looks at the entry and decides whether or not to write the files
1. If the results are good, he or she runs writeAllInMats and the latest matrices are written
2. If the results are bad, he or she does nothing. The matrices are still archived and can be written at any time in the future.

The code is set to run tomorrow morning. Everything but the writing will be done.

 Quote: My inclination is to not do the writing of the matrices automatically nor to do the weekly kicks. Its nice to have long locks of the MC, etc. I suggest just making the kick on Sundays when someone intentionally asks for it (e.g. by pressing a button on Friday). The free-swinging ringdown ought to be a opt-in kind of feature, not opt-out.

5824   Sun Nov 6 16:58:25 2011 ZachUpdateSUSDr. SUS failed--NDS2 problems again

Dr. SUS failed while trying to get the sensor data. Specifically, it couldn't get ETMY data. This is odd, because in my tribulations last week I ended up having to add the ETMY_SENSOR channels manually into the NDS2 channel files. After doing this, I was able to get ETMY data just fine (though I admitted that we would have problems again as soon as we wanted to update the channel files). I even ran the diagAllSUS code in a sandbox and it pulled data---and generated input matrices---just fine.

The error persists even if I try to get the data manually:

>> d = NDS2_GetData({'C1:SUS-ETMY_SENSOR_UL'},t0,10,'mafalda.martian:31200');

Connecting.... authenticate done

Warning: daq_recv_next failed

??? Error using ==> NDS2_GetData

Fatal Error getting channel data.

I think Jamie is still waiting for J.Z.'s help with this, but it is probably pointless to keep trying to run this code before NDS2 is working again. Another option is to just use NDS, but I think certain people are opposed to this.

3583   Fri Sep 17 12:11:42 2010 josephbUpdateCDSDowns update

In doing a re-inventory prior to the IOO chassis installation, I re-discovered we had a missing interface board that goes in an IO chassis.  This board connects the chassis to the computer and lets them talk to each other.  After going to Downs we remembered Alex had taken a possibly broken interface board back to downs for testing.

Apparently the results of that testing was it was broken.  This was about 2.5 months ago and unfortunately it hadn't been sent back for repairs or a replacement ordered.  Its my fault for not following up on that sooner.

I asked Rolf what the plan for the broken one was.  His response was  they were planning on repairing it, and that he'd have it sent back for repairs today.  My guess the turn around time for that is on the order of 3-4 weeks (based on conversations with Gary), however it could be longer.  This will affect when the last IO chassis (LSC) can be made fully functional.  I did however pickup the 100 foot fiber cable for going between the LSC chassis and the LSC computer (which will be located in 1X3).

As a general piece of information, according to Gary the latest part number for these cards is OSS-SHB-ELB-x4/x8-2.0 and they cost 936 dollars (latest quote).

11516   Wed Aug 19 01:45:10 2015 IgnacioUpdateIOODoubly Improved SISO (T240-X) FF of MCL

Today I tried and doubly-improved SISO FF filter on MCL. This filter has a stronger rolloff than the previous SISO filters I have tried. The rolloff most definelty helped towards reducing the ammount of noise being injected into YARM. Below is the usual stuff:

Filter:

T240-X (SISO)

Training data + Predicted FIR and IIR subtraction:

Online subtraction results:

MCL
YARM
MCL TRANS

Subtraction performace:

7250   Wed Aug 22 16:50:09 2012 JenneUpdateLockingDouble integrator in ARM LSC servos

Last week, Rana changed the integrators in the arm LSC servo filters to be double integrators with complex poles.

Yesterday, I found that using the "timeout" feature of Foton (at filter ON/OFF request, waits for zero crossing, or T seconds, whichever comes first) is useful for turning on the integrators, but bad for turning them off.  When we're locked, the error signal is oscillating around zero, so there is often a zero crossing.  When we lose lock, we want to turn off the filter immediately.  But, as soon as lock is lost, the input signal gets large, and doesn't often cross zero, so the filter waits 8 seconds until actually turning off.  If the arm flashes any time during that 8 sec, we send a big kick to the optics.

An alternative option could be ramping the filter on.  However, since the double integrator has -180deg phase at low frequencies (until the poles at ~5Hz), the transition between no filter (0deg phase) and integrator on could be problematic.  I simulated this, and find that for the very beginning of the ramping process, we would have a problem.

The filter is defined as:  NoFilter * (1 - R) + Integrator * (R), so for R=0, the integrator is off, and for R=1, the integrator is fully on.  R can be any value [0,1].

The first figure is the time series (1 second, 16kHz), ramp goes from 0->1 or 1->0 in 1 second:

The second figure is bode plots for selected values of R:

As R gets smaller and smaller, the notch goes to lower frequency, and becomes higher Q.  So perhaps ramping is not a good answer here.

What if we go for single or triple integrator, to get rid of the (+1) + (-1) problem?

7432   Mon Sep 24 16:59:31 2012 JenneUpdateVACDoors on, ready to pump

[The 40m Family]

The access connector and all heavy doors are back on.

Jamie put the regular viton EQ stops back on PRM, since he had to adjust the distance between the EQ stops and the PRM anyway.  Jamie also waved an IR card near the IPANG steering mirrors in ETMY, but it was not possible to take a good photo.  Jamie certifies that the beam is centered on both of those 2 optics.

I have centered IPPOS and IPANG QPDs.

All oplevs need a little realignment, especially ETMY, which had it's lens removed (Rana has a Wall of Shame photo of this, which is why it was removed by him).  Steve will look into this tomorrow, after he starts pumping.

I have turned off all PZT high voltage supplies for in-vac PZTs: The input PZTs, the output PZTs, and the OMC PZTs (which weren't on, but I confirmed they were off).

I have also prepared the 3 low-power items for high power: MC refl's path was changed back to regular BS, AS camera was moved to its nominal position, and IPPOS has its ND filters back.  MC refl and the AS camera will need to be realigned once we're actually at high power tomorrow afternoon.

Long vent, but good work everyone.

 Quote: All oplevs need a little realignment, especially ETMY, which had it's lens removed (Rana has a Wall of Shame photo of this, which is why it was removed by him).  Steve will look into this tomorrow, after he starts pumping.

The shame:

There is no situation in which it is OK to install a mount like this. Steve had installed this flaky and shaky mount to optimize the beam size on the OL QPD.

Everyone in the lab should know better. Putting in something like this is just like sabotage - it creates extra noise in our interferometer in a sneaky way and just makes locking harder. All mounts for anything useful (including QPDs) must have highly rigid mounts.

Use the example from the PSL relayout: use the 3/4" steel mounts and the wide aluminum bases from Newport. No more art projects using home made mounting crap, Steve.

15932   Wed Mar 17 15:02:06 2021 gautamUpdatesafetyDoor to outside from control room was unlocked

I came into the lab a few mins ago and found the back door open. I closed it. Nothing obvious seems amiss.

Caltech security periodically checks if this door is locked but it's better if we do it too if we use this door for entry/exit.

15938   Thu Mar 18 12:35:29 2021 ranaUpdatesafetyDoor to outside from control room was unlocked

I think this is probably due to the safety tour yesterday. I beleive Jordan showed them around the office area and C&B. Not sure why they left through the control room.

 Quote: I came into the lab a few mins ago and found the back door open. I closed it. Nothing obvious seems amiss. Caltech security periodically checks if this door is locked but it's better if we do it too if we use this door for entry/exit.

16867   Fri May 20 12:42:23 2022 TegaUpdateVACDoor installation on the end stations

[JC, Tega, Chub]

Today we installed the 200 lbs doors on the end station chambers.

14578   Thu Apr 25 18:14:42 2019 AnjaliUpdatePSLDoor broken

It is noticed that one of the doors (door # 2 ) of the PSL table is broken. Attachement #1 shows the image

11837   Wed Dec 2 15:08:41 2015 ericqUpdateComputer Scripts / ProgramsDonatella sudo problem resolved

Somehow, the controls user account on donatella lost its membership to the sudoers group, which meant doing anything that needs root authentication was impossible.

I fixed this by booting up from a Linux install USB drive, mounting the HD, and running useradd controls sudo

2961   Thu May 20 20:03:37 2010 JenneUpdateSAFETYDon't walk down the Y(new convention) arm tonight!

Please don't go down the Yarm (Old Xarm) for right now, or if you do, please be very careful.  Kiwamu and I are set up to take beam scan measurements down the walkway, and so there are some cables / carts / other stuff down there.  We are going to get dinner really quickly before beginning the measurements.

Right now, the PSL shutter is Closed, so there is no beam hazard outside of the chambers, just crowded space hazard.

2962   Fri May 21 00:21:24 2010 JenneUpdateSAFETYDon't walk down the Y(new convention) arm tonight!

All clear.

 Quote: Please don't go down the Yarm (Old Xarm) for right now, or if you do, please be very careful.  Kiwamu and I are set up to take beam scan measurements down the walkway, and so there are some cables / carts / other stuff down there.  We are going to get dinner really quickly before beginning the measurements.  Right now, the PSL shutter is Closed, so there is no beam hazard outside of the chambers, just crowded space hazard.

7278   Sun Aug 26 20:58:21 2012 JenneUpdateVACDon't vent!!!!

[Koji, Jenne]

Steve, do not vent tomorrow morning!  We are still not prepared, and will not finish the preparation tonight.  Hopefully we can finish the prep tomorrow, and then vent Tues.

Things we need to do before the vent:

MC spots centered [Jenne, tonight]

Use PZT2, BS to hit ~center of ETMs.

Realign arms, measure spot positions.

Make sure BS, ITMs are good - we want a good AS spot since we'll likely have to adjust some AS optics while we're inside

Insert attenuation optics, recover MC trans by rotating PBS cube to translate beam slightly

12376   Thu Aug 4 17:57:09 2016 KojiConfigurationGeneralDon't restart apache2 - nodus /etc/apache2/sites-available/* accidentally deleted

Late coming elog about the deletion of the apahce config files

Thu Aug 4 8:50ish 2016

I accidentally deleted four files in /etc/apache2/sites-available / on nodus. The deleted files were

elog   nodus  public_html  svn

I believe public_html is not used as it is not linked from /etc/apache2/sites-enabled

They are the web server config files and need to be reconfigured manually. We have no backup.

Currently all the web services are running as it was. However, once apache2 is restarted, we'll lose the services.

602   Mon Jun 30 13:48:47 2008 John, RobConfigurationPSLDon't put the bin in front of the air conditioning unit
We spotted that the laser power was dropping.

The air conditioning unit was blocked by the blue bin/trash can/cestino causing the laser head temp to increase by 2 degrees.

603   Mon Jun 30 14:07:26 2008 RobConfigurationPSLDon't put the bin in front of the air conditioning unit

 Quote: We spotted that the laser power was dropping.

the offending configuration:
4985   Mon Jul 18 21:06:32 2011 PSL Table GuardianOmnistructurePSLDon't leave the PSL table open, unattended!!!!!!!!!!!!11111

I found the PSL table left open, and unattended again.

As far as I know, Jamie and Jenne (working on the LSC rack, so no lasers / optics work involved) have been the only ones in the IFO room for several hours now.

I'm going to start taking laser keys, or finding other suitable punishments.  Like a day of lab cleanup chores or something.  Seriously, don't leave the PSL table open if you're not actively working on it.

184   Mon Dec 10 13:54:26 2007 robHowToComputer Scripts / ProgramsDon't blame the Matlab compiler

For human error. We should be careful to only run the compiler outside the mDV directory (thus placing the _mcr outside of the range the addpath command in the mdv_config files). Or maybe there's a smarter solution...
5841   Tue Nov 8 17:48:21 2011 MirkoUpdateCDSDolphin weirdness

Had since yesterday evening some trouble with getting a channel from rfm on c1sus to oaf on c1lsc via dolphin. Several restarts of c1lsc and c1sus didn't help. At some point this morning a restart of c1lsc helped. Everything ok again.
At the bad time the dolphin TF looked like this:

Should be flat at gain 1 and no phase change obviously.

4045   Mon Dec 13 11:56:32 2010 josephb, alexUpdateCDSDolphin is working

## Problem:

The dolphin RFM was not sending data between c1lsc and c1sus.

## Solution:

Dig into the controller.c code located in /opt/rtcds/caltech/c1/core/advLigoRTS/src/fe/.  Find this bit of code on line 2173:

2173 #ifdef DOLPHIN_TEST 2174 #ifdef X1X14_CODE 2175         static const target_node = 8; //DIS_TARGET_NODE; 2176 #else 2177         static const target_node = 12; //DIS_TARGET_NODE; 2178 #endif 2179         status = init_dolphin(target_node);

Replace it with this bit of code:

2173 #ifdef DOLPHIN_TEST 2174 #ifdef C1X02_CODE 2175         static const target_node = 8; //DIS_TARGET_NODE; 2176 #else 2177         static const target_node = 4; //DIS_TARGET_NODE; 2178 #endif 2179         status = init_dolphin(target_node);

Basically this was hard coded for use at the site on their test stands.  When starting up, the dolphin adapter would look for a target node to talk to, that could not be itself.  So, all the dolphin adapters would normally try to talk to target_node 12, unless it was the X1X14 front end code, which happened to be the one with dolphin node id 12.  It would try to talk to node 8.

Unfortunately, in our setup, we only had nodes 4 and 8.  Thus, both our codes would try to talk to a nonexistent node 12.  This new code has everyone talk to node 4, except the c1x02 process which talks to node 8 (since it is node 4 and can't talk to itself).

I'm told this stuff is going away in the next revision and shouldn't have this hard coded stuff.

## Different Dolphin Problem and Fix:

Apparently, the only models which should have pciRfm=1 are the IOP models which have a dolphin connection.  Front end models that are not IOP models (like c1lsc and c1rfm) should not have this flag set.  Otherwise they include the dolphin drivers and causes them and the IOP to refuse to unload when using rmmod.

So pciRfm=1 only in IOP models using Dolphin, everyone else should not have it or should have pciRfm=-1.

Current CDS status:

 MC damp dataviewer diaggui AWG c1ioo c1sus c1iscex RFM Dolphin RFM Sim.Plant Frame builder TDS
4815   Tue Jun 14 09:25:17 2011 JamieUpdateCDSDolphin fiber tested with c1sus, still bad

The bad Dolphin was still bad when tested with a connection between c1sus and the Dolphin swtich.

I'm headed over to Downs to see if we can resolve the issue with the PCIe extension fiber.

4809   Mon Jun 13 15:33:55 2011 Jamie, JoeUpdateCDSDolphin fiber between 1Y3 and 1X4 appears to be dead

The fiber that connects the Dolphin card in the c1lsc machine (in the 1Y3 rack) to the Dolphin switch in the 1X4 rack appears to have died spontaneously this morning.  This was indicated by loss of Dolphin communication between c1lsc and c1sus.

We definitively tracked it down to the fiber by moving the c1lsc machine over to 1X4 and testing the connection with a short cable.  This worked fine.  Moving it back to using the fiber again failed.

Unfortunately, we have no replaced Dolphin fiber.  As a work around, we are stealing  a long computer->IO chassis cable from Downs and moving the c1lsc machine to 1X4.

This is will be a permanent reconfiguration.  The original plan was to have the c1lsc machine also live in 1X4.  The new setup will put the computer farther from the RF electronics, and more closely mimic the configuration at the sites, both of which are good things.

10019   Tue Jun 10 11:54:36 2014 ZachConfigurationWikiDokuWikis are still down

Not sure if someone is already on this, but the nodus DokuWikis are still down (AIC, ATF, Cryo, etc.)

I get:

# DokuWiki Setup Error

The datadir ('pages') does not exist, isn't accessible or writable. You should check your config and permission settings. Or maybe you want to run the installer

10021   Tue Jun 10 19:11:27 2014 EvanConfigurationWikiDokuWikis are back up

As of this writing, the DokuWiki appears to be working.

As you and I suspected, it looks like this was a clusterwhoops with the permissions for the NFS mount. Let's recap what happened in the past 24 hours:

1. Yesterday, 8 PM: I restart the Apache server, thereby resurrecting the SVN (now conveniently located at /export/home/svn). The DokuWikis remain borked.
2. Yesterday, 7 to 11 PM: Zach, Rana, and Jenne perform deep magic to get the front-end machines up and running again. This should be irrelevant for this Apache/SVN/DokuWiki witchcraft.
3. Today, morning: the townsfolk happily resume their svn up and svn ci festival.
4. Today, ca. 3 PM: Zach runs stopapache.sh to bring down Apache, thinking he can bring it back up momentarily with startapache.sh. But NFS is a jealous and vengeful god, and Apache now complains that it doesn't have permission to write to its logfiles, and therefore can't start httpd.
5. Today, 5 PM: "How can this be?", Zach and I ask. Apache had no problem starting up yesterday night, and to our knowledge nobody futzed with chiara's NFS mount of /home/cds. This change remains mysterious to us.

Despite the aforementioned mystery, Zach and I pressed on and tried to diagnose the permissions issue. We found that even if you are logged into nodus or pianosa or rossa or whatever as the controls user, the NFS mount saw us as the user nobody (in the group nogroup). If we created a file on the NFS mount, it was owned by nobody/nogroup. If we tried to modify a file on the NFS mount that was owned by controls/controls or controls/staff, we got a "permission denied" error, even if we tried with superuser privileges.

It turns out this has to do with the vagaries of NFS (scroll down to gotcha #4). We have all_squash enabled in /etc/exports , which means that no matter your username or group on nodus, rossa, pianosa, or harpischordsa, NFS coerces your UID/GID to chiara's nobody/nogroup. Anyway, the fix was to go into chiara's /etc/exports and change this

/home/cds 192.168.113.0/255.255.255.0(rw,sync,no_subtree_check,all_squash,insecure)

to this

/home/cds 192.168.113.0/255.255.255.0(rw,sync,no_subtree_check,all_squash,anonuid=1001,anongid=1001,insecure)

where 1001/1001 are the UID/GID for chiara's controls/controls (as opposed to 65534/65534 for chiara's nobody/nogroup). That way, the NFS mount sees you as chiara's controls/controls.

In order to make chiara's NFS daemon aware of the new /etc/export settings, I ran sudo exportfs -r based on the answer to this StackOverflow question. As with all the best StackOverflow questions, the moderators closed it for being "off-topic".

[Edit, 2014-06-11, 11 AM: I've repeated the above anonuid/anongid change for the /home/cds/caltech/home/controls mount, so that nodus's /home/controls is writeable as well. I've also added a .screenrc for nodus in order to maintain sanity.]
ELOG V3.1.3-