I know it's really hard to remember, but our future selves will thank us dearly if we remember to commit all of our code changes to the svn with nice log messages. At the moment there's a LOT of modified stuff in the userapps working directory that needs to be committed:
controls@pianosa:/opt/rtcds/userapps/release 0$ svn status | grep '^M'
This doesn't even include things that haven't even been added yet. It doesn't take much time. Just copy and paste what you elog about the changes.
Let's see if the ripples observed in the MC ringdown can be due to tilt motion of the mirrors.
The time it takes to produce a phase shift corresponding to N multiples of 2*pi is given by:
t = sqrt(2*N*lambda/(L*omega_T^2*(alpha_1+alpha_2)))
L is the length of the MC (something like 13m), and alpha_1, alpha_2 are the DC tilt angles of the two mirrors "shooting into the long arms of the MC" produced by the MC control with respect to the mechanical equilibrium position. omega_T is the tilt eigenfrequency of the three mirrors (assumed to be identical). lambda = 1.064e-6m;
The time it takes from N=1 to N=2 (the first observable ripple) is given by: tau1 = 0.6/omega_T*sqrt(lambda/L/(alpha_1+alpha_2))
The time it takes from N=2 to N=3 is given by: tau2 = 0.77*tau1
First, we also see in the measurement that later ripples are shorter than early ripples consistent with some accelerated effect. The predicted ripple durations tau seem to be a bit too high though. The measurements show something like a first 14us and a late 8us ripple. It depends somewhat on the initial tilt angles that I don't know really.
In any case, the short ripple times could also be explained if the tilt motions start a little earlier than the ringdown, or the tilt motion starts with some small initial velocity. The next step will be to program a little ringdown simulation that includes mirror tilts and see what kind of tilt motion would produce the ripples exactly as we observe them (or maybe tilt motion cannot produce ripples as observed).
Isn't it just a ringing of the intracavity power as you shifted the laser frequency abruptly?
Hmm. I don't know what ringing really is. Ok, let's assume it has to do with the pump... I don't see how the pump laser could produce these ripples. They have large amplitudes and so I always suspected something happening to the intracavity field. Therefore I was looking for effects that would change resonance conditions of the intracavity field during ringdown. Tilt motion seemed to be one explanation to me, but it may be a bit too slow (not sure yet). Longitudinal mirror motion is certainly too slow. What else could there be?
Laser frequency shift = longitudinal motion of the mirrors
Ok, so the whole idea that mirror motion can explain the ripples is nonsense. At least, when you think off the ringdown with "pump off". The phase shifts that I tried to estimate from longitudinal and tilt mirror motion are defined against a non-existing reference. So I guess that I have to click on the link that Koji posted...
Just to mention, for the tilt phase shift (yes, there is one, but the exact expression has two more factors in the equation I posted), it does not matter, which mirror tilts. So even for a lower bound on the ripple time, my equation was incorrect. It should have the sum over all three initial tilt angles not only the two "shooting into the long arms" of the MC.
With a curvature radius of about 57m for the ETMs, flat ITMs at the beam waist, and using 39m for the arm lengths, one finds that the beam radius at the ETMs is about 5.3mm. The clipping power loss of a 5.3mm beam through a 20mm radius baffle hole would be less than a ppm of a ppm if the beam was perfectly centered. If the baffle hole had 15mm radius, the clipping loss would be 0.01ppm. If the baffle hole had 10mm radius, the loss would be 810ppm. The loss values are calculated using the formula of the "Gaussian beam" Wikipedia article, "Power through an aperture" section. So I did not check if that one is ok.
I finally managed to get long stretches of PRMI lock, up to many minutes. The lock is not yest very stable, it seems to me that we are limited by some yaw oscillation that I could not trace down. The oscillation is very well visible on POP.
Presently, PRCL is controlled with REFL55_I, while MICH is controlled with AS55_Q. This configuration is maybe not optimal from the point of view of phase noise couplings, but at least it works quite well. I believe that the limit on the length of locks is given by the angular oscillation. I attach to this entry few plots showing some of the lock stretches. The alignment is not optimal, as visible from a quite large TEM01 mode at the dark port.
Here are the parameters I used:
MICH gain -10 PRCL gain -0.1
Normalization of both error signal on POP22_I with factor 0.004
Triggering on POP22: in at 100, out at 20 for both MICH and PRCL.
POP55 demodulation phase -9
MICH and PRCL control signal limits at 2000 counts
There is a high frequency (628 Hz) oscillation going on when locked (very annoying on the speakers...), but reducing the gain made the lock less stable. I could go down to MICH=-1.5 and PRCL=-0.02, still being able to acquire the lock. But the oscillation was still there. I suspect that it is not due to the loops, but maybe some resonance of the suspension or payload (violin mode?). There is still some room for fine tuning...
Lock is acquired without problems and maintained for minutes.
Have a nice week-end!
I put a notch in FM10 for both MICH and PRCL at 628Hz, to try to prevent us from exciting the mode that Gabriele saw on Friday. Since those filter banks were all full, I have removed an ELP50 (ellip("LowPass",4,1,40,50)). I write it down here, so we can put it back if so desired.
Koji asked me to perform a simulation of the response of POP QPD DC signal to mirror motions, as a function of the CARM offset. Later than promised, here are the first round of results.
I simulated a double cavity, and the PRC is folded with parameters close to the 40m configuration. POP is extracted in transmission of PR2 (1ppm, forward beam). For the moment I just placed the QPD one meter from PR2, if needed we can adjust the Gouy phase. There are two QPDs in the simulation: one senses all the field coming out in POP, the other one is filtered to sense only the contribution from the carrier field. The difference can be used to compute what a POP_2F_QPD would sense. All mirrors are moved at 1 Hz and the QPD signals are simulated:
This shows the signal on the POP QPD when all fields (carrier and 55 MHz sidebands) are sensed. This is what a real DC QPD will see. As expected at low offset ETM is dominant, while at large offset the PRC mirrors are dominant. It's interesting to note that for any mirror, there is one offset where the signal disappears.
This is the contribution coming only from the carrier. This is what an ideal QPD with an optical low pass will sense. The contribution from the carrier increases with decreasing offset, as expected since there is more power.
Finally, this is what a 2F QPD will sense. The contribution is always dominated by the PRC mirrors, and the ETM is negligible.
The zeros in the real QPD signal is clearly coming from a cancellation of the contributions from carrier and sidebands.
The code is attached.
const Pin 1 # input power
const Lprc 6.752 # power recycling cavity length
const d_BS_PR3 0.401 # folding mirror distances
const d_PR2_PR3 2.081
const d_PRM_PR2 1.876
const c 299792458 # speed of light
const fmod 5*c/(4*Lprc) # modulation frequency, matched to Lprc
% compile simulation class
m = MIST('foldeddoublecavity.mist');
% create simulation object
s = FoldedDoubleCavity(8);
% set angulat motion
When I got back to the lab, there was enough water that it was seeping under the wall, and visible outside. Physical plant says it will take an hour before they can come, so I'm getting dinner, then will let them in.
The guy from physical plant came, and turned off the water to the kitchen sink. He is putting in a work order to have the plumbers come look at it on Monday morning. It looks like something is wrong with the water heater, and we're getting water out of the safety overpressure valve / pipe.
The wet things from under the sink are stacked (a little haphazardly) next to the cupboards.
Last supper before departing at "Grazie" El Portal. All the best on your journey!
While tightening the bolts on the ETMX wire clamp, the wire broke. All four face magnets broke off.
Fortunately, no pieces were lost.
For the rest of this vent, at least, we need to start using the EQ stops more frequently. Whenever the suspension is being worked on clamp the optic. When you need it to be free back off the stops, but only by a few hundred microns - never more than a millimeter.
Best to take our time and use the stops often. With all the magnets being broken off, its not clear now how many partially cracked glue joints we have on dumbells which didn't completely fall off.
"Why does the word wrapping not work in our browsers with ELOG?" I sometimes wonder. Some of the elogs are fine, but often the 40m one has the text run off the page.
I found that this is due to people uploading HUGE images. If you need to do this, just use the shrink feature in the elog compose window so that we only have to see the thumbnail at first. Otherwise your 12 MP images will make it hard to read everyone else's entries.
A novice was learning at the feet of Master Daqd. At the end of the lesson he looked through his notes and said, “Master, I have a few questions. May I ask them?”
Master Daqd nodded.
"Do we record minute trends of our data?"
"Yes, we record raw minute trends in /frames/trend/minute_raw"
"I see. Do we back up minute trends?"
"Yes, we back up all frames present in /frames/trend/minute"
"Wait, this means we are not recording our current trends! What is the reason for the existence of seperate minute and minute_raw trends?
“The knowledge you seek can be answered only by the gods.”
"Can we resume recording the minute trends?"
Master Daqd nodded, turned, and threw himself off the railing, falling to his death on the rocks below.
Upon seeing this, the novice was enlightened. He proceeded to investigate how to convert raw minute trends to minute trends so that historical records could be preserved, and precisely when Master Daqd started throwing himself off the mountain when asked to record minute trends.
It took at least ten years to rust away.
We have no coffee machine.
We are dreaming about it
We still do not have it.
New all organic machine.
The toilet tank in the big bathroom stopped refilling. I contacted PPService@caltech.edu and put up an "Out of Order sign".
a plumber came in yesterday and fixed the issue.
The backup of /cvs/cds (which runs as a cron job on fb40m; see /cvs/cds/caltech/scripts/backup/000README.txt)
has been down since fb40m was rebooted on March 3.
I was unable to start it because of conflicting ssh keys in /home/controls/.ssh .
With help from Dan Kozak, we got it to work with both sets of keys
( id_rsa, which allows one to ssh between computers in our 113 network without typing a password,
and backup2PB which allows the cron job to push the backup files to the archive in Powell-Booth).
It still goes down every time one reboots fb40m, and I don't have a solution.
A simple solution is for the script to send an email whenever it can't connect via ssh keys
(requiring a restart of ssh-agent with a passphrase), but email doesn't seem to work on fb40m.
I'll see if I can get help on how to have sendmail run on fb40m.