I added an integrator to increase the gain at low frequencies (below 5 Hz). In addition, I increased

the band of the differentiator. The schematics for both integrator and differentiator are the following:

The magnetic is stably levitated.

I turned off the light to get rid of 60Hz noise on the photodiode. I tried to measured the

open-loop transfer function of this setup, but somehow the SR560 is always saturate

when I injected the signal from SR785, which produces some weird results at

low-frequencies.

In addition, I found out that when the light is turned on, the levitation

can be stable even when I inverted the sign of the control loop. The control signal

on the osciloscope is the following:

This oscillator is around 120 Hz, which should be  the harmonics of 60 Hz from light pollution.

I am not sure exactly why it is stable when the control-loop sign is flipped. This could

be similar to the Pauli trap in the iron trap, because the coil not only provides a force

but also provides the rigidity. The sign of such rigidity depends on the sign of the control

current. If such oscillating rigidity changes at a frequency much higher than the response

frequency of the magnet, it will stablize  the system simply by significantly increasing

the inertial of the magnet.More investigations are essential to completely understand it.

For information about Pauli trap, one can look at the wikipedia:

http://en.wikipedia.org/wiki/Quadrupole_ion_trap

[Sanjit, Jenne]

Sanjit and I are trying to put names to some signals which exist in SimuLink land, but which don't (yet) exist in EPICS land.  The deelio is that for each of the chosen SEIS signals in the ASS_TOP_PEM screen, the signal is split.  One part of the signal is used to decide how the adaptive filter should look, and the other part is actually used when doing the on-line subtraction.  Previously only the part of the signal which is used to decide on the Adaptive Filter could be seen on the screens, and had names. 

Before touching anything on the Simulink ASS.mdl, I did an svn check in, which put things at revision 36639. 

To try to make the desired signals exist, I put cdsFilt boxes (to create filter modules for each of these signals), and gave each of them a name (kind of like the Neverending Story....once they have a name, they'll exist).  My new names are C1:ASS-TOP_PEM_#_APPLY, which correspond to the previously-existing C1:ASS-TOP_PEM_#_ADPT (these are the ones that are along the top of the ASS_TOP_PEM matrix screen).  This version of the simulink model was checked in, and the svn is now at revision 36640.

We then did some "make clean", "make ass" and "make install-ass" action, and burt restored c1assepics, but nothing seems to be happening.  The screen doesn't have white boxes all over the place, and we didn't get any errors when we did the makes, and I'm sure we burt restored correctly (made sure the ASS GDS screen had a 1 in the lower left box etc), but all the values on the screen are still zero.  

When we ran the ass front end in terminal on the c1ass machine, we did see an error: "Invalid chan num found 2 = 30624" "DAQ init failed -- exiting".  I think this means that we need to have told some file somewhere that I was going to be adding 8 new channels. (maybe an .ini file?) Hopefully the Joe & Peter team can help us out with this, since they've been doing this kind of thing for the new system.

Moral of the story is, the new (non-working) simulink file has been svn checked in as revision 36640, and we're reverting to revision 36639, which was before I touched anything today.

This plot shows the RIN as measured by the ISS. Its ~2 x 10^-7, whereas its supposed to be more like 3 x 10^-8.

The ISS has DC coupled RIN channels (with a _F suffix) and AC coupled RIN channels (with a _FW suffix). By using a swept sine, Rob determined that the AC coupled channels have an AC coupling pole at ~80 Hz. The attached plot uses this and then has the overall gain adjusted to match with the _F channels below 10 Hz.

The _F channels can be converted directly into RIN by just dividing the spectra by the mean value of the time series. The dark offset of these channels is small and so this only introduces a ~5-10% calibration error.

Question #1: Why is the RIN so bad? According to the MEDM screen, the photocurrent on the MON/SENS PDs is 1.9/1.3 mA. That's sort of low, but should still allow us to get 5x10^-8 in RIN.

Question #2: Does it make an effect on the current DC Readout work? IF so, should we try to fix up the ISS in a temporary way? Since the in-loop and out-of-loop detectors are completely coherent, all of the noise is likely just unsuppressed noise from the laser. We are unable to increase the gain because of the high frequency noise from the NPRO.

Let's remember to replace this ISS with a new one that can drive an AOM. Need a volunteer to get us a new ISS.

 Here is a 7 years plot of  of the 40m temperature variations.

 Saturday's special event of braking up the large concrete pieces in CES bay was un event full.

As part of the fb40m restart procedure (Sanjit and I were restarting it to add some new channels so they can be read by the OAF model), I checked up on how the backup has been going.  Unfortunately the answer is: not well.

Alan imparted to me all the wisdom of frame builder backups on September 28th of this year.  Except for the first 2 days of something having gone wrong (which was fixed at that time), the backup script hasn't thrown any errors, and thus hasn't sent any whiny emails to me.  This is seen by opening up /caltech/scripts/backup/rsync.backup.cumlog , and noticing that  after October 1, 2009, all of the 'errorcodes' have been zero, i.e. no error (as opposed to 'errorcode 2' when the backup fails).  

However, when you ssh to the backup server to see what .gwf files exist, the last one is at gps time 941803200, which is Nov 9 2009, 11:59:45 UTC.  So, I'm not sure why no errors have been thrown, but also no backups have happened. Looking at the rsync.backup.log file, it says 'Host Key Verification Failed'.  This seems like something which isn't changing the errcode, but should be, so that it can send me an email when things aren't up to snuff.  On Nov 10th (the first day the backup didn't do any backing-up), there was a lot of Megatron action, and some adding of StochMon channels.  If the fb was restarted for either of these things, and the backup script wasn't started, then it should have had an error, and sent me an email.  Since any time the frame builder's backup script hasn't been started properly it should send an email, I'm going to go ahead and blame whoever wrote the scripts, rather than the Joe/Pete/Alberto team.

Since our new raid disk is ~28 days of local storage, we won't have lost anything on the backup server as long as the backup works tonight (or sometime in the next few days), because the backup is an rsync, so it copies anything which it hasn't already copied.  Since the fb got restarted just now, hopefully whatever funny business (maybe with the .agent files???) will be gone, and the backup will work properly. 

I'll check in with the frame builder again tomorrow, to make sure that it's all good.

[Jenne, Sanjit]

We would like several channels from the OAF/ASS screen to be saved to frames, so that we can use the channels for our OAF model.  In theory, this should involve uncommenting the desired channels in the .ini file (.../caltech/chans/daq/C1ASS.ini), and restart the frame builder.  Since this .ini file was generated a long time ago, and things have been changed since then, the chnnums in the .ini file and the corresponding .par file don't match up.  We need to go through the .par file (/cvs/cds/gds/param/tpchn_c3.par), and look up the chnnums for our channels, and copy those numbers into the .ini file.  Figuring out what was going on involved many fb40m restarts, but on the last one of the night, I restarted the backup script, so it should (hopefully) run tonight, and get all of the frames that we've been missing.

Notes to self: 

*  When adding channels to other front ends, the end of the process is to click the blue button on the C0DAQ_DETAIL screen next to your computer.  C1ASS isn't on that screen.  Instead, in the C1ASS_GDS screen, click DAQ Reload.

*  The channel names for the Test Points and the .ini files must be different.  That's why there's a '_2048' suffix at the end of every channel in our .ini file.

*  tpchn_C1 is all of the old-style system test points.  tpchn_C2 is the C1OMC, and tpchn_C3 is for the C1ASS testpoints.

*  When uncommenting channels in the C1ASS.ini file, make sure acquire is set to 1 for every channel we want saved.  The default in this .ini file is set to acquire = 0.

With Koji's help, I measured the length of the Mode Cleaner.

The new modulation frequencies (as quoted on the Marconi front panels) are: 

165.980580 MHz

 33.196116 MHz

132.784464 MHz

199.176696 MHz

The Frequency Counter readback is 165980584.101 Hz (a 4Hz difference).  All of the Marconi's front-panel frequencies read ###.##### MHz Ext, and the Frequency standard has it's "locked" light illuminated, and the 1pps input light blinking, so I think everything is still nicely locked to the frequency standard, and the frequency standard is locked to the GPS.

While changing the marconi's, I accidentally touched the MC's 29.5 MHz marconi.  It is set back to the nominal value (according to Kiwamu's rack photos) of 29.485MHz.  But the phase might be sketchy, although hopefully this doesn't matter since we don't do a double demodulation with it.

I also ran the scripts in the wiki page: How To/Diagonalize DRMI Length Control to set the DD Phases.

I aligned the beam goes to PMC. It increased the MC Trans from 8.25 to 8.30.

I also aligned the beam goes to RC.
When I touched the FSS box (wrong: this was the VCO driver) that was close to one of the steering mirror, suddenly the RC trans increased.
It is now 9.8. I am afraid that it gets saturated. I could not reproduce the phenomenon. This could be caused by a bad contact?
Note that I didn't see there is any loose optic.

I propose that from now on, we indicate in the elog what frequencies we're referring to. In this case, I guess its the front panel readback and not the frequency counter -- what is the frequency counter readback? And is everything still locked to the 10 MHz from the GPS locked Rubidium clock?

Plus, what FSS Box? The TTFSS servo box? Or the VCO driver? As far as I know, the RC trans PD doesn't go through the FSS boxes, and so its a real change. I guess that a bad contact in the FSS could have made a huge locking offset.

What I meant was the VCO driver, not the FSS box.

As for the frequency, all written numbers were the Marconi displays.
The number on the frequency counter was also recorded, and so will be added to the previous entry shortly... 

I'm working on the AP table. I also opened the auxiliary NPRO shutter. The auxiliary beam is on its path on the AP table and PSL table.

 All is well again in the world of backups.  We are now up to date as of ~midnight last night. 

 Closing the AP table and the NPRO shutter now.

Locking has gone sour.  The CARM to MCL handoff, which is fairly early in the full procedure and usally robust, is failing reliably. 

As soon as the SUS-MC2_MCL gain is reduced, lock is broken.  There appears to be an instability around 10Hz.  Not sure if it's related.

I'm working on the AP table. I also opened the auxiliary NPRO shutter. The auxiliary beam is on its path on the AP table and PSL table.

Last night something happened on the beat between the PSL beam and the auxiliary NPRO beam, that spoiled the quality of the beating I had before. As a result the PLL has become unable to lock the two lasers.

The amplitude of the beat at the spectrum analyzer has gone down to -40 dBm from -10 that it was earlier. The frequency has also become more unstable so that now it can be seen writhing within tens of KHz.

Meanwhile the power of the single beams at the PLL photodiode hasn't changed, suggesting that the alignment of the two beam didn't change much.

Changes in the efficiency of the beating between the two beams are not unusual. Although that typically affects only the amplitude of the beat and wouldn't explain why also its frequency has become unstable. Tuning the alignment of the PLL optics usually brings the amplitude back, but it was uneffective today.

It looks like something changed in either one of the two beams. In particular the frequency of one of the two lasers has become less stable.

Another strange thing that I've been observing is that the amplitude of the beat goes down (several dBm) as the beat frequency is pushed below 50 MHz. Under 10 MHz it even gets to about -60 dBm.

I noticed the change yesterday evening at about 6pm, while I was taking measurements of the PLL open loop tranfer function and everything was fine. I don't know whether it is just a coincidence or it is somehow related to this, but Jenne and Sanjit had then just rebooted the frame builder.

 I confirm what I said earlier. The amplitude of the beat is -10 dBm at 300MHz. It goes down at lower frequencies. In particular it gets to-60 dBm below 20 MHz. For some strange reason that I couldn't explain the beating efficiency has become poorer at low frequencies.

 Backup Fail.  At least this time however, it threw the appropriate error code, and sent me an email saying that it was unhappy.  Alan said he was going to check in with Stuart regarding the confusion with the ssh-agent.  (The other day, when I did a ps -ef | grep agent, there were ~5 ssh-agents running, which could have been then cause of the unsuccessful backups without telling me that they failed.  The main symptom is that when I first restart all of the ssh-agent stuff, according to the directions in the Restart fb40m Procedures, I can do a test ssh over to ldas-cit, to see what frames are there.  If I log out of the frame builder and log back in, then I can no longer ssh to ldas-cit without a password.  This shouldn't happen....the ssh-agent is supposed to authenticate the connection so no passwords are necessary.) 

I'm going to restart the backup script again, and we'll see how it goes over the long weekend. 

Just felt a big "kerplunk" type ground-shaking, presumably from all the antics next door.  MC2's watchdog tripped as a result.  The watchdog has been reenabled.

 Five day minute trend.  FAST_F doesn't appear to have gone crazy.

 Whatever the locking problem was, the power of magical thinking has forced it to retreat for now.  The IFO is currently locked, having completed the full up script.  One more thing for which to be thankful.

 NPRO shutter closed

but the increase in both the RCtrans and the RCrefl is consistent with my theory that the power going to the RC has increased ; its not just an increase in the visibility.

We should scan the AOM/VCO to make sure the frequency is matched to the resonance to within 0.5 dB.

I checked C1:PSL-FSS_VCODETPWR. The attached is the 4 months trend of the FSS RCTRANS / RFPDDC(=FSS REFL) / VCODETPWR / VCOMODLEVEL.

Although VCO modulation level setting was mostly constnt, VCODETPWR, which presumably represents the RF level, changes time by time.
It coincides with the recent reduction of the RCTRANS/RFPDDC. Actually, my touch restored the VCO to the previous more stable state.
One can see that this is not only a single occation, but it happened before too. (In the middle of Aug.)

This could be explained by the bad contact of some cable or connector.

Nevertheless we need more careful investigation:

1. Understand what VCODETPWR is exactly.
2. Investigate relationship between VCOMODLEVEL / VCODETPWR / AOM deflection efficiency / RCTRANSPD
3. Confirm the frequency matching between the VCO and AOM.

Problem found. Inspecting with Koji we found that there was a broken SMA-to-BNC connector in the BNC cable from the photodiode.

I measured the open loop gain of the PLL in the AbsL experiment.

I repeated the measurement twice: one with gain knob on the universal PDH box g=3.0; the second measurement with g=6.0

The UGF were 60 KHz and 100 KHz, respectively.

That means that one turn of the knob equals to about +10 dB.

I closed the shutter of the NPRO for the night.

Now I am studying about the behavior of the Q-factor in the resonant circuit because the Q-factor of the circuit directly determine the performance as the EOM driver.

Here I summarize the fundamental which explains why Q-factor is important.

 --------------------------------------

The EOM driver circuit can be approximately described as shown in figure below

Z represents the impedance of a resonant circuit.

In an ideal case, the transformer just raise the voltage level n-times larger.  Rin is the output impedance of the signal source and usually has 50[Ohm].

The transformer also makes the impedance Z 1/n^2 smaller. Therefore this configuration gives a following relation between Vin and Vout.

 Where G is the gain for the voltage. And G goes to a maximum value when Rin=Z/n². This relation is shown clearly in the following plot.

 Note that I put Rin=50 [Ohm] for calculating the plot.

Under the condition  Rin=Z/n²( generally referred as impedance matching ), the maximum gain can be expressed as;

It means that larger Z makes more efficient gain. In our case, interested Z is considered as the impedance at a resonance.

So what we should do is making a resonant circuit which has a higher impedance at the resonance (e.g. high Q-resonant circuit).

The key point of the story is:
"The recipe to exploit maximum benefit from a resonant EOM"
- Make a resonant EOM circuit. Measure the impedance Z at the resonance.
- This Z determines the optimum turn ratio n of the step-up transformer.
  (n² = Z/Rin where Rin is 50Ohm in our case.)
- This n gives the maximum gain G_max (= n/2) that can be obtained with the step up transformer.
  And, the impedance matching is also satisfied in this condition.

OK: The larger Z, the better. The higher Q, the Z larger, thus the better.
(Although the relationship between Z and Q were not described in the original post.)

So, how can we make the Q higher? What is the recipe for the resonant circuit?
=> Choose the components with smaller loss (resistance). The details will be provided by Kiwamu soon??? 

When I was young (3 months ago), I thought...

• Hey! Let's increase the Q of an EOM! It will increase the modulation!
• Hey! Let's use the step-up transformer with n as high as possible! It will increase the modulation!
• Hey! Take the impedance matching! It will increase the modulation!

I was just too thoughtless. In reality, they are closely related each other.

A high Q resonant circuit has a high residual resistance at the resonant frequency. As far as the impedance is higher than the equivalent output impedance of the driving circuit (i.e. Z>Rin n²), we get the benefit of increasing the turn ratio of the transformer. In other words, "the performance of the resonant EOM is limited by the turn ratio of the transformer." (give us more turns!)

OK. So can we increase the turn ratio infinitely? No. Once Rin n² gets larger than Z, you no longer get the benefit of the impedance transforming. The output impedance of the signal source yields too much voltage drop.

There is an optimum point for n. That is the above recipe. 

So, a low Q resonant EOM has a destiny to be useless. But high Q EOM still needs to be optimized. As far as we use a transformer with a low turn ratio, it only shows ordinary performance.

 Plots don't really make sense. The second one is inherently unstable - and what's g?

I stopped by the 40m for some reason and found that the MC trans was 7.5.
This was caused by an oscillation of FSS, which seemed to be started by itself.

The oscillation stopped by reducing the FSS total gain to +9dB (from +11dB).
This is not a permanent fix (i.e. autolocker will restore the gain).
If it seems necessary to reduce the FSS gain always, we change the MC autolocker script.

When Alberto was parting the Red Sea this morning, and turning it green, he noticed that the wireless had gone sketchy.

When I checked it out, the ethernet light was definitely blinking, indicating that it was getting signal.  So this was not the usual case of bad cable/connector which is a known problem for our wireless (one of these days we should probably relay that ethernet cable....but not today).  After power cycling and replugging the ethernet cable, the light for the 2.4GHz wireless was blinking, but the 5GHz wasn't.  Since the wireless still wasn't working, I checked the advanced configuration settings, as described by Yoichi's wiki page:  40m Network Page

The settings had the 5GHz disabled, while Yoichi's screenshots of his settings showed it enabled.  Immediately after enabling the 5GHz, I was able to use the laptop at Alberto's length measurement setup to get online.  I don't know how the 5GHz got disabled, unless that happened during the power cycle (which I doubt, since no other settings were lost), but it's all better now.

I found the FEsync light on the OMC GDS screen red.  I power cycled C1OMC, and restarted the front end code and the tpman.  I assume this is a remnant of the bootfest of the morning/weekend, and the omc just got forgotten earlier today.

Came back from dinner to find the Mach Zehnder unlocked.  The poor IFO is kind of having a crappy day (computers, MZ, and I think the Mode Cleaner alignment might be bad too).

The Ranger was left in a place where it could be bumped during next week's activities (near the crawl-space to access the inside of the "L" of the IFO on the Yarm).  It has been moved a meter or so to a safer place.

Also, so that Steve can replace the battery in the SR560 that is used for the Ranger, I swapped it out with one of the ones which already has a new, charged battery.  All of the settings are identical.  For posterity, I took a pic of the front panel before unplugging the old SR560.

[Jenne Koji]

 We aligned the full IFO, and centered all of the oplevs and the IP_POS and IP_ANG QPDs.  During alignment of the oplevs, the oplev servos were disabled.

Koji updated all of the screenshots of 10 suspension screens.  I took a screenshot (attached) of the oplev screen and the QPD screen, since they don't have snapshot buttons.

We ran into some trouble while aligning the IFO.  We tried running the regular alignment scripts from the IFO_CONFIGURE screen, but the scripts kept failing, and reporting "Data Receiving Error".  We ended up aligning everything by hand, and then did some investigating of the c1lsc problem.  With our hand alignment we got TRX to a little above 1, and TRY to almost .9 . SPOB got to ~1200 in PRM mode, and REFL166Q got high while in DRM (I don't remember the number). We also saw a momentary lock of the full initerferometer:   On the camera view we saw that Yarm locked by itself momentarily, and at that same time TRX was above 0.5 - so both arms were locked simultaneously.   We accepted this alignment as "good", and aligned all of the oplevs and  QPDs.

It seems that C1LSC's front end code runs fine, and that it sees the RFM network, and the RFM sees it, but when we start running the front end code, the ethernet connection goes away.  That is, we can ping or ssh c1lsc, but once the front end code starts, those functions no longer work.  During these investigations, We once pushed the physical reset button on c1lsc, and once keyed the whole crate.  We also did a couple rounds of hitting the reset button on the DAQ_RFMnetwork screen.

 A "Data Receiving Error" usually indicates a problem with the framebuilder/testpoint manager, rather than the front-end in question.  I'd bet there's a DTT somewhere that's gone rogue.

We restarted daqd and it did restored the problem
http://lhocds.ligo-wa.caltech.edu:8000/40m/Computer_Restart_Procedures#fb40m
Then restart the 'daqd' process:'telnet fb40m 8087', type "shutdown" at the prompt. The framebuilder will restart itself in ~20s.

It did not related to the problem, but we also cleaned the processes related to dtt, dataviewer by pkill

After that the alignment scripts started to work again. As a result, we got some misalignment of the oplevs.
I am going to come on Sunday
- Align the optics
- Align the oplevs again
- Take snapshots for the suspensions
- Align the IP_POS, IP_ANG
- Align the aux laser for the absolute length
- Align PSL table QPDs, and MCT QPD

There's a large broadband increase in the MC_F spectrum.  I'm not totally sure it's real--it could be some weird bit-swapping thing.  I've tried soft reboots of c1susvme2 and c1iovme, which haven't helped.  In any case, it seems like this is preventing any locking success today.  Last night it was fine.

NOTE: HEPA is on at its full.

[[[OK]]] Align the suspended optics (by Rob)
[[[OK]]] Align the oplevs again
[[[OK]]] Take snapshots for the suspensions/QPDs/IO QPDs/PZT strain gauges
[[[OK]]] Align the IP_POS, IP_ANG
[[[OK]]] Align the PSL table QPDs, the MC WFS QPDs, and the MCT QPD
[[[OK]]] Align the aux laser for the absolute length 

Alignment of the aux laser

o Go to only ITMX mode:
Save the alignment of the mirrors. Activate X-arm mode. Misalign ITMY and ETMX.

o Inject the aux beam:
Open the shutter of the aux NPRO. Turn the injection flipper on.

o Look at the faraday output:
There are several spots but only one was the right one. Confirm the alignment to the thorlabs PD. Connect the oscilloscope to the PD out with a 50Ohm termination.
Thanks to the Alberto's adjustment, the beat was already there at around 10MHz. After the PD adjustment, the DC was about 600mV, the beat amplitude was about 50mVpp.

o Adjust the aux beam alignment:
Adjust the alignment of the aux beam by the steering mirrors before the farady isolator. These only change the alignment of the aux beam independently from the IFO beam.
After the alignment, the beat amplitude of 100mVpp was obtained.

o Closing
Close the shutter of the NPRO. Turn off the flipper mirror. Restore the full alignment of the IFO.

 Rebooting c1iovme (by keying off the crate, waiting 30 seconds, and then keying it back on and restarting) has resolved this.  The frequency noise is back to the 'usual' trace.

Steve, Jenne, Koji

The PSL was blocked by the shutter and the manual block.
We started venting at 9:30

09:30  25 torr
10:30 180 torr
11:00 230 torr
12:00 380 torr
13:00 520 torr
14:30 680 torr - Finish. It is already over pressured.

[Koji, Jenne, Alberto, Steve, Bob]

ETMX has been drag wiped. 

Around 2:45pm, after the main IFO volume had come up to atmospheric pressure, we removed both doors to the ETMX chamber.  Regular procedures (wiping of O-rings with a dry, lint-free cloth, covering them with the light O-ring covers, etc.) were followed.  Koji took several photos of the optic, and the rest of the ETMX chamber before anything was touched. These will be posted to the 40m Picasa page.  Steve and Koji then deionized the optic.

Koji removed the bottom front earthquake stop, and clamped the optic with the remaining earthquake stops.

The clean syringes were prepared: These are all glass and metal (nothing else) medical syringes.  The size used was 100microliters.  Earlier today, we had prepared our solvents in small little beakers which had been baked over the weekend.  Brand new glass bottles of Acetone and Isopropyl Alcohol were opened, and poured into the small beakers.  To make sure we have enough, we have 3 ~10ml beakers of each Acetone and Isopropyl.

We started with Acetone.  The syringe was filled completely with acetone, then squirted onto a kimwipe.  This was repeated ~twice, to ensure the syringe was well rinsed.  Then the syringe was filled a little past the 100 microliter mark.  Koji held a piece of lens cleaning paper to ETMX and used an allen wrench underneath the optic to help guide the paper, and keep it near the optic (of course, the only thing in actual contact with the optic was the lens paper).  In one smooth shot, the plunger of the syringe was pressed all the way down.   (This is a bit tricky, especially when the syringe is totally full.  You have to squeeze it so the plunger moves fairly quickly down the barrel of the syringe to get a good arc of liquid.  The goal is to shoot all of the solvent to the same place on the lens paper, so that it makes a little circle of wetness on the paper which covers the coated part of the optic.  The amount of solvent used should be balanced between having too little, so that the paper is dry by the time it has been wiped all the way down, and too much such that there is still a residue of liquid on the optic after the paper has been removed.)  The target was to hit the optic just above the center mark (the oplev was on, so I went for just above the red oplev dot).  Immediately after applying the liquid onto the paper, Koji slowly and smoothly pulled down on the lens paper until it came off of the bottom of the optic.  The acetone was repeated, for a total of 2 acetone wipes.  Because acetone evaporates very quickly, more acetone is used than isopropyl.  The optimal amount turned out to be ~115 microliters of acetone.  It is hard to say exactly how much I had on the second wipe, because the syringe is not marked past 100 microliters.  On the first wipe, with about 105 microliters, the lens paper was too dry at the bottom of the optic.

We then switched to Isopropyl.  A new syringe was used, and again we rinsed it by filling it completely with isopropyl, and emptying it onto a kimwipe.  This was repeated at least twice.  We followed the same procedure for applying liquid to the optic and wiping the optic with the lens paper.  On the first try with isopropyl, we used 100 microliters, since that was the preferred amount for acetone.  Since isopropyl evaporates much slower than acetone, this was determined to be too much liquid.  On the second isopropyl wipe, I filled the syringe to 50 microliters, which was just about perfect.  The isopropyl wiping was done a total of 2 times.

After wiping, we replaced the front bottom earthquake stop, and released the optic from the other earthquake stops' clamping.  The OSEM values were checked against the values from the screenshots taken yesterday afternoon, and were found to be consistent.  Koji took more photos, all of which will be placed on the 40m Picasa page.

We visually inspected the optic, and we couldn't see anything on the optical surface of the mirror.  Koji said that he saw a few particulates on some horizontal surfaces in the chamber.  Since the optic seemed (at least to the level of human vision without a strong, focused light) to be free of particulates on the optical surface to start with, the suspense will have to remain until we button down, pump down, and try to lock the IFO to determine our new finesse, to see if the wiping helped any substantial amount. 

We replaced the regular, heavy door on the inner side of the ETMX chamber (the side closer to the CES building), and put only a light door on the outer side of the chamber (the side closer to the regular walkway down the arm).  We will look at the spectra of the OSEMS tomorrow, to confirm that none of the magnets are stuck.

We commence at ~9am tomorrow with ETMY.

LESSONS LEARNED:

*  The LED lights are awesome.  It's easy to use several lights to get lots of brightness (more than we've had in the past), and the chamber doesn't get hot.

*  We should get larger syringes for the acetone for the large optics.  It's challenging to smoothly operate the plunger of the syringe while it's so far out.  We should get 200 microliter syringes, so that for the acetone we only fill them about half way.  It was noticeably easier to apply the isopropyl when the syringe only had 50 microliters.

* It may be helpful to have a strong, focused optical light to inspect the surface of the mirror.  Rana says that Garilynn might have such an optical fiber light that we could borrow.

I have made some measurements of the R value for some coatings we are interested in.  The plots have statistical error bars from repeated measurements, but I would suspect that these do not dominate the noise, and would guess these should be trusted to plus or minus 5% or so.  They still should give some indication of how useful these coatings will be for the green light.  I plan to measure for the ITM as soon as possible, but with the venting and finals this may not be until late this week.

EDIT (12/9/09): I fixed the label on the y axis of the plots, and changed them to png format.

In this night, I checked the free swinging spectra of ETMX to make sure nothing wrong with ETMX by the wiping.

Compared with the past (Aug.6 2008), the spectra of ETMX doesn't show significant change.

Successfully the wiping activity didn't change its configuration so much and didn't bring bad situations.

(bad situation means for example, the suspended components hit some others).

 The spectra of ETMX by DTT are attached. Also you can see the past spectra in Yoichi's entry.

Yoichi's data was taken during the air-pressure condition, so it's good for comparing.

Actually I compared those data by my eyes, because I could not get the past raw data somehow.

The resonant frequencies and their typical height changed a little bit, but I think those are not significant.

NOTE: In the figure, pitch and yaw modes (~0.57Hz and ~0.58Hz) look like having a smaller Q-factor than the past.

Opening of ETMY has been put on hold to deal with the computer situation.  Currently all front end computers are down.  The DAQ AWGs are flashing green, but everything else is red (fb40m is also green).  Anyhow, we'll deal with this, and open ETMY as soon as we can.

The computers take priority because we need them to tell us how the optics are doing while we're in the chambers, fitzing around.  We need to be sure we're not overly kicking up the suspensions. 

Jenne, Kiwamu, Alberto, Steve, Bob, Koji

We wiped ETMY after recovery of the computer system. We take the lunch and resume at 14:00 for ITMX.
Detailed reports will follow.

Jenne, Kiwamu, Koji, Alberto, Steve, Bob

ITMX was wiped without having to move it. 
After 'practice' this morning on ETMY, Kiwamu and I successfully wiped ITMX by leaning into the chamber to get at the front face. 

Most notable (other than the not moving it) was that inspection with the fiber light before touching showed many very small particles on the coated part of the optic (this is versus ETMY, where we saw very few, but larger particles).  The after-wiping fiber light inspection showed many, many fewer particles on the optical surface.  I have high hopes for lower optical loss here!

The free swinging spectra of ETMY and ITMX were taken after today's wiping, in order to check the test masses.

These data were taken under the atmospheric pressure condition, as well as the spectra of ETMX taken yesterday.

Compared with the past (see Yoichi's  good summary in Aug.7 2008), there are no significant difference.

There are nothing wrong with the ETMY and ITMX successfully.

 --

By the way I found a trend, which can be seen in all of the data taken today and yesterday.

The resonances of pitch and yaw around 0.5Hz look like being damped, because their height from the floor become lower than the past.

I don't know what goes on, but it is interesting because you can see the trend in all of the data.