40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 110 of 341  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  2966   Fri May 21 11:56:34 2010 AlbertoUpdate40m Upgrading40mUpgrade Field Power and RF Power Spectrum at the ports. 38m/38.55m arm length issue.

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:

RFPower_locked_38m.png

RFPower_unlocked_38m.png

FieldPower_locked_38m.png

FieldPower_unlocked_38m.png

 

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:

RFPower_3855m.png

 FieldPower_3855m.png

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.

40mUpgrade_distanceFromResonance_38m.png

 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.

  2967   Fri May 21 14:31:46 2010 josephb,alexUpdateCDSNew computer and IO chassis working in 1X4

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. 

  2968   Fri May 21 16:24:11 2010 KojiUpdateLSC40mUpgrade Field Power and RF Power Spectrum at the ports. 38m/38.55m arm length issue.

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.

  2971   Fri May 21 16:41:38 2010 Alberto, JoUpdateComputersIt's a boy!

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.

  2973   Mon May 24 10:03:14 2010 ranaUpdateLSC40mUpgrade Field Power and RF Power Spectrum at the ports. 38m/38.55m arm length issue.

 

 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.

  2974   Mon May 24 11:32:05 2010 ranaUpdateLSC40mUpgrade Field Power and RF Power Spectrum at the ports. 38m/38.55m arm length issue.

Quote:

 

 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:

reflRFpowerVsArmLength.png

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.

  2975   Mon May 24 14:28:35 2010 kiwamuUpdateElectronicsbad power supply of a vme rack

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.

  2976   Mon May 24 16:34:22 2010 KevinUpdatePSLND Filters for 2W Beam Profile

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.

  2977   Tue May 25 00:10:24 2010 ZachUpdateIOOIMC table leveled again

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.

 

  2978   Tue May 25 07:22:59 2010 kiwamuUpdateElectronicsbad power supply of a vme rack

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.

  2979   Tue May 25 07:58:23 2010 kiwamuUpdateelogelog down

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.

http://lhocds.ligo-wa.caltech.edu:8000/40m/How_To/Restart_the_elog

  2981   Tue May 25 10:06:09 2010 kiwamuUpdateElectronicsbad power supply of a vme rack

 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.

  2983   Tue May 25 16:40:27 2010 josephb, alexUpdateCDSFinally tracked down why new models wouldn't talk to each other

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.

  2984   Tue May 25 17:04:37 2010 KevinUpdate Beam Profile After Mode Cleaner

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

w0 = (1.51 ± 0.01) mm

For the vertical profile:

reduced chi^2 = 0.94

z0 = (673 ± 28) mm

w0 = (1.59 ± 0.01) mm

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.

Attachment 1: mcfit.png
mcfit.png
Attachment 2: mcerrors.png
mcerrors.png
  2985   Tue May 25 17:09:22 2010 KojiUpdateIOOBeam Profile After Mode Cleaner

Very nice as usual. Can you add the curve to show the ideal mode of the MC on the profile plot?

Quote:

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

w0 = (1.51 ± 0.01) mm

For the vertical profile:

reduced chi^2 = 0.94

z0 = (673 ± 28) mm

w0 = (1.59 ± 0.01) mm

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.

 

  2986   Tue May 25 17:22:56 2010 KevinUpdateIOOBeam Profile After Mode Cleaner

Quote:

Very nice as usual. Can you add the curve to show the ideal mode of the MC on the profile plot?

Quote:

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

w0 = (1.51 ± 0.01) mm

For the vertical profile:

reduced chi^2 = 0.94

z0 = (673 ± 28) mm

w0 = (1.59 ± 0.01) mm

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.

Here is the plot with the ideal mode of the mode cleaner shown in brown. The ideal mode was plotted with the radius of curvature of 18.4. 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.

Attachment 1: mcfit.png
mcfit.png
  2987   Wed May 26 00:50:16 2010 JenneUpdateIOOMirrors moved in prep for round 2 of MC mode measuring

[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. 

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.

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.

  2988   Wed May 26 04:14:21 2010 kiwamuUpdateGreen Lockinglocked

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.

Attachment 1: OLTF_endPDH.png
OLTF_endPDH.png
  2989   Wed May 26 10:58:29 2010 josephbUpdateCDSNew RCG checkout for use with all machines plus some issues

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
exit 1
fi

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.

  2990   Wed May 26 12:59:26 2010 josephbUpdateCDSCreated sus, sup, scx, spx models

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.

  2991   Wed May 26 14:28:01 2010 KojiUpdateIOOMirrors moved in prep for round 2 of MC mode measuring

That's true. But I thought that you measured the mode after those optics and the effect of them is already included.

So:

  • We need to model the transmissive optics in order to understand the measured mode which is different from the MC mode slightly.
  • We just can calculate the modes based on the measurement in order to figure out the realistic positions of the MMT1 and MMT2.

Quote:

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.

 

  2992   Wed May 26 14:38:02 2010 KojiUpdateGreen Lockinglocked

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)

Quote:

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.

 

  2993   Wed May 26 15:34:00 2010 JenneUpdateIOOMirrors moved in prep for round 2 of MC mode measuring

Quote:

That's true. But I thought that you measured the mode after those optics and the effect of them is already included.

So:

  • We need to model the transmissive optics in order to understand the measured mode which is different from the MC mode slightly.
  • We just can calculate the modes based on the measurement in order to figure out the realistic positions of the MMT1 and MMT2.

Quote:

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.

  2994   Wed May 26 17:10:09 2010 AlbertoUpdate40m UpgradingRF Generation box

This is how the RF generation box might soon look like:

Visio-frequencyGenerationBox_wiringSchematic.png

A dedicated wiki page shows the state of the work:

http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_09/RF_System/frequency_generation_box#preview

  2997   Thu May 27 02:22:24 2010 kiwamuUpdateGreen Lockingmore details

 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.

stimes.png

 

 

-- 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.

spectrum.png

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.

 

-- flashing

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.

ETMX_small.png

 

  2998   Thu May 27 08:22:57 2010 AidanUpdateComputersRestarted the elog this morning
  2999   Thu May 27 09:43:50 2010 ranaUpdateGreen Lockingmore details

Quote:

 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.

  3001   Thu May 27 12:52:02 2010 AlbertoUpdate40m UpgradingArm lengths


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.

  3002   Thu May 27 23:59:54 2010 ranaUpdatePEMNew Foam Box installed

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.

Attachment 1: Untitled.png
Untitled.png
  3003   Fri May 28 00:40:53 2010 ranaUpdatePEMDAQ down

 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.

  3005   Fri May 28 10:44:47 2010 josephbUpdatePEMDAQ down

Quote:

 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?

  3006   Fri May 28 11:26:35 2010 JenneUpdatePEMNew Foam Box installed

Quote:

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...

  3007   Fri May 28 11:35:33 2010 josephbUpdateCDSTaking a step backwards to get stuff running

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

Attachment 1: working_lsc_lsp.png
working_lsc_lsp.png
  3008   Fri May 28 13:17:05 2010 josephbUpdateCDSFixed problem with channel access on c1iscex

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 131.215.113.255
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.

  3009   Fri May 28 13:32:01 2010 alberto, kiwamuUpdateVACvacuum work

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.

 

P.S.

Kevin suceeded in locking it !!

  3010   Fri May 28 13:51:51 2010 JenneUpdateVACvacuum work

Quote:

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.

 

 

 Hey guys,

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.

New distances:

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

  3011   Fri May 28 14:24:30 2010 JenneUpdateVACvacuum work

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.....

  3012   Fri May 28 21:32:32 2010 AlbertoUpdate40m UpgradingMC alignment

[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.

  3013   Fri May 28 23:21:52 2010 KojiUpdateIOOMC alignment

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.

Quote:

[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.

 

  3014   Sun May 30 13:26:07 2010 rana, kiwamuUpdatePSLnew HIGH-LOW value for PMC_TRANS

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.

grecord(ai,"C1:PSL-PMC_PMCTRANSPD")
{

  field(LOW,"0.98")
  field(LOLO,"0.93")
  field(HIGH,"1.15")
  field(HIHI,"1.3")

}

- - - -

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.

  3018   Sun May 30 22:18:49 2010 ranaUpdatePEMGranite slab w/ lead balls is so far a flop

The seismometers showed an increased noise in the Y-direction when put on top of the granite slab. By tapping the slab, you can tell that its really a mechanical resonance of the lead balls + granite system at ~15-20 Hz.

I tried new balls, flipping the slab upside down, and sitting on the slab for awhile. None of this changed the qualitative behavior, although each of the actions changed the resonance frequencies by several Hz.

I have removed the granite/balls and put the seismometers back on the linoleum floor. The excess noise is gone. I have put the new big box back on top of them and we'll see how the data looks overnight.

 

I expect that we should remove the linoleum in a wider area and put the seismometers directly on the floor.

  3019   Mon May 31 00:10:18 2010 kiwamuUpdateIOOMC alignment

  [Alberto, Kiwamu]

The MC alignment is getting better by steering the axis of the incident beam into the MC.

We found the beam spot on MC1 and MC3 were quite off-centered in the beginning of today's work. It had the coil gain ratio of 0.6:1.4 after running the A2L script.

In order to let the beam hit the center of the MC1 and MC3, we steered the bottom mirror attached on the periscope on the PSL table to the yaw direction.

And then we got better numbers for the coil gain ratio (see the numbers listed at the bottom).

For the pitch direction, there still are some rooms to improve because we didn't do anything with the pitch. It is going to be improved tomorrow or later.

 

Here are the amounts of off-centering on MC1 and MC3 after steering the axis. 

 C1:SUS- MC1_ULPIT_GAIN =  0.900445

C1:SUS-MC1_ULYAW_GAIN =  0.981212

C1:SUS-MC3_ULPIT_GAIN =  0.86398

C1:SUS-MC3_ULYAW_GAIN =   1.03221

  3020   Mon May 31 03:38:48 2010 KojiUpdateIOOMC alignment

Remember that you only can introduce the axis translations from the PSL table.
It is quite difficult to adjust the axis rotation.

The calibration factor from A2L results to the beam position is dx = (A2L_result - 1) *10.8mm

If I believer the result below, the spot positions on the mirrors are

MC1 Pitch      -1.1mm
MC1 Yaw        -0.20mm
MC3 Pitch      -1.5mm
MC3 Yaw        +0.35mm

This means that the beam is 1.3mm too high and 0.28mm too much in north

This corresponds to tilting SM2 by
0.33mrad in pitch (23deg in CW)
and
0.10mrad in yaw (7deg in CW).

Quote:

C1:SUS-MC1_ULPIT_GAIN =  0.900445
C1:SUS-MC1_ULYAW_GAIN =  0.981212
C1:SUS-MC3_ULPIT_GAIN =  0.86398

C1:SUS-MC3_ULYAW_GAIN =  1.03221  

 

Attachment 1: MC_spot_centering.png
MC_spot_centering.png
  3021   Mon May 31 17:47:34 2010 kiwamuUpdateIOOtoday's plan : MC alignment

[Alberto, Kiwamu]

0. have a coffee and then dress up the clean coat.

1. level the MC table

2. lock and align MC 

3. run A2L script to see how much off-centering of the spots

4. steer the periscope mirror <--- We are here

5. move the pick off mirror which is used for monitoring of MCT CCD

6. check the leveling and move some weights if it's necessary

7. shut down

  3022   Mon May 31 22:52:57 2010 ranaUpdatePEMGranite slab w/ lead balls is so far a flop

This plot shows the noise with the box on, but no granite. We're still pretty far off from the Guralp data sheet.

Untitled.png

I implemented software rotation in the huddle subtraction as Valera suggested and it works much better. The two plots below show the before and after. So far this is just 2 deg. of rotation around the z-axis. I'm assuming that aligning the seismometers vertically via bubble level is good enough for the z-axis, but I haven't calibrated the bubble yet.

huddlez.pnghuddlez.png

The residual slope is now suspiciously smooth. I somehow suspect that our readout electronics can still be responsible. We need to hook up a 9V battery to the input terminals to check it out. Its a little steeper than 1/f and I thought that we had exonerated the Guralp breakout box in the past, but now I'm not so sure. I'll let Jenne comment on that.

I also noticed that we have not yet divided by sqrt(2) to account for the fact that we are subtracting 2 seismometers. In principle, an unbiased estimate of the single seismometer noise will be lower by sqrt(2) than the green curve.

  3024   Tue Jun 1 11:47:14 2010 steveUpdatePEMlead balls on concrete

Quote:

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.

 The tiles were cut out in 1.5" ID circle to insure that the 7/16" OD lead balls would not touch the tiles on Wednesday, May 26, 2010

Granite surface plate specifications: grade B, 18" x 24" x 3" , 139 lbs

These balls and granite plate were removed by  Rana in entry log #3018 at 5-31-2010

Attachment 1: P1060269.JPG
P1060269.JPG
  3025   Tue Jun 1 15:51:42 2010 steveUpdatePEMfoam box for good thermal stability

This box was made  to provide good thermal stability for seismometer calibration. There is an inner solid shell of 0.064" Al box that is covered by 2" insulation

inside and outside. The polystyrene foam is "CertiFoam 25 SE " from McMasterCarr #9255K3.

Attachment 1: albx2.PDF
albx2.PDF
  3026   Tue Jun 1 16:29:51 2010 AlbertoUpdateIOOMC transmitted beam aligned to the Faraday; next things to do

We moved the MC-trans pick-off mirror (= the beam splitter between the input of the Faraday and the steering mirror located right after MC3). Now the beam goes through the Farady without getting clipped.

This is the list of the things that have to be done next:

  1. take pictures of the beam spot just before and after the Faraday
  2. lock down to the table the MCTrans pickoff mirror with its screws
  3. measure the beam profile after the first MC telescope mirror (MMT1)
  4. remove Jenne's extra steering mirror from the MC table
  5. re-level the MC table with the bubble level
  6. align the MC-trans beam to its photodiode on the PSL table
  7. align the REFL beam to its photodiode on the AP table
  3027   Tue Jun 1 18:39:59 2010 NancyUpdate Lead spheres for the seismographs

 

the lead spheres that were placed below the granite slab have been flattened by hammering to have lesser degree of wobbling of the slab.

the height of each piece, and the flatness of their surfaces was checked by placing another slab over them and checking by the spirit level.

P6010170.JPG

P6010166.JPG

P6010164.JPG

 

  3028   Tue Jun 1 20:40:03 2010 KojiUpdatePSLnew HIGH-LOW value for PMC_TRANS

The alarm had kept crying. I reduced the LOW to be 0.90 and the LOLO to be 0.85 both in psl.db and with ezcawrite.

Quote:

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.

grecord(ai,"C1:PSL-PMC_PMCTRANSPD")
{

  field(LOW,"0.98")
  field(LOLO,"0.93")
  field(HIGH,"1.15")
  field(HIHI,"1.3")

}

- - - -

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.

 

ELOG V3.1.3-