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:
          item.start()
        for item in curlist:
          item.join()
          item.terminate()
        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.

 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 

2.895

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.

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

 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.

 I studied the eigenfrequencies of a mirror support using COMSOL.

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

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

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 ~10⁰.

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

 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.

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

 [Annalisa, Jenne, Rana, Steve]

We installed the fibres on cable trays the 1Y2 and the Control Room.

Still to do: find a power supply for the Fiboxes and plug everything in.

I re-adjusted coil gains and f2a filters for PRM and BS.
I'm not sure what happened to PRM since I balanced on Feb 16(elog #8093).
Let's see if it helps PRMI locking or not.


========== PRM ==========

- Original DC coil gains

C1:SUS-PRM_ULCOIL_GAIN 1.049901772380000e+00
C1:SUS-PRM_URCOIL_GAIN -9.833961907160000e-01
C1:SUS-PRM_LRCOIL_GAIN 9.543042546630000e-01
C1:SUS-PRM_LLCOIL_GAIN -9.713568522590000e-01

- New DC coil gains

multiplier factors are :
UL = 0.928167
UR = 1.061448
LR = 0.941659
LL = 1.068726
Set C1:SUS-PRM_ULCOIL_GAIN to 0.974482231437
Set C1:SUS-PRM_URCOIL_GAIN to -1.04382410014
Set C1:SUS-PRM_LRCOIL_GAIN to 0.898628670041
Set C1:SUS-PRM_LLCOIL_GAIN to -1.03811466772

- New f2p filters

- measured coupling coefficients are :
P2P(POS=>PIT) = 0.023968
P2Y(POS=>YAW) = 0.007075





========== BS ==========

- Original DC coil gains

C1:SUS-BS_ULCOIL_GAIN 1.037692431800000e+00
C1:SUS-BS_URCOIL_GAIN -1.016268296990000e+00
C1:SUS-BS_LRCOIL_GAIN 9.660800075010000e-01
C1:SUS-BS_LLCOIL_GAIN -9.791833500410000e-01

- New DC coil gains

multiplier factors are :
UL = 1.017855
UR = 1.023207
LR = 0.956184
LL = 1.002755
Set C1:SUS-BS_ULCOIL_GAIN to 1.0562177496
Set C1:SUS-BS_URCOIL_GAIN to -1.03985422464
Set C1:SUS-BS_LRCOIL_GAIN to 0.923750146975
Set C1:SUS-BS_LLCOIL_GAIN to -0.981880297098

- New f2p filters

- measured coupling coefficients are :
P2P(POS=>PIT) = 0.038251
P2Y(POS=>YAW) = -0.014677

I made a simple script to backup crontab (/opt/rtcds/caltech/c1/scripts/crontab/backupCrontab).

#!/bin/bash

crontab -l > /opt/rtcds/caltech/c1/scripts/crontab/crontab_$(hostname).$(date '+%Y%m%d%H%M%S')

I put this script into op340m crontab.

00 8 * * * /opt/rtcds/caltech/c1/scripts/crontab/backupCrontab

It took me 30 minutes to write and check this one line script. I hate shell scripts.

Did someone unlock the back door by the (unofficial) bike storage lately?  Out of habit, I checked the door behind me while about to leave, and it is unlocked. 

Please recall that if you leave through that door, it should automatically lock behind you (if it was locked already), however if you unlock and enter through the back door, it stays unlocked until someone locks it again.

(Obviously, I'm locking the door before I actually go).

Before Yuta left, I asked him to restore all optics to last saved values, to avoid hysteresis.

Some interesting modes appear at ETMYT and ETMXT.  The cavities aren't super well aligned right now, especially since we have been seeing this input pointing drift, but it's cool to see our first DRFPMI flashes. SRM, in particular, hasn't been aligned since before pumpdown.  If I misalign SRM, the mode content at the trans cameras improves somewhat, but it still isn't all low-order modes.

Here is the note that I wrote on youtube describing the video:

DRFPMI Flashing

Upper left is AS, upper right is POP
lower left is Xarm Trans (ETMXT), lower right is Yarm Trans (ETMYT)

Arms were last aligned several hours ago, and we know input pointing drifts, so at least some of the higher order modes in the arm transmissions are due to poor input pointing. All optics are "restored" to their last saved values, including SRM, which has not been aligned since before pumpdown.

TRX DC PD values are flashing to as high as 10
TRY DC PD values are flashing to as high as 7

Since uploading the video, I have seen TRY flash (once) to 45.  Yes, forty five!!!  Both arms are usually flashing to ~3ish, with an occasional medium flash (5-10), and then a few rare TRY flashes above 20.

We may have officially lost the bet of having arms locked by 9am Monday, but I think Team Grad Student / Postdoc still deserves some beer from Team Faculty / Staff.

I have modified the MeasureSpotPositions.py script to accept the arms as valid cavities (it used to give an error "Sorry, this only works for MC right now").

There is still no wrapper script to turn on lockins and turn them off after the measurement, so I have not tested the arm A2L yet.  But I should be able to tomorrow, or whenever the IFO is next available.

To-do:

* Write the wrapper script (analog of mcassMCdecenter).

* Fix arm assOff, assDown, assOn, assUp scripts to match the current channel names (which were changed long ago to be human-readable, versus mysterious numbers).

* Test.

[Jenne,Yuta]

We succeeded in locking PRMI in sideband and carrier.
Measured power recycling gain was ~60 power recycling gain was 4 (edited by YM on Feb 27; see elog #6947), but we have many things we cannot explain.

Snapshots:
  Here you are, Jamie.

PRMI sideband locked



PRMI carrier locked


  I centered POP camera and put attenuator to take these snapshots.

  Compare with previous ones.

Aug 17, 2012 elog #7213
Jun 28, 2012 elog #6886
Mar 15, 2012 elog #6421


Locking details:
 == MI only ==
  MICH: AS55_Q_ERR, AS55_PHASE_R = -12 deg, MICH_GAIN = -7, feedback to BS

 == PRMI sideband ==
  MICH: AS55_Q_ERR, AS55_PHASE_R = 24.5 deg,  MICH_GAIN = -0.05 (acquisition) -> -5 (UGF ~100 Hz), feedback to BS
  PRCL: REFL33_I_ERR, REFL33_PHASE_R = -22.65 deg, PRCL_GAIN = 4 (UGF ~120 Hz), feedback to PRM

 == PRMI carrier ==
  MICH: AS55_Q_ERR, AS55_PHASE_R = 24.5 deg,  MICH_GAIN = -0.08 (couldn't measure UGF), feedback to BS
  PRCL: REFL33_I_ERR, REFL33_PHASE_R = -22.65 deg, PRCL_GAIN = -0.3 (couldn't measure UGF), feedback to PRM


Power recycling gain:
  POPDC was 32 when PRM is misaligned, 25 when PRMI sideband locked, ~2000 when PRMI carrier locked.
  This means, power recycling gain is ~60 power recycling gain is ~4 (=POPlocked/POPmis*T_PRM=2000/30*0.06). Expected power recycling gain for PRMI is ~45, when there's no loss (see elog #6947).

  I reduced POPDC PD gain so that it doesn't saturate.

Issues:
  - We optimized AS55_PHASE_R to -12 deg by looking at MI signal. But somehow, -12 deg didn't work for PRMI.
  - Somehow, REFL11_I didn't work to lock PRCL.
  - REFL11_Q didn't work to lock MI. SNR not enough?
  - We saw POPDC flashing up to ~15000. What is this?
  - Carrier lock was not stable, we couldn't hold for more than ~30 sec. It looks like PRM moves too much when PRMI is locked.
  - Input pointing is drifting a lot in pitch. I had to re-align TT2/TT1 to the arms every ~1 hour to get good MI alignment. When I tweak TT2/TT1, both TRY and TRX gets better. I think this shows that input pointing is drifting, not the arms.


Next:
 - redo PRM/BS coil balancing
 - optimize REFL33 rotation phase
 - stabilize carrier lock somehow
 - measure PRC g-factor

I am putting a little bit of brain power into reviving the ASS, and I want to write down what the motivation is, and what the short and long-term plans are.

Why?

The IFO IR is not optimally aligned right now.  While we were at atmosphere, we should have taken the time to align the green beams to the arms until the greens were both resonating TEM00.  We were lazy, and excited to pump down, so we decided that locking on higher order modes was good enough to ensure the beams came out of vacuum.  Once we were pumped down, ITMY and ETMY were aligned to the green beam axis.  Then, the IR was aligned to this new Yarm cavity axis.  This would have been okay, and pretty close, if we had aligned the green beam all the way (used only the outside steering mirrors to resonate TEM00, after the cavity mirrors were aligned for flashing IR).  After the IR was aligned to the Ygreen axis, the rest of the IFO was aligned to this slightly-incorrect input pointing.  We want to measure the IR spot positions on ITMY and ETMY so that we can tweak the input pointing until we hit the center of both ITMY and ETMY.  Then we will align Ygreen's input pointing to this proper IR cavity axis.  The rest of the IFO alignment will also have to be redone.  This calls for a functioning A2L system, so the measurement part of the ASS.

The immediate motivation for measuring the spot positions is that the current Xarm IR axis is not at all very close to the Xgreen axis.  The other day while we were fixing up the Xend table (note in elog 8162), we found that the TRX beam to the TRX PD and the trans camera was clipped on the 2" harmonic separator (which is the first optic that the transmitted IR beam sees on the end tables).  It was clipping on the left side of the optic, if you are looking at the face of the optic.  This is the more east-erly side of the optic.  We moved that optic to the side so that we were not clipping.  Then, today when Manasa was trying to align the Xgreen beam, she found that it was clipping on the right side of the harmonic separator, the more west-erly side.  I remember seeing that the green beam was roughly centered on the harmonic separator when we were at atmosphere, so this clipping is certainly due to Yuta, Evan and my moving of the harmonic separator.  Since the end green steering optics are not very orthogonal in angle/translation, it is very difficult to translate the beam by a significant amount.  If we keep the current IR alignment, which surely isn't good anyway (you can see on the ETMXF camera that the beam isn't centered), we would probably have to move the Xgreen steering optics, which would be a total pain.  It seems that the better plan is to leave them where they are, and get the IR pointing in the correct direction, and move the harmonic separator back to where it was originally.

Short term (< few days):

Write the arm section of the existing MeasureSpotPositions.py script (in ....../scripts/ASS).  Write a wrapper script that, like ...../scripts/ASS/MC/mcassMCdecenter, calls sets up the lockins, runs MeasureSpotPositions.py, and calculates the calibrated spot positions.  Use this information to hand tweak the input pointing, then realign the cavities to the new IR, and the greens to the new cavity axes.

All of the infrastructure for this is already in place in the c1ass model.   The only drawback to the current situation is the LSC output matrix only has one row for ASS, and so only one cavity can be measured at a time.  To make things faster, we could consider increasing the size of the LSC output matrix so that the 2 arms could be measured simultaneously.  This change is low priority for now.

Long term:

Make the full ASS system work. 

A major change from the current situation is that the current ASS cannot actuate on the input pointing (TT1 and TT2 for Yarm, BS for Xarm).  We want a low bandwidth servo to force the input beam to follow the cavity axis.  Implementing this will require some changes to the ASS model. 

Remeasure sensing matrix, test system.

Jamie and I have had a few back-and-forths on this, but I wanted to write down my thoughts on the parts of the SUS infrastructure that we need for the active tip tilts.

I think we want the ASC pitch and yaw filter banks.  I also think we want to change the channel names so that they are C1:SUS rather than C1:IOO, to make scripting easier.  A corollary to this is that we should make the DC bias sliders have the same naming structure as the regular suspensions (C1:SUS-TT#_{PIT/YAW}_COMM).  This makes scripts like the save/restore scripts easier.  If we keep the IOO naming, it would still be convenient to add the _COMM.

I am having trouble imagining what we might want the lockins for, so I propose we leave them out.

Do we want the output matrix (PIT/YAW -> coils) to be a filter bank matrix?  If we want f2a filters, we need to change this to a filter bank matrix.

I also think we want a master on/off switch for the AC actuation (ASC stuff).  We don't have sensors, so we won't have watchdog-ing, but it might be useful to have a 'panic' switch.  Perhaps though if we are careful to set limits on the ASC filter banks, we won't ever have a panic about actuating too hard.

I'm think I'm joining Jamie's side in the medm screen debate....I think we want a separate TT_SINGLE screen, laid out similar to the SUS_SINGLE, but without all of the irrelevant parts.

EDIT:  Yuta just pointed out to me that right now, the TT DC bias sliders are not recorded anywhere (_DQ, conlog,...).  We *must* fix this.

The global damping input and output matrices were installed to run for the Y-arm. Since we are using just one arm for now, only the DARM and CARM DOFs were entered into the matrices.

The input matrix was set to have elements with magnitudes of 0.5 while the output matrix was set to have elements with magnitudes of 1. The input matrix gets the 0.5 because the sensor signals must be avergaed for each global DOF, to make an 'equivalent sensor' with the same gain. The output matrix gets magnitudes of 1 so that the overall gain of the global loops is the same as the local loops. A transfer function was measured on the CARM loop to check that the overall gain is in fact the same as the measured ITMY and ETMY loops.

Simple damping filters were installed for the ITMY and ETMY as well as the global y arm CARM and DARM loops.

The ETMY output tuning filter ETMY_GLOBPOS was set to have a gain of 0.4 because there is an extra gain of 2.5 relative to ITMY in some mysterious place as discussed in log 8172.

I corrected the circuit diagram I constructed last time - it would read 0 output most of the time because I made a mistake with the op amps. This will be attached once I discuss it with Eric.

I searched the 40m lab and ended up finding a breadboard in the Bridge lab. I then spent awhile trying to remove the QPD from the circuit board it was on, which was difficult since it had 6 pins. After that, I soldered wires to the QPD legs and began constructing the circuit on the breadboard. I also spent time showing Annalisa the setup and explaining my project.

On Friday I will try and reconstruct all of the circuitry from before for the QPD.

While doing initial measurements for the new global damping infrastructure I discovered that the ETMY loop between the OSEM actuation and the OSEM sensors has a gain that is 2.5 times greater than the ITMY.  The result is that to get the same damping on both, the damping gain on the ETMY must be 2.5 times less than the ITMY. I do not know where this is coming from, but I could not find any obvious differences between the MEDM matrices and gains.

I uploaded a screenshot of measured transfer functions of the damped ITMY and ETMY sus's. Notice that the ETMY measurement is 2.5 times higher than the ITMY. The peak also has a lower Q, despite having the same damping filters running because of this mysterious gain difference. Lowering the damping gain of the ETMY loop by this 2.5 factor results in similar Q's.

 Ah, yes.  I forgot to mention in my elog last night that Yuta and I found that the ITMX oplev servo had been on, even though the oplev beam was blocked, so ITMX was noisier than it should have been.

 [Yuta, Manasa]

FPMI locked.

Alignment and lock acquisition
1. Use ITMY/ETMY to maximize green transmission in Y arm (to get closer to arm alignment).
2. Use TT1/TT2 to align arms to IR to the Y-arm (Maximum TRY = 0.84)
3. Use BS/ITMX/ETMX to align IR to the X-arm.
4. Use POY11_I and POX11_I to lock Yarm and Xarm.
5. Use ASDC to lock MI.

Modified
1. X-arm trans camera settings changed.
2. Blocked stray green from reaching TRX PD and camera.

P.S. TRX seems to be moving less on the camera because of the oplevs centered and working from last night.

Plan
Lock green to X arm.

I made good on my threat from yesterday to convert the MC2 suspension controller to the library part.  Whatever changes were in MC2 were thrown out, although they are archived in the SVN.  Again, this kind of undocumented breaking is forbidden.

Change was committed to SVN, and c1mcs was recompiled/installed/restarted.

[jamie, brett]

Yesterday we added some new control logic to the sus_single_control part to allow for global damping.  Today we decided that a binary switch between local/global damping was probably a bit extreme since we might want to smoothly ramp between them, instead of just hard switching.  So we removed this switch and are now just summing the control inputs from global and local damping right before the output matrix.

Changes were committed to the SVN, and all suspension models were recompiled/installed/restarted.

Evan got 40m specific safety training today.

One of the biggest issues we had was that any Q signals (i.e. the quadrature where PRCL is absent.) of REFL11/33/55/(165) haven't been consistent each other.
i.e. We never had reliable lock of MICH with REFL_any_Q, regardless of the resonant condition. This is definitely one of the things to be tried in order to prepare for the full lock.

We don't trust any demodulation phases of any PDs any more as the previous PRC mode (or say, absence of the stable mode) was unreasonable to determine any of the demodulation phases.

I remember that the POP DC saturates at 27000. You may need to reduce the gain switch again.

The AS OSA and/or POP BBPD would be useful for the sideband PR gain estimation.

[Jenne, Yuta]

We began the evening, after alignment of all optics was good (arms flashing, PRC flashing, assumed SRM last saved alignment was okay), centering all oplevs and aligning beam onto AS55, REFL11, REFL55 and REFL33 and POPDC.

After a quick check to make sure that the input pointing was still okay for Yarm (TRY was 0.88 when we began PRMI work, which we called okay), we aligned and locked the Michelson with AS55Q.  We were able to use a gain as large (abs val) as -15 before the loop started oscillating.  (ETMs, PRM, SRM all misaligned during this).  We measured the UGF of the MICH loop to be 170Hz, with phase margin of 40 degrees.

We then restored the PRM, and tweaked the pointing until the PRC beam at AS overlapped the MICH beam. 

We then started playing with locking.  We were not very successful in using REFL 11 or REFL 55 (I for both, although we also tried 11Q just for kicks).  We then switched to using REFL33I, and had success!!  We are reliably able to lock to the "sideband", and not so reliably lock to the carrier (by flipping the sign of the PRCL loop gain). I say "sideband" with quotes, since we aren't sure that it is the sideband.  We are, however, confident that it is locking, and it's certainly not locked to the carrier.  Videos are at the bottom of the entry.

A list of some values:

Other notes:  We changed AS55's demod phase back to 24.5, from it's atmosphere half-cavity value.  The change from the original value was recorded in elog 8030.

We changed REFL11's demod phase back to 150, which is the value that it was when we had PRMI locked on ~July 10th, 2012.  (We looked up the burt snapshot to check).

FI back, upper right is POP, lower left is REFL, lower right is AS.  It seems as though we may need to redo coil balancing now that we're at vacuum / with the current OSEM values.

[Jenne,Yuta]

Both arms are aligned starting from Y green.
We have all beams unclipped except for IPANG. I think we should ignore IPANG and go on to PRMI locking and FPMI locking using ALS.
IPANG/IPPOS and oplev steering mirrors are kept un-touched after pumping until now.

Current alignment situation:
 - Yarm aligned to green (Y green transmission ~240 uW)
 - TT1/TT2 aligned to Yarm (TRY ~0.86)
 - BS and Xarm alined to each other (TRX ~ with MI fringe in AS)
 - X green is not aligned yet
 - PRMI aligned

Current output beam situation:
 IPPOS - Coming out clear but off in yaw. Not on QPD.
 IPANG - Coming out but too high in pitch and clipped half of the beam. Not on QPD.
 TRY   - On PD/camera.
 POY   - On PD.
 TRX   - On PD/camera.
 POX   - On PD.
 REFL  - Coming out clear, on camera (centered without touching steering mirrors).
 AS    - Coming out clear, on camera (centered without touching steering mirrors).
 POP   - Coming out clear, on camera (upper left on camera).

Oplev values:
Optic    Pre-pump(pit/yaw)    PRFPMI aligned(pit/yaw)
ITMX    -0.26 /  0.60         0.25 /  0.95
ITMY    -0.12 /  0.08         0.50 /  0.39
ETMX    -0.03 / -0.02        -0.47 /  0.19
ETMY     0.37 / -0.62        -0.08 /  0.80
BS      -0.01 / -0.18        -1    /  1 (almost off)
PRM     -0.34 /  0.03        -1    /  1 (almost off)

 All values +/- ~0.01. So, oplevs are not useful for alignment reference.

OSEM values:
Optic    Pre-pump(pit/yaw)    PRFPMI aligned(pit/yaw)
ITMX    -1660 / -1680        -1650 / -1680
ITMY    -1110 /   490        -1070 /   440
ETMX     -330 / -5380         -380 / -5420
ETMY    -1890 /   490        -1850 /   430
BS        370 /   840          360 /   800
PRM      -220 /  -110         -310 /  -110

  All values +/- ~10.
  We checked that if there's ~1200 difference, we still see flash in Watec TR camera. So, OSEM values are quite good reference for optic alignment.

IPANG drift:
  On Saturday, when Rana, Manasa, and I are trying to get Y arm flash, we noticed IPANG was drifting quite a lot in pitch. No calibration is done yet, but it went off the IPANG QPD within ~1 hour (attached).
  When I was aligning Yarm and Xarm at the same time, TRY drifted within ~1 hour. I had to tweak TT1/TT2 mainly in yaw to keep TRY. I also had to keep Yarm alignment to Y green. I'm not sure what is drifting so much. Suspects are TT2, PR2/PR3, Y arm and Y green.

  I made a simple script(/opt/rtcds/caltech/c1/scripts/Alignment/ipkeeper) for keeping input pointing by centering the beam on IPPOS/IPANG using TT1/TT2. I used this for keeping input pointing while scanning Y arm alignment to search for Y arm flash this weekend (/opt/rtcds/caltech/c1/scripts/Alignment/scanArmAlignment.py). But now we have clipped IPANG.


So, what's useful for alignment after pumping?:
  Optic alignment can be close by restoring OSEM values. For input pointing, IPPOS/IPANG are not so useful. Centering the beam on REFL/AS (POP) camera is a good start. But green works better.

 CDS:
    - Check out ASS and A2L working -JENNE
    - Are all whitening filters for PDs toggling correctly? -JENNE, JAMIE

PRMI locking:
    - Adjust I/Q rotation angles for error signals -JENNE, YUTA
    - Adjust filters -JENNE, YUTA
    - Coil balancing for BS (and ITMs/ETMs) -YUTA

PRC characterization in PRMI:
    - Measure PR2 loss from flipping -MANASA
    - Measure mode matching ratio -JENNE, YUTA
    - Measure finesse, PR gain -JENNE, YUTA
    - Calibrate PRM and/or ITM oplevs -MANASA, YUTA
    - Measure g-factor by tilting PRM or ITMs -JAMIE, YUTA
    - Calculate expected mode matching ratio and g-factor -JAMIE
    - Calculate expected finesse, PR gain -JENNE
    - Mode match and align aux laser into AS port -EVAN

ALS:
    - What's the end green situation? Optical layout changed? Laser temperature in CDS? -MANASA
    - What's the PSL green situation? Green trans cameras/PD? Design better layout -ANNALISA
    - Make ALS handing off to DARM/CARM LSC script -JENNE, YUTA
    - Demonstrate FPMI using ALS -JENNE, YUTA
    - Phase tracker characterization -YUTA, KOJI

PRFPMI:
    - Measure mode matching between PRC and arms -JENNE, YUTA
    - Measure PR gain -JENNE, YUTA
    - Calculate expected finesse, PR gain -JENNE

Others:
    - Update optical layout CAD after PR2 flipping -MANASA
    - IMC REFL demod phase rotation -EVAN, ANNALISA
    - Look into PMC drift -JENNE, MANASA
    - Measure RFAM contribution to error signals -YUTA

[Jenne, Evan, Yuta]

After Y alignment, X arm is aligned to IR and we got both arms locked in IR.
There's some dift (input pointing?) and this made aligning both arms tough. I will elog about it later.
Attached is ETMYF. ETMXF, ITMYF, ITMXF when both arms are locked by IR.

Alignment Procedure:
  1. Algined BS/ITMX to get MI fringe in AS. We got X arm flashing at this point.
  2. Use BS/ITMX/ETMX to get TRX maximized, without losing good MI fringe in AS. We reached 0.75.
  3. There was clipping of TRX beam at Xend optics. Since whole IFO alignment is started from Y green, this clipping is because of poor Y green pointing. But we needed clear TRX for aligning Xarm, so we re-arranged Xend TRX path to avoid clipping.

X arm issues:
  - Beam motion at TRX is larger than TRY. Turning off clean table air didn't help. Maybe we need BS oplev on or ETMX coil gain balancing.
  - X green scatters into TRX PD and ETMXT camera. Fix them.

 I made a minor modification to install some output filters in the new global damping GLOBAL box in c1sus.mdl. These will be needed for tuning the suspension drives to compensate for mismatches in the pendulums.

I recompiled and installed the model, but did not start it. Basically same as Jamie left it in 8159. Interestingly, I did not see the new POSOUT that was put in before the SUSPOS DOF filter. I made sure to reopen the .mdl file fresh before making more mods, but for some reason I do not see that update...

Global damping screens are in progress for the new global damping infrastructure Jamie discussed in log #8159. The main overview screen is /opt/rtcds/caltech/c1/medm/c1sus/master/C1SUS_GLOBAL.adl. The overview screen links to a few sub-screens in the same directory called C1SUS_GLOBAL_DAMPFILTERS.adl, C1SUS_GLOBAL_GLOBALTOLOCAL.adl, and C1SUS_GLOBAL_LOCALTOGLOBAL.adl.

This global damping is in intended to damp the 4 test masses along global interferometer degrees of freedom that are orthogonal to the cavity signals. Ideally the result will be that OSEM sensor noise from the damping loops is invisible to the cavity signals. Mismatches in the suspensions' dynamics and gains will cause some noise to leak through anyway, but we should be able to tune some of this out by carefully scaling the drives to each suspension.

[Jamie, Brett, Jenne]

We made some small modifications to the sus_single_control suspension controller library part to get in/out the signals that Brett needs for his "global damping" work.  We brought out the POS signal before the SUSPOS DOF filter, and we added a new GLOBPOS input to accommodate the global damping control signals.  We added a new EPIC input to control a switch between local and global damping.  It's all best seen from this detail from the model:

The POSOUT goto goes to an additional output.  As you can see I did a bunch of cleanup to the spaghetti in this part of the model as well.

As the part has a new input and output now we had to modify c1sus, c1scx, c1scy, and c1mcs models as well.  I did a bunch of cleanup in those models as well.  The models have all been compiled and installed, but a restart is still needed.  I'll do this first thing tomorrow morning.

All changes were committed to the userapps SVN, like they should always be.

We still need to update the SUS MEDM screens to display these new signals, and add switches for the local/global switch.  I'll do this tomorrow.

During the cleanup I found multiple broken links to the sus_single_control library part.  This is not good.  I assume that most of them were accidental, but we need to be careful when modifying things.  If we break those links we could think we're updating controller models when in fact we're not.

The one exception I found was that the MC2 controller link was clearly broken on purpose, as the MC2 controller has additional stuff added to it ("STATE_ESTIMATE"):

I can find no elog that mentions the words "STATE" and "ESTIMATE".  This is obviously very problematic.  I'm assuming Den made these modifications, and I found this report: 7497, which mentions something about "state estimation" and MC2.  I can't find any other record of these changes, or that the MC2 controller was broken from the library.  This is complete mickey mouse bullshit.  Shame shame shame.  Don't ever make changes like this and not log it.

I'm going to let this sit for a day, but tomorrow I'm going to remove replace the MC2 controller with a proper link to the sus_single_control library part.  This work was never logged so it didn't happen as far as I'm concerned.

 That's good news. I was ready to give up and say we should vent and remove the baffles. It will be interesting if you can find out how much the sensors and OL and IPANG are off from their pre-pump values. We should think about how to have better references.

Also, what is the story with the large drift we are seeing in IPANG?

[Koji, Yuta]

We aligned Y arm to Y green and tweaked TT1/TT2 to get IR locked in Y arm.

Alignment procedure:
  1. Align ETMY/ITMY to maximize TEM00 green transmission to PSL table. We reached ~240 uW.

  2. Aligned PRM and TT2 so that PRM reflected beam go through FI and get ITMY-PRM cavity flashing. This is to coarsely align input pointing to Y arm. After this alignment, we got tiny Y arm flash. Input pointing to IPANG QPD was lost.

  3. Aligned TT1/TT2 to maximize TRY in TEM00. We reached ~0.92.

Failed procedure:
  I was struggling with finding Y arm flash. I was using IPPOS/IPANG as input pointing reference, and slider values (C1:SUS-(ITMY|ETMY)_(PIT|YAW)_COMM) or OSEM values (C1:SUS-(ITMY|ETMY)_SUS(PIT|YAW)_IN1) before pumping for Y arm alignment reference. But it was a lot more easier if Y arm is aligned to green and having Yarm cavity axis assured.

Next:
  - X arm flash in IR
  - Steer X end green
  - If X arm or AS looks bad, adjust IR input pointing and Y arm alignment. We have to steer Y end green afterwards.

- IMC PDH demodulation phase adjustment

- Permanent setup for green transmission DC PDs  on the PSL table

 All normal, IFO pressure 1.5e-5 Torr

RGA is pumped by TP-3 in back ground mode.

 I asked John Z to talk with Jamie and then install a new NDS2 server software for us. Jamie may know if this happened or was foiled by the linux1 RAID failure.

In any case, our pyNDS stuff ought to be able to talk to NDS2 or our old NDS1 stuff, I hope.

  This looks pretty good already. Not sure if we can even measure anything reasonable below 0.1 Hz without a lot of thermal shielding.

The 10-20 kHz oscillation may just be the loop shape of the opamp. I think you saw similar effects when using the AD743 with high impedance for the OSEM testing.

I tried to fix the alarms for sensors on the SUS summary screen. I checked earlier elogs and found the setSensors.py script.

I received errors while running the script and pianosa was refused connection to nds. Yuta suspects problems with the lib directory.

Jamie! Can you fix this?

Rana suggested that I measure the OPA827 and OPA140 noise with high source impedance so as to see if we could find the low-frequency current noise corner. Below is a plot of both parts with R_s = 0, 10k, and 100k.

As you can see, both parts are thermal noise limited down to 0.1 Hz for up to R_s = 100k or greater. Given that the broadband current noise level for each part is ~0.5-1 fA/rtHz, this puts an upper limit to the 1/f corner of <100 Hz. This is where the AD743 corner is, so that sounds reasonable. Perhaps I will check with even higher impedance to see if I can find it. I am not sure yet what to make of the ~10-20 kHz instability with high source impedance.

EDIT: The datasheets claim that they are Johnson noise limited up to 1 Mohm, but this is only for the broadband floor, I'd guess, so it doesn't really say anything about the low frequency corner.

Jenne found that;
  0. If all mirrors are "aligned," Yarm flashes.
  1. If SRM is misaligned, Yarm doesn't flash.
  2. If BS is misaligned, Yarm doesn't flash.
  3. If ITMX is misaligned, Yarm still flashes.

So, my hypothesis from this is that I was playing with " TT1 -> TT2 -> ITMY -> BS -> SRM -> BS -> Yarm "  configuration last night.
This hypothesis can explain;
  1. Why I could not get TRY peak more than 0.5 (additional BS reflection makes incident power to Yarm less).
  2. Why I had to change POY11 I/Q mixing angle by ~ 45 deg (because EOM to Yarm length changed).
  3. Why I couldn't lock Yarm stably (additional reflection by BS and SRM made too much beam jitter?).

We are now trying to get "real" Yarm flash.

I'm not sure that Yuta had found the real Yarm flashes last night.  When I came in today, the Yarm would flash.  However I found that the SRM was aligned, and if I misaligned it, the Yarm flashes would disappear.  So somehow the beam getting into the cavity was related to the reflection off of the SRM.

Later, I moved the TTs, leaving ITMY and ETMY alone, after having misaligned SRM (and ITMX) and I found flashes.  This wasn't ideal though, since the beam was much, much too high on IPANG (beam was half falling off the top of the lens, although yaw was pretty good).  That was also when I changed out the ETMYT camera the first time around.  The flashes on the new camera were visible, but much dimmer than with the Watec.

I tried locking the Yarm in this state, but I could never achieve a lock, even momentarily.  It almost seemed like I wasn't sending actuation signal out to the coils, although signal appeared all the way through the chain until the LSC signal summed with the local damping signal.  I also switched the LSC output matrix to try actuating on the ITM, but I was also not able to lock then.  I have switched it back to have Yarm actuate on ETMY.  I could see a nice PDH signal on POY, and nice flashes on TRY, but no lock at all.  The trigger was triggering, but still no catching of the lock.  I'm not really sure what's up.

After playing with a non-locking, poorly aligned Yarm, I started over by recentering the beam on IPPOS and IPANG using the TTs, but have not been able to get flashing in the cavity again.  After much fitzing around, I put the Watec back at ETMYT, in hopes that we can see flashes again at some point, since it's more sensitive than the old Sony.  Still no flashes though.

I have to leave, but Yuta and Manasa are here, and so I'm leaving the IFO in their custody.

Calendars:  The calendar issue discussed previously (http://nodus.ligo.caltech.edu:8080/40m/8098) where the numbers are squished together is very difficult for me to find.  I am not going to worry about it for the time being.

Multiprocessing:   Reviewed the implementation of Multiprocessing in python (using Multiprocessing package).  Wrote a simple test function and ran it on megatron, to verify that multiprocessing could successfully take advantage of megatron’s multiple cores – it could.  Now, I will work on implementing multiprocessing in the program.  I began testing at a section in the program where a for loop calls process_data() (which has a long runtime) multiple times.  The megatron terminals I had open began to run very slowly.  Why?  I believe that the process_data() function loads data into global variables to accomplish its task.  The global variables in the original implementation were cleared before the subsequent calls to process_data().  But in the multiprocessing version, the data is not cleared, meaning the memory fills quickly, which drastically reduces performance.  In the short term, I could try generating fewer processes at a time, wait for them to finish, then clearing the data, then generating more processes, etc.  This will probably generate a nominal performance boost.  In the long-term, restructuring of the way the program handles data may help (but not for sure).  In the coming week I will experiment with these techniques and try to decrease the run time of the program.

According to Google, you can add a line in the crontab to backup the crontab by having the cronback.py script be in the scripts/ directory. It needs to save multiple copies, or else when someone makes the file size zero it will just write a zero size file onto the old backup.

I found some daily cron jobs for op340m I missed last night. Also, I edited timings of hourly jobs to maintain consistency with the past. Some of them looks old, but I will leave as it is for now.
At least, burt, FSSSlowServo and autolockMCmain40m seems like they are working now.
If you notice something is missing, please add it to crontab.

07 * * * * /opt/rtcds/caltech/c1/burt/autoburt/burt.cron >> /opt/rtcds/caltech/c1/burt/burtcron.log
13 * * * * /opt/rtcds/caltech/c1/scripts/general/scripto_cron /opt/rtcds/caltech/c1/scripts/PSL/FSS/FSSSlowServo >/cvs/cds/caltech/logs/scripts/FSSslow.cronlog 2>&1
14,44 * * * * /cvs/cds/caltech/conlog/bin/check_conlogger_and_restart_if_dead
15,45 * * * * /opt/rtcds/caltech/c1/scripts/SUS/rampdown.pl > /dev/null 2>&1
55 * * * *  /opt/rtcds/caltech/c1/scripts/general/scripto_cron /opt/rtcds/caltech/c1/scripts/MC/autolockMCmain40m >/cvs/cds/caltech/logs/scripts/mclock.cronlog 2>&1
59 * * * * /opt/rtcds/caltech/c1/scripts/general/scripto_cron /opt/rtcds/caltech/c1/scripts/PSL/FSS/RCthermalPID.pl >/cvs/cds/caltech/logs/scripts/RCthermalPID.cronlog 2>&1

00 0 * * * /var/scripts/ntp.sh > /dev/null 2>&1
00 4 * * * /opt/rtcds/caltech/c1/scripts/RGA/RGAlogger.cron >> /cvs/cds/caltech/users/rward/RGA/RGAcron.out 2>&1
00 6 * * * /cvs/cds/scripts/backupScripts.pl
00 7 * * * /opt/rtcds/caltech/c1/scripts/AutoUpdate/update_conlog.cron

The camera that Yuta means in his elog from last night/this morning is the scattering camera at the Yend.  The reason (I think) that he had to do this is that Manasa and Jan took the cable for the ETMYT camera, and were using it for their scattering camera.  They mention in elog 8072 that they installed a camera, but they didn't say anything about having taken the ETMYT cable.  This is the kind of thing that is useful to elog!

Anyhow, I have removed the Watec that belongs with the scattering setup, that Yuta borrowed, and put it back on the scattering table-on-a-pedestal. I then realigned the usual ETMYT camera (that Yuta moved out of the way to install the borrowed Watec), and put the ETMYT cable back to its usual place, connected to the Sony camera's box on the floor.

tl;dr: ETMYT camera is back to original state.

EDIT later:  I put the Watec back, since it is more sensitive to IR, so now we have a Watec in the regular ETMYT place.