40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 292 of 341 Not logged in
ID Date Author Type Category Subject
14012   Sun Jun 24 20:02:07 2018 gautamUpdateSUSSome notes about coil driver noise

Summary:

For a series resistance of 4.5 kohm, we are suffering from the noise-gain amplified voltage noise of the Op27 (2*3.2nV/rtHz), and the Johnson noise of the two 1 kohm input and feedback resistances. As a result, the current noise is ~2.7 pA/rtHz, instead of the 1.9 pA/rtHz we expect from just the Johnson noise of the series resistance. For the present EX coil driver configuration of 2.25 kohm, the Op27 voltage noise is actually the dominant noise source. Since we are modeling small amounts (<1dB) of measurable squeezing, such factors are important I think.

Details:

[Attachment #1] --- Sketch of the fast signal path in the coil driver board, with resistors labelled as in the following LISO model plots. Note that as long as the resistance of the coil itself << the series resistance of the coil driver fast and slow paths, we can just add their individual current noise contributions, hence why I have chosen to model only this section of the overall network.

[Attachment #2] --- Noise breakdown per LISO model with top 5 noises for choice of Rseries = 2.25 kohm. The Johnson noise contributions of Rin and Rf exactly overlap, making the color of the resulting line a bit confusing, due to the unfortunate order of the matplotlib default color cycler. I don't want to make a custom plot, so I am leaving it like this.

[Attachment #3] --- Noise breakdown per LISO model with top 5 noises for choice of Rseries = 4.5 kohm. Same comments about color of trace representing Johnson noise of Rin and Rf.

Possible mitigation strategies:

1. Use an OpAmp with lower voltage noise. I will look up some candidates. LT1028/LT1128? LISO library warns of a 400 kHz noise peak though...
2. Use lower Rin and Rf. The values of these are set by the current driving capability of the immediately preceeding stage, which is the output OpAmp of the De-Whitening board, which I believe is a TLE2027. These can source/sink 50 mA according to the datasheet . So for +/-10V, we could go to 400 ohm Ri and Rf, source/sink a maximum of 25mA, and reduce the Johnson noise contribution by 40%.

Other comments/remarks:

I've chosen to ignore the noise contribution of the high current buffer IC that is inside the feedback loop. Actually, it may be interesting to compare the noise measurements (on the electronics bench) of the circuit as drawn in Attachment #1, without and with the high current buffer, to see if there is any difference.

This study also informs about what level of electronics noise is tolerable from the De-Whitening stage (aim for ~factor of 5 below the Rseries Johnson noise).

Finally, in doing this model, I understand that the observation the voltage noise of the coil driver apparently decreased after increasing the series resistance, as reported in my previous elog. This is due to the network formed by the fast and slow paths (during the measurement, the series resistance in the slow path makes a voltage divider to ground), and is consistent with LISO modeling. If we really want to measure the noise of the fast path alone, we will have to isolate it by removing the series resistance of the slow bias path.

Comment about LISO breakdown plots: for the OpAmp noises, the index "0" corresponds to the Voltage noise, "1" and "2" correspond to the current noise from the "+" and "-" inputs of the OpAmp respectively. In future plots, I'll re-parse these...

 Quote: I will upload more details + photos + data + schematic + LISO model breakdown tomorrow to a DCC page.

Attachment 1: CoilDriverSchematic.pdf
Attachment 2: D010001_2k_fastOnly_2.25k.pdf
Attachment 3: D010001_4k_fastOnly_4.5k.pdf
14013   Sun Jun 24 23:13:46 2018 johannesUpdateGeneralAUX beam alignment issues

At some point we want to change the AUX injection on the AS table to interfere less with the normal interferometer path, and avoid 10/90 beamsplitters which produce a fair amount of ghosting. The plan is to replace the 99/1 BS whose reflection goes to AS110 and AS55, while the transmission goes to the AS camera, with a 90/10 BS as shown in the attachment. This results in ~10% less light on the PDs compared to the pre-AUX era. Between this BS and the AS camera there will be a second 90/10 BS that sends the AUX light into the IFO, so we end up with marginally less AUX power into the IFO and the same PSL power on the AS cam. We're short optics, so this has to wait until two new beamsplitters arrive from CVI.

Attachment 1: AS_AUX_SETUP.pdf
14016   Mon Jun 25 22:27:57 2018 shrutiUpdatePEMSeismometer temp control - heater circuit

After removing all the clamping screws from the heater circuit board, I soldered the wire connecting IRF630 to the output of OP27, which had come off earlier. This can only be a temporary fix as the wire was not long enough to be able to make a proper solder joint. I also tried fixing two other connections which were also almost breaking.

After re-assembling everything I found out that one of the LEDs was not working. The most likely cause seems to be an issue with LM791, LM 781 or the LED itself. Due to the positioning of the wires, I was unable to test them today but will try again possibly tomorrow.

Equipment used for this is still lying at the X end.

 Quote: We (Rana and I) are re-assembling the temperature controls on the seismometer to attempt PID control and then improve it using reinforcement learning. We tried to re-assemble the connections for the heater and in-loop temperature sensor on the can that covers the seismometer. We fixed (soldered) two of the connections from the heater circuit to the heater, but did not manage to get the PID working as one of the wires attached to the MOSFET had come off. Re-soldering the wire would be attempted tomorrow. Equipment for undertaking all this is still left at the X-end of the interferometer and will be cleared soon.
14017   Tue Jun 26 10:06:39 2018 keerthanaUpdateAUXFirst Coherent AUX Scan of PRC Using AM Sidebands

(Jon, Keerthana, Sandrine)

I am attaching the plots of the Reflected and transmitted AUX beam. In the transmission graph, we are getting peak corresponding to the resonance frequencies, as at that frequency maximum power goes to the cavity. But in the Reflection graph, we are obtaining dips corresponding to the resonance frequency because maximum power goes to the cavity and the reflected beam intensity becomes very less at those points.

Attachment 1: TRANS.pdf
Attachment 2: REFL.pdf
14018   Tue Jun 26 10:50:14 2018 poojaUpdateCamerasBeam spot tracking using OpenCV

Aim: To track the motion of beam spot in simulated video.

I simulated a video that moves the beam spot at the centre of the image initially by applying a sinusoidal signal of frequency 0.2Hz and amplitude 1 i.e. it moves maximum by 1 pixel. It can be found in this shared google drive link (https://drive.google.com/file/d/1GYxPbsi3o9W0VXybPfPSigZtWnVn7656/view?usp=sharing). I found a program that uses Kernelized Correlation Filter (KCF) to track object motion from the video. In the program we can initially define the bounding box (rectangle) that encloses the object we want to track in the video or select the bounding box by dragging in GUI platform. Then I saved the bounding box parameters in the program (x & y coordinates of the left corner point, width & height) and plotted the variation in the y coordinates. I have yet to figure out how this tracker works since the program reads 64*64 image frames in video as 480*640 frames with 3 colour channels and frame rate also randomly changes. The plot of the output of this tracking program & the applied signal has been attached below. The output is not exactly sinusoidal because it may not be able to track very slight movement especially at the peaks where the slope = 0.

Attachment 1: cv2_track_fig.pdf
14019   Tue Jun 26 16:28:00 2018 gautamUpdateSUSCoil driver protoboard characterization

I wanted to investigate my coil driver noise measurement technique under more controlled circumstances, so I spent yesterday setting up various configurations on a breadboard in the control room. The overall topology was as sketched in Attachment #1 of the previous elog, except for #4 below. Summary of configurations tried (series resistance was 4.5k ohm in all cases):

1. Op 27 with 1kohm input and feedback resistors.
2. LT1128 with 1kohm input and feedback resistors.
3. LT1128 with 400 ohm input and feedback resistors.
4. LT1128 with 400 ohm input and feedback resistors, and also the current buffer IC LM6321 implemented.

Attachments:

Attachment #1: Picture of the breadboard setup.

Attachment #2: Noise measurements (input shorted to ground) with 1 Hz linewidth from DC to 4 kHz.

Attachment #3: Noise measurements for full SR785 span.

Attachment #4: Apparent coupling due to PSRR.

Attachment #5: Comparison of low frequency noise with and without the LM6321 part of the fast DAC path implemented.

All SR785 measurements were made with input range fixed at -42dBVpk, input AC coupled and "Floating", with a Hanning window.

Conclusions:

• I get much better agreement between LISO and measurement at a few hundred Hz and below with this proto setup. So it would seem like the excess noise I measure at ~200 Hz in the Eurocrate card version of the coil driver could be real and not simply a measurement artefact.
• I am puzzled about the 10 Hz comb in all these measurements:
• I have seen this a few times before - e.g. elog13655.
• It is not due to the infamous GPIB issue - the lines persist even though I disconnect both power adaptor and GPIB prologix box from the SR785.
• It does not seem to be correlated with the position of the analyzer w.r.t. the DC power supply (Tektronix PS280) used to power the circuit (I moved the SR785 around 1m away from the supply).
• It persists with either of the two LN preamp boxes available.
• It persists with either "Float" or "Ground" input setting on the SR785.
• All this pointed to some other form of coupling - perhaps conductive EMI.
• The only clue I have is the apparent difference between the level of the coupling for Op27 and LT1128 - it is significantly lower for the latter compared to the former.
• I ruled out position on the breadboard: simply interchanging the Op27 and LT1128 positions on the breadboard, I saw higher 10 Hz harmonics for the Op27 compared to the LT1128. In fact, the coupling was higher for the DIP Op27 compared to an SOIC one I attached to the breadboard via an SOIC to DIP adapter (both were Op27-Gs, with spec'ed PSRR of 120 dB typ).
• To test the hypothesis, I compared the noise for the Op27 config, on the one hand with regulated (via D1000217) DC supply, and on the other, directly powered by the Tektronix supply. The latter configuration shows much higher coupling.
• I did have 0.1uF decoupling capacitors (I guess I should've used ceramic and not tantala) near the OpAmp power pins, and in fact, removing them had no effect on the level of this coupling
• As a quick check, I measured the spectrum of the DC power used to run the breadboard - it is supplied via D1000217. I used an RC network to block out the DC, but the measurement doesn't suggest a level of noise in the supply that could explain these peaks.
• The regulators are LM2941 and LM2991. They specify something like 0.03% of the output voltage as AC RMS, though I am not sure over what range of frequencies this is integrated over.
• But perhaps the effect is more subtle, some kind of downconversion of higher frequency noise, but isn't the decoupling cap supposed to protect against this?
• The 19.5 kHz harmonics seem to originate from the CRT display of the SR785 (SVGA).
• The manual doesn't specify the refresh rate, but from a bit of googling, it seems like this is a plausible number.
• The coupling seems to be radiative. The box housing the Busby preamp provides ~60dB attentuation of this signal, and the amplitude of the peaks is directly correlated to where I position the Busby box relative to the CRT screen.
• This problem can be avoided by placing the DUT and preamp sufficiently far from the SR785.

Punchlines:

1. The actual coildriver used, D010001, doesn't have a regulated power supply, it just draws the +/- 15V directly from Sorensens. I don't think this is good for low noise.
2. The LM6321 part of the circuit doesn't add any excess noise to the circuit, consistent with it being inside the unity gain feedback loop. In any case, with 4.5 kohm series resistance with the coil driver, we would be driving <2.5 mA of current, so perhaps we don't even need this?
Attachment 1: IMG_7060.JPG
Attachment 2: ETMXstitchced.pdf
Attachment 3: ETMXfullSpan.pdf
Attachment 4: PSRR.pdf
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.

Attachment 1: NN_noise_diag.zip
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)
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.

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

Summary:

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.

Attachment 1: DeWhiteningSketch.pdf
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.

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 to the controls user crontab on megatron .

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?

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

Attachment 1: 320d_N2.png
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.

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.

14031   Thu Jun 28 13:12:20 2018 SteveUpdatesafetysurf safety training

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

 Quote: Pooja and Keirthana received 40m specific basic safety training.

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
Optic

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.
14034   Mon Jul 2 09:01:11 2018 SteveUpdateSUSITMY_UL sensor

This bad connection is coming back

 Quote: We may lost the UL magnet or LED

Attachment 1: ITMY_ULcripingback.png
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.

Attachment 1: yarm_carrier_trans.pdf
Attachment 2: AG4395A_02-07-2018_185504.txt
# AG4395A Measurement - Timestamp: Jul 02 2018 - 18:55:04
#---------- Measurement Parameters ------------
# Start Frequency (Hz): 6000000.0, 6000000.0
# Stop Frequency (Hz): 15000000.0, 15000000.0
# Frequency Points: 801, 801
# Measurement Format: LOGM, PHAS
# Measuremed Input: AR, AR
#---------- Analyzer Settings ----------
# Number of Averages: 16
# Auto Bandwidth: Off, Off

... 807 more lines ...
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.

Attachment 1: yarm_trans_70uW.pdf
Attachment 2: prc_trans_9mW.pdf
Attachment 3: yarm_carrier_trans_70uW.tar.gz
Attachment 4: prc_carrier_trans_9mW.tar.gz
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.

Attachment 1: sitemap.png
Attachment 2: GigE_macros.png
Attachment 3: CUST_CAMERA.png
14038   Thu Jul 5 10:15:30 2018 gautamUpdateSUSPRM watchdog tripped

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

Attachment 1: PRM_watchdogTrip.png
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.

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.

Attachment 1: setup1.jpg
Attachment 2: setup2.jpg
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.

Attachment 1: PLL-single_demodulation.pdf
Attachment 2: PLL-double_demodulation.pdf
14046   Mon Jul 9 12:36:32 2018 poojaUpdateGeneralProjector light bulb blown out

Projector light bulb blown out today.

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

Bulb replaced at day 110  We have now spare now.

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

/cvs/cds/caltech/cds/rward-advLigo/src/epics/simLink/omc.mdl

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?
•
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)
16. TESTS TO DO
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
17. ADDITIONAL TO DO
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
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.

Attachment 1: graphs.pdf
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.

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.

UPDATE:

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

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.

Attachment 1: finesse_cavity.png
Attachment 2: Analytical1.pdf
Attachment 3: Finesse_Analytical.pdf
Attachment 4: Difference.pdf
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.

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

We are getting ready to vent.

Attachment 1: before_Vent.png
Attachment 2: before_Vent_cond.png
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.

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.

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

Attachment 1: preVentStatus.png
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.

Attachment 1: vent80wtiptilts.png
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.

Attachment 1: @atm.png
Attachment 2: vent80_7h.png
Attachment 3: ventregN2&Air_c.jpg
14067   Fri Jul 13 17:13:45 2018 KojiUpdateGeneralVent objectives and prep

## Notice: I removed these 75Ohm video cables.

Attachment 1: P_20180713_020603.jpg
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.

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.

Input:

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.

Attachment 1: nn_simulation_2_nodes4_lr0p00001_beta1_0p8_beta2_0p85.pdf
Attachment 2: nn_simulation_2_nodes8_lr0p00001_beta1_0p8_beta2_0p85.pdf
14072   Sat Jul 14 16:04:34 2018 aaronUpdateOMCChecking OMC Electronics

# Next check is the DCPD/OMMT Satellite Box

I traced a cable from the OMC electrical feedthrough flanges to find the DCPD/OMMT Satellite Box (D060105). I couldn't find the DCC number or mention of the box anywhere except this old elog.

Gautam and I supplied the box with power and tested what we think is the bias for the PD, but don't read any bias... we tracked down the problem to a suspicious cable, labelled.

We confirmed that the board supplies the +5V bias that Rich told us we should supply to the PDs.

We tested the TFs for the board from the PD input pins to output pins with a 100kHz low pass (attached, sorry no phase plots). The TFs look flat as expected. The unfiltered outputs of the board appear bandpassed; we couldn't identify why this was from the circuit diagram but didn't worry too much about it, as we can plan to use the low passed outputs.

Attachment 1: Screenshot_2018-07-14_17.53.40.png
Attachment 2: Screenshot_2018-07-14_17.57.17.png
14074   Mon Jul 16 18:12:00 2018 KojiUpdateVACAdding a manual gate valve between TP1 and V1/VM2

[Steve Koji]

We are in the process of adding a manual gate valve between TP1 (Osaka Maglev) and the other gate valves (I suppose V1 and VM2).
The work is still on going and we will continue to work on this tomorrow. Because this section is isolated from the main volume, this work does not hold off the possible rough pumping tomorrow morning.

The motivation of this work is as follows:
- Since TP2 failed, the main vacuum volume has been pumped down by TP1 and TP3. However TP3 is not capable to handle the large pressure difference at the early stage of the turbo pumping. This cause TP3 to have excessive heating or even thermal shutdown.
- The remedy is to put a gate valve between TPs and the main vacuum to limit the amount of gas flowing into the TPs. This indeed slows down the pumping speed of turbo, but this is not the dominant part of the pumping time.

Actual work:
- Comfirmed TP1 is isolated.
- Unscrewed the flange of TP1.
- Remove TP1. This required to lift up TP1 with some shim as the nuts interferes with the TP1 body. (Attachment1, 2, 3)
- Now remove 10inch flange adapter. (Attachment4)
-
Attach 10"-8" adapter and 8" rotational sleeve. (Attachment5)

Attachment 1: P_20180716_155413.jpg
Attachment 2: P_20180716_155645.jpg
Attachment 3: P_20180716_155738.jpg
Attachment 4: P_20180716_162307.jpg
Attachment 5: P_20180716_172000.jpg
14075   Tue Jul 17 01:07:40 2018 gautamUpdateSUSETMY EQ stops

For the heater setup on EY table, I EQ-stopped ETMY. Only the face EQ stops (3 on HR face, 2 on AR face) were engaged. The EY Oplev HeNe was also shutdown during this procedure.

14076   Tue Jul 17 12:46:28 2018 ranaUpdateGeneralsome notes from yesterday

For the EY, instead of balancing the table, I just moved the weight approximately so that the ETMY OSEMS were at half light, but didn't check the level since ETMY is the only optic.

Some notes on OMC/AS work (Aaron/Gautam can amend/correct):

- Beam is now well centered in OMC MMT. Hits input coupling mirror and cleanly exits the vacuum to the AS table.

- Didn't see much on OMC trans, but PDs are good based on flashlight test.

- just before closing, re-aligned beam in yaw so that it gets close to the east screw on the input coupler. Aaron and I think we maybe saw a flash there with the OMC length PZT being driven at full range by a triangle wave.

- with OMC Undulators (aka tip/tilt PZT mirrors) energized, the beam was low on PZT1 mirror. We pitched ITMY by ~150 micro-rad and that centered the beam on PZT1 mirror. ITMY-OL is probably not better than 100 urad as a DC reference?

- We checked the range of Undulator 1 and we were getting ~5 mrad of yaw of the beam for the full range, and perhaps half of that in pitch. Rob Ward emailed us from Oz to say that the range is robably 2.7 mrad, so that checks out.

Even if the ITMY has to be in the wrong position to get the beam to the OMC, we can still do the heater tests in one position and then do the OMC checkout stuff in the other position.

Gautam suspects that there is a possible hysterical behaviour in the Undulators which is related to the MC3 glitching and the slow machine hangups and also possibly the illuminati.

[aaron]

-We noticed a ghost beam that from MC REFL (MMT2) that should be dumped during the next vent--it travels parallel to the OMC's long axis and nearly hits one of the steering mirrors for OMC refl.

-We measured the level of the table and found it ~3 divisions off from level, with the south end tilted up

-Gautam rotated and slightly translated OM5 to realign the optic, as expected. No additional optics were added.

-Gautam and I tested the TT piezo driver. We found that 3.6V on the driver's input gave 75V (of 150V) at the output, at least for yaw on piezo 1. However, as Gautam mentioned, during testing it seemed that the other outputs may have different (nonzero) offset voltages, or some hysterisis.

14081   Wed Jul 18 03:14:48 2018 AnnalisaUpdateGeneralVent 80 recovery

[Gautam, Johannes, Koji, Annalisa]

Tonight we increased the power of the PSL laser and we achieved the lock of both arms with high power.

The AUX beam alignment to the Y arm was recovered and the PLL restored (using the Marconi as LO).

We made a quick measurement of the phase noise and the results will be posted tomorrow.

The beam on the PSL has been blocked, as well as the AUX beam on the AS table. The Marconi has been switched off.

gautam:

1. Before turning up PSL power, I placed a block in front of MC refl to avoid any PD burning. Replaced HR Y1 2" optic with the usual 10% reflective BS to direct MC REFL to the locking PD.
2. Waveplate was rotated back to 180 deg (original position before the vent). After optimizing PMC transmission, I measured 1.05 W going into the IMC (pre-vent value was 1.07 W, prolly within power meter absolute accuracy).
3. IMC autolocker restored to usual high power version on megatron.
4. There seems to be some kind of vacuum interlock in effect that prevents me from opening the PSL shutter via EPICS - I had to toggle the position on the shutter controller under the table. After tonight's work, I returned the controller to the NC state, to avoid any further interference with this interlock code that may prevent pumping in the AM.
5. PLL gain was re-adjusted to achieve maximum stability (judged by eye) of the beat-note in lock triggered on the Marconi LO signal. Alignment onto the NF beatPD was also tweaked to squeeze out as much beat as possible.
6. The main objective tonight was to send AUX beam in, recover transmission beat, scan the AUX frequency, and resolve some peaks (MAX HOLD scanning technique, magnitude only for now, no phase info). Thanks to JE's expert fiber alignment and beatnote maximization, we achieved this . Annalisa will post a plot tmr.
7. For unknown reasons, the Y arm ASS does not maximize TRY. So we are in the unfortunate situation of neither arm having a working ASS servo. To be worked on later.
14084   Wed Jul 18 23:43:50 2018 KojiUpdateGeneralVent 80 recovery

Is the reflector too close to the beam and causing clipping?

 Quote: For unknown reasons, the Y arm ASS does not maximize TRY. So we are in the unfortunate situation of neither arm having a working ASS servo. To be worked on later.
Attachment 1: IMG_5868.JPG
Attachment 2: IMG_5382.JPG
14089   Thu Jul 19 18:09:17 2018 poojaUpdateCamerasUpdate in developing neural networks

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

Case 1:

Input : Simulated video of beam spot motion in pitch by applying 4 sine  waves of frquencies 0.2, 0.4, 0.1, 0.3 Hz  and amplitude ratios to frame size to be 0.1, 0.04, 0.05, 0.08

The data has been split into train, validation and test datasets and I tried training on neural network with the same model topology & parameters as in my previous elog (https://nodus.ligo.caltech.edu:8081/40m/14070)

The output of NN and residual error have been shown in Attachment 1. This NN model gives a large error for this. So I think we have to increase the number of nodes and learning rate so that we get a lower error value with a single sine wave simulated video ( but not overfitting) and then try training on linear combination of sine waves.

Case 2 :

Normalized the target sine signal of NN so that it ranges from -1 to 1 and then trained on the same neural network as in my previous elog with simulated video created using single sine wave. This gave comparatively lower error (shown in Attachment 2). But if we train using this network, we can get only the frequency of test mass motion but we can't resolve the amount by which test mass moves. So I'm unclear about whether we can use this.

Attachment 1: nn_simulation_mlt_sine_nodes4_lr0p00001_beta1_0p8_beta2_0p85_marked.pdf
Attachment 2: nn_simulation_2_nodes4_target-1to1_marked.pdf
ELOG V3.1.3-