40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 285 of 346 Not logged in
ID Date Author Type Category Subject
13437   Tue Nov 21 11:37:29 2017 gautamUpdateOptical LeversBS OL calibration updated

I calibrated the BS oplev PIT and YAW error signals as follows:

1. Locked X-arm, ran dither alignment servos to maximize transmission.
2. Applied an offset to the ASC PIT/YAW filter banks. Set the ramp time to something long, I used 60 seconds.
3. Monitored the X arm transmission while the offset was being ramped, and also the oplev error signal with its current calibration factor.
4. Fit the data, oplev error signal vs arm transmission, with a gaussian, and extracted the scaling factor (i.e. the number which the current Oplev error signals have to be multiplied by for the error signal to correspond to urad of angular misalignment as per the overlap of the beam axis to the cavity axis.
5. Fits are shown in Attachment #1 and #2.
6. I haven't done any error analysis yet, but the open loop OL spectra for the BS now line up better with the other optics, see Attachment #3 (although their calibration factors may need to be updated as well...). Need to double check against OSEM readout during the sweep.
7. New numbers have been SDF-ed.

The numbers are:

BS Pitch     15  /  130    (old/new)     urad/counts

BS Yaw       14  /  170    (old/new)     urad/counts

 Quote: I bet the calibration is out of date; probably we replaced the OL laser for the BS and didn't fix the cal numbers. You can use the fringe contrast of the simple Michelson to calibrate the OLs for the ITMs and BS.

13438   Tue Nov 21 16:00:05 2017 KiraUpdatePEMseismometer can testing

I performed a test with the can last week with one layer of insulation to see how well it worked. First, I soldered two heaters together in series so that the total resistance was 48.6 ohms. I placed the heaters on the sides of the can and secured them. Then I wrapped the sides and top of the can in insulation and sealed the edges with tape, only leavng the handles open. I didn't insulate the bottom. I connected the two ends of the heater directly into the DC source and drove the current as high as possible (around 0.6A). I let the can heat up to a final value of 37.5C, turned off the current and manually measured the temperature, recoding the time every half degree. I then plotted the results, along with a fit. The intersection of the red line with the data marks the time constant and the temperature at which we get the time constant. This came out to be about 1.6 hours, much longer than expected considering that onle one layer instead of four was used. With only one layer, we would expect the time constant to be about 13 min, while for 4 layers it should be 53 min (the area A is 0.74 m^2 and not 2 m^2).

 Quote: I made a model for our seismometer can using actual data so that we know approximately what the time constant should be when we test it out. I used the appendix in Megan Kelley's report to make a relation for the temperature in terms of time. $\frac{dQ}{dt}=mc\frac{dT(t)}{dt}$ so $T(t)=\frac{1}{mc}\int \frac{dQ}{dt}dt=\frac{1}{mc}\int P_{net}dt$ and $P_{net}=P_{in}-P_{out}$ In our case, we will heat the can to a certain temerature and wait for it to cool on its own so $\inline P_{in}=0$ We know that $\inline P_{out}=\frac{kA\Delta T}{d}$ where k is the k-factor of the insulation we are using, A is the area of the surface through which heat is flowing, $\inline \Delta T$ is the change in temperature, d is the thickness of the insulation. Therefore, $T(t)=\frac{1}{mc}\int_{0}^{t}\frac{kA}{d}[T_{lab}-T(t')]dt'=\frac{kA}{mcd}(T_{lab}t-\int_{0}^{t}T(t')dt')$ We can take the derivative of this to get $T'(t)=\frac{kAT_{lab}}{mcd}-\frac{kA}{mcd}T(t)$, or $T'(t)=B-CT(t)$  We can guess the solution to be $T(t)=C_{1}e^{-t/\tau}+C_{2}$ where tau is the time constant, which we would like to find. The boundary conditions are $\inline T(0)=40$ and $\inline T(\infty)=T_{lab}=24$. I assumed we would heat up the can to 40 celcius while the room temp is about 24. Plugging this into our equations, $\inline C_{1}+C_{2}=40, C_{2}=24$, so $\inline C_{1}=16$ We can plug everything back into the derivative T'(t) $T'(t)=-\frac{16}{\tau}e^{-t/\tau}=B-C[16e^{-t/\tau}+24]$ Equating the exponential terms on both sides, we can solve for tau $\frac{16}{\tau}e^{-t/\tau}=16Be^{-t/\tau}, \frac{1}{\tau}=B, \tau=\frac{1}{B}=\frac{mcd}{kA}$ Plugging in the values that we have, m = 12.2 kg, c = 500 J/kg*k (stainless steel), d = 0.1 m, k = 0.26 W/(m^2*K), A = 2 m^2, we get that the time constant is 0.326hr. I have attached the plot that I made using these values. I would expect to see something similar to this when I actually do the test. To set up the experiment, I removed the can (with Steve's help) and will place a few heating pads on the outside and wrap the whole thing in a few layers of insulation to make the total thickness 0.1m. Then, we will attach the heaters to a DC source and heat the can up to 40 celcius. We will wait for it to cool on its own and monitor the temperature to create a plot and find the experimental time constant. Later, we can use the heatng circuit we used for the PSL lab and modify the parts as needed to drive a few amps through the circuit. I calculated that we'd need about 6A to get the can to 50 celcius using the setup we used previously, but we could drive a smaller current by using a higher heater resistance.

13439   Tue Nov 21 16:28:23 2017 gautamUpdateOptical LeversBS OL calibration updated

The numbers I have from the fitting don't agree very well with the OSEM readouts. Attachment #1 shows the Oplev pitch and yaw channels, and also the OSEM ones, while I swept the ASC_PIT offset. The output matrix is the "naive" one of (+1,+1,-1,-1). SUSPIT_IN1 reports ~30urad of motion, while SUSYAW_IN1 reports ~10urad of motion.

From the fits, the BS calibration factors were ~x8 for pitch and x12 for yaw - so according to the Oplev channels, the applied sweep was ~80urad in pitch, and ~7urad in yaw.

Seems like either (i) neither the Oplev channels nor the OSEMs are well diagonalized and that their calibration is off by a factor of ~3 or (ii) there is some significant imbalance in the actuator gains of the BS coils...

 Quote: Need to double check against OSEM readout during the sweep.

13441   Tue Nov 21 23:04:12 2017 gautamUpdateOptical LeversOplev "noise budget"

Per our discussions in the meetings over the last week, I've tried to put together a simple Oplev noise budget. The only two terms in this for now are the dark noise and a model for the seismic noise, and are plotted together with the measured open-loop error signal spectra.

1. Dark noise
• Beam was taken off the OL QPD
• A small DC offset was added to all the oplev segment input filters to make the sum ~20-30 cts [call this testSum] (usually it varies from 4000-13000 for the BS/ITMs, call this nominalSum).
• I downloaded 20mins of dq-ed error signal data, and computed the ASD, dividing by a factor of nominalSum / testSum to account for the usual light intensity on the QPD.
2. Seismic noise
• This is a very simplistic 1/f^2 pendulum TF with a pair of Q=2 poles at 1Hz.
• I adjusted the overall gain such that the 1Hz peak roughly line up in measurement and model.
• The stack isn't modelled at all.

Some remarks:

• The BS oplev doesn't have any whitening electronics, and so has a higher electronics noise floor compared to the ITMs. But it doesn't look like we are limited by this lower noise floor anywhere..
• I wonder what all those high frequency features seen in the ITM error signal spectra are - mechanical resonances of steering optics? It is definitely above the dark noise floor, so I am inclined to believe this is real beam motion on the QPD, but surely this can't be the test-mass motion? If it were, the measured A2L would be much higher than the level it is adjudged to be at now. Perhaps it's some resonances of steering mirrors?
• The seismic displacement @100Hz per the GWINC model is ~1e-19 m/rtHz. Assuming the model A2L = d_rms * theta(f) where d_rms is the rms offset of the beam spot from the optic center, and theta(f) is the angular control signal to the optic, for a 5mm rms offset of the spot from the center, theta(f) must be ~1e-17 urad @100Hz. This gives some requirement on the low pass required - I will look into adding this to the global optimization cost.

13444   Wed Nov 22 05:41:32 2017 ranaUpdateOptical LeversOplev "noise budget"

For the OL NB, probably don't have to fudge any seismic noise, since that's a thing we want to suppress. More important is "what the noise would be if the suspended mirrors were no moving w.r.t. inertial space".

For that, we need to look at the data from the OL test setup that Steve is putting on the SP table.

13446   Wed Nov 22 12:13:15 2017 KiraUpdatePEMseismometer can testing

Updated some values, most importantly, the k-factor. I had assumed that it was in the correct units already, but when converting it to 0.046 W/(m^2*K) from 0.26 BTU/(h*ft^2*F), I got the following plot. The time constant is still a bit larger than what we'd expect, but it's much better with these adjustments.

For our next steps, I will measure the time constant of the heater without any insulation and then decide how many layers of it we will need. I'll need to construct and calibrate a temperature sensor like the ones I've made before and use it to record the values more accurately.

Quote:

I performed a test with the can last week with one layer of insulation to see how well it worked. First, I soldered two heaters together in series so that the total resistance was 48.6 ohms. I placed the heaters on the sides of the can and secured them. Then I wrapped the sides and top of the can in insulation and sealed the edges with tape, only leavng the handles open. I didn't insulate the bottom. I connected the two ends of the heater directly into the DC source and drove the current as high as possible (around 0.6A). I let the can heat up to a final value of 37.5C, turned off the current and manually measured the temperature, recoding the time every half degree. I then plotted the results, along with a fit. The intersection of the red line with the data marks the time constant and the temperature at which we get the time constant. This came out to be about 1.6 hours, much longer than expected considering that onle one layer instead of four was used. With only one layer, we would expect the time constant to be about 13 min, while for 4 layers it should be 53 min (the area A is 0.74 m^2 and not 2 m^2).

 Quote: I made a model for our seismometer can using actual data so that we know approximately what the time constant should be when we test it out. I used the appendix in Megan Kelley's report to make a relation for the temperature in terms of time. $\frac{dQ}{dt}=mc\frac{dT(t)}{dt}$ so $T(t)=\frac{1}{mc}\int \frac{dQ}{dt}dt=\frac{1}{mc}\int P_{net}dt$ and $P_{net}=P_{in}-P_{out}$ In our case, we will heat the can to a certain temerature and wait for it to cool on its own so $\inline P_{in}=0$ We know that $\inline P_{out}=\frac{kA\Delta T}{d}$ where k is the k-factor of the insulation we are using, A is the area of the surface through which heat is flowing, $\inline \Delta T$ is the change in temperature, d is the thickness of the insulation. Therefore, $T(t)=\frac{1}{mc}\int_{0}^{t}\frac{kA}{d}[T_{lab}-T(t')]dt'=\frac{kA}{mcd}(T_{lab}t-\int_{0}^{t}T(t')dt')$ We can take the derivative of this to get $T'(t)=\frac{kAT_{lab}}{mcd}-\frac{kA}{mcd}T(t)$, or $T'(t)=B-CT(t)$  We can guess the solution to be $T(t)=C_{1}e^{-t/\tau}+C_{2}$ where tau is the time constant, which we would like to find. The boundary conditions are $\inline T(0)=40$ and $\inline T(\infty)=T_{lab}=24$. I assumed we would heat up the can to 40 celcius while the room temp is about 24. Plugging this into our equations, $\inline C_{1}+C_{2}=40, C_{2}=24$, so $\inline C_{1}=16$ We can plug everything back into the derivative T'(t) $T'(t)=-\frac{16}{\tau}e^{-t/\tau}=B-C[16e^{-t/\tau}+24]$ Equating the exponential terms on both sides, we can solve for tau $\frac{16}{\tau}e^{-t/\tau}=16Be^{-t/\tau}, \frac{1}{\tau}=B, \tau=\frac{1}{B}=\frac{mcd}{kA}$ Plugging in the values that we have, m = 12.2 kg, c = 500 J/kg*k (stainless steel), d = 0.1 m, k = 0.26 W/(m^2*K), A = 2 m^2, we get that the time constant is 0.326hr. I have attached the plot that I made using these values. I would expect to see something similar to this when I actually do the test. To set up the experiment, I removed the can (with Steve's help) and will place a few heating pads on the outside and wrap the whole thing in a few layers of insulation to make the total thickness 0.1m. Then, we will attach the heaters to a DC source and heat the can up to 40 celcius. We will wait for it to cool on its own and monitor the temperature to create a plot and find the experimental time constant. Later, we can use the heatng circuit we used for the PSL lab and modify the parts as needed to drive a few amps through the circuit. I calculated that we'd need about 6A to get the can to 50 celcius using the setup we used previously, but we could drive a smaller current by using a higher heater resistance.

13447   Wed Nov 22 14:47:03 2017 KiraUpdatePEMseismometer can testing

For the insulation, I have decided to use this one (Buna-N/PVC Foam Insulation Sheets). We will need 3 of the 1 inch plain backing ones (9349K4) to wrap a few layers around it. I'll try two layers for now, since the insulation seems to be doing quite well according to initial testing.

 Quote: Updated some values, most importantly, the k-factor. I had assumed that it was in the correct units already, but when converting it to 0.046 W/(m^2*K) from 0.26 BTU/(h*ft^2*F), I got the following plot. The time constant is still a bit larger than what we'd expect, but it's much better with these adjustments. For our next steps, I will measure the time constant of the heater without any insulation and then decide how many layers of it we will need. I'll need to construct and calibrate a temperature sensor like the ones I've made before and use it to record the values more accurately.

13448   Wed Nov 22 15:29:23 2017 gautamUpdateOptical LeversOplev "noise budget"

[steve, gautam]

What is the best way to set this test up?

I think we need a QPD to monitor the spot rather than a single element PD, to answer this question about the sensor noise. Ideally, we want to shoot the HeNe beam straight at the QPD - but at the very least, we need a lens to size the beam down to the same size as we have for the return beam on the Oplevs. Then there is the power - Steve tells me we should expect ~2mW at the output of these HeNes. Assuming 100kohm transimpedance gain for each quadrant and Si responsivity of 0.4A/W at 632nm, this corresponds to 10V (ADC limit) for 250uW of power - so it would seem that we need to add some attenuating optics in the way.

Also, does anyone know of spare QPDs we can use for this test? We considered temporarily borrowing one of the vertex OL QPDs (mark out its current location on the optics table, and move it over to the SP table), but decided against it as the cabling arrangement would be too complicated. I'd like to use the same DAQ electronics to acquire the data from this test as that would give us the most direct estimate of the sensor noise for supposedly no motion of the spot, although by adding 3 optics between the HeNe and the QPD, we are introducing possible additional jitter couplings...

 Quote: For the OL NB, probably don't have to fudge any seismic noise, since that's a thing we want to suppress. More important is "what the noise would be if the suspended mirrors were no moving w.r.t. inertial space". For that, we need to look at the data from the OL test setup that Steve is putting on the SP table.

13449   Wed Nov 22 16:40:00 2017 KojiUpdateOptical LeversOplev "noise budget"

You may want to consult with the cryo Q people (Brittany, Aaron) for a Si QPD. If you want the same QPD architecture, I can look at my QPD circuit stock.

13450   Wed Nov 22 17:52:25 2017 gautamUpdateOptimal ControlVisualizing cost functions

I've attempted to visualize the various components of the cost function in the way I've defined it for the current iteration of the Oplev optimal control loop design code. For each term in the cost function, the way the cost is computed depends on the ratio of the abscissa value to some threshold value (set by hand for now) - if this ratio is >1, the cost is the logarithm of the ratio, whereas if the ratio is <1, the cost is the square of the ratio. Continuity is enforced at the point at which this transition happens. I've plotted the cost function for some of the terms entering the code right now - indicated in dashed red lines are the approximate value of each of these costs for our current Oplev loop - the weights were chosen so that each of the costs were O(10) for the current controller, and the idea was that the optimizer could drive these down to hopefully O(1), but I've not yet gotten that to happen.

Based on the meeting yesterday, some possible ideas:

1. For minimizing the control noise injection - we know the transfer function from the Oplev control signal coupling to MICH from measurements, and we also have a model for the seismic noise. So one term could be a weighted integral of (coupling - seismic) - the weight can give more importance to f>30Hz, and even more importance to f>100Hz. Right now, I don't have any suc frequency dependant requirement on the control signal.
2. Try a simpler problem first - pendulum local damping. The position damping controller for example has fewer roots in the complex plane. Although it too has some B/R notches, which account for 16 complex roots, and hence, 32 parameters, so maybe this isn't really a simpler problem?
3. How do we pick the number of excess poles compared to zeros in the overall transfer function? The OL loop low-pass filters are elliptic filters, which achieve the fastest transition between the passband and stopband, but for the Oplev loop roll-off, perhaps its better to have a just have some poles to roll off the HF response?
13451   Wed Nov 22 19:20:01 2017 ranaUpdateOptical LeversOplev "noise budget"

too complex; just shoot straight from the HeNe to the QPD. We lower the gain of the QPD by changing the resistors; there's no sane reason to keep the existing 100k resistors for a 2 mW beam. The specular reflection of the QPD must be dumped on a black glass V dump (not some flimsy anodized aluminum or dirty razor stack)

13452   Wed Nov 22 23:56:14 2017 gautamUpdateOptical LeversOplev "noise budget"

## Do not turn on BS/ITMY/SRM/PRM Oplev servos without reading this elog and correcting the needful!

I've setup a test setup on the ITMY Oplev table. Details + pics to follow, but for now, be aware that

1. I've turned off the HeNe that is used for the SRM and ITMY Oplev.
2. Moved one of the HeNe's Steve setup on the SP table to the ITMY Oplev table.
3. Output power was 2.5mW, whereas normal power incident on this PD was ~250uW.
4. So I changed all transimpedance gains on the ITMY Oplev QPD from 100k to 10k thin film - these should be changed back when we want to use this QPD for Oplev purposes again. Note that I did not change the compensation capacitors C3-C6, as with 10k transimpedance, and assuming they are 2.2nF, we get a corner frequency of 6.7kHz. The original schematic recommends 0.1uF. In hindsight, I should have changed these to 22nF to keep roughly the same corner frequency of ~700Hz.
I've implemented this change as of ~5pm Nov 23 2017 - C3-C6 are now 22nF, so the corner frequency is 676Hz, as opposed to 723Hz before... This should also be undone when we use this QPD as an Oplev QPD again...
5. I marked the position of the ITMY Oplev QPD with sharpie and also took pics so it should be easy enough to restore when we are done with this test.
6. I couldn't get the HeNe to turn on with any of the power supplies I found in the cabinet, so I borrowed the one used to power the BS/PRM. So these oplevs are out of commission until this test is done.
7. There is a single steering mirror in a Polaris mount which I used to center the spot on the QPD.
8. The specular reflection (~250uW, i.e. 10% of the power incident on the QPD) is dumped onto a clean razor beam stack. Steve can put in a glass beam dump on Monday.
9. Just in case someone accidentally turns on some servos - I've disabled the inputs to the BS, PRM and SRM oplevs, and set the limiter on the ITMY servo to 0.

Here are some pics of the setup: https://photos.app.goo.gl/DHMINAV7aVgayYcf1.None of the existing Oplev input/output steering optics were touched. Steve can make modifications as necessary, perhaps we can make similar mods to the SRM Oplev QPD and the BS one to run the HeNe test for a few days...

 Quote: too complex; just shoot straight from the HeNe to the QPD. We lower the gain of the QPD by changing the resistors; there's no sane reason to keep the existing 100k resistors for a 2 mW beam. The specular reflection of the QPD must be dumped on a black glass V dump (not some flimsy anodized aluminum or dirty razor stack)

13453   Thu Nov 23 18:03:52 2017 gautamUpdateOptical LeversOplev "noise budget"

Here are a couple of preliminary plots of the noise from a 20minute stretch of data - the new curve is the orange one, labelled sensing, which is the spectrum of the PIT/YAW error signal from the HeNe beam single bounce off a single steering mirror onto the QPD, normalized to account for the difference in QPD sum. The peaky features that were absent in the dark noise are present here.

I am a bit confused about the total sum though - there is ~2.5mW of light incident on the PD, and the transimpedance gain is 10.7kohm. So I would expect 2.5e-3 mW * 0.4A/W * 10.7 kV/A ~ 10.7V over 4 quadrants. The ADC is 16 bit and has a range +/- 10V, so 10.7 V should be ~35,000 cts. But the observed QPD sum is ~14,000 counts. The reflected power was measured to be ~250uW, so ~10% of the total input power. Not sure if this is factored into the photodiode efficiency value of 0.4A/W. I guess there is some fraction of the QPD that doesn't generate any photocurrent (i.e. the grooves defining the quadrants), but is it reasonable that when the Oplev beam is well centered, ~50% of the power is not measured? I couldn't find any sneaky digital gains between the quadrant channels to the sum channel either... But in the Oplev setup, the QPD had ~250uW of power incident on it, and was reporting a sum of ~13,000 counts with a transimpedance gain of 100kohm, so at least the scaling seems to hold...

I guess we wan't to monitor this over a few days, see how stationary the noise profile is etc. I didn't look at the spectrum of the intensity noise during this time.

Quote:

## I've setup a test setup on the ITMY Oplev table. Details + pics to follow, but for now, be aware that

Here are some pics of the setup: https://photos.app.goo.gl/DHMINAV7aVgayYcf1.None of the existing Oplev input/output steering optics were touched. Steve can make modifications as necessary, perhaps we can make similar mods to the SRM Oplev QPD and the BS one to run the HeNe test for a few days...

13454   Sun Nov 26 19:38:40 2017 SteveUpdateVACTP3 drypump replaced again

The TP3 foreline pressure was 4.8 Torr, 50K rpm 0.54A and 31C........Maglev rotation normal 560 Hz.......    IFO pressure 7.2e- 6 Torrit was not effected

V1 closed ......replaced drypump.........V1 opened

IFO 6.9e-6 Torrit at 19:55, TP3fl 18 mT,  50Krpm 0.15A 24C

VM1 is still closed

13455   Tue Nov 28 16:02:32 2017 ranaUpdatePEMseismometer can testing

I've ordered 4 of these from McMaster. Should be delivered to the 40m by noon tomorrow.

 Quote: For the insulation, I have decided to use this one (Buna-N/PVC Foam Insulation Sheets). We will need 3 of the 1 inch plain backing ones (9349K4) to wrap a few layers around it. I'll try two layers for now, since the insulation seems to be doing quite well according to initial testing.

Kira and I also discussed the issiue. It would be good if someone can hunt aroun on the web and get some free samples of non-shedding foam with R~4.

13457   Wed Nov 29 15:33:16 2017 ranaUpdatePSLPMC locking

PMC wasn't locking. Had to power down c1psl. Did burt restore. Still not great.

I think many of the readbacks on the PMC MEDM screen are now bogus and misleading since the PMC RF upgrade that Gautam did awhile ago. We ought to fix the screen and clearly label which readbacks and actuators are no longer valid.

Also, the locking procedure is not so nice. The output V adjust doesn't work anymore with BLANK enabled. Would be good to make an autolocker script if we find a visitor wanting to do something fun.

13459   Thu Nov 30 10:38:39 2017 SteveUpdateVACannuloses are not pumped

Annuloses are not pumped for 30 days, since TP2 failed.  IFO pressure 7e-6 Torr it,  Rga 2.6e-6 Torr

Valve configuration: Vacuum Normal as TP3 is the forepump of Maglev, annuloses are not puped at 1.1 Torr

TP3 50K rpm,  0.15A  24C, foreline pressure 16.1 mTorr

 Quote: The TP3 foreline pressure was 4.8 Torr, 50K rpm 0.54A and 31C........Maglev rotation normal 560 Hz.......    IFO pressure 7.2e- 6 Torrit was not effected V1 closed ......replaced drypump.........V1 opened IFO 6.9e-6 Torrit at 19:55, TP3fl 18 mT,  50Krpm 0.15A 24C VM1 is still closed

13467   Thu Dec 7 16:28:06 2017 KojiUpdateIOOLots of red on the FE status screen

Once the RT machines were back, we launched only the five IOPs. They had bunch of red lights, but we continued to run essential models for the IFO. SOme of the lights were fixed by "global diag reset" and "mxstream restart".

The suspension were damped. We could restore the IMC lock. The locking became OK and the IMC was aligned. The REFL spot came back.

At least, I could confirm that the WFS ASC signals were not transmitted to c1mcs. There must be some disconneted links of IPC.

13471   Wed Dec 13 09:49:23 2017 johannesUpdateASSwiring diagram

I attached a wiring schematic from the slow DAQ to the eurocrate modules. Of these, pins 1-32 (or 1A-16C) and pins 33-64 (17A-32C) are on separate DSub connectors. Therefore the easiest solution is to splice the slow DIO channels into the existing breakouts so we can proceed with the transition. This will still remove a lot of the current cable salad. For the YEND we can start thinking about a more elegant solution (For example a connector on the front panel of the Acromag chassis for the fast DIO) now that the problem is better defined.

13473   Thu Dec 14 00:32:56 2017 johannesUpdateASSAcromag new crate; c1auxex2 configured as gateway server for acromag

This splicing in of fast binary channels we discussed at yesterday's and today's meetings is getting messy with the current chassis. Cleaning up the cable mess was a key point, so I got a 4U height DEEP chassis from Rich and drew up a front panel for a modular approach that we can use at the other 40m locations as well. The front panel will have slots for smaller slot panels to which we can mount the breakout boards as before, so all the wiring that I've done can be transfered to this design. If some new connector standard is required it will be easy to draw a new slot panel from a template, for now I'll make some with two DSub37 and IDC50. Since this chassis is so huge it will have ample space for cross-connects.

I also moved the communication of c1auxex2 with the Acromag units off the martian network, connecting them with a direct cable connection out of the second ethernet port. To test if this works I configured the second ethernet port of c1auxex2 to have the IP address 192.168.114.1 and one of the acromag units to have 192.168.114.11, and initialized an IOC with some test channels. Much to my surprise this actually worked straight out of the box, and the test channels can be accessed from the control room computers without having a direct ethernet link to the acromag modules. huzzah!

Steve: it would be nice to have all plugs- connectors lockable

13474   Thu Dec 14 07:07:09 2017 ranaUpdateIOOLots of red on the FE status screen

I had to key the c1psl crate to get the PMC locking again. Without this, it would still sort of lock, but it was very hard to turn on the loop; it would push itself off the fringe. So probably it was stuck in some state with the gain wrong. Since the RF stuff is now done in a separate electronics chain, I don't think the RF phase can be changed by this. Probably the sliders are just not effective until power cycling.

 Quote: Once the RT machines were back, we launched only the five IOPs. They had bunch of red lights, but we continued to run essential models for the IFO. SOme of the lights were fixed by "global diag reset" and "mxstream restart". The suspension were damped. We could restore the IMC lock. The locking became OK and the IMC was aligned. The REFL spot came back. At least, I could confirm that the WFS ASC signals were not transmitted to c1mcs. There must be some disconneted links of IPC.

I then tried to get the MC WFS back, but running rtcds restart --all would make some of the computers hang. For c1ioo I had to push the reset button on the computer and then did 'rtcds start --all' after it came up. Still missing IPC connections.

I'm going to get in touch with Rolf.

13475   Thu Dec 14 08:59:17 2017 SteveUpdateGeneralwe are here
13477   Thu Dec 14 19:41:00 2017 gautamUpdateCDSCDS recovery, NFS woes

[Koji, Jamie(remote), gautam]

## We locked Y-arm, hand aligned transmission to 1. Some pending problems with ASS model (possibly symptomatic of something more general). Didn't touch Xarm because we don't know what exactly the status of ETMX is.

Problems raised in elogs in the thread of 13474 and also 13436 seem to be solved.

I would make a detailed post with how the problems were fixed, but unfortunately, most of what we did was not scientific/systematic/repeatable. Instead, I note here some general points (Jamie/Koji can addto /correct me):

1. There is a "known" problem with unloading models on c1lsc. Sometimes, running rtcds stop <model> will kill the c1lsc frontend.
2. Sometimes, when one machine on the dolphin network goes down, all 3 go down.
3. The new FB/RCG means that some of the old commands now no longer work. Specifically, instead of telnet fb 8087 followed by shutdown (to fix DC errors) no longer works. Instead, ssh into fb1, and run sudo systemctl restart daqd_*.
4. Timing error on c1sus machine was linked to the mx_stream processes somehow not being automatically started. The "!mxstream restart" button on the CDS overview MEDM screen should run the necessary commands to restart it. However, today, I had to manually run sudo systemctl start mx_stream on c1sus to fix this error. It is a mystery why the automatic startup of this process was disabled in the first place. Jamie has now rectified this problem, so keep an eye out.
5. c1oaf persistently reported DC errors (0x2bad) that couldn't be addressed by running mxstream restart or restarting the daqd processes on FB1. Restarting the model itself (i.e. rtcds restart c1oaf) fixed this issue (though of course I took the risk of having to go into the lab and hard-reboot 3 machines).
6. At some point, we thought we had all the CDS lights green - but at that point, the END FEs crashed, necessitating Koji->EX and Gautam->EY hard reboots. This is a new phenomenon. Note that the vertex machines were unaffected.
7. At some point, all the DC lights on the CDS overview screen went white - at the same time, we couldn't ssh into FB1, although it was responding to ping. After ~2mins, the green lights came back and we were able to connect to FB1. Not sure what to make of this.
8. While trying to run the dither alignment scripts for the Y-arm, we noticed some strange behaviour:
• Even when there was no signal (looking at EPICS channels) at the input of the ASS servos, the output was fluctuating wildly by ~20cts-pp.
• This is not simply an EPICS artefact, as we could see corresponding motion of the suspension on the CCD.
• A possible clue is that when I run the "Start Dither" script from the MEDM screen, I get a bunch of error messages (see Attachment #2).
• Similar error messages show up when running the LSC offset script for example. Seems like there are multiple ports open somehow on the same machine?
• There are no indicator lights on the CDS overview screen suggesting where the problem lies.
• Will continue investigating tomorrow.

Some other general remarks:

1. ETMX watchdog remains shutdown.
2. ITMY and BS oplevs have been hijacked for HeNe RIN / Oplev sensing noise measurement, and so are not enabled.
3. Y arm trans QPD (Thorlabs) has large 60Hz harmonics. These can be mitigated by turning on a 60Hz comb filter, but we should check if this is some kind of ground loop. The feature is much less evident when looking at the TRANS signal on the QPD.

UPDATE 8:20pm:

Koji suggested trying to simply retsart the ASS model to see if that fixes the weird errors shown in Attachment #2. This did the trick. But we are now faced with more confusion - during the restart process, the various indicators on the CDS overview MEDM screen froze up, which is usually symptomatic of the machines being unresponsive and requiring a hard reboot. But we waited for a few minutes, and everything mysteriously came back. Over repeated observations and looking at the dmesg of the frontend, the problem seems to be connected with an unresponsive NFS connection. Jamie had noted sometime ago that the NFS seems unusually slow. How can we fix this problem? Is it feasible to have a dedicated machine that is not FB1 do the NFS serving for the FEs?

13478   Thu Dec 14 23:27:46 2017 johannesUpdateDAQaux chassis design

Made a front and back panel and slot panels for DSub and IDC breakouts. I want to send this out soon, are there any comments? Preferences for color schemes?

13479   Fri Dec 15 00:26:40 2017 johannesUpdateCDSRe: CDS recovery, NFS woes
Quote:

## Didn't touch Xarm because we don't know what exactly the status of ETMX is.

The Xarm is currently in its original state, all cables are connected and c1auxex is hosting the slow channels.

13480   Fri Dec 15 01:53:37 2017 jamieUpdateCDSCDS recovery, NFS woes
 Quote: I would make a detailed post with how the problems were fixed, but unfortunately, most of what we did was not scientific/systematic/repeatable. Instead, I note here some general points (Jamie/Koji can addto /correct me): There is a "known" problem with unloading models on c1lsc. Sometimes, running rtcds stop will kill the c1lsc frontend. Sometimes, when one machine on the dolphin network goes down, all 3 go down. The new FB/RCG means that some of the old commands now no longer work. Specifically, instead of telnet fb 8087 followed by shutdown (to fix DC errors) no longer works. Instead, ssh into fb1, and run sudo systemctl restart daqd_*.

This should still work, but the address has changed.  The daqd was split up into three separate binaries to get around the issue with the monolithic build that we could never figure out.  The address of the data concentrator (DC) (which is the thing that needs to be restarted) is now 8083.

 Quote: UPDATE 8:20pm: Koji suggested trying to simply retsart the ASS model to see if that fixes the weird errors shown in Attachment #2. This did the trick. But we are now faced with more confusion - during the restart process, the various indicators on the CDS overview MEDM screen froze up, which is usually symptomatic of the machines being unresponsive and requiring a hard reboot. But we waited for a few minutes, and everything mysteriously came back. Over repeated observations and looking at the dmesg of the frontend, the problem seems to be connected with an unresponsive NFS connection. Jamie had noted sometime ago that the NFS seems unusually slow. How can we fix this problem? Is it feasible to have a dedicated machine that is not FB1 do the NFS serving for the FEs?

I don't think the problem is fb1.  The fb1 NFS is mostly only used during front end boot.  It's the rtcds mount that's the one that sees all the action, which is being served from chiara.

13481   Fri Dec 15 11:19:11 2017 gautamUpdateCDSCDS recovery, NFS woes

Looking at the dmesg on c1iscex for example, at least part of the problem seems to be associated with FB1 (192.168.113.201, see Attachment #1). The "server" can be unresponsive for O(100) seconds, which is consistent with the duration for which we see the MEDM status lights go blank, and the EPICS records get frozen. Note that the error timestamped ~4000 was from last night, which means there have been at least 2 more instances of this kind of freeze-up overnight.

I don't know if this is symptomatic of some more widespread problem with the 40m networking infrastructure. In any case, all the CDS overview screen lights were green today morning, and MC autolocker seems to have worked fine overnight.

I have also updated the wiki page with the updated daqd restart commands.

Unrelated to this work - Koji fixed up the MC overview screen such that the MC autolocker button is now visible again. The problem seems to do with me migrating some of the c1ioo EPICS channels from the slow machine to the fast system, as a result of which the EPICS variable type changed from "ENUM" to something that was not "ENUM". In any case, the button exists now, and the MC autolocker blinky light is responsive to its state.

 Quote: I don't think the problem is fb1.  The fb1 NFS is mostly only used during front end boot.  It's the rtcds mount that's the one that sees all the action, which is being served from chiara.

13482   Fri Dec 15 17:05:55 2017 gautamUpdatePEMTrillium seismometer DC offset

Yesterday, while we were bringing the CDS system back online, we noticed that the control room wall StripTool traces for the seismic BLRMS signals did not come back to the levels we are used to seeing even after restarting the PEM model. There are no red lights on the CDS overview screen indicative of DAQ problems. Trending the DQ-ed seismometer signals (these are the calibrated (?) seismometer signals, not the BLRMS) over the last 30 days, it looks like

1. On ~1st December, the signals all went to 0 - this is consistent with signals in the other models, I think this is when the DAQ processes crashed.
2. On ~8 December, all the signals picked up a DC offset of a few 100s (counts? or um/s? this number is after a cts2vel calibration filter). I couldn't find anything in the elog on 8 December that may be related to this problem.

I poked around at the electronics rack (1X5/1X6) which houses the 1U interface box for these signals - on its front panel, there is a switch that has selectable positions "UVW" and "XYZ". It is currently set to the latter. I am assuming the former refers to velocities in the xyz directions, and the latter is displacement in these directions. Is this the nominal state? I didn't spend too much time debugging the signal further for now.

13483   Fri Dec 15 18:23:03 2017 ranaUpdatePEMTrillium seismometer DC offset

UVW refers to the 3 internal, orthogonal velocity sensors which are not aligned with the vertical or horizontal directions. XYZ refers to the linear combinations of UVW which correspond to north, east, and up.

13485   Fri Dec 15 19:09:49 2017 gautamUpdateIOOIMC lockloss correlated with PRM alignment?

## Motivation:

To test the hypothesis that the IMC lock duty cycle is affected by the PRM alignment. Rana pointed out today that the input faraday has not been tuned to maximize the output->input isolation in a while, so the idea is that perhaps when the PRM is aligned, some of the reflected light comes back towards the PSL through the Faraday and hence, messes with the IMC lock.

## Methodology:

I've made a simple script - the pseudocode is the following:

• Align PRM
• For the next half hour, look for downward transitions in the EPICS record for MC TRANS > 5000 cts - this is a proxy for an MC lockloss
• At the end of 30 minutes, record number of locklosses in the last 30 minutes
• Misalign PRM, repeat the above 3 bullets

The idea is to keep looping the above over the weekend, so we can expect ~100 datapoints, 50 each for PRM misaligned/aligned. The times at which PRM was aligned/misaligned is also being logged, so we can make some spectrograms of PC drive RMS (for example) with PRM aligned/misaligned. The script lives at /opt/rtcds/caltech/c1/scripts/SUS/FaradayIsolationTest/FaradayIsolCheck.py. Script is being run inside a tmux session on pianosa, hopefully the machine doesn't crash over the weekend and MC1/CDS stays happy.

A more direct measurement of the input Faraday isolation can be made by putting a photodiode in place of the beam dump shown in Attachment #1 (borrowed from this elog). I measured ~100uW of power leaking through this mirror with the PRM misaligned (but IMC locked). I'm not sure what kind of SNR we can expect for a DC measurement, but if we have a chopper handy, we could put a chopper (in the leaked beam just before the PD so as to allow the IMC to be locked) and demodulate at that frequency for a cleaner measurement? This way, we could also measure the contribution from prompt reflections (up to the input side of the Faraday) by simply blocking the beam going into the vacuum. The window itself is wedged so that shouldn't be a big contributor.

13486   Mon Dec 18 16:45:44 2017 gautamUpdateIOOIMC lockloss correlated with PRM alignment?

I stopped the test earlier today morning around 11:30am. The log file is located at /opt/rtcds/caltech/c1/scripts/SUS/FaradayIsolationTest/PRM_stepping.txt. It contains the times at which the PRM was aligned/misaligned for lookback, and also the number of MC unlocks during every 30 minute period that the PRM alignment was toggled. This was computed by:

• continuously reading the current value of the EPICS record for MC Trans.
• comparing its current value to its values 3 seconds ago.
• If there is a downward step in this comparison greater than 5000 counts, increment a counter variable by 1.
• Reset counter at the end of 30 minute period.

I think this method is a pretty reliable proxy, because the MC autolocker certainly takes >3 seconds to re-acquire the lock (it has to run mcdown, wait for the next cavity flash, and run mcup in the meantime).

Preliminary analysis suggests no obvious correlation between MC lock duty cycle and PRM alignment.

I leave further analysis to those who are well versed in the science/art of PRM/IMC statistical correlations.

13487   Mon Dec 18 17:48:09 2017 ranaUpdateComputersrossa: SL7.3 upgrade continues

Following instructions from LLO-CDS fo the rossa upgrade. Last time there were some issues with not being to access the LLO EPEL repos, but this time it seems to be working fine.

After adding font aliases, need to run 'sudo xset fp rehash' to get the new aliases to take hold. Afterwards, am able to use MEDM and sitemap just fine.

But diaggui won't run because of a lib-sasl error. Try 'sudo yum install gds-all'.

diaggui: error while loading shared libraries: libsasl2.so.2: cannot open shared object file: No such file or directory (have contacted LLO CDS admins)

X-windows keeps crashing with SL7 and this big monitor. Followed instructions on the internet to remove the generic 'Nouveau' driver and install the proprietary NVDIA drivers by dropping to run level 3 and runnning some command line hoodoo to modify the X-files. Now I can even put the mouse on the left side of the screen and it doesn't crash.

13488   Mon Dec 18 20:37:18 2017 gautamUpdatePSLPMC MEDM cleanup

There are fewer lies on this screen now. For reference, the details of the electronics modifications made are in this elog.

1. Error and control signals are now in units of nm, the appropriate filter switches have been SDF'ed.
2. I think it's useful to see the control voltage to the PZT in volts as well, so I've made two readbacks available at the control point, one in V and one in nm.
3. Indicated that the on-board LO mon readback, which reads "nan", is no longer meaningful, as the mixer is off the demod board.
4. Indicated that the PMC Trans readback of "0" is because of a dead ADC.
 Quote: I think many of the readbacks on the PMC MEDM screen are now bogus and misleading since the PMC RF upgrade that Gautam did awhile ago. We ought to fix the screen and clearly label which readbacks and actuators are no longer valid.

13492   Tue Dec 26 17:24:24 2017 SteveUpdateGeneralpower outage

There was a power outage.

The IFO pressure is 12.8 mTorr-it and it is not pumped. V1 is still closed. TP1 is not running. The Rga is not powered.

The PSL output shutter is still closed. 2W Innolight turned on and manual beam block placed in its beampath.

3 AC units turned on at room temp 84F

13493   Thu Dec 28 17:22:02 2017 gautamUpdateGeneralpower outage - CDS recovery
1. I had to manually reboot c1lsc, c1sus and c1ioo.
2. I edited the line in /etc/rt.sh (specifically, on FB /diskless/root.jessie/etc/rt.sh) that lists models running on a given frontend, to exclude c1dnn and c1oaf, as these are the models that have been giving us most trouble on startup. After this, I was able to bring back all models on these three machines using rtcds restart --all. The original line in this file has just been commented out, and can be restored whenever we wish to do so.
3. mx_stream processes are showing failed status on all the frontends. As a result, the daqd processes are still not working. Usual debugging methods didn't work.
4. Restored all sus dampings.
5. Slow computers all seem to be responsive, so no action was required there.
6. Burtrestored c1psl to solve the "sticky slider" problem, relocked PMC. I didn't do anything further on the PSL table w.r.t. the manual beam block Steve has placed there till the vacuum situation returns to normal.

@Steve: I noticed that we are down to our final bottle of N2, not sure if it will last till 2 Jan which is presumably when the next delivery will come in. Since V1 is closed and the PSL beam is blocked, perhaps this doesn't matter.

from Steve: there are spare full N2 bottles at the south end outside and inside. I replaced the N2 on Sunday night. So the system should be Ok as is.

I also hard-rebooted megatron and optimus as these were unresponsive to ping.

*Seems like the mx_stream errors were due to the mx process not being started on FB. I could fix this by running sudo systemctl start mx on FB. After which I ran sudo systemctl restart daqd_*. But the DC errors persist - not sure how to fix this. Elogging suggests that "0x4000" errors are connected to timing problems on FB, but restarting the ntp service on FB (which is the suggested fix in said elogs) didn't fix it. Also unsure if mx process is supposed to automatically start on FB at startup.

13495   Tue Jan 2 15:43:35 2018 SteveUpdateVACpumpdown after power outage

 Quote: There was a power outage. The IFO pressure is 12.8 mTorr-it and it is not pumped. V1 is still closed. TP1 is not running. The Rga is not powered. The PSL output shutter is still closed. 2W Innolight turned on and manual beam block placed in its beampath. 3 AC units turned on at room temp 84F

IFO pumped down from 44 mTorr to 9.6e-6 Torr with Maglev  backed with only TP3

Aux drypump  was helping our std drypump during this 1 hour period. TP3 reached 32 C and slowed down 47K rpm

The peak foreline pressure at P2  was ~3 Torr

Hornet cold cathode gauge setting:   research mode, air,

2830 HV  1e-4A  at 9.6e-6 Torr,

[  3110 HV  8e-5A at 7.4e-6 Torr one day later ]

Annuloses are at 2 Torr, not pumped

Valve configuration:  vacuum normal, RGA is still off

PSL shutter is opened automatically. Manual block removed.

End IR lasers and doublers are turned on.

NOTE: Maglev " rotation X " on vacuum medm screen is not working! " C1:Vac-TP1_rot " channel was removed.  Use " NORMAL X " for rotation monitoring.

*We removed this (i.e. rotation) field from the MEDM screen to avoid confusion.

13496   Tue Jan 2 16:24:29 2018 gautamUpdatesafetyProjector periodically shuts itself off

I noticed this behaviour since ~Dec 20th, before the power failure. The bulb itself seems to work fine, but the projector turns itself off after <1 minute after being manually turned on by the power button. AFAIK, there was no changes made to the projector/Zita. Perhaps this is some kind of in-built mechanism that is signalling that the bulb is at the end of its lifetime? It has been ~4.5 months (3240 hours) since the last bulb replacement (according to the little sticker on the back which says the last bulb replacement was on 15 Aug 2017

13497   Tue Jan 2 16:37:26 2018 gautamUpdateOptimal ControlOplev loop tuning

I've made various changes to the optimal loop design approach, but am still not having much success. A summary of changes made:

1. Parametrization of filter - enforcing uniqueness
• Previously, the input to the particle swarm was a vector of root frequencies and associated Q-factors.
• This way of parametrization is not unique - permuting the order of the roots yield the same filter, but particles traversing the high (65) dimensional parameter space may have to go over very expensive regions in order to converge with the global minimum / best performing particle.
• One way around this is to parametrize the filter by the highest pole/zero frequency, and then specifying the remaining roots by the cumulative separation from this highest root. This guarantees that a unique vector input to the particle swarm function specifies a unique filter.
• To avoid negative frequencies, I manually set a particular element of the vector to 0 if the cumulative sum yields a negative frequency. I believe this is how MATLAB's particle swarm implements the "constraints" in the constrained optimization routines.
2. Cost function - I've reformulated this into something that makes more sense to me, but probably can be improved further.
• Term #1 - integral of the area (evaluated with MATLAB's trapz utility) between the in-loop (i.e. suppressed) error signal and the sensing noise spectrum (for the latter, I use the orange curve from this plot). This is a signed number, so that suppression below the sensing noise is penalized. Target value is 1 urad rtHz. One problem I see with this approach is that if we believe the sensing noise measurement, then even at 10mHz, it looks like sensing noise is below the out-of-loop error signal level. So the optimizer doesn't seem to want to make the loop AC coupled.
• Term #2 - stability margin. I'm using this number, which is the distance-of-closest-approach to the point -1 in the Nyquist plot, instead of gain and phase margins, as this yields a more conservative robustness measure. Target value is 0.65.
• Term #3 - A2L contribution of in-loop control signal. This contribution is calculated using measurements of A2L coupling for the DRMI. The actual term that goes into the cost function is the ratio of the area under the in-loop control signal to that under the seismic noise curve above 35Hz. Further, f>100Hz is given 10x the weight of 35Hz<f<100Hz (I've not really played around with this weighting function). The goal is to be as close to the seismic curve as possible, at which point this term becomes 1.
• Terms #4 and #5 - the maximum open loop gain evaluated in a 1Hz wide bin centered around the bounce and roll resonances. The aim is to not exceed -40dB in these bins. Perhaps this needs to be reformulated, as the optimizer seems to be giving this term too much importance - the optimized loops have extremely deep bandstops around the BR resonances.
• To normalize each term, I divide by the "target" value mentioned above, so as to make the various terms comparable.
• Each term in the cost function has two regimes - one where it is rapidly varying close to the desired operating point, and one far away where the cost still increases monotonically, but slower (see Attachment #2).
• A scalar cost function is evaluated by taking a weighted sum of the above terms. The weights are chosen so as to make each term ~10 for the controller currently implemented.
• All of the above are only applicable if the resulting loop is stable - else, a large cost is assigned (exponential of sum of real parts of poles of OLTF).

Attachment #1 shows the outcome of a typical optimization run - so while I am having some more success with this than before, where the PSO algorithm was stalling and terminating before any actual optimization was done, it seems like I need to re-think the cost function yet again...

Attachment #2 shows the current terms entering the cost function, and their "desired" values.

The current version of the code I am using is here: although I may not have inculded some of the data files required to run it, to be fixed...

13498   Wed Jan 3 12:33:16 2018 ranaUpdateOptimal ControlOplev loop tuning

When putting code into git.ligo.org, one way to have automated testing is to use the Gitlab CI. This is an automated 'checker', much like the 'Travis' system used in GitHub. Essentially, you give it a make files which it runs somewhere and your GIT repo web page gets a little 'failed/passing' badge telling you if its working. You can also browse the logs to see in detail what happened. This avoids the 'but it works on my computer!' thing that we usually hear.

 Quote: The current version of the code I am using is here: although I may not have inculded some of the data files required to run it, to be fixed...

13499   Wed Jan 3 15:13:55 2018 SteveUpdateGeneralprojector light bulb replaced

Bulb  is replaced.

 Quote: I noticed this behaviour since ~Dec 20th, before the power failure. The bulb itself seems to work fine, but the projector turns itself off after <1 minute after being manually turned on by the power button. AFAIK, there was no changes made to the projector/Zita. Perhaps this is some kind of in-built mechanism that is signalling that the bulb is at the end of its lifetime? It has been ~4.5 months (3240 hours) since the last bulb replacement (according to the little sticker on the back which says the last bulb replacement was on 15 Aug 2017

13500   Wed Jan 3 16:25:32 2018 awadeUpdateOptimal ControlOplev loop tuning

Another cool feature is client side pre-commit hooks. They can be used to run checks on the local version at the time of commit and refuses to push until the pass/fail exits 0.

Can be the same as the Gitlab CI or just basic code quality checks.  I use them to prevent jupyter notebooks being commited with uncleared cells. It needs to be set up on the user's computer manually and is not automatically cloned with the directory: a script can be included in the repo to do this and run manually on first time clone.

 Quote: When putting code into git.ligo.org, one way to have automated testing is to use the Gitlab CI. This is an automated 'checker', much like the 'Travis' system used in GitHub. Essentially, you give it a make files which it runs somewhere and your GIT repo web page gets a little 'failed/passing' badge telling you if its working. You can also browse the logs to see in detail what happened. This avoids the 'but it works on my computer!' thing that we usually hear.

13501   Wed Jan 3 18:00:46 2018 gautamUpdatePonderSqueezeplan of action

Notes of stuff we discussed @ today's meeting, and afterwards, towards measuring ponderomotive squeezing at the 40m.

1. Displacement noise requirements
• Kevin is going to see if we can measure any kind of squeezing on a short timescale by tuning various parameters.
• Specifically, without requiring crazy ultra low current noise level for the coil driver noise.
2. Investigate how much actuation range we need for lock acquisition and maintaining lock.
• Specifically, for DARM.
• We will measure this by having the arms controlled with ALS in the CARM/DARM basis.
• Build up a noise budget for this, see how significant the laser noise contribution is.
3. RC folding mirrors
• In the present configuration, these are introducing ~2.5% RT loss in the RCs.
• This affects PRG, and on the output side, measurable squeezing.
• We want to see if we can relax the requirements on the RC folding mirrors such that we don't have to spend > 20 k\$.
• Specifically, consider spec'ing the folding mirror coatings to only have HR @1064 nm, and take what we get at 532 nm.
• But still demand tolerances on RoC driven by mode-matching between the RCs and the arm cavities.
4. ALS with Beat Mouth
• Use the fiber coupled light from the ends to make the ALS signals.
• Gautam will update diagram to show the signal chain from end-to-end (i.e. starting at AUX laser, ending at ADC input).
• Make a noise budget for the same - preliminary analysis suggests a sensing noise floor of ~10 mHz/rtHz.

RXA:

• For the ALS-DARM budget the idea is that we can do lock acquisition better, so we don't need to care about the acquisition reqs. i.e. we just need to set the ETM coil driver current range based on the DARM in-lock values.
• To get the coil driver noise to be low enough to detect squeezing we need to use a ~10-15 kOhm series resistor.
• We assume that all DAC and coil driver input noises can be sufficiently filtered.
• We are assuming that we don't change the magnet sizes or the number of coil windings in the OSEMs.
• The noise in the ITMs doesn't matter because we don't use them for any locking activity, so we can easily set the coil driver series resistors to 15 kOhm.
• We will do the bias for the ETMs and ITMs using some HV circuit (not the existing ones on the coil driver boards) and doing the summation after the main coil driver series resistor. This HV bias module needs to handle the ~ (2 V / 400 Ohm) = 5 mA which is now used. This would require (5 mA) x (15 kOhm) = 60+ V drivers.
• IF we can get away with doing the ALS beat note with just red (still using GREEN light from the end laser to lock to the arms from the ends), we will not have any requirements for the 532 nm transmission of any optics in the DRMI area.
• Get some quotes for the new PR/SR mirrors having tight RoC tolerance, high R for 1064, and no spec for 532.
• Check that the 1-way fiber noise for 1064 nm is < 100 mHz/rHz in the 50-1000 Hz band. If its more, explore putting better acoustic foam around the fiber run.
• Improve the mode-matching of the IR beam into the fibers at the ends. We want >80% to reduce the noise do to scattering; we don't really care about the amount of light available in the PSL - this is just to reduce the IR-ALS noise.
13502   Thu Jan 4 12:46:27 2018 gautamUpdateALSFiber ALS assay

Attachment #1 is the updated diagram of the Fiber ALS setup. I've indicated part numbers, power levels (optical and electrical). For the light power levels, numbers in green are for the AUX lasers, numbers in red are for the PSL.

I confirmed that the output of the power splitter is going to the "RF input" and the output of the delay line is going to the "LO input" of the demodulator box. Shouldn't this be the other way around? Unless the labels are misleading and the actual signal routing inside the 1U chassis is correctly done :/

• Mode-matching into the fibers is rather abysmal everywhere.
• In this diagram, only the power levels measured at the lasers and inputs of the fiber couplers are from today's measurements. I just reproduced numbers for inside the beat mouth from elog13254.
• Inside the beat mouth, the PD output actually goes through a 20dB coupler which is included in this diagram for brevity. Both the direct and coupled outputs are available at the front panel of the beat mouth. The latter is meant for diagnostic purposes. The number of -8dBm of beat @30MHz is quoted using the direct output, and not the coupled output.

Still facing some CDS troubles, will start ALS recovery once I address them.

Attachment #2 is the svg file of Attachment #1, which we can update as we improve things. I'll put it on the DCC 40m tree eventually.

13503   Thu Jan 4 14:39:50 2018 gautamUpdateGeneralpower outage - timing error

As mentioned in my previous elog, the CDS overview screen "DC" indicators are all RED (everything else is green). Opening up the displays for individual CPUs, the error message shown is "0x4000", which is indicative of some sort of timing error. Indeed, it seems to me that on the FB machine, the gpstime command shows a gps time that is ~1 second ahead of the times on other FE machines.

Running gpstime on other FE machines throws up an error, saying that it cannot connect to the network to update leap second data. Not sure what this is about...

I double checked the GPS timing module, we had some issues with this in the recent past. But judging by its front panel display, everything seems to be in order...

During handling of the above exception, another exception occurred:

Traceback (most recent call last):   File "/usr/bin/gpstime", line 9, in <module>     load_entry_point('gpstime==0.2', 'console_scripts', 'gpstime')()   File "/usr/lib/python3/dist-packages/pkg_resources.py", line 356, in load_entry_point     return get_distribution(dist).load_entry_point(group, name)   File "/usr/lib/python3/dist-packages/pkg_resources.py", line 2476, in load_entry_point     return ep.load()   File "/usr/lib/python3/dist-packages/pkg_resources.py", line 2190, in load     ['__name__'])   File "/usr/lib/python3/dist-packages/gpstime/__init__.py", line 41, in <module>     LEAPDATA = ietf_leap_seconds.load_leapdata(notify=True)   File "/usr/lib/python3/dist-packages/ietf_leap_seconds.py", line 158, in load_leapdata     fetch_leapfile(leapfile)   File "/usr/lib/python3/dist-packages/ietf_leap_seconds.py", line 115, in fetch_leapfile     r = requests.get(LEAPFILE_IETF)   File "/usr/lib/python3/dist-packages/requests/api.py", line 60, in get     return request('get', url, **kwargs)   File "/usr/lib/python3/dist-packages/requests/api.py", line 49, in request     return session.request(method=method, url=url, **kwargs)   File "/usr/lib/python3/dist-packages/requests/sessions.py", line 457, in request     resp = self.send(prep, **send_kwargs)   File "/usr/lib/python3/dist-packages/requests/sessions.py", line 569, in send     r = adapter.send(request, **kwargs)   File "/usr/lib/python3/dist-packages/requests/adapters.py", line 407, in send     raise ConnectionError(err, request=request) requests.exceptions.ConnectionError: ('Connection aborted.', OSError(101, 'Network is unreachable'))

13506   Fri Jan 5 21:54:28 2018 ranaUpdateGeneralpower outage - timing error

Rolf came here in the morning, but not sure what he did or if Jamie remotely did something. But the screen is green.

13507   Fri Jan 5 22:19:53 2018 gautamUpdateGeneralpower outage - timing error

Just putting the relevant line from email from Rolf which at least identifies the problem here:

Looks like FB time is actually off by 1 year, as your timing system does not get year info.

There still seems to be something funky with the X arm transmission PDs - I can't seem to get the triggering to switch between the QPD and the Thorlabs PD, and the QPD signal seems to be wildly fluctuating by several orders of magnitude from 0.01-100. The c1iscex FE was pulled out, and it seemed to me like someone was doing some cable re-arrangement at the X end.

I will look into this tomorrow.

 Quote: Rolf came here in the morning, but not sure what he did or if Jamie remotely did something. But the screen is green.

13508   Sat Jan 6 05:18:12 2018 KevinUpdatePonderSqueezeDisplacement requirements for short-term squeezing

I have been looking into whether we can observe squeezing on a short timescale. The simulations I show here say that we can get 2 dBvac of squeezing at about 120 Hz using extreme signal recycling.

The parameters used here are

• 100 ppm transmissivity on the folding mirrors giving a PRC gain of 40.
• 10 kΩ series resistance for the ETMs; 15 kΩ series resistance for the ITMs.
• 1 W incident on the back of PRM.
• PD quantum efficiency 0.88.

The first attachment shows the displacement noise. The red curve labeled vacuum is the standard unsqueezed vacuum noise which we need to beat. The second attachment shows the same noise budget as a ratio of the noise sources to the vacuum noise.

This homodyne angle and SRC detuning give about the maximum amount of squeezing. However, there's quite a bit of flexibility and if there are other considerations, such as 100 Hz being too low, we should be able to optimize these angles (even with more pessimistic values of the above parameters) to see at least 0.2 dBvac around 400 Hz.

13509   Sat Jan 6 13:47:32 2018 ranaUpdatePonderSqueezeDisplacement requirements for short-term squeezing
• ought to tune for 210 Hz (in-between powerlines) since 100 Hz is tough to work due to scattering, etc.
• rename DAC - I think what this curve shows is really the coil driver noise. The DAC noise we can always filter out with the dewhitening board; i.e. once we have 1000x attenuation between the DAC and the coil driver input, DAC noise is not dominant.
13510   Sat Jan 6 18:27:37 2018 gautamUpdateGeneralpower outage - IFO recovery

Mostly back to nominal operating conditions now.

1. EX TransMon QPD is not giving any sensible output. Seems like only one quadrant is problematic, see Attachment #1. I blame team EX_Acromag for bumping some cabling somewhere. In any case, I've disabled output of the QPD, and forced the LSC servo to always use the Thorlabs "High Gain" PD for now. Dither alignment servo for X arm does not work so well with this configuration - to be investigated.
2. BS Seismometer (Trillium) is still not giving any sensible output.
• I looked under the can, the little spirit level on the seismometer is well centered.
• I jiggled all the cabling to rule out any obvious loose connections - found none at the seismometer, or at the interface unit (labelled D1002694 on the front panel) in 1X5/1X6.
• All 3 axes are giving outputs with DC values of a few hundred - I guess there could've been some big earthquake in early December which screwed the internal alignment of the sensing mass in the seismometer. I don't know how to fix this.
• Attachment #2 = spectra for the 3 channels. Can't say they look very seismicy . I've assumed the units are in um/sec.
• This is mainly bothering me in the short term because I can't use the angular feedforward on PRC alignment, which is usually quite helpful in DRMI locking.
• But I think the PRM Oplev loop is actually poorly tuned, in which case perhaps the feedforward won't really be necessary once I touch that up.

What I did today (may have missed some minor stuff but I think this is all of it):

1. At EX:
• Toggled power to Thorlabs trans monitoring PD, checked that it was actually powered, squished some cables in the e- rack.
• Removed PDA55 in the green path (put there for EX laser AM/PM measurement). So green beam can now enter the X arm cavity.
• Re-connected ALS cabling.
• Turned on HV supply for EX Green PZT steering mirrors (this has to be done every time there is a power failure).
2. At ITMY table:
• Removed temporary HeNe RIN/ Oplev sensing noise measurement setup. HeNe + 1" vis-coated steering mirror moved to SP table.
• Turned on ITMY/SRM Oplev HeNe.
• Undid changes on ITMY Oplev QPD and returned it to its original position.
• Centered ITMY reflected beam on this QPD.
3. At vertex area
• Looked under Trillium seismometer can - I've left the clamps undone for now while we debug this problem.
• Power-cycled Trillium interface box.
• Touched up PMC alignment.
4. Control room
• Recover IFO alignment using combination of IR and Green beams.
• Single arm locking recovered, dither alignment servos run to maximize arm transmission. Single arm locks holding for hours, that's good.
• The X arm dither alignment isn't working so well, the transmission never quite hits 1 and it undergoes some low frequency (T~30secs) oscillations once the transmission reaches its peak value.
• Had to do the usual ipcrm thing to get dataviewer to run on pianosa.

Next order of business:

1. Recover ALS:
• aim is to replace the vertex area ALS signals derived from 532nm with their 1064nm counterparts.
• Need to touch up end PDH servos, alignment/MM into arms, and into Fibers at ends etc.
• Control the arms (with RMs misaligned) in the CARM/DARM basis using the revised ALS setup.
• Make a noise budget - specifically, we are interested in how much actuation range is required to maintain DARM control in this config.
2. Recover DRMI locking
• Continue NBing.
• Do a statistical study of actuation range required for acquiring and maintaining DRMI locking.
13511   Sat Jan 6 23:25:18 2018 KevinUpdatePonderSqueezeDisplacement requirements for short-term squeezing

 Quote: ought to tune for 210 Hz (in-between powerlines) since 100 Hz is tough to work due to scattering, etc.

We can get 1.1 dBvac at 210 Hz.

The first two attachments are the noise budgets for these optimized angles. The third attachment shows squeezing as a function of homodyne angle and SRC detuning at 210 Hz. To stay below -1 dBvac, the homodyne angle must be kept between 88.5 and 89.7 degrees and the SRC detuning must be kept between -0.04 and 0.03 degrees. This corresponds to fixing the SRC length to within a range of 0.07/360 * 1064 nm = 200 pm.

ELOG V3.1.3-