If I catch anyone putting small booties into the large bootie bin, I will make said person eat small booties.

 I propose we work around this problem with giant flip-flops.  These are in the vein of the take-off-your-shoes-and-put-on-Crocs, without the taking off your shoes part.  They're a little annoying on the sticky mats, but otherwise great.  They are also super easy to put on and take off without hands, so there's no excuse for wearing them around the control room. 

I propose we buy many pairs of the smalls in green (since we already have one green small...they are big on me, so should be just right for most people), and a few mediums in, say, blue, and a few larges in black, and then maybe a few extra larges in green for people with extraordinarily large feet (they only have 3 colors).  Then we can keep a few pairs of each by each door to the lab, and have no more tracking dirty control room filth into the lab.

 I would like to suggest a trial run on these....Ergomates and the cleanboot!

REPLY by JCD:  Are these going to trap dirt and be impossible to clean though?  The nice thing about Crocs and the giant flip flops is that they are solid and if they get dirty you can do a quick wipedown, and they're good as new.

 The Cleanboot is washable and reusable!

We discovered that the analog whitening filter of the REFL55_I board is not switching when we operate the button on the user interface. We checked with the Stanford analyzer that the transfer function always correspond to the whitening on.

The digital one is actually switching. We decided to keep the digital de-whitening on to compensate for the analog one. Otherwise we get a very bad shape of the PDH signal. Sorry Rana...

 I forgot to say that the analog gain of the REFL55 channels has been reduced to 9db

This turned out to just be a loose connection of the ribbon cable from Contec board in the LSC IO chassis at the BIO break-out box.  The DSUB connector at the break-out box was not strain relieved!  I reseated the connector and strain relieved it and now everything is switching fine.

I wonder if we'll ever learn to strain relieve...

controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master 0$ ls
C1IOO_LKIN_OUT_MTRX.adl   C1IOO_MC_ASS_LOCKIN5.adl     C1IOO_WFS1_I.adl             C1IOO_WFS_LKIN.adl
C1IOO_LOCKMC.adl          C1IOO_MC_ASS_LOCKIN6.adl     C1IOO_WFS1_Q.adl             C1IOO_WFS_MASTER.adl
C1IOO_LOCKMC_BAK.adl      C1IOO_MC_ASS_PIT_LOCKIN.adl  C1IOO_WFS1_SETTINGS.adl      C1IOO_WFS_MASTER.adl~
C1IOO_MC_ALIGN.adl        C1IOO_MC_ASS_YAW_LOCKIN.adl  C1IOO_WFS1_SETTINGS.adl.old  C1IOO_WFS_MASTER_BAK.adl
C1IOO_MC_ALIGN.adl~       C1IOO_MC_LOCKINS.adl         C1IOO_WFS2_I.adl             C1IOO_WFS_OUTMATRIX.adl
C1IOO_MC_ALIGN_BAK.adl    C1IOO_MC_SERVO.adl           C1IOO_WFS2_Q.adl             C1IOO_WFS_QPD.adl
C1IOO_MC_ASS.adl          C1IOO_MC_TRANS_QPD.adl       C1IOO_WFS2_SETTINGS.adl      C1IOO_WFS_QPD.adl.old
C1IOO_MC_ASS_LOCKIN1.adl  C1IOO_Mech_Shutters.adl      C1IOO_WFS2_SETTINGS.adl.old  fmX
C1IOO_MC_ASS_LOCKIN2.adl  C1IOO_MODECLEANER.adl        C1IOO_WFS_HEADS.adl          junk
C1IOO_MC_ASS_LOCKIN3.adl  C1IOO_QPDS.adl               C1IOO_WFS_HEADS.adl.old      master
C1IOO_MC_ASS_LOCKIN4.adl  C1IOO_QPDS_BAK.adl           C1IOO_WFS_INMATRIX.adl       svn-commit.tmp~
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo 0$ cd master
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo/master 0$ cd master
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo/master/master 0$ cd master
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo/master/master/master/master 0$ helppp
helppp: command not found
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo/master/master/master/master 127$ help me
bash: help: no help topics match `me'.  Try `help help' or `man -k me' or `info me'.

its an acquired taste, but its a must since we're sending an interferometer to India

I noticed that the MC3 LL sensor was apparently dead according to its suspension screen. Since it was only the fast ADC channel and not the SLOW PDmon, I could tell that it was just in the ADC cabling. I pushed in a few of the MC3 sensor cables on the front and back of the PD whitening board and it came back OK. According to this trend of the past 40 days and 40 nights, it started slipping on this past Wednesday morning.

Was anyone walking near MC2 or the suspension electronics racks before noon on Wednesday (Oct. 2nd)?

 Is this your illegally installed HP bench power supply?

If so, or if not but you care about the signal that passes through these amplifiers, I suggest you remove this temporary power supply and wire the power from the rack power supplies through the fuse blocks and possibly use a voltage regulator.

In 24 hours, that power supply will be disconnected and the wires snipped if they are still there.

 Steve has promised to add another row of fuses to the LSC rack first thing in the morning.  Then, during Wednesday Chores, we can move the wires from the power supply to the fused power.

STEVE:  NEVER MIND about doing this in the morning.  Let's chat at the lunch meeting about what needs to be done to power things down, then back up again, in a nice order, and we can do it after lunch.  

So, please do not do anything to the LSC rack tomorrow!  Thank you.

 The north side of the LSC rack is full. I installed more DIN connectors with fuses on the south side of the rack 1Y2

The access to this may be a little bit awkward. You just remove the connector, wire it and put it back in.

 The ELOG was frozen, with this in the .log file:   

GET /40m/?id=1279&select=1&rsort=Type HTTP/1.1

Cache-Control: no-cache

Connection: Keep-Alive

Pragma: no-cache

Accept: */*

Accept-Encoding: gzip, deflate

From: bingbot(at)microsoft.com

Host: nodus.ligo.caltech.edu

User-Agent: Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)

  (hopefully there's a way to hide from the Bing Bot like we did from the Google bot)

 The 40m experienced a building-wide power failure for ~30 seconds at ~7:38 pm today.

Thought that might be important...

Last week Rana and I struggled to figure out how to un-full-screen windows on the Ubuntu workstations that appeared to be stuck in some sort of full screen mode such that the "Titlebar" was not on the screen.  Nothing seemed to work.  We were in despair.

Well, there is now hope: it appears that this really is a "fullscreen" mode that can be activated by hitting F11.  It can therefore easily be undone by hitting F11 again.

Yesterday elog was excruciatingly slow, and bingbot was the culprit. It was slurping down elog entries and attachments so fast that it brought nodus to its knees. So I created a robots.txt file disallowing all bots, and placed it in the elog's scripts directory (which gets served at the top level). Today the log feels a little snappier -- there's now much less bot traffic to compete with when using it.

We might be able to let selected bots back in with a crawl rate limit, if anyone misses searching the elog on bing.

Oh, this is cool! Thanks!
I could not figure out how to place robot.txt as it was not so obvious how elogd handles the files in the "logfile" directory.

 Larry and Nicolas

Larry's transfer function measurements suddenly started returning 0dB 0degrees when before there was some fake filter in the C1:ALS-OFFSETTER2 filter bank.

We looked in the filter bank and his filter was gone. So I created a new filter called LARRYP in FM2. We also disabled the output so he could drive the filter bank and test his TF code.

 This is ridiculous.

How many RGs can I fit into one button???

After recompiling medm with a patch for dumping screens (attached), I added a time machine to the right-click Execute menu.  It's installed under /cvs/cds/caltech/users/wipf/src/medm_time_machine. Dependencies include the python CA server module (pcaspy) and the latest nds2-client 0.11.2.  These were also installed under my users directory, to avoid interfering with other tools.

SP table has been a mess because Q and I had let our SURF leave without cleaning up.

I cleaned up the SP table, put things back where they belong and did some sorting. I will put back the optomechanics where they belong sometime later.

For now, check out the SP table next time you are looking for a Y1  or lens or BS.

No more illegal power supply at the LSC rack 

The amplifiers are now being powered by the rack power supply through fuse blocks.

To make new connections, I shutdown the +/-15 V low noise power supplies. They were turned back ON after the work.

Please!

Don't put laptops on the ISC Tables!

Reward being offered for the safe return of this thing:

COD_Sugar napolion is due to Steve:  Item delivered, model CMG-SCU-0013, sn G9536

So I made coffee at 1547 and was astonished to find the above. Its a sad, very sad day.

At first I thought that something (a gravity wave?) or someone, accidentally hit the thing and it fell and broke. But Koji told me that the janitor was cleaning around the thing and it did indeed fell accidentally.

Trying to download some data using matlab today, I found that my ole mDV stuff doesn't work because its MEX files were built for AMD64...

Tried to rebuild the NDS1 MEX according to 7 year old instructions didn't work; our GCC is 'too' new.

From the Remote Data Access wiki (https://wiki.ligo.org/RemoteAccess/MatlabTools) I got the new 'get_data.m' and 'GWdata.m'. These didn't run, so I updated the nds2-client and matlab-nds2-client on Donatella.

Still doesn't run to get 40m data. It recognizes that we're C1, but throws some java exception error. Maybe it doesn't work on the NDS1 protocol of our framebuilder?

So then I noticed that our NDS2 server on megatron is no longer running...thought it was supposed to run via init.d. Found that the nds2 binary doesn't run because it can't find libframecpp.so.5; maybe this was blown away in some recent upgrade? We do have versions 3, 4, 6, 7, & 8 of this library installed.

So now, after an hour or two, I'm upgrading the nds2 server on megatron (plus a hundred dependencies) as well as getting a newer version of matlab to see if there's some kind of java version issue there.

Of course python still works to get data, but doesn't have any of the wiener filter calculating code that matlab has...

NDS2 restarted after hours long upgrade process; testing has begun. Let's try to get some long stretches of MC locked with MCL FF ON this weekend so's I can test out the angular FF idea.

やったー！Yatta!

"medm: command not found" error when run through command line both in pianosa and rossa in both editing and execution modes. It however gets executed and edited through the sitemap button. Don't know the source of the problem. Gautam did check the .bashrc file. aliases for SITEMAP and m40m are intact in the .bashrc file.

The workstations' .bashrc is a symbolic link to /users/controls/.bashrc

In it, someone commented out the critical line:

#source /ligo/cdscfg/workstationrc.sh

I uncommented it. medm (and all of the other things like cdsutils) work again.

I blame jamie.

Found PMC unlocked for many hours so I relocked it. IMC relocked by itself, but the input switch seems to be flickering to fast. Also the Keep Alive bit is not flashing. 

We found that someone had violated all rules of computer security decency and was storing our nodus password as a plain text file in their bash_profile.

After the flogging we have changed the pwd and put the new one in the usual secret place.

In this video: https://youtu.be/iphcyNWFD10, the comments focus on the orange crocs, my wrinkled shirt, and the first aid kit.

A few weeks ago we did some internet speed tests and found a dramatic difference between our general network and our internal Martian network in terms of access speed to the outside world.

As you can see, the speed from nodus is consistent with a Gigabit connection. But the speeds from any machine on the inside is ~100x slower. We need to take a look at our router / NAT setup to see if its an old hardware problem or just something in the software firewall. By comparison, my home internet download speed test is ~48 Mbit/s; ~6x faster than our CDS computers.

controls@megatron|~> speedtest
/usr/local/bin/speedtest:5: UserWarning: Module dap was already imported from None, but /usr/lib/python2.7/dist-packages is being added to sys.path
  from pkg_resources import load_entry_point
Retrieving speedtest.net configuration...
Testing from Caltech (131.215.115.189)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Race Communications (Los Angeles, CA) [29.63 km]: 6.52 ms
Testing download speed................................................................................
Download: 6.35 Mbit/s
Testing upload speed................................................................................................
Upload: 5.10 Mbit/s
controls@megatron|~> exit
logout
Connection to megatron closed.
controls@nodus|~ > speedtest
Retrieving speedtest.net configuration...
Testing from Caltech (131.215.115.52)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Phyber Communications (Los Angeles, CA) [29.63 km]: 2.196 ms
Testing download speed................................................................................
Download: 721.92 Mbit/s
Testing upload speed................................................................................................
Upload: 251.38 Mbit/s

We implemented the post-SURF-season nodus password change today.

New password can be found at the usual location.

While staring at epics records all day I noticed something about the PIT/YAW offset sliders and ASS offset offloading to slow channels scripts that I'm not sure others are aware off, so I'll briefly discuss it in this post.

The PIT and YAW sliders directly control soft channels that are hosted on the slow machine. Secondary epics records disentangle them for the individual coils:

• UL = PIT+YAW
• LL = -PIT+YAW
• UR = PIT-YAW
• LR = -PIT-YAW

These channels are the direct input for the physical output channels that generate the control voltage.

The fast channels for PIT and YAW have a numerical correction factor built in that accounts for differences between the OSEMs, but the slow channels don't. This means that the slow PIT/YAW controls are not entirely orthogonal but have crosstalk on the order of 10 percent. This in itself is not that dramatic, however the offload offsets scripts for the dither alignment use the fast PIT/YAW values as inputs, which represent the necessary adjustments to the OSEMs only after the individual correction factors have been applied. The offloading to slow knows nothing of this calibration difference between the OSEMs. The result is that there is a ~10 percent of the offset correction error on the mirror alignment AFTER offloading. This will of course converge after a few iterations, but in any case it is recommendable to run the dither alignment again after offloading and not offload the new offsets to the fast channels.

I don't think this is really a problem - we offload to the fast channels and not to the slow (although we really should offload to the slow channels). I think the best approach is to use the ezcaservo utility to offload the DC part of the ASS control signals to the slow channels, so as to not waste fast channel DAC counts on DC offsets. In principle, this approach should be somewhat immune to the slow channel calibration not being perfect.

[Koji Gautam]

We talked about touch interface of medm. We realized that android (and iOS) has vnc clients. I just installed VNC viewer on my phone and connected to my mac. Typing is tricky but I managed to get into pianosa, then launched sitemap. We could unlock/lock the IMC by screen touch!

Basically we can connect to one of the laptops (or control machines) from a tablet (either android or ipad). It'd be better to put both in a same network. It'd be great if we have a tablet case with a keyboard so that we can type without blocking the screen.

The rat is cut by mechanical trap and it was removed from ITMX south west location.

A nagy kover patkanyt a fogo elkapta es megolte.

All of our wikis (except the 40m one which unfortunately got turned into ligo.org mess) use DokuWiki. This now has an auto-upgrade feature through the Admin web interface.

I tried this recently and it fails with this message:

DokuWiki 2018-04-22a "Greebo" is available for download.
 You're currently running DokuWiki Release 2017-02-19e "Frusterick Manners".
 New DokuWiki releases need at least PHP 5.6, but you're running 5.4.16. You should upgrade your PHP version before upgrading!

So we'll have to wait until SL7 (which is what NODUS is running).

I DID do a 'yum upgrade' which updated all the packages. I also installed yum-cron so that the RPM listings get updated daily. But sadly, SL7 only has PHP 5.4.16 (which is a June 2013 release):

> Package php-5.4.16-43.el7_4.1.x86_64 already installed and latest version

It is feeling cold in the office area. According to the digital wall clock near the coffee machine, it is 19C. Rana bumped the thermostat setpoint up by 2F (from 75F to 77F). We need to setup long-term monitoring.

[Jordan, gautam]

We did the following:

• Route the fiber from the control room to 1Y2.
• Plug fiber in to FiBox at either end, turned FiBoxes ON.
• Tested the optical connection by driving a 1Vpp 440 Hz sine wave from a function generator - Yehonathan hears it loud and clear in the control room.
• Tested that both CH1 and CH2 work - only CH1 is connected to the speakers in the control room at the moment.
• There is some cross-coupling between the channels - not sure if this is happening in the multi-mode fiber or in the electroncis, but I estimate the isolation to be >30dB.
• Connected CH8 and CH9 of DAC0 in the c1lsc expansion chassis to CH1 and CH2 respectively of the FiBox in 1Y2. 
• Restarted the c1daf model on c1lsc, came up smooth.
• Routed the POY11 error signal through the various matrices in c1daf, and we could 👂 the Y-arm cavity 🔐 😎 
• Channels are muted for now - I'll give this a whirl while doing the PRFPMI locking.

https://breakthrough.caltech.edu/magazine/2019-aug/#article-Listening-with-Light

there were a zillion processes trying to activate (this is the initial activation after the initial installation) matlab 2015b on megatron, so I killed them all. Was someone logged in to megatron and trying to run matlab sometime in 2020? If so, speak now, or I will send the out-of-control process brute squad after you!