When I came in, Rossa was booted to Ubuntu 10. I tried rebooting to select 12, but couldn't ever successfully boot again. Since Diego was setting up Allegra from scratch, I've wiped and done the same with Rossa.
I've done some preliminary modeling to see if there is a good candidate for an IR DARM control signal that is available before the AS55 sign flip. From a DC sweep point of view, ASDC/(TRX+TRY) may be a candidate for further exploration.
As a reminder, both Finesse and MIST predict a sign flip in the AS55 Q control signal for DARM in the PRFPMI configuration, at a CARM offset of around 118pm.
The CARM offset where this sign flip occurs isn't too far off of where we're currently losing lock, so we have not had the opportunity to switch DARM control off of ALS and over to the quieter IR RF signal of AS55.
Here are simulated DC DARM sweep plots of our current PRFPMI configuration, with a whole bunch of potential signals that struck me.
Although the units of most traces are arbitrary in each plot (to fit on the same scale), each plot uses the same arbitrary units (if that makes any sense) so slopes and ratios of values can be read off.
In the 300 and 120pm plot, you can see that the zero crossing of AS55 is at some considerable DARM offset, and normalizing by TRX doesn't change much about that. "Hold on a second," I hear you say. "Your first plots said that the sign flip happens at around 120pm, so why does the AS55 profile still look bad at 50pm?!" My guess is that, probably due to a combination of Schnupp and arm length asymmetry, CARM offsets move where the peak power is in the DARM coordinate. This picture makes what I mean more clear, perhaps:
Thus, once we're on the other side of the sign flip, I'm confident that we can use AS55 Q without much problem.
Now, back to thoughts about an interim signal:
ASDC by itself does not really have the kind of behavior we want; but the power out of AS as a fraction of the ARM power (i.e. ASDC/TRX in the plot) seems to have a rational shape, that is not too unlike what the REFLDC CARM profile looks like.
Why not use POPDC or REFLDC? Well, at the CARM offsets we're currently at, POPDC is dominated by the PRC resonating sidebands, and REFLDC has barely begun to decline, and at lower CARM offsets, they each flatten out before the peak of the little ASDC hill, and so don't do much to improve the shape. Meanwhile, ASDC/TRX has a smooth response to points within some fraction of the DARM line width in all of the plots.
Thus, as was discussed at today's meeting, I feel it may be possible to lock DARM on ASDC/(TRX+TRY) with some offset, until AS55 becomes feasible.
(In practice, I figure we would divide by the sum of the powers, to reduce the influence of the DARM component of just TRX; we don't want to have DARM/DARM in the error signal for DARM)
Two caveats are:
[Code and plots live in /svn/trunk/modeling/PRFPMI_radpressure]
I've been trying to figure out why daqd keeps crashing, but nothing is fixed yet.
I commented out the line in /etc/inittab that runs daqd automatically, so I could run it manually. Each time I run it ( with ./daqd -c ./daqdrc while in c1/target/fb), it churns along fine for a little while, but eventually spits out something like:
[Thu Oct 16 11:43:54 2014] main profiler warning: 1 empty blocks in the buffer
[Thu Oct 16 11:43:55 2014] main profiler warning: 0 empty blocks in the buffer
[Thu Oct 16 11:43:56 2014] main profiler warning: 0 empty blocks in the buffer
[Thu Oct 16 11:43:57 2014] main profiler warning: 0 empty blocks in the buffer
[Thu Oct 16 11:43:58 2014] main profiler warning: 0 empty blocks in the buffer
[Thu Oct 16 11:43:59 2014] main profiler warning: 0 empty blocks in the buffer
[Thu Oct 16 11:44:00 2014] main profiler warning: 0 empty blocks in the buffer
[Thu Oct 16 11:44:01 2014] main profiler warning: 0 empty blocks in the buffer
[Thu Oct 16 11:44:02 2014] main profiler warning: 0 empty blocks in the buffer
GPS time jumped from 1097520250 to 1097520257
FATAL: exception not rethrown
I looked for time disagreements between the FB and the frontends, but they all seem fine. Running ntpdate only corrected things by 5ms. However, looking through /var/log/messages on FB, I found that ntp claims to have corrected the FB's time by ~111600 seconds (~31 hours) when I rebooted it on Monday.
Maybe this has something to do with the timing that the FB is getting? The FE IOPs seem happy with their sync status, but I'm not personally currently aware of how the FB timing is set up.
On Monday, Jamie suggested checking out the situation with FB's RAID. Searching the elog for "empty blocks in the buffer" also brought up posts that mentioned problems with the RAID.
I went to the JetStor RAID web interface at http://192.168.113.119, and it reports everything as healthy; no major errors in the log. Looking at the SMART status of a few of the drives shows nothing out of the ordinary. The RAID is not mounted in read-only mode either, as was the problem mentioned in previous elogs.
I've added (TRX-TRY)/(TRX+TRY) to the DC DARM sweep plots, and it looks like an even better candidate. The slope is closer to linear, and it has a zero crossing within ~10pm of the true DARM zero across the different CARM offsets, so we might not even need to use an intentional DARM offset.
I've been able to repeatedly get off of ALS and onto (TRY-TRX)/(TRY+TRX). Nevertheless, lock is lost between arm powers of 10 and 20.
I do the transition at the same place as the CARM->SqrtInv transition, i.e. arm powers about 1.0 Jenne started a script for the transition, and I've modified it with settings that I found to work, and integrated it into the carm_cm_up script. I've also modified carm_cm_down to zero the DARM normalization elements.
I was thwarted repeatedly by the frequent crashing of daqd, so I was not able to take OLTFs of CARM or DARM, which would've been nice. As it was, I tuned the DARM gain by looking for gain peaking in the error signal spectrum. I also couldn't really get a good look at the lock loss events. Once the FB is behaving properly, we can learn more.
Turning over to difference in transmission as an error signal naturally squashes the difference in arm transmissions:
I was able to grab spectra of the error and control signals, though I did not take the time to calibrate them... We can see the high frequency sensing noise for the transmission derived signals fall as the arm power increases. The low frequency mirror motion stays about the same.
So, it seems that DARM was not the main culprit in breaking lock, but it is still gratifying to get off of ALS completely, given its out-of-loop-noise's strong dependence on PSL-alignment.
BUT, what we really need (instead of just the DC sweeps) is the DC sweep with the uncertainty/noise displayed as a shaded area on the plot, as Nic did for us in the pre-CESAR modelling.
I've taken a first stab at this. Through various means, I've made an estimation of the total noise RMS of each error signal, and plotted a shaded region that shows the range of values the error signal is likely to take, when the IFO is statically sitting at one CARM offset.
I have not included any effects that would change the RMS of these signals in a CARM-offset dependent way. Since this is just a rough first pass, I didn't want to get carried away just yet.
For the transmission PDs, I measured the RMS on single arm lock. I also measured the incident power on the QPDs and thorlabs PDs for an estimate of shot noise, but this was ridiculously smaller than the in-loop RIN. I had originally though of just plotting sensing noise for the traces (i.e. dark+shot), because the amount of seismic and frequency noise in the in-loop signal obviously depends on the loop, but this gives a very misleading, tiny value. In reality we have RIN from the PRC due to seismic noise, angular motion of the optics, etc., which I have not quantified at this time.
So: for this first, rough, pass, I am simply multiplying the single transmission noise RMSs by a factor of 10 for the coupled RMS. If nothing else, this makes the SqrtInv signal look plausible when we actually practically find it to be plausible.
For the REFL PDs, I misaligned the ITMs for a prompt PRM reflection for a worst-case shot noise situation, and took the RMS of the spectra. (Also wrote down the dark RMSs, which are about a factor of 2 lower). I then also multiplied these by ten, to be consistent with the transmission PDs. In reality, the shot noise component will go down as we approach zero CARM offset, but if other effects dominate, that won't matter.
Enough blathering, here's the plot:
Now, in addition to the region of linearity/validity of the different signals, we can hopefully see the amount of error relative to the desired CARM offset. (Or, at least, how that error qualitatively changes over the range of offsets)
This suggests that we MAY be able to hop over to a normalized RF signal; but this is a pretty big maybe. This signal has the response of the quotient of two nontrivial optical plants, which I have not yet given much thought to; it is probably the right time to do so...
After the second of the two recent power outages, the outlet powering Chiara's external drive for local backups didn't come back. The modification to the backup script I made correctly identified that the drive wasn't mounted, and happily logged its absence and didn't try to stuff the internal drive with a copy of itself. However, I hadn't checked the logs to see if the backups were proceeding until today... maybe I should set up an email alert for these, too.
I plugged the external drive into a live outlet, and mounted the 40mBackup drive with: sudo udisks --mount /dev/sdc1, which is a helpful command that puts the drive at /media/40mBackup as it should be, based on the drive label.
sudo udisks --mount /dev/sdc1
The /cvs/cds backup is now proceeding, to make up for lost time.
I spent some time trying to debug our inability to get MICH onto REFL165Q while the arms are held off with ALS, to no real success.
I set up our usual repeatable situation of PRMI on 33 I&Q, arms held off with ALS. I figured that it may help to first sideband lock on REFL55, since 165 is looking for the f2 sidebands and maybe there is some odd offset between the locking points for f1 and f2 or other weirdness.
REFL 55 settings:
Demod angle 98->126 (was previously set for PRY locking)
PRCL = 0.5 * REFL55 I (UGF of ~200 Hz) (FM gain unchanged from REFL33 situation of -0.02)
MICH = 0.125 * REFL55 Q (UGF of ~60Hz) (same FM gain as 33)
Some REFL55 offset adjusting had to be done in order to not disturb the 33-initiated lock when handing off.
I also adjusted POP110 phase to zero the Q when locked, and switched the triggering over to 110I
The PRMI can acquire lock like this with arms held off with ALS, no problem.
Here, I tried to hop over to 165. PRCL was no problem, needing a +1 on 165I. However, I had no success in handing off MICH. I twiddled many knobs, but none that provably helped.
I saw indications that the sensing angle in 165 is small (~20deg), which is not consistent with current knowledge of the cavity lengths. We last interferometrically measured the PRC length by letting the PRMI swing and looking at sideband splitting in POP110. At LLO, they did a length measurement by looking at demod angle differences in PRMI carrier vs. sideband locking. (alog8562) This might be worth checking out...
I took some spectra of the error signals and MC2 Trans RIN with the loops off (blue) and on (red) during the current conditions of daytime seismic noise.
Short report: Further frustrated by 165 tonight. The weird thing is, the procedure I'm trying with the arms held off on ALS (i.e. excitation line in MICH and PRCL, adjust relative gains to make the signs and magnitudes mach, ezcastep over) works flawlessly with the ETMs misaligned. One can even acquire SB PRMI lock on 165 I&Q, with 80-90 degrees of demod angle between MICH and PRCL. The only real difference in REFL55 settings for misaligned vs. ALS-offset arms is an extra factor of two in the FM gains to maintain the same UGF, so I hoped that the matrix elements for 165 with misaligned arms would hold for ALS-offset arms.
Alas, no such fortune. I still have no clear explanation for why we can't get MICH on 165Q with the arms held off on ALS.
I also gave a quick try to measuring the PRCL->REFL55 demod phase difference between carrier and sideband lock (with arms misaligned), and got something on the order of 55 degrees, which really just makes me think I wasn't well set up / aligned, rather than actually conveying information about the PRC length...
I just installed cdsutils r351 at /ligo/apps/linux-x86_64/cdsutils. It should be available on all workstations.
It includes a bunch of bug fixes and feature improvements, including the step stuff that Rana was complaining about.
Cdsutils r361 installed, for the "avg" updates. aLOG
Earlier today, I did some simulations that suggested that PRC lengths on the order of a cm from our current estimated one could result in degenerate PRCL and MICH signals in REFL165 at 3nm CARM offset. I attempted more demod-angle derived cavity PRC length measurements with REFL11 and REFL55, but they weren't consistent with each other...
In any case, adding dual recycling, even with a SRC length off by 1cm in either direction, doesn't seem to exhibit the same possibility, so I spent some time tonight seeing if I could make any progress towards DRMI locking.
I was able to lock SRY using AS55 in a very similar manner to PRY, after adjusting the AS55 demod angle to get the error signal entirely in I. I used this configuration to align the SRM to the previously aligned BS and ITMY. Oddly, I was not able to do anything with SRX as I had hoped; the error signal looks very strange, looking more like abs(error signal).
I then was able to lock the SRMI on AS55 I & Q, the settings have been saved in the IFO configure screen. I've used AS55Q for PRMI locking with a gain of -0.2, so I started with that; the final gain ended up being -0.6. PRMI/PRY gain for prcl is something like 0.01, so since I used a gain of 2 for locking SRX, I started the SRCL gain around 0.02, the final gain ended up being -0.03. I basically just guessed a sign for AS110 triggering. Once I lucked upon a rough lock, I excited the PRM to tune the AS55 angle a few degrees; it was luckily quite close already from the SRY adjustment. AS110 needed a bigger adjustment to get the power into I. (AS55: -40.25->-82.25, AS110: 145->58, but I put AS55 back for PRMI)
I briefly tried locking the DRMI, but I was really just shooting in the dark. I went back and measured various sensing amplitudes/angles in SRMI and PRMI configurations; I'm hoping that I may be able to simulate the right gains/angles for eventual DRMI locking.
Something to note, as we have the IMC angular controls under consideration:
Jenne has the DRMI locked right now. I took a look at the coherence between the POP QPD and MC2 transmission QPDs. (Since she's using ASC, I also included those control signals. The coherences are about the same, unsurprisingly)
Based on the observed coherences, from about 1 to 6Hz, IMC motion is responsible for a fair amount of the DRMI angular motion. Also, PIT and YAW couple differently.
I've fallen down the rabbit hole of trying to reconcile our desire for newer versions of the Numpy and Scipy python packages with the use of our handy cdsutils tools.
I've set up an installation of Anaconda python in /ligo/apps/anaconda. Installing pyepics, nds2, and cdsutils was straightforward, but there were a myriad of odd python packages that cdsutils depends on, that are typically installed at the OS level (python-gst, gobject, glib) which I just manually copied over to the anaconda directories. Also, the version of readline that anaconda ships with is somewhat borked (dark voodoo fix was found here: github link. The issue mentioned there wasn't why I needed the fix. Somehow libreadline was causing pyepics initialization to fail).
I was initially hoping this kind of exercise would be useful, as having a separate python environment that we control buffers us from the system installation and allows us to use whatever version of packages we want, but the amount of hackery I did to get to get cdsutils to work probably didn't result in the most robust solution. (Maybe there was a better way!)
In any case, I have not changed any of our machines' default paths or environment variables. Instead, I have simply created an alias that points to Anaconda python: "apython"
import scipy as sp
from ezca import Ezca
print 'Python Version: '+ sys.version
print 'ez.read test:' + str(ez.read('LSC-TRY_OUT16'))
print 'Scipy Version: '+sp.__version__
Python Version: 2.7.3 (default, Feb 27 2014, 19:58:35)
Scipy Version: 0.9.0
Python Version: 2.7.8 |Continuum Analytics, Inc.| (default, Aug 21 2014, 18:22:21)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)]
Scipy Version: 0.14.0
Thus, Diego should now be able to complete his script that needs the newer Scipy, as well as CDSutils.
Final note: I've tested z (read|write|avg) with $PATH modified to have /ligo/apps/anaconda/bin at the start, and they seem to work. If things seem to hold up, maybe we can replace the default command-line python, but its not strictly necessary.
Given the checkout of the aLIGO BBPDs happening (aLOG link), wherein the PDs were acting funny, and Koji has made some measurements determining that intermodulation/nonlinearity of circuitry can corrupt 3F signals, I've made a similar measurement of the RF spectra of REFL165 when we're locked on DRMI using 1F signals. Maybe this could give us insight to our bad luck using REFL165...
In essence, I plugged the RF output of the PD into an AG4395, through a 10dB attenuator and downloaded the spectrum. I also did REFL33 as a possible comparison and because why not. The attached plots have the 10dB accounted for; the text files do not.
REFL165 (Exposed PCB BBPD):
(What is all that crap between 8 and 9 fmod?)
REFL33 (Gold Box resonant RFPD):
Green beatnotes recovered.
It was just a matter of aligning the arm greens and PSL greens on the PSL table. I suppose something knocked the PSL alignment out of whack... I was also able to simultaneously see the green beatnote and IR beatnote respond to Yend laser temperature.
Locked arms on POX/POY, checked RMS of ALS-BEAT[X/Y]_FINE_PHASE_OUT_HZ channels.
These seem fine. Locked CARM and DARM on ALS, found IR resonances.
ALS is back in business
Now that I have followed the chain, the PD signal is indeed being amplified at the LSC rack. It goes into a ZFL-1000LN+ amplifier (~23dB gain at 165MHz and 15V supply), followed by a SHP-100 high pass filter, and then enters the RF IN of the demod board.
I repeated the measurement in two spots.
First, I took a spectrum of the RF MON of the REFL165 demod board during DRMI lock; this was input-referred by adding 20dBm.
Second, I inserted a ZFDC-10-5 coupler between the high pass and the RF input of the demod board. This was input-referred by adding 10dBm.
My calibration isn't perfect; the peaks above the high pass corner seem to be different by a consistent amount, but within a few dBm.
Thus, it looks like the demod board is getting a little under -40dBm of 165MHz signal at its input.
Where is the PD out spectrum measured with the coupler???
The "coupled" port of the coupler went to the AG4395 input, the output of the Highpass is connected to the "IN", and the "OUT" goes to the demod board.
After some enlightening conversation with Koji, we figured that the RF amplifier in the REFL165 chain is probably being saturated (the amp's 1dB compression is at +3dBm, has 23dB gain, and there are multiple lines above -20dBm coming out of the PD). I took a few more spectrum measurements to quantify the consequences, as well as a test with the highpass connected directly to the PD output, that should reduce the power into the amplifier. However, I am leaving everything hooked back up in its original state (and have removed all couplers and analyzers...)
I also took some DRMI sensing measurements. In the simple Michelson configuration, I took TFs of each ITMs motion to AS55Q to make sure the drives were well balanced. They were. Then, in the DRMI, I took swept sine TFs of PRCL, SRCL and differential ITM MICH motion to the Is and Qs of AS55 and all of the REFLs. I constrained the sweeps to 300Hz->2kHz; the loops have some amount of coupling so I wanted to stay out of their bandwidth. I also took a TF of the pure BS motion and BS-PRM MICH to the PDs. From these and future measurements, I hope to pursue better estimates of the sensing matrix elements of the DRMI DoFs, and perhaps the coefficients for compensating both SRCL and PRCL out of BS motion.
I'm leaving analysis and interpretation for the daytime, and handing the IFO back to Diego...
After some enlightening conversation with Koji, we figured that the RF amplifier in the REFL165 chain is probably being saturated.
The measurements I took yesterday bear this out. However, even putting the high-pass directly on the PD output doesn't reduce the signal enough to avoid saturating the amplifier.
We need to think of the right way to get the 165MHz signal at large enough, but undistorted, amplitude to the demod board.
The current signal chain looks like:
AS Table LSC RACK
[ PD ]----------------------------------->[ AMP ]------>[ 100MHzHPF ]----->[ DEMOD ]
(1) (2) (3)
I previously made measurements at (3). Let's ignore that.
Last night, I took measurements with a directional coupler at points (1) and (2), to see the signal levels before and after the amplifier. I divided the spectrum at (2) by the nominal gain of the amplifier, 23.5dB; thus if everything was linear, the spectra would be very similar. This is not the case, and it is evident why. There are multiple signals stronger than -20dBm, and the amplifier has a 1dB compression point of +3dBm, so any one of these lines at 4x, 6x and 10x fMod is enough to saturate.
I also made a measurement at point 4 in the following arrangement, in an attempt to reduce the signal amplitude incident on the amplifier.
[ PD ]->[ 100MHzHPF ]----------------------------------->[ AMP ]--------->[ DEMOD ]
Though the signals below 100MHz are attenuated as expected, the signal at 110MHz is still too large for the amplifier.
Minicircuits' SHP-150 only has 13dB suppression at 110MHz, which would not be enough either. SHP-175 has 31dB suppression at 110MHz and 0.82dB at 160MHz, maybe this is what we want.
Here are some preliminary results from the sensing sweeps I did the other night.
xml files, and DttData matlab script used to generate these plots is attached.
Jenne and I measured the situation using a SHP-150 directly attached to the REFL165 RF output, and at first glance, the magnitude of the 165MHz signal seems to not be distorted by the amplifier.
We will soon investigate whether 165 signal quality has indeed improved.
ARG, I accidentally permuted the digital demod angles. This significantly weakens the argument for believing AS55I is broken... In fact, Jenne and I did some investigations this afternoon that showed that the channel is indeed working. SRX error signal strangeness remains unexplained, however.
Also, I have yet to compensate for the gain of the violin filters; the actuator calibration numbers I used were for the SUS-LSC FMs, not the LSC FMs where I was injecting. New measurements will be taken soon, as well, since REFL165 is hopefully improved.
Corrected plots are below.
Q >> Please measure the RF spectrum again with the notch.
The notch filter has been installed directly attached to the output of the SHP-150 at the PD output. Structurally, there is a right angle SMA elbow between the two filters; I set up a post holder under the notch pomona box to prevent torque on the PD. Via directional coupler and AG4395, we measured the output of the REFL165 RF amplifier with the PRMI locked on REFL33.
Note, the plot below is not referred to the amplifier output, as in my previous plots; it is directly representative of the amplifier output spectrum.
There are no RF signals being output above -28dBm, thus I am confident that we are not subject to compression distortion.
Given the last measurements we made (ELOG 10692), I estimate that the notch has reduced the power at 110MHz by ~33dB, which is 9dB higher than the notch performance Koji measured when he made it. Maybe this could be due to the non-50Ohm impedance of the HPF distorting the tuning, or I physically detuned it when mounting it on the PD. Still, 33dB is pretty good, and may even give us room to amplify further. (ZRL-700+ instead of the ZFL-1000LN+?)
I did some simulations to see if we are susceptible to HOM resonances as we reduce the CARM offset. I restricted my search to HG modes of the Carrier+[-55,-11,0,+11,+55]MHz fields with n+m<6, and used all the real physical parameters I could get ahold of.
In short, as I change the CARM offset, I don't see any stray resonances within 2nm of zero, either in PRFPMI or DRFPMI.
Now, the mode matching in my simulation is not the real mode matching our real interferometer has. Thus, it can't tell us how much power we may see in a given mode, but it can tell us about our susceptibility to different modes. I.e. if we were to have some power in a certain mode coming out of the IMC, or present in the vertex, we can see what it would do in the arms.
Since my simulation has some random amounts of power in each HOM coming into the interferometer, I simply swept the CARM offset and looked for peaks in the power of each mode. Many of the fields exhibited gentle slopes over the range, and we know we ok from 3nm->~100pm, so I made the selection rule that a "peak" must be at least 10 times as big as the minimum value over the whole range, in order to see fields that really do have CARM dependence.
In the following plots, normalized IFO power is plotted and the locations of HOM peaks are indicated with circles; their actual heights are arbitrary, since I don't know our real mode content. However, I'm not really too concerned, since all I see is some -11MHz modes between 2-3nm of full resonance, where we have no problem controlling things... Also, all of the carrier HOMs effectively co-resonate with the 00 mode, which isn't too surprising, and I didn't include these modes in the plots.
Finally, I visually inspected the traces for all of the modes, and didn't really find anything else peeking out.
Code, plots attached.
So, with my last entry, I was guilty of just throwing stuff into the simulation and not thinking about physics... so I retreated to Siegman for some algebraic calculations of the additional Guoy phase accumulated by the HOMs in the arms -> their resonant frequencies -> the arm length offset where they should resonate. Really, this isn't completely precise, as I treated the arms independently, with slightly differing ETM radii of curvature, but I would expect the "CARM Arm" to behave as a sort of average of the two arm cavities in this regard. (EDIT: Also, I didn't really consider the effect of the coupled vertex cavities... so there's more to be done)
The basic idea I used was:
In practice, I threw together a python script to do this all and print out a table. I've highlighted the values within 10nm, but the closet one is 3.8nm
########## X Arm HOM Resonance Locations in nm ##########
Mode Order: 0 , 1 , 2 , 3 , 4 , 5
Carrier : +0, +156.21, -219.58, -63.376, +92.832, +249.04
LSB 11 : +59.563, +215.77, -160.02, -3.8126, +152.4, -223.4
USB 11 : -59.563, +96.645, +252.85, -122.94, +33.269, +189.48
LSB 55 : -234.18, -77.975, +78.233, +234.44, -141.35, +14.857
USB 55 : +234.18, -141.61, +14.6, +170.81, -204.98, -48.776
########## Y Arm HOM Resonance Locations in nm ##########
Carrier : +0, +154.82, -222.35, -67.531, +87.292, +242.11
LSB 11 : +59.313, +214.14, -163.04, -8.218, +146.6, -230.57
USB 11 : -59.313, +95.51, +250.33, -126.84, +27.978, +182.8
LSB 55 : -235.43, -80.611, +74.212, +229.04, -148.14,
USB 55 : +235.43, -141.74, +13.08, +167.9, -209.27, -54.452
I've extended my analysis to the PRFPMI case, with the current working knowledge of radii of curvature and cavity lengths. However, losses were not included.
I do not see any HOM activity within about 20nm of the carrier TM00 resonance.
Basically, what I did was use the standard formulae for the reflection and transmission coefficients of FB cavities viewed as compound mirrors. However, I modified the normal spatial propagation terms to include the additional Guoy phase accumulated by the HOMs. I created these coefficients for each arm individually, and then used (rX + rY)/2 as a mirror in the PRC, and used that to create the transmission coefficient for the PRFPMI as a whole, as a function of frequency offset from the carrier, spatial mode order and CARM offset. As a check, this produced the correct finesse for the carrier lock to the single arm and PRFPMI.
Here is a PRFPMI CARM FSR of all of the fields' power transmission coefficients, up to order n+m=5.
One can observe some split peaks. There are two causes, the biggest effect is the mismatch between ETM radii of curvatures (ETMX:59.48, ETMY:60.26):, followed by asymmetric arm length(X:37.79, Y:37.81). (I judged this by the visual change of the plot when changing different factors).
In the following plot, I broke down the peaks by mode order:
Code, plots attached!
I took a quick look at single arm RIN. Actuating on MC2 vs. the ETM, or using AS55 instead of POY11 made no noticeable difference in the arm cavity RIN. Not too surprising, but there it is.
Similar to what Jenne did the other night, I kept the PRFPMI arm DoFs locked on ALS, in hopes to check out the RF error signals.
I was able to stably sit at nominally zero offset in both CARM and DARM, tens of minutes at a time, and the PRMI could reacquire without a fuss. Arm powers would rest between 10 and 20, intermittently exhibiting the "buzzing" behavior that Jenne mentioned when passing through resonance. 100pm CARM offset means arm powers of around 10, so since our ALS RMS is on this order, this seems ok. I saw TRX get as high as 212 counts, which is just about the same that I've simulated as the maximum power in our IFO.
To get this stable, I turned off all boosts on MICH and PRCL except PRCL FM6, and added matrix elements of 0.25 for TRX and TRY in the trigger line for the PRMI DoFs. The logic for this is that if the arm powers are higher than 1, power recycling is happening, so we want to keep things above the trigger down value of 0.5, even if POP22 momentarily drops.
I also played around a bit with DARM offsets. We know from experience that the ALS IR resonance finding is not super precise, and thus zero in the CARM FM is not zero CARM offset when on ALS. The same obviously holds for DARM, so I moved the DARM offset around, and could see the relative strengths of flashes change between the arms as expected.
I've written down some GPS times that I'm going to go back and look at, to try to back out some information about our error signals.
Lastly, there may be something undesirable happening with the TRX QPD; during some buzzing, the signal would fluctuate into negative values and did not resemble the TRY signal as it nominally would. Perhaps the whitening filters are acting up...
Steve had me measure the RIN of a JDSU HeNe laser. I used a PDA520, and measured the RIN after the laser had been running for about an hour, which let the laser "settle" (I saw the low frequency RIN fall after this period).
Here's the plot and zipped data.
Steve: brand new laser with JDSU 1201 PS
At Rana's request, I've made an in-situ measurement of the RIN of all of our OpLevs. PSL shutter closed, 10mHz BW. The OpLevs are not neccesarily centered, but the counts on darkest quadrant on each QPD is not more than a factor of a few lower than the brightest quadrant; i.e. I'm confident that the beam is not falling off.
I have not attached that raw data, as it is ~90MB. Instead, the DTT template can be found in /users/Templates/OL/ALL-SUM_141125.xml
Here are the mean and std of the channels as reported by z avg 30 -s, (in parenthesis, I've added the std/mean to estimate the RMS RIN)
z avg 30 -s,
SUS-BS_OLSUM_IN1 1957.02440999 1.09957708641 (5.62e-4)
SUS-ETMX_OLSUM_IN1 16226.5940104 2.25084766713 (1.39e-4)
SUS-ETMY_OLSUM_IN1 6755.87203776 8.07100449176 (1.19e-3)
SUS-ITMX_OLSUM_IN1 6920.07502441 1.4903816992 (2.15e-4)
SUS-ITMY_OLSUM_IN1 13680.9810547 4.71903560692 (3.45e-4)
SUS-PRM_OLSUM_IN1 2333.40523682 1.28749988092 (5.52e-4)
SUS-SRM_OLSUM_IN1 26436.5919596 4.26549117459 (1.61e-4)
Dividing each spectrum from DTT by these mean values gives me this plot:
ETMY is the worst offender here...
I've uploaded a note at T1400735 about a new implementation of CESAR ESCOBAR ideas I've been working on. Please send me any and all feedback, comments, criticisms!
Using the things I talk about in there, I was able to have a time domain simulation of a 40m arm cavity transition through three error signals, without hardcoding the gains, offsets, or thresholds for using the signals. Some results look like this:
I'm going to be trying this out on the real IFO soon...
After some housekeeping (ASS is wonky, alignment of X green beat was bad, tuning of demod angles, fm gains for REFL165), we were able to bring the PRFPMI up to arm powers of 8 very stably.
We were keeping an eye on the DARM OLG, to make sure the gain was correct. We then saw a bump around 120Hz. Here is the bump.
Changing CARM offset changes its amplitude. Maybe it's a DARM optical spring. It didn't occur to me until after we lost lock that we could have tweaked the DARM offset to move it around if this was the case.
Unfortunately, due to some unexplained locklosses, we weren't able to get back into a state to measure this more... which is annoying. During that stable lock, Jenne stated that PRCL and DARM noises were looking particularly good.
We may want to tweak the way we handle the transmission PD handoff; maybe we want to force the switch at a certain place in the carm_up script, so that we're not flipping back and forth during an IR handoff; I think this may have been responsible for a lock loss or two.
With some advice from Jamie, I've gotten the lock loss plotting script that is used at LHO working on our machines. The other night, I modified the ALSwatch.py script to log lockloss times. Tying it together, I've written a small wrapper script that grabs the last time from the lockloss log, and plots it.
It is: scripts/LSC/LocklossData/lastlock.sh
Jamie's going to make an adjustment to the pydv codebase that will let me implement the auto y-scaling that we like. We also will need to get a feel for the right timing window, once we see what kind of delay in the ALSwatch script is typical.
Here's an example of the output, with the window of [-10,+2] seconds from the logged GPS time:
The other day, I hooked up the agilent analyzer to OUT2 of the MC board, which is currently set to output the MC refl error signal. I've written a GPIB-based program that continuously polls the analyzer, and plots the live spectrum, an exponentially weighted running mean, and the first measured spectrum.
The intended use case is to see if the FSS or MC loops are going crazy when we're locking. Sometimes the GPIB interface hangs/loses its connection, and the script needs a restart.
The script lives in scripts/MC/MCerrmon
- It was not sure how the whitening gains have been given.
- The corresponding database entry was found in /cvs/cds/caltech/target/c1auxey/ETMYaux.db as
- The gains for S2-S4 were set to be 30. However, C1:ASC-QPDY_S1WhiteGain was set to be 8.62068.
And it was not writable.
- After some investigation, it was found that the database was wrong. The DAC channel was changed from S100 to S0.
The corrected entry is shown here.
field(DESC,"Whitening gain for QPDY Seg 1")
field(OUT,"#C0 S0 @")
- Once c1auxey was rebooted, the S1 whitening gain became writable. Now all of the channels were set to be +30dB (max).
This exact situation was happening at ETMX. I did the exact same change to the database, now I can read and write all four gain segments.
Yesterday, we were seeing anomalously high low frequency RIN in the y-arm (rms of 4% or so). I swung by the lab briefly to check this out. Turns out, despite TRY of 1.0, there was reasonable misalignment. ASS with the excitation lowered by a factor of two, and overall gain at 0.5 or so aligned things to TRY=1.2, and the RIN is back down to ~0.5% I reset the Thorlabs FM to make the power = 1.0
I then went to center the transmitted beam on the transmon QPD. Looking at the quadrant counts as I moved the beam around, things looked odd, and I poked around a little...
I strongly suspect that we have significantly mismatched gains for the different quadrants on the ETMY QPD.
Reasoning: With the y-arm POY locked, I used a lens to focus down the TRY beam, to illuminate the quadrants individually. Quadrants 2 and 3 would go up to 3 counts, while 1 and 4 would go up to 0.3 and 0.6, respectively. (These counts are in some arbitrary units that were set by setting the sum to 1.0 when pitch and yaw claimed to be centered, but mismatched gains makes that meaningless.)
I haven't looked more deeply into where the mismatch is occurring. The four individual whitening gain sliders did affect the signals, so the sliders don't seem sticky, however I didn't check the actual change in gains. Will the latest round of whitening board modifications help this?
Hopefully, once this is resolved, the DC transmission signals will be much more reliable when locking...
Nodus (solaris) is dead, long live Nodus (ubuntu).
Diego and I are smoothing out the Kinks as they appear, but the ELOG is running smoothly on our new machine.
SVN is working, but your checkouts may complain because they expect https, and we haven't turned SSL on yet...
However, the PRMI would not acquire lock with the arms held off resonance.
This is entirely my fault.
Last week, while doing some stuff with PRY, I put this filter in SUS_PRM_LSC, to stop some saturations from high frequency sensing noise
After the discussion at today's meeting, it struck me that I might have left it on. Turns out I did.
20 degree phase lag at 200Hz can explain the instability, some non-flat shape at few hundreds of Hz explains the non 1/f shape.
Sorry about all that...
I have completed all of the model modifications and medm screen updates to allow for feedback from the transmon QPD pitch and yaw signals to the ITMs. Now, we can design and test actual loops...
The signals come from c1sc[x/y] to c1rfm via RFM, and then go to c1ass via dolphin.
Out of curiosity about the RFM+dolphin delay, I took a TF of an excitation at the end SUS model (C1:SUS-ETM[X/Y]_QPD_[PIT/YAW]_EXC) to the input FM in the ASC model (C1:ASC-ETM[X/Y]_QPD_[PIT/YAW]_IN1). All four signals exhibit the same delay of 122usec. I saved the dtt file in Templates/ASC/transmonQPDdelay.xml
This is less than a degree under 20Hz, so we don't have to worry about it.
Some locking efforts tonight; many locklosses due to PRC angular motion. Furthest progress was arm powers of 15, and I've stared at the corresponding lockloss plot, with little insight into what went wrong. (BTW, lastlock.sh seems to catch the lock loss reliably in the window)
CARM and DARM loops were measured not long before this lock loss, and had nominal UGFs (~120Hz, ~20deg PM). However, there was a reasonably clear 01 mode shape at the AS camera, which I did nothing to correct. Here's a spectrum from *just* before the lockloss, recovered via nds. Nothing stands out to me, other than a possible loss of DARM optical gain. (I believe the references are the error signal spectra taken in ALS arms held away + PRMI on 3F configuration)
The shape in the DARM OLTF that we had previously observed and hypothesized as possible DARM optical spring was not ever observed tonight. I didn't induce a DARM offset to try and look for it either, though.
Looking into some of the times when I was measuring OLTFs, the AS55 signals do show coherence with the live DARM error signal at the excitation frequencies, but little to no coherence under 30Hz, which probably means we weren't close enough to swap DARM error signals yet. This arm power regime is where the AS55 sign flip has been modeled to be...
A fair amount of time was spent in pre-locking prep, including:
Since the Nodus switch, the offsite backup scripts (scripts/backup/rsync.backup) had not been running successfully. I tracked it down to the weird NFS file ownership issues we've been seeing since making Chiara the fileserver. Since the backup script uses rsync's "archive" mode, which preserves ownership, permissions, modification dates, etc, not seeing the proper ownership made everything wacky.
Despite 99% of the searches you do about this problem saying you just need to match your user's uid and gid on the NFS client and server, it turns out NFSv4 doesn't use this mechanism at all, opting instead for some ID mapping service (idmapd), which I have no inclination of figuring out at this time.
Thus, I've configured /etc/fstab on Nodus (and the control room machines) to use NFSv3 when mounting /cvs/cds. Now, all the file ownerships show up correctly, and the offsite backup of /cvs/cds is churning along happily.
I just stumbled upon this while poking around:
Since the great crash of June 2014, the scripts backup script has not been workingon op340m. For some reason, it's only grabbing the PRFPMI folder, and nothing else.
Megatron seems to be able to run it. I've moved the job to megatron's crontab for now.
I've set up nodus to start the ELOG on boot, through /etc/init/elog.conf. Also, thanks to this, we don't need to use the start-elog.csh script any more. We can now just do:
controls@nodus:~ $ sudo initctl restart elog
I also tweaked some of the ELOG settings, so that image thumbnails are produced at higher resolution and quality.
Given that op340m showed some undesired behavior, and that the FSS slow seems prone to railing lately, I've moved the FSS slow servo job over to megatron in the same way I did for the MC autolocker.
Namely, there is an upstart configuration (megatron:/etc/init/FSSslow.conf), that invokes the slow servo. Log file is in the same old place (/cvs/cds/caltech/logs/scripts), and the servo can be (re)started by running:
controls@megatron|~ > sudo initctl start FSSslow
Maybe this won't really change the behavior. We'll see
I ssh'd in, and was able to run each script manually successfully. I ran the initctl commands, and they started up fine too.
We've seen this kind of behavior before, generally after reboots; see ELOGS 10247 and 10572.
In order to fix ELOG search, I have started running ELOG v2.9.2 on Nodus.
Sadly, due to changes in the software, we can no longer use one global write password. Instead, we must now operate with registered users.
Based on recent elog users, I'll be creating user accounts with the following names, using the same old ELOG write password. (These will be valid across all logbooks)
All of these users will be "Admins" as well, meaning they can add new users and change settings, using the "Config" link.
Let me know if I neglected to add someone, and sorry for the inconvenience.
RXA: What Eric means to say, is that "upgrading" from Solaris to Linux broke the search and made us get a new elog software that;s worse than what we had.
Steve and I switched chiara over to the UPS we bought for it, after ensuring the vacuum system was in a safe state. Everything went without a hitch.
Also, Diego and I have been working on getting some of the new computers up and running. Zita (the striptool projecting machine) has been replaced. One think pad laptop is missing an HD and battery, but the other one is fine. Diego has been working on a dell laptop, too. I was having problems editing the MAC address rules on the martian wifi router, but the working thinkpad's MAC was already listed.
Turns out that, as the martian wifi router is quite old, it doesn't like Chrome; using Firefox worked like a charm and now also giada (the Dell laptop) is on 40MARS.
So, despite having registered users, it turns out that the "Author" field is still open for editing when making posts. I.e. we don't really need to make new accounts for everyone.
Thus, I've made a user named "elog" with the old write password that can write to all ELOGs.
(Also, I've added a user called "jamie")