6/16: LIGO Orientation; First Weekly Meeting; 40m tour with Jenne; Removed WFS Box Upper Panel, Inserted Cable, Reinstalled panel

6/17: Read Chapter 1 of Control Systems Book; LIGO Safety Meeting; Koji's Talk about PDH Techniques, Fabry-Perot Cavities, and Sensing/Control; Meeting w/ Nancy and Koji

6/18: LIGO Talk Part II; Glossed over "LASERS" book; Read Control Systems Book Chapter 2; Literary Discussion Circle

6/21: Modecleaner Matrix Discussion with Nancy; Suggested Strategy: construct row-by-row with perturbations to each d.f. --> Leads to some questions on how to experimentally do this.

6/22: Learned Simulink; Learned some Terminal from Joe and Jenne; LIGO Meeting; Rana's Talk; Christian's Talk; Simulink Intro Tutorial

6/23 (morning): Simulink Controls Tutorial; Successfully got a preliminary feedback loop working (hooray for small accomplishments!)

Outlook for the Upcoming Week:

Tutorials (in order of priority): Finish Simulink Tutorials, Work through COMSOL Tutorials

Reading (in order of priority): Jenne's SURF Paper, Controls Book, COMSOL documentation, Lasers by Siegman.

Work: Primarily COMSOL-related and pre-discussed with Rana

7/1: 4th draft and final drafts of Progress Report; submitted to SFP

7/5: Began working through busbar COMSOL example

7/6: LIGO meeting and lecture; meeting with Koji and Steve to find drawing of stacks; read through Giaime's thesis, Chapter 2 as well as two other relevant papers.

7/7: Continued working on busbar in COMSOL; should finish this as well as get good headway on stack design by the end of the day.

Single layer of stack successfully modeled in COMSOL. I'm working on trying to add Viton springs now and extend it to a full stack. Having some difficulty with finding consistent parameters to work with.

For the last week, I have been attempting to determine the mirror stack transfer function which relates mechanical mirror response to a given ground-motion drive. The idea is to model the stacks in COMSOL and ultimately apply mechanical tests for manual calculation.

Procuring the correct drawings to base my 3D models off of was no simple task. There are two binders full of a random assortment of drawings, and some of them are associated with the smaller chambers, while others are appropriate for the main chamber, which is what we're interested in right now. For future workers, I suggest checking that your drawings are appropriate for the task at hand with other people before wasting time beginning the painstaking process of CAD design in COMSOL.

The drawings that I ultimately decided to use are attached below. They detail four layers of stacks, each which arrange 15, 12, 8, and 5 (going from bottom to top) Viton damping springs in an orderly fashion. The numbers have been chosen to keep the load per spring as constant as possible, in order for all springs to oscillate with as close a resonant frequency to each other as possible.

After making some minor simplifications, I have finished modeling the top stack:

After triangular meshing, before my many failed attempts at mechanical testing:

Both the Viton and steel portions have been given their material properties, and so I should be (theoretically ) ready to perform some eigenfrequency calculations on this simplified system. If my predictions are correct, these eigenfrequencies shouldn’t be too far of the eigenfrequencies of the 4-layer stacked system, because of the layout of the springs. I’ve tried doing mechanical tests on the top stack alone, but there hasn’t been much progress yet on this end, mostly because of some boundary value exceptions that COMSOL keeps throwing at me.

In the next couple weeks or so, I plan to extend this model to combine all four layers into one completed stack, along with a simple steel base and mirror platform. I also plan to figure out how to make eigenfrequency and transfer function measurements.

Lastly, to anyone who is experienced with COMSOL, I am facing two major roadblocks and could really use your help:

1) How to import one model into another, merge models together, or copy and paste the same model over and over.

2) Understanding and debugging run-time errors during mechanical testing.

If you have any idea how to attack either of these issues, please talk to me! Thanks!

Eigenfrequency analysis has been successfully completed in COMSOL on both a tutorial camshaft, as well as a homemade metal bar.

Upon increasing in complexity to the busbar, I once again began getting into run time errors and increased lag. It seems that this is due to undefined eigenvalues when solving the linear matrices. I tried many boundary values as well as initial conditions in case this was the issue, but it was not. There seems to be some sort of an internal inconsistency. This is no longer a matter of tweaking parameters.

Next steps:

1) Try using the same techniques on the actual mirror stacks to see if we get lucky.

2) In the likely case that this doesn't happen, continue the debugging process. If necessary, a good deal of time may need to be spent learning the COMSOL lower-level jargon.

Via reconfiguration of Viton parameters (previously posted), I managed to debug the COMSOL run time errors and null pointer exceptions. Listed are the resultant eigenfrequencies obtained through structural analysis testing. For all tests, the bottom of the Viton springs are constrained from motion, and all other parts are free to oscillate. Notice that color variations signify displacement from the equilibrium position. Also note that different initial conditions produce different eigenmodes:

No initial displacement:

0.01 m x-displacement:

0.01 m y-displacement:

0.01 m z-displacement:

Clearly, the plate has its first harmonic between 210-215 Hz, which is much greater than seismic noises (which never exceed the 10-Hz range). This suggests a highly attenuating transfer function. Since the remaining three plates have been designed to resonate similarly, it is likely that the entire stack system will also function very well.

Next steps:

1) Extend the eigenfrequency analysis to obtain a transfer function for the single-plate system

2) Expand the CAD model to include all four stack layers, and perhaps a base

My previous eigenfrequency analysis was incorrect by two orders of magnitude due to the misuse of Young's Modulus information for Viton. After editing this parameter (as documented on 7/14 19:00), the eigenmodes became much more reasonable. I also discovered the Deformation option under the Surface Plotting Options, which makes the eigenmodes of the single stack much more apparant.

Attached are pictures of the first four eigenmodes:

I experimentally determined the spring constant of a single Vitol spring in order to obtain a rough estimate for the natural frequency of single-stack oscillation.

The procedure basically involved stacking metal bars of known mass onto the Vitol and using a caliper to measure deviations from the equilibrium length.

The plot below shows that, for small compressions, the response is linear to an R-squared of 0.98.

The experimental spring constant came out to be about 270 lb/ft, or 3900 N/m.

Previous documents have listed that the top stack takes on a load of approximately 43 kg. per individual spring. A bit of calculation yields an experimental resonant frequency of 9.5 Hz.

Compared with the theoretical COMSOL first harmonic of about 7.5 Hz, there is a reasonable amount of error. Of course, I used this calculation as a simple ballpark estimate: errors from misplacement onto the Viton were minimized through use of a level, but were still inevitable on the mm scale. Since the two methods yield answers with the same order of magnitude, we are ready to move forward and build the remaining layers of the stack.

Expanding on the single-layer model, I added the second, third, and fourth layers to the stack in COMSOL. Eigenfrequency analysis run times increased exponentially as the model multiplied in complexity. The following images document the some of the important eigenfrequencies:

First Eigenmode: y-translational, 3.34 Hz:

Second Eigenmode: x-translational, 3.39 Hz:

Third Eigenmode: z-rotational, 3.88 Hz:

Sixth Eigenmode: z-translational, 8.55 Hz:

As expected, the eigenfrequencies are generally lower, but still in the same range, as the single-layer model, because of greater mass but constant weight-per-spring distribution.

Next Steps:

1) Extend a single stack to the full stack system, which consists of three stacks like this. Perform similar eigenmode analysis.

2) Analyze the mirror suspension system and incorporate a similar pendulum on the top plate.

3) Make transfer function measurements between seismic and mirror motions.

Some clarification is warranted regarding the different shapes of stacks. Corrections are appreciated:

1) The single-leg stack that I just completed should function as a working model for the IO, OO, and MC1/3. Rana commented, however, that the current dimensions are slightly off for MC1/3 (which makes sense since I could only find drawings for the IOC). If anyone knows the whereabouts of similar drawings for MC1/3, I'd much appreciate it.

2) A triple-leg stack can model the BS, ITMX, and ITMY chambers. I don't have exact dimensions for these, but I can make decent approximations from to-scale stack drawings. I'll probably work on a model for this style next, since at least I have some information regarding this version.

3) The MC2 chamber has its own stack model, about which I haven't found any drawings in the binders. I can't start on MC2C at all until I find such drawings.

7/14: Analytical calculation of Viton spring constant; updated Viton values in models; experimental confirmation of COMSOL eigenfrequencies (single stack layer)

7/15: Extensions to 2-, 3-, and 4-layer stack legs. Eigenfrequency characterizations performed for each level. Meshing issues with 4-layer stack prevented completion.

7/19: Debugged the 4-layer stack. Turned out to be a boundary condition issue because of non-sequential work-plane definitions. Successful characterization of single-leg eigenfrequencies.

7/20: Prototype three-legged stack completed, but dimensions are incorrect. Read Sievers paper for details of triple-legged stack. Sorted through many stack design binders in efforts to distinguish IOC/OOC, BSC/ITMX/ITMY, MC1/MC3, and MC2 dimensions.

7/21: Researched frequency domain analysis testing in COMSOL. Attempting to first find transfer function of a single-layer stack --> currently running into some run-time errors that will need some more debugging in the afternoon.

Now that venting is complete, this is a request for anyone who opens any chamber:

1) Please notify me immediately so I can take pictures of the stacks in that chamber.

2) If I'm not around, please take a few pictures for me. I'm most interested in the shape, number of layers, size, and damper arrangements of each stack.

This is most important for the MC1/MC3 chamber, MC2 chamber, and BS/ITMX/ITMY chambers.

Over the past couple days, I discovered a simple, direct method for calculating frequency responses with a combination of COMSOL and any plotter such as Excel or MatLab. The simple case of rectangular prism of steel was analyzed using this method; details will be posted shortly on the COMSOL Wiki page. The frequency response matched theoretical reasoning: the bar acts as a simple mechanical low-pass filter, rapidly attenuating driving frequencies at the base beyond the first eigenmode.

It therefore shouldn't be too difficult to extend this analysis to the MC1/MC3 stack. The many eigenfrequencies will produce a more complicated transfer function, and so more data points will be taken.

The major shortcoming of this method involves dealing with the imaginary components of the eigenfrequencies. As of now, I haven't found a way of measuring the phase lag between the drive and the response. I also haven't found a way of changing the damping constants and therefore playing with phase components.

I have successfully completed a preliminary transfer function measurement test on the MC1/MC3 stack in COMSOL. Using the measurement scheme described on the Wiki, I initialized a 1 N/m^2 sinusoidal perturbation on the bottom of the stack and measured the maximum displacement of the top layer. This preliminary test just calculated the responses to 1-,2-,3-,4-, and 5-Hz drives along the x-axis (pictures attached).

Currently, I am rerunning the same test but from 1-10 Hz with 0.1-Hz steps. When both x- and y-axis responses have been plotted, I can move on to repeating this entire process on the MC2 stack.

I completed the frequency domain analysis mentioned previously in the x-direction. Although I ran it from 1-10 Hz, with 0.1-Hz increments, COMSOL was unable to complete the task past 7 Hz because the relative error was beyond the relative tolerance. To solve this issue, I'd have to rerun the simulation with a finer mesh, an unfavorable option because of the already-extensive run times. The Bode magnitude plot from this simulation is attached:

This simulation raises some questions about the feasibility of this method:

1) Do we have the computing power necessary?

I already moved my work from my personal Mac Pro to Kallo (4 GB --> 12 GB RAM difference). Now, instead of crashing the program constantly, I typically wait a half hour for a standard run of the model. Preferably, I could move my work to Megatron or some other workhorse-computer... but I also know that many of the big boys are already being strained as is.

2) Is it possible to take measurements through Matlab?

This way, I could write a script to instruct COMSOL and just run a few tests at a time overnight. Also, I wouldn't have to sit and record measurements manually as I've done here. The benefits of such an improvement warrant further attention. I'll work on this option next.

3) Up until what frequency do we need to model?

As I've shown, normal meshing yields data up to 7 Hz. Is this enough? Do we need more data? Certainly not less, I'm quite sure. We need to keep in mind that as frequency range increases, run times increase exponentially.

4) How do we incorporate gravity into the equation?

Gravity will produce a bit of extra force in the non-restoring direction for off-axis deviations, slightly decreasing the expected frequency. Whether or not this is an important effect is questionable, since the deviations are typically on the order of a micron, which is orders of magnitude smaller than the initial displacement I'm using on the base. I've decided to ignore this complication for now.

1) Gravity has to be included because the inverted pendulum effect changes the resonant frequencies. The deflection from gravity is tiny but the change in the dynamics is not. The results are not accurate without it. The z-direction probably is unaffected by gravity, but the tilt modes really feel it.

2) You should try a better meshing. Right now COMSOL is calculating a lot of strain/stress in the steel plates. For our purposes, we can imagine that the steel is infinitely stiff. There are options in COMSOL to change the meshing density in the different materials - as we can see from your previous plots, all the action is in the rubber.

3) I don't think the mesh density directly limits the upper measurement frequency. When you redo the swept-sine using the matlab scripting, use a logarithmic frequency grid like we usually do for the Bode plots. The measurement axis should go from 0.1 - 30 Hz and have ~100 points.

In any case, the whole thing looks promising: we've got real solid models and we're on the merge of being able to duplicate numerically the Dugolini-Vass-Weinstein measurements.

I made some progress on a couple issues:

1) I figured out how to create log-transfer function plots directly in COMSOL, which eliminates the hassle of toggling between programs.

2) Instead of plotting maximum displacement, which could lead to inconsistencies, I've started using point displacement, standardizing to the center of the top surface.

3) I discovered that the displacement can be measured as a field vector, so the minor couplings between each translational direction (due to the asymmetry in the original designs) can be easily ignored.

For the past couple of days, Jan and I have been discussing a major issue in COMSOL involving modeling both oscillatory and non-oscillatory forces simultaneously while using FDA. It turns out that he and I had run into the same problem at different times and with different projects. After discussing with an expert, Jan had decided in the past that this simple task was impossible via direct means.

The issue could still be resolved if there was a way for us to work on the Weak Form of the differential equations describing the system:

Usually, one must define weight as a body load in the negative-z direction. However, this problematically instantiates a new force in COMSOL, which is automatically driven over the range of frequencies during FDA.

Instead, we could define gravity as an anti-restoring force, since we assume that the base of the stack is fixed.

In other words,F_{g} = (ρ*g/L)*x + (ρ*g/L)*y for a point mass which is constrained on the bottom (for small angles).

Working in Weak Form then, we'd never have to define an explicit gravity load-- this could just be an extra couple of terms in the differential equation which are related entirely to the x- and y-vectors (well-defined for each mesh point). This would fool COMSOL into never tacking on the oscillatory term during FDA.

According to current documentation however, Weak Form analysis is not yet possible in COMSOL 4.0. Jan suggested moving my work over to ANSYS or waiting for the 4.0 upgrade, but there's probably not enough time left in my SURF for either of these options. I suggested attempting a backwards-compatibility test to COMSOL 3.5; Jan and I will be exploring this option some time next week.

I have discovered a method of completely characterizing the 6x6 response of all six types (x-,y-, and z- translational/rotational) of oscillatory disturbances at the base of the stack.

"Tipping" drives are trivial, and simply require a face load in the appropriate direction.

"Tilting" drives could use a torque, but I am instead implementing multiple edge loads in opposing directions to create the appropriate net curl. This curl will be kept constant across the three axes for sake of comparing the resulting transfer functions.

"Tipping" responses are once again trivial, and merely require the displacement vector of the top center coordinate to be recorded.

"Tilting" responses require the normal vector to be recorded and manipulated to produce the angular coordinates (assuming right-handed coordinate system):

θ_{x }= tan^{-1}(x/z)

θ_{y }= tan^{-1}(y/z)

θ_{z }= tan^{-1}(y/x)

The first three concepts have been confirmed through simulations to produce correct transfer functions. The last test seems to be producing some problems, in that the vector normal to the equilibrium position (an obvious and useless piece of information) is sometimes given instead of the vector normal to the position of maximum displacement. This means that, as of now, I have the capability of measure the half of the complete 6x6 matrix of transfer functions in the coming weeks. The first three of eighteen transfer functions are attached below and will be included in my progress report.

I reran the FDA in COMSOL on the MC1/MC3 Stack and produced the following Displacement-Displacement Transfer Functions:

X-Translational Drive has a blue background

Y-Translational Drive has a red background

Z-Translational Drive has a green background

Obtaining the Displacement-to-Phase part of the Transfer Function still produces difficulties -- I'm still working on the COMSOL-Matlab interface to perhaps better facilitate this.

RA: I have deleted those plots because they weren't transfer functions. Transfer functions must always be the ratio of something to something. For example: if I had a nickel for every bad plot I see, I would be a millionaire. In that example, the transfer function would have the units of nickels/plots. For the stacks, it should be meters/meter.

I reran the FDA in COMSOL on the MC1/MC3 Stack and produced the following Displacement-Displacement Transfer Functions:

X-Translational Drive has a blue background

Y-Translational Drive has a red background

Z-Translational Drive has a green background

Obtaining the Displacement-to-Phase part of the Transfer Function still produces difficulties -- I'm still working on the COMSOL-Matlab interface to perhaps better facilitate this.

RA: I have deleted those plots because they weren't transfer functions. Transfer functions must always be the ratio of something to something. For example: if I had a nickel for every bad plot I see, I would be a millionaire. In that example, the transfer function would have the units of nickels/plots. For the stacks, it should be meters/meter.

My apologies for the mislabeled axes on my previous plots. They have been corrected to a ratio (in./in.), as Rana so kindly suggested in his helpful, not-at-all-condescending response.

I have chosen to stay in the English system because all of the original stack drawings are in inches as well.

Time Domain Analysis on a Driven, Damped Simple Pendulum has produced a method for implementing gravity.

COMSOL made this simple task a cryptic one: the following methods had previously failed:

Previous Frequency Domain testing lead to unwanted oscillations of all loads.

Prescribed accelerations at first seemed to create a constant gravity, but instead incorrectly constrained net acceleration to the inputted amount

Methodology:

1) An (approximately) impulse displacement was applied in the horizontal direction. The pendulum bob's displacement was observed for varying pendulum lengths.

2) The drive and response displacements vs. time were FFT'd to produce transfer functions.

3) The fundamental frequencies were inverted, squared, and plotted against frequency.

4) Since the graph is linear with an R^2 of over 0.99, it is reasonable to assume that gravity is properly acting as a restoration force.

For the sake of future users, I have decided to periodically add tips and tricks in using COMSOL that I have figured out, most probably after hours of circuitous efforts. They will always be listed under the new COMSOL Tips category.

Today's topic: Intrusions

COMSOL has a very user-friendly interface for taking objects from 2D to 3D using the "extrusion" feature. But suppose one wants to design an object which contains screw holes or some other indentation. I've found that creating "punctures" in COMSOL is either impossible or very complicated.

Instead, COMSOL encourages users to always "add" to the object. In other words, one must form the lowest level first, then build layers sequentially on top using new work plane and boolean difference operators. This will probably be a bit clearer with an example:

1) First, create the planar projection in a work plane:

2) Extrude the first layer only in the regular fashion:

3) Add a new work plane which is offset in the z-direction to the deepest point of the intrusion.

4) Now, create the shape of the intrusion in this new work plane.

5) Use the Boolean "Difference" to let COMSOL know that, on this plane, the object has a hole.

6) Extrude once more from the second work plane to complete the intrusion.

Wed. 7/7: COMSOL Busbar tutorials; began stack design; began base; Viton rubber research

Thurs. 7/8: Completed Viton rubber research; updated materials; finished designing the base layer

Fri. 7/9: Research model coupling papers; extensive eLog entry about base design and troubleshooting

Sun. 7/11: Played around with Busbar to find first eigenfrequency; continued crashing COMSOL

Mon. 7/12: Intrusions in COMSOL eLog tutorial entry; research eigenfrequency analysis; successfully got first eigenmode of rectangular bar

Tues. 7/13: Updated Poisson ratio of Viton and subsequently succeeded in running eigenfrequency tests on base stack layer. Systematic Perturbation Tests were documented in the most recent elog entry. Discussed results with Rana and decided this didn't make sense. Analytical study required.

Wed. 7/14: Went over to machine shop to experimentally extrapolate spring constant of Viton. Calculations to be done in the afternoon.

In this experiment, we used a feedback control to create a stable trap for a NdFeB permanent magnet. The block diagram is the following:

The displacement of the magnet is sensed by the Hall-effect sensor, whose output voltage is proportional to the magnetic flux produced

by the permanent magnet. It has a flat response within the frequencies we are interested in. It is driven by a 5 V power supplier and its

output has a DC voltagle of 2.5 V. We subtracted the DC voltage and used the resulting signal as the error signal. This was

simply achieved by using two channels "A" and "B". The output is "A-B" with a gain equal to one. We then put the error

signal into another SR560 as a low-pass filter with a gain of 100 above 30 Hz. We used the "DC" coupling modes in both

preamplifers. The output is then used to drive a coil. The coil has a dimension of 1.5 inch in diameter and 2 inch in length.

The inductance of the coil is around 0.5 H and the resistance is 4.7 Om. Therefore, it has a corner frequency aournd 10/2pi Hz.

The coil has a iron core inside to enhance the DC force to the permanent magnet. The low-frequency 1/f response of the magnet is produced

by the eddy current damping of the aluminum plane that is below the magnet. This 1/f response is essential for a stable configuration. In the

next stage, we will remove the aluminum plane, and instead we will use a filter to create similar transfer function. At high-frequencies, it behaves as

a free-mass and has a 1/f^2 response. Finally, the magnet is stably levitated.

I am using SR785 Spectrum Analyzer now and also tomorrow.
I will put it back on Sunday. If anyone needs it during the weekend,
please just take it and I can reset it by myself later. Thanks.

I measured the open-loop transfer function of the magnetic levitation system.

The schematic block diagram for this measurement is the following:

I injected a signal at a level of 20mV between two preamplifiers, and the corresponding open-loop

transfer function is given by B/A. I took a picture of the resulting measurement, because

I encountered some difficulties to save the data to the computer via the wireless network.

The bode plots for the transfer function shown on the screen is the following:

I am puzzled with the zero near 10 Hz. I think it should come from the mechanical response function, because there is no zero in the transfer functions

of the preamplifer and the coil itself. I am not sure at the moment.

The corresponding configuration of the levitated magnet is

1. Why do all of the BNCs have no GND connection? Each should have the individual cables to the ground. Each signal line and the corresponding ground line should be twisted together.

2. This looks the (usual) oscillation of the V-I conversion stage but I can't tell anything as I don't have the circuit diagram of the whole circuit.

3. In a certain case, putting some capacitance at the feedback may help. Read P.11 of the data sheet of LT1125. Try to put some capacitors from 20pF to some larger one whether it changes the situation or not. I suppose the bandwidth of your sensor can be ~1kHz. So putting a capacitance less than 10nF still has no effect to the servo.

1. They are all connected to the box which has a single connection to the board ground. If I connect each of them to the ground, there would be many small loops

of ground. Of course, I should have replaced all the connectors such that the they are disconnected to the box as point out by Robert.

2. The oscillation disappears after I add 5 nF capacitor in parallel to the existing resistor. Thank you very much for pointing this out.

We did some quick DC balancing of the MC2 coil drivers to reduce the l2a coupling. We updated the gains in the C1:SUS-MC2_UL/UR/LR/LLCOIL to be 1, -0.99, 0.937,-0.933, respectively. The previous values were 1, -1, 1, -1.

The procedures are the following:

Lock IMC.

Drive UL+LR and change the gain of LR to zero pitch.

Drive UR+LL and change the gain of LL to zero pitch.

Lastly, drive all 4 coils and change UR & LR together to zero yaw.

We used C1:SUS-MC2_LOCKIN1_OSC to create the excitations at 33 Hz w/ 30,000 cts. The angular error signals were derived from IMC WFSs.

While this time we did things by hand, in the future it should be automated as the procedure is sufficiently straightforward.

My old scheme was flawed as I used pitch as the readback. The pitch signal could not distinguish the cross-coupling due to coil imbalance and that due to the natural suspension L2P. A new scheme based on yaw alone has been developed and will be integrated into ifo_test. For now we revert the C1:SUS-MC2_UL/UR/LR/LLCOIL gains back to 1, -1, 1, -1.

Quote:

[Yehonathan, Hang]

We did some quick DC balancing of the MC2 coil drivers to reduce the l2a coupling. We updated the gains in the C1:SUS-MC2_UL/UR/LR/LLCOIL to be 1, -0.99, 0.937,-0.933, respectively. The previous values were 1, -1, 1, -1.

The procedures are the following:

Lock IMC.

Drive UL+LR and change the gain of LR to zero pitch.

Drive UR+LL and change the gain of LL to zero pitch.

Lastly, drive all 4 coils and change UR & LR together to zero yaw.

We used C1:SUS-MC2_LOCKIN1_OSC to create the excitations at 33 Hz w/ 30,000 cts. The angular error signals were derived from IMC WFSs.

While this time we did things by hand, in the future it should be automated as the procedure is sufficiently straightforward.

After updating the 40 m finesse file to incorporate the new SRC length (and the removal of SR2), we find that the current SRM radius curvature is fine. Thus a replacement of SRM is NOT required.

Basically, the new one-way SRC gouy phase is 11.1 deg according to Finesse, which is very close to the previous value of 10.8 deg. Thus the transmode spacing should be essentially the same.

In the first attached plot is the mode content calculated with Finesse. Here we have first offset DARM by 1m deg and misaligned the SRM by 10 urad. From the top to bottom we show the amplitude of the carrier fields, f1, and f2 sidebands, respectively. The red vertical line is the nominal operating point (thanks Koji for pointing out that we do signal recycling instead of extraction now). No direct co-resonance for the low-order TEM modes. (Note that the HOMs appeared to also have peaks at \phi_srm = 0. This is just because the 00 mode is resonant and thus the seed for the HOMs is greater. )

We can also consider a clean case without mode interactions in the second plot. Indeed we don't see co-resonances of high order modes.

We proposed a few BHD mode-matching telescope designs and then preformed a few monte-carlo experiments to see how the imperfections would change the story. We assumed a 2 mm (1-sigma) error on the location of the components and 1% (1-sigma) fractional error on the RoC of the curved mirrors. The angle of incidence has not yet been taken into account (no astigmatism at the moment but will be included in the follow-up study.)

For the LO path things are mostly fine. We can use LO1 and LO2 as the actuators (Sec. 2.2 of the note), and when errors are taken into account more than 90% of times we can still achieve 98% mode matching. The gouy phase separation between LO1 and LO2 > 34 deg for 90% of the time, which corresponds to a condition number of the sensing matrix of ~ 3.

The situation is more tricky for the AS path. While the telescopes are usually robust against 2 or 3 mm of positional error, the 1% RoC does affect the performance quite significantly. In the note we choose two best-performing ones but still only 50% of the time they can maintain a power-overlap of > 99%. In fact, the 1% RoC error assumed should be quite optimistic... Not sure if we could achieve this in reality.

One potential way out is to ignore the MM for the first round of BHD. Here anyway we only need to test the ISC schemes. Then in the second round when we have the whole BHD board suspended, we can then use AS1 and the BHD board as the actuators. This might be able to make things more forgiving if we don't need to shrink the AS beam very fast so that it could be separated from AS4 in gouy phase.

As Rana suggested, we present the scattering plot of the AS path mode matching for various variables. The plot is for the AS path, Plan 2 (whose params we summarize at the end of this entry).

In the corner plot, we color-coded each realization according to the mode matching. We use (purple, olive, grey) for (MM>0.99, 0.98<MM<=0.99, MM<=0.98), respectively. From the plot, we can see that it is most sensitive to the RoC of AS1. The plot also shows that we can compensate for some of the MM errors if we adjust the distance between AS1-AS3 (note that AS2 is a flat mirror). The telescope is quite robust to other errors.

The compensation requirement is further shown in the second plot. To correct for the 1% RoC error of AS1, we typically need to adjust AS1-AS3 distance by ~ 1 cm (if we want to go back to MM=1; the window for >0.99 MM spans also about 1 cm). This should be doable because the nominal distance between AS1-AS3 is 115 cm.

The story for plan1 is similar and thus not shown here.

I think the conclusion is that if the AS1 RoC error is not significantly more than 1%, then with some adjustment of the AS1-AS3 distance (~ 1 cm), we could find a solution that simultaneously makes the AS path mode-matching better than 99% for the t- and s-planes.

The requirement of the LO path is less strict and the current plan using LO1-LO2 actuation should work.

We computed the required actuation range for the telescope design in elog:15357. The result is summarized in the table below. Here we assume we misalign an IFO mirror by 1 urad, and then compute how many urad do we need to move the (AS1, AS4) or (LO1, LO2) mirrors to simultaneously correct for the two gouy phases.

Actuation requirement in urad per urad misalignment

[urad/urad]

ITMX

ITMY

ETMX

ETMY

BS

PRM

PR2

PR3

SR3

SRM

AS1

1.9

2.1

-5.0

-5.5

0.5

0.5

-0.3

0.2

0.1

0.6

AS4

2.9

2.0

-8.8

-5.5

-5.9

-0.7

1.3

-0.7

-0.5

0.7

LO1

-4.0

-3.9

11.0

10.4

1.9

-0.4

-0.2

0.1

0.0

-1.1

LO2

-5.0

-3.7

15.1

10.4

8.7

0.8

1.9

1.1

0.7

-1.3

The most demanding ifo mirrors are the ETMs and the BS, for every 1 urad misalignment the telescope needs to move 10-15 urad to correct for that. However, it is unlikely for those mirrors to move more 100 nrad for a locked ifo with ASC engaged. Thus a few urad actuation should be sufficient. For the recycling mirrors, every 1 urad misalignment also requires ~ 1 urad actuation.

As a result, if we could afford 10 urad actuation range for each telescope suspension, then the gouy phase separations we have should be fine.

We looked at the oplev spectra from gps 1274418500 for 512 sec. This should be a period when the ifo was locked in the PRFPMI state according to elog:15348. We just focused on the yaw data for now. Please see the attached plots. The solid traces are for the ASD, and the dotted ones are the cumulative rms. The total rms for each mirror is also shown in the legend.

I am now confused... The ITMs looked somewhat reasonable in that at least the < 1 Hz motion was suppressed. The total rms is ~ 0.1 urad, which was what I would expect naively (~ x100 times worse than aLIGO).

There seems to be no low-freq suppression on the ETMs though... Is there no arm ASC at the moment???

We consider the astigmatism effects of the stock options. The conclusions are:

1. For the AS path, the stock should work fine for the phase-one of BHD, if we could tolerate a few percent MM loss. The window for length adjustment to achieve >99% MM for both s and t is only 1 mm for 1% RoC error (compared to ~ 1 cm in the customized case).

2. The LO path seemed tricky. As LO3 & LO4 are both significantly curved (RoC<=0.5 m), the non-zero angle of incidence makes the astigmatism quite sever. For the t-plane the nominal MM can be 0.98, yet for the s-plane, the nominal MM is only 0.72. We could move things around to achieve a MM ~ 0.85, which is probably fine for the phase-one implementation but not long term.

Details:

Attachments 1-3 are for the AS path; 4-6 are for the LO path.

1 & 4. Marginalized MM distribution for the AS/LO paths. Here we assumed 5 mm positional error and 1% fractional RoC error. Due to the astigmatism, the nominal s-plane MM is only 0.72 for the LO path.

2 & 5. Scattering plots for the AS/LO paths. We color coded the points as the following: pink: MM>0.99; olive: 0.98<MM<=0.99; grey: MM<=0.98. For the AS path, MM is mostly sensitive to the AS1 RoC and can be adjusted by changing AS1-AS3 distance. For the LO path, the LO3 RoC and LO3-LO4 distance are most critical for the MM.

3 & 6. Assuming +- 1% AS1 (LO3) fractional RoC error, how much can we compensate for it using AS1-AS3 (LO3-LO4) distance. For the AS path, there exists a ~ 1 mm window where the MM for s and t can simultaneously > 99%. For the LO path, the best we can do is to make s and t both ~ 85%.

Quote:

Summary

For the initial phase of BHD testing, we recently discussed whether the mode-matching telescopes could be built with 100% stock optics. This would allow the optical system to be assembled more quickly and cheaply at a stage when having ultra-low loss and scattering is less important. I've looked into this possibility and conclude that, yes, we do have a good stock optics option. It in fact achieves comprable performance to our optimized custom-curvature design [ELOG 15357]. I think it is certainly sufficient for the initial phase of BHD testing.

Vendor

It turns out our usual suppliers (e.g., CVI, Edmunds) do not have enough stock options to meet our requirements. This is for two reasons:

For sufficient LO1-LO2 (AS1-AS4) Gouy phase separation, we require a very particular ROC range for LO1 (AS1) of 5-6 m (2-3 m).

We also require a 2" diameter for the suspended optics, which is a larger size than most vendors stock for curved reflectors (for example, CVI has no stock 2" options).

However I found that Lambda Research Optics carries 1" and 2" super-polished mirror blanks in an impressive variety of stock curvatures. Even more, they're polished to comprable tolerances as I had specificied for the custom low-scatter optics [DCC E2000296]: irregularity < λ/10 PV, 10-5 scratch-dig, ROC tolerance ±0.5%. They can be coated in-house for 1064 nm to our specifications.

From modeling Lambda's stock curvature options, I find it still possible to achieve mode-matching of 99.9% for the AS beam and 98.6% for the LO beam, if the optics are allowed to move ±1" from their current positions. The sensitivity to the optic positions is slightly increased compared to the custom-curvature design (but by < 1.5x). I have not run the stock designs through Hang's full MC corner-plot analysis which also perturbs the ROCs [ELOG 15339]. However for the early BHD testing, the sensitivity is secondary to the goal of having a quick, cheap implementation.

Stock-Part Telescope Designs

The following tables show the best telescope designs using stock curvature options. It assumes the optics are free to move ±1" from their current positions. For comparison, the values from the custom-curvature design are also given in parentheses.

AS Path

The AS relay path is shown in Attachment 1:

AS1-AS4 Gouy phase separation: 71°

Mode-matching to OMC: 99.9%

Optic

ROC (m)

Distance from SRM AR (m)

AS1

2.00 (2.80)

0.727 (0.719)

AS2

Flat (Flat)

1.260 (1.260)

AS3

0.20 (-2.00)

1.864 (1.866)

AS4

0.75 (0.60)

2.578 (2.582)

LO Path

The LO relay path is shown in Attachment 2:

LO1-LO2 Gouy phase separation: 67°

Mode-matching to OMC: 98.6%

Optic

ROC (m)

Distance from PR2 AR (m)

LO1

5.00 (6.00)

0.423 (0.403)

LO2

1000 (1000)

2.984 (2.984)

LO3

0.50 (0.75)

4.546 (4.596)

LO4

0.15 (-0.45)

4.912 (4.888)

Ordering Information

I've created a new tab in the BHD procurement spreadsheet ("Stock MM Optics Option") listing the part numbers for the above telescope designs, as well as their fabrication tolerances. The total cost is $2.8k + the cost of the coatings (I'm awaiting a quote from Lambda for the coatings). The good news is that all the curved substrates will receive the same HR/AR coatings, so I believe they can all be done in a single coating run.

We explore bilinear SRCL to DARM noise coupling mechanisms, and show two cases that by doing BHD readout the noise performance can be improved. In the first case, the bilinear piece is due to residual DHARD motion (see also LHO:45823), and it matters mostly for the low-frequency (<100 Hz) part, and in the second piece the bilinear piece is due to residual SRCL fluctuation and it matters mostly for the a few x 100 Hz part. Details are below:

=================================================

General Model:

We can write the SRCL to DARM transfer function as (Evan Hall's thesis, eq. 2.29)

The first term in (2) is due to residual DARM motion dx_D. This term does not depends on the DC value of DARM offset <x_D> and thus does not depend on doing BHD or DC readout. On the other hand, the typical residual DARM motion is 1 fm << 1 pm of DARM offset. Since the current feedforward reduction factor is about 10 (see both Den Martynov's thesis and Evan Hall's thesis), clearly we are not limited by the residual DARM motion.

The second term is due to the change in the arm finesse, which can be affected by, e.g., the alignment fluctuation (both increasing the loss due to scattering into 01/10 modes and affecting the spot positon and hence changing the losses), and is likely to be the reason why we see the effect being modulated by DHARD.

The last term in (2) is due to the residual SRCL fluctuation and is important for the ~ a few x 100 Hz band.

=================================================

DHARD effects.

As argued above, the DHARD affects the SRCL -> DARM coupling as it changes the finesse in the arm cavity (through scattering into 01/10 modes; in finesse we cannot directly simulate the effects due to spot hitting a rougher location).

Since in the second term of eq. (2) the LF part depends on the DARM DC offset <x_D>, this effect can be improved by going from DC readout to BHD.

To simulate it in finesse, at a fixed DARM DC offset, we compute the SRCL->DARM transfer functions at different DHARD offsets, and then numerically compute the derivative \partial Z_s2d / \partial \theta_{DH}. Then multiplying this derivative with the rms value of DHARD fluctuation \theta_{DH} we then know the expected bilinear coupling piece.

The result is shown in the first attached plot. Here we have assumed a flat SRCL noise of 5e-16 m/rtHz for simplicity (see PRD 93, 112004, 2016). We do not account for the loop effects which further reduces the high frequency components for now. The residual DHARD RMS is assumed to be 1 nrad.

In the first plot, from top to bottom we show the SRCL noise projection at different DARM DC offsets of (0.1, 1, 10) pm. Since the DHARD alignment only affects the arm finesse starting at quadratic order, it thus matters what DC offset in DHARD we assume. In each pannel, the blue trace is for no DC offset in DHARD and the orange one for a 5 nrad DC offset. As a reference, the A+ sensitivity is shown in grey trace in each plot as a reference.

We can see if there is a large DC offset in DHARD (a few nrad) and we still do DC readout with a few pm of DARM offset, then the bilinear piece of SRCL can still contaminate the sensitivity in the 10-100 Hz band (bottom panel; orange trace). On the other hand, if we do BHD, then the SRCL noise should be down by ~ x100 even compared to with the top panel.

(A 5 nrad of DC offset in DHARD coupled with 1 nrad RMS would cause about 0.5% RIN in the arms. This is somewhat greater than the typically measured RIN which is more like <~ 0.2%. See the second plot).

=================================================

SRCL effect.

Similarly we can consider the SRCL->DARM coupling due to residual SRCL rms. The approach is very similar to what we did above for DHARD. I.e., we compute Z_s2d at fixed DARM offset and for different SRCL offsets, then we numerically evaluate \partial Z_s2d / \partial dphi_S. A residual SRCL rms of 0.1 nm is then used to generate the projection shown in the third figure.

Unlike the DHARD effect, the bilinear SRCL piece does not depend on the DC SRCL detuning (for the 50-500 Hz part). It does still depends on the DARM DC offset and therefore could be improved by BHD.

Since we do not include the LP of the SRCL loop in this plot, the HF noise at 1 kHz is artifical as it can be easily filtered out. However, the LP will not be very strong around 100-300 Hz for a SRCL UGF ~ 30 Hz, and thus doing BHD could still have some small improvements for this effect.

What: Anchal and I measured the XARM OLTF last Thursday.

Goal: 1. measure the 2 zeros and 2 poles in the analog whitening filter, and potentially constrain the cavity pole and an overall gain.

2. Compare the parameter distribution obtained from measurements and that estimated analytically from the Fisher matrix calculation.

3. Obtain the optimized excitation spectrum for future measurements.

How: we inject at C1:SUS-ETMX_LSC_EXC so that each digital count should be directly proportional to the force applied to the suspension. We read out the signal at C1:SUS-ETMX_LSC_OUT_DQ. We use an approximately white excitation in the 50-300 Hz band, and intentionally choose the coherence to be only slightly above 0.9 so that we can get some statistical error to be compared with the Fisher matrix's prediction. For each measurement, we use a bandwidth of 0.25 Hz and 10 averages (no overlapping between adjacent segments).

The 2 zeros and 2 poles in the analog whitening filter and an overall gain are treated as free parameters to be fitted, while the rest are taken from the model by Anchal and Paco (elog:16363). The optical response of the arm cavity seems missing in that model, and thus we additionally include a real pole (for the cavity pole) in the model we fit. Thus in total, our model has 6 free parameters, 2 zeros, 3 poles, and 1 overall gain.

The analysis codes are pushed to the 40m/sysID repo.

Fig. 1 shows one measurement. The gray trace is the data and the olive one is the maximum likelihood estimation. The uncertainty for each frequency bin is shown in the shaded region. Note that the SNR is related to the coherence as

SNR^2 = [coherence / (1-coherence)] * (# of average),

and for a complex TF written as G = A * exp[1j*Phi], one can show the uncertainty is given by

\Delta A / A = 1/SNR, \Delta \Phi = 1/SNR [rad].

Fig. 2. The gray contours show the 1- and 2-sigma levels of the model parameters using the Fisher matrix calculation. We repeated the measurement shown in Fig. 1 three times, and the best-fit parameters for each measurement are indicated in the red-crosses. Although we only did a small number of experiments, the amount of scattering is consistent with the Fisher matrix's prediction, giving us some confidence in our analytical calculation.

One thing to note though is that in order to fit the measured data, we would need an additional pole at around 1,500 Hz. This seems a bit low for the cavity pole frequency. For aLIGO w/ 4km arms, the single-arm pole is about 40-50 Hz. The arm is 100 times shorter here and I would naively expect the cavity pole to be at 3k-4k Hz if the test masses are similar.

Fig. 3. We then follow the algorithm outlined in Pintelon & Schoukens, sec. 5.4.2.2, to calculate how we should change the excitation spectrum. Note that here we are fixing the rms of the force applied to the suspension constant.

Fig. 4 then shows how the expected error changes as we optimize the excitation. It seems in this case a white-ish excitation is already decent (as the TF itself is quite flat in the range of interest), and we only get some mild improvement as we iterate the excitation spectra (note we use the color gray, olive, and purple for the results after the 0th, 1st, and 2nd iteration; same color-coding as in Fig. 3).