40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 161 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  16747   Tue Mar 29 15:07:11 2022 TegaSummaryVACOpening of MC and ETM chambers

[Anchal, Chub, Ian, Paco, Tega]

Today, we opened the MC chamber, ETMX chamber and ETMY chamber.

  8574   Tue May 14 20:27:19 2013 KojiConfigurationLSCOpenloop gain for PRMI lock May 13

The OLTFs for PRCL and MICH for the last night's lock were modelled using Yuta's python script.

Attachment 1: LSCPRCLOLTF.png
LSCPRCLOLTF.png
Attachment 2: LSCMICHOLTF.png
LSCMICHOLTF.png
Attachment 3: 130513.zip
  8577   Wed May 15 00:45:28 2013 ranaConfigurationLSCOpenloop gain for PRMI lock May 13

 

 Pfft. Why 500 usec delay? We should be using the known parameters for the hardware and software AA/AI.

  10871   Wed Jan 7 14:41:46 2015 SteveUpdateGeneralOphir pmeter filter found

Quote:

Quote:

Ophir power meter gets new filter with calibration. This is not cheap. It was the second time we lost it.

Filter leash is attached.

 Some one already took  off the filter and did not care to put it back on. This is carelessness!

Missing filter found. Labeled drawer OPHIR in control room - behind soldering station-  with spare battery and filter

  10121   Wed Jul 2 14:19:17 2014 SteveUpdateGeneralOphir pmeter gets new filter

Ophir power meter gets new filter with calibration. This is not cheap. It was the second time we lost it.

Filter leash is attached.

Attachment 1: ophirNewFilter.jpg
ophirNewFilter.jpg
  10505   Mon Sep 15 14:37:49 2014 SteveUpdateGeneralOphir pmeter has no filter already

Quote:

Ophir power meter gets new filter with calibration. This is not cheap. It was the second time we lost it.

Filter leash is attached.

 Some one already took  off the filter and did not care to put it back on. This is carelessness!

  13441   Tue Nov 21 23:04:12 2017 gautamUpdateOptical LeversOplev "noise budget"

Per our discussions in the meetings over the last week, I've tried to put together a simple Oplev noise budget. The only two terms in this for now are the dark noise and a model for the seismic noise, and are plotted together with the measured open-loop error signal spectra.

  1. Dark noise
    • Beam was taken off the OL QPD
    • A small DC offset was added to all the oplev segment input filters to make the sum ~20-30 cts [call this testSum] (usually it varies from 4000-13000 for the BS/ITMs, call this nominalSum).
    • I downloaded 20mins of dq-ed error signal data, and computed the ASD, dividing by a factor of nominalSum / testSum to account for the usual light intensity on the QPD.
  2. Seismic noise
    • This is a very simplistic 1/f^2 pendulum TF with a pair of Q=2 poles at 1Hz.
    • I adjusted the overall gain such that the 1Hz peak roughly line up in measurement and model.
    • The stack isn't modelled at all.

Some remarks:

  • The BS oplev doesn't have any whitening electronics, and so has a higher electronics noise floor compared to the ITMs. But it doesn't look like we are limited by this lower noise floor anywhere..
  • I wonder what all those high frequency features seen in the ITM error signal spectra are - mechanical resonances of steering optics? It is definitely above the dark noise floor, so I am inclined to believe this is real beam motion on the QPD, but surely this can't be the test-mass motion? If it were, the measured A2L would be much higher than the level it is adjudged to be at now. Perhaps it's some resonances of steering mirrors?
  • The seismic displacement @100Hz per the GWINC model is ~1e-19 m/rtHz. Assuming the model A2L = d_rms * theta(f) where d_rms is the rms offset of the beam spot from the optic center, and theta(f) is the angular control signal to the optic, for a 5mm rms offset of the spot from the center, theta(f) must be ~1e-17 urad @100Hz. This gives some requirement on the low pass required - I will look into adding this to the global optimization cost.

 

Attachment 1: vertexOL_noises.pdf
vertexOL_noises.pdf vertexOL_noises.pdf vertexOL_noises.pdf
  13444   Wed Nov 22 05:41:32 2017 ranaUpdateOptical LeversOplev "noise budget"

For the OL NB, probably don't have to fudge any seismic noise, since that's a thing we want to suppress. More important is "what the noise would be if the suspended mirrors were no moving w.r.t. inertial space".

For that, we need to look at the data from the OL test setup that Steve is putting on the SP table.

  13448   Wed Nov 22 15:29:23 2017 gautamUpdateOptical LeversOplev "noise budget"

[steve, gautam]

What is the best way to set this test up?

I think we need a QPD to monitor the spot rather than a single element PD, to answer this question about the sensor noise. Ideally, we want to shoot the HeNe beam straight at the QPD - but at the very least, we need a lens to size the beam down to the same size as we have for the return beam on the Oplevs. Then there is the power - Steve tells me we should expect ~2mW at the output of these HeNes. Assuming 100kohm transimpedance gain for each quadrant and Si responsivity of 0.4A/W at 632nm, this corresponds to 10V (ADC limit) for 250uW of power - so it would seem that we need to add some attenuating optics in the way.

Also, does anyone know of spare QPDs we can use for this test? We considered temporarily borrowing one of the vertex OL QPDs (mark out its current location on the optics table, and move it over to the SP table), but decided against it as the cabling arrangement would be too complicated. I'd like to use the same DAQ electronics to acquire the data from this test as that would give us the most direct estimate of the sensor noise for supposedly no motion of the spot, although by adding 3 optics between the HeNe and the QPD, we are introducing possible additional jitter couplings...

Quote:

For the OL NB, probably don't have to fudge any seismic noise, since that's a thing we want to suppress. More important is "what the noise would be if the suspended mirrors were no moving w.r.t. inertial space".

For that, we need to look at the data from the OL test setup that Steve is putting on the SP table.

 

Attachment 1: OplevTest.jpg
OplevTest.jpg
  13449   Wed Nov 22 16:40:00 2017 KojiUpdateOptical LeversOplev "noise budget"

You may want to consult with the cryo Q people (Brittany, Aaron) for a Si QPD. If you want the same QPD architecture, I can look at my QPD circuit stock.

  13451   Wed Nov 22 19:20:01 2017 ranaUpdateOptical LeversOplev "noise budget"

too complex; just shoot straight from the HeNe to the QPD. We lower the gain of the QPD by changing the resistors; there's no sane reason to keep the existing 100k resistors for a 2 mW beam. The specular reflection of the QPD must be dumped on a black glass V dump (not some flimsy anodized aluminum or dirty razor stack)

  13452   Wed Nov 22 23:56:14 2017 gautamUpdateOptical LeversOplev "noise budget"

Do not turn on BS/ITMY/SRM/PRM Oplev servos without reading this elog and correcting the needful!

I've setup a test setup on the ITMY Oplev table. Details + pics to follow, but for now, be aware that

  1. I've turned off the HeNe that is used for the SRM and ITMY Oplev.
  2. Moved one of the HeNe's Steve setup on the SP table to the ITMY Oplev table.
  3. Output power was 2.5mW, whereas normal power incident on this PD was ~250uW.
  4. So I changed all transimpedance gains on the ITMY Oplev QPD from 100k to 10k thin film - these should be changed back when we want to use this QPD for Oplev purposes again. Note that I did not change the compensation capacitors C3-C6, as with 10k transimpedance, and assuming they are 2.2nF, we get a corner frequency of 6.7kHz. The original schematic recommends 0.1uF. In hindsight, I should have changed these to 22nF to keep roughly the same corner frequency of ~700Hz.
    I've implemented this change as of ~5pm Nov 23 2017 - C3-C6 are now 22nF, so the corner frequency is 676Hz, as opposed to 723Hz before... This should also be undone when we use this QPD as an Oplev QPD again...
  5. I marked the position of the ITMY Oplev QPD with sharpie and also took pics so it should be easy enough to restore when we are done with this test.
  6. I couldn't get the HeNe to turn on with any of the power supplies I found in the cabinet, so I borrowed the one used to power the BS/PRM. So these oplevs are out of commission until this test is done.
  7. There is a single steering mirror in a Polaris mount which I used to center the spot on the QPD.
  8. The specular reflection (~250uW, i.e. 10% of the power incident on the QPD) is dumped onto a clean razor beam stack. Steve can put in a glass beam dump on Monday.
  9. Just in case someone accidentally turns on some servos - I've disabled the inputs to the BS, PRM and SRM oplevs, and set the limiter on the ITMY servo to 0.

Here are some pics of the setup: https://photos.app.goo.gl/DHMINAV7aVgayYcf1.None of the existing Oplev input/output steering optics were touched. Steve can make modifications as necessary, perhaps we can make similar mods to the SRM Oplev QPD and the BS one to run the HeNe test for a few days...

Quote:

too complex; just shoot straight from the HeNe to the QPD. We lower the gain of the QPD by changing the resistors; there's no sane reason to keep the existing 100k resistors for a 2 mW beam. The specular reflection of the QPD must be dumped on a black glass V dump (not some flimsy anodized aluminum or dirty razor stack)

 

  13453   Thu Nov 23 18:03:52 2017 gautamUpdateOptical LeversOplev "noise budget"

Here are a couple of preliminary plots of the noise from a 20minute stretch of data - the new curve is the orange one, labelled sensing, which is the spectrum of the PIT/YAW error signal from the HeNe beam single bounce off a single steering mirror onto the QPD, normalized to account for the difference in QPD sum. The peaky features that were absent in the dark noise are present here.

I am a bit confused about the total sum though - there is ~2.5mW of light incident on the PD, and the transimpedance gain is 10.7kohm. So I would expect 2.5e-3 mW * 0.4A/W * 10.7 kV/A ~ 10.7V over 4 quadrants. The ADC is 16 bit and has a range +/- 10V, so 10.7 V should be ~35,000 cts. But the observed QPD sum is ~14,000 counts. The reflected power was measured to be ~250uW, so ~10% of the total input power. Not sure if this is factored into the photodiode efficiency value of 0.4A/W. I guess there is some fraction of the QPD that doesn't generate any photocurrent (i.e. the grooves defining the quadrants), but is it reasonable that when the Oplev beam is well centered, ~50% of the power is not measured? I couldn't find any sneaky digital gains between the quadrant channels to the sum channel either... But in the Oplev setup, the QPD had ~250uW of power incident on it, and was reporting a sum of ~13,000 counts with a transimpedance gain of 100kohm, so at least the scaling seems to hold...

I guess we wan't to monitor this over a few days, see how stationary the noise profile is etc. I didn't look at the spectrum of the intensity noise during this time.

Quote:

I've setup a test setup on the ITMY Oplev table. Details + pics to follow, but for now, be aware that

Here are some pics of the setup: https://photos.app.goo.gl/DHMINAV7aVgayYcf1.None of the existing Oplev input/output steering optics were touched. Steve can make modifications as necessary, perhaps we can make similar mods to the SRM Oplev QPD and the BS one to run the HeNe test for a few days...

 

 

Attachment 1: ITMY_P_noise.pdf
ITMY_P_noise.pdf
Attachment 2: ITMY_Y_noise.pdf
ITMY_Y_noise.pdf
  10348   Thu Aug 7 16:47:35 2014 ericqUpdateSUSOplev Checkup

 I noticed some weird behavior on the ETMY oplev that led me to check them all out. 

The short of it is that the ETMY oplev has a pretty small angular range, compared to the displays and other oplevs. I measured how much angular motion each oplev can sense before the beam no longer hits all four quadrants (thus losing the ability to sense).  This could account for some of the additional angular motion of the mirrors... maybe. 

Also, some of the QPD quadrants had offsets as big as 400 counts, thus distorting the zero point. Anyways, here are the angular ranges of each QPD, assuming the current urad/cnt calibrations are valid. 

EMTY

  • P: +- 25urad
  • Y +- 30urad

ITMY

  • P:+-160urad
  • Y:+-172urad

 

BS

  • P:+-43urad
  • Y:+-40urad

 

ITMX

(Note: ITMX's oplev pitch and yaw is almost 30 degrees off of the alignment sliders' pitch/yaw coordinates. Steve tells me this is due to the tight nature of getting the oplev beam to the mirror without clipping.)

  • P:+-110urad
  • Y:+-80urad

 

ETMX

  • P:+-45urad
  • Y:+-85urad

 

PRM

  • P:+-50urad
  • Y:+-45urad

 

SRM

  • P:+-80urad
  • Y:+-80urad

I wrote a script to zero all of the QPD quadrants' offsets (it lives in /scripts/OL) and have used it successfully. The oplev laser must  be off before using it. 

  6253   Fri Feb 3 20:19:38 2012 ranaUpdateSUSOplev QPD Sum Trends are suspicious

The attached trend shows a problem with the QPD sums.

Why are ETMX and ITMX so much lower than ETMY and ITMY? Are the laser's dying? Or is it the gain inside the QPD? Or the reflectivity of the coatings?

Steve - please check on Monday the laser powers and the ETM/ITM reflectivity for HeNe lasers. Maybe we have to increase the transimpedance gain in the heads.

Attachment 1: a.png
a.png
  6256   Mon Feb 6 11:07:21 2012 steveUpdateSUSOplev QPD Sum Trends are suspicious

Quote:

The attached trend shows a problem with the QPD sums.

Why are ETMX and ITMX so much lower than ETMY and ITMY? Are the laser's dying? Or is it the gain inside the QPD? Or the reflectivity of the coatings?

Steve - please check on Monday the laser powers and the ETM/ITM reflectivity for HeNe lasers. Maybe we have to increase the transimpedance gain in the heads.

ETMX and ETMY have 0.2 mW returning to their QPDs........so the gain must lower at  ETMX

ITMX laser 1103P has only 0.67 mW output and 0.025 mW returning to the QPD.

ITMX and ETMX oplev lanching paths  have lenses without AR coating. This is my fault. I will buy them.

          ETMX   0.2 mW           900 counts

         ITMX     0.025           1300

         SRM      0.04            2600

          BS      0.05            3500

          PRM     0.06            4000

         ETMY     0.2             9000

        ITMY      0.3            14500

Attachment 1: oplevsums.png
oplevsums.png
  9690   Wed Mar 5 09:52:31 2014 JenneUpdateSUSOplev Tuning - Cartoon cost function

Not a whiteboard, but here's a cartoon of my oplev cost function cartoon.  For the "maximize this area" and "minimize this area", I plan to use ratios between the curves, and then give those ratios to a sigmoid function.

CostFunctionOplev.pdf

 

 

  9700   Thu Mar 6 17:34:03 2014 ranaUpdateSUSOplev Tuning - Cartoon cost function

Quote:

CostFunctionOplev.pdf

 In addition, we have to make sure to not let the suspension DACs saturate and make sure that the impulse response time of the OL servo is short; otherwise the lock acquisition kicks or bumps can make it wiggle for too long.

  9680   Thu Feb 27 01:02:57 2014 JenneUpdateSUSOplev Tuning Party - round 1

[Jenne, Vivien]

We had an oplev tuning party this afternoon.  What we have learned is that we don't have a lot of intuition yet on tuning loops.  But, that was part of the point - to build some intuition. 

I took responsibility for the PRM, and Vivien took ITMX.  I think, in the end, all changes were reverted on ITMX, however Vivien took some data to try and make a computer-generated controller.  Before we got started, I locked and aligned the PRMI, and we centered the PRMI-relevant oplevs.

I moved my "boost bump" around a bit, to do more at higher frequencies, but had to sacrifice some of the "oomph", since it was starting to eat up too much phase at my UGF of ~8Hz.  I also made the stack resonant gain higher Q and lower height so that it didn't eat so much phase.  In the end, I have 25 degrees of phase margin, which isn't really great, but I do win a factor of 2 around 2 and 3 Hz.  Also, now I'm able to engage the 3.2 resgain at all, whereas with the previous filter shape I was not able to turn it on.

PRM_oplevTuning_26Feb2014.pdf

Maybe it's because I really want it to have helped, but I feel like the POP spot isn't moving as much when I'm locked on PRMI sidebands as it was earlier (we were seeing a lot of low frequency (few Hz) motion).  So, I think I did something good.

  9682   Thu Feb 27 22:25:29 2014 ranaUpdateSUSOplev Tuning Party - round 1 commentary

  in order to Win in Loop Tuning, you must draw a cartoon of the cost function on the whiteboard before starting. Some qualitative considerations from our Workshop:

  1. We want to use the oplev servo to reduce the motion of the mirror in the frequency band where the Oplev is quieter than the mirror, w.r.t. inertial space.
  2. We can estimate the true mirror motion by some simple stack / pendulum model and compare it to the Oplev noise (not the dark noise). There are several contributions to the mirror angular motion due to the cross-coupling in the stacks and pendula.
  3. Below ~0.2 Hz, we think that the oplev is not the right reference, but this is not quantitative yet.
  4. The high frequency noise in the OPLEV ERROR is definitely electronics + shot noise.
  5. We cannot increase the gain of the loop without posting some loop measurements (Bode + steps). Also have to post estimates of how much PRCL noise is being introduced by the Oplev feedback. Oplev feedback should make less length noise than what we have from seismic.

Give us a cost function in the elog and then keep tuning.

  13548   Mon Jan 15 17:36:03 2018 gautamHowToOptical LeversOplev calibration

Summary:

I checked the calibration of the Oplevs for both ITMs, both ETMs and the BS. The table below summarizes the old and new cts->urad conversion factors, as well as the factor describing the scaling applied. Attachment #1 is a zip file of the fits performed to calculate these calibration factors (GPS times of the sweeps are in the titles of these plots). Attachment #2 is the spectra of the various Oplev error signals (open loop, so a measure of seismic induced angular motion for a given optic, and DoF) after the correction. Loop TF measurements post calibration factor update and loop gain adjustment to be uploaded tomorrow.

Optic, DoF Old calib [urad/ct] New Calib [urad/ct] Correction Factor [new/old]
ETMX, Pitch 200 175 0.88
ETMX, Yaw 222 175 0.79
ITMX, Pitch 122 134 1.1
ITMX, Yaw 147 146 1
BS, Pitch 130 136 1.05
BS, Yaw 170 176 1.04
ITMY, Pitch 239 254 1.06
ITMY, Yaw 226 220 0.97
ETMY, Pitch 140 164 1.17
ETMY, Yaw 143 169 1.18

Motivation:

We'd like for the Oplev calibration to be a reliable readback of the optic alignment. For example, a calibrated Oplev would be a useful diagnostic to analyze the drifting (?) ETMX.

Details:

  1. I locked and dither aligned the individual arms.
  2. I then used a 60 second ramp time to misalign <optic> in {ITMX, ITMY, BS, ETMX, ETMY} one at a time, and looked at the appropriate arm cavity transmission while the misalignment was applied. The amplitude of the misalignment was chosen such that in the maximally misaligned state, the arm cavity was still locked to a TEM00 mode, with arm transmission ~40% of the value when the cavity transmission was maximized using the dither alignment servos. The CDS ramp is not exactly linear, it looks more like a sigmoid near the start and end, but I don't think that really matters for these fits.
  3. I used the script OLcalibFactor.py (located at /opt/rtcds/caltech/c1/scripts/OL) to fit the data and extract calibration factors. This script downloads the arm cavity transmission and the OL error signal during the misalignment period, and fits a Gaussian profile to the data (X=oplev error signal, Y=arm transmission). Using geometry and mode overlap considerations, we can back out the misalignment in physical units (urad).

Comments:

  1. For the most part, the correction was small, of the order of a few percent. The largest corrections were for the ETMs. I believe the last person to do Oplev calibration for the TMs was Yutaro in Dec 2015, and since then, we have certainly changed the HeNes at the X and Y ends (but not for the ITMs), so this seems consistent.
  2. From attachment #2, most of the 1Hz resonances line up quite well (around 1-3urad/rtHz), so gives me some confidence in this calibration.
  3. I haven't done a careful error analysis yet - but the fits are good to the eye, and the residuals look randomly distributed for the most part. I've assumed precision to the level of 1 urad/ct in setting the new calibration factors.
  4. I think the misalignment period of 60 seconds is sufficiently long that the disturbance applied to the Oplev loop is well below the lower loop UGF of ~0.2Hz, and so the in loop Oplev error signal is a good proxy for the angular (mis)alignment of the optic. So no loop correction factor was applied.
  5. I've not yet calibrated the PRM and SRM oplevs.

Now that the ETMX calibration has been updated, let's keep an eye out for a wandering ETMX.

Attachment 1: OLcalib_20180115.tar.bz2
Attachment 2: Oplevs.pdf
Oplevs.pdf Oplevs.pdf
  5532   Fri Sep 23 17:57:34 2011 PaulUpdateSUSOplev filter optimization for 2 poles and 2 zeros

I have made a function to optimise the overall gain, pole frequencies and zero frequencies for the oplev filter. The script will optimize any user defined number of poles and zeros in order to minimise the RMS motion below a certain cut off frequency (in this case 20Hz). The overall gain is adjusted so that each trial filter shape always has a UGF of 10 Hz.

I have a attached a plot showing the power spectrum and RMS curves for the optimization result for 2 zeros and 2 poles, optimized to give a minimal RMS below 20Hz.

I have also attached a plot showing the loop gain and the filter transfer function.

The noise spectrum shows that the optimised filter gives a better noise performance below 10Hz, but a servo oscillation at the UGF of 10 Hz means it injects a lot of motion around this frequency. Should I consider some more aggressive way to force the script to keep a decent phase margin?

The fminsearch results show that the 'optimized' solution is two resonant peaks:

 

 -- Optimisation completed after 571 iterations--

 Started with: 

 Pole 1 frequency = 1 Hz 

 Pole 2 frequency = 2 Hz 

 Zero 1 frequency = 0.1 Hz 

 Zero 2 frequency = 5 Hz 

Overall gain = 1 

 Finished with: 

 Pole 1 frequency = 0.0497181 Hz 

 Pole 2 frequency = 2.01809 Hz 

 Zero 1 frequency = 0.0497181 Hz 

 Zero 2 frequency = 2.01809 Hz 

Overall gain = 71970.1 

 Initial RMS below 10 Hz = 5.90134e-06

 Remaining RMS below 10 Hz = 8.42898e-07

 

 

 

Attachment 1: optimised2p2z_v1.png
optimised2p2z_v1.png
Attachment 2: optimised2p2z_v1_TFs.png
optimised2p2z_v1_TFs.png
  5536   Sat Sep 24 01:51:02 2011 ranaUpdateSUSOplev filter optimization for 2 poles and 2 zeros

Quote:

I have made a function to optimise the overall gain, pole frequencies and zero frequencies for the oplev filter. The script will optimize any user defined number of poles and zeros in order to minimise the RMS motion below a certain cut off frequency (in this case 20Hz). The overall gain is adjusted so that each trial filter shape always has a UGF of 10 Hz.

I think this is a nice start. Its clear that we don't want to use this feedback law, but the technique can be tweaked to do what we want by just tweaking our cost function.

Let's move the scripts into the SUS/ scripts area and then start putting in weights that do what we want:

1) Limit the gain peaking at the upper UGF to 6 dB.

2) Minimum phase margin of 45 deg.

3) Minimum gain margin of 10 dB.

4) Lower UGF = 0.1 Hz / Upper UGF = 10 Hz.

5) Assume a A2L coupling of 0.003 m/rad and constrain the injected noise at the test mass to be less than the seismic + thermal level.

6) Looser noise contraint above 50 Hz for the non TM loops.

  5554   Tue Sep 27 08:51:29 2011 PaulUpdateSUSOplev filter optimization for 2 poles and 2 zeros

Quote:

Quote:

I have made a function to optimise the overall gain, pole frequencies and zero frequencies for the oplev filter. The script will optimize any user defined number of poles and zeros in order to minimise the RMS motion below a certain cut off frequency (in this case 20Hz). The overall gain is adjusted so that each trial filter shape always has a UGF of 10 Hz.

I think this is a nice start. Its clear that we don't want to use this feedback law, but the technique can be tweaked to do what we want by just tweaking our cost function.

Let's move the scripts into the SUS/ scripts area and then start putting in weights that do what we want:

1) Limit the gain peaking at the upper UGF to 6 dB.

2) Minimum phase margin of 45 deg.

3) Minimum gain margin of 10 dB.

4) Lower UGF = 0.1 Hz / Upper UGF = 10 Hz.

5) Assume a A2L coupling of 0.003 m/rad and constrain the injected noise at the test mass to be less than the seismic + thermal level.

6) Looser noise contraint above 50 Hz for the non TM loops.

 I moved two matlab scripts into the folder /cvs/cds/rtcds/caltech/c1/scripts/SUS/Oplev_filter_optimization

These are the function 'filter_optimiser_zeros_and_poles.m', and the example script to run the function 'run_filter_optimiser.m'. Type 'help filter_optimiser_zeros_and_poles.m' to get details about the function.

I haven't implemented the new weights yet. I've pasted them into the the file header to remind me/us of the work to be done on the function.

  11125   Mon Mar 9 18:10:59 2015 JenneUpdateASCOplev filters re-copied

Back on Feb 20th (elog 11056) Q replaced all of our oplev parts with the aLIGO version. 

Unfortunately, after this it has seemed like there was something not quite right with the optical lever servos.

  • When we would restore kicked optics, after the osem rms values come down the scripts try to engage the optical levers.  This would often kick and ring up the optics (I've seen this with ETMX and ETMY, and once or twice with the beam splitter)  Not good.
  • Sometimes, if the optic wasn't kicked, it would oscillate.  I would see this in particular with ETMY, by seeing the green transmission at the PSL table oscillating.
  • Q noticed that sometimes when the oplevs' outputs were turned off, the outputs were railed at the limiter values.

Since, when the models were changed which gave us an extra underscore in the oplev names, Q did a find-and-replace in the foton text files, I was worried that this might have broken things.  I'm not entirely sure how it would have broken them (I didn't see any difference in a diff), but I've heard enough horror stories about the delicacy of the foton text files.

Anyhow, I opened the last archived foton files from just before Q made the change, and copy-and-pasted the design strings from the old filter banks to the new ones.  Hopefully this fixes things.

  13497   Tue Jan 2 16:37:26 2018 gautamUpdateOptimal ControlOplev loop tuning

I've made various changes to the optimal loop design approach, but am still not having much success. A summary of changes made:

  1. Parametrization of filter - enforcing uniqueness
    • Previously, the input to the particle swarm was a vector of root frequencies and associated Q-factors.
    • This way of parametrization is not unique - permuting the order of the roots yield the same filter, but particles traversing the high (65) dimensional parameter space may have to go over very expensive regions in order to converge with the global minimum / best performing particle.
    • One way around this is to parametrize the filter by the highest pole/zero frequency, and then specifying the remaining roots by the cumulative separation from this highest root. This guarantees that a unique vector input to the particle swarm function specifies a unique filter.
    • To avoid negative frequencies, I manually set a particular element of the vector to 0 if the cumulative sum yields a negative frequency. I believe this is how MATLAB's particle swarm implements the "constraints" in the constrained optimization routines.
  2. Cost function - I've reformulated this into something that makes more sense to me, but probably can be improved further.
    • Term #1 - integral of the area (evaluated with MATLAB's trapz utility) between the in-loop (i.e. suppressed) error signal and the sensing noise spectrum (for the latter, I use the orange curve from this plot). This is a signed number, so that suppression below the sensing noise is penalized. Target value is 1 urad rtHz. One problem I see with this approach is that if we believe the sensing noise measurement, then even at 10mHz, it looks like sensing noise is below the out-of-loop error signal level. So the optimizer doesn't seem to want to make the loop AC coupled.
    • Term #2 - stability margin. I'm using this number, which is the distance-of-closest-approach to the point -1 in the Nyquist plot, instead of gain and phase margins, as this yields a more conservative robustness measure. Target value is 0.65.
    • Term #3 - A2L contribution of in-loop control signal. This contribution is calculated using measurements of A2L coupling for the DRMI. The actual term that goes into the cost function is the ratio of the area under the in-loop control signal to that under the seismic noise curve above 35Hz. Further, f>100Hz is given 10x the weight of 35Hz<f<100Hz (I've not really played around with this weighting function). The goal is to be as close to the seismic curve as possible, at which point this term becomes 1.
    • Terms #4 and #5 - the maximum open loop gain evaluated in a 1Hz wide bin centered around the bounce and roll resonances. The aim is to not exceed -40dB in these bins. Perhaps this needs to be reformulated, as the optimizer seems to be giving this term too much importance - the optimized loops have extremely deep bandstops around the BR resonances.
    • To normalize each term, I divide by the "target" value mentioned above, so as to make the various terms comparable.
    • Each term in the cost function has two regimes - one where it is rapidly varying close to the desired operating point, and one far away where the cost still increases monotonically, but slower (see Attachment #2).
    • A scalar cost function is evaluated by taking a weighted sum of the above terms. The weights are chosen so as to make each term ~10 for the controller currently implemented.
    • All of the above are only applicable if the resulting loop is stable - else, a large cost is assigned (exponential of sum of real parts of poles of OLTF).

Attachment #1 shows the outcome of a typical optimization run - so while I am having some more success with this than before, where the PSO algorithm was stalling and terminating before any actual optimization was done, it seems like I need to re-think the cost function yet again...

Attachment #2 shows the current terms entering the cost function, and their "desired" values.

The current version of the code I am using is here: although I may not have inculded some of the data files required to run it, to be fixed...

Attachment 1: loopOpt_180102_1706.pdf
loopOpt_180102_1706.pdf
Attachment 2: globalCosts.pdf
globalCosts.pdf
  13498   Wed Jan 3 12:33:16 2018 ranaUpdateOptimal ControlOplev loop tuning

When putting code into git.ligo.org, one way to have automated testing is to use the Gitlab CI. This is an automated 'checker', much like the 'Travis' system used in GitHub. Essentially, you give it a make files which it runs somewhere and your GIT repo web page gets a little 'failed/passing' badge telling you if its working. You can also browse the logs to see in detail what happened. This avoids the 'but it works on my computer!' thing that we usually hear.

Quote:

The current version of the code I am using is here: although I may not have inculded some of the data files required to run it, to be fixed...

 

  13500   Wed Jan 3 16:25:32 2018 awadeUpdateOptimal ControlOplev loop tuning

Another cool feature is client side pre-commit hooks. They can be used to run checks on the local version at the time of commit and refuses to push until the pass/fail exits 0.

Can be the same as the Gitlab CI or just basic code quality checks.  I use them to prevent jupyter notebooks being commited with uncleared cells. It needs to be set up on the user's computer manually and is not automatically cloned with the directory: a script can be included in the repo to do this and run manually on first time clone.

Quote:

When putting code into git.ligo.org, one way to have automated testing is to use the Gitlab CI. This is an automated 'checker', much like the 'Travis' system used in GitHub. Essentially, you give it a make files which it runs somewhere and your GIT repo web page gets a little 'failed/passing' badge telling you if its working. You can also browse the logs to see in detail what happened. This avoids the 'but it works on my computer!' thing that we usually hear.

 

  13520   Tue Jan 9 21:57:29 2018 gautamUpdateOptimal ControlOplev loop tuning

After some more tweaking, I feel like I may be getting closer to a cost-function definition that works.

  • The main change I made was to effectively separate the BR-bandstop filter poles/zeros and the rest of the poles and zeros.
  • So now the input vector is still a list of highest pole frequency followed by frequency separations, but I can specify much tighter frequency bounds for the roots of the part of the transfer function corresponding to the Bounce/Roll bandstops.
  • This in turn considerably reduces the swarming area - at the moment, half of the roots are for the notches, and in the (f0,Q) basis, I see no reason for the bounds on f0 to be wider than [10,30]Hz.

Some things to figure out:

  1. How the "force" the loop to be AC coupled without explicitly requiring it to be so? What should the AC coupling frequency be? From the (admittedly cursory) sensing noise measurement, it would seem that the Oplev error signal is above sensing noise even at frequencies as low as 10mHz.
  2. In general, the loops seem to do well in reducing sensing noise injection - but they seem to do this at the expense of the loop gain at ~1Hz, which is not what we want.
    • I am going to try and run the optimizer with an excess of poles relative to zeros
    • Currently, n(Poles) = n(Zeros), and this is the condition required for elliptic low pass filters, which achieve fast transition between the passband and stopband - but we could just as well use a less rapid, but more monotonic roll-off. So the gain at 50Hz might be higher, but at 200Hz, we could perhaps do better with this approach.
  3. The loop shape between 10 and 30Hz that the optimizer outputs seems a but weird to me - it doesn't really quite converge to a bandstop. Need to figure that out.
Attachment 1: loopOpt_180108_2232.pdf
loopOpt_180108_2232.pdf
  13289   Mon Sep 4 16:30:06 2017 gautamUpdateLSCOplev loop tweaking

Now that the DRMI locking seems to be repeatable again, I want to see if I can improve the measured MICH noise. Recall that the two dominant sources of noise were

  1. BS Oplev loop A2L - this was the main noise between 30-60Hz.
  2. DAC noise - this dominated between ~60-300Hz, since we were operating with the de-whitening filters off.

In preparation for some locking attempts today evening, I did the following:

  1. Added steeper elliptic roll-off filters for the ITMX and ITMY Oplevs. This is necessary to allow the de-whitening filters to be turned on without railing the DAC.
  2. Modified the BS Oplev loop to also have steeper high-frequency (>30Hz) roll off. The roll-off between 15-30Hz is slightly less steep as a result of this change.
  3. Measured all Oplev loop TFs - UGFs are between 4 Hz and 5 Hz, phase margin is ~30degrees. I did not do any systematic optimization of this for today.
  4. Went into the Foton filter banks for all the coil output filters, and modified the "Output" settings to be on "Input crossing", with a "Tolerance" of 10 and a "Timeout" of 3 seconds. These settings are to facilitate smooth transition between the two signal paths (without and with coil-dewhitening). The parameters chosen were arbitrary and not optimized in any systematic manner.
  5. After making the above changes, I tried engaging the de-whitening filters on ITMX, ITMY and BS with the arms locked. In the past, I was unable to do this because of a number of issues - Oplev loop shapes and Foton settings among them. But today, the switching was smooth, the single arm locks weren't disturbed when I engaged the coil de-whitening.

Hopefully, I can successfully engage a similar transition tonight with the DRMI locked. The main difference compared to this daytime test is going to be that the MICH control signal is also going to be routed to the BS.

Tasks for tonight, if all goes well:

  1. Lock DRMI.
  2. Use UGF servos to set the overall loop gains for DRMI DoFs.
  3. Reduce PRCL->MICH and SRCL->MICH coupling.
  4. Measure loop shapes of all DRMI DoFs.
  5. Make sensing matrix measurement.
  6. Engage coil-dewhitening, download data, make NB.

Unrelated to this work: the PMC was locked near the upper rail of the PZT, so I re-locked it closer to the middle of the range.

Quote:

Surprisingly, there was no evidence of REFL55 behaving weirdly tonight, and I was able to easily lock the DRMI on 1f error signals using the recipe I've been using in the last few months.

  9220   Tue Oct 8 08:58:16 2013 SteveUpdateSUSOplev power spectrums

Quote:

 Just plot.

RA: I'm not sure how to interperet this; I think that the SUM channel is divided by the SUM so that this is supposed to be RIN, but not sure. Can someone please take a look into the SUS model and then explain in the elog what the SUM normalization algorithm is?

 

PRM is dark. PRM and SRM oplev servos are off. ETMY is not centered.

Attachment 1: ITMoplevServoValues.png
ITMoplevServoValues.png
Attachment 2: oplevPSpectrums_darkPRM.png
oplevPSpectrums_darkPRM.png
Attachment 3: BSoplevServoValues.png
BSoplevServoValues.png
  9241   Tue Oct 15 15:25:13 2013 SteveUpdateSUSOplev power spectrums bandwidths

  Atm1 bandwidth 0.01 Hz ETMY plot is different from

Atm2 bandwidth 0.1 Hz  normal ???????    They should be the same !!!!

Attachment 1: BW0.01oplevPS.png
BW0.01oplevPS.png
Attachment 2: oplevPSetmXYclosed.png
oplevPSetmXYclosed.png
  9230   Thu Oct 10 11:30:15 2013 SteveUpdateSUSOplev power spectrums: PIT-YAW

 

Power spetrum of ETMX and ETMY in the view of oplev  pitch and yaw.

Attachment 1: PitYawOLetmXY.png
PitYawOLetmXY.png
  13971   Fri Jun 15 09:14:42 2018 SteveUpdateGeneralOplev sums

Oplev sums of 240 days.

Quote:

Since there have been various software/hardware activity going on (stack weighing, AUX laser PLL, computing timing errors etc etc), I decided to do a check on the state of the IFO.

  • c1susaux, c1aux and c1iscaux crates were keyed as they were un-telnet-able.
  • Single arm locking worked fine, TT alignment was tweaked (as these had drifted due to the ADC failure in c1lsc) to maximize Y arm transmission using the dither servos.
  • Arms weren't staying locked for extended periods of time. I particularly suspected ITMX, as I saw what I judged to be excess motion on the Oplev.
  • @Steve - ITMX and BS HeNes look like they are in need of replacement judging by the RIN (although the trend data doesn't show any precipitous drop in power). If we are replacing the BS/PRM Oplev HeNe, might be a good time to plan the inejction path a bit better on that table.
  • RIN in Attachment #1 has been normalized by the mean value of the OL sum channel. There is now a script to make this kind of plot from NDS in the scripts directory (as I found it confusing to apply different calibrations to individual traces in DTT).

 

Attachment 1: opSums.png
opSums.png
  7808   Tue Dec 11 09:31:47 2012 AyakaUpdateLSCOplev update for improving sensitivity

 Motivation

We observed that oplev servos affect the arm spectra badly (elog #7798). Some of them are fixed, but still they inject noise into the arms.
So I tried to turn the oplevs off and to see the acoustic noise effect. However, the mirrors moves so much that the signal does not seem to be linear any more, and the noise spectrum of arms changes especially around 60 - 100 Hz as you can see the spectrogram of YARM error signal below. This makes it difficult to find acoustic coupling noise. Therefore, I tried to fix the oplev servos so that the noise spectra do not get worse when the oplev servos are on.
POYspectrogram_nonoise.png

Checking oplev UGFs

I checked the oplev open loop transfer functions. The UGFs of oplevs are all around 1-3Hz and phase margin looks enough except the BS oplev.
The gain of the BS oplev OLTF has so low that the signal is not fed back. Moreover, there is much phase delay in the BS feedback loop than the others'.
The counts of BS oplev sum is not changed so much for this 4 months, so the oplev beam seems to hit the BS correctly.
I am not sure what makes difference.
ETMYoplev.pdfOL_BSoplevPIT.pdf

 BSoplev.pdf

 

Clipped oplev beam fixed

Den and I found the output beam of ETMY oplev was clipped the other day. Also I found the scattered beam of ITMY oplev was on the edge of the mirror inside the vacuum and it made more scattered lights.
ITMYoplev_before.jpg(before) -> IMG_0128.JPG(after)

  I fixed both of the clipped beam. But still the oplev feedback inject the noise into the arm. (red: oplev off, blue: oplev on)
   POYspe_oplev.pdf

  7812   Tue Dec 11 21:53:37 2012 AyakaUpdateLSCOplev update for improving sensitivity

[Rana, Ayaka]

The BS oplev pitch feedback came back.

OL_BSpit.pdf

The problem was that 300^2:0 filter was off. And I turned on all the low pass filters (ELP35), then the oplev servo does not seem to inject big noise into the arms as long as I see the spectra of POY and POX. These low-pass filters will be modified tomorrow so that the acoustic coupling noise is minimized.

BSoplevservo.png

  1234   Fri Jan 16 18:29:08 2009 YoichiUpdateSUSOplevs QPDs centered
Kakeru centered ITMX and BS optical levers with the help of Jenne on the walkie-talkie.
  6743   Fri Jun 1 14:56:08 2012 JamieUpdateSUSOplevs all different, messed up

For some reason the state of the oplevs is completely different for almost every suspension.  They have different sets of filters in the bank, and different filters engaged.  wtf?  How did this happen?  Is this correct?  Do we expect that the state of the oplevs should be different on all the different suspensions?  I wouldn't have thought so.

I discovered this because the PRM is unstable with the oplevs engaged.  I don't think it was yesterday.  Is something hidden changing the oplev settings?

Attachment 1: oplevs.png
oplevs.png
  6745   Fri Jun 1 19:48:54 2012 ranaUpdateSUSOplevs all different, messed up

 

 Its a good question, but the answer is yes. At some level all of the OL servos should be different to handle the different mechanical resonances of the suspension as well as the optical table's acoustic noise and the different noise requirements for the difference optical cavities.

However, it would be better to have the same basic structure and then one or two customization filters.

  16877   Thu May 26 19:55:43 2022 yutaConfigurationBHDOplevs centered, BHD DCPDs are now online

[Paco, Yuta]

We have aligned the IFO (except for LO-AS and GRY), and centered all the oplevs.
We have also restored Gautam's in-air BHD DCPD setup and placed it to ITMY table.
BHD DC PD signals are now online at C1:XO4-MADC1_EPICS_CH4 and CH5. 

Oplevs:
 Aligned the IFO following the steps in elog 40m/16875.
 When we were woking on BHD DCPDs, we lost REFL beam on camera and both arms flashing. Alignment was restored mostly with TT2 pitch.
 We centered all the oplevs after the recovery (see attached).

BHD DCPDs:
 1. We removed a circuit box with M2 ISS photodetector readout board from AP table, in-air BHD photodiodes from optics graveyard. (see LIGO-E2000436 and elog 40m/15493 for wiring diagram)
 2. Taken out temporary two Thorlabs PDA100A used for aligning LO-AS during the vent from ITMY table, and placed the BHD setup in ITMY table (see attached and attached).
 3. DB9 cable (15ft+10ft) was connected from M2 ISS box to anti-aliasing chassis for ADC1 of C1X04 at 1Y2 rack (see attached).
 4. +/-18V power for M2 ISS box was supplied from 1Y1 rack.
 5. BHD DCPD signals are now available at C1:XO4-MADC1_EPICS_CH4 and CH5 (see attached).

Next:
 - Tweak alignment of green Y input to follow Yarm
 - Do LO-AS alignment
 - Centering of PDs everywhere with IFO aligned
 - Update RTS model for BHD

Attachment 1: elog_1Y2.JPG
elog_1Y2.JPG
Attachment 2: elog_BHD.JPG
elog_BHD.JPG
Attachment 3: elog_box.JPG
elog_box.JPG
Attachment 4: Screenshot_2022-05-26_17-37-27_IFOaligned_OplevCentered.png
Screenshot_2022-05-26_17-37-27_IFOaligned_OplevCentered.png
Attachment 5: Screenshot_2022-05-26_20-35-02.png
Screenshot_2022-05-26_20-35-02.png
  2352   Fri Dec 4 21:48:01 2009 JenneUpdateoplevsOplevs centered, IP_POS and IP_ANG centered

[Jenne Koji]

 We aligned the full IFO, and centered all of the oplevs and the IP_POS and IP_ANG QPDs.  During alignment of the oplevs, the oplev servos were disabled.

Koji updated all of the screenshots of 10 suspension screens.  I took a screenshot (attached) of the oplev screen and the QPD screen, since they don't have snapshot buttons.

We ran into some trouble while aligning the IFO.  We tried running the regular alignment scripts from the IFO_CONFIGURE screen, but the scripts kept failing, and reporting "Data Receiving Error".  We ended up aligning everything by hand, and then did some investigating of the c1lsc problem.  With our hand alignment we got TRX to a little above 1, and TRY to almost .9 . SPOB got to ~1200 in PRM mode, and REFL166Q got high while in DRM (I don't remember the number). We also saw a momentary lock of the full initerferometer:   On the camera view we saw that Yarm locked by itself momentarily, and at that same time TRX was above 0.5 - so both arms were locked simultaneously.   We accepted this alignment as "good", and aligned all of the oplevs and  QPDs.

It seems that C1LSC's front end code runs fine, and that it sees the RFM network, and the RFM sees it, but when we start running the front end code, the ethernet connection goes away.  That is, we can ping or ssh c1lsc, but once the front end code starts, those functions no longer work.  During these investigations, We once pushed the physical reset button on c1lsc, and once keyed the whole crate.  We also did a couple rounds of hitting the reset button on the DAQ_RFMnetwork screen.

Attachment 1: Oplev_IPang_screenshot_4Dec2009.png
Oplev_IPang_screenshot_4Dec2009.png
  2353   Fri Dec 4 23:17:55 2009 robUpdateoplevsOplevs centered, IP_POS and IP_ANG centered

Quote:

[Jenne Koji]

 We aligned the full IFO, and centered all of the oplevs and the IP_POS and IP_ANG QPDs.  During alignment of the oplevs, the oplev servos were disabled.

Koji updated all of the screenshots of 10 suspension screens.  I took a screenshot (attached) of the oplev screen and the QPD screen, since they don't have snapshot buttons.

We ran into some trouble while aligning the IFO.  We tried running the regular alignment scripts from the IFO_CONFIGURE screen, but the scripts kept failing, and reporting "Data Receiving Error".  We ended up aligning everything by hand, and then did some investigating of the c1lsc problem.  With our hand alignment we got TRX to a little above 1, and TRY to almost .9 . SPOB got to ~1200 in PRM mode, and REFL166Q got high while in DRM (I don't remember the number). We also saw a momentary lock of the full initerferometer:   On the camera view we saw that Yarm locked by itself momentarily, and at that same time TRX was above 0.5 - so both arms were locked simultaneously.   We accepted this alignment as "good", and aligned all of the oplevs and  QPDs.

It seems that C1LSC's front end code runs fine, and that it sees the RFM network, and the RFM sees it, but when we start running the front end code, the ethernet connection goes away.  That is, we can ping or ssh c1lsc, but once the front end code starts, those functions no longer work.  During these investigations, We once pushed the physical reset button on c1lsc, and once keyed the whole crate.  We also did a couple rounds of hitting the reset button on the DAQ_RFMnetwork screen.

 A "Data Receiving Error" usually indicates a problem with the framebuilder/testpoint manager, rather than the front-end in question.  I'd bet there's a DTT somewhere that's gone rogue.

  2354   Sat Dec 5 01:40:11 2009 KojiUpdateoplevsOplevs centered, IP_POS and IP_ANG centered

We restarted daqd and it did restored the problem
http://lhocds.ligo-wa.caltech.edu:8000/40m/Computer_Restart_Procedures#fb40m
Then restart the 'daqd' process:'telnet fb40m 8087', type "shutdown" at the prompt. The framebuilder will restart itself in ~20s.

 

It did not related to the problem, but we also cleaned the processes related to dtt, dataviewer by pkill

After that the alignment scripts started to work again. As a result, we got some misalignment of the oplevs.
I am going to come on Sunday
- Align the optics
- Align the oplevs again
- Take snapshots for the suspensions
- Align the IP_POS, IP_ANG
- Align the aux laser for the absolute length
- Align PSL table QPDs, and MCT QPD

  2358   Sat Dec 5 18:23:48 2009 KojiUpdateoplevsOplevs centered, IP_POS and IP_ANG centered

NOTE: HEPA is on at its full.

[[[OK]]] Align the suspended optics (by Rob)
[[[OK]]]
Align the oplevs again
[[[OK]]] Take snapshots for the suspensions/QPDs/IO QPDs/PZT strain gauges
[[[OK]]] Align the IP_POS, IP_ANG
[[[OK]]] Align the PSL table QPDs, the MC WFS QPDs, and the MCT QPD
[[[OK]]] Align the aux laser for the absolute length 


Alignment of the aux laser

o Go to only ITMX mode:
Save the alignment of the mirrors. Activate X-arm mode. Misalign ITMY and ETMX.

o Inject the aux beam:
Open the shutter of the aux NPRO. Turn the injection flipper on.

o Look at the faraday output:
There are several spots but only one was the right one. Confirm the alignment to the thorlabs PD. Connect the oscilloscope to the PD out with a 50Ohm termination.
Thanks to the Alberto's adjustment, the beat was already there at around 10MHz. After the PD adjustment, the DC was about 600mV, the beat amplitude was about 50mVpp.

o Adjust the aux beam alignment:
Adjust the alignment of the aux beam by the steering mirrors before the farady isolator. These only change the alignment of the aux beam independently from the IFO beam.
After the alignment, the beat amplitude of 100mVpp was obtained.

o Closing
Close the shutter of the NPRO. Turn off the flipper mirror. Restore the full alignment of the IFO.

Attachment 1: Screenshot_091205_1830.png
Screenshot_091205_1830.png
  11142   Sat Mar 14 00:12:18 2015 ranaUpdateSUSOplevs huh?

The oplev situation still seems unresolved - notice this DTT. I guess there are still inconsistencies in the screens / models etc.

Could use some some investigation and ELOGGING from Eric.

Attachment 1: burp.png
burp.png
  6533   Fri Apr 13 01:27:10 2012 JenneUpdateSUSOplevs recentered

It's been a while since I think anyone has done it, and several optics were pretty far from centered, so I centered all of the oplevs except for SRM.

I am confident about my arm alignment, MICH and PRC (so BS, ITMX, ITMY, PRM, ETMX and ETMY), but I wasn't sure if I was getting SRC right, so I didn't touch the SRM's oplev.

Suresh removed all of the IPPOS measurement optics, so there was nothing blocking the BS and PRM oplevs.

However, the PRM oplev was ridiculously bad, and I don't know how long it's been that way.  Some of the optics shooting the beam into the chamber weren't optimally aligned, so the beam coming out of the chamber was hitting the lowest edge of the optic mount, for the first optic the beam encountered.  I adjusted the mirror launching the beam into the chamber by a teeny bit, so that the outcoming beam was ~horizontal and hitting the center of the first steering mirror in pitch.  I had to move that steering mirror a little to the right (if you are staring at the HR face of the mirror), to get the beam to come close to the horizontal center of the optic.  Then I proceeded to do normal oplev alignment.

Also, I've noticed lately that ITMX is noisier than all the other optics.  It's kind of annoying.  The sensor RMS values reported for the ITMX watchdogs for UL and LL are rarely below 2, and are often (~70% of the time?) above 3.  The SD RMS is a normal 1-ish.

  6744   Fri Jun 1 18:07:32 2012 steveUpdateSUSOplevs servo values

Quote:

For some reason the state of the oplevs is completely different for almost every suspension.  They have different sets of filters in the bank, and different filters engaged.  wtf?  How did this happen?  Is this correct?  Do we expect that the state of the oplevs should be different on all the different suspensions?  I wouldn't have thought so.

I discovered this because the PRM is unstable with the oplevs engaged.  I don't think it was yesterday.  Is something hidden changing the oplev settings?

 As of February 23, 2012 when oplev PIT and YAW transfer functions were taken

 

OPLEV SERVO 300^ 2:0 BR ELP RLP RES GAIN QPD counts OD mm           
                   
ETMY pit 300^ 2:0 BR 35 80 0.5 -1.5 15,500 ~1  
ETMY yaw 300^ 2:0 BR 35 80 0.6 -1.0      
ETMX pit 300^ 2:0 BR 35 80 0.5 0.5 1,500 ~1.5  
ETMX yaw 300^ 2:0 BR 35 80 0.6 1.0      
ITMY pit 300^ 2:0 BR   80   2.0 15,000 ~2.5  
ITMY yaw 300^ 2:0 BR   80   -4.0      
ITMX pit 300^ 2:0 BR   80   1.0 1,350 ~1.5  
ITMX yaw 300^ 2:0 BR   80   -2.0      
BS pit 300^ 2:0 BR 50     0.5 3,500 ~1  
BS yaw 300^ 2:0   50   3.3 -1.0      
PRM pit 300^ 2:0 BR     3.3 1.0 4,000 ~2  
PRM yaw 300^ 2:0 BR 35   3.3,  4 -0.5      
SRM pit 300^ 2:0 BR 40     -2.0 2,600 ~2.5  
SRM yaw 300^ 2:0 BR 40     2.0      

 

  6535   Sat Apr 14 00:19:35 2012 SureshOmnistructureLSCOptical Fibers for insitu RFPD characterisation

   I have worked out the fibers we need to get for the following distribution scheme:

1) We have a laser placed at the 1Y1 rack.  A part of the power is split off for monitoring the laser output and sent to a broadband PD also placed in the same rack.  The RF excitation applied to the laser is split and sent to LSC rack (1Y2) and used to calibrate the full PD+Demod board system for each RFPD.

2) A single fiber goes from the laser to a 11+ way switch located in the OMC electronics cabinet next to the AP table.  From here the fibers branch out to three different tables.

Table / Rack   RF PDs on the table Number of PDs Fiber Length from OMC
The AP table AS11,AS55,AS165,REFL11,REFL33,REFL55,REFL165 7 6 m
The ITMY table POY11 1 12 m
The ITMX table POX11, POP22/110 and POP55 3 20 m

 

Cable for the laser source to the OMC table:

The 1Y1 Rack to OMC rack AM Laser Source to Switch 25 m

We also require a cable going from PSL table to the ETMY table:   This is not a part of the RFPD characterisation.  It is a part of the PSL to Y-end Aux laser lock  which is a part of the green locking scheme.  But it is  fiber we need and might as well order it now along with the rest.

PSL Table to ETMY Table PSL to ETMY Aux laser 75m

 

If you would like to add anything to this layout / scheme, please comment.  On Monday Eric is going to take a look at this and place orders for the fibers.

(I have included the lengths required for routing the fibers and added another 20% to that ) 

 

  12695   Sun Jan 8 12:47:06 2017 ranaUpdateGeneralOptical Layout in DCC

Manasa pointed me to the CAD drawings in the 40m SVN and I've now uploaded them to the 40m DCC Tree so that EricG and SteveV can convert them into SolidWorks.

  12697   Mon Jan 9 16:12:30 2017 SteveUpdateGeneralOptical Layout in DCC

Caltech Facilities promissed to email the 40m facility drawings in Cad format.

I organized the old of optical , vacuum and facility layout drawings on paper in the old cabinet. 

Quote:

Manasa pointed me to the CAD drawings in the 40m SVN and I've now uploaded them to the 40m DCC Tree so that EricG and SteveV can convert them into SolidWorks.

 

Attachment 1: drawings_on_paper.jpg
drawings_on_paper.jpg
ELOG V3.1.3-