I think this is a nice debugging find. Its not very robust to use the workstations as 24/7 script machines (as we have found out over the years).
Best is to install a conda env on the main framebuilder machine, and run the perpetual scripts there in a tmux session.
Once its all sehup, update the ATF Wiki with a description of haw its done. Workstations crash when users do stuff, so its better if the data gettin script can run as a system service (e.g. systemctl, etc)
that's good. Can you from these models estimate what the uncertainty will be on the emissivity? i.e. by MCMC or otherwise rather than eyeballing
I've modeled the cooldown of a 2" diameter and 4" diameter Si wafer in Attachments 1 and 2, using the current Megastat model and previous cold head temperature data. The model includes heat leaking into the inner shield enclosure from an aperture, which we currently observe in Megastat cooldowns. (Note how the wafer cools down much faster than the current test mass, due to the very tiny volume.)
I'd recommend drilling a through hole and using a nut, rather than tapping as I suggested earlier. The shield is not thick enough to have many 4-40 threads.
Is it better to have the inner shield inner surface low or high emissivity? \Depending on the effect on the MCMC uncertainties, we may want to make everything black, including the cold plate. i.e. we could mount something like black aquadag tiles on the cold plate.
that's a good start, but we want the cooldown to be fast, so what we would need from the model is for you to change some parameters and find out what kind of possible physical changes we can make to make the cooldown fast. i.e. change some parameters and see what configurations would give a fast cooldown, and then we can discuss which of those is the easiest.
I modeled the cooldown of a 2" Si wafer in Megastat with cooling from a) the existing cryocooler and b) LN2. The only difference between the two models is the temperature that the cold end of the copper bar "sees" - in the cryo-cooler case, I've used cold head temperature data from a previous cooldown; in the LN2 case, I've used 77K. In Attachment 1, the cryo-cooler models are solid lines and the LN2 models are dashed.
It is clear from the plot that the cold head gets ~30K colder than LN2 at 77K. This explains the discrepancy between the inner shield models for the two cases at steady state. While the initial temperature rates of change are greater in the LN2 case, the cold head crosses the 77K line in roughly 5 hours.
Does the true cold-head temperature follow the model? Or is it less good than the model?
From the plot, it seems like the slop is ~50 Ohms / 120 K. So a difference of 5 K corresponds to ~2 Ohms.
It could be that your measurement of the resistance is off slightly due to the lead resistances, etc. Are you using a 3-wire or 4-wire probe?
You can get a higher accuracy relative calibration by dunking all the RTDs together in ice water and then in boiling water.
On their web page (https://www.masterbond.com/properties/thermally-conductive-epoxy-adhesives), they have one with Aluminum Nitride that's twice as conductive. Is that useful to get?
In order to get the strong cooling from the test mass, do we need a more conductive epoxy? (I found this related paper on low temp epoxies).
Today we moved some of the optics away from the blue box to make room for the mode matching.
We also found a 1" diameter optic in one of the cabinets with a transmission of 0.81 % (S-pol). This makes a nice match with the 0.57% transmission of the 2" diameter output coupler and so its now installed. We'll later replace it with a good 2" diameter mirror.
We also moved all of the optics after the laser to align with the screw holes and are trying to make the beams go along the screw hole lines.
Alastair has remeasured the laser beam profile after the EOM and the PBSs using the WinCamD beam scanner. Results are being produced.
The script which cleans up the frame files (so that the disk doesn't become overful) was set to only delete files when the /frames/full directory was getting up to 99.7% of the full capacity. This is ridiculously close to the edge. We set it instead to be 95%. Here's the diff in the /target/fb/wiper.pl script:
fb0:fb>diff wiper.pl wiper.pl~
< $full_frames_percent_keep = 95;
> $full_frames_percent_keep = 99.7;
< $minute_frames_percent_keep = 0.2;
> $minute_frames_percent_keep = 0.005;
The DAQD process was spitting out core files and had also filled up the / partition on FB0. After deleting this the regular system processes were able to run. To check the disk space you can use 'df -h':
Filesystem Size Used Avail Use% Mounted on
224G 24G 189G 12% /
/dev/sda1 99M 28M 66M 30% /boot
tmpfs 1006M 0 1006M 0% /dev/shm
/dev/sdd1 1.4T 142G 1.3T 11% /frames/trend
/dev/sdc1 917G 707G 165G 82% /frames/full
fb1:/cvs 917G 104G 814G 12% /cvs
We found that although NTPD was running on FB0, it had been configured in some really screwy way. We used /sbin/ifconfig to remove the configuration for the other network devices (eth1, eth2, eth3) and set it so that FB0 only talks to the ATF martian network and the router. The router is now configured to NOT filter out the requests from FB0. Now the NTPD works and seems to be correctly fixing the computer's system time. There's still the issue that the ATF FE will change this time as long as the FE is running, but I guess the system clock will once in awhile get fixed when we restart the FE and NTP takes over.
Along the way, I also restored the Xinerama dual-head display on ws1. Alastair somehow believed that it had never been dual-head before, but in fact I elogged the procedure in September. Please don't do any auto-updates on any of these machines unless you know what you're doing. and are willing to fix things after breaking them.
I attached an image showing that I can, indeed, get real time data from one of the _DAQ channels of the gyro.
That's a weird plot. I think we want to see the HOM of the SBs, not the carrier. Or rather, we want to see both but maybe not on the same plot. Are these the SB HOMs?
If so, I think its fine to have an 8th order HOM of a SB to have the same phase shift as the TEM00 SB. I say that the frequency should be between 21 and 45 MHz.
I had a rather lengthy discussion with Aidan, Frank and Koji about this the other day. The resonance peaks are resonances of the cavity for some higher order mode. They can be excited by either the carrier or the SBs impartially. This plot is equivalent to the ones that are in other elog entries (like John's from last year), but it is much less cluttered. Those plots show you exactly how far each higher order mode is from resonance for the carrier and each sideband, whereas this one shows you the resonance frequency of each cavity HOM, along with the frequency of the carrier and SBs, from which you can directly infer how far each one is from whichever mode peak. I think this is a clearer way of doing it, as it emphasizes that the resonances belong to the cavity, not to the light entering it.
No, I disagree. There should be a plot showing how the HOMs of the SBs show up in the cavity. A TEM01 of the +SB will be in a different place than the -SB TEM01 or the CR TEM01.
Came in and found the PMC_PZT output trying to deliver an obscenely large number of counts to the DAC.
Not really sure where the issue is coming from - looks like the filters in the attached module. Anyway, just set a limit on what that module can output for the time being. Will leave this one for DMass to figure out.
Frank was talking about rebooting the frame builder last night. That shouldn't have affected the front end though. But if we do want to reboot the front end will all our settings be saved and restored automatically?
Filt 1 integrates.
Infinite gain at DC.
There's constant input.
My locking algorithm:
You should try just leaving FM4 on all the time. Since the purpose of this FM is to make the loop 1/f everywhere from 1Hz to several kHz, the loop should be stable over very large gain ranges. This makes locking much easier.
There were no testpoints according to DTT and DV - This is because:
/cvs/cds/caltech/target/gds/param/tpchn_M1.par was commented out of /cvs/cds/caltech/target/fb/master.
Changing this solved (some of) the problems we encountered.
We also encountered an unkillable frontend process at some point -
The above appeared to be correlated with running startatf a number of times, (so killing and restarting everything repetitively.) We have zero interest in trying to repeat the unkillable bug so we rebooted oms and everything seemed ok.
pkill can not slay the processes spawned by the .rtl files, because they are kernel modules, and thus operate in a lower domain. Sometimes you may invoke the demon of /sbin/rmmod instead of rebooting.
I borrowed (retrieved?) the TED200C temperature controller from the north table in QIL to use in the cryo lab.
Yehonathan brought over 532nm/1064nm laser goggles from the 40m.
Our next step would be to measure the LO shot noise.
Since we had left the lasers ON with the shutters closed we wanted to see if the powers measured after opening the shutter would be similar to what it was when we left. We realized that opening and closing the green shutter destabilizes the doubling cavity (the FI is after the shutter and the shutter does not seem to be a good dump), which in turn changes the SHG crystal temperature (possibly because of the power fluctuation within the crystal). Re-opening the shutter requires some tuning of the temperature and offset to recover similar output power. Finally, after some tuning, we were able to see 156 mW of green light.
Yesterday we went back to fiddling with the green path. Soon after opening the green shutter and then switching the doubling cavity to 'AUTO' we were able to see 150 mW of green light. We were able to replicate this a couple of times yesterday.
Since we had earlier removed the green fiber from the fiber launch to clean its tip, the coupling into the fiber turned out to be quite poor. As can be seen in Attachment 1, Yehonathan pointed out that a lot of green light was being lost to the cladding due to poor coupling. He then played around with the alignment and finally was able to see 65% coupling efficiency. This process seemed to involve a great amount of trial and error through several local power minima.
Attachment 2 shows that the coupling between the two fibers at the 532 nm input of the waveguide is quite poor (there is visible light being lost in the cladding). Furthermore, this light intensity decreases as we get closer to the waveguide meaning this light is being dissipated in the fiber. Even at the 1064 nm output where we expect to see squeezing there is some remnant green light.
We wanted to test if the green leakage reaching the PDs were causing additional noise. For this we just looked at the spectrum analyzer on the Moku (after amplifying 100x with the SR 560) and saw no difference in the noise spectrum with and without the green shutter being open. Although, we're not convinced with this measurement since we were not able to find good quality SMA cables for the entire path. Moving around the BNCs seemed to change the noise. Also, near the end, we noticed some coupling between the two channels on the Moku while measuring the noise that seemed to cause additional noise in one of the channels. We did not have sufficient time yesterday to probe this further.
When I went into QIL today there was a lot of flooding from water dripping from the ceiling at several places in the lab. Images attached.
First we turned on the relevant instruments for this experiment after the power shutdown:
- Main laser drivers and doubling cavity controller. We set the current to 2 A as we had it before.
- The waveguide TEC. We tried setting it to 60.99 C (for maximum efficiency) but the temperature ramps up much faster and over shoots the setpoint. So we had to do what we did earlier which was to adiabatically change the setpoint from room temperature and finally set it to something like 63 C so the actual measured temperature stabilizes at ~60.9 C. How do we change the PID parameters on this controller? The settings don't seem to allow for it.
- PD power supply, oscilloscopes, function generator, SR 560s lying nearby
Then we tried to probe further what was going on with the PDs (TL;DR not much made sense or was reproducible):
After conversations with Alastair and Steve, I have come up with the following design for the new (AR, wedged) viewports for the gyro vacuum system. I turns out that we already---for some time---have the optics (W2-LW-1-C-1064-0) and CF blanks that we need.
So, all we need to do is:
A glance at the diagram below will make the above make sense.
I am going to talk to Mike Gerfen on Monday to see what he thinks.
The plastic brace-delrin on the top has to function on the top: 1, hold the window in place at atm 2, keep dust-dirt out.
The window should sit on a thin teflon gaskit on the vacuum side
I had decided to just use the chamber as it was, but then Frank and Alastair both independently suggested that I at least spend a day or so trying to track down any egregious leaks that may exist. Alastair had bought 2 KF blanking flanges explicitly for this purpose, so it was hard to resist.
The procedure is pretty time consuming and so is still underway, but it basically goes like this:
Going through all possible combinations is intractably time consuming and probably pointless, so I have gone about it in a somewhat haphazard but reasonable way. First I removed one corner chamber, then another chamber (so, 2 total) and the tube between them, and so on. I've gone through three iterations so far while doing other things today, and the fourth one I've left running overnight is just one corner chamber (the one to which the pump is connected) and two hoses. I think the last two that I'll try are just 1) one chamber by itself and 2) one hose by itself.
The goal is to see if any combination is drastically better than the entire system. So far, all combinations get to ~7 uTorr within 2-3 hours. If there is no obvious "bad part", then I will chalk it up to the overall quality of the o-rings and/or residual water in the tank.
It should be reiterated that there is no "goal pressure" for the gyro so far. The original idea was just to evacuate the area within the cavity to reduce air noise from index of refraction fluctuations and buffeting. So, uTorr vacuum should be fine---and perhaps even the mTorr level we get without a pump attached---but it can't hurt to remove any gaping holes in the system.
1, do not use solvent to clean o-rings,try dry lint free wipers
2, use solvent to detect leaks on metal seals only
3, spray some gas or bag-fill suspected piece
4, remove water and solvent saturated o-rings and replace them with dry cleaned ones
I cleaned the viewport components and began installing them this afternoon. All the parts were cleaned and the chambers were prepped, but I was only able to install the two input-side viewports tonight. The cleaning procedure was as follows:
The mounting went largely without incident except for the placing of the thin Teflon gaskets. These are meant to go around the circumference of the inner (vacuum-seal) Viton o-rings to keep the window glass from compressing against the steel around the o-ring at vacuum. The problem is that without o-ring compression, the gasket is free to slide down into a position where it would obstruct the glass/Viton seal, which is obviously no good. It could be that the glass will never actually touch the metal anyway, but if it does we might want to consider some other option.
I also re-cleaned the inside of the 4 corner chambers with acetone and then methanol, having removed all optics from them first.
As you can tell from the second picture above, there is no longer enough space at the edge of the table for a steering mirror into the vacuum from the N side. It looks like I can make room by sliding the entire vacuum system to the S by an inch or so. The way the flexi-hoses are designed, they compress quite noticeably upon pump-down. So, unless the corner chambers are bolted to the table, the system does not have the correct form factor at atmosphere (if the chambers are bolted, then the flexi-hoses are just put under stress). For this reason, it is best to move the tanks around after the system has been evacuated, so this is what I plan to do.
Another benefit of moving it while evacuated is that I can do a test run of the system without any optics inside. I also plan to use the resistive heating tape we have to "bake" the chamber in-situ before re-venting and installing the optics.
I am waiting to find out if I can borrow the cryo turbopump, but if not I will have to share with the coating Q setup (which will suck). The other two viewports will be installed tomorrow and I can go from there.
The viewport should be assembled in horizontal position first and installed on CF later. Drill holes into the delrin piece so you can reach the CF bolts.
The delrin part should be bigger to protect the optic, o-ring from dust.
Here is the entry about EOM temp control used in PSL.
We might use the similar one for gyro. I need to check the performance of the servo.
I made a thermal insulation box for the cell holder that will be used in iodine setupr, see ATF:1665. I used the similar style to CTN refcav insulation. We can make more space in the foam to hold more thermal sensors later. I'll see if I can test how good it can stabilize the temperature tomorrow.
Plus, I also made another thermal insulation for an EOM. It is based on what frank did inPSL:744. It can be used for Gyro or for CTN lab when I have to install two lasers later.
Zach and I borrowed 2 seismometers from the 40m. Den gave us Guralp and Barcadi with their breakout boxes.
We added the seismometers to compare it with gyro readout noise in hope that we can see any coherence between gyro noise and seismometer noise. Since, at low frequencies, tilt and seismic noise will both show up on seismometers, but only tilt will show up in gyro. Any coherence between gyro and seismic signal should confirm us that the measured gyro signal is real (coming from tilt).
The signals from Guralp are ~ +/-1.5 V for all 3 channels. Signals from Barcadi are much smaller ~+/- 50mV because the gain stages are broken and not in used. We will add some preamps before DAQ. However, the signals between the two seismometers appeared to be the same. We did a quick check by tapping the table and looking at the response. We could see table's frequency at 9 Hz (for Horizontal motion).
fig1: breakout boxes are on the ground next to DAQ. fig2,3 Guralp and Barcadi on gyro table.
fig4: orientations and positions of the two seismometers.
Found the beat, the temperature on CTN laser is 48.80 C, and gyro laser is 54.72 C for a 20MHz beat signal.
Before trying to scan the laser by changing the temperture, I suspected that we did not see beat yesterday because either,
A 121307 161942 0100 0.3 000000 0.5 000000 TMP 000680 R/H 000130 LOC 000000 C/S 000E54
A 121307 164641 0100 0.3 000000 0.5 000000 TMP 000680 R/H 000130 LOC 000000 C/S 000E53
A 121307 171340 0100 0.3 000000 0.5 000000 TMP 000685 R/H 000130 LOC 000000 C/S 000E52
A 121307 174039 0100 0.3 000000 0.5 000000 TMP 000680 R/H 000200 LOC 000000 C/S 000E53
A 121307 180738 0100 0.3 000000 0.5 000000 TMP 000680 R/H 000210 LOC 000000 C/S 000E57
A 121307 183437 0100 0.3 000000 0.5 000000 TMP 000680 R/H 000210 LOC 000000 C/S 000E56
A 121307 190136 0100 0.3 000000 0.5 000000 TMP 000680 R/H 000195 LOC 000000 C/S 000E5C
A 121307 192835 0100 0.3 000000 0.5 000000 TMP 000685 R/H 000195 LOC 000000 C/S 000E69
Following Alex's suggestions, I fixed the front-end problems we were encountering the other day.
To get the shared libraries stuff to work, I inspected the contents of /etc/ld.so.conf.d and
found it all looking fine. I ran /sbin/ldconfig, which updates some shared library index
somewhere, which seemed to fix the problem with the EPICS server finding its libraries. To create
the /rtl_mem_atf file, I edited /etc/rc.local, adding "atf" to the list of subsystems. I believe
that everything now works to compile and run the ATF front-end system.
As a reminder, some useful commands:
cvs update refreshes the software distribution from CDS
make atf recompiles the front-end system
make install-atf installs new front-end binary and scripts
make install-daq-atf installs DAQ channel stuff to framebuilder
make install-screens-atf makes new generic MEDM screens
killatf Stop the front end code
startatf Stop and then start the front-end-code
If you want to change the name of the computer itself, I think you just
need to (1) edit /etc/sysconfig/network and change the hostname; and (2)
etc /etc/hosts on all the machines from which you'll be connecting to the
front-end machine (at the moment, just ws1?).
[fixed command syntax - 7/22/08 DYM]