[Alan, Koji, Manasa]
Record number of 50 freshmen were given tour of the 40m this afternoon.
Valve configuration: Vacuum Normal
I have modified the LSC model (the currently-running model is checked into the svn), but it is not compiling for me. So, if you need to make changes to it, be careful, and probably save my version off to the side, and checkout the latest svn version. (I don't foresee anyone needing to modify this model any time soon though).
The change that I'm trying to make is adding several more lockin setups, so that we can measure the sensing matrix elements for several degrees of freedom simultaneously.
Right now, the error that I'm getting is the frustrating "something isn't connected" error, even though if you look in the model, the part that it mentions is fully connected. Usually the solution to this is to disconnect and reconnect everything, so I'll work on that after I return to the lab in a bit.
This was the second week without wet mopping the floor and wet wipe down of the vacuum envelope.
We changed filters on the 40m "HEPA" vacuum pump. It still has very dirty exhaust. Do not use it in clean room!
RA: I'm not sure how to interperet this; I think that the SUM channel is divided by the SUM so that this is supposed to be RIN, but not sure. Can someone please take a look into the SUS model and then explain in the elog what the SUM normalization algorithm is?
PRM is dark. PRM and SRM oplev servos are off. ETMY is not centered.
Step by step procedure for stabilizing arms using ALS servo:
The procedure is the same for both the arms.
0. Check that the ALS arm servos are turned OFF and not sending any signals to the ETM suspensions.
1. Find the beat note by varying the laser temperature (moving the slider for SLOW_SERVO2_OFFSET).
Tip: It is easier to have the arms locked using IR PDH while searching for the beat note. Also check the stability of the MC. Unstable MC will cause the PSL temperature to drift and thereby affect the beat frequency.
2. Once you have the beat note, check if the beat amplitude is ~ -15 to -20 dBm. If the amplitude is small, then the alignment needs to be fixed (either the green input pointing at the end tables or the PSL green alignment). This is important because the UGF of the phase tracking loop (should be above 1KHz) changes with the amplitude of the beat note.
Also the beat frequency should be < 100 MHz; preferably below 80 MHz.
3. Disable IR PDH locking if you had used it while searching for the beat note.
4. Press CLEAR HISTORY button for the phase tracker servo. Check if the phase tracking loop is stable (phase tracker servo output counts should not be ramping up). If the phase tracker is not stable, check the servo gain and phase margin of the loop.
5. Turn OFF all filters in the ALS arm servo filter module except for FM5 (phase compensation filter). With ALS arm servo gain set to zero, enable the arm servo and allow ALS control signals to be sent to the ETM suspensions.
5. Open dtt and look at the power spectrum of the ALS error signal (C1:ALS-BEAT?_FINE_PHASE_OUT_HZ).
6. Set ALS arm servo gain +/- 0.1 to check the sign of the servo gain. Wrong sign of gain will make the loop unstable (beat note moving all over the frequency range on the spectrum analyzer). If this happens, set the gain to zero immediately and clear history of phase tracker servo. If you have set the correct sign for gain, the servo will stabilize the beat note frequency right away.
7. Once you know the correct sign of the servo gain, increase the gain in steps while simultaneously looking at the power spectrum of error signal on dtt (it is convenient to set dtt measurements to low bandwidth and exponential measurement settings). Increase the gain until you can see a slight bump close to the UGF of the ALS servo (>100Hz).
There have been times when this servo gain was in a few hundreds; but right now it varies from +/- 10-20 for both the arms. So we are stepping up gain in steps of +/- 2.
8. Enable filters (FM2, FM3, FM6, FM7, FM8). Wait to see the rms noise of the error signal go down (a few seconds).
9. Enable boost filter (FM10). There also exists a weaker boost filter (FM4) which we don't use any more.
1. Beat frequency changes affect both the servo gain and sign of gain. So if you lose stability of ALS servo at any point, you should go through all the steps again.
2. At any point if the ALS arm servo becomes unstable (which can happen if the MC loses lock or if the beat frequency was too high ), change the servo gain to zero immediately. Turn OFF all the filters except for FM5 (if they were enabled) and reset phase tracker servo (CLEAR HISTORY button in the phase tracker filter module). Masayuki has written the down script that does all this. The script will detect arm servo loop instability by continuously looking at the feedback signal. Details about the script can be found here.
Here is a cheat sheet that can give you an idea of the SLOW SERVO2 offset range to scan in order to find the beat note:
PSL temperature X offset Y offset
31.58 5278 -10890
31.52 5140 (not recorded)
31.45 4810 (not recorded)
31.33 4640 -10440
31.28 4500 -10340
Bonus: notice how we have cleverly used the comb of bounce frequencies around the calibration line to determine that REFL11 is clipping!
Rana and I noticed last week that it looked like the REFL11 beam was clipping. This afternoon, I locked the PRMI with REFL 165 I&Q, and checked the REFL 11 path. The beam looks fine through all of the optics going to the diode, so I just realigned the beam onto the diode using the itty bitty steering mirror. I have not yet checked the change (hopefully improvement) in the REFL11 spectrum.
I discovered that I was not getting enough SNR on all the refl RFPDs when I actuated using the Sensing Matrix script. The problem was that the ITMs have actuation constants that are a factor of 5 lower than the PRM. So, I need to push on the ITMs (for MICH) about 5 times as hard as I push on the PRM (for PRCL). I have modified the sensing matrix scripts to allow different actuation amplitudes for each degree of freedom. If I watch the REFL PD spectra while the script is running, I see that I now have some actual SNR (as in, more than 1, which is what the SNR was for some diodes previously).
A consequence of this is that the script to analyze past data will no longer work on sensing matrix data taken before this afternoon. On the other hand, that data isn't very useful, since there was no SNR.
The upgrade of megatron broke the nds2 service. I have fixed things by
1) installing the latest version of framecpp (1.19.32) from the lsc debian repository (this was necessary because I couldn't link to the existing version)
2) built nds2-server-0.5.11 and installed it in the system directories (/usr/bin)
3) there were a few scripts/links/etc that didn't seem to be set up correctly and I fixed them to correspond with my preious message.
nds2 is now running and the channel list should be updated regularly and the service restarted as appropriate.
I have resaved the PRMI locking settings in the IFO Config screen. Nothing has changed, except that I have put a 1e-4 into the PRCL matrix elements for REFL11I, REFL33I and REFL55I. So, PRMI still locks on REFL165 I&Q, but the other 3 REFL diodes' whitening gets triggered when the cavity is locked. I think this will help the LSC sensing matrix measurements, which I'm going to test out now.
Something is really excellent with the alignment today, or something has changed with the POP path / electronics. While usually we see ~120 counts on POP22_I and ~175 counts on POP110_I (cf elog 9193), today I have ~175 counts on POP22_I and ~265 counts on POP110_I.
Someone left the arms aligned, and the LSC engaged, so the arms have been locked almost continuously for several days hours. The trend below is for 4 days hours. What is most impressive to me is that we don't see a big degredation in the transmitted power over this time.
EDIT: Okay, I got excited without paying attention to units. It was only several hours, which is not too unusual. Although the lack of transmission degredation is still unusual. However, this may be due to improved oplevs? I'm not sure why, but we're not seeing (at least in this plot) the degredation to ~0.7 after an hour or so.
Tried a bunch of stuff, but eventually just turned off the TRANS_QPD loops and loops are stable. Needs more debugging.
Back around June 18, Jamie was debugging some Guardian code here to replace our MC autolocker. Afterwards our MC WFS stopped working. We never figured out what went wrong, but at the time we turned off the feedback from the MC trans QPD and it stabilized the response at DC.
Today, I noticed that the trans QPD feedback is on. Did anyone do this on purpose?
Its problem causing behavior is slow, but you can catch it if you wait. With the nominal WFS gain of 0.4 the control signal ramps up monotonically at a rate of ~100 counts/minute. Depending upon the static alignment of the MC, this could let it take 10 minutes or a few hours before it rails the MC SUS actuators and breaks the lock. Very sneaky. Don't turn this loop back on without making sure its working and not breaking. I would trend it for you, but the SLOW channels associated with the TRANS QPD servo are not trended --- does anyone know how to get them in the channel list?
I wonder what's drifting between the laser and the PMC? And why is it getting worse lately?
I noticed that the MC3 LL sensor was apparently dead according to its suspension screen. Since it was only the fast ADC channel and not the SLOW PDmon, I could tell that it was just in the ADC cabling. I pushed in a few of the MC3 sensor cables on the front and back of the PD whitening board and it came back OK. According to this trend of the past 40 days and 40 nights, it started slipping on this past Wednesday morning.
Was anyone walking near MC2 or the suspension electronics racks before noon on Wednesday (Oct. 2nd)?
MC3 watchdog gets tripped sometimes when lock is lost. I noticed that there were no limits set in the MC WFS drive. The attached plot shows that over 40 days, the OUT16 channels from the WFS don't exceed 1000 counts. So I've set the limit to be 2000 in all 6 of the MC ASCPIT/YAW filter banks. Please don't turn them off.
OUT16 is really not the right way to measure this, but for some reason, we don't have any DQ channels from the MC WFS screen ??? So we're not able to measure the trend of the high frequency drive signal.
So I added the WFS(1,2)_I_(PIT,YAW)_OUT_DQ and WFS(1,2)_(PIT,YAW)_OUT_DQ channels to the c1ioo.mdl at 2048 Hz. I used Jamie's excellent 'rtcds' utility to build and install:
1) after making the edits to c1ioo.mdl I saved the file/
2) sshing to c1ioo
3) rtcds stop c1ioo
4) rtcds make c1ioo
5) rtcds install c1ioo
6) rtcds start c1ioo
7) telnet fb 8087
8) daqd> shutdown
That seemed to do it OK.
Unfortunately, all of the instructions that we have in the Wiki for adding channels and model building are misleading and don't mention any of this. There are a few different methods listed which all instruct us to do the whole make and make install business in a bunch of non existent directories.
I centered the ETMY OL today and found that the UGF was around 3-4x too LOW after the laser swap and re-alignment. That's why the Y arm has been shaking so much today.
NO more OL work without loop measurements and noise measurements.
MC unlocked over the weekend and also got severely mis-aligned. It all started around midnight on Saturday.
At first I thought that this was due to the MCS CPU meter being railed at 60 us, so I deleted a bunch of filters in MC1,2,3 that are unused and left over from Den's quantization noise investigations. This reduced the CPU load somewhat, but didn't make any real improvements. Turning on the ASC filter banks in the MC SUS still mis-aligned the MC.
With the MC WFS and MC ASS turned off, there is still some digital junk coming in and misaligning things. Plot attached.
Similar stuff coming in on ITMX, but not ITMY.
Tried restarting various FEs, but there was no effect. Also tried rebooting c1lsc, c1ioo, & c1sus. Finally did 'shutdown -r now' on all 5 computers on the CDS overview screen and simultaneously (almost) pressed the reset button on the RFM switch above the old c1pem crate. Everything came back OK except for c1oaf (I had to manually button his BURT button) and now the ASC inputs on all the SUS are zero when they should be and MC is well locked and aligned.
Rob and I used to do this trick when he thought that a cosmic ray had corrupted a bit in the RFM network.
I wrote the down script for ALS. This script is (script)/ALS/ALSdown.py When this script is running, it watches the feedback signal of the ALS control loop so as to shut down the servo immediately when the suspension is kicked.
When the value of C1:ALS-X(Y)ARM_OUT becomes larger than the threshold (right now it is 4500 counts), it changes the servo gain to 0, turns off all filters except for FM5 (the filter for phase compensation), resets the history of the phase tracker of each arm and prints the time on window when the suspension kicked
I put the switch on the C1ALS screen, and if you push this switch the window will open (like when you turn on the c1ass script) and the script start to run. For stopping this script, you have to close that window or press Ctrl + C on that window. This is little bit inconvenient, but we will make autolocker script for ALS and this downscript will be included that script soon. So I think it is enough to protect the suspensions right now.
That's good, but please no more Oplev work. We want to do all of it at once and to make no more changes until we have all the parts (e.g. dumps and correct lenses) in hand and then talk over what the new design will be. I don't want to tune the beam size and loop shape every week.
We replaced the laser for optical lever of ETMY. And also we aligned the path so that beam spot hits the center for each optics. I attached the spectrum of the SUS-ETMY_OPLEV_SUM, the red curve is with old laser, and blue curve is with the new laser. We also measured without laser so as to measure the QPD dark noise (green curve). The change is significant, and seems much closer to other oplev spectrum.(Brown curve is the oplev spectrum of ITMY)
The new laser is:
Manufacture name: JDSU, Model number: 1103P, Serial number: PA892324
The injection power is 3.7 mW and the out coming power is 197 uW (measured just before the QPD). The output value of the SUS-ETMY_OPLEV_SUM is about 8500.
First we measure 2 spectrum ( including the dark noise). After that we replace the laser and align the optical lever path. We changed the post of one of the mirror (just before the QPD) because the hight was too low. Inside of the chamber is darker than before - actually we had scattering light inside the chamber before. We dumped the reflected light from QPD. And then we measured the spectrum of the oplev output. I also aligned oplev of ETMY after restoring the YARM configuration using IFO configure screen.
We don't know actually what was the problem, laser quality or the scattering light or some clipping. But the oplev seems to be better.
Steve: Atm2 shows increased gains correction later for UGF elog 9206
We locked MICH with 2 arms stabilized by ALS control.
We measured the power spectrum of the LSC-MICH_IN1 at each step so as to know the in-loop noise of MICH. And also we measured the OLTF of MICH loop and the error signal with BS excited at 580 Hz and MICH notch filter at same frequency enabled to obtain the MICH calibration factor.
1. We locked MICH using the AS55Q error signal and fedback to BS actuator. (Red curve)
2. We locked MICH and locked both the arms using POX11 and POY11 error signals and fedback to ETMs actuators.(Blue curve)
3. We stabilized both the arms using ALS. We use the ALS error signals and fedback to ETMs actuators. And then we locked MICH.(Magenta curve)
The green and brown curve are the ALS in-loop noise, which is the _PHASE_OUT_Hz calibrated error signals. So for these two curves the unit of vertical axis is Hz/rHz. The other curves are the MICH in-loop noises and these are not calibrated. So for these curves the unit of vertical axis is counts/rHz.
The UGF of MICH loop is 10 Hz with phase margin of 45 degrees (measured today). The FPMI noise with ALS stabilized arms is much larger than the FPMI with IR PDH locked arms above 30 Hz. That is because the ALS arm stability is not as good as the stability of PDH locked arms. We have to analyze and verify the calibrated numbers for FPMI + ALS with model.
I checked the BK precision 1856D manual. I found that although this frequency counter can measure upto 3.5GHz, it has 2 separate input channels to measure two range of frequencies.
One input to measure between 0.1Hz to 100 MHz and the other to measure between 80MHz to 3.5GHz. Our beat frequency desirable range is <100MHz for stable ALS. Also, the beat PD response falls off beyond ~150MHz . Should we be happy with this frequency counter and use it in the 0.1Hz-100MHz range or look for one with a better measuring range?
P.S. Right now we are using the spectrum analyzer in the control room set to frequency range from 10MHz - 140 MHz for beat note search.
We succeeded in stabilizing both the arms using ALS and get IR to resonate at the sametime.
At each step we measured the _PHASE_OUT_Hz calibrated error signals for Y in this configuration so as to get the in-loop noise of ALS control of YARM
1. we stabilized YARM off IR resonance by using ALS, misaligned ETMX, closed XARM green shutter. That means no IR flashing and no green in XARM.
2. we aligned the ETMX with XARM green shutter closed.
3. we opened the green shutter and locked the green laser with PDH to the XARM.
4. we stabilized the XARM using ALS and off resonance for IR.
5.We brought the XARM to IR resonance with YARM stabilized off IR resonance.
6. we brought the YARM to IR resonance
Beat frequencies when both the arms were stabilized and had IR resonating :
X arm beat frequency = 73.2 MHz; Y arm beat frequency = 26.6 MHz.
1.the ALS in-loop noise in X and Y arms with IR off resonance and resonating.
2.the ALS in-loop noise in Y arm in each step from 1 to 6.(will follow soon)
The Y arm ALS in-loop noise doesn't seem to be different in any of the configurations in step 1 to 6. This seems to mean that the ALS of the two arms are decoupled.
Actually we are not sure what changed from the last few days (when we were seeing some sort of coupling between the ALS of X and Y arm) except for YARM green PDH servo gain changed (see this entry),
We found the PDH servo gain for Y arm green was set at 2 (too low). The gain was set to 8.6 (based on earlier OLTF measurement elog 8817).
The ALS out-of loop noise was remeasured. We also measured the out-of loop noise of each arm while the other arm had no green (shutter closed). There doesn't seem to be any difference in the noise (between green and orange for Y arm and red and pink for the X arm) except that the noise in the X arm was slightly low for the same conditions (blue and red) when measurement was repeated.
TRANSLATION by Jenne: We first locked both X and Y for IR using the LSC, and X and Y for green using the analog PDH servos. We measured the _PHASE_OUT_Hz calibrated error signals for both X and Y in this configuration - this gives us the out of loop noise for the ALS system, the Green and Blue traces in the plot. We then closed the X end shutter, and measured the Y arm's error signal (to check to see if there is any noise contribution from the suspected X-Y cross beatnote). Then, we closed the Y end shutter, relocked the Xarm on green's 00 mode, and measured the X arm's error signal. We weren't sure why the Pink curve was smaller than the Blue curve below a few Hz, so we repeated the original measurement with both arms dichroic. We then got the Red curve. So, we should ignore the blue curve (although I still wonder why the noise changed in such a short time period - I don't think we did anything other than unlock and relock the cavity), and just see that the Green and Gold curves look similar to one another, and the Red and Pink curves look similar to one another. This tells us that at least the out of loop noise is not affected by any X-Y cross beatnote.
We made a new flowchart of ALS autolocker. We added the additional step to find the beat note frequency. We have to find a way to read the PSL temperature. By reading the PSL temperature we can decide the sweep range for the end green laser temperature with the curve which measured in previous measurement (in this entry)
We have three thresholds of error signal. One is the threshold for checking the arms are stabilized or not. It should be some hundreds count. Another threshold is to check that the suspensions are not kicked. This should be some thousands counts (in flow chart, it is 2K counts). The other is to check the optimal servo gain. If the servo gain is too high, the UGF is also too high and we will not have enough gain margin. The error signal start to oscillate at the UGF. We will check this oscillation and find the optimal gain. In flow chart this threshold is 1K counts.
As another proof that sometime is ill with ETMX Optical Lever:
We scanned the ETMX bias in PIT using ezcastep and saw that the OL response is very screwy. In the attached, you can see that the ETMX SUSPIT signal shows that the actual motion is good and linear. In fact, our sus diagonalization is extermely good and there's almost no signal in SUSYAW.
ETMY oplev laser clearly showing a tail when it was projected up the sealing.
PS (10-4-2013): I checked the beam quality again as it was removed from the table: it had a good image at 3 meters
As I was trying to solve the 2 arm ALS problem, I found the Y arm ALS not so stable AGAIN :( . I measured the in-loop noise of the X arm as ~400Hz/rtHz (60 picometers).
I went ahead and checked the out of loop noise of the ALS and found there is some high frequency noise creeping in above 20Hz for the Y arm ALS (blue curve). I checked the UGFs and phase margins of the phase tracker loops and found they were good (UGF above 1.4KHz and phase margins between 40 and 60 degrees).
So the suspect now is the PDH servo loop of both the arms which has to be checked.
Attached is the out-of loop noise plots of X and Y arm ALS.
Message on 'pianosa':
Failed to fetch http://ppa.launchpad.net/drgraefy/nds2-client/ubuntu/dists/lucid/main/binary-amd64/Packages.gz 404 Not Found
Sorry, that was an experiment to see if I could set up a general-use repository for the NDS packages. I've removed it, and did an update/upgrade.
First up for me this evening was getting the PRMI locked.
I used the IFO configure screen to lock the X and Y arms, then aligned them using the ASS scripts. Then used the IFO config screen to restore the Michelson, and did some fine tune tweaking of the BS alignment by looking at the AS camera. Then, I restored the PRMI from the IFO config screen, tweaked the PRM a little bit in yaw, and was able to get a lock using REFL 165 I&Q for ~25 minutes before I got bored and unlocked things. I used the ASS for the PRM to align the PRM, then turned off the ASS. POP110 and POP22 both drifted down, but by a small amount, and at the end (when I turned the ASS back on for PRM), they picked back up to about their original levels.
(Note to self: to get it to print both plots, chose custom paper size, make it 14.5 by 11. Don't ask why, just do it, because it works. Also, in PNG device properties, increase the compression to 9.)
After I played with the PRMI, I started looking at the ALS system.
I had both arms locked on IR using the regular LSC system (so POX and POY for the error signals). Then I opened up the green shutters, and got both arms locked on green (so the green lasers were just following the arms...no digital ALS business). I went out to the PSL table and tweaked up the alignment of the green beams (didn't need much at all, just an itsy bitsy bit in yaw, mostly). I saw a very strong peak for the Yarm vs. PSL (around -19dBm), and there was a harmonic of that beat. Opening and closing the Xarm green shutter had no effect on these peaks, so there wasn't any kind of X-Y cross beat sneaking around that I could see. That's really as far as I got - I think (but haven't checked) that Manasa may have removed the power splitter / combiner, so that the RF analyzer is only looking at the Y beat PD (she mentioned earlier today that she was going to give that a try to narrow things down).
After that, Rana and I went back to the PRMI for some noise stuff, and worked on the PMC. See those separate elogs for info on those activites.
The attached plot shows the spectra of all the REFL signals with the PRMI SB lock.
We excited the ITMY_LSC with 3000 counts. We used the Masayuki calibration of ITMY (5 nm / count * (1/f^2)) to estimate this peak in the REFL spectra.
To correctly scale the REFL spectra we account for the fact that the DTT BW was "0.187 Hz" and we turn off the "Bin" radio box before measuring the peak height with the cursor.
Since the ITMY motion is 3000 * 5e-9 / (580.1 Hz)^2 = 44.6 pm_peak, we want the DTT spectrum of the REFL spectra to report that too.
i.e. to convert from peak height to meters_peak, we use this formula:
meters_peak = peak_height * sqrt(BW) * sqrt(2)
I *think* that since the line shows up in multiple bins of the PSD, we should probably integrate a ~0.5 Hz band around the peak, but not sure. Need to check calibration by examining the time series, but this is pretty close.
Mystery: why are the REFL_I 3f signals nearly as good in SNR as the 1f signals? The modelling shows that the optical gain should be ~30-100x less. Can it be that our 1f electronics are that bad?
The PMC transmission was around 0.78 all day, rather than the usual 0.83ish. Rana went out to the PSL table and fixed up the PMC alignment. This should not need to be done very often, so things to check before touching the alignment are FSS / PMC settings (digital stuff). Make sure that the PC RMS (on the FSS screen) is low (at least below 2, preferably below 1), and that the FSS Fast monitor is near 5ish (not near 0 or 10).
This is a capture of PMC REFL's camera after Rana was finished. If it doesn't look this good when you finish then you are not done. Never do PMC alignment without looking at the PMC REFL camera.
The attached trend shows 80 days of PMC REFL and TRANS. The bad alignment stuff started on Sep 21-24 time period. You know who you are.
I vote on PRMI+1arm -> PRFPMI
In moving now to full IFO locking, there are a number of sub-states to diagnose:
Which to do first and in what order?
The smoke alarms were turned off and surrounding areas were covered with plastic.
The folding I-beam was ground down to be in level with the main beam.
Load bearing cable moved into correct position. New folding spring installed.
Crane calibration was done at 500 lbs at the end of the fully extended jib.
Than we realized that the rotating wheel limit switch stopped working.
This means that the crane is still out of order.
Max and I started upgrading megatron to Ubuntu 12.NN today. We were having some troubles with getting latest python code to run to support the Summary pages stuff.
Its also a nice test to see what CDS tools fail on there, before we upgrade the workstations to Ubuntu 12.
Since its Linux, none of the usual upgrading commands worked, but after an hour or so of reading forums we were able to delete some packages and all the 3rd party packages and get the upgrade to go ahead. We'll have to re-install the LSC, GDS, LAL repos to get it back into shape and get NDS2 working. The upgrade is running in a 'screen' command on there.
Wed Oct 02 14:50:16 2013
Update #1: The upgrade asks a couple dozen questions so it doesn't proceed by itself. I've been checking in to the 'screen' every couple hours to type in 'Yes' to let it keep going.
Update #2: It finished a few hours ago:
controls@megatron:~ 0$ uname -a
Linux megatron 3.2.0-54-generic #82-Ubuntu SMP Tue Sep 10 20:08:42 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
controls@megatron:~ 0$ date
Wed Oct 2 18:33:41 PDT 2013
[revised at 10/1 pm 5:00]
As we mentioned in previous entry (elog#9171), the phase margin of ALS control was at most 20 degree. We modified the filter of C1ALS_XARM and C1ALS_YARM. The OLTF is in attachment1. Now the phase margins of both arms are more than 35 degree. I modified the FM5 filters of both servo.
FM5 filter is the filter for the phase compensation. It had the one pole at 1000 Hz and one zero at 1Hz. As you can see in attachment2, it start to lose the phase at 50 Hz. But the UGF of our ALS control loop is higher than 100 Hz, so I changed the pole from 1 kHz to 3 kHz in order to get more phase margin at UGF. The new servo have 10dB larger gain than previous filter at higer than 1kHz, but the control loop do nothing in that region, so it's no problem.
We have phase lag between 2 arms. I used same filters for both arms, so I'm wondering where these phase lag came from.
Yesterday and this morning's slow NFS disk access was caused by 'svndumpfilter' being run at linux1 to carve out the Noise Budget directory. It is being moved to another server; I think the disk access is back to normal speed now.
Probably more important is to establish quantitatively how particle counts affects the lock acquisition or noise in the interferometer.
We don't want to adopt a "Sky is Falling" mentality as was done previously in LIGO when people were trying to outlaw burritos and perfume.
Dust monitor counts and human noses do not correlate well with the interferometer's nose.
When the vacuum system is closed, we might check to see if particle counts correlate with losses in the PMC or excess scatter on the ISC tables. If not, we should move on to other concerns.
How can we improve the cleanliness of the 40m IFO room 104 ? May be Mario Batali crocs if you chief chef of the lab likes it. We can do more effective things.
Atm 1 is showing the lab air quality dependence on outside air measured at the top of the IOO chamber. This made me to measure the differential pressure between lab and out side.
Properly sized air conditioner is over pressurizing it's room by 0.05 [" Water] like clean assembly room.
The 40m at Vertex location is barely getting pressurized to 0.01 " W
The control room is OK with 0.04 " W but it's air quality is very bad! It is 10x worse at 0.5 micron than IFO room.
Every entry from well pressurized control room into barely pressurized IFO pumps dirty air to our "clean room."
This door should be closed.
The drill- room entry is ideal because it is using the same air conditioner as the main lab, therefore it has cleaner air.
Things to do: seal holes of CES walls, seal paint wall at south end so it will shed less, replace gas kits on doors.
I have plugged the cable tray space entering the control room above Rosalba.
I think we can use the IMC autolocker to start with getting this started. Once Jamie fixes the NDSSERVER environment variable bug, we should be able to use his more slick automation code to make it auto lock.
Flowchart for ALS autolocker. The error signal thresholds will be decided by trial and error.
We wanted to lock both the arms using ALS and get IR to resonate while arms are held using ALS. The X arm was locked using ALS and offsetter2 was used to scan the arm and find IR resonance. The Y arm was locked using ALS. But as the Y arm was brought closer to IR resonance, the X arm ALS loses lock. (attachment 1)
We believe that this comes from the X and Y transmission not being well separated at the PSL table. The PBS is not sufficient to decouple them (A strong beatnote ~35dB between the X and the Y arm green lasers can be seen on the spectrum analyzer).
Decouple the X and Y arm transmitted beams at the PSL table. I am trying to find a wedged mirror/window that can separate the 2 beams at the PSL table before the beat PD (sadly the laseroptik HR532nm optics have no wedge)
The MC lost lock around 8+hrs ago. The transmission from PMC was 0.77 this morning, so we aligned the PSL to the PMC using the two steering mirrors before the PMC. We brought the PMC transmission to 0.841. We also aligned the MC, and the MC transmission reflection now is 0.59.
I fixed the XARM and YARM real time calibration servo.
I also change the C1CAL_MICH_A servo. Now the actuator response and the suspension TF are combined together and that filter name is BS_act. C1CAL_XARM_A and C1CAL_YARM_A have same kind of filters, ETMX_act and ETMY_act.
There are AI filter in each A servo and inv_AA, inv_DAA filters in CINV servo, but it's doesn't work correctly yet.
These aren't servos. What he means is that he's changed some filters in the real time calibration screens so as to make the actuation and sensing parts more accurate, but the inversion of the AA filters is not accurate yet.