I'm using the notebooks from rana as a starting point, and making a script to measure and fill the WFS sensing matrix. It lives at /users/aaron/WFS/scripts/WFSsensingMatrix.ipynb for now. Here's what it does; what's been tested is in green, untested is goldenrod, uncoded is fire brick.

1. Sets up an nds connection, listening to the WFS channels and the MC#_PIT/YAW IN1 channels.
2. Loops over the excitation channels. For now, I'm assuming the user is injecting excitations one at a time in awggui; in principle, we could excite the various MC angular dof at several frequencies and take a single measurement, or use the natural frequencies of the suspensions.
   1. For each excitation, grab the data
   2. Filter the data. I'm using a 30 Hz to 40 Hz cheby filter
   3. Take an FFT, hold on to that for future reference
   4. Generate an LO at the excitation frequency, and demodulate the signals. Strong low pass.
   5. The single-frequency transfer function is now [WFS channel] / [excited MC channel]. Each iteration of this loop generates a column of the sensing matrix.
3. Invert the sensing matrix
4. Populate in the appropriate channels of the WFS_OUTMATRIX

Grabbing data with nds

To run these on pianosa, I ran (inside the jupyter notebook)

I'm getting an error when starting the nds2 connection

conn = nds2.connection('192.168.113.201', 31200)
Failed to establish a connection[INFO: Request SASL authentication protocol]+

 I didn't find anything on the elog about this error, but I'm looking at the nds user manual. The problem was, I didn't have a valid Kerberos ticket; I opened one on Pianosa with my albert.einstein (note all caps ligo.org).

 I'm now able to run the scripts Rana mentions, but I haven't been able to grab the channels I want (eg C1:SUS-MC1_ASCPIT_IN1_OUT); it says the channel isn't found. When I check how many of the Caltech channels are available (conn.count_channels('C1*')), there are none. I was connecting to nds.ligo.caltech.edu, but this must be the wrong server (it has all the channels for the sites). fb and fb1 (and the IP they point to, 192.168.113.201) cannot be connected to, giving the error 'Error occurred trying to write to socket.'

I recall that in the cryo lab, we need to use port 8088 to get data from cymac1, and indeed substituting 31200 -> 8088 lets me access the C1 channels (I can count the channels), but no matter what time I request, nds tells me there is no data available (gap). Gautam came by and diagnosed that the gaps I'm seeing in the frames' data are real, fb is down (see elog).

WFS Sensing Matrix Script

Saving extra channels

Continuing, I'm going to modify the script to grab live data. I'm using the iterate and next methods. I noticed that the MC2_TRANS pit/yaw channels are not saved to frames, even though WFS1/2 pit/yaw are. Since I expect I'll want to lookback at these channels, I followed the instructions for adding a daq channel, uncommenting the following line in /opt/rtcds/caltech/c1/chans/daq/C1IOO.ini:

I made a backup of the old version of this .ini file, which can be found in /users/aaron/backups/190917_C1IOO.ini. I did not remake the model, as I couldn't find the c1ioo model in /opt/rtcds/caltech/c1/userapps/trunk or from the matlab command prompt. I restarted the fb via telnet, but didn't restart the model or check the svn (got an error?). The _DQ channels are now reachable on dataviewer, so things seem to be working.

awgpy

I also tried importing cdsutils, so I can control awg in the same script that we read out the sensing matrix, but I'm getting the python3 error when I import cdsutils:

I tried pip upgrading cdsutils, but it's already up-to-date. I get the above error even if I switch to a python 2 kernel; cdsutils is installed in the python2.7 directory, so I don't know why pip is finding it when I'm running a python 3 kernel. I can move on from this for now, but it would be useful to be able to script the excitation along with the measurement.

Changes to the user environment

jupyter on donatella

Tangentially related, Rika wanted to be running some jupyter notebooks while working on donatella. I ran, on donatella:

 hm, that didn't work. Also jupyter is installed when you install conda, so I'm not sure how there is a version of conda but not of jupyter. I also see that pip and pip3 are not recognized commands on donatella.

scipy on pianosa

I noticed that some of the functions in the scipy signal processing toolbox were out of date on pianosa. The cheby and welch filters now accept additional kwargs (for eg, before you needed to give IIR filter methods a cutoff frequency normalized to the Nyquist rate, but now you can give it the frequencies and sampling rate separately).

I want to update this package, but I hesitate to break everyone's existing scripts.

New DIMM cards have arrived. I stored them in the digital cabinet along y arm.

I booted Rossa in rescue mode; though I see no errors on bootup, I still see the same error ("a problem has occurred") after boot, and a prompt to logout. I powered rossa off/on (single short press of power button), no change.

Booting in debug mode, I see that the error occurs when mounting /cvs/cds, with the error

Which is odd, because when I boot in recovery mode, is mounts /cvs/cds successfully. 

I booted in emergency mode by adding to the boot command

systemd.unit=emergency.target

but didn't have the appropriate root password to troubleshoot further (the usual two didn't work).

I wanted to measure the RF transimpedance of the WFS heads, as outlined above.

Summary: Measurement is not done.

Details:

• closed the PSL shutter
• taped over the WFS 2 opening with frosted scotch tape
• illuminated the QPD with an incandescent flashlight.
  • All of the D batteries were close to dead, so it seemed dimmer than usual
• Observed the WFS2 segment 1 RF spectrum on the Agilent, but saw no difference between the spectrum with and without the flashlight. Must need a brighter light, and possibly also better alignment.
• Needed to skype someone and pass off the IFO to gautam, so I untaped the QPD, returned the appropriate LEMO connector, and opened the PSL shutter.

I set up the spectrum analyzer to make the WFS head RF transfer function measurement (V/W) on WFS1. I placed the Jenne laser on the AP table, along with the reference PD power supply, laptop, and laser power supply. The Agilent output AM modulates the laser; the reference PD is again NewFocus 1611, with its AC output sent to Agilent's R channel and DC output sent to an oscilloscope;

I closed the PSL shutter while checking for a location to place the breadboard, and opened it while writing this. Headed back to Cryo to pick up the large incandescent bulb we'd borrowed over the summer.

I measured the RF response of the fiber-coupled NewFocus 1611, calibrating out the cable delay. The laser current was set to 20.0 mA, and the RF power going into the splitter was -10 dBm. The DC voltage was 1.87 V, and Gautam and I measured the power from the fiber at 344uW.

Something still looks very wrong -- the PD is supposed to be flat out to 1GHz, and physical units pending, need food.

Summary:

The fiber-coupled PD seems to have a factor of ~1.5 difference in responsivity compared to the free-space PD. There are some differences in the two ways I made the measurement that I don't yet understand.

Details

I measured relative responsivities of the fiber and free coupled NewFocus 1611 PDs (scaled by the Jenne AM transfer function).

I made the measurement in two ways, see attachment three. In attachment one, I show the response for separately measuring the two PDs relative to a pickoff of the source (two-port thru calibration). In attachment two I measure the relative responses directly, without picking off a reference (three-port calibration). I scaled the transfer functions by their DC voltages; both PDs have transimpedances of 700 V/A.

However, there are some clear differences in the response (overall factor of 0.5dB offset that may be explained by a miscalibrated DC level; apparent periodicity in attachment 1) that I don't yet understand.The free path of the non-fiber PD is ~5-6 inches, which accounts for the ~45 degrees of phase advance of the fiber relative to free coupled PD signal. (12.7cm / (c / 300 MHz) * 360 degrees ~ 45 degrees)

Mon Oct 7 14:51:53 2019. I closed the PSL shutter to measure the WFS head responsivity.

I made a thru calibration as in this elog, treating laser, reference PD, and WFS RF output as a three-port device. The DC current supplied to the laser is 20.0 mA in all cases. The Agilent spectrum analyzer supplies a -10 dBm excitation to Jenne laser's AM port, and A/B is measured with 20dB attenuation on each input port. Results are in /users/aaron/WFS/data/191007/. The calibration had 100 averages, all other measurements 32 averages; other parameters found in the yml file, same folder as the data.

I normalized the result by the difference between the dark and bright DC levels of each segment.

Mon Oct 7 17:29:58 2019 opened PSL shutter.

I simulated this circuit with zero, but haven't gotten the results to match the measurements above.

I installed nds2 on donatello with yum, but still can't import nds2.

I installed nds2 again, this time successfully with

The backup of /cvs/cds (which runs as a cron job on fb40m; see /cvs/cds/caltech/scripts/backup/000README.txt) 
has been down since fb40m was rebooted on March 3.
I was unable to start it because of conflicting ssh keys in /home/controls/.ssh .
With help from Dan Kozak, we got it to work with both sets of keys
( id_rsa, which allows one to ssh between computers in our 113 network without typing a password,
 and backup2PB which allows the cron job to push the backup files to the archive in Powell-Booth).

It still goes down every time one reboots fb40m, and I don't have a solution.
A simple solution is for the script to send an email whenever it can't connect via ssh keys
(requiring a restart of ssh-agent with a passphrase), but email doesn't seem to work on fb40m.
I'll see if I can get help on how to have sendmail run on fb40m.

Ever since July 22, the backup script that runs on fb40m has failed to ssh to ldas-cit.ligo.caltech.edu to back up our trend frames and /cvs/cds.

This was a new failure mode which the scripts didn't catch, so I only noticed it when fb40m was rebooted a couple of days ago.

Alex fixed the problem (RAID array was configured with the wrong IP address, conflicting with the outside world), and I modified the script ( /cvs/cds/caltech/scripts/backup/rsync.backup ) to handle the new directory structure Alex made.

Now the backup is current and the automated script should keep it so, at least until the next time fb40m is rebooted...

After the mini boot fest that Jenne did today, I checked whether that fixed the overflow issues we yesterday prevented the alignemnt of the arms. 

I ran the alignment script for the arms getting 0.85 for TRX and 0.75 for TRY: low values.

After I ran the script ,C1SUSVME1 and C1SUSVME2 started having problems with the FE SYNC (counter at 16378). I rebooted those two and fix the sync problem but the transmitted powers didn't improve.

Are we still having problem due to MC misalignment?

See attachments

 I've now also trended the MOPA output power for the last 200 days to check a possible correlation with the FSS reflected power. See attachment.

The trend shows that the laser power has decayed but it seems that the FSS reflected power has done it even faster: 30% drop in the FSS vs 7% for the MOPA in the last 60 days (attachment n.2).

 more detailed instructions needed....

Carrier and SB (f2) shouldn't be resonant at the same time in the SRC-arms coupled cavity. No additional filtering of the GW signal is wanted.

The SRC macroscopic length is chosen to be = c / f2 - rather than = [ (n+1/2) c / (2*f2) ] - accordingly to that purpose.

I calculated the frequency of the double cavity pole for the 40m SRC-arm coupled cavity.

w_cc = (1 + r_srm)/(1- r_srm) * w_c

where w_c is the arm cavity pole angular frequency [w_c = w_fsr * (1-r_itm * r_etm)/sqrt(r_itm*r_etm) ]

I found the pole at about 160KHz. This number coincides with what I got earlier with my optickle model configured and tuned as I said in my previous entry. See attachments for plots of transfer functions with 0 and 10pm DARM offsets, respectively.

I think  the resonance at about 20 Hz that you can see in the case with non-zero DARM offset, is due to radiation pressure. Koji suggested that I could check the hypothesis by changing either the mirrors' masses or the input power to the interferometer. When I did it frequency and qualty factor of the resonance changed, as you would expect for a radiation pressure effect.

This gave me more confidence about my optickle model of the 40m. This is quite comforting since I used that model other times in the past to calculate several things (i.e. effects of higher unwanted harmonics from the oscillator, or, recently, the power at the ports due to the SB resonating in the arms).

We started a vacuum work in this morning. And still it's going on.

Although the last night the green team replaced a steering mirror by an 80% reflector on the PLS table, the beam axis to the MC looks fine.

The MC refl beam successfully goes into the MCrefl PD, and we can see the MC flashing as usual.

We started measuring the distance of the optics inside the vacuum chamber, found the distance from MC3 to MMT1(curved mirror) is ~13cm shorter than the design.

We moved the positions of the flat mirror after the Faraday and the MMT1, but could not track the beam very well because we did not completely lock the MC.

Now we are trying to get the lock of the MC by steering the MC mirrors.

P.S.

Kevin suceeded in locking it !!

 Here we trended also the PMC and the MZ. The drop in the PMC happens at the same rate as the MOPA's.

That let us think that the FSS transmitteed power has gone down because of the reference cavity progressive misalignment to the laser beam.

We need to adjust that alignment sometime.

The drop in the NPRO output power (upper row, 3rd plot: Ch10 C1:PSL_126MOPA_126MON) accompained an increase of "fuzziness" in PMCTRANSPD and both coincided in time with the day we tempoarirly removed the flap from the laser chiller's chiller (July 14 2009).

The frame builder is timed from the Symmetricom GPS card now, which is getting the IRIGB timecode from the freq. distribution amplifier (from the VME GPS receiver card).

I have adjusted the GPS seconds to match the real GPS time and the DTT seems to be happy: sweeping MC2 MCL filter module produces nice plot.

Test points are working on SUS.

Excitations are working on SUS.

I am leaving the frame builder running and acquiring the data.

Alex

I started my attempt on noise budgeting of ALS by going back to how Kiwamu did it and adding as many sources as I could find up till now. This calculation is present in ALS_Noise_Budget notebook. I intend to collect data for noise sources and all future work on ALS in the ALS repo.

The noise budget runs simulink through matlab.engine inside python and remaining calculations including the pygwinc ones are done in python. Please point out any errors that I might have done here. I still need to add noise due to DFD and the ADC after it. For the residual frequency noise of AUX laser, I have currently used an upper limit of 1kHz/rt Hz at 10 Hz free-running frequency noise of an NPRO laser.

I've added 4 proposed schemes for implementing ALS in voyager. Major thing to figure out is what AUX laser would be and how we would compare the different PSL and AUX lasers to create an error signal for ALS. Everywhere below, 2um would mean wavelengths near 2 um including the proposed 2128nm. Since it is not fixed, I'm using a categorical name. Same is the case for 1um which actually would mean half of whatever 2 um carries.

Higher Harmonic Generation:

• We can follow the current system of ALS with using 1.5 times PSL frequency as AUX instead of second harmonic as 1 um is strongly absorbed in Si.
• To generate 1.5 times PSL frequency, three stages would be required.
  • SHG: Second Harmonic Generation mode matched to convert 2um to 1um. If we are instead making 2 um from 1um to start with, this stage will not be required.
  • SFG: Sum Frequency Generation mode matched to sum 2um photon and 1um photon to give 0.65 um photon.
  • DPDC: Degenerate Parametric Down Conversion mode matched to convert 0.65 um to 1.3 um (which would be 1.5 times PSL frequency).
• To compare, we can either convert pick-off from PSL to AUX frequency by doing the above 3 stages (Scheme II).
• Or we can just do SHG and SFG at PSL pick-off and do another SHG at AUX end (Scheme I) to compare the AUX and PSL both converted to 0.65 um (which would be 2 times AUX and 3 times PSL frequency).
• This method would have added noise from SHG, SFG and DPDC processes along with issues to be inefficiency of conversion.

Arbitrary AUX frequency:

• We can get away with using some standard laser near 1.5 um region directly as AUX. Most probably this would be 1550 nm.
• What's left is to devise a method of comparing 1.5 um and 2um frequencies. Following are two possible ways I could think of:

Using a frequency comb:

• Good stable frequency combs covering the wavelength region from 1.5 um to 2 um are available of the shelf.
• We would beat PSL and transmitted AUX separately with the frequency comb. The two beat note frequencies would be:
  
  
• Here, m1 and m2 represent the nearest modes (comb teeth) of frequency comb to PSL and AUX respectively.
• Carrier Envelope Offset frequency () can be easily generated by using an SHG crystal in front of the Frequency comb. This step is not really required since most of the modern frequency combs now comb with inbuilt zero stabilization.
• Mixing above beatnotes with would remove from them along with any noise associated with .
• Further, a Direct Digital Synthesis IC is required to multiply the AUX side RF signal by m1/m2. This finally makes the two RF signals to be:
  
  
• Which on mixing would give desired error signal for DFD as :
  
• This method is described in Stenger et al. PRL. 88, 073601 and is useful in comparing two different optical frequencies with a frequency comb with effective cancellation of all noise due to the frequency comb itself. Only extra noise is from the DDS IC which is minimal.
• This method, however, might be an overkill and expensive. But in case (for whatever reason) we want to send in another AUX at another frequency down the 40m cavity, this method allows the same setup to be used for multiple AUX frequencies at once.

Using a Transfer Cavity:

• We can make another more easily controlled and higher finesse cavity with a PZT actuator on one of the mirrors.
• In the schematic, I have imagined it has a triangular cavity with a back end mirror driven by PZT.
• Shining PSL from one side of the transfer cavity and employing the usual PDH, we can lock the cavity to PSL.
• This lock would require to be strong and wide bandwidth. If PZT can't provide enough bandwidth, we can also put an EOM inside the cavity! (See this poster from Simon group at UChicago)
• Another laser at AUX frequency, called AUX2 would be sent from the other side of the cavity and usual PDH is employed to lock AUX2 to the transfer cavity.
• So clearly, this cavity also requires coatings and coarse length such that it is resonant with both PSL and AUX frequencies simultaneously.
• And, the FSS for AUX2 needs to be good and high bandwidth as well.
• The transmitted AUX2 from the transfer cavity now would carry stability of PSL at the frequency of AUX and can be directly beaten with transmitted AUX from the 40m cavity to generate an error signal for DFD.
• I believe this is a more doable and cheaper option. Even if we want to do a frequency comb scheme, this could be a precursor to it.

_________________________

EditTue Jul 21 17:24:09 2020: (Jamie's suggestion)

Using Mode Cleaner cavity as Transfer Cavity:

• If we coat the mode cleaner cavity mirrors appropriately, we can use it to lock AUX2 laser (mentioned above).
• This will get rid of all extra optics. The only requirement is for FSS to be good on AUX2 to transfer PSL (MC) stability to AUX frequency.
• I've added suggested schematic for this scheme at the bottom.

Setting the record straight

I found out an error I did in copying some control model values from Kiwamu's matlab code. On fixing those, we get a considerably reduced amount of total noise. However, there was still an unstable region around the unity gain frequency because of a very small phase margin. Attachment 3 shows the noise budget, ALS open-loop transfer function, and AUX PDH open-loop transfer function with ALS disengaged. Attachment 4 is the yaml file containing all required zpk values for the control model used. Note that the noise budget shows out-of-loop residual arm length fluctuations with respect to PSL frequency. The RMS curve on this plot is integrated for the shown frequency region.

Trying to fix the unstable region

Adding two more poles at 100 Hz in the ALS digital filter seems to work in making the ALS loop stable everywhere and additionally provides a steeper roll-off after 100 Hz. Attachment 1 shows the noise budget, ALS open-loop transfer function, and AUX PDH open-loop transfer function with ALS disengaged. Attachment 2 is the yaml file containing all required zpk values for the control model used. Note that the noise budget shows out-of-loop residual arm length fluctuations with respect to PSL frequency. The RMS curve on this plot is integrated for the shown frequency region.

But is it really more stable?

• I tried to think about it from different aspects. One thing is sure that  remains greater than 1 in all of the frequency region plotted for. This is also evident in the common-mode to residual noise transfer function which shows no oscillation peaks and is a clean mirror image of the open-loop transfer function (See Attachment 1, page 2).
• Another way is to look for the phase margin. This is a little controversial way of checking stability. For clarity, the open-loop transfer function I'm plotting does not contain the '-1' feedback in it. So the bad phase value at unity gain frequency is -180 degrees (or 180 degrees) for us. I've taken the difference from the closest side and got 76.2 degrees of phase margin.
• Another way I checked was by plotting a Nyquist plot for the open-loop transfer function. It is said that if the contour does not encircle the point '-1' in the real axis, then the loop would be stable even if the where is the frequency where phase lag becomes -180 degrees at the lowest frequency. For us, is at 1 Hz because of the test mass actuator pole. But I have verified that the Nyquist contour of the open-loop transfer function does not encircle '-1' point. I have not uploaded the Nyquist plot as it is not straight forward to plot. Because of large dc gain, it covers a large region and one needs to zoom in and out to properly follow what the contour is really doing. I didn't get time to make insets for it.

Is this close to reality?

For that, we'll have to take present noise source estimates but Gautum vaguely confirmed that this looked more realistic now 'shape-wise'. If I remember correctly, he mentioned that we currently can achieve 8 pm of residual rms motion in the arm cavity with respect to the PSL frequency. So we might be overestimating our loop's capability or underestimating some noise source. More feedback on this welcome and required.

Additional Info:

The code used to calculate the transfer functions and plot them is in the repo 40m/ALS/noiseBudget

Attachment 5 here shows a block diagram for the control loop model used. Output port 'Res_Disp' is used for referring all the noise sources at the residual arm length fluctuation in the noise budget. The open-loop transfer function for ALS is calculated by -(ALS_DAC->ALS_Out1 / ALS_DAC->ALS_Out2) (removing the -1 negative feedback by putting in the negative sign.) While the AUX PDH open-loop transfer function is calculated by python controls package with simple series cascading of all the loop elements.

This is not a reply to comments given to the last post; Still working on incorporating those suggestions.

Trying out a better filter from scratch

Rana suggested looking first at what needs to be suppressed and then create a filter suited for the noise from scratch. So I discarded all earlier poles and zeros and just kept the resonant gains in the digital filter. With that, I found that all we need is three poles at 1 Hz and a gain of 8.1e5 gives the lowest RMS noise value I could get.

Now there can be some practical reasons unknown to me because of which this filter is not possible, but I just wanted to put it here as I'll add the actual noise spectra into this model now.

Few questions:

• What anti-aliasing filters are used in ALS?
• Is the digital delay fixed to a constant upper limit or is it left to change as per filters? I have already used a 470 us delay (modeled with Pade 4th order approximation).
• I could not find a good place where channel names are listed with corresponding meaning. Where can I find them?
• Is there a channel which keeps a record of lock status? In short, how do I find the in-lock times

Yes, that loop was unstable. I started using the time domain response to check for the stability of loops now. I have been able to improve the filter slightly with more suppression below 20 Hz but still poor phase margin as before. This removes the lower frequency region bump due to seismic noise. The RMS noise improved only slightly with the bump near UGF still the main contributor to the noise.

For inclusion of real spectra, time delays and the anti-aliasing filters, I still need some more information.

Few questions:

• What anti-aliasing filters are used in ALS?
• Is the digital delay fixed to a constant upper limit or is it left to change as per filters? I have already used a 470 us delay (modeled with Pade 4th order approximation).
• I could not find a good place where channel names are listed with corresponding meaning. Where can I find them?
• Is there a channel which keeps record of lock status? In short, how do I find the in-lock times

Additional Info:

The code used to calculate the transfer functions and plot them is in the repo 40m/ALS/noiseBudget

Related Elog post with more details: 40m/15587

The only two PZT Phase modulation transfer function measurements I could find are 40m/15206 and 40m/12077. Both these measurements were made to find a good modulation frequency and do not go below 50 kHz. So I don't think these will help us. We'll have to do a frequency transfer function measurement at lower frequencies.
I'm still looking for ALS PDH loop measurements to verify the model. I found this 40m/15059 but it is only near the UGF. The UGF measured here though looks very similar to the model prediction. A bit older measurement in 2017 was this 40m/13238 where I assume by ALS OLTF gautum meant the green laser PDH OLTF. It had similar UGF but the model I have has more phase lag, probably because of a 31.5 kHz pole which comes at U7 through the input low pass coupling through R28, C20 and R29 (See D1400293)

If the green laser is not being used, can I go and take some of these measurements myself?

Koji recommended that I can add whitening filters to suppress ADC noise easily. I added a filter before ADC in ALS loop with 4 zeros at 1.5 Hz and 4 poles at 100 Hz and added a reversed filter in the digital filter of ALS. This did not change the performance of the loop but significantly reduced the contribution of ADC noise above 1 Hz. One can see ALS_controls.yaml for the filter description. Please let me know if this does not make sense or there is something that I have overlooked.

Now, the dominant noise source is DFD noise below 100 Hz and green laser frequency noise above that. For DFD noise, I used data dating back to Kiwamu's paper. The noise contribution from DFD in the model is lower than the latest measured ALS noise budget post on elog. I'll look further into design details and noise of DFD.

Code, data, and schematics