Using the calculated \( H_\infty \) limited controllers in the attached plot I show that as \( \gamma \) decreases the phase margin and the gain margin both increase. It also shows that the gain and phase margin are strongly correlated. In the plot the gamma is represented by the colors in the color bar and the current LIGO controller is shown as a blue triangle. The different lines of points are diffrent F1 gains and show that the relation between the gain margin and the phase margin is not always linear. However, generally speaking, this shows that gain margin and phase margin can be used somewhat interchangeably in this case. I'm not sure if this extends to all admissible controllers.
When \(a \ne 0\), there are two solutions to \(ax^2 + bx + c = 0\) and they are \[x = {-b \pm \sqrt{b^2-4ac} \over 2a}.\]
The source for this is:
When \(a \ne 0\), there are two solutions to \(ax^2 + bx + c = 0\) and they are \[x = {-b \pm \sqrt{b^2-4ac} \over 2a}.\]
Note that text inside of
,
tags does not get rendered. The ASCII Text edit mode uses those tags.
From Chris, attached pdf shows pictures of all of the vacuum pieces to review.
Lee has a spread sheet of the parts I believe. In the mean time the shipping address is:
391 S Holliston Ave
MC: 149-33
Pasadena, CA 91106
[Continuing 11217]
The environmental noise (SEI) must be stable and the plant must have a nonzero D matrix. Because the controller I added in [11217] was unstable it made the seismic section unstable causing the failure we saw in the last post. To fix this issue I manipulated the poles and zeros in this way;
This process keeps the SEI stable and keeps the plant's D matrix non-zero all while keeping the characteristics of the system. The stable poles in the SEI are canceled out by the zeros in the plant leaving only the unstable zeros in the plant.
When running this modified model, the solver runs no problem and gives the attached RMS plot. This plot has all the features that we are looking for; the margins increase as we move away from the H2 limit and it does not seem to have any numerical errors.
There are two things that bother me about this plot. The first is that the current controller (red center in the top left of the plot) seems to be in the outside the theoretical H2 bound for optimality, i.e. it is to the left of the dotted red line. One possible explanation is that this might be some numerical thing, for example, it is not unusual for the solver to return controllers that were below the theoretical limit when the controllers seemed to have numerical issues like the BNS FOM being weighted too high. The second of which is that the current controller does not seem to be particularly stable with this new model. It is only reporting 0.55dB of gain margin and under 10 degrees of phase margin. I'm not sure why either of these things is true and I haven't investigated yet.
There are a few things that are new with the plot. The first of which is that there is an H2 optimal bound on the plot. This is the red line. The second is that there is text to describe what the numbers next to the points are. This is ground breaking tech
Next Steps:
GQUEST's SNSPDs,
Python libraries emerge,
my Haikus conclude.
His first solo log post,
starts Ian's Haiku machine,
electronics stuff.
[Ian, Torrey]
There are a few options for good viewing cards for 1550 nm. I lay out some of the options here. A good resource is this Adakari Group elog post
We should get a variety for different applications and also to test them out. we will spend a lot of time looking at them so we really do want them to be good.
[Ian, Torrey]
We set up a temporary soldering station in the swing space. this is just until the full lab ins built then we can move it over there. It is also so that we could move all of the electronics equipment off of the optical table. it is very crowded right now so we should buy some storage for all of the stuff to clean up the area a little bit, but for now at least it is off the optics table. We also need to order some solder because we don't have any.
See picture
Melting metal joins,
Solder's fiery touch binds.
Alex buy solder.
I set up the network for in the swing space. Both the 2.4GHz and 5GHz networks combined into one network. We can turn off the 2.4GHz network if it starts to be a problem.
Router model: ASUS - AX6000 Dual Band Wi-Fi 6 Router, Model: RT-AX88U Pro
Network Name: pLANk time
Network and Admin Passwords: LIGO Secrets or written on router
Admin site: http://192.168.50.1
In swing space's realm,
Ian supplies internet.
LIGO's secrets held.
The Mach–Zehnder in the cryo lab was installed with a beamsplitter mounted on a 3 port mount. Went to install the second readout of the Mach–Zehnder and discovered this. I have since reinstalled the beamsplitter with an appropriate mount, put the other 1811 PD with a lens in front of it on the second readout path, and recovered the alignment on both paths. Minor alignment is still needed to maximize visibility but there are fringes.
Additionally, the source of the oscillations on the PD in reflection of the cavity are still unresolved. Here are some things I know about it:
1) I don't believe they are physical power fluctuations with the laser. As you can see from the screen shot, those fluctuations are between ~3-4 volts on the PD. If these were physical power fluctuations they would show up on a power meter; they don't.
2) They don't seem to be a saturation issue as you can use the half wave plate + PBS to control the amount of power to the cavity and they still occur at very low power.
3) Thought maybe an electrical issue. I substituted the power source for a new 15V power source that we just bought from Newport. Aaron suggested having the moku and PD power from the same power strip so they have a common ground. Also I've tried plugging in the PD to different outlets all around the room. Nothing has worked.
4) The new 1811 I installed in the Mach-Zehnder path (that doesn't see the cavity at all) does not have these fluctuations.
My only other idea is maybe the suspension of this chamber that the cavity is housed in (if it has a suspension) is causing it but I'm unsure how to mitigate/test for that. If anyone has any ideas, please let me know.
Unresolved ripples
in the Mach-Zender's dance,
knowledge to unfold
Alternate 7-7 Poem:
One port, two port, three port, four,
Dr. Torrey just wants more.
In all previous tests I have been using a model of the ASC system that was fit from data using IIRRational in the 'ASC' Folder of the 300m repo. The ZPK representation (See attachment T_ASC_CHARD_P_Unstable.yml) that it produced had right half plane poles meaning the filter was unstable. We then stabilized this by hand by flipping the right hand plane poles into left hand plane poles, i.e. 4.9234+12442i -> -4.9234+12442i (See attachment T_ASC_CHARD_P.yml). We then used the stabilized version in all of our testing.
I went back and tried to see if the solver could handle the the unstable ASC model. I added the model (See attachment ASC_BH2_solver2_unstable.mat) to the buzz 'ExampleModels' folder in the buzz repo and tried it. The solver fails when calculating:
'Q = solve_continuous_are_scipy(a=A.T, b=C.T, q=V1i, r=bh.D2 @ bh.D2.T, e=None, s=V12i, balanced=True)'
giving the error:
'LinAlgError: Failed to find a finite solution.'
See [11229] for the fix