40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 314 of 344  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  1533   Wed Apr 29 15:56:43 2009 robUpdateLockingeffect of SRCL detune on ARM powers in a CARM sweep

With no DARM offset, sweeping CARM shows an asymmetry between the state where we lock to a DARM spring and the state with a DARM anti-spring.  This is why we have a link between the DARM and CARM optical springs. 

For each DARM detune direction (positive or negative, spring or anti-spring), there is only one CARM direction which can yield a DC-based error signal lock with a CARM offset but no DARM offset, which is what we want.

  1535   Thu Apr 30 15:10:54 2009 robUpdateLockingCARM RF changed to REFL_2I

Quote:
Yoichi, Peter

As Rob suggested, the optimal demodulation phase is easier to find for REFL_2I than POX_1I.
Moreover, for 166MHz LO, we have a phase shifter (delay line) already installed. So we can easily change the demodulation phase of REFL_2I.
Tonight, we switched the RF CARM signal to REFL_2I.
To do so, I changed the signal going to the REFL1 input of the common mode board from POX_1I to REFL_2I.
I moved a BNC-T installed at the output of POX_1I to the REFL_2I output to split the REFL_2I signal and send it to the CM board.
Since the gain of the REFL_2I was about 20dB lower than that of POX_1I, I increased the gain of the SR560, which is installed between the REFL_2 demodulation board and the CM board, from 1 to 10.

With some gain tweaks, we were able to hand off the CARM from REFL_DC to REFL_2I. We also succeeded in switching the REFL_2I ADC channel from PD11 to PD2_DC (the output of the length path from the CM board). This switching is necessary in order to engage the boost on the CM board.

There remains some offset in the CARM when the arm power is maximized. This is expected because the REFL_2I demodulation phase is probably not exactly right.
I will optimize the demodulation phase tomorrow.



From Optickle simulations, it looks like the SRCL/CARM gain ratio at REFL I2 is about 8e-4. So a 1 nanometer offset in SRCL yields 0.8 picometers of offset in CARM.
  1537   Fri May 1 10:04:10 2009 robUpdateLocking166MHz LO phase adjustment

Quote:
I continued to adjust the REFL_2I demodulation phase.
I first optimized the demod phase for SRCL in the DRMI configuration (the error signals were DDs).
Then I restored the full IFO and offset locked it.
Before handing the DARM to RF, I adjusted the 166MHz delay line to maximize the SRCL signal at REFL_2I.
I did this before the DARM RF hand off because changing the delay line setting also changes the AS166 demodulation phase.
After this, I adjusted the digital phase shifter for AS166 to maximize the DARM signal for this port.

I also adjusted the digital demodulation phase of PD11 (REFL_2I) because the optimal demodulation phase for the initial lock acquisition is somewhat (15deg)
different from the optimal demodulation phase for the SRCL when the central part is locked with the DD signals.
This happens because the resonant condition of the central part (lock points of the recycling cavities) changes when the error signals are switched to the DD signals,
due to the offset in the DD signals. This is not good and should be fixed by the optimization of the DD demodulation phases.

Finally, I reduced the CARM offset to zero and tweaked the delay line a bit to maximize the arm power.

Right now, the locking script runs fine until the end.
At the end of the script, I was able to engage the boost on the CM board.



Awesome. Up next: dewhitening.
  1545   Tue May 5 08:26:56 2009 robUpdateLockingDC Readout and DARM response

Quote:
Tonight, I was able to switch the DARM to DC readout a couple of times.
But the lock was not as stable as the RF DARM. It lost lock when I tried to measure the DARM loop gain.

I also measured DARM response when DARM is on RF.
The attached plot shows the DARM optical gain (from the mirror displacement to the PD output).
The magnitude is in an arbitrary unit.

I measured a transfer function from DARM excitation to the DARM error signal. Then I corrected it for the DARM open loop gain and the pendulum response to get the plot below.

There is an RSE peak at 4kHz as expected. The origin of the small bump and dip around 2.5kHz and 1.5kHz are unknown.
I will consult with the Optickle model.
I don't know why the optical gain decreases below 50Hz (I don't think it actually decreases).
Seems like the DARM loop gain measured at those frequencies are too low.
I will retry the measurement.


The optical gain does decrease below ~50Hz--that's the optical spring in action. The squiggles are funny. Last time we did this we measured the single arm TFs to compensate for any tough-to-model squiggles in the transfer functions which might arise from electronics or the suspensions.
  1548   Tue May 5 11:44:33 2009 robUpdateLocking DARM response

Here's the RF DARM optical response, on the anti-spring side, from optickle. Note that for the f1 sideband, changing the demod phase mostly adjusts the overall gain, while for the f2 sideband a change in demod phase alters the shape of the response. This is the quadrature-selecting power of using a single RF sideband as a local oscillator.
  1549   Tue May 5 14:02:16 2009 robUpdateLSCDARM DC response varies with DARM offset

Note the effect of quadrature rotation for small offsets.

  1559   Thu May 7 23:34:59 2009 robUpdateSEIseisBLRMS already lost

Can't find hostname 'fb40m'

 

it only lasted a few hours

  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. 

  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.

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

 

 

  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.

  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
  1595   Sun May 17 21:45:40 2009 robUpdateASCITMX oplev centered
  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.
  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.

  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.

  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.

  1625   Tue May 26 17:05:44 2009 robUpdatePSLMOPA re-activated

steve, rob, alberto

 

Steve installed two rotary flow meters into the MOPA chiller system--one at the chiller flow output and one in the NPRO cooling line.  After some hijinks, we discovered that the long, insulated chiller lines have the same labels at each end.  This means that if you match up the labels at the chiller end, at the MOPA end you need switch labels: out goes to in and vice-versa.  This means that, indubitably, we have at some point had the flow going backwards through the MOPA, though I'm not sure if that would make much of a difference. 

Steve also installed a new needle valve in the NPRO cooling line, which works as expected as confirmed by the flow meter. 

We also re-discovered that the 40m procedures manual contains an error.  To turn on the chiller in the MOPA start-up process, you have to press ON, then RS-232, then ENTER.  The proc man says ON, RS-232, RUN/STOP.

The laser power is at 1.5W and climbing.

  1626   Tue May 26 17:34:14 2009 robUpdatePSLMOPA re-deactivated

Quote:

steve, rob, alberto

 

Steve installed two rotary flow meters into the MOPA chiller system--one at the chiller flow output and one in the NPRO cooling line.  After some hijinks, we discovered that the long, insulated chiller lines have the same labels at each end.  This means that if you match up the labels at the chiller end, at the MOPA end you need switch labels: out goes to in and vice-versa.  This means that, indubitably, we have at some point had the flow going backwards through the MOPA, though I'm not sure if that would make much of a difference. 

Steve also installed a new needle valve in the NPRO cooling line, which works as expected as confirmed by the flow meter. 

We also re-discovered that the 40m procedures manual contains an error.  To turn on the chiller in the MOPA start-up process, you have to press ON, then RS-232, then ENTER.  The proc man says ON, RS-232, RUN/STOP.

The laser power is at 1.5W and climbing.

 Rob, Alberto

The chiller HT alarm started blinking, as the water temperature had reached 40 degrees C, and was still rising.  We turned off the MOPA and the chiller.  Maybe we need to open the needle valve a bit more?  Or maybe the flow needs to be reversed?  The labels on the MOPA are backwards?

  1627   Wed May 27 10:54:09 2009 robUpdatePSLwe don't understand the chiller (broken)

Quote:

Quote:

steve, rob, alberto

 

Steve installed two rotary flow meters into the MOPA chiller system--one at the chiller flow output and one in the NPRO cooling line.  After some hijinks, we discovered that the long, insulated chiller lines have the same labels at each end.  This means that if you match up the labels at the chiller end, at the MOPA end you need switch labels: out goes to in and vice-versa.  This means that, indubitably, we have at some point had the flow going backwards through the MOPA, though I'm not sure if that would make much of a difference. 

Steve also installed a new needle valve in the NPRO cooling line, which works as expected as confirmed by the flow meter. 

We also re-discovered that the 40m procedures manual contains an error.  To turn on the chiller in the MOPA start-up process, you have to press ON, then RS-232, then ENTER.  The proc man says ON, RS-232, RUN/STOP.

The laser power is at 1.5W and climbing.

 Rob, Alberto

The chiller HT alarm started blinking, as the water temperature had reached 40 degrees C, and was still rising.  We turned off the MOPA and the chiller.  Maybe we need to open the needle valve a bit more?  Or maybe the flow needs to be reversed?  The labels on the MOPA are backwards?

 The chiller appears to be broken.  We currently have it on, with both the SENSOR and RS-232 unplugged.  It's running, circulating water, and the COOL led is illuminated.  But the temperature is not going down.  The exhaust out the back is not particularly warm.  We think this means the refrigeration unit has broken, or the chiller computer is not communicating with the refrigerator/heat exchanger.  Regardless, we may need a new chiller and a new laser.

  1628   Wed May 27 15:59:44 2009 robUpdatePSLwe don't understand the chiller (broken)

steve, alberto, rob

After some futzing around with the chiller, we have come to the tentative conclusion that the refrigeration unit is not working.  Steve called facilities to try to get them to recharge the refrigerant (R-404a) tomorrow, and we're also calling around for a spare chiller somewhere in the project (without luck so far).

  1629   Thu May 28 14:34:25 2009 robUpdatePSLchiller diagnosis

Quote:

steve, alberto, rob

After some futzing around with the chiller, we have come to the tentative conclusion that the refrigeration unit is not working.  Steve called facilities to try to get them to recharge the refrigerant (R-404a) tomorrow, and we're also calling around for a spare chiller somewhere in the project (without luck so far).

 The repair man thinks it's a bad start capacitor, which is 240uF at 120V.  Steve has ordered a new one which should be here tomorrow, and with luck we'll have lasing by tomorrow afternoon.

  1632   Sat May 30 11:24:56 2009 robConfigurationPSLNPRO slow scan

I'm setting SLOWDC to about -5.

I had to edit FSSSlowServo because it had hard limits on SLOWDC at (-5 and 5).  It now goes from -10 to 10.

 

 

  1633   Sat May 30 12:03:34 2009 robUpdatePSLMC locked

I locked to PSL loops, then tweaked the alignment of the MC to get it to lock. 

I first steering MC1 until all the McWFS quads were saturated.  This got the MC locking in a 01 mode.  So I steered MC1 a little more till it was 00.  Then I steered MC2 to increase the power a little bit.  After that, I just enabled the MC autolocker.

  1634   Sat May 30 12:36:52 2009 robUpdateComputersc1susvme2, c1iscex running late

c1susvme2 has been running just a bit late for about a week.  I rebooted it. 

The plot shows SRM_FE_SYNC, which is the number of times in the last second that c1susvme2 was late for the 16k cycle.   Similarly for ETMX.

 

  1635   Mon Jun 1 13:25:00 2009 robUpdateComputersc1susvme2, c1iscex running late

Quote:

c1susvme2 has been running just a bit late for about a week.  I rebooted it. 

The plot shows SRM_FE_SYNC, which is the number of times in the last second that c1susvme2 was late for the 16k cycle.   Similarly for ETMX.

 

 

The reboot appears to have worked.

  1637   Mon Jun 1 14:33:42 2009 robConfigurationComputer Scripts / Programsop540m Monitor added to web status

I added op540m's display 0 (the northern-most monitor in the control room) to the MEDM screens webpage: https://nodus.ligo.caltech.edu:30889/medm/screenshot.html

 

Now we can see the StripTool displays that are usually parked on that screen.

 

 

  1638   Mon Jun 1 14:49:07 2009 robSummaryPSLpsl thoughts

Some thoughts on what happened with the MOPA cooling. 

Some unknown thing happened to precipitate the initial needle valve jiggle, which unleashed a torrent of flow through the NPRO.  This flow was made possible by the fact that the cooling lines are labeled confusingly, and so flow was going backwards through the needle valve, which was thus powerless to restrict it.  The NPRO got extremely cold, and most of the chiller's cooling power was being used to unnecessarily cool the NPRO.  So, the PA was not getting cooled enough.  At this, point, reversing the flow probably would have solved everything.  Instead, we turned off the chiller and thus discovered the flaky start-motor capacitor. 

Now we have much more information, flow meters in the NPRO and main cooling lines, a brand-new, functioning needle valve, a better understanding of the chiller/MOPA settings necessary for operation, and the knowledge of what happens when you install a needle valve backwards.

 

  1642   Tue Jun 2 23:12:08 2009 robConfigurationComputersntp on op440m

I restarted ntpd on op440m to solve a "synchronization error" that we were having in DTT.  I also edited the config file (/etc/inet/ntp.conf) to remove the lines referring to rana as an ntp server; now only nodus is listed.

To do this:

log in as root

/usr/local/bin/ntpd -c /etc/inet/ntp.conf

  1650   Thu Jun 4 01:32:20 2009 robConfigurationLSCAS port mode scan

Here is a set of mode scans of the AS port, using the OMC as a mode scanner.  The plot overlays various configurations of the IFO.  

To remove PZT nonlinearity, each scan was individually flattened in fsr-space by polynomial (3rd order) fitting to some known peak locations (the carrier and RF sidebands).
 

  1656   Fri Jun 5 13:51:49 2009 robUpdateLockingtdsavg failure in cm_step script

Quote:

the command

tdsavg 5 C1:LSC-PD4_DC_IN1

was causing grievous woe in the cm_step script.  It turned out to fail intermittently at the command line, as did other LSC channels.  (But non-LSC channels seem to be OK.)  So we power cycled c1lsc (we couldn't ssh).

Then we noticed that computers were out of sync again (several timing fields said 16383 in the C0DAQ_RFMNETWORK screen).  We restarted c1iscey, c1iscex, c1lsc, c1susvme1, and c1susvme2.  The timing fields went back to 0.  But the tdsavg command still  intermittently said "ERROR: LDAQ - SendRequest - bad NDS status: 13".

The channel C1:LSC-SRM_OUT16 seems to work with tdsavg every time.

Let us know if you know how to fix this. 

 

 Did you try restarting the framebuilder?

 

What you type is in bold:

op440m> telnet fb40m 8087

daqd> shutdown

 

  1663   Tue Jun 9 23:25:24 2009 robUpdateLocking?

Quote:

Quote:

Lock acquisition is proceeding smoothly for the most part, but there is a very consistent failure point near the end of the cm_step script.

Near the end of the procedure, while in RF common mode, the sensing for the MCL path of the common mode servo is transitioned from a REFL 166I signal which comes into the LSC whitening board from the demodulator, to another copy of the signal which has passed through the common mode board, and is coming out of the Length output of the common mode board.  We do this because the signal which comes through the CM board sees the switchable low-frequency boost filter, and so both paths of the CM servo (AO and MCL) can get that filter switched on at the same time.

The problem is occurring after this transition, which works reliably.  However, when the script tries to remove the final CARM offset, and bring the offset to zero, lock is abruptly lost.  DARM, CM, and the crossover all look stable, and no excess noise appears while looking at the DARM, CARM, MCF spectra.  But lock is always lost right about the same offset. 

Saturation somewhere?

 I've seen this before. At that time, the problem was gone spontaneously the next day.

You could stop just before the offset reaches zero and then try to slowly reduce the offset manually to see where is the threshold.

 

 

Well, it hasn't gone away yet.  It happened Sat, Mon, and Tues afternoon, as well as Friday.  The threshold varies slightly, but is always around ~200-300 cnts.   I've tried reducing the offset with the signal coming from the CM board and the signal not going through the CM board, I've also tried jumping the signal to zero (rather than a gradual reduction). 

Tonight we'll measure the MC length and set the modulation frequencies, and maybe try some MZ tweaking to do RFAMMon minimization.    

  1670   Fri Jun 12 02:01:03 2009 robUpdateComputer Scripts / ProgramsDRM matrix diagonalization

I started two scripts, senseDRM and loadDRMImatrixData.m, which Peter will bang on until they're correct.  They're in the $SCRIPTS/LSC directory.  The first is a perl script which uses TDS tools to drive the DRM optics and measure the response at the double demod photo-detectors, and write these results to a series of files loadable by matlab.  The second loads the output from the first script, inverts the resulting sensing matrix to get an input matrix, and spits out a tdswrite command which can be copied and pasted into a terminal to load the new input matrix values. 

What's left is mainly in figuring out how to do the matrix inversion properly.  Right now the script does not account for the output matrix, the gains in the feedback filters at the measurement frequency, or the fact that we'll likely want the UGF of our loops to be less than the measurement frequency.  Peter's going to hash out these details.

  1675   Tue Jun 16 02:09:31 2009 robUpdateLockingDD handoff finally working

I had trouble getting the SRC handoff from SD to DD to work.  I tried different gains, flipping the PD7 & 8 demod phases by 180 degrees, and messing with the output matrix to reduce cross-couplings in the state with MICH & PRC on DD and SRC on SD.  Eventually I decided to try to make the DRM matrix diagonalization work. 

It does, mostly.  The handoff is now stable, and the loops all have UGFs around 100Hz.  So, tonight anyways, it's possible to run senseDRM and then loadDRMImatrixData.m and run the resulting tdswrite command, and have a working handoff.  I had to eliminate a few PDs (PD5 & PD10) to get it to work properly. 

It would be nice if this script would measure all the PDs and allow individual setting of loop UGFs and measurement frequencies. 

 

 

  1676   Tue Jun 16 03:43:04 2009 robUpdateLockingsame troubles

Lock is still being lost, right at the end of the process when trying to reduce the CARM offset to zero.

  1678   Tue Jun 16 14:02:16 2009 robUpdateLockinglocked

The IFO is locked, at the operating point (zero CARM offset).  The problem with reducing the residual CARM offset in the last stage appears to have been because the common mode gain was getting too high, and so the loop was going unstable at high frequencies. 

The cm_step script is currently a confusing mess, with all the debugging statements.  I'll clean it up this afternoon and check that it still works.

  1680   Tue Jun 16 17:38:35 2009 robUpdateLockingDeWhites ON

With the common mode servo bandwidth above 30kHz and the BOOST on (1), I was able to switch on the test mass dewhitening.  Finally.

  1682   Wed Jun 17 01:07:50 2009 robConfigurationComputersmatapps on /cvs/cds

I checked out a copy of matapps into /cvs/cds/caltech/apps/lscsoft so that I could find the matlab function strassign.m, which is necessary for some old mDV commands to run.  I don't know why it became necessary or why it disappeared if it did.

  1683   Wed Jun 17 01:09:47 2009 robUpdateComputers/cvs/cds 91% full

In /cvs/cds/caltech

 


1.6M    2008-8-15.pdf
2.9M    40mUpgradeOpticalLayoutPlan01.pdf
2.4M    alh
19M     apache
18G     apps
11M     archive
4.0K    authorized_keys2
8.0K    backup.notes
8.0K    backup.notes~
1.9G    build
62G     burt
47M     cds
13M     cds40m
37M     chans
70G     conlog
52K     crontab
12K     cshrc.40m
12K     cshrc.40m~
36M     diag
1.4G    dmt
8.2M    framecpp-0.2.0
1.7M    free_080730.pdf
57M     gds
9.8G    home
60K     hooks
8.0K    hosts.40m
4.0K    id_rsa
10M     iscmodeling
110M    ldg-4.7
648M    libs
4.0K    log2.txt
224K    logs
0       log.txt
238M    medm
344M    NB
148M    NB_080304
211M    NB_080307
401M    NB40
1.2G    noisebudget.071109
837M    noisebudget.bak.20060623
3.5M    oldtarget
123M    root
5.7M    savesets
208K    schematics
655M    scripts
13G     scripts_archive
1.1M    state
3.7G    svn
4.0K    svn-commit.tmp
7.3G    target
295M    target_archive
6.7M    test
72K     test.png
4.0K    tmp
8.0K    typescript
35G     users
205M    wind

  1684   Thu Jun 18 23:08:46 2009 robUpdateLockingspectrum

Here's a noise spectrum of the RSE interferometer, in anti-spring mode, with RF readout.  I'd say the calibration is "loose."

I used the Buonanno & Chen modification of the KLMTV IFO transfer functions to model the DARM opto-mechanical response.  I just guessed at the quadrature, and normalized the optical gain at the frequency of the calibration line used (927Hz, not visible on the plot).

  1685   Thu Jun 18 23:20:40 2009 robSummaryLSCI-Q ratio with RF detected DARM

This is a ratio of PD1_I to PD1_Q (so a ratio of the two quadratures of AS166), measured in an anti-spring state.  It's not flat because our set up has single sideband RF heterodyne detection, and using a single RF sideband as a local oscillator allows one to detect different quadratures by using different RF demodulation phases.   So the variation in frequency is actually a measure of how the frequency response of DARM changes when you vary the detection quadrature.  This measure is imperfect because it doesn't account for the effect of the DARM loop.

Even though you can choose your detection quadrature with this setup, you can't get squeezed quantum noise with a single RF sideband.  The quantum noise around the other (zero-amplitude) RF sideband still gets mixed in, and negates any squeezing benefits.

  1699   Wed Jun 24 14:43:19 2009 robUpdateComputerstdsresp on linux => pzresp

 

tdsresp is broken on our linux control room machines.  I made a little perl replacement which uses the DiagTools.pm perl module, called pzresp.  It's in the $SCRIPTS/general directory, and so in the path of all the machines.  I also edited the cshrc.40m file so that on linux machines tdsresp points to this perl replacement.

I've patched DiagTools.pm to circumnavigate the tdsdmd bug described here.  I also added a function to DiagTools.pm called diagRespNoLog, which is just like diagResp but without that pesky log file.

 


Here's the output from the tdsresp binary on CentOS:
allegra:~>tdsresp 941.54 10000 100 10 C1:LSC-ITMX_EXC C1:LSC-PD1_Q C1:LSC-PD1_I
nan nan nan nan nan nan nan
nan nan nan nan nan nan nan
nan nan nan nan nan nan nan
*** glibc detected *** tdsresp: free(): invalid next size (fast): 0x089483e8 ***
======= Backtrace: =========
/lib/libc.so.6[0xa800f1]
/lib/libc.so.6(cfree+0x90)[0xa83bc0]
/usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xf7f36571]
tdsresp[0x8057fbb]
tdsresp[0x805b394]
/lib/libc.so.6(__libc_start_main+0xdc)[0xa2ce8c]
tdsresp(__gxx_personality_v0+0x169)[0x804ddd1]
======= Memory map: ========
00242000-00249000 r-xp 00000000 fd:00 15400987                           /lib/librt-2.5.so
00249000-0024a000 r--p 00006000 fd:00 15400987                           /lib/librt-2.5.so
0024a000-0024b000 rw-p 00007000 fd:00 15400987                           /lib/librt-2.5.so
009f9000-00a13000 r-xp 00000000 fd:00 15400963                           /lib/ld-2.5.so
00a13000-00a14000 r--p 00019000 fd:00 15400963                           /lib/ld-2.5.so
00a14000-00a15000 rw-p 0001a000 fd:00 15400963                           /lib/ld-2.5.so
00a17000-00b55000 r-xp 00000000 fd:00 15400974                           /lib/libc-2.5.so
00b55000-00b57000 r--p 0013e000 fd:00 15400974                           /lib/libc-2.5.so
00b57000-00b58000 rw-p 00140000 fd:00 15400974                           /lib/libc-2.5.so
00b58000-00b5b000 rw-p 00b58000 00:00 0 
00b5d000-00b70000 r-xp 00000000 fd:00 15400984                           /lib/libpthread-2.5.so
00b70000-00b71000 r--p 00012000 fd:00 15400984                           /lib/libpthread-2.5.so
00b71000-00b72000 rw-p 00013000 fd:00 15400984                           /lib/libpthread-2.5.so
00b72000-00b74000 rw-p 00b72000 00:00 0 
00b76000-00b78000 r-xp 00000000 fd:00 15400981                           /lib/libdl-2.5.so
00b78000-00b79000 r--p 00001000 fd:00 15400981                           /lib/libdl-2.5.so
00b79000-00b7a000 rw-p 00002000 fd:00 15400981                           /lib/libdl-2.5.so
00b7c000-00ba1000 r-xp 00000000 fd:00 15400975                           /lib/libm-2.5.so
00ba1000-00ba2000 r--p 00024000 fd:00 15400975                           /lib/libm-2.5.so
00ba2000-00ba3000 rw-p 00025000 fd:00 15400975                           /lib/libm-2.5.so
00bca000-00bdd000 r-xp 00000000 fd:00 15401011                           /lib/libnsl-2.5.so
00bdd000-00bde000 r--p 00012000 fd:00 15401011                           /lib/libnsl-2.5.so
00bde000-00bdf000 rw-p 00013000 fd:00 15401011                           /lib/libnsl-2.5.so
00bdf000-00be1000 rw-p 00bdf000 00:00 0 
00dca000-00dd5000 r-xp 00000000 fd:00 15400986                           /lib/libgcc_s-4.1.2-20080825.so.1
00dd5000-00dd6000 rw-p 0000a000 fd:00 15400986                           /lib/libgcc_s-4.1.2-20080825.so.1
08048000-080b7000 r-xp 00000000 00:17 6455328                            /cvs/cds/caltech/apps/linux/tds/bin/tdsresp
080b7000-080ba000 rw-p 0006e000 00:17 6455328                            /cvs/cds/caltech/apps/linux/tds/bin/tdsresp
080ba000-080bb000 rw-p 080ba000 00:00 0 
0893d000-0896b000 rw-p 0893d000 00:00 0                                  [heap]
f5e73000-f5e74000 ---p f5e73000 00:00 0 
f5e74000-f6874000 rw-p f5e74000 00:00 0 
f692d000-f6931000 r-xp 00000000 fd:00 15400995                           /lib/libnss_dns-2.5.so
f6931000-f6932000 r--p 00003000 fd:00 15400995                           /lib/libnss_dns-2.5.so
f6932000-f6933000 rw-p 00004000 fd:00 15400995                           /lib/libnss_dns-2.5.so
f6956000-f6a12000 rw-p f6a31000 00:00 0 
f6a74000-f6a7d000 r-xp 00000000 fd:00 15400997                           /lib/libnss_files-2.5.so
f6a7d000-f6a7e000 r--p 00008000 fd:00 15400997                           /lib/libnss_files-2.5.so
f6a7e000-f6a7f000 rw-p 00009000 fd:00 15400997                           /lib/libnss_files-2.5.so
f6a7f000-f6a80000 ---p f6a7f000 00:00 0 
f6a80000-f7480000 rw-p f6a80000 00:00 0 
f7480000-f7481000 ---p f7480000 00:00 0 
f7481000-f7e83000 rw-p f7481000 00:00 0 
f7e83000-f7f63000 r-xp 00000000 fd:00 6236924                            /usr/lib/libstdc++.so.6.0.8
f7f63000-f7f67000 r--p 000df000 fd:00 6236924                            /usr/libAbort

 
  1747   Wed Jul 15 11:38:31 2009 robUpdateLockingMC_F channel dead

It's railed.  This is what halted locking progess on Monday night, as this channel is used for the offloadMCF script, which slowly feeds back a CARM signal to the ETMs to prevent the VCO from saturating.

 

Attached is a 5 day trend, which shows that the channel went dead a few days ago.  All the channels shown are being collected from the same ICS110B (I think), but only some are dead.  It looks like they went dead around the time of the "All computers down" from Sunday.

  1758   Thu Jul 16 14:41:38 2009 robUpdateLockingMC_F channel dead

Quote:

It's railed.  This is what halted locking progess on Monday night, as this channel is used for the offloadMCF script, which slowly feeds back a CARM signal to the ETMs to prevent the VCO from saturating.

 

Attached is a 5 day trend, which shows that the channel went dead a few days ago.  All the channels shown are being collected from the same ICS110B (I think), but only some are dead.  It looks like they went dead around the time of the "All computers down" from Sunday.

 Attached are the channels being recorded from the ICS110B in 1Y2 (the IOO rack).  Channels 12, 13, 16, 17, 22, 24, 25 appear to have gone dead after the computer problems on Sunday.

  1759   Thu Jul 16 14:54:05 2009 robUpdateLockingMC_F channel dead

Quote:

Quote:

It's railed.  This is what halted locking progess on Monday night, as this channel is used for the offloadMCF script, which slowly feeds back a CARM signal to the ETMs to prevent the VCO from saturating.

 

Attached is a 5 day trend, which shows that the channel went dead a few days ago.  All the channels shown are being collected from the same ICS110B (I think), but only some are dead.  It looks like they went dead around the time of the "All computers down" from Sunday.

 Attached are the channels being recorded from the ICS110B in 1Y2 (the IOO rack).  Channels 12, 13, 16, 17, 22, 24, 25 appear to have gone dead after the computer problems on Sunday.

 This has been fixed by one of the two most powerful & useful IFO debugging techniques: rebooting.  I keyed the crate in 1Y2.

  1762   Sun Jul 19 22:38:24 2009 robOmnistructureGeneralWeb screenshots aren't being updated

Quote:

Before heading back to the 40m to check on the computer situation, I thought I'd check the web screenshots page that Kakeru worked on, and it looks like none of the screens have been updated since June 1st.  I don't know what the story is on that one, or how to fix it, but it'd be handy if it were fixed.

 Apparently I broke this when I added op540m to the webstatus page.  It's fixed now.

  1764   Mon Jul 20 12:35:21 2009 robConfigurationLockingalignment biases funny

I found the alignment biases for the PRM and the SRM in a funny state.  It seemed like they had been "saved" in badly misaligned position, so the restore scripts on the IFO configure screen were not working.  I've manually put them into a better alignment.

  1777   Wed Jul 22 11:18:49 2009 robConfigurationComputerssticky sliders

Quote:

Quote:

Quote:

Quote:

All suspentions are kicked up. Sus dampings and  oplev servos turned off.

c1iscey and c1lsc are down. c1asc and c1iovme are up-down

 The computers and RFM network are up working again. A boot fest was necessary.Then I restored all the parameters with burtgooey.

The mode cleaner alignment is in a bad state. The autolocker can't get it locked. I don't know what caused it to move so far from the good state that it was till this afternoon.  I went tuning the periscope but the cavity alignment is so bad that it's taking more time than expected. I'll continue working on that tomorrow morning.

 I now suspect that after the reboot the MC mirrors didn't really go back to their original place even if the MC sliders were on the same positions as before.

 Alberto, Rob,

we diagnosed the problem. It was related with sticky sliders. After a reboot of C1:IOO the actual output of the DAC does not correspond anymore to the values read on the sliders. In order to update the actual output it is necessary to do a change of the values of the sliders, i.e. jiggling a bit with them.

 I've updated the slider twiddle script to include the MC alignment biases.  We should run this script whenever we reboot all the hardware, and add any new sticky sliders you find to the end of the script.  It's at

 

/cvs/cds/caltech/scripts/Admin/slider_twiddle

  1780   Wed Jul 22 18:04:14 2009 robOmnistructureComputersweird noise coming from Gigabit switch

in the rack next to the printer.  It sounds like a fan is hitting something.

ELOG V3.1.3-