40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 163 of 344  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  395   Sun Mar 23 00:43:08 2008 mevansHowToGeneralOnline Adaptive Filtering
I wrote a short document about the OAF running on the ASS. Since there is no BURT setup, I put a script in /cvs/cds/caltech/scripts to help with setting initial parameters: upass.
  7220   Fri Aug 17 16:58:06 2012 MashaUpdatePEMOnline Seismic Noise Classification - Part 1

Den and I decided to try to classify seismic signals in the frequency domain rather than the time domain. We looked at amplitude spectral density plots of all of the data in our set, and noted that there were noticeable differences in the frequency domain for midnight quiet, trucks, and earthquakes.

For example, here is the time series of quiet, midnight seismic noise as compared to the seismic noise at the peak of an earthquake - the earthquake signal is noticeably higher in the 1 - 3 Hz region. Likewise, for the truck signal, there are noticeable bumps that arise at 10 and 30 Hz during the peak of the truck's motion due to the resonant frequency of the truck bouncing on its wheels.

noises.png

We investigated this potential means of classification further by considering the linear separability of the power of our signals in various frequency bands. Below is a plot of the power of a normalized signal in the 0.1 - 3.0 Hz region vs. the power of the normalized signal in the 3.0 - 30.0 Hz region - calculated by means of fft and separation of the discrete resulting frequencies (in short, an ideal filter).

Seismic_Signal_Linear_Separability.png

There is rather clear linear separability of the normalized signals in this case, as two lines could potentially be drawn to separate trucks from quiet and earthquake in this case (with a few misclassified points due to quiet - since the lab isn't actually empty and quiet in the middle of the night, and man-made seismic disturbances to occur). The reason we have to normalize our signals lies in the fact that the data set had different gains for various seismometers at different times. Normalization not only allows us to use our data set for training effectively, but it also assures that the online classification, if the online signals are also normalized, will allow for variable seismometer gains in the future and still be able to classify signals.

I looked at the linear separability of our training set using various combinations of frequency bands, and deduced that the current separation in the BLRMS preforms best (coincidentally, since the BLRMS separations are just decades), which meant that we could use the current BLRMS system we have for online classification of seismic noise.

Thus, I built a neural network which performed classification with the following parameters:

- One hidden layer of 20 neurons

- Gradient descent backpropagation with learning parameter mu = 0.175

- Sigmoidal activation functions for each neuron (computationally achieved by a parametrized hyperbola rather than an actual hyper-tangent in order to save on computation time). 

- 5 inputs - the normalized fft^2 of the signal (since the root of a signal doesn't add linearly to 1) in the following frequency regions: 0.1 - 0.3, 0.3 - 1.0, 1.0 - 3.0, 3.0 - 10.0 and 10.0 - 30.0 Hz. Since this division was done through the (frequency, fft value) return in Matlab, the signal was essentially filtered ideally into these frequency bands.

- 3 output neurons representing an output vector, with desired output vectors of [1, 0, 0] for earthquake, [0, 1, 0] for truck, and [0, 0, 1] for quiet.

- 1,600,000 training epochs (batch backpropagation on all of the data)

Below is the best learning curve for this network, representing the total amount of inputs misclassified out of 224. The best result achieved was 30 misclassified signals out of 224. Obviously this is not ideal, but our data is not totally linearly separable. This could, however, be reduced with further iterations, but given the close to 0 slope of the learning curve between iteration number 1,000,000 and number 1,500,000, this could take a very long time.

 

3_Output_Learning_Curve.png

Thus, I trained the network, generated the weight vectors and optimal activation function parameters, and was ready to implement a feed-forward neural network (with no online training). My next e-log (Part 2) will be about this system and will be posted shortly.

  7221   Fri Aug 17 18:17:16 2012 MashaConfigurationPEMOnline Seismic Noise Classification - Part 2

As promised in previous e-log, this log is all about the current online seismic noise classification system.

While we had the BLRMS system already in place (which I helped make), Den realized that we would need better filters for the BLRMS channels, as we wanted a strong cut-off, but we also wanted a short step-response so that we could quickly classify seismic signals. Likewise, having a step response which oscillates is also undesirable as this could lead to false classifications of post-truck signal as trucks as a filter adjusts and then dips back down. Thus, after experimenting with many different filters, Den chose to use a combination of

chebyl("LowPass", 1, 1, 0.03)*chebyl("LowPass", 1, 1, 0.03)

as our low-pass filter. The step response and bode plot are below.

LP_RMS_Filter

 The next step was to write C code that would implement the feedforward neural network with my newly generated weights.

Next, I had to implement the code in the c1pem model, and normalize the inputs. Below is an overview of the model, and a close up of the C block section.

GUR1X_Model.png

 GUR1X_Model_Closeup.png

The above close-up includes the process of normalization (dividing by the square of the incoming signal), feeding through the neural network, and classifying.

Each seismometer channel set (GUR1X, GUR1Y, GUR1Z, GUR2X, GUR2Y, GUR2Z, STS1X, STS1Y, STS1Z) now has channels (and corresponding DQ channels) of the following form:

SEIS_CLASS : The class of seismic noise 1.0 means Earthquake, 0.5 means Quiet, and 0.0 means Truck. (There are only these 3 digital values).

SEIS_CLASS_EQ, SEIS_CLASS_TRUCK, SEIS_CLASS_QUIET: These channels represent the confidence of the neural network's classification. The class of the current signal will have an output of 1, where the other two channels will have an output between 0 and 1 representing the ratio of the neural network's output in that class neuron to the output in the classification vector neuron. To simply - suppose the neural network classified an earthquake. Ideally, the neural network output neurons would have the value [1, 0, 0], and SEIS_CLASS would equal 1.0 for earthquake. However, the output neurons probably read something along the lines of [0.9, 0.3, 0.5] - SEIS_CLASS is still 1.0, but SEIS_CLASS_EQ would be 1.0, and SEIS_CLASS_TRUCK would be 0.5 / 0.9 and SEIS_CLASS_QUIET would be 0.3 / 0.9. The lower the other two signals are, the better - this means that we are more confident in our classification.

The MEDM screen for this system (in the RMS system) has the following form for all seismometer channels (this one is GUR1X):

GUR1X_MEDM.png

These are the screens I edited earlier in the summer, with modifications. The bottom filter banks represent the norm of the seismometer signal, which we use to normalize the inputs to the neural network.

Here a close-up of the most important part:

GUR1X_MEDM_CLOSE_UP.png

The orange meter on the right points to the current signal type. Here it reads truck - this is ok because it's the middle of the day, and there are a lot of trucks around. The left side represents our confidence in the signal - the signal is classified as a truck, so the "Truck" bar is saturated. The quiet signal bar is very low, which is good since it means that the neural network thinks that it's definitely not quiet. The earthquake bar has some magnitude, since earthquake signals and trucks have some degree of linear non-separability.

How has this been performing? Firstly, all of the seismometer channels have the same classification readout, which is good. Last night, all of the classes were "quiet", with an "earthquake" which occurred when Den jumped around GUR1 to simulate an EQ. This morning it was on "truck" as expected. The filters are still not fine enough to detect individual trucks, but I will continue to monitor the performance over the coming days.

If anyone has ideas on how better to represent this information, please let me know. This was the first thing that came into my head that would work with my MEDM monitor options, and I'm open to suggestions!

  7223   Sat Aug 18 01:40:09 2012 MashaConfigurationPEMOnline Seismic Noise Classification Widget

I added a widget to the C1PEM_OVERVIEW MEDM screen. The screen shows the nine seismometer channels (GUR1, GUR2, and STS1 X, Y, and Z), the current signal class in dark red, and the overall confidence in the classification, as Rana suggested. The confidence indication thresholds range from 0.1 to 0.9, in intervals of 0.1. Basically, if a signal class is completely dark red, and the other two classes show only white, or, better yet, nothing at all, this means that we have a clear classification. If, however, the other regions have some yellow, or even red indicators, this means that we are not very confident in our signal classification.

Classification_Widget.png

This is a screenshot of the widget. The nine seismometer channels are classifying the signal as quiet, which is good both because it's the middle of the night, and because the nine seismometer signals somehow agree (I'd use the word correspond with one another, but that implies a strong level of coherence..). The confidence is high, seeing as there's little indication in the truck and earthquake regions (none whatsoever in the truck, meaning that the signal, given our classification method, could not possibly be a truck, and some in the earthquake region (below 0.1 of the quiet signal classification strength, however), possibly due to low seismic disturbance).

  8515   Tue Apr 30 23:04:23 2013 JenneConfigurationRF SystemOnly 4 25m cables ordered

I have found in the depths of the elog the (original?) list of fibers and lengths that were decided upon:  elog 6535.

In Suresh's elog, we were assuming that POP22 & POP110 would be served by a single PD.  This is still the nominal plan, although we (Rana is maybe still thinking about this in the back of his head?) think that it might not be feasible.  Riju and I were hoping to put a 4th fiber in the tubing so that we wouldn't have to add it later if POP22 & POP110 are eventually 2 separate PDs.  Anyhow, for now, all we have available are 3 fibers for the POX table, so that is what was installed this afternoon.

  1422   Tue Mar 24 13:54:49 2009 JenneUpdateSUSOp Levs Centered

ITMX, ITMY, BS, SRM, PRM op levs were all recentered.  ETM's looked okay enough to leave as-is. 

  6601   Thu May 3 22:37:44 2012 JenneUpdateGeneralOpLev 90-day trend

After fixing the PRM tonight, all of the oplevs look okay. 

.....except ITMX, which looks like it's power dropped significantly after the CDS upgrade.  To be investigated tomorrow.

  6602   Fri May 4 17:44:42 2012 JenneUpdateGeneralOpLev 90-day trend

Quote:

After fixing the PRM tonight, all of the oplevs look okay. 

.....except ITMX, which looks like it's power dropped significantly after the CDS upgrade.  To be investigated tomorrow.

 I had a look-see at ITMX's oplev.  I can't see any clipping, so maybe the power is just low?  One thing that was funny though is the beam coming directly from the laser.  There is the main, regular beam, and then there is a thin horizontal line of red light also coming straight out of the laser.  I don't know what to do about that, except perhaps put an iris right after the HeNe, to block the horizontal part?  I'm not sure that it's doing anything bad to the optic though, since the horizontal part gets clipped by other optics before the beam enters the vacuum, so there is no real irregularity on the beam incident on the QPD.

I realigned the oplev on the QPD, using last night's ITMX alignment + whatever drift it picked up over night, so it may need re-recentering after Xarm is nicely aligned.

  10735   Tue Nov 25 14:52:14 2014 ericqUpdateOptical LeversOpLev RINs

 At Rana's request, I've made an in-situ measurement of the RIN of all of our OpLevs. PSL shutter closed, 10mHz BW. The OpLevs are not neccesarily centered, but the counts on darkest quadrant on each QPD is not more than a factor of a few lower than the brightest quadrant; i.e. I'm confident that the beam is not falling off. 

I have not attached that raw data, as it is ~90MB. Instead, the DTT template can be found in /users/Templates/OL/ALL-SUM_141125.xml

Here are the mean and std of the channels as reported by z avg 30 -s, (in parenthesis, I've added the std/mean to estimate the RMS RIN)

SUS-BS_OLSUM_IN1 1957.02440999 1.09957708641 (5.62e-4)
SUS-ETMX_OLSUM_IN1 16226.5940104 2.25084766713 (1.39e-4)
SUS-ETMY_OLSUM_IN1 6755.87203776 8.07100449176 (1.19e-3)
SUS-ITMX_OLSUM_IN1 6920.07502441 1.4903816992 (2.15e-4)
SUS-ITMY_OLSUM_IN1 13680.9810547 4.71903560692 (3.45e-4)
SUS-PRM_OLSUM_IN1 2333.40523682 1.28749988092 (5.52e-4)
SUS-SRM_OLSUM_IN1 26436.5919596 4.26549117459 (1.61e-4)
 

Dividing each spectrum from DTT by these mean values gives me this plot:

 RIN.pdf

ETMY is the worst offender here...

  10488   Wed Sep 10 14:58:58 2014 JenneUpdateSUSOpLev test: New channels

Steve and EricG are moving their oplev test for aLIGO over to the SP table, so that we can have the SRM optical lever back.  

I have pulled out an Ontrak PSM2-10 position sensor and accompanying driver for the sensor.  This, like the POP QPD, has BNC outputs that we can take straight to the ADC.

In the c1pem model I have created 3 new filter modules:  C1:PEM-OLTEST_X, C1:PEM-OLTEST_Y, and C1:PEM-OLTEST_SUM.  I built, installed and restarted the model, and also restarted the daqd process on the frame builder.  On the AA breakout board on the 1X7 rack, these correspond to:

BNC # 29 = OLTEST_X

BNC # 30 = OLTEST_Y

BNC # 31 = OLTEST_SUM

By putting 1Vpp, 0.1Hz into each of these channels one at a time, I see on StripTool that they correspond as I expect.

Everything should be plug-and-play at this point, as soon as Steve is ready with the hardware.

  10496   Thu Sep 11 17:12:42 2014 SteveUpdateSUSOpLev test: old SP qpd connected

IP POS cable was swapped with old SP-QPD sn222 at the LSC rack.  So there is NO IP POS temporarily.

This QPDsn222 will be used the HeNe oplev test for aLIGO

 

  9349   Tue Nov 5 19:39:27 2013 JenneUpdateLSCOpLev time series

[Rana, Jenne]

We looked at the time series for all the oplevs except the BS, from last Tuesday night, during a time when we were building up the power in the arms.  We conclude from a 400 second stretch of data that there is not discernible difference in the amount of motion of any optic, when the cavities are at medium power, and when they're at low power.  Note however, that we don't have such a nice stretch of data for the really high powers, so the maximum arm power in these plots is around 5.  Both the TRX and TRY signals look fairly stationary up to powers of 1 or 2, but once you get to 4 or 5, the power fluctuations are much more significant.  So, since this isn't caused by any optic moving more, perhaps it's just that we're more sensitive to optic motion when we're closer to resonance in the arms.

However, from this plot, it looks like the ETMY is moving much more than any other optic.  On the other hand, ETMY has not ever been calibrated (there's an arbitrary 300 in there for the calibration numbers on the ETMY oplev screen).  So, perhaps it's not actually moving any more than other optics.  We should calibrate the ETM oplevs nicely, so we have some real numbers in there.  ETMX also only is roughly calibrated, relative to the OSEMs.  We should either do the move-the-QPD calibration, or a Kakeru-style pitch and yaw some mirrors and look at transmitted power.

Traces on this xml file have been filtered with DTT, using zpk([0],[0.03],1,"n").

OpLevs_during_PRMI_2arms.pdf

 

  7058   Tue Jul 31 15:24:53 2012 YaakovUpdateSTACISOpen loop gains and block diagram

First, a quick note on the PZT I thought I killed- it was most likely something in the high voltage amplifier that broke, since I put the amplifier in another STACIS with a working y-axis PZT and it still didn't work properly. Conclusion: something in the y-axis amplifier circuitry is broken, not the PZT itself.

Today I retook the open loop gains in the X and Z axes (Y axis out of commission for now, see above). With the loop open, I input a swept sine signal from 0.1 to 100 Hz, and measure the output of the geophones. This way all the transfer function that are present in the closed loop are present here as well: the transfer functions of the physical STACIS, the geophone pre-amplifier circuit, the high-voltage amplifier, and the PZT actuators.

Here is a block diagram showing what I am measuring, with the various transfer functions in blue boxes (the measurement is their product):

 stacis_block.bmp

x_OL.bmpz_OL.bmp

z_OL.fig

x_OL.fig

These open loop gains show there is gain of at least 10x from 2 to 80 Hz in the z-axis and 2 to 60 Hz in the x-axis. This is the region I was seeing isolation in when I switched to closed loop, which is consistent. These measurements were with all the pots in the geophone preamplifier set very low, so more gain (and thus isolation) is hypothetically possible if I find a way to stop the horizontal axes from becoming unstable at higher gains. There is unity gain at around 0.5 Hz and 100 Hz for the z-axis, but the phase is nowhere near 180 deg. at these points so there shouldn't be instability due to this. The peak at around 15 Hz is consistent with old records of the STACIS open loop gain.

  7061   Tue Jul 31 19:34:55 2012 KojiUpdateSTACISOpen loop gains and block diagram

With your definition of the open loop gain, G=+1 is the condition to have singularity in a closed loop transfer function 1/(1-G).

But this is not the sole criteria of the loop stability.
Basically, the closed loop transfer function should not have "unphysical" pole.
For more about loop instability, you should refer stability criteria in literature such as Nyquist's stability criterion.

Both of the X and Z loops look unstable with the current gain.

  17092   Fri Aug 19 14:46:32 2022 AnchalUpdateSUSOpen loop transfer function measurements for local damping loops of BHD optics

[Anchal, Tega]

As a first step to characterize all the local damping loops, we ran an open loop transfer function measurement test for all BHD optics, taking transfer function using band-limited (0.3 Hz to 10 Hz) gaussian noise injection at error points in different degrees of freedom. Plots are in the git repo. I'll make them lighter and post here.

We have also saved coherence of excitation at the IN1 test points of different degrees of freedom that may be later used to determine the cross-coupling in the system.

The test ran automatically using measSUSOLTF.py script. The script can run the test parallelly on all suspensions in principle, but not in practice because the cdsutils.getdata apparently has a limitation on how many real-time channels (we think it is 8 maximum) one can read simultaneously. We can get around this by defining these test points at DQ channels but that will probably upset the rtcds model as well. Maybe the thing to do is to separate the c1su2 model into two models handling 3 and 4 suspensions. But we are not sure if the limitation is due to fb or DAQ network (which will persist even if we reduce the number of testpoints on one model) or due to load on a single core of FE machines.

The data is measured and stored here. We can do periodic tests and update data here.


Next steps:

  • Run the test for old optics as well.
  • Fit the OLTF model with the measured data, and divide by the digital filter transfer function to obtain the plant transfer function for each loop.
  • Set maximum noise allowed in the local damping loop for each degree of freedom, and criteria for Q of the loop.
  • Adjust gains and or loop shape to reach the requirements on all the suspensions in a quantitative manner.
  • (optional) Add a BLRMS calculation stream in SUS models for monitoring loop performance and in-loop noise levels in the suspensions.
  • More frequency resolution, please. (KA)
  17096   Sat Aug 20 20:26:10 2022 AnchalUpdateSUSOpen loop transfer function measurements for local damping loops of Core optics

I made measurements of old optics OLTF today. I have reduced the file sizes of the plots and data now. It is interesting that it is allowed to read 9 channels simultaneously from c1mcs or c1sus models, even together. The situation with c1su2 is a bit unclear. I was earlier able to take measurements of 6 channels at once from c1su2 but not I can't read more than 1 channel simultaneously. This suggests that the limit is dictated by how much a single model is loaded, not how much we are reading simultaneously. So if we split c1su2 into two models, we might be able to read more optics simultaneously, saving time and giving us the ability to measure for longer.

Attached are the results for all the core optics. Inferences will be made later in the week.

Note: Some measurements have very low coherence in IN2 channels in most of the damping frequency region, these loops need to be excited harder. (eg PIT, POS, YAW, on ITMs and ETMs).

 

  17097   Mon Aug 22 14:36:49 2022 ranaUpdateSUSOpen loop transfer function measurements for local damping loops of Core optics

for damping and OL loops, we typically don't measure the TF like this because it takes forever and we don't need that detailed info for anything. Just use the step responses in the way we discussed at the meeting 2 weeks ago. There's multiple elog entries from me and others illustrating this. The measurement time is then only ~30 sec per optic, and you also get the cross-coupling for free. No need for test-point channels and overloading, just use the existing DQ channels and read back the response from the frames after the excitations are completed.

  2203   Sat Nov 7 23:50:45 2009 HaixingUpdateGeneralOpen-loop transfer function of the magnetic levitation system

I measured the open-loop transfer function of the magnetic levitation system.

The schematic block diagram for this measurement is the following:

transfer_function_meas_bd.PNG

I injected a signal at a level of 20mV between two preamplifiers, and the corresponding open-loop

transfer function is given by B/A.  I took a picture of the resulting measurement, because

I encountered some difficulties to save the data to the computer via the wireless network.

The bode plots for the transfer function shown on the screen is the following:

Transfer_function_meas.jpg

 

I am puzzled with the zero near 10 Hz. I think it should come from the mechanical response function, because there is no zero in the transfer functions

of the preamplifer and the coil itself. I am not sure at the moment.

The corresponding configuration of the levitated magnet is

magnetic_levitation.jpg

  7662   Fri Nov 2 14:37:36 2012 JenneUpdateGeneralOpen-sided mount - why

Quote:

Quote:

Suprema- SS clear edge mirror mount 2" diameter is modified for 40m vacuum use. One left and one right handed one. It's adjustment screw housing is bronze! It is not ideal for out gassing.

It will be baked and scanned. If it passes we should use it.

We may need these to bring out some pick-off beams.

 I vote against it. We don't know about the grease inside the screw bushings - scans are not everything if adjusting the screw loosens up the grease. If we need more pick off mirrors lets just make some of the kind that we already use inside for the 2" optics.

 I think Steve had these prepared in response to my question a few days ago of how badly do we need adjustability for the POX/POY mirrors?  We already have cleaned open-sided mounts that have no adjustment screws.  So as long as the beam reflects off the ITMs horizontally (which it should), we can do yaw adjustment by twisting the whole mount. We don't need super fine yaw adjustment, we just need to get the beam out, so this is probably good enough.

We should put the POY mirror on this open-sided mount (the one without screws) some time.  Perhaps even today.

  7663   Fri Nov 2 16:09:14 2012 SteveUpdateGeneralOpen-sided mount - why

Quote:

Quote:

Quote:

Suprema- SS clear edge mirror mount 2" diameter is modified for 40m vacuum use. One left and one right handed one. It's adjustment screw housing is bronze! It is not ideal for out gassing.

It will be baked and scanned. If it passes we should use it.

We may need these to bring out some pick-off beams.

 I vote against it. We don't know about the grease inside the screw bushings - scans are not everything if adjusting the screw loosens up the grease. If we need more pick off mirrors lets just make some of the kind that we already use inside for the 2" optics.

 I think Steve had these prepared in response to my question a few days ago of how badly do we need adjustability for the POX/POY mirrors?  We already have cleaned open-sided mounts that have no adjustment screws.  So as long as the beam reflects off the ITMs horizontally (which it should), we can do yaw adjustment by twisting the whole mount. We don't need super fine yaw adjustment, we just need to get the beam out, so this is probably good enough.

We should put the POY mirror on this open-sided mount (the one without screws) some time.  Perhaps even today.

 The hex adjustment screw  is removed from the brass bushing for degreasing, cleaning and baking. Newport says the  bushing is is brass not bronze.

Brass outgassing rate is 10x higher than copper that is truth. The surface area is small so  Krytox grease is ok if it is really needed in the 40m. ( It was ok in the past and it is still there )

  13056   Fri Jun 9 16:37:29 2017 jigyasaUpdateComputer Scripts / ProgramsOpenCV installation

OpenCV 3.1.0 has been installed by following the commands locally on Donatella

git clone https://github.com/Itseez/opencv.git
cd opencv
git checkout 3.1.0
git clone https://github.com/Itseez/opencv_contrib.git
cd opencv_contrib
git checkout 3.0.0
cd ~/opencv
mkdir release
cd release
cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local -D OPENCV_EXTRA_MODULES_PATH=/~/opencv_contrib/modules/ ~/opencv/

In ~/opencv/release, make and sudo make install were executed.

This completed the installation. The version of the installation was verified pkg-config --modversion opencv which showed 3.1.0. Also verified the import of cv2 module in python and it seems to work fine. 

 

  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.

  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.

  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.

 

  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.

 

  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...

 

 

  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.

  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

  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.

  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

 

 

 

  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...

  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.
ELOG V3.1.3-