40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 82 of 335  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  1714   Thu Jul 2 06:31:35 2009 ClaraUpdatePEMFirst mic in place and connected

I clamped Bonnie (microphone) to the top of a chamber near the vertex of the arms and placed Clyde (pre-amp) on the table right below (see picture). The cable was laid and Bonnie and Clyde are plugged into port #13 on the ADC. The second cable was plugged into port #14, but it is not connected to anything. I placed the looped up cable on top of the cabinet holding the ADC.

Note: the angle in the photograph is such that we are looking along the y-arm.


Attachment 1: bonnieandclyde.JPG
bonnieandclyde.JPG
  8874   Thu Jul 18 20:20:52 2013 gautamConfigurationendtable upgradeFirst mirror glued to PZT and mounted in modified mounts

 

 Yesterday, I mounted the first PZT in one of the modified mounts, and then glued a 2-inch Y2 mirror on it using superglue.

Details:

-The mirror is a 2-inch, Y2 mirror with HR and AR coatings for 532 nm light.

-The AR side of the mirror had someone's fingerprint on it, which I removed (under Manasa's guidance) using tweezers wrapped in lens cleaning paper, and methanol.

-Before gluing the mirror, I had to assemble the modified mount. Manasa handed over the remaining parts of the mounts (which are now in my newly acquired tupperware box along with all the other Piezo-related hardware). I took the one labelled A, and assembled the holder part. I then used one of the new mounts (2.5 inches, these are with the clean mounts in a cardboard box in the cupboard holding the green optics along the Y-arm) and mounted the holder on it. 

-Having assembled the mount, I inserted the piezo tip-tilt into the holder. The wedge that the machine shop supplied is useful (indeed required) for this. 

-I then cleaned the AR surface of the mirror and the top-surface of the tip-tilt. 

-The gluing was done using superglue which Steve got from the bookstore (the remaining tube is in the small fridge). We may glue the other mirror using epoxy. I placed 4 small drops of superglue on the tip-tilt's top surface, placed the mirror with its AR face in contact with the piezo, and applied some pressure for a short while until the glue spread out fairly evenly. I then left the whole setup to dry for about half an hour.

-Steve suggested using a reference piece (I used two small bolts) to verify when the glue had dried.

-Finally, I attached the whole assembly to a base.

Here it is in action in my calibration setup (note that it has not been oriented yet. i.e. the two perpendicular axes of the piezo are for the time being arbitrarily oriented. And maybe the spreading of the glue wasn't that even after all...):

Piezo-mirror.jpg

 

Sidenote:

Yesterday, while setting stuff up, I tested the piezo with a 0.05 Hz, 10Vpp input from the SR function generator just to see if it works, and also to verify that I had set up all my electronics correctly. Though the QPD was at this point calibrated, I did observe periodic motion of both the X and Y outputs of my QPD amp! Next step- calibration... 

  11979   Fri Feb 5 16:50:24 2016 gautamUpdateGreen LockingFirst pass at mode-matching

I've done a first pass at trying to arrive at a mode-matching solution for the X-end table once we swtich the lasers out. For this rough calculation, I used a la mode to match my seed beam (with z = 0 being defined as the shutter housing on the current position of the Innolight laser head, and the waist of the beam from the NPRO being taken as the square-root of the X and Y waists as calculated here), to a target beam which has a waist of 35um at the center of the doubling oven (a number I got from this elog). I also ignored the optical path length changes introduced by the 3 half-wave plates between the NPRO and the doubling oven, and also the Faraday isolator. The best a la mode was able to give me, with the only degrees of freedom being the position of the two lenses, was a waist of 41um at the doubling oven. I suppose this number will change once we take into account the effects of the HWPs and the Faraday. Moreover, the optimized solution involves the first lens after the NPRO, L1, being rather close to the second steering mirror, SM2 (see labels in Attachment #2, in cyan), but I believe this arrangement is possible without clipping the beam. Moreover, we have a little room to play with as far as the absolute physical position of the z=0 coordinate is - i.e. the Lightwave NPRO head can be moved ~2cm forward relative to where the Innolight laser head is presently, giving a slightly better match to the target waist (see attachment #3). I will check the lenses we have available at the 40m to see if a more optimal solution can be found, but I'm not sure how much we want to be changing optics considering all this is going to have to be re-done for the new end table... Mode-matching code in Attachment #4...

Attachment 1: Modematch_AUXx.pdf
Modematch_AUXx.pdf
Attachment 2: NewSetUp.png
NewSetUp.png
Attachment 3: Modematch_AUXx_2.pdf
Modematch_AUXx_2.pdf
Attachment 4: XendModeMatch.m.zip
  3593   Tue Sep 21 16:05:21 2010 josephbUpdateCDSFirst pass at rack diagram

I've made a first pass at a rack diagram for the 1X1 and 1X2 racks, attached as png.

Gray is old existing boards, power supplies etc.  Blue is new CDS computers and IO chassis, and gold is for the Alberto's new RF electronics.  I still need to double check on whether some of these boards will be coming out (perhaps the 2U FSS ref board?).

Attachment 1: 1X1_1X2_racks.png
1X1_1X2_racks.png
  5157   Tue Aug 9 16:21:59 2011 Manuel, IshwitaUpdateWienerFilteringFirst results of our simulations

We did the simulation of the stacks by defining a transfer function for one stack (green plot) and another similar transfer function for the other stack.

We simulated the ground motion by filtering a white noise with a low pass filter with a cutoff frequency at 10Hz. (blue plot) (the ground motion for the 2 stacks are completely uncorrelated)

We simulated the electronic white noise for the seismic measurements. (black plot)

We filtered the ground motion (without the measurements electronic noise) with the stack's transfer function and subtracted them to find the mirror response (red plot), which is the target signal for the wiener filter.

We computed the static wiener filter with the target signal (distance between the mirrors) and the input data (seismic measurements = ground motion + electronic noise).

We filtered the input and plotted the output (light blue plot).

We subtracted the target and the output to find the residual (magenta plot).

We didn't figure out why the residual is above the electronic noise only under ~6hz. We tried to increase and decrease the electronic noise and the residual follows the noise still only under ~6Hz.

It also shows that the residues are above the target at frequencies over 20Hz. This means that we are injecting noise here.

simu1.png

We tried to whiten the target and the input (using an high pass filter) to make the wiener filter to care even of higher frequencies.

The residues are more omogeneously following the target.

We also plotted the Wiener filter transfer function without making whitening and with making whitening. It shows that if we do whitening we inject no noise at high frequency. But we loose efficency at low frequencies.

simu2w.png

TFwhitened2.png

We shouldn't care about high frequency, because the seismometers response is not good over 50Hz. So, instead of whitening, we should simply apply a low pass filter to the filter output to do not inject noise and keep a good reduction at low frequencies.

 

  2941   Mon May 17 19:42:11 2010 JenneUpdateIOOFirst steps toward MC mode measuring

[Jenne, Kevin, Steve]

We made some progress toward getting the MC's beam profile measured.  In the end, no changes were made to anything today, but we're more prepared to go for tomorrow.

What we did:

* Grabbed the scanning slit beam scan from the PSL lab.  It's the same kind as we had here at the 40m, so Kevin was able to hook it up to the computer, and confirmed that it works.

* Opened the IOO and OMC chamber doors, and locked the MC.  Unfortunately the MC mode was awful in Yaw.  Awful like TEM(0,10+). But it still locked.  

* Confirmed that the beam went through the Faraday.  I looked at the beam before and after the Faraday on a card, and it was the same nasty beam both before and after.  So it looks like Zach did a good job aligning the Faraday and everything else.  I was going to clamp the Faraday, but I didn't yet, since I wanted to see the nice happy TEM00 mode go through without clipping before risking moving the Faraday during clamping (I don't know how heavy it is, so I'm not sure how much it might potentially move during clamping.)

* Noticed that there is a whole lot of crap on both the OMC and BS tables that's going to have to move.  In particular, one of the weights leveling the OMC table is right where I need to put MMT2.  Steve suggested putting the optic there, in its approximate place, before doing too much other stuff, since it could potentially affect the leveling of the table, and thus the input pointing to the MC.  Unfortunately, to do that I'll need to move the weight, which is definitely going to change things.  Sad face.  Moving the weight will likely be one of the first things I do tomorrow, so that all 3 profile measurements have the same configuration. 

* Before closing up, I tried to align the MC, to get back to TEM00, to no avail.  I got as far as achieving TEM11 flashing, along with a bunch of other crappy modes, but didn't get 00.  That's also on the to-do list.

What we're going to do:

* Open the chambers, and align the MC to TEM00 (using the sliders on the MC align screen).

* Check with an IR card that the beam goes through the Faraday.

* Clamp the Faraday, reconfirm.

* Remove the weight on the OMC table.

* Place MMT2 on the OMC table in it's approximate final location.

* Realign the MC, and make sure the beam goes through the Faraday.  If this doesn't happen smoothly, I may need more instruction since I've never dealt with aligning the Faraday before.  What are the appropriate mirrors to adjust? 

* Move the PZT flat steering mirror from the BS table to the IOO table.  (Thoughts on this?  This will change the table leveling, and also includes the trickiness of needing to move the connectors for the PZT.)

* Place a flat mirror on the BS table to route the MC beam out to the BS/PRM/SRM oplev table. 

* Measure the mode using the beam scan: on the BS oplev table, on the POX table, and then perhaps by shooting the beam through the beamtube on the ETMY (new convention) table.

* Place MMT1 on the BS table, use flat mirrors to get it out of the chambers, repeat measurements.

* Place MMT2 in the correct position, use flat mirrors to get it out of the chambers, repeat measurements.

All of this may require some serious cleaning-up of the BS table, which is going to be ugly, but it has to happen sometime. Hopefully I can get away with only moving a minimal number of things, in order to get these measurements done.

 

Another note: Don't trust the PSL shutter and the switch on the MEDM screens! Always use a manual block in addition!!! We discovered upon closeup that hitting the "Closed" button, while it reads back as if the shutter is closed (with the red box around the buttons), does not in fact close the shutter.  The shutter is still wide open.  This must be fixed.

  2942   Tue May 18 01:40:56 2010 KojiUpdateIOOFirst steps toward MC mode measuring

OK. Don't worry. This is just an initial confusion which we also had for the suspensions a while ago.

The faraday must be clamped. It shakes the table terribly but it is fine. The leveling may change a bit but should be small enough. Otherwise, just tweak the weights. In fact, the faraday has enough large apertures and we hope we don't need to move it again, as far as the MC incident beam is not moved. But if necessary, we don't move the mirrors but move the faraday itself.

Usually the alignment of the MC is taken by MC2/MC3 such that we don't  move the refl. But if you think what have moved is the MC1/MC3 (i.e. activity in the IMC chamber), take the alignment of the MC1/MC3.

It is just a matter of time to get TEM00. If you get TEM11, it is already close. If you align for TEM11, it is enough aligned to lock TEM10 or TEM01. Once you got better mode, align for it again. Eventually you will get TEM00.

The leveling may change by moving the optics and the weight again. But once the leveling is recovered by arranging the weights somewhere else,
the pointing must be fine again. If necessary, You can remove two optics for squeezing injection (strange motorized rotating mirror and a mount sticking out from the table to south.)

Yes, we need to move the PZT mirror. For the connection, only Steve can give us the right way to do it. If it is too much hussle, just move only the mirror and ignore the wiring for now.

I will update how the mirrors should be migrated from the table to the table.

 

  2945   Tue May 18 12:04:13 2010 robUpdateIOOFirst steps toward MC mode measuring

Quote:

Another note: Don't trust the PSL shutter and the switch on the MEDM screens! Always use a manual block in addition!!! We discovered upon closeup that hitting the "Closed" button, while it reads back as if the shutter is closed (with the red box around the buttons), does not in fact close the shutter.  The shutter is still wide open.  This must be fixed.

 Has anyone tried pushing the "reset" button on the Uniblitz driver?

  2949   Tue May 18 16:44:35 2010 KojiUpdateIOOFirst steps toward MC mode measuring

Here is the upadted list http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_09/Optics

Quote:

I will update how the mirrors should be migrated from the table to the table. 

 

  15926   Tue Mar 16 19:13:09 2021 Paco, AnchalUpdateSUSFirst success in Input Matric Diagonalization

After jumping through few hoops, we have one successful result in diagonalizing the input matrix for MC1, MC2 and MC3.


Code:

  • Attachment 2 has the code file contained. For now, we can only guarantee it to work on Donatella in conda base environment. Our code is present in scripts/SUS/InMatCalc
  • We mostly follow the steps mentioned in 4886 and the matlab codes in scripts/SUS/peakFit.
  • Data is first multiplied with currently used inpur matrix to get time series data in DOF (POS, PIT, YAW, SIDE) basis.
  • Then, the peak frequencies of each resonance are identified.
  • For getting these results, we did not attempt to fit the peaks with lorentzians and took the maxima point of the PSD to get the peak positions. This is only possible if the current input matrix is good enough. We have to adjust some parameters so that our fitting code works always.
  • TF estimate between the sensor data w.r.t UL sensor is taken and the values around the peak frequencies of oscillations are averaged to get the sensing matrix.
  • This matrix is normalized along DOF axis (columns in our case) and then inverted.
  • After inversion, another normaliation is done along DOF axis (now rows).
  • Finally we plot the comparison of ASD in DOF basis when using current input matrix and when using our calculated inpur matrix (diagonalizing).
  • You can notice in Attachment 1 that after the diagonalization, each DOF shows resonance at only one and its own resonance frequency while earlier there was some mixing shown.
  • Absolute value of the calculated DOF might have changed and we need to calibrate them or apply appropriate gain factors in the DOF basis filter chains.

Next steps:

  • We'll complete our scripts and make them more general to be used for any optic.
  • We'll combine all of them into one single script which can be called by medm.
  • In parallel, we'll start onwards from step 2 in 15881.
  • Anything else that folks can suggest on our first result. Did we actually do it or are we fooling ourselves?
Attachment 1: IMC_InputMatrixDiagonalization.pdf
IMC_InputMatrixDiagonalization.pdf IMC_InputMatrixDiagonalization.pdf IMC_InputMatrixDiagonalization.pdf
Attachment 2: InMatCalcScripts.zip
  10959   Fri Jan 30 02:57:03 2015 JenneUpdateModern ControlFirst try with PRCL ASC Wiener filtering

[Aside - How do you rotate plots in the new elog?  It's showing them correctly in the attachments list below the entry, but not in the body of the log :( ]

I tried a round of PRCL ASC Wiener filtering today, but something wasn't right.  I was able to either make the cavity motion worse, or completely throw the cavity out of lock.  Making it less noisy didn't happen.

I took only 9 minutes of data the other day, since the PRMI didn't want to stay locked while it was daytime.  So, this wasn't a whole lot to train on.  But, even so, I designed some Wiener filters.  The plots with the designs show the calculated Wiener filter ("Wiener") and the result from vectfit ("Fit"). Below the bode plot is the coherence between that witness (seismometer direction) and the degree of freedom (QPD channel).  The fits were weighted by the choherence, so you can see that in the areas where the coherence was good, the fit was good.  Elsewhere, it's not so great.

 

Using these filters, and assuming a Cheby1 2nd order lowpass filter at 30Hz, I predicted the following residuals:

After discovering that these filters didn't work, I went rogue and also put in a high pass filter at 0.1 Hz, but that didn't really change anything.

Here is a plot of what happened in Yaw.  The Wiener filters' gains were all 0.3 here, which made the cavity motion larger, but not so large that it lost lock.  The filters ought to have gains of 1 - the Wiener calculation should figure out the gains appropriately, if I've given it enough information.  Here, as in the prediction plots above, red is the reference with the Wiener off, and black is with the Wiener filters on.  Black is supposed to be below red, if the filters are working.  Blue is the estimate of the angular motion that is being fed forward to the PRM, and you can see that at least the general shape is correct.  I do need to figure out what the resonance in the blue trace is from - it's at the same frequency as a peak in the T-240's spectrum (that I didn't save).  I suspect the cable might be touching the spaghetti pot on the inside, and making a mechanical short to pot vibrations.

Anyhow, more work to be done.  I left the PRMI locked for a while this afternoon, starting at 5:15ish, so I'll see tomorrow how long of a lock stretch I was able to capture for training. 

 

Attachment 1: WienerFilter_Witness1.png
WienerFilter_Witness1.png
Attachment 3: WienerFilter_Witness3.png
WienerFilter_Witness3.png
Attachment 9: 29Jan2015_Yaw_didnotwork.pdf
29Jan2015_Yaw_didnotwork.pdf
  6882   Wed Jun 27 14:18:30 2012 Yaakov SummarySTACISFirst week summary

The beginning of my first week was spent at various orientations and safety meetings, some for general SURF and some more specific to LIGO and the lab. In between these I started  work.

Jenne and I took out the spare STACIS and took it apart, taking out the circuit boards. I've spent some time looking through the boards and sketching various parts of the board in trying to understand the exact function without any useful technical diagrams (STACIS supplied us only with a picture of the board without components, not all that helpful). I think I now at least understand the basic block diagram of the circuitry: the STACIS geophone signal goes through a preamplifier and filters (the semi-circular board), and converts it into a signal for the PZT stacks. This signal then goes through a high voltage amplifer, and then goes to the five PZTs (3 in the z, one each in the x and y direction). The unit I am looking at has an extension board, which allows us to tap into the signal going into the preamp and the one leaving it. This should allow us to input our own signal instead of the geophone signal, and thereby drive the PZTs ourselves.

My next step, once I get a resistor to replace a burnt one on the high voltage amplifier, is to take a transfer function of the STACIS and see if it is possible to drive the PZT stacks with the cables from the extension board. If that does not work, I'll have to keep tracing the circuit to determine where to input our own signal.

  16373   Mon Oct 4 15:50:31 2021 HangUpdateCalibrationFisher matrix estimation on XARM parameters

[Anchal, Hang]

What: Anchal and I measured the XARM OLTF last Thursday.

Goal: 1. measure the 2 zeros and 2 poles in the analog whitening filter, and potentially constrain the cavity pole and an overall gain. 

          2. Compare the parameter distribution obtained from measurements and that estimated analytically from the Fisher matrix calculation.

          3. Obtain the optimized excitation spectrum for future measurements.   

How: we inject at C1:SUS-ETMX_LSC_EXC so that each digital count should be directly proportional to the force applied to the suspension. We read out the signal at C1:SUS-ETMX_LSC_OUT_DQ. We use an approximately white excitation in the 50-300 Hz band, and intentionally choose the coherence to be only slightly above 0.9 so that we can get some statistical error to be compared with the Fisher matrix's prediction. For each measurement, we use a bandwidth of 0.25 Hz and 10 averages (no overlapping between adjacent segments). 

The 2 zeros and 2 poles in the analog whitening filter and an overall gain are treated as free parameters to be fitted, while the rest are taken from the model by Anchal and Paco (elog:16363). The optical response of the arm cavity seems missing in that model, and thus we additionally include a real pole (for the cavity pole) in the model we fit. Thus in total, our model has 6 free parameters, 2 zeros, 3 poles, and 1 overall gain. 

The analysis codes are pushed to the 40m/sysID repo. 

===========================================================

Results:

Fig. 1 shows one measurement. The gray trace is the data and the olive one is the maximum likelihood estimation. The uncertainty for each frequency bin is shown in the shaded region. Note that the SNR is related to the coherence as 

        SNR^2 = [coherence / (1-coherence)] * (# of average), 

and for a complex TF written as G = A * exp[1j*Phi], one can show the uncertainty is given by 

        \Delta A / A = 1/SNR,  \Delta \Phi = 1/SNR [rad]. 

Fig. 2. The gray contours show the 1- and 2-sigma levels of the model parameters using the Fisher matrix calculation. We repeated the measurement shown in Fig. 1 three times, and the best-fit parameters for each measurement are indicated in the red-crosses. Although we only did a small number of experiments, the amount of scattering is consistent with the Fisher matrix's prediction, giving us some confidence in our analytical calculation. 

One thing to note though is that in order to fit the measured data, we would need an additional pole at around 1,500 Hz. This seems a bit low for the cavity pole frequency. For aLIGO w/ 4km arms, the single-arm pole is about 40-50 Hz. The arm is 100 times shorter here and I would naively expect the cavity pole to be at 3k-4k Hz if the test masses are similar. 

Fig. 3. We then follow the algorithm outlined in Pintelon & Schoukens, sec. 5.4.2.2, to calculate how we should change the excitation spectrum. Note that here we are fixing the rms of the force applied to the suspension constant. 

Fig. 4 then shows how the expected error changes as we optimize the excitation. It seems in this case a white-ish excitation is already decent (as the TF itself is quite flat in the range of interest), and we only get some mild improvement as we iterate the excitation spectra (note we use the color gray, olive, and purple for the results after the 0th, 1st, and 2nd iteration; same color-coding as in Fig. 3).   

 

 

 

Attachment 1: tf_meas.pdf
tf_meas.pdf
Attachment 2: fisher_est_vs_data.pdf
fisher_est_vs_data.pdf
Attachment 3: Pxx_evol.pdf
Pxx_evol.pdf
Attachment 4: fisher_evol.pdf
fisher_evol.pdf
  16486   Mon Nov 29 15:24:53 2021 HangHowToGeneralFisher matrix vs length of each FFT segment

We have been discussing how does the parameter estimation depends on the length per FFT segment. In other words, after we collected a series of data, would it be better for us to divide it into many segments so that we have many averages, or should we use long FFT segments so that we have more frequency bins?

My conclusions are that:

1). We need to make sure that the segment length is long enough with T_seg > min[ Q_i / f_i ], where f_i is the resonant frequency of the i'th resonant peak and the Q_i its quality factor. 

2). Once 1) is satisfied, the result depends weakly on the FFT length. There might be a weak hint preferring a longer segment length (i.e., want more freq bins than more averages) though. 

=================================================================

To reach the conclusion, I performed the following numerical experiment.

I considered a simple pendulum with resonant frequency f_1 = 0.993 Hz and Q_1 = 6.23. The value of f_1 is chosen such that it is not too special to fall into a single freq bin. Additionally, I set an overall gain of k=20. I generated T_tot = 512 s of data in the time domain and then did the standard frequency domain TF estimation. I.e., I computed the CSD between excitation and response (with noise) over the PSD of the excitation. The spectra of excitation and noise in the readout channel are shown in the first plot. 

In the second plot, I showed the 1-sigma errors from the Fisher matrix calculation of the three parameters in this problem, as well as the determinant of the error matrix \Sigma = inv(Fisher matrix). All quantities are plotted as functions of the duration per FFT segment T_seg. The red dotted line is [Q_1/f_1], i.e., the time required to resolve the resonant peak. As one would expect, if T_seg <~ (Q_1/f_1), we cannot resolve the dynamics of the system and therefore we get nonsense PE results. However, once T_seg > (Q_1/f_1), the PE results seem to be just fluctuating (as f_1 does not fall exactly into a single bin). Maybe there is a small hint that longer T_seg is better. Potentially, this might be due to that we lose less information due to windowing? To be investigated further... 

I also showed the Fisher estimation vs. MCMC results in the last two plots. Here each dot is an MCMC posterior. The red crosses are the true values, and the purple contours are the results of the Fisher calculations (3-sigma contours). The MCMC results showed similar trends as the Fisher predictions and the results for T_seg = (32, 64, 128) s all have similar amounts of scattering << the scattering of the T_seg=8 s results. Though somehow it showed a biased result. In the third plot, I manually corrected the mean so that we could just compare the scattering. The fourth plot showed the original posterior distribution. 

 

Attachment 1: setup.pdf
setup.pdf
Attachment 2: Fisher_vs_Tperseg.pdf
Fisher_vs_Tperseg.pdf
Attachment 3: fisher_vs_mcmc_offset_removed.png
fisher_vs_mcmc_offset_removed.png
Attachment 4: fisher_vs_mcmc.png
fisher_vs_mcmc.png
  5015   Thu Jul 21 23:36:51 2011 JennyUpdate Fitting beam waist with MATLAB

I am starting work on the PSL table at the 40m. My goal is to lock the laser coming from the nearby table to the FP cavity and get a measurement of the response to a temperature step on the surrounding can.

I have to mode match the beam to the cavity. Specifically, I have to mode match to the beam coming from the PMC through the EOM to the polarizing beam splitter. Yesterday David and I measured the beam width at various distances (from a particular lens through which the beam traveled), and I fit that data using MATLAB to find the beam's waist size and location. However, I'm not convinced that the fit is any good, since we only took measurements at five spots and they had large error bars.

 

z (mm) 2w_vert (mm) 2w_horiz (mm)
180 4.68 3.38
230 4.64 3.49
305 4.68 3.47
370 5.1 3.81
510 5.5 4.17

Here is the fit I obtained using fminsearch. The horizontal beam width measurements were smaller than the vertical width measurements, suggesting that the incoming beam was elliptical. I fit the data for each set of measurements separately and got two waist locations. The red trace is the fit for the horizontal width and the blue represents the vertical width of the beam. Averaging the two fitted waist locations and sizes gives

vert z_0= -1760 mm (waist location)

horiz z_0= -1540 mm (waist location)

vert w_0 = 0.286 mm (waist size)

horiz  w_0 = 0.275 mm (waist size)

avg z_0= -1650 mm

avg w_0 = 0.281 mm

 

twobeamfit2.jpg

Here is the code I used:

I defined the function spotsize.m and then made a function gaussbeam.m that called it with input parameters and returned the least squares error. I then wrote another function twobeamfits.m that ran fminsearch to minimize the least squares error and made the above plot. I've pasted the code below.

spotsize

function omega = spotsize(z_0, w_0, z)
lambda=0.001064;
omega=w_0*(1+(lambda*(z-z_0)/(pi*w_0^2)).^2).^(1/2);

 

gaussbeam

function sse = gaussbeam(params,xvals,yvals)

%This f'n takes as its inputs
%three parameters (w_0, z_0, and lambda),
%a vector of x-values (distances),
%and an associated vector of y-values (spotsizes),


%It then generates a vector of fitted y-values by applying
%an exponential approach function (single pole), with the given parameters,
%to the x-values.

%It then returns the sum of the squares of the entries of the difference
%between the fitted y-vector and the actual y-vector

z_0=params(1);
w_0=params(2);
fityvals=spotsize(z_0, w_0, xvals);

error=(fityvals - yvals);% .*xvals;
% sse stands for sum of squares error
sse=sum(error.^2);

 

twobeamfits

function [outputs] = twobeamfits(guesses, dists, vert, horiz)


%This f'n takes as its inputs
%two starting guess parameters (w_0 and z_0),
%a vector of distances (x-values),
%and two associated vectors of measured beam radii,

%the radius measured along the vertical axis

%and the radius measured along a horizontal axis (y-values).

%It then calls the gaussbeam f'n for each set of y-values and minimizes its output (sum of squares error)
%using the fminsearch f'n. It outputs the fit parameters it settles on.

%It then plots the input data, the fitted curves, and the residuals


fminopts=optimset('TolFun',1e-6,'MaxIter', 100000);
vertparams=fminsearch(@gaussbeam,guesses,fminopts,dists,vert);
fitvert=spotsize(vertparams(1), vertparams(2), dists);
resid1=(vert-fitvert)./vert;
spoterror=[.1, .1, .1, .1, .1]; %uncertainties, all in mm

fminopts=optimset('TolFun',1e-6,'MaxIter', 100000);
horizparams=fminsearch(@gaussbeam,guesses,fminopts,dists,horiz);
fithoriz=spotsize(horizparams(1), horizparams(2), dists);
resid2=(horiz-fithoriz)./horiz;


points=linspace(-2000,1000,1000);
figure(1)
hold off
clf
subplot(2,1,1)
hold on
errorbar(dists, vert, spoterror, 'x')
grid
errorbar(dists, horiz, spoterror, 'r*');
plot(points,spotsize(vertparams(1), vertparams(2), points));
plot(points,spotsize(horizparams(1), horizparams(2), points),'r');
xlabel('Distance z (mm)')
title('Gaussian Beam Fits')
ylabel('Spotsize w (mm)')
legend('Vertical Spotsize','Horizontal Spotsize','Vertical Fit',...
    'Horizontal Fit','Location','SouthEast')
hold off

subplot(2,1,2)
plot(dists,resid1,'x')
hold on
plot(dists,resid2,'r*');
xlabel('Distance (z)')
title('Residuals')
ylabel('Fractional Difference')
legend('Vertical Fit Residuals','Horizontal Fit Residuals',...
    'Location','SouthEast')
grid

outputs=[vertparams horizparams];

 

 

 

Later on I may repeat some measurements and try to gain more certainty in my fit. In the mean time I will use this beam profile for mode matching. 

 

  512   Tue Jun 3 02:15:29 2008 AndreySummaryCamerasFitting results

There have been a lot of work going on related to the processing of images captured by the cameras GC-650 and GC-750 recently.

In the end of the week of May 30 Joseph and me (Andrey) installed the two cameras capturing the images of the pick-off of the main beam on the PSL optical table. The cameras are located after the picked-off beam going towards the "PSL position QPD", after the 33-66 beamsplitter (33% of reflection and 66% of transmission).

Initially (on May 30) the GC-650 camera was taking the images of reflected beam, while the camera GC-750 was taking images of transmitted beam. On Monday June 2 we switched the positions of the cameras, so GC-650 appeared to be on the path of the transmitted beam and GC-750 on the path of the reflected beam.

I (Andrey Rodionov) was able in the weekend to succeed in writing a Matlab program that performs the two-dimensional Gaussian fitting of the captured images, and I used that program to fit the images from the cameras.

The program fits the camera data by a two-dimensional Gaussian surface:

Z = A * exp[ - 2 * (X - X_Shift)^2 / (Waist_X)^2 ] * exp[ - 2 * (Y - Y_Shift)^2 / (Waist_Y)^2 ] + CONST_Shift,

where A, X_Shift, Waist_X, Y_Shift, Waist_Y, CONST_Shift are 6 parameters of the fit.

Attached are the pdf-files showing the results: images taken with our cameras, the 2-dimensional Gaussian fit for these images and the surfaces of residuals. Residuals are differences between the exact beam profile and the result of fitting. In normalized version of residual graph I normalize it by the first coefficient of fitting A, the factor in front of the exponents.
Attachment 1: May30-GC650.pdf
May30-GC650.pdf May30-GC650.pdf May30-GC650.pdf May30-GC650.pdf May30-GC650.pdf May30-GC650.pdf
Attachment 2: May30-GC750.pdf
May30-GC750.pdf May30-GC750.pdf May30-GC750.pdf May30-GC750.pdf May30-GC750.pdf May30-GC750.pdf
Attachment 3: June02-GC650.pdf
June02-GC650.pdf June02-GC650.pdf June02-GC650.pdf June02-GC650.pdf June02-GC650.pdf June02-GC650.pdf
Attachment 4: June02-GC750.pdf
June02-GC750.pdf June02-GC750.pdf June02-GC750.pdf June02-GC750.pdf June02-GC750.pdf June02-GC750.pdf
  16467   Tue Nov 16 11:37:26 2021 HangHowToSUSFitting suspension model--large systematic errors

One goal of our sysID study is to improve the aLIGO L2A feedforward. Our algorithm currently improves only the statistical uncertainty and assumes the systematic errors are negligible. However, I am currently baffled by how to fit a (nearly) realistic suspension model...

My test study uses the damped aLIGO QUAD suspension model. From the Matlab model I extract the L2 drive in [N] to L3 pitch in [rad] transfer function (given by a SS model with the A matrix having a shape of 103x103). I then tried to use VectFIT to fit the noiseless TF. After removing nearby z-p pairs (defined by less than 0.2 times the lowest pole frequency) and high-frequency zeros, I got a model with 6 complex pole pairs and 4 complex zero pairs (21 free parameters in total). I also tried to fit the TF (again, noiseless) with an MCMC algorithm assuming the underlying model has the same number of parameters as the VectFIT results. 

Please see the first attached plots for a comparison between the fitted models and the true one. In the second plot, we show the fractional residual

    | TF_true - TF_fit | / | TF_true |,

and the inverse of this number gives the saturating SNR at each frequency. I.e., when the statistical SNR is more than the saturating value, we are then limited by systematic errors in the fitting. And so far, disappointingly I can only get an SNR of 10ish for the main resonances...

I wonder if people know better ways to reduce this fitting systematic... Help is greatly appreciated!

Attachment 1: L2L_L3P_fit.pdf
L2L_L3P_fit.pdf
Attachment 2: L2L_L3P_residual.pdf
L2L_L3P_residual.pdf
  14439   Thu Feb 7 17:27:53 2019 KojiSummaryTip-TIltFive FiveNine Optics Optics delivered

5 PR3/SR3 optics from FiveNine Optics were delivered. The data sheets were scanned and uploaded to the following wiki page. https://wiki-40m.ligo.caltech.edu/Aux_Optics

  14442   Fri Feb 8 00:20:56 2019 gautamSummaryTip-TIltFive FiveNine Optics Optics delivered

They have been stored on the 3rd shelf from top in the clean optics cabinet at the south end. EX

Quote:

5 PR3/SR3 optics from FiveNine Optics were delivered. The data sheets were scanned and uploaded to the following wiki page. https://wiki-40m.ligo.caltech.edu/Aux_Optics

  16274   Tue Aug 10 17:24:26 2021 pacoUpdateGeneralFive day trend

Attachment 1 shows a five and a half day minute-trend of the three temperature sensors. Logging started last Thursday ~ 2 pm when all sensors were finally deployed. While it appears that there is a 7 degree gradient along the XARM it seems like the "vertex" (more like ITMX) sensor was just placed on top of a network switch (which feels lukewarm to the touch) so this needs to be fixed. A similar situation is observed in the ETMY sensor. I shall do this later today.


Done. The temperature reading should now be more independent from nearby instruments.


Wed Aug 11 09:34:10 2021 I updated the plot with the full trend before and after rearranging the sensors.

Attachment 1: six_day_minute_trend.png
six_day_minute_trend.png
  4868   Thu Jun 23 21:35:46 2011 Jamie, Rana, KiwamuUpdateSUSFix calibration for sus sensors

We have fixed the counts-to-micron (cts2um) calibration for the suspension sensor filters. Each suspension sensor filter bank (e.g. ULSEN) has a "cts2um" calibration filter. These have now been set with the following flat gains:

   40 V       10^3 um         um
 -------- *  --------  = .36  --
 2^16 cts     1.7 V           ct

The INMTRX was also fixed with proper element values:

UL UR LR LL SIDE  
.25 .25 .25 .25 0 POS
1.666 1.666 -1.666

-1.666

0 PIT
1.666 -1.666 -1.666 1.666 0 YAW
0 0 0 0 1 SIDE

This was done for all core optic suspensions (BS, PRM, SRM, ITMX, ITMY, ETMX, ETMY).

 

  8325   Thu Mar 21 12:04:05 2013 ManasaUpdateComputersFixed

All FE computers are back.

Restart procedure:

0a. Restart frame builder: telnet fb 8087 & type shutdown

0b. Restart mx_stream from the FE overview screen

1. I ssh ed to the computer. (c1lsc, c1ioo, c1iscex, c1isey)

2. I used 'sudo shutdown -r (computername)'. They came back ON.

3. While rebooting c1ioo, c1sus shutdown (for reasons I don't know). I could not ping or ssh c1SUS after this.

4. I went in and switched c1SUS computer OFF and back ON after which I could ssh to it.

5. I did the same reboot procedure for c1SUS.

6. I had to restart some of the models individually.
    (i) ssh to the computer running the model
    (ii) rtcds restart 'model name'

7. All computers are back now.

up.png

  8326   Thu Mar 21 12:33:51 2013 ranaUpdateComputersFixed

Please stop power cycling computers. This is not an acceptable operation (as Jamie already wrote before). When you don't know what to do besides power cycling the computer, just stop and do something else or call someone who knows more. Every time you kill the power to a computer you are taking a chance on damaging it or corrupting some hard drive.

In this case, the right thing to do would be to hook up the external keyboard and monitor directly to c1sus to diagnose things.

NO MORE TOUCHING THE POWER BUTTON.

  8453   Sun Apr 14 17:30:14 2013 ManasaUpdateLockingFixed

TRY path fixed and ready for normalization.

I used 2" BS at R=50 and R=98 to reflect the Y arm transmission at QPD-Y and TRY PD respectively. The residual beam transmitted by the BS is now steered by a Y1mirror to the camera. With Y arm locked, transmission currently measures 40mW against the expected 70mW. TRY shows 0.45 counts in dataviewer.

  8455   Sun Apr 14 23:20:42 2013 DenUpdateLockingFixed

Quote:

TRY path fixed and ready for normalization.

I used 2" BS at R=50 and R=98 to reflect the Y arm transmission at QPD-Y and TRY PD respectively. The residual beam transmitted by the BS is now steered by a Y1mirror to the camera. With Y arm locked, transmission currently measures 40mW against the expected 70mW. TRY shows 0.45 counts in dataviewer.

 I think it is too much. Incident power to IFO is 1.3 W. Even if we assume no losses and pick-offs on the path to the arms, we should get ~100 uW out of the cavity. I measured X and Y arms transmission to be 60 uW. Did you disable triggering during your measurement?

  8463   Thu Apr 18 21:12:56 2013 ManasaUpdateLockingFixed

[Den, Manasa]

TRY & TRX power measurement was redone.

TRY measures 66uW and 0.8counts on dataviewer.
TRX measures 70.4uW and 0.84counts on dataviewer.

___________________________
Detector       Power
-------------------------------------------------
QPD-Y          33uW (50%)
TRY-PD         29.8uW (49%)
Y-Camera         1%
QPD-X         35.2uW (50%)
TRX-PD        25.1uW (90%)
X-Camera    10%
____________________________

  8055   Mon Feb 11 13:07:17 2013 Max HortonUpdateSummary PagesFixed A Calendar Bug

Understanding the Code:  Documented more functions in summary_pages.py.  Since it is very difficult and slow to understand what is going on, it might be best to just start trying to factor out the code into multiple files, and understand how the code works from there.

Crontab:  Started learning how the program is called by cron / what cron is, so that I can fix the problem that forces data to only be displayed up until 6PM.

Calendars:  One of the problems with the page is that the calendars on the left column didn't have any of the months of 2013 in them.

I identified the incorrect block of code as:

Original Code:
  # loop over months
  while t < e:
     if t.month < startday.month or t >= endday:
       ptable[t.year].append(str)
    else:
      ptable[t.year].append(calendar_link(t, firstweekday, tab=tab, run=run))

    # increment by month
    # Move forward day by day, until a new month is reached.
    m = t.month
    while t.month == m:
      t = t + d

    # Ensure that y still represents the current year.
    if t.year > y:
      y = t.year
      ptable[y] = []

The problem is that the months between the startday and endday aren't being treated properly.

Modified Code:
  # loop over months
  while t < e:
    if (t.month < startday.month and t.year <= startday.year) or t >= endday:
      ptable[t.year].append(str)
    else:
      ptable[t.year].append(calendar_link(t, firstweekday, tab=tab, run=run))

    # increment by month
    # Move forward day by day, until a new month is reached.
    m = t.month
    while t.month == m:
      t = t + d

    # Ensure that y still represents the current year.
    if t.year > y:
      y = t.year
      ptable[y] = []


After this change, the calendars display the year of 2013, as desired.

  11480   Wed Aug 5 17:15:08 2015 EveUpdateSummary PagesFixed ASC Tab

I've fixed the ASC tab on the summary pages to populate the graphs with data without causing an error.

Motivation: The ASC tab was showing no data. It resulted in a name error when generated.

What I did:

A name error indicates a bad channel name in the plot definition. I identified two errors in the code:

  1. I said C1:SUS_MC1_ASCPIT_OUT16.mean instead of C1:SUS-MC1_ASCPIT_OUT16.mean (underscore should be dash)
  2. The channel C1:ASX-XARM_M1_PUT_OSC_CLKGAIN was resulting in a name error. I removed it.

Results:

The plots are not processing without error. However, no titles or axis labels are present on the plots- I'll work on adding these.

 

  5098   Tue Aug 2 23:02:48 2011 NicoleUpdateSUSFixed Accelerometer


 

The EM shaker was broken (the input terminals (banana inputs) had snapped off. To fix this, I have mounted two banana input mounting posts to a metal mount that Steve attached to the shaker.

shakerposts.jpgclipstoamplifier.jpg

However, because bananas do not provide a secure connection (they easily fall out), I have made special wires to connect the banana inputs of the shaker to the mounted banana inputs of the amplifier I am using (along with the sine generating function of the HP 3563A signal analyzer). Upon Koji's suggestion, I have made C-shaped clips to attach to the banana post mounts. These clips are made from insulated ring terminals.

 newclips.jpg

Today I tested the  shaker and it works! WOOT! I currently have the shaker attached to the horizontal sliding platform (without the TT suspension on it).

Using a 750mHz signal from the HP 3563A with an amplitude of 500 mV amplified to 0.75V, I have gotten the shaker to displace the platform (without the TT suspension on it) 1 mm.

  857   Tue Aug 19 19:14:17 2008 YoichiConfigurationDAQFixed C1:IOO-MC_RFAMPDDC
Yoichi, Rob

C1:IOO-MC_RFAMPDDC, which is a PD at the transmission port of the MC, was not recording sensible values.
So I tracked down the problem starting from the centering of the beam on the PD.
The beam was hitting the PD properly. The DC output BNC on the PD provided +1.25V output when the light was
falling on the PD. The PD is fine.
The flat cable from the PD runs to the IOO rack and fed into the LSC PD interface card.
The output from the interface card is connected to a VMIC3113A DAQ card, through cross connects.
The voltages on the cross connects were ok.
The VMIC3113A was controlled by an EPICS machine (c1iool0). So it provides only a slow channel.
By looking at C1IOOF.ini and tpchn_C1.par, I figured that C1:IOO-MC_RFAMPDDC is using chnnum=13639 in the RFM
network and it is named C1:IOO-ICS_CHAN_15 in the .par file. So it is reading values from the ICS DAQ board.
Actually nothing was connected to the channel 15 of the ICS board and that was why C1:IOO-MC_RFAMPDDC was reading
nothing. So I took the PD signal from the cross connect and hooked it up to the Ch15 of the ICS DAQ through
the large black break out box with 4-pin LEMOs. Now C1:IOO-MC_RFAMPDDC reads the DC output of the PD.
I also put an ND filter in front of the RFAMPD to avoid the saturation of the ADC. The attenuation should have been done
electronically, but I was too lazy. Since the ND filter changes the Stochmon values, someone should remove it and reduce the
gain of the LSC PD interface accordingly.
  16236   Thu Jul 1 16:55:21 2021 AnchalSummaryOptical LeversFixed Centeringoptical levers PRM

This was a mistake. When arms are locked, PRM is misaligned by setting -800 offset in PIT dof of PRM. The oplev is set to function in normal state not this misalgined configuration. I undid my changes today by switching off the offset, realigning the oplev to center and then restoring the single arm locked state. The PRM OpLevs loops are off now.

Quote:

 PRM because I've known that we have been keeping its OpLev off. The reason was clear once I opened the table. The oplev reflection beam was hitting the PD box instead of the PD. After correcting, I was able to swithc on PRM opLev loops and saw normal functioning.

 

  4184   Fri Jan 21 17:59:27 2011 josephb, alexUpdateCDSFixed Dolphin transmission

The orientation of the Dolphin cards seems to be opposite on c1lsc and c1sus.  The wide part is on top on c1lsc and on the bottom on c1sus.  This means, the cable is plugged into the left Dolphin port on c1lsc and into the right Dolphin port on c1sus.  Otherwise you get a wierd state where you receive but not transmit.

  4518   Wed Apr 13 11:34:07 2011 josephbUpdateCDSFixed IFO_ALIGN.adl

Problem:

I switched the ITMX and ITMY control channels yesterday, but forgot to update the IFO_ALIGN.adl file (/opt/rtcds/caltech/c1/medm/c1ifo/) which had the control labels swapped to make life easier.

Solution:

I swapped ITMX and ITMY control locations on the screen.

Question:

Are there any other screens involving ITMX and ITMY that had controls reversed to make life easier?

  682   Wed Jul 16 16:28:14 2008 josephbConfigurationComputersFixed IP address on Switch
Realized today that the change I made back on June 30th to the switch was to the wrong switch. I had disabled the DHCP setting and mislabeled the switch in the control room (which seems to not have affected anything).

I've turned DHCP back on and labeled it correctly using the Netgear "Smartwizard discovery" program.
  10927   Wed Jan 21 15:27:47 2015 JenneUpdateLSCFixed LSC model bug

This problem with the CARM loop last night was the fault of a bug that I had put into the LSC model last week.  When I gave the input matrix and normalization matrix double rows, I had put the goto tags for the CARM normalization matrix rows backwards.  So, even though I thought I was not normalizing CARM, in fact I was normalizing by POPDC, which was near zero since the PRM was misaligned.

Anyhow, found, fixed, currently locking, and all seems well.

  4308   Wed Feb 16 12:16:14 2011 josephbUpdateCDSFixed Optical level SUM channel names

[Joe,Valera]

Valera pointed out the OPLEV SUM channels were incorrect.  We changing the optical level sum channel to _OPLEV_SUM when it should have been OL_SUM.  This has been fixed in the activateDAQ.py script.

  5178   Wed Aug 10 19:18:26 2011 NicoleSummarySUSFixed Reflective Photosensors; Recalibrated Photosensor 2

Thanks to Koji's help, the second photosensor, which was not working, has been fixed. I have re-calibrated the photosensor after fixing a problem with the circuit.  I have determined the new linear region to lie between 7.6 mm and 19.8mm. The slope defining the linear region is -0.26 V/mm (no longer the same as the first photosensor, which is -0.32 V/mm).

 

Here is the calibration plot.

ps2.jpg

  3642   Mon Oct 4 11:20:45 2010 josephbUpdateCDSFixed Suspension binary output list and sus model

I've updated the CDS wiki page listing the wiring of the 40m suspensions with the correct binary output channels.  I previously had confused the wiring of the Auxillary crate XY220 (watchdogs) with the SOS coil dewhitening bypasses.  So I had wound up with the wrong channels (the physical cables we plugged in were correct, just what I thought was going on channel X of that cable was wrong).  This has been corrected in the plan now.  The updated channel/cable list is at http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_09/CDS/Suspension_wiring_to_channels

  4130   Mon Jan 10 16:47:08 2011 josephb, alex, rolfUpdateCDSFixed c1lsc dolphin reflected memory

While Alex and Rolf were visiting, I pointed out that the Dolphin card was not sending any data, not even a time stamp, from the c1lsc machine.

After some poking around, we realized the IOP (input/output processor) was coming up before the Dolphin driver had even finished loading. 

We uncommented the line

#/etc/dolphin_wait

in the /diskless/root/etc/rc.local file on the frame builder.  This waits until the dolphin module is fully loaded, so it can hand off a correct pointer to the memory location that the Dolphin card reads and writes to.  Previously, the IOP had been receiving a bad pointer since the Dolphin driver had not finished loading.

So now the c1lsc machine can communicate with c1sus via Dolphin and from there the rest of the network via the traditional Ge Fanuc RFM.

  4666   Mon May 9 15:21:36 2011 josephbUpdatePSLFixed channel names for PSL QPDs, fixed saturation, changed signs

[Valera, Joe]

Software Changes:

First we changed all the C1:IOO-QPD_*_* channels to C1:PSL-QPD_*_* channels in the /cvs/cds/caltech/target/c1iool0/c1ioo.db file, as well as the /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini file.  We then rebooted the frame builder via "telnet fb 8087" and then "shutdown".

This change breaks continuity for these channels prior to today.

The C1:PSL-QPD_POS_HOR and C1:PSL-QPD_POS_VERT channels were found to be backwards as well.  So we modified the /cvs/cds/caltech/target/c1iool0/c1ioo.db file to switch them.

Lastly, we changed the ASLO and AOFF values for the C1:PSL-QPD_POS_SUM and the C1:PSL-QPD_ANG_SUM so as to provide positive numbers.  This was done by flipping the sign for each entry.

ASLO went from 0.004883 to -0.004883, and AOFF when from -10 to 10 for both channels.

Hardware Changes:

The C1:PSL-QPD_ANG_SUM channel had been saturated at -10V.  Valera reduced the power on the QPD to drop it to about 4V by placing an ND attenuator in the ANG QPD path.

  4677   Tue May 10 10:06:23 2011 josephbUpdatePSLFixed channel names for PSL QPDs, fixed saturation, changed signs

I added calculation entries to the /cvs/cds/caltech/target/c1iool0/c1ioo.db file which are named C1:IOO-QPD_*_*, as the channels were originally named.  These calculation channels have the identical data to the C1:PSL-QPD_*_* channels.  I then added the channels to the C0EDCU.ini file, so as to once again have continuity for the channels, in addition to having the newer, better named channels.

The c1iool0 machine ("telnet c1iool0", "reboot") and the framebuilder process ("telnet fb 8087", "shutdown") were both restarted after these changes.

These channels were brought up in dataviewer and compared.  The approriate channels were identical.

Quote:

[Valera, Joe]

Software Changes:

First we changed all the C1:IOO-QPD_*_* channels to C1:PSL-QPD_*_* channels in the /cvs/cds/caltech/target/c1iool0/c1ioo.db file, as well as the /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini file.  We then rebooted the frame builder via "telnet fb 8087" and then "shutdown".

This change breaks continuity for these channels prior to today.

 

  16179   Thu Jun 3 17:35:31 2021 AnchalSummaryIMCFixed medm button

I fixed the PSL shutter button on Shutters summary page C1IOO_Mech_Shutter.adl. Now PSL switch changes C1:PSL-PSL_ShutterRqst channel. Earlier it was C1:AUX-PSL_ShutterRqst which doesn't do anything.

 

Attachment 1: C1IOO_Mech_Shutters.png
C1IOO_Mech_Shutters.png
  4404   Fri Mar 11 11:33:24 2011 josephbUpdateCDSFixed mistake in Matrix of Filter banks naming convention

While fixing up some medm screens and getting spectra of the simulated plant, I realized that the naming convention for the Matrices of Filter banks was backwards when compared to that of the normal matrices (and the rest of the world).  The naming was incorrectly column, row.

This has several ramifications:

1) I had to change the suspensions screens for the TO_COIL  output filters.

2) I had to change the filters for the suspension with regards to the TO_COIL output filters so they go in the correct filter banks.

3) Burt restores to times previous March 11th around noon, will put your TO_COIL output filters in a funny state that will need to be fixed.

4) The simplant RESPONSE filters had to be moved to the correct filter banks.

5) If you have some model I'm not aware of that uses the FiltMuxMatrix piece, it is going to correctly build now, but you're going to have to move filters you may have created with foton.

  16391   Mon Oct 11 17:31:25 2021 AnchalSummaryCDSFixed mounting of mx devices in fb. daqd_dc is running now.
 
 

However, lspci | grep 'Myri' shows following output on both computers:

controls@fb1:/dev 0$ lspci | grep 'Myri'
02:00.0 Ethernet controller: MYRICOM Inc. Myri-10G Dual-Protocol NIC (rev 01)

Which means that the computer detects the card on PCie slot.

 

I tried to add this to /etc/rc.local to run this script at every boot, but it did not work. So for now, I'll just manually do this step everytime. Once the devices are loaded, we get:

controls@fb1:/etc 0$ ls /dev/*mx*
/dev/mx0  /dev/mx4  /dev/mxctl   /dev/mxp2  /dev/mxp6         /dev/ptmx
/dev/mx1  /dev/mx5  /dev/mxctlp  /dev/mxp3  /dev/mxp7
/dev/mx2  /dev/mx6  /dev/mxp0    /dev/mxp4  /dev/open-mx
/dev/mx3  /dev/mx7  /dev/mxp1    /dev/mxp5  /dev/open-mx-raw

The, restarting all daqd_ processes, I found that daqd_dc was running succesfully now. Here is the status:

controls@fb1:/etc 0$ sudo systemctl status daqd_* -l
● daqd_dc.service - Advanced LIGO RTS daqd data concentrator
   Loaded: loaded (/etc/systemd/system/daqd_dc.service; enabled)
   Active: active (running) since Mon 2021-10-11 17:48:00 PDT; 23min ago
 Main PID: 2308 (daqd_dc_mx)
   CGroup: /daqd.slice/daqd_dc.service
           ├─2308 /usr/bin/daqd_dc_mx -c /opt/rtcds/caltech/c1/target/daqd/daqdrc.dc
           └─2370 caRepeater

Oct 11 17:48:07 fb1 daqd_dc_mx[2308]: mx receiver 006 thread priority error Operation not permitted[Mon Oct 11 17:48:06 2021]
Oct 11 17:48:07 fb1 daqd_dc_mx[2308]: mx receiver 005 thread put on CPU 0
Oct 11 17:48:07 fb1 daqd_dc_mx[2308]: [Mon Oct 11 17:48:06 2021] [Mon Oct 11 17:48:06 2021] mx receiver 006 thread put on CPU 0
Oct 11 17:48:07 fb1 daqd_dc_mx[2308]: mx receiver 007 thread put on CPU 0
Oct 11 17:48:07 fb1 daqd_dc_mx[2308]: [Mon Oct 11 17:48:06 2021] mx receiver 003 thread - label dqmx003 pid=2362
Oct 11 17:48:07 fb1 daqd_dc_mx[2308]: [Mon Oct 11 17:48:06 2021] mx receiver 003 thread priority error Operation not permitted
Oct 11 17:48:07 fb1 daqd_dc_mx[2308]: [Mon Oct 11 17:48:06 2021] mx receiver 003 thread put on CPU 0
Oct 11 17:48:07 fb1 daqd_dc_mx[2308]: warning:regcache incompatible with malloc
Oct 11 17:48:07 fb1 daqd_dc_mx[2308]: [Mon Oct 11 17:48:06 2021] EDCU has 410 channels configured; first=0
Oct 11 17:49:06 fb1 daqd_dc_mx[2308]: [Mon Oct 11 17:49:06 2021] ->4: clear crc

● daqd_fw.service - Advanced LIGO RTS daqd frame writer
   Loaded: loaded (/etc/systemd/system/daqd_fw.service; enabled)
   Active: active (running) since Mon 2021-10-11 17:48:01 PDT; 23min ago
 Main PID: 2318 (daqd_fw)
   CGroup: /daqd.slice/daqd_fw.service
           └─2318 /usr/bin/daqd_fw -c /opt/rtcds/caltech/c1/target/daqd/daqdrc.fw

Oct 11 17:48:09 fb1 daqd_fw[2318]: [Mon Oct 11 17:48:09 2021] [Mon Oct 11 17:48:09 2021] Producer thread - label dqproddbg pid=2440
Oct 11 17:48:09 fb1 daqd_fw[2318]: Producer crc thread priority error Operation not permitted
Oct 11 17:48:09 fb1 daqd_fw[2318]: [Mon Oct 11 17:48:09 2021] [Mon Oct 11 17:48:09 2021] Producer crc thread put on CPU 0
Oct 11 17:48:09 fb1 daqd_fw[2318]: Producer thread priority error Operation not permitted
Oct 11 17:48:09 fb1 daqd_fw[2318]: [Mon Oct 11 17:48:09 2021] Producer thread put on CPU 0
Oct 11 17:48:09 fb1 daqd_fw[2318]: [Mon Oct 11 17:48:09 2021] Producer thread - label dqprod pid=2434
Oct 11 17:48:09 fb1 daqd_fw[2318]: [Mon Oct 11 17:48:09 2021] Producer thread priority error Operation not permitted
Oct 11 17:48:09 fb1 daqd_fw[2318]: [Mon Oct 11 17:48:09 2021] Producer thread put on CPU 0
Oct 11 17:48:10 fb1 daqd_fw[2318]: [Mon Oct 11 17:48:10 2021] Minute trender made GPS time correction; gps=1318034906; gps%60=26
Oct 11 17:49:09 fb1 daqd_fw[2318]: [Mon Oct 11 17:49:09 2021] ->3: clear crc

● daqd_rcv.service - Advanced LIGO RTS daqd testpoint receiver
   Loaded: loaded (/etc/systemd/system/daqd_rcv.service; enabled)
   Active: active (running) since Mon 2021-10-11 17:48:00 PDT; 23min ago
 Main PID: 2311 (daqd_rcv)
   CGroup: /daqd.slice/daqd_rcv.service
           └─2311 /usr/bin/daqd_rcv -c /opt/rtcds/caltech/c1/target/daqd/daqdrc.rcv

Oct 11 17:50:21 fb1 daqd_rcv[2311]: Creating C1:DAQ-NDS0_C1X07_CRC_SUM
Oct 11 17:50:21 fb1 daqd_rcv[2311]: Creating C1:DAQ-NDS0_C1BHD_STATUS
Oct 11 17:50:21 fb1 daqd_rcv[2311]: Creating C1:DAQ-NDS0_C1BHD_CRC_CPS
Oct 11 17:50:21 fb1 daqd_rcv[2311]: Creating C1:DAQ-NDS0_C1BHD_CRC_SUM
Oct 11 17:50:21 fb1 daqd_rcv[2311]: Creating C1:DAQ-NDS0_C1SU2_STATUS
Oct 11 17:50:21 fb1 daqd_rcv[2311]: Creating C1:DAQ-NDS0_C1SU2_CRC_CPS
Oct 11 17:50:21 fb1 daqd_rcv[2311]: Creating C1:DAQ-NDS0_C1SU2_CRC_SUM
Oct 11 17:50:21 fb1 daqd_rcv[2311]: Creating C1:DAQ-NDS0_C1OM[Mon Oct 11 17:50:21 2021] Epics server started
Oct 11 17:50:24 fb1 daqd_rcv[2311]: [Mon Oct 11 17:50:24 2021] Minute trender made GPS time correction; gps=1318035040; gps%120=40
Oct 11 17:51:21 fb1 daqd_rcv[2311]: [Mon Oct 11 17:51:21 2021] ->3: clear crc

Now, even before starting teh FE models, I see DC status as ox2bad in the CDS screens of the IOP and user models. The mx_stream service remains in a failed state at teh FE machines and remain the same even after restarting the service.

controls@c1sus2:~ 0$ sudo systemctl status mx_stream -l
● mx_stream.service - Advanced LIGO RTS front end mx stream
   Loaded: loaded (/etc/systemd/system/mx_stream.service; enabled)
   Active: failed (Result: exit-code) since Mon 2021-10-11 17:50:26 PDT; 15min ago
  Process: 382 ExecStart=/etc/mx_stream_exec (code=exited, status=1/FAILURE)
 Main PID: 382 (code=exited, status=1/FAILURE)

Oct 11 17:50:25 c1sus2 systemd[1]: Starting Advanced LIGO RTS front end mx stream...
Oct 11 17:50:25 c1sus2 systemd[1]: Started Advanced LIGO RTS front end mx stream.
Oct 11 17:50:25 c1sus2 mx_stream_exec[382]: Failed to open endpoint Not initialized
Oct 11 17:50:26 c1sus2 systemd[1]: mx_stream.service: main process exited, code=exited, status=1/FAILURE
Oct 11 17:50:26 c1sus2 systemd[1]: Unit mx_stream.service entered failed state.

But  if I restart the mx_stream service before starting the rtcds models, the mx-stream service starts succesfully:

controls@c1sus2:~ 0$ sudo systemctl restart mx_stream
controls@c1sus2:~ 0$ sudo systemctl status mx_stream -l
● mx_stream.service - Advanced LIGO RTS front end mx stream
   Loaded: loaded (/etc/systemd/system/mx_stream.service; enabled)
   Active: active (running) since Mon 2021-10-11 18:14:13 PDT; 25s ago
 Main PID: 1337 (mx_stream)
   CGroup: /system.slice/mx_stream.service
           └─1337 /usr/bin/mx_stream -e 0 -r 0 -w 0 -W 0 -s c1x07 c1su2 -d fb1:0

Oct 11 18:14:13 c1sus2 systemd[1]: Starting Advanced LIGO RTS front end mx stream...
Oct 11 18:14:13 c1sus2 systemd[1]: Started Advanced LIGO RTS front end mx stream.
Oct 11 18:14:13 c1sus2 mx_stream_exec[1337]: send len = 263596
Oct 11 18:14:13 c1sus2 mx_stream_exec[1337]: Connection Made

However, the DC status on CDS screens still show 0x2bad. As soon as I start the rtcds model c1x07 (the IOP model for c1sus2), the mx_stream service fails:

controls@c1sus2:~ 0$ sudo systemctl status mx_stream -l
● mx_stream.service - Advanced LIGO RTS front end mx stream
   Loaded: loaded (/etc/systemd/system/mx_stream.service; enabled)
   Active: failed (Result: exit-code) since Mon 2021-10-11 18:18:03 PDT; 27s ago
  Process: 1337 ExecStart=/etc/mx_stream_exec (code=exited, status=1/FAILURE)
 Main PID: 1337 (code=exited, status=1/FAILURE)

Oct 11 18:14:13 c1sus2 systemd[1]: Starting Advanced LIGO RTS front end mx stream...
Oct 11 18:14:13 c1sus2 systemd[1]: Started Advanced LIGO RTS front end mx stream.
Oct 11 18:14:13 c1sus2 mx_stream_exec[1337]: send len = 263596
Oct 11 18:14:13 c1sus2 mx_stream_exec[1337]: Connection Made
Oct 11 18:18:03 c1sus2 mx_stream_exec[1337]: isendxxx failed with status Remote Endpoint Unreachable
Oct 11 18:18:03 c1sus2 mx_stream_exec[1337]: disconnected from the sender
Oct 11 18:18:03 c1sus2 mx_stream_exec[1337]: c1x07_daq mmapped address is 0x7fe3620c3000
Oct 11 18:18:03 c1sus2 mx_stream_exec[1337]: c1su2_daq mmapped address is 0x7fe35e0c3000
Oct 11 18:18:03 c1sus2 systemd[1]: mx_stream.service: main process exited, code=exited, status=1/FAILURE
Oct 11 18:18:03 c1sus2 systemd[1]: Unit mx_stream.service entered failed state.

This shows that the start of rtcds model, causes the fail in mx_stream, possibly due to inability of finding the endpoint on fb1. I've again reached to the edge of my knowledge here. Maybe the fiber optic connection between fb and the network switch that connects to FE is bad, or the connection between switch and FEs is bad.

But we are just one step away from making this work.

 

 

  3008   Fri May 28 13:17:05 2010 josephbUpdateCDSFixed problem with channel access on c1iscex

Talked with Alex and tracked down why the codes were not working on the new c1iscex finally.  The .bashrc and .cshrc files in /home/controls/ on c1iscex has the following lines:

setenv EPICS_CA_ADDR_LIST 131.215.113.255
setenv EPICS_CA_AUTO_ADDR_LIST NO

This was interfering with channel access and preventing read and writes from working properly.  We simply commented them out. After logging out and back in, the things like ezcaread and write started working, and we were able to get the models passing data back and forth.

Next up, testing RFM communications between megatron on c1iscex.  To do this, I'd like to move Megatron down to 1Y3, and setup a firewall for it and c1iscex so I can test the frame builder and testpoints at the same time on both machines.

  16282   Wed Aug 18 20:30:12 2021 AnchalUpdateASSFixed runASS scripts

Late elog: Original time of work Tue Aug 17 20:30 2021


I locked the arms yesterday remotely and tried running runASS.py scripts (generally ran by clicking Run ASS buttons on IFO OVERVIEW screen of ASC screen). We have known for few weeks that this script stopped working for some reason. It would start the dithering and would optimize the alignment but then would fail to freeze the state and save the alignment.

I found the caget('C1:LSC-TRX_OUT') or caget('C1:LSC-TRY_OUT') were not working in any of the workstations. This is weird since caget was able to acquire these fast channel values earlier and we have seen this script to work for about a month without any issue.

Anyways, to fix this, I just changed the channel name to 'C1:LSC-TRY_OUT16' when the script checks in the end if the arm has indeed been aligned. It was only this step that was failing. Now the script is working fine and I tested them on both arms. On the Y arm, I misaligned the arm by adding bias in yaw by changing C1:SUS-ITMY_YAW_OFFSET from -8 to 22. The script was able to align the arm back.

  3907   Fri Nov 12 11:36:06 2010 AidanConfigurationComputersFixed the PERL PATH errors from the scripts directory change

 I've been trying to get a PID loop running for the green locking and I've discovered that some of the directories in the path for the Perl Modules are now obselete. Specifically, since the scripts directory has been moved from /cvs/cds/caltech/scripts to /cvs/cds/rtcds/caltech/c1/scripts the following locations in the Perl @INC path list need to be changed:

  • /cvs/cds/caltech/scripts/general
  • /cvs/cds/caltech/scripts/general/perlmodules

I've added the above directories to the PERL5LIB path in /cvs/cds/caltech/cshrc.40m.

 

 

setenv PERL5LIB /cvs/cds/caltech/scripts/general:

/cvs/cds/caltech/scripts/general/perlmodules:

/cvs/cds/caltech/libs/solaris9/usr_local_lib/perl5/5.8.0/:

/cvs/cds/rtcds/caltech/c1/scripts/general:

/cvs/cds/rtcds/caltech/c1/scripts/general/perlmodules

 This seems to fix the problem .. at least, you no longer get an error if you try nodus:~>perl -e 'user EpicsTools'

 

  8452   Sun Apr 14 15:03:17 2013 ManasaUpdateLockingFixing - progress

Quote:

TRY signals are all gone!  Both the PD and the camera show no signal.  I went down there to turn off the lights, and look to see what was up, and I don't see any obvious things blocking the beam path on the table.  However, Steve has experimentally bungeed the lids down, so I didn't open the box to really look to see what the story is.

Absent TRY, I redid the IFO alignment.  Yarm locked, so I assumed it was close enough.  I redid Xarm alignment pretty significantly.  Transmission was ~0.5, which I got up to ~0.85 (which isn't too bad, since the PMC transmission is 0.74 instead of the usual 0.83).  I then aligned MICH, and PRM.  After fixing up the BS alignment, the POP beam wasn't hitting the POP PD in the center any more.  I centered the beam on the PD, although as Gabriele pointed out to me a week or two ago, we really need to put a lens in front of POP, since the beam is so big.  We're never getting the full beam when the cavity flashes, which is not so good.

Den is still working on locking, so I'll let him write the main locking report for the night.

We see that the PRC carrier lock seems to be more stable when we lock MICH with +1 for ITMY and -1 for ITMX, and PRCL with -1 for both ITMs.  This indicates that we need to revisit the systematic problem with using the PRM oplev to balance the coils, since that oplev has a relatively wide opening angle.  I am working on how to do this.

I'm fixing the TRY path.

I misaligned PRM and restored ETMY; but did not see the Y arm flashing. I am going ahead and moving the optics to get Y arm flashing again.

The slider values on the medm screen before touching any of them (for the record):

       tt1        tt2      itmy        etmy
p    -1.3886    0.8443     0.9320    -3.2583
y     0.3249    1.1407    -0.2849    -0.2751
  4455   Tue Mar 29 00:00:55 2011 KojiUpdateIOOFixing MC/Freq Divider Box

This is the log of the work on Wednesday 23rd.

1. Power Supply of the freq divider box

Kiwamu claimed that the comparator output of the freq div box only had small output like ~100mV.
The box worked on the electronics bench, we track down the power supply and found the fuse of the +15V line
brew out. It took sometime to notice this fact as the brown-out-LED of the fuse was not on and the power
supply terminal had +15V without the load. But this was because of the facts 1) the fuse is for 24V, and 2)
the large resistor is on the fuse for lighting the LED when the fuse is brown out.

I found another 24V fuse and put it there. Kiwamu is working on getting the correct fuses.

2. MC locking problem

After the hustle of the freq divider, the MC didn't lock. I tracked down the problem on the rack and found
there was no LO for the MC. This was fixed by pushing the power line cable of the AM Stabilizer for the MC LO, which was a bit loose.

  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.

ELOG V3.1.3-