text:
# Weil norm, Tenney-Weil norm, and TWp interval and tuning space

If p/q is a positive rational number reduced to its lowest terms, then the Weil height is the integer $\max(p, q)$. This is sometimes referred to as the multiplicative Weil height, whereas often it is common to take the logarithm of this quantity, which is called the logarithmic Weil height.

In number theory, this is often just called the "height" of the rational, or sometimes the "classical height" or "naive height", although Gene Smith suggested the use of the term Weil height to differentiate it from the other height functions we use, such as Tenney height.

## Relationship to Kees expressibility

If we first remove all factors of 2 before taking the Weil height, we get an octave-equivalent measure called the Kees height or Kees expressibility, depending on if you are using the multiplicative or logarithmic version.

## Relationship to Tenney height and span

The Weil height has some interesting properties which make it very suitable for use in tuning theory. For starters, we have the following identity:

$\displaystyle \log \max(p, q) = \frac12\log(pq) + \frac12|\log(p/q)|$

On the right hand side of this equation (ignoring the factors of $\frac12$), the first term represents the Tenney height and the second represents the span of the interval. Thus, the Weil height can be thought of as an altered version of the Tenney height which also incorporates the span of an interval into the calculation, so that larger intervals are increased in complexity relative to smaller intervals. The log base in the above equation is arbitrary, but it is conventionally taken to be either base 2, in which case the span will be in octaves, or sometimes base e, in which the units are in nepers, where one neper is about 1731.234 cents.

## Generalized Tenney-Weil height

We can immediately derive a family of "interpolated" complexity measures, intermediate to the Tenney and Weil heights, by changing the coefficients in the right-hand side of the above equation from $\frac12$ to something else.

Although there are several ways to write it, we will simply take a weighted average of the Tenney and Weil height at first, adding a new free parameter $k$. We also note that for the Tenney height to scale properly with the Weil height, we will want to take the logarithm of the square root of $pq$, rather than just the logarithm of $pq$. We get:

$\displaystyle \text{TW}_k(p, q) = (1-k)\log((pq)^{\frac12}) + k\log \max(p,q)$

So that we have, for $k=0$, (half of) the Tenney height and $k=1$, the Weil height. This can be rewritten as

$\text{TW}_k(p, q) = (\frac12 - \frac{k}{2})\log(pq) + k\log \max(p,q)$

And using the previous identity, we get

$\text{TW}_k(p, q) = (\frac12 - \frac{k}{2})\log(pq) + k(\frac12\log(pq) + \frac12|\log(p/q)|)\\ = \text{TW}_k(p, q) = \frac12\log(pq) + \frac{k}{2}|\log(p/q)|$

So that we can see the parameter $k$ also simply measures how much priority we place on the span.

Since we only care about dyads, we can also drop the factor of $\frac12$ to get

$\text{TW}_k(p, q) = \log(pq) + k|\log(p/q)|$

although it is noteworthy that this factor becomes important when looking at generalizations of the Weil norm to larger chords; see Chord complexity.

## Weil and Tenney-Weil interval space

The Tenney height can also be thought of as a norm on monzos. This is a Banach space called Tenney interval space, where the Tenney norm is a type of scaled $L_1$ norm. The logarithmic Weil norm also has the property of being a norm on interval space, as does the entire family of Tenney-Weil norms, and thus we may refer to Weil or Tenney-Weil interval space.

Given some $n$-limit monzo $m$ = [$x_2$ $x_3$ $x_5$ $\ldots$ $x_n$, using the identity above, the Weil norm can be expressed as

$\displaystyle \|m\|_{W_1} = |x_2| \log(2) + |x_3| \log(3) + \ldots + |x_n| \log(n) + |x_2\log(2) + x_3\log(3) + \ldots + x_n\log(n)|$

where $W_1$ refers to the Weil norm (this notation will be explained later below). For the general Tenney-Weil norm, we have

$\displaystyle \|m\|_{TW_{1,k}} = |x_2| \log(2) + |x_3| \log(3) + \ldots + |x_n| \log(n) + k \cdot|x_2\log(2) + x_3\log(3) + \ldots + x_n\log(n)|$

Note that the last term on the right is equal to the span. If we have $k=0$, we get the Tenney norm, and if we have $k=1$, we get the Weil norm.

This can be expressed as a matrix multiplication. We can form the following matrix

$X_{k} = \begin{bmatrix} \log(2) & 0 & 0 & \cdots & 0 \\ 0 & \log(3) & 0 & \cdots & 0 \\ 0 & 0 & \log(5) & \cdots & 0 \\ \vdots & \vdots & \vdots & \ddots & 0 \\ 0 & 0 & 0 & \cdots & \log(n) \\ k\log(2) & k\log(3) & k\log(5) & \cdots & k\log(n) \end{bmatrix}$

Or, if $W$ is the usual monzo-weighting matrix, and $J$ is the JIP, we can think of this as forming the block matrix

$\displaystyle X_{k} = \begin{bmatrix} W \\ \hline k\cdot J \end{bmatrix}$

Then we have the Tenney-Weil norm of our monzo $m$ is simply

$\|m\|_{TW_{1,k}} = \|X_{k} \cdot m\|_1$

This maps every monzo $m$ = [$x_2$ $x_3$ $x_5$ $\ldots$ $x_n$ to the "weighted augmented vector" [$w_2$ $w_3$ $w_5$ $\ldots$ $w_n;$ $k$ $\cdots$ in a one-dimensional-larger space, where the $w_n$ are weighted coordinates, $k$ is the coefficient on the span, and the semicolon is just to make clear where this extra spurious coefficient is. The $L_1$ norm of this augmented vector is the result.

So that even the arbitrary Tenney-Weil norm can be thought of as an $L_1$ norm, although in a vector space expanded by one dimension. This definition can easily be extended to arbitrary subgroup by first embedding the subgroup monzos into the full $n$-limit, and then applying the above.

TODO: add pictures of 2D unit sphere for different values of $k$

## Generalized Weil and Tenney-Weil "$W_p$" and "$TW_{p,k}$" norms

Similarly to the Tenney-Euclidean norm, we can use this to define a variety of generalized "$L_p$-style" norms, some of which are easier to work with than the original Weil norm. To do this, we simply change the above expression from an $L_1$ norm to some other kind of norm. So we get

$\displaystyle \|m\|_{TW_{p,k}} = \left((|x_2| \log(2))^p + (|x_3| \log(3))^p + \ldots + (|x_n| \log(n))^p + (k \cdot|x_2\log(2) + x_3\log(3) + \ldots + x_n\log(n)|)^p \right)^{1/p}$

We can rewrite this simply using our matrix notation as

$\|m\|_{TW_{p,k}} = \|X_{k} \cdot m\|_p$

Where we have simply changed the $p$-norm from 1 to a different value of $p$.

### Weil-Euclidean norm

The special value of $p=2$ is called the Weil-Euclidean or WE norm, analogously to the Tenney-Euclidean or TE norm. We can similarly declare the Tenney-Weil-Euclidean or TWE family of norms for different values of $k$, with the TE and WE norms being special cases.

However, it so happens that our TWE norm is really just a reinvention of the Cangwu norm, although with some difference in scaling with our parameter $k$. Still, it is the same thing, up to a simple change in variables. We will treat these as generally synonymous.

The unit sphere of this norm is an ellipsoid which has been "squished" in monzo space along the axis measuring the span of a comma (this can be visualized as a squishing along the direction of the JIP, but treated as though it were a monzo). As the value of $k$ increases, this sphere is increasingly squished, meaning that larger commas are given a greater norm.

### Kees-Euclidean seminorm

Given the Kees-Euclidean norm, we can quotient out by octaves to arrive at the Kees-Euclidean seminorm. This seminorm can be thought of as a "L2-ified" version of the Kees expressibility, similarly to how the Weil-Euclidean norm is an L2-ified version of the Weil height. With some care in dealing with the divergences, this can be used to compute a Kees-Euclidean tuning which very closely approximates, but is not exactly equal to, the POTE tuning. This unique tuning happens to be identical to the "octaves-constrained" Weil-Euclidean tuning.

## Geometric interpretation and alternative formulation

The Weil norm skews the interval space by way of introducing an extra dimension. If we remove a layer of Tenney weight from the Weil norm, we get the equilateral-Weil norm. The figure shows an equilateral-Weil interval space. As each instance of either prime contributes positively to the extra dimension, the angle θ between two formal primes decreases. The measure cos θ is the cosine similarity between any two formal primes. If the length of each prime is set to unity, and if the contribution factor to the extra dimension is sqrt (s), then the contribution factor to the original dimension is sqrt (1 - s). It can be shown that cos θ = s.

k is the slope of the extra dimension. s and k can be related by

$\displaystyle k = \sqrt {s/(1-s)} \\$

When k = 1, s = 1/2. So we see the Weil norm skews the space to θ = arccos s = 60 degrees.

An alternative formulation which gives identical results in the Euclidean space as above is to skew the space within the dimension through constructing each unit vector that is 60 degrees from all previous unit vectors. Here is an algorithm to do so.

1. Let the first unit vector be x1 = [1.
2. Given the first j-th unit vectors, to find the (j + 1)-th, solve the j + 1 equations of the form
$\displaystyle \vec x_{j + 1} \cdot \vec x_i = \cos (\theta), i = 1, 2, \ldots, j \\ \left\Vert \vec x_{j + 1} \right\Vert_2 = 1$
3. Compose the transformation matrix X as
$\displaystyle X = \begin{bmatrix} \vec x_1 & \vec x_2 & \ldots & \vec x_n \end{bmatrix}$
4. Return X.

The result is without Tenney weighting. For the Tenney-weighted form, multiply it by the Tenney height transformation matrix on the right.

## Dual norms

These norms also induce dual norms on the dual space of vals and tuning maps. In general, the $TW_{p,k}$ norm on any $n$-limit monzo can be given by first embedding it into another vector space augmented with one extra dimension, and then taking the $p$-norm on that space. The free parameter $k$ determines at which angle the $n$-limit is being embedded into this augmented space. The norm on the original space is then induced as a "slice" through this larger space.

To get the "dual $TW_{p,k}$" norm on the space of vals, we first build the dual on this augmented space in the standard fashion; this is just the dual of the $L_p$ norm on the larger space. Then, since the norm on the original space was induced as a subspace of this larger space, the norm on the original dual space of vals will be induced as a quotient space of the dual of this larger space, as a corollary to the Hahn-Banach theorem.

Since we are mapping monzos to these "augmented monzos", which we are doing via the aforementioned matrix multiplication, the dual space of this larger space is made up of "augmented vals" of the form $v_2$ $v_3$ $v_5$ $\ldots$ $v_n;$ $\text{junk}$] where "junk" is an extra junk coefficient that we don't care about, formed as a byproduct of adding the augmented coefficient to monzos. The dual transformation of our matrix maps back from these augmented vals to regular ones, in effect "co-tempering" them to the original vals. We do this simply by multiplying the matrix on the other side, so that instead of mapping from monzos to augmented monzos via $\hat m = X_k \cdot m$, we map from augmented vals to regular vals via $v = \hat v \cdot X_k$.

Every val in our original space corresponds to an entire equivalence class or coset of augmented vals which are in the preimage of this dual transformation. It so happens that two of these augmented vals are in the same equivalence class if they differ by the augmented val $k$ $k$ $k$ $\ldots$ $k;$ $-1$], which is the left nullspace of our $X_k$ above.

So to make this clear, if we want to compute the dual $TW_{p,k}$ norm of some $n$-limit val

$v = \langle v_2 \, v_3 \, v_5 \ldots v_n]$

It so happens that all of the vals in the preimage of this, in our augmented val space, will be of the form

$v = \langle v_2 \, v_3 \, v_5 \ldots v_n;0| + r\cdot \langle k \, k \, k \ldots k;-1]$

Note that $k$ is determined ahead of time as the free parameter we have chosen from our $TW_{p,k}$ norm, so the only free variable we have here is $r$. Then the norm on our original val $v$ is the quotient norm induced on this new space:

$\|v\|_{TW_{p,k}} = \min_r{\|\langle v_2 \, v_3 \, v_5 \ldots v_n;0] + r\cdot \langle k \, k \, k \ldots k;-1]\|_q}$

where $q$ is the $q$-norm such that $\frac1q + \frac1p = 1$ (the standard definition of the dual of the $p$-norm).

Solving the minimization problem, we find the val transformation matrix X in the equilateral-weighted space is of the form

$\displaystyle X = \begin{bmatrix} I - krJ & r\vec j \end{bmatrix}$

where J is the all-ones matrix, and similarly j is the all-ones vector. For the Tenney-weighted space, multiply it by the Tenney weighter on the left.

The special case of the Tenney-Weil-Euclidean or Cangwu norm can be easily computed using the pseudoinverse, and r is given by

$\displaystyle r = k/(nk^2 + 1)$

where n is the dimensionality of the subgroup.


text:
40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 241 of 341 Not logged in
ID Date Author Type Category Subject
13089   Fri Jun 30 11:08:26 2017 jigyasaUpdateCamerasGigE camera at ETMX
With Steve's help in getting the right depth of field for imaging and focusing on the test mass with the new AR coated lens, Gautam's help with locking the arm and trying my hand at adjusting the focus of the camera yesterday, we were able to get some images of the IR beam, with the green shutter on and off at different exposures. Since the CCD is at an angle to the optic, the exposure time had to be increased signifcantly(and varied between 0.08 to 0.5 seconds) to capture bright images.
A few frames without the IR on and with the green shutter closed were captured.
These show the OSEM and the Oplev on the test mass.

Steve's note: AR coated camera lens M5018-SW installed at ~40 degrees
Atm2,  pcicture is taken through dirty window

 Quote: Also the GigE has been wired and conencted to the Martian. Image acquisition is possible with Pylon.

Attachment 1: PicturesETMX.pdf
Attachment 2: dirtyETMXwindow.jpg
13091   Fri Jun 30 15:25:19 2017 jigyasaUpdateCamerasGigE camera at ETMX

All thanks to Steve, we cleaned the view port on the ETMX on which the camera is installed, and with a little fine tuning of the focus of the camera, here's a really good image of the beam spot at 6 and 14 ms.

 Quote: Steve's note: AR coated camera lens M5018-SW installed at ~40 degrees

Attachment 1: Image__2017-06-30__15-10-05.pdf
Attachment 2: 14ms.pdf
13092   Fri Jun 30 16:03:54 2017 jigyasaUpdateCamerasGigE camera at ETMX

Quote:

All thanks to Steve, we cleaned the view port on the ETMX on which the camera is installed, and with a little fine tuning of the focus of the camera, here's a really good image of the beam spot at 6 and 14 ms.

 Quote: Steve's note: AR coated camera lens M5018-SW installed at ~40 degrees

Attachment 1: 14msexposure.png
13098   Thu Jul 6 11:58:28 2017 jigyasaUpdateCamerasHDR images of ETMX

I captured a few images of the beam spot on ETMX at 5ms, 10ms, 14ms, 50ms, 100ms, 500ms, 1000ms exposure and ran them through my python script for HDR images. Here's what I obtained.
The resulting image is an improvement over the highly saturated images at say, 500ms and 1 second exposures.
Additionally, I also included a colormapped version of the image.

Attachment 1: ETMXHDRcolormap.png
Attachment 2: ETMXHDRimage.png
13105   Mon Jul 10 17:13:21 2017 jigyasaUpdateComputer Scripts / ProgramsCapture image without pylon GUI

Over the day, I have been working on a C++ program to interface with Pylon to capture images and reduce dependence on the Pylon GUI. The program uses the Pylon header files along with opencv headers. While ultimately a wrapper in python may be developed for the program, the current C++ program at,

/users/jigyasa/GigEcode/Grab/Grab.cpp when compiled as

g++ -Wl,--enable-new-dtags -Wl,-rpath,/opt/pylon5/lib64 -o Grab Grab.o -L/opt/pylon5/lib64 -Wl,-E -lpylonbase -lpylonutility -lGenApi_gcc_v3_0_Basler_pylon_v5_0 -lGCBase_gcc_v3_0_Basler_pylon_v5_0 pkg-config opencv --cflags --libs

returns an executable file named Grab which can be executed as ./Grab

This captures one image from the camera and displays it, additionally it also displays the gray value of the first pixel.

I am working on adding more utility to the program such as manually adjusting exposure, gain and also on the python wrapper (Cython has been installed locally on Ottavia for the purpose)!

13118   Sat Jul 15 01:28:53 2017 jigyasaUpdateCamerasBRDF Calibrations

This evening, Gautam helped me with setting up the apparatus for calibrating the GigE for BRDF measurements.
The SP table was chosen to set up the experiment and for this reason a few things including a laser and power meter (presumably set up by Steve) had to be moved around.

We initially started by setting up the Crysta laser with its power source (Crysta #2, 150-190 mW 1064 laser) on the SP table. The Ophir power meter was used to measure the laser power. We discovered that the laser was highly unstable as its output on the power meter fluctuated (kind of periodically) between 40 and 150 mW. The beam spot on the beam card also appeared to validate this change in intensity. So we decided to use another 1064 nm laser instead.
Gautam got the LightWave NPro laser from the PSL table and set it up on the SP table and with this laser the output as measured by the same power meter was quite stable.

We manually adjusted the power to around 150 mW. This was followed by setting up the half wave plate(HWP) with the polarizing beam splitter (PBS), which was very gently and precisely done by Gautam, while explaining how to handle the optics to me.
On first installing the PBS, we found that the beam was already quite strongly polarized as there seemed to be zero transmission but a strong reflection.
With the HWP in place, we get a control over the transmitted intensity. The reflected beam is directed to a beam dump.
I have taken down the GigE(+mount) at ETMX and wired a spare PoE injector.
We tried to interface with the camera wirelessly through the wireless network extenders but that seems to render an unstable connection to the GigE so while a single shot works okay, a continuous shot on the GigE didn’t succeed.

The GigE was connected to the Martian via Ethernet cable and images were observed using a continuous shot on the Pylon Viewer App on Paola.

We deliberated over the need of a beam expander, but it has been omitted presently. White printer paper is currently being used to model the Lambertian scatterer. So light scattered off the paper was observed at a distance of about 40 cm from the sample.
While proceeding with the calibrations further tonight, we realized a few challenges.

While the CCD is able to observe the beam spot perfectly well, measuring the actual power with the power meter seems to be tricky. As the scattered power is quite low, we can’t actually see any spot using a beam card and hence can’t really ensure if we are capturing the entire beam spot on the active region of the power meter (placed at a distance of ~40cm from the paper) or if we are losing out on some light, all the while ensuring that the power meter and the CCD are in the same plane.

We tried to think of some ways around that, the description of which will follow. Any ideas would be greatly appreciated.

Thanks a ton for all your patience and help Gautam! :)

More to follow..

13121   Sun Jul 16 11:58:36 2017 jigyasaUpdateCamerasBRDF Calibrations

From what I understood froom my reading, [Large-angle scattered light measurements for quantum-noise filter cavity design studies(Refer https://arxiv.org/abs/1204.2528)], we do the white paper test in order to calibrate for the radiometric response, i.e. the response of the CCD sensor to radiance.‘We convert the image counts measured by the CCD camera into a calibrated measure of scatter. To do this we measure the scattered light from a diffusing sample twice, once with the CCD camera and once with a calibrated power meter. We then compare their readings.’

But thinking about this further, if we assume that the BRDF remains unscaled and estimate the scattered power from the images, we get a calibration factor for the scattered power and the angle dependence of the scattered power!

 Quote: Power meter only needed to measure power going into the paper not out. We use the BRDF of paper to estimate the power going out given the power going in.

13122   Sun Jul 16 12:09:47 2017 jigyasaUpdateCamerasBRDF Calibrations

With this idea in mind, we can now actually take images of the illuminated paper at different scattering angles, assume BRDF is the constant value of (1/pi per steradian),

then scattered power Ps= BRDF * Pi cosθ * Ω, where Pi is the incident power, Ω is the solid angle of the camera and θ is the scattering angle at which measurement is taken. This must also equal the sum of pixel counts divided by the exposure time multiplied by some calibration factor.

From these two equations we can obtain the calibration factor of the CCD. And for further BRDF measurements, scale the pixel count/ exposure by this calibration factor.

Quote:

From what I understood froom my reading, [Large-angle scattered light measurements for quantum-noise filter cavity design studies(Refer https://arxiv.org/abs/1204.2528)], we do the white paper test in order to calibrate for the radiometric response, i.e. the response of the CCD sensor to radiance.‘We convert the image counts measured by the CCD camera into a calibrated measure of scatter. To do this we measure the scattered light from a diffusing sample twice, once with the CCD camera and once with a calibrated power meter. We then compare their readings.’

But thinking about this further, if we assume that the BRDF remains unscaled and estimate the scattered power from the images, we get a calibration factor for the scattered power and the angle dependence of the scattered power!

 Quote: Power meter only needed to measure power going into the paper not out. We use the BRDF of paper to estimate the power going out given the power going in.

4394   Thu Mar 10 01:28:47 2011 joe, jamie, rana, chrisSummaryCDSSimSuspension !

Today was a banner day for Simulated Plants.

Joe and Jamie have been working to get it all happening and this afternoon we started stuffing filters into the plant to make it act like the:

We put in the following features so far:

1. Anti-Imaging filters (these are hacked to be approximate since the real ones are 7570 Hz LP filters and the SimAI only can have filters up to 8192 Hz).
2. Dewhitening filters (copied from the SimDW in the SUS-ETMY screens)
3. Coil Driver transimpedance (1 / 200 Ohms)
4. Magnet-coil force constant (0.016 N/A)
5. Conversion from Coil to DOF Basis
6. All DOFs of the mechanical model are represented as simple harmonic oscillators with Q~100 and f ~ measured free swinging peaks.
7. Signals/Noise can be injected either as force noise on the test mass or as displacement noise at the suspension point.
8. Conversion from DOF to Shadow Sensor basis.
9. Optical Levers (with whitening)

We have also changed the switching logic for the SUS and SimETMs for the shadow sensor whitening. It used to be that either the hardware OR the software whitening was on. Now we have made it like all of the other whitening/antiwhitening in LIGO and the whitening/antiwhitening come on together. Joe and Jamie are going to propagate this to the other SUS. The hardware filter is a 30,100:3 (poles:zeros) whitening filter. The digital filter used to also be 30,100:3 with a DC gain = 1. I've changed the FM1 filter in the XXSEN filter banks into a 3:30 for the ETMY so that it now comes on and just compensates the hardware filter. This change should be propagated to all other SUS and the MEDM screens updated to show the new situation.

After this change, we decided to calibrate the {UL,UR,LL,LR,SD}SEN channels into units of microns. To do this we have made an FM6 filter called 'cts2um' that accounts for the OSEM gain and the ADC conversion factors. These channels are now in units of microns without applying any calibration in the DTT or Dataviewer. The plot below shows the OSEM shadow sensor time series with all damping loops ON and a very rough version of seismic noise being injected in all 6 DOFs (note that the y-axis is microns and the x-axis is seconds).

Next, Jamie is adding the angular calibrations (so that SUSPIT and SUSYAW are in rads) and Chris is making vectift quality seismic noise injectors.

We also need to add coating thermal noise, suspension thermal noise, substrate thermal noise, ADC/DAC noise and a lot of MEDM screen indicators of what state we're in. I myself can't tell from the OSEM time series if its real or Sim.

2624   Mon Feb 22 11:38:05 2010 joe, jenne and steveConfigurationVACvacuum is back to normal

Morning condition: vacuum rack power is still off, no MEDM screen reading.....meaning unknown vacuum pressure.We closed PSL shutter immediately.

Joe restored c1iscepis and Jenne powered up the vac-rack UPS. Now the rest of the vac-rack power were restored from starting at the top to bottom.

P1 was reading 15 mTorr.  We restarted pumps and  set vacuum valve positions. V1 opening required Rob's recipe of elog # 1863 to defeat interlock that

has a non communicating gauge: PTP1

CC1 pressure just reached 1e-6 Torr at VAC NORMAL configuration.

12849   Thu Feb 23 15:48:43 2017 johannesUpdateComputersc1psl un-bootable

Using the PDA520 detector on the AS port I tried to get some better estimates for the round-trip loss in both arms. While setting up the measurement I noticed some strange output on the scope I'm using to measure the amount of reflected light.

The interferometer was aligned using the dither scripts for both arms. Then, ITMY was majorly misaligned in pitch AND yaw such that the PD reading did not change anymore. Thus, only light reflected from the XARM was incident of the AS PD. The scope was showing strange oscillations (Channel 2 is the AS PD signal):

For the measurement we compare the DC level of the reflection with the ETM aligned (and the arm locked) vs a misaligned ETM (only ITM reflection). This ringing could be observed in both states, and was qualitatively reproducible with the other arm. It did not show up in the MC or ARM transmission. I found that changing the pitch of the 'active' ITM (=of the arm under investigation) either way by just a couple of ticks made it go away and settle roughly at the lower bound of the oscillation:

In this configuration the PD output follows the mode cleaner transmission (Channel 3 in the screen caps) quite well, but we can't take the differential measurement like this, because it is impossible to align and lock the arm but them misalign the ITM. Moving the respective other ITM for potential secondary beams did not seem to have an obvious effect, although I do suspect a ghost/secondary beam to be the culprit for this. I moved the PDA520 on the optical table but didn't see a change in the ringing amplitude. I do need to check the PD reflection though.

Obviously it will be hard to determine the arm loss this way, but for now I used the averaging function of the scope to get rid of the ringing. What this gave me was:
(16 +/- 9) ppm losses in the x-arm and (-18+/-8) ppm losses in the y-arm

The negative loss obviously makes little sense, and even the x-arm number seems a little too low to be true. I strongly suspect the ringing is responsible and wanted to investigate this further today, but a problem with c1psl came up that shut down all work on this until it is fixed:

I found the PMC unlocked this morning and c1psl (amongst other slow machines) was unresponsive, so I power-cycled them. All except c1psl came back to normal operation. The PMC transmission, as recorded by c1psl,  shows that it has been down for several days:

Repeated attempts to reset and/or power-cycle it by Gautam and myself could not bring it back. The fail indicator LED of a single daughter card (the DOUT XVME-212) turns off after reboot, all others stay lit. The sysfail LED on the crate is also on, but according to elog 10015 this is 'normal'. I'm following up that post's elog tree to monitor the startup of c1psl through its system console via a serial connection to find out what is wrong.

12851   Thu Feb 23 19:44:48 2017 johannesUpdateComputersc1psl un-bootable

Yes, that was one of the things that I wanted to look into. One thing Gautam and I did that I didn't mention was to reconnect the SRM satellite box and move the optic around a bit, which didn't change anything. Once the c1psl problem is fixed we'll resume with that.

 Quote: The fringes seen on the oscope are mostly likely due to the interference from multiple light beams. If there are laser beams hitting mirrors which are moving, the resultant interference signal could be modulated at several Hertz, if, for example, one of the mirrors had its local damping disabled.

Speaking of which:

Using one of the grey RJ45 to D-Sub cables with an RS232 to USB adapter I was able to capture the startup log of c1psl (using the usb camera windows laptop). I also logged the startup of the "healthy" c1aux, both are attached. c1psl stalls at a point were c1aux starts testing for present vme modules and doesn't continue, however is not strictly hung up, as it still registers to the logger when external login attempts via telnet occur. The telnet client simply reports that the "shell is locked" and exits. It is possible that one of the daughter cards causes this. This seems to happen after iocInit is called by the startup script at /cvs/cds/caltech/target/c1psl/startup.cmd, as it never gets to the next item "coreRelease()". Gautam and I were trying to find out what happends inside iocInit, but it's not clear to us at this point from where it is even called. iocInit.c and compiled binaries exist in several places on the shared drive. However, all belong to R3.14.x epics releases, while the logfile states that the R3.12.2 epics core is used when iocInit is called.

Next we'll interrupt the autoboot procedure and try to work with the machine directly.

Attachment 1: slow_startup_logs.tar.gz
12852   Fri Feb 24 20:38:01 2017 johannesUpdateComputersc1psl boot-stall culprit identified

[Gautam, Johannes]

c1psl finally booted up again, PMC and IMC are locked.

Trying to identify the hickup from the source code was fruitless. However, since the PMCTRANSPD channel acqusition failure occured long before the actual slow machine crashed, and since the hickup in the boot seemed to indicate a problem with daughter module identification, we started removing the DIO and DAQ modules:

1. Started with the ones whose fail LED stayed lit during the boot process: the DIN (XVME-212) and the three DACs (VMIVME4113). No change.
2. Also removed the DOUT (XVME-220) and the two ADCs (VMIVME 3113A and VMIVME3123). It boots just fine and can be telnetted into!
3. Pushed the DIN and the DACs back in. Still boots.
4. Pushed only VMIVME3123 back in. Boot stalls again.
5. Removed VMIVME3123, pushed VMIVME 3113A back in. Boots successfully.
6. Left VMIVME3123 loose in the crate without electrical contact for now.
7. Proceeded to lock PMC and IMC

The particle counter channel should be working again.

• VMIVME3123 is a 16-Bit High-Throughput Analog Input Board, 16 Channels with Simultaneous Sample-and-Hold Inputs
• VMIVME3113A is a Scanning 12-Bit Analog-to-Digital Converter Module with 64 channels

/cvs/cds/caltech/target/c1psl/psl.db lists the following channels for VMIVME3123:

Channels currently in use (and therefore not available in the medm screens):

• C1:PSL-FSS_SLOW_MON
• C1:PSL-PMC_PMCERR
• C1:PSL-FSS_SLOWM
• C1:PSL-FSS_MIXERM
• C1:PSL-FSS_RMTEMP
• C1:PSL-PMC_PMCTRANSPD

Channels not currently in use (?):

• C1:PSL-FSS_MINCOMEAS
• C1:PSL-FSS_RCTRANSPD
• C1:PSL-126MOPA_126MON
• C1:PSL-126MOPA_AMPMON
• C1:PSL-FSS_TIDALINPUT
• C1:PSL-FSS_TIDALSET
• C1:PSL-FSS_RCTEMP
• C1:PSL-PPKTP_TEMP

There are plenty of channels available on the asynchronous ADC, so we could wire the relevant ones there if we done care about the 16 bit synchronous sampling (required for proper functionality?)

Alternatively, we could prioritize the Acromag upgrade on c1psl (DAQ would still be asynchronous, though). The PCBs are coming in next Monday and the front panels on Tuesday.

The (nameless?) Windows 7 laptop that lives near MC2 and is used for the USB microscope was used for interfacing with c1psl. No special drivers were necessary to use the USB to RS232 adapter, and the RJ45 end of the grey homemade DB9 to RJ45 cable was plugged into the top port which is labeled "console 1". I downloaded the program "CoolTerm" from http://freeware.the-meiers.org/#CoolTerm, which is a serial protocol emulator, and it worked out of the box with the adapter. The standard settings fine worked for communicating with c1psl, only a small modification was necessary: in Options>Terminal make sure that "Enter Key Emulation" is set from "CR+LF" to "CR", otherwise each time 'Enter' is pressed it is actually sent twice.

12854   Tue Feb 28 01:28:52 2017 johannesUpdateComputersc1psl un-bootable

It turned out the 'ringing' was caused by the respective other ETM still being aligned. For these reflection measurements both test masses of the other arm need to be misaligned. For the ETM it's sufficient to use the Misalign button in the medm screens, while the ITM has to be manually misaligned to move the reflected beam off the PD.

I did another round of armloss measurements today. I encountered some problems along the way

• Some time today (around 6pm) most of the front end models had crashed and needed to be restarted GV: actually it was only the models on c1lsc that had crashed. I noticed this on Friday too.
• ETMX keeps getting kicked up seemingly randomly. However, it settles fast into it's original position.

General Stuff:

• Oscilloscope should sample both MC power (from MC2 transmitted beam) and AS signal
• Channel data can only be loaded from the scope one channel at a time, so 'stop' scope acquisition and then grab the relevant channels individually
• Averaging needs to be restarted everytime the mirrors are moved triggering stop and run remotely via the http interface scripts does this.

Procedure:

1.     Run LSC Offsets
2.     With the PSL shutter closed measure scope channel dark offsets, then open shutter
3.     Align all four test masses with dithering to make sure the IFO alignment is in a known state
4.     Pick an arm to measure
5.     Turn the other arm's dither alignment off
6.     'Misalign' that arm's ETM using medm screen button
7.     Misalign that arm's ITM manually after disabling its OpLev servos looking at the AS port camera and make sure it doesn't hit the PD anymore.
8.     Disable dithering for primary arm
9.     Record MC and AS time series from (paused) scope
10.     Misalign primary ETM
11.     Repeat scope data recording

Each pair of readings gives the reflected power at the AS port normalized to the IMC stored power:

$\widehat{P}=\frac{P_{AS}-\overline{P}_{AS}^\mathrm{dark}}{P_{MC}-\overline{P}_{MC}^\mathrm{dark}}$

which is then averaged. The loss is calculated from the ratio of reflected power in the locked (L) vs misaligned (M) state from

$\mathcal{L}=\frac{T_1}{4\gamma}\left[1-\frac{\overline{\widehat{P}_L}}{\overline{\widehat{P}_M}} +T_1\right ]-T_2$

Acquiring data this way yielded P_L/P_M=1.00507 +/- 0.00087 for the X arm and P_L/P_M=1.00753 +/- 0.00095 for the Y arm. With $\gamma_x=0.832$ and $\gamma_x=0.875$ (from m1=0.179, m2=0.226 and 91.2% and 86.7% mode matching in X and Y arm, respectively) this yields round trip losses of:

$\mathcal{L}_X=21\pm4\,\mathrm{ppm}$  and  $\mathcal{L}_Y=13\pm4\,\mathrm{ppm}$, which is assuming a generalized 1% error in test mass transmissivities and modulation indices. As we discussed, this seems a little too good to be true, but at least the numbers are not negative.

12869   Mon Mar 6 12:34:30 2017 johannesSummaryASSASS light injection scenarios

What we want from the light source for the AS port light injection:

• Frequency control for locking and maintaining known offset from arm cavity resonances -> see below
• Fast extinguishing light in the IFO -> AOM first order switching

We have four possible laser sources that we can use for the injection of 1064 nm from the back:

• There are ~65 mW of IR power coming from the PSL doubling oven, of which ~2mW are used for the fiber beat box. The remaining light is currently dumped on the PSL table and would be available. It is picked off after the PMC and does not have any of the sidebands.
• There is a ~200 mW Lightwave NPRO on the PSL table that is currently unused.
• Koji said he has a ~500mW NPRO in the OMC lab that has no PZT actuation. I contacted a couple companies about fiber-coupled variable AOM frequency shifters that we can pair with this laser.
• I don't think using the high power beam of the PSL itself is a good idea, especially if we want to map the loss on the optics, because' we'll need it for the dither locking

I think for maximum flexibility it's best to fiber-couple whichever source we choose on the PSL table and then just collimate it out of a fiber on the AS table. This way if we want to add fiber-coupled modulators of any kind it's a plug-and-play modification.

Different frequency control schemes are:

• Modulate sidebands on the light and stabilize directly to the arm, using POX/Y or back-reflection at AS
• Free-space resonant EOM
• Free-space broadband EOM with Rich's resonant amplifier attachment
• Fiber-coupled EOM
• Offset phaselock:
• PSL IR: Transfer mode-cleaner stability
• Can lock arms while measurement in progress, but will have PSL IR light on PDs
• Green from the end;
• Broadly tunable laser frequency and no interference from IR.

Either way we'll need a few things:

• required for PDH locking, optional if we phaselock instead
• AOM
• We have free-space available, looking into fiber-coupled ones with frequency tuning
• Fast switching electronics
• Various fiber stuff
• We have enough to set up the fiber coupling of one light source. I'm starting with the 200 mW NPRO but this is technically interchangable.

I'm working on how to best set this up at the AS port and interfere with normal operation as little as possible. Ideally we use a Faraday just like for squeezed light injection, but this requires some modification of the layout, although nothing that involves mode-matching.

12874   Wed Mar 8 18:18:51 2017 johannesUpdateComputer Scripts / Programsloss script

I started a loss script on Donatella that will scan the beam spot across ETMY, recording the reflected power from the arm via the networked scope at the AS port until later tonight (should be done by 9 pm). ITMX is currently strongly misaligned for this, but can be restored with the saved values. I mostly adapted the mapping scipts for the scope readout but still have to iron out a few kinks, which is why I'm running this test. In particular, I still need to calibrate how much the spot actually moves on the optic and control the ASS demodulation offsets to keep the beam stationary on ITMY.

12879   Thu Mar 9 22:28:11 2017 johannesUpdateComputer Scripts / Programsloss script

loss map script running on Rossa that moves the beam on ETMX. Yarm was misaligned for this, most recent PIT and YAW settings were saved beforehand. This will take until late at night, I estimate 2-3 am.

 Quote: I started a loss script on Donatella that will scan the beam spot across ETMY, recording the reflected power from the arm via the networked scope at the AS port until later tonight (should be done by 9 pm). ITMX is currently strongly misaligned for this, but can be restored with the saved values. I mostly adapted the mapping scipts for the scope readout but still have to iron out a few kinks, which is why I'm running this test. In particular, I still need to calibrate how much the spot actually moves on the optic and control the ASS demodulation offsets to keep the beam stationary on ITMY.

12882   Fri Mar 10 19:48:56 2017 johannesUpdateComputer Scripts / Programsloss script

Loss script running again, on Pianosa this time. Due to an oversight in the code the beam wasn't actually moved across ETMY last night. This time I confirmed that the correct offset value is written as a demodulation parameter to the correct mirror degree of freedom. Script will probably run through the night. Yarm is currently misaligned but previous alignment was saved.

12883   Sat Mar 11 20:11:58 2017 johannesUpdateComputer Scripts / Programsloss script

Yarm script running on Pianosa. Still working on visualization of the ETMX lossmap.

 Quote: Loss script running again, on Pianosa this time. Due to an oversight in the code the beam wasn't actually moved across ETMY last night. This time I confirmed that the correct offset value is written as a demodulation parameter to the correct mirror degree of freedom. Script will probably run through the night. Yarm is currently misaligned but previous alignment was saved.

12938   Mon Apr 10 18:42:09 2017 johannesUpdateCamerasPylon installation warning

It looks like we may not need to use this old Pylon version after all. Gautam and I looked into installing SnapPy with the makefile in scripts/GigE/SnapPy/ that he modified (removed the linkage to paths that don't exist in Pylon 5). Compiling took a while (~10 minutes) but eventually succeeded. The package was installed to /ligo/apps/linux-x86_64/camera/

GV 10pm April 10 2017: We didn't actually try executing an image capture or change some settings using the python utilities, that remains to be done..

12958   Fri Apr 28 22:50:35 2017 johannesUpdateCamerasAttempting to Load Camera Client

You'll likely have to run camera_server.py using the same ini file first before you can use the client. Since the pylon installation is not on the shared drive but only local to optimus at the moment you would have to do it from there. You'll need to add /opt/pylon5/lib64/ to LD_LIBRARY_PATH or it won't find some required libraries. I couldn't start up the server all the way, probably because we need to define some slow EPICS channels before running the server script, as Joe points out in his document T1300202. You'll find instructions how to do that for example in this elog.

 Quote: Using /ligo/apps/linux-x86-64/camera/bin/camera_client.py -c  /opt/rtcds/caltech/c1/scripts/GigE/SnapPy/L1-CAM-MC1.ini, the Python script was able to run without error but didn't show any video feed from the camera in GStreamer. Problem might be in the configuration of the camera in the .ini file.

12965   Wed May 3 16:12:36 2017 johannesConfigurationComputerscatastrophic multiple monitor failures

It seems we lost three monitors basically overnight.

The main (landscape, left) displays of Pianosa, Rossa and Allegra are all broken with the same failure mode:

their backlights failed. Gautam and I confirmed that there is still an image displayed on all three, just incredibly faint. While Allegra hasn't been used much, we can narrow down that Pianosa's and Rossa's monitors must have failed within 5 or 6 hours of each other, last night.

One could say ... they turned to the dark side

Quick edit; There was a functioning Dell 24" monitor next to the iMac that we used as a replacement for Pianosa's primary display. Once the new curved display is paired with Rossa we can use its old display for Donatella or Allegra.

13235   Mon Aug 21 20:11:25 2017 johannesSummaryGeneralLoss measurements plan

There are three methods we (will soon) have available to evaluate the round-trip dissipative losses in the arms that do not suffer from the ITM loss dominance:

• DC reflection method:
• Compare reflected light levels from [ITM only] vs [arm cavity on resonance]
• Basler CCDs:
• Infer large (or small) angle scatter loss with calibrated CCDs
• Reflection ringdowns:
• Need AS port light injection, principle is similar to DC method but better (?)

### DCREFL

The DC method comparing reflectivities has been used in the past and is relatively easy to do. After the recent vacuum troubles the first step should be to re-perform these as CDS permits (needs some ASS functionality and of course the MC to behave). It wouldn't hurt to know the parameters this depends on, aka mode overlap and modulation depths with better certainty. Maybe the SURF scripts for mode-spectroscopy can be applied?

### CCDs

With the new CCD cameras calibrated, pre-vent we can determine the magnitude of the large-angle scatter loss (assuming isotropic scatter) of ETMX and possibly ETMY. Can we look past ETMX/ETMY from the viewports? Then we can probably also look at the small angle scatter of ITMX and ITMY. If not, once we open one of the chambers there's the option of installing mirrors as close as possible to the main beam path. The easiest is probably to look at ITMX, since there is plenty of space in the XEND chamber, and the camera is already installed.

### ASPORT

This requires a lot of up-front work. We decided to use the spare 200mW NPRO. It will be placed on the PSL table and injected into an optical fiber, which terminates on the AS table. The again free space beam there needs to be sort-of mode-matched into the SRC ("sort-of" because mode-spectroscopy). We want to be able to phaselock this secondary beam to the PSL with at least a couple kHz bandwidth and also completely extinguish the beam on time-scales of a few microseconds. We will likely need to purchase a few components that we can salvage from other labs, I'm still going through the inventory and will know more soon (more detailed post to follow). We need to settle for the polarization we want to send in from the back.

## Tentative Schedule (aggressive)

#### Week Aug 21 - Aug 27:

• Update mode-overlap estimates
• Obtain current DC refl estimates
• Spatial profile of auxiliary NPRO
• CCD software prep work

#### Week Aug 28 - Sep 3:

• Re-evaluate modulation indices if necessary
• Optical beat AS Port Auxiliary Laser (ASAL) - PSL
• PLL setup
• CCD large angle prep work

#### Week Sep 4 - Sep 10:

• PLL CDS integration
• Amplitude-modulation preparation
• CCD large angles

#### Week Sep 11 - Sep 17:

• Fiber-injection
• AS table preliminary mode-matching
• CCD small angle prep work

#### Week Sep 18 - Sep 24:

• ASAL amplitude switching
• CCD small angles

#### Week Sep 25 - Oct 1:

• AS port ringdowns

13241   Tue Aug 22 16:56:54 2017 johannesSummaryGeneralAS laser existing components inventory

I surveyed the lab today to see what we may need to buy for the AS laser setup.

## We have:

NPRO 200 mW + Driver

ISOMET Model 1201E: This is a free space AOM I found in the modulator cabinet. It needs to be driven at 40MHz (to be confirmed) with ~6W of electrical power. For a 500 micron beam it can allegedly achieve rise times of '93' [units not specified, could this be nanoseconds?]. I did not find a dedicated driver for it, however there was a 5W minicircuits amplifier ZHL-5W-1 in the RF cabinet and a switch ZSDR-230, which has a typical switch time of 2 microseconds, however I'm not sure how this translates to rise/fall times of the deflected power. It seems we have everything to set this up, so we'll by the end of the week if we can use a combination of these things or if we need to buy additional driver electronics.

New Focus model 4004 broadband phase modulator which is labeled as dusty, and in fact quite dirty when looking through. We should attempt to clean this thing and maybe we can use it here or at the ends.

Probably all the optics we need for the PSL table setup.

## We need:

Beat PD: How about one of these: EOT ET-3000A? I didn't find a broadband PD for the beat with the PSL

Fiber Stuff: coupler & polarization maintaining fiber 20m & collimator. There are a couple options here, which we can discuss in the meeting.

Faraday Isolator: If we want to inject P-polarization. If S is okay we can use a polarizing plate beamsplitter instead.

Possibly some large lenses for mode-matching to IFO (TBD)

13264   Mon Aug 28 23:22:56 2017 johannesUpdatePSLPSL table auxiliary NPRO

I moved the axuiliary NPRO to the PSL table today and started setting up the optics.

The Faraday Isolator was showing a pretty unclean mode at the output so I took the polarizers off to take a look through them, and found that the front polarizer is either out of place or damaged (there is a straight edge visible right in the middle of the aperture, but the way the polarizer is packaged prevents me from inspecting it closer). I proceeded without it but left space so an FI can be added in the future. The same goes for the broadband EOM.

There are two spare AOMs (ISOMET and Intraaction, both resonant at 40MHz) available before we have to resort to the one currently installed in the PSL.

I installed the Intraaction AOM first and looked at the switching speed of its first order diffracted beam using both its commercial driver and a combination of minicircuits components. Both show similar behavior. The fall time of the initial step is ~110ns in both cases, but it doesn't decay rapidly no light but a slower exponential. Need to check the 0 order beam and also the other AOM.

## Mini Circuits Drive

13271   Tue Aug 29 21:36:59 2017 johannesUpdatePSLPSL table auxiliary NPRO
 Quote: there is a large (~1 cm) aperture Pockels cell that Frank Siefert was using for making pulses to damage photo diodes. There is a DEI Pulser unit near the entrance to the QIL in Bridge which can drive it.

I'll look for it tomorrow, but I haven't given up on the AOMs yet. I swapped in the ISOMET modulator today and saw the same behavior, both in 0th and 1st order. The fall time is pretty much identical. Gautam saw no such thing in the PSL AOM using the same photodetector.

### 1st order diffracted       0th order

In the meantime I prepared the fiber mode-matching but realized in the process that I had mixed up some lenses. As a result the beam did not have a waist at the AOM location and thus didn't have the intended size, although I doubt that this would cause the slower decay. I'll fix it tomorrow, along with setting up the fiber injection, beat note with the PSL, and routing the fiber if possible.

13298   Tue Sep 5 23:13:44 2017 johannesUpdatePSLPSL table auxiliary NPRO

I used Gautam's mode measurement of the auxiliary NPRO (w=127.3um, z=82mm) for the spacing of the optics on the PSL table for the fiber injection and light modulation. As mentioned in previous posts, for the time being there is no Faraday isolator and no broadband EOM installed, but they're accounted for in the mode propagation and they have space reserved if desired/required/available.

The coupler used for the injection is a Thorlabs F220APC-1064, which allegedly collimates the beam from the fiber type we use to 2.4mm diameter, which I used as the target for the mode calculations. I coupled the first order diffracted beam to a ~60m fiber, which is a tad long but the only fiber I could locate that was long enough. The coupling efficiency from free-space to fiber is 47.5%, and we can currently get up to 63 mW out of the fiber.

Tomorrow Steve and I are going to pull the fiber through protective tubing and bring it to the AS port. The next step is then characterizing the beam out of the collimator to match it into the interferometer.

As far as the switching itself is concerned: I confirmed that the exponential decay is still present when looking at the fiber output. I located the DEI Pulser unit in the QIL lab, and also found several more AOMs, including a 200MHz Crystal Technologies one, same brand that the PSL has, where the ringdown was not observed. According to past elogs, with good polarizers we can expect an extinction ratio of ~200 from the Pockels cell, which should be fine, but it's going to be tradeoff switching speed <-> extinction (if the alternate AOM doesn't show this ringdown behavior).

Attachment 1: PSL_IR.pdf
Attachment 2: psl_aux_laser.pdf
13299   Wed Sep 6 01:09:11 2017 johannesUpdateComputer Scripts / ProgramsNew set of loss measurements

I stumbled upon a faster way to stream data from the TDS3014 oscilloscopes to disk, which speeds the loss measurements up by a lot:  ftp://sprite.ssl.berkeley.edu/pub/sharris/MAVEN_LPW_Preamp/109_TDS3014B_control/tds3014b.py
This convenient(!) set of scripts contains a function that parses the scope's native binary format, for which the acquisition of 1 screenful of data takes <1s as opposed to ~20s, into readable data. I tested it for a bit and concluded that it does what it actually claims to do, but there's one weirdness: It get's the channel offset wrong. However this doesn't matter in our measurement because we're subtracting the dark level, which sees the same (wrong) offset. Other than that it seems okay.

So I started a new set of armloss measurements, and since the data acquisition is now much faster, I was able to squeeze a set of 20 individual measurements for each arm into ~30 minutes. This is the procedure I follow when I take these measurements for the XARM (symmetric under XARM <-> YARM):

1. Dither-align the interferometer with both arms locked. Freeze outputs when done.
2. Misalign ETMY + ITMY.
3. ITMY needs to be misaligned further. Moving the slider by at least +0.2 is plentiful to not have the other beam interfere with the measurement.
4. Start the script, which does the following:
1. Resume dithering of the XARM
2. Check XARM dither error signal rms with CDS. If they're calm enough, proceed.
3. Freeze dithering
4. Start a new set of averages on the scope, wait T_WAIT (5 seconds)
5. Read data (= ASDC power and MC2 trans) from scope and save
6. Misalign ETMX and wait 5s
7. Read data from scope and save
8. Repeat desired amount of times
5. Close the PSL shutter and measure the PD dark levels

I will write a more comprehensive post describing the data acquisition and processing, let's just look at the results for now: The "uncertainties" reported by the individual measurements are on the order of 1-2 ppm (~1.9 for the XARM, ~1.3 for the YARM). This accounts for fluctuations of the data read from the scope and uncertainties in mode-matching and modulation depths in the EOM. I made histograms for the 20 datapoints taken for each arm: the standard deviation of the spread is a little over 2ppm. We end up with something like:

XARM: 49.3 +/- 2.1 ppm
YARM: 20.3 +/- 2.3 ppm

Attachment 1: XARM_20170905.pdf
Attachment 2: YARM_20170905.pdf
13301   Thu Sep 7 23:09:00 2017 johannesUpdatePSLPSL table auxiliary NPRO

I brought the DEI Pulser unit and a suitable Pockels cell over from Bridge today (I also found an identical Pockels cell already at the 40m on the SP table, now that I knew what to look for).

I also brought the 200MHz AOM (Crystal Technology 3200-1113) along which can achieve rise times of 10 ns(!). Before I start setting up the Pockels cell I wanted to try this different AOM and look at its switching behavior. It asks for a much smaller beam (<65 um diam.) than what's currently in the path to the fiber (500 um diam.), although it's clear aperture is technically big enough (~1mm diam.). So I still tried, and the result was a somewhat elliptical deflected beam, and the slower decay was again visible after switching the RF input.

I was using the big Fluke function generator for the 200MHz seed signal, a Mini Circuits ZASWA-2-50 switch and a Mini Circuits ZHL-5W-1 amplifier. For the last two I moved two power supplies (+/-5V for the switch and +24V for the amplifier) into the PSL enclosure. I started at low seed power on the Fluke, routing the amplified signal into a 20dB attenuator before measuring it with an RF power meter. The AOM saturates at 2.5W (34 dBm), which I determined is achieved with a power setting on the Fluke of -4 dBm. As expected, this AOM performed faster (~80ns fall time) but I again observed the slower decay.

This struck me as weird and I started swapping components other than the AOM, which I probably should have done before. It turned out that it was the PD I was using (the same PDA10CF Gautam had used for his MC ringdown investigations). When I changed it to a PDA10A (Si diode, 150MHz bandwidth) the slow decay vanished! One last round of crappy screenshots:

Rather than proceeding with the Pockels cell, tomorrow I will make the beam in the AOM smaller and hope that that takes care of the ellipticity. If it does: the AOM can theoretically switch on ~10ns timescale, same for the switch (5-15ns typical), and the amplifier is non-resonant and works up to 500MHz, so it shouldn't be a limiting factor either. If this doesn't work out, we can still have ~100ns switching times with the other AOMs.

13306   Mon Sep 11 12:40:32 2017 johannesUpdatePSLPSL table auxiliary NPRO

I changed the PSL table auxiliary laser setup to the 200 MHz AOM and put the light back in the fiber. Coupling efficiency is again ~50%, giving us up to about 75 mW of auxiliary laser light on the AS table. The 90% to 10% fall time of the light power out of the fiber when switched off is 16.5 ns with this AOM on the PDA10A, which will be sufficient for the ringdown measurements.

13307   Mon Sep 11 12:56:40 2017 johannesUpdateComputer Scripts / Programslossmap attempts

I was trying to get a lossmap measurement over the weekend but had some trouble first with the IMC and then with the PMC.

For the IMC: It was a bit too misaligned to catch and maintain lock, but I had a hard time improving the alignment by hand. Fortunately, turning on the WFS quickly once it was locked restored the transmission to nominal levels and made it maintain the lock for longer, but only for several minutes, not enough for a lossmap scan (can take up to an hour). Using the WFS information I manually realigned the IMC, which made locking easier but wouldn't help with staying locked.

For the PMC: The PZT feedback signal had railed and the PMC had been unlocked for 8+ hours. The PMC medm screen controls were generally responsive (I could see the modes on the CCDs changing) but I just couldn't get it locked. c1psl was responding to ping but refusing telnet so I keyed the crate, followed by a burt restore and finally it worked.

After the PMC came back the IMC has already maintained lock for more than an hour, so I'm now running the first lossmap measurements.

13310   Mon Sep 11 23:31:50 2017 johannesUpdateCameraspost-vent camera capture comparison

The latest pre-unintended vent captures of the test mass face cameras were taken on June 2nd, 2017. Only exposures for ITMYF, ETMYF, and ETMXF exist in /users/sensoray/SensorayCaptures/. I took new captures for those three after locking the arms and having the dither-alignment on for 5+ minutes (exposures were taken after turning the dithering off). The capture script is choking on ITMXF, saying the channel can't lock on. Maybe that's why there's also no reference image for it. Capturing QUAD3, which shows ITMXF in the lower right corner, works, but we don't have a capture for reference. I also recorded dark fields after closing the PSL shutter. Naturally, these don't subtract out as well for the three-month old pictures, but it's actually not terrible and qualitatively one can still compare the subtracted images

Visually, ITMYF and ETMYF do not show a dramatic difference between then and now. ETMXF however, does. To get a numerical estimate for the difference in counts, I worked with the subtracted images and placed an aperture about 1.5x the size of the visible beam blob. I summed up the pixel values inside and subtracted the sum of the pixel values of an equally sized area from the upper left corner of the respective image, which looks free of subtraction artifacts and looks qualitatively similar to the background in the central region.

The pixel sum has gone up by about 50% between the exposures. I still have to do the same for the YARM optics but don't expect such a large discrepancy. Unfortunately we're missing those ITMYF expsures...

All pictures are organized in this format:

 Pre-vent exposure Post-vent exposure Pre-vent subtracted Post-vent subtracted

## ETMXF

Attachment 11: ETMXF_pre_sub.bmp
13330   Mon Sep 25 17:56:33 2017 johannesUpdateComputer Scripts / Programstransmitted power during lossmap

I had to do a reboot + burt restore of c1psl today. It was unresponsive and I couldn't get the PMC to lock. I also had to slightly realign the PMC, and the IMC was too misaligned for the autolocker to catch lock. Adjusting it manually, it was predominantly MC1 PIT that was off. The YARM locked on a 10 mode and had to be aligned manually as well.

I left a script running on Donnatella that tilts ETMX and thus moves the beam on ITMX. I'm monitoring the transmitted power to evaluate sane thresholds for the demodulation offsets in a lossmap measurement. The script will return the IFO to normal after it is done and will take <2 hours to complete (no real clue, but there's no way it takes longer than that for ~50 datapoints).

13334   Tue Sep 26 22:11:08 2017 johannesUpdateCameraspost-vent camera capture comparison

I configured the remaining GigE-Camera to work on the 40m network. We currently have 3 operational Basler cameras:

The 120gm's have been assigned the IPs 192.168.113.152  (was already configured) and 192.168.113.153 (freshly configured) and have been labeled accordingly. Note that it was not necessary to connect the out-of-the-box camera directly to a dedicated ethernet adapter whose IP was set manually to 169.254.0.XXX as pointed out in earlier posts - a few seconds after connecting the camera to the control room switch (with PoE adapter to power it) the camera showed up in the configuration software tool which is launched via

/opt/rtcds/caltech/c1/scripts/GigE/pylon5/bin/./IpConfigurator

and can be assigned a corrected, static IP.

We have a plethora of 2" tubes for the lens assembly, but not a great variety of focal lengths for 2" lenses. Present with the camera gear were two f=250 mm and one f=150 mm 2" lenses with a NIR broadband AR coating

To determine the lens positions relativ to the sensor I assumed that the camera we're setting up looks at its test mass from a distance of 1m. Using the two available focal lengths we can look for solutions which have reasonable lens separations <~10cm and suitable magnification. We primarily want to image the central mirror area onto a 1/4" sized sensor, which can be achieved with a magnification of ~1/8.

I chose a lens separation of 6cm, which gives a theoretical magnification of -.12 and a sensor-lens 2 distance of 7.95 cm. I placed the lenses accordingly in the tubes and checked the focusing with Gautam's help:

It's pretty close to what we would expect. We will do the calibration using the auxiliary laser on the PSL table. For this I temporarily routed a fiber from the PSL enclosure to the SP table. Since the main cable hole is sort of cramped it's going in through a gap near the ceiling instead.

Attachment 1: lens_distance.pdf
13348   Mon Oct 2 12:44:45 2017 johannesUpdateCamerasBasler 120gm calibration

Disclaimer: Wrong calibration factors! See https://nodus.ligo.caltech.edu:8081/40m/13391

The two acA640-120gm Basler GigE-Cams have been calibrated. I used the collimated output of a fiber that carried the auxiliary laser light from the PSL table. With a non-polarizing beam splitter some of the light was picked off onto a PD, and I modified the RF amplitude of the AOM drive signal to vary the power coming out of the fiber. The fiber output was directed at a white paper, which was placed 1.06m from the front of the lens tube assembly, which is where the focal plane is. Using the Pylon Viewer App I made sure that the entirety of the beam spot was imaged onto the CCD. Since the camera sensor is 1/4" across, I removed the camera from the lens tube and instead placed the Ophir power meter head at the position of the sensor and measured the power reported versus PD voltage, which turned out to be 1.5 V/uW.

The camera was put back in place and I used the Pypylon package Gautam had stumbled upon to sweep the exposure time from 100us to 10ms at different light power settings including no laser light at all for background subtraction, and rather than keeping the full bitmap data for O(100s) of images I recorded only the quantities

1. Pixel Max
2. Pixel Sum
3. Pixel Mean
4. Pixel Standard Deviation
5. Pixel Median

I performed this procedure for both the 152 and 153 cameras and plotted the pixel sum and the pixel max vs the exposure time. All the exposures were taken at a gain setting of 100, which is the smallest possible setting (out of 100-600). To obtain the calibration factor I use the input power Pin=75nW in the 'safe' region 1ms to 10ms where the pixel sum looks smooth and the CCD is reportedly not saturated.

 Camera IP Calibration Factor CF 192.168.113.152 8.58 W*s 192.168.113.153 7.83 W*s

The incident power can be calculated as Pin =CF*Total(Counts-DarkCounts)/ExposureTime.

Attachment 1: calib_20170930_152.pdf
Attachment 2: calib_20170930_153.pdf
13354   Tue Oct 3 01:58:32 2017 johannesHowToCamerasCCD calibration

Disclaimer: Wrong calibration factors! See https://nodus.ligo.caltech.edu:8081/40m/13391

The factors were indeed enormously off. The correct table reads:

 Camera IP Calibration Factor CF 192.168.113.152 85.8 pW*s 192.168.113.153 78.3 pW*s

I did subtract a 'dark' frame from the images, though not in the sense of your point 1, just an exposure of identical duration with the laser turned off. This was mostly to reduce the effect of residual light, but given similar initial conditions would somewhat compensate for the offset that pre-existing charge and electronics noise put on the pixel values. The white field is of course a difference story.

I wonder how close we can get to a white field by putting a thin piece of paper in front of the camera without lenses and illuminate it from the other side. A problem is of course the coherence if we use a laser source... Or we scrap any sort of screen/paper and illuminate directly with a strongly divergent beam? Then there wouldn't be a specular pattern.

I'm not sure I understand your point about the 1.5V/A. Just to make sure we're talking about the same thing I made a crude drawing:

The PD sees plenty of light at all times, and the 1.5V/uW came from a comparative measurement PD<-->Ophir (which took the place of the CCD) while adjusting the power deflected with the AOM, so it doesn't have immediate connection to the conversion gain of silicon in this case. I can't remember the gain setting of the PD, but I believe it was 0dB, 20dB at most.

Attachment 1: gige_calibration.pdf
13375   Thu Oct 12 01:03:49 2017 johannesHowToCamerasETMX GigE side view

I calculated a better lens solution for the ETMX side view with the simple python script that's attached. The camera is still not as close to the viewport as we would like, and now the front lens is almost all the up to the end of the tube. With a little more playing around there maybe a better way, especially if we expand the repertoire of focal lengths. Using Steve's wonderful camera fixture I put the beam spot in focus. I turned the camera sideways for better use of the field of view, and now the beam spot actually fills the center area of the beam, to the point where we probably don't want more magnification or else we start losing the tails of the Gaussian.

We'll take a serious of images tomorrow, and will have an estimate of the scatter loss by the end of tomorrow.

Attachment 1: IMG_20171011_164549698.jpg
Attachment 2: Image__2017-10-11__16-52-01.png
Attachment 3: GigE_lens_position_helper.py.zip
13389   Wed Oct 18 11:37:58 2017 johannesHowToCamerasETMX GigE side view at 50 deg
 uote: Telescope front lens to wall distance 25 cm,  GigE camera lenght 6 cm and cat6 cable 2cm  Atm3,   Existing short camera  can has 16cm  lenght to lexan guard on viewport. Available 2" od periscope tube lenght is 8cm. The one in use 16 cm long.              Note: we can fabricate a lite cover with tube that would accomodate longer telescope.              Can we calibrate the AR coated M5018-SW and compare it's performance agains the 2" periscope              Look at the Edmond Optics 3" od camera lens with AR Atm1,   Now I can see dust. This is much better. The focus is not right yet. Atm2,   Chamber viewport wiped and image refocused. Actually I was focusing on the dust.

We don't really have to calibrate the lens, just the CCD, which we've done. It's more about knowing the true aperture size to know how much solid angle you're capturing to infer the total amount of scatter. For our custom lens tubes this is the ID of the retaining ring.

The Edmund Optics lens tube looks tempting, but itcomes at a price. Thorlabs sells lens tubes that offer a more flexibility than what we have right now, so I bought a few different ones, and also more 150mm 2" lenses. This will allow for more compact solutions and offer some in-situ focusing ability that doesn't require detaching the lens tube like now. Should be here in a couple of days, then we'll be able to enclose the GigE camera in the viewport can with a similar field of view we have now.

I also bought a collimation package for the AS port fiber stuff so we can move ahead with the ringdown measurements and also mode spectroscopy.

13391   Wed Oct 18 15:26:58 2017 johannesHowToCamerasRevision: CCD calibration

The units were still off in my previous post. Here's the corrected, sanity-checked version:

 Camera IP Calibration Factor 192.168.113.152 85.8 +/- 4.3 pW*μs 192.168.113.153 78.3 +/- 3.9 pW*μs

I estimated the uncertainties based on a linear fit to the data I recorded with 75nW incident on the CCD and assumed a 5% uncertainty in that number. This is just an upper limit, to be safe. I had calibrated the power reading placing the Ophir power meter where the CCD would otherwise be and comparing it to the PD voltage of a picked off beam. In my previous figures the axes were mislabeled, so I reproduce them here:

Using the current camera position I recorded 50 exposures both with and without beam (XARM locked vs PSL shutter closed) and averaged the images to see how much the reading fluctuates. The exposure time was 10 ms, which left the maximum reported pixel value in all exposures below 3800 out of 4096. The gain setting was 100, which is what I used to calibrate the CCDs.

 Counts with XARM locked 2.799 +/- 0.027 x107 Counts with shutter closed 3.220 +/- 0.047 x106 Power on CCD 193.9 +/- 2.2 nW Power scattered into 2π (*) 254 +/- 39 μW ETMX scatter loss (**) 25.4 +/- 3.9 ppm

(*) I calculated the lens positions to focus at a plane 65cm from the front lens. We're pretty close to that, but I can't confirm the actual distance easily, so I assumed a 5cm error on the distance, which is where most of the error is coming from. This is also assuming uniform scatter.

(**) This is assuming 10W of circulating power

Attachment 1: calib_20170930_152.pdf
Attachment 2: calib_20170930_153.pdf
13422   Thu Nov 9 15:33:08 2017 johannesUpdateCDSrevisiting Acromag
 Quote: We probably want to get a dedicated machine that will handle the EPICS channel serving for the Acromag system

http://www.supermicro.com/products/system/1U/5015/SYS-5015A-H.cfm?typ=H

This is the machine that Larry suggested when I asked him for his opinion on a low workload rack-mount unit. It only has an atom processor, but I don't think it needs anything particularly powerful under the hood. He said that we will likely be able to let us borrow one of his for a couple days to see if it's up to the task. The dual ethernet is a nice touch, maybe we can keep the communication between the server and the DAQ units on their separate local network.

13443   Wed Nov 22 00:54:18 2017 johannesOmnistructureComputersSlow DAQ replacement computer progress

I got the the SuperMicro 1U server box from Larry W on Monday and set it up in the CryoLab for initial testing.

The processor is an Intel D525 dual core atom processor with 1.8 GHz (i386 architecture, no 64-bit support). The unit has a 250GB SSD and 4GB RAM.

I installed Debian Jessie on it without any problems and compiled the most recent stable versions of EPICS base (3.15.5), asyn drivers (4-32), and modbus module (2-10-1). EPICS and asyn each took about 10 minutes, and modbus about 1 minute.

I copied the database files and port driver definitions for the cryolab from cryoaux, whose modbus services I suspended, and initialized the EPICS modbus IOC on the SuperMicro machine instead. It's working flawlessly so far, but admittedly the box is not under heavy load in the cryolab, as the framebuilder there is logging only the 16 analog channels.

I have recently worked out some kinks in the port driver and channel definitions, most importantly:

• mosbus IOC initialization is performed automatically by systemd on reboot
• If the IOC crashes or a system reboot is required the Acromag units freeze in their last current state. When the IOC is started a single read operation of all A/D registers is performed and the result taken as the initial value of the corresponding channel, causing no discontinuity in generated voltage EVER (except of course for the rare case when the Acromags themselves have to be restarted)

Aaron and I set 12/4 as a tentative date when we will be ready to attempt a swap. Until then the cabling needs to be finished and a channel database file needs to be prepared.

13458   Wed Nov 29 21:40:30 2017 johannesOmnistructureComputersSlow DAQ replacement computer progress

[Aaron, Johannes]

We configured the AtomServer for the Martian network today. Hostname is c1auxex2, IP is 192.168.113.49. Remote access over SSH is enabled.

There will be 6 acromag units served by c1auxex2.

 Hostname Type IP Address c1auxex-xt1221a 1221 192.168.113.130 c1auxex-xt1221b 1221 192.168.113.131 c1auxex-xt1221c 1221 192.168.113.132 c1auxex-xt1541a 1541 192.168.113.133 c1auxex-xt1541b 1541 192.168.113.134 c1auxex-xt1111a 1111 192.168.113.135

Some hardware to assemble the Acromag box and adapter PCBs are still missing, and the wiring and channel definitions have to be finalized. The port driver initialization instructions and channel definitions are currently locally stored in /home/controls/modbusIOC/ but will eventually be migrated to a shared location, but we need to decide how exactly we want to set up this infrastructure.

• Should the new machines have the same hostnames as the ones they're replacing? For the transition we simply named it c1auxex2.
• Because the communication of the server machine with the DAQ modules is happening over TCP/IP and not some VME backplane bus we could consolidate machines, particularly in the vertex area.
• It would be good to use the fact that these SuperMicro servers have 2+ ethernet ports to separate CDS EPICS traffic from the modbus traffic. That would also keep the 30+ IPs for the Acromag thingies off the Martian host tables.
13463   Mon Dec 4 22:06:07 2017 johannesOmnistructureComputersAcromag XEND progress

I wired up the power distribution, and ethernet cables in the Acromag chassis today. For the time being it's all kind of loose in there but tomorrow the last parts should arrive from McMaster to put everything in its place. I had to unplug some of the wiring that Aaron had already done but labeled everything before I did so. I finalized the IP configuration via USB for all the units, which are now powered through the chassis and active on the network.

I started transcribing the database file ETMXaux.db that is loaded by c1auxex in the format required by the Acromags and made sure that the new c1auxex2 properly functions as a server, which it does.

ToDo-list:

• Need to calibrate the +/- 10V swing of the analog channels via the USB utility, but that requires wiring the channels to the connectors and should probably be done once the unit sits in the rack
• Need to wire power from the Sorensens into the chassis. There are +/- 5V, +/- 15V and +/- 20V present. The Acromags need only +12V-32V, for which I plan to use the +20V, and an excitation voltage for the binary channels, for which I'm going to wire the +5V. Should do this through the fuse rails on the side.
• The current slow binary channels are sinking outputs, same as the XT1111 16-channel module we have. The additional 4 binary outputs of the XT1541 are sourcing, and I'm currently not sure if we can use them with the sos driver and whitening vme boards that get their binary control signals from the slow system.
• Confirm switching of binary channels (haven't used model XT1111 before, but I assume the definitions are identical to XT1121)
• Setup remaining essential EPICS channels and confirm that dimensions are the same (as in both give the same voltage for the same requested value)
• Disconnect DIN cables, attach adapter boards + DSUB cables
• Testing

Quote:

[Aaron, Johannes]

We configured the AtomServer for the Martian network today. Hostname is c1auxex2, IP is 192.168.113.49. Remote access over SSH is enabled.

There will be 6 acromag units served by c1auxex2.

 Hostname Type IP Address c1auxex-xt1221a 1221 192.168.113.130 c1auxex-xt1221b 1221 192.168.113.131 c1auxex-xt1221c 1221 192.168.113.132 c1auxex-xt1541a 1541 192.168.113.133 c1auxex-xt1541b 1541 192.168.113.134 c1auxex-xt1111a 1111 192.168.113.135

Some hardware to assemble the Acromag box and adapter PCBs are still missing, and the wiring and channel definitions have to be finalized. The port driver initialization instructions and channel definitions are currently locally stored in /home/controls/modbusIOC/ but will eventually be migrated to a shared location, but we need to decide how exactly we want to set up this infrastructure.

• Should the new machines have the same hostnames as the ones they're replacing? For the transition we simply named it c1auxex2.
• Because the communication of the server machine with the DAQ modules is happening over TCP/IP and not some VME backplane bus we could consolidate machines, particularly in the vertex area.
• It would be good to use the fact that these SuperMicro servers have 2+ ethernet ports to separate CDS EPICS traffic from the modbus traffic. That would also keep the 30+ IPs for the Acromag thingies off the Martian host tables.
13464   Thu Dec 7 11:14:37 2017 johannesHowToComputer Scripts / ProgramsLots of red on the FE status screen

Since we're getting ready to put the replacement slow DAQ for c1auxex in I wanted to bring the IFO back to operating condition after the PMC hasn't been locked for days. Something seems wrong with the CDS system though, many of the frontent models have red background and don't seem to be responsive. I followed the instructions laid out in https://wiki-40m.ligo.caltech.edu/Computer_Restart_Procedures.

In the attached screenshot, initially all c1ioo models were red, and on c1iscex only c1x01 was blue, the other ones red. I was able to ssh into both machines and tried to restart indivitual models, which didn't work and instead turned their background white. Still following the wiki page, I restarted both machines but they don't respond to pinging anymore and thus I cannot use ssh to reach them. Not sure what to do, I also rebooted fb over telnet.

So far I couldn't find any records of how to fix this situation.

Attachment 1: 22.png
13466   Thu Dec 7 15:46:31 2017 johannesHowToComputer Scripts / ProgramsLots of red on the FE status screen

[Koji, Johannes]

The issue was partially fixed and the interferometer is in workable condition now.

What -probably- fixed it was restarting the dhcp server on chiara

sudo service isc-dhcp-server restart

Afterwards the frontends were restarted one by one. SSH access was possible and the essential models for IFO operation were started.

c1iscex reported initially that no DAQ card was found, and inside the IO chassis the LED indicator strip was red. Turning off the machine, checking the cables and rebooting fixed this.

Attachment 1: 04.png
13468   Thu Dec 7 22:24:04 2017 johannesOmnistructureComputersAcromag XEND progress

 Quote: Need to calibrate the +/- 10V swing of the analog channels via the USB utility, but that requires wiring the channels to the connectors and should probably be done once the unit sits in the rack Need to wire power from the Sorensens into the chassis. There are +/- 5V, +/- 15V and +/- 20V present. The Acromags need only +12V-32V, for which I plan to use the +20V, and an excitation voltage for the binary channels, for which I'm going to wire the +5V. Should do this through the fuse rails on the side. The current slow binary channels are sinking outputs, same as the XT1111 16-channel module we have. The additional 4 binary outputs of the XT1541 are sourcing, and I'm currently not sure if we can use them with the sos driver and whitening vme boards that get their binary control signals from the slow system. Confirm switching of binary channels (haven't used model XT1111 before, but I assume the definitions are identical to XT1121) Setup remaining essential EPICS channels and confirm that dimensions are the same (as in both give the same voltage for the same requested value) Disconnect DIN cables, attach adapter boards + DSUB cables Testing

Getting the chassis ready took a little longer than anticipated, mostly because I had not looked into the channel list myself before and forgot about Lydia's post which mentions that some of the switching controls have to be moved from the fast to the slow DAQ. We would need a total of 5+5+4+8=22 binary outputs. With the existing Acromag units we have 16 sinking outputs and 8 sourcing outputs. I looked through all the Eurocrate modules and confirmed that they all use the same switch topology which has sourcing inputs.

While one can use a pull-down resistor to control a sourcing input with a sourcing output,

pulling down the MAX333A input (datasheet says logic low is <0.8V) requires something like 100 Ohms for the pull down resistor, which would require ~150mA of current PER CHANNEL, which is unreasonable. Instead, I asked Steve to buy a second XT1111 and modified the chassis to accomodate more Acromag units.

I have now finished wiring the chassis (except for 8 remaining bypass controls to the whitening board which need the second XT1111), calibrated all channels in use, confirmed all pin locations via the existing breakout boards and DCC drawings for the eurocrate modules, and today Steve and I added more fuses to the DIN rail power distribution for +20V and +15V.

There was not enough contingent free space in the XEND rack to mount the chassis, so for now I placed it next to it.

c1auxex2 is currently hosting all original physical c1auxex channels (not yet calc records) under their original name with an _XT added at the end to avoid duplicate channel names. c1auxex is still in control of ETMX. All EPICS channels hosted by c1auxex2 are in dimensions of Volts. The plan for tomorrow is to take c1auxex off the grid, rename the c1auxex2 hosted channels and transfer ETMX controls to it, provided we can find enough 37pin DSub cables (8). I made 5 adapter boards for the 5 Eurocrate modules that need to talk to the slow DAQ through their backplane connector.

13469   Fri Dec 8 12:06:59 2017 johannesOmnistructureComputersc1auxex2 ready - but need more cables

The new slow machine c1auxex2 is ready to deploy. Unfortunately we don't have enough 37pin DSub cables to connect all channels. In fact, we need a total of 8, and I found only three male-male cables and one gender changer. I asked Steve to buy more.

Over the past week I have transferred all EPICS records - soft channels and physical ones - from c1auxex to c1auxex2, making changes where needed. Today I started the in-situ testing

1. Unplugged ETMX's satellite box
2. Unplugged the eurocrate backplane DIN cables from the SOS Driver and QPD Whitening filter modules (the ones that receive ao channels)
3. Measured output voltages on the relevant pins for comparison after the swap
4. Turned off c1auxex by key, removed ethernet cable
5. Started the modbus ioc on c1auxex2
6. Slow machine indicator channels came online, ETMX Watchdog was responsive (but didn't have anything to do due to missing inputs) and reporting. PIT/YAW sliders function as expected
7. Restoring the previous settings gives output voltages close to the previous values, in fact the exact values requested (due to fresh calibration)
8. Last step is to go live with c1auxex2 and confirm the remaining channels work as expected.

I copied the relevant files to start the modbus server to /cvs/cds/caltech/target/c1auxex2, although kept local copies in /home/controls/modbusIOC/ from which they're still run.

I wonder what's the best practice for this. Probably to store the database files centrally and load them over the network on server start?

13470   Fri Dec 8 23:31:31 2017 johannesFrogsASSc1ass slow channel offloading scripts with small

While staring at epics records all day I noticed something about the PIT/YAW offset sliders and ASS offset offloading to slow channels scripts that I'm not sure others are aware off, so I'll briefly discuss it in this post.

The PIT and YAW sliders directly control soft channels that are hosted on the slow machine. Secondary epics records disentangle them for the individual coils:

• UL = PIT+YAW
• LL = -PIT+YAW
• UR = PIT-YAW
• LR = -PIT-YAW

These channels are the direct input for the physical output channels that generate the control voltage.

The fast channels for PIT and YAW have a numerical correction factor built in that accounts for differences between the OSEMs, but the slow channels don't. This means that the slow PIT/YAW controls are not entirely orthogonal but have crosstalk on the order of 10 percent. This in itself is not that dramatic, however the offload offsets scripts for the dither alignment use the fast PIT/YAW values as inputs, which represent the necessary adjustments to the OSEMs only after the individual correction factors have been applied. The offloading to slow knows nothing of this calibration difference between the OSEMs. The result is that there is a ~10 percent of the offset correction error on the mirror alignment AFTER offloading. This will of course converge after a few iterations, but in any case it is recommendable to run the dither alignment again after offloading and not offload the new offsets to the fast channels.

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.

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

Attachment 1: fp_mod_4U.pdf
Attachment 2: IMG_20171213_171541850_HDR.jpg
ELOG V3.1.3-

format: plain


text:
## 统计代写|回归分析作业代写Regression Analysis代考|AH7722

2022年7月18日

couryes-lab™ 为您的留学生涯保驾护航 在代写回归分析Regression Analysis方面已经树立了自己的口碑, 保证靠谱, 高质且原创的统计Statistics代写服务。我们的专家在代写回归分析Regression Analysis代写方面经验极为丰富，各种代写回归分析Regression Analysis相关的作业也就用不着说。

• Statistical Inference 统计推断
• Statistical Computing 统计计算
• (Generalized) Linear Models 广义线性模型
• Statistical Machine Learning 统计机器学习
• Longitudinal Data Analysis 纵向数据分析
• Foundations of Data Science 数据科学基础
couryes™为您提供可以保分的包课服务

## 统计代写|回归分析作业代写Regression Analysis代考|The p-Value

In the example above, the thresholds to determine which real $T$ values are explainable by chance alone are the numbers that put $95 \%$ of the $T$ values that are explained by chance alone between them; these are $-1.9845$ and $+1.9845$ in the case of the $T_{98}$ distribution. If the observed $T$ statistic falls outside that range, then we can say that the difference between $\hat{\beta}_{1}$ and 0 is not easily explained by chance alone.

See Figure $3.7$ again. Notice that there is $5 \%$ total probability outside the $\pm 1.9845$ range, simply because there is $95 \%$ probability inside the range. Now, if the $T$ statistic falls inside the $95 \%$ range, then there has to be more than $5 \%$ total probability outside the $\pm T$ range. See Figure $3.7$ again, and suppose $T=1.7$, which is inside the range. Then there has to be more than $5 \%$ probability outside the $\pm 1.7$ range, right? See Figure $3.7$ again, and locate $\pm 1.7$ on the graph. Make sure you understand this; it is not hard at all. Do not just read the words, because then you will not understand. Instead, look at Figure 3.7, put your finger on the graph at $1.7$, and think about the area outside the $\pm 1.7$ range. It is more than $0.05$, do you see?

Now, suppose $T=2.5$, and look at Figure $3.7$ again. Then there has to be less than $5 \%$ probability outside the $\pm 2.5$ range, right? See Figure $3.7$ again, and locate $\pm 2.5$ on the graph. Make sure you understand this; it is not hard at all. Look at the graph! Do not just read the words! Instead, put your finger on the graph at $2.5$ and think about the area outside the $\pm 2.5$ range. It is less than $0.05$, do you see?

## 统计代写|回归分析作业代写Regression Analysis代考|Evaluating Assumptions

As shown in Chapter 1 , the linearity assumption in regression is almost always false, to one degree or another, when there are more than two levels of the $X$ variable. The constant variance assumption and normality assumptions are also almost always false, to one degree or another. Independence is often violated as well. When violated, these assumptions can make the results of the analyses dubious: The model does not represent reality very well, estimates are biased, and confidence intervals, prediction intervals, and $p$-values do not behave as expected.

Nevertheless, the goal of evaluating model assumptions in statistics is not to prove that the assumptions of the model are true. You may as well try to prove that $1+1=3$ ! Rather, the goal is to assess degree of violation of the assumptions. If the assumptions of your chosen model are not too badly violated, then your model represents reality reasonably well, it is usable for making predictions, and the inferential techniques behave approximately as expected (e.g., $\approx 95 \%$ confidence, $\approx 5 \%$ significance level). If the assumptions of your chosen model are badly violated, then you should choose a different model. You can most easily answer the question, “how badly violated must the assumptions be before I must choose a different model?” by using simulation, where you simulate data with violated assumptions, and see how well the estimates and inferences work when you use different models.

Since researchers often think that assumptions refer to the data, let us be clear and emphatic.

# 回归分析代写

## 有限元方法代写

tatistics-lab作为专业的留学生服务机构，多年来已为美国、英国、加拿大、澳洲等留学热门地的学生提供专业的学术服务，包括但不限于Essay代写，Assignment代写，Dissertation代写，Report代写，小组作业代写，Proposal代写，Paper代写，Presentation代写，计算机作业代写，论文修改和润色，网课代做，exam代考等等。写作范围涵盖高中，本科，研究生等海外留学全阶段，辐射金融，经济学，会计学，审计学，管理学等全球99%专业科目。写作团队既有专业英语母语作者，也有海外名校硕博留学生，每位写作老师都拥有过硬的语言能力，专业的学科背景和学术写作经验。我们承诺100%原创，100%专业，100%准时，100%满意。

## MATLAB代写

MATLAB 是一种用于技术计算的高性能语言。它将计算、可视化和编程集成在一个易于使用的环境中，其中问题和解决方案以熟悉的数学符号表示。典型用途包括：数学和计算算法开发建模、仿真和原型制作数据分析、探索和可视化科学和工程图形应用程序开发，包括图形用户界面构建MATLAB 是一个交互式系统，其基本数据元素是一个不需要维度的数组。这使您可以解决许多技术计算问题，尤其是那些具有矩阵和向量公式的问题，而只需用 C 或 Fortran 等标量非交互式语言编写程序所需的时间的一小部分。MATLAB 名称代表矩阵实验室。MATLAB 最初的编写目的是提供对由 LINPACK 和 EISPACK 项目开发的矩阵软件的轻松访问，这两个项目共同代表了矩阵计算软件的最新技术。MATLAB 经过多年的发展，得到了许多用户的投入。在大学环境中，它是数学、工程和科学入门和高级课程的标准教学工具。在工业领域，MATLAB 是高效研究、开发和分析的首选工具。MATLAB 具有一系列称为工具箱的特定于应用程序的解决方案。对于大多数 MATLAB 用户来说非常重要，工具箱允许您学习应用专业技术。工具箱是 MATLAB 函数（M 文件）的综合集合，可扩展 MATLAB 环境以解决特定类别的问题。可用工具箱的领域包括信号处理、控制系统、神经网络、模糊逻辑、小波、仿真等。


text:
# When should an answer be given as opposed to just giving a hint

It's my impression that on this site (and https://math.stackexchange.com/) that many times questions aren't answered but just hints in the comments are given. (This is different on https://mathematica.stackexchange.com where unless it's obvious a homework problem or self-study a detailed answer is many times given.)

If my impression is not wrong, are there guidelines as to when to give hints as opposed to detailed answers? If my impression is wrong, I'd like to hear about that, too.

• I am not gonna give a full answer but just leave a comment. I believe that in statistics it may also play a role that it is not always possible to give a conclusive answer but people still want to provide comments. After all, how many statisticians does it require to change a light bulb? It's many. May 13 at 14:32
• @Sextus I thought the answer to that joke was "it depends." ;-)
– whuber Mod
May 17 at 17:39
• @whuber, I thought the answer was 3, one to change the light bulb and two to comment on it. But sure, statisticians might criticise this number. Anyways, it is more than one. May 17 at 19:05
• @Sextus Be quantitative! One answer is $2.32 \pm 0.59.$
– whuber Mod
May 17 at 19:19
• "Anyways, it is more than one" Actually, a statistician might approximate it with a normal curve and state something like $1.32 \pm 0.59$, including less than one. May 17 at 19:55

When it's not a homework-type question, a full answer is merited. People nevertheless sometimes leave hints in comments: I can't presume to speak for anyone else, but when I do that it's usually because I can't answer properly (or find a suitable duplicate) owing to lack of some combination of time, brains, & interest; yet hope that the hint will help someone else to. From time-to-time it's also a factor that I feel the O.P. will find it satisfying to arrive at the answer for themself, given a nudge in the right direction (as with homework-type questions).

I don't know why the practice should be more prevalent on some sites than others. Perhaps on sites with higher answer rates, people assume hints are otiose—an answer's likely to come along anyway. Perhaps on some it's more the case that you know the answer or you don't, & if you do it's not much trouble to write it out.

• (ctd) -- so comments are needed to encourage more detail or focus. Occasionally the discussion in comments is as or even more interesting than any answer.... May 13 at 11:36

There's no particular need to use the commenting feature. You can use comments or the answer field. The issue is that if the post is a homework-type question (people will sometimes say it's not homework), then our policy is to provide hints to help the OP figure it out for themselves. Once they've figured it out, you can post a final, complete answer. This only applies to homework-type questions, though. Our homework policies are listed here; you can peruse out meta.CV threads regarding the policies by clicking on the tag; you can see examples of how I've dealt with such questions here and here.

• Sometimes answers are converted into comments when the answers are not substantial enough. So there is some basis for a need to use the commenting feature instead of the answer field. (I would agree if one would counter with an argument that often these conversions are made when the answer field is abbused by somebody to place a comment, but at least sometimes these conversions occur because some answer is considered as not enough answer). May 13 at 14:59
• I occasionally convert poor answers to comments to protect the respondent from suffering from too much downvoting ;-). The moral of this is that even when you post an answer in the form of a hint, you ought to be sure it's a well-founded one!
– whuber Mod
May 17 at 17:41

When should an answer be given as opposed to just giving a hint

As often as possible, regardless of the question. Up to the readers to make the most of it. A few reasons: "homework-type questions" may very well appear outside a classroom, humans are lifelong learners and some students like myself learn faster with full answers.

• Homework-type questions needn't of course be homework (in fact we tag them with 'self-study'). But they are all exercises; homework or not, the point's to practise by completing them rather than to obtain the solution. When a student's stuck the best help's the least needed to enable them to complete the exercise for themself. May 21 at 12:14
• @Scortchi-ReinstateMonica disagreed. homework-type questions" may very well appear outside a classroom, so the hints will waste my time when I run into the same issue. Also, some students like myself learn faster with full answers. May 21 at 12:24
• Our policy does allow for providing fuller solutions when appropriate: "In the spirit of creating a resource, you may come back after a suitable amount of time and edit your response to include more details, if the question seems like such information will have lasting value." In most cases, though, it would be pointless - & tedious. May 21 at 19:35
• @Scortchi-ReinstateMonica thanks, I vote to amend it to "you may write the entire answer". The "after a suitable amount of time" is what I dislike as a student: not my learning style, as if I wait then I'll likely forget my chain of thoughts and why I got stuck. Also answers shouldn't be written with the OP in mind, but any reader. May 22 at 0:28
• Your chain of thoughts & why you got stuck ought to be documented in the question. The suggested delay here is so as not to facilitate students' cribbing. May 22 at 7:18