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.

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

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

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.

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

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

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.

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)

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

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.

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

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. 

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.

I ran two recently trained neural network controllers today between 10 am and Noon. Each test comprised of four segments:

• All loops open
• Linear loop closed
• Neural Network working alone
• Neural Network + Linear Loop

The latest controller unfortunately failed in both cases, working alone and working together with linear loop.

The second latest controller functioned well, keeping the arm locked throughout.

I've turned on NN controller for MC WFS PIT loops. One can disable this controller and go back to linear controller by sitemap>IOO>C1IOO_WFS_MASTER>Actions!>Stop Shimmer . One can start the controller again sitemap>IOO>C1IOO_WFS_MASTER>Actions!>Run Shimmer .

I'm going to get into the PSL enclosure. Also turn on the HEPA for a while during the intrusion.
Work done.

Start of the work:
(cds) ~>gpstime 
PDT: 2023-04-06 21:09:36.670623 PDT
UTC: 2023-04-07 04:09:36.670623 UTC
GPS: 1364875794.670623

End of the work:
(cds) ~>gpstime 
PDT: 2023-04-06 21:19:37.331716 PDT
UTC: 2023-04-07 04:19:37.331716 UTC
GPS: 1364876395.331716

Attached are the Rayleigh spectrograms of the error/control signal channels associated with the NN nonlinear control of IMC (pitch). The 4-hour data stretch starts at 3:45pm PDT on 4/18. The spectrograms were generated with (stride=5, fftlength=2, overlap=1). PNG images are attached for reference; the generated pdf files were too large to include here or send over email.

The Rayleigh statistic measures nongaussianity of the data.

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

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)

Broadband noise in:

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

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.

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

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

I drafted a calibrated LO Phase noise budget using diaggui whose template is saved under /opt/rtcds/caltech/c1/Git/40m/measurements/BHD/LO_PHASE_cal_nb.xml which includes new estimates for laser frequency and intensity noises at the LO phase when MICH is locked (whether they couple through MICH or the LO path is to be determined with noise coupling measurements in the near future, but we expect them to couple through the LO phat mostly).

Attachment #1 shows the result.

Laser Frequency Noise

To calibrate the laser frequency noise contribution, I used the LO PHASE error point away from the control bandwidth (~ 20 Hz) and the calibrated C1:IOO-MC_F control point (in Hz) which should represent the laser frequency noise above 100 Hz. and dithered MC2 at frequencies around to 130, 215, and 325 Hz to match the LO phase error point with the MC_F signal. I was expecting to use a single 0 Hz pole + gain (to get the phase equivalent of the laser frequency noise) but in the end I managed to calibrate with a single gain of 3.6e-7 rad/Hz and no pole. Since the way the laser frequency noise couples into our BHD readout may be complicated (especially when using BH55 RF sensor) I didn't think much of this for now.

Laser Intensity Noise

For the intensity noise, I followed more or less a similar prescription as for laser frequency noise. This time, I used the AOM in the PSL table to actuate on the 0th order intensity going into the interferometer. Attachments #2-3 show the connection made to the RF driver where I added a 50 mVpp sine (at an offset of 0.1 V) excitation in the AM port to inject intensity noise calibration lines at 215 and 325 Hz and matched the LO_PHASE error point with the BHDC_SUM noise spectrum.

• The slotted disks that capture the wires do not have the alignment bore used to center the wire in the hole
  
• We didn't correctly route the far field QPD cable so it runs funny
  
• We didn't have a tool which could be used to get two of the DCPD preamp box mounting screws (which are M3's chub!)
  
• We don't have the cable clamps to tie off the electrical cables to the intermediate mass
  
• We don't have any of the cabling from the OMC-SUS top to the rack so we can't test anything
  
• We haven't uploaded pretty pictures for all to see
  

• The bottom plate of the EQ stops is too thick so that it bumps into the tombstones
  
• The vertical member on the "waist" EQ stops is too close to the breadboard, possibly interfering with the REFL beam
  
• The "waist" EQ stops are made from a thin plate that doesn't have enough thickness to mount helicoils in
  
• Helicoil weren't loaded in the correct bottom EQ stops
  
• The DCPD cable loops over the end EQ stop looking nasty but not actually making contact
  

• ND10 and ND20 neutral density filter
  
• EOM and mount set for 4 inch beam height
  
• Post for fiber launch to get to 4 inch
  
• Mode matching lens at 4in
  
• 3x steering mirror at 4in
  
• RF photodiode at 4in
  
• Post for camera to 4in
  
• Light sheild for camera
  
• Long BNC cable
  

• DitherLock_sweep: Sweep of the IN2/IN1 for the dither lock error point showing 600 Hz UGF
  
• HiResPZTDither_sweep: Sweep of the PZT dither input compared to the PDH error signal. I restarted the front end before the sweep was finished accounting for the blip.
  
• HiResPZTDither_sweep2: Finish of the PZT dither sweep
  

• FIgure 1: PZT dither path. Most of the features in this plot are understood: There is a 2kHz high pass filter in the PZT drive which is otherwise flat. The resonance features above 5 kHz are believed to be the tombstones. I don't understand the extra motion from 1-2 kHz.
  
• Figure 2: PZT dither path zoom in. Since I want to dither the PZT to get an error signal, it helps to know where to dither. The ADC Anti-aliasing filter is a 3rd order butterworth at 10 kHz, so I looked for nice flat places below 10 KHz and settled on 8 kHz as relatively harmless.
  
• Figure 3: PZT LSC path. This path has got a 1^2:10^2 de-whitening stage in the hardware which hasn't been digitally compensated for. You can see its effect between 10 and 40 Hz. The LSC path also has a 160 Hz low path which is visible causing a 1/f between 200 and 500 Hz. I have no idea what the 1 kHz resonant feature is, though I am inclined to point to the PDH loop since that is pretty close to the UGF and there is much gain peaking at that frequency.