Masha and Yaakov - this is an excellent opportunity for you guys to test out your triangulation stuff!  Also, it might give a lot of good data times for the learning algorithms.

Maybe you should also put out the 3 accelerometers that Yaakov isn't using (take them off their cube, so they can be placed separately), then you'll have 6 sensors for vertical motion.  Or you can leave the accelerometers as a cube, and have 4 3-axis sensors (3 seismometers + accelerometer set).

Below is angular spectra of every suspended core optics.
As you can see, there's a peak at 3.3 Hz for BS and PRM angular motion. Compared with other optics, they look large.

I briefly checked suspension filters and found that BounceRoll filters and f2a filters are not turned on for BS.
I checked elog and there was no reason for them to be off, so I turned them on. It didn't change angular spectra very much, though.

I'm going to check BS suspension damping and see where 3.3 Hz peak comes from.

Note that oplev quadrant sums are different for every optics, so we can't simply compare angular motion between optics from OLPIT/OLYAW. But for OSEMs, there are "cnt2um" which calibrate sensor outputs into um. and input matrix should be normalized, so we can compare SUSPIT/SUSYAW with other optics.

I centered all oplevs to do this measurement.
Quadrant sum (C1:SUS-XXX_OLSUM) for each optic now is

ITMX   ITMY   ETMX   ETMY     BS    PRM    SRM
2456  14630   1476  14885   3650   4302   2937   (counts)


  

phone: 626-395-2465

This week, my work fell into two categories: Artificial Neural Networks and lab-related projects.

Artificial Neural Networks

- I played around with radial basis functions and k-means classification algorithms for a bit in order to develop an algorithm to pick out various features of seismic signals. However, I soon realized that k-means is an extremely slow algorithm in practice, and that radial basis functions are thus difficult to implement since their centers are chosen by the k-means algorithm in practice.

- Thus, I moved on to artificial neural networks. Specifically, I chose to implement a sigmoidal neural network, where the activation function of each neuron is f(u) = 1/ (1 + e-u/T), T constant, which is nice because it's bounded in [0, 1]. Classification, then, is achieved by generating a final output vector from the output layer of the form [c1, c2, c3, ..., cN] where N is the number of classes, ci = 1 (ideally) if the input is of class i, and ck = 0 otherwise.

- First, I built a network with randomly generated weights, ten neurons in the one hidden layer, and two output neurons - to simply classify [1, 0] (earthquake) and [0, 1] (not an earthquake). I ran this on fake input I generated myself, and it quickly converged to error 0. Thus, I decided to built a network for real data.

- My current network is a 2-layer, 10 neuron / 2 neuron sigmoidal network that also classified earthquake / not an earthquake. It trains in roughly 80 - 100 iterations (it's learning curve on training data it attached). It decimates full data from DataViewer by a factor of 256 in order to run faster.

- Next steps: currently, my greatest limitation is data - I can use US Geological Survey statistics to classify each earthquake (so that N = 10, rather than 2, for example), but I would like definite training data on people, cars, trucks, etc. for supervised learning, in order to develop those classes. Currently, however, the seismometers are being used for mine and Yaakov's triangulation project, so this may have to wait a few days.

Lab-Related Projects

- I apologize for all of the E-logs, but I changed the filters in the RMS system (to elliptic and butterworth filters) and changed the seismic.strip display file.

- I repositioned the seismometers so that Yaakov and I can triangulate signals and determine seismic noise hot-spots (as a side-project).

Right now I'm going to try for more classes based on USGS statistics, and I will also explore other data sources Den suggested.

Thanks for your help, everybody in 40m!

These past two weeks, I've been working on simulating a basic Fabry-Perot cavity.  I finished up a simulation involving static, non-suspension mirrors last week. It was supposed to output the electric field in the cavities given a certain shaking (of the mirrors), and the interesting thing was that it outputted the real and imaginary components seperately, so I ended up with six different bode plots. Since we're only interested in the real part, bodes 2, 4, and 6 can be discarded (see attachment 1). There was a LOT of split-peak behavior, and I think it has to do either with matlab overloading or with the modes of the cavity being very close together (I actually think the first is more likely since a smaller value of T_1 resulted in actual peaks instead of split ones).

At any rate, there really wasn't much I could improve on that simulation (neither was there any point), but I attach the subsystem governing the electric field in the cavity as a matter of academic interest (see attachment 2). So I moved onto simulations where the mirrors are actually suspended pendulums as they are in reality.

A basic simulation of the suspended mirrors gave me fairly good results (see attachment 3). A negative Q resulted in a phase flip, detuning the resonance from the wrong side resulted in a complete loss of the resonance peak, and the peak looked fairly consistent with what it should be. The simulation itself is pretty bare bones, and relies on the two transfer functions P(s) and K(s); P(s) is the transfer function for translating the force of the shaking of the two test masses (lumped together into one transfer function) into actual displacement. Note that s = i*w, where w is the frequency of the force being applied. K(s), on the other hand, is the transfer function that feeds displacement back into the original applied force-based shaking. Like I said, pretty bare bones, but working (see attachment 4 for a bode plot of a standard detuning value and positive Q). Tweaking the restoring (or anti restoring, depending on the sign of the detuning) force constant (K_0 for short) results in some interesting behavior. The most realistic results are produced for K_0 = 1e4, when the gain is much lower overall but the peak in resonance gets you a gain of 100 in dB.  For those curious as to where I got P(s) and K(s), see "Measurement of radiation-pressure-induced optomechanical dynamics in a suspended Fabry-Perot cavity" by Thomas Corbitt, et. al.

I'm currently working on a more realistic simulation, with frequency and force noise as well as electronic feedback (via transfer functions, see attachment 5). The biggest thing so far has been trying to get the electronic transfer functions right. Corbitt's group gave some really interesting transfer functions (H_f(s) and H_l(s) for short; H_f(s) gives the frequency-based electronic transfer function, while H_l(s) gives the length-based electronic transfer function), which I've been trying to copy so that I can reproduce their results (see attachment 6). It looks like H_l(s) is a lowpass Butterworth filter, while H_f(s) is a Bessel filter (order TBD). Once that is successful, I'll figure out what H_f(s) and H_l(s) are for us (they might be the same!), add in degrees of freedom, and my first shot at the OSEM system of figuring out where the mirror's position is.

I have been working on configuration of the Daily Summary webpages and have been attempting to create a "PSL health" page.  This page will display the PMC power, the temperature on the PSL table and the PSL table microphone levels.  Thus far, I have managed to make the extra PSL tab and configure the graph of the interior temperature, using channel C1:PSL-FSS_RMTEMP.

I have been attempting to make a spectrogram for one of the PMC channels, but there is an issue with the spectrogram setup, as Duncan Macleod noted in ELOG 6686:

"At the moment a package version issue means the spectrogram doesn't work, but the spectrum should. At the time of writing, to use the spectrum simple add 'plot-dataplot2'."

Because of this issue, I have also been trying to make the spectrogram plots work.  Thus far, I have fixed the issue with one of the spectrogram plots, but there are several problems with the other four that I need to address.  I have also been looking at the microphone channels and trying to make the plot for them work.  I checked which microphone was on the PSL table and plotted it in matplotlib to make sure it was working.  However, when I tried to incorporate it into the daily summary pages, the script stops at that point!  It might simply be taking an excessively long time, but I have to figure out why this is the case.

                                                 (I am using channel C1:PEM-MIC_6_IN1_DQ, if this is blatantly wrong, please let me know!!)

The main point of this ELOG is that I have working test-daily summary pages online!  They can be found here:

https://nodus.ligo.caltech.edu:30889/40m-summary-test/archive_daily/20120710/

Also, if anyone has more requests for what they would like to see on the finalized summary pages site, please respond to this post or email me at: endavison@umail.ucsb.edu

It is not as dramatic as PRMI, but I could see BS 3.3 Hz motion at AS and REFL when MI is locked at dark fringe.
Below is uncalibrated spectra of REFLDC and ASDC when
  Red: MI is locked at dark fringe
  Blue: there's no light (PSL shutter closed)

We have to do something to get rid of this.

My hypothesis from the measurements below, to explain PRMI beam spot motion is;

  Stack motion at 3.3 Hz largely couples to BS and PRM angular motion.
  LSC for PRMI try to compensate this 3.3 Hz motion because they appear in the error signal.
  But since it's not length, failing and even adding more angular motion.

Some plots:
  1. Uncalibrated spectra of POPDC and ASDC when PRMI is locked. This tells you that beam motion seen at POP is 3.3 Hz.

  2. Uncalibrated spectra of feedback signal to BS and PRM. This tells you that LSC is actuating BS and PRM mainly at 3.3 Hz. I think this is because beam spot on PD moves at 3.3 Hz and so faking the error signal.

  3. Below left is uncalibrated spectra of BS, ITMX, ITMY, PRM (and ETMY) angular motion measured using oplevs. I centered oplevs on these optics (except ETMY, which was mis-aligned during PRMI lock). It looks like BS and PRM motion at 3.3 Hz is larger than other optics. Also, there's some coherence between POPDC and BS/PRM motion. We see some coherence with ITMs and even with ETMY, which is completely independent from PRMI. I think this is because 3.3 Hz motion is originated from the ground (stack) motion.

  left:            right:

  4. Above right is the same spectra, but when PRMI is not locked. It looks like there's no big change compared with PRMI locked. When locked, there's some excess for BS and PRM at ~1-3 Hz. I think this is from LSC feedback, which in principle, doesn't affect any angular motion.

Next:
  - Why BS and PRM has large 3.3 Hz peak compared with other optics?
  - Is 3.3 Hz peak effecting MI lock or arm lock?
  - How can we monitor PR2/3 angular motion?

PRMI glitch certainly comes from power recylcing gain fluctuation.
I confirmed this by
  - Reading the value of POPDC at the time when there's glitch in error signals
      -> There was some threshold for POPDC to make a glitch
  - Look closer to the glitch
      -> It was oscillation in ~400Hz, where we have phase flip in PRCL/MICH servo

Next is to find why we have power recycling gain fluctuation. I want to see the correlation between alignment fluctuation of optics and POPDC.

Glitch analysis:
  Below is the plot of
   Red   PRCL error signal (C1:LSC-REFL33_I_ERR)
   Green MICH erorr signal (C1:LSC-AS55_Q_ERR)
   Blue  PRC intra-cavity power (C1:LSC-POPDC_OUT)
  when PRMI is carrier locked.



  Time when there is a glitch in error signal is marked. Value of POPDC at that time is also marked. It looks like there's some threshold (dotted blue line).
  It sometimes doesn't show glitch even if POPDC is above the "threshold". It is maybe because of alignment fluctuation. Intra-cavity power gets high, but power at PDs get low, or vice versa.

  Right plot is closer look. Glitch is a sudden oscillation at ~400 Hz. It is the frequency where we have phase flip in PRCL/MICH openloop transfer function now(see elog #6950).

I centetered PRM oplev, lowered gain and PRM oplev servo is not oscillating any more.
It is OK for more than a softball practice.

C1:SUS-PRM_OLPIT_GAIN = 0.15  (was 0.5)
C1:SUS-PRM_OLYAW_GAIN = -0.3  (was 0.7)

Openloop transfer function:
  Oplev Pitch: gain ~ 12 at 0.69 Hz resonance
  Oplev Yaw: gain ~ 18 at 0.83 Hz resonance


  I adjusted the gain so that oplev damps resonance as much as possible, but not introduce additional noise. I did no calculation, but just measured OSEM spectra (SUSPIT and SUSYAW). Below, you can see the noise reduces at resonance when oplev servo is on, and not increasing at other frequencies. It was introducing noise before. Someone should do more systematic adjustment of oplev servos for all the optics.


 

 Highlighting good, ALL CAPS LESS SO!

I modified filiters for LSC_MICH and LSC_PRCL again to cope with power recycling gain fluctuation.
After some more alignment, power recycling gain increased (but still ~3.7). It fluctuates more than a factor of 2, and I began to see glitches again. So I needed more gain margin, as Koji pointed out.

I played around with filters, but I couldn't remove all the glitches. Gain margin now look OK in principle.
It looks like PRM motion is related. Since PRM doesn't have oplev now, I will see PRM oplev tomorrow.

New openloop transfer function:
 LSC_MICH
   UGF ~100 Hz, phase margin ~ 50 deg
   no phase flip in less than factor of ~5 gain change
   550 usec delay
 LSC_PRCL
   UGF ~100 Hz, phase margin ~ 70 deg (phase bump at UGF)
   no phase flip in less than factor of ~5 gain change
   550 usec delay


Power recylcing gain:
  It is now ~3.7. It fluctuates pretty much. See time series data below when I locked PRMI. MICH and PRCL locks at the same time.

G = (1600-244)/(266-244)*0.06 = 3.7


 

The phase margins looks still too small.

Do You need such high gain at LF? This is not a high finesse cavity so can we sacrifice
some DC gain while gaining more phase around UGFs?

Otherwise, the gain fluctuation should be nicely compensated (i.e. fancy normalization).

I modified filiters for LSC_MICH and LSC_PRCL.
Although modes we can see at POP and AS look still bad, error signals are less glitchy than I see before (elog #6886).

Measured power recylcing gain for PRMI was 1.6 (??)

Openloop transfer function for LSC_MICH:
  UGF ~130Hz, phase margin ~30 deg
  550 usec delay


APOLOGIES: I forgot "pi" in previous delay calculation. (I put notes on elogs #6940 and #6941)

Openloop transfer function for LSC_PRCL:
  UGF ~130Hz, phase margin ~30 deg
  550 usec delay
  A bump cam be seen in ~200 Hz. Coupling of DOFs?


Beam shape and motion:
   Below left is the Sensoray capture of AS/REFL/POP when PRMI is carrier locked.


  Beam spot motion looks less bouncy than before, but it still shows motion mostly at ~3.3Hz. This might be from PRM motion. Above right is uncalibrated spectra of POPDC and REFLDC. You can see 3.3 Hz peak. This peak has some coherence with PRM motion measured by oplevs. I centered BS/PRM oplev to do this measurement.

Power recycling gain:
 - Definition and designed value
  Power recylcing gain is

G = (PRC intracavity power) / (incident power)

  When MI is perfectly symmetric, this can be written as

G  = (t_PRM/1-r_PRM*r_ITM)**2

  where t_i, r_i is amplitude transmissivity, reflectivity. Inserting the designed values;

 t_PRM = sqrt(0.0575)
 r_ITM = sqrt(1-0.014)

  designed power recycling gain for PRMI is

G = 44

 - Measurement
  POP power when PRM is misaligned and MI is locked at dark fringe is

P_mis = P_in * T_PRM * (1-T_PR3) * (1-T_ITM) * T_PR3

  POP power when PRMI is locked is

P_PR = P_intra * T_PR3

  So,

G = P_intra / P_in = (P_PR / P_mis) * T_PRM * (1-T_PR3) * (1-T_ITM) ~ (P_PR / P_mis) * 0.06

  I measured power of POP using C1:LSC-POPDC_OUT. It was 268 when PRM is misalined and MI is locked at dark fringe. Also, it was ~850 when PRMI is carrier locked. When closing PSL shutter, it was ~246. So,

G_PR = (850-246)/(268-246) * 0.06 = 1.6

  It looks too small.

Today I REPOSITIONED THE SEISMOMETERS in order to triangulate noise sources (as Rana suggested).

I re-levelled all of them, locked them, and turned them on. They should be located out of sight, but just in case:

GUR 1 IS DOWN THE X-ARM, behind the interferometer.

GUR 2 IS BETWEEN THE TWO ARMS, BEHIND THE CABLE TRAP THAT RUNS PARALLEL TO THE X-ARM.

STS 1 IS DOWN THE Y-ARM behind the interferometer.

I'll wait a day for them to stabilize (continuing to reset STS-1 every hour or so) and then begin taking data tomorrow morning, depending on the condition of the signal.

Ideally, I'd like a few days' worth of data, so I'll update when I've changed the configuration back to the way it was prior.

[Masha, Jenne]

Masha is moving the seismometers, so they are all off right now.  Were they on, they would see a bunch of noise from the guy outside the 40m front door who is installing a safety shower.

The c1oaf model hasn't been running for a few days (since the leap second problems we were having last week).  I had looked into it, but finally figured it out (with Jamie's help) today. 

The BURT restore has to be given to the model during startup, but for whatever reason it wasn't BURT restoring until *after* the model had already failed to start.  The symptoms were:  no 'heartbeat' for the oaf model, no connection to the fb, NO SYNC on the GDS screen, 0x4000.  the BURT restore button was green, which threw me off the scent, but that's just because it did, in fact, get set, just way too late.

I ended up looking in the dmesg of the lsc computer, and the last set of stuff was several lines of "[3354303.626446] c1oaf: Epics burt restore is 0".  Nothing else was written after that.  Jamie pointed out that this meant the BURT restore wasn't getting sent before the model unloaded itself and decided not to run.

The solution:  restart the model, and manually click the BURT restore button as soon as you're able (after everything comes back from being white).  We used to have to do this, but then there was a "fix", which apparently isn't super robust and failed for the oaf (even though it used to work just fine).  Bugzilla report submitted.

The RMS signals generated by the updated filtering process are now on the wall. The NaN issue is gone it seems, and the template has been changed. Thanks for your help, Jenne. 

I locked MI while both arm length are stabilized at IR resonance. This could be done using DC READOUT, in other words, use AS_DC as MICH error signal.
Lock using RF signals are still not successful.

I adjusted filters of ALS to give more phase margin.
RMS of stabilized X/Y arm length is 97 pm and 65 pm respectively.

X arm ALS:
- Openloop transfer function
UGF ~160 Hz, phase margin 30 deg
1600 usec delay (LSC-XARM had 1800 usec delay)     500 usec delay (LSC-XARM had 570 usec delay) - Edited by Yuta on July 9



- Arm length spectra
   Red is the free run spectrum. Measured using C1:ALS-BEATX_FINE_PHASE_OUT. Calibration factor is 1.32 nm/deg.
   Green is the out-of-loop spectrum. Measured using C1:LSC-POX11_I_ERR. Calibration factor is 3.8e12 counts/m.
   Blue is the in-loop spectrum. Measured using C1:ALS-BEATX_FINE_PHASE_OUT.
   Black is the expected spectrum from openloop transfer function, such as (free run)/|1+G|.



   Out-of-loop estimation of RMS during X ALS is 97 pm.
   RMS mostly comes from 1 Hz and 3.3 Hz peak.
   Out-of-loop and in-loop agrees at around 10-20 Hz.

Y arm ALS:
- Openloop transfer function
UGF ~130 Hz, phase margin 20 deg
2400 usec delay (LSC-XARM had 1800 usec delay)     760 usec delay (LSC-XARM had 570 usec delay) - Edited by Yuta on July 9



- Arm length spectra
   Red is the free run spectrum. Measured using C1:ALS-BEATY_FINE_PHASE_OUT. Calibration factor is 1.30 nm/deg.
   Green is the out-of-loop spectrum. Measured using C1:LSC-POY11_I_ERR. Calibration factor is 1.4e12 counts/m.
   Blue is the in-loop spectrum. Measured using C1:ALS-BEATY_FINE_PHASE_OUT.
   Black is the expected spectrum from openloop transferfunction, such as (free run)/|1+G|.


   Out-of-loop estimation of RMS during X ALS is 65 pm.
   RMS mostly comes from 1 Hz and 3.3 Hz peak.
   Out-of-loop and in-loop agrees at around 3-40 Hz.

RMS of X/Y arm length using POX/POY lock is <160 pm and <120 pm respectively. RMS of free swinging X/Y arm length is both 0.17 um.

I used ALS error signal for out-of-loop evaluation of IR lock. We can even use ALS error signal when arm is free swinging because phase tracking ALS error signal is linear to arm length.
ALS error signal might not be as good as POX/POY. So, this out-of-loop estimation might be not so good.

X arm lock using POX11:
- Openloop transfer function
   I adjusted filter (C1:LSC-XARM) gain and now, UGF ~150 Hz, phase margin ~20 deg.
  570 usec delay (number in the figure is wrong) - Edited by Yuta on July 9


- Arm length spectra
   Red is the free run spectrum. Measured using C1:ALS-BEATX_FINE_PHASE_OUT, calibration factor in frequency is 9.81 kHz/deg (see elog #6938), so calibration factor is 1.32 nm/deg.
   Green is the out-of-loop spectrum. Measured using C1:ALS-BEATX_FINE_PHASE_OUT.
   Blue is the in-loop spectrum. Measured using C1:LSC-POX11_I_ERR, calibration factor is 3.8e12 counts/m (see elog #6841).
   Black is the expected spectrum from openloop transfer function, such as (free run)/|1+G|.



  Out-of-loop estimation of RMS during POX lock is 160 pm. But since this looks too large, ALS error signal might not see actual arm length change when arm length is locked.
  Also, it is interesting that ALS error signal sees 24 Hz peak, but POX doesn't. Roll mode coupling to green?

Y arm lock using POY11:
- Openloop transfer function
   I adjusted filter (C1:LSC-YARM) gain and now, UGF ~150 Hz, phase margin ~20 deg.
  570 usec delay (number in the figure is wrong) - Edited by Yuta on July 9


- Arm length spectra
   Red is the free run spectrum. Measured using C1:ALS-BEATY_FINE_PHASE_OUT, calibration factor in frequency is 9.65 kHz/deg (see elog #6938), so calibration factor is 1.30 nm/deg.
   Green is the out-of-loop spectrum. Measured using C1:ALS-BEATY_FINE_PHASE_OUT.
   Blue is the in-loop spectrum. Measured using C1:LSC-POY11_I_ERR, calibration factor is 1.4e12 counts/m (see elog #6834).
   Black is the expected spectrum from openloop transferfunction, such as (free run)/|1+G|.



  Out-of-loop estimation of RMS during POY lock is 120 pm. But since this looks too large, ALS error signal might not see actual arm length change when arm length is locked.
  Also, it is interesting that ALS error signal sees 16.5 Hz peak, but POY doesn't. Bounce mode coupling to green?

Next:
  - Noise budgeting of phase tracking ALS
  - Is it possible to lock MI when RMS of arm length during POX/POY lock increased to ~100pm?

These aren't so bad. (Look at this entry)

And interestingly the ETM curvatures are closer to ATF measurements than Coastline's measurement. (Look at wiki)

FSR for X/Y arm are 3.97 +/- 0.03 MHz and 3.96 +/- 0.02 MHz respectively. This means X/Y arm lengths are 37.6 +/- 0.3 m and 37.9 +/- 0.2 m respectively.
I calibrated the mode scan results using 11MHz sideband as frequency reference.
Calibration factor between the phase of the phase tracker and IR frequency is 9.81 +/- 0.05 kHz/deg for X arm, 9.65 +/- 0.02 kHz/deg for Y arm.

Calculation:
  For the mode scan measurements, we swept the phase of the phase tracker linearly with time. Previous calculation was done without calibrating seconds into actual IR frequency. The first order calibration can be done using modulation frequency as reference. Note that I'm still assuming our sweep was linear here.

  Relation between FSR and modulation frequency can be written in

f_mod = n * nu_FSR + nu_f

  where f_mod is the modulation frequency, n is an integer, nu_f = mod(nu_FSR,f_mod).
  nu_FSR and nu_f are measurable values (in seconds) from the mode scan. We know that f_mod = 11065910 Hz (elog #6027). We also know that nu_FSR is designed to be ~3.7 MHz(=c/2L). So, n = 2.
  We can calculate f_mod in seconds, so we can calibrate seconds into IR frequency.


Calibrating X arm mode scan:
  From the 8FSR mode-scan data (see elog #6859), positions of TEM00 and upper/lower 11 MHz sidebands in seconds are;

TEM00    242.00     214.76     187.22     159.27     131.33     102.96     74.61     46.00     17.51
upper    236.70     209.05     181.36     153.42     125.06      96.86     68.43     40.20
lower    220.35     192.96     165.03     136.98     108.92      80.65     52.25     23.90

  So, FSR and nu_f in seconds are;

FSR    27.24     27.54     27.95     27.94     28.37     28.35     28.61     28.49
nu_f   21.80     21.82     22.14     22.19     22.26     22.28     22.40     22.40

  By using formula above, modulation frequency in seconds are;

f_mod    76.28    76.90    78.04    78.07    79.00    78.98    79.62    79.38

  By taking average, FSR and f_mod in seconds are

FSR    28.1 +/- 0.2
f_mod    78.3 +/- 0.4

  We know that f_mod = 11065910 Hz, so conversion constant from seconds to frequency is

k1 = 0.1413 +/- 0.0007 MHz/sec

  We swept the phase by 3600 deg in 250 sec, so conversion constant from degree to frequency is

k2 = 9.81 +/- 0.05 kHz/deg

  Also, using k1, FSR for X arm is

FSR = 3.97 +/- 0.03 MHz

  This means, X arm length is

L = c/(2*FSR) = 37.6 +/- 0.3 m


Calibrating Y arm mode scan:
  From the 8FSR mode-scan data (see elog #6832), positions of TEM00 and upper/lower 11 MHz sidebands in seconds are;

TEM00    246.70     218.15     190.06     161.87     133.26     104.75     76.01     47.19     18.60
upper    240.86     212.78     184.32     155.73     127.23      98.48     69.78     41.26
lower    224.53     195.73     167.31     139.13     110.81      82.27     53.60     24.50

  So, FSR and nu_f in seconds are;

FSR    28.55     28.09     28.19     28.61     28.51     28.74     28.82     28.59
nu_f   22.44     22.57     22.60     22.61     22.47     22.48     22.50     22.68

  By using formula above, modulation frequency in seconds are;

f_mod    79.54    78.75    78.98    79.825    79.485    79.955    80.14    79.855

  By taking average, FSR and f_mod in seconds are

FSR    28.5 +/- 0.1
f_mod    79.6 +/- 0.2

  We know that f_mod = 11065910 Hz, so conversion constant from seconds to frequency is

k1 = 0.1390 +/- 0.0003 MHz/sec

  We swept the phase by 3600 deg in 250 sec, so conversion constant from degree to frequency is

k2 = 9.65 +/- 0.02 kHz/deg

  (k2 of X arm and Y arm is different because delay-line lengths are different)
  Using k1, FSR for X arm is

FSR = 3.96 +/- 0.02 MHz

  This means, X arm length is

L = c/(2*FSR) = 37.9 +/- 0.2 m


Summary of mode scan results:
X arm
  Mode matching    MMR = 91.2 +/- 0.3 % (elog #6859) Note that we had ~2% of 01/10 mode.
  FSR         FSR = 3.97 +/- 0.03 MHz (this elog)
  finesse    F = 416 +/- 6 (elog #6859)
  g-factor    g1*g2 = 0.3737 +/- 0.002 (elog #6922)

  length        L = 37.6 +/- 0.3 m (this elog)
  ETM RoC  R2 = 60.0 +/- 0.5 m (this elog and #6922; assuming ITM is flat)

Y arm
  Mode matching    MMR = 86.7 +/- 0.3 % (elog #6828) Note that we had ~5% of 01/10 mode.
  FSR         FSR = 3.96 +/- 0.02 MHz (this elog)
  finesse    F = 421 +/- 6 (elog #6832)
  g-factor    g1*g2 = 0.3765 +/- 0.003 (elog #6922)

  length       L = 37.9 +/- 0.2 m (this elog)
  ETM RoC R2 = 60.7 +/- 0.3 m (this elog and #6922; assuming ITM is flat)

  I think these are all the important arm parameters we can derive just from mode scan measurement.

  Every errors shown above are statistical error in 1 sigma. We need linearity check to put systematic error. Also, we need more precise calibration after that, too, if the sweep has considerably large non-linearity. To do the linearity check, I think the most straight forward way is to install frequency divider to monitor actual beat frequency during the sweep.

I'm not currently sure how to apply my template to seismic.strip shown on the wall (I saved it as seismic.strip on Pianossa and copied the old file to seismic.stripOld). I understand the job is being run on Megatron. I'll play around with this later tomorrow. (In other words, the display currently on the wall, while it does not have the Nan spikes like yesterday and this morning does not currently display the template I made).

Hi everybody,

Sorry for flooding the ELOG about the PEM channels. Today I

- Changed all of the GUR1 and GUR2 filters to elliptic, and lowered the orders of their low-pass filters.

- Lowered the order of the low-pass filters on the STS channels

- Changed the parameters in seismic.strip, which I saved as MashaTemplate2.

Attached is the most recent status of the channels as seen with StripTools:

 FIGURED IT OUT - THERE WAS A PROBLEM WITH THE LOW PASS FILTERS (TOO HIGH ORDER). FIXING IT NOW, SHOULD BE GOOD IN AN HOUR. 

UPDATE: I changed all of the GUR1Z channels to order-5 elliptic filters. I approximated the attenuation for each one by setting the integral from _CutoffFrequency to 10^3 Hz of 10^(-Percent(f)/20) df to 0.01, where Percent(f) is a linear approximation of the relationship between the log of the frequency and the dB level (with the attenuation defining one of the points). Right now the Nan problem continues to persist, even after I loaded the coefficients. In Dataviewer, the channels look relatively normal for the past 10 minutes, as does the data when viewed with tdsdata.

Hi everybody,

Last night I (with the help of Jenne and Jenne's advice - not to implicate her in this or anything) changed the filters for GUR1, GUR2, and STS in C1:PEM-RMS, adding a butterworth bandpass filter at each corresponding frequency band as well as a gain to convert from counts to micros/sec, and then adding a low pass filter in case of aliasing upon squaring.

Currently the seismic signals are going crazy, and producing "Nan" output on the strip graph (which leads to the instantaneously sharp spikes - which leads to the entire signal being filled on the visualizer on the wall). I checked the DataViewer output and the tdsdata output using both grep and wc, and it seems that both every single signal point is present and is a real number (also not a small real number, thereby debunking floating-point error). I'm currently not sure why seismic-strip reads out 'Nan' - perhaps because it's taking the log of 0, taking a negative log, taking the root of a negative number, or dividing by zero.

Does anyone know if the seismic-strip Nan issue is a program bug? If it's not (and therefore a filter bug), please let me know as well.

I'll be in lab for the rest of the night changing the butterworth filters to odd-order elliptic filters (at Rana's suggestion), as well as changing the cut-off frequency for the low-pass filters.

I'll E-log about it when I'm done.

Just to be sure that my numbers are correct - The STS, GUR1, and GUR2 channels all have gain 10, right? (I parsed through the e-log, and these seem to be the most recent numbers

Thanks for your help,

Masha

From calculation, phase fluctuation of reflected beam from length stabilized arm is not disturbing MI lock.

Easy calculation:
  The phase PD at AS port sense is

phi = phi_x - phi_y = 2*l_MICH*omega/c + (phi_X - phi_Y)

  where l_MICH is the Michelson differential length change, omega is laser frequency, phi_X and phi_Y are phase of arm reflected beam. From very complicated calculation,

phi_X ~ F/2 * Phi_X

  at near resonance. Where F is arm finesse, Phi_X is the round trip phase change in X arm. So,

phi = 2*l_MICH*omega/c + F/2 * 2*L_DARM*omega/c

  Our ALS stabilizes arm length in ~ 70 pm(see elogs #6835,  #6858). Finesse for IR is ~450. Considering l_MICH is ~ 1 um, MICH signal at AS port should be larger than stabilized DARM signal by an order of magnitude.

Length sensing matrix of FPMI:
  Calculated length sensing matrix of 40m FPMI is below. Here, I'm just considering 11 MHz modulation. I assumed input power to be 1 W, modulation index 0.1i, Schnupp asymmetry 26.6 mm. PRM/SRM transmissivity is not taken into account.

[W/m]     DARM      CARM      MICH
REFL_I    0         1.69e8    0
REFL_Q    7.09e1    0        -3.61e3
AS_I      0         0         0
AS_Q      1.04e6    0         3.61e3

  Maybe we should use REFL_Q as MICH signal, but since IQ separation is not perfect, we see too much CARM. I tried to lock MI with REFL11_Q yesterday, but failed.

 I can not understand what really happened here with CC1 gauge or there was really a pressure glitch.

attachment 1,  pump down day 3 with 4th of July fireworks in the lab

attachment 2,  before and after vent in 9 days

 I'm looking for some movement indicators of the vent-pump down events.

There is a package that provides the mex source, but it doesn't actually provide the mex binaries.  The problem is that the binary depends on the matlab version, so you can't possibly provide binaries for every version.

The solution is to just build the binaries from the source package.  We should put together a nice script that builds the binaries from the source, and installs them in the directory of your choosing.  If we get something nice working, we can probably get them to include it with the package, to make it easier in the future.

Here's what's included in the source package:

controls@pianosa:~ 0$ sudo apt-get install nds2-client-matlab
...
controls@pianosa:~ 0$ dpkg -L nds2-client-matlab | sort
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/nds2-client-matlab
/usr/share/doc/nds2-client-matlab/changelog.Debian.gz
/usr/share/doc/nds2-client-matlab/changelog.gz
/usr/share/doc/nds2-client-matlab/copyright
/usr/share/matlab
/usr/share/matlab/NDS2_GetChannels.m
/usr/share/matlab/NDS2_GetData.m
/usr/share/matlab/NDS_GetChannels.m
/usr/share/matlab/NDS_GetData.m
/usr/share/matlab/NDS_GetMinuteTrend.m
/usr/share/matlab/NDS_GetSecondTrend.m
/usr/share/matlab/src
/usr/share/matlab/src/NDS2_GetChannels.c
/usr/share/matlab/src/NDS2_GetData.c
/usr/share/matlab/src/NDS_GetChannels.c
/usr/share/matlab/src/NDS_GetData.c
/usr/share/matlab/src/nds_mex_utils.c
/usr/share/matlab/src/nds_mex_utils.h
controls@pianosa:~ 0$ 

Why do we have these timing blanks?

Handing off the servo from ALS to LSC for one arm is quite easy because servo filters are pretty much same for ALS and LSC. I demonstrated it Y arm during MI is locked.
We need DARM/CARM-kind of handing off in the near future.

What I did:
  1. Brought both arms to IR resonance.
  2. Brought X arm to off resonance.
  3. Locked MI in bright fringe(why can't I lock in dark fringe, when one arm is on resonance?) using AS55_Q and BS.
  4. Ran /opt/rtcds/caltech/c1/scripts/ALS/handofftoLSC.py Yarm to handoff. It decreases ALS gain and increases LSC gain in 30 sec ramp time. It also turns on some filters for LSC. Make sure you turn off filter triggers for LSC.

 Below is the plot of what I did. You can see LSC feedback signal gradually increasing and TRY getting more stable.
 I was dissapointed with ALS not having any DQ channels for feedback signal. I will make them DQ channels tomorrow.

MI with X arm length stabilized off resonance and Y arm length stabilized at resonance using ALS succeed, but I couldn't bring X arm to IR resonance. This maybe because of too much phase fluctuation. I will calculate it later.

What I did:
  1. Brought X arm to IR resonance.
  2. Brought Y arm to IR resonance.
  3. Brought X arm to off-resonance.
  4. Brought Y arm to off-resonance. (1-4 are to play with arms)
  5. Locked MI in dark fringe using AS55_Q as error signal and BS as actuator.
  6. Brought Y arm to IR resonance. This flips sign, so MI lock will be bright fringe.
  7. Brought X arm to IR resonance. This destroys MI lock.

  Below is the plot showing what I did


  I also tried to lock MI after both arms are stabilized at resonance, but it failed, too.
  MI + X arm ALS fails. I think this is from too much BS motion to compensate phase fluctuation of arm reflected beam.
  MI + Y arm ALS fails when I want to lock in dark fringe. Only bright fringe works.


New compact MEDM screen for ALS:
  It has (almost) everything you need for ALS. It lives in /opt/rtcds/caltech/c1/medm/c1gcv/master/C1ALS_COMPACT.adl.
  Features;

  - Button for turning on/off ALS. It even does "clear history"!
      (light brown button "ON plus", "ON minus", "OFF"; runs /opt/rtcds/caltech/c1/scripts/ALS/easyALS.py; Currently, you have to guess the sign of gain. Ctrl-C if the sign was wrong. It will be nice if script can handle this. Use lockin to detemrine the sign?)

  - Button for finding IR resonance.
      (pink button "IRres"; runs /opt/rtcds/caltech/c1/scripts/ALS/findIRresonance.py)

  - Button for bringing arm length to off-resonance.
      (pink button "-10", "+10"; steps +/- 10 deg offset)

  - Button for toggling green shutters.
      (green button "shutter"; runs /opt/rtcds/caltech/c1/medm/c1gcv/cmd/toggle(X|Y)Shutter.py)

  - Button for switching monitors.
      (grey button "Video (X|Y)arm"; runs /opt/rtcds/caltech/c1/scripts/general/Video_(X|Y)arm.csh)

  - Slider for changing temperature of end lasers. You can also open temperature servo screens from orange "(X|Y)SLOW" button.

 The reason I started looking at BLRMS and c1sus today was that the BLRMS striptool was totally wacky.  I finally figured out that the pemepics hadn't been burt restored, so none of the channels were being filtered.  It's all better now, and will be even better soon when Masha finishes updating the filters (she'll make her own elog later)

I was trying to use a new BLRMs c-code block that the seismic people developed, instead of Mirko's more clunky version, but putting this in crashed c1sus.

I reverted to a known good c1pem.mdl, and Jamie and I did a reboot, but c1sus is still funny - none of the models are actually running. 

rtcds restart all - all the models are happy again, c1sus is fine.

But, we still need to figure out what was wrong with the c-code block.

Also, the BLRMS channels are listed in a Daq Channels block inside of the (new) library part, so they're all saved with the new CDS system which became effective as of the upgrade.  (I made the Mirko copy-paste BLRMS into a library part, including a DAQ channels block before trying the c-code.  This is the known-working version to which I reverted, and we are currently running.)

Cavity g-factor for X arm is 0.3737 +/- 0.002, Y arm is 0.3765 +/- 0.003.
If ITMs are flat and arm length L = 39 +/- 1 m, this means RoC of ETMX and ETMY is 62 +/- 2 m and 63 +/- 2 m respectively.

Calculation:
  Transverse mode spacing is expressed by

nu_TMS / nu_FSR = arccos(sqrt(g1*g2)) / pi

  where g1 and g2 is g-factor

gi = 1 - L/Ri

 of ITM/ETM.

  For mode-scan, we swept laser frequency nu. Let's assume this sweep was linear and we can replace laser frequency with time. From the mode-scan result, TMS can be derived by

  t_TMS = sum((n_i-n)*(t_i-t)) / sum((n_i-n)^2)

  where n_i is the order of transverse mode, n is average of n_i's, t_i is the time i-th order mode appeared and t is average of t_i's.
  Since I could only recognize up to 3rd order mode, this can be rewritten as

  t_TMS = 1.5/5 * t_0 + 0.5/5 * t_1 - 0.5/5 * t_2 - 1.5/5 * t_3

  FSR is time between TEM00s. So, g1*g2 can be calculated by

g1*g2 = (cos(pi*t_TMS/t_FSR))^2


X arm result:
  From the 8FSR mode-scan data (see elog #6859), X arm HOM positions in sec are;

HOM 0    242.00     214.76     187.22     159.27     131.33    102.96     74.61     46.00     17.51
HOM 1    234.29     206.78     179.20     150.96     122.90     94.58     66.27     38.10
HOM 2    226.36     198.91     170.80     142.92     114.62     86.51     58.05     29.65
HOM 3    218.14     190.65     162.71     134.78     106.68     78.27     49.95     21.25

  Calculated FSR and TMS in sec are;

FSR    27.24     27.54     27.95     27.94     28.37     28.35     28.61     28.49
TMS     7.951     8.020     8.193     8.151     8.223     8.214     8.220     8.270

  Calculated cavity g-factor are;

g1*g2    0.3699     0.3720     0.3662     0.3704     0.3761     0.3765     0.3839     0.3748

  By taking average,

g1*g2 = 0.3737 +/- 0.002  (error in 1 sigma)


Y arm result:
  From 8FSR mode-scan data (see elog #6832), Y arm HOM positions in sec are;

HOM 0    246.70     218.15     190.06     161.87     133.26    104.75     76.01     47.19     18.60
HOM 1    238.83     210.55     181.88     153.47     124.93     96.08     67.51     39.01
HOM 2    230.48     202.21     173.64     144.80     116.43     86.17     59.84     31.43
HOM 3    222.15     193.47     165.33     137.13     108.60     80.04     51.17     22.25

  Calculated FSR and TMS in sec are;

FSR    28.55     28.09     28.19     28.61     28.51     28.74     28.82     28.59
TMS     8.200     8.238     8.243     8.289     8.248     8.404     8.219     8.240

  Calculated cavity g-factor are;

g1*g2    0.3841     0.3657     0.3683     0.3765     0.3778     0.3683     0.3904     0.3811

  By taking average,

g1*g2 = 0.3765 +/- 0.003  (error in 1 sigma)


Conclusion:
  If ITMs are flat and arm length L = 39 +/- 1 m, this means RoC of ETMX and ETMY is 62 +/- 2 m and 63 +/- 2 m respectively. Designed RoC is 57.35 m.
  Error of RoC is dominated by arm length error. So, we need more precise measurement of the length. This can be done when scan is calibrated and we can measure FSR in frequency.
  Also, we need evaluation of linearity of the sweep. This also can be done by calibration.

From my conversations with JZ and Leo, it seemed there was no package that generated the appropriate mex files. It was clear that the right ones weren't there from the absence of a /cvs/cds/caltech/apps/linux64/lib/matlab2010b directory. I'm sorry if I screwed anything up with pynds, but I have repeatedly asked for help with NDS2+matlab and no one has done anything.

It would be nice to do it via apt if there indeed is a versioned package that can make the mexs. Sorry again if I jumped the gun, but I didn't think anyone was going to do anything.

I guess the only 32-bit machine I can think of is mafalda.

About tconvert, I think the best solution is to make a new wrapper M-file. gps was just a convenient remnant of mDV, but all that we need is some matlab function that can output a GPS time given a date/time string. We can use whatever command-line utility you want.

This was indeed another leap second timing issue.  I'm guessing nodus resync'd from whatever server is posting the wrong time, and it brought everything out of sync again.  It really looks like the caltech server is off.  When I manually sync form there the time is off by a second, and then when I manually sync from the global pool it is correct.

I went ahead and updated nodus's config (/etc/inet/ntp.conf) to point to the global pool (pool.ntp.org).  I then restarted the ntp daemon:

  nodus$ sudo /etc/init.d/xntpd stop
  nodus$ sudo /etc/init.d/xntpd start

That brought nodus's time in sync.

At that point all I had to do was resync the time on fb:

  fb$ sudo /etc/init.d/ntp-client restart

When I did that daqd died, but it immediately restarted and everything was in sync.

No no, this is totally unnecessary.  NDS2 was already installed on every machine from the official packaged releases (apt-get install nds2-client), and it's known to work fine. We use it with pynds all the time. If the matlab component is not working we should figure out the right way to fix it with the existing packages.

In general, please only manually install software as a very last resort.  Manually installed software doesn't get maintained, where as the officially packaged stuff is being actively maintained by the collaboration. If there is a problem with the distributed packaging we should report it and get it fixed (and hint I was the one who built the original Debian packaging for nds2, so I know how to fix all the issues).  I'm trying to bring the 40m out of the dark days of complete chaos, where random software was installed in random locations.

That's because this wasn't the problem!

This sounds like it's more likely the issues. You did the right thing by going to apt to fix the authentication packages.  It's curious to me that you did that here, whereas you went totally out of band for the nds2 client stuff.  Why?

The matlab mex files are the other problem.  But there is also a nds2-client-matlab Debian/Ubuntu package for that as well.  The problem is that the package just distributes the source, and it needs to be compiled.  I'll help figure out a good way to do that.

Again, this is handled by the packaging!  Just use apt and the right architecture is installed automatically.

But what 32 bit machines are you referring to?  I think basically everything is 64 bit nowadays.

We are now using lalapps_tconvert for tconvert.  We're not using that ligotools crap anymore.  I've aliased that to tconvert on the command line, but maybe matlab isn't getting the message.  I'll try to think of a more robust solution (e.g. make a wrapper script).

 I was bad and didn't read the elog before touching things, so I did a daqd restart, and mxstream restart on all the front ends, but neither of those things helped.  Then I saw the elog that Jamie's working on figuring it out.

All the front-ends are showing 0x4000 status and have lost communication with the frame builder.  It looks like the timing skew is back again.  The fb is ahead of real time by one second, and strangely nodus is ahead of real time by something like 5 seconds!  I'm looking into it now.

I tried to lock FPMI using ALS, but I could not take care of ALS for both arms + MI. So, I decided to try one arm + MI.
I don't know why, but I couldn't make it. We need investigation.

Procedure I took:
  1. Align FPMI.

  2. Misalign ETMY.

  3. Press CLEAR HISTORY for C1:ALS-BEATY_FINE_PHASE filter module.
    Are there any command to do this?

  4. Stabilize X arm length.
    I made a script for turning on ALS servo nicely. It currently lives in /users/yuta/scripts/easyALS.py. You have to specify the arm(X or Y) and sign of the gain. It needs to be refined.

  5. Sweep the offset and stabilize X arm lenth to IR resonance.
   (Ran /opt/rtcds/caltech/c1/scripts/ALS/findIRresonance.py Xarm)

  6. Tried to lock MI. I tried to do this by feeding back the signal to BS or ITMs. Both worked fine when ALS holds X arm to IR off-resonance, but I couldn't lock MI when ALS holds X arm to IR resonance. This may come from too much phase fluctuation from X arm reflection. We should investigate this.

Handing off the servo from ALS to LSC:
  I made a script to do this. It just decreases ALS gain and increases LSC gain with 30 sec ramp time. It needs to be refined, so it currently lives in /users/yuta/scripts/handofftoLSC.py. It worked fine without loosing IR transmission.

ALS stability:
  Current stabiliy of the ALS servo is not enough. It doesn't stay for more than ~ 10min. I suspect this is from frequency servo of end lasers losing lock, or beat signals being too small for the beat box because of intensity fluctuation of green transmission. We definitely need to align end greens, but it is painful.

ALS looks OK. I tried to lock FPMI using ALS, but I feel like I need 6 hands to do it with current ALS stability. Now I have all computers being so slow.

It was fine for 7 hours after Jamie the Great fixed this, but fb went down couple times and DAQ status for all models now shows 0x4000. I tried restarting mx_stream and restarting fb, but they didn't help.

I aligned FPMI and greens. There's no recognizable difference between before and after the vent.

What I did:
  1. Aligned Y arm to maximize Y green transmission.
  2. Used PZT1/2 to maximize TRY. But since PZT1 doesn't work so much, I had to align Y arm, too (mostly ETMY). This decreases green transmission, but I will leave it.
  3. Aligned BS and X arm to maximize TRX
  4. Fine tune them to minimize ASDC during FPMI lock, without decreasing TRX
  5. Aligned X end green to get TEM00 transmission.

Now, TRY and TRX are both  ~0.89.
Green transmission from Y and X arm are ~123 uW and ~275 uW respectively. Their max we got so far was ~200 uW and ~255 uW.
I still see clipped beam at AS, which I think is from the Faraday edge, as we found in elog #6897.
Below is the Sensoray capture of some ports, and MEDM screen shots to compare with before vent(see #6893).
There are two AS captures, one is without MI lock and the other is with MI lock. Note that PRM/SRM is misalined.




Next:
 - I will check ALS
 - I keep Y end green optics untouched since elog #6776, to use it as a reference. We need to realign them if tip-tilts are installed in vacuum, or PZTs are installed in both ends.

Issues in PRC:
  1. Power recycling gain is too low (~ 15 instead of 40, according to Kiwamu).
  2. Mode matching to both arms are ~90%(see #6859), but PRC has terrible mode.
       Clipping/flipping in PRC?
  3. From cameras, beam spot moves so much when PRMI is locked.
       Alignment? Mirrors(especially PR2/3) moves too much?
  4. Error signals are glitchy when PRMI is locked.
       Servo design? Mirrors moves too much?

What we have learned from the vent:
  1. PRM, PR2, PR3 was not flipped.
  2. Their suspensions looked OK, too.
  3. We noticed clipping at BS and Faraday. They must be avoided when tip-tilts are installed on next vent.

  4. Took useful photos for next vent. Positions of green optics on optical layout CAD must be updated.
  5. It is not so difficult to recover the IFO state after cycling the vacuum if we use attenuator setup using PBS (see elog #6892).  But, of course, we need plans before cycling.

Commissioning Plan:
  - measure PRMI power recycling gain from POP
  - FPMI using ALS
  - measure PRFPMI power recycling gain from TRY/X
  - correlation between beam spot motion at POP camera and glitch
  - correlation between PR2/PR3 motion and glitch (how can we measure PR2/3 motion? set up oplevs?)
  - mode scan for PRC, using AS AUX laser
  - beam profile measurement at REFL,POP
  - refine servo design of MICH and PRCL

After plenty of work, NDS2 can now be used to get site data within MATLAB using the following machines:

• allegra
• megatron
• ottavia
• pianosa
• rosalba
• rossa

What I did

NDS2 was not working on any of the machines, so the first thing I did was simply to install the newest version. I downloaded the latest tarball (0.9.1) from the LDAS Wiki, unzipped and installed it

/users/zach $ tar -xvf nds2-client-0.9.1.tar

/users/zach $ cd nds2-client-0.9.1

/users/zach $ sudo ./configure --prefix=/cvs/cds/caltech/apps/linux64 --with-matlab=/cvs/cds/caltech/apps/linux64/matlab/bin/matlab

/users/zach $ sudo make

/users/zach $ sudo make install

Even with the new version, it still didn't work.

Solution: The main problem was that the cyrus-sasl-gssapi authentication protocol was not installed on these machines, so that even with a kerberos ticket the datalink could not be established. Using information from the LDAS Wiki, I used aptitude to install it as:

$ sudo aptitude install lscsoft-auth

This group installs both the SASL protocol and the package python-kerberos

I also needed to update the kerberos config file for each machine, which is located at /etc/krb5.conf. I found that ottavia had a nice one with many realms, so I copied that one over to the other machines. In any case where there was an old config file overwritten, it is now /etc/krb5.conf.old.

Finally, the matlab path for NDS2 was still set to the old 2010a directory (/cvs/cds/caltech/apps/linux64/lib/matlab2010a) that was created by the NDS2 install when Rana originally did it. The new install I made above created the appropriate 2010b mexa64 files, so I changed the matlab path within matlab to this one:

>> rmpath /cvs/cds/caltech/apps/linux64/lib/matlab2010a

>> addpath /cvs/cds/caltech/apps/linux64/lib/matlab2010b

>> savepath

Now everything works fine on all these machines. As in Rana's original post, you get data in the following way:

$ kinit albert.einstein %then enter password

$ matlab -nosplash -nodesktop

>> d = NDS2_GetData({'H1:LSC-NPTRX_OUT16.mean'},963968415,6000,'nds.ligo.caltech.edu:31200')

d = 

            name: 'H1:LSC-NPTRX_OUT16.mean' 

            chan_type: 'm-trend'             

            rate: 0.0167       

            data_type: 'real_8'     

            signal_gain: 1   

            signal_offset: 0     

            signal_slope: 1     

            signal_units: ''   

            start_gps_sec: 963968415     

            duration_sec: 6000             

            data: [100x1 double]           

            exists: 1

>> quit % since you've seen that the data is really here

$ kdestroy % so that no one uses your credentials

Some thoughts

• I would like to extend this to the 32-bit machines, but I have to figure out the best way to install the proper NDS2 client without interfering with the 64-bit version. I think it is just a matter of specifying the matlabroot in the .../linux/ instead of .../linux64/
• It would be nice to find a way that the nice tool gps('MM/DD/YYYY XX:XX:XX UTC'), which calls the ligotool executable tconvert, can be automatically usable when calling NDS2 functions. Right now, there seems to be an issue preventing that: even though tconvert can be run in the terminal, gps() returns an error and even directly running unix('tconvert now') or !tconvert returns the same error. I have emailed Peter Shawhan to see if he has any advice.

I got a call from Koji and Yuta that something was wrong with the CDS system.  I somehow had an immediate suspicion that it had something to do with the recent leap second.

It took a while for nodus to respond, and once he finally let me in I found a bunch of the following in his dmesg, repeated and filling the buffer:

Jul  3 22:41:34 nodus xntpd[306]: [ID 774427 daemon.notice] time reset (step) 0.998366 s
Jul  3 22:46:20 nodus xntpd[306]: [ID 774427 daemon.notice] time reset (step) -1.000847 s

Looking at date on all the front end systems, including fb, I could tell that they all looked a second fast, which is what you would expect if they had missed the leap second.  Everything syncs against nodus, so given nodus's problems above, that might explain everything.

I stopped daqd and nds on fb, and unloaded the mx drivers, which seemed to be showing problems.  I also stopped nodus's xntp:

  sudo /etc/init.d/xntpd stop

His ntp config file is in /etc/inet/ntp.conf, which is definitely the WRONG PLACE, given that the ntp server is not, as far as I can tell, being controlled by inetd.  (nodus is WAY out of date and desperately needs an overhaul.  it's nearly impossible to figure out what the hell is going on in there).  I found an old elog of Rana's that mentioned updating his config to point him to the caltech NTP server, which is now listed in the config, so I tried manually resyncing against that:

  sudo ntpdate -s -b -u 131.215.239.14

Unfortunately that didn't seem to have any effect.  This was making me wonder if the caltech server is off?  Anyway, I tried resyncing against the global NTP pool:

  sudo ntpdate -s -b -u pool.ntp.org

This seemed to work: the clock came back in sync with others that are known good.  Once nodus time was good I reloaded the mx drivers on fb and restarted daqd and nds.  They seemed come up fine.  At this point front ends started coming back on their own.  I went and restarted all the models on the machines that didn't (c1iscey and c1ioo).  Currently everything is looking ok.

I'm worried that there is still a problem with one of the NTP servers that nodus is sync'ing against, and that the problem might come back.  I'll check in again later tonight.

MC came back to the state as it was before the vent.

What I did:
  1. Removed beam attenuating setup on PSL table(see elog #6892).

  2. Removed 100% reflection mirror before the MC reflection PD and put 10% BS back, so that we can have MC WFS. Also, I changed C1:IOO-MC_RFPD_DCMON.HOPR to 5.

  3. Removed autolockMCmain40m_low_power from crontab on op340m, and put autolockMCmain40m again.

  4. Aligned MC and ran /opt/rtcds/caltech/c1/scripts/MC/WFS/WFS_FilterBank_offsets to adjust WFS offsets.

  5. Measured beam spot positions. They looked same as before the vent.

# filename    MC1pit    MC2pit    MC3pit    MC1yaw    MC2yaw    MC3yaw    (spot positions in mm)
./dataMCdecenter/MCdecenter201206290135.dat    2.914584    4.240889    2.149244    -7.117336    -1.494540    4.955329    before vent
./dataMCdecenter/MCdecenter201207011253.dat    3.294659    3.416584    2.620511    -6.691800    -3.164084    4.806517    after vent
./dataMCdecenter/MCdecenter201207032009.dat    3.737099    3.994597    3.087857    -6.442053    -0.992543    4.714607    after pumping (now)

  6. I also turned on high voltage power supplies for input and output PZTs

  7. Below is captured Sensoray images of the current state.



Next:
  I will go on to check if IFO works as it was before or not, but I think we should center MC beam spot positions and see if we can avoid clipping in the near future.