40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 61 of 335  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  12407   Sat Aug 13 18:25:22 2016 gautamUpdateCOCRC folding mirrors - Numerical review

This elog is meant to summarize my numerical simulations for looking into the effects of curvature on the RC mirrors. I've tried to go through my reasoning (which may or may not be correct) and once this gets a bit more refined, I will put all of this into a technical note.


Motivation: 

  • Both the G&H (PR2, SR2) and Laseroptik (PR3 SR3) are convex on the HR side with RoCs of approximately -600m and -700m (though as stated in the linked elog, I'm not actually sure if there are measurements of this number) EDIT AUG15: There are measurements for the Laseroptik mirrors here
    GV April 8 2017: This elog by Jenne suggests that the installed PR2 has an RoC of approximately -700m. Koji has uploaded the phase map data for the RC TT mirrors to
    /users/public_html/40m_phasemap/40m_TT and 
    /users/public_html/40m_phasemap/40m_TT2. The G&H mirror data seems to be in the former folder, and it looks like there are two mirrors, one with RoC of ~ -700m and the other with RoC of ~ -500m. Does this mean PR2 has RoC -700m and SR2 has RoC -500m?
  • As a result, both the PRC and SRC were close to instability
  • By flipping the folding mirrors, the instability has been mitigated, but at the expense of the non-ideal situation where the AR coated side and the substrate are now inside the recycling cavity
  • We would like to order some new folding mirrors. In order to avoid receiving convex mirrors from the vendor, we want to specify a concave curvature for the HR side
  • The aim of this investigation is to look at how concave we should make these mirrors, because although the cavity stability improves with concavity of the HR side, possible disadvantages of having too convex mirrors are:
    • ​Mode-mismatch between the recycling cavities and the arms
    • Astigmatism

The study:

  • I've built a Finesse model for the 40m, which has been used for all the numerical studies quoted here
  • In constructing this Finesse model, I've used the following sources to specify various paramaters:
    • ​RoCs, R, T and physical dimensions of 4 test-masses, PRM, SRM and BS: Core optics wiki page
    • Losses - arm losses from Yutaro's measurements in elog11857 and elog11818 (distributed equally between ITM and ETM). For other optics, a generic value of 25ppm was used
    • "Ideal" lengths for our current modulation frequency were used for the various cavities (37.795m for the arms, 6.753m for PRC, 5.399 for SRC)
    • The folding mirrors (PR2, PR3, SR2, SR3) are initialized as flat in the model
  • I performed some low-level checks (e.g. arm linewidth, PRC FSR etc) to check that the model was sensible
  • I then proceeded to investigate the effects of curvature on the folding mirrors. Specifically, I investigated the following:
    • What is the mode mismatch between the recycling cavity mode and the arm as a function of the RoC of the folding mirror?
    • What is the effect of the RoC of the folding mirrors on the round-trip gouy phase accumulated (and hence the transverse mode spacing) in the recycling cavities?
  • For now, the parameter space explored is from 300m concave to 1000m concave. An RoC of 1km for a 2" optic corresponds to a sag of ~0.3 microns. I will explore the 1km-10km concave space and update the results shortly

Results:

  • Attachments #1 and #2 show the mode mismatch between the recycling cavity and the arm for various curvatures. The colorbars have been normalized to span the same range in all the plots
  • For both the PRC and the SRC, if we have folding mirrors with an RoC of 1000m concave, we will have a mode mismatch of 2-3%. The number gets worse the more convex the mirror
  • Attachments #3 and #4 show the one-way accumulated Gouy phase. Here, I have varied the curvature of the folding mirrors along a specific axis at a time (i.e. I've assumed that the folding mirrors are identical). I've also added the transverse mode spacing as a second y-axis. I have yet to check how these numbers compare with the linewidth of the 00-mode for the various fields, but for 1km concave folding mirrors, the TMS is in the region of 2MHz 

To do:

  • I will extend the range of RoCs explored to 10km concave and post results - but I will have to check with EricG to make sure that it is feasible for us to specify curvatures in this range
  • I was trying to use the RT gouy phase as calcluated by my Finesse simulations to plug into some analytical expressions to try and generate plots like this for various RoCs of the folding mirrors, but if the TMS calculations suffice, I will abandon these efforts
  • What are the other specifications we need to worry about before placing an order? Some thoughts from Rana's earlier elog:
    • The coatings need to be dichroic to allow extraction of the green beam (but only PR3/SR3 is currently dichroic?)
    • Wedge angle on the AR side?
  • Are there any other obvious sanity checks I should carry out?

 

Attachment 1: PRX_consolidated.pdf
PRX_consolidated.pdf
Attachment 2: SRX_consolidated.pdf
SRX_consolidated.pdf
Attachment 3: Gouy_PRC.pdf
Gouy_PRC.pdf
Attachment 4: Gouy_SRC.pdf
Gouy_SRC.pdf
  12413   Tue Aug 16 11:51:43 2016 gautamUpdateCOCRC folding mirrors - Numerical review

Summary of roundtable meeting yesterday between EricG, EricQ, Koji and Gautam:

We identified two possible courses of action.

  1. Flip the G&H mirror (PR2/SR2) back such that the (convex) HR face is the right way round. We want to investigate what are the requirements on a new PR3/SR3 optic that will guarantee cavity stability and also give good mode matching.
  2. Order two new sets of mirrors (i.e. replace all 4 folding mirrors). In this case, we want to spec a flat (how flat is reasonable to specify? EricG will update us) PR3/SR3, and design a PR2/SR2 with some concavity that will guarantee cavity stability in the event PR3/SR3 deviates from flatness (but still within what we spec). The choice to make PR3 as close to flat as possible is because the angle of incidence in our arrangement means that any curvature on PR3 dominates astigmatism.

I have done some calculations to evaluate the first alternative. 

  • Based on yesterday's preliminary discussion, we felt it is not reasonable to spec mirrors with RoC > 4km (sag of ~80nm). So I restrict my analyses to the range 300m-4km
  • Koji has a measurement of the phase maps for the G&H mirrors. The measured curvature is ~-500m. In my simulations, I've tried to allow for error in this measurement, so I look at the range -450m to -700m for the G&H mirror.
  • The Gouy phase analysis suggests we should look for an RoC of +500m (concave) for the new PR3/SR3 to have a TMS of ~1.5 MHz. Anything flatter (but still concave) means the TMS gets smaller.
  • The mode-matching in this region also looks pretty good, between 98% and 99%
  • I will post results of the analysis for the second alternative here for comparison

Something else that came up in yesterdays meeting was if we should go in for 1" optics rather than 2", seeing as the beam spot is only ~3mm on these. It is not clear what (if any) advantages this will offer us (indeed, for the same RoC, the sag is smaller for a 1" optic than a 2").


Attachments:

Attachment #1: Mode-matching maps between PRX and Xarm cavities, PRY and Yarm cavities with some contours overlaid.  

Attachment #2: Mode-matching maps between SRX and Xarm cavities, SRY and Yarm cavities with some contours overlaid. 

Attachment #3: Gouy phase calculations for the PRC

Attachment #3: Gouy phase calculations for the SRC

 

Attachment 1: PRC_consolidated.pdf
PRC_consolidated.pdf
Attachment 2: SRC_consolidated.pdf
SRC_consolidated.pdf
Attachment 3: GouyPRC.pdf
GouyPRC.pdf
Attachment 4: GouySRC.pdf
GouySRC.pdf
  12414   Tue Aug 16 16:38:00 2016 gautamUpdateCOCRC folding mirrors - Numerical review

Here are the results for case 2: (flat PR3/SR3, for purpose of simulation, I've used a concave mirror with RoC in the range 5-15km, and concave PR2/SR2 - I've looked at the RoC range 300m-4km).

  • This is where we order two new sets of mirrors, one for use as PR2/SR2, and the other for use as PR3/SR3.
  • RoC of flat PR3/SR3 in simulation explored in the range 5km-15km (concave)
  • RoC of concave PR2/SR2 in simulation explored in the range 300m-4km (concave)

Attachment #1: Mode matching between PRC cavities and arm cavities with some contour plots

Attachment #2: Mode matching between SRC cavities and arm cavities with some contour plots

Attachment #3: Gouy phase and TMS for the PRC. I've plotted two sets of curves, one for a PR3 with RoC 5km, and the other for a PR3 with RoC 15km

Attachment #4: Gouy phase and TMS for the SRC. Two sets of curves plotted, as above.


Hopefully EricG will have some information with regards to what is practical to spec at tomorrow's meeting.


EDIT: Added 9pm, 16 Aug 2016

A useful number to have is the designed one-way Gouy phase and TMS for the various cavities. To calculate these, I assume flat folding mirrors, and that the PRM has an RoC of 115.5m, SRM has an RoC of 148m (numbers taken from the wiki). The results may be summarized as:

Cavity One-way Gouy phase [rad]           TMS [MHz]           
PRX 0.244 1.730
PRY 0.243 1.716
SRX 0.197 1.743
SRY 0.194 1.717

So, there are regions in parameter space for both options (i.e. keep current G&H mirrors, or order two new sets of folding mirrors) that get us close to the design numbers...

Attachment 1: PRC_consolidated.pdf
PRC_consolidated.pdf
Attachment 2: SRC_consolidated.pdf
SRC_consolidated.pdf
Attachment 3: GouyPRC.pdf
GouyPRC.pdf
Attachment 4: GouySRC.pdf
GouySRC.pdf
  12417   Wed Aug 17 14:37:36 2016 gautamUpdateCOCRC folding mirrors - Numerical review
Quote:

 

Cavity One-way Gouy phase [rad]           TMS [MHz]           
PRX 0.244 1.730
PRY 0.243 1.716
SRX 0.197 1.743
SRY 0.194 1.717

So, there are regions in parameter space for both options (i.e. keep current G&H mirrors, or order two new sets of folding mirrors) that get us close to the design numbers...

Keeping these design numbers in mind, here are a few possible scenarios. The "designed" TMS numbers from my previous elog are above for quick reference.

Case 1: Keep existing G&H mirror, flip it back the right way, and order new PR3/SR3. 

  • Spec PR3 to be concave with RoC 600 +/- 50m
  • This means the TMS in the PRC is in the range 1.4 MHz - 1.6 MHz [see this plot]
  • The mode matching efficiency for the PRC is > 98.5% [see this plot]
  • The TMS in the SRC is in the range 1.6 MHz - 1.8 MHz [see this plot]
  • Mode matching efficiency for SRC is > 98.5% [see this plot]
  • PRG between 34-38, depending on uncertainty in measurement of RoC of existing G&H mirror [see Attachment #1, added Nov 11 2016]

Case 2: Order two new sets of folding mirrors

  • Spec PR3/SR3 to be flat - for purposes of simulation, let's make it concave with RoC 10 +/- 5 km
  • Spec PR2/SR2 to be concave with RoC 1500 +/- 500m
  • The TMS in the PRC is between 1.7 MHz and 1.85 MHz [see this plot]
  • Mode matching efficiency is >98.5% in the PRC [see this plot]
  • TMS in the SRC is between 1.7 MHz and 2 MHz [see this plot]
  • Mode matching efficiency >99.0% in the SRC [see this plot]

At first glance, it looks like the tolerances are much larger for Case 2, but we also have to keep in mind that for such large RoCs in the km range, it may be impractical to specify as tight tolerances as in the 100s of metres range. So these are a set of numbers to keep in mind, that we can re-iterate once we hear back from vendors as to what they can do.

For consolidation purposes, here are the aLIGO requirements for the coatings on the RC folding mirrors: PR2, PR3, SR2, SR3

Attachment 1: PRG.pdf
PRG.pdf
  12418   Wed Aug 17 16:28:46 2016 KojiUpdateCOCRC folding mirrors - Numerical review

For the given range of the PR3/SR3 RoCs for both cases, all the resulting numbers such as TMSs/mode matching ratios look reasonable to me.

  12631   Mon Nov 21 15:34:24 2016 gautamUpdateCOCRC folding mirrors - updated specs

Following up on the discussion from last week's Wednesday meeting, two points were raised:

  1. How do we decide what number we want for the coating on the AR side for 532nm?
  2. Do we want to adjust T@1064nm on the HR side to extract a stronger POP beam?

With regards to the coating on the AR side, I've put in R<300ppm@1064nm and R<1000ppm@532nm on the AR side. On the HR side, we have T>97% @ 532nm (copied from the current PR3/SR3 spec), and T<50ppm @1064nm. What are the ghost beams we need to be worried about? 

  • Scattered light the AR side interfering with the main transmitted green beam possibly making our beat measurement noisier
    • With the above numbers, accounting for the fact that we ask for a 2 degree wedge on PR3, the first ghost beam from reflection on the AR side will have an angular separation from the main beam of ~7.6 degrees. So over the ~4m the green beam travels before reaching the PSL table, I think there is sufficient angular separation for us to catch this ghost and dump it. 
    • Moreover, the power in this first ghost beam will be ~30ppm relative to the main green beam. If we can get R<100ppm @532nm on the AR side, the number becomes 3ppm
  • Prompt reflection from the HR surface of PR3 scattering green light back into the arm cavity mode 
    • The current spec has T>97% @532nm. So 3% is promptly reflected at the HR side of PR3
    • I'm not sure how much of a problem this really will be - I couldn't find the reflectivities of PR2 and PRM @532nm (were these ever measured?)
    • In any case, if we can have T<50ppm @1064nm and R>99.9% @532nm, that would be better

So in conclusion, with the specs as they are now, I don't think the ALS noise performance is adversely affected. I have updated the spec to have the following numbers now.

HR side: T < 50ppm @1064nm, T>99.9% @532nm

AR side: R < 100ppm @1064nm and @532nm

 

As for the POP question, if we want to extract a stronger POP beam, we will have to relax the requirement on the transmission @1064nm on the HR side. But recall that the approach we are now considering is to replace only PR3, and flip PR2 back the right way around. Currently, POP is extracted at PR2, so if we want to stick with the idea of getting a new PR3 and extracting a stronger POP beam, there needs to be a major optical layout reshuffle in the BS/PRM chamber. Koji suggested that in the interest of keeping things moving along, we don't worry about POP for the time being...


Alternatively, if it turns out that the vendor can meet the specs for our second requirement (which requires 1.5% of lambda @632nm measurement precision to meet the 10+/-5km RoC tolerance on PR3), then we can ast for T<1000ppm @1064nm for the HR coating on PR2, and keep the coating specs on PR3 as above. 

 

Attached is a pdf with the specs updated to reflect all the above considerations...

Attachment 1: Recycling_Mirrors_Specs_Nov2016.pdf
Recycling_Mirrors_Specs_Nov2016.pdf Recycling_Mirrors_Specs_Nov2016.pdf Recycling_Mirrors_Specs_Nov2016.pdf
  12847   Thu Feb 23 10:59:53 2017 gautamUpdateCOCRC folding mirrors - coating optimization

I've now made a DCC page for the mirror specifications, all revisions should be reflected there.

Over the last couple of days, I've been playing around with Rana's coating optimization code to come up with a coating design that will work for us. The basic idea is a to use MATLAB's particle swarm constrained optimization tool to minimize an error function that is a composite of four penalties:

  1. Thermal noise - we use the proxy function from E0900068-v3 to do this
  2. Deviation from target T @1064nm, p-pol
  3. Deviation from target T @532nm, p and s-pol
  4. HR Surface field

On the AR side, I only considered 2 and 3. The weighting of these four components were set somewhat arbitrarily, but I seem to be able to get reasonable results so I am going with this for now. 

From my first pass at it, the numbers I've been able to get, for 19 layer pairs, are (along with some plots):

HR Side:

  • T = 50ppm, 1064nm p-pol
  • T = 99%, 532nm s and p-pol

       (in this picture, the substrate is to the right of layer 38)

AR Side:

  • R ~50ppm for 532nm, s and p-pol

   (substrate to the right of layer 38)

These numbers are already matching the specs we have on the DCC page currently. I am not sure how much better we can get the specs on the HR side keeping with 19 layer pairs... 

All of this data, plus the code used to generate them, is on the gitlab coatings page...

 

Attachment 1: PR3_R_170222_2006.pdf
PR3_R_170222_2006.pdf
Attachment 2: PR3_123_TOnoise_170222_2203.pdf
PR3_123_TOnoise_170222_2203.pdf
Attachment 3: PR3_123_Layers_170222_2203.pdf
PR3_123_Layers_170222_2203.pdf
Attachment 4: PR3AR_R_170222_2258.pdf
PR3AR_R_170222_2258.pdf
Attachment 5: PR3AR_123_Layers_170222_2258.pdf
PR3AR_123_Layers_170222_2258.pdf
  12887   Tue Mar 14 10:56:33 2017 gautamUpdateCOCRC folding mirrors - coating optimization

Rana suggested including some additional terms to the cost function to penalize high sensitivity to deviations in the layer thickness (L). So the list of terms contributing to the cost function now reads:

  1. Thermal noise - we use the proxy function from E0900068-v3 to do this
  2. Deviation from target T @1064nm, p-pol
  3. Deviation from target T @532nm, p and s-pol
  4. HR Surface field
  5. The ratio \frac{d\mathcal{T}/\mathcal{T}}{dL/L} with dL/L = 1%, evaluated at 1064nm p-pol and 532nm p and s-pol (only the latter two for the AR side)

I did not include other sensitivity terms, like sensitivity to the refractive index values for the low and high index materials (which are just taken from GWINC).

There is still some arbitrariness in how I chose to weight the relative contributions to the cost function, but after some playing around, I think I have a solution that I think will work. Here are the spectral reflectivity and layer thickness plots for the HR and AR sides respectively. 

HR side: for a 1% increase in the thickness of all layers, the transmission changes by 5% @ 1064nm p-pol and 0.5% @ 532nm s and p-pol

  

AR sidefor a 1% change in the thickness of all layers, the transmission changes by <0.5% @ 532nm s and p-pol

  (substrate to the right of layer 38)

I've also checked that we need 19 layer pairs to meet the spec requirements, running the code with fewer layer pairs leads to (in particular) large deviations from the target value of 50ppm @ 1064nm p-pol.

Do these look reasonable? 

 

Attachment 1: PR3_R_170313_1701.pdf
PR3_R_170313_1701.pdf
Attachment 2: PR3AR_123_Layers_170313_1701.pdf
PR3AR_123_Layers_170313_1701.pdf
Attachment 3: PR3AR_R_170313_1752.pdf
PR3AR_R_170313_1752.pdf
Attachment 4: PR3AR_123_Layers_170313_1752.pdf
PR3AR_123_Layers_170313_1752.pdf
  12936   Mon Apr 10 15:37:11 2017 gautamUpdateCOCRC folding mirrors - v3 of specs uploaded

Koji and I have been going over these calculations again before we send a list of revised requirements to Ramin. I've uploaded v3 of the specs to the DCC page. Here is a summary of important changes.

  1. Change in RoC specification - I condensed the mode-matching information previously in 8 plots into the following 2 plots. Between tangential and saggital planes, the harmonic mean was taken. Between X and Y cavities, the arithmetic mean was taken. Considering the information in the following plots, we decided to change the spec RoC from 600 +/- 50m to 1000 +/- 150m. The required sensitivity in sag measurement is similar to the previous case, so I think this should be feasible.

    Why this change? From the phase map information at  /users/public_html/40m_phasemap/40m_TTI gather that we have 2 G&H mirrors, one with curvature ~ -700m and the other with curvature ~ -500m. An elog search suggests that the installed PR2 has RoC ~ -700m, so this choice of RoC for PR3 should give us the best chance of achieving optimal modematching between the RCs and arms as per the plots below.

  2. Cavity stability checks - these plots confirm that the cavity remains stable for this choice of RoC on PR3...
      
  3. Coating design - I've been playing around with the code and my understanding of the situation is as follows. to really hit low AR of 10s of ppms, we need many dielectric layer pairs. But by adding more pairs, we essentially become more susceptible to errors in layer thickness etc, so that even though the code may tell us we can achieve R_AR(532nm) < 50ppm, the minima is pretty sharp so even small perturbations can lead to much higher R of the order of a few percent. On the HR side, we need a large number of layer pairs to achieve T_HR(1064nm)=50ppm. Anyways, the MC studies suggest that for the HR coating design, with 19 layer pairs, we can be fairly certain of T_HR(1064nm)<100ppm and R_HR(532nm)>97% for both polarizations, which seems reasonable. In order to make the R_HR(532nm) less susceptible to errors, we need to reduce the number of layer pairs, but then it becomes difficult to achieve the 50ppm T_HR(1064nm) requirement. Now, I tried using very few layer pairs on the AR side - the best result seems to be with 3 layer pairs, for which we get R_AR(532nm)<1% and T_AR(1064nm)>95%, both numbers seem reasonable to me. In the spectral reflectivity, we also see that the minima are much broader than with large number of layer pairs.

    First row below is for the HR side, second row is for the AR side. For the MC studies, I perturbed the layer thicknesses and refractive indices by 1%, and the angle of incidence by 5%.
        
       

If there are no objections, I would like to send this version of the specs to Ramin and get his feedback. Specifically, I have assumed values for the refractive indices of SiOand Ta2O5 from google, Garilynn tells me that we should get these values from Ramin. Then we can run the code again if necessary, but these MC studies already suggest this coating design is robust to small changes in assumed values of the parameters...

Attachment 1: PRC_modematch.pdf
PRC_modematch.pdf
Attachment 2: SRC_modematch.pdf
SRC_modematch.pdf
Attachment 3: TMS_PRC.pdf
TMS_PRC.pdf
Attachment 4: TMS_SRC.pdf
TMS_SRC.pdf
Attachment 5: PR3_HR_spectralRefl.pdf
PR3_HR_spectralRefl.pdf
Attachment 6: PR3_HR_MC_CDF_revised.pdf
PR3_HR_MC_CDF_revised.pdf
Attachment 7: PR3_AR_spectralRefl_new.pdf
PR3_AR_spectralRefl_new.pdf
Attachment 8: PR3_AR_MC_CDF_new.pdf
PR3_AR_MC_CDF_new.pdf
  13155   Mon Jul 31 23:39:02 2017 ranaUpdateCOCCavity Scan Simulation Code

Hiro Yamamoto has updated SIS (Static Interferometer Simulation) to allow us to do the MCMC based inference of the 40m arm cavity mirror maps. 

The latest version is in git.ligo.org: IFOsim/SIS/

In the examples directory I have put 3 files:

  1. mcmcCavityScans.m - runs many cavity scans using parfor and saves the data
  2. plotCavityScans.m - loads the .mat file with the data and plots it
  3. plotCavityScans.py - python file which also loads & plots, but nicer since python has a transparency option for the traces.

Attached is the plots and the data. The first attached plot is a low resolution one: 200 scans of 100 frequency points each. Second plot is 200 scans of 300 points each.

The run was done assuming perfect LIGO arm params with a random set of Zernike perturbations for each run. The amplitude of each Zernike was chosen from a Normal distribution with a standard deviation of 10 nm.

We need to come up with a better guess for the initial distribution from which to sample, and also to use the more smart sampling that one does using the MCMC Hammer.

Attachment 1: manyCavityScans-SIS.pdf
manyCavityScans-SIS.pdf
Attachment 2: manyCavityScans-SIS.pdf
manyCavityScans-SIS.pdf
Attachment 3: MonteCarlo_CavityScans.mat
  14148   Thu Aug 9 02:12:13 2018 gautamUpdateCOCSouth East or West?

Summary:

For operating the SRC in the "Signal-Recycled" tuning, the SRC macroscopic length needs to be ~4.04m (compared to the current value of ~5.399m), assuming we don't do anything fancy like change the modulation frequencies and not transmit through the IMC. We're putting together a notebook with all the calculations, but today I was thinking about what the signal extraction path should be, specifically which chamber the SRM should be in. Just noting down the thoughts I had here while they're fresh in my head, all this has to be fleshed out, maybe I'm making this out to be more of a problem than it actually is.

Details:

  • For the current modulation frequencies, if we want the reosnance conditions such that the f2 sideband is resonant in the SRC (but not f1, i.e. small Schnupp asymmetry regime) while the carrier is resonant in the arms (required for good sensing of the SRC length), the macroscopic length of the SRC needs to be changed to ~4.04m.
  • Practically, this means that the folded SRC would only have one folding mirror (SR2).
  • There is a shorter SRC length of ~1.something metres which would work, but that would involve changing the relative position between ITMs and BS (currently ~2.3m) so I reject that option for now.
  • So the SR2 would be roughly where it is right now, ~20cm from the BS.
  • The question then becomes, where do we direct the reflection from the SR2? We need an optical path length of ~1.5m from SR2. So options are 
    • ITMY table (East)
    • ITMX table (South)
    • IMC table (West)
  • Moreover, after the SRM, we have to accommodate:
    • Some kind of pickoff for in-air PDs.
    • OFI.
    • OMC MMT.
    • OMC.
  • Some kind of CBA (as of now I think going to the ITMY table is the best option):
Option Advantages Disadvantages
ITMY
  • Easy to direct beam from BS/PRM chamber to the ITMY table (i.e. we don't have to worry too much about avoiding other optics in the path etc).
  • Ease of access to chamber, ease of working in there.
  • ITMY table probably has the most room to work out an OFI + OMC MMT + OMC solution.
  • AS beam extraction to air will be more complicated, possibly have to do it on ITMY optical table.
  • Not sure if the ITMY table can accommodate all of the output optics subsystems I listed above.
  • Routing the LO beam to this table would be tricky I guess.
ITMX
  • Routing the LO beam for homodyne detection is probably easiest in this chamber.
  • Allows for small AoI on folding mirror, reducing the impact of astigmatism.
  • Pain to work in this chamber because of IMC tube.
  • Steering beam from SR2 to ITMX table means threading the needle between PRM and PR3 possibly.
IMC
  • Probably allows the use of (almost) the entire existing OMC chamber for the output optics (OFI, OMC MMT, OMC).
  • IMC table is crowded (2 SOS towers, several steering optics for the input beam, input faraday).
  • Not sure what is the performance of the seismic isolation stacks on these tables vs the larger optical tables.
  • Painful to work in these smaller chambers.
  14164   Wed Aug 15 12:15:24 2018 gautamUpdateCOCMacroscopic SRC length for SR tuning

Summary:

It looks like we can have a stable SRC of length 4.044 m without getting any new mirrors, so this is an option to consider in the short-term.

Details:

  • The detailed calculations are in the git repo
  • The optical configuration is:
    • A single folding mirror approximately at the current SR3 location.
    • An SRM that is ~1.5m away from the above folding mirror. Which table the SRM goes on is still an open question, per the previous elog in this thread. 
  • The SRC length is chosen to be 4.044 m, which is what the modeling tells us we need for operating in the SR tuning instead of RSE.
  • Using this macroscopic length, I found that we could use a single folding mirror in the SRC, and that the existing (convex) G&H folding mirrors, which have a curvature of -700m, happily combine with our existing SRM (concave with a curvature of 142m) to give reasonable TMS and mode-matching to the arm cavity.
  • The existing SRM transmission of 10% may not be optimal but Kevin's calculations say we should still be able to see some squeezing (~0.8 dB) with this SRM.
  • Attachment #1 - corner plot of the distribution of TMS for the vertical and horizontal modes, as well as the mode-matching (averaged between the two modes) between the SRC and arm cavity.
  • Attachment #2 - histograms of the distributions of RoCs and lengths used to generate Attachment #1. The distributions were drawn from i.i.d Gaussian pdfs.

gautam 245pm: Koji pointed out that the G&H mirrors are coated for normal incidence, but looking at the measurement, it looks like the optic has T~75ppm at 45 degree incidence, which is maybe still okay. Alternatively, we could use the -600m SR3 as the single folding mirror in the SRC, at the expense of slightly reduced mode-matching between the arm cavity and SRC.

Attachment 1: SRC_MCMC_shortTerm.pdf
SRC_MCMC_shortTerm.pdf
Attachment 2: SRC_dists_shortTerm.pdf
SRC_dists_shortTerm.pdf
  14314   Wed Nov 21 16:48:11 2018 gautamUpdateCOCEY mini cleanroom setup

With Chub's help, I've setup a mini cleanroom at EY - Attachment #1. The HEPA unit is running on high now. All surfaces were wiped with isopropanol, we can wipe everything down again on Monday and replace the foil.

Attachment 1: IMG_7174.JPG
IMG_7174.JPG
  15374   Thu Jun 4 00:21:28 2020 KojiSummaryCOCITM spares and New PR3 mirrors transported to Downs for phasemap measurement

GariLynn worked on the measurement of E1800089 mirrros.

The result of the data analysis, as well as the data and the codes, have been summarized here:
https://nodus.ligo.caltech.edu:30889/40m_phasemap/#E1800089
 

  15401   Tue Jun 16 13:05:36 2020 KojiUpdateCOCITM spares and New PR3 mirrors transported to Downs for phasemap measurement

ITMU01 / ITMU02 as well as the five E1800089 mirrors came back to the 40m. Instead, the two ETM spares (ETMU06 / ETMU08) were delivered to GariLynn.
Jordan worked on transportation.

Note that the E1800089 mirrors are together with the ITM container in the precious optics cabinet.

Attachment 1: 40m_Optics.jpg
40m_Optics.jpg
  15625   Wed Oct 14 13:28:04 2020 KojiUpdateCOCITM/ETM spares in Downs

The two ITM spares and two ETM spares are together stored in the optic storage (B110) at Downs. c/o Liyuan and GariLynn

Attachment 1: IMG_3073.jpeg
IMG_3073.jpeg
  3193   Mon Jul 12 11:20:56 2010 Gopal HowToCOMSOL TipsIntrusions (Negative Extrusions)

For the sake of future users, I have decided to periodically add tips and tricks in using COMSOL that I have figured out, most probably after hours of circuitous efforts. They will always be listed under the new COMSOL Tips category.

Today's topic: Intrusions

COMSOL has a very user-friendly interface for taking objects from 2D to 3D using the "extrusion" feature. But suppose one wants to design an object which contains screw holes or some other indentation. I've found that creating "punctures" in COMSOL is either impossible or very complicated.

Instead, COMSOL encourages users to always "add" to the object. In other words, one must form the lowest level first, then build layers sequentially on top using new work plane and boolean difference operators. This will probably be a bit clearer with an example:

1) First, create the planar projection in a work plane:

Screen_shot_2010-07-12_at_10.51.22_AM.png

2) Extrude the first layer only in the regular fashion:

Screen_shot_2010-07-12_at_10.51.28_AM.png

 3) Add a new work plane which is offset in the z-direction to the deepest point of the intrusion.

Screen_shot_2010-07-12_at_10.52.08_AM.png

 4) Now, create the shape of the intrusion in this new work plane.

Screen_shot_2010-07-12_at_10.53.53_AM.png

5) Use the Boolean "Difference" to let COMSOL know that, on this plane, the object has a hole.

 Screen_shot_2010-07-12_at_10.54.36_AM.png

 6) Extrude once more from the second work plane to complete the intrusion.

Screen_shot_2010-07-12_at_10.55.36_AM.png

  3194   Mon Jul 12 12:16:50 2010 DmassHowToCOMSOL TipsIntrusions (Negative Extrusions)

 An entry on the 40m wiki page might serve you better, and be easier to sift through once all is said and done

  3291   Mon Jul 26 11:15:23 2010 GopalHowToCOMSOL TipsPictures from Transfer Function Tutorial on the Wiki

The attached pictures give a brief overview of my transfer function measurement procedure in COMSOL. For more details, please see the Wiki.

Screen_shot_2010-07-23_at_2.57.14_PM.png

Screen_shot_2010-07-23_at_2.57.38_PM.png

Screen_shot_2010-07-23_at_2.57.45_PM.png

Screen_shot_2010-07-23_at_2.58.05_PM.png

Screen_shot_2010-07-23_at_2.58.18_PM.png

Screen_shot_2010-07-23_at_2.59.02_PM.png

Screen_shot_2010-07-23_at_3.00.37_PM.png

  3322   Thu Jul 29 17:11:16 2010 GopalUpdateCOMSOL TipsIncluding Gravity in COMSOL

[Gopal, Jan]

For the past couple of days, Jan and I have been discussing a major issue in COMSOL involving modeling both oscillatory and non-oscillatory forces simultaneously while using FDA. It turns out that he and I had run into the same problem at different times and with different projects. After discussing with an expert, Jan had decided in the past that this simple task was impossible via direct means.

The issue could still be resolved if there was a way for us to work on the Weak Form of the differential equations describing the system:

  • Usually, one must define weight as a body load in the negative-z direction. However, this problematically instantiates a new force in COMSOL, which is automatically driven over the range of frequencies during FDA.
  • Instead, we could define gravity as an anti-restoring force, since we assume that the base of the stack is fixed.
  • In other words, Fg = (ρ*g/L)*x + (ρ*g/L)*y for a point mass which is constrained on the bottom (for small angles).
  • Working in Weak Form then, we'd never have to define an explicit gravity load-- this could just be an extra couple of terms in the differential equation which are related entirely to the x- and y-vectors (well-defined for each mesh point). This would fool COMSOL into never tacking on the oscillatory term during FDA. 

According to current documentation however, Weak Form analysis is not yet possible in COMSOL 4.0. Jan suggested moving my work over to ANSYS or waiting for the 4.0 upgrade, but there's probably not enough time left in my SURF for either of these options. I suggested attempting a backwards-compatibility test to COMSOL 3.5; Jan and I will be exploring this option some time next week. 

  3536   Tue Sep 7 20:44:54 2010 YoichiHowToCOMSOL TipsCOMSOL example for calculating mechanical transfer functions

I added COMSOL example files to the 40m svn to demonstrate how to make transfer function measurements in COMSOL.

https://nodus.ligo.caltech.edu:30889/svn/trunk/comsol/MechanicalTF/

The directory also contains an (incomplete) explanation of the method in a PDF file.

  8190   Wed Feb 27 19:27:29 2013 AnnalisaHowToCOMSOL TipsMirror support Eigenfrequency

 I studied the eigenfrequencies of a mirror support using COMSOL.

 

Attachment 1: IronSupport.png
IronSupport.png
Attachment 2: IronSupportEigenfreq.png
IronSupportEigenfreq.png
  8226   Mon Mar 4 20:03:42 2013 AnnalisaHowToCOMSOL TipsStudy of mirror mount eigenfrequencies

 I studied the eigenfrequencies of a mirror mount designed with COMSOL.

I imposed fixed constraints for the base screws and for the screw connecting the base with the pedestal. Note that the central screw is connected to the base only for a small thickness, and the pedestal touches the base only with a thin annulus. This is in way to make a better model of the actual stress.

Shown in fig. 2 is the lowest eigenfrequency of the mount.

I' going to change the base and study the way the eigenfrequency vary, in way to find the configuration which minimizes the lowest eigenfrequency.

 

Attachment 1: MirrorSupport1.png
MirrorSupport1.png
Attachment 2: MirrorSupportEig1.png
MirrorSupportEig1.png
Attachment 3: pedestal.png
pedestal.png
Attachment 4: Base2.png
Base2.png
  8437   Wed Apr 10 15:49:22 2013 AnnalisaConfigurationCOMSOL TipsYend table eigenfrequency simulation with COMSOL

 I made a Simulation with COMSOL for the Yend table. Mainly, I tried to see how the lower eigenmode changes with the number and the size of the posts inside.

The lateral frame is just sitting on the table, it is fixed by its weight. I also put a couple of screws to fix it better, but the resulting eigenfrequency didn't change so much (less than 1 Hz). 

In Fig. 1 I didn't put any post. Of course, the lowest eigenfrequency is very low (around 80 Hz).

Then I added 2 posts, one per side (Fig. 2 and Fig. 3), with different diameter.

In some cases posts don't have a base, but they are fixed to the table only by a screw. It is just a condition to keep them fixed to the table

Eventually I put 4 posts, 2 per side. 

The lowest eigenfrequency is always increasing.

At the end I also put a simulation for 4 1.6 inch diameter posts without base, and the eigenfrequency is slightly higher. I want to check it again, because I would expect that the configuration shown in Fig.5a could be more stable.

P.S.: All the post are stainless steel.

 

Attachment 1: Pics_end_table.pdf
Pics_end_table.pdf Pics_end_table.pdf Pics_end_table.pdf
  15650   Thu Oct 29 09:50:12 2020 anchalSummaryCalibrationPreliminary calibration measurement taken

I went to 40m yesterday at around 2:30 pm and Koji showed me how to acquire lock in different arms and for different lasers. Finally, we took a preliminary measurement of shaking the ETMX at some discrete frequencies and looking at the beatnote frequency spectrum of X-end laser's fiber-coupled IR and Main laser's IR pick-off.


Basic controls and measurement 101 at 40m

  • I learned a few things from Koji about how to align the cavity mirrors for green laser or IR laser.
  • I learned how to use ASS and how to align the green end laser to the cavity. I also found out about the window at ETMX chamber where we can directly see the cavity mode, cool stuff.
  • Koji also showed me around on how to use diaggui and awggui for taking measurements with any of the channels.

Preliminary measurement for calibration scheme

We verified that we can send discrete frequency excitation signals to ETMX actuators directly and see a corresponding peak in the spectrum of beatnote frequency between fiber-coupled X-end IR laser and main laser IR pickoff.

  • I sent excitation signal at 200 Hz, 250 Hz and 270 Hz at C1:SUS-ETMX_LSC_EXC channel using awggui with an amplitude of 100 cts and gain of 2.
  • I measured corresponding peaks in the beatnote spectrum using diaggui.
  • Page 1 shows the ASD data for the 4 measurements taken with Hanning window and averaging of 10.
  • Page 2 shows close up Spectrum data for the 4 measurements taken with flattop window and averaging of 10.
  • I converted this frequency signal into displacement by using conversion factor \nu_{FSR}/\frac{\lambda}{2} or \frac{L \lambda}{c}.

If full interferometer had been locked, we could have used the DARM error signal output to calibrate it against this measurement.

Data

Attachment 1: PreliminaryCalibrationData.pdf
PreliminaryCalibrationData.pdf PreliminaryCalibrationData.pdf
  16128   Mon May 10 10:57:54 2021 Anchal, PacoSummaryCalibrationUsing ALS beatnote for calibration, test

Test details:

  • We locked both arms and opened the shutter for Yend green laser.
  • After toggling the shutter on.off, we got a TEM00 mode of green laser locked to YARM.
  • We then cleared the phase Y history by clicking "CLEAR PHASE Y HISTROY" on C1LSC_ALS.adl (opened from sitemap > ALS > ALS).
  • We sent excitation signal at ITMY_LSC_EXC using awggui at 43Hz, 77Hz and 57Hz.
  • We measured the power spectrum and coherence of C1:ALS-BEATY_FINE_PHASE_OUT_HZ_DQ and C1:SUS-ITMY_LSC_OUT_DQ.
  • The BEATY_FINE_PHASE_OUT_HZ is already calibrated in Hz. This we assume is done by multip[lying the VCO slope in Hz/cts to the error signal of the digital PLL loop that tracks the phase of beatnote.
  • We calibrated C1:SUS-ITMY_LSC_OUT_DQ by multiplying with
    \large 3 \times \frac{2.44 \, nm/cts}{f^2} \times \frac{c}{1064\,nm \times 37.79\, m} = \frac{54.77}{f^2} kHz/cts where f is in Hz.
    The 2.44/f2 nm/cts is taken from 13984.
  • We added the calibration as Poles/zeros option in diaggui using gain=54.577e3 and poles as "0, 0".
  • We found that ITMY_LSC_OUT_DQ calibration matches well at 57Hz but overshoots (80 vs 40) at 43 Hz and undershoots (50 vs 80) at 77Hz.

Conclusions:

  • If we had DRFPMI locked, we could have used the beatnote spectrum as independent measurement of arm lengths to calibrate the interferometer output.
  • We can also use the beatnote to confirm or correct the ITM actuator calibrations. Maybe shape is not exactly 1/f2 unless we did something wrong here or the PLL bandwidth is too short.
Attachment 1: BeatY_ITMY_CalibrationAt57Hz.pdf
BeatY_ITMY_CalibrationAt57Hz.pdf BeatY_ITMY_CalibrationAt57Hz.pdf
Attachment 2: BeatY_ITMY_CalibrationAt43Hz.pdf
BeatY_ITMY_CalibrationAt43Hz.pdf BeatY_ITMY_CalibrationAt43Hz.pdf
Attachment 3: BeatY_ITMY_CalibrationAt77Hz.pdf
BeatY_ITMY_CalibrationAt77Hz.pdf BeatY_ITMY_CalibrationAt77Hz.pdf
  16315   Tue Sep 7 18:00:54 2021 TegaSummaryCalibrationSystem Identification via line injection

[paco]

This morning, I spent some time restoring the jupyter notebook server running in allegra. This server was first set up by Anchal to be able to use the latest nds python API tools which is handy for the calibration stuff. The process to restore the environment was to run "source ~/bashrc.d/*" to restore some of the aliases, variables, paths, etc... that made the nds server work. I then ran ssh -N -f -L localhost:8888:localhost:8888 controls@allegra from pianosa and carry on with the experiment.


[paco, hang, tega]

We started a notebook under /users/paco/20210906_XARM_Cal/XARM_Cal.ipynb on which the first part was doing the following;

  • Set up list of excitations for C1:LSC-XARM_EXC (for example three sine waveforms) using awg.py
  • Make sure the arm is locked
  • Read a reference time trace of the C1:LSC-XARM_IN2 channel for some duration
  • Start excitations (one by one at the moment, ramptime ~ 3 seconds, same duration as above)
  • Get data for C1:LSC-XARM_IN2 for an equal duration (raw data in Attachment #1)
  • Generate the excitation sine and cosine waveforms using numpy and demodulate the raw timeseries using a 4th order lowpass filter with fc ~ 10 Hz
  • Estimate the correct demod phase by computing arctan(Q / I) and rerunning the demodulation to dump the information into the I quadrature (Attachment #2).
  • Plot the estimated ASD of all the quadratures (Attachment #3)

[paco, hang, tega]

Estimation of open loop gain:

  • Grab data from the C1:LSC-XARM_IN1 and C1:LSC-XARM_IN2 test points
  • Infer excitation from their differnce, i.e. C1:LSC-XARM_EXC = C1:LSC-XARM_IN2 - C1:LSC-XARM_IN1
  • Compute the open loop gain as follows : G(f) = csd(EXC,IN1)/csd(EXC,IN2), where csd computes the cross spectra density of the input arguments
  • For the uncertainty in G, dG, we repeat steps (1) to (3) with & without signal injection in the C1:LSC-XARM_EXC channel. In the absence of signal injection, the signal in C1:LSC-XARM_IN2 is of the form: Y_ref = Noise/(1-G), whereas with nonzero signal injection, the signal in C1:LSC-XARM_IN2 has the form: Y_cal = EXC/(1-G) + Noise/(1-G), so their ratio, Y_cal/Y_ref = EXC/Noise, gives the SNR, which we can then invert to give the uncertainty in our estimation of G, i.e dG = Y_ref/Y_cal.
  • For the excitation at 53 Hz, our measurtement for the open loop gain comes out to about 5 dB whiich is consistent with previous measurement.
  • We seem to have an SNR in excess of 100 at measurement time of 35 seconds and 1 count of amplitude which gives a relative uncertainty of G of 0.1%
  • The analysis details are ongoing. Feedback is welcome.
Attachment 1: raw_timeseries.pdf
raw_timeseries.pdf
Attachment 2: demod_signals.pdf
demod_signals.pdf
Attachment 3: cal_noise_asd.pdf
cal_noise_asd.pdf
  16352   Tue Sep 21 11:13:01 2021 PacoSummaryCalibrationXARM calibration noise

Here are some plots from analyzing the C1:LSC-XARM calibration. The experiment is done with the XARM (POX) locked, a single line is injected at C1:LSC-XARM_EXC at f0 with some amplitude determined empirically using diaggui and awggui tools. For the analysis detailed in this post, f0 = 19 Hz, amp = 1 count, and gain = 300 (anything larger in amplitude would break the lock, and anything lower in frequency would not show up because of loop supression). Clearly, from Attachment #3 below, the calibration line can be detected with SNR > 1.

We read the test point right after the excitation C1:LSC-XARM_IN2 which, in a simplified loop will carry the excitation suppressed by 1 - OLTF, the open loop transfer function. The line is on for 5 minutes, and then we read for another 5 minutes but with the excitation off to have a reference. Both the calibration and reference signal time series are shown in Attachment #1 (decimated by 8). The corresponding ASDs are shown in Attachment #2. Then, we demodulate at 19 Hz and a 30 Hz, 4th-order butterworth LPF, and get an I and Q timeseries (shown in Attachment #3). Even though they look similar, the Q is centered about 0.2 counts, while the I is centered about 0.0. From this time series, we can of course show the noise ASDs in Attachment #3.


The ASD uncertainty bands in the last plot are statistical estimates and depend on the number of segments used in estimating the PSD. A thing to note is that the noise features surrounding the signal ASD around f0 are translated into the ASD in the demodulated signals, but now around dc. I guess from Attachment #3 there is no difference in the noise spectra around the calibration line with and without the excitation. This is what I would have expected from a linear system. If there was a systematic contribution, I would expect it to show at very low frequencies.

Attachment 1: XARM_signal_asd.pdf
XARM_signal_asd.pdf
Attachment 2: XARM_demod_timeseries.pdf
XARM_demod_timeseries.pdf
Attachment 3: XARM_demod_asds.pdf
XARM_demod_asds.pdf
Attachment 4: XARM_cal_0921_timeseries.pdf
XARM_cal_0921_timeseries.pdf
  16353   Wed Sep 22 11:43:04 2021 ranaSummaryCalibrationXARM calibration noise

I would expect to see some lower frequency effects. i.e. we should look at the timeseries of the demod with the excitation on and off.

I would guess tat the exc on should show us the variations in the optical gain below 3 Hz, whereas the exc off would not show it.

Maybe you should do some low pass filtering on the time series you have to see the ~DC effects? Also, reconsider your AA filter design: how do you quantitatively choose the cutoff frequency and stopband depth?

  16363   Tue Sep 28 16:31:52 2021 PacoSummaryCalibrationXARM OLTF (calibration) at 55.511 Hz

[anchal, paco]

Here is a demonstration of the methods leading to the single (X)arm calibration with its budget uncertainty. The steps towards this measurement are the following:

  1. We put a single line excitation through the C1:SUS-ETMX_LSC_EXC at 55.511 Hz, amp = 1 counts, gain = 300 (ramptime=10 s).
  2. With the arm locked, we grab a long timeseries of the C1:LSC-XARM_IN1_DQ (error point) and C1:SUS-ETMX_LSC_OUT_DQ (control point) channels.
  3. We assume the single arm loop to have the four blocks shown in Attachment #1, A (actuator + sus), plant (mainly the cavity pole), D (detection + electronics), and K (digital control).
    1. At this point, Anchal made a model of the single arm loop including the appropriate filter coefficients and other parameters. See Attachments #2-3 for the split and total model TFs.
    2. Our line would actually probe a TF from point b (error point) to point d (control point). We multiplied our measurement with open loop TF from b to d from model to get complete OLTF.
    3. Our initial estimate from documents and elog made overall loop shape correct but it was off by an overall gain factor. This could be due to wrong assumption on RFPD transimpedance or analog gains of AA or whitening filters. We have corrected for this factor in the RFPD transimpedance, but this needs to be checked (if we really care).
  4. We demodulate decimated timeseries (final sampling rate ~ 2.048 kHz) and I & Q for both the b and d signals. From this and our model for K, we estimate the OLTF. Attachment #4 shows timeseries for magnitude and phase.
  5. Finally, we compute the ASD for the OLTF magnitude. We plot it in Attachment #5 together with the ASD of the XARM transmission (C1:LSC-TRX_OUT_DQ) times the OLTF to estimate the optical gain noise ASD (this last step was a quick attempt at budgeting the calibration noise).
    1. For each ASD we used N = 24 averages, from which we estimate rms (statistical) uncertainties which are depicted by error bands (\pm \sigma) around the lines.

** Note: We ran the same procedure using dtt (diaggui) to validate our estimates at every point, as well as check our SNR in b and d before taking the ~3.5 hours of data.

Attachment 1: OLTF_Calibration_Scheme.jpg
OLTF_Calibration_Scheme.jpg
Attachment 2: XARM_POX_Lock_Model_TF.pdf
XARM_POX_Lock_Model_TF.pdf
Attachment 3: XARM_OLTF_Total_Model.pdf
XARM_OLTF_Total_Model.pdf
Attachment 4: XARM_OLTF_55p511_Hz_timeseries.pdf
XARM_OLTF_55p511_Hz_timeseries.pdf
Attachment 5: Gmag_55p511_Hz_ASD.pdf
Gmag_55p511_Hz_ASD.pdf
  16369   Thu Sep 30 18:04:31 2021 PacoSummaryCalibrationXARM OLTF (calibration) with three lines

[anchal, paco]

We repeated the same procedure as before, but with 3 different lines at 55.511, 154.11, and 1071.11 Hz. We overlay the OLTF magnitudes and phases with our latest model (which we have updated with Koji's help) and include the rms uncertainties as errorbars in Attachment #1.

We also plot the noise ASDs of calibrated OLTF magnitudes at the line frequencies in Attachment #2. These curves are created by calculating power spectral density of timeseries of OLTF values at the line frequencies generated by demodulated XARM_IN and ETMX_LSC_OUT signals. We have overlayed the TRX noise spectrum here as an attempt to see if we can budget the noise measured in values of G to the fluctuation in optical gain due to changing power in the arms. We multiplied the the transmission ASD with the value of OLTF at those frequencies as the transfger function from normalized optical gain to the total transfer function value.

It is weird that the fluctuations in transmission power at 1 mHz always crosses the total noise in the OLTF value in all calibration lines. This could be an artificat of our data analysis though.

Even if the contribution of the fluctuating power is correct, there is remaining excess noise in the OLTF to be budgeted.

Attachment 1: XARM_OLTF_Model_and_Meas.pdf
XARM_OLTF_Model_and_Meas.pdf XARM_OLTF_Model_and_Meas.pdf
Attachment 2: Gmag_ASD_nb_withTRX.pdf
Gmag_ASD_nb_withTRX.pdf Gmag_ASD_nb_withTRX.pdf Gmag_ASD_nb_withTRX.pdf
  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
  16399   Wed Oct 13 15:36:38 2021 HangUpdateCalibrationXARM OLTF

We did a few quick XARM oltf measurements. We excited C1:LSC-ETMX_EXC with a broadband white noise upto 4 kHz. The timestamps for the measurements are: 1318199043 (start) - 1318199427 (end).

We will process the measurement to compute the cavity pole and analog filter poles & zeros later.

Attachment 1: Screenshot_2021-10-13_15-32-16.png
Screenshot_2021-10-13_15-32-16.png
  10436   Thu Aug 28 11:02:53 2014 SteveUpdateCalibration-RepairSR785 repair

SN 46,795 of 2003 is back.

Attachment 1: 08281401.PDF
08281401.PDF
  11641   Thu Sep 24 17:06:14 2015 ericqUpdateCalibration-RepairC1CAL Lockins

Just a quick note for now: I've repopulated C1CAL with a limited set of lockin oscillators/demodulators, informed by the aLIGO common LSC model. Screens are updated too. 

Rather than trying to do the whole magnitude phase decompostion, it just does the demodulation of the RFPD signals online; everything beyond that is up to the user to do offline. 

Briefly testing with PRMI, it seems to work as expected. There is some beating evident from the fact that the MICH and PRCL oscillation frequencies are only 2Hz apart; the demod low pass is currently at an arbitrary 1Hz, so it doesn't filter the beat much. 

Screens, models, etc. all svn'd.

  12040   Mon Mar 21 14:29:32 2016 SteveUpdateCalibration-Repair1W Innolight laser repair diagnoses

 

Quote:
Quote:

After adjusting the alignment of the two beams onto the PD, I managed to recover a stronger beatnote of ~ -10dBm. I managed to take some measurements with the PLL locked, and will put up a more detailed post later in the evening. I turned the IMC autolocker off, turned the 11MHz Marconi output off, and closed the PSL shutter for the duration of my work, but have reverted these to their nominal state now. The are a few extra cables running from the PSL table to the area near the IOO rack where I was doing the measurements from, I've left these as is for now in case I need to take some more data later in the evening...I

Innolight 1W 1064nm, sn 1634 was purchased in 9-18-2006 at CIT. It came to the 40m around 2010

It's diodes should be replaced, based on it's age and performance.

RIN and noise eater bad. I will get a quote on this job.

The Innolight Manual frequency noise plot is the same as Lightwave' elog 11956

Diagnoses from Glasglow:

“So far we have analyzed the laser. The pump diode is degraded. Next we would replace it with a new diode. We would realign the diode output beam into the laser crystal. We check all the relevant laser parameters over the whole tuning range. Parameters include single direction operation of the ring resonator, single frequency operation, beam profile and others. If one of them is out of spec, then we would take actions accordingly. We would also monitor the output power stability over one night. Then we repackage and ship the laser.”

  12045   Thu Mar 24 07:56:09 2016 SteveUpdateCalibration-RepairNO Noise Eater for 1W Innolight

1W Innolight is NOT getting Noise Eater as it was decided yesterday at the 40m meeting. Corrected 3-25-2016

Repair quote with adding noise eater is in 40m wiki

Quote:

 

Quote:
Quote:

After adjusting the alignment of the two beams onto the PD, I managed to recover a stronger beatnote of ~ -10dBm. I managed to take some measurements with the PLL locked, and will put up a more detailed post later in the evening. I turned the IMC autolocker off, turned the 11MHz Marconi output off, and closed the PSL shutter for the duration of my work, but have reverted these to their nominal state now. The are a few extra cables running from the PSL table to the area near the IOO rack where I was doing the measurements from, I've left these as is for now in case I need to take some more data later in the evening...I

Innolight 1W 1064nm, sn 1634 was purchased in 9-18-2006 at CIT. It came to the 40m around 2010

It's diodes should be replaced, based on it's age and performance.

RIN and noise eater bad. I will get a quote on this job.

The Innolight Manual frequency noise plot is the same as Lightwave' elog 11956

Diagnoses from Glasglow:

“So far we have analyzed the laser. The pump diode is degraded. Next we would replace it with a new diode. We would realign the diode output beam into the laser crystal. We check all the relevant laser parameters over the whole tuning range. Parameters include single direction operation of the ring resonator, single frequency operation, beam profile and others. If one of them is out of spec, then we would take actions accordingly. We would also monitor the output power stability over one night. Then we repackage and ship the laser.”

 

  12070   Mon Apr 11 17:03:41 2016 SteveUpdateCalibration-Repair1W Innolight repair completed

The laser is back. Test report is in the 40m wiki as New Pump Diode Mephisto 1000

It will go on the PSL table.

  13456   Tue Nov 28 17:27:57 2017 awadeBureaucracyCalibration-RepairSR560 return, still not charging

I brought a bunch of SR560s over for repair from Bridge labs. This unit, picture attached (SN 49698), appears to still not be retaining charge. I’ve brought it back. 

Attachment 1: 96B6ABE6-CC5C-4636-902A-2E5DF553653D.jpeg
96B6ABE6-CC5C-4636-902A-2E5DF553653D.jpeg
Attachment 2: image.jpg
image.jpg
  14759   Mon Jul 15 03:30:47 2019 KruthiUpdateCalibration-RepairWhite paper as a Lambertian scatterer

I made some rough measurements, using the setup I had used for CCD calibration, to get an idea of how good of a Lambertian scatterer the white paper is. Following are the values I got:

Angle (degrees) Photodiode reading (V)  Ps (W) BRDF (per str) % error
12 0.864 2.54E-06 0.334 20.5
24 0.926 2.72E-06 0.439 19.0
30 1.581 4.65E-06 0.528 19.0
41 0.94 2.76E-06 0.473 19.8
49 0.545 1.60E-06 0.423 22.5
63 0.371 1.09E-06 0.475 28

Note: All the measurements are just rough ones and are prone to larger errors than estimated.

I also measured the transmittance of the white paper sample being used (it consists of 2 white papers wrapped together). It was around 0.002

Attachment 1: BRDF_paper.png
BRDF_paper.png
  14804   Wed Jul 24 04:20:35 2019 KruthiUpdateCalibration-RepairMC2 pitch and yaw calibration

Summary:  I calibrated MC2 pitch and yaw offsets to spot position in mm. Here's what I did:

  1. Changed the MC2 pitch and yaw offset values using  ezca.Ezca().write('IOO-MC2_TRANS_PIT_OFFSET', <pitch offset value> ) and ezca.Ezca().write('IOO-MC2_TRANS_YAW_OFFSET', <yaw offset value> )
  2. Waited for ~ 700-800 sec for system to adjust to the assigned values
  3. Took snapshots with the 2 GigEs I had installed - zoomed in and zoomed out. (I'll be using these to make a scatter loss map, verify the calibration results, etc)
  4. Ran the mcassDecenter script, which can be found in /scripts/ASS/MC. This enters the spot position in mm in the specified text file.

Results:  In the pitch/yaw vs pitch_offset/yaw_offset graph attached,

  • intercept_pitch = 6.63 (in mm) ,  slope_pitch = -0.6055 (mm/counts) 
  • intercept_yaw = -4.12 (in mm) ,  slope_yaw = 4.958 (mm/counts) 
Attachment 1: Pitchyaw_calibration.png
Pitchyaw_calibration.png
  15510   Sat Aug 8 07:36:52 2020 Sanika KhadkikarConfigurationCalibration-RepairBS Seismometer - Multi-channel calibration

Summary : 

I have been working on analyzing the seismic data obtained from the 3 seismometers present in the lab. I noticed while looking at the combined time series and the gain plots of the 3 seismometers that there is some error in the calibration of the BS seismometer. The EX and the EY seismometers seem to be well-calibrated as opposed to the BS seismometer.

The calibration factors have been determined to be :

BS-X Channel: \small {\color{Blue} 2.030 \pm 0.079 }

BS-Y Channel: \small {\color{Blue} 2.840 \pm 0.177 }

BS-Z Channel: \small {\color{Blue} 1.397 \pm 0.182 }


Details :

The seismometers each have 3 channels i.e X, Y, and Z for measuring the displacements in all the 3 directions. The X channels of the three seismometers should more or less be coherent in the absence of any seismic excitation with the gain amongst all the similar channels being 1. So is the case with the Y and Z channels. After analyzing multiple datasets, it was observed that the values of all the three channels of the BS seismometer differed very significantly from their corresponding channels in the EX and the EY seismometers and they were not calibrated in the region that they were found to be coherent as well. 


Method :

Note: All the frequency domain plots that have been calculated are for a sampling rate of 32 Hz. The plots were found to be extremely coherent in a certain frequency range i.e ~0.1 Hz to 2 Hz so this frequency range is used to understand the relative calibration errors. The spread around the function is because of the error caused by coherence values differing from unity and the averages performed for the Welch function. 9 averages have been performed for the following analysis keeping in mind the needed frequency resolution(~0.01Hz) and the accuracy of the power calculated at every frequency. 

  1. I first analyzed the regions in which the similar channels were found to be coherent to have a proper gain analysis. The EY seismometer was found to be the most stable one so it has been used as a reference. I saw the coherence between similar channels of the 2 seismometers and the bode plots together. A transfer function estimator was used to analyze the relative calibration in between all 3 pairs of seismometers. In the given frequency range EX and EY have a gain of 1 so their relative calibration is proper. The relative calibration in between the BS and the EY seismometers is not proper as the resultant gain is not 1. The attached plots show the discrepancies clearly : 
  • BS-X & EY-X Transfer Function : Attachment #1
  • BS-Y & EY-Y Transfer Function : Attachment #2

          The gain in the given frequency range is ~3. The phase plotting also shows a 180-degree phase as opposed to 0 so a negative sign would also be required in the calibration factor. Thus the calibration factor for the Y channel of the BS seismometer should be around ~3. 

  • BS-Z & EY-Z Transfer Function : Attachment #3

The mean value of the gain in the given frequency range is the desired calibration factor and the error would be the mean of the error for the gain dataset chosen which is caused due to factors mentioned above.

Note: The standard error envelope plotted in the attached graphs is calculated as follows :

         1. Divide the data into n segments according to the resolution wanted for the Welch averaging to be performed later. 

         2. Calculate PSD for every segment (no averaging).

         3. Calculate the standard error for every value in the data segment by looking at distribution formed by the n number values we obtain by taking that respective value from every segment.

Discussions :

The BS seismometer is a different model than the EX and the EY seismometers which might be a major cause as to why we need special calibration for the BS seismometer while EX and EY are fine. The sign flip in the BS-Y seismometer may cause a lot of errors in future data acquisitions. The time series plots in Attachment #4 shows an evident DC offset present in the data. All of the information mentioned above indicates that there is some electrical or mechanical defect present in the seismometer and may require a reset. Kindly let me know if and when the seismometer is reset so that I can calibrate it again. 

Attachment 1: BS_X-EY_X.png
BS_X-EY_X.png
Attachment 2: BS_Y-EY_Y.png
BS_Y-EY_Y.png
Attachment 3: BS_Z-EY_Z.png
BS_Z-EY_Z.png
Attachment 4: timeseries.png
timeseries.png
  227   Tue Jan 8 15:20:17 2008 PkpUpdateCamerasGigE update
[Tobin , Pinkesh]

Finally we got the camera doing something (other than giving out its attributes). The only thing that seems to work so far is a program called AAviewer, which converts the image into an ASCII format and displays it on the screen. If you want to play around with it, log into mafalda (131.215.113.23) via rana.ligo.caltech.edu. Access /cvs/cds/caltech/target/Prosilica/bin-pc/x86/ and there should be a few programs in there, one of which is AAviewer, which requires you to get an IP address (which is 131.215.113.103) for the camera right now. (You can also get the IP information via the ListCameras program). The camera is physically in the 40m near the network rack.

Other programs dont seem to be working and its probably due to the network/packetsize issues. Since linux2 can change its packetsize to a higher number, I will get it to compile on linux2 for now and then give it a shot.
  234   Thu Jan 10 13:45:52 2008 PkpUpdateCamerasGLIBC Error
So, I have tried to compile the camera files which are in /cvs/cds/caltech/target/Prosilica/examples for the past 2 days now and have been unable to get rid of the following error. (specifically ListCameras.cpp, as it doesnt have any other libraries required, which unnecessarily complicates things)

../../bin-pc/x86/libPvAPI.so: undefined reference to `__stack_chk_fail@GLIBC_2.4'
collect2: ld returned 1 exit status
make: *** [sample] Error 1

I used to get this error on mafalda too, but I had fixed it by installing the latest version of the glibc libraries. Inspite of doing so on linux2, the error still persists. I suspect it had something to do with it being a FC3 machine. My own laptop, which also runs Ubuntu works fine too. The problem with these Ubuntu machines is that they dont let me set the packet sizes to 9 kb which is required by the camera. Linux2 does.

If anyone has any idea how to resolve this issue, please let me know.

Thanks
Pinkesh.
  236   Fri Jan 11 17:01:51 2008 pkpUpdateCamerasGigE again
So, here I detail all the efforts on the GigE so far

(1) The GiGE camera requires a minimum of 9 kb packet size, which is not available on mafalda or on my laptop ( both of which run Ubuntu and the Camera programs compile there). The programs which require smaller sizes work perfectly fine on these machines. I tried to statically compile the files on these machines so that I could then port them to the other machines. But that fails because the static libraries given by the company dont work.

(2) On Linux2, which lets me set a packet size as high as 9 Kb, it doesnt compile because of a GLIBC error. I tried updating the glibc and it tells me that the version already existing is the latest ( which it clearly is not). So I tried to uninstall GLIBC and reinstall it, but it wont let me uninstall (it == rpm) glibc, since there are a lot of dependencies. A dead end in essence.

Steps being taken

(1) Locally installing the whole library suites on linux2. Essentially install another version of gcc and g++ and see if that helps.
(2) IF this doesnt work, then the only course of action I can take is to cannibalize linux2's GigE card and put it on mafalda. ( I need permission for this Smile ).

Once again any suggestions welcome.
  245   Thu Jan 17 15:11:13 2008 josephbUpdateCamerasWorking on Malfalda
1) I can statically compile the ListCamera code (which basically just goes out and finds what cameras are connected to the network) on Malfalda and use that compiled code to run on Linux2 without a problem. Simply needed to add explicit links to libpthread.a and librt.a.
(i.e. -Bstatic -L /usr/lib/ -lpthread -Bstatic -L /usr/lib -lrt)

With appropriate static libraries, it should be possible to port this code to other linux machines even if we can't get it to compile on the target machine itself.

2)I've modified the Snap.cpp file so that it uses a packet size of 1000 or less. This simply involves setting the "PacketSize" attribute with the built in functions they provide in their library. After un-commenting some lines in that code, I was able to save tiff type images from the camera of up to 400x240 pixels on Malfalda. The claimed maximum resolution for the camera is 752x480, but it doesn't seem to work with the current setup. The max number of pixels seems to about 100 times the packet size. I.e. packet size of 1000 will allow up to 400x240 (96000) but not 500x240 (120,000). Not sure if this is an issue just with snap code or the general libraries used.

3)Will be working towards getting video running over the next day or so.
  266   Fri Jan 25 11:38:16 2008 josephbConfigurationCamerasWorking GiGE video on Linux - sort of
1)I have been able to compile the SampleViewer program which can stream the video from the Prosilica 750C camera. This was accomplished on my 64-bit laptop running Ubuntu, after about 3 hours of explicitly converting strings to wxStrings and back again within the C++ code. (There was probably an easier way to simply overload the functions that were being called, but I wasn't sure how to go about doing so). By connecting it to the CDS network, I was able to immediately detect the camera and display the images.

Unfortunately, I have not yet been able to get it to compile on Mafalda with the x86 architecture. This may be do the fact that it has wxWidgets version 2.8.7 while my laptop has 2.8.4. Certainly the failure at compile time looks different from the errors earlier, and seem to be within the wxWidget code rather than the SampleViewer code. I may simply need to uninstall 2.8.7 and install 2.8.4 of wxWidgets.

The modified code that will compile on my machine has been copied to /cvs/cds/caltech/target/Prosilica/examples/SampleViewer2b.

2)The Snap program (under /cvs/cds/caltech/target/Prosilica/examples/Snap) also will now take full resolution images even on Mafalda. This was achieved by reducing the packet size to 1000 and also increasing the wait until timeout time up to 400 ms, which originally was at 100. Apparently, it takes on the order of 1 ms per packet as far as I can tell. So full resolution at 752x480 required something of order 360 packets.

To Do:
1) Get sample viewer to compile on Mafalda, and then statically compile it so it can be run from any Linux based machine.
2) Get a user friendly version of Snap up and running, statically compiled, with options for a continuous loop every X seconds and also to set desired parameters (such as height, width, file name to save to, save format, etc).
3) Figure out data analysis with the images in Matlab and an after the fact image viewer.

Attached is an example .tiff image from the Snap program.
Attachment 1: snap.tiff
  267   Fri Jan 25 13:36:13 2008 josephbConfigurationCamerasWorking GiGE video on Mafalda
Finally got the GiGE camera sample viewer video running on Mafalda by updating to the latest API (version 1.16 from Dec 16, 2007) from Prosilica and then using the modified Sample Viewer code I had written. The API version previously in cvs was 1.14.

It can currently be run by ssh -X into Mafalda and going to /cvs/cds/caltech/target/Prosilica/bin-pc/x86 and running the SampleViewer executable found there.
  289   Thu Jan 31 16:53:41 2008 josephbConfigurationCamerasImproving camera user interface
There's a new and improved version of Snap program at the moment people are free to play with.

Located in /cvs/cds/caltech/target/Prosilica/40mCode/

The program Snap now has a -h or --help option which describes some basic command line arguments. The height (in pixels), width (in pixels), exposure time (in micro seconds), file name to be saved to (in .tiff format), and packet size can all be set. The format type (i.e. pixel format such as Mono8 or Mono16) doesn't work at the moment.

At the moment, it only runs on mafalda.

Currently in the process of adding a loop option which will take images every X seconds, saving them to a given file name and then appending the time of capture to the file name.

After that need to add the ability to identify and choose the camera you want (as opposed to the first one it finds).

Lastly, I've been finding on occassion that the frame fails to save. However if you try again a few seconds later with the exact same parameters, it generally does save the second time. Not sure whats causing this, whether on the camera or network side of things.

I've attached two images, the first at default exposure time (15,000 microseconds) and the second at 1/5th that time (3,000 microseconds).
The command line used was "./Snap -E 3000 -F 'Camera_exp_3000.tiff' "
Attachment 1: Camera_exp_15000.tiff
Attachment 2: Camera_exp_3000.tiff
  292   Fri Feb 1 15:04:54 2008 josephbConfigurationCamerasSnap with looping functionality available
New GiGE camera code is available in /cvs/cds/caltech/target/Prosilica/40mCode/. Currently only runs on Mafalda.

Snap has expanded functionality to continuously loop infinitely or for a maximum number of images set by the user. File names generated with the loop option have the current Unix time and .tiff appended to them. So -f './test' will produce tiff files with format "test1234567.tiff". The -l option sets the number of seconds between images.

"./Snap -l 5 -i -f './test' " will cause the program to infinitely loop, saving images every 5 seconds. Using "-m 10" instead of "-i" will take a series of 10 images every 5 seconds (so taking a total of 50 seconds to run).

It also now defaults to 16-bit (in reality only 10 bit) output instead of 8 bit output. You can select between the two with -F 'Mono8' or -F 'Mono16'.

Use --help for a full list of options.

Note that if you ctrl-c out of the loop, you may need to run ./ResetCamera 131.215.113.104 (or whatever the IP is - use ./ListCameras to determine IP if necessary) in order to reset the camera because it doesn't close out elegantly at the moment.
ELOG V3.1.3-