"Why does the word wrapping not work in our browsers with ELOG?" I sometimes wonder. Some of the elogs are fine, but often the 40m one has the text run off the page.
I found that this is due to people uploading HUGE images. If you need to do this, just use the shrink feature in the elog compose window so that we only have to see the thumbnail at first. Otherwise your 12 MP images will make it hard to read everyone else's entries.
June 22-June 24:
1.Coupling light into fibre at the ETMY.
2.Routing of the fibre to the PSL table.
June 27-June 30:
1.PSL optical table layout sketching.
2.Combining the PSL beam with fibre output onto a BS and then superpose them on a New Focus 1611 PD.
July 5-July 8:
1.Conversion of the PD output to voltage using MFD(Mixer Frequency Discriminator).
2. Report writing.
July 7: 5:00 pm: 1st Report Due.
July 11-July 22:
1.Locking Y-arm to PSL.
2.Setting up the feedback loop using the MFD output as the error signal and acting on the AUX laser frequency.
July 25-Aug 5:
1.Y-Arm cavity characterisation.
Measurement of the transmission of IR and green light through the cavity.
To obtain FSR, Finesse,Loss of the Cavity, Visibility, Transverse Modes(g-factor, astigmatism), Reflectivity, Q-factor.
3.Report and abstract writing.
Aug 1: 5:00 pm: 2nd Report and absract due.
Preparation for talk and seminar.
The cable tray holder cross beam is removed and cut short for good access to seismometer.
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.
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.
We aligned and locked xarm for green.
That's really, really awesome!
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.
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:
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.
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:
-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
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
There seems to be stronger-than-expected coupling between CARM and the 3f sensors.