I've setup a test setup on the ITMY Oplev table. Details + pics to follow, but for now, be aware that
Here are some pics of the setup: https://photos.app.goo.gl/DHMINAV7aVgayYcf1.None of the existing Oplev input/output steering optics were touched. Steve can make modifications as necessary, perhaps we can make similar mods to the SRM Oplev QPD and the BS one to run the HeNe test for a few days...
too complex; just shoot straight from the HeNe to the QPD. We lower the gain of the QPD by changing the resistors; there's no sane reason to keep the existing 100k resistors for a 2 mW beam. The specular reflection of the QPD must be dumped on a black glass V dump (not some flimsy anodized aluminum or dirty razor stack)
Here are a couple of preliminary plots of the noise from a 20minute stretch of data - the new curve is the orange one, labelled sensing, which is the spectrum of the PIT/YAW error signal from the HeNe beam single bounce off a single steering mirror onto the QPD, normalized to account for the difference in QPD sum. The peaky features that were absent in the dark noise are present here.
I am a bit confused about the total sum though - there is ~2.5mW of light incident on the PD, and the transimpedance gain is 10.7kohm. So I would expect 2.5e-3 mW * 0.4A/W * 10.7 kV/A ~ 10.7V over 4 quadrants. The ADC is 16 bit and has a range +/- 10V, so 10.7 V should be ~35,000 cts. But the observed QPD sum is ~14,000 counts. The reflected power was measured to be ~250uW, so ~10% of the total input power. Not sure if this is factored into the photodiode efficiency value of 0.4A/W. I guess there is some fraction of the QPD that doesn't generate any photocurrent (i.e. the grooves defining the quadrants), but is it reasonable that when the Oplev beam is well centered, ~50% of the power is not measured? I couldn't find any sneaky digital gains between the quadrant channels to the sum channel either... But in the Oplev setup, the QPD had ~250uW of power incident on it, and was reporting a sum of ~13,000 counts with a transimpedance gain of 100kohm, so at least the scaling seems to hold...
I guess we wan't to monitor this over a few days, see how stationary the noise profile is etc. I didn't look at the spectrum of the intensity noise during this time.
Today Angelina and I looked at the PRM OL with an eye towards installing a 2nd QPD. We want to try out using 2 QPDs for a single optic to see if theres a way to make a linear combination of them to reduce the sensitivity to jitter of the HeNe laser or acoustic noise on the table.
The power supply for the HeNe was gone, so I took one from the SP table.
There are WAY too many optics in use to get the beam from the HeNe into the vacuum and then back out. What we want is 1 steering mirror after the laser and then 1 steering mirror before the QPD. Even though there are rumors that this is impossible, I checked today and in fact it is very, very possible.
More optics = more noise = bad.
I checked the calibration of the Oplevs for both ITMs, both ETMs and the BS. The table below summarizes the old and new cts->urad conversion factors, as well as the factor describing the scaling applied. Attachment #1 is a zip file of the fits performed to calculate these calibration factors (GPS times of the sweeps are in the titles of these plots). Attachment #2 is the spectra of the various Oplev error signals (open loop, so a measure of seismic induced angular motion for a given optic, and DoF) after the correction. Loop TF measurements post calibration factor update and loop gain adjustment to be uploaded tomorrow.
Now that the ETMX calibration has been updated, let's keep an eye out for a wandering ETMX.
I found that the BS/PRM OL SUM channels were reading close to 0. So I went to the optical table, and found that there was no beam from the HeNe. I tried power-cycling the controller, there was no effect. From the trend data, it looks like there was a slow decay over ~400000 seconds (~ 5 days) and then an abrupt shutoff. This is not ideal, because we would have liked to use the Oplevs as a DC alignment reference during the ventI plan to use the AS camera to recover some sort of good Michelson alignment, and then if we want to, we can switch out the HeNe.
*How can I export PDF from NDscope?
Perhaps the ETMY Oplev HeNe is also giving up - the power has fallen by ~30% over 1 year (Attachment #2), nearly twice as much as ETMX but the RIN spectrum (Attachment #1, didn't even need to rotate it!) certainly seems suspicious. Some "nominal" RIN levels for HeNes can be found earlier in this thread. I can't close any of the EY Oplev loops in this condition. I'll double check to make sure I'm routing the right beam onto the QPD, but if the problem persists, I'll replace the HeNe. ITMX HeNe also looks to be near EOL.
Finally I reallized what is killing the ETMY oplev laser. Wrong power supply, it was driving the HeNe laser by 600V higher voltage than recommended. Power supply 101T-2300Vdc replaced by 101T-1700Vdc ( Uniphase model 1201-1, sn 2712420 )
The laser head 1103P, sn P947049 lived for 120 days and it was replaced by sn P964431 New laser output 2.8 mW, quadrant sum 19,750 counts
I replaced the BS/PRM Oplev HeNe with one of the heads from the SP table where Steve was setting up the OL RIN/pointing noise experiment. The old one was dead. The new one outputs 3.2 mW of power, I've labelled it with this number, serial number and date of replacement. The beam comes out of the vacuum chamber for both the BS and PRM, and the RIN spectra (Attachment #1) look alright. The calibration into urad and loop gains possibly have to be tweaked. Since the beam comes out of vacuum, I say that we shouldn't open the BS/PRM chamber for this vent - we don't have a proper plan for the in-air layout yet, so we can add this to the list of to-dos for the next vent.
I think we are down to our last spare HeNe head in the lab - @Chub, please look into ordering some more, the ITMX HeNe is going to need replacement soon.
Oplev HeNe was replaced this afternoon. We did some HeNe shuffling:
Attachment #1 shows the RIN and Attachment #2 and #3 show the PIT and YAW TFs with the new HeNe.
The ITMX Oplev path is still not great - the ingoing beam is within 2mm of clipping on a 2" lens used in the POX path, and there is a bunch of scattered red light everywhere. We should take the opportunity when the chamber is open to try and have a better layout (it may be tricky to optize without touching the two in-vacuum steering optics).
I'll ask Chub to replace it this afternoon.
The AS spot on the camera was oscillating at ~3 Hz. Looking at the Oplevs, the culprit was the BS PIT DoF. Started about 12 hours ago, not sure what triggered it. I disabled Oplev damping, and waited for the angular motion to settle down a bit, and then re-enabled the servo - damps fine now...
While working on recovering interferometer alignment, I noticed that the ETMX Oplev SUM channel reported 0 counts. Attachment #1 shows the 200 day trend - despite the missing data, the accelerating downward decay is evident. I confirmed that there is no light coming out of the HeNe by walking down to EX. The label on the HeNe says it was installed in March 2017, so the lifetime was ~30 months. Seems a little short? I may replace this later today.
To facilitate POX locking investigations, I replaced this HeNe today with one of the spares Chub/Steve had acquired some time ago. Details:
The RIN of the sum channel with the Oplev servo engaged, along with that for the other core FPMI optics, in shown in Attachment #1. The ETMX HeNe RIN is compatible with the other HeNes in the lab (the high-frequency behaviour of the BS Oplev is different from the other four because the QPD whitening electronics are different).
Not sure what to make of the ETMY RIN profile being so different from the others, seems like some kind of glitchy behaviour, I could see the mean level of the ASD moving up and down as I was taking the averages in DTT. Needs further investigation.
The old / broken HeNe is placed i(nside the packaging of the abovementioned replacement HeNe) on Steve's old desk for disposal in the proper way.
*It looked like Steve had hooked up a thermocouple to be able to monitor the temperature of the HeNe head. I removed this feature as I figured if we don't have this hooked up to the DAQ, it isn't a really useful diagnostic. If we want, we can restore this in a more useful way.
In preparation for locking tonight, I re-centered the spots on the Oplev QPDs for the ITMs, BS and PRM after locking and running the dither alignment for the arms and also the PRMI carrier. In the past, DC coupling the ITM Oplevs helped the angular stability a bit, let's see if it still does.
Attachment #1 shows that the ITMX, ETMY and beamsplitter Oplev light levels have decayed significantly from their values when installed. In particular, the ETMY and ITMX sum channels are now only 50% of the values when a new HeNe was installed. ELOG search revealed that ITMY and ETMX HeNes were replaced with newly acquired units in March and September of last year respectively. The ITMX oplev was also replaced in March 2019, but the replacement was a unit that was being used to illuminate our tourist attraction glass fiber at EX.
We should replace these before any vent as they are a useful diagnostic for the DC alignement reference.
The ITMX Oplev (installed in March 2019) was near end of life judging by the SUM channel (see Attachment #1). I replaced it yesterday evening with a new HeNe head. Output power was ~3.25 mW. The head was labelled appropriately and the Oplev spot was recentered on its QPD. The lifetime of ~20 months is short but recall that this HeNe had already been employed as a fiber illuminator at EX and so maybe this is okay.
Loop UGFs and stability margins seem acceptable to me, see Attachment #2-#3.
As part of the hunt why the X arm IR transmission RIN is anomalously high, I noticed that the BS Oplev Servo periodically kicks the optic around - the summary pages are the best illustration of this happening. Looking back in time, these seem to have started ~Nov 23 2020. The HeNe power output has been degrading, see Attachment #1, but this is not yet at the point where the head usually needs replacing. The RIN spectrum doesn't look anomalous to me, see Attachment #2 (the whitening situation for the quadrants is different for the BS and the TMs, which explains the HF noise). I also measured the loop UGFs (using swept sine) - seems funky, I can't get the same coherence now (live traces) between 10-30 Hz that I could before (reference traces) with the same drive amplitude, and the TF that I do measure has a weird flattening out at higher frequencies that I can't explain, see Attachment #3.
The excess RIN is almost exactly in the band that we expect our Oplevs to stabilize the angular motion of the optics in, so maybe needs more investigation - I will upload the loop suppression of the error point later. So far, I don't see any clean evidence of the BS Oplev HeNe being the culprit, so I'm a bit hesitant to just swap out the head...
When both arms were locked, we found that ITMY optical lever was very off-center. This seems to have happened after the c1susaux rebooting we did in June 17th. I opened the ITMY table and realigned the OPLev beam to the center when the arm was locked. I repeated this process for BS, PRM and ETMY. I did PRM because I've known that we have been keeping its OpLev off. The reason was clear once I opened the table. The oplev reflection beam was hitting the PD box instead of the PD. After correcting, I was able to swithc on PRM opLev loops and saw normal functioning.
This was a mistake. When arms are locked, PRM is misaligned by setting -800 offset in PIT dof of PRM. The oplev is set to function in normal state not this misalgined configuration. I undid my changes today by switching off the offset, realigning the oplev to center and then restoring the single arm locked state. The PRM OpLevs loops are off now.
PRM because I've known that we have been keeping its OpLev off. The reason was clear once I opened the table. The oplev reflection beam was hitting the PD box instead of the PD. After correcting, I was able to swithc on PRM opLev loops and saw normal functioning.
[yehonathan, anchal, paco]
Yesterday around 9:30 pm, we centered the BS, ITMY, ETMY, ITMX and ETMX oplevs (in that order) in their respective QPDs by turning the last mirror before the QPDs. We did this after running the ASS dither for the XARM/YARM configurations to use as the alignment reference. We did this in preparation for PRFPMI lock acquisition which we had to stop due to an earthquake around midnight
Late elog. Original time 08/02/2021 21:00.
I locked both arms and ran ASS to reach to optimum alignment. ETMY PIT > 10urad, ITMX P > 10urad and ETMX P < -10urad. Everything else was ok absolute value less than 10urad. I recentered these three.
Than I locked PRMI, ran ASS on PRCL and MICH and checked BS and PRM alignment. They were also less than absolute value 10urad.
I centered all the optical levers on ITMX, ITMY, ETMX, ETMY, and BS to a position where the single arm lock on both were best aligned. Unfortunately, we are seeing the TRX at 0.78 and TRY at 0.76 at the most aligned positions. It seems less power is getting out of PMC since last month. (Attachment 1).
Then, I tried to lock PRMI with carrier with no luck. But I was able to see flashing of up to 4000 counts in POP_DC. At this position, I centered the PRM optical lever too (Attachment 2).
Here is an early sketch of the MC table.
I have made an editable draw.io diagram of the planned simplified BHD setup on the ITMY table (see attached). 10 pts = 1 inch.
This is very sketchy but easily adjustable since we are removing everything but the ITMY Oplev from that table.
We are supposed to have BS Oplev Beams. We don't like the shallow angle reflections (i.e. AOI>45deg).
The laser is too big but I suspect the other components are too small. So it'd be check the actual size of the components including the optical mounts that are missing on the figure so far.
Possibility to swap BS and ITMX tables:
BS table, which Tega said MC table, is 2ft x 4ft. The ITMX table is 3ft x 5ft and only the central 2ft x 4ft area is used. The area around the BS table is the narrowest for the east arm. We need at least (2+delta) ft of the hallway width so that we can move the instrument. I'm not yet sure if the ITMX table can be placed there without precise investigation.
I have updated the BS table using feedback from Koji and Paco and the attached pdf document is the latest iteration.
We measured the wedge angle of the G&H and LaserOptik mirrors at the OMC lab using an autocollimator and rotation stage.
The wedge angles:
G&H : 18 arc seconds (rough measurement)
LaserOptik : 1.887 deg
Reflectivity of AR surface of LaserOptik (SN6)
The first step measurements of R for AR surface. I am not convinced with the data....because the power meter is a lame detector for this measurement.
I'm repeating the measurements again with PDs. But below is the log R plot for AR surface.
6000ppm @ 42 deg
3560ppm @ 44 deg
7880ppm @ 46 deg
4690ppm @ 48 deg
Hours of struggle and still no data
I tried to measure the AR reflectivity and the loss due to flipping of G&H mirrors
With almost no wedge angle, separating the AR reflected beam from the HR reflected beam seems to need more tricks.
The separation between the 2 reflected rays is expected 0.8mm. After using a lens along the incident beam, this distance was still not enough to be separable by an iris.
The first trick: I could find a prism and tried to refract the beams at the edge of the prism...but the edges weren't that sharp to separate the beams (Infact I thought an axicon would do the job better..but I think we don't have any of those).
Next from the bag of tricks: I installed a camera to see if the spots can actually be resolved.
The camera image shows the 2 sets of focal spots; bright set to the left corresponding to HR reflected beam and the other from the AR surface. I expect the ghost images to arise from the 15 arcsec wedge of the mirror. I tried to mask one of the sets using a razor blade to see if I can separate them and get some data using a PD. But, it so turns out that even the blade edge is not sharp enough to separate them.
If there are any more intelligent ideas...go ahead and suggest!
How about to measure the AR reflectivity at larger (but small) angles the extrapolate the function to smaller angle,
or estimate an upper limit?
The spot separation is
D = 2 d Tan(\phi) Cos(\theta), where \phi = ArcSin(Sin(\theta) * n)
D = 2 d Tan(\phi) Cos(\theta), where \phi = ArcSin(Sin(\theta) / n) (<== correction by Manasa's entry)
\theta is the angle of incidence. For a small \theta, D is propotional to \theta.
So If you double the incident angle, the beam separation will be doubled,
while the reflectivity is an even function of the incident angle (i.e. the lowest order is quadratic).
I am not sure until how much larger angle you can use the quadratic function rather than a quartic function.
But thinking about the difficulty you have, it might be worth to try.
n1Sin(\theta1) = n2 Sin(\theta2)
So it should be
\phi = ArcSin(Sin(\theta) / n
I did check the reflected images for larger angles of incidence, about 20 deg and visibly (on the IR card) I did not see much change in the separation. But I will check it with the camera again to confirm on that.
Use the trick I suggested:
Focus the beam so that the beam size at the detector is smaller than the beam separation. Use math to calculate the beam size and choose the lens size and position. You should be able to achieve a waist size of < 0.1 mm for the reflected beam.
I, by chance, found that my windows partition has Vision32 installed.
So I run my usual curvature characterization for the TT phasemaps.
They are found under this link
https://nodus.ligo.caltech.edu:30889/40m_phasemap/40m_TT/（requires: LVC credentials)
asc/ (ascii files) --> .asc files are saved in Wyko ascii format.
bmp/ (screen shots of Vision32)
mat/ (Matlab scripts and results)
opd/ (Raw binary files)
Estimated radius of curvature
Mirror / RoC from Vision32 / RoC from KA's matlab code
G&H "A" 0864 / -527.5 m / -505.2 m
G&H "B" 0884 / -710.2 m / -683.6 m
LaserOptik SN1 / -688.0 m / -652.7 m
LaserOptik SN2 / -605.2 m / -572.6 m
LaserOptik SN3 / -656.7 m / -635.0 m
LaserOptik SN4 / -607.5 m / -574.6 m
LaserOptik SN5 / -624.8 m / -594.3 m
LaserOptik SN6 / -658.5 m / -630.2 m
The aperture for the RoC in Vision32 seems a bit larger than the one I have used in the code (10mm in dia.)
This could be the cause of the systematic difference of the RoCs between these, as most of our mirrors
has weaker convex curvature for larger aperture, as seen in the figure. (i.e. outer area is more concave
after the subtration of the curvature)
I did not see any structure like Newton's ring which was observed from the data converted with SXMimage. Why???
I adjusted the focal length of the focusing lens and reduced the beam size enough to mask with the razor blade edge while looking at the camera and then making measurements using PD.
I am still not satisfied with this data because the R of the HR surface measured after flipping seems totally unbelievable (at around 0.45).
G&H AR reflectivity
11 ppm @4 deg
19.8 ppm @6 deg
20 ppm @ 8 deg
30 ppm @ 20 deg
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)
function [Mt, Ms] = mirror(R, a1, n)
% [Mt, Ms] = mirror(R, a1, n)
if length(R) > 1
Rt = R(1);
Rs = R(2);
Rt = R;
Rs = R;
function [Mt, Ms] = transmission(R, a1, n1, n2)
% [Mt, Ms] = transmission(R, a1, n1, n2)
if length(R) > 1
Rt = R(1);
Rs = R(2);
Rt = R;
Rs = R;
function [Mt, Ms] = TTflipped(R, a1)
% [Mt, Ms] = TTflipped(R, a1)
if length(R) > 1
Rt = R(1);
Rs = R(2);
Rt = R;
Rs = R;
function Reff = M2Reff(type, M, a)
% Reff = M2Reff('type', M, a)
n = 1;
R = -2*n/M(2,1);
ca = cos(a*pi/180);
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: