The mode cleaner is locked and the air conditioning is full on. So the the air conditioning doesn't seem to be so important for the lock to hold.
We changed the HIGH/LOW values of the PMC_TRANS.
The edited file was updated on the svn.
Since the PMC_TRANSPD was replaced behind the pzt mirror (see the entry), its nominal value were reduced to something like ~1V from the previous value of ~2V.
In the medm screen C1PSL_PMC.adl the PMC_TRAN always indicated red because the value were low compared with the previous one.
We went to /cvs/cds/caltech/target/c1psl, then edited psl.db
- Here are the new parameters we set up in the file.
- - - -
These values are based on ~4days trend of the PMC_TRAN.
Then we manually updated those numbers by using ezcawrite in order not to reboot C1PSL.
So now it nicely indicates green in the medm screen.
Hm... You touched the optics between the MC and the Faraday... This will lead us to the painful work.
I am afraid that the beam is already walking off from the center of MC1/MC3 after the work on the PSL table.
This may result in the shift of the spot on those MC mirrors. So I recommend that:
- Lock the cavity
- Check the A2L for MC1/3
- Adjust it by the periscope
- If it is fine, adjust the optics after the MC (steering, Faraday, etc)
Off-centering of the MC2 spot is no problem. We can move it easily using Zach's scripts.
Tell me when the work is planed on Sunday as I might be able to join the work if it is in the evening.
[Alberto, Kiwamu, Kevin, Rana]
Today we tried to measured the beam shape after the MC MMT1 that Jenne installed on the BS table.
The beam scan showed a clipped spot. We tracked it down to the Farady and the MCT pickoff mirror.
The beam was getting clipped at the exit of the Faraday. But it was also clipping the edge of the MCT pick-off mirror. I moved the mirror.
Also the beam looked off-center on MC2.
We're coming back on Sunday to keep working on this.
Now things are bad.
I just got off the phone with Alberto and Kiwamu, and I'm going to try to recalculate things based on their measurements of the distances between MC3 and SM1. It sounds like the CAD drawings we have aren't totally correct. I know that when we opened doors just before Christmas we measured the distances between the BS table and the ITM tables, but I don't think we measured the distance between the IOO table and the BS table. Hopefully we can fit everything in our chambers.....
We started a vacuum work in this morning. And still it's going on.
Although the last night the green team replaced a steering mirror by an 80% reflector on the PLS table, the beam axis to the MC looks fine.
The MC refl beam successfully goes into the MCrefl PD, and we can see the MC flashing as usual.
We started measuring the distance of the optics inside the vacuum chamber, found the distance from MC3 to MMT1(curved mirror) is ~13cm shorter than the design.
We moved the positions of the flat mirror after the Faraday and the MMT1, but could not track the beam very well because we did not completely lock the MC.
Now we are trying to get the lock of the MC by steering the MC mirrors.
I just finished redoing the calc based on the measurements that happened last week. Using the average of the Vert and Horz measurements in Kevin's elog 2986, I find that we need to make the MMT telescope ~8cm longer. So, can you please place the flat mirror after the Faraday in the same place as the drawing, but move the MMT1 79mm farther away from that flat mirror? Looking at the table layouts that Koji has on the wiki, this should still (barely) fit.
d2a = 884.0mm (no change) ------ MC3 to Flat after Faraday
d2b = 1123.2mm (move MMT1 farther toward center of BS table) -------- Flat after Faraday (SM1) to MMT1
d3 = 1955.0mm (result of moving MMT1) --------- MMT1 to MMT2
d4a = 1007.9mm (no chnage) ----------- MMT2 to SM2
d4b = 495.6mm (no change) ------------ SM2 to PRM
Kevin suceeded in locking it !!
Talked with Alex and tracked down why the codes were not working on the new c1iscex finally. The .bashrc and .cshrc files in /home/controls/ on c1iscex has the following lines:
setenv EPICS_CA_ADDR_LIST 22.214.171.124
setenv EPICS_CA_AUTO_ADDR_LIST NO
This was interfering with channel access and preventing read and writes from working properly. We simply commented them out. After logging out and back in, the things like ezcaread and write started working, and we were able to get the models passing data back and forth.
Next up, testing RFM communications between megatron on c1iscex. To do this, I'd like to move Megatron down to 1Y3, and setup a firewall for it and c1iscex so I can test the frame builder and testpoints at the same time on both machines.
I've modified the lsc.mdl and lsp.mdl files back to an older configuration, where we do not use an IO processor. This seems to let things work for the time being on megatron while I try to figure out what the is wrong with the "correct" setup which includes the IO processor.
Basically I removed the adcSlave = 1 line in the cdsParameters block.
I've attached a screen shot of the desktop showing one filter bank in the LSP model passing its output correctly to a filter block in the LSC. I also put in a quick test filter (an integrator) and you can see it got to 80 before I turned off the offset.
So far this is only running on megatron, not the new machine in the new Y end.
The models being use for this are located in /cvs/cds/caltech/cds/advLigoRTS/src/epics/simLink
Valera and I put the 2 Guralps and the Ranger onto the big granite slab and then put the new big yellow foam box on top of it.
There is a problem with the setup. I believe that the lead balls under the slab are not sitting right. We need to cut out the tile so the thing sits directly on some steel inserts.
You can see from the dataviewer trend that the horizontal directions got a lot noisier as soon as we put the things on the slab.
You'll have to ask Steve how deep he cut, but the tile is cut around the lead balls, so they are not sitting on the linoleum. They might just be sitting on the concrete slab, or whatever Steve found underneath the tile, instead of fancy steel inserts, but at least they're not on the tile. I don't know why things got noisier though...
Although trends are available, I am unable to get any full data from in the past (using DTT or DV). I started the FB's daqd process a few times, but no luck.
I blame Joe's SimPlant monkeying from earlier today for lack of a better candidate. I checked and the frames are actually on the FB disk, so its something else.
I tried running dataviewer and dtt this morning. Dataviewer seemed to be working. I was able to get trends, full data on a 2k channel (seismic channels) and full data on a 16k channel (C1:PEM-AUDIO_MIC1) This was tried for a period 24 hours a go for a 10 minute stretch.
I also tried dtt and was able to get 2k and 16k channel data, for example C1:PEM-AUDIO_MIC1. Was this problem fixed by someone last night or did time somehow fix it?
A poor lonely SR785 was found this morning roaming around in the lab in evident violation of the fundamental rule which requires all the equipment on carts to be brought back inside the lab right after use.
The people and the professors related to the case should take immediate action to repair for their misdeed.
For both sidebands to be antiresonant in the arms, the first modulation frequency has to be:
f1 = (n + 1/2) c / (2*L)
where L is the arm length and c the speed of light. For L=38m, we pick to cases: n=3, then f1a = 13.806231 MHz; n=2, then f1b = 9.861594 MHz.
If we go for f1a, then the mode cleaner half length has to change to 10.857m. If we go for f1b, the MC length goes to 15.200m. A 2 meter change from the current length either way.
And the mode cleaner would only be the first of a long list of things that would have to change. Then it would be the turn of the recycling cavities.
Kind of a big deal.
I leave notes about a plan for the green locking especially on the PSL table.
(1) open the door of the MC13 tank to make the PSL beam go into the MC. Lock it and then optimize the alignment of the MC mirror so that we can later align the incident beam from the PSL by using the MC as a reference.
(2) Remove a steering mirror located just after the PMC on the PSL table. Don't take its mount, just take only the optic in order not to change the alignment .
(3) Put an 80% partial reflector on that mount to pick off ~200mW for the doubling . One can find the reflector on my desk.
(4) Put some steering mirrors to guide the transmitted beam through the reflector to the doubling crystal. Any beam path is fine if it does not disturb any other setups. The position of the oven+crystal should not be changed so much, I mean the current position looks good.
(5) Match the mode to the crystal by putting some lenses. The optimum conversion efficiency can be achieved with beam waist of w0~50um (as explained on #2735).
(6) Align the oven by using the kinematic mount. It takes a while. The position of the waist should be 6.7 mm away from the center of the crystal (as explained on #2850). The temperature controller for the oven can be found in one of the plastic box for the green stuff. After the alignment, a green beam will show up.
(8) Find the optimum temperature which gives the best conversion efficiency and measure the efficiency.
(7) Align the axis of the PSL beam to the MC by steering the two mirrors attached on the periscope.
RMS which is integrated down to 1Hz is 1.6MHz.
This number is almost what I expected assuming the cavity swings with displacement of x ~< 1um.
Its OK, but the real number comes from measuring the time series of this in the daytime (not the spectrum). What we care about is the peak-peak value of the PZT feedback signal measured on a scope for ~30 seconds. You can save the scope trace as a PNG.
Here are some more plots and pictures about the end PDH locking with the green beam.
-- DC reflection
I expected that the fluctuation of the DC reflection had 1% from the resonant state to the anti-resonant state due to its very low finesse.
This values are calculated from the reflectivity of ETM measured by Mott before (see the wiki).
In my measurement I obtained DC reflection of V_max=1.42 , V_min=1.30 at just after the PD.
These numbers correspond to 7.1% fluctuation. It's bigger than the expectation.
I am not sure about the reason, but it might happen by the angular motion of test masses (?)
--- time series
Here is a time series plot. It starts from openloop state (i.e. feedback disconnected).
At t=0 sec I connected a cable which goes to the laser pzt, so now the loop is closed.
You can see the DC reflection slightly decreased and stayed lower after the connection.
The bottom plot represents the feedback signal measured before a sum amp. which directly drives the pzt.
-- length fluctuation
One of the important quantities in the green locking scheme is the length fluctuation of the cavity.
It gives us how much the frequency of the green beam can be stabilized by the cavity. And finally it will determine the difficulty of PLL with the PSL.
I measured a spectrum of the pzt driving voltage [V/Hz1/2] and then converted it to a frequency spectrum [Hz/Hz1/2].
I used the actuation efficiency of 1MHz/V for the calibration, this number is based on the past measurement.
RMS which is integrated down to 1Hz is 1.6MHz.
A picture below is a ETMx CCD monitor.
One of the spot red circled in the picture blinks when it's unlocked. And once we get the lock the spot stays bright.
The second sideband is resonant in the arms for a cavity length of 37.9299m.
The nearest antiresonant arm lengths for f2 (55MHz) are 36.5753m and 39.2845m.
If we don't touch the ITMs, and we use the room we still have now on the end tables, we can get to 37.5m.
This is how the power spectrum at REFL would look like for perfect antiresonance:
And this is how it looks like for 37.5m:
Or, god forbid, we change the modulation frequencies...
Andri and I mounted the Raicol Crystal #724 in one of the new Covesion Ovens. The procedure was the same as before - see elog entry here.
There was one issue - the glass plate that goes on top of the crystal is coated on one side with ITO (Indium-Tin Oxide) and it's not 100% certain that this was mounted in the correct orientation. It is virtually impossible to tell which side of the glass is coated.
The base plate of the oven was tapped for an M3 hole. We retapped it for an 8-32 and bolted it to a post and that one of the New Focus 4-axis translation stage. The assembly is currently bolted to the PSL table, awaiting use.
This is how the RF generation box might soon look like:
A dedicated wiki page shows the state of the work:
That's true. But I thought that you measured the mode after those optics and the effect of them is already included.
Rana pointed out that the anticipated mode calculation should be modified to include the index of refraction of the crystals in the Faraday, and the polarizers in the Faraday. This may affect where we should put MMT1, and so this should be completed before round 2 measurements are taken, so that we can move MMT1.
Yes, the measured mode takes all of this into account. But in Kevin's plot, where he compares 'measured' to 'expected', the expected doesn't take the Faraday optics into account. So I should recalculate things to check how far off our measurement was from what we should expect, if I take the Faraday into account. But for moving forward with things, I can just use the mode that we measured, to adjust (if necessary) the positions of MMT1 and MMT2. All of the other transmissive optics (that I'm aware of) have already been included, such as the PRM and the BS. This included already the air-glass curved interface on the PRM, etc.
Congratulation! Probably you are right, but I could not get this is a real lock or something else.
1) How much was the fringe amplitude (DC) of the reflected beam? (Vref_max=XXX [V] and Vref_min=YYY [V])
Does this agree with the expectation?
2) Do you have the time series? (V_ref and V_error)
I guess I succeeded in locking of the cavity with the green beam
Strictly speaking, the laser frequency of the end NPRO is locked to the 40 meter arm cavity.
Pictures, some more quantitative numbers and some plots are going to be posted later.
After the alignment of the cavity I could see DC fringes in its reflection. Also I could see the cavity flashing on the monitor of ETMY_CCD.
I drove the pzt of the NPRO with f=200kHz, and then the spectrum analyzer showed 200kHz beat note in the reflection signal. This means it's ready to PDH technique.
And then I made a servo loop with two SR560s, one for a filter and the other for a sum amp.
After playing with the value of the gain and the sign of the feedback signal, the laser successfully got lock.
To make sure it is really locked, I measured the open loop transfer function of the PDH servo while it stayed locked. The result is shown in the attached figure.
The measured data almost agrees with the expected curve below 1kHz, so I conclude it is really locked.
However the plot looks very noisy because I could not inject a big excitation signal into the loop. If I put a big excitation, the servo was unlocked.
The current servo is obviously too naive and it only has f-1 shape, so the filter should be replaced by a dedicated PDH box as we planed.
That's true. But I thought that you measured the mode after those optics and the effect of them is already included.
I created the sus model, which is the suspension controller for ITMX, ITMY, BS, PRM, SRM. I also created sup, which is the suspension plant model for those same optics.
Updated /cvs/cds/caltech/target/fb master and daqdrc files to add SUS, SUP models. Megatron's /etc/rc.d/rc.local file has been updated to include all the necessary models as well.
The suspension controller needs the Binary IO outputs need to be checked and corrected if wrong by changing the constant connected to the exclusive or gates. Right now its using the end suspension binary output values which may not be correct.
Now that we have multiple machines we'd like to run the new front end code on, I'm finding it annoying to have to constantly copy files back and forth to have the latest models on different machines. So I've come to the conclusion that Rana was right all along, and I should working somewhere in /cvs/cds/caltech which gets mounted by everyone.
However, this leads to the svn problem: I.e. I need recent code checked out from the RCG repository, but our current /cvs/cds/caltech/cds/advLigo directory is covered by the 40m SVN. So for the moment, I've checked out the advLigoRTS from https://redoubt.ligo-wa.caltech.edu/svn/advLigoRTS/trunk into /cvs/cds/caltech/cds/advLigoRTS. This directory will be kept as up to date as I can keep it, both by running svn update to get Alex/Rolf's changes and on my end by keeping the new and updated models. It will remain linked the RCG repository and not the 40m repository. At some point a better solution is needed, but its the best I can come up with for now.
Also, because we are starting to compile on different machines sometimes, you may run into a problem where a code won't run on a different machine. This can be fixed by commenting out some lines in the startup script. Go to the /cvs/cds/caltech/scripts directory. Then edit the associated startSYS file by commenting out the lines that look like:
if [ `hostname` != megatron ]; then
echo Cannot run `basename $0` on `hostname` computer
Unfortunately, this gets reverted each time "make SYS" and "make install-SYS" gets run.
The other issue this leads to is that some machines don't have as many CPUs available as others. For example our new thin 1U machines have only 4 dual cores (8 CPUs total). This means the specific_cpu setting of any of the codes cannot be higher than 7 (cores being numbered 0 through 7). Core 0 is reserved for the real time kernel, and Core 1 will be used on all machines for the IO processor. This leaves only cores 2 through 7 available for models to use which include LSC, LSP, SUS, SUP, SPY, SCY, SPX, SCX, OMC, OMP, OAF, OAP?, IOC, IOP. Since there are more than 6 models, duplication in final production code of specific_cpus will be necessary. Codes which are all running on Megatron at one point will have to be rebuilt with new specific_cpu values when run on the actual final machine.
[Jenne, Kevin, Kiwamu]
We moved some optics in preparation for measuring the MC mode after the first MMT curved optic, RoC -5m.
Kevin and I found the box of DLC (sp?) mounts with the 2" Y1-45P optics in the clean tupperware boxes. We removed one of the Y1-45P's, and replaced it with the MMT1 -5m optic, which was baked several weeks ago. We left the Y1-45P on the cleanroom table next to where the MMT optics are. We placed this MMT mirror in the place it belongs, according to Koji's table layout of the BS table.
We drag wiped one of the other Y1-45P's that was in the box since it was dirty, and then placed the optic on the IOO table, on the edge closest to the BS table, with the HR side facing the BS table, so that the beam reflected off the curved mirror is reflected back in the direction of the BS table. This was aligned so the beam hits the same PZT mirror we were using last time, to get the beam out of the BS chamber door. We left a razor dump on the edge of the BS table, by the door, which will need to be removed before actual measurements can take place.
Also, the optics are in place now, and the beam is going out the BS chamber door, but we have not yet measured distances (design distances quoted on the MMT wiki page), and confirmed that everything is in the right place. So there is a bit more work required before beginning to measure round 2.
Note: While I was poking around on the BS table, I had to move several optics so that we could fit MMT1 in the correct place. When preparing to move these optics, I found 2 or 3 that were totally unclamped. This seems really bad, especially for tall skinny things which can fall over if we have an earthquake. Even if something is in place temporarily, please clamp it down.
Very nice as usual. Can you add the curve to show the ideal mode of the MC on the profile plot?
I fit the data from the beam profile that Jenne measured on 5/21/2010. The distances are measured from halfway between MC1 and MC3 to the beam scanner. The fits give the following where w0 is the waist size and z0 is the distance from the waist to halfway between MC1 and MC3.
For the horizontal profile:
reduced chi^2 = 0.88
z0 = (1 ± 29) mm
z0 = (1
w0 = (1.51 ± 0.01) mm
w0 = (1.51
For the vertical profile:
reduced chi^2 = 0.94
z0 = (673 ± 28) mm
z0 = (
w0 = (1.59 ± 0.01) mm
w0 = (1.59
I calculated the radius of curvature of MC2 using these values of w0:
horizontal: (16.89 ± 0.06) m
vertical: (17.66 ± 0.07) m
For this calculation, I used the value of (13.546 ± .0005) m for the length of the mode cleaner measured on 6/10/2009. The specification for the radius of curvature of MC2 is (18.4 ± 0.1) m.
In the following plots, the blue curve is the fit to the vertical beam radius, the purple curve is the fit to the horizontal beam radius, * denotes a data point from the vertical data, and + denotes a data point from the horizontal data.
The problem with the new models using the new shared memory/dolphin/RFM defined as names in a single .ipc file.
The first is the no_oversampling flag should not be used. Since we have a single IO processor handling ADCs and DACs at 64k, while the models run at 16k, there is some oversampling occuring. This was causing problems syncing between the models and the IOP.
It also didn't help I had a typo in two channels which I happened to use as a test case to confirm they were talking. However, that has been fixed.
[Alex, Joe, Kiwamu]
Eventually all the front end computers came back !!
There were two problems.
(1): C0DCU1 didn't want to come back to the network. After we did several things it turned the ADC board for C0DCU1 didn't work correctly.
(2): C1PEM1 and C0DAQAWG were cross-talking via the back panel of the crate.
(what we did)
* installed a VME crate with single back panel to 1Y6 and mounted C1PEM1 and C0DAQAWG on it. However it turned out this configuration was bad because the two CPUs could cross-talk via the back panel.
* removed the VME crate and then installed another VME crate which has two back panels so that we can electrically separate C1PEM1 and C0DAQAWG. After this work, C0DAQAWG started working successfully.
* rebooted all the front ends, fb40m and c1dcuepics.
* reset the RFM bypath. But these things didn't bring C0DCU1 back.
* telnet to C0DCU1 and ran "./startup.cmd" manually. In fact "./startup.cmd" should automatically be called when it boots.
* saw the error messages from "./startup.cmd" and found it failed when initialization of the ADC board. It saids "Init Failure !! could not find ICS"
* went to 1Y7 rack and checked the ADC. We found C0DCU1 had two ADC boards, one of two was not in used.
* disconnected all two ADCs and put back one which had not been in used. At the same time we changed the switching address of this ADC to have the same address as the other ADC.
* powered off/on 1Y7 rack. Finally C0DCU1 got back.
* burtrestored the epics to the last Friday, May 21st 6:07am
I got a VME crate from Peter's lab. It is already installed in 1Y6 instead of the old broken one.
I checked its power supply, and it looked fine. It successfully supplies +5, +12 and -12 V. And then I put c0daqawg and c1pem1 back from 1Y7.
Now I am trying to reboot all the front end computers with Peter's VME crate. A picture of the VME crate will be updated later.
We should completely turn off the air conditioner when working on green locking.
Even if green beams propagates inside of chambers, the air conditioner does affect the spatial jitter of the beam.
The attached picture was taken when Steve and I were seeing how the green beam jittered.
At that time the beam was injected from the end table and going through inside of the ETM, the ITM and the BS camber.
Eventually it came out from the camber and hit the wall outside of the chamber. It was obvious, we could see the jittering when the air cond. was ON.
I found the elog got down around 7:30 am in this morning.
So I restarted it by running the script: "start-elog-nodus" as instructed on the wiki.
Notes on May 25th
Don't do the following things !! This causes bad cross-talking of CPUs mounted on the crate.
I moved c0daqawg and c1pem1 from 1Y6 vme crate to 1Y7 crate due to the bad power supply.
Another problem: c0dcu1 doesn't come back to the network.
After moving them, I tried to get back them into the RFM network. However c0dcu1 never came back, it still indicates red in C0DAQ_DETAIL.adl screen.
Alberto and I did even "nuclear option" (as instructed), but no luck.
The IMC table had to be leveled again, for two reasons: 1) It was un-leveled when Jenne and Kiwamu removed an extra beam dump when they took the beam profile measurements, and 2) the stack of weights I had put there before was too tall to allow the beam to pass (I didn't realize that the BS chamber is offset a bit to the north, so the beam passes right over the NE edge of the IMC table).
First of all, I was wrong before when I said that the stack of weights was 4 blocks tall; it was 6 blocks tall. I re-leveled the table this afternoon by removing the top three blocks and placing them immediately south of the bottom three in the original stack, while also moving the circular weight north of its previous position. The table is now balanced roughly to within the tolerance of the bubble level I was using.
After the leveling, I tried to re-lock the modecleaner. Upon removing the beam block on the PSL table, I got some sort of resonance flashes on the MC TRANS monitor. With some minor adjustments to MC2&3, I was able to get a decent TEM00 mode to hit. The cavity wouldn't lock, so I went to the AP table and checked to make sure that the REFL beam was hitting the PD. It was, but the beam was very close to the edge of the focusing lens, so I moved the steering mirror slightly to make the situation a little better.
I then went to the control room to finish the by-now-mundane task of fine-tuning the MC lock, but today's was a worthier opponent. For some reason, the thing didn't want to lock for more than a few seconds at a time. I saw that the spot on MC2 was quite a bit off-center, so I ran the MC2_spot_xxx scripts to get it visually in place, then revisited the AP table to ensure that the REFL beam was still on the PD. No dice.
I don't know what was different. I had Ameristat over the opening between the tanks, with posters on top and on the sides (as usual), and I checked to ensure that the servo gains were at the appropriate levels. Joe pointed out that IOO VME was not responding, but we didn't seem to think that this was the problem (based on nothing I can put in words or stick figure cartoons), and the "alive" indicator on the Auto-Lock control in the MEDM screen was not blinking, as it usually is, but I don't know what bearing this has on anything.
I will try to lock again tomorrow.
I tried to measure the beam profile of the 2W laser today but ran into problems with the ND filters. With the measurements I made a few weeks ago, I used a reflective ND 4.0 filter on the PD. The PD started to saturate and Koji and I noticed that a lot of the metallic coating on the filter had been burnt off. Koji told me to use an absorptive ND 4.0 filter in front of a reflective ND 0.6 filter. I tried this today but noticed that a few holes were being burned into the absorptive filter and that the coating on the reflective filter behind it was also being burned off in spots. I don't think we wanted to use a polarizing beam splitter to reduce the power before the PD but I didn't want to ruin any more filters.
In this morning I found daqawg didn't work.
After looking for the cause, I found one of the vme racks mounted on 1Y6 doesn't work correctly.
It looks like the vme rack mounting c0daqawg could not supply any power to the frontends.
Now Steve and I are trying to look for a spare for it.
If you have a working 40m Optickle model, put it in a common place in the SVN, not in your own folder.
I can't figure out why changing the arm length would effect the RF sidebands levels. If you are getting RF sidebands resonating in the arms, then some parameter is not set correctly.
As the RF sideband frequency gets closer to resonating in the arm, the CARM/DARM cross-coupling to the short DOFs probably gets bigger.
I uploaded the latest iscmodeling package to the SVN under /trunk. It includes my addition of the 40m Upgrade model: /trunk/iscmodeling/looptickle/config40m/opt40mUpgrade2010.m.
I don't know the causes of this supposed resonances yet. I'm working to try to understand that. It would be interesting also to evaluate the results of absolute length measurements.
Here is what I also found:
It seems that 44, 66 and 110 are resonating.
If that is real, than 37.5m could be a better place. Although I don't have a definition of "better" yet. All I can say is these resonances are smaller there.
IFO room temp 27.5C , Please remember to turn AC back on !
Today the new Dell computer for the GSCS (General SURF Computing Side) arrived.
We put it together and hooked it up to a monitor. And guess what? It works!
I'm totally impressed by how the Windows get blurred on Windows 7 when you move them around. Good job Microsoft! Totally worth 5 years of R&D.
Bob replaced the tipseal in an other drypump and I swapped it in. TP3 turbo is running again, it's foreline pressure is 40 mTorr. The RGA is still off
... not just because we haven't locked the interferometer for quite some time. I mean, it literally stinks. The chiller's chiller is molding. Its' dripping water and there's mold all under it (Jo just confirmed: "yeah, it's mold").
Someone from Caltech maintenance just crossed the door. Hopefully he'll help us fix it.
I'll keep you updated. Stay tuned.
1. Give us the designed arm length. What is the criteria?
2. The arm lengths got shorter as the ITMs had to shift to the end. To make them longer is difficult. Try possible shorter length.
Alex brought over a ADC, DAC, and PCIe card which goes into the computer and talk to the IO chassis. We tried installing the new "small" IO chassis in 1X4, but initially it couldn't find the ADC/DAC boards, just the Contec Binary out board.
We tried several different configurations (different computer, different IO chassis, the megatron chassis, the megatron IO chassis with new cards, a new IO chassis with megatron cards.
The two things were concluded once we got a new IO chassis talking with the new computer.
1) Its possible one of the slots is in the IO chassis as we didn't see the ADC until we moved it to a different slot in the new chassis
2) The card that Alex had brought over to put in the computer doesn't behave well with these IO chassis. He went back to downs to try and figure out what it is, and test it with the chassis over there.
Currently, Megatron's IO chassis is sitting on a table behind racks 1Y5 and 1Y6, along with the new "large" IO chassis. Megatron's PCIe card for talking to the IO chassis was moved to the computer in 1X4. The computer in 1X4 is currently being called c1iscex with IP 192.168.113.80.
I update my old 40mUpgrade Optickle model, by adding the latest updates in the optical layout (mirror distances, main optics transmissivities, folding mirror transmissivities, etc). I also cleaned it from a lot of useless, Advanced LIGO features.
I calculated the expected power in the fields present at the main ports of the interferometer.
I repeated the calculations for both the arms-locked/arms-unlocked configurations. I used a new set of functions that I wrote which let me evaluate the field power and RF power anywhere in the IFO. (all in my SVN directory)
As in Koji's optical layout, I set the arm length to 38m and I found that at the SP port there was much more power that I woud expect at 44Mhz and 110 MHz.
It's not straightforward to identify unequivocally what is causing it (I have about 100 frequencies going around in the IFO), but presumably the measured power at 44MHz was from the beat between f1 an f2 (55-11=44MHz), and that at 110MHz was from the f2 first sidebands.
Here's what i found:
I found that When I set the arm length to 38.55m (the old 40m average arm length), the power at 44 and 110 MHz went significantly down. See here:
I checked the distances between all the frequencies circulating in the IFO from the closest arm resonance to them.
I found that the f2 and 2*f2 are two of the closest frequencies to the arm resonance (~80KHz). With a arm cavity finesse of 450, that shouldn't be a problem, though.
I'll keep using the numbers I got to nail down the culprit.
Anyways, now the question is: what is the design length of the arms? Because if it is really 38m rather than 38.55m, then maybe we should change it back to the old values.