The saga has started here  We have to give credit to the Boss who fixed it. The seismometers themself are not labeled yet.

Atm6  added on 8-12-2016   EX needed to be centered

Thanks to Max for the nice plost at summery pages

I never actually figured out exactly what was wrong in entry 2162, but I managed to circumvent by changing the time sequence of events in the up script, moving the big gain increases in the common mode servo to the end of the script.  So the IFO can be locked again.

I've been putting together a new machine that Rolf got for us as a replacement for fb.

I've installed and configured the OS, and compiled daqd and the necessary supporting software.  I want to try acquiring data with it.  This will require removing the current/old fb from the DAQ network, and adding the new machine.  It should be able to be done relatively non-invasively, such that none of the front end configuration needs to be adjusted, and the old fb can be put back in place easily.

If the test is successfully, then I'll push ahead with the rest of the replacement (such as either moving or copying the /frames RAID to the new machine).

I will do this work in the early AM tomorrow, September 22, 2015.

I'm working on the AP table. I also opened the auxiliary NPRO shutter. The auxiliary beam is on its path on the AP table and PSL table.

 Closing the AP table and the NPRO shutter now.

2.1 mag earth quake in Norhten Ca

Our seimometers need professorial centering. Related electronics must be checked too.

 Koji and I went into "Update Manager" on several of the Ubuntu workstations and unselected the "check for updates" button. This is to prevent the machines from asking to be upgraded so frequently - I am concerned that someone might be tempted to upgrade the workstations to Ubuntu 12.

We didn't catch them all, so please take a moment to check that this is the case on all the laptops you are using and make it so. We can then apply the updates in a controlled manner once every few months.

We are currently working on donatella workstation upgrade, which we are calling donatellaclone for now. After installing Debian 11, we install the cds conda environment. This takes care of most of the requisite packages except `dataviewer` and `burtgooey`.

To resolve the machines on the martian network, we do the following:

then create or open the file '/etc/resolvconf/resolv.conf.d/head'

sudo nano /etc/resolvconf/resolv.conf.d/head

and add the following

burtgooey:

The installation binary for burtgooey `/usr/bin/burtgooey` is a symoblic link that points to `/ligo/apps/epics-3.14.10/extensions/bin/linux-x86_64/burtgooey`. To get this working, we need to install some requisite libraries, see below:

dataviewer:

dataviewer depends on 'grace' and 'libmotif-dev' which are not installed automatically and results in a broken initial installation, so do the following:

The channels for IPPOS had been assigned in a wrong way.

Because of this, C1:ASC-IP_POS_X_Calc corresponds to the actual vertical motion and C1:ASC-IP_POS_Y_Calc is for the horizontal motion.

We should fix the database file to get the correct vertical/horizontal corrdinate.

Today Steve was working around the 1X5 rack to strain relief the cable jungles and the jungle is now getting less jungle.

During the work he disconnected and reconnected some cables.

So for a doublecheck I checked all the suspensions to see if the suspensions are still healthy or not.

Aha, then I found a mistake.

See the pictures below. It's a very subtle difference. This wrong connection prevented MC1 and MC3 from damping.

To balance the actuation on ETMX and ETMY, x4.12 was aded to C1:SUS-ETMX_(UL|UR|LR|LL|SD)COIL FM1. OSEM damping filter gains, oplev loop gains, and alignment offsets were divided by this factor.
C1:LSC-ETMX_GAIN is now 1.

To do:
 - Balance ETM and ITM. It should make ASS more sensible.
 - Re-commission Xarm ASS and Yarm ASS.

We aligned and locked xarm for green.

 That's really, really awesome!

Moku:Go used for full locking of green laser - OLTF to come

Picking up from where Reuben left off, I used the Moku:Go in multi-instrument mode to replace the signal generator and uPDH box entirely (Moku:Go setup shown in Attachments 1+2). The lock-in amplifier sourced the modulation for the PZT: 210.5 kHz, 1.4 Vpp amplitude (consistent with 7dBm used by the uPDH box) This LO was used to demodulate the REFL signal input. I coarsely tuned the demodulation phase to 90 degrees until the PDH error signal looked reasonable. The PDH error signal was passed to the digital filter box using the same filter as before. After slightly adjusting the gain knob in the filter module (-8 dB), the lock seemed reasonably stable - transmission screenshot in Attachment 3. I got transmission to ~0.8 with the analog loop today, so it was exciting to see this level maintained with the Moku:Go lock (ignoring oscillations from test mass motion). The system remains locked to TEM00 for 5-10 minutes before mode hopping, which is qualitatively comparable to the analog loop as well.

An OLTF of the Moku:Go loop still needs to be taken. Since the loop error point isn't outputted from the Moku (passed direclty between instruments), I'll need to inject an excitation at the control point. When I fed the control signal to input A of the SR560 and tried to lock with the direct output, the lock would repeatedly break. I noticed that the BATT light of the SR560 was on - I'll repeat this with another SR560, but the lock might be breaking due to an offset. Once this is debugged, I can inject an excitation and measure the loop OLTF.

 Xend internal cabling and external connector is ready. We are waiting for seismometer from Gyro lab. We still need to fix the pot with clamps after we put the instrument in.

We also need a long cable from Xend to the guralp readout box.

We aligned and locked Y arm for green:

• installed camera on PSL to monitor green transmission
• aligned green path on the ETMY table to see the beam on the PSL camera
• misaligned ETMY and aligned ITMY to see reflected beam on REFL PD
• installed green transmission PD on PSL
• aligned ETMY and locked YARM to 00 mode

I've switched error channel cable to output monitor. Whitening filter is need for scattering measurements.

As a CM slow path test I locked free swinging yarm by actuating on MC length with bandwidth of 200 Hz. Crossover with AO is not stable so far.

I used xarm as an ool frequency noise sensor. MC2 violin mode is at 645 Hz, I have added a notch filter to LSC-MC2 bank.

Yend seismometer isolation kit (elog 8461) hosts Guralp seismometer. I made a cable for inside connection, assembled the kit and relocated the instrument from its previous position at the yend inside the kit.

Seismometer is connected to the readout box and running.

I went to Ottavia, and tried running yum update.  It was having dependancy issues with mjpegtools, which was a rpmforge provided package.  In order to get it to update, I moved the rpmforge priority above (a lower number) that of epel ( epel -> 20 from 10, rpmforge -> 10 to 20).  This resolved the problem and the updates proceeded (all 434 of them). yum update on Ottavia now reports nothing needs to be done.

I went to Rosalba and found rpmfusion repositories enabled.  The only one of the 3 repositories in each file enabled was the first one.

I then added priority listing to all the repositories on Rosalba.  I set CentOS-Base and related to priority=1.  I set CentOS-Media.repo priority to 1 (although it is disabled - just to head off future problems). I set all epel related to priorities to 20. I set all rpmforge related priorities to 10.  I set all rpmfusion related priorities to 30, and left the first repo in rpmfusion-free-updates and rpmfusion-nonfree-updates were enabled.  All other rpmfusion testing repositories were disabled by me.

I then had to by hand downgrade expat to expat-1.95.8-8.3.el5_4.2.x86_64 (the rpmforge version).  I also removed and reinstalled x264.x86_64.  Lastly I removed and reinstalled lyx. yum update was then run and completed successfully.

I installed yum-priorities on Allegra and made all CentOS-Base repositories priority 1. I similarly made the still disabled CentOS-Media priority 1.  I made all epel related repos priority 20.  I made all lscsoft repos priority=50 (not sure why its on Allegra and none of the other ones).  I made all rpmforge priorities 10.  I then ran "yum update" which updated 416 packages.

So basically all the Centos control room machines are now using the following order for repositories:

CentOS-Base > rpmforge > epel > (rpmfusion - rosalba only) > lscsoft (allegra only)

I'm not sure if rpmfusion and lscsoft are necessary, but I've left them for now.  This should mean "yum update" will have far fewer problems in the future.

I added the following repos which I found on allegra to megatron and then did a 'yum install sshfs' on both machines:

allegra:yum.repos.d>l
total 28
-rw-r--r-- 1 root root  428 Feb 12 16:47 rpmforge.repo
-rw-r--r-- 1 root root  684 Feb 12 16:47 mirrors-rpmforge
-rw-r--r-- 1 root root 1054 Feb 12 16:47 epel-testing.repo
-rw-r--r-- 1 root root  954 Feb 12 16:47 epel.repo
-rw-r--r-- 1 root root  626 Feb 12 16:47 CentOS-Media.repo
-rw-r--r-- 1 root root 1869 Feb 12 16:47 CentOS-Base.repo
-rw-r--r-- 1 root root  179 Feb 12 16:47 adobe-linux-i386.repo

This also required me to import the rpmforge GPG key:

sudo rpm --import http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt

For several of the channels on the PEM ADCU, zeros are occuring at the same time. Does anyone know why that might happen or how to fix it?

Added zita to the martian host table, and configured his network accordingly:

zita            A       192.168.113.217

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

 I installed 'nfs-client' on zita (the StripTool terminal). It now has mounted all the shared disks, but still can't do StripTool since its a 32-bit machine and our StripTool is 64.

I'll finish the rest of the config to turn it into a full-fledged workstation tomorrow.

Here is a comparison of the response of various DoFs in our various RFPD sensors for two different CARM offsets. Even in the case of the smaller CARM offset of ~1kHz, we are several linewidths away from the resonance. Need to do some finesse modeling to make any meaningful statement about this - why is the CARM response in REFL11 apparently smaller for the smaller CARM offset?

If you mistrust my signal processing, the GPS times for which I ran the sensing lines are:

CARM offset = ~30kHz (arm transmission <0.02) --- 1257064777+5min

CARM offset = ~1kHz (arm transmission ~5) --- 1257065566+5min