40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 60 of 339  Not logged in ELOG logo
ID Date Author Type Category Subject
  14070   Fri Jul 13 23:23:49 2018 poojaUpdateCamerasUpdate in developing neural networks

Aim: To develop a neural network that resolves mirror motion from video.

I tried to reduce the overfitting problem in previous neural network by reducing the number of nodes and layers and by varying the learning rate, beta factors (exponential decay rates of moving first and second moments) of Nadam optimizer assuming error of 5% is reasonable.


32 * 32 image frames (converted to 1d array & pixel values of 0 to 255 normalized) of simulated video by applying sine signal to move beam spot in pitch with frequency 0.2Hz and at 10 frames per second.

Total: 300 cycles ,           Train: 60 cycles,    Validation: 90 cycles,    Test: 150 cycles

Model topology:

                                          Input               -->                  Hidden layer               -->                    Output layer                                  

                                                                                          4 nodes                                              1 node

Activation function:                                  selu                                             linear

Batch size = 32, Number of epochs = 128, loss function = mean squared error

Optimizer: Nadam

Case 1:

Learning rate = 0.00001,    beta_1 = 0.8 (default value in Keras = 0.9),  beta_2 = 0.85 (default value in Keras = 0.999)

Plot of predicted output by neural network, applied input signal & residual error given in 1st attachment.

Case 2:

Changed number of nodes in hidden layer from 4 to 8. All other parameters same.

These plots show that when residual error increases basically the output of neural network has a smaller amplitude compared to the applied signal. This kind of training error is unclear to me.

When beta parameters of optimizer is changed farther from 1, error increases.

  14069   Fri Jul 13 20:36:33 2018 KojiSummaryGeneralIn vac/In air heater wiring

I went to the Y-end and took more photos of the cable stand. These revealed that in-vac pin #13 is connected to the shield of the cable (P.2). This in-vac pin #13 corresponds to  in-air pin #1. So in the end, we bunch the pins in the following order.

In Air In Vac
Pin #2-7 Pin #12-7
Pin #8-13 Pin #6-1
Pin #14-19 Pin #25-20
Pin #20-25 Pin #19-14


  14068   Fri Jul 13 18:01:13 2018 gautamUpdateGeneralLow power MC

After getting the go ahead from Steve, I removed the physical beam block on the PSL table, sent the beam into the IFO, and re-aligned the MC to lock at low power. I've also revived my low power autolocker (running on megatron), seems to work okay though the gains may not be optimal, but it seems to do the job for now. Nominal transmission when well aligned at low power is ~1200cts. I briefly checked Y arm alignment with the green, seems okay, but didn't try locking the Y arm yet. All doors are still on, and I'm closing the PSL shutter again while Keerthana and Sandrine are working near the AS table.

  14067   Fri Jul 13 17:13:45 2018 KojiUpdateGeneralVent objectives and prep

Notice: I removed these 75Ohm video cables.

  14066   Fri Jul 13 16:26:52 2018 SteveUpdateVACVent 80 is completing...

Steve and Aaron,

6 hrs vent is reaching equlibrium to room air. It took 3 and a half instrument grade air cilynders [ AI UZ300 as labelled ] at 10 psi pressure. Average vent speed ~ 2 Torr/min

Valve configuration: IFO at atm and RGA is pumped through VM2 by TP1 maglev.


  14064   Fri Jul 13 10:54:55 2018 aaronUpdateVACVent 80

[aaron, steve]

Steve gave me a venting tutorial. I'll record this in probably a bit more detail than is strictly necessary, so I can keep track of some of the minor details for future reference.

Here is Steve's checklist:

  • Check that all jam nuts are tightened
  • all viewports are closed
  • op levs are off
  • take a picture of the MEDM screens
  • Check particle counts
  • Check that the cranes work & wiped
  • Check that HV is off

Gautam already did the pre-vent checks, and Steve took a screenshot of the IFO alignment, IMC alignment, master op lev screen, suspension condition, and shutter status to get a reference point. We later added the TT_CONTROL screen. Steve turned off all op levs.

We then went inside to do the mechanical checks

  • N2 cylinders in the 40m antechamber are all full enough (have ~700psi/day of nitrogen)
  • We manually record the particle count
    • this should be <10,000 on the 0.5um particles to be low enough to vent, otherwise we will contaminate the system
    • note: need to multiply the reading on the particle counter by 10 to get the true count
    • the temperature inside the PSL enclosure should be 23-24C +/- 3 degrees
    • We recorded the particle counts at ~830 and ~930, and the 0.5um count was up to ~3000
  • We put a beam stop in front of the laser at the PSL table
  • Checked that all HV supplies are either off or supplying something in air
    • we noticed four HV supplies on 1X1 that were on. Two were accounted for on the PSL table (FSS), and the other two were for C1IOO_ASC but ran along the upper cable rack. We got ahold of Gautam (sorry!) and he told us these go to the TT driver on OMC_SOUTH, where we verified the HV cables are disconnected. We took this to mean these HV supplies are not powering anything, and proceeded without turning these HV off.
    • There are HV supplies which were all either off or supplying something in-air at: 1Y4, 1Y2, OMC N rack, 1X9 (green steering HV)
  • Checked that the crane works--both move up and down
    • vertex crane switch is on the wall at the inner corner of the IFO
    • y arm crane switch is on the N wall at the Y end
    • turn off the cranes at the control strip after verifying they work
  • While walking around checking HV, we checked that the jam nuts and viewports are all closed
    • we replaced one viewport at the x arm that was open for a camera

After completing these checks, we grabbed a nitrogen cylinder and hooked it up to the VV1 filter. Steve gave me a rundown of how the vacuum system works. For my own memory, the oil pumps which provide the first level of roughing backstream below 500mtorr, so we typically turn on the turbo pumps (TP) below that level... just in case there is a calibrated leak to keep the pressure above 350mtorr at the oil pumps. TP2 has broken, so during this vent we'll install a manual valve so we can narrow the aperture that TP1 sees at V1 so we can hand off to the turbo at 500mtorr without overwhelming it. When the turbos have the pressure low enough, we open the mag lev pump. Close V1 if things screw up to protect the IFO. This 6" id manual gatevalve will allow us throttle the load on the small turbo while the maglev is taking over the pumping  The missmatch in pumping speed is 390/70 l/s [ maglev/varian D70 ]  We need to close down the conductive intake of the TP1 with manual gate valve so the 6x smaller turbo does not get overloaded...

We checked CC1, which read 7.2utorr.

Open the medm c0/ce/VacControl_BAK.adl to control the valves.

Steve tells me we are starting from vacuum normal state, but that some things are broken so it doesn't exactly match the state as described. In particular, VA6 is 'moving' because it has been disconnected and permanently closed to avoid pumping on the annulus. During this v ent, we will also keep pumping on the RGA since it is a short vent; steve logged the RGA yesterday.

We began the vent by following the vacuum normal to chamber open procedure.

  1. VM1 closed
  2. We didn't open VM3, because we want to keep the RGA on
  3. Closed V1
  4. Connect the N2 to the VV1 filter
    1. first puged the line with nitrogen
    2. We confirmed visually that V1 is closed
  5. We opened VM2 to pump on the RGA with the mag lev pump.
    1. This is a nonstandard step because we are keeping the RGA pumped down.
    2. The current on TP3 is ~0.19A, which is a normal, low load on the pump
  6. VV1 opened to begin the vent at ~10:30am
    1. use crescent wrench to open, torque wrench wheel to close
    2. Keep the pressure regulator below 10 psi for the vent. We started the vent with about 2psi, then increased to 8psi after confirming that the SUS sensors looked OK.
  7. We checked the pressure plot and ITMX/ETMX motion to make sure we weren't venting too quickly or kicking the optics
    1. Should look at eg C1:SUS-ITMX_SENSOR_LL, as well as C1:Vac-P1_pressure
  8. Once the pressure reaches 25torr, we switched over to dry air
    1. wipe off the outside dolly wheels with a wet rag, and exit through the x-arm door to get the air. Sweep off the area outside the door, and wipe off new air containers with the rag.
    2. Bring the cylinder inside, get the regulator ready/purged, and swap relatively quickly.
    3. We increased the vent speed to 10psi. 
    4. Steve says the vents typically take 4 of 300 cf cylinders from Airgas "Ultra Zero" AI  UZ300 that contains 0.1 PPM of THC

Everything looks good, so I'm monitoring the vent and swapping out cylinders.

At 12:08pm, the pressure was at 257 torr and I swapped out in a new cylinder.

Steve: Do not overpressurize the vacuum envelope! Stop around 720 Torr and let lab air do the rest. Our bellows are thin walled for seismic isolation.

  14063   Fri Jul 13 02:52:11 2018 gautamUpdateGeneralVent objectives and prep

[KA, GV]

  1. Arm scan setup moved from West side of PSL table to North side of AP table
    • Marconi is now providing the LO for the loop. A ~5m 50ohm BNC cable needs to be laid out from the PLL area to the NW corner of the AP table where the Agilent is for the TF measurement scheme which allows phase discrimination.
    • We took this opportunity to characterize/improve the setup a bit, and also clean up the 10s of cables around the PSL table. There were some Video cables (75ohm instead of 50ohm no) that were part of the scanning setup which we excised.
    • Mode matching onto beat PD on PSL table was improved - beat signal Vpp increased by factor of 2. PLL gain was adjusted accordingly. 
    • AUX power @AP table ~37mW (before recombination BS), ~3.7mW onto SRM, ~200uW onto ITMY.
    • We got a beatnote in transmission of ~120uV (rms?) after optimizing alignment into Y arm cavity with the AUX frequency on an arm FSR.
    • From Sandrine's calculations, I expected ~20mV of beat signal. We leave it to Annalisa and Terra to square that circle. Probably the MM into the arm isn't stellar either, and we didn't check the polarization of the aux beam (that it is matched to the IFO's p-pol).
    • The entire AUX injection chain needs careful characterization before
  2. Vent prep
    • Both arms were locked to IR, TRY maximized using ASS, TRX maximized by hand.
    • GTRY and GTRX were also maximized.
    • All test mass/PRM/SRM oplevs were centered with this "good" alignment.
    • PSL power into the IMC was cut from 1.07 W (measured after G&H mirror) to 97 mW, by rotating the waveplate immediately after the PSL (original angle 180deg, new angle 216 degrees).
    • PMC was locked. I did not need to change any of the gain settings.
    • 2" R=10% BS in the IMC REFL path was replaced with a Y2, so there is no MCREFL till we turn the power back up.
    • IMC was locked. I touched up my IMC low power autolocker, but this probably needs a bit more touching up tomorrow. MC has remained locked at low power for ~25mins, but as I typed this, I jinxed it and it lost the lock. anyway we have good alignment references.
    • PSL shutter will remain closed.

@SV, we are ready to vent tomorrow. Aaron is supposed to show up ~830am to assist.

  14062   Fri Jul 13 00:15:13 2018 Annalisa, TerraConfigurationAUXY arm cavity scan

[Annalisa, Terra, Koji, Gautam]

Summary: We find a configuration for arm scans which significantly reduces phase noise. We run several arm scans and we were able to resolve several HOM peaks; analysis to come.


As first, we made a measurement with the already established setup and, as Jon already pointed out, we found lots of phase noise. We hypothesized that it could either come from the PLL or from the motion of the optics between the AUX injection point (AS port) and the Y arm. 

  • We first characterized the PLL loop phase noise by comparing the beat signal against the Agilent reference signal, and we found that the beat had lots of phase noise with respect to the reference. Decreasing the PLL gain, we got rid of the phase noise in the beat signal.
  • Next, for the optical path length induced phase noise, we took the transfer function between TransMon and REFL signal rather than TransMon and Agilent reference signal. This takes advatage of the fact that the TransMon and REFL both see optical path length phase noise, which therefore gets canceled out in the transfer function. 

In this configuration, we were able to do arm scans where the phase variation at each peak was pretty clear and well defined. We took several 10MHz scan, we also zoomed around some specific HOM peak, and we were able to resolve some frequency split. 

We add some pictures of the setup and of the scan.

The data are saved in users/OLD/annalisa/Yscans. More analysis and plots will follow tomorrow. 

  14061   Thu Jul 12 23:59:14 2018 gautamUpdateGeneralVent objectives and prep

Vent objectives:

  1. Install radiative heater setup in EY chamber.
  2. Re-direct 50% of AS beam to OMC
    • First, we need to check if the OMC trans PDs work. Else, we have to consider using some in-air PDs for the transmon.
    • Check that OMC length PZT works.
    • Check that OMC steering PZTs work (Koji and I have used this in 2016 to check AS beam clipping so they should work).

We only anticipate opening up the IOO chamber and the EY chamber.

Vent preparation: see here.

  14060   Thu Jul 12 21:16:25 2018 aaronUpdateOMCChecking OMC Electronics

In preparation for tomorrow's vent, I'm checking some of the OMC-related electronics we plan to use.

First up is the HV Piezo Driver (D060283).

(well, technically the first up was the Kepco HV power supply... but I quickly tested that its output works up to 300V on a multimeter. The power supply for OMC-L-PZT is all good!)

According to the DCC, the nominal HV supply for this board is 200V; the board itself is printed with "+400V MAX", and the label on the HV supply says it was run at 250V. For now I'm applying 200V. I'm also supplying +-15V from a Tektronix supply.

I used two DB25 breakout boards to look at the pins for the DC and AC voltage monitors (OMC_Vmon_+/-, pins 1/6, and OMC_Vmon_AC+/-, pins 2 and 7) on a scope. I hooked up a DS345 function generator to the piezo drive inputn (pins 1,6). According to the 2013 diagram from the DCC, there is just one drive input, and an alternative "dither in" BNC that can override the DAC drive signal. I leave the alternative dither floating and am just talking to the DAC pins.

Aspects of the system seem to work. For example, I can apply a sine wave at the input, and watch on the AC monitor FFT as I shift the frequency. However, anything I do at DC seems to be filtered out. The DC output is always 150V (as long as 200V comes from the supply). I also notice that the sign of the DC mon is negative (when the Vmon_+ pin is kept high on the scope), even though when I measure the voltage directly with a multimeter the voltage has the expected (+) polarity.

A few things to try:

  • The DC_Readout electronics scheme on the wiki has separate oscillator and control inputs. This diagram has lied to us in the past and is older, and the traces on top of the breadboard seem to only go to pins 1 and 6, but I'm going to first try to apply a voltage across pins 2 and 7 in case there actually is a separate control I'm ignoring.
    • Driving on these pins seems to do nothing

On further investigation this was the key clue. I had the wrong DCC document, this is an old version of this board, the actual board we are using is version A1 of D060283-x0 (one of the "other files")

Gautam and Koji returned at this point and we started going through the testpoints of the board, before quickly realizing that the DC voltage wasn't making it to the board. Turns out the cable was a "NULL" cable, so indeed the AC wasn't passing. We swapped out the cable, and tested the circuit with 30V from the HV supply to trim the voltage reference at U14. The minimum voltage we could get is 5V, due to the voltage divider to ground made by R39. We confirmed that the board, powered with 200V, can drive a sine wave and the DC and AC mons behave as expected.

  14059   Thu Jul 12 16:18:22 2018 SteveUpdateVACVent preparations

We are getting ready to vent.


  14058   Thu Jul 12 15:15:47 2018 SandrineUpdate Beat Note Measurements for Cavity Scans

(Gautam, Sandrine)

We calculated the expected power of the beat note for Annalisa's Y arm cavity scans. 

Beat Note Measurement

We began by calculating the transmitted power of the PSL and AUX. We assumed that the input power of the PSL was 25 mW and the input power of the AUX was 250 uW. We also assumed a loss of 25 ppm for the ITM and ETM. We used T1 = 0.0138 and T2 = 25 x 10-6. 

P_{t} = \frac{t _{1}^{2}t_{2}^{2}}{1+r_{1}^{2}r_{2}^{2}-2r_{1}r_{2}}

t = \sqrt{T}          

r = \sqrt{1-T-L} = {\sqrt{R}}

The transmitted power of the PSL is approximately 100 uW, and the transmitted power of the AUX is approximately 0.974 uW. 

P_{t}^{PSL} = 100 uW                          P_{t}^{AUX} = 0.974 uW

The beat note was calculated with the following:

P_{beat} = 2\sqrt{P_{PSL}P_{AUX}} = 20 uW

The  expected beat note should be approximately 20 uW. 

  14057   Thu Jul 12 14:06:39 2018 keerthanaUpdateelogFinesse and Analytical solution - Comparison

I tried to compare the cavity scan data we get from the Finesse simulation and that we expect from the Analytical solution. The diagram of the cavity I defined in Finesse is given below along with the values of different quantities I used. For the analytical solution I have used two different equations and they are listed below.

Analytical 1 - Blue Graph

\phi = \frac {2.L.\Omega_1}{c}

t_{cav} = \frac{t_e. t_f \exp^{-i\frac{\phi}{2}}}{1- r_f. r_e \exp^{-i\phi} }

T_{cav} = \left|{t_{cav}} \right|^2


Analytical 2 - Red Graph

F = \frac {4. r_f.r_e}{(1-r_f.r_e )^2}

\phi = \frac {2.L.\Omega_1}{c}

T_{cav} = \left|{t_{cav}} \right|^2 = \frac {(t_e.t_f)^2}{(1 - r_f . r_e)^2} \frac{1}{1+F(\sin\frac {\phi}{2})^2}

The graph obtained from both these solutions completely matches with each other.

Finesse Solution

The cavity which I defined in Finesse is shown below. The solution from Finesse and the Analytical solution also matches with each other. Another plot is made by taking the difference between Finesse solution and Analytical solution. The difference seems to be of the order of \approx 10^{-19}.

The Difference plot is also attached below.

  14056   Thu Jul 12 12:26:39 2018 aaronUpdateGeneralOMC revival

We found a diagram describing the DC Readout wiring scheme on the wiki page for DC readout (THIS DIAGRAM LIED TO US). The wiring scheme is in D060096 on the old DCC.

Following this scheme for the OMC PZT Driver, we measured the capacitance across pins 1 and 14 on the driver end of the cable nominally going to the PZT (so we measured the capacitance of the cable and PZT) at 0.5nF. Gautam thought this seemed a bit low, and indeed a back of the envelope calculation says that the cable capacitance is enough to explain this entire capacitance.

Gautam has gone in to open up the HV driver box and check that the pinout diagram was correct. We could identify the PZT from Gautam's photos from vent 79, but couldn't tell if the wires were connected, so this may be something to check during the vent.


Turns out the output was pins 13 and 25, we measured the capacitance again and got 209nF, which makes a lot more sense.

  14055   Thu Jul 12 11:13:39 2018 gautamUpdateGeneralOMC revival

Aaron and I are going to do the checkout of the OMC electronics outside vacuum today. At some point, we will also want to run a c1omc model to integrate with rtcds. Barring objections, I will set up this model on one of the spare cores on the physical machine c1ioo tomorrow.

  Draft   Wed Jul 11 18:13:19 2018 keerthanaSummaryAUXGouy Phase Measurements from AUX-Laser Scans

From the Measurement Jon made, FSR is 3.967 MHz and the Gouy phase is 52 degrees. From this, the length of the Y-arm cavity seems to be 37.78 m and the radius of curvature of the mirror seems to be 60.85 m.


Guoy Phase = \cos^{-1} \sqrt{g1.g2}

\\ g = 1- \frac{L}{R}

L = \frac {c} {2*FSR}

FSR = Free spectral Range

L = Lenth of the arm

R = Radius of curvature of the mirror (R1 =\infty  , R2= unknown)


This note reports analysis of cavity scans made by directly sweeping the AUX laser carrier frequency (no sidebands). The measurement is made by sweeping the RF offset of the AUX-PSL phase-locked loop and demodulating the cavity reflection/transmission signal at the offset frequency.

Y-Arm Scan

Due to the simplicity of its expected response, the Y-arm cavity was scanned first as a test of the AUX hardware and the sensitivity of the technique. Attachment 1 shows the measured cavity transmission with respect to RF drive signal.

The AUX laser launch setup is capable of injecting up to 9.3 mW into the AS port. This high-power measurement is shown by the black trace. The same measurement is repeated for a realistic SQZ injection power, 70 uW, indicated by the red curve. At low power, the technique still clearly resolves the FSR and six HOM resonances. From the identified mode resonance frequencies the following cavity parameters are directly extracted.

YARM Gautam V. Finesse Model Actual
FSR 3.966 MHz 3.967 MHz
Gouy phase 54.2 deg 52.0 deg



  14053   Wed Jul 11 16:50:34 2018 poojaUpdateCamerasUpdate in developing neural networks

Aim: To develop a neural network that resolves mirror motion from video.

I had created a python code to find the combination of hyperparameters that trains the neural network. The code (nn_hyperparam_opt.py) is present in the github repo. It's running in cluster since a few days. In the meanwhile I had just tried some combination of hyperparameters.

These give a low loss value of approximately 1e-5 but there is a large error bar for loss value since it fluctuates a lot even after 1500 epochs. This is unclear.

Input: 64*64 image frames of simulated video by applying beam motion sine wave of frequency 0.2Hz and at 10 frames per sec. This input data is given as an hdf5 file.

Train : 100 cycles,  Test: 300 cycles, Optimizer = Nadam (learning rate = 0.001)

Model topology:

                    256       ->      128    ->       1

Activation :        selu     selu           linear

Case 1: batch size = 48, epochs = 1000, loss function = mean squared error

Plots of output predicted by neural network (NN) & input signal has been shown in 1st graph & variation in loss value with epochs in 2nd graph.

Case 2: batch size = 32, epochs = 1500, loss function = mean squared logarithmic error

Plots of output predicted by neural network (NN) & input signal has been shown in 3rd graph & variation in loss value with epochs in 4th graph.




  14052   Wed Jul 11 16:23:21 2018 aaronUpdateOMCCoordination of the Output Mode-cleaner Mirror Insertion Expedition (COMMIE)

I started this document on my own with notes as I was tracing the beam path through the output optics, as well as some notes as I started digging through the elogs. Let's just put it here instead....

  1. Beam from AS port into OMMT
  2. Reflect off OM5-PJ
    1. TO DO: check that the PZT works
    2. 40/P/F/L, 1525-45-P
  3. Pick off from OMPO
    1. TO DO: determine how much power is needed for the pick off, choose an appropriate optic (for this vent probably 50-50 is fine)
    2. The PO beam goes to OM6
  4. Reflect off MMT1???
    1. TO DO: determine if this mirror has a PZT, get it working
      1. Has a PZT?
      2. Which PZT channel on the DAQ?
      3. Is there a cable going to from the DAC to the PZT?
      4. Is the PZT functional?
      5. How many PZTs does this mirror actually have?
    2. TO DO: determine the real name of this optic, find its recent history in the elog
    3. TO DO: determine the correct telescope parameters to optimally couple into the mode cleaner given the following:
    4. TO DO: look up how the radius of curvature (RC) of the OMC has changed, and therefore what telescope parameters are necessary
  5. Focused by MMT2???
    1. TO DO: determine if this mirror has a PZT
      1. Has a PZT?
      2. Which PZT channel on the DAQ?
      3. Is there a cable going to from the DAC to the PZT?
      4. Is the PZT functional?
      5. How many PZTs does this mirror actually have?
    2. TO DO: determine the real name of this optic, find its recent history in the elog
    3. TO DO: what about this optic is tunable? It looks bulky
  6. Columnated by MMT3???
    1. TO DO: determine if this mirror has a PZT
      1. Has a PZT?
      2. Which PZT channel on the DAQ?
      3. Is there a cable going to from the DAC to the PZT?
      4. Is the PZT functional?
      5. How many PZTs does this mirror actually have?
  7. Steered by MMT4???
    1. TO DO: determine the real name of this optic
    2. TO DO: why is this optic so small? Looks different from the rest, maybe weird space constraint
  8. Steered by MMT5???
    1. TO DO: why is this optic so large compared to OMMT4?
    2. TO DO: is there a more space efficient way of steering this beam, or even some way that avoids having to steer with three distinct optics
  9. Steered by MMT6???
    1. TO DO: Can this optic be removed with some clever new beam path?
  10. Cleaned by the OMC
    1. TO DO: Where does the promptly reflected beam from OMC1 go after it exits the chamber?
    2. TO DO: check the PZTs
      1. Has a PZT?
      2. Which PZT channel on the DAQ?
      3. Is there a cable going to from the DAC to the PZT?
      4. Is the PZT functional?
      5. How many PZTs does the OMC actually have?
    3. TO DO: Determine if a new OMC configuration would be more ideal for the squeezing experiment
      1. This is a large task, not part of this immediate vent
    4. TO DO: What is done with the OMC reflection? What is done with the transmission?
    5. TO DO: Check the logs about how the OMC had been in use; should be mostly from rob ward
  11. Reflected beam goes to the next chamber
  12. Transmitted beam is split by OM7???
    1. TO DO: find the actual name of this optic
    2. TO DO: why does this have the R/T that is does?
  13. Reflected beam goes to my OMPD
    1. TO DO: figure out what this PD is used for, and whether we even need it
      1. I think this might be the camera mentioned in 40m elog 21
      2. Elog 42 says the 4 QPDs for the OMC have meds screens located under C2TPT—is this a clue for channel names?
  14. Transmitted beam is reflected to the next chamber by OM8???
    1. TO DO: determine the name of this optic
    2. TO DO: Where does this beam go? What is it used for?
  15. Beam Dumps to add
    1. Transmission through OM5? Probably don’t need…
    2. OMMT1 transmission
    3. OMMT steering mirror transmissions
    4. OMC transmissions? Probably not?
    5. OMPD transmission?
    6. OM8 transmission
    7. Green scattering off of the window where the beam goes after GR_SM5
    8. Backscatter from the OMC prompt reflection to the window
    9. Backscatter from the OMC reflection to the window
    10. Backscatter from the MC beam off the window (this beam just travels through this chamber, interacts with no optics; there is also what looks like a small blue beam on this diagram, so maybe need to dump that backscatter too)
    11. Backscatter from the PO beam from OM6 going through the chamber window
    12. Backscatter from IM1 out the window
    13. There is a small blue beam from OMMT3 that goes through this window as well, I’m not sure exactly what is is from or for, or if it is physical (there are a few of these strange blue lines, i'm probably just misreading the diagram)
    1. Characterize the PZT control
    2. Lock the OMC with a PZT dither lock
      1. Eg elog 59
    3. “Tap-tap-tappy-tap test” to find resonanes
      1. Look at combination of PDH error signal and DCPD signal???
      2. See elog 86 for results from initial OMC install—Nov 2007
    4. Check wiggling wires, etc
    5. TFs to check? Vertical TF?
    6. OMC Length check— see for eg elog 768
    1. Mode matching calculation for new radius of curvature optics—see elog 1271
      1. The current MMT is not the optimal configuration even for the old Rc (see 3077 and 3088)


Notes during reading elog

  • Entry 590 has a labelled picture of the optics setup with OMC
  • Mention of omcepics at elog 894
  • Some important changes happened in elog 1823
    • 1''->2'' mirror out of the vacuum--I should check whether this is still there, or if it has been moved
    • [many more changes.....]
  • There were at one time 2 cameras monitoring OMCT and R (see 4492, 4493)
  • Some OMC PZT HV supply info is at elog 4738, 4740... 
  • There are some photos of the OMC table at elog 5120, and a note about moving some optics
  • Not strictly about the OMC, but I really like Suresh's diagram 6756, I'll make something similar for the OMC electronics
    • although it is about adding the tip tilt electronics, which I think required a new flange for the OMC chamber
  • OMC stage 1 and 2 are the steering mirrors going into the OMC, and were controlled by EPICS chans (6875, 6884)
    • these PZT HV supplies lived in OMC_SOUTH (or maybe 1Y3? see elog 6893), the driver in OMC_NORTH (LIGO-D060287)
    • Photos of these supplies in 7696
  • There are pictures of the OMC and its PZTs in 7401
  • The OMC HV supply was moved to power a different set of PZTs (see 7603)
  • Talk of replacing the PZTs with picomotors or tip/tilts in 7684
  • More pictures of the OMC table before the OMC was 'removed' are here (8114) and in 12563/12571 Gautam links to a Picassa album with pictures from just before the beam was diverted
  14051   Wed Jul 11 15:57:00 2018 aaronUpdateOMCReviving OMC electronics
Gautam showed me the electronics racks for the OMC PZTs and DAQ. I'm in the process of chasing down what channels we need, and confirming that we'll be able to plug the old antialiasing/imaging boards into the current DAC/ADC boards. I found what I think was Rob Ward's simlink model for the omc, located at
Channels in this model:
  • 27 or 29 total ADC channels are used (depending whether we keep 2 spare adc chans)
    • 4 each go to ASC_QPD1/2 (8 chans total)
    • 5 go to TRANS_PD1, TRANS_PD2, REFL_PD, TRANS_PD1_UF, TRANS_PD2_UF. These PD are used for ASC and LSC.
    • 2 go to the LSC, one each for DVMDC, DVMAC, X3DC, and X4DC
    • 12 go to the ASC_PZT
    • 2 go to the SPARE_ADC (not sure what this is)
    • I think these channels are (or were at some point) defined in memory by /cvs/cds/caltech/chans/ipc/G1.ipc
      • I found this from elog 2860; it mentions that these should eventually be migrated over to a file C1.ipc, but I don't see any OMC channels in that file or any of the 'old' C1.ipc files, so I suppose it never happened or they were removed later
    • During this vent, we won't have ASC, so
  • 10 or 14 DAC channels are used (depending whether we keep 4 spare dac chans)
    • 2 from the LSC, one for CLK_OUT and one for "LSC"
    • 8 from ASC, including P1A, P1B, P2A, P2B, P1OSC, Y1OSC, P2OSC, Y2OSC
    • I think these channels are (or were at some point) saved to frames due to /cvs/cds/caltech/chans/daq/C1OMC.ini, which I found from elog 2073
    • At some point, the 33MHz mod depth was controlled by one of the spare OMC chans, C1:OMC-SPARE_DAC_CH_15. See elog 2126. I assume this is no longer the case, since c1omc is defunct.
    • Durnig this vent, we won't have ASC and don't need to CLK_OUT the LSC, so we may just need one DAC channel

As of at least Nov 2009, the .par file for the OMC was located at /cvs/cds/gds/param/tpchn_C2 (see elog 2316)

Electronics inventory:
  • Kepco HV supply, "OMC-L-PZT", labels indicate it goes to 250V, needs to be tested  ("TESTED OK 2014OCT12")
  • Tip/Tilt Piezo Driver, LIGO D060287
  • HV Piezo Driver, LIGO D060283
  • QPD Whitening Board, D060214
  • LIGO D050374/D050387
  • LIGO D050368/D050373

Need to check:

  • Can the ADC/DAC adapter boards (eg D0902006) drive whatever ~10V control signal we need across ~10m of SCSI cable?
  14050   Tue Jul 10 23:44:23 2018 AnnalisaConfigurationThermal CompensationHeater setup assembly

[Annalisa, Koji]

Today both the heater and the reflector were delivered, and we set down the setup to make some first test.

The schematic is the usual: the rod heater (30mm long, 3.8 mm diameter) is set inside the elliptical reflector, as close as possible to the first focus. In the second focus we put the power meter in order to measure the radiated power. The broadband power meter wavelength calibration has been set at 4µm: indeed, the heater emits all over the spectrum with the Black Body radiation distribution, and the broadband power meter measures all of them, but only starting from 4µm they will be actually absorbed my the mirror, that's why that calibration was chosen.

We measured the cold resistance of the heater, and it was about 3.5 Ohm. The heater was powered with the BK precision DC power supply 1735, and we took measurements at different input current.

Current [A] Voltage [V] Measured radiated power [mW] Resistance [Ohm]
0.5 2.2 20 4.4
0.8 6 120 7.5
1 11 400 11
1.2 18 970 15

We also aimed at measuring the heater temperature at each step, but the Fluke thermal camera is sensitive up to 300°C and also the FLIR seems to have a very limited temperature range (150°C?). We thought about using a thermocouple, but we tested its response and it seems definitely too slow. 

Some pictures of the setup are shown in figures 1 and 6.

Then we put an absorbing screen in the suspension mount to see the heat pattern, in such a way to get an idea of the heat spot position and size on the ETMY. (figure 2)

The projected pattern is shown in figures 3-4-5

The optimal position of the heater which minimizes the heat beam spot seems when the heater inserted by 2/3 in the reflector (1/3 out). However, this is just a qualitative evaluation.

Finally, two more pictures showing the DB connector on the flange and the in-vacuum cables.

Some more considerations about in-vacuum cabling to come.

Steve: how are you going to protect the magnets ?

  14049   Tue Jul 10 16:59:12 2018 Izabella PastranaHowToComputer Scripts / ProgramsTaking Remote TF Measurements with the Agilent 4395A

I copied the netgpibdata folder onto rossa (under the directory ~/Agilent/), which contains all the necessary scripts and templates you'll need to remotely set up, run, and download the results of measurements taken on the AG4395A network analyzer. The computer will communicate with the network analyzer through the GPIB device (plugged into the back of the Agilent, and whose communication protocol is found in the AG4395A.py file in the directory ~/Agilent/netgpibdata/).

The parameter template file you'll be concerned with is TFAG4395Atemplate.yml (again, under ~/Agilent/netgpibdata/), which you can edit to fit your measurement needs. (The parameters you can change are all helpfully commented, so it's pretty straightforward to use! Note: this template file should remain in the same directory as AGmeasure, which is the executable python script you'll be using). Then, to actually set up, run, and download your measurement, you'll want to navigate to the ~/Agilent/netgpibdata/ directory, where you can run on the command line the following: python AGmeasure TFAG4395Atemplate.yml

The above command will run the measurement defined in your template file and then save a .txt file of your measured data points to the directory specified in your parameters. If you set up the template file such that the data is also plotted and saved after the measurement, a .pdf of the plot will be saved along with your .txt file.

Now if you want to just download the data currently on the instrument display, you can run: python AGmeasure -i -a 10 --getdata

Those are the big points, but you can also run python AGmeasure --help to learn about all the other functions of AGmeasure (alternatively, you can read through the actual python script).

Happy remote measuring! :)





  14048   Tue Jul 10 14:20:09 2018 steveUpdateGeneralprojector light bulb replaced

Bulb replaced at day 110  We have now spare now.


  14047   Mon Jul 9 17:29:28 2018 Udit KhandelwalSummaryTip-TIltTipTilt mirror holder final changes

Final Summary of changes to mirror holder in Tip-Tilt holder.

Determining minimum range for Side Clamp:

1. The initial distance b/w wire-release point and mirror assembly COM = 0.265 mm

2. But this distance is assuming that wire-release point is at mid-point of clamp. So I'm settling on a range of +/- 1mm. The screenshots below confirm range of ~1mm between (1) side screw & protrusion and (2) clamp screw and clamp.

Determining length of tilt-weight assembly rod at the bottom to get \pm 20mRad range

The tilt-weight assembly is made from following Mcmaster parts:
Rod   - 95412A864 18-8 SS  #2-56 Threaded Rod
Nuts  - 91855A103 18-8 SS #2-56 Acorn Cap Nut

Since the weights are fixed, only rod length can be changed to get the angle range.

tan \theta =\frac{d}{h}

d= h \times tan\theta = 34.25\text{mm} \times tan(20 \text{mRad}) = 0.69 \text{mm}
So a range of 1 mm between nut's inner face and mirror-holder face should be enough. Since holder is 12 mm thick, rod length = 12mm + 2 x 1mm + 2 x (nut length) = 12 + 2 + 9.6 = 23.6 mm = 0.93 inch. So a 1" rod from Mcmaster will be fine.

  14046   Mon Jul 9 12:36:32 2018 poojaUpdateGeneralProjector light bulb blown out

Projector light bulb blown out today.

  14045   Sun Jul 8 22:27:25 2018 keerthanaUpdate AUX diagram

(Analisa, Keerthana, Sandrine)

So far we tried four different techniques to scan the AUX laser. They are,

1. Scanning the marconi frequency to sweep the central frequency of the AUX laser.

2. Sweeping the side band frequency of the AUX laser by providing RF frequency from the spectrum analyser.

3. Double demodulation technique.

4. Single demodulation technique.

Now we are taking all the scan data with the help of Single demodulation technique.

  14044   Sun Jul 8 12:20:12 2018 JonSummaryAUXGouy Phase Measurements from AUX-Laser Scans

This note reports analysis of cavity scans made by directly sweeping the AUX laser carrier frequency (no sidebands). The measurement is made by sweeping the RF offset of the AUX-PSL phase-locked loop and demodulating the cavity reflection/transmission signal at the offset frequency.

Y-Arm Scan

Due to the simplicity of its expected response, the Y-arm cavity was scanned first as a test of the AUX hardware and the sensitivity of the technique. Attachment 1 shows the measured cavity transmission with respect to RF drive signal.

The AUX laser launch setup is capable of injecting up to 9.3 mW into the AS port. This high-power measurement is shown by the black trace. The same measurement is repeated for a realistic SQZ injection power, 70 uW, indicated by the red curve. At low power, the technique still clearly resolves the FSR and six HOM resonances. From the identified mode resonance frequencies the following cavity parameters are directly extracted.

YARM Gautam's Finesse Model Actual
FSR 3.966 MHz 3.967 MHz
Gouy phase 54.2 deg 52.0 deg

PRC Scan

An analogous scan was performed for the PRC, with the IFO locked on PSL carrier in PRMI. Attachment 2 shows the measurement of PRC transmission with respect to drive signal.

The scan resolves HOM resonances to at least ~13th order, whose frequencies yield the following cavity parameters.

PRC Gautam's Finesse Model Actual
FSR 22.30 MHz 22.20 MHz
Gouy phase 13.4 deg 15.4 deg

SRC Scan

Ideally (and at the sites) the SRC mode resonances will be measured in SRMI configuration. Because every other cavity is misaligned, this configuration provides an easily-interpretable spectrum whose resonances can all be attributed to the SRC.

Due to time constraints at the 40m, the IFO could not be restored to lockability in SRMI. It has been more than two years since this configuration was last run. For this reason the scan was made instead with the IFO locked in DRMI, as shown in Attachment 3. The quantity measured is the AUX reflection with respect to drive signal.

This result requires far more interpretation because resonances of both the SRC and PRC are superposed. However, the resonances of the PRC are known a priori from the independent PRMI scan. The SRC mode resonances identified below do not conincide with any of the first five PRC mode resonances.

Based on the identified mode resonance frequencies, the SRC parameters are measured as follows.

SRC Gautam's Finesse Model Actual
FSR 27.65 MHz 27.97 MHz
Gouy phase 10.9 deg 8.8 deg

Lessons Learned

From experience with the 40m, the main challenges to repeating this measurement at the sites will be the following.

  • Pointing jitter of the input AUX beam. This causes the PSL-AUX beam overlap to vary at transmission (or reflection), causing variation in the amplitude of the AUX-PSL beat note. As far as we can tell, the frequency of the resonances (the only object of this measurement) is not changing in time, only the relative amplitudes of the diferent mode peaks. I believe the SQZ alignment loops will mitigate this problem at the sites.
  • Stabilization of the network analyzer time base. We found the intrinsic frequency stability of the network analyzer (Agilent 4395A) to be unacceptably large. We solved this problem by phase-locking the Agilent to an external reference, a 10-MHz signal provided by an atomic clock.
  14043   Sat Jul 7 19:50:38 2018 AnnalisaConfigurationThermal CompensationStudy about the Thermal projection setup and its effect on the cavity

I made some simulation to study the change that the heater setup can induce on the Radius of Curvature of the ETM.

Heat pattern

First, I used a non-sequential ray tracing software (Zemax) to calculate the heat pattern. I made a CAD of the elliptical reflector and I put a radiative element inside it (similar to the rod-heater 30mm long, 3.8mm diameter that we ordered), placing it in such a way that the heater tip is as close as possible to the ellipse first focus. (figure 1)

Then, by putting a screen at the second focus of the ellipse (where we suppose to place the mirror HR surface), I could find the projected heat pattern, as shown in figure 2 and 3 (section). Notice that the scale is in INCH, even if the label says mm. As you can see, the heat pattern is pretty broad, but still enough to induce a RoC change. 

Mirror deformation

In order to compute the mirror deformation induced by this kind of pattern, I used this map produced with Zemax as absorption map in COMSOL. I considered ~1W total power absorbed by the mirror (just to have a unitary number).

The mirror temperature and deformation maps induced by this heat pattern are shown in figures 4 and 5. 

RoC change evaluation

Then I had to evaluate the RoC change. In particular, I did it by fitting the Radius of Curvature over a circle of radius:

r = w_{00} * \sqrt{n}

where w_{00} is the waist of tha Gaussian mode on the ETMY (5mm) and n is the mode order. This is a way to approximately know which is the Radius of Curvature as "seen" by each HOM, and is shown in figure 6 (the RoC of the cold mirror is set to be 57.37m). Of course, besides being very tiny, the difference in RoC strongly depends on the heat pattern.

Gouy phase variation

Considering this absorbed power, the cavity Gouy phase variation between hot and cold state is roughly 15kHz (I leave to the SURFs the details of the calculation).

Unanswered points

So the still unaswered questions are:

- which is the minimum variation we are able to resolve with our measurement

- how much heating power do we expect to be projected onto the mirror surface (I'll make another entry on that)

  14042   Fri Jul 6 19:39:37 2018 Udit KhandelwalSummaryGeneralCAD drawings of cantilever suspension required

Request to Koji to acquire the drawings or 3D CAD of the cantilever suspensions of the Tip-Tilt Assembly!

  14041   Fri Jul 6 12:12:09 2018 AnnalisaConfigurationThermal CompensationThermal compensation setup

I tried to put together a rudimentary heater setup. 

As a heating element, I used the soldering iron tip heated up to ~800°C.

To make a reflector, I used the small basket which holds the cork of champains battles (see figure 1), and I covered it with alumnum foil. Of course, it cannot be really considered as a parabolic reflector, but it's something close (see figure 2).

Then, I put a ZnSe 1 inch lens, 3.5 inch FL (borrowed from TCS lab) right after the reflector, in order to collect as much as possible the radiation and focus it onto an image (figure 3). In principle, if the heat is collimated by the reflector, the lens should focus it in a pretty small image. Finally, in order to see the image, I put a screen and a small piece of packaging sponge (because it shouldn't diffuse too much), and I tried to see the projected pattern with a thermal camera (also borrowed from Aidan). However, putting the screen in the lens focal plane didn't really give a sharp image, maybe because the reflector is not exactly parabolic and the heater not in its focus. However, light is still focused on the focal plane, although the image appears still blurred. Perahps I should find a better material (with less dispersion) to project the thermal image onto. (figure 4)

Finally, I measured the transmitted power with a broadband power meter, which resulted to be around 10mW in the focal plane. 

  14040   Thu Jul 5 17:58:04 2018 keerthana, sandrineUpdateelog 

(Analisa, Sandrine, Keerthana)

Today Annalisa helped us to understand the new set up used to make the frequency scans of the AUX laser. While tracking the cables it seemed that there were quite a lot of cables near the mixer. So we have reconnected one of the splitter which was splitting the RF out put signal from the Agilent and have placed it just near the Agilent itself. A picture of the changed setup is provided below. The splitter divides the signal into two components. One goes to the LO port of the mixer and the other goes to the R port of the Agilent. We have tried locking the PLL after the change and it works fine. We are trying to make a diagram of the setup now, which we will upload shortly.


  14039   Thu Jul 5 17:33:36 2018 keerthana, sandrineUpdateelogLights not working
  • N/S ARM FL.
  • N/S ARM INC.

These two lights inside the 40m-lab are not working.

  14038   Thu Jul 5 10:15:30 2018 gautamUpdateSUSPRM watchdog tripped

PRM watchdog was tripped around 7:15am PT today morning. I restored it.

  14037   Wed Jul 4 20:48:32 2018 poojaUpdateCamerasMedm screen for GigE

(Gautam, Pooja)

Aim: To develop medm screen for GigE.

Gautam helped me set up the medm screen through which we can interact with the GigE camera. The steps adopted are as follows:

(i) Copied CUST_CAMERA.adl file from the location /opt/rtcds/userapps/release/cds/common/medm/ to /opt/rtcds/caltech/c1/medm/MISC/.

(ii) Made the following changes by opening CUST_CAMERA.adl in text editor.  

  • Changed the name of file to "/cvs/cds/rtcds/caltech/c1/medm/MISC/CUST_CAMERA.adl"
  • Replaced all occurences of "/ligo/apps/linux-x86_64/camera/bin/" to "/opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/" & "/ligo/cds/$(site)/$(ifo)/camera/" to "/opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/"

(iii) Added this .adl file as drop-out menu 'GigE' to VIDEO/LIGHTS section of sitemap (circled in Attachment 1) i.e opened Resource Palette of VIDEO/LIGHTS, clicked on Label/Name/Args & defined macros as CAMERA=C1:CAM-ETMX,CONFIG=C1-CAM-ETMX in Arguments box of Related Display Data dialog box (circled in Attachment 2) that appears. In Related Display Data dialog box, Display label is given as GigE and Display File as ./MISC/CUST_CAMERA.adl

(iv) All the channel names can be found in Jigyasa's elog https://nodus.ligo.caltech.edu:8081/40m/13023

(v) Since the slider (circled in Attachment 3) for pixel sum was not moving, changed the high limit value to 10000000 in PV Limits dialog box. This value is set such that the slider reaches the other end on setting the exposure time to maximum.

(vii) Set the Snapshot channel C1:CAM-ETMX_SNAP to off (very important!). Otherwise we cannot interact with the camera.

(vii) GigE camera gstreamer client is run in tmux session.

Now we can change the exposure time and record a video by specifying the filename and its location using medm screen. However, while recording the video, gstream video laucher of GigE stops or is stuck.

  14036   Wed Jul 4 19:11:49 2018 JonUpdateAUXMore Testing of AUX-Laser Mode Scanning

More progress on the AUX-laser cavity scans.

Changes to the Setup

  • For scans, the Agilent is now being used as a standalone source of the LO signal provided to the AUX PLL (instead of the Marconi), which sets the RF offset. We discovered that when the sweep is "held" in network analyzer mode, it does not turn off the RF drive signal, but rather continues outputting a constant signal at the hold frequency. This eliminates the need to use the more complicated double-deomdulation previously in use. The procedure is to start and immediately hold the sweep, then lock the PLL, then restart the sweep. The PLL is able to reliably remain locked for frequency steps of up to ~30 kHz. The SURFs are preparing schematics of both the double- and single-demodulation techniques.
  • Both the Marconi and Agilent are now phase-locked to the 10 MHz time reference provided by the rabidium clock. This did noticeably shift the measured resonance frequencies.
  • I raised the PI controller gain setting to 4.5, which seems to better suppress the extra noise being injected.
  • I've procured a set of surgical needles for occluding the beam to produce HOMs. However, I have not needed to use them so far, as the TEM00 purity of the AUX beam appears to already be low. The below scans show only the intrinisic mode content.

New Results

  • YARM scan at 70 uW injection power (Attachment #1). The previously reported YARM scan was measured with 9 mW of injected AUX power, 100x larger than the power available from the SQZ laser at the sites. This scan repeats the measurement with the AUX power attenuated to uW. It still resolves the FSR and at least three HOMs.
  • PRC scan (Attachment #2) at 9 mW injection power. It appears to resolve the FSR and at least three HOMs. Angular injection noise was found to cause large fluctuations in the measured signal power. This dominates the error bars shown below, but affects only the overall signal amplitude (not the peak frequency locations). The SQZ angular alignment loops should mitigate this issue at the sites.

Both data sets are attached.

  14035   Tue Jul 3 11:59:10 2018 JonUpdateAUXAUX Carrier Scan of Y-Arm Cavity

I made the first successful AUX laser scan of a 40m cavity last night.

Attachment #1 shows the measured Y-end transmission signal w.r.t. the Agilent drive signal, which was used to sweep the AUX carrier frequency. This is a distinct approach from before, where the carrier was locked at a fixed offset from the PSL carrier and the frequency of AM sidebands was swept instead. This AUX carrier-only technique appears to be advantageous.

This 6-15 MHz scan resolves three FSR peaks (TEM00 resonances) and at least six other higher-order modes. The raw data are also enclosed (attachment #2). I'll leave it as an excercise for the SURFs to compute the Y-arm cavity Gouy phase.

  14034   Mon Jul 2 09:01:11 2018 SteveUpdateSUSITMY_UL sensor

This bad connection is coming back


We may lost the UL magnet or LED


  14033   Fri Jun 29 18:16:32 2018 JonConfigurationPSLChanges to AUX Optical Layout on PSL Table

In order to use the 0th-order deflection beam from the AOM for cavity mode scans, I've coaligned this beam to the existing mode-matching/launch optics set up for the 1st-order beam.

Instead of being dumped, the 0th-order beam is now steered by two 45-degree mirrors into the existing beam path. The second mirror is on a flip mount so that we can quickly switch between 0th-order/1st-order injections. None of the existing optics were touched, so the 1st-order beam alignment should still be undisturbed.

Currently the 0th-order beam is being injected into the IFO. After attenuating so as to not exceed 100 mW incident on the fiber, approximately 50 mW of power reaches the AS table. That coupling efficiency is similar to what we have with the 1st-order beam. With the Y-arm cavity locked and the AUX PLL locked at RF offset = 47.60 MHz (an Y-arm FSR), I observed a -50 dBm beat note at Y-end transmission.

  14032   Thu Jun 28 16:48:27 2018 gautamUpdateSUSSOS cage towers

For the upcoming vent, we'd like to rotate the SOS towers to correct for the large YAW bias voltages used for DC alignment of the ITMs and ETMs. We could then use a larger series resistance in the DC bias path, and hence, reduce the actuation noise on the TMs. 

Today, I used the calibrated Oplev error signals to estimate what angular correction is needed. I disabled the Oplev loops, and drove a ~0.1 Hz sine wave to the EPICS channel for the DC yaw bias. Then I looked at the peak-to-peak Oplev error signal, which should be in urad, and calibrated the slider counts to urad of yaw alignment, since I know the pk-to-pk counts of the sine wave I was driving. With this calibration, I know how much DC Yaw actuation (in mrad) is being supplied by the DC bias. I also know the directions the ETMs need to be rotated, I want to double check the ITMs because of the multiple steering mirrors in vacuum for the Oplev path. I will post a marked up diagram later. 

Steve is going to come up with a strategy to realize this rotation - we would like to rotate the tower through an axis passing through the CoM of the suspended optic in the vertical direction. I want to test out whatever approach we come up with on the spare cage before touching the actual towers.

Here are the numbers. I've not posted any error analysis, but the way I'm thinking about it, we'd do some in air locking so that we have the cavity axis as a reference and we'd use some fine alignment adjust (with the DC bias voltages at 0) until we are happy with the DC alignment. Then hopefully things change by so little during the pumpdown that we only need small corrections with the bias voltages.

SoS tower DC bias correction

EPICS excitation

[V pk-pk]

Oplev error signal readback

[urad pk-pk]

Calibration [mrad/V] Current DC bias voltage [V] Required correction [mrad]
ETMX 0.06 110 1.83 -5.5305 -10.14
ITMX 0.02 180 9 -1.4500 -13.05
ITMY 0.02 120 6 -0.3546 -2.13
ETMY 0.06 118 1.97 0.5532 1.09

Some remarks:

  1. Why the apparent difference between ITMs and ETMs? I think it's because the bias path resistors are 400 ohms on the ETMs, but 100 ohms on the ITMs
  2. If we want the series resistance for the bias path to be 10 kohm, we'd only have ~800 urad actuation (for +10V DC), so this would be an ambitious level of accuracy. 
  14031   Thu Jun 28 13:12:20 2018 SteveUpdatesafetysurf safety training

Shruti and Sandrine received 40m specific basic safety training this morning.


Pooja and Keirthana received 40m specific basic safety training.


  14030   Thu Jun 28 11:05:48 2018 shrutiUpdatePEMSeismometer temp control equipment

Earlier today I cleared up most of the equipment at the X end near the seismometer to make the area walkable. 

In the process, I removed the connections to the temperature sensor and placed the wires on top of the can.

  14029   Thu Jun 28 10:28:27 2018 ranaUpdateCDS vacuum pneumatic N2 pressure

we disabled logging the N2 Pressure to a text file, since it was filling up disk space. Now it just sends an email to our 40m mailing list, so we'll all get a warning.

The crontab uses the 'bash' version of output redirection '2>&1', which redirects stdout and stderr, but probably we just want stderr, since stdout contains messages without issues and will just fill up again.

  14028   Thu Jun 28 08:09:51 2018 SteveUpdateCDS vacuum pneumatic N2 pressure

The fardest I can go back on channel C1: Vac_N2pres is  320 days

C1:Vac-CC1_Hornet Presuure gauge started logging Feb. 23, 2018

Did you update the " low N2 message"  email addresses?



I moved the N2 check script and the disk usage checking script from the (sudo) crontab of nodus no to the controls user crontab on megatron yes.


  14027   Wed Jun 27 21:18:00 2018 gautamUpdateCDSLab maintenance scripts from NODUS---->MEGATRON

I moved the N2 check script and the disk usage checking script from the (sudo) crontab of nodus no to the controls user crontab on megatron yes.

  14026   Wed Jun 27 19:37:16 2018 KojiConfigurationComputersNew NAT router installed

[Larry, Koji]

We replaced the NAT router between martian and the campus net. We have the administrative web page available for the NAT router, but it is accessible from inside (=martian) as expected.

We changed the IP address registration of nodus for the internet so that the packets to nodus is directed to the NAT router. Then the NAT router forwards the packets to actual nodus only for the allowed ports. Because of this change of the IP we had a few confusions. First of all, martian net, which relies on chiara for DNS resolution. The 40m wifi router seemed to have internal DNS cache and required to reboot to make the IP change effective.

The WAN side cable of nodus was removed.

We needed to run "sudo rndc flush" to force chiara's bind9 to refresh the cache. We also needed to restart httpd ("sudo systemctl restart httpd") on nodus to make the port 8081 work properly. 

So far, ssh (22), web services (30889), and elog (8081, 8080) were tested. We also need to test megatron NDS port forwarding and rsync for nodus, too.

Finally I turned off the firewall rules of shorewall on nodus as it is no longer necessary.

More details are found on the wiki page. https://wiki-40m.ligo.caltech.edu/FirewallSetting

  14025   Wed Jun 27 19:05:20 2018 ranaUpdateComputersrossa: SL7.3 upgrade continues: DTT is back

UNELOGGED: someone has changed Pianosa from Ubuntu/Dumbian into SL7. Might be hackers.

Donatella is now the only Ubuntu machine in the control room. I propose we keep it this way for another month and then go fully SL7 if we find no bugs with Pianosa/Rossa.

  14024   Wed Jun 27 18:12:04 2018 gautamUpdateElectronicsCoil driver dewhitening


I've been thinking about what we need to do to the de-whitening boards for the ITMs and ETMs, in order to have low noise actuators. Noting down what I have so far, so that people can comment / point out things I've overlooked. 

Attachment #1: Block diagram schematic of the de-whitened signal path on D000183 as it currently exists. I've omitted the unity gain buffer stage at the output, though this is important for noise considerations. 

Some considerations, in rough order of priority:

  1. Why do we need de-whitening?
    • Because we want the Johnson noise of the series resistor (4.5 kohm) in the coil driver path to dominate the current noise to the coils at ~200 Hz where we want to measure the squeezing.
  2. What should the shape of this de-whitening filter be?
    • The DAC noise was measured to be ~1 uV/rtHz at 200 Hz. 
    • The Johnson noise spectral density of 4.5 kohm at 300 K is ~9 nV/rtHz
    • So we need ~60dB of attenuation at 200 Hz relative to DC. Currently, they have ~80dB of attenuation at 200 Hz.
    • However, we also need to consider the control signal multiplied by the inverse of this shape in the digital domain (required for overall flat shape). This should not saturate the DAC range.
    • Furthermore, we'd like for the shape to be such that we don't have a large transient when transitioning between high range and low noise modes. We should use the DARM control signal estimate to inform this choice.
  3. What about the electronics noise of the de-whitening filter itself?
    • This shows up at the input of the coil driver stage, and gets transmitted to the coil with unity gain. 
    • So we should aim for < 3nV/rtHz at 200 Hz, such that we are dominated by the Johnson noise of the 4.5 kohm series resistance [the excess will be 5%]. 
    • This can be realized by using the passive network which is the final stage in the de-whitening (there is a unity gain output buffer stage implemented with LT1128, which we also have to account for).   

I will experiment with a few different shapes and investigate noise and de-whitened digital signal levels based on these considerations. At the very least, I guess we should remove the x3 gain on the ETM boards, they have already been bypassed for the ITMs. 

  14023   Tue Jun 26 22:06:33 2018 ranaUpdateComputersrossa: SL7.3 upgrade continues: DTT is back

I used the following commands to get diaggui to run on rossa/SL7:

controls@rossa|lib64> ls -lrt libsasl*
-rwxr-xr-x. 1 root root 121296 Feb 16  2016 libsasl2.so.3.0.0
lrwxrwxrwx. 1 root root     17 Dec 18  2017 libsasl2.so -> libsasl2.so.3.0.0
lrwxrwxrwx. 1 root root     17 Dec 18  2017 libsasl2.so.3 -> libsasl2.so.3.0.0
controls@rossa|lib64> sudo ln -s libsasl2.so.3.0.0 libsasl2.so.2
controls@rossa|lib64> ls -lrt libsasl*
-rwxr-xr-x. 1 root root 121296 Feb 16  2016 libsasl2.so.3.0.0
lrwxrwxrwx. 1 root root     17 Dec 18  2017 libsasl2.so -> libsasl2.so.3.0.0
lrwxrwxrwx. 1 root root     17 Dec 18  2017 libsasl2.so.3 -> libsasl2.so.3.0.0
lrwxrwxrwx. 1 root root     17 Jun 26 22:02 libsasl2.so.2 -> libsasl2.so.3.0.0


Basically, I have set up a symbolic link to point sasl2.so.2 to sasl2.so.3.0.0. I've asked LLO again for some guidance on whether or not to find some backport in a non-standard SL7 repo. IF they reply, we may later replace this link with a regular file.

For the nonce, diaggui runs and is able to show us the spectra. We also got swept sine to work. But the FOTON launched from inside of AWGGUI doesn't inherit the sample frequency of the excitation channel so we can't filter noise injections from awggui yet.

  14022   Tue Jun 26 20:59:36 2018 aaronUpdateOMCprep for vent in a couple weeks

I checked out the elog from the vent in October 2016 when the OMC was removed from the path. In the vent in a couple weeks, we'd like to get the beam going through the OMC again. I wasn't really there for this last vent and don't have a great sense for how things go at the 40m, but this is how I think the procedure for this work should approximately go. The main points are that we'll need to slightly translate and rotate OM5, rotate OM6, replace one mirror that was removed last time, and add some beam dumps. Please let me know what I've got wrong or am missing.

[side note, I want to make some markup on the optics layouts that I see as pdfs elsewhere in the log and wiki, but haven't done it and didn't much want to dig around random drawing software, if there's a canonical way this is done please let me know.]

Steps to return the OMC to the IFO output:

  1. Complete non-Steve portions of the pre-vent checklist (https://wiki-40m.ligo.caltech.edu/vent/checklist)
  2. Steve needs to complete his portions of the checklist (as in https://nodus.ligo.caltech.edu:8081/40m/12557)
  3. Need to lock some things before making changes I think—but I’m not really sure about these, just going from what I can glean from the elogs around the last vent
    1. Lock the IMC at low power
    2. Align the arms to green
    3. Lock the arms
    4. Center op lev spots on QPDs
    5. Is there a separate checklist for these things? Seems this locking process happens every time there is a realignment or we start any work, which makes sense, so I expect it is standardized.
  4. Turn/add optics in the reverse order that Gautam did
    1. Check table leveling first?
    2. Rotate OM5 to send the beam to the partially transmissive mirror that goes to the OMC; currently OM5 is sent directly to OM6. OM5 also likely needs to be translated forward slightly; Gautam tried to maintain 45 deg AOI on OM5/6.
    3. A razor beam dump was also removed, which should be replaced (see attachment 1 on https://nodus.ligo.caltech.edu:8081/40m/12568)
    4. May need to rotate OM6 to extract AS beam again, since it was rotated last time
    5. Replace the mirror just prior to the window on the AP table, mentioned here in attachment 3: https://nodus.ligo.caltech.edu:8081/40m/12566
      1. There is currently a rectangular weight on the table where the mirror was, for leveling
  5. Since Gautam had initially made this change to avoid some backscattered beams and get a little extra power, we may need to add some beam dumps to kill ghosts
    1. This is also mentioned in 12566 linked above, the dumps are for back-reflection off the windows of the OMC
  6. Center beam in new path
  7. Check OMC table leveling
  8. AS beam should be round on the camera, with no evidence of clipping on any optics in the path (especially check downstream of any changes)
  14021   Tue Jun 26 17:54:59 2018 poojaUpdateCamerasDeveloping neural networks

Aim:  To find a model that trains the simulated data of Gaussian beam spot moving in a vertical direction by the application of a sinusoidal signal. The data also includes random uniform noise ranging from 0 to 10.

All the attachments are in the zip folder.

I simulated images 128*128 at 10 frames/sec by applying a sine wave of frequency 0.2Hz that moves the beam spot, added random uniform noise ranging from 0 to 10 & resized the image frame using opencv to 64*64. 1000 cycles of this data is taken as train & 300 cycles as test data for the following cases. Optimizer = Nadam (learning rate = 0.001), loss function used = mean squared error, batch size = 32,

Case 1:

Model topology:

                         256 (dropout = 0.1)  ->           256 (dropout = 0.1)   ->       1

Activation :             selu                                         selu

Number of epochs = 240.

Variation in loss value of train & test datasets is given in Attachment 1 of the attached zip folder & the applied signal as well as the output of neural network given in Attachments 2 & 3 (zoomed version of 2).

The model fits well but there is no training since test loss is lower than train loss value. I found in several sites that dropout of some of the nodes during training but retaining them during test could be the probable reason for this (https://stackoverflow.com/questions/48393438/validation-loss-when-using-dropout , http://forums.fast.ai/t/validation-loss-lower-than-training-loss/4581 ). So I removed dropout while training next time.

Case 2:

Model topology:

                         256 (dropout = 0.1)  ->           256 (dropout = 0.1)   ->       1

Activation :             selu                                         selu                          linear

Number of epochs = 200.

Variation in loss value of train & test datasets is given in Attachment 4 of the attached zip folder & the applied signal as well as the output of neural network given in Attachments 5 & 6 (zoomed version of 2).

But still no improvement.

Case 3:

I changed the optimizer to Adam and tried with the same model topology & hyperparameters as case 2 with no success (Attachments 7,8 & 9).

Finally I think this is because I'm training & testing on the same data. So I'm now training with the simulated video but moving it by a maximum of 2 pixels only and testing with a video of ETMY that we had captured earlier.

  14020   Tue Jun 26 17:20:33 2018 JonConfigurationCamerasLLO Python Camera Software is Working

Thanks to a discussion yesterday with Joe Betzweiser, I was able to identify and fix the remaining problem with the LLO GigE camera software. It is working now, currently only on rossa, but can be set up on all the machines. I've started a wiki page with documentation and usage instructions here:


This page is also linked from the main 40m wiki page under "Electronics."

This software has the ability to both stream live camera feeds and to record feeds as .avi files. It is described more on the wiki page.

ELOG V3.1.3-