40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 306 of 339  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  1563   Fri May 8 04:46:01 2009 rana, yoichiSummaryoplevsBS/PRM/SRM table bad!
We went to center the oplevs because they were far off and found that (as usual) the numbers changed
a little after we carefully centered the oplevs and came back to the control room.

To see if the table was on something soft, we tried pushing the table: no significant effect with ~10 pounds of static force.

With ~10 pounds of vertical force, however, we saw a large change: ~0.25 Oplev units. This corresponds to
~20-30 microradians of apparent optic pitch.

In the time series below you can see the effects:

2.5 s: lid replaced on table after centering.

2.5 - 11 s: various force tests on table

11 s: pre-bias by aligning beams to +0.25 in pitch and then add lid.


So there's some kind of gooey behavior in the table. It takes ~1 s to
settle after we put the lid on. Putting the laptops on the table also
has a similar effect. Please do not put anything on this table lid.
Attachment 1: a.png
a.png
  3438   Wed Aug 18 20:54:23 2010 rana, yoichiConfigurationEnvironmentChiller's chiller turned off

WE programmed the MOPA chiller's AC unit to turn off at 6PM each day and automatically turn on at 7 AM each morning. Its now very quiet in the control room at night.

Next, we'll leave it off during the day and see if it makes Steve go crazy or not.

  7169   Tue Aug 14 04:32:49 2012 rana, yoichiUpdateLockingPOX signal sometimes looks very funny

 The alignment was way off. We moved the PZT, the BS, and the x arm to get it to lock. Along the way we noticed that giving the ETM and POS offsets makes it tilt a lot. The DC coil balancing is no good at all.

After locking, we tuned up the X arm filters in the LSC and activated the filter module triggers.  I would attach a screenshot of the trigger screen, but sadly it has no snapshot button on it.

WE changed the integrator into a double integrator with a complex zero pair. We also replaced the 1:50 boost with a 2nd order complex pole:zero pair. And added a 18 Hz RG. These were all set by looking at the error point spectra and minimizing the RMS. Hopefully, this kind of work will all be obsolete once we get the optimal feedback code. For now, the arm is very stable - we're leaving it locked overnight since the filter triggering seems to work well.

The loop kept oscillating, so we turned the xarm gain down from the 0.3 that we found it at down to 0.045. We measured the loop gain using our old xarm loopgain DTT template (which is in the Templates directory, not in /users/IAmAnAmateur/secret/secret/bozo/). It shows that we are missing ~20 deg of phase at the peak of the phase bubble compared to the old days. We guess that its because of the downsample/upsample digital AA filters which we now have in addition to the 7kHz hardware AA/AI which we still have from the pre-upgrade times). We (Jamie) have to think about how to rationalize this: we cannot survive with double AA/AI.

Another big hindrance in the lock acquisition is that the whitening filters were on. Because the WG is set to 45 dB, the ADCs are getting saturated when the flashes are large. We should have the whitening filters switch after acquiring lock.

Also, why are all the camera views of the ITMs and ETMs different? Steve, please go back and make them all the same (angles, aperture, lenses, etc.). Without them being the same, we cannot compare them.

ETMXF_1028975007.bmp

ETMXT_1028975105.bmpAS_1028975166.bmp

 I have found the video capture scripts in Yuta's personal directory. This is illegal, of course. All useful scripts (even when in development) go into the shared scripts directory. As a punishment, I have added some nasty typos to a couple of his other scripts and then backdated the timestamps so that he cannot find it easily.

 Also, I fixed the "mcup" script. After the ringdown people inserted the pickoff for MC2 trans, no one adjusted the thresholds in the MC autolocker. I've fixed mcup to trigger at 7000 cts. This should be changed back if the pickoff is removed someday. MC WFS now coming on.

Attachment 1: ITMX_1028974969.bmp
  10015   Mon Jun 9 22:26:44 2014 rana, zachUpdateCDSSLOW controls recovery

 All of the SLOW computers were in limbo since the fileserver/nameserver change, but me and Zach brought them back.

One of the troubles, was that we were unable to telnet into these computers once they failed to boot (due to not having a connection to their bootserver).

  1. Needed special DB9-RJ45 cable to connect from (old) laptop serial ports to the Motorola VME162 machines (e.g. c1psl, c1iool0, c1aux, etc.); thanks to Dave Barker for sending me the details on how to make these. Tara found 2 of these that Frank or PeterK had left there and saved us a huge hassle. Most new laptops don't have a serial port, but in principle there's a way to do this by using one of our USB-Serial adapters. We didn't try this, but just used an old laptop. The RJ45 connector must go into the top connector of the bottom 4; its labeled as 'console' on some of the VME computers. Thanks to K. Thorne for this very helpful hint and to Rolf for pointing me to KT.
  2. Installed 'minicom' on these machnes to allow communication via the serial port.
  3. Had to install RSH on chiara to allow the VME computers to connect to it. Also added the names of all the slow machines in /etc/hosts.equiv to allow for password-less login. Without this they were not able to load the vxWorks binary. It was tricky to get RSH to work, since its an insecure and deprecated service. 'rsh-server' doesn't work, but installing 'rsh-redone-server' did finally work for passwordless access. Must be that linux1 has RSH enabled, but of course, this was undocumented.
  4. Some of the SLOW machines didn't have their own target names or startup.cmd in their startup boot parameters (???). I fixed these.
  5. For C1VAC1, I have updated the boot parameters via bootChange, but I have not rebooted it. Waiting to do so when Koji and Steve are both around. We should make sure to not forget doing this on C1VAC2. Steve always tells us that it never works, but actually it does. It just crashes every so often.
  6. Leaving C1AUXEX and C1AUXEY for Q and Jacy to do, to see if this ELOG is good enough.
  7. The PSL crate still starts up with a SysFail light turned on red, but that doesn't seem to bother the c1psl operation. We (Steve) should go around and put a label on all the crates where SysFail is lit during 'normal' operation. Misleading warning lights are a bad thing.

We still don't have control completely of the MC Servo board, so we need the morning crew to start checking that out

An example session (using telnet, not the laptop/serial way) where we use bootChange to examine the correct c1aux config:

controls@pianosa|target> telnet c1aux
Trying 192.168.113.61...
Connected to c1aux.martian.
Escape character is '^]'.

c1aux > bootChange

'.' = clear field;  '-' = go to previous field;  ^D = quit

boot device          : ei
processor number     : 0
host name            : chiara
file name            : /cvs/cds/vw/mv162-262-16M/vxWorks
inet on ethernet (e) : 192.168.113.61:ffffff00
inet on backplane (b):
host inet (h)        : 192.168.113.104
gateway inet (g)     :
user (u)             : controls
ftp password (pw) (blank = use rsh):
flags (f)            : 0x0
target name (tn)     : c1aux
startup script (s)   : /cvs/cds/caltech/target/c1aux/startup.cmd
other (o)            :

value = 0 = 0x0
c1aux >

  554   Mon Jun 23 19:48:28 2008 rana,albertoSummaryIOOStochMon trends (80 days)
Here's a StochMon plot showing the RFAM after the MC. Remember that in these units, 2V means no RFAM
and 0 V means lots of RFAM. Alberto says "the calibration is in Tiramisu". So there you go.
Attachment 1: e.png
e.png
  710   Mon Jul 21 19:55:16 2008 rana,jenneConfigurationIOONoise in MC_F
Jenne put the MC board on extender today - its still that way but everything is probably connected (check AO).

We measured the TFs of the DAQ section for MC_F because of how everything looked wrong in the plots Jenne
put in the log earlier. Everything we measured today seemed to jive with the schematic. We also looked up
the original traveler for this board which Betsy filled in years ago: it also is in spec for the DAQ filtering.

So then I looked at the power spectrum of the output signal to the VCO. It had lots of HFC (high frequency crap).
I adjusted the parameters of the FSS (common gain, fast gain, RF phase Astonished) and lowered the MC common gain. This
produced a global minimum in that 4D parameter space.

I think that basically, the FSS gain is too low even with the common gain slider maxed. Having the fast gain up
at 19 dB like I had left it was bad - even though it minimizes the PC control signal, it produces a lot of HFC
up around 100 kHz in MC_F. After John (finally) gets around to measuring the FSS loop we can figure out how to
better tune this. The MC gain then has to be tuned so as to best minimize the HFC given the new FSS gain; there's
basically no coupling from the MC gain to the FSS loop shape so its always best to tune the FSS first. Pleased

The RF phase of the FSS was a mystery - I have no idea why it should do anything and I have never heard of this
and I don't know why I tried it today. But...changing it by ~0.6-0.7 slider units reduced the HFC by another factor
of ~3. Somebody should put this slider into units of degrees.8-)

Here's a table of the changes. Please make these the new nominals:
you asked for:   diff 2008/07/21,13:00 2008/07/22,2:44:16 utc '.*FSS.*|.*MC.*'
LIGO controls: differences, 2008 07/21 13:00:00 utc vs. 2008 07/22 02:44:16 utc
__Epics_Channel_Name______   __Description__________   __value1____     __value2____
C1:IOO-MC_REFL_GAIN                                    22.000000        19.000000
C1:IOO-MC_REFL_OFFSET                                  0.818380         0.818100
C1:PSL-FSS_MGAIN                                       10.000000        30.000000
C1:PSL-FSS_PHCON                                       2.073170         1.413170

The attached plot shows the "SERVO" TNC output of the board; this is supposed to be the same as the voltage going to the
VCO box. So its V/Hz transfer function is flat above 40 Hz. Tomorrow Jenne will post more data and remove the extender
board.

Since I only used an SR785, I only saw noise up to 100 kHz. Its key to use an RF spectrum analyzer when checking out
the FSS and the MC systems.
Attachment 1: SCRN0024.GIF
SCRN0024.GIF
  892   Wed Aug 27 13:55:43 2008 rana,jenneUpdatePSLPMC Servo Board
Board is back in. PMC is locked.

Nominal gain is now 15 dB with brick. We need to do more studies:

  • Find out why there is still 35 MHz signal at the error point. Order some low pass filters to cut off above 35 MHz.
  • Explore brick + no-brick loop shapes and error spectra.
  • Measure and set the OLG.

We've left the copper-wrapped lead brick installed to let it slowly conform to the glass better.
  895   Fri Aug 29 02:40:43 2008 rana,jenneUpdatePSLPMC Servo Board

Quote:
Board is back in. PMC is locked.


This entry has details about the low pass filter after the PMC mixer. This filter has a few purposes:

1] Remove the beat signal (at 2*f_mod) between the PD RF signal at f_mod and the LO signal at f_mod.
2] Remove the beat signal (at f_mod) between the PD RF signal at 2*f_mod (which comes from the
beating of the upper and lower RF sidebands) and the LO signal at f_mod.
3] Remove other RF signals from non-ideal behavior of the LO drive signal and distortion in the RF PD pre-amp.


So its important to have a very good rejection at 35 MHz and higher. I used the Hartmut LC network design which is
installed on H1, H2, & L1. Since there is a high gain in the audio amps right after the mixer we have to get rid of
the RF or else we'll get slew rate limited or otherwise rectified downconversion of the RF signal into our audio band.

Of course, what everyone immediately realizes from the above 3 points, is that this filter can't protect the PMC
noise performance from homodyne mixing (e.g. 2*f_mod in the LO and 2*f_mod in the RF PD). To get around that, we're
ordering some filters from Mini-Circuits to remove the 2f from those signals by ~30 dB. As long as we install
the same filters on the RF and LO legs, there should be no significant phase shift in the demodulated signal.

The attached 2 page PDF shows the calculated before and after TFs of this filter. The 2 attached .m files
calculate the TF's and have ascii art which shows how the filter works.

Here's a comparison of the attenuation (in dB) of 2 candidate Mini-circuits filters:

f(MHz)SLP-30SLP-50
31 0.5 0.4
35 1.3 0.4
38 6.1 0.4
40 10.8 0.42
61 46.3 14.8
71 60 29
91 76.9 48
10780 60

We don't have tabulated data at the same frequencies for both filters so I just made up some of the points by eye-balling the
plots from the catalog - but you get the idea: we can get away with using the SLP-30 at 35 MHz since it only attenuates the
signals by ~1.5 dB. So if someone can find 4 of these then Steve doesn't have to order any from Mini-Circuits.
Attachment 1: pmclp-07.pdf
pmclp-07.pdf pmclp-07.pdf
Attachment 2: pmclp_40m_080824.m
% PMCLP is a TF of the IF filter after the PMC mixer
%       

% Mixer_Voltage -- Rs -- L1 --- L2 ---------Vout
%                            |      |   |
%                           C1     C2   Rl                   
%                            |      |   |
%                           GND    GND  GND
%

... 58 more lines ...
Attachment 3: pmclp.m
% PMCLP is a TF of the IF filter after the PMC mixer
%       

% Mixer_Voltage -- Rs -- L1 --- L2 ---------Vout
%                            |      |   |
%                           C1     C2   Rl                   
%                            |      |   |
%                           GND    GND  GND
%

... 57 more lines ...
  1208   Tue Dec 30 18:51:18 2008 rana,yoichiConfigurationElectronicsIlluminator Power Supply reset
We noticed that none of the illuminators were working.

The switches were off on all the ports. After turning them on it still didn't work.

The +24 V Sorensen power supply which powers all of the illuminators had its OVP light on.
We turned it off, ramped the voltage to zero, turned it back on, and then went back to +24 V.

We then checked the operation of the illuminators; ETMY is still MIA.

Each of the illuminators sucks ~0.6-0.7 A when the (unlabeled) rheostat knob panel is set
to the "25" setting.

It seems pretty unwise, in the EMI sense, to be sending Amps of unshielded, high current,
switching supply outputs for 40m down the arms. This creates a huge antenna for radiating
the switching noise. I hereby assign minus 5 points to whoever designed this system.

Illuminator Upgrade:
- Use LEDs of a wavelength that the OSEMs don't see. LEDs are also cool so that the
  Suspension won't drift in alignment.

- Use 2 power supplies so that the power is balanced.

- Make is +/-12 V twisted AWG 14 wire so that the EMI is contained. Should also
  be shielded cable.
  13278   Thu Aug 31 00:19:35 2017 rana[^r]UpdatePSLIMC/FSS FAST gain

nominal changed from 22 to 23 dB to minimize PC drive RMS

previous loop gain measurement is sort of bogus (made on SR785); need some 4395 loop measurements and checking of crossover and error point spectrum

  12937   Mon Apr 10 16:00:26 2017 rebeccaUpdateCamerasPylon installation warning

When trying to install an older version of Pylon packaged for Debian that Joe B. had sent, it gave the warning that the package was of bad quality along with the details below.

Is it safe to ignore the warning? Or should I hold off on the installation?

Lintian check results for /home/controls/Downloads/pylon-2.3.3-1.deb:
Use of uninitialized value $ENV{"HOME"} in concatenation (.) or string at /usr/bin/lintian line 108.
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/.IpConfigurator
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/.PylonViewerApp
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/.SpeedOMeter
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtBase.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtBase.so.1
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtBase.so.1.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtBase.so.1.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtStyle.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtStyle.so.1
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtStyle.so.1.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtStyle.so.1.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtWidgets.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtWidgets.so.1
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtWidgets.so.1.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtWidgets.so.1.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonViewerSdk.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonViewerSdk.so.1
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonViewerSdk.so.1.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonViewerSdk.so.1.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libQtNetwork.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libQtNetwork.so.4
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libQtNetwork.so.4.3
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libQtNetwork.so.4.3.2
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libjpeg.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libjpeg.so.62
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libjpeg.so.62.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libtiff.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libtiff.so.3
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libtiff.so.3.7.3
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/plugins/imageformats/libqtiff.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libXMLLoader_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalan-c.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalan-c.so.110
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalan-c.so.110.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalanMsg.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalanMsg.so.110
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalanMsg.so.110.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-c.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-c.so.27
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-c.so.27.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-depdom.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-depdom.so.27
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-depdom.so.27.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApiPreProcessor
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/libGCBase_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/libGenApi_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/libLog_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/libMathParser_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/liblog4cpp_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libgxapi-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libgxapi.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylonbase-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylonbase.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylongigesupp-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylongigesupp.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylonutility-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylonutility.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalan-c.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalan-c.so.110
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalan-c.so.110.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalanMsg.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalanMsg.so.110
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalanMsg.so.110.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-c.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-c.so.27
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-c.so.27.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-depdom.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-depdom.so.27
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-depdom.so.27.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/pylon/tl/pyloncamemu-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/pylon/tl/pyloncamemu.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/pylon/tl/pylongige-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/pylon/tl/pylongige.so

  12956   Fri Apr 28 18:01:56 2017 rebeccaUpdateCamerasAttempting to Load Camera Client

Using /ligo/apps/linux-x86-64/camera/bin/camera_client.py -c  /opt/rtcds/caltech/c1/scripts/GigE/SnapPy/L1-CAM-MC1.ini, the Python script was able to run without error but didn't show any video feed from the camera in GStreamer. Problem might be in the configuration of the camera in the .ini file.
 

  12989   Fri May 12 18:45:04 2017 rebeccaUpdateCamerasMC2 Pics with Olympus

Raw and JPG formats of the pictures are saved on the Mac in the control room and at this link:

https://drive.google.com/open?id=0B9WDJpPRYby1c2xXRHhfOExXNFU 

The camera was mounted using the JOBE arm wrapped around a small heavy piece of metal. The lights were kept on, the camera was zoomed in as closely as possible (so the light would take up most of the frame), F number of 8 was used, and shutter speeds from 1/2 to 1/100 seconds were used. 

The pictures still look a bit blurry, probably because looking back at the details of the image, the focal length was 86.34m (as short of a focal length would be ideal, and Olympus is capable of going down to 1m).

Next steps include looking at the saturation in the pictures and setting up a more stable mount. 

  7854   Tue Dec 18 16:44:00 2012 rijuUpdate Photodiode transimpedance

Today I measured the dark current of the PDA10CF. The output of the PD was connected to the A channel of the network analyzer, when there was no light falling on it. The response is collected using GPIB.

I will upload the result shortly.

  14880   Mon Sep 16 11:55:58 2019 rikaUpdateIOOWFS loop measurements

[rika, aaron]

We aligned optics of WFS as it was. Now auto-locker is working to lock MC.

But it still doesn't lock. We notice that the c1lsc machine doesn't work. So we run rebootCILSC.sh.

 

Now we reset the hardware!

 

17:11

After reset, auto locking didn't work well. Gautum and Aaron reboot slow c1ioo. Then it works, and Gautam returned the MC to a good alignment.

We found the beam is not in the center of the QPD, we (turned off the MC autolocker and MC loop, then) realigned to make beam to get in to the QPD center. Afterwards we start auto locking.

With the WFS on, the maximum MC transmission we observe is 14,700 counts; after the transmission level stabilizes (MC_TRANS pit and yaw brought to 0), the MC transmission is only 14,200 counts. Perhaps the MC_TRANS QPD offsets need adjustment. We relieve the WFS servo of its DC offsets. This is the configuration we'll use for WFS loop measurements this week.

  14888   Tue Sep 17 10:47:44 2019 rikaUpdateIOOWFS loop measurements

[aaron, rika]

Once stop the auto-locker and realigned to make beam to get into QPD again.

After we lock MC, we took TFs from suspension MC1/2/3 PIT/YAW to WFS1/2 PIT/YAW. 

----- 

Diagnotics test tools

range: 7 Hz to 50 Hz

 avarage=61

Column 0: WFS2_PIT   1: WFS2_YAW   2:WFS1_PIT   3: WFS1_YAW   4: TRANCE_PIT   5:TRANCE_YAW 

-----

I'm wondering weather the MC1data I saved is correct, becouse I found the channel was changed when I exported MC2 data. So I took MC1 data again.

 

We got all data for TFs already.  Each data is devided to real part and imaginary part. Then we are arranging the datas to obtain TFs. 

TF of MC2 is attachiment 1. So tomorrow, I make other TF.

Quote:

[rika, aaron]

We aligned optics of WFS as it was. Now auto-locker is working to lock MC.

But it still doesn't lock. We notice that the c1lsc machine doesn't work. So we run rebootCILSC.sh.

 

Now we reset the hardware!

 

17:11

After reset, auto locking didn't work well. Gautum and Aaron reboot slow c1ioo. Then it works, and Gautam returned the MC to a good alignment.

We found the beam is not in the center of the QPD, we (turned off the MC autolocker and MC loop, then) realigned to make beam to get in to the QPD center. Afterwards we start auto locking.

With the WFS on, the maximum MC transmission we observe is 14,700 counts; after the transmission level stabilizes (MC_TRANS pit and yaw brought to 0), the MC transmission is only 14,200 counts. Perhaps the MC_TRANS QPD offsets need adjustment. We relieve the WFS servo of its DC offsets. This is the configuration we'll use for WFS loop measurements this week.

 

Attachment 1: MC2.pdf
MC2.pdf
  14896   Wed Sep 18 14:45:52 2019 rikaUpdateIOOWFS loop measurements

[aaron, rika]

Gettng TFs

In the data we got yesterday, we can see some filter's effect. 

But it is not good coherence above 10Hz, so we mesured again. And this time we save the data as xml file.

And also we chaned the frequency regions broader to watch corner frequency of suspension.

-----

 Diagnotics test tools

 range: 0.1 Hz to 100 Hz

 points: 120 

 Amplitude: 1000

----

but at low frequency, the mode maching cavity was unloked cause of too much shaking.

So, we saw single frequency TF, and searched the good amplitude.

 

First, I tried to get TF @0.1~1 Hz .

-----

0.1 to 1 Hz

points: 61 (I think it's too much becous it takes about an hour)

amplitude: 5

-----

The TFs and coherence of MC1/PIT to each QPD is below. [above window: coherence, below: TF]

During the mesurement, something happened @0.2-0.3Hz so I stopped it.

We found the coherence of WFS1P and WFS2Y is not good, but others are good.

we guess that it could come from alignment which made Q chainging to small.

 

Finaly, I also got the  .xml data of MC1P 1 Hz to 10 Hz. In this time,

-----

1 to 10 Hz

points: 41 

amplitude: 90

-----

 

Making matrics

Now we took single frequency 6 TFs (MC1/2/3 PIT/YAW) @7Hz (Because this frequency has good coherence in all channel).

Aaron wrote the script using dtt to making matrics. 

 

 

Quote:

[aaron, rika]

Once stop the auto-locker and realigned to make beam to get into QPD again.

After we lock MC, we took TFs from suspension MC1/2/3 PIT/YAW to WFS1/2 PIT/YAW. 

----- 

Diagnotics test tools

range: 7 Hz to 50 Hz

 avarage=61

Column 0: WFS2_PIT   1: WFS2_YAW   2:WFS1_PIT   3: WFS1_YAW   4: TRANCE_PIT   5:TRANCE_YAW 

-----

I'm wondering weather the MC1data I saved is correct, becouse I found the channel was changed when I exported MC2 data. So I took MC1 data again.

 

We got all data for TFs already.  Each data is devided to real part and imaginary part. Then we are arranging the datas to obtain TFs. 

TF of MC2 is attachiment 1. So tomorrow, I make other TF.

Quote:

[rika, aaron]

We aligned optics of WFS as it was. Now auto-locker is working to lock MC.

But it still doesn't lock. We notice that the c1lsc machine doesn't work. So we run rebootCILSC.sh.

 

Now we reset the hardware!

 

17:11

After reset, auto locking didn't work well. Gautum and Aaron reboot slow c1ioo. Then it works, and Gautam returned the MC to a good alignment.

We found the beam is not in the center of the QPD, we (turned off the MC autolocker and MC loop, then) realigned to make beam to get in to the QPD center. Afterwards we start auto locking.

With the WFS on, the maximum MC transmission we observe is 14,700 counts; after the transmission level stabilizes (MC_TRANS pit and yaw brought to 0), the MC transmission is only 14,200 counts. Perhaps the MC_TRANS QPD offsets need adjustment. We relieve the WFS servo of its DC offsets. This is the configuration we'll use for WFS loop measurements this week.

 

 

Attachment 1: Screenshot_from_2019-09-18_18-15-34.png
Screenshot_from_2019-09-18_18-15-34.png
  15   Thu Oct 25 22:02:58 2007 robRoutinePSLHEPAs maxed
In light of the SoCal fires, I turned the PSL HEPAs up to 100%.
  40   Wed Oct 31 15:22:59 2007 robConfigurationIOOMode Cleaner transfer function
I measured the transfer function of the input mode cleaner using a PDA255 and the ISS. First I put the PD in front of the ISS out-of-loop monitor diode and used an SR785 to measure the swept sine transfer function from the Analog IN port of the ISS to the intensity at the PD. Then I moved the PD to detect the light leaking out from behind MC2, using ND filters to get the same DC voltage, and measured the same transfer function. Dividing these two transfer functions should take out the response of the ISS and the PD, and leave just the transfer function of the MC. A plot of the data, along with a single-pole fit, are attached.

The fit is pretty good for a single pole at 3.79 kHz. There's a little wiggle around 9kHz due to ISS weirdness (as Tobin has not been giving it the attention it requires), but this shouldn't affect this result too much. Using the known MC length of 27.0955m, and assuming that MC1 and MC3 have a power transmissivity of 2000ppm and MC2 is perfectly reflecting, the total round trip loss should be about 300ppm. The fitted finesse is 1460.
Attachment 1: MCtf.pdf
MCtf.pdf
  67   Tue Nov 6 10:42:01 2007 robConfigurationIOOmode cleaner locked
Increased the power exiting the PSL by turning the half-wave plate after the MOPA, opened the PSL shutter, and aligned the mode cleaner to the input beam. It wasn't that hard to find the beam with the aperture open all the way on the MC2 camera. The transmitted power is now 2.9 arbitrary units, while the input power is 1.2 arbitrary units. Not sure yet if that's an increase or decrease in efficiency, since no one posted numbers before the vent. Also turned on the input-steering PZTs and saw a REFL beam on the camera.
  69   Tue Nov 6 15:36:03 2007 robUpdateLSCXARM locked
Easily, after resetting the PSL Uniblitz shutters. There's no entry from David or Andrey about the recovery from last week's power outage, in which they could have indicated where the procedure was lacking/obscure. Tsk, tsk.
  70   Tue Nov 6 15:37:34 2007 robConfigurationSUSrampdown script
/cvs/cds/caltech/scripts/SUS/rampdown.pl is now in the crontab for op340m, running every half-hour at 15&45. It checks the suspension watchdog trip levels, and reduces them by 20 if they are above 150.
  78   Wed Nov 7 13:54:44 2007 robConfigurationIOOMode Cleaner transfer function
I performed the same procedure described here, and re-measured the transfer function of the mode cleaner to see the effect of the drag-wiping. The results are attached in a pdf. We don't seem to have done any damage, but the improvements are barely measurable.

WhatThenNow
pole frequency3.789kHz3.765kHz
loss per optic99ppm91ppm
finesse14601470
trans86.7%87.7%
Attachment 1: mctf.pdf
mctf.pdf
  89   Fri Nov 9 17:33:33 2007 robConfigurationPSLISS

The 3.7 MHz is actually on the light. It's the beat between the 29.5 MHz sidebands and the 33.2 MHz sidebands. There are pads in the ISS PCB for a filter to notch this frequency--John is working on it.

I also found a 1.2 ND filter on the lens which focuses the beam on the ISS diodes. I replaced it with a 0.6 ND filter, which brought the ISS DC level (on the screen) up to ~4.2 (it saturates at 5). Once John finishes the filter we should be able to crank up the gain.
  90   Fri Nov 9 21:36:14 2007 robConfigurationPSLFSS
rob, rana

We looked at the FSS a bit today. The most we could get out of it with the gain sliders was a UGF of around 95kHz. After a bit of tweaking the waveplate after the AOM, this got up to ~115kHz. We should be able to get at least 500kHz. This system needs a fair amount of work.
  94   Mon Nov 12 14:09:19 2007 robDAQGeneraltpman dead on fb40m
The testpoint manager was dead on fb40m. I know I re-started it sometime after the power outage, so something must have killed it. If you get an error from DTT like
"diagnostic kernel does not support: testpoints", then log into fb40m as root, check for the tpman with a ps -ef | grep tpman. If it's not there, then run /usr/controls/tpman & and close the terminal window.
  95   Mon Nov 12 15:05:49 2007 robConfigurationPSLFSS

Spent a bit of time fiddling with the FSS again today. In a not-particularly-systematic manner, I raised the input-side of the 21.5MHz PC, adjusted the half-wave plate in front of it, touched up the RC alignment and the alignment onto the transmitted and reflected diodes. This got us a ~15% increase in
transmitted light, and I was able to push the UGF to 140kHz with the common gain slider at 30dB and the FAST gain slider at 22dB. The next options include adjusting the AOM setup, mode matching into the RC, and just increasing the pickoff fraction right from the getgo.
  96   Mon Nov 12 15:18:34 2007 robUpdatePSLISS

After John soldered a 3.7 MHz notch filter onto the ISS board, I took a quick TF and RIN measurement. The out-of-loop RIN is attached, including a dark noise trace, and with the gain slider at 10dB. The UGF is 35kHz with a phase margin of 30deg. John is currently doing a more thorough inspection, and will detail his findings in a subentry.
Attachment 1: ISS.png
ISS.png
  121   Wed Nov 21 14:31:41 2007 robUpdatePSLFSS twiddle

I `tweaked' the FSS path today. Here's what I did:

1) Shut down the FSS autolocker

2) Turn off FSS servo

3) Assume the beam coming back from the AOM is double-first-order, and don't make any changes large enough to lose it.

4) Tweak the alignment of these components to maximize the incident power on the RC reflected diode:

a) PBS before AOM
b) AOM
c) curved mirror after the AOM

5) Translate the AOM such that the beam moves away from the PZT, then when it levels off (no more power gains with movement),
move it back just a little bit so there's a teensy drop in power. This should but the beam as close to the edge as possible,
but whether or not it's the best place is still to be determined.

6) Lock the FSS, and align the mirrors into the frequency reference cavity.

After all this, the RC transmitted power went from .57 to .73 -- probably not a big enough change to account for the missing loop
gain, but we'll know more once the loop gets measured (after Alberto stops hogging the Agilent network analyzer).

Other possible routes include a systematic check of the upstream path (e.g., the Pockels cell) and just increasing the pickoff fraction for the FSS.
  124   Tue Nov 27 15:45:08 2007 robConfigurationPSLFSS loop

It's unclear (to me, at least) what was the end result of the FSS path tweaking before Thanksgiving. Today I measured the open loop gain, and it was still around 100kHz, even with the gain sliders maxed out, but it looked really crappy with a sharp cutoff around the UGF. Then, on a lark, I pushed around the "Input Offset Adjust" slider, which sums an offset into the signal coming out of the mixer. By moving this slider to 7V, I got the UGF to 500kHz with 45 deg of phase. That would be fine, and we could go offset hunting, but the same thing happens if one puts in a large negative value! I don't really understand what's going on, but it seems like weirdness in the electronics. Unfortunately the web interface to the conlog is not running (presumably because the `new' linux1 doesn't have its apache server running) and my command line conlog efforts have been stymied. So, I don't know what the historical settings of this offset are, but zero is definitely not a good setting right now. Here's a snapshot:

FSS
UGF: 500kHz
CG : 24dB
FG : 19dB
input offset: 7V
Phase Adjust: 1.09V
Phase Button: 0
RF Amp Adjust: 7.38V

margins:
phase: 45 deg
gain: 8dB
Attachment 1: FSSsmall.jpg
FSSsmall.jpg
  125   Tue Nov 27 15:47:17 2007 robConfigurationIOOMC loop
After the FSS running pretty quick, I checked the MC loop. I used TPA 1&2.

MC loop
UGF: 70kHz
Input Gain: 29dB
Boost Level: 2
phase: 40 deg
Attachment 1: MCsmall.jpg
MCsmall.jpg
  126   Tue Nov 27 16:18:58 2007 robConfigurationIOOMC loop
Reduced the common gain to 22dB in the mcup script, so that the WFS would not blow the lock. The above measure of the OLG was done without the mcWFS running, so may be a low estimate as compared to when the alignment is perfect.
  134   Wed Nov 28 17:41:34 2007 robUpdatePSLFSS again
I investigated the FSS a bit more today. I looked at the signals coming out of the FSS frequency reference, and saw that both the LO and PC drive were distorted, non-symmetric waveforms. In addition, the LO path had a 3dB attenuator, meaning the mixer was starved. I placed mini-circuits SLP-30 filters in both paths, and now both are nice sine waves. I also took out the 3dB att. With this work, and the CG slider maxed out at 30, the FSS open loop gain (for real this time) goes up to ~250kHz. Still needs more investigation.
  139   Thu Nov 29 11:10:54 2007 robOmnistructureVACRGAlogger sleeping
Without the RGA controller responding, the RGAlogger script just hangs. Rather than fix it, I just put it to sleep by commenting out the line in op440m crontab file. Once we get it running again, we'll move the cronjob to op340m.
  141   Thu Nov 29 15:17:53 2007 robConfigurationPSLISS

I put some ISS beam on the diode on the PSL table. In the previous layout, this was the monitor diode (and it's labeled monitor) but I plugged it into the sensor jack anyways so we can run with the loop closed for now; we can just switch the cables later. The reason the beam was unclear is because someone popped up a flipper mirror which redirects the beam from the ISS into an OSA.

With the ISS gain slider at 15 dB the UGF is around 40kHz.

Why do we have such short cables for the ISS diodes?
  145   Fri Nov 30 11:44:57 2007 robConfigurationElectronicsETMX oplev
In the interests of getting the Xarm alignment script working again, I reset the local damping gains for the test masses to their previous known working values (1), then I noticed that the ETMX oplev was dead. Since the scripts use the oplev motion as a readback for the optic motion, this means the script was basically blindly swinging the optics around. Some monkeying around with swapping HeNe power supplies eventually led to the conclusion that the power strip is funky, since the laser works when plugged into another power strip. Even weirder, the HeNe and the power supply indicator light have some sort of XOR relationship going on. When one works, the other doesn't. Steve will sort out this confusion later; we're good for now.
  146   Fri Nov 30 13:46:50 2007 robConfigurationElectronicsETMX oplev dead again

Quote:
In the interests of getting the Xarm alignment script working again, I reset the local damping gains for the test masses to their previous known working values (1), then I noticed that the ETMX oplev was dead. Since the scripts use the oplev motion as a readback for the optic motion, this means the script was basically blindly swinging the optics around. Some monkeying around with swapping HeNe power supplies eventually led to the conclusion that the power strip is funky, since the laser works when plugged into another power strip. Even weirder, the HeNe and the power supply indicator light have some sort of XOR relationship going on. When one works, the other doesn't. Steve will sort out this confusion later; we're good for now.


Ech. The HeNe quit again. Let's replace it and see what happens.
  175   Thu Dec 6 18:11:15 2007 robHowToComputer Scripts / ProgramsMaking DMF monitors

I was able to use the matlab compiler to compile a version of the linetracker written by Rana, and run the compiled version on mafalda.

I believe I made the necessary edits to our mDV config file so that it should be easy for others to follow these steps:

1) Write the DMF routine you want, as a matlab function (not a script).

2) If it runs correctly in matlab, then from the matlab command line compile
it using the -m flag (i.e., mcc -m myfun.m). You should run the
compiler from the directory where you want the executable to end up (don't use the mDV/extra
directory so it doesn't get all cluttered).

3) prior to running the resulting executable (which should be called simply myfun),
prepend the directories
/cvs/cds/caltech/apps/linux/matlab/bin/glnx86
/cvs/cds/caltech/apps/linux/matlab/sys/os/glnx86/

to the LD_LIBRARY_PATH enviroment variable. These directories must be prepended as the
versions that already exist in /usr/lib don't work; I'm loathe to do this in the cshrc.40m
for fear of later conflicts, so it will need to be done in some sort of shell script which
calls the matlab executable.
  180   Fri Dec 7 14:14:48 2007 robMetaphysicsComputer Scripts / Programstdsread problems on Solaris

tdsread has developed a strange new illness, whereby it cannot read EPICS values from two subsystems at once (e.g., getting an LSC and SUS value simultaneously). I thought this might have something to with the fact that both losepics and iscepics are running on the same box,
but the same thing happens with IOO EPICS records, so that's not the culprit.

This is new behaviour, and it's only happening on the solaris machines. I suspect some ENV/cshrc juju has caused it, as the tdsread executable is the same one from April, and I don't think our EPICS infrastructure has changed otherwise. In the near term we can either try running the scripts on linux, or modify the IFO scripts to not do these types of calls.
  184   Mon Dec 10 13:54:26 2007 robHowToComputer Scripts / ProgramsDon't blame the Matlab compiler

For human error. We should be careful to only run the compiler outside the mDV directory (thus placing the _mcr outside of the range the addpath command in the mdv_config files). Or maybe there's a smarter solution...
  224   Thu Jan 3 12:38:49 2008 robBureaucracyTMISore throat

Quote:

I did not feel anything wrong yesterday, but unfortunately I have a very much sore throat today. I need to drink warm milk with honey and rinse my throat often today. So far I do not have other illness symptomes (no fever), so I hope that this small disease will not last for a long time, but I feel that it is better for me to cure my sore throat today at home (and probably it is safer for others in 40-m).

I took yesterday the book "Digital Signal Processing", so I have it for reading at home.

Hope to see you tomorrow.


I've added a new category--TMI--for entries along these lines.
  240   Wed Jan 16 14:06:24 2008 robUpdateLSCmonday's locking
rob, tobin, johnnie

We did some locking work monday night, with decent progress. Working in the PRFPMI style, we managed to get through the part of the script that hands off the offset-CARM DOF to the MCL, but were not successful in engaging the AO path.

We also confirmed the problem with tdsread which prevent it from reading from multiple TLS (Three Lettered Subsystems) at the same time. Tobin traced this to a problem with the ezca library which tds uses, but it's not clear how to fix it. For now we just split the tdsread calls so that there are no multiple TLS calls. Tobin will report further on this.
  241   Wed Jan 16 14:09:45 2008 robUpdateLSCtuesday's locking

I got a little further with the locking (PRFPMI) last night, after discovering that the cable going from the CM board to the MC board was unplugged at the MC side. This explains why we weren't able to engage the AO path last night. Tonight, I got up to the point where DARM is handed off to OMC transmission, a step which repeatedly failed.
Eventually I realized that although all the lights are the green, the OMC Trans signal was not being updated in the LSC's memory. I suspect this is because the c1ass machine was powered down. Work continues.
  244   Thu Jan 17 14:13:20 2008 robUpdateLSCWednesday's locking
Incremental progress on locking yet again. This time the handoff of DARM to the OMC worked, and progress halted at handing off control of the common mode to REFL166.
  249   Fri Jan 18 15:31:47 2008 robUpdateLSCThursday's locking

rob, johnnie, andrey

On Thursday night we got the intereferometer fully locked in a power-recycled FPMI state. The obstacles included the REFL166 phase being wrong by 180 deg (because that's the correct phase for DRMI locking) and getting confused (again) by the "manual" mode dewhite switching at the ETMs. After turning on the dewhites and the MICH correction, we took the noise spectrum below.
Attachment 1: DARMnoise080118.png
DARMnoise080118.png
  252   Tue Jan 22 02:33:45 2008 robUpdateLSCDRMI work

0) The ETMY oplev needs work/centering

1) recentered DRMI oplevs

2) Did some light DRMI locking. Looked at the loops and the DD signals. The PODD signals look flaky; the beam may not be on the diode. MICH and PRC handoffs to DD signals were spotty, but not a total disaster. Changed the PD9 phase by 115 degs. Work continues on the DD_handoff subscript.

3) John says "There are ants everywhere."

4) Andrey is now versed in the arts of decimation.
  263   Fri Jan 25 08:55:26 2008 robConfigurationGeneralChanges to Dataviewer channels (XARM)

As a general rule,


Quote:
clicking random blue buttons chaotically


is not a good problem solving technique. It is thus now explicitly discouraged as an option in the LIGO 40m Lab.
  265   Fri Jan 25 10:14:35 2008 robConfigurationSUSChanges to Dataviewer channels (XARM)

Quote:

2) BAD NEWS. While "clicking the appropriate blue button" on the DAQ MEDM screen,
namely CODAQ_DETAIL,adl screen, I obviously clicked some blue button that I should not have clicked,
and as a result the signal in Dataviewer from the channel "C1:SUS-ITMX_POS" has disappeared (it is now a straight line).


Description of what has happened and of my wrong actions:
I had two channels opened in Dataviewer simultaneously (both "C1:SUS-ETMX_POS" and "C1:SUS-ITMX_POS"),
and after clicking some blue button on CODAQ_DETAIL,adl screen, the signal from "C1:SUS-ITMX_POS" became
a straight line,
while signal from "C1:SUS_ETMX_POS" continued to be a random noise.

I was scared that I made worse for the channels and for Dataviewer, and I started clicking random blue buttons chaotically hoping that it will restore the signal from "C1:SUS-ITMX_POS". Random clicking on arbitrary blue buttons did not return the signal.

As the channel "C1:SUS-ETMX_POS" works normally, I will be measuring Q-factors of ETMX tonight,
but it is obvious that someone else (Rana, Robert,Steve?) needs to restore the correct settings for "C1:SUS-ITMX_POS".

Moreover, as I was clicking chaotically all the blue buttons on CODAQ_DETAIL,adl screen, someone else (Rana, Robert, Steve?) will need to check somehow that I did not destroy signals from some other channels.

I apologize for the negative consequences of my channel adding,

but Rana asked me in the very beginning in September to let others know if I spoil something, so that others would be aware of it and could fix the problem.


I eventually resolved the situation by restarting the c1susvme1 processor, which had somehow got confused by the clicking random blue buttons chaotically. The data acquisition should be working again.
  280   Mon Jan 28 15:11:38 2008 robHowToDMFrunning compiled matlab DMF tools

I compiled Rana's seisBLRMS monitor, and it's now running on mafalda. To start your own DMF tools, here is a procedure:

1) build your tool in mDV, get it working the way you'd like.
2) Make a new directory /cvs/cds/caltech/apps/DMF/compiled_matlab/{your_new_directory} and copy the *.m file there.
3) Make the *.m in your new directory into a function with no args (just add a function line at the top)
4) compile it (from within a fully mDV-configured matlab) with mcc -m -R -nojvm {yourfile}.m at the matlab command line.
5) add a line corresponding to your new tool to the script /cvs/cds/caltech/apps/DMF/scripts/start_all
6) Run the start_all script referenced in part (5).

NB: Steps (4) and (6) must be carried out on mafalda.
  284   Tue Jan 29 14:56:39 2008 robUpdateDMFseisBLRMS 1.0

The seisBLRMS 1.0 program crashed at ~7:20 pm last night, so we didn't get data from overnight. It crashed when framecaching failed. I added
a try-catch-end statement around the call to dttfft2 to let the program survive this, then compiled it and started it on mafalda. After ~45 minutes, the compiled version encountered the same error, and while it didn't crash per se, after 20 minutes it still wasn't able to read data. We may have to dig deeper into the guts of mDV to make this stuff run more robustly.
ELOG V3.1.3-