40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 43 of 337 Not logged in
ID Date Author Type Category Subject
14846   Thu Aug 15 18:54:54 2019 gautamUpdateALSALS sensing noise due to IMC

Summary:

I came aross an interesting suggestion by Yutaro that KAGRA's low-frequency ALS noise could be limited by the fact that the IMC comes between the point where the frequencies of the PSL and AUX lasers are sensed (i.e. the ALS beat note), and the point where we want them to be equal (i.e. the input of the arm cavity). I wanted to see if the same effect could be at play in the 40m ALS system. A first estimate suggests to me that the numbers are definitely in the ballpark. If this is true, we may benefit from lower noise ALS by picking off the PSL beam for the ALS beat note after the IMC.

Details:

Even though the KAGRA phase lock scheme is different from the 40m scheme, the algebra holds. I needed an estimate of how much the arm cavity moves, I used data from a POX lock to estimate this. The estimate is probably not very accurate (since the arm cavity length is more stable than the IMC length, and the measured ALS noise, e.g. this elog, is actually better than what this calculation would have me believe), but should be the right order of magnitude. From this crude estimate, it does look like for f<10 Hz, this effect could be significant. I assumed an IMC pole of 3.8 kHz for this calculation.

I've indicated a "target" ALS performance where the ALS noise would be less than the CARM linewidth, which would hopefully make the locking much easier. Seems like realizing this target will be touch-and-go. But if we can implement length feedforward control for the arm cavities using seismometers, the low frequency motion of the optics should go down. It would be interesting to see if the ALS noise gets better at low frequencies with length feedforward engaged.

1. Took data from Kiwamu's paper for the seismic noise
2. Overlaid measured ALS noise
Attachment 1: ALSsensingNoise.pdf
14845   Tue Aug 13 14:36:17 2019 gautamUpdateCDSP1--->P2

As it turns out, only one extra shroud needed to be installed - I did this and migrated the cables for the 4 whitening boards from the P1 to P2 connectors. So until the new Acromag box is installed, we have no control over the whitening gains (slow channels), but do still have control over the whitening filter enable/disable (controlled by fast BIO). I am thinking about the easiest way to test the latter - I think the ambient PD dark noise level is too low to be seen above ADC noise even with the whitening enabled, and setting up drive signals to individual channels is too painful - maybe with +45dB of whitening gain, the (z,p) whitening filter shape can be seen with just PD/demod chain electroncis noise.

 Quote: This morning, I wanted to move the existing cables going to the P1 connectors of the iLIGO whitening boards to the P2 connector, to test the modifications made to allow whitening stage switching. Unfortunately, I found that the shrouds werent installed. Where can I find these?
14844   Tue Aug 13 08:07:09 2019 gautamUpdateCDSP1--->P2

This morning, I wanted to move the existing cables going to the P1 connectors of the iLIGO whitening boards to the P2 connector, to test the modifications made to allow whitening stage switching. Unfortunately, I found that the shrouds werent installed. Where can I find these?

14843   Mon Aug 12 21:25:19 2019 KojiUpdateCDSMore bench test of c1iscaux

1.

> Looking through the manual, I found a recommendation (pg10) that the "IN-" terminal of the Acromag ADC units be tied to the "RTN" pins on the same units. I don't know if this preserves the differential receiving capability of the Acromag ADCs

I suppose, we loose the differential capability of an input if the -IN is connected to whatever defined potential. We should check if the channels are still working as a true differential or not.

2. If the multi bit operation is too complicated to solve, we can use EPICS Calc channels to breakout a value to bits and send the individual bits as same as the other individual binary channels.

14842   Mon Aug 12 19:58:23 2019 gautamUpdateIOOMC1 suspension oddness

Repair plan:

1. Get "spare" satellite box working --- Chub
• According to elog14441, this box has flaky connectors which probably need to be remade
2. Re-make the 64-pin IDC crimped connection on the cable from the coil driver board to sat. box, at the Satellite box end --- Chub and gautam

Any other ideas? The problem persists and it's annoying that the IMC cannot be locked.

14841   Mon Aug 12 17:36:04 2019 gautamUpdateCDSMore bench test of c1iscaux

[chub, gautam]

With Chub's help, most of the problems have been resolved. Summary: I judge that we are good to go ahead with an install tomorrow.

1. The problem with the BIO channels was a mis-wiring internal to the chassis - Chub fixed this and now all 32 AA enable/disable switches seem to work as advertised. Of course we will need to do the in-situ test to make sure.
2. The problem with the ADC channels were multiple:
• On the software end, I had gotten some addressing wrong - this was fixed.
• On the hardware side - even though the inputs of the Acromag are "differential", I found that the readback was extremely noisy (~0.5 V RMS for a 3 V DC signal from the handheld calibrator unit ðŸ˜² ). Looking through the manual, I found a recommendation (pg10) that the "IN-" terminal of the Acromag ADC units be tied to the "RTN" pins on the same units. I don't know if this preserves the differential receiving capability of the Acromag ADCs - anyways, after Chub implemented this change, all the Analog Input channels behave as expected (I tested with a DC voltage and also a 200 mHz sine wave from a function generator).
• Note that most of the Eurocard electronics we use are single-ended sending anyways.
• What does this mean for the other Acromag ADCs (e.g. OSEM Shadow Sensor monitors) we have installed????? I saw no documentation in the elog/wiki.
3. Binary input channel:
• This is used by the "CM LIMIT" channel.
• I found that I had to initialize a separate alias for the BIO3 unit, which acquires this signal, to use the modbus function "4" corresponding to "Read Input Registers" - c.f. the binary output modbus function 6, which is to "Write Single Register".
• The fix for the mbbo channels is also likely to be along this lines - but I don't have the energy for that endavor right now.
4. Testing of the physical mbboDirect bit channels using the Acromag Window utility
• I can't get the mbboDirect EPICS record to work as expected, so I decided to use the native Acromag utility to test the functionality
• First I released control of the acromags from the supermicro (stopped modbus)
• There were several wiring errors - Chub had left for the day so I just fixed it myself.
• The LED tester kit was used to check that the correct bits were flipped - they were.
5. At the time of writing, the non-functional channels (in EPICS) are all related to the CM board:
• C1:LSC-CM_LIMIT (binary input) tested later in the day, works okay...
• C1:LSC-CM_REFL1_BITS (mbboDirect)
• C1:LSC-CM_REFL2_BITS (mbboDirect)
• C1:LSC-CM_AO_BITS (mbboDirect)
• C1:LSC-CM_BOOST2_BITS (mbboDirect)

Since we don't immediately need the CM board, I say we push ahead with the install - at least that will restore the ability to lock PRMI / DRMI. Then we can debug these issues in situ - I'm certain the issue is related to the EPICS/Modbus setup and not the hardware because I verified the physical channel map using the Acromag windows utility.

1. Install power supply cables at 1Y3
2. Install supermicro and Acromag crates in 1Y3
3. Migrate existing P1 connectors to P2 where applicable (Whitening boards)
4. Connect Dsub-->P1 / P2 adaptors
5. Run in-situ tests
 Quote: I bench tested the functionality of all the c1iscaux Acromag crate channels. Summary: we are not ready for a Monday install, much debugging remains.
Attachment 1: iscauxCheclist.pdf
14840   Sun Aug 11 11:47:42 2019 gautamUpdateCDSBench test of c1iscaux

I bench tested the functionality of all the c1iscaux Acromag crate channels. Summary: we are not ready for a Monday install, much debugging remains.

1. DAC channels were tested using 4 ch oscilloscope and stepping the whitening gain sliders through their 15 gain settings
• Response was satisfactory - the output changes between 0 - 5 V DC in 15 steps.
• This analog voltage is converted to binary representation by an on-board ADC on the whitening boards. So we may have to tune the offset voltage and range to avoid accidental bit flipping due to the analog voltage of a particualr step falling close to the bit-flipping edge of the on-board ADC. This will require an in-situ test.
• Test passed
2. BIO output channels were tested using a DMM, and monitoring the resistance between the BIO pin and the RTN pin. In the "ON" state, the expected resistance is ~5 Mohm, and in the off state, it is ~3 ohms.
• The AA filter switches on BIO1 unit do not show the expected behavior - @ Chub, please check the wiring.
• All others (except the mbboDirect bits, see next bullet) were okay, including those for the CM board that are NOT part of the mbboDirect groups.
• Test failed
3. ADC channels were tested by driving a ~2Vpp 300mHz sine wave with a function generator, and looking at the corresponding EPICS channel with StripTool.
• I found that all the ADC channels don't function as expected.
• Part of the problem is due to incorrect formatting of the EPICS records in the db files, but I think the ADCs also need to be calibrated with the precision voltage source.
• Why only ADCs require calibration and not the DACs????
• Test failed
4. mbboDirect BIO output test - I made a little LED breadboard tester kit to simultaneously monitor the status of these groups of binary outputs.
• The LSB is toggled as expected when moving the gain slider along.
• However, the other bits in the group are not toggled correctly.
• I believe this is a problem with either (i) the way the EPICS record is configured to address the bits or (ii) the incorrect modbus datatype is used to initialize the ioc.
• It will be helpful if someone can look into this and get the mbboDirect bits working, I don't really want to spend more time on this.
• Test failed

I am leaving the crate powered (by bench supplies) in the office area so I have the option to work remotely on this.

14839   Fri Aug 9 20:58:33 2019 JonUpdateElectronicsBorrowed Variac transformer

I borrowed an old-looking Variac variable transformer from the power supplies cabinet along the y-arm. It is currently in the TCS lab.

14838   Fri Aug 9 16:37:39 2019 gautamUpdateALSMore EY table work

Summary:

1. 220 uW / 600 uW (~36 % mode-matching) of IR light coupled into fiber at EY.
2. Re-connected the RF chain from the beat mouth output on the PSL table to the DFD setup at 1Y2.
3. A beat note was found between the PSL and EY beams using the BeatMouth.

Motivation:

We want to know that we can lock the interferometer with the ALS beat note being generated by beating IR pickoffs (rather than the vertex green transmission). The hope is also to make the ALS system good enough that we can transition the CARM offset directly to 0 after the DRMI is locked with arms held off resonance.

Details:

Attachment #1: Shows the layout. The realized MM is ~36 %. c.f. the 85% predicted by a la mode. It is difficult to optimize much more given the tight layout, and the fact that these fast lenses require the beam to be well centered on them. They are reasonably well aligned, but I don't want to futz around with the pointing into the doubling crystal. Consequently, I don't have much control over the pointing.

Attachment #2: Shows pictures of the fiber tips at both ends before/after cleaning. The tips are now much cleaner.

The BeatMouth NF1611 DC monitor reports ~580 mV with only the EY light incident on it. This corresponds to ~60 uW of light making it to the photodiode, which is only 25% of what we send in. This is commensurate with the BS loss + mating sleeve losses.

To find the beat between PSL and EY beams, I had to change the temperature control MEDM slider for the EY laser to -8355 cts (it was 225 cts). Need to check where this lies in the mode-hop scan by actually looking at the X-tal temperature on the front panel of the EY NPRO controller - we want to be at ~39.3 C on the EY X-tal, given the PSL X-tal temp of ~30.61 C. Just checked it, front panel reports 39.2C, so I think we're good.

Next steps:

• Fix the IMC suspension
• Measure the ALS noise for the Y arm
• Determine if improvements need to be made to the IR beat setup (e.g. more power? better MM? etc etc).

EY enclosure was closed up and ETMY Oplev was re-enabled after my work. Some cleanup/stray beam dumping remains to be done, I will enlist Chub's help on Monday.

Attachment 1: IMG_7791.JPG
Attachment 2: fiberCleaning.pdf
14837   Fri Aug 9 08:59:04 2019 gautamUpdateCDSPrep for install of c1iscaux

[chub, gautam]

We scoped out the 1Y3 rack this morning to figure out what needs to be done hardware wise. We did not think about how to power the Acromag crate - the LSC rack electronics are all powered by linear supplies and not Sorensens, and the linear supplies are operating at pretty close to their maximum current-drive. The Acromag box draws ~3A of current from the 20 V supply, not sure what the current draw will be from the 15 V supply. Options:

1. Since there are sorensens in 1Y2 and 1Y1, do we really care about installing another pair of switching supplies (+20 V DC and +15 V DC) in 1Y3?
• Contingent on us having two spare Sorensens available in the lab. Chub has already located one.
2. Use the Sorensens installed already in 1Y1.
• Probably the easiest and fastest option.
• +15 V already available, we'd have to install a +20 V one (or if the +/-5 V or +12 V is unused, reconfigure for +20 V DC).
• Can argue that "this doesn't make the situation any worse than it already is"
• Will require the running of some long (~3 m) long cabling to bring the DC power to 1Y3 where it is required.
3. Get new linear supplies, and hook them up in parallel with the existing.
• Need to wait for new linear supply to arrive
• Probably expensive
• Questionable benefit to electronics noise given the uncharacterized RF pickup situation at 1Y2

I'm going with option #2 unless anyone has strong objections.

14836   Thu Aug 8 12:01:12 2019 gautamUpdateIOOMC1 suspension oddness

At ~1am PDT today, all the MC1 shadow sensor readbacks (fast CDS channels and Slow Acromag channels, latter not shown here) went to negative values. Of course a negative value makes no sense. After ~3 hours, they came back to positive values again. But since then, the shadow sensor RMS noise has been significantly higher in the >20 Hz band, and there are frequent glitches which kick the suspension. The IMC has been having trouble staying locked. I claim that this has to do with the Satellite box.

No action being taken now while I work on the ALS. In the past the problem has fixed itself.

Attachment 1: MC1_suspension.png
Attachment 2: MC1_suspension.pdf
14835   Tue Aug 6 23:09:20 2019 gautamUpdateALSEY table work
• Removed power monitoring PD (It was off anyways)
• Installed Steering mirror and collimator in K6XS mount (fast axis = p-pol to best effort by eye)
• Installed lens mounts in approx position
• Cleaned fiber at EY and connected to the collimator
• Coupled EY--->PSL and spare PSL-->EY fibers together at the PSL table to facilitate coupling.
• tbc tomorrow...
 Quote: Couple IR light into fiber with good MM at EY
14834   Tue Aug 6 16:44:50 2019 yehonathanUpdateLoss Measurement

I grab 2 hours of the PD measurements using dlData_simple.ipynb in the misaligned state.

I get pretty much a normally distributed reading without drifts (Attachements 1 and 2).

The error in the reading is ~ 0.5%.

I am pretty sure this amount of noise is enough to explain the big noise in the Loss figure measurement.

The reason is that the loss formula is #(1-P_Locked/P_Misaligned+T1)-T2) where T1 and T2 are the transmissions of the ITM and ETM.

The average of the ratio P_Locked/P_Misaligned is ~ 1.01 for a loss figure of ~ 100ppm.

The standard deviation of the ratio is ~ 1% which is also the standard deviation of the expression in the brackets.

The average of this experssion however is ~ 0.01.

The reduction of the mean amplifies the error in the loss measurments by a factor of a few 10s!

Attachment 1: figure_1.png
Attachment 2: figure_1-1.png
14833   Tue Aug 6 15:52:06 2019 gautamUpdateBHDPreliminary BHD calculations

Summary:

The requirement on the phase noise on the direct backscatter from the OMC back into the SRM is that it be less than $10^{-5} \, \mathrm{rad/\sqrt{Hz}} \approx 10^{-12} \, \mathrm{m/\sqrt{Hz}}$ @ 100 Hz, for a safety factor (arbitrarily chosen) of 10 (= 20dB below unsqueezed vacuum). Assuming 5 optics between the OMC and SRM which contribute incoherently for a factor of sqrt(5), and assuming a total of 1 ppm of the LO power to be backscattered, we need the suspensions to be moving $< 5 \times 10^{-13} \, \mathrm{m/\sqrt{Hz}}$ @ 100 Hz. This seems possible to realize with single stage suspensions - I assume we get f^4 filtering from the pendulum at 100 Hz, and that there is an additional 80 dB attenuation (from the stack) of the assumed 1 micron/rtHz motion at 100 Hz, for an overall 160 dB attenutaiton, yielding 10^-14 m/rtHz at 100 Hz.

Details:

This is the same calculation as I had posted a couple of months ago (see elog that this is a reply to), except that Koji pointed out that the LO power is expected to dominate the (carrier) power incident on the OMC cavity(ies). So the more meaningful comparison to make is to have the x-axes of the plots denote the backscatter fraction, $\epsilon_{\mathrm{BS}}$ rather than the LO power. One subtlety is that because the phase of the scattered field is random, the displacement-noise induced phase noise could show up in the amplitude quadrature. I think that in these quadrature field amplitude units, the RIN and phase noise are directly comparable but I might have missed a factor of 2*pi. But in the worst case, if all the phase noise shows up in the amplitude quadrature, we end up being only ~10dB below unsqueezed vacuum (for 1 ppm backscatter).

For the requirement on the noise in the intensity quadrature - I think this is automatically satisfied because the RIN requirement on the incident LO field is in the mid 10^-9 1/rtHz regime.

Attachment 1: OMCbackscatter.pdf
14832   Tue Aug 6 14:55:23 2019 gautamUpdateCDSMaking Matlab R2015b the default

ML2013 is unable to open Simulink on any of the workstations. We decided to make the default version of Matlab R2015b (the default of the version of RCG we are using).

I commenced the procedure of the migration, starting with making a tagged commit of the current running simulink models. A local backup was also made, plus we have the usual chiara-based backup so I think we're in good hands.

Currently the branch and tag are protected - once we verify that everything works as expected post migration, I will open it up. I changed the directory structure of the models, need to confirm that the rtcds compilers don't have any hardcoded paths which may break due to my change.

The symlink to Matlab R2013 was deleted and a new symlink to R2015b was made. I activated the license using the Caltech campus license. Now running matlab from shell starts up R2015b . Simulink even works 😲 .

Attachment 1: ML2015b.png
14831   Tue Aug 6 14:12:02 2019 yehonathanUpdateComputersmaking rossa great again

cdsutils is not working on rossa.

Import cdsutils produces this error:

In [2]: import cdsutils
---------------------------------------------------------------------------
OSError                                   Traceback (most recent call last)
<ipython-input-2-949babce8459> in <module>()
----> 1 import cdsutils

/ligo/apps/linux-x86_64/cdsutils-480/lib/python2.7/site-packages/cdsutils/__init__.py in <module>()
53
54 try:
---> 55     import awg
56 except ImportError:
57     pass

/ligo/apps/linux-x86_64/cdsutils-480/lib/python2.7/site-packages/cdsutils/awg.py in <module>()
30 """
31
---> 32 import sys, numpy, awgbase
33 from time import sleep

/ligo/apps/linux-x86_64/cdsutils-480/lib/python2.7/site-packages/cdsutils/awgbase.py in <module>()
17 libawg = CDLL('libawg.so')
18 libtestpoint = CDLL('libtestpoint.so')
---> 19 libSIStr = CDLL('libSIStr.so')
20
21 ####

/ligo/apps/anaconda/lib/python2.7/ctypes/__init__.pyc in __init__(self, name, mode, handle, use_errno, use_last_error)
364
365         if handle is None:
--> 366             self._handle = _dlopen(self._name, mode)
367         else:
368             self._handle = handle

OSError: libSIStr.so: cannot open shared object file: No such file or directory

14830   Mon Aug 5 17:36:04 2019 yehonathanUpdateLoss Measurement

We check for unexpected drifts in the PD reading (clipping and such). We put a pickoff mirror where the PD used to be and place the PD at the edge of the table such that the beam is focused on it (see attachment).

The arms are completley misaligned. We note the time of start of measurement to be 1249086917.

Attachment 1: 20190805_171511.jpg
14829   Mon Aug 5 17:23:26 2019 gautamSummaryComputersWiFi Settings on asia

The VEA laptop asia was configured to be able to connect to too many WiFi networks - it was getting conflicted in its default position at the vertex and trying to hop between networks, for some reason trying to connect to networks that had poor signal strength. I deleted all options from the known networks except 40MARS. Now the network connection seems much more stable and reliable.

Draft   Mon Aug 5 16:28:41 2019 yehonathanUpdateLoss Measurementwhat is going on with the loss measurements ?

We hypothesize that the systematic error in the loss measurement can come from the fact that the requirement on the alignment of the cavity mirrors is not stringent enough.

We repeat the loss measurement with 50 measurements. This time we change the thresholds for the error signals of the dither-align in the measureArmLoss.py file from 0.5 to 0.3.

We repeat the analysis done before:

We plot the reflected power of the two states on top of each other:

This  time it appears there was no drift. The histogram of the loss measurement:

The mean is 104ppm and the variation is 27%.

What I notice this time is that the PD readings in the aligned and misaligned states are anti-correlated. This is also true in the previous run (where there was drift) when looking in the short time scales. I plot several time series to demonstrate:

I wonder what can cause this behaviour.

14827   Mon Aug 5 14:47:36 2019 yehonathanUpdateLoss Measurement

Summary:

I analyze the 100 reps loss measurement of the Y arm using the AnalyzeLossData.ipynb notebook.

The mean of the measured loss is ~ 100ppm and the variation between the repititions is ~ 27%.

In Detail

In the real measurement the misaligned and locked states are repeatedly switched between each other. I plot the misaligned and locked PD readings seperately over time.

There seems to be a drift that is correlated between the two readings. This is probably a drift in the power after the MC2. To verify, I plot the ratio between those readings and find no apparent drift:

The variation in the ratio is less than 1%. The loss figure, computed to be 1 minus this ratio times a big number, give a much worse variation. I plot the histogram of the loss figure at each repitition (excluding extremely bad measurements):

The mean is ~ 100ppm. And the variation is ~ 27%.

14826   Sun Aug 4 14:39:41 2019 gautamUpdateGeneralsome lab activity
1. Unresponsive c1psl, c1iool0, c1auxey and c1iscaux VME crates were keyed.
2. c1psl channels were burt-restored, did a burtrestore, and re-locked the PMC. Tweaked the pointing into the PMC on the PSL table to increase the PMC transmission from ~0.69 to ~0.71.
3. Re-locked IMC. Ran WFS offset script to relieve the ~100 DAC counts (~10 urad) DC offset from the WFS servos to the IMC suspensions (a serious calibration of this into physical units should be made part of the planned 40m WFS activity). Now that I think about it, since we change the IMC alignment to match the input beam alignment, some post-IMC clipping could modulate the power incident on the ITMs, which is a source of error for the arm cavity loss determination using DC reflection. We need a better normalizing data stream than the IMC transmission.
4. The IFO_OVEREVIEW medm screen was modified such that the threshold for the PMC transmitted beam to be visible was lowered from 0.7 to 0.6, so that now there is a continuous beam line from the NPRO to the PRM when the IMC is locked even when the PMC transmission degrades by 5% due to thermally driven pointing drifts on the PSL table.
5. The wmctrl utility on pianosa wasn't working so well, I wasn't able to use my usual locking MEDM autoconfig scripts. Turned out to be due to a zombie MEDM window which I killed with xkill, now it is working okay again.
6. The misaligned XARM was re-aligned and the loss measuring PDA520 at the AS port was removed from the beam path (mainly to avoid ADC saturations the fringing Michelson will cause).
7. I noticed that the ETMX Oplev HeNe SUM level has degraded to ~50% of its power level from 200 days ago [Attachment #1], may need a new HeNe here soon. @Chub, do we have spare HeNes in stock?

I want to collect some data with the arms locked to investigate the possibility/usefullness of having seismic feedforward implemented for the arms (it is already known to help the IMC length and PRC angular stability at low frequencies). To facilitate diagnostics I modified the file /users/Templates/Seismic/Seismic_vs_TRXTRYandMC.xml to have the correct channel names in light of Lydia's channel name changes in 2016. Looking at the coherence data, the alignment of the cartesian coordinate system of the Seismometers at the ends and the global interferometer coordinate system can be improved.

I don't know if for the MISO filter design if there is any difference in using TRX/TRY as the target, or the arm length control signal.

Data collection started at 1249018179. I've setup a script running in a tmux shell to turn off the LSC enable in 2 hours.

Attachment 1: ETMX_OL.png
Attachment 2: Seismic_TRXTRYandMC_4Aug2019.pdf
14825   Fri Aug 2 17:07:33 2019 yehonathan, gautamUpdateLoss Measurement

We run a loss measurement on the Y arm with 50 repetitions.

14824   Fri Aug 2 16:46:09 2019 KruthiUpdateCamerasClean up

I've put the analog camera back and disconnected the 151 unit GigE. But I ran out of time and wasn't able to replace the beamsplitter. I've put all the equipments back to the place where I took them from. The chopper and beam dump mount, that Koji had got me for the scatterometer, are kept outside, on the table I was working on earlier, in the control room. The camera lenses, additional GigEs, wedge beamsplitter, 1050nm LED and all related equipments are kept in the GigE box. This box was put back into CCD cameras' cabinet near the X arm.

Note: To clean stuff up, I had entered the lab around 9.30pm on Monday. This might have affected Yehonathan's loss measurement readings (until then around 57 readings had been recorded).

Sorry for the late update.

14823   Fri Aug 2 11:37:38 2019 gautamUpdateALSEY IR ALS Assay

Summary:

I'd like to confirm that the IR ALS scheme will work for locking. The X-arm performance so far has been encouraging. I want to repeat the characterization for the Y arm. So I inspected the layout on the EY table, and made a list of characterization tasks. The current EY beam routing is difficult to work with, and it will definitely benefit from a re-do. However, I don't know how much time I want to spend re-doing it, so for a start, I will just try and couple some amount of light into a fiber and bring it to the PSL table, and see what noise performance I get.

Details:

Attachment #1: Photo of the current beam layout. The powers indicated were measured with the Ophir power meter.

• I measure an SHG conversion efficiency of 0.87 %/W, which is considerably lower than the ~3.7%/W that is theoretically expected, and 1.5%/W that is realized at EX.
• Of the 0.5 mW of green light that is generated, I measure ~0.375 mW at the viewport into the EY chamber. So there is ~25 % loss in the green beam path on the EY table. Seems high to me.
• The previous solution of coupling IR light into the fiber realized at EY was to use the SHG leakage IR beam. While there isn't a measurement showing that this dirty beam is noisier than a cleaner pickoff, I'd like to adopt the solution used at EX, which is to use the leakage beam from the first steering mirror in the NPRO beam path. This will allow better mode-matching and polarization control of the beam being coupled into the fiber, which at least in principle, translates to less phase noise.
• However - the beam layout at the EY table offers much less freedom to work with this idea than EX. A constraint is the clamp that secures the enclosure to the optical table, labelled in the photo. Further behind it, the green steering optics occupy all available space. A more comprehensive photo of the EY table can be found here.
• Off the top of my head, I don't see any other good open spots on the EY table where we could couple IR light into the fiber.
• One other change I'd like to make is to replace the first steering mirror after the NPRO head, which is currently a Y1 HR mirror, with a R=99% BS. This will make it easier to control the amount of power coupled into the fiber, which is something we'd like.

Attachment #2: A candidate mode-matching solution, given the constraints outlined above. It isn't great, with only 85% modematching even theoretically possible. The lenses required are also pretty fast lenses. But I think it's the best possible without a complete overhaul of the EY layout. I'm still waiting for the lens kit to arrive, but as soon as they get here, I will start this work.

• Characterize SHG at EY [done 7/28]
• Characterize gPDH at EY (loop TFs, improve MM, PDH discriminant, check the polarization)
• Couple IR light into fiber with good MM at EY [done with 36% MM 8/9]
• Clean fiber at EY, and at the PSL table [done 8/9]
• Make the PSL + Y IR beat [done 8/9]
• Noise budget
Attachment 1: IMG_7780.JPG
Attachment 2: Ey_MM_20190802.pdf
14822   Thu Aug 1 13:55:34 2019 DuoBureaucracyEquipment loanGpib module taken to QIL lab

vanna --> QIL.

gautam 20190804: The GPIB module + power supply were returned to me by Duo ~5pm today at the 40m.

14821   Wed Jul 31 17:57:35 2019 KojiUpdateBHDOMC cavity geometry

4 deg is not an optimized number optimized for criteria, but to keep the cavity short width to 0.1m. But the justification of 4deg is found in Section 3 and 4 of T1000276 on Page 4.

 Quote: Question for Koji: how is the aLIGO OMC angle of incidence of ~4 degrees chosen? Presumably we want it to be as small as possible to minimize astigmatism, and also, we want the geometric layout on the OMC breadboard to be easy to work with, but was there a quantitative metric? Koji points out that the backscatter is also expected to get worse with smaller angles of incidence.
14820   Wed Jul 31 14:44:11 2019 gautamUpdateComputersSupermicro inventory

Chub brought the replacement Supermicro we ordered to the 40m today. I stored it at the SW entrance to the VEA, along with the other Supermicro. At the time of writing, we have, in hand, two (unused) Supermicro machines. One is meant for EY and the other is meant for c1psl/c1iool0. DDR3 RAM and 120 GB SSD drives have also been ordered, but have not yet arrived (I think, Chub, please correct me if I'm wrong).

Update 20190802: The DDR3 RAM and 120 GB SSD drives arrived, and are stored in the FE hardware cabinet along the east arm. So at the time of writing, we have 2 sets of (Supermicro + 120GB HD + 4GB RAM).

 Quote: We should ask Chub to reorder several more SuperMicro rackmount machines, SSD drives, and DRAM cards. Gautam has the list of parts from Johannes' last order.
14819   Wed Jul 31 09:41:12 2019 gautamUpdateBHDOMC cavity geometry

Summary:

We need to determine the geometry (= round-trip length and RoC of curved mirrors) of the OMC cavities for the 40m BHD experiment. Sticking to the aLIGO design of a 4 mirror bowite cavity with 2 flat mirrors and 2 curved mirrors, with a ~4deg angle of incidence, we need to modify the parameters for the 40m slightly on account of our different modulation frequencies. I've setup some infrastructure to do this analytically - even if we end up doing this with Finesse, it is useful to have an analytic calculation to validate against (also not sure if Finesse can calculate HOMs up to order 20 in a reasonable time, I've only seen maxtem 8).

Attachment #1: Heatmap of the OMC transmission for the following fields:

• Carrier TEM00 is excluded, but HOMs up to m+n=20 included for both the horizontal and vertical modes of the cavity.
• f1 and f2 upper and lower sidebands, up to m+n=20 HOMs for both the horizontal and vertical modes of the cavity, including TEM00.
• Power law decay assumed for the HoM content incident on the OMC - this will need to be refined
• The white region is where the cavity isn't geometrically stable.
• Green dashed line indicates a possible operating point, white dashed line indicates the aLIGO OMC operating point. On the basis of this modeling, we would benefit from choosing a better operating point than the aLIGO OMC geometric parameters.

Algorithm:

1. Compute the round-trip Gouy phase, $\phi_{\mathrm{gouy}}$, for the cavity.
2. With the carrier TEM00 mode resonant, compute the round-trip propagation phase, $\phi_{\mathrm{prop}} = \frac{2 \pi f_{\mathrm{offset}} L_{\mathrm{rt}}}{c}$, and the round-trip Gouy phase, $\phi_{\mathrm{G}} = (m+n)\phi_{\mathrm{gouy}}$ for the $\mathrm{TEM}_{mn}$ mode of the field, with $f_{\mathrm{offset}}$ specifying the offset from the carrier frequency (positive for the upper sideband, negative for the lower sideband). For the aLIGO cavity geometry, the 40m modulation sidebands acquire ~20% more propagation phase than the aLIGO modulation sidebands.
3. Compute the OMC transmission for this round-trip phase (propagation + Gouy).
4. Multiply the incident mode power (depending on the power law model assumed) by the cavity transmission.
5. Sum all the fields.

Next steps:

1. Refine the incident mode content (and power) assumption. Right now, I have not accounted for the fact that the f2 sideband is resonant inside the SRC while the f1 sideband is not. Can we somehow measure this for the 40m? I don't see an easy way as it's probably power dependent?
2. Make plots for the projection along the slices indicated by the dashed lines - which HOMs are close to resonating? Might give us some insight.
3. What is the requriement on transmitted power w.r.t. shot noise? i.e. the colorbar needs to be translated to dBVac.
4. If we were being really fancy, we could simultaneously also optimize for the cavity finesse and angle of incidence as well.
5. Question for Koji: how is the aLIGO OMC angle of incidence of ~4 degrees chosen? Presumably we want it to be as small as possible to minimize astigmatism, and also, we want the geometric layout on the OMC breadboard to be easy to work with, but was there a quantitative metric? Koji points out that the backscatter is also expected to get worse with smaller angles of incidence.

The code used for the ABCD matrix calcs have been uploaded to the BHD modeling GIT (but not the one for making this plot, yet, I need to clean it up a bit). Some design considerations have also been added to our laundry list on the 40m wiki.

Attachment 1: paramSpaceHeatMap.pdf
14818   Tue Jul 30 20:11:12 2019 ranaSummaryIMCIMC ASC: thoughts and hopes

One of the biggest challenges in LIGO is reducing the alignment control noise. If you haven't worked on it for at least a few years, it probably seems like a trivial problem. But all versions of LIGO since 2001 have been limited by ASC noise below ~50 Hz.

I think the 40m IMC is a good testbed for us to try a few approaches towards mitigating this noise in LIGO. The following is a list of steps to take to get there:

1. Using step responses and TF measurements, characterize the full existing system: SISO loop shapes, cross-couplings, and how diagnonal is the input and output matrices of the WFS. In principle, since we have 2 WFS in reflection and 1 DC QPD in the MC2 transmission, we should have full sensing of all angular DoFs.
2. Check the correct operation of the WFS heads and the whole RF chain. We want the gains in the system to be such that either the shot noise or the RF electronics noise of the head is the limiting broadband noise in the system.
3. Balancing the gains and phases of the demodulated signals is tricky, because we have no good reference. Should we use the JenneAM laser or the PSL beam?
4. Estimate the coupling from the angular feedback signal to the IMC length noise using (1) sine wave injections for linear coupling, and (2) broadband noise for nonlinear coupling.
5. We think the bilinear noise is due to the beam spot motion modulating the angle to length coupling as sensed by the laser beam. If this is true, we can increase the low frequency gain to minimize the beam spot motion (is this true?).
6. By sinusoidally driving the mirror angles we can measure the instantaneous beam spot positions. We can then derive the matrix required to convert from our angular sensors (WFS + QPD) into beam spot motion. We should modify our IMC-WFS real-time model to give us DAQ channels which are beam spot estimators.
7. Build a simulation of an IMC which has WFS, QPD, shot noise, and seismic noise.
8. Use our optimal linear-feedback design tools to make Angular loops which minimize the bilinear noise coupling.
9. Build a nonlinear controller (neural networks: dense + CNN) that outperforms the linear one by estimating the beam spot motion continuously and driving the cavity length to cancel the angle-to-length noise.

I think that steps 1-6 are well within our existing experience, but we should do it anyway so as to reduce the IMC beam motion at low frequencies, and also to reduce the 10-100 Hz frequency noise as seen by the rest of the interferometer.

Steps 7-8 are medium hard, but we can get some help from the CSWG in tackling it.

Step is pretty tough, but I would like to try it and also get some help from MLWG and CSWG to address it.

14817   Tue Jul 30 09:13:31 2019 gautamUpdatePSLc1psl keyed, Agilent setup cleared
1. IMC would not lock. c1psl EPICS channels were unresponsive. I keyed the crate and went through the usual burtrestore/PMC-relocking dance.
2. While at 1X2, I decided to take this opportunity to clean up the AG4395 setup that has been setup there unused for several weeks now.
• Unplugged the active probe connected via BNC-T connector to the mixer IF output.
• Noticed that the active probe (S/N 2850J01450) did not have it's power connection connected. According to the manual, this is bad. I don't know if the probe is damaged or not.
• Moved the AG4395 cart out of the way so that there is a little more room around 1X1/1X2.
14816   Mon Jul 29 19:08:55 2019 yehonathanUpdateLoss MeasurementReviving loss measurement by reflection

1. X arm is totally misaligned in order to measure the Y arm loss using the reflection method. Each measurement round consists of measuring the reflected power when the Y arm is aligned and when it is misaligned.

2. The measurement script used is /scripts/lossmap_scripts/armLoss/measureArmLoss.py. It generates a log file in the /logs folder specifying the alignment and misalignment times.

3. The data extraction script dlData.py processes the raw data in the log file and creates a hdf5 file in the /Data folder conataining the data of the measurement it self.

4. dlData.py labels the the aligned and misaligned datas incorrectly when the number of measurement is odd. I use only even number of measurements then.

5. In order to clip the chaotic transition between the aligned and misaligned states I use tDur attribute smaller than the actual sleep time used in the measurement script itself.

6. plotData.py (written by Gautam) and AnalyzeLossData.ipynb (written by me) can be used to calculate the loss and to plot some analyses (see https://nodus.ligo.caltech.edu:8081/40m/14568). They give roughly the same answer. The descripancy can be explained by the different modulation and ITM transmissions used.

7. I take a measurement of 8 repeatitions. I plot the measured reflected power alternating between the aligned and misaligned states.

I find that the reflected power is repeatable to within 1%.

This is consistent with the transmission data plotted here which is also repeatable to within 1%.

8. I take an overnight measurement of 100 repeatitions.

14815   Mon Jul 29 13:32:56 2019 gautamUpdateLoss MeasurementLoss measurement PD installed in AS path

[yehonathan, gautam]

• we placed a PDA520 photodiode in the AS beampath, so AS110 and AS55 no longer see any light.
• ITMX and ETMX were misaligned (since the plan is to measure the Y arm loss).
• The PDA520 and MC2 transmission are currently going to the Y arm ALS beat channels in the DAQ system. Unfortunately, we have no control over the whitening gains for these channels because of the c1iscaux2 situation.
14814   Fri Jul 26 19:53:53 2019 JonOmnistructureCamerasGigE Camera Server

I've started setting up the last new rackmount SuperMicro as a dedicated server for the GigE cameras. The new machine is currently sitting on the end of the electronics test bench. It is assigned the hostname c1cam at IP 192.168.113.116 on the martian network. I've installed Debian 10, which will be officially supported until July 2024.

I've added the /cvs/cds NFS mount and plan to house all the client/server code on this network disk. Any dependencies that must be built from source will be put on the network disk as well. Any dependencies that can be gotten through the package manager, however, will be installed locally but in an automated way using a reqs file.

We should ask Chub to reorder several more SuperMicro rackmount machines, SSD drives, and DRAM cards. Gautam has the list of parts from Johannes' last order.

14813   Thu Jul 25 20:08:36 2019 gautamUpdateComputersSolidworks machine

I brought one CPU (Dell T3500) and one 28" monitor from Mike Pedraza's office in Downs to the 40m. It is on Steve's desk right now, pending setup. The machine already has Solidworks and Altium installed on it, so we can set it up at our leisure. The login credentials are pasted on the CPU with a post-it should anyone wish to set it up.

14812   Thu Jul 25 14:28:03 2019 gautamConfigurationComputersfirewalld disabled for EPICS CA

I think rana did some more changes to this workstation to make it useful for commissioning activities - but the MEDM screens were still white blanks. The problem was that the firewalld wasn't disabled (last two steps of the KThorne setup wiki). I disabled it. Now donatella can run MEDM, ndscope and StripTool. DTT doesn't work to get online data because of a "Synchronization Error", I'm not bothering with this for now. I think Kruthi successfully demonstrated the fetching of offline data with DTT.

Attachment 1: donatellaCommissioning.png
14811   Thu Jul 25 12:25:56 2019 gautamUpdateALSIR ALSX noise

Summary:

1. There are some broad peaks in the ALS out-of-loop noise, centered at ~145 Hz, ~245 Hz and ~570 Hz which are absent in both the POX in-lock error signal and in the green PDH error signals (see Attachment #1). So I conclude they originate in the IR ALS beat chain somewhere. Needs more investigation, in the general quest to improve the ALS noise.
2. This measurement also shows that the ALS noise is limited by unsuppressed EX green PDH frequency noise above ~400 Hz (100 Hz if you ignore the unexplained broad humps).

These spectra were taken with the arm cavity length locked to the PSL frequency using POX as an error signal, and the EX laser frequency locked to the XARM cavity length by the analog PDH servo at EX, so there is no feedback control with the ALS beat signal as an error signal.

Other details:

• The transition of arm resonance control from POX to ALS error signal is more robust now - I am able to do this during daytime, and also maintain the lock for >20 minutes at a time.
• Rana encouraged me not to spend too much time on this - so my next goal here will be to get the Y arm IR ALS working, and then we can control the two arms using ALS error signals in the CARM/DARM basis instead of the X/Y basis.
• I still think it's worth getting the ALS good enough that the locking becomes repeatable and reliable.
• The main task here is going to be re-doing the EY green layout to match the EX layout, get good MM into the cavity etc.
• The IR light also has to be coupled into the fiber at EY.
14810   Thu Jul 25 09:19:32 2019 JonUpdateCamerasUpgraded Pylon from 5.0.12 to 5.2.0

I'll keep developing the camera server on a parallel track using the "new_..." directory naming convention. One thing I forgot to note is that the new pylon/pypylon packages require Python 3, so will not work with any of the 2.7 scripts. All of the environment I need to set up is exclusively Python 3. I won't change anything in the Python 2.7 environment in current use.

Also, I found the source of the bit resolution issue: Joe B's code loads a set of initialization parameters from a config file. One of them is "Frame Type = Mono8" which sets the dynamic range of the stream. I'll look into how this should be changed.

 Quote: Since there are multiple SURF projects that rely on the cameras: I moved the new installs Jon made to "new_pylon5" and "new_pypylon". The old installs were moved back to be the default directories. The bashrc alias for pylon was updated to allow the recording of videos (i.e. it calls the PylonViewerApp from new_pypylon). There is a script that can grab images at multiple exposures and save 12-bit data as uint16 numpy arrays to an HDF5 file. Right now, it is located at /users/kruthi/scripts/grabHDR.py. We can move this to a better place later, and also improve the script for auto adjusting the exposure time to avoid saturations.
14809   Thu Jul 25 00:26:47 2019 MilindUpdateCamerasConvolutional neural networks for beam tracking

Somehow I never got around to doing the pixel sum thing for the new real data from the GigE. Since I have to do it for the presentation, I'm putting up the results here anyway. I've normalized this and computed the SNR with the true readings.

SNR = (power in true readings)/ (power in error signal between true and predicted values)

Attachment #2 is SNR of best performing CNN for comparison.

Attachment 1: centroid.pdf
Attachment 2: subplot_yaw_test.pdf
14808   Wed Jul 24 20:23:52 2019 gautamUpdateCamerasUpgraded Pylon from 5.0.12 to 5.2.0

Since there are multiple SURF projects that rely on the cameras:

1. I moved the new installs Jon made to "new_pylon5" and "new_pypylon". The old installs were moved back to be the default directories.
2. The bashrc alias for pylon was updated to allow the recording of videos (i.e. it calls the PylonViewerApp from new_pypylon).
3. There is a script that can grab images at multiple exposures and save 12-bit data as uint16 numpy arrays to an HDF5 file. Right now, it is located at /users/kruthi/scripts/grabHDR.py. We can move this to a better place later, and also improve the script for auto adjusting the exposure time to avoid saturations.

My changes were necessary because the grabHDR.py script was throwing python exceptions, whereas it was running just fine before Jon's changes. We can move the "new_*" dirs to the default once the SURFs are gone.

Let's freeze the camera software config in this state until next week.

14807   Wed Jul 24 20:05:47 2019 MilindUpdateCamerasCNNs for beam tracking || Tales of desperation

At the lab meeting today, Rana suggested that I use the Pylon app to collect more data if that's what I need. Following this, Jon helped me out by updating the pylon version and installing additional software to record video. Now I am collecting data at

1. higher exposure rate - 600 us magically gives me a saturation percentage of around 1%, see attachment #1 (i.e around 1% of the pixels in the region containing the beam spot are over 240 in value). Ths is a consequence of my discussion with Gabriele where we concluded that I was losing information due the low exposure rate I was using.
2. For much longer: roughly 10 minutes
1. at an amplitude of 40 cts for 0.2 Hz
2. at an amplitude of 20 cts for 0.2 Hz
3. at an amplitude of 10 cts for 0.2 Hz
4. at an amplitude of 40 cts for 0.4 Hz
5. at an amplitude of 20 cts for 0.2 Hz
6. Random motion

Consequently I have dithered the MC2 optic from around 9:00 PM.

Attachment 1: saturation_percentage.pdf
14806   Wed Jul 24 16:45:32 2019 JonUpdateCamerasUpgraded Pylon from 5.0.12 to 5.2.0

I upgraded Pylon, the C/C++ API for the GigE cameras, to the latest release, 5.2.0. It is installed in the same location as before, /opt/rtcds/caltech/c1/scripts/GigE/pylon5, so environment variables do not change. The old version, 5.0.12, still exists at opt/rtcds/caltech/c1/scripts/GigE/backup_pylon5.

The package contains a GUI application (/bin/PylonViewerApp) for streaming video. The old version supports saving still images, but Milind discovered that the new version supports saving video as well. This required installing a supplementary package supporting MPEG-4 output.

Basler's GUI application is launched from the terminal using the alias pylon. I've tested it and confirm it can save both videos and still-image formats. I recommend to also try grabbing images using this program and check the bit resolution. It would be a useful diagnostic to know whether it's a bug in Joe B.'s code or something deeper in the camera settings.

Attachment 1: IMG_3525.jpg
14805   Wed Jul 24 12:24:43 2019 MilindUpdateIOOunstick.py and ifotest

Moved the unstick.py code to the ifotest repository here. It now handles signals like those generated by Ctrl-C and so forth. It can still be run as python unstick.py <machine1> <machine2> etc.

14804   Wed Jul 24 04:20:35 2019 KruthiUpdateCalibration-RepairMC2 pitch and yaw calibration

Summary:  I calibrated MC2 pitch and yaw offsets to spot position in mm. Here's what I did:

1. Changed the MC2 pitch and yaw offset values using  ezca.Ezca().write('IOO-MC2_TRANS_PIT_OFFSET', <pitch offset value> ) and ezca.Ezca().write('IOO-MC2_TRANS_YAW_OFFSET', <yaw offset value> )
2. Waited for ~ 700-800 sec for system to adjust to the assigned values
3. Took snapshots with the 2 GigEs I had installed - zoomed in and zoomed out. (I'll be using these to make a scatter loss map, verify the calibration results, etc)
4. Ran the mcassDecenter script, which can be found in /scripts/ASS/MC. This enters the spot position in mm in the specified text file.

Results:  In the pitch/yaw vs pitch_offset/yaw_offset graph attached,

• intercept_pitch = 6.63 (in mm) ,  slope_pitch = -0.6055 (mm/counts)
• intercept_yaw = -4.12 (in mm) ,  slope_yaw = 4.958 (mm/counts)
Attachment 1: Pitchyaw_calibration.png
14803   Wed Jul 24 02:06:05 2019 KruthiUpdateCamerasHDR images

I have been trying a couple of HDR algorithms, all of them seem to give very different results. I don't know how suitable these algorithms are for our purpose, because they are more concerned with final display. I'm attaching the HDR image I got by modifying Jigyasa's code a bit (this image has been be modified further to make it suitable for displaying). Here, I'm trying compare the plots of images that look similar. The HDR image has a dynamic ratio of 700:1

PS: 300us_image.png file actually looks very similar to HDR image on my laptop (might be an issue with elog editor?). So I'm attaching its .tiff version also to avoid any confusion.

Attachment 1: HDR_8bit.png
Attachment 2: hdrplot.png
Attachment 3: C_MC2_2019-07-19-01-50-09.tiff
Attachment 4: 300us_image.png
Attachment 5: 300us_image.tiff
Attachment 6: actualimageplot.png
14802   Wed Jul 24 00:22:24 2019 gautamUpdateALSPSL frequency locked to XARM length using ALS

Summary:

I succeeded in locking the PSL frequency to the XARM cavity length, with 9 pm RMS (Attachment #1) motion below 1 kHz, by actuating on MC2 to change the IMC length. The locks were pretty stable (~20 minutes) - the dominant cause of lockloss was the infamous ETMX drifting problem.

Details:

1. I did not need to do anything to fix the anomalosly high BR mode coupling I reported yesterday .
• To test where this could be coming from - I looked at the ALS spectrum again with the XARM length locked to the PSL frequency using POX.
• Then I compared the spectra with the BR filter in the XARM servo enabled/disabled, see Attachment #2
• There bounce/roll peak heights even with the BR filter disabled is ~x100 smaller than what I reported yesterday (it remained the case today, because without enabling the BR filter in the CARM servo bank, the TRX level was fluctuating wildly at ~16 Hz).
2. The CARM loop (which is what the PSL frequency was slaved to) had ~150 Hz UGF with ~40 degrees phase margin, see Attachment #3.
3. The quoted RMS sensing noise is if we trust the old POX calibration - may be off by a factor of a few, but probably not an order of magnitude. I'll recalibrate using the free-swinging Michelson technique in the coming days.
4. The two broad humps in Attachment #1, centered at ~180 Hz and ~300 Hz, are present in the XARM lock as well - so it is somehow imprinted on the arm cavity length. Fixing that will improve the RMS noise performance significantly.

My main motivation here is to make some measurements and investigate the SoCal idea using a toy system, i.e. a single arm cavity controlled using ALS, so that's what Craig and I will attempt next.

Attachment 1: ALS_X_noise_POX.pdf
Attachment 2: BR_comparison.pdf
Attachment 3: ALS_CARM_OLG.pdf
14801   Tue Jul 23 21:59:08 2019 JonUpdateCamerasPlan for GigE cameras

This afternoon Gautam and I assessed what to do about restoring the GigE camera software. Here's what I propose:

• Set up one of the new rackmount Supermicros as a dedicated camera feed server
• All GigE cameras on a local subnet connected to the second network interface (these Supermicros have two)
• Put the SnapPy, pypylon, and pylon5 binaries on the shared network drive. These all have to be built from source.
• All other dependencies can be gotten through the package managers, so create requirements files for yum and pip to automatically install these locally.

I've started resolving the many dependencies of this code on rossa. The idea is to get a working environment on one workstation, then generate requirements files that can be used to set up the rest of the machines. I believe the dependencies have all been installed. However, many of the packages are newer versions than before, and this seems to have broken SnapPy. I'll continue debugging this tomorrow.

14800   Mon Jul 22 23:53:16 2019 gautamUpdateALSIR ALS locking attempt

Summary:

My goal tonight was to lock the PSL frequency to be resonant in the XARM cavity, using the PSL+EX beat as the error signal. I was not successful - mainly, I was plagued by huge BR mode coupling in the error signal, and I could not enable the BR notch filter in the control loop without breaking the lock. Need to think about next steps.

Details:

• POX and POY locking was easily restored.
• EX green alignment was tweaked at the end-table. A large YAW correction was required, which I opted to apply on the mechanical mirror mounts rather than the PZTs. GTRX ~0.4 was recovered.
• The arm cavity length was first locked using POX as an error signal
• Then I looked at the out-of-loop ALS noise, trusting the DFD's V/Hz calibration (red-trace in Attachment #1).
• I judged it to be close enough to the benchmark reference (green-trace in Attachment #1), and so decided that I could go ahead and try locking.
• A modified version of the script /opt/rtcds/caltech/c1/scripts/XARM/Lock_ALS_XARM.py was used to transition control from POX to the ALS error signal
• I found that I had to change the sign of the CARM loop gain for the servo to remain stable (in this config, CARM-->MC2 length, thereby modifying the IMC frequency to keep the PSL resonant in the XARM cavity).
• I don't know why this sign change was required - we are still sticking to the same convention that the beat frequency increases when the temperature slider for the EX laser is incremented in counts.
• The script failed multiple times at the BOOST/BR notch filter enabling step.
• Doing these steps manually, I found that turning the BR notch, FM6, ON destroyed the lock immediately.
• Motivated by this observation, I looked at the in-loop error signal spectrum, see Attachment #2. Here, the PSL frequency is servoed by the ALS error signal, but the BR notch filter isn't enabled.
• The Bounce-mode peak is huge - where is this coming from? It is absent in the ALS spectrum when the XARM is locked with POX. So it is somehow connected with actuating on the MC2 suspension? Or is it that the FM6=BounceRoll filter of the XARM loop is squishing the noise when looking at the ALS spectrum in POX lock, i.e. Attachment #1? In which case, why can't I engage FM6 for the CARM loop???

Anyway, now that I have a workable set of settings that gets me close to the ALS lock of the XARM, I expect debugging to proceed faster.

Update 2019 July 23: I looked at the control loop shape today, see Attachment #3. I'm not sure I understand why the "BounceRoll" filter  in this filter bank looks like a resonant gain rather than a notch, as it does for the Oplev or SUSPOS loops for example - don't we want to not actuate at these frequencies because the reason the signal exists is because of the imperfect OSEM/magnet positioning? This does not explain the spectrum shown in Attachment #2 however, as that filter was disabled.

Attachment 1: ALS_X_outOfLoopnoise.pdf
Attachment 2: ALS_X_inLoopnoise.pdf
Attachment 3: CARM_loopShape.pdf
14799   Mon Jul 22 21:04:40 2019 ranaUpdateComputersmaking rossa great again
• copied over /etc/fstab lines from pianosa sothat the NFS mounts work correctly
• added symlinks so that the NFS dirs mount in the right dirs
• installed Opera browser
• symlink libsasl2.so.3 -> libsasl2.so.2 and now DTT runs and can get data now and in the past
• DTT can natively produce PDF so you don't have to take screen caps of your camera phone and make a chalk drawing of that anymore
• sitemap/MEDM is working
• after editing fonts.alias as detailed in Thorne wiki, I ran 'sudo xset fp rehash' to get MEDM to notice new fonts. MEDM Scalable fonts are back!!
• installed Grace and now dataviewer works
• ndscope not running: yum install ndscope breaks because it can't find a couple of python34 packages
• tested that AWGGUI also runs and puts in real sine waves
Attachment 1: seis.pdf

[Kruthi, Milind]

On Friday, Milind and I performed the pitch adjustment test Rana had asked us to do. Only 1 blue beam in case of ITMX and two in case of ETMY, ETMX and ITMY were accessible. Milind (of mass 72 kg as of 10 May 2019) stood on each of the accessible blue beams of the test mass chambers for one minute and I recorded the corresponding gps time. Before moving to the next beam, we spared more than a minute for relaxation after the standing end time. Following are the recorded gps times.

 ETMX ITMX ETMY ITMY Beam 1 Beam 2 Beam 1 Beam 1 Beam 2 Beam 1 Beam 2 Standing start time (gps) 1247620911 1247621055 1247621984 1247622394 1247622585 1247622180 1247622814 Standing end time (gps) 1247620974 1247621118 1247622058 1247622459 1247622647 1247622250 1247622880

PS: For each blue beam relaxation time ~ 1 min after the standing end time

Attachment 1: ETMX.pdf
Attachment 2: itmx.pdf
Attachment 3: ETMY.pdf
Attachment 4: ITMY.pdf
Attachment 5: 3f1a82f2-b86a-469e-8914-9278a216c5f9.jpg
Attachment 6: 1d174307-d940-42e6-812b-83417d0f5f6a.jpg
14797   Mon Jul 22 13:26:41 2019 KruthiUpdateIOOMC locked

The MC2 has 2 GigE cameras right now. I'll put back the analog asap.

 Quote: I found the MC2 face camera disabled(?) and the MC servo board input turned off. I turned the MC locking back on but I don't see any camera image yet.
ELOG V3.1.3-