40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 238 of 344 Not logged in
ID Date Author Type Category Subject
3033   Wed Jun 2 07:54:55 2010 steveUpdateMOPAlaser headtemp is up

Is the cooling line clogged? The chiller temp is 21C See 1 and 20 days plots

3035   Wed Jun 2 11:28:31 2010 KojiUpdateMOPAlaser headtemp is up

Last night we stopped the air conditioning. It made HDTEMP increase.
Later we restored them and the temperature slowly recovered. I don't know why the recovery was so slow.

 Quote: Is the cooling line clogged? The chiller temp is 21C See 1 and 20 days plots

3108   Wed Jun 23 17:48:16 2010 steveUpdateMOPAlaser head temp

The laser chiller temp is fluctuating and the power output is decreasing. See 120 days plot.

Yesterday I removed ~300cc water from the overflowing chiller tank.

3130   Tue Jun 29 08:41:06 2010 steveUpdateMOPAMOPA is dead

I found the laser dead this morning.

The crane people are here to unjam it.

Laser hazard mode is lifted and LASER SAFE MODE is in place. No safety glasses but CRANE HAZARD is still active.

Stay out of the 40m lab !

3132   Tue Jun 29 10:20:58 2010 ranaUpdateMOPAMOPA is NOT dead

Not dead. It just had a HT fault. You can tell by reading the front panel. Cycling the power usually fixes this.

3137   Tue Jun 29 16:44:12 2010 Jenne, ranaUpdateMOPAMOPA is NOT dead, was just asleep

 Quote: Not dead. It just had a HT fault. You can tell by reading the front panel. Cycling the power usually fixes this.

MOPA is back onliine.  Rana found that the fuse in the AC power connector's fuse had blown.  This was evident by smelling all of the inputs and outputs of the MOPA controller. The power cord we were using for this was only rated for 10A and therefore was a safety hazard. The fuse should be rated to blow before the power cord catches on fire. The power cord end was slightly melted. I don't know why it hadn't failed in the last 12 years, but I guess the MOPA was drawing a lot of extra current for the DTEC or something due to the high temperature of the head.

We got some new fuses from Todd @ Downs.

The ones we got however were fast-blow, and that's what we want  The fuses are 10A, 250V.  The fuses are ~.08 inches long, 0.2 inches in diameter.

3202   Tue Jul 13 10:02:30 2010 steveUpdateMOPAlaser power is dropping slowly

I have just removed an other 400 cc of water from the chiller.  I have been doing this since the HTEMP started fluctuating.

The Neslab bath temp is 20.7C, control room temp 71F

3577   Wed Sep 15 16:00:26 2010 koji, steveUpdateMOPA

We removed the Lightwave MOPA Controller from 1X1 (south)  It was a real painfully messy job to pull out the umbilical.

Note: the umbilical is shading it plastic cover. It is functional but it has to be taken out side and cleaned. Do not remove it from it's plastic bag in a clean environment.

Now Joe has room for IOO chassy  in this rack.

We also removed the Minco temp controller and ref. cavity ion pump power supply.

3578   Wed Sep 15 16:12:35 2010 koji, steveUpdateMOPAMOPA Controller is taken out of the PSL rack

We removed the Lightwave MOPA Controller, PA#102, NPRO206 power supply to make room for the IOO chassy at 1X1 (south) rack.

The umbilical cord was a real pain to take out. It is shading its plastic cover. The unused Minco was disconnected and removed.

The ref. cavity ion pump controller- power supply was temporarily taken out also.

1195   Fri Dec 19 11:29:16 2008 Alberto, YoichiConfigurationMZMZ Trans PD
Lately, it seems that the matching of the input beam to the Mode Cleaner has changed. Also, it is drifting such that it has become necessary to continuously adjust the MC cavity alignment for it to lock properly.

Looking for causes we stopped on the Mach Zehnder. We found that the monitor channel:
C1:PSL-MZ_MZTRANSPD

which supposedly reads the voltage from some photodiode measuring the transmitted power from the Mach Zehnder, is totally unreliable and actually not related to any beam at all.

Blocking either the MZ input or output beam does not change the channel's readout. The reflection channel readout responds well, so it seems ok.
2006   Sat Sep 26 13:55:20 2009 JenneUpdateMZMZ was locked in a bad place

I found the MZ locked in a bad place earlier today.  It was locked in a similarly bad spot yesterday after we fixed the cable situation for 126MOPA_126MON, with reflection of ~0.8, rather than the nominal 0.305.  It's good now though.

2017   Tue Sep 29 10:44:29 2009 KojiUpdateMZMZ investigation

Rana, Jenne, Koji

Last night we checked MZ. The apparent thing we found was the gain slider does not work.
The slider actually changes the voltage at the cross connection of 1Y2 (31 pin4?), the gain does not change.
The error spectrum didn't change at all even when the slider was moved.

Rana poked the flat cable at the bottom of 1Y2, we had no imporvement.

We coudn't find the VME extender board, so we just replaced AD602 (=VGA) and LT1125 (=Buffer for the ctrl voltage).
Even after the replacement, the gain slider is not working yet.

Today, I will put a lead or probe to the board to see whether the slider changes the voltage on the board or not.

Somehow the gain is sitting at a intermediate place that is not to low not to high. So I still don't know the gain slider
is the cause of the MZ instability or not.

2018   Tue Sep 29 12:47:08 2009 KojiUpdateMZMZ unlocked

12:45 I started the work on MZ. Thus the MZ was unlocked.

Found the bad connection on the FLKM 64pin cross connection board. We need a replacement.

I went to Wilson and got the replacement, two VME extender boards, three 7815, and three 7915. Thanks, Ben!

2020   Tue Sep 29 18:21:41 2009 KojiUpdateMZMZ work done

The MZ work completed. I replaced the bad cross connection terminal. The gain slider is working now.

I looked at the error spectrum on an FFT analyzer. I could see the lock was more tight.

Then I proceeded to the MZ epics panel.

1) C1:PSL-MZ_MZTRANSPD has no meaning (not connected). So I put  C1:PSL-ISS_INMONPD as the MZ trans monitor.

2) The EPICS setting for the MZ gain slider was totaly wrong.
Today I learned from the circuit, the full scale of the gain slider C1:PSL-MZ_GAIN gave us +/-10V at the DAC.
This yield +/-1V to V_ctrl of the AD602 after the internal 1/10 attenuation stage.
This +/-1V didn't correspond to -10dB~+30dB, but does -22dB~+42dB and is beyond the spec of the chip.

The gain of AD602 is calculated by

G [dB] = 32 V_crtl + 10,  for -0.625 [V]< V_ctrl < +0.625 [V].

In order to fix this I used the following commands which overrode the EPICS parameters.
The tip of EGUF/EGUL is to know how much the gain (virtually) goes for the full scale of the DAC output.

ezcawrite C1:PSL-MZ_GAIN.EGUF 42 ezcawrite C1:PSL-MZ_GAIN.EGUL -22 ezcawrite C1:PSL-MZ_GAIN.DRVH 30 ezcawrite C1:PSL-MZ_GAIN.DRVL -10 ezcawrite C1:PSL-MZ_GAIN.HOPR 30 ezcawrite C1:PSL-MZ_GAIN.LOPR -10

and for the permanent change I modified the db file /cvs/cds/caltech/target/c1iool0/c1iooMZservo.db
This will be active when cliool0 is rebooted.

# This yields the output limited to -6.25V ~ +6.25V, which corresponds to -10dB ~ +30dB # modified by Koji Arai (29-Sept-2009) grecord(ao,"C1:PSL-MZ_GAIN") {         field(DESC,"GAIN- overall pre-modecleaner servo loop gain")         field(SCAN,"Passive")         field(PINI,"YES")         field(DISV,"1")         field(DTYP,"VMIVME-4116")         field(OUT,"#C3 S5 @")         field(EGUF,"42")         field(EGUL,"-22")         field(PREC,"1")         field(EGU,"dB")         field(HOPR,"30")         field(LOPR,"-10")         field(DRVH,"30")         field(DRVL,"-10")         field(LINR,"LINEAR")         field(OROC,"0")         field(DOL,"0") }

# previous code grecord(ao,"C1:PSL-MZ_GAIN") {         field(DESC,"GAIN- overall pre-modecleaner servo loop gain")         field(SCAN,"Passive")         field(PINI,"YES")         field(DISV,"1")         field(DTYP,"VMIVME-4116")         field(OUT,"#C3 S5 @")         field(EGUF,"30")         field(EGUL,"-10")         field(PREC,"4")         field(EGU,"Volts")         field(HOPR,"30")         field(LOPR,"-10")         field(LINR,"LINEAR")         field(OROC,"0")         field(DOL,"0") }

 Quote: 12:45 I started the work on MZ. Thus the MZ was unlocked. Fond the bad connection on the FLKM 64pin cross connection board. We need the replacement. I went to Wilson and got the replacement, two VME extender boards, three 7815, and three 7915. Thanks, Ben!

2021   Tue Sep 29 21:37:09 2009 ranaUpdateMZMZ work done : some noise checking

Since we used to run with a gain slider setting of +15 dB on the MZ, I wanted to check that the new setting of +30dB was OK. It is.

To check it I turned it up and looked for some excess noise in the ISS or in the MC. There was none. I also set the input offset slider by unlocking the PMC and zeroing the mixer monitor readback. The new slider setting is -6.5V.

I don't know why we would need more gain on the MZ loop, but we can have some if we want it by turning up the gain before the servo (optical or RF). The attached plot shows the MC_F and ISS signals with the ISS loop on and off. There was no change in either of these spectra with the MZ gain high or low.

2022   Tue Sep 29 21:51:32 2009 KojiUpdateMZMZ work done : some noise checking

The previous "+15" was Vctrl = 0.25 [V]. Which was +18 dB.

 Quote: Since we used to run with a gain slider setting of +15 dB on the MZ, I wanted to check that the new setting of +30dB was OK.

2023   Tue Sep 29 22:51:20 2009 KojiUpdateMZPossible gain mis-calibration at other places (Re: MZ work done)

Probably there is the same mistake for the PMC gain slider. Possibly on the FSS slider, too???

 Quote: 2) The EPICS setting for the MZ gain slider was totaly wrong.     Today I learned from the circuit, the full scale of the gain slider C1:PSL-MZ_GAIN gave us +/-10V at the DAC.     This yield +/-1V to V_ctrl of the AD602 after the internal 1/10 attenuation stage.     This +/-1V didn't correspond to -10dB~+30dB, but does -22dB~+42dB and is beyond the spec of the chip.

2032   Thu Oct 1 09:36:09 2009 KojiUpdateMZMZ relocked (Re:suspention damping restored and MZ HV stuck)

MZ stayed unlocked. Now It was relocked.

 Quote: Earthquake  of magnitude 5.0  shakes ETMY loose. MC2 lost it's damping later.

2035   Thu Oct 1 13:12:41 2009 KojiUpdateMZMZ Work from 13:00-

I will investigate the MZ board. I will unlock MZ (and MC).

2038   Thu Oct 1 19:04:05 2009 KojiUpdateMZMZ work done (Re: MZ Work from 13:00-)

MZ work has been done. I did not change anything on the circuit.

Recently we observed that the MZ PZT output was sticking at a certain voltage. I found the reason.
Shortly to say "we must return the PZT Ramp offset to 0, after the lock"

I am going to write a MZ auto lock script someday, to do it automatically.

According to the resister values used in the circuit, the PZT HV output voltage is determined by the following formula:

V_PZT = 150 - 12 V_ctrl - 24 Vramp

Here the ramp voltage Vramp moves from -10V to +10V, the feedback control voltage V_ctrl moves from -13V to +13V.
The baseline offset of 150V is provided in the circuit board.

When V_ramp is 0, V_PZT runs from 0 to 300. This is just enough for the full scale of the actual V_PZT range,
that is 0V~280V.

If any Vramp offset is given, V_PZT rails at either side of the edges. This limits the actual range of the PZT out.

This is not nice, but is what happened recently.

 Quote: I will investigate the MZ board. I will unlock MZ (and MC).

2349   Mon Nov 30 19:23:50 2009 JenneUpdateMZMZ down

Came back from dinner to find the Mach Zehnder unlocked.  The poor IFO is kind of having a crappy day (computers, MZ, and I think the Mode Cleaner alignment might be bad too).

7418   Thu Sep 20 08:50:14 2012 MashaUpdateMachineLearningMachine Learning Update

Hi everyone,

I've been working a bit on neural network code for a controller, and thus far I have code that creates a reference plant neural network. This is necessary to perform a gradient-descent learning algorithm on a controller neural network (one that reads an error signal and outputs actuation force). Because the error signal is read after the previous output of the controller neural network has passed through the plant, in order to calculate the gradient, either the inverse of the plant needs to be calculated, or the plant can be simulated through a neural network, and the error signal can thus be back-propagated through the plant neural network to find the gradient with respect to the output (as opposed to with respect to the plant), and thus back-propagated through the controller network in order to learn.

I have uploaded to my directory a directory neural_plant. The most important file is reference_plant.c, which compiles with the command

gcc reference_plant.c -o reference_plant -lfann -lm

The code runs on a file called reference_plant.data, which consists of a series of delayed inputs i_1, i_2, i_3 ... i_{n - 1} of the plant signals and then an output that is i_{n}, the subsequent signal. Parallel streams may also be used, if more than one signal is to be read. The top of the file must contain the number of total training packets (input-output groups), followed by the number of inputs, and the number of outputs. reference_plant.c also has constant variables which specify the number of hidden neurons, which can be changed.

All of this code runs on the FANN library. If the code doesn't seem to be compiling, then it means the library might have to be downloaded and built from source.

Thus far, I have created my own plant in simulink (the driven, damped harmonic oscillator, as before), and obtained results of 0.0002929292 training MSE after 5 epochs (subsequently lowered to 0.000)  and 0.000 training error. This, however, is due to the fact that my plant is overly simple, and seems only to need 3 time-delayed plant signals, rather 31 to specify it (since all motion is second-order).

It should be fairly easy to use interferometer signals as input to this plant by just reading some signals and parsing them into time-delayed groups. (I tried this over the summer with my previous code, and it seemed to work, although I haven't accessed any of the channels to obtain data lately).

In terms of LIGO stuff this week, I'm going to be finishing up (writing) my final report, but please let me know if you have any comments or concerns.

Thanks!
7424   Thu Sep 20 22:52:38 2012 DenUpdateMachineLearningFeedback controller

 Quote: I have uploaded to my directory a directory neural_plant. The most important file is reference_plant.c, which compiles with the command

We would appreciate some plots. Learning curves of recurrent NN working as a plant are interesting. For harmonic oscillator your RNN should not contain any hidden layers - only 1 input and 1 output node and 2 delays at each of them. Activation function should be linear. If your code is correct, this configuration will match oscillator perfectly. The question is how much time does it take to adapt.

Does FANN support regularization? I think this will make your controller more stable. Try to use more advanced algorithms then gradient descent for adaptation. They will increase convergence speed. For example, look at fminunc function at Matlab.

7661   Fri Nov 2 13:20:35 2012 MashaUpdateMachineLearningFeedback controller

Quote:

 Quote: I have uploaded to my directory a directory neural_plant. The most important file is reference_plant.c, which compiles with the command

We would appreciate some plots. Learning curves of recurrent NN working as a plant are interesting. For harmonic oscillator your RNN should not contain any hidden layers - only 1 input and 1 output node and 2 delays at each of them. Activation function should be linear. If your code is correct, this configuration will match oscillator perfectly. The question is how much time does it take to adapt.

Does FANN support regularization? I think this will make your controller more stable. Try to use more advanced algorithms then gradient descent for adaptation. They will increase convergence speed. For example, look at fminunc function at Matlab.

Hi everyone,

I've been on break this week, so in addition to working at my lab here, I've done some NN stuff. In response to Den's response to my last post, I've included learning curve plotting capabilities,

I've explored all of the currently documented capabilities of FANN (Fast Artificial Neural Network - it's a C library) (most likely, there are additions to the library floating around in open-source communities, but I have yet to look into those). There is extensive FANN documentation on the FANN website (http://leenissen.dk/fann/html/files/fann-h.html), but I'll cut it down to the basics here:

FANN Neural Network Architectures

standard: This creates a fully connected network, useful for small networks, as in the reference plant case

sparse: This creates a sparsely connected network (not all of the connections between all neurons exist at all times), useful for large networks, but not useful in the reference plant case, since the number of neurons is relatively small

shortcut: This creates some connections in the network which skip over various hidden layers. Not useful in the harmonic oscillator case since there are no hidden layers. Probably won't be useful in a better-modeled referrence plant since this reduces the non-linear capabilities of the model.

FANN Training

TRAIN_INCREMENTAL: updates the weights after every iteration, rather than after each epoch. This is faster than the other algorithms for the reference plant.

TRAIN_BATCH: updates the weights after training on the whole set. This should not be used on batches of data for the reference plant, seeing as the time history dependence of the plant is smaller than the size of the entire data set.

TRAIN_RPROP: batch training algorithm which updates the learning parameter.

TRAIN_QUICKPROP: updates the learning parameter, and uses second derivative information, instead of just first derivative, for backpropagation.

FANN Activation Functions

FANN offers a bunch of activation functions, including a function FANN_ELLIOT, which is essentially the "signmoid like" activation function Den and I used this summer, which runs in the order of multiplication and addition. The function parameters (steepness) can also be set.

FANN Parameters

As usual, the learning parameter can be set. While over the summer we worked with lower learning parameters, in the case of the harmonic oscillator reference plant, since the error is low after the first iteration, higher learning parameters (0.9, for example), work better. However, this is a very isolated case, and, in general, lower parameters, though convergence is slower, produce more optimal results.

The learning momentum is another parameter that can be set - the momentum factor is a coefficient in the weight adjustment equation which allows for the difference in weights beyond the previous weight to be factored in. In the case of the reference plant, a higher learning momentum (0.9) is optimal, although in most cases, a lower learning momentum is optimal so that the learning curve doesn't oscillate terribly.

FANN does not explicitly include regularization, but this can be implemented by checking the MSE  at each iteration against the MSE at the n previous iterations, where n is the regularization parameter, and stopping training if there is no significant decrease (also determined by a parameter). The error bound I specified during training was 0.0001

The best result for the reference plant was obtained using FANN_TRAIN_INCREMENTAL, a "standard" architecture, a learning rate of 0.9 (as explained above) and a learning momentum of 0.9 (these values should NOT be used for highly non-linear and more complicated systems).

I have included plots of the learning curves - each title includes the architecture, the learning algorithm, the learning parameter, and the learning momentum if I modified it explicitly.

All of my code (and more plots!) can be found in /users/masha/neural_plant

On the whole, FANN has rather limited capabilities, especially in terms of learning algorithms, where it only has 4 (+ all of the changes one can make to parameters and rates). It is, however, much more intuitive to code with and faster han the Matlab NN library, although the later has more algorithms. I'll browse around for more open-source packages.

Best,

Masha

7267   Fri Aug 24 00:23:20 2012 DenUpdateModern Controlfeedback using LQG method

I did a simulation of linear quadratic gaussian (LQG) controller applied to local damping. The cost function was frequency shaped to have a peak at 1 Hz. This technique prevents the controller from adding sensor noise at high and very low frequencies.

Noise was simulated to have 1/f spectrum (seismic) multiplied by stack with a resonance at 4 Hz with Q=5.

7270   Fri Aug 24 13:22:19 2012 DenUpdateModern Controlcavity simulation

I did a simulation of a cavity, feedback signal was calculated using LQG controller. I assumed that there is not length -> angle coupling and 2 mirrors that form the cavity have the same equation of motions (Q and eigen frequencies are the same). Cost functional was chosen in such a way that frequencies below 15 Hz contribute much more then other frequencies.

Gains in the controller are calculated to minimize the cost functional.

This technique works well, but it requires full information about the system states. If we do not assume that cavity mirrors have the same equations of motion then we need to apply Kalman filter to approximate the position of one of the mirrors.

7412   Wed Sep 19 17:48:47 2012 DenUpdateModern ControlETMX

Time domain control using LQR technique is now applied to ETMX sus position. The plan was to do it for oplevs, I'll do it after the vent.

The cost function for state space variables was determined by TF  900 / (s + 30)^2. There was no penulty imposed for velocity, only for position. We can try that configuration as well.

7430   Sun Sep 23 22:40:48 2012 DenUpdateModern ControlMC_L locking

I've applied LQR approach to MC_L locking. Results show that LQR does not make MC_F signal smaller below 0.3 Hz in contrast with classical locking. This might indicate that in this frequency range we see sensing noise as LQR was provided with state-space model of MC only so it tries to reduce displacement noise. It is also possible that state-space model is not accurate enough.

7497   Sun Oct 7 23:39:10 2012 DenUpdateModern Controlstate estimation

I've applied online state estimation technique using Kalman filter to LQG controller. It helps to estimate states that we do not measure. I've considered MC2 local damping, we measure position and want to estimate velocity that we need for control. We can either differentiate the signal or apply state estimation to avoid huge noise injection at high frequencies. In state estimation we need to know noise covariance, I've assumed that LID sensor noise is 0.1 nm. Though covariance can be calculated better.

In the time-domain figure C1:SUS-MC2_SUSPOS_IN1 = MC2 postion, C1:SUS-MC2_SUSPOS_OUT = MC2 velocity obtained by differentiation, 2 other channels are estimations of position and velocity.

7499   Mon Oct 8 09:51:30 2012 ranaUpdateModern Controlstate estimation

I guess that the estimated state has the same low pass filter, effectively, that we use to low pass the feedback signal in SUSPOS. I wonder if there is an advantage to the state estimation or not. Doesn't the algorithm also need to know about the expected seismic noise transmission from the ground to the optic?

7503   Mon Oct 8 12:34:52 2012 DenUpdateModern Controlstate estimation

 Quote: I guess that the estimated state has the same low pass filter, effectively, that we use to low pass the feedback signal in SUSPOS. I wonder if there is an advantage to the state estimation or not. Doesn't the algorithm also need to know about the expected seismic noise transmission from the ground to the optic?

I think state estimation and optimal control are two different techniques that are often used together. Sometimes (as for pendulum) we can use LQG without state estimation as we need only position and velocity. But for more complex systems (like quad suspension) the states of all 4 masses can be reconstructed in some optimal way using information from only one of them if the dynamics is sufficiently well known. When current system states are measured/estimated we can apply control where all our filters are hidden.

The algorithm needs to know about expected seismic noise transmission from the ground to the optic, but it might be not very precise. I gave it some rough estimate, there are better ways to do it. I think that we'll understand whether we need state estimation or not when we'll move to more complex systems. Brett uses a similar approach for his modal control. Interesting if these methods + seismometer readings will be able to say if one of your sensors is noisier then others.

7714   Thu Nov 15 02:18:24 2012 DenUpdateModern ControlBS oplev

I've applied LQR feedback technique to BS oplev in pitch. I think the most inconvenient thing in using LQR controller is the amount of additional states created during cost function shaping. It requires 1 filter bank for each state. To avoid this I wrote state estimation code so all states are calculated inside one function.

On the plots below cost function and oplev feedback controller performance are shown.

8048   Fri Feb 8 23:22:48 2013 DenSummaryModern Controlprogress report

I wrote a small document on the application of LQG method to a Fabry-Perot cavity control.

10744   Mon Dec 1 20:12:52 2014 ericqUpdateModern ControlRebirth of CESAR / ESCOBAR

I've uploaded a note at T1400735 about a new implementation of CESAR ESCOBAR ideas I've been working on. Please send me any and all feedback, comments, criticisms!

Using the things I talk about in there, I was able to have a time domain simulation of a 40m arm cavity transition through three error signals, without hardcoding the gains, offsets, or thresholds for using the signals. Some results look like this:

I'm going to be trying this out on the real IFO soon...

10941   Mon Jan 26 21:10:04 2015 JenneUpdateModern ControlWaking up the OAF

I had a look at the OAF model today.

Somehow, the screens that we had weren't matching up with the model.  It was as if the screens were a few versions old.  Anyhow, I found the correct screens in /userapps/oaf/common/medm, and copied them into the proper place for us, /userapps/isc/c1/medm/c1oaf.  Now the screens seem all good.

I also added 2 PCIE links between the OAF and the SUS models.  I want to be able to send signals to the PRM's pitch and yaw.  I compiled and restarted both the oaf model and the sus model.

The OAF model isn't running right now (it's got the NO SYNC error), but since it's not something that we need for tonight, I'll fix it in the morning.

My thought for trying out the OAF is to look at the coherence between seismic motion and the POP DC QPD when the PRMI is locked (no arms).  I assume that the PRM is already handled in terms of angular damping (local and oplev), so the motion will be primarily from the folding mirrors.  Then, if I can feedforward the seismometer signal to the PRM to compensate for the folding mirrors' motion, I can use the DC QPD as a monitor to make sure it's working when we're PRMI-only locked, or at low recycling gain with the arms.  But, since I'm not actually using the QPD signal, this will be independent of the arm power increase, so should just keep working.

Anyhow, that's what my game plan is tomorrow for FF.  Right now the T-240 is settling out from its move today, and the auto-zero after the move.

10943   Tue Jan 27 14:00:05 2015 JenneUpdateModern ControlPRMI locked

PRMI is locked on sideband, starting ~4 minutes ago, to collect ASC/seismic data for feedforward.

10959   Fri Jan 30 02:57:03 2015 JenneUpdateModern ControlFirst try with PRCL ASC Wiener filtering

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

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

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

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

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

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

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

10967   Tue Feb 3 04:07:49 2015 JenneUpdateModern ControlMeasured PRM -> POP QPD TFs

Today (after centering the POP QPD), I measured the PRM to POP QPD transfer functions.  I am suspicious that this was part of my problem last week.  Since most of the angular noise is coming from the folding mirrors, but I can't actuate on them, I need to know (rather, the Wiener calculator needs to know) how actuating on the PRM will affect the spot at the POP QPD.

For the plots below, I have cut out any data points that have coherence less than 0.95. I may want to go back and fill in a little bit some of the areas (particularly around 3Hz) that I had trouble getting coherence in.

Using these to prefilter my witness data, I am failing to calculate a Wiener filter.  I have tried the Levinson algorithm, as well as brute-forcing it, but I'm too close to singular for either to work.  I am able to calculate a set of Wiener filters without the prefiltering, or with a dummy very simple prefilter, so it's not inherently in the calculators.  Separately, I can plot my vectfit-ed actuator TFs, and I can convert them to a discrete fiilter with the bilinear transform, and then use sosfilt to filter some white noise data, which comes out with the shape I expect.  So.  It's not inherently the filters either.  More work to do, when it's not 4am.

Here are the measured actuator transfer functions.  They were measured as usual with DTT, but since the measurement kept getting interrupted (MC unlock, or I wanted to add more integrations or more cycles), these are several different DTT files stitched together.  In both cases I am acuating PRM's ASC[pit, yaw] EXC point, and looking at the POP QPD.

10993   Tue Feb 10 02:55:29 2015 JenneConfigurationModern ControlQuacky filters

I discovered that somehow my Wiener filters that show up in Foton are not the same as what I have in Matlab-land.

I have plotted each of my 3 filters that I'm working with right now (T-240 X, Y and Z for PRCL Pitch) at several stages in the filter creation process.  Each plot has:

• Blue trace is the Wiener filter that I want, after the vectfit process.
• Green trace is the frequency response of the SOS filters that are created by autoquack (really, quack_to_rule_them_all, which is called by autoquack).  The only thing that happens in matlab after this is formatting the coefficients into a string for writing to foton.
• Red trace is the exported text file from foton.

It's not just a DC gain issue - there's a frequency dependent difference between these filters.  Why??

It's not frequency warping from changing between analog and digital filters.  The sample rate for the OAF model is 2048Hz, so the effect is small down at low frequencies.  Also, the green trace is already discretized, so if it were freq warping, we'd see it in the green as well as red, which clearly we don't.

Has anyone seen this before?  I'm emailing my seismic friends who deal in quack more than I do (BLantz and JKissel, in particular) to see if they have any thoughts.

Also, while I'm asking questions, can autoquack clear filters?  Right now I'm overwriting old filters with zpk([],[],1)'s, which isn't quite the same.  (I need this because the Wiener code needs more than one filter module to fit all of the poles I need, and it decides for itself how many FMs it needs by comparing the length of the poles vector with 20.  If one iteration needs 4 filter modules, but the next iteration only wants 3, I don't want to leave in a bogus 4th filter.

Here are the plots:

(The giant peak at ~35Hz in the Z-axis fiilter is what tipped me off that something funny was going on)

11186   Tue Mar 31 22:27:43 2015 JenneUpdateModern ControlPreliminary PRMI angular Wiener results

Before locking for the evening, I wanted to try again implementing the Wiener filters that I had designed back in Jaunary (elog 10959).

The problem then was that the newer version of Quack that I was using was doing weird things to me (elog 10993).  But, tonight I used the old quack3andahalf that we used to use for Wiener-related things, and that worked (for up to order 20 filters).  Actually, the pitch z-axis Wiener filter, when I copy the command string into Foton, says "Error" in the alternate box (the lower one).  I also get this error message if I try to put in filters that were greater than order 20, and have been split into several filters.  I'm not sure what's wrong, so for tonight I'm leaving out the pitch z-axis seismometer feed forward, and only using 20th order filters for all the rest.

So, pitch has feed forward signals from the T-240's x and y axes, and yaw has feed forward signals from all 3 seismometer channels.

At first, I just had the calculated Wiener filters, and a 10Hz lowpass, but the POP beam spot on the camera was getting slowly pushed away from the starting location.  So, I added a 0.01Hz cheby1 highpass filter, and that seems to have fixed that problem.  I need to go back to the simulations though, and see if this is going to cause extra noise to be injected (because of incorrect phase in the feed forward signal) at very low frequencies.  All 5 Wiener filter banks have a gain of -1.

I'm getting a factor of 4-5ish between 2Hz and 3Hz in both pitch and yaw.  What's interesting is that despite no direct angular suppression (as measured by the QPD) at higher frequencies, both POP22 and POPDC see improvement over a much broader range of frequencies.  I'll have to think about how to predict this RIN coupling in my budgets.

The time series data for these filters was collected 2 months ago, on the 29th of January.  So, it's nice to see that they work now too (although we have already seen that length feed forward signals are good over a many-month period).

In uncalibrated units (I need to calibrate the QPD to microrad, and should probably quote the PD signals in RIN), here is the plot.  Blue trace (taken first) was with the feed forward on. Red trace (taken immediately afterward) was with feed forward off. This data is all PRMI-only, locked on REFL165 using Koji's recipe from elog 11174, including changing REFL165 phase to -14deg (from the -110 I found it at) for the no-arms case.

PRMI_31Mar2015.pdf

11202   Sat Apr 4 17:54:03 2015 ranaUpdateModern ControlPreliminary PRMI angular Wiener results

This is a very cool result. I'm surprised that it can work so good. Please post what frequency dependent weighting you used on the target before running the Wiener code.

I think its important to tune it to keep the low frequencies from getting amplified by a factor of 10 (as they are in your plots). The seismometers are all just noise acting like thermometers and tilt sensors below 0.1 Hz. Temperature and tilt do not couple to our interferometer very much.

It also seems weird that you would need 20th order filters to make it work good. In any case, you can always split the SOS up into pieces before making the digital filters. For LLO, we used 3 buttons in some cases.

 Quote: Before locking for the evening, I wanted to try again implementing the Wiener filters that I had designed back in Jaunary (elog 10959).
11229   Tue Apr 21 01:17:13 2015 JenneUpdateModern ControlT-240 self-noise propagated through stack and pendulum

Going back to Wiener filtering for a moment, I took a look at what the T-240 noise level looks like in terms of pitch motion on one of our SOS optics (eg. PRM).

The self-noise of the T-240 (PSD, in dB referenced to 1m^2/s^4/Hz) was taken by pulling numbers from the Users Guide.  This is the ideal noise floor, if our installation was perfect.  I'm not sure where Kissel got the numbers from, but on page 13 of G1200556 he shows higher "measured" noise values for a T-240, although his numbers are already transformed to m/rtHz.

To get the noise numbers to meters, I use:  $\left[ \frac{\rm m}{\sqrt{\rm Hz}} \right] = \frac{\sqrt{10^{\frac{[\rm dB/\sqrt{Hz}]}{10}}}}{(2 \pi f)^2}$.  The top of that fraction is (a) getting to magnitude from power-dB and (b) getting to asd units from psd units.  The bottom of the fraction is getting rid of the extra 1/s^2.

Next I propagate this seismometer noise (in units of m/rtHz) to effective pendulum pitch motion, by propagating through the stacks and the transfer function for pos motion at the anchor point of the pendulum to pitch motion of the mirror (see eq 63 of T000134 for the calculation of this TF).   This gives me radians/rtHz of mirror motion, caused by the ground motion:

.

I have not actually calibrated the POP QPD, so I will need to do that in order to compare this seismometer noise to my Wiener filter results.

11310   Tue May 19 14:51:44 2015 ericqUpdateModern ControlBrushing up on Wiener Filtering

As part of preparing for the SURF projects this summer, I grabbed ~50 minutes of MCL and STS_1 data from early this morning to do a little MISO wiener filtering. It was pretty straightforward to use the misofw.m code to achieve an offline subtraction factor of ~10 from 1-3Hz. This isn't the best ever, but doesn't compare so unfavorably to older work, especially given that I did no prefiltering, and didn't use all that long of a data stretch.

Code and plot (but not data) is attached.

11313   Tue May 19 17:53:38 2015 ranaUpdateModern ControlBrushing up on Wiener Filtering

Good to see that misofw.m is still alive and well. Todo:

1. Apply weighting to the filter via time domain SOS prefiltering of the signals (see Jenne's code from the LLO Global FF paper)
2. Consider using some of the MC SUSPOS signals. Its not strictly legal, but I wonder if its responsible for out noise below 1 Hz.
3. Steve was in the midst of hooking up the Wilcoxones to get better subtraction at 5-15 Hz, but couldn't find cables. We need to hunt them down in W Bridge.
4. Attach one of the medium or big Lings to the MC2 chamber platform and see if we can do this in hardware without driving the suspension. WE want to use a DAC channel (from where?) and pipe it to the Ling using a medium high current drive. Might start with the 50 Ohm output of the SR560 and later use a BUF634 ala Crackle coil driver.
14603   Fri May 10 18:24:29 2019 gautamUpdateNoiseBudgetaligoNB

I pulled the aligoNB git repo to /ligo/GIT/aligoNB/aligoNB. There isn't a reqs.txt file in the repo so installing the dependencies on individual workstations to get this running is a bit of a pain. I found the easiest thing to do was to setup a virtual environment for the python3 stuff, this way we can run python2 for the cdsutils package (hopefully that gets updated soon). I'm setting up a C1 directory in there, plan is to budget some subsystems like Oplev, ALS for now, and develop the code for the eventual IFO locking. As a test, I ran the H1 noise budget (./aligonb H1), works, so looks like I got all the dependencies...

15047   Mon Nov 25 22:10:26 2019 shrutiUpdateNoiseBudgetDiagnostics

This is to help troubleshoot the excess noise measured earlier.

The following channels were measured at GPS times 1258586880 s and 1258597457 s, corresponding to low and high Power Recycling Gain (PRG) respectively.

Excess noise was seen between 25-110 Hz in the high PRG case when compared to the low PRG case in the following channels:

C1:LSC-CARM-IN1_DQ (shown in Attachment 1 where the reference is low PRG)

C1:ALS-Y_ERR_MON_OUT_DQ

C1:ALS-BEAT{X,Y}_FINE_PHASE_OUT_DQ

C1:SUS-ETM{X,Y} _SENSOR_{LL,LR,UL,UR}

C1:ALS-TRX_OUT_DQ

Surprisingly, it was also seen to a smaller extent in (refer Attachment 3)

C1:SUS-ITMX_SENSOR_{LL,LR,UL,UR}

A different type of noise spectrum, attributed to known electronic effects, was observed for

C1:SUS-ITMY_SENSOR_{LL,UL}    (refer Attachment 2)

These did not show any significant change in the noise spectrum:

C1:LSC-DARM-IN1_DQ (shown in Attachment 1 where the reference is low PRG)

C1:ALS-X_ERR_MON_OUT_DQ

C1:ALS-TRY_OUT_DQ

C1:SUS-ITMY_SENSOR_{LL,LR,UL,UR}

C1:SUS-ITMY_SENSOR_{LR,UR}  (refer Attachment 2)

C1:LSC-PO{X,Y}11_I_ERR_DQ

15300   Tue Apr 7 15:30:40 2020 JonSummaryNoiseBudget40m noise budget migrated to pygwinc

In the past year, pygwinc has expanded to support not just fundamental noise calculations (e.g., quantum, thermal) but also any number of user-defined noises. These custom noise definitions can do anything, from evaluating an empirical model (e.g., electronics, suspension) to loading real noise measurements (e.g., laser AM/PM noise). Here is an example of the framework applied to H1.

Starting with the BHD review-era noises, I have set up the 40m pygwinc fork with a working noise budget which we can easily expand. Specific actions:

• Updated the 40m fork to the latest pygwinc version (while preserving the commit history).
• Added a directory ./CIT40m containing the 40m-specific noise budget files (created by GV).
• Added an ipython notebook CIT40m.ipynb at the root level showing how to generate a noise budget.
• Integrated our DAC and seismic noise estimators into pygwinc.
• Marked the old 40m NB repo as obsolete (last commit > 2 yrs ago). Many of these noise estimates are probably stale, but I will work with GV to identify which ones can be migrated.

I set up our fork in this way to keep the 40m separate from the main pygwinc code (i.e., not added to as a built-in IFO type). With the 40m code all contained within one root-level directory (with a 40m-specific name), we should now always be able to upgrade to the latest pygwinc without creating intractable merge conflicts.

16152   Fri May 21 12:12:11 2021 PacoUpdateNoiseBudgetAUX PDH loop identification

[Anchal, Paco]

We went into 40m to identify where XARM PDH loop control elements are. We didn't touch anything, but this is to note we went in there twice at 10 AM and 11:10 AM.

16975   Wed Jul 6 19:58:16 2022 PacoSummaryNoiseBudgetXARM noise budget

[Anchal, Paco, Rana]

We locked the XARM using POX11 and made a noise budget for the single arm displacement; see Attachment #1. The noise budget is rough in that we use simple calibrations to get it going; for example we calibrate the measured error point C1:LSC-XARM_IN1_DQ using the single cavity pole and some dc gain to match the UGF point. The control point C1:LSC-XARM_OUT_DQ is calibrated using the actuator gain measured recently by Yuta. We also overlay an estimate of the seismic motion using C1:PEM-SEIS_BS_X_OUT_DQ (calibrated using a few poles to account for stack and pendulum), and finally the laser frequency noise as proxied by the mode cleaner C1:IOO-MC_F_DQ.

A couple of points are taken with this noise budget, apart from it needing a better calibration;

1. Overall the inferred residual displacement noise is high, even for our single arm cavity.
1. By looking at the sim OLTF in foton, it seemed that the single arm cavity loop TF could easily become unstable due to some near-UGF-funkiness likely from FM3 (higher freq boost), so we disabled the automatic triggering on it; the arm stayed locked and we changed the error signal (light blue vs gold (REF1) trace)
2. The arm cavity is potentially seeing too much noise from the IMC in the 1 to 30 Hz band in the form of laser frequency noise.
1. Need IMC noise budget to properly debug.
3. At high frequency (>UGF), there seem to be a bunch of "wiggles" which remain unidentified.
1. We actually tried to investigate a bit into these features, thinking they might have something to do with misalignment, but we couldn't really find significant correlation.

RXA edit:

1. we also noticed some weirdness in the calibration of MC_F v. Arm. We think MC_F should be in units of Hz, and Paco calculated the resulting motion as seen by the arm, but there was a factor of several between these two. Need to calibrate MC_F and check. In principle, MC_F will show up directly in ALS_BEATX (with the green PDH lock off), and I assume that one is accurately calibrated. Somehow we should get MC_F, XARM, and ALS_BEAT to all agree. JC is working on calibrating the Mini-Circuits frequency counter, so once that is done we will be in good shape.
2. we may need to turn on some MC_L feedback for the IMC, so that the MC length follows the NPRO frequency below ~20 Hz.
3. Need to estimate where the IMC WFS noise is in all of this. Does it limit the MC length stability in any frequency band? How do we determine this?
4. Also, we want to redo this noise budget today, whilst using AS55 instead of POX. Please measure the Schnupp asymmetry by checking the optimum demod phase in AS55 for locking Xarm v Yarm.
5   Fri Oct 19 16:11:38 2007 pkpOtherOMCOMC PZT response
Sam and I locked the laser to the OMC cavity and looked at the error signal as a function of the voltage applied to the OMC PZT.
Here are two plots showing the response as a function of frequency from 1 kHz to 100 kHz and another high-res response in the region of 4.5 kHz to 10 kHz.
ELOG V3.1.3-