I have modified the DARM model from elog 11133, to include the fact that these are digital filters.
I have also extracted the data from elog 11143, and it together with the model.
The modeled loop has an arbitrary gain factor, to make it have the same 234Hz UGF as the measured data.
The modeled loop includes:
There is a 1.5 degree phase discrepancy at 100Hz, and an 11 degree phase discrepancy at 900Hz, but other than that, the modeled and measured loops match pretty well.
For the measured frequencies, here are the residuals:
I've done a few things to start waking up the IFO after it's week of conference-vacation.
PMC trans was at 0.679, aligned the input to the PMC, now it's up at 0.786.
MC transmission was very low, mostly from low PMC transmission. Anyhow, MC locked, WFS relieved so that it will re-acquire faster.
Many of the optics had drifted away. AS port had no fringing, and almost every optic was far away from it's driftmon set val. While putting the optics back to their driftmon spots, I noticed that some of the cds.servos had incorrect gain. Previously, I had just been using the ETMX servo, which had the correct gain, but the ITMs needed smaller gain, and some of the optics needed the gain to be negative rather than positive. So, now the script ..../scripts/SUS/DRIFT_MON/MoveOpticToMatchDriftMon.py has individually defined gains for the cds.servo.
Next up (after lunch) will be locking an aligning the arms. I still don't have MICH fringing at the AS port, so I suspect that the ASS will move some of the optics somewhat significantly (perhaps the input tip tilts, which I don't have DRIFT_MON for?)
If the optics moved such amount, could you check the PD alignment once the optics are aligned?
X arm ASS is having some issues. ITMX oplev was recentered with ITMX in a good hand-aligned state.
The martian wifi network wasn't showing up, so I power cycled the wifi router. Seems to be fine now.
In addition to (and probably related to) the XARM ASS not working today, the ITMX has been jumping around kind of like ETMX sometimes does. It's very disconcerting.
Earlier today, Q and I tried turning off both the LSC and the oplev damping (leaving the local OSEM damping on), and ITMX still jumped, far enough that it fell off the oplev PD.
I'm not sure what is wrong with ITMX, but probably ASS won't work well until we figure out what's up.
I tried a few lock stretches (after realigning the Xgreen on the PSL table) after hand-aligning the Xarm, but the overall alignment just isn't good enough. Usually POPDC gets to 400 or 450 while the arms are held off resonance, but today (after tweaking BS and PRM alignment), the best I can get POPDC is about 300 counts.
Den and I are looking at the ASS and ITMX now.
The problem with the ASS turned out to be a mode that was rung up at 1326Hz in ETMX. It was rung up when the Xarm's overall gain was too high. So, by turning down the digital gain we were able to prevent it ringing up, and then the ASS worked. To circumvent this, we added a notch to the violin filter bank. It turned out that, upon trying to check if this existed also for the Yarm by turning up the digital gain, the ETMY frequency was almost identical. So, the same single notch is in both ETMs, and it covers the modes for both ETMs.
After that, we got back to locking. We have made at least 9 transitions to all-RF (both CARM and DARM) tonight (I have lost track of how many Den has done while I've been writing this - maybe we're up to 10 or so.). We have changed the order of things a little bit, but they're mostly similar to last week. There are some new notches in the CARM_B filter bank, as well as a 700Hz low pass. We have not been using the lead filter in DARM from last week. Script is checked in, and also zipped and attached. At first CARM was actuating on ETMs, but the last half of the locks we've been using MC2. The script is optimized for MC2 actuation.
While locked all RF, we phased REFL55 in preparation for transitioning PRMI over from REFL165. REFL55 phase was +125, now is +80, give or take 5 deg. We have tried measuring the relative gain and sign between REFL55 and REFL165, but we keep losing lock, perhaps as a result of the TFs Den is taking. He's being gentle though.
Measure CARM loop (why was SRmeasure not working?? is it plugged in??)
Turn on AO boosts, etc.
So, was there real shifting in the ITMX alignment as seen in the DV trend or just mis-diagnosis from the ETMX violin mode? Or how would the ETMX violin mode drive the ITMX with the LSC feedback disabled?
We run out of N2 for the vacuum system. The pressure peaked at 1.3 mTorr with MC locked. V1 did not closed because the N2 pressure sensor failed.
We are back to vac normal. I will be here tomorrow to check on things.
We run out of N2 for the vacuum system 6 hrs ago. The pressure rose to 1.2 mTorr with V1 closed. The interlock worked! See Nirogen presure reading fixed at http://nodus.ligo.caltech.edu:8080/40m/10968
The vacuum interlock: Nitrogen pressure transducer is reading the pneumatic pressure continously at the pump spool and c1vac1 processing it. When it drops below 60 PSI it closes V1 gate valve and V4 & V5. Gate valve V1 needs minimum 60 PSI to close. It is critical that V1 is closed before you run out of Nitrogen so the IFO pressure is contained.
IFO vacuum is back to Vac Normal. The MC is locked.
cc4 = 2E-6 Torr with VM1 open.
Daily N2 consumption measured to be 530PSI as 3 days on 3-27-2015 but note: it does vary !
I have seen it as high as 900 psi The long term average ~750 psi
Based on Jenne's chiara disk usage monitoring script, I made a script that checks the N2 pressure, which will send an email to myself, Jenne, Rana, Koji, and Steve, should the pressure fall below 60psi. I also updated the chiara disk checking script to work on the new Nodus setup. I tested the two, only emailing myself, and they appear to work as expected.
The scripts are committed to the svn. Nodus' crontab now includes these two scripts, as well as the crontab backup script. (It occurs to me that the crontab backup script could be a little smarter, only backing it up if a change is made, but the archive is only a few MB, so it's probably not so important...)
I've been poking around the oplev situation. One thing I came across regarding ITMX was that the gain on segment 4 seems to be about higher than the other segments. I was led to believe this by steering the optic around, and looking at the counts on each quadrant when the other 3 were dark.
Putting a gain of 0.86 (the ratio of the other segments' max counts over segment 4's max counts) in the segment 4 FM flattens the 1 Hz peak in the ITMX_OL_SUM spectrum, as well as significantly reducing the sub-Hz coherence of the sum with the individual quandrant counts. This is what I would expect from reducing the coupling of angular motion due to quadrant gain mismatch into the sum.
Here are the ITMX_OL_SUM spectra before and after (oplev servos are off).
The "burps" and control filter saturations are still unexplained. Investigations continue...
The rsync job to sync our frames over to the cluster has been on a 20 MB/s BW limit for awhile now.
Dan Kozak has now set up a cronjob to do this at 10 min after the hour, every hour. Let's see how this goes.
You can find the script and its logfile name by doing 'crontab -l' on nodus.
Back when Diego and I were getting all of the web services running up on the new nodus, we inexplicably were not able to get the hosting of the public_html directory and wikis to share the same port of 30889. In ELOG 10793, we stated that public_html was hosted on a new port, 30888, though we didn't really bring much attention to that new fact.
Unbeknowst to us at the time, this broke other links/bookmarks/sites that people had been using. Koji pointed this out to me the other day, but I have not made any sort of resolution. For now, the public_html directory, and the sites therein, have been taken offline.
In other nodus news, Jamie has set Nodus' apache service with a certificate for SSL goodness. We want to extend this to the ELOG, which uses a built in webserver, rather than apache.
He set up a proxy at the https address which will later host the secured elog: https://nodus.ligo.caltech.edu:8081/
When we make the switch to running the ELOG with HTTPS on by default, living on port 8081, we will set up apache to point 8080 at 8081, to preserve all of the old links.
I.e. this change should effectively be invisible to ELOG users if we implement it right.
Terse tonight, more verbose tomorrow.
We have succesfully achieved multiple kHz bandwidth using the CARM AO path. The CM board super boosts are at too high of a frequency to use effectively, given the flattening of the AO TF.
Jenne's totally, completely, and in all possible ways uncalibrated plot. Calibration lines are in here (numbers in control room notebook). I'm going to export and replot the data tomorrow, in real units.
I found that the scripts in FOL and PDFR directories were not in the svn. These were added to the svn.
I have created new slow channels for FOL. To do so, I have edited the fcreadout.db file in Domenica and the C0EDCU.ini file in /chans/daq
Domenica and frame builder were restarted after the edits.
Koji has moved the following files from /opt/rtcds/caltech/c1/chans/daq/ to /opt/rtcds/caltech/c1/chans/daq/trash as they are not being used anymore.
From there, we should be able to up the overall CARM gain by another 10dB, and turn on a super boost.
I measured the IN1/IN2 response of the IMC loop with the aglient analyzer providing the IN2 excitation, to see the transfer function of the AO acutation. The hump in the TF explains the flattening out of the CARM OLTF we saw last night. Turning down the gain by 6dB flattens this bump, and more importantly, has around 10dB less gain when the phase goes through -180, meaning more gain margin for the CARM loop.
Oddly, when I back out the MC OLG from these measurements, the loop shape is different than what Koji and Rana measured in December (ELOG 10841). Specifically, there is some new flattening of the loop shape around 300-400kHz that lowers the frequency where the phase hits -180. What could have caused this???
The -6dB that I mentioned was determined by putting the MC UGF at about 100kHz, at the peak of the phase bubble. This should allow us to safely have a CARM UGF of 40kHz since the MC loop has around +10dB loop gain there, which Rana once quoted as a rule of thumb for these loops. At that UGF, at least one CM board super boost should be fine, based on the loop shapes measured last night.
Lastly, I also checked out whether the 3 MC super boosts were limiting the AO shape; I did not observe any diffrence of the AO TF when turning off one super boost. It's likely totally fine.
Jenne has more detailed notes about how things went down last night, but I figure I should write about how we got the AO path stably up.
As the carm_cm_up script stood after Jenne and Den's work last week, the CARM loop looked like the gold trace in the loop shape plot I posted in the previous elog. The phase bubble was clearly enlarged by the AO path, but there was some bad crossover instability brewing at 400 Hz. This was evident as a large noise peak, and would lead to lock loss if we tried to increase the overall CARM gain.
As with our single arm CM board locking adventures, it was useful to have a filter that made the digital loop shape steeper around the crossover region, so that the 1/f AO+cavity pole shape played nice with the digital slope. As in the single arm trials, this effectively meant undoing the cavity pole compensating zero with a corresponding pole, letting the physical cavity pole do the steepening. This is only possible once the AO path has bestowed some phase upon you. A zero at a somewhat higher frequency (500Hz) gives the digital loop back some phase, which is neccesary to stay locked when the loop has only a few hundred Hz UGF, and the digital phase still matters. This gives us the purple trace.
This provided us with a loop shape that could smoothly be ramped up in overall gain towards UGFs of multiple kHz (red trace). At this point we could reliably turn on the first boost, which will help in transitioning the PRMI to 1f signals (green trace). We didn't want to ramp it up too much, as we saw that the phase bubble likely ended not much higher than 100kHz, and the OLG magnitude was flattening pretty clearly around 40kHz. While we could turn on a super boost, it didn't look too nice, as we would have to stay at low phase margin to avoid bad gain peaking (blue trace).
As could be seen in the noise spectra that Jenne showed, you can see the violin notches in the CARM noise. This means we are injecting the digital loop noise all over the place. We attempted rolling off the digital loop (by undoing the zero at 500Hz), but found this made the gain at ~200Hz crash down, almost becoming unstable. We likely haven't positioned the crossover frequency in the ideal place for doing this.
We didn't really give the interferometer any time to see how the long term stability was, since we wanted to poke around and measure as much as we could. While not every attempt would get us all the way there, the current carm_cm_up's success rate at achieving multi-kHz CARM bandwidth was pretty good (probably more than 50%) and the whole thing is still pretty snappy.
Overall a "meh" night for locking I think. The script to all-RF worked several times earlier in the evening, although it was delicate and failed at least 50% of the time. Later in the evening, we couldn't get even ~10% of the lock attempts all the way to RF-only.
Den looked into angular things tonight. With the HEPA bench at the Xend on (which it was found to be), the ETMX oplevs were injecting almost a factor of 10 noise (around 10ish Hz?) into the cavity axis motion (as seen by the trans QPD) as compared to oplevs off. Turning off the HEPA removed this noise injection.
Den retuned the QPD trans loops so that they only push on the ETMs, so that we can turn off the ETM oplevs, and leave the ITMs and their oplevs alone.
We are worried again about REFL55. There is much more light on REFL55 than there is on REFL11 (a 90/10 beam splitter divides the light between them), and we see this in the DC output of the PDs, but there seems to be very little actual signal in REFL55. Den drove a line (in PRCL?) while we had the PRMI locked with the arms held off resonance, and REFL55 saw the line a factor of 1,000 less than REFL 11 or REFL165. The analog whitening gain for REFL11 is +18dB, and for REFL55 is +21dB, so it's not that we have significantly less analog gain (that we think). We need to look into this tomorrow. As of now, we don't think there's much hope for transitioning PRMI to REFL55 without a health checkup.
I turned on the HEPA at the south end during the LSC. Sorry I ment to turn it off.
After discussions during the meeting today, I removed the PBS from the REFL path, which gives much more light to REFL11, REFL33 and REFL55. Also, the ND1.5 in front of REFL165 was replaced with ND1.1, so that REFL165 now gets 50mW of light. REFL11 gets about 1.3mW, REFL33 gets about 13mW and REFL55 gets about 12mW.
No locking, and importantly no re-phasing of any PDs has been done yet.
Here is an updated diagram of the REFL branching ratios.
- Aligned the arms with ASS. It had alot of offset accumulated. We offloaded it to the suspension.
- We could lock the PRMIsb with the new setup.
PRCL: REFL165I (-14deg, analog +9dB)) -0.1, Locking FM4/5, Triggered FM 2
MICH: REFL165Q (-14deg, analog +9dB) -1.5, Locking FM4/5, Triggered FM2/6/9
- Demod phases at REFL were adjusted such that PRCL in Q signals were minimized :
REFL165 -80deg => -14deg
REFL11 +164 => +7
REFL33 +136 => +133
Note: analog gains: REFL11: +18dB, REFL33: +30dB, POP55: +12dB, REFL165: +9dB
- Try some transition between REFL signals to check the signal quality.
Measure TFs between the REFL signals
REFL11I/REFL165I = +58
REFL33I/REFL165I = +8.5
POP55I /REFL165I = -246
REFL11I/REFL165I = +58
REFL33I/REFL165I = +8.5
POP55I /REFL165I = -246
REFL11Q/REFL165Q = +11
REFL33Q/REFL165Q = -1.5
POP55Q /REFL165Q = +280
REFL11Q/REFL165Q = +11
REFL33Q/REFL165Q = -1.5
POP55Q /REFL165Q = +280
- This resulted us to figure out the relationships of the numbers in the input matrix
REFL165I/Q 1.0/1.0 (reference)
REFL165I/Q 1.0/1.0 (reference)
Full locking trial
Arm locked -> ALS -> Arm offset locked
REFL165 phase tuned -110deg
PRCL gain -0.1 / MICH gain -2
We needed script editing.
Previous script saved in: /opt/rtcds/caltech/c1/scripts/PRFPMI/carm_cm_up_BACKUP.sh
Previous script saved in: /opt/rtcds/caltech/c1/scripts/PRFPMI/carm_cm_up_BACKUP.sh
- PRMI gain setting (input matrix & servo gain)
- CARM/DARM transition setting (see below)
The current CARM/DARM transition procedure:
== CARM TRANSITION (PART1) ==
- CM REFL1 gain is set to be -32
- CARM_B is engaged and the gain is ramped from 0 to +2.5
- Turn on FM7 (integrator)
- MC IN2 (AO path) engaged
- MC IN2 gain increased from -32 to -21
== DARM TRANSITION (PART1) ==
- DARM_B is engaged and the gain is ramped from 0 to +0.1
- Turn on FM7 (integrator)
== CARM TRANSITION (PART2) ==
- CM REFL1 Gain is increased from -32 to -18
- Ramp down CARM A gain to 0
== DARM TRANSITION (PART2) ==
- DARM_B gain is incrased to 0.37. At the same time DARM_A gain is reduced to 0
We succeeded to make the transition several times in the new setting.
- But later the transition got hard. We started to see big jump of the arm trans (TRX/Y 50->100) at the CARM transition.
- We tested the PRCL transition from 165MHz to 55MHz. 55MHz (i.e. POP55 which is REFL55PD) looks alot better now.
- ~1:30 The PMC was realigned. This increased PMC_TRANS about 10%. This let the Y arm trans recover ~1.00 for the single arm locking
- Decided to end around 3:00AM
The PMC is seated on 3 SS balls and it is free to move. I'm sure it will move in an earthquake. Not much, because the input and output K1 mirror frame will act as an earthquake stop.Atm2
Are there a touch of super glue on the balls? No, but there are V grooves at the bottom and on the top of each ball.Atm3
Some more words on yesterday's REFL path work.
The 90/10 BS that splits the light between REFL11 and REFL55 was placed back in August 2013, to compensate for the fact that REFL11 has a much larger RF transimpedance than REFL33. See elog 9043 for details.
We had been operating for a long time with an embarrasingly small amount of light on the REFL PDs. REFL11 used to have 80 uW, REFL33 used to have 400 uW and REFL55 used to have 700 uW. REFL 165 was the only sane one, with about 15 mW of light.
After yesterday's work, the situation is now:
As an aside, I was foiled for a while by S vs. P polarizations of light. The light transmitted through the PBS was P-pol, so the optics directing the beams to REFL11, 33 and 55 were all P-pol. At first I completely removed the PBS and the waveplate, but didn't think through the fact that now my light would all be S-pol. P-pol beam splitters don't work for S-pol (the reflection ratios are different, and it's just a terrible idea), so in the end I used the PBS to set the half waveplate so that all of my light was P-pol, and then removed the PBS but left the waveplate. This means that all of the old optics are fine for the beams going to the 3 gold-box REFL PDs. We don't have many S-pol beamsplitter options, so it was easier to use the waveplate to rotate the polarization.
Tonight I have modified transition steps from als to pdh signals. I have added 1:20 filters to CARM_A and DARM_A filter banks to make them unconditionally stable. These filters made locking more robust -- duty cycle is was ~70% tonight. I have also modified slow/ao crossover to avoid ringing up of lines above 1kHz.
Once AO is engaged with high bandwidth, REFL55 signal looks good and I transition PRCL from 165I to 55I. Optical gain compared to PRMI reduced from 55I/165I = -330 down to 55I/165I = 30 in full lock.
I worked on alignment of ETMs. Looking on the cameras I could improve arm power up to 160 and ifo visibility was 80%. POP22 fluctuated by ~50% and every few minutes we loose lock because POP22 almost touches zero.
Batteries replaced after 3.5 years with Amstron AP-1250F2, 8x 12V 6Ah
APC Smart -UPS 2200 model: SUA2200RM2U batteries were replaced by compatible RBC43, 8x 12V5A
Jenne and I interviewd Den this afternoon to make the things clear
- His "duty cycle" is not about the lengths of the lock stretch. He saids, the transition success probability is improved.
- For this improvement, the CARM transition procedure was modified to include turning on 1:20 (Z1P20) filter in CARM_A (i.e. ALS) once CARM_B (i.e. RF) dominates the loop in all frequency.
- I think this transition can be summarized like the attachment. At STEP4, the integration of the ALS is reduced. This actually does not change the stability of the servo as the servo stability is determined by the stability of the CARM_B loop. But this does further allow CARM_B to supress the noise. Or in other word, we can remove the noise coming from the CARM_A loop.
- The POP22 issue: Jenne has the trigger signal that is immune to this issue by adding some amount of POPDC for the trigger.
We can avoid the trigger issue by this technique. But if the issue is due to the true optical gain fluctuation, this may mean that the 11MHz optical gain is changing too much. This might be helped by PRC angular feedforward or RF 22MHz QPD at POP.
Tonight I measured seismic noise coupling to beam spot on PR2. There is coherence of 0.9 from X to PIT and Y to YAW around the stack resonances. TF was fited using vectfit and put into static matrix of oaf in the elements T240X -> PRM PIT, T240Y -> PRM YAW. I think we should actuate on the error point of the PRM OL but I decided not to go for a model change tonight. Data from seismometers and POP QPD was obtained during the UTC time 04:06:00 - 04:50:00 when PRMI was locked on sideband
Interferometer was locking rather robustly and every lock lasted on the everage of 3 minutes. During these lock periods I incresed bandwidth of optical lever servos of BS and test masses from 4Hz up to 10Hz and then closed transmission QPD loops. It seems from the camera that lock losses correspond to strong motion of the beam on pop camera. Scripts that change OPLEV bandwidth are in /users/den "increase_ol_bandwidth.sh" "decrease_ol_bandwidth.sh". Script "engage_qpd_servos" turns off ETM oplevs and turns on ETM -> trans QPD servos. These scripts can be copied to locking directrly if are useful.
Please, note that transition from 3f to 1f should still be tuned. Only PRCL was stably controlled using 1f so far
I had a handful of ~10 minute locks tonight. I intended to work on the 1f PRMI transition, but ended just familiarizing myself with the current scheme.
Before touching anything, I committed the locking scripts to the svn. Unfortunately, the up script as I found it never worked for me tonight. I had to reintroduce the digitial crossover helper in CM_SLOW to get past the ramping up of the overall REFL11 gain. (With this is in place, there is some bad ringing around 200Hz for a time, but it goes away... or unlocks)
I did phase the PD formally known as REFL55 with an 800Hz PRM excitation while in full lock.42 to 102 degrees, ~30dB ratio between the I and Q peaks. However, come to think of it, how much does the CARM loop interfere with this?
The locklosses I had seemed to be due to a large fluctuation in all cavities' power. Maybe this will be helped by better PRC angular control, but we could maybe be helped by normalizing the digital part of the CARM loop by the arm transmissions once lock is acquired.
Assuming the carrier mode in PRC is stable and the SB is the one moving, can we just use the POP DC QPD to control PRM?
Can we plot the arm power trend for multiple locks to see if it is associated with any thermal phenomenan in the IFO?
They should be able to fit with an exp + DC.
Can we plot the arm power trend for multiple locks to see if it is associated with any thermal phenomenan in the IFO?
I'm currently more inclined to believe that the arm power trends have more to do with the arm alignments. Here's a 10 minute lock from last night, where the QPD servos were switched on about halfway through. I couldn't get Den's new servos to turn on without blowing the lock, so I reverted to my previous design, but still only actuated on the ETMs, with their oplevs still on.
The most obvious feature is the reduction in power that seems to correspond to a ~10urad pitch deflection of ITMX when the lock begins. Is this optical spring action?
Also, it looks like the Y arm Yaw loop was badly tuned, and injecting noise. Ooops.
As of Den's QPD tuning, the QPD servos just actuate on the ETM. This next lock effectively had the QPD servos on the entire time, and we can see a similar drift in ITMX, and how ETMX then follows it to keep the QPD spot stationary. (Here, I'm plotting the QPD servo control signals, unlike above, so we can see X pitch servo output drift with the ITMX deflection)
Again, ITMX is moving in pitch by ~10urad when the interferometer starts resonating. If this is an optical spring, why does this just happen to ITMX? If it is digital shenanigans, how does it correlate with the lock, since there is nothing actuating on ITMX but oplevs and OSEM damping? Is light scattering into the ITMX OSEMs?
Before locking for the evening, I wanted to try again implementing the Wiener filters that I had designed back in Jaunary (elog 10959).
The problem then was that the newer version of Quack that I was using was doing weird things to me (elog 10993). But, tonight I used the old quack3andahalf that we used to use for Wiener-related things, and that worked (for up to order 20 filters). Actually, the pitch z-axis Wiener filter, when I copy the command string into Foton, says "Error" in the alternate box (the lower one). I also get this error message if I try to put in filters that were greater than order 20, and have been split into several filters. I'm not sure what's wrong, so for tonight I'm leaving out the pitch z-axis seismometer feed forward, and only using 20th order filters for all the rest.
So, pitch has feed forward signals from the T-240's x and y axes, and yaw has feed forward signals from all 3 seismometer channels.
At first, I just had the calculated Wiener filters, and a 10Hz lowpass, but the POP beam spot on the camera was getting slowly pushed away from the starting location. So, I added a 0.01Hz cheby1 highpass filter, and that seems to have fixed that problem. I need to go back to the simulations though, and see if this is going to cause extra noise to be injected (because of incorrect phase in the feed forward signal) at very low frequencies. All 5 Wiener filter banks have a gain of -1.
I'm getting a factor of 4-5ish between 2Hz and 3Hz in both pitch and yaw. What's interesting is that despite no direct angular suppression (as measured by the QPD) at higher frequencies, both POP22 and POPDC see improvement over a much broader range of frequencies. I'll have to think about how to predict this RIN coupling in my budgets.
The time series data for these filters was collected 2 months ago, on the 29th of January. So, it's nice to see that they work now too (although we have already seen that length feed forward signals are good over a many-month period).
In uncalibrated units (I need to calibrate the QPD to microrad, and should probably quote the PD signals in RIN), here is the plot. Blue trace (taken first) was with the feed forward on. Red trace (taken immediately afterward) was with feed forward off. This data is all PRMI-only, locked on REFL165 using Koji's recipe from elog 11174, including changing REFL165 phase to -14deg (from the -110 I found it at) for the no-arms case.
I got the PRMI transitioned from REFL165 over to REFL55 two times tonight. Also, I had 2 long-ish locks, one 9 minutes, and one 6 minutes. All the other locks were short - less than a minute or two.
I've done some shuffling around of the point in the CARM transition when the anti-boosts (1:20 filters) come on in the CARM A filter bank. I've moved the turn-on of these filters a several gain steps earlier, but I'm not sure that they're in the best place yet. Fiddling with the turn-on of the anti-boosts makes the big CARM oscillations last for longer or shorter - if they last too long, they blow the lock, so we don't want them to get too big.
The PRMI angular feedforward has helped a lot tonight, I think. I've added a line to the up script to enable the output of the OAF after the PRMI is locked, and the down script turns it off again. It's not so great when the PRM isn't aligned, since it's designed to work when the oplev is on, so it should be off unless the PRM is aligned. I tried to get a comparison of off vs. on PRC powers with the arms resonating, but I can't hold the lock for long enough when the OAF is not on to get even one average on my 0.01Hz bandwidth spectrum.
I've turned the arm ASC on a few times, but not every lock. Around 12:34am, I set the offsets when CARM and DARM were on RF signals, and I had hand-aligned the ETMs to minimize the power at the AS port. But, this wasn't a good spot for the next lock - the AS port was much darker with the ASC off for that lock. It would be nice to think about trying some dither alignment, and then maybe resetting the setpoints every lock. I'm using Q's original loop shapes, but as he left them yesterday, only actuating on the ETMs (with Yarm Yaw gain 0.7 rather than 0.9).
The CARM crossover might need more tuning. There's some gain peaking around 400 Hz that goes mostly away if I turn the digital CARM gain down by 2dB. (I'm not using any filters in the CM_SLOW filter bank).
I think that the CARM/DARM transition is more likely to be successful if the FSS slow DC is greater than 0.55ish. So far this is pretty anecdotal, but I think I have more success when it's higher. We should pay attention, and see if our trouble locking later in the nights correlates with smaller FSS slow DC values.
I got the PRMI over to 1f two times, at 1:54am and at 2:25am. I did not re-phase "POP"55 (which is the REFL55 signal), but I did check the values for the input matrix. I needed MICH = 0.01*POP55Q and PRCL = 0.008*POP55I. The first time I lost lock because I turned down the CARM digital gain too much. The second time I forgot to turn down the PRCL gain (I was *actually* using 0.01*POP55I for the PRCL input matrix, but needed to lower the gain from -0.08 to -0.07, which is about the same as just using 0.008 in the input matrix). Anyhow, I think PRCL loop oscillations were the cause of the second lockloss.
Here's a strip chart of my first lock of the night, which was the 9 minute lock. Up until about -6 minutes, I was hand-aligning (including the dip around -7.5 minutes, where I was figuring out which direction to move the ETMs). Around -3.5 minutes there is a significant dip down, that corrected itself. By the time I realized that the power had gone down, and was trying to figure out why, it came back. Maybe the same thing happened at the end of the lock, but it kept getting worse? Self, re-look at this time (around 11:50pm) to find out why the power dips.
My tummy feelings (without any data) make me think that this could be something with ITMX, like Q saw earlier today. Or, maybe ETMX, like we've seen for ages. Anyhow, my tummy feeling says this is an optic pointing problem. I certainly think this might be the same thing we see at the end of many locks, the power going low suddenly. So, it might give a big clue to our locklosses. Maybe.
RXA: I've changed the above text into pink Comic Sans to lend it the appropriate level of gravitas, given its scientific justification.
The 40m fenced area will start storing this large ~ 8000 lbs chamber on April 14. The asphalt will be cut, jack hammered the next 2-3 days in order to lay concrete.
Their schedule is from 8 to 5 starting tomorrow. We are asking them to work from 6 to 3pm
ETMX is about 12-15 ft away
Since none of us here are experts in pearl, I have put together a python script for a simple PID controller. This can be imported into any main scripts that will run the actual PID loop. The script, PID.py, exists in /scripts/general/
I'd like to get a concrete list of measurements written down, so that it's clear what needs to be done before I graduate.
Are there things that I'm missing? I've never had an IFO to characterize before.
Something funky is happening with the green light locked to the X arm. The green transmitted power is drifiting around. Maybe something weird is happening with the doubler? The digital thermal feedback loop is not on.
The green has been locked on a TM00 mode this whole time. The step in power is me closing the PSL green shutter, but I'm not doing anything during the smooth changes in power. IR power is steady, so the alignment should be ok. I can't recover full power with the end PZT alignement either.
Have you tried a different set of laser temperatures? I don't remember the value for the Xgreen, but whatever the value that matches PSL of 0.62ish and above seems to put the Xgreen laser at a bad temperature. I think this is the mode-hopping region, and we sometimes lock to the wrong mode.
So, FSS values of above 0.5ish are good, but they should be below 0.61ish.
Have you tried a different set of laser temperatures?
Yep, that is how I got back to stable powers.
A paltry two locks tonight, but not entirely useless. I had some issues keeping the PRMI locked, which some additional boosts helped with. But, my feeling was that our crossover process is not tuned well.
At full lock, both sub-loops have high gain around the crossover region, so the usual DTT loop transfer function measurement produces a meausrement of Gdigital/G_aopath (or minus that. I.e. I'm not currently 100% which is the bad phase in this plot, though it intuitive looks like 0 ). Thus, we can directly look at the crossover frequency and the effect of the different filters there. (I've also been working on an up-to-date CARM loop model today, so this will help inform that).
Below, the black traces are the crossover at the end of the script when using the 120:500 "helper," and purple is without it. As we turn up the AO path gain, the trace "falls" from above, which explains why we can see instabilities around the violin filter.
Having the helper on definitely made the probability of surviving the first overall CARM gain ramp higher, but it's not currently intuitively clear to me why that is the case. Afterwards, we can turn the helper off, to keep the shallower crossover shape. This is what I've put in to the up script for now. I also added a few seconds delay for when the script wants to switch DARM to RF only; I found it was maybe speeding too fast through this point.
DTT xml attached
Here's the comparison of last night's crossover measurement to my loop model. Not stellar, but not totally off base. All of the digital filters are read directly from the foton filter file, and translated from their SOS coefficients, so they should be accurate. I may have tallied together the wrong arrangement of FMs, though. I will recheck.
Although I don't have a measurement to compare it with yet (as I don't know where the crossover was, the filter statesolder, etc. for the older loop measurements), here's what my current CARM loop model looks like, just for kicks. Here, only the first CM board boost is on. If we turn on some super boosting, we can probably ease up on some of the digital boosts, lower the crossover frequency, and put some lowpass that suppress the violin filters' effect on the crossover and reduces digital sensing noise injection.
Lastly, I'll just note that my current MIST model predicts that the CARM cavity pole should be at ~170Hz, and a peak arm transmission of 180 times single arm power. I saw powers of ~120 last night.
Whoops, I implemented the IOP downsampling filters wrong. Once I did that, it looked like just delay mismatch, so I added two more computation cycles for a total of four 16k cycles, which is maybe not so justified... Nevertheless, model and measurement now agree much better. Here are the corrected plots.
I have 12 tick marks for times I got all the way to 1f for all 4 degrees of freedom in the PRFPMI. The CARM / DARM transitions now succeed more than they fail, which is nice.
At Q's suggestion, I am turning off all the violin filters in the MC2 path during the CARM transition. This also means that I don't need any of the notches that Den and I put into the CARM_A and CARM_B filter banks last week, which were right at the edges of the violin notches. Anyhow, this seems to make the transition much more likely to succeed. I don't ever use the CM_SLOW FM10 "crossover helper" that Q had to use last night. The violin filters are turned back on after the CARM transition is complete. We don't ever need those other notches.
I checked the REFL165 vs. REFL55 transfer functions for PRCL and MICH, and they are mostly flat. REFL55 seems like it'll give us extra phase for some reason.
I tried setting offsets for PRMI, but they seem to be strongly dependent on arm alignment. I ended up being pretty confused, and since all the REFL signals are pretty close to zero (when CARM/DARM on RF, PRMI on 3f), I have given up on that avenue for tonight.
I think many of my locklosses tonight (lost from the all 1f state) have been fast things, faster than the ADCs can handle. On the lockloss plots that I've looked at, the FSS PC drive is railed at 10V about 200msec before I lose lock. So, something (presumably in the fast CARM path) is making the MC/FSS loop unhappy. I have plugged in the Agilent to the Out2 of the CM board, so that it looks at REFL11. Unfortunately, this is after the input gain slider, so we don't see much until we're locked, but that seems fine. A video camera is pointed at the screen, so that I get real time spectra. It's hard to watch the TV at the same time as everything else, so I haven't witnessed the moment of lockloss in the fast spectrum yet. Be careful when walking down the Yarm. The tripod is partly in the walkway.
Q, I took a few TFs of the total CARM loop, although none of them are particularly good below a few kHz. I can't push hard enough to get coherence, without blowing the lock. TF data is in /users/jenne/PRFPMI/CM_TFs/CM_TFs_2Apr2015/ .
I was worried for a while that, after I transition PRMI to 1f, I hear lots of low frequency rumbling. However, watching the spectra (relative to references taken with CARM and DARM on RF, but PRMI on 3f), the low frequency error and control signals are staying the same for all 4 DoFs, but the high frequency for PRCL and MICH goes down significantly, so it's probably just that the low frequency stuff sounds more obvious, since it's not drowning in high frequency fuzz.
ITMX, ETMY, BS and SRM are oscillating ?
The BS oplev has been misbehaving and kicking the optic from time to time since noon. The kicks are not strong enough to trip the watchdogs (current watchdog max counts for the sensors is 135).
I took a look at the spectrum of the BS oplev error in pit and yaw with both loops enabled while the optic was stable. There is nothing alarmingly big except for some additional noise above 4Hz.
I have turned the BS oplev servo OFF for now.
I saw this kicking before
I think that this happens when the beam gets too close to the edge of the QPD. We see this regularly in the ETMs, if they've been kicked a bit, but not enough to trip the watchdogs. I think it might be the step/impulse response of the RES3.3 filter, which rings for almost 20 seconds.
Anyhow, I've just recentered the BS oplev. It was at -21urad in pitch, and had more than 400 counts on the top two quadrants, but only about 100 counts on the bottom two. Now it's around 300 counts on all 4 quadrants.
As a totally unrelated aside, I have installed texlive on Donatella, so that I could run pdflatex.
This is a very cool result. I'm surprised that it can work so good. Please post what frequency dependent weighting you used on the target before running the Wiener code.
I think its important to tune it to keep the low frequencies from getting amplified by a factor of 10 (as they are in your plots). The seismometers are all just noise acting like thermometers and tilt sensors below 0.1 Hz. Temperature and tilt do not couple to our interferometer very much.
It also seems weird that you would need 20th order filters to make it work good. In any case, you can always split the SOS up into pieces before making the digital filters. For LLO, we used 3 buttons in some cases.
The 40m fenced area will start storing this large chamber on April 14. The asphalt will be cut, jack hammered the next 2-3 days in order to lay concrete.
Jackhammering was happening around 7:30am
It looks like it did no harm. It is too early to say what may have moved. Rana's worrisome email was late.
The ground preparation is completed.
Unfortunately, this kind of trend plot is not detailed enough to know if something has gone bad in a quantitative way. But at least we can tell that the suspension wire didn't break.