40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 75 of 344  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  8430   Tue Apr 9 08:37:54 2013 SteveUpdate40m UpgradingEndtable upgrade for auxiliary green laser : TRY temporarily in place

Quote:

The TRY path on the end table is temporarily in place to help IFO locking.
The Y arm transmission was steered to get TRY back on the PD and the camera. I found that TRY is a couple of inches off in yaw at the end table (comparing to the CAD layout and the earlier layout) and I believe it is because of the changes in input pointing.
I've used a Y1 mirror to steer the Y transmission to an R98% BS. The reflected beam falls on PDA520 and the transmitted beam is steered to the camera. The earlier normalization of TRY is no more valid as the power distribution at the PD has changed.

Temporary  acrylic wind guard added between enclosure and ETMY transmission window to help IFO locking

  8341   Mon Mar 25 18:42:38 2013 ManasaUpdate40m UpgradingEndtable upgrade for auxiliary green laser : Timeline

 Endtable upgrade - timeline and progress chart. End table upgrade wiki page updated.

 

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

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

  8418   Fri Apr 5 01:28:56 2013 ManasaUpdate40m UpgradingEndtable upgrade for auxiliary green laser : populating the table

I started populating the end table; the TRY path to start with. I found that I need to redo the cables/electronics layout around the table as we have only one cable feedthrough hole with the new box right now. I need another hand with this and will have Annalisa help me tomorrow.

P.S. I misaligned PRM and restored ETMY to get TRY flashes. I tweaked ETMY to see strong TEM00 flashes.

Old slider positions on medm screen in case we need to restore them:

        TT1    TT2     ITMY    ETMY

P   -1.3586  0.8443   0.9114   -3.7693

Y   0.3049   1.1507  -0.2823  -0.2761

 

  8425   Tue Apr 9 00:15:18 2013 ManasaUpdate40m UpgradingEndtable upgrade for auxiliary green laser : populating the table

[Den, Annalisa, Manasa]

The Alberto laser was moved from the PSL table. The height of the heat sink rendered a beam height of only 3 inches. I did not want to deal with changing beam height at the table. So, we went ahead and used the old heat sink. I used the beam scan to make measurements of the beam width to match my mode-matching calculations and found some mismatch with the measurements done earlier. So I will measure the beam width again before alignment.

I will also have to change the layout because of the supporting posts that have come up with the new box. Annalisa is doing a COMSOL model to check what the thickness of these supporting posts should be so that the box stays stiff.

  8458   Wed Apr 17 02:20:13 2013 ManasaUpdate40m UpgradingEndtable upgrade for auxiliary green laser : progress

 

Assembly progress:

1. ETMY oplev setup has been put together. Because of the shift in the TRY path, I had to modify the oplev path on the table as well.

TRY_OPL.jpg

2. Green laser setup coming together:
    (i) Used a HWP after the NPRO to convert s-polarization to p-polarization. (Verified by introducing a PBS after the HWP and then removed later).
    (ii) Lens focuses the beam into the Faraday.
    (iii) Used steering mirrors to align the beam to the faraday. With 320mW before the Faraday, I was able to get 240mW after the output aperture. The spec sheet for the faraday specifies a 93% transmission; but what I measure is only 75%.

GRY.jpg

 

  8522   Thu May 2 01:19:41 2013 ManasaUpdate40m UpgradingEndtable upgrade for auxiliary green laser : progress

I started to put together optics at the endtable. I am attaching the layout with the green blocks showing the optics that are assembled and will not be moved henceforth unless somebody contradicts.

1. Power after HWP = 314mW
    Power before faraday = 310mW
    Power after faraday = 300mW (the power loss while aligning the faraday earlier was due to the AR coating on the focusing lens before the faraday - it was AR coated for visible and that accounted to the power lost)

2. Since we do not know the length of TGG inside faraday, I measured the beam profile after the faraday so that I can trace the beam without any errors to calculate exact mode matching solutions.

3. The NPRO beam seems to be obviously elliptical as seen on the IR card and also from beam profile measurement. So we cannot skip including cylindrical lenses in the layout.

ETMY_0502.png

 

  8543   Tue May 7 19:06:45 2013 ManasaUpdate40m UpgradingEndtable upgrade for auxiliary green laser : progress

I have updated the waists (W)  and beam diameters (D) at 1064nm optics on the endtable.

I am not able to locate the characteristics of QPD-Y and oplev PD and hence took the beam diameter to be half of the detector surface area to determine their positions.

Beam diameter on PDA520 used for TRY was calculated using the transimpedance and responsivity of the PD from an old elog in 2004.

ETMY_endtable_New.png 

  8556   Thu May 9 01:36:32 2013 ManasaUpdate40m UpgradingEndtable upgrade for auxiliary green laser : progress

Progress with end table:

Parts in green show assembled optics that will not require any changes. Parts in yellow are in place but will need either change of lenses in their optical path or change in position.

0509.png 

  8560   Thu May 9 22:29:23 2013 ManasaUpdate40m UpgradingEndtable upgrade for auxiliary green laser : progress

[Annalisa, Manasa]

More optics have been put on the table. Direction of the rejected beam from the 532nm faraday estimated to be ~1.7 deg along -y axis.

Transmon QPD, TRY and camera have beams on them for locking Y arm. Oplev configuration is waiting for it's lens to arrive.

 

  8561   Fri May 10 20:05:21 2013 AnnalisaUpdate40m UpgradingEndtable upgrade for auxiliary green laser : progress

I rotated some mounts along the green beam path, and I started aligning the beam again.

The beam is aligned up to the waveplate just before the doubler crystal, even if I couldn't reach more than 88% transmission for the Faraday. Next week I will finish the alignment and I'll put the lenses that Manasa already ordered.

 

  8565   Mon May 13 21:35:55 2013 AnnalisaUpdate40m UpgradingEndtable upgrade for auxiliary green laser : progress

Yend table - Current status

OPLEV

Today the 2m focal length lens along the oplev path (just after the laser) has been added. In Manasa's layout it allows to have a beam waist of 3.8mm on the OPLEV QPD, even if it seems to be smaller.

The laser is closer to the box wall than the layout shows (it's on the line n.1 instead of line n.9), so maybe it has to be moved in the position shown in the layout, as Steve suggests, to leave empty space just before the window.

Rana suggests a 2mm diameter beam on the QPD, so a new calculation has to be done to add a second lens.

GREEN

The beam has been aligned until the doubler, but after the crystal it it has a small tilt, so a better alignment has to be done.

Moreover, the beam waist has to be measured after the Faraday for the green, in way to choose the focal length of the lenses necessary for the mode matching.

Then the three steering mirrors to send the beam into the arm have to be put.

TRANSMON PATH

A lens which has to be put on the Transmon path (already ordered) has to be added, and the beam alignment on the QPD-y and on the PDA520 has to be done.

  8576   Tue May 14 21:03:15 2013 AnnalisaUpdate40m UpgradingEndtable upgrade for auxiliary green laser : progress

 

GREEN

The new lenses arrived, and I put the right 250mm before the doubler. I'm still not so confident with the alignment, because I cannot get more than 11-12 uW out from the "green" Faraday, with more than 200uW going in.

TRANSMON

I replaced the Y1 mirror with an HR1064-HT532. The alignment has to be done. Today the 50cm focal length lens arrived, and I'm going to put in tomorrow.

 

  8584   Wed May 15 21:27:39 2013 AnnalisaUpdate40m UpgradingEndtable upgrade for auxiliary green laser : progress

 

GREEN

I still have problems in maximizing the power out from the doubler. I realized that the real green power I obtain is about 30 uW, and it is the power which really enters the Faraday.

Before I was measuring it just after the Harmonic separator, and there was some residual IR beam which increased the power on the power meter, that's why I obtained about 200 uW.

I also tried to slightly vary the position of the mode matching lens, but I was not able to get more than 30 uW on the power meter.

TRANSMON PATH

The 50 cm focal length lens has been added in the position shown on Manasa's layout, and the beam has been focused on the PD.

 

 

  8486   Wed Apr 24 15:27:59 2013 ManasaUpdate40m UpgradingEndtable upgrade for auxiliary green laser : progress: New layout

Layout that will be improved upon over the next few days.

Things that need to be updated:
1. Waist size at all optics
2. Beam size at detectors and choice of lenses
3. IPANG & green PD proposed positions

 ETMY_endtable_New.png

  7889   Thu Jan 10 12:41:06 2013 ManasaConfiguration40m UpgradingEndtable upgrade for auxiliary green laser : wiki page

 

I have created a wiki page linked here with all details about the endtable upgrade.

The page has links to the new drawing for doubler post to hold the tilt-aligner that holds it. The Faradays will also be mounted similarly on tilt aligners placed on these posts. The bulk mounts will be made of aluminium similar to the colorful cylindrical mounts (images of which can be seen in the archived layouts on the wiki) that hold the He-Ne lasers and few faradays now.

  3762   Fri Oct 22 16:59:21 2010 JenneUpdateElectronicsEpic Takeover

As the suspension work winds down (we'll be completely done once the ETMs arrive, are suspended, and then are placed in the chambers), I'm going to start working on the RF system. 

Step 1: Figure out what Alberto has been up to the last few months.

Step 2: Figure out what still needs doing.

Step 3: Complete all the items listed out in step 2.

Step 4: Make sure it all works.

Right now I'm just starting steps 1 & 2.  I've made myself a handy-dandy wiki checklist: RF Checklist.  Hopefully all of the bits and pieces that need doing will be put here, and then I can start checking them off. Suggestions and additions to the list are welcome.

  3764   Fri Oct 22 18:22:27 2010 AlbertoUpdateElectronicsEpic Takeover

Quote:

As the suspension work winds down (we'll be completely done once the ETMs arrive, are suspended, and then are placed in the chambers), I'm going to start working on the RF system. 

Step 1: Figure out what Alberto has been up to the last few months.

Step 2: Figure out what still needs doing.

Step 3: Complete all the items listed out in step 2.

Step 4: Make sure it all works.

Right now I'm just starting steps 1 & 2.  I've made myself a handy-dandy wiki checklist: RF Checklist.  Hopefully all of the bits and pieces that need doing will be put here, and then I can start checking them off. Suggestions and additions to the list are welcome.

 There's also a page dedicated to the progress in the PD upgrade process:

http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_09/RF_System/Upgraded_RF_Photodiodes

There you can find a pdf document with my notes on that.

  15007   Mon Nov 4 11:41:28 2019 shrutiUpdateComputer Scripts / ProgramsEpics installed on donatella

I've installed pyepics on Donatella running

sudo yum install pyepics

Pip and ipython did not seem to be installed yet.

  12828   Tue Feb 14 10:43:06 2017 gautamBureaucracyEquipment loanEquipment to Cryo Lab

PZT Buzzer Box (Thorlabs HV Supply + Manual + 2*PZT Buzzers) ---> Cryo Lab (Brittany + Aaron)

  9660   Fri Feb 21 12:45:57 2014 ericqUpdateLSCEquivalent Displacement Noise from QPD Dark Noise in SQRTINV

EQ UPDATE: Measured it wrong the first time, fixed now.

I measured the spectra of the SQRTINV channels from dark QPDs, with offsets adjusted to imitate various transmission levels. (While the dark noise stays constant in terms of, say, TRX counts, 1/sqrt(TRX) isn't linear, and so the noise coupling depends on the TRX offset). 

SQRTINVspectra.pdf

I did some calculations to turn this into the equivalent displacement noise when using SQRTINV as an error signal. This depends on where on the fringe you are locking, since the slope of SQRTINV vs. position is not constant, and can only really be treated as linear down to about 1/3 of a line width away from full resonance. In my calculations, I assumed a coupled arm line width of 38pm, and a full transmission of 700 counts in TRX/Y. 

The QPD dark noise RMS when two line widths away (TR = 40) is about 5fm, and only goes down from there. 

SQRTINV_DarkNoise.pdf

  9693   Wed Mar 5 18:04:36 2014 ericqUpdateLSCEquivalent Displacement Noise from QPD Dark Noise in SQRTINV

At today's meeting, it was suspected that these noise levels were far too low. (ELOG 9660)

I've attached the math I did to get the conversions, as well as the dark noise SQRTINV spectra at various imitated transmission values and the python script that does the converting. 

I've gone over my calculations, and think they're self-consistent. However, a potential source of misestimation is the treatment of the Lorentzian profile simply existing with the coupled arm line width (38pm). The conversion to m/rtHz is directly proportional to the line width of the transmission peak, so if it is much broader in practice (because of imperfect PRC buildup or something), the noise will be that much worse.

I'm open to any other feedback about what I may have done wrong!

 

  11525   Mon Aug 24 14:05:47 2015 ericqUpdateSUSEricG Investigating L2A

This afternoon, I showed Eric Gustafson some of the basics of making swept sine measurements with DTT. We turned off the f2a filters and oplev damping on the BS and made a cursory measurement of the transfer function from position drive to the oplev signals. 

He will be in the lab periodically to continue this line of investigations. 

  15178   Thu Jan 30 17:31:28 2020 JonUpdatePSLErrant FSS_INOFFSET change

A script I was testing errantly set C1:PSL-FSS_INOFFSET => 10 V at about 5:30 pm. I manually reverted the channel value to 0, but I don't know what the value was initially. Someone please check this value if there are problems locking the FSS.

  15179   Thu Jan 30 17:41:10 2020 gautamUpdatePSLErrant FSS_INOFFSET change

You can trend the data for the past few hours and see what the appropriate value. I think these tests should only be done when whoever is running a test is in the lab.

P.S. I was surprised that the IMC didn't lose lock when this step was applied. I manually stepped this voltage between +/- 10 V and didn't see any response in the FSS readbacks. Either the channel doesn't work, or there is a divide by 40 in the physical circuit or something...

Quote:

A script I was testing errantly set C1:PSL-FSS_INOFFSET => 10 V at about 5:30 pm. I manually reverted the channel value to 0, but I don't know what the value was initially. Someone please check this value if there are problems locking the FSS.

  1175   Thu Dec 4 16:29:20 2008 josephbConfigurationComputersError message on Frame Builder Raid Array
The Fibrenetix FX-606-U4 RAID connected to the frame builder in 1Y7 is showing the following error message: IDE Channel #4 Error Reading
  17010   Mon Jul 18 04:42:54 2022 AnchalUpdateCalibrationError propagation to astrophysical parameters from detector calibration uncertainty

We can calculate how much detector calibration uncertainty affects the estimation of astrophysical parameters using the following method:

Let \overrightarrow{\Theta} be set of astrophysical parameters (like component masses, distance etc), \overrightarrow{\Lambda}be set of detector parameters (like detector pole, gain or simply transfer function vaue for each frequency bin). If true GW waveform is given by h(f; \overrightarrow{\Theta}), and the detector transfer function is given by \mathcal{R}(f; \overrightarrow{\Lambda}), then the detected gravitational waveform becomes:
g(f; \Theta, \Lambda) = \frac{\mathcal{R}(f; \overrightarrow{\Lambda_t})}{\mathcal{R}(f; \overrightarrow{\Lambda})} h(f; \overrightarrow{\Theta})

One can calculate a derivative of waveform with respect to the different parameters and calculate Fisher matrix as (see correction in 40m/17017):

\Gamma_{ij} = \left( \frac{\partial g}{\partial \mu_i} | \frac{\partial g}{\partial \mu_j}\right )

where the bracket denotes iner product defined as:

\left( k_1 | k_2 \right) = 4 Re \left( \int df \frac{k_1(f)^* k_2(f))}{S_{det}(f)}\right)

where S_{det}(f) is strain noise PSD of the detector.

With the gamma matrix in hand, the error propagation from detector parameter fractional errors \frac{\Delta \Lambda_j}{\Lambda_j}to astrophysical paramter fractional errors \frac{\Delta \Theta_i}{\Theta_i}is given by (eq 26 in Evan et al 2019 Class. Quantum Grav. 36 205006):

\frac{\Delta \Theta_j}{\Theta_j} = - \mathbf{H}^{-1} \mathbf{M} \frac{\Delta \Lambda_j}{\Lambda_j}

where \mathbf{H}_{ij} = \left( \frac{\partial g}{\partial \Theta_i} | \frac{\partial g}{\partial \Theta_j}\right ) and \mathbf{M}_{ij} = \left( \frac{\partial g}{\partial \Lambda_i} | \frac{\partial g}{\partial \Theta_j}\right ).


Using the above mentioned formalism, I looked into two ways of calculating error propagation from detector calibration error to astrophysical paramter estimations:

Using detector response function model:

If we assume detector response function as a simple DC gain (4.2 W/nm) and one pole (500 Hz) transfer function, we can plot conversion of pole frequency error into astrophysical parameter errors. I took two cases:

  • Binary Neutron Star merger with star masses of 1.3 and 1.35 solar masses at 100 Mpc distance with a \tilde{\Lambda} of 500. (Attachment 1)
  • Binary black hole merger with black masses of 35 and 30 at 400 MPc distance with spin along z direction of 0.5 and 0.8. (I do not fully understand the meaning of these spin components but a pycbc waveform generation model still lets me calculate the effect of detector errors) (Attachment 2)

The plots are plotted in both loglog and linear plots to show the order of magnitude effect and how the error propsagation slope is different for different parameters. 'm still not sure which way is the best to convey the information. The way to read this plot is for a given error say 4% in pole frequency determination, what is the expected error in component masses, merger distance etc. I

Note that the overall gain of detector response is not sensitive to astrophysical error estimation.

Using detector transfer function as frequency bin wise multi-parameter function

Alternatively, we can choose to not fit any model to the detector transfer function and simply use the errors in magnitude and phase at each frequency point as an independent parameter in the above formalism. This then lets us see what is the error propagation slope for each frequency point. The hope is to identify which parts of the calibration function are more important to calibrate with low uncertainty to have the least effect on astrophysical parameter estimation. Attachment 3 and 4 show these plots for BNS and BBH cases mentioned above. The top panel is the error propagation slope at each frequency due to error in magnitude of the detector transfer function at that frequency and the bottom panel is the error propagation slope at each frequency due to error in phase of the detector transfer function.

The calibration error in magnitude and phase as a function of frequency would be multiplied by the curves and summed together, to get total uncertainty in each parameter estimation.


This is my first attempt at this problem, so I expect to have made some mistakes. Please let me know if you can point out any. Like, do the order of magnitude and shape of error propagation makes sense? Also, comments/suggestions on the inference of these plots would be helpful.

Finally, I haven't yet tried seeing how these curves change for different true values of the merger event parameters. I'm not yet sure what is the best way to extract some general information for a variety of merger parameters.

Future goals are to utilize this information in informing system identification method i.e. multicolor calibration scheme parameters like calibration line frequencies and strength.

Code location

  17011   Mon Jul 18 15:17:51 2022 HangUpdateCalibrationError propagation to astrophysical parameters from detector calibration uncertainty

1. In the error propogation equation, it should be \Delta \Theta = -H^{-1} M \Delta \Lambda, instead of the fractional error. 

2. For the astro parameters, in general you would need t_c for the time of coalescence and \phi_c for the phase. See, e.g., https://ui.adsabs.harvard.edu/abs/1994PhRvD..49.2658C/abstract.

3. Fig. 1 looks very nice to me, yet I don't understand Fig. 3... Why would phase or amplitude uncertainties at 30 Hz affect the tidal deformability? The tide should be visible only > 500 Hz. 

4. For BBH, we don't measure individual spin well but only their mass-weighted sum, \chi_eff = (m_1*a_1 + m_2*a_2)/(m_1 + m_2). If you treat S1z and S2z as free parameters, your matrix is likely degenerate. Might want to double-check. Also, for a BBH, you don't need to extend the signal much higher than \omega ~ 0.4/M_tot ~ 10^4 Hz * (Ms/M_tot). So if the total mass is ~ 100 Ms, then the highest frequency should be ~ 100 Hz. Above this number there is no signal. 

 

  17017   Tue Jul 19 07:34:46 2022 AnchalUpdateCalibrationError propagation to astrophysical parameters from detector calibration uncertainty

Addressing the comments as numbered:

  1. Yeah, that's correct, that equation normally \Delta \Theta = -\mathbf{H}^{-1} \mathbf{M} \Delta \Lambda but it is different if I define \Gamma bit differently that I did in the code, correct my definition of \Gamma to :
    \Gamma_{ij} = \mu_i \mu_j \left( \frac{\partial g}{\partial \mu_i} | \frac{\partial g}{\partial \mu_j} \right )
    then the relation between fractional errors of detector parameter and astrophysical parameters is:
    \frac{\Delta \Theta}{\Theta} = - \mathbf{H}^{-1} \mathbf{M} \frac{\Delta \Lambda}{\Lambda}
    I prefer this as the relation between fractional errors is a dimensionless way to see it.
  2. Thanks for pointing this out. I didn't see these parameters used anywhere in the examples (in fact there is no t_c in documentation even though it works). Using these did not affect the shape of error propagation slope function vs frequency but reduced the slope for chirped Mass M_c by a couple of order of magnitudes.
    1. I used the get_t_merger(f_gw, M1, M2) function from Hang's work to calculate t_c by assuming f_{gw} must be the lowest frequency that comes within the detection band during inspiral. This function is:
      t_c = \frac{5}{256 \pi^{8/3}} \left(\frac{c^3}{G M_c}\right)^{5/3} f_{gw}^{-8/3}
      For my calculations, I've taken f_{gw} as 20 Hz.
    2. I used the get_f_gw_2(f_gw_1, M1, M2, t) function from Hang's work to calculate the evolution of the frequency of the IMR defined as:
      f_{gw}(t) = \left( f_{gw0}^{-8/3} - \frac{768}{15} \pi^{8/3} \left(\frac{G M_c}{c^3}\right)^{5/3} t \right)^{-3/8}
      where f_{gw0} is the frequency at t=0. I integrated this frequency evolution for t_c time to get the coalescence phase phi_c as:
      \phi_c = \int^{t_c}_0 2 \pi f_{gw}(t) dt
  3. In Fig 1, which representation makes more sense, loglog of linear axis plot? Regarding the affect of uncertainties on Tidal amplitude below 500 Hz, I agree that I was also expecting more contribution from higher frequencies. I did find one bug in my code that I corrected but it did not affect this point. Maybe the SNR of chosen BNS parameters (which is ~28) is too low for tidal information to come reliably anyways and the curve is just an inverse of the strain noise PSD, that is all the information is dumped below statistical noise. Maybe someone else can also take a look at get_fisher2() function that I wrote to do this calculation.
  4. Now, I have made BBH parameters such that the spin of the two black holes would be assumed the same along z. You were right, the gamma matrix was degenerate before. To your second point, I think the curve also shows that above ~200 Hz, there is not much contribution to the uncertainty of any parameter, and it rolls-off very steeply. I've reduced the yspan of the plot to see the details of the curve in the relevant region.
Quote:

1. In the error propogation equation, it should be \Delta \Theta = -H^{-1} M \Delta \Lambda, instead of the fractional error. 

2. For the astro parameters, in general you would need t_c for the time of coalescence and \phi_c for the phase. See, e.g., https://ui.adsabs.harvard.edu/abs/1994PhRvD..49.2658C/abstract.

3. Fig. 1 looks very nice to me, yet I don't understand Fig. 3... Why would phase or amplitude uncertainties at 30 Hz affect the tidal deformability? The tide should be visible only > 500 Hz.

4. For BBH, we don't measure individual spin well but only their mass-weighted sum, \chi_eff = (m_1*a_1 + m_2*a_2)/(m_1 + m_2). If you treat S1z and S2z as free parameters, your matrix is likely degenerate. Might want to double-check. Also, for a BBH, you don't need to extend the signal much higher than \omega ~ 0.4/M_tot ~ 10^4 Hz * (Ms/M_tot). So if the total mass is ~ 100 Ms, then the highest frequency should be ~ 100 Hz. Above this number there is no signal.

 

  17029   Sun Jul 24 08:56:01 2022 HangUpdateCalibrationError propagation to astrophysical parameters from detector calibration uncertainty

Sorry I forgot to put tc & phic in the example. 

I modified astroFisherLib.py to include these parameters. Please note that their meaning is that we don't know when the signal happens and at which phase it merges.

It does not mean the time & phase from a reference frequency to the merger. This part is not free to vary because it is fixed by the intrinsic parameters.  

It might be good to have a quick scan through the Cutler & Flanagan 94 paper to better understand their physical meanings.

 

  11119   Sun Mar 8 03:27:48 2015 JenneUpdateLSCError signal blending for CARM/DARM transitions

This elog will be about work that happened yesterday.  I will write a reply to this with work from this evening's success.


[Rana, Jenne]

Work started with the plan of trying ALS fool, using the new triggering scheme (elog 11114).

The PRMI was having a bit of trouble holding lock with REFL165, so we checked its demod phase.  On Monday (elog 11095) we rotated the REFL165 phase from -91 deg to -48 deg while in PRFPMI configuration (I think the -91 was from PRMI-only phase setting).  However, Friday night we saw that MICH was super noisy, especially when the CARM and DARM offsets were near zero.  Rana rotated REFL165's phase until the MICH noise seemed to get lower (by at least an order of magnitude in the control signal), while we were at zero offset everywhere. We were not driving and looking at any lines/peaks, just the overall spectra.  The final REFL165 demod phase is -80. 

We tried engaging the fool path with no success. 

First, Rana moved the low frequency boost in the MC filter bank from 20:1 to 0.3:0.03.  This gave the whole loop at least 20 or 30 degrees of phase at all frequencies below the design UGF (a few hundred Hz?  Don't quite remember).  To check this, we put in a "plant" filter, and turned on the locking filter (3:3000^2) and the low freq boost and the plant, and the phase never touched 180 at any low freq.  This is so that we can ramp on this filter bank's gain without having an unstable unity gain crossing anywhere.  Also, I added two +10dB filters to the first two filter modules, so that we could ramp on the gain at the input rather than the output.

Last night we were actuating CARM on MC2 and DARM on the ETMs, and the MC filter bank was set to actuate on MC2.  Even with super duper low gain in the MC filter bank, so that the control signal was much less than one (1) count, it would make CARM unhappy.  The CARM filter bank's output was doing +/- a hundred or more counts, so why a few tenths of a count mattered, we couldn't figure out.  We were using the power trigger for the MC filter bank, but not the zero-crossing trigger.  Since the fool tuning was checked while actuating on the ETMs, we wonder if maybe the tuning isn't valid for MC2 actuation?  Maybe there's enough of a difference between them that the fool needs to be re-tuned for MC2 actuation?  Fool had the complex pair of poles at 1Hz, the "comp1" filter to give phase lag, and a gain of 22. 

I think that at some point we even turned off the fool path, but left the MC path on with a little bit of gain, and the audible noise over the speakers didn't seem to change in character at all. Weird. 


We ended up leaving the fool path for another time, and started working on error signal blending at the CARM filter bank input.  This is pretty similar to Kiwamu's self-locking principle.

Our goal was to ramp up the gain of the RF error signal at low frequency, while letting ALS keep hold of things at higher frequencies. 

CARM and DARM sweeps from earlier seemed to indicate that the RF signals are valid without normalization above transmitted powers of 50 or so, so we thought we'd give those a whirl for this error signal blending.

From doing a CARM sweep through resonance, we guessed roughly that the REFL11 (non-normalized) slope was about a factor of 10,000 larger than the ALS slope.  We put a 1e-4 into the input matrix element REFL11I -> CARM_B.  For some reason, REFL11 seemed to be centered around -250 counts, so we put an offset of +0.025 ( = 250*1e-4) into the CARM_B filter module to compensate for this. 

Since we thought that a gain of 1 in the CARM_B filter bank would make it equal to ALS, we tried some lower gains to start with.  0.3 kicked it out of lock, so we ended up liking and using 0.15.  With this low gain on, we tried turning on a low frequency boost, 20:1, but that didn't do very much.  We turned that off, and instead turned on an integrator, 20:0, which totally made things better.  The transmitted arm power was staying higher more of the time.

From a DARM sweep, we thought that AS55Q (non-normalized) should also have an input matrix element of 1e-4 for DARM.  We gave DARM_B a gain of 0.1, which seemed good and not too high.  Again, trying the gentle boost didn't do much, so we went with the integrator. 

At this point, since both RF signals were being used as error signals with integrators, we declared that at least at DC we were on RF signals.  Hooray!! 

After this, we started increasing the CARM_B gain a little, and decreasing the CARM_A gain.  When Rana finally set the CARM_A element to zero, we lost lock.  We realized that this is because we didn't include a zero to compensate for the arm cavity pole, which the IR signal will see, but the ALS won't. 

We decided that the plan of attack would be to get back to where we were (DC error signals on RF), and try to start engaging the AO path. 

 

  11120   Sun Mar 8 04:04:19 2015 JenneUpdateLSCError signal blending for CARM/DARM transitions

As I (very excitedly) reported in elog 11116, I was able to follow the error signal blending procedure from last night, and get CARM and DARM onto digital non-normalized RF signals.  The lock held for about 3 minutes after this transition (elog 11118 has plot of this). yes

I was then able to script what I did (in the carm_up script), and repeat the transitionyes. Q joined me in the control room, but we have not been able to complete the transition a third timeno.

Here's the sequence that worked the two times:

  • Go to zero CARM and DARM offsets 
    • CARM is locked on ALS comm through the CARM_A filter bank (CARM_A gain = 1)
    • DARM is locked on ALS diff through the DARM_A filter bank (DARM_A gain = 1)
  • Lower CARM servo gain to 5 (from 7)
  • Lower DARM servo gain to 5 (from 7)
  • Lower PRCL servo gain to -0.03 (from -0.04)
  • Lower MICH servo gain to 2.5 (from 3.0)
  • Set up _B error signals
    • CARM_B has 1e-4*REFL11I, no normalization
    • DARM_B has -1e-4*AS55Q, no normalization
  • Give CARM_B a gain of 0.15
  • Turn on CARM_B FM7 (integrator)
  • Give DARM_B a gain of 0.1
  • Turn on DARM_B FM7 (integrator)
  • Slowly increase CARM_B gain, lowering CARM_A gain when gain peaking happens
    • CARM_B to 0.3, sleep 2
    • CARM_B to 0.5, sleep 2
    • CARM_A to 0.8, sleep 2
    • CARM_B to 0.6, sleep 2
    • CARM_A to 0.6, sleep 2
    • CARM_B to 0.7, sleep 2
    • CARM_A to 0.4, sleep 2
    • CARM_A to 0.2, sleep 2
    • CARM_B to 0.8, sleep 2
    • CARM_A to 0
  • Slowly increase DARM_B gain, lowering DARM_A gain when gain peaking happens
    • DARM_B to 0.2, sleep 2
    • DARM_A to 0.8, sleep 2
    • DARM_B to 0.3, sleep 2
    • DARM_A to 0.6, sleep 2
    • DARM_B to 0.4, sleep 2
    • DARM_A to 0.4, sleep 2
    • DARM_B to 0.5, sleep 2
    • DARM_A to 0
  • This is where I started working on the ETMX alignment to improve dark port contrast.  DARM kept having gain peaking, so I was lowering the DARM servo gain as I worked on the ETMX alignment.  I didn't make note of what the final gain was when I lost lock, but whatever it was, it wasn't right.

After those two attempts, we ran the LSC offset script, since that hadn't been done since early yesterday.  We did a quick CARM sweep, and REFL11 seemed to be centered around 0 counts, so we removed the 0.025 count offset from the CARM_B filter bank.

For later attempts, we keep seeing oscillations in the lockloss plots around 50 Hz, as if we're seeing gain peaking at the low side of the phase bubble.  We have tried turning off various filters at various levels of RF gain, but none of the combinations seems to be excellent.  Turning off the FM6 bounce/roll filter in CARM was particularly bad (immediately lost arm transmitted power), but others weren't good either (eg turning off FM3 boost lost arm powers within a second or so).  When we lose arm powers, the RF signals aren't valid, so if you don't turn them off fast enough (and ALS is still on with enough gain), you'll lose the full IFO lock.  If you're fast though, you can turn off the CARM and DARM _B outputs and not have to start from scratch. 

There seemed to be a very fine line to walk between not enough gain (~50Hz oscillations), and too much gain (200-300Hz oscillations).  It has been pretty frustrating later in the evening.  We seem to only have about 3dB of gain margin on the low side, when all the boosts are on.  Not excellent. 

When the RF signals had a moderate amount of gain, but ALS was still holding CARM and DARM, Q checked the phases of REFL11 and AS55 with excitation lines.  He rotated AS55 from -55 deg to -30 deg (+25 deg) and REFL11 from 144 deg to 164 deg (+20 deg).


Prior to the all-digital attempts, I tried several times to turn on the AO path, without success.  I think that the best that I got was 0dB on the CM board input 1 gain, +14dB on the CM board's AO gain, and -30dB on the MC board's AO gain before the mode cleaner lost lock. 

I was hoping that I could get CARM entirely to RF signals, and that would make things more stable and less complicated, and I could try again to turn on the AO path, but we haven't been able to do this tonight.


A few times in the later attempts we tried turning on the UGF servos for CARM or DARM.  I'm not sure if the lines kicked things out of lock, or if the UGF servos went a little crazy, or what, but we never survived for more than a few seconds after turning on the excitations.


There is a problem with the optical lever servos.  I had thought I'd been seeing it ever since Q re-did the models, and now I'm pretty sure that's what's up.  Q is hot on the trail of figuring out what may have changed that shouldn't have.  We may want to revert to an old Foton file, and re-copy the old filters into the new filter banks just in case.  The watchdog damprestore scripts have been tweaked to clear the oplev filter bank histories before turning on the oplevs, and this seems to solve the symptom of kicking the optic when oplevs are engaged. 


Although we haven't been able to make the transition to RF-only a third time, I think we're getting there.  Progress has certainly been made in the last 2 days!

  11121   Sun Mar 8 13:51:41 2015 ranaUpdateLSCError signal blending for CARM/DARM transitions

According to the official rules, we only need 8 seconds to declare it "locked".

I wonder if the double cavity pole compensation filter for CARM was on for all the attempts yesterday? IF it looks like it will not saturate, it would be more stable to have the whitening on for REFL11 / AS55. Since on Friday, I set the REFL165 demod phase just by minimizing the MICH control signal with the arms on resonance, we ought to check out the PRMI degeneracy with the ETMs misaligned.

Speaking of signal mixing: Although we weren't able to get the carrier term cancelled in the 3*f1 signals by the relative mod phase method, I wonder if we can do it by mixing the 3*f1 and 3*f2 signals in the input matrix. Might help to keep the PRMI more stable, if that's an issue.


P.S. I have done some scripts directory / SVN cleanup. Adding some directories that were not in (like lockloss) and then removing stuff from the repo using 'svn rm --keep-local  filenames' for the image and data files.

  11122   Mon Mar 9 14:14:32 2015 JenneUpdateLSCError signal blending for CARM/DARM transitions

Here is a longer stretch of data, from the first RF-only lock on Saturday night.  Unfortunately daqd had died about 400 seconds before the lockloss, so I can't show the RF signals coming on.  

ALS was on the _A channels for CARM and DARM, so when those go to zero (about -300 seconds for CARM, and about -200 seconds for DARM), we're using RF signals only for the error signals.

CARM noise definitely improves, but holy smokes does DARM start to look good!  Although, right at the end it starts to look like REFL11I is getting bigger.  Not sure why, but we'll have to watch out for this.

 


Here's the equivalent plot for the second lock stretch. This is the one that was handled by the carm_up script. It looks like I had about 150 seconds of RF-only lock here. 

DARM error is getting bigger with time jnear the end, even though I wasn't working on alignment here.  Zooming in, DARM is oscillating at 16.4 Hz, which is the bounce frequency.  I thought I had my bounce/roll filters on, but somehow it still got a little rung up.  It just rings up to a steady state though, it's not getting huge, so I don't know that it was the cause of the lockloss.

 

  8401   Wed Apr 3 14:46:17 2013 GabrieleSummaryLSCError signal simulation in PRMI

Here is a summary of a simulation of the error signal behavior in the PRMI configuration. The main parameters are:
L_PRC = 6.7538 m
Schnup = 0.0342 m
fmod1 = 11.065399e6 Hz
fmod2 = 5 * fmod1

prmi_prclsweep_pop22.pngprmi_prclsweep_pop110.png

These two plots shows the response of the POP22 and POP110 signals (in almost arbitrary units) to a PRCL sweep around the resonance. The splitting of the 55 sideband peaks is well visible in the second plot. It is due to the fact that the 55MHz sidebands are not perfectly matched to the PRC length

prmi_michsweep_pop22.pngprmi_michsweep_pop110.png

The same thing when sweeping MICH. The peaks are wider and it is not possible to see the splitting.

prmi_prclsweep_errsig_not_tunedphase.pngprmi_michsweep_errsig_not_tunedphase.png

These are the error signals (REFL11_I/Q and REFL_55_I/Q) as a function of the PRCL (left) and MICH (right) sweep. Here the demodulation phases are not properly tuned. This is just to show that when the phase is wrong, you can get multiple zero crossings (in this case only in the Q signals, but in general also in I) close to resonance.

prmi_prclsweep_errsig_tunedphase.pngprmi_michsweep_errsig_tunedphase.png

If the phases are tuned in order to maximize the slope of the I signals with respect to PRCL, one gets these "optimized phase" responses. It is that the phase does not correspond to the one that makes the PRCL peak to peak signal small in Q. The Q signals are indeed flat around resonance for a PRCL motion, but they deviate quite a lot from zero when moving more far from resonance. Moreover, both the REFL_55 error signals (I for PRCL and Q for MICH) are crossing again zero at two additional positions, but those are quite far from the resonance point.

prmi_prclsweep_triggering.pngprmi_michsweep_triggering.png

These plots just show the PRCL and MICH error signals together with the POP22 and POP110 signals, to give an idea of the level of triggering that might be needed to be inside the linear range. It seems that if we trigger on POP22 when using the REFL55 signal we loose a bit of linear range, but not that much.

prmi_prclsweep_linearized_signals.pngprmi_michsweep_linearized_signals.png

If you reached this point it means you're really interested in this topic, or maybe you have nothing better to do... However, this plot shows the effect of linearization of the error signal, obtained dividing them by the proper POP22/110 signal. The linear range is increased, but unfortunately for the 55 signals, the additional zero crossing I was mentioning before creates two sharp features. Those are however quite outside the triggering region, so they should not be harmful.

  8537   Tue May 7 16:21:01 2013 JenneSummaryLSCError signal simulation in PRMI

I asked Gabriele why it looked like for the PRCL sweep REFL 55 I&Q were zero at zero, but for the MICH sweep only REFL55 I was zero.  He took a look at his code, and found that he was not at the correct locking point.  Here is his email back to me:

I found the reason for the not zero value. Indeed, if you could zoom into the PRCL sweep, you would see that the error signals does not cross zero exactly at PRCL=0, but instead some 50 pm away from zero. This is enough to change a lot the PRCL signal when sweeping MICH. If I put PRCL to the correct zero point, and I sweep MICH, I now get everything at zero. I'm sending again the plots.

The fact that such a small detuning is enough to change PRCL signal when sweeping MICH is due, I believe, to the fact that MICH optical gain is much smaller than PRCL one.

Here are the redone plots:

Phase not tuned:

michsweep_errsigs_phasenottuned.pngprclsweep_errsigs_phasenottuned.png

 

Phase tuned:

michsweep_errsigs_tunedphase.pngprclsweep_errsigs_tunedphase.png

POP22 resonance for MICH and PRCL:

michsweep_pop22.pngprclsweep_pop22.png

POP110 resonance for MICH and PRCL:

michsweep_pop110.pngprclsweep_pop110.png

  10887   Tue Jan 13 00:42:15 2015 JenneUpdateLSCError signals for MICH with variable finesse technique

In order to know where we should try to make the transition from REFL##Q to ASDC for MICH, I did a quick Optickle simulation to see what the error signals will look like.

The idea is to try to lock the PRMI on a single REFL diode (ex. REFL33 I&Q) with some MICH offset, and then transition over to ASDC.  As soon as we have completed the transition, we can engage the normalization matrix to normalize ASDC by POPDC, and also increase the MICH offset if we want.  Unfortunately, we do not as yet have the ability in our model to independently normalize different error signals, and then blend them, so we have to turn on the normalization after we've transitioned.

Here is the situation for PRMI-only:

You can see that REFL33Q has a slightly wider range than REFL165Q.  It seems like we can perhaps try to make the transition around -15nm or so.  Note that the error signals are not quite symmetric about 0nm, so we can use that to help determine what + and - mean.  We expect that we need to add about 1nm offset to REFL33Q to get a true minimum in ASDC, so the sign of the digital offset that we need will tell us if there is a sign flip or not between the digital offset and this x-axis. 

After we get this to work (hopefully in the next hour or so....), we will want to try the same thing with the arms held off resonance. 

Usually we lock the PRMI at an offset of about 3nm:

However we could do it lower, perhaps around 1nm (which is where we currently are doing our CARM/DARM ALS->IR signals transitions):

At some point, we will arrive at 0nm CARM offset, when we'll want to transition back to RF signals (although probably we could jump straight to a 1f signal, not plotted):

The moral of the story here is that I'm not sure how we were ever successfully locking MICH on REFL165Q, unless my phase-setting in Optickle is way off.  Certainly it looks like we should be sticking with REFL33 for PRFPMI.  Also, since we have an offset in REFL33Q anyway (which we have seen and have commented on before), at 3nm CARM offset it looks like we could try to just do the jump without any extra digital offset.  Here's a zoom of the 3nm situation:

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

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

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

So, we should:

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

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

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

   * Try using ALS CARM for frequency stabilization.

   * Hand off from ALS CARM and DARM to PSL.

* To do ALS-FPMI, we should:

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

     * Align green beams to the arms.

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

          * Lock the arm in green, align Beat PD. 

          * Push ETM, watch beat in the phase tracker.

          * Repeat for other arm.

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

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

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

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

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

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

  13023   Wed May 31 14:23:42 2017 jigyasaUpdateComputer Scripts / ProgramsEstablishing the EPICs channels for the GigE

To set up the EPICs channels for the GigE, Gautam and I followed the steps in the elog by him  8957 .

We copied the 11 required channels from scripts/GigE/SnapPy/example_camera.db to c1cam.db that we created, however due to conflicts with the existing CAM-AS_PORT channels, the channels could not be accessed.

We later changed the database file to Video.db and on restarting the slow machine, it was verified that the channels indeed could be written to and read from.

11 channels were added

C1: CAM-MC1_X (X centroid position)
C1: CAM-MC1_Y (Y centroid position)
C1: CAM-MC1_WX (Gaussian width in the X direction)
C1: CAM-MC1_WY (Gaussian width in the Y direction)
C1: CAM-MC1_XY (Gaussian width along XY line)
C1: CAM-MC1_SUM (Pixel sum)
C1: CAM-MC1_EXP (Exposure time in microseconds)
C1: CAM-MC1_SNAP (Control signal for taking snapshots)
C1: CAM-MC1_FILE(File name for image to saved to - time stamp automatically appended)
C1: CAM-MC1_RELOAD (Reloads configuration file)
C1: CAM-MC1_AUTO (1 means autoexposure on, 0 means autoexposure off)

The procedure followed –

  • Add the channel names to the file C0EDCU.ini (path = /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini).
  • Make a database (.db) file so that these channels are actually recorded (path = /cvs/cds/caltech/target/c1aux/Video.db).
  • Restarted the slow machine. FB
  • Verify that the channels indeed exist and can be read and written to using ezcaread and ezcawrite.

GV: Initially, I made a new directory called c1cam in /cvs/cds/caltech/target/ and made a .db file in there. However, the channels were not accessible after re-starting FB (attempting to read these channels threw up the "Channel does not exist" error). On digging a little further, I saw that there were already some "C1:CAM-AS_PORT" channels in C0EDCU.ini. The corresponding database records were defined inside /cvs/cds/caltech/target/c1aux/Video.db. So I just added the new records there. I also had to uncomment out the dummy channel in C0EDCU.ini to keep an even number of channels. Restarting FB still did not allow read/write access to the channels. Looking through the files in /cvs/cds/caltech/target/c1aux, I suspected that the epics database records are loaded when the machine is first booted up - so on a hunch I re-started c1aux by keying the crate, and this did the trick. The channels can now be read / written to (tested using Python cdsutils).

  9490   Wed Dec 18 17:28:50 2013 GabrieleSummaryLSCEstimate of the PRC length error

Measurement 

Looking back at what I did in april (see log #8411) I realized that it is possible to get an estimate of how much the PRC length is wrong looking at the splitting of the sideband resonant peak as visible in the POP_110_I signal. With the help of Jenne the PRMI was aligned and left swinging. The first plot shows a typical example of the peak splitting of 55MHz sidebands. This is much larger than what was observed in April.

When the sidebands resonate inside the PRC they get a differential dephasing given by 

dPhi = 4*pi*f_mod/c * dL

where dL is the cavity length error with respect to the one that makes the sidebands perfectly resonant when the arms are not there. This is not exactly the error we are interested in, since we should take into account the shift from anti-resonance of the SBs in the arm cavities.

Nevertheless, I can measure the splitting of the peak in units of the peaks full width at half maximum (FWHM). I did this fitting few peaks with the sum of two Airy peaks. Here is an example of the result

data_fit2.png

The average splitting is 1.8 times the FWHM. Knowing the PRC finesse, one can determine the length error:

dL = c / (4 * f_mod * Finesse) * (dPhi / FWHM)

Assuming a finesse of 60, I get a length error of 4 cm.

To get another estimate, we kicked the PRM in order to get some almost linear sweeps of the PRC length. Here is one of the best results:

data_kick.png

The distance between consecutive peaks is the free spectral range (FSR) of the PRC cavity. Again, I can measure the peak splitting in units of the FSR and determine the length error:

dL = c / (4 * f_mod) * (dPhi / FSR)

The result is again a length error of 4 cm.

Simulation

An error of 4 cm seems pretty big. Therefore I set up a quick simulation with MIST to check if this makes sense. Indeed, if I simulate a PRMI with the 40m parameters and move the PRC length from the optimal one, I get the following result for POP_110_I, which is consistent with the measurement.

pop110_vs_dL.png

 

 Therefore, we can quite confidently assume that the PRC is off by 4 cm with respect to the position that would make the 55 MHz sideband resonant without arms. Unfortunately, it is not possible with this technique to infere the direction of the error.

 

 

 

 

 

 

  9493   Thu Dec 19 12:51:57 2013 JenneSummaryLSCEstimate of the sign of the PRC length error

My hunch is that the PRC is SHORT by a few cm, not long. 

In my Optickle simulation, the sidebands are not perfectly co-resonating in the PRMI when the arms are not locked.  See Fig 1, which is the fields in the PRMI using the design PRC length.  If I add 5cm to the PRC length, I get Fig 2, where the peaks are about the same separation, but the upper and lower sidebands have swapped sides of the 0 mark.  However, if I remove 5cm from the PRC length, I get Fig 3, where the peaks are much farther apart than in Fig 1.  This case looks more similar to the data that Gabriele plotted in his elog entry, where the peaks are separated by at least a linewidth.  This is not at all conclusive, but it's a guess for which direction we need to move.  Obviously doing an actual measurement will be better. 

My tummy feelings also agree with this simulation:  When we flipped PR3 (the only optic change in the PRC since Gabriele and I measured the 55MHz peak separation in April), since the HR side of the optic is now at the back, we had to push the whole suspension cage forward to get the beam aligned to the Yarm.  Conversely, however, transmitting through the glass substrate adds to the optical path length.  So, my tummy feelings may be wrong.

Figure 1, PRC at design length, PRMI sweep:

DesignLength.png

Figure 2, PRC 5cm longer than design length:

Plus5cm.png

Figure 3, PRC 5cm shorter than design length:

Minus5cm.png

 

  9495   Thu Dec 19 18:33:25 2013 GabrieleSummaryLSCEstimate of the sign of the PRC length error

Maybe I'm getting confused, but I still believe there is no way to decide the direction from yesterday's measurement.

Let's say for example that the arm sideband detuning from antiresonance is equivalent to a PRC length change of +1cm away from the position of ideal resonance of the sidebands without arms. Then we can get a measured separation of the sidebands, without arms, corresponding to 5cm both if the PRC is off by +4cm or by -6cm...

  10706   Wed Nov 12 22:22:11 2014 KojiSummaryIOOEstimation of the angular jitter imposed by the TTs

[Koji, Rana, Jenne]

One coil of the TT produce 36nrad/rtHz at DC.

- C1:IOO-TT2_UL_EXC was excited with 5 count_pk at 0.04Hz.

- LSC_TRY exhibited the symmetric reduction of the transmission from 0.95 to 0.90.

1 - (theta/theta0)^2 /2 = 0.90 / 0.95

=> theta / theta0 = 0.32

- 40m beam waist radius is 3.1mm. This means the divergence angle is 1.1e-4 rad.

=> 1.1e-4*0.32 = 3.6e-5 rad

=> 3.6e-5/5 = 7.2 urad/count (per coil)

- DAC noise 1/sqrt(12 fs), where fs is the sampling rate (fs = 16384)

=> 0.002 cnt/rtHz

- One coil causes 7.2u*0.002 = 14 nrad/rtHz (at DC)

- One suspension cause 29 nrad/rtHz (at DC)

  444   Thu Apr 24 22:06:47 2008 AndreySummaryComputersEthernet Cables and Hubs
Today in the morning (between 8.30AM and noon) Joe and I were working on understanding which ethernet cables connect "processors controlling the work of equipment in the interferometer room" and "Internet hub in the computer room".

Firstly, we took off several times the blue ethernet cables from the router located near ETMX in the morning. We were trying to understand which port in the hub is responsible for the interaction with that processor.

Secondly, we were working on reviving the connection with the computer controlling vacuum in the interferometer.

Later in the middle of the day (around 2PM) Joe continued some work with ethernet cables without me. We plan on continuing the cable work on Friday morning. A better and more detailed elog will appear then.
  7691   Thu Nov 8 22:04:43 2012 CharlesUpdateElectronicsEthernet Illuminator Control

Configured ethernet controlled power strips to have static IP addresses: 192.168.113.110, 192.168.113.111 and 192.168.113.112.

Wrote a python script to interact with the power strips that can turn individual sockets on or off via telnet.

This functionality will be implemented on the control room computer GUIs in short order.

  7698   Mon Nov 12 23:38:50 2012 CharlesUpdateElectronicsEthernet Illuminator Control

Quote:

Configured ethernet controlled power strips to have static IP addresses: 192.168.113.110, 192.168.113.111 and 192.168.113.112.

Wrote a python script to interact with the power strips that can turn individual sockets on or off via telnet.

This functionality will be implemented on the control room computer GUIs in short order.

 The ethernet power strips have been installed. 192.168.113.110 is on ETMX, 192.168.113.111 is on ETMY and 192.168.113.112 is on the vertex. I have also written an EPICS file "illuminator_control.adl" (currently stored in my named directory) that allows a user to turn individual sockets on and off at each of the three locations. Some short tests have indicated that everything is in working order.

Currently, no illuminators are hooked up to the power strips. However, the power control will most likely be ready for use tomorrow, granted I can find and use extension cords so that the illuminators might reach their respective power strips.

  7701   Tue Nov 13 00:27:50 2012 JenneUpdateElectronicsEthernet Illuminator Control

Quote:

 

 The ethernet power strips have been installed. 192.168.113.110 is on ETMX, 192.168.113.111 is on ETMY and 192.168.113.112 is on the vertex. I have also written an EPICS file "illuminator_control.adl" (currently stored in my named directory) that allows a user to turn individual sockets on and off at each of the three locations. Some short tests have indicated that everything is in working order.

Currently, no illuminators are hooked up to the power strips. However, the power control will most likely be ready for use tomorrow, granted I can find and use extension cords so that the illuminators might reach their respective power strips.

 I'm sure Charles meant to also say that he connected the ETM power strips to the ethernet switches in those racks.  For the vertex, the ethernet switch is in 1X2, but there isn't space in there, so the power switch was installed in 1Y2.  The vertex ethernet cable is along the overhead inside cable tray.

I'm not sure what we want to do about connecting the new power strips to the illuminators.  No illuminator is close enough that its built-in cable can reach the power strip, so we'll need extension cables or some such.  Charles is going to ask Steve about the plan tomorrow.

  14414   Wed Jan 23 18:11:56 2019 gautamUpdateElectronicsEthernet Power Strip IP conflict

For the last week, I noticed that I was unable to turn the EY chamber illuminator on using the remote python scripts. This was turning out to be really annoying, having to turn the light on/off manually. Today, I looked into the problem and found that there is a conflict in the IP addresses of the EY Ethernet Strip (which Chas assigned a static IP but did not include detailed procedures forno) and the vertex area laptop, paola. The failure of the python control of the power strip coincided exactly with when Chub and I turned on paola for working at the IY chamber - but how was I supposed to know these events are correlated? I tried shutting down paola , power cycling the Ethernet power strip, and restarting the bind9 services on chiara, but remote control of the ethernet power strip remains elusive. I suspect reconfiguring the static IP for the Ethernet switch will require some serial port enabled device...

  14418   Fri Jan 25 12:49:53 2019 gautamUpdateElectronicsEthernet Power Strip IP conflict resolved

To avoid the annoying excercise of having to manually toggle the illuminators, I solved the IP conflict. Made a wiki page for the ethernet power strips since the documentation was woeful (the way the power strips are mounted in the racks, you can't even see the manufacturer/model/make). All chamber illuminators can now be turned on/off by the MEDM scripts yes. Note that there is a web interface available too, which can be useful in case of some python socket issues. The main lesson is: avoid using the "reset" button on the power strips, it destroys the static IP config.


Unrelated to this work: The EY laptop, asia, won't boot up anymore, with a "Fan Error" message being the red flag. I've temporarily recommissioned the vacuum rack laptop, belladonna, to be the EY machine for this vent. Can we get 3 netbooks that actually work and don't need to be tethered to a power strip for the VEA?

ELOG V3.1.3-