40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 195 of 339  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  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:

TT.png

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.

 

  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.

Next:

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

  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:

YARMdecenter.png

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.

  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.


Scripts:
  /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

  etc...


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


Next:
 - 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

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

Method:
  Same as in elog #8221.

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

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

  8234   Tue Mar 5 18:36:27 2013 JenneUpdateLSCLSC whitening triggering started

More effort at debugging the LSC whitening. 

Today I tried moving things over to the c1tst model, which runs on the y-end computer, but I crashed c1iscey.  I rebuilt the TST model to a known good state, then cycled the power on c1iscey, and the computer came back up fine. 

I have now backed off and am just writing the code inside a little wrapper script, so that I can just compile and test the code completely independent from the realtime system.  Then once I get all the bugs out, I can try again installing on the actual system.

Still, there are no changes to the functionality of the c1lsc model.  There will not be until I get the c-code for matrix parsing debugged.

The logic, in non-diagram form (I'll make a diagram, but so you can read without waiting):

*** C-code

* Inputs is an array of degree of freedom triggers, the same schmidt triggers used for main LSC locking. (This means it also uses the same thresholds as main triggers.  Side note, now that the WAIT command (see below) works, I want to change the filter module triggers to use the same main trigger, and then just wait a specified time before turning on.)

* Parse the LSC input matrix (internal to the c-code).

     * This tells you which photodiode is being used to control which degree of freedom.

* Multiply rows of the LSC input matrix by the degree of freedom triggers (the same trigger as the main LSC triggers, which is a schmidt trigger).

     * This gives a matrix, where non-zero elements indicate that a photodiode is supposed to be used for a degree of freedom, AND that DoF has been triggered (is locked or has flashed).

* Sum along the columns of the matrix.

     * If a column has a non-zero element, that means that that PD quadrature is used, and has been triggered (by any DoF).

* Apply OR to I and Q quadratures of each PD. 

      * Since the phase rotation happens after whitening and dewhitening, if either I_ERR or Q_ERR is requested (used and triggered), we need to turn on the whitening for both channels.  I am hopeful that this doesn't cause problems for cases when we want to use both quadratures of a PD to control 2 degrees of freedom, but I haven't yet put much thought into it.  COMMENTS WELCOME on this point.

*  Output of c-block is array of PD triggers.  So if either AS11I or AS11Q is triggered, output a "1" for the first element, which corresponds to AS11, etc.

*** LSC model

* Give GoTo/From flag for each DoF trigger to the mux of inputs.

* Go through c-code

* Demux outputs into GoTo/From flags, one per PD (one flag for AS11, one for AS55, and one for ASDC...DC elements count separately, even though they're derived from the same physical PD).

* For each PD, trigger flag goes through WAIT c-code

   * This allows you to define a wait time, in seconds, with an EPICS variable. 

   * Starts counting the wait time as soon as it receives a "1".  Resets counter each time it receives a "0".

    * Output of wait function is ANDed with the current (non-delayed) trigger.

         * This allows for cavity to flash, but if it's not still locked after the wait time, don't actually flip any switches.

* Use delayed ANDed trigger to flip the FM1 switch on both the I and Q filterbank for that PD.

  8235   Tue Mar 5 23:00:08 2013 yutaUpdateLSCYarm and PRC g-factor from misalignment measurement

I fitted intra-cavity power dependance on mirror misalignment plot with parabola to get the g-factor.

  Y arm (tangential) g = 0.44 +0.01 -0.01  (measured value before was 0.3765 +/- 0.003 elog #6938)
  PRC (sagittal)       g = 0.97 +0.01 -0.04 (expected value is 0.939 elog #8068)
  PRC (tangential)   g = 0.96 +0.02 -0.05 (expected value is 0.966 elog #8068)

Error bars are just statistical errors from the fitting. Estimated systematic error is ~0.04 (or more).
Here, I assumed PR2/PR3 to be flat to make the calculation simple. I assumed PRC to be curved PRM - flat ITM cavity, and Y arm to be curved ETMY - flat ITMY cavity.

g-factor calculation:
  Intra-cavity power decrease can be written as

dP/P = (dx/w0)**2 + (dt/a0)**2

where dx and dt are translation and tilt of the beam axis introduced by mirror misalignment. w0 is waist size and a0 is divergence angle (= lamb/(pi*w0)).

  When considering a flat-curved cavity with cavity length L, dx and dt can be expressed as;

(dx)    1  ( L*g     L ) (a2)
(  ) = --- (           )*(  )
(dt)   1-g ( -(1-g)  0 ) (a1)


using misalignments of mirrors(a1,a2). Here, mirror1 is curved, and mirror2 is flat. See Kakeru document /users/OLD/kakeru/oplev_calibration/oplev.pdf for derivation.

  So, power decrease by flat mirror misalignment can be expressed as

dP/P = pi*L/lamb * g/(1-g)/sqrt(g*(1-g)) * a2**2

  For curved mirror is

dP/P = pi*L/lamb * 1/(1-g)/sqrt(g*(1-g)) * a1**2

  We can derive g-factor by measuring dP dependance on a1/a2.


Script:
  My script lives in /opt/rtcds/caltech/c1/scripts/dither/gfactormeasurement/plotgfactor.py.
  It least fitts data with parabola (scipy.optimize.leastsq) and gets g-factor value from bisection (scipy.optimize.bisect).


Result:
  Below are the plots of fitted curves.

ITMY_YAW_20130305_DC.pngPRM_PIT_20130305a_DC.pngPRM_YAW_20130305b_DC.png


Systematic effect:
  [oplev calibration] We noticed QPD rotation when calibration oplevs (elog #8232). ~5 deg of rotation makes 10% of systematic error to the oplev calibration and this introduces ~0.04 of error to g-factor values. This

  [oplev linear range] Oplev linear range is ~100 urad, so this is OK.

  [assumption of flat PR2/PR3] Result here doesn't tell you g-factor of PRM itself, but some "effective g-factor" of PRM/PR2/PR3 combination. We can compare with FINESSE result.

  [intra-cavity power drift] If there's significant intra-cavity power drift during the measurement, if effects parabola fitting. We can make this affect small by sweeping the mirror alignment in both direction and take average.


By the way:
  I kept getting PRC g-factor of something like 0.999999 because I had power normalization mistake in my calculation. My script worked for Yarm because TRY is already normalized.
  Also, I was multiplying the oplev calibration factor wrong last night (see elog #8230).

Next:
  - Compare with FINESSE result.
  - Is this g-factor enough? Is this presicion enough? Calculate from mirror angluar motion.
  - More stable lock of PRMI.
  - Try dithering method to measure g-factor to check consistency and also to study systematic effect.

  8236   Tue Mar 5 23:37:11 2013 yutaUpdateSUSPRM angular motion spectra

I measured PRM angular motion spectra (in daytime today).
PRM angular motion is ~ 10 urad in RMS when undamped and ~1 urad in RMS when damped.
If PR2/PR3 angular motions are something like this, and their motion are not enhanced when PRC is locked, measured g-factor of PRC looks OK. But considering the error we have, maybe we are not OK yet. We need calculation.

PRMangularmotion.png

  8237   Wed Mar 6 02:46:20 2013 ManasaUpdateLSCPRMI locking for g-factor measurement

 [Yuta, Manasa]

PRMI alignment procedure for carrier locking has been kept the same except that a couple of issues that have persisted are now taken care of.

We were able to keep PRMI locked for over a minute (POPDC measures 2200) .

1. Trigger levels to MICH and PRCL for PRMI locking have been changed
Whenever we enabled LSC controls to lock PRMI, ITMY moves haphazard if PRM is not aligned. This is because of the low trigger levels of POPDC which keeps MICH triggered all the time while we align PRM. Increasing POPDC trigger (Upper level : 1000 and Lower level:20) for both MICH and PRCL solved this problem and resulted in a more stable ITMY. Also this has stabilized locking greatly if the alignment is fair enough.

2. C1:SUS-ITMY_LSC_GAIN reset
Quoting Yuta's elog "  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)."
This has been reset to 1.0 and it has not affected PRMI locking.


Mystery

1. Filter module (FM1) on PRCL and MICH show significant delay while enabling and disabling.

2. I tried to fix PMC alignment (PMC trans was 0.76). I was not able to get PMC trans more than 0.79.
PMC has been this way since yesterday.

3. MICH is still bright when locked (ASDC_OUT reads 0.08 for dark and 2.0 for bright). We suspect it is because of the AS55_I error offset that persists even after running LSCoffsets script.

4. PRMI shows some dither at 3Hz when locked.
POPDCspec_PRMIlocked.png

  8238   Wed Mar 6 08:40:03 2013 SteveUpdateVACfirst scan of this pumpdown

 Pumpdown 75 - Maglev - day 12

Precondition: 66 days at atm, installed TIP-TILTs with coils that  replaced PZT-Jena input steering

 

Attachment 1: pd75m12d.png
pd75m12d.png
Attachment 2: pd75mRGA12d.png
pd75mRGA12d.png
  8239   Wed Mar 6 09:44:29 2013 KojiUpdateLSCPRMI locking for g-factor measurement

- What about normalizing POPDC to indicate the carrier recycling gain?

- When you align the PMC, confirm FSS SLOW DC is around zero. Some region of the slow thermal actuation makes the laser source emit at multiple frequencies. In the case, the cavity visibility get worse.

- Do you guys think we can determine if the TT is longitudinally quiet enough? Is there any comparison between the simple Michelson and the PRC motion in m/rtHz?

  8240   Wed Mar 6 11:33:09 2013 steveUpdateSAFETYsafety audit 2013

 

                                                 Recommended correction list:

1,  refill- upgrade first aid boxes

2,  maintain 18" ceiling to bookshelf clearance so the ceiling fire sprinklers are not blocked: room 101

3,  label chilled water supply & return valves in IFO room

4,  calibrate bake room hoods annually

5,  update safety sign at fenced storage

 

              40m still to do list:

1,   clean and measure all safety glasses

2,   annual crane inspection is scheduled for 8am March 19, 1013

3,   make PSL encloser shelf earthquake proof

 

Do you see something that is not safe? Add it to this list please.

 

 

Attachment 1: IMG_0010.JPG
IMG_0010.JPG
  8241   Wed Mar 6 16:14:27 2013 SteveUpdateSAFETYsafety training

Chloe Ling, Max Horton and Annalisa Allocca have received basic 40m specific safety training.

Attachment 1: IMG_500.jpg
IMG_500.jpg
  8243   Wed Mar 6 18:27:24 2013 JamieUpdateGeneralnow recording input TT channels to frames, but why no autoburt?

I spent some time trying to figure out how to get a record of the pointing of the input pointing tip-tilt (TT) channels.

Frames

Currently the TT pointing is done via the offset in the PIT/YAW filter banks, ie. C1:IOO-TT1_PIT_OFFSET, which is an EPICS record.  I added these channels to the C0EDCU.ini, which (I'm pretty sure) specifies which EPICS channels are recorded to frames.

controls@pianosa:~ 0$ grep C1:IOO-TT /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini 
[C1:IOO-TT1_PIT_OFFSET]
[C1:IOO-TT1_YAW_OFFSET]
[C1:IOO-TT2_PIT_OFFSET]
[C1:IOO-TT2_YAW_OFFSET]
controls@pianosa:~ 0$ 

I then confirmed that the data is being recorded:

controls@pianosa:~ 0$ FrChannels /frames/full/10466/C-R-1046657424-16.gwf | grep TT
C1:IOO-TT1_PIT_OFFSET 16
C1:IOO-TT1_YAW_OFFSET 16
C1:IOO-TT2_PIT_OFFSET 16
C1:IOO-TT2_YAW_OFFSET 16
controls@pianosa:~ 0$ 

BURT

The EPICS records for these channels *should* be recorded by autoburt, but Yuta noticed they were not:

controls@pianosa:~ 0$ grep -R C1:IOO-TT1_PIT_OFFSET /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2013/Mar/6/
controls@pianosa:~ 1$

The autoburt log seems to indicate some sort of connection problem:

controls@pianosa:! 130$ grep C1:IOO-TT1_PIT_OFFSET /opt/rtcds/caltech/c1/burt/autoburt/logs/c1assepics.log
pv >C1:IOO-TT1_PIT_OFFSET< nreq=-1
pv >C1:IOO-TT1_PIT_OFFSET.HSV< nreq=-1
pv >C1:IOO-TT1_PIT_OFFSET.LSV< nreq=-1
pv >C1:IOO-TT1_PIT_OFFSET.HIGH< nreq=-1
pv >C1:IOO-TT1_PIT_OFFSET.LOW< nreq=-1
C1:IOO-TT1_PIT_OFFSET ... ca_search_and_connect() ... OK
C1:IOO-TT1_PIT_OFFSET.HSV ... ca_search_and_connect() ... OK
C1:IOO-TT1_PIT_OFFSET.LSV ... ca_search_and_connect() ... OK
C1:IOO-TT1_PIT_OFFSET.HIGH ... ca_search_and_connect() ... OK
C1:IOO-TT1_PIT_OFFSET.LOW ... ca_search_and_connect() ... OK
C1:IOO-TT1_PIT_OFFSET ... not connected so no ca_array_get_callback()
C1:IOO-TT1_PIT_OFFSET.HSV ... not connected so no ca_array_get_callback()
C1:IOO-TT1_PIT_OFFSET.LSV ... not connected so no ca_array_get_callback()
C1:IOO-TT1_PIT_OFFSET.HIGH ... not connected so no ca_array_get_callback()
C1:IOO-TT1_PIT_OFFSET.LOW ... not connected so no ca_array_get_callback()
controls@pianosa:~ 0$ 

This is in contrast to successfully recorded channels:

controls@pianosa:~ 0$ grep C1:LSC-DARM_OFFSET /opt/rtcds/caltech/c1/burt/autoburt/logs/c1lscepics.log
pv >C1:LSC-DARM_OFFSET< nreq=-1
pv >C1:LSC-DARM_OFFSET.HSV< nreq=-1
pv >C1:LSC-DARM_OFFSET.LSV< nreq=-1
pv >C1:LSC-DARM_OFFSET.HIGH< nreq=-1
pv >C1:LSC-DARM_OFFSET.LOW< nreq=-1
C1:LSC-DARM_OFFSET ... ca_search_and_connect() ... OK
C1:LSC-DARM_OFFSET.HSV ... ca_search_and_connect() ... OK
C1:LSC-DARM_OFFSET.LSV ... ca_search_and_connect() ... OK
C1:LSC-DARM_OFFSET.HIGH ... ca_search_and_connect() ... OK
C1:LSC-DARM_OFFSET.LOW ... ca_search_and_connect() ... OK
C1:LSC-DARM_OFFSET ... ca_array_get_callback() nreq 1 ... OK
C1:LSC-DARM_OFFSET.HSV ... ca_array_get_callback() nreq 1 ... OK
C1:LSC-DARM_OFFSET.LSV ... ca_array_get_callback() nreq 1 ... OK
C1:LSC-DARM_OFFSET.HIGH ... ca_array_get_callback() nreq 1 ... OK
C1:LSC-DARM_OFFSET.LOW ... ca_array_get_callback() nreq 1 ... OK
controls@pianosa:~ 0$ 

In fact all the records in the c1assepics log are showing the same "not connected so no ca_array_get_callback()" error.  I don't know what the issue is.  I have no problem reading the values from the command line, with e.g. ezcaread.  So I'm perplexed.

If anyone has any idea why the c1ass EPICS records would fail to autoburt, let me know.

  8244   Wed Mar 6 18:51:07 2013 AnnalisaUpdateAlignmentAuxiliary laser installed for FSR and TMS measurement of the PRC

We want to measure the g-factor of the PRC using the beat note of the main laser with an auxiliary NPRO laser.

We are going to phase lock the NPRO to the main laser (taking it from POY) and then we will inject the NPRO  through the AS edge of the ITMY.

Today Sendhil and I installed the auxiliary laser on the ITMY table moving it from the AS table.

We also installed the beam steering optics, except the BS which will launch the beam through the AR edge of the ITMY.

To do: install the BS, take the POY beam and mix it with the auxiliary laser on a photodiode to phase lock the two lasers, do better calculations for the mode matching optics to be used for the auxiliary laser beam.

Attachment 1: IMG_3-6-13.JPG
IMG_3-6-13.JPG
  8245   Wed Mar 6 20:21:34 2013 JamieUpdateGeneralBeatbox pulled from rack

I pulled the beatbox from the 1X2 rack so that I could try to hack in some output whitening filters.  These are shamefully absent because of my mis-manufacturing of the power on the board.

Right now we're just using the MON output.  The MON output buffer (U10) is the only chip in the output section that's stuffed:

2013-03-06-195232_1060x927_scrot.png

The power problem is that all the AD829s were drawn with their power lines reversed.  We fixed this by flipping the +15 and -15 power planes and not stuffing the differential output drivers (AD8672).

It's possible to hack in some resistors/capacitors around U10 to get us some filtering there.  It's also possible to just stuff U9, which is where the whitening is supposed to be, then just jump it's output over to the MON output jack.  That might be the cleanest solution, with the least amount of hacking on the board.

In any event, we really need to make a v2 of these boards ASAP.  Before we do that, though, we need to figure out what we're going to do with the "disco comparator" stage back near the RF input.  (There are also a bunch of other improvements that will be incorporated into v2).

  8246   Wed Mar 6 21:58:39 2013 JenneUpdateElectronicsPOX whitening was fine all along

After my investigations this afternoon (with help from Sendhil and Shivaraj), I do not find any problems with the POX whitening switching.

Earlier this afternoon / evening I was misleading myself into thinking that either the switching component (ADG333ABR) was broken, or that the whitening op amps (LT1124CS8) were broken on the POX I&Q and POY I&Q channels.  I had not realized until Jamie mentioned the possibility, that some of the DC gain stages were on for POX and POY.  POX and POY (I&Q for both) all had +36dB of gain, so when I was injecting my 60Hz sine wave into those channels, the whitening opamps were already saturated, which is why it didn't look like I was getting any gain.  When I set them all to 0dB (which is what AS11 and REFL11, the other 2 PDs using that whitening board, were set to), all 8 channels behaved the same.

The shaped whitening (which is either bypassed or not, depending on the condition of the software "unwhite" switch) is 2 filters in series, each with a zero at 15Hz, and a pole at 150Hz, with DC gain of 0dB.  For a 60Hz sine wave, this gives a factor of ~4 from each stage.  After setting all of the whitening gains to 0dB, I was able to see on all 8 channels of the board an input sine wave, a larger (by 4-ish) sine wave, and then a larger (by 4ish again) sine.  When I looked at the output of the switch of all 8 channels, the signal was either the same as the input amplitude, or the same as after the 2nd whitening stage, depending on the "unwhite" filters.

Before looking at actual signals, Sendhil and I also had checked to see that indeed, the board was receiving the digital signal input to the switch chip, requesting switching based on the state of the "unwhite" filters.

I looked through the elogs, and the only "symptoms" I find are from an IFO check-up session that Koji, Den and I had back in May, where we declared in the elog that POX whitening may or may not be switching.  See elog 6595.  We didn't mention what the actual symptoms we saw were, so unless Koji or Den remember something that I don't, I cannot confirm that we are no longer seeing those symptoms.  However, based on the number of "?" after "POX whitening not toggling the analog whitening", I don't think that we were totally sure that something was wrong in the first place.

Anyhow, the whitening board in the LSC rack labeled "WF1", serving AS11, REFL11, POX11 and POY11 has had a thorough checkup, and I give it a clean bill of health.

  8247   Wed Mar 6 22:11:19 2013 KojiUpdateElectronicsPOX whitening was fine all along

At the time you, den and I worked together, we could not lock the X-arm on TEM00 with the FM1s of the POX11 on.
We could lock the arm only on the higher order mode but he gain was low. Once we turned off the FM1s, we immediately
locked the cavity on TEM00.

Don't you have the direct measurement of the TF with FM1 on and off?

  8248   Thu Mar 7 01:43:35 2013 yutaUpdateLSCcalibrated MI differential length spectra

Free swing MI differential length is 86 nm RMS and residual length when locked is 0.045 nm RMS(in-loop).
Looks very quiet. Comparison with PRMI is the next step.

Openloop transfer function:
  OLTF of simple MI lock using AS55_Q_ERR as error signal and ITMs as actuators is below.
  UGF ~ 90 Hz, phase margin ~ 40deg
  I added 16 Hz resonant gain to suppress bounce mode.
LSCMICHOLTF_MI.png

MI differential length spectra:
  Below. Calibration was done using calibrated AS55_Q_ERR and actuator response(elog #8242)
MImotion.png


  Expected free swing is calculated using

x_free = (1+G)/G * A * fb

where G is openloop transfer function, A is actuator response, fb is feedback signal(C1:LSC_ITMX/Y_IN1) spectrum. I used A as simple pendulum with resonant frequency at 1 Hz, Q = 5. Since free swing RMS is dominated by this resonance, RMS depends on this Q assumption.

  8249   Thu Mar 7 11:43:15 2013 JenneUpdateElectronicsPOX and POY whitening DC gain left low

Manasa and Jan were having trouble locking the Yarm, and asked me to take a look at it.  After a good long time of trying to figure out what was going on, it finally occurred to me that I did not turn the DC gain on POX and POY back to the nominal 36dB.  As soon as I did that, both arms acquired lock.  Ooops.

  8250   Thu Mar 7 12:39:12 2013 JenneUpdateLockingErudite discussion on PRMI locking

[Rana, Jenne, Yuta] (late last night)

After some trouble getting the PRMI to lock with REFL55 I&Q last night, we began to think about the size of signals everywhere, and the coupling of the sidebands in the different cavity configurations.  We have determined that it is possible that the Q phase signal is too small everywhere, so the PRMI will never be easy to lock. The Q phase will be smaller than iLIGO equivalents since the modulation frequencies are lower, and we have a small Schnupp asymmetry. The calculations of signals at each port were all done for the DRMI case, where sidebands get recycled more, so signals get larger.  If locking the PRMI is "hopeless" due to very small signals, we should stop trying, move on with other things, and come back to the corner when we have the DRMI ready. In order to figure out if it is reasonable to keep working on the PRMI, we must calculate the size of all of our signals at each port, and convert them into real units (if we expect a 1mVpp signal at REFL11Q, we're not going to successfully lock MICH with that).

So, we should:

* Calculate sideband signals at AS and REFL, for 11 and 55 MHz, for the PRMI case.

* Convert those signals into physical units (Watts -> Amps -> Volts).

* In parallel, work on dual arm ALS, and FPMI locking.

   * Try using ALS CARM for frequency stabilization.

   * Hand off from ALS CARM and DARM to PSL.

* To do ALS-FPMI, we should:

     * Use A2L to center the IR spots on all arm cavity mirrors.

     * Align green beams to the arms.

    * For each arm, determine which frequency (arm green or PSL green) is higher.

          * Lock the arm in green, align Beat PD. 

          * Push ETM, watch beat in the phase tracker.

          * Repeat for other arm.

     * Use ALS input matrix to construct CARM and DARM signals.

         * Check by shaking ALS-CARM, watch both X and Y beat signals - if they move in the same direction, we were right, but if they move in opposite directions we have flipped CARM and DARM.

    * Send the ALS-CARM signal to MC2, or the analog common mode board.

  8251   Thu Mar 7 16:55:28 2013 KojiUpdateLockingErudite discussion on PRMI locking

PRMI for the sidebands may have different situation. Investigate our wiki to find our the simulation result.

Also I'm not confident how much is the modulation depth at 55MHz is.

  8252   Thu Mar 7 18:12:03 2013 yutaUpdateAlignmentInput beam drift ~ 0.1 mrad/h in pitch

[Jenne, Manasa, Yuta]

We temporarily centered the beam on IPANG to see input pointing drift. From eyeball, drift was ~ 0.1 mrad/h in pitch.

What we did:

  1. Aligned TT1/TT2 and aligned input pointing to Yarm.

  2. Tweaked TT2 in pitch to center the beam on the first steering mirror of IPANG path. We still saw Yarm flash in higher order modes at this point. Before tweaking, the beam was hitting at the top edge.

  3. Centered the beam on IPANG QPD.

  4. Moved IPPOS first steering mirror because IPPOS beam was not on the mirror (off in yaw, on mirror edge). Also, IPPOS beam was coming out clipped in yaw.

  5. Centered the beam on IPPOS QPD. We put lens in the path to focus the beam on the QPD.

  6. Left input pointing untouched for 4 hours.

  7. Restored TT2 again. We tried to align Y arm with IPANG available, but it was not possible without touching TRY path and AS was also clipped.

Result:
  Below is the trend of IPANG sum, X, and Y. IPANG Y (IBQPD_Y) drifted by ~0.8 counts in 4 hours. IPANG is not calibrated yet, but Jenne used her eyeball to measure beam position shift on IPANG steering mirror. It shifted by ~2 mm. This means, input pointing drifts ~0.1 mrad/h in pitch.
IPangulardrift.png

Discussion:
  Compared with yaw, pitch drift is quite large considering beam size at ETMY(~5 mm). We can monitor input pointing drift in weekends get longer trend.

Note:
  - IPANG and IPPOS are both changed from the state before pumping.

  8253   Thu Mar 7 18:41:03 2013 JenneUpdateElectronicsPOX whitening was fine all along

Here are the transfer functions that we took back in 2011 (see elog 4915 and replies) for POX:

POX11I.png

POX11Q.png

The table of all whitening filter zpk values is on the wiki: https://wiki-40m.ligo.caltech.edu/Electronics/WhiteningFilters

  8254   Thu Mar 7 18:48:43 2013 yutaUpdateComputer Scripts / Programsreleasing my secret scripts

I released/updated my secret scripts to real scripts directory.
I checked they run correctly (but maybe not working correctly).


burtlookup.py
  in ./scripts/general/burtlookup.py

  It returns a value of a specified channel in the past using burt snapshots.
  Help is available.


GRtoggler.py
  in ./scripts/ALS/GRtoggler.py

  Toggles green shutter until it locks TEM00.
  Help is available. Threshold setting is critical.


MCbeeper.py
  in ./scripts/MC/MCbeeper.py

  Beeps when MC is unlocked.


yutalib.py
  in ./scripts/pylibs/yutalib.py

  Python library for data loading, saving and plotting.
  I think it's well commented.


pyezcalib.py
  in ./scripts/pylibs/pyezcalib.py

  Python library for ezca stuff.
  It has functions for recording and resetting default channel values in case of interrupt.


./scripts/PRCmodescan
  Python scripts for PRC modescan. Not well commented. Not organized.
  See elog #8012


./scripts/Alignment
  Python and shell scripts for alignment work. Not well commented.
  See elog #8164


./scripts/SUS/OplevCalibration
  Python scripts for oplev calibration. Not well commented.
  See elog #8221


./scripts/dither/gfactormeasurement
  Python scripts for g-factor measurement. Not well commented.
  See elog #8230


./scripts/SUS/ActuatorCalib
  Python scripts for calibrating actuators. Not well commented.
  See elog #8242

  8255   Fri Mar 8 02:17:04 2013 yutaUpdateLSCcalibration of PRM actuator

[Manasa, Yuta]

We measured AC response of PRM actuator using PRM-ITMY cavity.
Result is

PRM:  (19.6 +/- 0.3) x 10^{-9} (Hz/f)^2 m/counts

It is almost the same as in 2011 (elog #5583). We took the same procedure as what Kiwamu did.

What we did:
  1. Aligned PRMI in usual procedure, mis-aligned ITMX and locked PRM-ITMY cavity using REFL55_Q_ERR. POP DC was about 18 when locked.

  2. Made UGF of PRM-ITMY cavity lock at 10 Hz and introduced elliptic LPF at 50 Hz(OLTF below).
OLTF_PRCL.png


  3. Measured transfer function from C1:LSC_ITMY_EXC to C1:LSC_REFL55_Q_ERR. Dividing this by ITMY actuator response(measured in elog #8242) gives calibration of REFL55_Q.

  4. Measured transfer function from C1:LSC_PRM_EXC to C1:LSC_REFL55_Q_ERR to calibrate PRM actuator.

Result:
  Calibration factor for REFL55_Q for PRM-ITMY cavity was (1.37 +/- 0.02) x 10^9 counts/m (plot below). Error is mainly from statistical error of the average.
calibREFL55Q.png


  Measured AC response (50-200 Hz) of PRM is below.
actcalibPRM.png


Next:
  - Measure free-run length spectrum of PRM-ITMY cavity and compare with MICH free-run.

  8256   Fri Mar 8 03:07:19 2013 yutaUpdateLSCcalibrated PRM-ITMY length spectra

Measured free swing PRM-ITMY length was 230 nm RMS.
MI differential length was 85 nm RMS(elog #8248). This tells you that PR2, PR3 are not so noisy compared with usual suspensions.

Openloop transfer function:
  OLTF of PRM-ITMY cavity lock using REFL55_Q_ERR as error signal and PRM as actuator is below.
  UGF ~ 120 Hz, phase margin ~ 50 deg.
  Somehow, phase delay was 460 usec, which is smaller than the empirical value 550 usec.
LSCPRCLOLTF_PRITMY.png


PRM-ITMY length spectra:
  Below. Calibration was done using calibrated REFL55_Q_ERR and actuator response(elog #8255).
PRITMYmotion.png

  8257   Fri Mar 8 12:57:57 2013 AnnalisaUpdateABSLBS installed on ITMY table

 Sendhil and I installed the S polarized BS on the ITMY table to steer the NPRO beam through the AR wedge and align it to the POY beam. 

We took a shutter from the BSPRM table (which was not used) and a beam dump from the AS table (which was used by the auxiliary laser already removed and installed on the ITMY).

To do: do better alignment of the NPRO beam, maybe installing some iris after the BS and before the AS wedge, phase lock the two beams. 

  8258   Fri Mar 8 13:42:35 2013 JenneUpdateABSLBS installed on ITMY table

Re:  POY beam reduction.

We are able to lock the Yarm with the beam / gain as it is.  I had thought we might need to increase the DC gain in the whitening board by a factor of 2, but so far it's fine.

  8259   Fri Mar 8 15:27:42 2013 yutaUpdateGreen LockingPSL green shutter installed

[Manasa, Yuta]

Mechanical shutter for PSL green is installed right in front of PSL doubling crystal.
This is for blocking PSL green when we want to measure the power of green beam from the arms.

The shutter was previously sitting on AS table un-used. Channel name to control this shutter was C1:AUX-SPS_Shutter. This should be renamed as C1:AUX-GREEN_PSL_Shutter.

Next:
  We are going to restore both arm green in parallel to PRMI work.

  - Coarsely align IR input pointing and arms using A2L
  - Align X green
  - Install green DC PDs and cameras on PSL table

  8260   Fri Mar 8 16:02:52 2013 JenneUpdateAlignmentGetting closer to beam centering on Yarm

I'm working on getting the input beam centered on the Yarm optics.  To do this, I measured the spot positions, move the tip tilts, realign the cavity, then measure the new spot positions.  While doing this, I am also moving the BS and Xarm optics to keep the Xarm aligned, so that I don't have to do hard beam-finding later.

Here is the plot of spot measurements today.  The last measurement was taken with no moving, or realigning, just several hours later after speaking with our Indian visitors.  I'm closer than I was, but there is more work to do.

YARMdecenter_zoom_8Mar2013.png

  8262   Fri Mar 8 20:51:00 2013 ManasaUpdateAlignmentInput beam drift - investigation **IMPORTANT**

Checking the drift in input pointing (TT2 is the main suspect)

I have centered IPPOS and the 2/3 part of IPANG that comes out of vacuum to the QPDs to see the drift in input pointing over the weekend or atleast overnight.

If anybody would be working with the IFO alignment over the weekend, do so only after recording the drift in IPANG and IPPOS or if you will be working later tonight, center them ion the QPDs before leaving.

  8263   Fri Mar 8 21:00:05 2013 ManasaUpdatePSLPMC fixed

Quote:

  Mystery

1. Filter module (FM1) on PRCL and MICH show significant delay while enabling and disabling.

2. I tried to fix PMC alignment (PMC trans was 0.76). I was not able to get PMC trans more than 0.79.
PMC has been this way since yesterday.

3. MICH is still bright when locked (ASDC_OUT reads 0.08 for dark and 2.0 for bright). We suspect it is because of the AS55_I error offset that persists even after running LSCoffsets script.

4. PRMI shows some dither at 3Hz when locked.

 [Koji, Manasa]

PMC is fixed with 0.84 in transmission. It was misaligned in pitch (fixing this increased PMC_trans to 0.822 from 0.773) and Koji also touched the wave plate and polarizer (changed PMC_trans to 0.845).

  8264   Sat Mar 9 19:29:27 2013 KojiUpdatePSLModulation depth

Last night I measured the modulation depth of the MC incident beam.


Method:

The beam is taken from one of the  PO beam at the wedge plate before the IMC.
After removing the knife edge to dump this beam, the beam is sent to the west side
of the PSL table and put into the OSA cavity.
[The beam dump was returned after the measurement.]

I had some confusion and after all I use the OSA labeled as AS OSA rather than the one on the PSL table.
[The AS OSA was returned to the AP table.]

The transmission was detected by PDA255 and filtered by ITHACO 1201 preamp with G=10, no HPF, 30kHz LPF.
It was confirmed that the peak amplitudes are not reduced by the LPF filter. The resulting time series
was recorded by an oscilloscope.

Three measurements have been taken. The 11MHz peaks are offset by the carrier peak. They appropriately
removed. The ratio of the sideband and carrier peaks is converted to the modulation depth using the following formula.

P_sb / P_ca = [J1(m)/J0(m)]^2


Measurement

The modulation depth for the 11MHz: 0.190 +/- 0.003

The modulation depth for the 55MHz: 0.2564 +/- 0.0003

The three scans showed very similar numbers. That's why the statistical error is such small.
I don't think the systematic error is not such good.

This number is much different form the previous meaurement by Mirko.

http://nodus.ligo.caltech.edu:8080/40m/5519 m=0.14 (11MHz) & 0.17 (55MHz)
but the measured voltages and the modulatio depths are inconsistent.

http://nodus.ligo.caltech.edu:8080/40m/5462 m=0.17 (11MHz) & 0.19 (55MHz)

Probably the modulation depths should be checked by the IMC again.
However, it is certain that the 55MHz modulation exists, and even larger than the 11MHz one.

The next is to confirm that the modulation frequency is matched with the IMC FSR.
It is to make sure that the modulation is transmitted to the main IFO without attenuation.

Attachment 1: mod_depth.pdf
mod_depth.pdf
  8267   Mon Mar 11 12:29:25 2013 ManasaUpdateAlignmentInput beam drift - weekend trend

I centered ipang and ippos on the QPDs (using only the steering mirrors) and wanted to see the drift over the weekend.

Observation
1. IPANG has drifted (QPD sum changed from -6 to -2.5); but it is still on the QPD.
2. IPPOS does not show any drift.
3. In the plot: The jump in IPANG on the left occured when I centered the beam to the QPD and that on the right is from the 4.7 earthquake and its aftershocks this morning.

Follow-up questions
1. Do we need to worry about this drift?
2. Which of the two TTs is resposible for the drift?
3. Do the TTs tend to drift in the same direction everytime?

P.S. The TTs were not touched to center on IPANG and IPPOS. The last time they were touched was nearly 6 hours before the centering. So the question of any immediate hysteresis is ruled out.

IPANG_drift.png

  8268   Mon Mar 11 14:10:05 2013 JenneUpdateEnvironmentMC suspensions moved by this morning's earthquakes

None of the suspensions All suspensions were tripped (edited by Manasa; see elog 8271) by this morning's earthquakes, but the MC suspensions are in a different place than they were a day ago.  The big symptom here is that the MCWFS are pulling the mode cleaner slightly out of alignment.  When it first locks, the reflected light is ~0.5, but when the WFS are engaged it goes up to ~0.8.  I'm going to put the MC optics back where they were (according to SUSpit and SUSyaw), and tweak up the MC from there. Probably other optics are affected, but I was going to work on continuing to center the beam on the Yarm optics, so I'll deal with the rest of the IFO in a minute.

Note re: lower plot - the mxstream was down on c1sus and c1ioo, so no fast channels on those computers were recorded for almost a day.  (The plot is one day 4 days long).  I was going to plot the seismic blrms along with the suspension pointing values, but there's no data saved, so there's no point.  Jamie tells me he thinks this spontaneous loss of the mxstream is fixed in the next RCG upgrade, and that we can talk about upgrading the RCG after the LSC meeting, so this data loss is no longer an issue.

EQ.png

MC-SUS-kicked-EQ.png

EDIT:  Plot with 4 days of trend, rather than just 1.  The MC alignment (as measured by MC refl) has been very bad for several days.  I'm going to move the suspensions back to their last good place.  Also, Manasa realigned the MC after the EQ, so I don't actually know where the suspensions got kicked to this morning.

  8269   Mon Mar 11 15:52:46 2013 JenneUpdateIOOMC spots centered, WFS realigned

Looking more into the MC, it appears that no spot centering was done after the power attenuation optics were removed (see elog 8142).  Since Manasa had changed the zig-zag steering after putting in the attenuation optics (elog 7843) the pointing was not correct for the nominal MC.  This is (likely) why Yuta and Manasa found some significant decentering.  If Manasa's tweaks when preparing for vent were primarily in yaw, then this is most definitely what happened.  A note, this is why we should change to inserting the attenuation optics before the PMC, but even so, one should adjust the angle of the PBS, NOT the zig zag optics, to get the input pointing back to the same place.  This is also why it is useful to ensure the attenuation optics do not block the PSL pointing QPD pickoff, so it is easier to adjust the PBS to get back to the original pointing.

In any case, I touched the last zig-zag mirror in yaw today (the top of the knob was moved away from me) to recenter the spots.

MCspots_11Mar2013.png

With the MC unlocked, I centered the WFS.  Now the MC is back to its normal working condition....WFS are on, autolocker is on, reflected DC power is low, etc., etc.

  8270   Mon Mar 11 16:29:29 2013 SteveUpdatePEMproposed seismometer locations

Granite base 20" x 20" x 5"  locations are on the CES side of our IFO arms:  as shown ETMY_ south-west, ETMX_north-east, ITMX_south-east . No height limitation. This side of the tube has no traffic.

SS cover McMaster#  41815T4  (H) SS container cov

Attachment 1: ETMY_sw.jpg
ETMY_sw.jpg
Attachment 2: ITMX_se.jpg
ITMX_se.jpg
Attachment 3: ETMX_ne.jpg
ETMX_ne.jpg
  8271   Mon Mar 11 17:18:00 2013 ManasaUpdateEnvironmentEarthquake: Suspensions tripped and MC realigned

I found all suspensions including the MC suspensions tripped this morning after the earthquake.

I damped all the optics and realigned MC mirrors to lock at refl 0.57.

PRM and SRM tripped a couple of times due to the aftershocks that followed; but were damped eventually.

  8272   Mon Mar 11 19:01:21 2013 JenneUpdatePEMproposed seismometer locations

This is my interpretation of where Steve is proposing to place the seismometers (he wrote ITMX southwest, but I'm pretty sure from the photo he means southeast).

I think his point is that these locations are on the less-used side of the beam tube, so they will not be in the way.  Also, they are not underneath the tube, so we will not have any problems putting the covers on/taking them off.

 

 

SeismometerProposedPositions_11March2013.pdf

  8273   Mon Mar 11 22:28:30 2013 Max HortonUpdateSummary PagesFixing Plot Limits

Quick Note on Multiprocessing:  The multiprocessing was plugged into the codebase on March 4. Since then, the various pages that appear when you click on certain tabs (such as the page found here: https://nodus.ligo.caltech.edu:30889/40m-summary/archive_daily/20130304/ifo/dc_mon/ from clicking the 'IFO' tab) don't display graphs.  But, the graphs are being generated (if you click here or here, you will find the two graphs that are supposed to be displayed).  So, for some reason, the multiprocessing is preventing these graphs from appearing, even though they are being generated.  I rolled back the multiprocessing changes temporarily, so that the newly generated pages look correct until I find the cause of this.

Fixing Plot Limits:  The plots generated by the summary_pages.py script have a few problems, one of which is: the graphs don't choose their boundaries in a very useful way.  For example, in these pressure plots, the dropout 0 values 'ruin' the graph in the sense that they cause the plot to be scaled from 0 to 760, instead of a more useful range like 740 to 760 (which would allow us to see details better).

The call to the plotting functions begins in process_data() of summary_pages.py, around line 972, with a call to plot_data().  This function takes in a data list (which represents the x-y data values, as well as a few other fields such as axes labels).  The easiest way to fix the plots would be to "cleanse" the data list before calling plot_data().  In doing so, we would remove dropout values and obtain a more meaningful plot.

To observe the data list that is passed to plot_data(), I added the following code:

      # outfile is a string that represents the name of the .png file that will be generated by the code.
      print_verbose("Saving data into a file.")
      print_verbose(outfile)
      outfile_mch = open(outfile + '.dat', 'w')

      # at this point in process_data(), data is an array that should contain the desired data values.
      if (data == []):
          print_verbose("Empty data!")
      print >> outfile_mch, data
      outfile_mch.close()

When I ran this in the code midday, it gave a human-readable array of values that appeared to match the plots of pressure (i.e. values between 740 and 760, with a few dropout 0 values).  However, when I let the code run overnight, instead of observing a nice list in 'outfile.dat', I observed:

[('Pressure', array([  1.04667840e+09,   1.04667846e+09,   1.04667852e+09, ...,
         1.04674284e+09,   1.04674290e+09,   1.04674296e+09]), masked_array(data = [ 744.11076965  744.14254761  744.14889221 ...,  742.01931356  742.05930208
  742.03433228],
             mask = False,
       fill_value = 1e+20)
)]

I.e. there was an ellipsis (...) instead of actual data, for some reason.  Python does this when printing lists in a few specific situations.  The most common of which is that the list is recursively defined.  For example:

INPUT:
a = [5]
a.append(a)
print a

OUTPUT:
[5, [...]]

It doesn't seem possible that the definitions for the data array become recursive (especially since the test worked midday).  Perhaps the list becomes too long, and python doesn't want to print it all because of some setting.

Instead, I will use cPickle to save the data.  The disadvantage is that the output is not human readable.  But cPickle is very simple to use.  I added the lines:

      import cPickle
      cPickle.dump(data, open(outfile + 'pickle.dat', 'w'))

This should save the 'data' array into a file, from which it can be later retrieved by cPickle.load().

Next:
There are other modules I can use that will produce human-readable output, but I'll stick with cPickle for now since it's well supported.  Once I verify this works, I will be able to do two things:
1) Cut out the dropout data values to make better plots.
2) When the process_data() function is run in its current form, it reprocesses all the data every time.  Instead, I will be able to draw the existing data out of the cPickle file I create.  So, I can load the existing data, and only add new values.  This will help the program run faster.

  8274   Tue Mar 12 00:35:56 2013 JenneUpdateComputersFB's RAID is beeping

[Manasa, Jenne]

Manasa just went inside to recenter the AS beam on the camera after our Yarm spot centering exercises of the evening, and heard a loud beeping.  We determined that it is the RAID attached to the framebuilder, which holds all of our frame data that is beeping incessantly.  The top center power switch on the back (there are FOUR power switches, and 3 power cables, btw.  That's a lot) had a red light next to it, so I power cycled the box.  After the box came back up, it started beeping again, with the same front panel message:

H/W monitor power #1 failed.

Right now the fb is trying to stay connected to things, and we can kind of use dataviewer, but we lose our connection to the framebuilder every ~30 seconds or so.  This rough timing estimate comes from how often we see the fb-related lights on the frontend status screen cycle from green to white to red back to green (or, how long do the lights stay green before going white again).  We weren't having trouble before the RAID went down a few minutes ago, so I'm hopeful that once that's fixed, the fb will be fine. 

In other news, just to make Jamie's day a little bit better, Dataviewer does not open on Pianosa or Rosalba.  The window opens, but it stays a blank grey box.  This has been going on for Pianosa for a few days, but it's new (to me at least) on Rosalba.  This is different from the lack of ability to connect to the fb that Rossa and Ottavia are seeing.

  8275   Tue Mar 12 00:45:50 2013 JenneUpdateIOOMC weird again

~20 minutes ago, maybe right around the time the fb's RAID died (elog 8274) the mode cleaner started behaving weirdly again.  The reflected value is very high, even with the WFS on.  Earlier this evening, I saw that with the WFS off, the MC reflection was high, but the WFS brought it back down to ~0.7 or 0.8.  But now it's ~1.3.  With the WFS off, the reflected value is ~1.1.  I don't really understand.

Also, the PMC has been drifting in alignment in pitch all day, but a lot more later in the day. The PMC trans is 0.800 right now, but it was as high as 0.825 today, and spent most of the day in the high 0.81xxx range today.

I would provide plots, but as mentioned in elog 8274, we can't get data right now.

  8276   Tue Mar 12 00:58:05 2013 ManasaUpdateAlignmentYarm - Spot positions centered

[Jenne, Manasa]


Spot centering on Y arm - DONE!

Alignment procedure
1. I went back to the IFO alignment slider positions from Friday. The Y arm was flashing in HOM because the earthquake this morning tripped all suspensions and the slider values were not real. X arm did not have any flashes.

2. Y arm aligned using TT1 and TT2. Spot centering measured using Jenne's A2L_Yarm script.

Spot positions:
           ITMY    ETMY
Pitch    6.48    4.39
Yaw     -7.42    -3.135

3. I started centering in pitch. I used the same in-vac alignment method (down on TT1 and up on TT2 in pitch) and measured spot positions.

4. When the spot positions were centered in pitch, I started with yaw alignment.

5. I had to use TT1 to center on ITMY and move TT2 and ITMY to center on ETMY.

6. Spot positions after centering:

                          ITMY    ETMY
Pitch    -1.22    -1.277
Yaw       0.42    -0.731


7. I wanted to go back and tweak the pitch cenetering; but framebuilder failed and dataviewer kept loosing connection to fb

Notes
AS seems clipped. Although it could be because of the misaligned BS.

IPANG was centered on the QPD, but it is so clipped, that I'm not sure we can trust it.  Max sum right now is -4, rather than the usual -8 or -9.

Tomorrow:

Once fb is fixed, we should align the X-arm which will be followed by green alignment.

Mystery
Over the last few weeks, it has been observed that there is some strong seismic activity that starts at around 9PM everyday and goes on for a couple of hours. It seems unlikely that it is our geologist neighbour (Jenne met with the grad student who works on the noisy experiment).
 

  8277   Tue Mar 12 11:49:18 2013 JenneUpdateIOOMC weird again

[Manasa, Annalisa, Jenne]

The MC wasn't locking on TEM00 this morning, and the WFS kept pulling the MC out of alignment.  The MC was realigned, and the WFS spots are back to being roughly centered (all of this only touching the MC sliders), but the WFS keep doing bad things.  They're okay, and improve the alignment slightly at first, but as soon as the FM1 integrator comes on, the MC alignment immediately starts going bad, and within a second or so the MC has unlocked.

The WFS are off right now, and we'll keep investigating after LIGOX.

  8278   Tue Mar 12 12:06:22 2013 JamieUpdateComputersFB recovered, RAID power supply #1 dead

The framebuilder RAID is back online.  The disk had been mounted read-only (see below) so daqd couldn't write frames, which was in turn causing it to segfault immediately, so it was constantly restarting.

The jetstor RAID unit itself has a dead power supply.  This is not fatal, since it has three.  It has three so it can continue to function if one fails.  I have removed the bad supply and gave it to Steve so he can get a suitable replacement.

Some recovery had to be done on fb to get everything back up and running again.  I ran into issues trying to do it on the fly, so I eventually just rebooted.  It seemed to come back ok, except for something going on with daqd.  It was reporting the following error upon restart:

[Tue Mar 12 11:43:54 2013] main profiler warning: 0 empty blocks in the buffer

It was spitting out this message about once a second, until eventually the daqd died.  When it restarted it seemed to come back up fine.  I'm not exactly clear what those messages were about, but I think it has something to do with not being able to dump it's data buffers to disk.  I'm guessing that this was a residual problem from the umounted /frames, which somehow cleared on it's own.  Everything seems to be ok now.

Quote:

Manasa just went inside to recenter the AS beam on the camera after our Yarm spot centering exercises of the evening, and heard a loud beeping.  We determined that it is the RAID attached to the framebuilder, which holds all of our frame data that is beeping incessantly.  The top center power switch on the back (there are FOUR power switches, and 3 power cables, btw.  That's a lot) had a red light next to it, so I power cycled the box.  After the box came back up, it started beeping again, with the same front panel message:

H/W monitor power #1 failed.

DO NOT DO THIS.  This is what caused all the problems.  The unit has three redundant power supplies, for just this reason.  It was probably continuing to function fine.  The beeping was just to tell you that there was something that needed attention.  Rebooting the device does nothing to solve the problem.  Rebooting in an attempt to silence beeping is not a solution.  Shutting of the RAID unit is basically the equivalent of ripping out a mounted external USB drive.  You can damage the filesystem that way.  The disk was still functioning properly.  As far as I understand it the only problem was the beeping, and there were no other issues.  After you hard rebooted the device, fb lost it's mounted disk and then went into emergency mode, which was to remount the disk read-only.  It didn't understand what was going on, only that the disk seemed to disappear and the reappear.  This was then what caused the problems.  It was not the beeping, it was the restarting the RAID that was mounted on fb.

Computers are not like regular pieces of hardware.  You can't just yank the power on them.  Worse yet is yanking the power on a device that is connected to a computer.  DON"T DO THIS UNLESS YOU KNOW WHAT YOU"RE DOING.  If the device is a disk drive, then doing this is a sure-fire way to damage data on disk.

 

  8279   Tue Mar 12 14:02:22 2013 JenneUpdateAlignmentBeam drift - mystery partially solved?

Steve just told those of us in the control room that the custodian who goes into the IFO room regularly steps on the blue support beams to reach the top of the chambers to clean them.  Since we have seen in the past that stepping on the blue tubes can give the tables a bit of a kick, this could help explain some of the drift, particularly if it was mostly coming from TT2.  The custodian has promised Steve that he won't step on the blue beams anymore.

This doesn't explain any of the ~1 hour timescale drift that we see in the afternoons/evenings, so that's still mysterious.

  8280   Tue Mar 12 14:51:00 2013 SteveUpdateComputersbuy warranty or not ?

 Details of the warranties are posted on wiki power supply cost, warranty described, cost

.......I’ve also attached a warranty renewal quote.  A 1 year warranty renewal is usually $.... per year, but we gave you special pricing of $.... / year if you renew both units.  This pricing is also special due to the fact that both warranties expired awhile ago.  We usually require that the warranty renewal begin on the date of expiration, but we will waive this for you this time if both are renewed.

 

JetStor SATA 416S, SN: SB09040111A3 – expired 04/24/2012 (3 years old)

 

JetStor SATA 516F, SN: SB09080016P – expired on 08/21/2012........

 

. Are we keep it for an other 2 years? buy warranty or buy better storage.

 

  8281   Wed Mar 13 02:48:13 2013 JenneUpdateIOOMC all better

Koji reminded me (again....this is probably the  2nd or 3rd time I've "discovered" this, at least) that the script

..../scripts/MC/WFS/WFS_FilterBank_offsets

exists, and that we should use it sometimes.  See his elog 7452 for details. 

 

Notes about using this script:

* Only use it after MC has been very well aligned.  MC REFL DC should be less than 0.5 when the MC is locked (with the DC value ~4.5 with the MC unlocked, as usual).  This is hard to achieve, but important.  Also, check the MC spot centering.

* With the WFS servo off, but the MC locked and light on the WFS diodes, run the script. 

ELOG V3.1.3-