40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 167 of 330  Not logged in ELOG logo
ID Date Author Type Category Subject
  8233   Tue Mar 5 17:23:06 2013 ChloeUpdate QPD Adding/Subtracting Circuit

Today I finished building the adding/subtracting circuit for the QPD and tested that the QPD could see a laser moving across its visual field for both pitch and yaw. It didn't seem to behave weirdly (saturate) at the edges, but I need to test this more carefully to be sure.

However, this circuit uses many op amps, which will cause problems for building the actual circuit to fit into the QPD box. I am trying to figure out how to do this with fewer op amps (both with a quad op amp for amplifying the signals from the QPD and by summing/subtracting the signals with a single op amp instead of 3).

I finally got around to asking Steve to order more breadboards! Trying to determine what would be a good QPD to order for the final circuit, since we do not have any unmounted QPDs that aren't ancient. I'll read up on things I don't know enough about (namely op amps).

  8232   Tue Mar 5 17:09:30 2013 yutaUpdateSUSoplev calibration for ITMY

[Manasa, Sendhil, Yuta]

We calibrated oplev for ITMY. Calibration factor for C1:SUS-ITMY_OL(PIT|YAW)_IN1 are;
  OLPIT: 6.29 +/- 0.11 counts/mrad
OLYAW: 5.74 +/- 0.09 counts/mrad

Note that there was ~10% of coupling between pitch and yaw.
This is large considering statistical error, but I think this is from QPD mounted rotated (by ~5 deg).

  Same as in elog #8221.

moved in y: ITMY_PIT.png      moved in x: ITMY_YAW.png

micrometer    OLPIT          OLYAW
moved in y    3.14 +/- 0.05  0.27 +/- 0.03
moved in x   -2.87 +/- 0.04  0.17 +/- 0.03    (counts/mm)

  Measured the path length of ITMY oplev returning beam was 2000 +/- 20 mm. This gives you the calibration factors above.

  ~10 % coupling between OLPIT and OLYAW can be explained by QPD rotation by ~ 5 deg, which seems not unreasonable.

  8231   Tue Mar 5 14:59:32 2013 SteveHowToVACdry-forepump replaced

TP3 turbo pump's dry-foreline pump was replaced.

How to do it:

The pump should be replaced when it's performance  <1.0 - 1.3 Torr

Set up valve configuration as shown at Atm1: close in this order VAEE, VASV, VABS, VASV, VASE, VA6 and V5,

Turn TP3 off at it's controller in the rack. Wait till is stops, so you can read 760 Torr at TP3 foreline gauge

Disconnect intake, exhaust vacuum seals and replace pump. Reconnect vacuum fitting and start it up.

Confirm operational details on the front of the controller: 50 K_RPM, 0.2A and <100 mTorr

Reset valves in reverse order

PS: the average life of the tip seal on the Varian SSH-110 dry-pump is about 1 year

      This pump " ser LP1007L556 " seal  made new record of 668 days: thanks to Bob Taylor who is replacing these seals


Attachment 1: changingforepump.png
Attachment 2: TP3wFp600.jpg
  8230   Tue Mar 5 06:27:14 2013 yutaUpdateLSCintra-cavity power dependence on mirror misalignment

I measured intra-cavity power dependance on mirror misalignment.
Intra-cavity power of PRC in PRMI degrates roughly 20 % when there's 0.5 mrad 5 urad misalignment. (edited by YM)
Currently, PRMI lock is not so stable, so it is hard to do this measurement and error bars are huge.

Measurement method:
  0. Align the cavity and lock.
  1. Misalign one optic and measure oplev output value and intra-cavity power.
  2. Also, dither the optic in pitch or yaw in 8.5 Hz and get demodulated amplitudes at 8.5 Hz of oplev output and intra-cavity power using tdsdmd.
  3. Misalign the optic again and do the same things.

  1. gives intra-cavity power dependence on mirror misalignment directly, but 2. should give better S/N because of dithering.

  /opt/rtcds/caltech/c1/scripts/dither/dithergfactor.py does these things, and ./plotgfactor.py plots the result.
  They work quite well, but it should be made better so that

  - it checks if the cavity is locked
  - automatically change the oplev calibration factor for each optic
  - automatically adjusts the region and modulation amplitude
  - read data with better error evaluation


PRMI alignment:
  Y green looks like it drifted quite a lot somehow. If we start aligning Yarm to Y green, we get AS and POP beam at different spot on camera compared with last week. Also, TRY and TRX only goes as high as ~0.7. Since we have A2L now (elog #8229), let's start using Yarm spot positions as input pointing reference.

PRMI locking details:
  Same as in elog #8212, but I changed gains in the lock acquisition mode.

  == PRMI carrier ==
  MICH: AS55_Q_ERR, AS55_PHASE_R = -12 deg,  MICH_GAIN = -0.2, feedback to ITMX(-1),ITMY(+1)
  PRCL: REFL55_I_ERR, REFL55_PHASE_R = 70 deg, PRCL_GAIN = 1.0, feedback to PRM

  I made gainx5 in LSC_MICH filter bank so that it increases the overall gain when locked by trigger.
  I also made gainx0.3 in LSC_PRCL filter bank so that it reduces the overall gain when locked by trigger.

Result for PRC in PRMI:
  For PRMI, I couldn't done dithering method because dithering takes time to measure and I could not hold PRMI locking during the measurement.
  Below is the result when reading just the DC values. Mirror angle is calibrated by oplev (elog #8221). Error bars are huge because of beam motion mainly in yaw.

PRM in pitch: PRM_PIT_20130305a.png    PRM in yaw:PRM_YAW_20130305b.png

Results for the arms:
  For the arms, I could do both in DC and dithering. Below are the results, but ITMs misalignments are not calibrated because we don't have calibrated oplev yet.
  Results for the arms can be used to verify this method because we know g-factors of the arms from mode scan.

ITMX in yaw: ITMX_YAW_20130305.png    ITMY in yaw: ITMY_YAW_20130305.png

By the way:
  I found C1:SUS-ITMY_LSC_GAIN is somehow set to be 2.895 recently. I think this should be 1.0. Maybe this is why we had actuation imbalance in ITMs(elog #8212).

 - more stable lock
 - calibrate ITM oplevs to apply this method to the arms
 - derive g-factor from these measurements
 - measure PRM angular motion spectra using calibrated oplev

  8229   Tue Mar 5 01:43:04 2013 JenneUpdateASSArm A2L measurement script finished

In either .../scripts/XARM or ...../scripts/YARM run either A2L_XARM or A2L_YARM.

The wrapper script will, like the MC script, open a striptool so you can monitor the lockin outputs, setup the measurement, run the measurement, including misbalancing coils on the optics for calibration, and then calculates the spot positions.  It records the measurement in a log file in /data_spotMeasurements under each arm's directory.  The wrapper script then runs the plotting script which reads the logfile, and plots all past measurements.

Here is that plot for the Yarm:


The first two points were measured within a few minutes of eachother, the third set of points was after input pointing adjustment during IFO alignment.  Clearly the pointing that optimized the cavity transmission (trying to leave the test mass mirrors alone, and only moving TT1 and TT2) does not also give the best spot centering.  I claim that this is a result of the arm being aligned to the green beam, which was never locked to the 00 mode when we were at air.  This is a lesson learned....take the time to deal with the green beams.

  8228   Tue Mar 5 00:24:52 2013 ManasaConfiguration40m UpgradingEndtable upgrade for auxiliary green laser : customized mount

 Drawing of customized mount for endtable doubler crystal (PV40+PVP2+NP9071) modified and updated on the endtable upgrade wiki page.

  8227   Mon Mar 4 21:05:49 2013 Max HortonUpdateSummary PagesMultiprocessing and Crontab

Multiprocessing:  In its current form, the code uses multiprocessing to the maximal extent possible.  It takes roughly 2600 seconds to run (times may vary depending on what else megatron is running, etc.).  Multiprocessing is only used on the process_data() function calls, because this by far takes the longest.  The other function calls after the process_data() calls take a combined ~120 seconds.  See http://nodus.ligo.caltech.edu:8080/40m/8218 for details on the use of Multiprocessing to call process_data().

Crontab:  I also updated the crontab in an attempt to fix the problem where data is only displayed until 5PM.  Recall that previously (http://nodus.ligo.caltech.edu:8080/40m/8098) I found that the crontab wasn't even calling the summary_pages.py script after 5PM.  I changed it then to be called at 11:59PM, which also didn't work because of the day change after midnight.

I decided it would be easiest to just call the function on the previous day's data at 12:01AM the next day.  So, I changed the crontab.

Previous Crontab:

59 5,11,17,23 * * * /users/public_html/40m-summary/bin/c1_summary_page.sh 2>&1

New Crontab:

0 6,12,18 * * * /users/public_html/40m-summary/bin/c1_summary_page.sh 2>&1
1 0 * * * /users/public_html/40m-summary/bin/c1_summary_page.sh $(date "+%Y/%m/%d" --date="1 days ago") 2>&1

For some reason, as of 9:00PM today (March 4, 2013) I still don't see any data up, even though the change to the crontab was made on February 28.  Even more bizarre is the fact that data is present for March 1-3.  Perhaps some error was introduced into the code somehow, or I don't understand how crontab does its job.  I will look into this now.


Once I fix the above problem, I will begin refactoring the code into different well-documented classes.

  8226   Mon Mar 4 20:03:42 2013 AnnalisaHowToCOMSOL TipsStudy of mirror mount eigenfrequencies

 I studied the eigenfrequencies of a mirror mount designed with COMSOL.

I imposed fixed constraints for the base screws and for the screw connecting the base with the pedestal. Note that the central screw is connected to the base only for a small thickness, and the pedestal touches the base only with a thin annulus. This is in way to make a better model of the actual stress.

Shown in fig. 2 is the lowest eigenfrequency of the mount.

I' going to change the base and study the way the eigenfrequency vary, in way to find the configuration which minimizes the lowest eigenfrequency.


Attachment 1: MirrorSupport1.png
Attachment 2: MirrorSupportEig1.png
Attachment 3: pedestal.png
Attachment 4: Base2.png
  8225   Mon Mar 4 19:52:03 2013 Jamie, YutaUpdateGeneralinput pointing mirror (TT1/TT2) control improved

We improved the active tip-tilt (TT) controllers such that they now have filter banks at the PIT/YAW inputs, and at the coil outputs:


This allowed us to do a couple of things:

  • normalize the matrix to unity, and move overall gains into the filters (we moved x100 gain into PIT/YAW)
  • slider control is now PIT/YAW OFFSET
  • potentially do coil balancing
  • allow for input excitiations
  • automatically record EPICS values

These are all big improvements.  The TT MEDM screens were appropriately updated.

We had to rebuild/restart c1ass, which reset the TT pointing.  We recorded all the values before hand and were able to recover the pointing easily.  Interestingly, there did appear to be hysteresis in pitch, which is maybe not entirely unexpected, but still worth nothing.


  8224   Mon Mar 4 19:38:21 2013 CharlesUpdateGeneralIntensity Stabilization and Control Systems

 I have been studying Jamies master's thesis concerning intensity stabilization of a solid-state laser (the 1064 nm specifically) to the ~10^-9 level, as well as relevant supporting material. I have also been reading about general control systems, photodiodes and acousto-optic modulators to help facilitate work on the ISS. 

Now that Altium has been properly installed, I have also begun familiarizing myself with the program and general libraries of boards and devices that have already been modeled with the program.

  8223   Mon Mar 4 18:11:10 2013 JamieUpdateSUSCleaning up suspension POS inputs

I did a little bit of cleanup of the suspension POS inputs today, both in model and MEDM land.


sus_single_control.mdl was simplified such that now there are just two position inputs:

  • POS: with LSC filter
  • ALTPOS: unfiltered

The regular LSC inputs go into POS, and any optic-specific extra pos inputs go into ALTPOS after being properly filtered and summed.

So for instance, MC2_MCL and MC2_ALS are filtered and summed then go into MC2 ALTPOS.  The ETM ALS inputs go into ALTPOS.

I modified the GLOBAL DAMPING outputs so that they are filtered in the GLOBAL block before being sent to be summed before going into ALTPOS for {I,E}TM{X,Y}.

All suspension models were rebuilt/installed/restarted.


The SUS_SINGLE.adl template screen was modified such that the POS button now points to optic-specific POS filter screens at:


For MC1, MC3, PRM, BS, SRM these are links to SUS_SINGLE_POS.adl.  The rest of the suspensions (MC2, {I,E}TM{X,Y}) now have custom screens that are variations of SUS_SINGLE_POS but with their extra filter screens added in.  For instance, here is the new SUS_ETMX_POS.adl:


This gets rid of all the white screen crap that was in here before.

All of this has been committed to the SVN.  NOTE: symlinks were heavily used when sorting this stuff out, so check for symlinks when modifying in the future.

  8222   Mon Mar 4 17:32:26 2013 yutaBureaucracyGeneralflowchart for PRMI g-factor measurement

I made a very useful flowchart for the week. Our goal for the week is to measure g-factor of PRC in PRMI.


  8221   Mon Mar 4 16:46:31 2013 yutaUpdateSUSoplev calibration for PRM

[Manasa, Sendhil, Yuta]

We calibrated oplev for PRM. Calibration factor for C1:SUS-PRM_OL(PIT|YAW)_IN1 are;
  OLPIT: 15.6 +/- 0.3 counts/mrad
  OLYAW: 17.8 +/- 0.3 counts/mrad

We needed these values for g-factor measurement of PRC using angle dithering method.

What we did:
  1. Adjusted QPD offsets (C1:SUS-PRM_OL[1-4]_OFFSET) by zeroing the output when turned oplev laser was turned off.
  2. Centered PRM oplev beam on QPD using steering mirror.
  3. Mounted PRM oplev QPD on a xy-stage and centered the beam on QPD.
  4. Moved QPD in x and y using micrometers and measured dependance of C1:SUS-PRM_OL(PIT|YAW)_IN1 on QPD displacement.
  5. Measured the path length of PRM oplev returning beam. We get the in-vac path length using optical layout CAD. We measured out of vac path using scale and tape measure.
  6. Dismounted PRM QPD from the stage and put it back to the original position.

  1. Figures below are OLPIT/OLYAW dependance on micrometer displacement moved in x and y. Error bars are measured fluctuation in the signal.

moved in x:PRM_PIT.png       moved in y:PRM_YAW.png

  2. We fitted the result by error function to get slope at zero crossing point. We also linear-fitted the other degree of freedom to get cross coupling between x and y. Slopes we get were;

micrometer    OLPIT          OLYAW
moved in x    4.68 +/- 0.08  0.01 +/- 0.03
moved in y   -5.32 +/- 0.10  0.11 +/- 0.03    (counts/mm)

  3. Measured the path length of PRM oplev returning beam was 3340 +/- 20 mm. This gives you the calibration factors above.

  [Precision] According to Jamie's calculation, expected g-factor for PRC in PR2-flipped PRMI is 0.966/0.939 (elog #8068). We care about the g-factor change in ~0.01. Also, intra-cavity power dependance on mirror angle is proportional to 1/(1-g). So, we need to calibrate mirror angle in ~few 10 % of precision in order to get useful g-factor from angle dithering measurement. Measurement precision here meets this requirement.

  [x/y coupling] Measured x/y coupling was less than 2 %. We assumed gains in 4 QPD quadrants are same, and assumed QPD is mounted well in x/y axes. These assumptions are OK considering precision we need.

  [x/y difference] Calibration factors for OLPIT/OLYAW are different by ~10 %. This is not so crazy considering the incident angle on the QPD (~20 deg) and elliptic beam shape.

  8220   Mon Mar 4 16:26:45 2013 BrettUpdateSUSGlobal Damping Noise Measurement

Here is an amplitude spectrum plot of y-arm cavity noise with a 50 Hz cutoff damping filter of the form zpk(0,[50;50],1). The low passing of this filter was intentionally extremely poor in order to see the damping noise in the cavity. The blue trace is the noise with no damping, which may be considered the 'best case' scenario from a noise point of view. The green has regular local damping on the ITMY. The ETMY has no damping for this measurement because the cavity control feedback to the ETMY takes care of its control when the cavity is locked. Notice the the large increase in noise from 40 Hz to 250 Hz, up to 1 order of magnitude. This noise is from the OSEM sensors passing through the damping loops. The red curve shows the y-arm noise with the exact same damping, except it is now applied in the global scheme. In this case, the damping noise falls completely below the baseline level of the cavity and becomes indistinguishable from the 'no damping' case.

If the damping injected enough noise I'd expect we would see a drop of 50 to 80 times switching from local to global. That is, the same factor measured in the transfer functions listed in log entry 8193.  However, the damping noise is only at most 1 order of magnitude above the baseline in this measurement. We would have to increase the damping noise by about another order of magnitude before we could expect to see the global damping noise in the cavity measurement.

The units of the cavity displacement in the plot were calculated using the 1.4e12 counts per meter calibration in log 6834. The measured UGF of the LSC loop at the time was 205 Hz. The peak in the plot above 200 Hz appears to be from this unity crossing. Moving the UGF also moves this peak.

Moral of the story: global damping can isolate the damping noise pretty well from the cavity signal.

Attachment 1: YARM_Noise.png
  8219   Mon Mar 4 11:30:47 2013 SteveUpdatePEMair cond problem


 The air cond is out of order at the area covered by racks 1 X 1  through 1 X 7

The arm X and Y AC units are working.

Attachment 1: 40dAC.png
  8218   Mon Mar 4 10:41:18 2013 Max HortonUpdateSummary PagesMultiprocessing Implementation


Upon investigation, the other methods besides process_data() take almost no time at all to run, by comparison.  The process_data() method takes roughly 2521 seconds to run using Multiprocessing with eight threads.  After its execution, the rest of the program only takes 120 seconds to run.  So, since I still need to restructure the code, I won't bother adding multiprocessing to these other methods yet, since it won't significantly improve speed (and any improvements might not be compatible with how I restructure the code).  For now, the code is just about as efficient as it can be (in terms of multiprocessing).  Further improvements may or may not be gained when the code is restructured.

  8217   Mon Mar 4 09:55:33 2013 ranaUpdateLSCLSC whitening triggering started

  How about posting a logic flow diagram? Is the idea to trigger only on the power signals to determine the lock state? Is the hysteresis going to be done in the same way as the main filter bank triggers?

  8216   Mon Mar 4 09:51:26 2013 SteveUpdateASSIP-ANG is still not real

 IP-ANG  is coming out of ETMY without clipping. The beam is very high on the pick off mirror at the end table but it is still missing the qpd .


Attachment 1: IP-ANG.png
  8215   Sun Mar 3 22:16:46 2013 JenneUpdateLSCLSC whitening triggering started

[Jenne, Annalisa]

We have started working on writing the c-code to parse the LSC input matrix, to see which PD is used for what degree of freedom, and to output a trigger for the PD.  The code is in ..../isc/c1/src, and there is a little block in the LSC code to the left of the triggering stuff.  Right now, the output of the c-code just goes to some temporary EPICS channels, so that we can see if things are working before we actually implement it.  At this time, there is no change to how the LSC model runs.

I can't figure out a bug in my c-code though.  Right now it's all commented out, so that the LSC model would start, but if I try to sum all of the elements in an array, the model compiles fine, but it won't start running.  I'm going to ask Jamie about it tomorrow.  I have a less-tidy backup plan if we can't get this figured out.

If I have time on the IFO to check that this works tomorrow, I expect another few hours of work (2?  3?), and then we'll have whitening filter triggering.

  8214   Sat Mar 2 20:09:12 2013 yutaUpdateRF Systemphase tracker: DAQ noise limited

[Koji, Yuta]

We found that our phase tracker noise is currently limited by the noise introduced in DAQ.
We confirmed that the frequency noise was improved from 2 Hz/rtHz to 0.4 Hz/rtHz by increasing the gain of the whitening filter.
The whitening filters should definitely be refined.

What we did:
  1. Put constant frequency RF input to the beatbox from Marconi and measured noise spectrum of the beatbox output(BEATX I) after the whitening filter with a spectrum analyzer. Noise floor level was ~0.2 Hz/rtHz at carrier frequency range of 15-100 MHz. Calibration factor of the beatbox output was ~380 mV/MHz.

  2. Measured noise spectrum of C1:ALS-BEATX_FINE_I_OUTPUT(figure below). The noise floor didn't change when there was RF input of 100 MHz from Marconi(blue) and DAQ input was terminated (green). Also, C1:ALS-BEATX_FINE_I_IN1(which is before unwhitening filter) showed a flat spectrum. These show our spectrum is limited by DAQ noise, which is introduced after the whitening filter.

  3. We increased the gain of whitening filter by x20 to show frequency noise performance can be improved by better whitening filter(red). But we can not use this setup as the other quadrature will be saturated by a too much gain at DC. Thus we need to carefully consider the signal level and the gain distribution of the whitening filters.

  - Better whitening filters. The current one consists of zero 1 Hz and pole 10 Hz with DC gain of 5 using SR560.
  - Better beatbox. We can increase the RF input power to the mixer and unify the preamplifier and the whitening filter in the box.

  8213   Sat Mar 2 14:52:02 2013 ranaUpdateLSCstable lock of PRMI

  Whereas the sensing matrix coefficients for ITMX/ITMY in REFL_I indicate an actuation imbalance, the disparity in the ITMX/ITMY to AS_Q elements does not. However, they do indicate why there is a PRM to AS_Q coupling at all.

I would recommend setting up the triggering so that the REFL & AS whitening is turned on AFTER lock acquisition and using a frequency of ~100-300 Hz for the sensing matrix measurement to fix these issues.

  8212   Sat Mar 2 05:53:15 2013 yutaUpdateLSCstable lock of PRMI

I tuned alignment, gains and filters to achieve stable lock of PRMI.
It now locks quite stably with UGF of ~100 Hz. Measured power recycling gain at maximum is ~ 25.

Locking details:
  == PRMI carrier ==
  MICH: AS55_Q_ERR, AS55_PHASE_R = -12 deg,  MICH_GAIN = -1, feedback to ITMX(-1),ITMY(+1)
  PRCL: REFL55_I_ERR, REFL55_PHASE_R = 70 deg, PRCL_GAIN = 0.3, feedback to PRM

  MICH servo is always on. PRCL loop turns on by trigger using POP DC. Boost filters and resonant gains turn on by triggers using POP DC.
  Gain normalization was not used.

Openloop transferfunctions:

  MICH: UGF ~90 Hz, phase margin ~40 deg
  PRCL: UGF ~100 Hz, phase margin ~50 deg (cf. Fitted gain was same as half-PRC: elog #8053)

Power recycling gain:

  POP DC when unlocked is 6, when locked is 2200-2500, and when dark is 0. So, power recycling gain is ~ 22 to 25. Value without any loss in PRMI is 45 (elog #6947). Alignment was pretty critical to achieve this recycling gain and stable lock.
  There was oscillation at 630 Hz when locked, which is similar to the one we saw in POX11 (elog #8203).


AS(top left), POP(top right), REFL(bottom left), and ETMYT(bottom right). ETMY was mis-aligned, but you can see the beam at ETMYT after PRMI was carrier locked.

MICH/PRCL coupling:

  I measured "sensing matrix" of PRMI by tickling PRM/ITMs/BS at 8.5 Hz and measuring 8.5 Hz peak height of AS55_Q, REFL55_I spectra during PRMI lock (attached is an example measurement of PRM). Below table is the result. AS55_Q has ~5% of sensitivity to PRCL compared with MICH. Also, BS introduces REFL55_I signal considerably. And also, there seems to be an imbalance in actuation efficiency between ITMX and ITMY.

actuation AS55_Q_ERR   REFL55_I_ERR
ITMX      +11.4        +0.80
ITMY      +33.0        +1.06
BS        +50.8        +1.90
PRM       - 0.7        +1.05

AS clipping:
  AS was clipped inside the vaccuum the other day(elog #8198). So, I tried to avoid AS clipping by aligning BS this morning. But it turned out that avoiding AS clipping by BS makes ITMX beam centering worse. Maybe we should center the beam on Yarm first next week.

 - calculate expected PRMI recycling gain with loss, PR2 filpped
 - beam centering on the arms
    - IPANG, IPPOS, Y green, X green
    - PRMI g-factor measurement

Attachment 3: PRMtoAS55REFL55.png
  8211   Sat Mar 2 00:23:19 2013 ranaSummaryCOCPhase Maps measured of the ATF flat mirrors

I took the two 'flat' 2" mirrors over to Downs and Garilynn showed me how to measure them with the old Wyko machine.

The files are now loaded onto our Dropbox folder - analysis in process. From eyeball, it seems as if the RoCs are in the neighborhood of ~5 km, with the local perturbations giving ~10-15 km of curvature depending upon position (few nm of sage over ~1 cm scales)

Koji's matlab code should be able to give somewhat more quantitative answers...

Ed: Here you are. "0966" looks good. It has RoC of ~4km. "0997" has a big structure at the middle. The bump is 10nmPV (KA)


Attachment 1: 0966_0997_phasemap.pdf
0966_0997_phasemap.pdf 0966_0997_phasemap.pdf 0966_0997_phasemap.pdf 0966_0997_phasemap.pdf 0966_0997_phasemap.pdf 0966_0997_phasemap.pdf 0966_0997_phasemap.pdf 0966_0997_phasemap.pdf
  8210   Sat Mar 2 00:09:31 2013 ranaUpdateLSCXarm oscillation stopped

  Don't use resonant gain - it can lead to a loop instability since it makes the loop have 3 UGFs.

Just use a elliptic bandstop filter at this harmonic frequency separately for each test mass. There are many detailed examples of this in elog entries from Rob and I over the past ~10 years. This bandstop should get clicked on automatically after lock acquisition.

  8209   Fri Mar 1 18:23:28 2013 JamieUpdateComputer Scripts / Programsupdated version of "getdata"

I updated the getdata script so that it can now handle downloading long stretches of data.


It now writes the data to disk incrementally while it's downloading from the server, so it doesn't fill up memory.

I also added a couple new options:

* --append allows for appending to existing data files

* --noplot suppresses plotting during download

  8208   Fri Mar 1 16:58:37 2013 yutaUpdateLSCXarm oscillation stopped

POX11 oscillation at 630 Hz was stopped by installing 630 Hz resonant gain to LSC_XARM.
After few hours, oscillation stopped. So I removed the resonant gain.
Our guess is that 630 Hz peak is some violin mode or something, and it was excited somehow, and didn't stopped for very long time because of its high Q. It coupled into POY11 somehow (scattering, electronics, etc).

Attachment 1: POX11_630Hz.png
  8207   Fri Mar 1 16:37:45 2013 BrettUpdateSUSGlobal Damping Update

Brett and Kamal

The global damping testing for the week is now complete. The c1sus.mdl simulink diagram settled on the attached screenshot. The top level of c1sus.mdl is shown on the left zoomed in over the new global damping block. The right shows the inside of that block. Also attached in the second screenshot are two of the modal damping MEDM screens. The left shows the main overview screen, the right shows the global damping filters. The overview screen is called C1SUS_GLOBAL.adl and is found in ...medm/c1sus/master/.

We have measured transfer functions and power spectra that show that global damping, with just a moderate amount of tuning (30 minutes of work) reduces the OSEM damping noise seen by YARM_IN1 by a factor between 50 and 80. Log 8193 highlights the transfer function measurements. The power spectra directly measure the noise in the cavity. I am not putting that data here because I have to catch. I will process the data and post it here later.

Overall the global damping tests appear to have been successful, isolating (not removing) the test mass damping noise from the cavity by almost 2 orders of magnitude. Presumably even more isolation is possible with more tuning.

Attachment 1: GlobalDamp_Simulink.png
Attachment 2: GlobalDampScreens.png
  8206   Fri Mar 1 14:50:36 2013 SteveUpdateVACpumpdown day 8

 Atm1, RGA background scan with TP3 pumping at day 7

Atm2,  IFO  CC1 = 1.1e-5 Torr at day 8

 Vacuum valve VM3 closed and VM2 opened, it switched the RGA to IFO scanning mode. CC4 = 3.5e-6 Torr

TP3 is pumping on the annuloses, their pressures are 1-3 mTorr

Vacuum condition reached the state of  Vacuum Normal. The MEDM screen "Current State" channel does not work because we disconnected some valves after the VME swap CAOS

Note: TP1 Maglev performance on Atm2  CC4 = 4e-9 Torr when VM2 valve was open


Attachment 1: bgTP3d7.png
Attachment 2: RGAonIFO.png
  8205   Fri Mar 1 08:19:40 2013 SteveUpdateASSdrift

 Early morning drift in pitch. This plot is meaningless because there is no real  light on IP-Ang

The beam is clipping on the pick off mirror at ETMY chamber. The beam is half beam size too high. Yaw is perfect


Attachment 1: drift.png
  8204   Fri Mar 1 02:49:34 2013 JenneUpdateASSArm A2L measurement

I haven't finished debugging the scripts so that the measurement is fully automatic, like the MC, but I did measure the arm spot positions just now. 

These numbers aren't especially precise....I just picked numbers off of a StripTool plot, but they give us a good idea of how very far off we are.  Also, I don't know yet which way the signs go...I have to think about that in terms of the direction I mis-balanced the coils.  It's the same convention as the MC though.  You can see in the attached quad camera image (quadrants match the corners of the table) that these numbers aren't unreasonable.

Pit 4 mm Pit 4 mm
Yaw -1.5 mm Yaw 6 mm
Pit -3 mm Pit -3 mm
Yaw 4 mm Yaw -4 mm


EDIT: It occurs to me now, a little later, that it had been at least half an hour since I last realigned the cavities, so some of this apparent miscentering is due to the input pointing drift. That doesn't account for all of it though. Even when the cavities have very high transmitted power, the spots are visibly miscentered.

  8203   Fri Mar 1 01:17:06 2013 JenneUpdateLSCXarm oscillation

There is an oscillation in the Xarm at 631Hz, which is not in the Yarm.  There is a small peak in POY11_I at this frequency, but only when the Xarm is locked.  If the Xarm unlocks, the peak disappears from POY.  The peak is 3 orders of magnitude larger in POX than in POY, and 4 orders of magnitude larger than the POY noise when this peak is not present.  In the plot, I have turned off the POY whitening, so that its situation is the same as POX (we still need to fix POX whitening switching).  Dark noise (MC unlocked) is the same for both PDs.


  8202   Thu Feb 28 14:51:43 2013 JenneUpdatePEM"Rock Monster" causing low frequency noise

Manasa and I have been wondering why the low frequency seismic noise has been different in the last few days/weeks.  I went over to visit the Rock Monster, a.k.a. the Earth Surface Dynamics Laboratory next door, and the grad student turned it up for me (increased water flow significantly) for a few minutes.  Then I came back to look at the BLRMS, and you can see the low frequency increase a few minutes ago, when he turned it up on high.  He said that they run it on low almost all the time, 9am-5pm ish, and on high for an hour or so at a time periodically during the day.


  8201   Thu Feb 28 14:19:20 2013 Max HortonUpdateSummary PagesMultiprocessing Implementation

Okay, more memory would definitely be good.  I don't think I have been using MEDM (which Jamie tells me is the controls interface) so making a cronjob would probably be a good idea.

  8200   Thu Feb 28 06:51:17 2013 yutaUpdateRF Systemphase tracker: noise level

I measured noise level of the phase tracker by inputting constant frequency RF signal from marconi.
Measured frequency noise was ~2 Hz/rtHz @ 100 Hz. It's not so good.

What I did:
  1. Unplugged 11MHz marconi and put RF signal to the beatbox from this. Frequency and amplitude I put are 100 MHz and -3 dBm.
  2. Measured spectra of phase tracker outputs, C1:ALS-BEATX_FINE_PHASE_OUT, C1:ALS-BEATY_FINE_PHASE_OUT.
  3. Calibrated using the factor I measured (elog #8199).
  4. Put marconi back to orignal settings.


  - According to Schilt et al., this noise level is not so good.
  - By changing the delay-line cable length or optimizing whitening filter etc., we can improve this.

  8199   Thu Feb 28 05:54:54 2013 yutaUpdateRF Systemphase tracker: calibration

I swept the frequency of RF input to the beatbox to calibrate and check linearity range of phase tracker.
Calibration factors are;
  C1:ALS-BEATX_FINE_PHASE_OUT    52.1643 +/- 0.0003 deg/MHz
  C1:ALS-BEATY_FINE_PHASE_OUT    51.4788 +/- 0.0003 deg/MHz

There was systematic error to the linearity check, but at least, calibration factor changes less than 50 % in the frequency range of 10 MHz to more than 500 MHz.

What I did:
  Used network analyzer(Aligent 4395A) to sweep the frequency RF input to the beatbox and getdata of phase tracker signal. I swept from 10 Hz to 500 MHz with 501 points in 50 sec. This sweep is slow enough considering we could lock the 40m arms (typical speed of a mirror is 1 um/s, so bandwidth of the phase tracker should be more than 1 um/sec / 40 m * 3e14 Hz = 75 MHz/s).
  RF amplitude was set to be -3 dBm and splitted into BEATX and BEATY.

  Plots for BEATX and BEATY are below;

  - Considering delay line length is ~30m, expected calibration factor is;

    2*pi*l/v = 2*pi * 30 m / (2e8 m/s) = 0.94 rad/MHz = 54 deg/MHz

so, this calibration is reasonable.

  - Since frequency sweep of network analyzer is not continuous, phase tracker output is like steps with some ringdown. This makes some systematic error for checking linearity. I'm planning to do slower sweep or continuous sweep. Also, the phase tracker seems like he can exceed 500 MHz.

  8198   Thu Feb 28 03:41:31 2013 KojiUpdateLSCPR gain ~ 25 from PRMI carrier lock

This is how the carrier lock PRMI should look like.

- There is more room to improve the differential ITM alignment to make the dark port more dark, then you will gain more PRG

- The AS spot is definitely clipped.

  8197   Thu Feb 28 03:25:27 2013 yutaUpdateLSCPR gain ~ 25 from PRMI carrier lock

[Manasa, Yuta]

We locked PRMI in carrier. Measured power recycling gain was ~25.


  Here's some plot of PRC intra-cavity powers and MICH,PRCL error signals. As you can see from POPDC, cavity buildup was about 400, which means power recycling gain was ~25. Power recyling gain is fluctuating up to ~45 during lock. We need some gain normalization or something.


  Here's 30 sec movie of AS, POP, REFL when acquiring PRMI carrier lock. Although there's oscillation when acquiring lock, beam spot motion is less and stable compared with the past(before flipping PR2).

Locking details:
 == PRMI carrier ==
  MICH: AS55_Q_ERR, AS55_PHASE_R = -12 deg,  MICH_GAIN = -0.1, feedback to ITMX(-1),ITMY(+1)
  PRCL: REFL55_I_ERR, REFL55_PHASE_R = 70 deg, PRCL_GAIN = 5, feedback to PRM

  - Better filters and gains for stable lock
  - Kakeru method to measure g-factor (see elog around #1434)
  - OSA to measure g-factor

  8196   Thu Feb 28 02:43:49 2013 yutaUpdateLSCsome qualitative evidence of PRMI sideband lock

[Manasa, Yuta]

Since we have setup POP22 PD now(elog #8192), we could confirm that sideband power builds up when PRMI is sideband locked.

  Here's some plot of PRC intra-cavity powers and MICH,PRCL error signals. As you can see from POP22, we locked at the peak of 11MHz sideband. There was oscillation at ~500 Hz, but we couldn't optimize the gain yet.

  Here's 30 sec movie of AS, POP, REFL when acquiring (and losing) PRMI sideband lock. It was pretty hard to take a movie because it locks pretty seldom (~1 lock / 10 min).

Locking details:
  For MICH lock, we used ITMs instead of BS for reducing coupling between PRCL.
  Also, AS55 phase rotation angle was coarsely optimized by minimizing MICH signal in I.
  For PRCL lock, we used REFL55_I_ERR instead of REFL33_I_ERR. It had better PDH signal and we coarsely optimized phase rotation angle by minimizing PRCL PDH signal in Q.

 == PRMI sideband ==
  MICH: AS55_Q_ERR, AS55_PHASE_R = -12 deg,  MICH_GAIN = -0.1, feedback to ITMX(-1),ITMY(+1)
  PRCL: REFL55_I_ERR, REFL55_PHASE_R = 70 deg, PRCL_GAIN = -15, feedback to PRM

  We set POP22_PHASE_R = -170 deg by minimizing Q.

 - We tried to use REFL55_Q_ERR to lock MICH, but couldn't. It looks like REFL error signals are bad.
 - We tried to use POP22_I_ERR to trigger PRCL lock, but it didn't work.

  8195   Wed Feb 27 23:19:54 2013 ranaUpdateSummary PagesMultiprocessing Implementation

  At first I thought that this was goofy, but then I logged in and saw that Megatron only has 8GB of RAM. I guess that used to be cool in the old days, but now is tiny (my laptop has 8 GB of RAM). I'll see if someone around has some free RAM for a 4600; in the meantime, I've killed a MEDM that was running on there and using up a few hundred MB.

Run your ssh-MEDMs elsewhere or else I'll make a cronjob to kill them periodically.

  8194   Wed Feb 27 22:46:53 2013 Max HortonUpdateSummary PagesMultiprocessing Implementation

Overview: In order to make the code more maintainable, I need to factor it into different well-documented classes.  To do this carefully and rigorously, I need to run tests every time I make changes to the code.  The runtime of the code is currently quite high, so I will work on improving the runtime of the program before factoring it into classes.  This will be more efficient (minimize testing time) and allow me to factor more quickly.  So, my current goal is to improve runtime as much as possible.

Multiprocessing Implementation:

I invented a simple way to implement multiprocessing in the summary_pages.py file.  Here is an example: in the code, there is a process_data() function, which is run 75 times and takes rather long to run.  I created multiple processes to run these calls concurrently, as follows:

Original Code: (around line 7840)

for sec in datasections:
      for run in run_opts:
        run_opt = 'run_%s_time' % run
        if hasattr(tabs[sec], run_opt) and getattr(tabs[sec], run_opt):

          process_data(cp, ifo, start, end, tabs[sec],\
                       cache=datacache, segcache=segcache, run=run,\
                       veto_def_table=veto_table[run], plots=do['plots'],\
                       subplots=do['subplots'], html_only=do['html_only'])

  # free data memory
          keys = globvar.data.keys()
          for ch in keys:
            del globvar.data[ch]


The weakness in this code is that process_data() is called many times, and doesn't take advantage of megatron's multiple threads.  I changed the code to:

Modified Code: (around line 7840)
  import multiprocessing

  if do['dataplot']:
  ... etc... (same as before)       
    if hasattr(tabs[sec], run_opt) and getattr(tabs[sec], run_opt):

          # Create the process
          p = multiprocessing.Process(target=process_data, args=(cp, ifo, start, end, tabs[sec], datacache, segcache, run, veto_table[run], do['plots'], do['subplots'], do['html_only']))
          # Add the process to the list of processes
          plist += [p]


Then, I run the process in groups of size "numconcur", as follows:
    numconcur = 8
    curlist = []
    for i in range(len(plist)):
      curlist += [plist[i]]
      if (i % numconcur == (numconcur - 1)):
        for item in curlist:
        for item in curlist:
        keys = globvar.data.keys()
        for ch in keys:
          del globvar.data[ch]
        curlist = []


The value of numconcur (which defines how many threads megatron will use concurrently to run the program) greatly effects the speed of the program!  With numconcur = 8, the program runs in ~45% of the time of the original code!  This is the optimal value -- megatron has 8 threads.  Several other values were tested - numconcur = 4 and numconcur = 6 had almost the same performance as numconcur = 8, but numconcur = 1 (which is essentially the same as the unmodified code) has a much worse performance.

Improvement Cap:

Why does numcores = 4 have almost the same performance as numcores = 8?  I monitored the available memory of megatron, and it is quickly consumed during these runs.  I believe that once 4 or more cores are being used, the fact that the data can't all fit in megatron's memory (which was entirely filled during these trials) counteracts the usefulness of additional threads.

Summary of Improvements:

Original Runtime of all process_data() statements: (approximate): 8400 sec

Runtime with 8 processes (approximate): 3842 sec

This is about a 55% improvement for speed, in this particular sector (not in the overall performance of the entire program).  It saves about 4600 seconds (~1.3 hours) per run of the program.  Note that these values are approximate (since other processes are running on megatron during my tests.  They might be inflated or deflated by some margin of error).


Next Time:

This same optimization method will be applied to all repetitive processes with reasonably large runtimes.

  8193   Wed Feb 27 22:28:53 2013 BrettUpdateSUSGlobal Damping Update

 New excitation points were added after the global damping loops for more testing options. The updated c1sus.mdl model was re-committed to the svn. Two interesting simulink 'requirements' were found during this minor modification. First, excitation points must be placed on the top level of the diagram. If they are in a subsystem you will get compiling errors. Second, the excitation name must end in _EXC. It will compile OK if you don't do this, but the excitation points will not put out any excitations.

To do further investigation on the mysterious gain factor of 2.5 between the ETMY and ITMY POS damping loops, I measured TFs in the POS direction to the locked YARM signal for each. This provides an additional sensor, common to both, so we can see if the gain is coming from the actuation side or sensing side of the damping loops. The difference in these TFs is about 


So it seems the majority of the damping gain difference is on the actuation side with some small difference on the sensing side. In order to allow for the later splitting of YARM LSC control between ITMY and ETMY (global damping and the cavity control must be along the same coordinate system), I placed this gain of 2.95 in ITMY_LSC.

To get a first measure of the relative performance of global damping to local damping I measured some TFs between the sensor signal inputs and YARM. So first, while the cavity was still locked with just ETMY, I measured a TF between C1:SUS-ITMY_SUSPOS_EXC and C1:LSC-YARM_IN1. Second, I split the cavity control evenly between the ETMY and ITMY by adjusting C1:LSC-OUTPUT_MTRX. I turned off the local damping and turned on the common DOF global damping (called CARM at this point despite being on just one arm). I then repeated the same TF but driving from C1:SUS-GLOBAL_CARMDAMP_EXC.

The resulting TFs are displayed in the attached figure. The blue curve is then the TF from local damping sensor noise to YARM. The green is global damping sensor noise to YARM. The suppression between local to global is in red. The global damping curve is about 50 to 100 times lower (better) than local damping. This can probably be improved with further tuning to account for remaining differences between the ITMY and ETMY.

Note, the damping loop used in the filter modules for all of these is zpk(0,[15 15],1), with a gain of 30. This purposely has little high frequency filtering so it is easier to see the influence on YARM.

Attachment 1: DampNoise_to_YARM_fig_27Feb2013.png
  8192   Wed Feb 27 20:50:41 2013 ManasaUpdateLSC22/110MHz path for POP

[Yuta, Manasa]

Modified POP path.

1. Removed temporary POP DC and the BS 50 (elog)
2. Introduced a 95% BS after the POP steering mirrors (95% of the signal goes to PD10CF used for POP22 and 5% goes to POP camera)
3. Output of PD10CF goes to the LSC rack through POP110 heliax cable.
4. The PD output at the LSC rack  goes through a DC block to separate DC from RF.


We could not find a power supply slot for the amplifiers on the LSC rack. We had to put a temporary power supply in contradiction to our 'no temporary power supply' policy.

  8191   Wed Feb 27 20:10:43 2013 ranaUpdateLockingDRFPMI flashes


 If its true that there have been large flashes, then there indeed might be beer. But first I'd have to see a calibrated plot. And make sure that the flashes are not overamplified due to a whitening filter imbalance.

Is it the readout of a PD with no whitening/antiwhitening? IF so, its much easier to believe.

  8190   Wed Feb 27 19:27:29 2013 AnnalisaHowToCOMSOL TipsMirror support Eigenfrequency

 I studied the eigenfrequencies of a mirror support using COMSOL.


Attachment 1: IronSupport.png
Attachment 2: IronSupportEigenfreq.png
  8189   Wed Feb 27 18:38:51 2013 RijuUpdate Photodiode transimpedance



How much is the exact resonant frequency?

And what's the unit of the plot? The resonant "transimpedance" in the unit of Ohm can not be ~100.

 The exact resonant frequency is 29.38MHz. I ve uploaded the other plot. It was the output of Vectfit.

 Is the DC transimpedance now 10010 Ohm? I ve used 50 Ohm. Which one is correct?

  8188   Wed Feb 27 18:17:05 2013 RijuUpdate Photodiode transimpedance


How much is the exact resonant frequency?

And what's the unit of the plot? The resonant "transimpedance" in the unit of Ohm can not be ~100.

 The exact resonant frequency is 29.38MHz. I ve uploaded the other plot. It was the output of Vectfit.

  8187   Wed Feb 27 18:01:46 2013 KojiUpdate Photodiode transimpedance

How much is the exact resonant frequency?

And what's the unit of the plot? The resonant "transimpedance" in the unit of Ohm can not be ~100.

  8186   Wed Feb 27 17:43:54 2013 RijuUpdate Photodiode transimpedance

Here is the transimpedance for the other PD used for MC REFL

Attachment 1: TFnewreflpd.pdf
Attachment 2: NewREFL_z.pdf
  8185   Wed Feb 27 14:59:01 2013 EvanUpdate Altered MC demodulation phase

 I took out a short (~12 cm) SMA cable from the "LO input" path into the MC demod board in an attempt to maximize the power in Q and minimize the power in I. The path might benefit from being shortened a little more, but it's hard to tell since I is noisy. (In the attached plots, channel 1 is Q and channel 2 is I.)

Should you find it necessary to restore the original path length, the cable I took out is in the "SMA ONLY" tupperware and has a printed label with "5" on it.

Attachment 1: Q_and_I_before.eps
Attachment 2: Q_and_I_after.eps
  8184   Wed Feb 27 14:53:02 2013 SteveUpdateLSCwhat is the Fibox ?

Fibox FBAI-M 20bit units were connected with multimode fibre.  This pair of fiber is not protected in the cable tray.

ELOG V3.1.3-