40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 225 of 344  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  13367   Mon Oct 9 01:29:26 2017 gautamUpdateLSCDRMI Nosie Budget v3.0

Summary:

I spent this weekend doing a more careful investigation of the DRMI noise. I think I have some new information/insights. Attachment #1 is the noise budget (png attached because pdf takes forever to upload, probably some ImageMagick problem. The last attachment is a tarball of the PDF). Long elog, so here are the Highlights:

  1. Coil de-whitening does result in small improvement in noise in the 60-200Hz band.
  2. Above 200Hz, we seem to be limited by "Dark" noise. More on this below.
  3. The coupling from SRCL->MICH is the other limiting noise in the 60-200Hz band now.

Sensing Matrix Measurement:

  • I rotated the AS55 demod phase from -42 degrees to -82 degrees, the idea being to get more of the MICH error signal in AS55_Q.
  • Consequently, the MICH servo gain has been lowered from -0.035 to -0.021. Settings have been updated in the snap file used by the locking script.  
  • Seems to have worked.
  • Attachment #2 is the measured sensing elements.
  • One major source of uncertainty in these sensing element numbers is the actuator gains for PRM, SRM and BS. The coil driver electronics for the latter two have been modified recently, and for them, I am using numbers from this elog scaled by the expected factor as a result of removing the x3 gain in the de-whitening boards for SRM and BS.

MICH OLTF

  • Measurement was done in lock using the usual IN1/IN2 method.
  • Model made by loading the FOTON filters + assumed models for the BS pendulum and AA/AI filters in Matlab, and fitting to an overall gain + delay.
  • Attachment #3 shows the agreement between measurement and model.
  • The model was exported and used to invert in-loop signals to their out-of-loop counterparts in the noise budget.

DAC Noise

  • I had claimed that turning on the coil de-whitening did not improve the MICH noise.
  • This was not exactly true - I had only compared MICH noise with the BS de-whitening turned ON/OFF, while the ITM de-whitening was always on.
  • Turns out that there is in fact a small improvement - see Attachment #4 (DTT crashes everytime I try to print a pdf, so png screenshot will have to do for now).
  • I have also changed the way in which DAC noise is plotted in the Noise Budget code:
    • I used to directly convert the measured voltage noise (multiplied by appropriate scalar to account for quadrature sum of 4 coils each in 3 optics) to displacement noise using the sensing measurement cts/m values.
    • Now I convert the measured voltage noise first to current noise (knowing the series resistance), then to force noise (using the number 0.016 N/A per coil), then to displacement noise (assuming a mirror mas of 250g).
    • Quadrature sum is again taken for 4 coils on 3 optics.
  • I've also added the option to plot the DAC noise with the de-whitening filter TF applied (taking care that the maximum of filtered DAC noise / coil driver electronics noise is used at each frequency).
  • So the major source of uncertainty in the calculated DAC noise is the assumed actuator gain of 0.016 N/A.

The DAC noise is not limiting us anywhere when the coil de-whitening is switched on.


Dark Noise

I think this is the major find.

  • The dark noise spectrum is measured with:
    • the PSL shutter closed
    • the AS55 I and Q analog whitening filters (and corresponding digital de-whitening filters) engaged, to mimic the operating conditions under which the in-lock error signal is acquired.
  • Comparing the blue and black traces, it is clear that turning on the analog whitening is having some effect on the dark noise.
  • However, the analog whitening filters should suppress the ADC noise by ~30dB @ 100Hz - so assuming 1uV/rtHz, this would be ~30nV/rtHz @100Hz.
  • But the measured noise seems to be ~5x higher, with 4*10^-4 cts/rtHz translating to roughly 120nV/rtHz.
  • The photodiode dark noise is only 15nV/rtHz according to the wiki. Where is this measured?

So I don't understand the measured Dark Noise level, and it is limiting us at frequencies > 200Hz. Some busted electronics in the input signal chain? Or can the LSC demod daughter board gain of ~5 explain the observed noise?


Shot noise

  • The DC power on AS55 photodiode was measured to be ~13mW with the SRM misaligned.
  • This corresponds to ~100cts peak amplitude on the ASDC channel (derived from AS55 photodiode).
  • In the DRMI lock, the ASDC level is ~200cts.
  • I used these numbers, and equation 2.17 in Tobin's thesis, to calculate this curve.

Edit 1730 9 Oct: I had missed out the factor of 5 gain in the demod board in calculating the shot noise curve. Attachment #7 shows the corrected shot noise level. Explicitly:

n_{\mathrm{shot}} [m/\sqrt{\mathrm{Hz}}] = \alpha \sqrt{2 h \nu \bar{P} (\frac{1}{2} - \frac{1}{4}\mathrm{cos}2\theta)}, where \alpha [m/W] = (\mathcal{M}_{\mathrm{MICH}} [V/m] / 5 [V/V] / 420 [V/A] / 0.7 [A/W])^{-1}is to convert shot noise in W to displacement units.


AUX coupling

This is the other find.

  • While chatting with Gabriele, he suggested measuring the SRCL->MICH and PRCL->MICH cross couplings.
  • I injected a signal in SRCL servo EXC channel, and adjusted amplitude till coherence in MICH_IN1 was good.
  • The actual TF measured was MICH_IN1 / SRCL_IN1 (so units of cts/ct).
  • My multiplying the in-lock PRCL and SRCL IN1 signals by these coupling coefficients (assumed flat in frequency for now, note that measurement was only made between 100Hz and 1kHz), I get the trace labelled "AUX coupling" in Attachment #1 (this is the quadrature sum for SRCL and PRCL couplings).
  • Also repeated for PRCL -> MICH coupling in the same way.
  • Measurements of these TFs and coherence are shown in Attachment #5 (again png screenshot because of DTT).
  • However, there is no significant coherence in MICH/SRCL or MICH/PRCL in this frequency range.

This seems to be limiting us from saturating the dark noise once the coil de-whitening is engaged. But lack of coherence means the mechanism is not re-injection of SRCL/PRCL sensing noise? Need to think about what this means / how we can mitigate it.


OL A2L coupling

  • I didn't measure these
  • These couplings would have changed because I modified the Oplev loop shapes to allow engaging of coil de-whitening filters.
  • But anyways, their effect will only be below 100Hz because I made the roll-offs steeper.

Still to measure (but not likely to be limiting us anywhere in the current state):

  • Laser intensity noise -> MICH coupling (using AOM).
  • Laser frequency noise -> MICH coupling (using CM board IN2).
  • Oscillator noise (amplitude + phase) -> MICH coupling (using AM/FM input of Marconi).

I've also made several changes to the NB code - will push to git once I finish cleaning stuff up, but it is now much faster to make these plots and see what's what.

  13368   Mon Oct 9 11:55:01 2017 KojiUpdateLSCDRMI Nosie Budget v3.0

My last characterization of the AS55 PD was on Feb 2013. ELOG 8100

There I said the dark noise at the PD output was 16nV/rtHz. I don't have the measurement of the Voltage noise at the output of the demod board.

Note that the PD can only be limited by shot noise when the DC current is larger then 4mA.

  13369   Mon Oct 9 22:18:34 2017 gautamUpdateLSCAS55Q Dark Noise

I measured the output voltage noise of the Q output of the AS55 Demod Board with the PSL shutter closed, using the SR785 (see Attachment #1). The measured noise is consistent with the expected number of ~120nV/rtHz around 100Hz. I had measured the gain of this board from RFPD input to Q output to be ~5.1: so if the PD dark noise is 16nV/rtHz, this would be amplified to ~80nV/rtHz. Still a discrepancy of ~50%. I didn't measure the noise with the PD input terminated. Added the noise of the demod board output with the RFPD input terminated. The level of ~100nV/rtHz seems consistent with the actual PD dark noise being ~80nV/rtHz, as their quadrature sum is around 130nV/rtHz. Need to dig up the schematics for the demod board + daughter board, and check against LISO, to see if this is consistent with what is expected.

Also - I think I was using the wrong value of the DC power on the AS55 photodiode for shot noise calculations - 13mW was for REFL55, not AS55. I did a crude measurement of the power by sticking the Ophir power meter (filter removed) in front of the AS55 PD with the Michelson flashing around, and noticed the maximum value registered was ~1.2mW. So in the DRMI lock, there would be ~2.4mW, which is 10x lower than the value I was assuming. I've made the correction in the NB code, for the next time the plot is generated. A more rigorous measurement would involve sticking the Ophir in front of the AS110 PD during a DRMI lock. The light from the AS port is split by a 50-50 BS to the AS55 and AS110 PDs (so measuring at AS110 is a reasonable proxy for power at AS55), and the AS110 signals are not used for triggering in the DRMI lock, so this is feasible.

 

  13370   Tue Oct 10 22:04:06 2017 ranaUpdateLSCAS55Q Dark Noise

how about calibrate the DC channels so that you can just get the acutal power levels from the trend data?

  13372   Wed Oct 11 14:42:03 2017 gautamUpdateLSCAS55Q Dark Noise

I keep adding traces to this plot, here is the most complete one I have now. Looks like the input noise to the D040179 (measured at "Q out" SMA jack of D990511 with RFPD input terminated) is ~10nV/rtHz. This supports the hypothesis that something is wonky on the daughter board, because the purple trace should only be the quad sum of the orange and green traces. I will pull it out and have a look.

Some other follow-ups on the questions raised at the meeting:

  1. Doesn't look like I've implemented thin film resistors on the input of the coil driver boards. De-whitening boards have the critical signal path resistors (judged as the ones with largest contribution as per LISO model) changed to thin film. Pictures are here.
  2. I think I didn't make a full elog of my demod board efficiency investigations, but from my notes and Attachment #4 of elog 12972, I calculated the gain in the signal path as the ratio of Vpp_out / Vpp_in.
Quote:

I measured the output voltage noise of the Q output of the AS55 Demod Board with the PSL shutter closed, using the SR785 (see Attachment #1). The measured noise is consistent with the expected number of ~120nV/rtHz around 100Hz. I had measured the gain of this board from RFPD input to Q output to be ~5.1: so if the PD dark noise is 16nV/rtHz, this would be amplified to ~80nV/rtHz. Still a discrepancy of ~50%. I didn't measure the noise with the PD input terminated. Added the noise of the demod board output with the RFPD input terminated. The level of ~100nV/rtHz seems consistent with the actual PD dark noise being ~80nV/rtHz, as their quadrature sum is around 130nV/rtHz. Need to dig up the schematics for the demod board + daughter board, and check against LISO, to see if this is consistent with what is expected.

Also - I think I was using the wrong value of the DC power on the AS55 photodiode for shot noise calculations - 13mW was for REFL55, not AS55. I did a crude measurement of the power by sticking the Ophir power meter (filter removed) in front of the AS55 PD with the Michelson flashing around, and noticed the maximum value registered was ~1.2mW. So in the DRMI lock, there would be ~2.4mW, which is 10x lower than the value I was assuming. I've made the correction in the NB code, for the next time the plot is generated. A more rigorous measurement would involve sticking the Ophir in front of the AS110 PD during a DRMI lock. The light from the AS port is split by a 50-50 BS to the AS55 and AS110 PDs (so measuring at AS110 is a reasonable proxy for power at AS55), and the AS110 signals are not used for triggering in the DRMI lock, so this is feasible.

 

 

  13374   Wed Oct 11 19:31:32 2017 gautamUpdateLSCAS55Q Dark Noise

I tried replacing the AD797s on the daughter board with OP27s, and saw no significant improvement in the electronics noise of the demod board. Note that according to LISO, in this configuration, the voltage noise of the Op27 is expected to dominate the total noise of the daughter board. Measurement condition was that the RFPD input was terminated, but the LO input was still being driven (SR785 input range is -50dBVpk for all traces, and the input ranging was set to "UpOnly"). Need to do a more systematic investigation to figure out where this excess noise is coming from. I will upload photos of the board later.

Quote:

This supports the hypothesis that something is wonky on the daughter board, because the purple trace should only be the quad sum of the orange and green traces. I will pull it out and have a look.

 

  13376   Thu Oct 12 01:50:11 2017 gautamUpdateLSCAS55Q Dark Noise

I worked on the daughter board a little more in the evening. I have somehow managed to make the dark noise ~25% worse [Attachment #1].

  • Earlier in the day, I had switched out both on-board AD797s for OP27. The latter has ~3x the input voltage noise, and LISO modeling suggests that this is the dominant contribution to the output voltage noise.
  • There are some differences in the actual components with which the board is stuffed, and the schematic. 
  • After updating the LISO model, I expect to get an output voltage noise of ~50nV/rtHz. But I measured ~2x this value (measured with LO input of demod board driven, RFPD input terminated).
  • While I had the board out, I replaced most of the installed thick-film resistors with thin film ones. For good measure, I also changed the AD829s.

After making all these changes, I re-installed the card in the eurocrate and repeated the measurement. The Q channel noise was close to the expected value (~50nV/rtHz), but the I channel is twice as noisy. I will continue this investigation tomorrow.

  13378   Thu Oct 12 12:17:28 2017 gautamUpdateLSCAS55Q Dark Noise

Here is the marked up schematic with the board as it is stuffed. Annoyingly, there is a capacitor (C1) which according to the schematic is supposed to be open, but is stuffed in our board. I can't find any elog about this, and its a pain to measure the value of this capacitance. I will upload all of this + LISO + noise model/measurements to a 40m AS55 daughter board DCC page.

 

  13380   Fri Oct 13 12:26:12 2017 gautamUpdateLSCAS55Q Dark Noise

Attachment #1 - Measured / modelled noises for AS55 demod board. I've plotted quadrature sum of the LISO trace with the SR785 noise floor with input terminated to ground via 50ohm. Note that these measurements were made after all the changes in the marked up schematic in the previous elog were implemented.

Both channels should be identical - I don't understand why the I channels are noisier than their Q counterparts. This is almost certainly a problem on the daughter board, as the orange traces are pretty much identical for both channels.

The dark red curves were measured by shorting the inputs to D040179 to ground via 50ohms using some Pomona minigrabbers - I wanted to avoid ripping the daughter board out, but this probably explains the excess noise compared to the green trace at low frequencies. All other measurements were made with the board installed in the LSC rack eurocrate, with the LO input driven at the nominal level (I didn't measure this yesterday but a measurement from ~6months ago says that this level is 1.5dBm).

  13382   Mon Oct 16 16:01:04 2017 gautamUpdateLSCAS55Q Dark Noise

Koji suggested looking at the output of the AS55 demod board on a fast oscilloscope to look for differences in the two channel outputs (if there is some high-frequency oscillations, for example, we could miss this information in the SR785 spectra). Besides, I was only looking at spectra out to a few kHz on the SR785. I grabbed this data with a 300MHz BW Tektronix oscilloscope (battery mode) today. Input impedance of both channels were set to 1Mohm, and the measurement was made with the RFPD input terminated, output of the daughter board is what is measured. The vertical scaling of the channels was set to the minimum allowed, 1mV/div.

Attachment #1 shows that there is indeed a visible difference between the two channels - the (noisier) I channel has a much larger DC offset of ~5mV compared to the Q channel (I tried switching channels on the O'scope and the larger DC offset remained on the I channel, so seems real). There is also some kind of oscillation going on in the I channel, although the frequency is pretty low, with the peaks spaced ~50us apart. Indeed, in the ASD of the acquired data, the excess power in the I channel at 20kHz and higher harmonics are evident (see Attachment #2). Anyway all of this points to something being anomalous on the daughter board I channel signal path - I will pull it out and monitor the outputs at various points along the signal path with the fast scope to see if I can narrow down what's going on where.

Quote:

Both channels should be identical - I don't understand why the I channels are noisier than their Q counterparts. This is almost certainly a problem on the daughter board, as the orange traces are pretty much identical for both channels.

 

  13383   Tue Oct 17 17:53:25 2017 jamieSummaryLSCprep for tests of Gabriele's neural network cavity length reconstruction

I've been preparing for testing Gabriele's deep neural network MICH/PRCL reconstruction.  No changes to the front end have been made yet, this is all just prep/testing work.

Background:

We have been unable to get Gabriele's nn.c code running in kernel space for reasons unknown (see tests described in previous post).  However, Rolf recently added functionality to the RCG that allows front end models to be run in user space, without needing to be loaded into the kernel.  Surprisingly, this seems to work very well, and is much more stable for the overall system (starting/stopping the user space models will not ever crash the front end machine).  The nn.c code has been running fine on a test machine in this configuration.  The RCG version that supports user space models is not that much newer than what the 40m is running now, so we should be able to run user space models on the existing system without upgrading anything at the 40m.  Again, I've tested this on a test machine and it seems to work fine.

The new RCG with user space support compiles and installs both kernel and user-space versions of the model.

Work done:

  • Create 'c1dnn' model for the nn.c code.  This will run on the c1lsc front end machine (on core 6 which is currently empty), and will communicate with the c1lsc model via SHMEM IPC.  It lives at:
    • /opt/rtcds/userapps/release/isc/c1/models/c1dnn.mdl
  • Got latest copy of nn.c code from Gabriele's git, and put it at:
    • /opt/rtcds/userapps/release/isc/c1/src/nn/
  • Checked out the latest version of the RCG (currently SVN trunk r4532):
    • /opt/rtcds/rtscore/test/nn-test
  • Set up the appropriate build area:
    • /opt/rtcds/caltech/c1/rtbuild/test/nn-test
  • Built the model in the new nn-test build directory ("make c1dnn")
  • Installed the model from the nn-test build dir ("make install-c1dnn")

Test:

I tried a manual test of the new user space model.  Since this is a user space process running it should have no affect on the rest of the front end system (which it didn't):

  • Manually started the c1dnn EPICS IOC:
    • $ (cd /opt/rtcds/caltech/c1/target/c1dnn/c1dnnepics && ./startupC1)
  • Tried running the model user-space process directly:
    • $ taskset -c 6 /opt/rtcds/caltech/c1/target/c1dnn/bin/c1dnn -m  c1dnn

Unfortunately, the process died with an "ADC TIMEOUT" error.  I'm investigating why.

Once we confirm the model runs, we'll add the appropriate SHMEM IPC connections to connect it to the c1lsc model.

  13384   Tue Oct 17 19:31:53 2017 gautamUpdateLSCAS55Q Dark Noise

[Koji, gautam]

We took a closer look at the AS55 demod board today. The procedure was to just be as thorough as possible, and check the behaviour of the circuit (both Transfer Function and Noise) stage by stage. Checking the transfer function was the key.

During this process, we found that the reason why the Q channels had lower noise than the I channels was because of the gain of the AD829 stage of the circuit was 0dB rather than 4dB (which is what it should be according to the component values used). Specifically, resistor R12, which is supposed to be 1.30kohm, was measured to be 1.03kohmfrown. Replacing this resistor, the transfer functions (see Attachment #1) and noise levels (see Attachment #2) match the expectations from LISO. Some notes:

  1. The daughter board essentially consists of 2 stages
    • OP27 stage, which has a design gain of 16dB ((=316ohm/50ohm) (flat at frequencies <100kHz).
    • AD829 stage, which has a design gain of 4dB (=1.3kohm/768ohm), and is a 2nd order Butterworth LPF with corner @ 1MHz.
    • So the overall gain of the daughter board is 20dB (i.e. x10) at audio frequencies.
  2. The output noise of D040179 is expected to be ~35nV/rtHz at 100Hz, and the measurement (made with inputs soldered together) is consistent with this value.
  3. The measured voltage noise at the input to D040179 (i.e. the output of the minicircuits mixer + SCLF-5 LPF) is ~9nV/rtHz.
  4. The output voltage noise of the demod board with RFPD input terminated then is expected to be the quadrature sum of the noise due to the D040179 electronics (i.e. 40nV/rtHz) and the input noise to the D040179 (i.e. 9nV/rtHz) multiplied by the gain of the daughter board (i.e. x10) == \sqrt{40^2 + 90^2} \approx 98nV/\sqrt{\mathrm{Hz}}.
  5. To calculate the "dark noise" contribution of AS55 to MICH displacement noise, we have to further add the photodiode dark noise contribution: this gets us up to \sqrt{98^2 + 80^2} \approx 130nV/\sqrt{\mathrm{Hz}}. This is consistent with the measurement (see Attachment #2).
  6. Assming the whitened ADC noise level is much below this (should only be ~10nV/rtHz), and given the measured sensing element of 6.2e8 V/m, this means that the dark noise sets a maximum achievable sensitivity of 2e-16m/rtHz.

To figure out what (if anything) is to be done next, we need to first figure out what is the goal. In the end, we care about DARM and not MICH. The optical gain for the former is ~300x the latter, so the dark noise contribution gets scaled by this factor (giving us a number of 7e-19 m/rtHz). There are certainly many noises above that level which have to be handled first. Indeed, looking at the DARM spectrum from DRFPMI lock back in March 2016, it looks like the current 1f DRMI (with coils de-whitened) Michelson sensitivity is within a factor of 2 of DARM in the full lock (albeit with vertex DoFs on 3f signals, and no coil de-whitening). Koji pointed out that we need to consider the photodiode resonant circuit itself too.

TODO: Upload all this onto the DCC

  13390   Wed Oct 18 12:14:08 2017 jamieSummaryLSCprep for tests of Gabriele's neural network cavity length reconstruction
Quote:

I tried a manual test of the new user space model.  Since this is a user space process running it should have no affect on the rest of the front end system (which it didn't):

  • Manually started the c1dnn EPICS IOC:
    • $ (cd /opt/rtcds/caltech/c1/target/c1dnn/c1dnnepics && ./startupC1)
  • Tried running the model user-space process directly:
    • $ taskset -c 6 /opt/rtcds/caltech/c1/target/c1dnn/bin/c1dnn -m  c1dnn

Unfortunately, the process died with an "ADC TIMEOUT" error.  I'm investigating why.

Once we confirm the model runs, we'll add the appropriate SHMEM IPC connections to connect it to the c1lsc model.

I tried moving the model to c1ioo, where there are plenty of free cores sitting idle, and the model seems runs fine.  I think the problem was just CPU contention on the c1lsc machine, where there were only two free cores and the kernel was using both for all the rest of the normal user space processes.

So there are two options:

  • Use cpuset on c1lsc to tell the kernel to remove all other processes from CPU6 and save it just for the c1dnn model.  This should not have any impact on the running of c1lsc, since that's exactly what would be happening if we were running the model in kernel space (e.g. isolating the core for the front end model).  The auxilliary support user space processes (epics seq/ioc, awgtpman) should all run fine on CPU0, since that's what usually happens.  Linux is only using the additional core since it's there.  We don't have much experience with cpuset yet, though, so more offline testing will be required first.
  • Run the model on c1ioo and ship the needed signals to/from c1lsc via PCIe dolphin.  This is potentially slightly more invasive of a change, and would put more work on the dolphin network, but it should be able to handle it.

I'm going to start testing cpuset offline to figure out exactly what would need to be done.

  13395   Thu Oct 19 15:42:03 2017 jamieSummaryLSCMICH/PRCL reconstruction neural network running on c1lsc

Gabriele's PRCL/MICH reconstruction neural network is now running on c1lsc.  Summary:

  • front-end model is called c1dnn, and is running as an experimental user-space process
  • c1dnn is getting most of it's needed inputs from existing SHMEM IPC outputs from c1lsc
  • none of the output signals from the network are being sent anywhere yet (grounded)
  • c1dnn has not been integrated in any way, into the DAQ etc.  it is being run manually by hand, and will be completely shut down after this test

Simple MEDM screen I made to monitor the input/output signals:

The RTS process seems to run fine, but there is quite a bit of jitter in the CPU_METER, at the 50% level:

It's not running over the limit, but it is jumping around more than I think it should be.  Will look into that...

cpuset for cpu isolation for user-space model

The c1dnn model is running on CPU6 on c1lsc.  CPU6 was isolated from the rest of the system using cpuset.  The "cset" utility was used to create a "system" CPU set that was assigned to CPU0, and the kernel was instructed to move all running processes to that set:

controls@c1lsc:~ 2$ sudo cset set
cset:
         Name       CPUs-X    MEMs-X Tasks Subs Path
 ------------ ---------- - ------- - ----- ---- ----------
         root        0,6 y       0 y   343    0 /
controls@c1lsc:~ 0$ sudo cset set -c 0 -s system --cpu_exclusive
cset: --> created cpuset "system"
controls@c1lsc:~ 0$ sudo cset set
cset:
         Name       CPUs-X    MEMs-X Tasks Subs Path
 ------------ ---------- - ------- - ----- ---- ----------
         root        0,6 y       0 y   342    1 /
       system          0 y       0 n     0    0 /system
controls@c1lsc:~ 0$ sudo cset proc --move -f root -t system -k
cset: moving all tasks from root to /system
cset: moving 292 userspace tasks to /system
cset: moving 0 kernel threads to: /system
cset: --> not moving 50 threads (not unbound, use --force)
[==================================================]%
cset: done
controls@c1lsc:~ 0$ sudo cset set
cset:
         Name       CPUs-X    MEMs-X Tasks Subs Path
 ------------ ---------- - ------- - ----- ---- ----------
         root        0,6 y       0 y    50    1 /
       system          0 y       0 n   292    0 /system
controls@c1lsc:~ 0$ sudo cset proc --move -f root -t system -k --force
cset: moving all tasks from root to /system
cset: moving 50 kernel threads to: /system
[==================================================]%
cset: **> 29 tasks are not movable, impossible to move
cset: done
controls@c1lsc:~ 0$ sudo cset set
cset:
         Name       CPUs-X    MEMs-X Tasks Subs Path
 ------------ ---------- - ------- - ----- ---- ----------
         root        0,6 y       0 y    29    1 /
       system          0 y       0 n   313    0 /system
controls@c1lsc:~ 0$

I then created a set for the RTS process ("rts-c1dnn") on CPU6, and executed the c1dnn model in that set:

controls@c1lsc:~ 0$ sudo cset set -c 6 -s rts-c1dnn --cpu_exclusive
cset: --> created cpuset "rts-c1dnn"
controls@c1lsc:~ 0$ sudo cset set
cset:
         Name       CPUs-X    MEMs-X Tasks Subs Path
 ------------ ---------- - ------- - ----- ---- ----------
         root        0,6 y       0 y    24    2 /
    rts-c1dnn          6 y       0 n     0    0 /rts-c1dnn
       system          0 y       0 n   340    0 /system
controls@c1lsc:~ 0$ sudo cset proc -s rts-c1dnn --exec /opt/rtcds/caltech/c1/target/c1dnn/bin/c1dnn -- -m c1dnn
cset: --> last message, executed args into cpuset "/rts-c1dnn", new pid is: 27572
sysname = c1dnn
....

When done I just hit Ctrl-C.

I left the cpusets as they are, with all system processes in the "system" set.  This should not pose any problems since it's the identical configuration as would be if a normal kernel-level model was running in CPU6.

The c1dnn process and it's EPICS sequencer were shutdown after this test.

  13400   Tue Oct 24 20:14:21 2017 jamieSummaryLSCfurther testing of c1dnn integration; plugged in to DAQ

In order to try to isolate CPU6 for the c1dnn neural network reconstruction model, I set the CPUAffinity in /etc/systemd/system.conf to "0" for the front end machines.  This sets the cpu affinity for the init process, so that init and all child processes are run on CPU0.  Unfortunately, this does not affect the kernel threads.  So after reboot all user space processes where on CPU0, but the kernel threads were still spread around.  Will continue trying to isolate the kernel as well...

In any event, this amount of isolation was still good enough to get the c1dnn user space model running fairly stably.  It's been running for the last hour without issue.

I added the c1dnn channel and testpoint files to the daqd master file, and restarted daqd_dc on fb1, so now the c1dnn channels and test points are available through dataviewer etc.  We were then able to observe the reconstructed signals:

We'll need to set the phase rotation of the demodulated RF PD signals (REFL11, REFL55, AS55, POP22) to match them with what the NN expects...

  13401   Wed Oct 25 09:32:14 2017 GabrieleSummaryLSCfurther testing of c1dnn integration; plugged in to DAQ
Quote:

 

 

We'll need to set the phase rotation of the demodulated RF PD signals (REFL11, REFL55, AS55, POP22) to match them with what the NN expects...

Here are the demodulation phases and rotation matrices tuned for the network. For the matrices, I am assuming that the input is [I, Q] and the output is [I,Q].

POP22
phi = 153 degrees
[[-0.894, 0.447],
 [-0.447, -0.894]]

REFL11
phi = 93 degrees
[[-0.058, 0.998],
 [-0.998, -0.058]]

REFL55
phi = -90 degrees
[[0.000, -1.000],
 [1.000, 0.000]]

AS55
phi = 7 degrees
[[0.993, 0.122],
 [-0.122, 0.993]]

  13411   Mon Nov 6 18:22:48 2017 jamieSummaryLSCcurrent procedure for running c1dnn code

This is the current procedure to start the c1dnn model:

$ ssh c1lsc
$ sudo systemctl start rts-epics@c1dnn
$ sudo systemctl start rts-awgtpman@c1dnn
$ sudo /usr/bin/cset proc -s rts-c1dnn --exec /opt/rtcds/caltech/c1/target/c1dnn/bin/c1dnn -- -m c1dnn
...

Then to shutdown:

...
Ctrl-C
$ sudo systemctl stop rts-awgtpman@c1dnn
$ sudo systemctl stop rts-epics@c1dnn

The daqd already knows about this model, so nothing should need to be done to the daqd to make the dnn channels available.

  13412   Tue Nov 7 17:45:05 2017 gautamUpdateLSCDRMI Nosie Budget v3.1

Some days ago, I had tried to measure the SRCL->MICH and PRCL->MICH cross couplings using broadband noise injected between 120-180 Hz, a frequency band chosen arbitrarily, in hindsight, I could have done a more broadband test. I've spent some time including the infrastructure to calculate "White-Noise TFs" in the noise budgeting code, where a transfer function is estimated by injecting a "broadband" excitation into a channel of interest, and looking at the resulting response in MICH. I figured this would be useful to estimate other couplings as well, e.g. laser intensity nosie, oscillator noise etc.

I estimate the transfer function of the coupling using the relation (MICH is the median ASD of the MICH error signal in the below expression, and similarly for PRCL)

|H_{cpl}| = \sqrt{\frac{|\mathrm{MICH}^{2}_{\mathrm{exc}} - \mathrm{MICH}^{2}_{\mathrm{quiet}}|}{|\mathrm{PRCL}^{2}_{\mathrm{exc}} - \mathrm{PRCL}^{2}_{\mathrm{quiet}}|}}

Attachments #1 and #2 show the spectra of the MICH, PRCL and SRCL signals during 'quiet' times and during the injection, while Attachment #3 shows the calculated coupling TFs using the above relation. These are significantly different (more than 10dB lower) than the numbers I reported in elog 13367, where the measurement was made using swept sine. As can be seen in the attached plots, the injected broadband excitation is visible above the nominal noise level, and I calculated the white noise TFs using ~5mins of data which should be plenty, so I'm not sure atm what to make of the answers from swept-sine and broadband injections being so different.

Attachment #4 shows the noise budget from the October 8 DRMI lock with the updated SRCL->MICH and PRCL->MICH couplings (assumed flat, extrapolated from Attachment #2 in the 120-180Hz band). If these updated coupling numbers are to be believed, then there is still some unexplained noise around 100Hz before we hit the PD dark noise. To be investigated. But if Attachment #4 is to be believed, it is not surprising that there isn't significant coherence between SRCL/PRCL and MICH around 100Hz.

Nov 8 1600: Updating NB to inculde estimated Oplev A2L.

Quote:
 

AUX coupling

This is the other find.

  • While chatting with Gabriele, he suggested measuring the SRCL->MICH and PRCL->MICH cross couplings.
  • I injected a signal in SRCL servo EXC channel, and adjusted amplitude till coherence in MICH_IN1 was good.
  • The actual TF measured was MICH_IN1 / SRCL_IN1 (so units of cts/ct).
  • My multiplying the in-lock PRCL and SRCL IN1 signals by these coupling coefficients (assumed flat in frequency for now, note that measurement was only made between 100Hz and 1kHz), I get the trace labelled "AUX coupling" in Attachment #1 (this is the quadrature sum for SRCL and PRCL couplings).
  • Also repeated for PRCL -> MICH coupling in the same way.
  • Measurements of these TFs and coherence are shown in Attachment #5 (again png screenshot because of DTT).
  • However, there is no significant coherence in MICH/SRCL or MICH/PRCL in this frequency range.

This seems to be limiting us from saturating the dark noise once the coil de-whitening is engaged. But lack of coherence means the mechanism is not re-injection of SRCL/PRCL sensing noise? Need to think about what this means / how we can mitigate it.


  13413   Tue Nov 7 22:56:21 2017 gautamUpdateLSCDRMI locking recovered

I hadn't re-locked the DRMI after the work on the AS55 demod board. Tonight, I was able to recover the DRMI locking with the old settings.

The feature in the PRCL spectrum (uncalibrated, y-axis is cts/rtHz) at ~1.6kHz is mysterious, I wonder what that's about.

Wasted some time tonight futzing around with various settings because I couldn't catch a DRMI lock, thinking I may have to re-tune demod phases etc given that I've been mucking around the LSC rack a fair bit. But fortunately, the problem turned out to be that the correct feedforward filters were not enabled in the angular feedforward path (seems like these are not SDF monitored). Clue was that there was more angular motion of the POP spot on the CCD than I'm used to seeing, even in the PRMI carrier lock.

After fixing this, lock was acquired within seconds, and the locks are as robust as I remember them - I just broke one after ~20mins locked because I went into the lab. I've been putting off looking at this angular feedforward stuff and trying out some ideas rana suggested, seems like it can be really useful.

As part of the pre-lock work, I dither aligned arms, and then ran the PRCL/MICH dithers as well, following which I re-centered the ITM, PRM and BS Oplevspots onto their respective QPDs - they have not been centered for a couple of months now.

I'm now going to try and measure some other couplings like PSL RIN->MICH, Marconi phase noise->MICH etc.

 

  13414   Wed Nov 8 00:28:16 2017 gautamUpdateLSCLaser intensity coupling measurement attempt

I tried measuring the coupling of PSL intensity noise by driving some broadband noise bandpassed between 80-300Hz using the spare DAC channel at 1Y3 that I had set up for this purpose a couple of weeks ago (via a battery powered SR560 buffer set to low-noise operation mode because I'm not sure if the DAC output can drive a ~20m long cable). I was monitoring the MC2 TRANS QPD Sum channel spectrum while driving this broadband noise - the "nominal" spectrum isn't very clean, there are a bunch of notches from a 60Hz comb and a forest of peaks over a broad hump from 300Hz-1kHz (see Attachment #1).

I was able to increase the drive to the AOM till the RIN in the band being driven increased by ~10x, and saw no change in the MICH error signal spectrum [see Attachment #1] - during this measurement, the RFPD whitening was turned on for REFL11, REFL55 and AS55, and the ITM coil drivers were de-whitened, so as to get a MICH spectrum that is about as "low-noise" as I've gotten it so far.

I tried increasing the drive further, but at this point, started seeing frequent MC locklosses - I'm not convinced this is entirely correlated to my AOM activities, so I will try some more, but at the very least, this places an upper bound on the coupling from intensity noise to MICH.

  13415   Wed Nov 8 09:37:45 2017 ranaUpdateLSCDRMI Nosie Budget v3.1

why no oplev trace in the NB ?

#4 shows the noise budget from the October 8 DRMI lock with the updated SRCL->MICH and PRCL->MICH couplings (assumed flat, extrapolated from Attachment #2 in the 120-180Hz band). If these updated coupling numbers are to be believed, then there is still some unexplained noise around 100Hz before we hit the PD dark noise. To be investigated. But if Attachment #4 is to be believed, it is not surprising that there isn't significant coherence between SRCL/PRCL and MICH around 100Hz

also, this method would work better if we had a median averaging python PSD instead of mean averaging as in Welch's method.

  13416   Wed Nov 8 09:59:12 2017 gautamUpdateLSCDRMI Nosie Budget v3.1

The Oplev trace is missing for now, as I have not re-measured the A2L coupling since modifying the Oplev loop shape (specifically the low pass filter and overall gain) to allow engageing the coil de-whitening.

The averaging for the white noise TFs plotted is computed using median averaging - I have used a python transcription of Sujan's matlab code. I use scipy.signal.spectrogram to compute the fft bins (I've set some defaults like 8s fft length and a tukey window), and then take the median average using np.median(). I've also incorporated the ln(2) correction factor.

It seems like GwPy has some in-built capability to compute median (and indeed various other percentile) averages, but since we aren't using it, I just coded this up. 

Quote:

why no oplev trace in the NB ?

also, this method would work better if we had a median averaging python PSD instead of mean averaging as in Welch's method.

 

  13421   Thu Nov 9 10:51:37 2017 gautamSummaryLSCcurrent procedure for compiling and installing c1dnn code

Jamie pointed out that the compile and install instructions are different for c1dnn:

cd /opt/rtcds/caltech/c1/rtbuild/test/nn-test
make c1dnn
make install-c1dnn

See also: https://nodus.ligo.caltech.edu:8081/40m/13383.

I think these build instructions have to be run on the c1lsc frontend - in the past, I have been able to compile and install models on any computer with the shared drive mounted (including the control room workstations), but I'm guessing that something has changed since the RCG upgrade. Jamie can correct me on this if I'm wrong.

  13428   Wed Nov 15 01:37:07 2017 gautamUpdateLSCDRMI low freq. nosie improved

Pianosa just crashed and ate my elog, along with all the DTT/Foton windows I had open, so more details tomorrow... This workstation has been crashing ~once a month for the last 6 months.

Summary:

Below ~100Hz, the hypothesis is that the BS oplev A2L contribution dominates the MICH displacement noise. I wanted to see if I could mitigate this my modifying the BS Oplev loop shape.

Details:

  • Swept sine TF measurements suggested that the BS A2L contribution is between 10-100x that of the ITM A2L
  • The Oplev loop shape for BS is different from ITMs - specifically, there is a Res-gain centered at ~3.3 Hz. The low frequency ~0.6Hz boost filter present in the ITM Oplev loops was disengaged for the BS Oplves.
  • I turned off the BS OL loops and looked at error signal spectra - didn't seem that different from ITM OL error signals, so I decided to try turning off the res-gain and engage the 0.6Hz boost.
  • This change also gave me much more phase at ~6Hz, which is roughly the UGF of the loop. So I put in another roll-off low pass filter with corner frequency 25Hz. 
  • This worked okay - RMS went down by ~5x (which is even better than the original config), and although the performance between ~3 and 10Hz is slightly worse than with the old combination,this region isn't the dominant contribution to the RMS. PM at the upper UGF is ~30degrees in the new configuration. 
  • I wanted to give DRMI locking a shot with the new OL loop - expectations were that the noise between 30-100Hz would improve, and perhaps the engaging of de-whitening filters on BS would also be easier given the more severe roll-off at high-frequencies.
  • Attachment #1 shows the NB for tonights lock. All MICH optics had their coil drivers de-whitened, and all the LSC PDs were whitened for this measurement.
  • I've edited the NB code to make the A2L calculation more straightforward, I now just make the coupling 1/f^2 and give the function a measured overall gain, so that this curve can now be easily added to all future NBs. I've also transcribed the matlab funciton used for parsing Foton files into python, this allows me to convert the DQ-ed OL error signals to control signals. Will update git with changes.

Remarks:

  1. MICH noise has improved by ~2x between 40-80Hz.
  2. Not sure what to make of the broad hump around 60Hz - scatter shelf?
  3. There is still unexplained noise below 100Hz, the A2L estimate is considerably lower than the measured noise.
  4. We are still more than an order of magnitude away from the estimated seismic noise floor at low frequencies (but getting closer!).

I've been banging my head against optimal loop shaping, with the OL loop as a test-case, without much success - as was the case with coating PSO, the magic is in smartly defining the cost function, but right now, my optimizer seems to be pushing most of the roots I'm making available for it to place to high frequencies. I've got a term in there that is supposed to guard against this, need to tweak further...


Attachment #2: Eye-fits of measured OL A2L coupling TFs to a 1/f^2 shape, with the gain being the parameter "fitted". I used these value, and the DQ-ed OL error signal in lock, to estimate the red curve labelled "A2L" in Attachment #1. The dots are the measurement, and the lines are the 1/f^2 estimates.

  13431   Thu Nov 16 00:53:26 2017 gautamUpdateLSCDRMI noise sub-budgets

I've incorporated the functionality to generate sub-budgets for the various grouped traces in the NBs (e.g. the "A2L" trace is really the quadrature sum of the A2L coupling from 6 different angular servos).

For now, I'm only doing this for the A2L coupling, and the AUX length loop coupling groups. But I've set up the machinery in such a way that doing so for more groups is easy.

Here are the sub-budget plots for last night's lock - for the OL plot, there are only 3 lines (instead of 6) because I group the PIT and YAW contributions in the function that pulls the data from the nds server, and don't ever store these data series individually. This should be rectified, because part of the point of making these sub-budgets is to see if there is a particularly bad offender in a given group.

I'll do a quick OL loop noise budget for the ITM loops tomorrow.

I also wonder if it is necessary to measure the Oplev A2L coupling from lock to lock? This coupling will be dependant on the spot position on the optic, and though I run the dither alignment servos to minimize REFL_DC, AS_DC, I don't have any intuition for how the offset from center of optic varies from lock to lock, and if this is at all significant. I've been using a number from a measurement made in May. Need to do some algebra...

  13907   Thu May 31 23:12:17 2018 gautamUpdateLSCDRMI locking attempt

Summary:

I wanted to recover the DRMI locking. Among other things, Jon mentioned that his mode spectroscopy can be done in the DRMI config. But I was foiled last night by a rogue waveplate in the AS beampath, and today evening, I noticed the resurfacing of this problem. Clearly, this is indicative of some issue in the analog whitening electronics, as the DC light level on the AS55 PD is consistent with previous measurements. Moreover, last time, the problem "fixed itself" so I don't know what exactly the problem was in the first place. I'll try doing the same test in the linked elog tomorrow. As a quick test, I cycled through the whitening gains (0-45dB) to see if it was some stuck ADC register, but that didn't fix the problem.

The problem seems to be with REFL55 only - I am able to lock the PRMI with carrier resonant without any issues, and the error signal levels are consistent with what I remember them being while the PRMI is swinging around. AS55 lives on the same whitening board and doesn't seem to suffer from the same probelms.


Decided to do the check tonight, but as Attachment #1 shows, no real red flags from the whitening gain side.

  13908   Fri Jun 1 01:22:50 2018 gautamUpdateLSCDRMI locking restored

As it happened last time, the problem apparently fixed itself - somehow the act of me disconnecting the cables and reconnecting them seems to solve the problem, need to think about this.

Anyway, DRMI was locked a few times tonightyes. I got in a good long stretch where I ran some sensing lines and collected some data, analysis tomorrow. I am going to center the vertex oplevs as an alignment reference for now. A major source of lockloss seems to be angular instability - see for example this video grab of POP:

Could be due to noise injection from the noisy PRM Oplev HeNe, or just TT mirror angular motion (I couldn't get the PRC angular FF going tonight).

  13920   Wed Jun 6 14:36:15 2018 gautamUpdateLSCTRX clipping

For some time now, I've been puzzled by the unreliability of the ASS_X dither alignment servo. Leaving the servo on, TRX often begins to decay to a lower value, and even after freezing the dither at the maximum TRX values, I can manually align the mirrors to increase TRX. We have suspected some kind of clipping in the TRX path that is responsible for this behaviour. Today I decided to investigate this a bit further. To have the arm locked and to inspect the beam, we have to change the locking trigger - TRX is what is normally used, but I misaligned the Y arm completely, and used AS110 as a trigger instead. There is some strangeness in the triggering topology, but this deserves a separate elog.

Once the arm was locked (and relocks using the AS110 trigger in the event of an unlock), I was able to trace the beampath on the EX table with an IR card. The TRX beam is rather large and weak, so it is hard to see, but as best as I can tell, the only real danger of clipping (or perhaps the beam is already clipped) is on the final steering mirror before the beam hits the (Thorlabs) PD. Steve/Pooja are working on getting a photo of this, and will upload it here shortly. Options to mitigate this:

  1. Use the harmonic separator to steer the beam lower, and center it on the 1" steering mirror. However, this could possibly lead to clipping on some of the upstream lenses.
  2. Raise the height of the 1" steering mirror by 0.25". However, this would require a custom 3/4" dia post height or some shims, which I am not sure is in line with our optomechanic mounting practises.
  3. Use a 2" mirror instead of a 1" mirror.

The EX QPD has stopped working since the Acromag install. If it were working, we wouldn't have to rely on the alternate triggering with AS110 and instead just use the QPD as TRX, while we debug the Thorlabs PD path.

  13927   Thu Jun 7 16:15:03 2018 gautamUpdateLSCTRX clipping

I opted for the quickest fix - I raised the height of the offending steering mirror using a 0.25" shim. In the long term, we can get a taller post machined. After raising the mirror height, I then checked the DC centering of the spot on the DC PD using a scope.

Looking at the performance of the X arm ASS, I no longer see the strange oscillatory behaviour I described in my previous post yes. Moreover, the TRX level was ~1 before be raising the steering mirror - but it is now ~1.2. So we were certainly losing some power.

  13933   Fri Jun 8 01:58:56 2018 gautamUpdateLSCDRMI locking attempt again

Given the various changes to the IFO config since last Thursday when I was last able to lock the DRMI, I wanted to try once again tonight. However, I had no success. By my judgement, the alignment is fine as judged by looking at mode flashes on the cameras. However, despite following the usual alignment procedures, I did not get a single lock in tonight. indecision

Perhaps we can use a flip mount on the BS that combines the PSL and AUX beams on the AS table, so we have the option of recovering the usual IFO config when we so desire - while Jon needs the SRC locked for his measurement, it would be nice to not have to figure out the correct demod phases etc each time there is a change in the optical setup of the AUX beam.

  13948   Tue Jun 12 03:22:25 2018 gautamUpdateLSCAUX laser shuttered

I worked a bit on recovering the DRMI locking again tonight. I decided to shutter the AUX laser on the PSL table at least until I figured out the correct locking settings. As has become customary now, there was a cable in the AS beampath (leading from the AS55 DC monitor to nothing, through the enclosure side panel, it is visible in Attachment #3 in this elog) which I only found after 30mins of futility - please try and remove all un-necessary cables and leave the AS beampath in a usable state after working on the AS table! angry In the end, I got several short (~3mins) stretches in tonight, but never long enough to do the loop characterization I wanted to get in tonight, probably wrong gains in one or more of the loops. In the last 30 minutes, the IMC has been frequently losing lock, so I am quitting for now. The AUX laser remains shuttered.

  13952   Wed Jun 13 01:02:40 2018 gautamUpdateLSCReliable and repeatable 1f DRMI locking

[koji, gautam]

With Koji's help, I got repeatable and reliable DRMI locking going again tonight - this is with the AS path optics for the spectroscopy measurement in place, although the AUX laser remained shuttered tonight. Results + spectra tomorrow, but here's what I did:

  • Initial alignment procedure was as usual - use arms+ASS to align ITMs, and then PRMI carrier+ASS to align PRM and BS.
  • Found the appropriate gains and demod phases.
  • Measured loop TFs - PRCL is a big mystery. Used these to finalize loop gains.
  • Ran some sensing lines.
  • Whitened DRMI PDs for a calibrated "low-noise" spectrum (although the coils were not de-whitened).

As I have found before, it is significantly easier to get the locking going post 11pm - the wall Seis BLRMS don't look that much quieter at midnight compared to 10pm, but this might be a scaling issue. I'll do a quantitative assessment next time... Also, Foton takes between 25-45 secs to save an updated filter (timed twice today).

  13953   Wed Jun 13 11:17:40 2018 gautamUpdateLSCPRCL loop shape anomaly

Attachment #1 shows the measured PRCL loop shape. The blue line is meant to be the "expected" loop shape. While the measured loop shape tracks the expectation down to ~100 Hz, I cannot explain the shape below it. I am also not sure what to make of the fact that there is high coherence down to 10 Hz fron IN2 to IN1, but no coherence between EXC/IN2. I confirmed that the low-frequency boost filters were ON during the measurement. I don't understand how a pendulum TF + the digital filters we used can account for the shape below 100Hz.

gautam 11pm: After discussing with Koji, I conclude that the low frequency loop shape is consistent with the excitation amplitude being insufficient below 100 Hz. Coherence is good between In1/In2 because they are the same signal effectively - what we need is coherence between In1 and EXC, which isn't plotted. It is still strange that Coherence between In2/EXC is ZERO....

Quote:

Measured loop TFs - PRCL is a big mystery. Used these to finalize loop gains.

  13959   Thu Jun 14 00:40:42 2018 gautamUpdateLSCPRCL loop shape anomaly

don't use IN_1/IN_2: recall pizza meeting from a few weeks back: use IN1/EXC + Al-Gebra

Quote:
Quote:

Measured loop TFs - PRCL is a big mystery. Used these to finalize loop gains.

 

  13966   Thu Jun 14 18:09:24 2018 gautamUpdateLSCReliable and repeatable 1f DRMI locking

I finally analyzed the sensing measurement I ran on Tuesday evening. Sensing responses for the DRMI DOFs seems consistent with what I measured in October 2017, although the relative phasing of the DoFs in the sensing PDs has changed significantly. For what it's worth, my Finesse simulation is here

  13969   Fri Jun 15 00:53:21 2018 gautamUpdateLSCCalibrated MICH spectrum

Using the numbers from the sensing measurement, I calibrated the measured in-loop MICH spectrum from Tuesday night into free-running displacement noise. For convenience, I used the noise-budgeting utilities to make this plot, but I omitted all the technical noise curves as the coupling has probably changed and I did not measure these. The overall noise seems ~x3  higher everywhere from the best I had last year, but this is hardly surprising as I haven't optimized anything for low noise recently. To summarize:

  • DRMI was locked using 1f error signals.
  • MICH was controlled using AS55_Q.
  • Main difference is that we have a little less (supposedly 10%) light on the AS55 PD now because of the AUX laser injection setup. But the AUX laser was shuttered.
  • 1f LSC PDs (REFL11, REFL55 and AS55) had ADC whitening filters engaged in while this data was taken.
  • ITM and BS coils were not de-whitened.

I will do a more thorough careful characterization and add in the technical noises in the coming days. The dominant uncertainty in the sensing matrix measurement, and hence this free-running noise spectrum, is that I haven't calibrated the actuators in a while.

Quote:

I finally analyzed the sensing measurement I ran on Tuesday evening. Sensing responses for the DRMI DOFs seems consistent with what I measured in October 2017, although the relative phasing of the DoFs in the sensing PDs has changed significantly. For what it's worth, my Finesse simulation is here

  14152   Fri Aug 10 01:10:56 2018 gautamUpdateLSCSome vertex locking restored

For the first time after the whirlwind vent, I managed to lock the PRMI.

  • First, I did POX/POY locking, dither aligned the arms to maximize TRX and TRY.
  • Next, I misaligned the ETM and tested the Michelson locking
    • Since we've lost ~70% of power on the AS55 PD, I set the whitening gain for AS55 I and Q channels to +6dB (old value was 0dB).
    • worked alright. In this new config, the peak-to-peak Michelson fringe count is ~80 cts, while I reported ~60cts-pp a couple of months ago, so all seems good on that front.
    • But the config script in the IFOconfigure MEDM screen somehow doesn't set the AS55_Q ----> MICH_A element in the LSC input matrix anymore.
    • I edited the .snap file for this configuration to set the relevant matrix element EPICS channel to +1.0.
    • I also edited the overall loop gain for this configuration from +30 to +2 (for bright fringe, use -2 for dark fringe).
  • Feeling adventerous, I decided to try PRMI in the carrier resonant tuning (to be clear, PRCL on REFL11_I, MICH on AS55_Q).
    • Finding the REFL spot on the camera took a while since the PRM has been macroscopically misaligned for the mode-scanning
    • Went out to the table and centered the REFL beam onto REFL11 and REFL55 PDs - didn't need much tweaking, which is a good sign, since we shouldn't have screwed anything up on the symmetric side by any of the vent activities.
    • Restored PRMI locking using the IFOconfigure MEDM screen - lock caught almost immediately.
    • Ran the dither alignment servos for MICH and PRCL - BS needed a bit of encouragement to make the dark spot dark, but POP has been pretty stable over ~15mins.
    • I didn't take any loop transfer functions, to do.

I don't have the energy to make a DRMI attempt tonight - but the signs are encouraging. I'd like to use the IFO in the next few days to try and recover DRMI locking. The main concern is that the optical path on the AS beam has changed by ~0.3m I estimate. So the demod phase for AS55 may need to be adjusted, but the change due to optical path length only should be ~10degrees so the DRMI locking with the old settings should still work. Perhaps we also want to scan the PRC and SRC with the phase information from the Trans/Refl transfer functions as well.


Don't want to jinx it, but the c1lsc FE models have been stable. Tomorrow, I'd like to re-enable c1cal, since it has some useful channels for NBing. Could c1daf/c1oaf which have significant amounts of custom C code be the culprits?

  14160   Tue Aug 14 00:27:55 2018 gautamUpdateLSCLocking prep

In preparation for attempting some DRMI locking, I did the following:

  • Slow machine reboots for unresponsive c1psl, c1susaux and c1iscaux. The latter requried a manual burtrestore to recover the usual LSC PD whitening settings.
  • Shuttered AUX laser (which was on Standby anyways) - we should really install a remotely controllable shutter for this on the AS table.
  • Re-aligned PMC (half turn of knob in yaw, full turn in pitch) - IMC transmission 15,000cts ---> 15,600cts.
  • Squished sat. box cables at ITMX and ETMX.

Not related to this work, but I turned the Agilent NA off since we aren't using it immediately.

  14162   Tue Aug 14 02:01:12 2018 gautamUpdateLSCDRMI locking - partial success

After tweaking the AS55 demod phase, SRM alignment, triggering settings, I got a few brief DRMI locks in tonight, I'm calling it a success (though this isn't really robust yet). The main things to do now are:

  • turn on all the boosts on the LSC loops - today I only managed to trigger the PRCL boost filters successfully without blowing up the lock.
  • measure all 3 loops, tweak gain as necessary.
  • Run some sensing lines, tune the demod phase.
  • The SRCL triggering is strange to me - SRCL loop is currently triggered on POP22_I, but the 2f1 buildup in the symmetric side does not say anything about the linearity of the SRCL error signal? Or are we just hoping the SRM is in the correct place and engaging the servo? Anyway, this setting seems to work but perhaps once the locking is more robust the triggering can be fixed.
  • do a quick NB - I expect the main change to be that the AS55_Q dark noise contribution would have gone up on account on the reduced amount of light at this port.

I think the main IFO characterization remaining to be done to determine the status of the IFO post vent is to measure the losses of the arm cavities. IMO, we will need to certainly fix the clipping at ETMY before we attempt some serious locking.

  14235   Sun Oct 7 16:51:03 2018 gautamConfigurationLSCYarm triggering changed

To facilitate Yuki's alignment of the EY green beam into the Yarm cavity, I have changed the LSC triggering and PowNorm settings to use only the reflected light from the cavity to do the locking of Arm Cavity length to PSL. Running the configure script should restore the usual TRY triggering settings. Also, the X arm optics were macroscopically misaligned in order to be able to lock in this configuration.

  14236   Sun Oct 7 22:30:42 2018 yukiConfigurationLSCYarm Green locking was recovered

I finished installation of optics in the Y-end and recovered green locking. Current ALS-TRY_OUTPUT is about 0.25, which is lower than before. So I still continue the alignment of the beam. The simulation code was attached. (Sorry. The optic shown as QWP2 is NOT QWP. It's HWP.)

  14240   Tue Oct 9 23:03:43 2018 yukiConfigurationLSCYarm Green locking was recovered

[ Yuki, Gautam, Steve ]

To align the green beam in Y-end these hardware were installed:

  • PZT mirrors in Y-end table
  • PZT driver in 1Y4 rack
  • Anti-Imaging board in 1Y4 rack
  • cables (DAC - AIboard - PZTdriver - PZT)
  • high voltage supplier 

I made sure that DAC CH9~16 and cable to AI-board worked correctly. 

When we applied +100V to PZT driver and connected DAC, AI-board and PZT drive, the output voltage of the driver was not correct. I'll check it tomorrow.

  14241   Wed Oct 10 12:38:27 2018 yukiConfigurationLSCAll hardware was installed

I connected DAC - AIboard - PZTdriver - PZT mirrors and made sure the PZT mirrors were moving when changing the signal from DAC. Tomorrow I will prepare alignment servo with green beam for Y-arm.

  14285   Wed Nov 7 23:07:11 2018 gautamUpdateLSCDRMI locking recovered

I had some success today. I hope that the tweaks I made will allow working with the DRMI during the day as well, though it looks like the main limiting factor in lock duty cycle is angular stability of the PRC.

  • Since there has been some change in the light levels / in vacuum optical paths, I decided to be a bit more systematic.
  • Initial guess of locking gains / demod phases was what I had last year.
  • Then I misaligned SRM, and locked PRMI, for the sideband resonant in the PRC (but still no arm cavities, and using 1f Refl error signals).
  • Measured loop TFs, adjusted gains, re-enabled boosts.
  • Brought the SRM back into the picture. Decided to trigger SRCL loop on AS110I rather than the existing POP22I (because why should 2f1 signal buildup carry information about SRCL?). New settings saved to the configure script. Reduced MICH gain to account for the SRC cavity gain.
  • Re-measured loop TFs, re-adjusted gains. More analysis about the state of the loops tomorrow, but all loops have UGF ~100-120 Hz.
  • Ran some sensing lines - need to check my sensing matrix making script, and once I get the matrix elements, I can correct the error signal demod phasing as necessary.

[Attachment #1]: Repeatable and reliable DRMI locks tonight, stability is mainly limited by angular glitches - I'm not sure yet if these are due to a suspect Oplev servo on the PRM, or if they're because of the tip-tilt PR2/PR3/SR2/SR3.

[Attachment #2]: A pass at measuring the TF from SRCL error point to MICH error point via control noise re-injection. I was trying to measure down to 40 Hz, but lost the lock, and am calling it for the night.

[Attachment #3]: Coherence between PRM oplev error point and beam spot motion on POP QPD.

Note that the MICH actuation is not necessarily optimally de-coupled by actuating on the PRM and SRM yet (i.e. the latter two elements of the LSC output matrix are not precisely tuned yet).

What is the correct way to make feedforward filters for this application? Swept-sine transfer function measurement? Or drive broadband noise at the SRCL error point and then do time-domain Wiener filter construction using SRCL error as the witness and MICH error as the target? Or some other technique? Does this even count as "feedforward" since the sensor is not truly "outside" the loop?

  14288   Sat Nov 10 17:32:33 2018 gautamUpdateLSCNulling MICH->PRCL and MICH->SRCL

With the DRMI locked, I drove a line in MICH using the sensing matrix infrastructure. Then I looked at the error points of MICH, PRCL and SRCL. Initially, the sensing line oscillator output matrix for MICH was set to drive only the BS. Subsequently, I changed the --> PRM and --> SRM matrix elements until the line height in the PRCL and SRCL error signals was minimized (i.e. the change to PRCL and SRCL due to the BS moving, which is a geometric effect, is cancelled by applying the opposite actuation to the PRM/SRM respectively. Then I transferred these to the LSC output matrix (old numbers in brackets).

MICH--> PRM = -0.335 (-0.2655)

MICH--> SRM = -0.35 (+0.25)

I then measured the loop TFs - all 3 loops had UGFs around 100 Hz, coinciding with the peaks of the phase bubbles. I also ran some sensing lines and did a sensing matrix measurement, Attachment #1 - looks similar to what I have obtained in the past, although the relative angles between the DoFs makes no sense to me. I guess the AS55 demod phase can be tuned up a bit.

The demodulation was done offline - I mixed the time series of the actuator and sensor signals with a "local oscillator" cosine wave - but instead of using the entire 5 minute time series and low-passing the mixer output, I divvied up the data into 5 second chunks, windowed with a Tukey window, and have plotted the mean value of the resulting mixer output.

Unrelated to this work: I re-aligned the PMC on the PSL table, mostly in Pitch.

  14292   Tue Nov 13 18:09:24 2018 gautamUpdateLSCInvestigation of SRCL-->MICH coupling

Summary:

I've been looking into the cross-coupling from the SRCL loop control point to the Michelson error point.

[Attachment #1] - Swept sine measurement of transfer function from SRCL_OUT_DQ to MICH_IN1_DQ. Details below.

[Attachment #2] - Attempt to measure time variation of coupling from SRCL control point to MICH error point. Details below.

[Attachment #3] - Histogram of the data in Attachment #2.

[Attachment #4] - Spectrogram of the duration in which data in #2 and #3 were collected, to investigate the occurrance of fast glitches.

Hypothesis: (so that people can correct me where I'm wrong - 40m tests are on DRMI so "MICH" in this discussion would be "DARM" when considering the sites)

  • SRM motion creates noise in MICH.
  • The SRM motion may be naively decomposed into two contributions -
    • Category #1: "sensing noise induced" motion, which comes about because of the SRCL control loop moving the SRM due to shot noise (or any other sensing noise) of the SRCL PDH photodiode, and
    • Category #2: all other SRM motion.
  • We'd like to cancel the former contribution from DARM.
  • The idea is to measure the transfer function from SRCL control point to the MICH error point. Knowing this, we can design a filter so that the SRCL control signal is filtered and summed in at the MICH error point to null the SRCL coupling to MICH.
  • Caveats/questions:
    • Introducing this extra loop actually increases the coupling of the "all other" category of SRM motion to MICH. But the hypothesis is that the MICH noise at low frequencies, which is where this increased coupling is expected to matter, will be dominated by seismic/other noise contributions, and so we are not actually degrading the MICH sensitivity.
    • Knowing the nosie-budget for MICH and SRCL, can we AC couple the feedforward loop such that we are only doing stuff at frequencies where Category #1 is the dominant SRCL noise?

Measurement details and next steps:

Attachment #1

  • This measurement was done using DTT swept sine.
  • Plotted TF is from SRCL_OUT to MICH_IN, so the SRCL loop shape shouldn't matter.
  • I expect the pendulum TF of the SRM to describe this shape - I've overlaid a 1/f^2 shape, it's not quite a fit, and I think the phase profile is due to a delay, but I didn't fit this.
  • I had to average at each datapoint for ~10 seconds to get coherence >0.9.
  • The whole measurement takes a few minutes.

Attachments #2 and #3

  • With the DRMI locked, I drove a sine wave at 83.13 Hz at the SRCL error point using awggui.
  • I ramped up the amplitude till I could see this line with an SNR of ~10 in the MICH error signal.
  • Then I downloaded ~10mins of data, demodulated it digitally, and low-passed the mixer output.
  • I had to use a pretty low corner frequency (0.1 Hz, second order butterworth) on the LPF, as otherwise, the data was too noisy.
  • Even so, the observed variation seems too large - can the coupling really change by x100?
  • The scatter is huge - part of the problem is that there are numerous glitches while the DRMI is locked.
  • As discussed at the meeting today, I'll try another approach of doing multiple swept-sines and using Craig's TFplotter utility to see what scatter that yields.

Attachments #2

  • Spectrogram generated with 1 second time strides, for the duration in which the 83 Hz line was driven.
  • There are a couple of large fast glitches visible.
  14298   Fri Nov 16 00:47:43 2018 gautamUpdateLSCMore DRMI characterization

Summary:

  • More DRMI characterization was done.
  • I was working on trying to improve the stability of the DRMI locks as this is necessary for any serious characterization.
  • Today I revived the PRC angular feedforward - this was a gamechanger, the DRMI locks were much more stable. It's probably worth spending some time improving the POP LSC/ASC sensing optics/electronics looking towards the full IFO locking.
  • Quantitatively, the angular fluctuations as witnessed by the POP QPD is lowered by ~2x with the FF on compared to offyes [Attachment #1, references are with FF off, live traces are with FF on].
  • The first DRMI lock I got is already running 15 mins, looking stable.
    • Update: Out of the ~1 hour i've tried DRMI locking tonight, >50 mins locked!
  • I think the filters can be retrained and this performance improved, something to work on while we are vented.
  • Ran sensing lines, measured loop TFs, analysis tomorrow, but I think the phasing of the 1f PDs is now okay.
    • MICH in AS55 Q, demod phase = -92deg, +6dB wht gain.
    • PRCL in REFL11 I, demod phase = +18 deg, +18dB wht gain.
    • SRCL in REFL55 I, demod phase = -175 deg, +18dB wht gain.
  • Also repeated the line in SRCL-->witness in MICH test.
    • At least 10 minutes of data available, but I'm still collecting since the lock is holding.
    • This time I drove the line at ~124 Hz with awggui, since this is more a regime where we are sensing noise dominated.

Prep for this work:

  • Reboots of c1psl, c1iool0, c1susaux.
  • Removed AS port PD loss measurement PD.
  • Initial alignment procedure as usual: single arms --> PRMI locked on carrier --> DRMI

I was trying to get some pics of the optics as a zeroth-level reference for the pre-vent loss with the single arms locked, but since our SL7 upgrade, the sensoray won't work anymore no. I'll try fixing this during the daytime.

  14313   Wed Nov 21 09:59:26 2018 gautamUpdateLSCLSC feedforward block diagram

Attachment #1 is a block diagram depicting the pathway by which the vertex DOF control signals can couple into DARM (adapted from a similar diagram in Gabriele's Virgo note on the subject). I've also indicated some points where noise can couple into either loop. In general, there are sensing noises that couple in at the error point of the loop, and actuation noises that couple in at the control point. In this linear picture, each block represents a (possibly time varying) transfer function. So we can write out the node-to-node transfer functions and evaluate the various couplings.

The motivation is to see if we can first simulate with some realistic noise and time-varying couplings (and then possibly test on the realtime system) the effectiveness of the filter denoted by "FF" in canceling out the shot noise from the auxiliary loop being re-injected into the DARM loop via the DARM sensor. Does this look correct?

  14326   Fri Nov 30 19:37:47 2018 gautamUpdateLSCLSC feedforward block diagram

I wanted to set up an RTCDS model to understand this problem better. Attachment #1 is the simulink diagram of the signal flow. The idea will be to put in the appropriate filter shapes into the various filter blocks denoting the DARM and auxiliary DoF plants, controllers and actuators, and then use awggui / diaggui to inject some noises and see if in this idealized model I can achieve good subtraction. Then we can build up to applying a time varying cross coupling between DARM and the vertex DoF, and see how good the adaptive FF works. Still need to setup some MEDM screens to make working with the test system easier.

I figured c1omc would be the least invasive model to set this upon without risking losing any of our IR/green alignment references. Compile and install went smooth, see Attachment #2. The c1omc model was clocking 4us before, now it's using 7us.

Attachment #3 shows the top level of the OMC model, while Attachment #4 shows the MEDM screen.

* Note to self: when closing a loop inside the realtime model, there has to be a delay block somewhere in the loop, else a compilation error is thrown.

  14339   Mon Dec 10 15:53:16 2018 gautamUpdateLSCSwept-sine measurement with DTT

Disclaimer: This is almost certainly some user error on my part.

I've been trying to get this running for a couple of days, but am struggling to understand some behavior I've been seeing with DTT.

Test:

I wanted to measure some transfer functions in the simulated model I set up.

  • To start with, I put a pendulum (f0 = 1Hz, Q=5) TF into one of the filter modules
  • Isolated it from the other interconnections (by turning off the MEDM ON/OFF switches).
  • Set up a DTT swept-sine measurement
    • EXC channel was C1:OMC-TST_AUX_A_EXC
    • Monitored channels were C1:OMC-TST_AUX_A_IN2 and C1:OMC-TST_AUX_A_OUT.
    • Transfer function being measured was C1:OMC-TST_AUX_A_OUT/C1:OMC-TST_AUX_A_IN2.
    • Coherence between the excitation and output were also monitored.
  • Sweep parameters:
    • Measurement band was 0.1 - 900 Hz
    • Logarithmic, downward.
    • Excitation amplitude = 1ct, waveform = "Sine"

Unexplained behavior:

  • The transfer function measurement fails with a "Synchronization error", at ~15 Hz.
    • I don't know what is special about this frequency, but it fails repeatedly at the same point in the measurement.
  • Coherence is not 1 always
    • Why should the coherence deviate from 1 since everything is simulated? I think numerical noise would manifest when the gain of the filter is small (i.e. high frequencies for the pendulum), but the measurement and coherence seem fine down to a few tens of Hz.

To see if this is just a feature in the simulated model, I tried measuring the "plant" filter in the C1:LSC-PRCL filter bank (which is also just a pendulum TF), and run into the same error. I also tried running the DTT template on donatella (Ubuntu12) and pianosa (SL7), and get the same error, so this must be something I'm doing wrong with the way the measurement is being run / setup. I couldn't find any mention of similar problems in the SimPlant elogs I looked through, does anyone have an idea as to what's going on here?

* I can't get the "import" feature of DTT to work - I go through the GUI prompts to import an ASCII txt file exported from FOTON but nothing selectable shows up in DTT once the import dialog closes (which I presume means that the import was successful). Are we using an outdated version of DTT (GDS-2.15.1)?  But Attachment #1 shows the measured part of the pendulum TF, and is consistent with what is expected until the measurement terminates with a synchronization error.


the import problem is fixed - when importing, you have to give names to the two channels that define the TF you're importing (these can be arbitrary since the ASCII file doesn't have any channel name information). once i did that, the import works. you can see that while the measurement ran, the foton TF matches the DTT measured counterpart.


11 Dec 2pm: After discussing with Jamie and Gabriele, I also tried changing the # of points, start frequency etc, but run into the same error (though admittedly I only tried 4 combinations of these, so not exhaustive).

ELOG V3.1.3-