The framebuilder on FB4 thinks the current time is 26-Jan-2018 6:18AM UTC. The date command on FB4 yields the correct date and time (5-Feb-2018 15:17 PST).
There is a major error with the framebuilder clock.
Attached for reference is the RIN measurement from the initial data.
The 400 mW CO2 laser on the Hartmann table is currently configured for a measurement of its relative intensity noise. It is aligned to a TCS CO2P photodetector powered by a dual DC power supply beside the light enclosure. I got some data last night with the laser current dialed back for low output power (0.5-10 mW incident), but still need to analyze it. In the meantime please don't remove parts from the setup, as I may need to repeat the measurement with better power control.
I implemented an access point for LDAS to pull data from the TCS lab EPICS frame archive (fb4:/frames) via rsync. The setup is analogous to what is already running at the 40m for automated backups. Here are the implementation details in case we want to replicate this in other W. Bridge labs.
Two lab machines are needed, the frame builder machine (fb4; 10.0.1.156) and a second machine to handle the network interfacing with the outside world (tcs-ws; 10.0.1.168).
1. Set up an NFS mount on tcs-ws to remotely access the frame archive on fb4.
i. NFS server-side setup:
a. Install the required packages
controls@fb4:~$ sudo apt-get install rpcbind nfs-common nfs-kernel-server
b. Add the following line to the file /etc/exports
c. Restart the NFS-related services
controls@fb4:~$ sudo /etc/init.d/rpcbind restart
controls@fb4:~$ sudo /etc/init.d/nfs-common restart
controls@fb4:~$ sudo /etc/init.d/nfs-kernel-server restart
ii. NFS client-side setup:
controls@tcs-ws:~$ sudo apt-get install rpcbind nfs-common
b. Add the following line to the file /etc/fstab
10.0.1.156:/frames /fb4/frames nfs rw,nofail,sync,hard,intr 0 0
c. Create the directory for the mount point, then set ownership and permissions
controls@tcs-ws:~$ sudo mkdir /fb4/frames
controls@tcs-ws:~$ sudo chmod -R 775 /fb4
controls@tcs-ws:~$ sudo chown -R controls.root /fb4
c. Mount the new network drive
controls@tcs-ws:~$ sudo mount -a
2. Configure the rsync daemon on tcs-ws.
i. Create a new file named /etc/rsyncd.conf with the following content. These settings match those of the 40m setup.
max connections = 10
read only = yes
log file = /var/tmp/rsyncd.log
list = yes
uid = controls
gid = controls
use chroot = yes
strict modes = yes
pid file = /var/run/rsyncd.pid
comment = For LDAS access to TCS lab frame files
read only = yes
path = /fb4/frames
hosts allow = ldas-grid.ligo.caltech.edu,localhost
ii. Kill, then restart the rsync daemon. The daemon may not be already running.
controls@tcs-ws:~$ sudo kill `cat /var/run/rsyncd.pid`
controls@tcs-ws:~$ sudo rsync --daemon
3. Open a port through the gateway firewall for LDAS to access.
To do this, configure a new port forwarding on the linksys gateway router in the usual way (access the router settings via http://10.0.1.1 from the web browser of any subnet machine). For the TCS lab, the external-facing gateway port 2046 is forwarded to port 873 of tcs-ws (the standard rsync port).
Security is handled by the tcs-ws rsync daemon. Its config file allows outside access to only the hostname ldas-grid.ligo.caltech.edu, and that access is read-only and restricted to the /fb4/frames directory.
For testing purposes, another outside machine name can be temporarily appended to the "hosts allow" parameter of /etc/rsyncd.conf. For example, I appended my office desktop machine. From the outside machine, the connectability of the rsync server can be tested with:
user@outside-hostname:~$rsync -dt rsync://188.8.131.52:2046/ldasaccess
If successful, the command will return an output similar to
drwxr-xr-x 4096 2017/08/28 16:13:31 .
drwxr-xr-x 4096 2017/11/14 02:30:38 full
drwxr-xr-x 4096 2017/08/28 16:13:38 trend
showing the contents of the frame archive.
We've had trouble logging into FB4. I access the computer directly in the AWC lab and found that the IP address had changed from 10.0.1.156 to 10.0.1.161.
I'm not sure how this happened. It's possible that the IP address is not set to a static value and FB4 was rebooted. I'm not familar with Debian so I don't know where to look to find whether the IP address is static or not.
The DAQD is still running.
I set up an Acromag DAC today with the fixed IP address 10.0.1.56. Last Friday Andrew and Antonio set up an ADC unit with fixed IP address 10.0.1.55. The former is for outputting a control voltager that goes to the driver for the heater on composite mirror we are testing. The latter is used to read the temperature of the thermocouple on the composite mirror. The thermocouple to voltage conversion is achieved with a Type K Thermocouple Amplifier unit from The Sensor Connection.
The temperature sensor channel is C4:AWC-TEMPMON_C. We took a couple of different measurements of temperature and calibrated the conversion from volts to Celsius as: C = 122.06*V -0.67
The new temperature sensor channel is now being recorded in the frames.
For archive purposes, attached is a write-up of all the HWS measurements I've made to date for the SRM CO2 projector mock-up.
See attached photo for how data is written to frames ...
These are also being written to frames on FB4.
I've added a softIoc to TCS-WS to capture the beam size from the MAKO camera. The IOC is run using ...
controls@tcs-ws:~$ softIoc -S EPICS_IOC/iocBoot/iocfirst/st.cmd &
The st.cmd contains the following text:
controls@tcs-ws:~$ more EPICS_IOC/iocBoot/iocfirst/st.cmd
The db file is:
controls@tcs-ws:~$ more EPICS_IOC/db/beamSize.db
I fixed a bug in how the raw Mako CCD camera images are being read into memory. The bmp files turn out to have a block memory layout that broke my in-place reader.
Aidan found a C demo code for acquiring a single image from the Mako CCD camera and saving it to disk (SynchronousGrab -- aliased on tcs-ws as makoGrab). I wrapped that inside my realtime HWS beam profiler code to create a realtime beam profiler for the Mako camera. The interface is identical to that for the HWS.
The Mako camera is running on the tcs-ws machine (10.0.1.168) and is launched from the console via the command
It is currently configured to write a raw image to the local frame archive every 5 seconds (it prints the write location in the console), which can be disabled by setting the "-d" flag.
There is an SDK for the camera with compiled examples. For a really quick image grab from the command line, use the following:
This will produce a BMP image. We should probably recompile the C code to produce a 16-bit TIFF image.
I installed the Maku Gigabit CCD camera driver software on the hws-ws machine. The camera viewer can be opened from the terminal (from any directory) with the command
and there is also a shortcut icon on the desktop. The camera is ocurrently on the subnet at 10.0.1.157 and is configured to get its IP via DHCP. We can assign it a static IP if we'd like to keep it on the network permanently.
I left the camera mounted on the CO2 laser table. It's connected and ready to use.
There were known to be huge (65%) heating beam power losses on the SRM AWC table, somewhere between the CO2 laser and the test optic. Today I profiled the setup with a power meter, looking for the dominant source of losses. It turned out to be a 10" focusing lens which had the incorrect coating for 10.2 microns. I swapped this lens with a known ZnSe 10" FL lens (Laser Research Optics LX-15A0-Z-ET6.0) and confirmed the power transmittance to be >99%, as spec'd. There is now ~310 mW maximum reaching the test optic, meaning that the table losses are now only 10%.
Using a single-axis micrometer stage I also made an occlusion measurement of the heating beam radius just in front of the test optic. I moved the 10" focusing lens back three inches away from the test optic to slightly enlarge the beam size. In this position, I measure a beam radius of 3.5+/-0.25 mm at 1.5" in front of the test optic (the closest I can place the power meter). The test optic is approximately 20" from the 10" FL lens, so the beam has gone through its waist and is again expanding approaching the test optic. I believe that at the test optic, the beam is very close to 4 mm.
I measured the reflectivity of a possible HWS replacement mirror at 532nm. Thorlabs BB2-EO3
Incident power = 1.28mW
Reflected power = 0.73mW
R = 56% at 45 degrees AOI.
Today I made the first characterization measurements of the mocked-up adaptive wavefront control system planned for the signal recycling mirrors.
Inside the light-tight enclosure on the center table, I've assembled and aligned a 10.2 micron CO2 projector which provides a heating beam of up to 150 mW incident on an SRM-like test optic. A co-aligned 633 nm probe beam and Hartmann wavefront sensor are used to measure the resulting thermal lens. I've written and installed new software on the machine hws (10.0.1.167) for viewing the wavefront distortion in real time, as shown in the below screenshot. This viewer is launched from the terminal via the command $stream_gradient_CIT
There is also a second utility program for displaying the raw Hartmann sensor CCD image in real time, which is useful for aligning the probe beam. It is launched by the terminal command $stream_intensity_CIT
Lens Formation Time Scale
First, I made a time-resolved measurement of the thermal lens formation on the test optic at maximum heating beam power (150 mW). The lens appears to reach steady-state after 30 s of heating. When the heating beam is turned off, the lens decays on a very similar time scale.
Lens Strength v. Incident Heating Power
Second, I measured the thermal lens strength as a function of incident heating beam power, which I measured via a power meter placed directly in front of the test optic. Below is the approximate maximum optical path difference induced at several heating beam powers.
The above optical path differences are approximate and were read-off from the live display. I recorded Hartmann sensor frame data during all of these measurements and will be analyzing it further.
I replaced the dead 24" monitor on the work bench, which is connected to the video multiplexer. Mike Pedraza was kind enough to bring us us a new one and take away the old one.
Borrowed thorlabs power meter on 21 Sep 2017. It is on the south table of the ATF lab.
I lent your fancy Newport TrueRMS Supermeter with the thermocouple plugs on the top to the SURF student Jordon. He has it in the cryo lab or the EE workshop with one of the PSL lab temperature probes.
The data from the long-term measurement of the HWS is presented here. The beam envelope moves by, at most, about 0.3 pixels, or around 3.6 microns. The fiber-launcher is about 5" away from the HWS. Therefore, the motion corresponds to around 30 micro-radians (if it is a tilt). The beam displacement is around 4 microns.
The optical properties change very little over the full 38 days (about 2 micro-radians for tilt and around 2 micro-diopters for spherical power).
The glitches are from when the SLED drivers were turned off temporarily for other use (with the 2004nm laser).
I noticed that the TCS lab temperature sensor batteries died. Apparently they died two days ago. I swapped in some new batteries this morning.
I've started a long-term measurement of the HWS fiber-launcher. I'm interested in seeing how stable the output is. The HWS is currently running in the following configuration:
The HWS is currently running at 57Hz. The HWS code is running on HWS (10.0.1.167). It is the same as the site code with some modifications to determine information about the Gaussian beam envelope. The following data is written to file on the HWS machine in files containing 10,000 cycles. Each cycle (or row) the following data is recorded:
These are saved to files on the HWS machine: ~/framearchive/C4/HWSlongterm/<GPSTIME>_CIT_HWS.txt
Spelt out in a searchable fashion:
iface <portname> inet static
dns-nameservers 10.0.1.1 184.108.40.206 220.127.116.11
These settings work to get a computer onto the TCS/ATF network.
Made a COMSOL model that can include CO2 laser heating, self heating, and ring heating
Figured out how to run SIS out of a script and set up commands to run the two SIS stages of the model
-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.
- Finished the MatLab code that both combines two fields and simulates the adjustment of the beamsplitter to minimize the power out (with a small offset).
- Added the signal recycling telescope to the SIS code that generates the fields
To Do: Make the OMC cavity in SIS
Plan for building the model
- Find the fields that would be incident on the beam splitter from each arm (This is done already)
- Propagate these through until they get to the OMC using the TELESCOPE function in SIS
- Combine the fields incident on the OMC in MATLAB and minimize the power to get the input field for the OMC (Most of this is done, just waiting to figure out what kind of format we need to use it as an SIS input)
- Model the OMC as an FP cavity in SIS
+ Need to think about how to align the cavity in a sensible way in SIS (need to find out more about how they actually do it)
- Pick off the fields from both ends of the OMC-FP cavity for analysis
- Add thermal effects to one of the arms and see how that changes the fields, specifically how the signal to noise ratio changes
- Discussed the further project with Dr. Brooks.
-Tried to derive formula for the test mass inside cryogenic shield(infinitely long shield from one side)
-Updated 3 week progress report with new additions and deletions.
-Attended LIGO lecture which was very interesting and full of information.
- Paper edits and more data generation for the paper (lower resolution grid data)
- Attended a talk on LIGO
-Attented LIGO orientation meeting and safety session.
-Prepared 3 week report
- Attended a lot of meetings (Safety, LIGO Orientation)
- Finished draft of week 3 report (images attached)
- Did more modeling for different levels of heating and different mesh densities for the SIS input.
- Lots of orientation stuff
- Started on progress report.
-Read about blue team design for maximum power budget.
-Read third generation talks to get a better understanding of the work.
- Verified that the SIS output does match satisfy the equations for Gaussian beam propagation
- Investigated how changing the amount of data points going into SIS changed the output, as well as how changes in the astigmatic heating effect the output
+ The results are very dependent on number of data points (similar order changes to changing the heating)
+ Holding the number of data points the same, more assymetric heating tends to lead to more power in the H(2,0) mode, and less in the H(0,2)
- Plugged the output of the model with uniform heating into SIS using both modification of the radius of curvature, and direct importation of deflection data
- Generated a graph for asymmetric heating and did the same
- Aligned axes in model to better match with the axes in MATLAB and SIS so that the extrema in deflections lie along x and y (not yet implemented in the data below)
FP cavity modal analysis using cold optics parameters
ROC(ITM) = 1934, ROC(ETM) = 2245, Cavity lenggth = 3994.499999672, total Gouy = 2.7169491305278
Fval(ITM) = -4297.7777755379, OPL(ITM) = 0.13793083662307, Fval(ETM) = -4988.8888885557
waist size = 0.01203704073212, waist position from ITM = 1834.2198819617, Rayleigh range = 427.80682127602
Mode parameters of cavity fields
ETM AR (out base) : w = 0.0619634 R = 1548.276 z = 1519.925 z0 = 207.583 w0 = 0.008384783
-Derived formula for manual calculation of temperature due to total influx.
-Compared the results by COMSOL and by the formula.
- Realized that the strange deformations that we were seeing only occur on the face nearest the ring heater, and not on the face we are worried about (the HR face)
- Read papers by Morrison et al. and Kogelnik to get a better understanding of the mathematics and operations of the optical cavity modeled in SIS
- Read some of the SIS manual to better understand the program and the physics that it was using (COMSOL licenses were full)
-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.
- Fixed the (ts) model, got strange results that indicate that the antisymmetric heating mode is much more prominent than previously thought
- Managed to get COMSOL data through matlab and into SIS
-Created a COMSOL model for cryogenically shielded test mass with compensation plate.
-Analyzed the behavior of the model in different size configurations.
- Tried to fix COMSOL error using the (ts) module, ended up emailing support as the issue is new in 4.3
- Managed to get a symmetric geometric distortion by fixing the x and y movements of the mirror to be zero (need to look for a better way to do this as this may be unphysical)
- Worked on getting the COMSOL data into SIS, need to look through the SIS specs to find out how we should be doing this (current method isn't working well)
-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 with thermal deformations
- Added non-symmetrical heating to cause astigmatism
- Worked on a method to compute the optical path length changes in COMSOL
-Discussed the actual project outline
-Installed Comsol on the system
-Learned the basics of Comsol with the help of tutorials available on 40m wiki
-Made few simple models in Comsol
-Studied LIGO GWADW slides for a better understanding of the project.
-Setup SVN to access remote repository.
- Got access to and started working with SIS on Rigel1
- Fixed SVN issues
- Refined COMSOL model parameters and worked on a better way to implement the heating ring to get the astigmatic heating pattern.
- Had a meeting to talk about the basics of LIGO (esp. TCS) and discuss the project
- Created COMSOL model for the test mass with incident Gaussian beam.
- Added a ring heater to the previous file
- Set up SVN for the COMSOL repository