I, by chance, found that my windows partition has Vision32 installed.
So I run my usual curvature characterization for the TT phasemaps.
Is it possible to calculate astigmatism with your tools? Can we get curvature in X/Y direction, preferably aligned with some axis that we might align to in the vacuum?
Gooch & Housego optics order specification from 03-13-2010
Side 1: HR Reflectivity >99.99 % at 1064 nm for 0-45 degrees for S & P polarization
Side 2: AR coat R <0.15
The HR coating scans uploaded to 40mwiki / Aux optics today
Below are new alamode calculations of the PRC and SRC g-factors and arm mode matchings. These include fixes to the ABCD matrices for the flipped folding mirrors that properly (hopefully) take into account the focusing effect of passing through the optic substrates.
I've used nominal curvatures of -600 m for the G&H PR2/SR2 optics, and -700 m for the Laseroptik PR3/SR3 dichroics.
An interesting and slightly disappointing note is that it looks like it actually would have been better to flip PR3 instead of PR2, although the difference isn't too big. We should considering flipping SR3 instead or SR2 when dealing with the SRC. I'll take responsibility for messing up the calculation for the flipped TTs.
RXA: maybe nominal, but we don't actually have measurements of the installed optics' curvatures, so there could be ~10-15% errors in the RoC. Which translates into a 1-2% error in the g-factor.
I think we like the idea of flipping SR2 better than SR3 for the same ghost beam reasons as PR2 is better than PR3. There isn't very much free space in the BS chamber, and if we flip PR/SR3, we have to deal with green ghosts as well as IR.
The flipping SR2 case seems okay to me - flipping either one of the SR folding mirrors gives us a slightly better g-factor than the design with infinite curvatures, and flipping SR2 gives us slightly better mode matching to the arm than the flipped SR3 case, but more importantly, there are fewer ghosts to deal with. I vote we flip SR2, not SR3.
In case anyone is curious how I got the numbers for the effective radius of curvature of the flipped TT mirrors, I include the code below. Now you can calculate at home!
Here's the calculation for the effective RoC of a flipped SR2 with nominal un-flipped HR RoC of -600:
>> [Mt, Ms] = TTflipped(600, 5);
>> M2Reff('t', Mt, 5)
I've attempted to visualize the various components of the cost function in the way I've defined it for the current iteration of the Oplev optimal control loop design code. For each term in the cost function, the way the cost is computed depends on the ratio of the abscissa value to some threshold value (set by hand for now) - if this ratio is >1, the cost is the logarithm of the ratio, whereas if the ratio is <1, the cost is the square of the ratio. Continuity is enforced at the point at which this transition happens. I've plotted the cost function for some of the terms entering the code right now - indicated in dashed red lines are the approximate value of each of these costs for our current Oplev loop - the weights were chosen so that each of the costs were O(10) for the current controller, and the idea was that the optimizer could drive these down to hopefully O(1), but I've not yet gotten that to happen.
Based on the meeting yesterday, some possible ideas:
I've made various changes to the optimal loop design approach, but am still not having much success. A summary of changes made:
Attachment #1 shows the outcome of a typical optimization run - so while I am having some more success with this than before, where the PSO algorithm was stalling and terminating before any actual optimization was done, it seems like I need to re-think the cost function yet again...
Attachment #2 shows the current terms entering the cost function, and their "desired" values.
The current version of the code I am using is here: although I may not have inculded some of the data files required to run it, to be fixed...
When putting code into git.ligo.org, one way to have automated testing is to use the Gitlab CI. This is an automated 'checker', much like the 'Travis' system used in GitHub. Essentially, you give it a make files which it runs somewhere and your GIT repo web page gets a little 'failed/passing' badge telling you if its working. You can also browse the logs to see in detail what happened. This avoids the 'but it works on my computer!' thing that we usually hear.
Another cool feature is client side pre-commit hooks. They can be used to run checks on the local version at the time of commit and refuses to push until the pass/fail exits 0.
Can be the same as the Gitlab CI or just basic code quality checks. I use them to prevent jupyter notebooks being commited with uncleared cells. It needs to be set up on the user's computer manually and is not automatically cloned with the directory: a script can be included in the repo to do this and run manually on first time clone.
After some more tweaking, I feel like I may be getting closer to a cost-function definition that works.
Some things to figure out:
1) Lock it down.
2) Turn it sideways. Use the leveling screws to center the bubble level.
3) Carefully loosen the hanger rod and release slowly the tension to allow
the mass to recenter.
4) Look through the little viewhole next to the rod to make the white lines
line up. This means the mass is centered.
5) Look at the output on a scope. It should be freely moving with a ~1 sec.