I'm leaving the lab now for less than 2 hours. I should be back in time for when the pumping is finished so that I can measure the finesse again.

Wait, Wait, Wait. You are moving too fast. Go one by one.

Check the PZTs, the MC, initial pointings, IFO mirrors, some of the partial locks, and maybe some momentary full locks?
Once the recover of the IFO is declared, you can proceed to the measurements.

I hope the grad students can take this precious opportunity to have their fun time for restoring everything by themselves.

Slow pumpdown of rebuilt IFO-mark4 started at 3pm today.

We are at 680Torr at this minute with 1.5 Torr/min speed.

I'm looking for IOO steering mirror power supplies. I found two so far: one at 1Y3 as Kepco  + 75V and one at OMC_North rack -150V

Are there any more? The OMC is off.

ANSWER: only one of the steering PZT can be driven, so see their power supplies

The vacuum system is at 760 torr  All chambers with doors on and their annuloses are pumped down.

PSL output shutter is still closed. We are fully prepared to star slow pump down tomorrow.

The plan is to reach 1 torr ~ in 6 hrs  without a creating a sand storm.

 Pump down is completed. Valve configuration is VACUUM NORMAL. CC1 pressure is in the ~8 e-5 torr   PSL output shutter is opened.

Pd 76 and 77 are compared at 30 days of pumping. We spend 13-14 days at atmosphere  before each.

 Pump down 76 was with leaky ion pump gate valve. The ion pumps are not in use for years so they accumulated some higher pressure  PLUS the valve switching caos at computer reboot most likely

increased the ion pumps pressures to about 10-20 torr

I think one of the ion pump gate valve was not sealing well. This leak was holding back pump down speed at pd76

cd /opt/rtcds/caltech/c1/userapps
rm -rf trunk
svn update --depth=files trunk
svn update --depth=empty trunk/{CDS,ISI,ISC,PSL,SUS}
svn update trunk/{CDS,ISI,ISC,PSL,SUS}/{c1,common}

  [Zach and Kiwamu]

 We installed the new ETMY tower and successfully aligned the beam to the center of ETMY.

 Also we finished the final alignment of IP_ANG.

(what we did)

 - took the old ETM out  from the chamber and put it on the flow bench at the X end.

 - with a help from Joe and Osamu, we brought the new ETM and put it roughly on place.

 - did a fine positioning of ETMY.

 - covered the ETM tower with a large peace of aluminum foil in order to see the spot on a video monitor.

 - stoled a compact video monitor that was sitting on the PSL table since we don't have any monitors at the Y end.

 - made a ~1cm hole on the foil as a target for the beam.

 - steered PZT1 in order to correct the beam position on ETMY. This is done by looking at the spot on the video monitor.

 - steered IPANG_SM1 to let the beam hit a steering mirror in the ETMY chamber which Koji installed recently.

     Now we have IP_ANG coming out from the viewport of the ETMY chamber.

(Joe, Yuta)

Summary:
  LOCKIN(consists of oscillator and demodulator) is needed for A2L measurement.
  So, we put LOCKIN to c1ioo model, whose outputs goes to c1mcs ASC.
  After that, I checked the functionality of LOCKIN by directly connecting DAC output for a coil to ADC input for MCL with BNC cable.

What we did:
[Putting LOCKING to c1ioo model]
1. Copied Simulink LOCKIN stuff(cdsOsc, Product, cdsPhase ...) from /cvs/cds/caltech/cds/rward-advLigo/src/epics/simLink/omc.mdl and put it into c1ioo model.

2. Copied MEDM screen file /cvs/cds/caltech/medm/c1/omc/C1OMC_LSC_LOCKIN.adl and modified it for our use.

[Checking LOCKIN]
3. Disconnected MC2_ULCOIL input to SOS Coil driver at 1X4-1-6A and checked the signal from software oscillator at c1ioo is coming.

4. Disconnected the cable labeled "MC OUT1" at 1X2 (which is MCL signal to ADC) and put MC2_ULCOIL output directly using long BNC cable.

5. Checked the functionality of LOCKIN by StripTool.
   The cable wiring did not conflict with my expectation.
   Software mixer is working.(frequency is doubled. X_SIN has offset and X_COS doesn't)

6. Put the cables back.

Result:
  Thanks to c1rfm, c1ioo and c1sus are talking without ADC timeout.
  Also, LOCKIN is working fine.

I started to look into putting together a 110 MHz demod board to be used as POP110 (see #8399).

We have five spare old-skool EuroCard demod boards (LIGO-D990511).  From what I gather (see #4538, #4708) there are two modifications we do to these boards to make them ready for prime time:

• appropriate LP filter at PD RF input (U5 -> MC SCLF-*)
• swap out T1 transformer network with a commercial phase shifting power splitter (MC PQW/PSCQ)

#4538 also describes some other modifications but I'm not sure if those were actually implemented or not:

• removal of the attenuator/DC block/ERA-5 amp sections at the I/Q outputs
• swap ERA-5 amp with "Cougar"(?) amp at LO input.

What we'll need for a 110 demod:

• U5 -> SCLF-135
• T1 network -> PSCQ-2-120

I'll scrounge or order.

This SCPQ-150+, which is surface mount, might also work in place of the PSCQ-2-120, which is through-mount.  Would need to be reconciled with the board layout.

 For the 110 MHz demod boards, we would ideally have a plugin bandpass filter. If you have some specs in mind, you can email mini-circuits or pulsar microwave about making a custom part; its not too expensive usually.

For the meantime, you should remove the onboard one and replace with a combination of low/high pass filters from Mini-Circuits. If you put a SLP-150 and a SHP-100 in series, the insertion loss should be less than 1 dB.

I think the ERA amps are OK for now, but they die with time, so they just need to be tested and replaced if necessary.

I'm having Steve order the following:

2x  SXBP-100+
2x  SCLF-135+
2x  PSCQ-2-120+

If you want him to add anything to the order let him know ASAP.

I have modified one of the spare demod boards that was sitting above the electronics bench (the one which was unlabeled - the others say 33MHz, 55MHz and 165MHz) to be the new AS110 demod board.  In place of the T1 coil, and the C3 and C6 resistors, I have put the commercial splitter PSCQ-2-120+.  In place of U5 (the low pass for the PD input) I have put an SCLF-135+. 

In order to figure out how to make the pinout of the PSCQ match up with the available pads from T1, I first pulled the "AS11" board (it's not something that we use, so it would be less of a tragedy if something happened while I had the board pulled).  However, while the PCB layout is the same, the splitter for the low frequencies (PSCQ-2-51W) has a different pinout than the one I need for the 110MHz.  So, I put AS11 back, and pulled the POP110 board. (After I noted the pinout on POP110, I reinstalled that board.  To get it out, I had to unplug the I and Q outs of POP22, but I have also replugged those in).

For my new AS110 demod board, I copied the pin connections on POP110.  I have made a little diagram, so you can see what pins went where.  The top 2 rectangles are the "before" installation cartoon, and the bottom is the "as installed" cartoon.

The one thing that must be noted is that, because of the pinout of the splitter and the constraints of the board layout, the +0 degrees (I-phase) output of the splitter is connected to the Q channel for the rest of the demod board.  This means that the +90 degrees (Q-phase) output of the splitter is connected to the I channel for the rest of the demod board.  This is not noted for POP110, but is true for both:  The I and Q channels of the 110 MHz demod boards are switched.  In practice, we can handle this with our digital phase rotation.

Daytime tomorrow, I will test my new board as Suresh did in elog 4736.  Before we get to use AS110, we need (a) some LO juice from the RF distribution box, and (b) a spot to plug the board in, in the LSC rack.  Meditating on how those are going to happen are also tasks for daytime tomorrow.

OK, but what kind of filter should we be actually using? i.e. what purpose the 135 MHz low pass serve in contrast to a PHP-100+ ?

 Hmmm. Indeed. This is just cutting off higher frequency stuff, but anything from other lower sidebands still gets through.  I should actually stick in the SXBP-100's, which will band pass from 87-117 MHz.  These have an insertion loss at 100 MHz of 1.64 dB. 

Jamie ordered 2 of these, so I can put one in each of AS110 and POP110. 

I measured the phase split between the I and Q signals of my AS110 board.  To do so, I plugged the board into an empty slot next to the PD DC readout / whitening board in the LSC rack.  I borrowed the POP110 local oscillator, and used a Marconi to generate a "PD input".  (I'm roughly following what Suresh did in elog 4736).  Our 11MHz is currently 11.066134MHz, so I had the Marconi going at 110.662340 MHz (1kHz from 10*11MHz), and I had the Marconi source at -13dBm.  

I took a transfer function using the SR785 between the I and Q outs of the AS110 demod board, and got a magnitude misbalance of 0.809 dB, and a phase split of 110.5 degrees.  This isn't so close to 90 degrees, but this may be a problem with the splitter that we're using, as Suresh detailed in elog 4755.  In that elog, he measured a phase split of POP110 of 105 degrees, unless the power going into the splitter was pretty high.  As with POP110, since I expect that we'll usually only look at one channel (I, for instance), this isn't such a big deal for AS110. 

I have left, for now, the board in the empty slot.  It looks like (I'm going to go check) there are 3 open channels on the whitening board that has the PD DC signals.  So, the only thing left to figure out is how we want to get some local oscillator action for this new board.

EDIT: Yes, those channels are available.  Right now (as a remnant from testing the whitening filters waaaay back in the day) they are called C1:LSC-PDXXX I, Q, DC.  I'll use 2 of those for the AS110 I and Q. 

 I have removed the 135 MHz low pass from my new AS110 demod board, but these SXBPs have different feet than the SCLFs, so I want to confirm with Koji or someone that I can solder them in the same way, before I get carried away and destroy anything.  I should be able to finish this up tomorrow, plug in the demod board and the distribution box, and try out AS110 triggering, etc, tomorrow night.

I moved the Pynds package from Yuta's local directory to the public place.

Now the package is living under :

Also I added the PATH on cshrc.40m, so you don't have to setenv every time.

       (This package can not run on non-64bit linux)

Typing "import nds" on python allows you to use the nds functions.

 Quote from Yuta's  past entry

EDIT by kiwamu Dec.7th ;

The Pynds package has been moved to the appropriate place:

/cvs/cds/caltech/apps/linux64/python/lib64/python2.4/site-packages

Background:
 We need the python module pyNDS to get the data directly from the server using python.
 Leo helped us install pyNDS today.

Installation:
1. Get pyNDS source tarball from here.
  https://www.lsc-group.phys.uwm.edu/daswg/download/software/source/pynds-0.3.tar.gz

2. All you need is Boost.Python and nds2-client. See README in the pynds-0.3 directory.

3. I installed pyNDS to /cvs/cds/caltech/users/yuta/pynds

4. You have to set environment variable to import the module. For example, run;
  setenv PYTHONPATH /users/yuta/pynds/lib64/python2.4/site-packages:${PYTHONPATH}

Notes:
 RPM will be available soon from Leo.

I've modified the __init.py__ file located at /ligo/apps/linux-x86_64/cdsutils-480/lib/python2.7/site-packages/cdsutils/__init__.py so that you can now simply import pyawg from cdsutils. On the control room workstations, iPython is set up such that cdsutils is automatically imported as "cds". Now this import also includes the pyawg stuff. So to use some pyawg function, you would just do (for example):

One could also explicitly do the import if cdsutils isn't automatically imported:

pyawg-away!

Linking this useful instructional elog from Chris here: https://nodus.ligo.caltech.edu:8081/Cryo_Lab/1748

?  Why aren't you able to just import 'awg' directly?  You shouldn't have to import it through cdsutils.  Something must be funny with the config.

 controls@rosalba:~ 0$ cdsutils
Traceback (most recent call last):
  File "/ligo/apps/cdsutils/lib/cdsutils/__main__.py", line 7, in <module>
    from cdsutils import CMDS
  File "/ligo/apps/cdsutils/lib/cdsutils/__init__.py", line 4, in <module>
    from servo import servo
  File "/ligo/apps/cdsutils/lib/cdsutils/servo.py", line 1, in <module>
    from epics import PV
ImportError: No module named epics
controls@rosalba:~ 1$ 

Mon Sep 16 19:40:32 2013 

 I properly installed the python-pyepics package on all the workstations, so this should be working now.

And for posterity, the pyepics source is at:

  pianos:/home/controls/src/pyepics

From this debian packages were built:

  controls@pianosa:~/src/pyepics 0$ debuild -uc -us

The .deb was then moved into the /ligo/apps/deb nfs:

  controls@pianosa:~/src 0$ cp python-pyepics_*_all.deb /ligo/apps/debs/pyepics/

It was then installed on the various workstations:

  controls@rosalba:~ 0$ sudo dpkg -i /ligo/apps/debs/pyepics/python-pyepics*.deb

This will probably need to be repeated any time we upgrade the EPICS install.

I installed pyepics version 3 (http://cars9.uchicago.edu/software/python/pyepics3/overview.html) in ..../scripts/pylibs    .   I also added an "epics.conf" file to /etc/ld.so.conf.d/ , which points to the place in /ligo/apps/epics/base/lib/linux-x86_64/ where the DLLs live.  All .conf files in /etc/ld.so.conf.d/   get included in the path, so python should always automatically be able to use epics now, after you "import epics" in a script.

This is supposed to give us direct channel access to all epics channels, rather than using Yuta's wrapper scripts for ezca stuff.  I was going to write a tdsavg equivalent using camonitor, since it's unclear whether tds tools are being supported anymore.

However, I'm not getting it to connect to the server that serves epics, so I can't get the values of any channels.  All of the info in the link above assumes that you automatically get a connection, and I'm out of ideas right now of things to try.  Does anyone else have any ideas?

 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.

[Paco, Tega]

I added the pypi package "restoreEpics" to the donatella clone under test. This is required by some of Anchal's scripts that turn on F2A filters as well as other recovery stages during some measurements.

On pianosa: The ezca.Ezca class somehow initializes with its prefix set to "C1:", even though the docstring says the default is None. This makes existing scripts act wonky, because they're looking for channels like "C1:C1:FO-BLAH".

In ligo/apps/linux-x86_64, I ran ln -sfn cdsutils-old cdsutils to get the old version back for now, so I don't have to edit all of our up/down scripts.

Also, Chiara can't find the epics package when I try to load Ezca. It exists in '/usr/lib/pymodules/python2.6/epics/__init__.pyc' on pianosa, but there is no corresponding 2.7 folder on chiara.

I just pushed a fix to ezca to allow for having a truly empty prefix even if the IFO env var is set:

controls@pianosa:~ 0$ ipython
Python 2.6.5 (r265:79063, Feb 27 2014, 19:43:51) 
Type "copyright", "credits" or "license" for more information.

IPython 0.10 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object'. ?object also works, ?? prints more.

In [1]: import ezca

In [2]: ezca.Ezca()
Out[2]: Ezca(prefix='C1:')

In [3]: ezca.Ezca(ifo=None)
Out[3]: Ezca(prefix='')

In [4]: ezca.Ezca(ifo=None).read('C1:LSC-DARM_GAIN')
Out[4]: 0.0

This is in cdsutils r232, which I just installed at the 40m.  I linked it in as well, so it's now the default version.  You will have to make a modification to any python scripts utilizing the Ezca object, but now it's a much smaller change (just in the invocation line):

-ca = ezca.Ezca()
+ca = ezca.Ezca(ifo=None)

I installed the Python bindings for sqlite on Allegra using

$ sudo yum install python-sqlite python-sqlite2

MUX input 7 to ITMXF camera cable was replaced by temporary cable labeled as 888

The problem remains to be the same black stripe at the bottom of the image The single picture is OK.

I'm trying to get some intuition how digital noise due to quantization shows up in iir filters. I decided to do tests in C using Python to calculate psd and visualize. I've implemented Direct Form 1, 2, "Biquad" and "Low Noise" forms of realization of second-order iir filter from Matt's presentation. There is a typo in the "Low Noise Form" scheme - a₁ and a₂ gains should be switched. Other then that schemes correctly implement 2 order iir. 

The input signal to each filter was a sine wave plus white noise with small amplitude x[n] = sin(2*pi*f*t[n]) + g*random( [-1, 1] ),  g << 1, f=1kHz. Sampling frequency was 16384 Hz. All 4 forms implemented 2 order low-pass butterworth filter with cut-off frequency 0.2 Hz

For g=1e-2 all implementations work fine. For g=1e-8 when quantization noise increases, all implementations give a lot of noise at low frequencies. I did not notice any significant difference between any of these implementations. I'll try to do more tests to figure out any difference in noise between the forms.

Quantization noise depends on the architecture of the processor, compiler and what not. But I do not think this can give a huge difference in results. We need to understand carefully digital noise during PSD estimation and all operations done at Matlab or Python.

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'.

Instrument rack power supplies checked and labeled at present loads.

The vacuum rack Sorensen is running HOT! Their is only 0.3A load at 24V There is plenty of space around it.

It is alarming to me because all vacuum valve positions are controlled by this 24V

All rack power supplies labeled if their load changed.

[Tega, Jamie]

Here is a proposal for what we would like to do in terms of reshuffling a few rack-mounted equipments for the CDS upgrade. 

• Frequency Distribution Amp - Move the unit from 1X7 to 1X6 without disconnecting the attached cables. Then disconnect power and signal cables one at a time to enable optimum rerouting for strain relief and declutter.  

• GPS Receiver Tempus LX - Move the unit from 1X7 to 1X6 without disconnecting the attached cables. Then disconnect power and signal cables one at a time to enable optimum rerouting for strain relief and declutter.

• PEM & ADC Adapter - Move the unit from 1X7 to 1X6 without disconnecting the attached cables. Disconnect the single signal cable from the rear of the ADC adapter to allow for optimum rerouting for strain relief.

• Martian Network Switch - Make a note of all connections, disconnect them, move the switch to 1X7 and reconnect ethernet cables. 

• MARTIAN NETWORK SWITCH CONNECTIONS
  #	LABEL	#	LABEL
  1	Tempus LX (yellow,unlabeled)	13	FB1
  2	1Y6 HUB	14	FB
  3	C0DCU1	15	NODUS
  4	C1PEM1	16
  5	RFM-BYPASS	17	CHIARA
  6	MEGATRON/PROCYON	18
  7	MEGATRON	19	CISC/C1SOSVME
  8	BR40M	20	C1TESTSTAND [blue/unlabelled]
  9	C1DSCL1EPICS0	21	JetStar [blue/unlabelled]
  10	OP340M	22	C1SUS [purple]
  11	C1DCUEPICS	23	unknown [88/purple/goes to top-back rail]
  12	C1ASS	24	unknown [stonewall/yellow/goes to top-front rail]

   

I believe all of this can be done in one go followed by CDS validation. Please comment so we can improve the plan. Should we move FB1 to 1X7 and remove old FB & JetStor during this work?

Attachment 1: Reshuffling proposal

Attachment 2: Front of 1X7 Rack

Attachment 3: Rear of 1X7 Rack

Attachment 4: Front of 1X6 Rack

Attachment 5: Rear of 1X6 Rack

Attachment 6: Martian switch connections

@tega This looks great, thank you for putting this together.  The rack drawing in particular is great.  Two notes:

1. In "1X6 - proposed" I would move the "PEM AA + ADC Adapter" down lower in the rack, maybe where "Old FB + JetStor" are, after removing those units since they're no longer needed.  That would keep all the timing stuff together at the top without any other random stuff in between them.  If we can't yet remove Old FB and the JetStor then I would move the VME GPS/Timing chassis up a couple units to make room for the PEM module between the VME chassis and FB1.
2. We'll eventually want to move FB1 and Megatron into 1X7, since it seems like there will be room there.  That will put all the computers into one rack, which will be very nice.  FB1 should also be on the KVM switch as well.

I think most of this work can be done with very little downtime.

I took the pictures of all racks of electronics yesterday, and then uploaded these pictures on the wiki.

http://lhocds.ligo-wa.caltech.edu:8000/40m/Electronics

You can see them by clicking "pictures" in the wiki page.

The south arm labels were changed from y to x to reflect reality.

So racks, manual disconnects and breakers now have their actual name. The east arm will be changed over tomorrow.

Please remove incorrect labels if you see any !

I can not find 1X4 breaker so it will be  traced.

The crontab for op340m which runs various IFO maintenance activities has been set to the wrong path for the watchdog rampdown script since the CDS changeover.

This is a dangerous situation. With the watchdog thresholds set as high as 1000, the magnets can be broken if the new CDS has some mental problems. This kind of thing happened before at LHO (which is why Stan invented the watchdogs). Please try to make sure that the watchdog thresholds are not set that way - its our only defense against bad CDS.

I've now corrected the crontab. The watchdog thresholds are being stepped down every 30 minutes as before.

However, out test points are gone again, so who knows how things are behaving.

I found some DQ channels (e.g. SENSOE_UL and etc.) for C1SUS haven't been activated, so I ran activateDQ.py.

Then I restarted daqd on fb as usual. So far the DQ channels look working fine.

Rana, Jan, Jenne

We noticed that the Ranger data was all bogus at low frequencies. So we checked it and found that the proper procedure had not been used when changing it from horizontal to vertical last week. So the huddle test data from the weekend is not valid for the ranger; we will have to repeat it sometime.

So we used the manual, and extended the hanger rod on top of the Ranger to free the mass. It now has good response and coherence with the Guralps down to 0.1 Hz. See attached plot soon.

Last jump at rack Y2.

1. The vertical axis should start from zero. The horizontal axis should be extended so that it includes the waist. See Zach's plot http://nodus.ligo.caltech.edu:8080/40m/2818

2. Even if you are measuring only the linear region, you can guess w0 and z0, in principle. w0 is determined by the divergence angle (pi w0/lambda) and z0 is determined by the linear profile and w0. Indeed your data have some fluctuation from the linear line. That could cause the fitting prescision to be worse.

3. Probably the biggest reason of the bad fitting would be that you are fitting with three parameters (w0, z0, zR) instead of two (w0, z0). Use the relation ship zR= pi w0^2/lambda.

I tried Koji's suggestions for improving the fit to the vertical beam profile; however, I could not improve the uncertainties in the fit parameters.

I started retaking the data today with the same laser settings used last time and noticed that the photodiode was saturating. We were using an ND 4.0 neutral density filter on the photodiode. Koji and I noticed that the coating on the filter was reduced in the center and added an additional ND 0.6 filter to the photodiode. This seemed to fix the photodiode saturation.

I think that the photodiode was also saturating to a lesser extent when I took the last set of data. I will take another vertical beam profile tomorrow.

[Edit by KA: Metallic coating started being evaporated and the ND filters reduced their attenuation. We decided to use absorptive one as the first incident filter, and put a thinner one behind. This looked fine.]

Give me the plot of the fit, otherwise I am not convinced.

I thought that the micrometer I was using to move the razor through the laser beam was metric; however, it is actually english.

After discovering this mistake, I converted my previous measurements to centimeters and fit the data to

w = sqrt(w0^2+lambda^2*(z-z0)^2/(pi*w0)^2) with the following results:

reduced chi squared = 14.94

z0 = (-4.2 ± 1.9) cm

w0 = (0.013 ± 0.001) cm

I used the Mathematica CurveFit package that we use in Ph6/7 to make the fits for the beam profile data. I wrote two functions that use CurveFit shown in the attachment to make the fits to the error function and square root.