June 5

-Discussed the actual project outline 

-Installed Comsol on the system

-Learned the basics of Comsol with the help of tutorials available on 40m wiki

and others.

June 6

-Made few simple models in Comsol 

-Studied LIGO GWADW slides for a better understanding of the project.

-Setup SVN to access remote repository.

-Created a COMSOL model for variation of temperature in two mass system.

-Used the above model for cryogenic conditions.

-checked it analytically.

-Created a COMSOL model for cryogenically shielded test mass with compensation plate.

-Analyzed the behavior of the model in different size configurations.

 -Continued with the same cryogenic model created and varied the length of  outer shield and studied the temperature variation inside.

-Compared the temperature difference given by COMSOL with manually calculated one.

-Derived formula for manual calculation of temperature due to total influx.

-Compared the results by COMSOL and by the formula.

 -Read about blue team design for maximum power budget.

-Read third generation talks to get a better understanding of the work. 

 -Attented LIGO orientation meeting and safety session.

-Prepared 3 week report

 -Updated 3 week progress report with new additions and deletions.

-Attended LIGO lecture which was very interesting and full of information.

- Discussed the further project with Dr. Brooks.

-Tried to derive formula for the test mass inside cryogenic shield(infinitely long shield from one side)

 -Discussed the project outline for next 6 weeks.

-made a write up for the tasks. (attached)

-Analyzed the variation of temperature of the test mass with input power for different lengths of the shield. 

 Does this work?

I installed a recycled VME crate in the electronics rack. It currently has a Baja 4700E CPU card in it - and this needs to be configured. We also have the following cards, which are not plugged in right now.

1. ICS-110A-32 Analogue-to-Digital Converter - the jumpers need to be set on this to give it a unique memory address in the VME bus.

2. D000186 LIGO-type Anti Image card.

The CPU card needs to be configured to search it's OS binaries on the network (in this case we're going to store them on the framebuilder in Rana's lab). These settings are accessed by plugging a serial cable into the front of the card and using a terminal window to access the menu system. There are some screen caps of this below. As the card is reset we get the Start-up screen and then we can either do nothing (and a full boot will take place) or we can press a key and access the menu. From there we can restart the boot process by entering "@" or we can change the boot settings by entering "c". These are shown below:

We fixed the start-up settings on the VME crate to look for a TCS startup file on fb0. The settings on the Baja 4700 are now:

 On the advice of Ben Abbott, I've ordered the Diamond Systems Athena II computer w/DAQ, as well as an I/O board, solid state disk and housing for it. The delivery time is 4-6 weeks.

Diamond Systems Athena II

I've been trying to measure the ring heater transfer function (current to emitted power) by sweeping the supply voltage and measuring the emitted power with a photodector positioned right next to the ring heater.

Last night the voltage was sweeping with a 1000mV setting on the SR785 which was fed into the Voltage Control of the Kepco Bipolar Operational Power Supply/Amplifier which was biased around 10V.

The results are very, very strange. The magnitude of the transfer function decreases at lower frequency. I'll post the data just as soon as I can (ASCII dumps 13 and 14 on the disk from the SR785).

The circuit looks like this:

SR785 drive ----> Amplifier ----> Ring Heater : Photodetector ---> SR560 (5000x gain) ----> SR785 input

 This is wrong. It turns out the SR785 was wired up incorrectly.

I mounted the thinner Aluminium Watlow heater inside a 14" long, 1" inner diameter cylinder. The inner surface was lined with Aluminium foil to provide a very low emissivity surface and scatter a lot of radiation out of the end. ZEMAX simulations show this could increase the flux on a PD by 60-100x. 

There was 40V across the heater and around 0.21A being drawn. The #9005 HgCdTe photo-detector was placed at one end of the cylinder to measure the far-IR. (Bear in mind this is a 1mmx1mm detector in an open aperture of approximately 490 mm^2), The measured voltage difference between OFF and the steady-state ON solution, after a 5000x gain stage, was around 270mV. This corresponds to 0.054mV at the photo-diode. Using the responsivity of the PD ~= 0.05V/W then this corresponds to about 10mW incident on the PD.

Just a note: this board was for the QPD not the Bull's eye detector.

I've been looking to see what the time constant of the ring heater is. The attached plot shows the voltage measured by the photodiode in response to the heater turning on and off with a period of 30 minutes.

The time constant looks to be on the order of 600s.

After leaving the ring heater off for several hours I turned on a 40V, 0.2A supply at a gps time of 949 988 700

The channel recording the PD response is C2:ATF-TCS_PD_HGCDTE_OUT.

However, there is a delay between the time at which something is supposed to be recorded and the time at which it is recorded. I looked at the GPS clock and it read that time when I started the heater voltage. If you play the channel back in dataviewer you see the temperature start to increase around 80s BEFORE the heater current was switched on. This needs to be calibrated away!!!

I applied a step function to the silver WATLOW heater and measured the response with the photodiode. The power spectrum of the derivative of the PD response is attached. The voltage isn't calibrated, but that's okay because right now we're just interested in the shape of the transfer function. It looks like a single pole around 850uHz. The noise floor is too great above 4 or 5 mHz to say anything about the transfer function.

Hideously slow internet at airport is making me write a brief entry. This is the times series of the hesilver watlow heater radiative response to a step function.

Laso United airlines are a bit cheap ....

 The EDT PCIe4 DV C-Link frame grabber arrived this morning. There is a CD of drivers and software with it that I'll back up to the wiki or 40m svn sometime soon.

 I installed the EDT PCIe4 DV C-Link frame grabber in a spare Windows XP PC and connected the Dalsa 1M60 camera directly to it via the CameraLink cable. In this configuration I was able to access the menu system in the camera using the supplied serial_cmd.exe routine.

PC --> Frame-Grabber --> Camera-Link Cable --> Dalsa 1M60: works OK

Next, I attached the RCX C-Link: Fiber to Camera Link converters to either end of a 300' fiber, plugged them into the PC and the Dalsa 1M60 and then supplied them with 5V of power. Once again, I was able to access the on-board menu system in the camera (as the attached screen-capture shows). I also did a quick-test using the in-built video display program and verified that I could get an image from the camera - by waving around my hand in front of the CCD I was able to modulate the light in the image on the computer. This, therefore, demonstrates that the camera can be easily accessed and run at a distance of at least 300' via optical fiber.

PC --> Frame-Grabber --> RCX C-Link --> 300' optical fiber --> RCX C-Link --> Dalsa 1M60: works OK

The attached images:

 hartman_sensor.JPG: a screencap of the Dalsa 1M60 on-board menu system captured with the C-Link to fiber connector running

Fiber_Camera_Link_1.jpg: A RCX C-Link and one end of the 300' fiber connected to the Dalsa 1M60

Fiber_Camera_Link_3.jpg: A RCX C-Link and the other end of the 300' fiber connected to the PC

 I installed CentOS on the machine with the EDT frame-grabber. I then installed the frame-grabber software from the CD.

In the /opt/EDTpdv/ directory the camconfig program was run and I entered "331" to start the frame-grabber and run with the Dalsa 1M60 settings ... this was necessary to get the frame grabber running, but didn't seem to force pdvshow, installed at a later point, to use this configuration file. At this point I could access the camera menu with the serial_cmd program.

After some effort, which will be detailed shortly, I managed to finally get the pdv_show GUI program compiled and installed. I found that trying to run that program with the dalsa_1m60.cfg configuration file resulted in a segmentation fault.

However, when I ran it with the default Dalsa configuration file, pantera11m4fr.cfg, and selected "Continuous Exposure" I got a stream of illuminated pixels on the screen. It was clear that the display was displaying the pixels coming back from the camera in the wrong way (for instance, trying to load a 1024x1024 image into a 1440x900 array), however, by changing the frame rate on the camera to 20Hz and waving my hand around in front of the camera I was able to modulate the intensity of the hash of pixels being displayed. This means that the frame-grabber is successfully getting data - it just isn't interpreting it correctly yet.

Here are a couple of images from pdv_show (hit Alt+PrtScrn to get a screenshot of the active window):

 1. Screenshot-PCI_DV_Display.png - the image on the computer with the camera running unobscured

2. Screenshot-PCI_DV_Display-1.png - the image on the computer with me covering the camera with my hand.

3. -opt-EDTpdv.png - the camera parameters at the time of this test (running serial_cmd)

Yesterday, I installed CentOS 5.3 on the Gateway GT5482 machine that housed the EDT frame-grabber.

1. I installed CentOS 5.3 with all the default options
2. As recommended by the README.lnx_pkg_reqs, I tried and failed to install the "Development Tools", "Development Libraries" and the "X Software Development" using the Add/Remove Software.
3. I copied the entire install CD to ~/fgdriver on the hard disk.
4. Installed the following packages at the command line

> yum install gcc

> yum install make

> yum install tk

> yum install kernel

I tried to run ~/fgdriver/linux.go at this point to install the EDT driver, but the installation failed about halfway through with the message "problem making the driver module". An investigation revealed that this was the due to the failure of ~/fgdriver/linux/module/makefile. I tried running that makefile separately to build the driver module and it crashed with the message: Can't find /lib/modules/2.6.18-128.el5/source/include/linux/mm.h. I concluded that the kernel source code wasn't installed

• Added "Development Libraries" with Add/Remove Software
• Ran the following command lines

> yum install kernel-devel

> yum install kernel-xen-devel

 And then I followed the instructions at the link: http://wiki.centos.org/HowTos/I_need_the_Kernel_Source

from: > yum install rpm-build redhat-rpm-config unifdef

 to:  > rpm -i http://mirror.centos.org/centos/5/updates/SRPMS/kernel-2.6.18-164.15.1.el5.src.rpm 2>&1 | grep -v mockb

and at the latter point the rpm build  pissed and moaned that it couldn't find the file kernel-2.6.18-164.15.1.el5.src.rpm

However, some combination of the above must have worked. I rebooted the computer and logged in again as root. At this point the install script ~/fgdriver/linux.go ran from start to finish without complaining. A quick test of the resulting /opt/EDTpdv/camconfig and then /opt/EDTpdv/serial_cmd showed that I could access the Dalsa 1M60 camera through the frame grabber.

I installed a Windows XP virtualization on the Hartmann machine. It can be accessed from the desktop, or by running virt-manager at the command line. Once the virtualization manager starts the virtualization of Windows needs to be started. It runs quite slowly.

I also installed MATLAB on this machine in /apps/. TThis was intended to be /apps/MATLAB/ but apparently the install program doesn't add a top directory called MATLAB as you might expect. I had to run a yum install libXp because it was complaining that "/apps/bin/glnxa64/MATLAB: error while loading shared libraries: libXp.so.6: cannot open shared object file: No such file or directory"

I saw this and tried it when i was installing, but I had more flexibility when I copied the files directly to the hard drive.

Alex Ivanov came in on Friday and demonstrated his EPICS kung-fu. His EPICS knig-fu is strong.

We fixed the IP address of the Hartmann machine, renamed it hartmann, and mounted the cvs drives from the frame builder. - including the EPICS base from that machine. In principle, with a new softIoc, this should have been enough to run EPICS on the hartmann machine. However, whilst the softIoc would start, it wouldn't broadcast any channels. Eventually we figured out that this was because of the Windows Virtualization adding another IP address to the hartmann machine (revealed with /sbin/ifconfig). So we removed the virtualization system and then EPICS seemed to broadcast much better.

The minutia of install isshown in the history files for the controls and root users - attached.

I noticed that when i ran /opt/EDTpdv/camconfig and selected camera 331, which appeared to be closest to the Dalsa Pantera 1M60 camera, the software loaded the configuration file pantera11m4fr.cfg.

I tried to locate which entry in the camconfig list corresponded to the dalsa_1m60.cfg configuration file, but none of them seemed to. I couldn't select any entry and get it to report that it was using the 1m60 config file.

Next I noticed that there were 659 configuration files in the /opt/EDTpdv/camera_config directory but only 460 configuration options in camconfig. This seemed like 1/3 of the config files were somehow not formatted correctly, including,possibly the 1M60 config file.

By editing the pantera11m4fr.cfg I verified that the name of the camera, as it appears in the camconfig program, is the second line in the configuration file. For that file it was:

# CAMERA_MODEL 	"Dalsa Pantera 12 bit single channel camera link"

where the first line is just a single hash. The dalsa_1m60.cfg file did not have a name formatted in the same way as above: it was originally as shown below:

# Dalsa 1m60 config file (freerun)

so i changed the name in that configuration file to the following and it was suddenly available in the list when ./camconfig was run

# CAMERA_MODEL "Dalsa 1m60 config file (freerun)"

I selected that camera (number 53 in the list). Once this was done I ran pdv_flshow/pdvshow again the image that was displayed from the camera appeared to be correctlty demodulated.

Actually, the very first time i ran pdvshow the image was demodulated correctly but it appeared that the origin was offset and then the image wrapped around a little at the edges. However, every successive time I've run pdvshow since then I've had a perfectly demodulated image.

I ran some test patterns by changing the video mode using the serial communications menu in the camera. I also illuminated the Hartmann sensor with a torch/flashlight and got some spot patterns - see attached images.

Also, I've attached the dalsa_1m60.cfg file.

I updated the .bashrc file in controls@hartmann to include aliases for the ezca EPICS commands and a few others. Details shown below:

Also added launchers to the top panel for MATLAB, sitemap, dataviewer and StripTool. The icons for the launchers are located in:

/cvs/users/ops/ligo-launchers/icons

Changes to .bashrc

alias dv="/cvs/opt/apps/Linux/dataviewer/dataviewer"
alias StripTool = "/cvs/opt/apps/Linux/medm/bin/StripTool"
alias medm="/cvs/opt/apps/Linux/medm/bin/medm"
alias sitemap='medm -x /cvs/cds/caltech/medm/c2/atf/C2ATF_MASTER.adl'

# EPICS aliases
alias ezcademod="/cvs/opt/apps/Linux/gds/bin/ezcademod"
alias ezcaread="/cvs/opt/apps/Linux/gds/bin/ezcaread"
alias ezcaservo="/cvs/opt/apps/Linux/gds/bin/ezcaservo"
alias ezcastep="/cvs/opt/apps/Linux/gds/bin/ezcastep"
alias ezcaswitch="/cvs/opt/apps/Linux/gds/bin/ezcaswitch"
alias ezcawrite="/cvs/opt/apps/Linux/gds/bin/ezcawrite"

I added the Dalsa 1M60 temperature measurements to EPICS. The break down is as follows:

I added a softIoc called HWS to /cvs/cds/caltech/target/softIoc. It added the channels following channels: C4:TCS-HWS_TEMP_DIGITIZER and C4:TCS-HWS_TEMP_SENSOR. The ioc (input/output controller) is run with the following command:

/cvs/opt/epics-3.14.10-RC2-i386/base/bin/linux-x86/softIoc HWS.cmd

 I've added the digitizer and sensor board temperature readings from the HWS to the frames. This was done in the following way

1. Create a new file /cvs/cds/caltech/chans/daq/C4TCS.ini - with the channels in it - see below

2.  open /cvs/cds/caltech/target/fb1/master

3. add a line that includes the C4TCS.ini file when the frame builder starts

4. restart frame-builder by killing the daq daemon - kill <process id for daqd> (this is the only thing that needs to be entered as it will automatically restart)

C4TCS.ini

[default]

dcuid=4

datarate=16

gain=1.0

acquire=1

ifoid=0

datatype=4

slope=1.0

offset=0

units=NONE

[C4:TCS-HWS_TEMP_SENSOR]

[C4:TCS-HWS_TEMP_DIGITIZER]

 I added the following line to ~/.bashrc

export PYTHONPATH=/home/controls/scripts/modules:/usr/local/lib/python

Python script

I wrote a Python script, ~/scripts/dalsa_to_epics.py that reads the temperature off the camera using serial_cmd vt and then it writes this to the EPICS channels using ezcawrite. See attached. It is now running continuously in the background as dalsa_to_epics.

Dalsa1M60 baud rate

Also I accessed the menu of the 1M60 and changed the baud rate to 115200 using sbr 115200. Then I edited the dalsa_1m60.cfg file to set the baud rate to 115200 in that file. Finally, I changed the settings on the camera so that it will boot with the new baud rate when it is turned off and on again - this was with wus in the camera menu.

All the files are attached.

~/scripts/dalsa_to_epics.py

~/scripts/Dalsa1M60/VerifyTemperature.py

/opt/EDTpdv/camera_config/dalsa_1m60.cfg

I added the camera parameters to EPICS and the MEDM screen. These are available as channels now in EPICS and eventually there will be a python script that writes the EPICS value to those channels, but right now it is just a python script that reads the values off the Dalsa camera.

I updated the channels in /cvs/cds/caltech/chans/daq/C4TCS.ini so that these are saved to the daq and I also restarted the daq daemon.

The python script that gets the camera parameters is here: scripts/Dalsa1M60/GetCameraParameters.py and the script that writes the parameters to the EPICS channels is here scripts/dalsa_to_epics.py.

These are attached as is C4TCS.ini and HWS.db which defines the new channels.

Here's the error:

 Traceback (most recent call last):

This looks really efficient! However, I think there's a systematic error in the calculation. I tested it on some simulated data and it had trouble getting the centroids exactly right. I need to better understand the functions that are called to get an idea of what might be the problem.

 After much effort trying to get a MATLAB routine to compile in C I discovered the following pieces of information.

1. CentOS will not install a gcc compiler more recent than 4.1.2 with yum install. This is circa 2007. If you want a more recent compiler it must be installed manually.

2. To compile and link C programs that call the MATLAB engine, they must be compiled in MATLAB using the mex command. Every version of MATLAB after R2008b requires the gcc compiler 4.2.3.

3. Building gcc 4.2.3 takes a lot more than 1 hour of compile time. I accidentally killed the build process and gave it up as a lost cause. 

This is an amended version of simple_take.c.

The files below are all in the directory /opt/EDTpdv/hartmann/src

1. simple_hartmann.c   - the C code to access the frame grabber, retrieve an image, load the MATLAB engine and pass the image to MATLAB for centroiding
2. centroid_image.m  - the MATLAB routine that centroids the image
3. get_defocus.m - the MATLAB function that determines the defocus in the centroids
4. build_simple_hartmann.sh - a shell script I wrote that contains the compile and link options to build the thing correctly 

 I've added the following channels to the HWS softIoc in /cvs/cds/caltech/target/softIoc/HWS.db

EPICS and DAQ restart procedure

1. Kill the existing softIoc. Use a "ps -e | grep softIoc" command to determine the process id.
2. After editing the HWS.db file restart the softIoc with the following command:

        3. Edit the /cvs/cds/caltech/chans/daq/C4TCS.ini file and kill the daqd process on fb1. It should restart automatically.

Done!

 Here's a copy of an email I distributed today that describes the centroid and simulation code I wrote.

Hi Won,

I've written some code that generates an image of Gaussian spots and provides you with the coordinates of the centers used to generate those spots. There is the facility to turn on i) photo-electron shot noise, ii) random displacement of the nominal positions of the centers from a regular array and iii) 12-bit digitization to more accurately model the output from a CCD.

I've included an example routine that calls this function and then centroids those spots using a variant of your centroiding algorithm.

You should be able to use this to generate reliable simulated data to test versions of your centroiding algorithm.

Cheers,
Aidan.

Attached files: 
1. test_spot_generation_and_centroiding.m     - the example routine. Run this first
2. generate_simulated_spots.m         - the function to generate the simulated spots in an image and as a set of positions
3. centroid_image.m - the function to centroid an image

dV = 0.385V

Responsivity= 0.65A/W

Transimpedance = 1.5E4 V/A

therefore power= 0.385V / (1.5E4 * 0.65 V/W) = 40uW

Verified that the test-point for the current limit pot on the driver (Wavelength Electronics - LDTC 0520) was at 0.5V. Driver is set to INTERNAL set point at the moment. This is down about 10% below the current limited point.

Voltage across TP7 and TP9 = 0.970V = LD Current Mon

Voltage across TP2 and TP3 = 0.017V = LD P Mon

--- Hartmann sensor ---

-set the sampling rate on the CCD to 16HZ. With the current alignment and intensity this gives as maximum intensity of around 3850 out of 4095. Thus the pixels are not saturated.

- centroid_image located some of the spots - see attached image of spots where those located by the algorithm and circled. I need to play with the threshold level and spot_radius to get this to work properly.

I just replaced the brass Hartmann plate with the Invar one. The camera was off during the process but has been turned on again. The camera is now warming up again. I've manually set the temperature in the EPICS channels by looking at the on-board temperature via the serial communications.

 I also made sure the front plate was secured tightly.

14:55 -  Mindy stopped by with the copper heater spreaders and the cooling fins for the Hartmann sensor. We've set them all up and have turned on the camera to see what temperature above ambient is achieves.

17:10 - Temperature of the HWS with no active cooling( Digitizer = 44.1C, Sensor = 36.0C, Ambient = 21.4C)

 8:10AM - I removed the base plate from the Hartmann sensor. I want to know what steady-state temperature the HWS achieves without the plate.

The photo below shows the current configuration.

11:22AM - (Digitizer - 52.2C, Sensor - 43.8C, Ambient - 21.8C)

I removed the cooling fins from the Hartmann sensor to see what steady-state temperature it reached without any passive cooling elements. I also dropped the set-point temperature for the lab to help keep for getting too hot.

After nearly 3 hours the temperature is:

(Digitizer: 54.3C, Sensor: 46.6C, Ambient: 19.6C)

I switched in just the base piece of the Hartmann sensor. The cooling fins are removed. I bolted the camera securely to the base plate and I bolted the plate securely to the table.

 5:00PM - (Digitizer = 41.9C, Sensor = 33.8C, Ambient = 19.3C)