40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 312 of 344  Not logged in ELOG logo
ID Date Author Type Category Subject
  1623   Sun May 24 11:24:08 2009 robUpdateComputerselog restarted

I just restarted the elog.  It was crashed for unknown reasons.  The restarting instructions are in the wiki.

  1622   Fri May 22 17:05:24 2009 rob, peteUpdateComputershard reboot of vertex suspension controllers

we did a hard reboot of c1susvme1, c1susvme2, c1sosvme, and c1susaux.  We are hoping this will fix some of the weird suspension issues we've been having (MC3 side coil, ITMX alignment).

  1621   Fri May 22 17:03:14 2009 rob, steveUpdatePSLMOPA takes a holiday

The MOPA is taking the long weekend off.

Steve went out to wipe off the condensation inside the MOPA and found beads of water inside the NPRO box, perilously close to the PCB board.  He then measured the water temperature at the chiller head, which is 6C.  We decided to "reboot" the MOPA/chiller combo, on the off chance that would get things synced up.  Upon turning off the MOPA, the neslab chiller display immediately started displaying the correct temperature--about 6C.  The 22C number must come from the MOPA controller.  We thus tentatively narrowed down the possible space of problems to: broken MOPA controller and/or clog in the cooling line going to the power amplifier.  We decided to leave the MOPA off for the weekend, and start plumbing on Tuesday.  It is of course possible that the controller is the problem, but we think leaving the laser off over the weekend is the best course of action.

 

 

  1620   Fri May 22 01:27:14 2009 peteUpdateSUS200 days of MC3 side

Looks like something went nuts in late April.  We have yet to try a hard reboot.

Attachment 1: mc3_side_200days.png
mc3_side_200days.png
  1619   Fri May 22 00:43:24 2009 robConfigurationComputer Scripts / ProgramsIFO configure scripts for XARM and YARM

I edited the configure scripts (those called from the C1IFO_CONFIGURE screen) for restore XARM and YARM.  These used to misalign the ITM of the unused arm, which is totally unnecessary here, as we have both POX and POY.  They also used to turn off the drive to the unused ETM.  I've commented out these lines, so now running the two restores in series will leave a state where both arms can be locked.  This also means that the ITMs will never be deliberately mis-aligned by the restore scripts.

  1618   Thu May 21 18:21:57 2009 ranaSummaryTreasureYoichi's words

Yoichi's final words on what do next with the interferometer (as of 5 PM on May 21, 2009):

  1. Measure laser noise couplings in spring and anti-spring configurations.
  2. Dewhitening filter turn on for the ETMs.
  3. Noisebudget - import from the sites.
  4. Stabilize CM handoff.

My personal sub-comments to these bullets:

  1. For the laser noise I'm not sure that we will be able to understand these if the couplings are mainly from junk light due to accidental HOM resonances.
  2. WE should look into putting a static passive stage of filtering into the ETMs if warranted by the NB.
  3. Because of the sad track record with this, I will start us off this time by importing and modifying the H1/L1 versions.
  4. I guess we can do this by just acquiring on MC2 with the huge CARM offset. It works for the single arm so it should work for offset CARM.
  1617   Thu May 21 18:07:32 2009 ranaUpdatePSLScrew on Needle valve loosened
Alberto and I went in to loosen up the needle valve yesterday around 4:30 PM. The idea was to cut down on
the flow to the NPRO so that the cooling power of the chiller would be used almost entirely on the
amplifier instead of the NPRO block.

The need valve was basically all the way open. The lock nut was screwed in all the way and stuck. By using
pliers and a wrench for the nut, we freed the lock nut. Even so, the screw for the needle valve seemed to
be bad: I think the thread is stripped; it doesn't go down even after several turns. I even tried to squirt
alchohol on it and really press down in the hopes of catching a thread. It may have closed slightly but its
impossible to be sure.

I also increased the NPRO diode current to the max (+0.1 A). This got us a little bit of NPRO power and
I hope some more AMPMON stability. The attached plot shows 4 days of minute trend. If you squint you
might believe that we got some suppression in the HTEMP fluctuations over the last two days.
Attachment 1: Untitled.png
Untitled.png
  1616   Thu May 21 18:05:03 2009 peteUpdateSUSETMX coils look OK

Quote:

I checked the four rear coils on ETMX by exciting XXCOIL_EXC channel in DTT with amplitude 1000@ 500 Hz and observing the oplev PERROR and YERROR channels.  Each coil showed a clear signal in PERROR, about 2e-6 cts.  Anyway, the coils passed this test.

 

 I also made xfer fctns of the 4 piston coils on ETMY and ETMX with OL_PIT.  (I looked at all 4 even though the attached plot only shows three.)  So it looks ike the coils are OK.

Attachment 1: etmx_etmy_coils.pdf
etmx_etmy_coils.pdf
  1615   Thu May 21 12:58:32 2009 robConfigurationALARMPEM count-half disabled

I've disabled the alarm for PEM_count_half, using the mask in the 40m.alhConfig file.  We can't do anything about it, and it's just annoying.

  1614   Wed May 20 16:03:52 2009 steveOmnistructureEnvironmentusing OSEMs to look at seismic activity

Rana suggested using OSEM sensing voltages as guide lines to look seismic activity.

As you see todays drilling and tumping activity was nothing compared to the EQ of mag 5 and 4

Optic level servos are turned back on.

 

What Steve means is that there is some drilling going on in the CES shop to accomodate the new water flume group. We want to

make sure that the mirrors don't move enough to break the magnets. On the dataviewer we should look to make sure that the

sensor channels stay between 0-2 V.     -Rana

 

Attachment 1: eqOSEM5m4.jpg
eqOSEM5m4.jpg
  1613   Wed May 20 10:43:17 2009 steveOmnistructureEnvironmentaccelerometers sensitivity

Quote:

2009 May 18 03:39:36 UTC

Earthquake Details

Magnitude 5.0
Date-Time
  • Monday, May 18, 2009 at 03:39:36 UTC
  • Sunday, May 17, 2009 at 08:39:36 PM at epicenter
Location 33.940°N, 118.338°W
Depth 13.5 km (8.4 miles)
Region GREATER LOS ANGELES AREA, CALIFORNIA
Distances
  • 2 km (1 miles) E (91°) from Lennox, CA
  • 2 km (1 miles) SSE (159°) from Inglewood, CA
  • 3 km (2 miles) NNE (22°) from Hawthorne, CA
  • 7 km (4 miles) ENE (72°) from El Segundo, CA
  • 15 km (10 miles) SSW (213°) from Los Angeles Civic Center, CA
Location Uncertainty horizontal +/- 0.4 km (0.2 miles); depth +/- 0.9 km (0.6 miles)
Parameters Nph=139, Dmin=7 km, Rmss=0.42 sec, Gp= 40°,
M-type=local magnitude (ML), Version=C
Source
Event ID ci10410337

 Wilcoxon 731A seismic accelerometers and Guralp CMG-40T-old seismometer at magnitude 5 and 4 erthquakes

Attachment 1: eq5m4.jpg
eq5m4.jpg
  1612   Wed May 20 09:55:18 2009 steveUpdatePEMoplev servos turned off

All oplevs servos turned off to protect our suspentions from vibration due to drilling and pounding in CES high bay area.

This activity will be done from 10 am till 3 pm today.

 

Meanwhile our IFO-air conditions are turned off for maintenance.

Their performance of 6 months is shown on plot.

Attachment 1: ACpart6m.jpg
ACpart6m.jpg
  1611   Wed May 20 01:53:48 2009 rob, peteUpdateLockingviolin mode filters in drstep_bang

Recently the watch script was having difficulty grabbing a lock for more than a few seconds.  Rob discovered that the violin notch filters which were activated in the script were causing the instability.  We're not sure why yet.  The script seems significantly more stable with that step commented out.

  1610   Wed May 20 01:41:19 2009 peteUpdateVACcryopump probably not it

I found some neat signal analysis software for my mac (http://www.faberacoustical.com/products/), and took a spectrum of the ambient noise coming from the cryopump.  The two main noise peaks from that bad boy were nowhere near 3.7 kHz.

  1609   Tue May 19 16:18:45 2009 steveConfigurationVACIFO pressure is 4.2e-7 Torr with CRYO pump

Quote:
Morning Vacuum condition: IFO is not being pumped, P1 pressure is 1.8 mTorr and rising (see P1 pressure plot of 100 min ).

Overnight the RGA protection software interlock at closed the VM1 valve triggering on CC1 = 1e-5 torr.

This interlock blocked our attempt to hold the IFO operational pressure in the high 1e-5 Torr range with one small
"beer can" turbopump (Varian V70D drag-turbo pumping speed for N2 is ~60 l/s at 75KRPM).

I started CRYO regeneration using TP3. Pressure readout on the P3 gauge. This is after 30 days of CRYO operation.

V5 was closed for 60 sec to see the outgassing rate of the cryopump surfaces. It was good (but I am not going to elog
what 'good' actually means - instead I will write it in my paper logbook to prevent others from learning). I will now'
go start cooling down the cryo pump.

** translated into English by Rana


The Cryo cooled down to ~12K by noon.Photo switch was reset and VC1 was opened at 2pm

The VACMONITOR.adl screen is not working. Someone made some improvement on it last night.
  1608   Tue May 19 16:08:03 2009 ranaSummarySEIEUCLID
From Stuart Aston, I've attached a picture of the EUCLID position sensor:
Attachment 1: Picture_6.png
Picture_6.png
  1607   Tue May 19 15:57:07 2009 steveUpdateIOOMC2 damping restored after EQ

  Earthquake mag 4.0 at Lennox, Ca     trips MC2 watchdogs       http://quake.usgs.gov/recenteqs/Quakes/ci10411545.html

See 40m accelerometers as they see it.

Attachment 1: acc.jpg
acc.jpg
  1606   Tue May 19 15:54:29 2009 JenneUpdatePEMMore Plots for the S5 H1:DARM Wiener Filtering....

Even more plots for the Wiener filtering!

We have a set of spectrograms, which show (in color) the amplitude spectrum, at various times during a one month stretch of time, during S5. Each vertical data-'stripe' is 10min long.

We also have a set of band-limited plots, which take the spectra at each time, and integrate under it, for different frequency bands.

Each set of plots has the following 3 plots:  The raw DARM spectrum, a ratio of residual/raw, and the residuals, normalized to the first one (on which the wiener filter was trained).

The residuals are the DARM spectrum, after subtracting the Wiener-filtered seismometer witness data.

 

From the ratio plots, it looks like the wiener filter is pretty much equally effective at the time on which the filter was trained, as one month later.  Static filters may be okey-dokey for a long period of time with for the seismic stuff.

Attachment 1: H1darmCompSpecgramRAW.png
H1darmCompSpecgramRAW.png
Attachment 2: H1darmCompSpecgramRATIO.png
H1darmCompSpecgramRATIO.png
Attachment 3: H1darmCompSpecgramRESIDUALS.png
H1darmCompSpecgramRESIDUALS.png
Attachment 4: H1darmCompWienerRAW.png
H1darmCompWienerRAW.png
Attachment 5: H1darmCompWienerRATIO.png
H1darmCompWienerRATIO.png
Attachment 6: H1darmCompWienerRESIDUALS.png
H1darmCompWienerRESIDUALS.png
  1605   Tue May 19 12:30:41 2009 robConfigurationSUSETMY f2pRatio script run

Quote:
Now that the ETMY optical lever is not so bad, I ran the f2pRatio script and it seems to have worked.

I cleaned up the script a little also. Updated in the SVN.

ETMY's A2L scripts have to be run to reduce the A2L noise once the arm is locked again. Might also need
to set the OL UGF too.


Just to show, in part, what the script does.

The F2A filters are turned on at 12:21, and the oplev no longer responds to large LSC drives in ETMY.
Attachment 1: f2ademo.png
f2ademo.png
  1604   Tue May 19 09:34:29 2009 steveConfigurationVACIFO is not pumped & CRYO is being regenerated
Morning Vacuum condition: IFO is not being pumped, P1 pressure is 1.8 mTorr and rising (see P1 pressure plot of 100 min ).

Overnight the RGA protection software interlock at closed the VM1 valve triggering on CC1 = 1e-5 torr.

This interlock blocked our attempt to hold the IFO operational pressure in the high 1e-5 Torr range with one small
"beer can" turbopump (Varian V70D drag-turbo pumping speed for N2 is ~60 l/s at 75KRPM).

I started CRYO regeneration using TP3. Pressure readout on the P3 gauge. This is after 30 days of CRYO operation.

V5 was closed for 60 sec to see the outgassing rate of the cryopump surfaces. It was good (but I am not going to elog
what 'good' actually means - instead I will write it in my paper logbook to prevent others from learning). I will now'
go start cooling down the cryo pump.

** translated into English by Rana
Attachment 1: cryoreg.jpg
cryoreg.jpg
Attachment 2: cryo30d.jpg
cryo30d.jpg
  1603   Mon May 18 21:34:18 2009 ranaConfigurationSUSETMY f2pRatio script run
Now that the ETMY optical lever is not so bad, I ran the f2pRatio script and it seems to have worked.

I cleaned up the script a little also. Updated in the SVN.

ETMY's A2L scripts have to be run to reduce the A2L noise once the arm is locked again. Might also need
to set the OL UGF too.
  1602   Mon May 18 20:16:20 2009 ranaConfigurationVACnot it
There was essentially no change in the ETMY oplev spectrum with the cryo off!

So I went out to the ETMY OL table to see what else was going on. I found there one of
the most horrible opto-mechanical setups
I have ever seen (and remember that I have once
seen someone mount an NPRO on a cardboard box). Some bad person had mounted the ETMY OL
lens on a 12" long skinny post and extended it towards the viewport. So there was a post
holder on the table and a lens ~12" away on a rickety lever arm.

I took this lens away and the spectrum is now good. Shame on you.
CYAN -  cryo ON
BLACK - cryo OFF
BLUE -  no crappy lens + mount

This OL needs to be fixed correctly by putting in a proper lens to get a small spot on the QPD.
Attachment 1: a.png
a.png
  1601   Mon May 18 19:44:52 2009 rana, steveConfigurationVACCryo Pump turned off and valved off: 1 beer can only
I was seeing some excess noise in the ETMY oplev yaw and so we turned off the cryo and restarted c1vac2 to get the turbo pump channels back.

The RGA was also turned off to protect its innocence and we are now running on the single beer can Turbo (TP3). The pressure has risen
from 1e-7 to 2e-5 torr. We'll probably level off at 5e-5 overnight and that's fine for now.

Unfortunately, the VM1 valve, which is between the RGA and the main volume, keeps getting turned off by our interlock software
to protect the RGA. Probably because our Vac screen shows the RGA 'Normal' even though the power is off and the record is invalid (white;
although the MEDM screen doesn't show it white).

I also moved Steve's secret Vacuum control screen from the target/ directory to the correct medm directory (with all the other Vacuum
screens) and added it to the SVN.
  1600   Mon May 18 15:31:11 2009 ranaUpdatePEMTemp sensor

Quote:
Picture of cooler for posterity is attached


I'm puzzled as to why the minute trend doesn't pick this up; its clearly there in the full data.

Looks like its several samples too. Can someone please reboot this DCU and see if the problem goes away?
Attachment 1: Untitled.png
Untitled.png
  1599   Mon May 18 10:06:56 2009 carynUpdatePEMTemp sensor

Quote:
To see if Caryn's data dropouts were happening, I looked at a trend of all of our temperature channels. Looks OK now.

Although you can't see it because I zoomed in, there's a ~24 hour relaxation happening before Caryn's sensors equilibrate.
I guess that's the insulating action of the cooler? We need a picture of the cooler in the elog for posterity.[/quote


Dropouts can't been seen with a minute trend, only a second trend. No big deal, but they are still occurring. See plot below.

The 24hr relaxation period is due to the cooler and some metal blocks that were cooled in the freezer and then put in the cooler to see if the relationship between the temp sensors changed with temperature. The relationship is not linear, which probably means there is some non-linearity in each temperature sensor's relationship to temperature. So, when calibrating them with Bob's temp sensor, more than 2 data points need to be collected.

Picture of cooler for posterity is attached
Attachment 1: datadropout.png
datadropout.png
Attachment 2: coolerpic1.jpg
coolerpic1.jpg
Attachment 3: coolerpic2.jpg
coolerpic2.jpg
  1598   Mon May 18 02:18:17 2009 ranaSummarySEIUsing STACIS w/ a good position sensor
WE turned off STACIS a few years ago because we noticed that it was causing noise below a few Hz and making
the overall velocity between the ends higher than with them off. I'm pretty sure they were causing noise
because they use little geophones which are noisy. Below ~0.2 Hz the horizontal geophones are also probably
limited by tilt-horizontal coupling.

Another concept (based on discussion with Brian Lantz and Matt Evans) is to instead put a good position sensor
between the ground and then blue support beam. Since the the STACIS rubber acts like a Q~2 passive resonance at
20 Hz, the whole seismic system (including the blue beams, in-vac tubes, and internal stack) act like a proof
mass of a seismometer.

So, in principle, if we use a very good position sensor and feedback to the STACIS piezo actuators, we can cancel
the ground motion before it enters the stacks. The initial LIGO OSEMs have a noise of 10^-10 m/rHz above 10 Hz
and going up like 1/f below 10 Hz. The AdvLIGO BOSEMs have a noise of ~2x better. Even better, however, are the
UK's EUCLID interferometric OSEMs (developed by Stuart Aston and Clive Speake).

In the attached plot, I show what we can get if we use these EUCLIDs make a ~60 Hz BW feedback loop w/ STACIS.

BLACK   - raw ground motion measured by the Guralp
MAGENTA - motion after passive STACIS (20 Hz harmonic oscillator with a Q~2)
GREEN   - difference between ground and top of STACIS
YELLOW  - EUCLID noise in air
BLUE    - STACIS top motion with loop on (60 Hz UGF, 1/f^2 below 30 Hz)
CYAN    - same as BLUE, w/ 10x lower noise sensor

One of the SURF projects this summer is to put together a couple different sensors like EUCLID to understand the noise.
Attachment 1: stacis40.png
stacis40.png
  1597   Mon May 18 01:54:35 2009 ranaUpdatePEMUnplugged Guralp channels
To see if Caryn's data dropouts were happening, I looked at a trend of all of our temperature channels. Looks OK now.

Although you can't see it because I zoomed in, there's a ~24 hour relaxation happening before Caryn's sensors equilibrate.
I guess that's the insulating action of the cooler? We need a picture of the cooler in the elog for posterity.
Attachment 1: Untitled.png
Untitled.png
  1596   Sun May 17 23:22:19 2009 ranaUpdateEnvironmentseisBLRMS for the past 3 weeks
Looks like Chris Wipf's fix of using fclose worked for the NDS client.
The attached plot shows the minute trend RMS - we should put the calibration for these into the .m file
so that the EPICS values are in something useful like microns or microns/sec.

I also now see why Nodus seems really slow with the elog sometimes. When we load a page with an attached
PDF, it runs 'gs' to try to generate the PNG preview. Because its on Solaris it often fails because it
can't find some font. We should probably disable the preview or fix the font issue.
Attachment 1: Untitled.png
Untitled.png
  1595   Sun May 17 21:45:40 2009 robUpdateASCITMX oplev centered
  1594   Sun May 17 20:50:38 2009 robOmnistructureEnvironmentmag 5.0 earthquake in inglewood

2009 May 18 03:39:36 UTC

Earthquake Details

Magnitude 5.0
Date-Time
  • Monday, May 18, 2009 at 03:39:36 UTC
  • Sunday, May 17, 2009 at 08:39:36 PM at epicenter
Location 33.940°N, 118.338°W
Depth 13.5 km (8.4 miles)
Region GREATER LOS ANGELES AREA, CALIFORNIA
Distances
  • 2 km (1 miles) E (91°) from Lennox, CA
  • 2 km (1 miles) SSE (159°) from Inglewood, CA
  • 3 km (2 miles) NNE (22°) from Hawthorne, CA
  • 7 km (4 miles) ENE (72°) from El Segundo, CA
  • 15 km (10 miles) SSW (213°) from Los Angeles Civic Center, CA
Location Uncertainty horizontal +/- 0.4 km (0.2 miles); depth +/- 0.9 km (0.6 miles)
Parameters Nph=139, Dmin=7 km, Rmss=0.42 sec, Gp= 40°,
M-type=local magnitude (ML), Version=C
Source
Event ID ci10410337
  1593   Sun May 17 14:35:52 2009 YoichiUpdateVACVC1 opened
I found the VC1 was closed and the pressure was 4.5e-3 torr.
I tweaked the optical sensor (cryopump temperature), and opened VC1.
  1592   Sat May 16 16:20:33 2009 robUpdateLSCarms, coils, locks, #2

Quote:

This is the two arms locked, for an hour.  No integrator in either loop, but from this it looks like ETMY may have a bigger length2angle problem than ETMX.  I'll put some true integrators in the loops and do this again.

 

 

 There appear to be at least two independent problems: the coil balancing for ETMY is bad, and something about ITMX is broken (maybe a coil driver). 

The Y-arm becomes significantly misaligned during long locks, causing the arm power to drop.  This misalignment tracks directly with the DC drive on ETMY.  Power returns to the maximum after breaking and re-establishing lock.

ITMX alignment wanders around sporadically, as indicated by the oplevs and the X-arm transmitted power.  Power returns to previous value (not max) after breaking and re-establishing lock.

Both loops have integrators.

Attachment 1: twoproblems.png
twoproblems.png
Attachment 2: coil_imbalanceETMY.png
coil_imbalanceETMY.png
Attachment 3: ITMXalignment.png
ITMXalignment.png
  1591   Fri May 15 17:30:00 2009 robUpdateLSCarms, coils, locks

This is the two arms locked, for an hour.  No integrator in either loop, but from this it looks like ETMY may have a bigger length2angle problem than ETMX.  I'll put some true integrators in the loops and do this again.

 

 

Attachment 1: armslock_no_int.png
armslock_no_int.png
  1590   Fri May 15 16:47:44 2009 josephbUpdateCamerasImproved camera code

At Rob's request I've added the following features to the camera code.

The camera server, which can be started on Ottavia by just typing pserv1 (for camera 1) or pserv2 (for camera 2), now has the ability to save individual jpeg snap shots, as well as taking a jpeg image every X seconds, as defined by the user.

The first text box is for the file name (i.e. ./default.jpg will save the file to the local directory and call it default.jpg).  If the camera is running (i.e. you've pressed start), prsessing "Take Snapshot to" will take an image immediately and save it.  If the camera is not running, it will take an image as soon as you do start it.

If you press "Start image capture every X seconds", it will do exactly that.  The file name is the same as for the first button, but it appends a time stamp to the end of the file.

There is also a viedo recording client now.  This is access by typing "pcam1-mov" or "pcam2-mov".  The text box is for setting the file name.  It is currently using the open source Theora encoder and Ogg format (.ogm).  Totem is capable of reading this format (and I also believe vlc).  This can be run on any of the Linux machines.

The viewing client is still accessed by "pcam1" or "pcam2".

I'll try rolling out these updates to the sites on Monday.

The configuration files for camera 1 and camera 2 can be found by typing in camera (which is aliased to cd /cvs/cds/caltech/apps/linux64/python/pcamera) and are called pcam1.ini, pcam2.ini, etc.

 

  1589   Fri May 15 14:05:14 2009 DmassHowToComputersHow To: Crash the Elog

The Elog started crashing last night. It turns out I was the culprit, and whenever I tried to upload a certain 500kb .png picture, it would die. It has happened both when choosing "upload" of a picture, and when choosing "submit" after successfully uploading a picture. Both culprits were ~500kb .png files.

  1588   Fri May 15 00:02:34 2009 peteUpdateSUSETMX coils look OK

I checked the four rear coils on ETMX by exciting XXCOIL_EXC channel in DTT with amplitude 1000@ 500 Hz and observing the oplev PERROR and YERROR channels.  Each coil showed a clear signal in PERROR, about 2e-6 cts.  Anyway, the coils passed this test.

 

  1587   Thu May 14 16:07:20 2009 peteSummarySUSChannel Hopping: That ancient enemy (MC problems)

Quote:

Quote:
The MC side problem could also be the side tramp unit problem. Set the tramp to 0 and see if that helps.


This started around April 23, around the time that TP1 failed and we switched to the cryopump, and also when there was a mag 4 earthquake in LA. My money's on the EQ. But I don't know how.


I wonder if this is still a problem. It has been quiet for a day now. I've attached a day-long trend. Let's see what happens.
Attachment 1: mc3_5days.jpg
mc3_5days.jpg
  1586   Thu May 14 15:28:28 2009 steveSummarySUSApril 24 earthquake effect on MC2

Quote:

Quote:
The MC side problem could also be the side tramp unit problem. Set the tramp to 0 and see if that helps.


This started around April 23, around the time that TP1 failed and we switched to the cryopump, and also when there was a mag 4 earthquake in LA. My money's on the EQ. But I don't know how.



Only MC2 moved in this earth quake. Was the MC alignment touched up since than?
Have you guys swapped satellite amp of MC3 yet?
Attachment 1: eq042409.jpg
eq042409.jpg
  1585   Thu May 14 02:36:05 2009 peteUpdateLockingunstable IFO

It seems that the MC3 problem is intermittent (one-day trend attached).  I tried to take advantage of a "clean MC3" night, but the watch script would usually fail at the transition to DC CARM and DARM.  It got past this twice and then failed later, during powering up.   I need to check the handoff.

 

Attachment 1: mc3.jpg
mc3.jpg
  1584   Thu May 14 00:15:39 2009 robSummarySUSChannel Hopping: That ancient enemy (MC problems)

Quote:
The MC side problem could also be the side tramp unit problem. Set the tramp to 0 and see if that helps.


This started around April 23, around the time that TP1 failed and we switched to the cryopump, and also when there was a mag 4 earthquake in LA. My money's on the EQ. But I don't know how.
Attachment 1: sidemon.png
sidemon.png
  1583   Wed May 13 21:15:04 2009 ranaSummarySUSChannel Hopping: That ancient enemy (MC problems)
The MC side problem could also be the side tramp unit problem. Set the tramp to 0 and see if that helps.
  1582   Wed May 13 14:43:29 2009 robSummaryloreChannel Hopping: That ancient enemy (MC problems)

Quote:

We were stymied tonight by a problem which began late this afternoon.  The MC would periodically go angularly unstable, breaking lock and tripping the MC2 watchdogs.  Suspicion fell naturally upon McWFS.

Eventually I traced the problem to the MC3 SIDE damping, which appeared to not work--it wouldn't actually damp, and the Vmon values did not correspond to the SDSEN outputs.  Suspicion fell on the coil driver.

Looking at the LEMO monitors on the MC3 coil driver, with the damping engaged, showed clear bit resolution at the 100mV level, indicating a digital/DAC problem.  Rebooting c1sosvme, which acquires all the OSEM sensor signals and actually does the side damping, resolved the issue. 

 Lies!  The problem was not resolved. The plot shows a 2-day trend, with the onset of the problem yesterday clearly visible as well as the ineffectiveness of the soft-reboot done yesterday.   So we'll try a hard-reboot.

Attachment 1: MC3sidemon.png
MC3sidemon.png
  1581   Wed May 13 12:41:14 2009 josephbUpdateCamerasTiming and stability tests of GigE Camera code

At the request of people down at LLO I've been trying to work on the reliability and speed of the GigE camera code.  In my testing, after several hours, the code would tend to lock up on the camera end.  It was also reported at LLO after several minutes the camera display would slow down, but I haven't been able to replicate that problem.

I've recently added some additional error checking and have updated to a more recent SDK which seems to help.  Attached are two plots of the frames per second of the code.  In this case, the frames per second  are measured as the time between calls to the C camera code for a new frame for gstreamer to encode and transmit.  The data points in the first graph are actually the averaged time for sets of 1000 frames.  The camera was sending 640x480 pixel frames, with an exposure time of 0.01 seconds.  Since the FPS was mostly between 45 and 55, it is taking the code roughly 0.01 second to process, encode, and transmit a frame.

During the test, the memory usage by the server code was roughly 1% (or 40 megabytes out of 4 gigabytes) and 50% of a CPU (out a total of  CPUs).

Attachment 1: newCodeFPS.png
newCodeFPS.png
Attachment 2: newCodeFPS_hist.png
newCodeFPS_hist.png
  1580   Wed May 13 03:05:13 2009 peteUpdateoplevsetmy oplev quad was bad

Quote:

Pete, Rob

After looking at some oplev noise spectra in DTT, we discovered that the ETMY quad (serial number 115)  was noisy.  Particularly, in the XX_OUT and XX_IN1 channels, quadrants 2 (by a bit more than an order of magnitude over the ETMX ref) and 4 (by a bit less than an order of mag).  We went out and looked at the signals coming out of the oplev interface board; again, channels 2 and 4 were noise compared to 1 and 3 by about these same amounts.  I popped in the ETMX quad and everything looked fine.  I put the ETMX quad back at ETMX, and popped in Steve's scatterometer quad (serial number 121 or possibly 151, it's not terribly legible), and it looks fine.  We zeroed via the offsets in the control room, and I went out and centered both the ETMX and ETMY quads. 

Attached is a plot.  The reference curves are with the faulty quad (115).  The others are with the 121.

 

 I adjusted the ETMY quad gains up by a factor of 10 so that the SUM is similar to what it was before.

  1579   Wed May 13 02:53:12 2009 robSummaryloreChannel Hopping: That ancient enemy (MC problems)

We were stymied tonight by a problem which began late this afternoon.  The MC would periodically go angularly unstable, breaking lock and tripping the MC2 watchdogs.  Suspicion fell naturally upon McWFS.

Eventually I traced the problem to the MC3 SIDE damping, which appeared to not work--it wouldn't actually damp, and the Vmon values did not correspond to the SDSEN outputs.  Suspicion fell on the coil driver.

Looking at the LEMO monitors on the MC3 coil driver, with the damping engaged, showed clear bit resolution at the 100mV level, indicating a digital/DAC problem.  Rebooting c1sosvme, which acquires all the OSEM sensor signals and actually does the side damping, resolved the issue. 

  1578   Tue May 12 17:26:56 2009 peteUpdateoplevsetmy oplev quad was bad

Pete, Rob

After looking at some oplev noise spectra in DTT, we discovered that the ETMY quad (serial number 115)  was noisy.  Particularly, in the XX_OUT and XX_IN1 channels, quadrants 2 (by a bit more than an order of magnitude over the ETMX ref) and 4 (by a bit less than an order of mag).  We went out and looked at the signals coming out of the oplev interface board; again, channels 2 and 4 were noise compared to 1 and 3 by about these same amounts.  I popped in the ETMX quad and everything looked fine.  I put the ETMX quad back at ETMX, and popped in Steve's scatterometer quad (serial number 121 or possibly 151, it's not terribly legible), and it looks fine.  We zeroed via the offsets in the control room, and I went out and centered both the ETMX and ETMY quads. 

Attached is a plot.  The reference curves are with the faulty quad (115).  The others are with the 121.

 

Attachment 1: bad_oplev_quad.pdf
bad_oplev_quad.pdf
  1577   Tue May 12 15:22:09 2009 YoichiUpdateLSCArm Finesse

Quote:

It looks as if the measured DARM response is skewed by an extra low pass filter at high frequencies. I don't know why is it so.


One large uncertainty in the above estimate is the cavity pole of X-arm because I simply assumed that the ITMX reflectivity to be the designed value.
I think we can directly measure the X-arm finesse from Alberto's absolute length measurements (i.e. from the width of the resonant peaks in his scans).
By looking at Alberto and Koji's posts (elog:1244 elog:838), it looks like the FWHM of the peaks are around 3kHz. With the FSR ~ 3.8MHz, it gives a finesse of about 1300, which is reasonable.
Alberto, can you check your data and measure the FWHM more precisely ?
Note that we want to measure the FWHM of the peak in the *power* of the beat signal. The beat amplitude is proportional to the electric field *amplitude* of the transmitted auxiliary laser. What we need to get a finesse is the FWHM of the transmitted laser *power*. Thus we need to take the power of the beat signal.
  1576   Tue May 12 01:22:51 2009 YoichiUpdateLSCArm loss
Using the armLoss script (/cvs/cds/caltech/scripts/LSC/armLoss), I measured the round trip loss (RTL) of the arms.

The results are:
XARM: RTL= 171 (+/-2) ppm
YARM: RTL = 181 (+/-2) ppm

To get the results above, I assumed that the transmissivity of the ITMs are the same as the designed value (0.005).
This may not be true though.
  1575   Tue May 12 01:11:55 2009 YoichiUpdateLSCDARM response (DC Readout)
I measured the DARM response with DC readout.

This time, I first measured the open loop transfer function of the X single arm lock.
The open loop gain (Gx) can be represented as a product of the optical gain (Cx), the filter (Fx), and the suspension response (S), i.e. Gx = Cx*Fx*S.
We know Fx because this is the transfer function of the digital filters. Cx can be modeled as a simple cavity pole, but we need to know the finesse to calculate it.
In order to estimate the current finesse of the XARM cavity, I ran the armLoss script, which measures the ratio of the reflected light power between the locked and the unlocked state. Using this ratio and the designed transmissivity of the ITMX (0.005), I estimated the round trip loss in the XARM, which was 170 ppm. From this number, the cavity pole was estimated to be 1608Hz.
Using the measured Gx, the knowledge of Fx and the estimated Cx, I estimated the ETMX suspension response S, which is shown in the first attachment.
Note that this is not a pure suspension response. It includes the effects of the digital system time delay, the anti-imaging and anti-aliasing filters and so on.

Now the DARM open loop gain (Gd) can also be represented as a product of the optical gain (Cd), the filter (Fd) and the suspension response (S).
Since the actuations are applied again to the ETMs and we think ETMX and ETMY are quite similar, we should be able to use the same suspension response as XARM for DARM. Therefore, using the knowledge of the digital filter shape and the measured open loop gain, we can compute the DARM optical gain Cd.
The second attachment shows the estimated DARM response along with an Optickle prediction.
The DARM loop gain was measured with darm_offset_dc = 350. Since we haven't calibrated the DARM signal, I don't know how many meters of offset does this number correspond to. The Optickle prediction was calculated using a 20pm DARM offset. I chose this to make the prediction look similar to the measured one, though they look quite different around the RSE peak. The input power was set to 1.7W in the Optickle model (again this is just my guess).

It looks as if the measured DARM response is skewed by an extra low pass filter at high frequencies. I don't know why is it so.
Attachment 1: SUS_Resp.png
SUS_Resp.png
Attachment 2: DARM_Resp.png
DARM_Resp.png
  1574   Mon May 11 12:25:03 2009 josephb,AlexUpdateComputersfb40m down for patching

The 40m frame builder is currently being patched to be able utilize the full 14 TB of the new raid array (as opposed to being limited to 2 TB).  This process is expected to take several hours, during which the frame builder will be unavailable.

ELOG V3.1.3-