We noticed about a week ago that the NDS2 channel lists were not getting updated on megatron. JZ and I investigated; he was able to fix it all up this afternoon by logging in and snooping around Megatron.

Please try it out and tell me about any problems in getting fresh data.

1. The NDS2 server is what we connect to through our python NDS2 client software to download some data.
2. It has been working for years, but it looks like there was a file corruption of the channel lists that it makes back in 2017.
3. Since the NDS2 server code tries to make incremental changes, it was failing to make a new channel list. Was failing to parse the corrupted file.
4. there was a controls crontab entry to restart the server every morning, but the file name in that tab had a typo, so that wasn't working. I commented it out, since it shouldn't be necessary (lets see how it goes...)
5. the nds2mgr account also has a crontab, but that was failing since it didn't have sudo permission. JZ added nds2mgr to the sudoers list so that should work now.
6. I was able to get new channels as of 4 PM today, so it seems to be working.

* we should remember to rebuild the NDS2 server code for Ubuntu. The thing running on there is for CentOS / SL7, but we moved to Ubuntu recently since the SL7 support is going away.

** the nds2 code & conf files are not backed up anywhere since its not on /cvs/cds. It has 52 GB(!!) of txt channel lists & archives which we don't need to backup

Two ITM spares (ITMU01/ITMU02) and five new PR3 mirrors (E1800089 Rev 7-1~Rev7-5) were transported to Downs for phasemap measurement

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. 

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

AS path plan2 nominal params:

label     z (m)     type             parameters  
-----     -----     ----             ----------  
SRMAR          0    flat mirror      none:     
AS1       0.7192    curved mirror    ROC: 2.5000 
AS2       1.2597    flat mirror      none:     
AS3       1.8658    curved mirror    ROC: -0.5000
AS4       2.5822    curved mirror    ROC: 0.6000  
OMCBS1    3.3271    flat mirror      none:   

I have a serious concern about this low angle scattering analysis:

Phase maps perturb the spatial mode of the steady-state of the cavity, but how is this different than mode-mismatch? The loss that I calculated is an overall loss, not roundtrip loss.

The only way I can think this can become serious loss is when the HOMs themselves have very high roundtrip loss. Attached is the modal power fraction that I calculated.

It would be good to have a corner plot with all the distances/ RoCs. Also perhaps a Jacobian like done in this breathtaking and seminal work.

[Jon, Tega, Hang]

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.

This EQ in Nevada seems to have tripped all watchdogs. ITMX was stuck. It was released, and all the watchdogs were restored. Now the IMC is locked.

Hang and I have reanalyzed the BHD telescope designs, with the goal of identifying sufficiently non-degenerate locations for ASC actuation. Given the limited room to reposition optics and the requirement to remain insensitive to small positioning errors, we conclude it is not possible put sufficient Gouy phase separation between the AS1/AS2 and LO1/LO2 locations. However, we can make the current layout work if we instead actuate AS1/AS4 and LO1/LO4. This would require actuating one optic on the breadboard for each relay path. If possible, we believe this offers the simplest solution (i.e., least modification to the current layout).

LO Telescope Design (Attachment 1)

Radius of curvatures:

• LO1: +10 m
• LO2: flat
• LO3: +15 m
• LO4: flat

AS Telescope Design (Attachment 2)

Radius of curvatures:

• AS1: +3 m
• AS2: flat
• AS3: -1 m
• AS4: flat

Perturbation theory:

The cavity modes  , where q is the complex beam parameter and m,n is the mode index, are the eigenmodes of the cavity propagator. That is:

,

where is the mirror reflection matrix. At the 40m, ITM is flat, so . ETM is curved, so , where R is the ETM's radius of curvature.

is the Gouy phase.

is the free-space field propagator. When acting on a state it propagates the field a distance L.

The phase maps perturb the reflection matrices slightly so:

,

Where h_12 are the height profiles of the ITM and ETM respectively. The new propagator is

, where is the unperturbed propagator and

To find the perturbed ground state mode we use first-order perturbation theory. The new ground state is then

Where N is the normalization factor. The (0,1) and (1,0) modes are omitted because they can be zeroed by tilting the mirrors. Gouy phase of TEM00 mode is taken to be 0.

Some simplification can be made here:

The last step is possible since the beam parameter q matches the cavity.

The loss of the TEM00 mode is then:

I finished calculating the X Arm loss using first-order perturbation theory. I will post the details of the calculation later.

I calculated loss maps of ITM and ETM (attachments 1,2 respectively). It's a little different than previous calculation because now both mirrors are considered and total cavity loss is calculated. The map is calculated by fixing one mirror and shifting the other one around.

The losin total is pretty much the same as calculated before using a different method. At the center of the mirror, the loss is 21.8ppm which is very close to the value that was calculated. 

Next thing is to try SIS.

This is to facilitate the summary page config fines to be pulled from nodus in a scripted way, without being asked for authentication. If someone knows of a better/more secure way for this to be done, please let me know. The site summary pages seem to pull the config files from a git repo, maybe that's better?

Summary:

I think the boosts that are currently stuffed on the CM board are too aggressive to be usable for locking the interferometer. I propose some changes.

Details:

[CM board schematic]

[CM board transfer function measurement]

[Measurement of the AO path TF]. Empirically, I have observed that the CARM OLTF has ~90 degrees phase margin available at the UGF when no boosts are engaged, which is consistent with Koji's measurement. Assuming we want at least 30 degrees phase margin in the final configuration, and assuming a UGF to be ~10 kHz, the current boosts eat up way too much phase at 10 kHz. Attachment #1 shows the current TFs (dashed lines), as the boosts are serially engaged. I have subtracted the 180 degrees coming from the inverting input stage. The horizontal dash-dot line on the lower plot is meant to indicate the frequency at which the boost stages eat up 60 degrees of phase, which tells us if we can meet the 30 degree PM requirement.

In solid lines on Attachment #1, I have plotted the analogous TFs, with the following changes:

• R52, R54: 1.21k --> 3.16k (changes 4 kHz zero to 1.5 kHz).
• R61, R62: 82.5 --> 165 (changes 20 kHz zero to 10 kHz).
• R63: 165 --> 300 (changes 10 kHz zero to 5 kHz).

These changes will allow possibly two super boosts to be engaged if we can bump up the CARM UGF to ~15 kHz. We sacrifice some DC gain - I have not yet done the noise analysis of the full CARM loop, but it may be that we don't need 120 dB gain at DC to be sensing noise limited. I suppose the pole frequencies can also be halved if we want to keep the same low frequency gain. In any case, in the current form, we can't access all that gain anyways because we can't enable the boosts without the loop going unstable.

The input referred noise gets worse by a factor of 2 as a result of these changes, but the IN1 gain stage noise is maybe already higher? If this sounds like a reasonable plan, I'll implement it the next time I'm in the lab.

Koji pointed out during the group meeting that I should compensate for local tilt when I move the beam around the mirror for calculating the loss map.

So I did.

Also, I made a mistake earlier by calculating the loss map for a much bigger (X7) area than what I thought.

Both these mistakes made it seem like the loss is very inhomogeneous across the mirror.

Attachment 1 and 2 show the corrected loss maps for ITMX and ETMX respectively.

The loss now seems much more reasonable and homogeneous and the average total arm loss sums up to ~ 22ppm which is consistent with the after-cleaning arm loss measurements.

Yes, \eta_A is the (average) round-trip loss for an arm cavity. I'd estimate this is ~100ppm currently. I edited the original elog to fill in this omission.

The RC mirror specs require some guesswork - the available specs for the Laseroptik mirrors (PR3) are for a 48 degree angle of incidence, and could be as high as 0.5 %. According to the poster, the spec is 2.6% loss inside the recycling cavity but I don't know where I got the number for the AR surface of the G&H PR2, and presumably that includes some guess I made for the MM between the PRC and the arm. Previously, assuming ~1-2% loss inside the RC gave good agreement between model and measurement. Certainly, if we assume similar numbers, a recycling gain of ~11 (200 * T_P=5.637%) is reasonable. But I think we need more data to make a stronger statement.

Is \eta_A the roundtrip loss for an arm?

Thinking about the PRG=10 you saw:
- What's the current PR2/3 AR? 100ppm? 300ppm? The beam double-passes them. So (AR loss)x4 is added.
- Average arm loss is ~150ppm?

Does this explain PRG=10?

Attachment #1 is meant to show that having a T=500ppm PR2 optic will not be the dominant contributor to the achievable recycling gain. Nevertheless, I think we should change this optic to start with. Here, I assume:

• \eta_A denotes the (average) round trip loss per arm cavity (i.e. ITM + ETM). Currently, I guess this is ~100ppm.
• Fixed 0.5% loss from mode mismatch between the CARM mode and the PRC mode (the x-axis does NOT include this number).
• No substrates/AR coatings inside the cavity.
• For the nominal case, let's say the intracavity loss sums to 100 ppm.
• For the T=500ppm PR2, I assumed a total of 550 ppm loss in the PRC.

In relaity, I don't know how good the MM is between the PRC and the arms. All the scans of the arm cavity under ALS control and looking at the IR resonances suggest that the mode-matching into the arm is ~92%, which I think is pretty lousy. Kiwamu and co. claim 99.3% matching into the interferometer, but in all the locks, the REFL mode looks completely crazy, so idk

apt install source-highlight

then modified bashrc to point to /usr/share instead of /usr/bin

Finally - Attachment #1. This plot uses 16 Hz EPICS data. All y-axes are uncalibrated for now, but TRX/TRY are normalized such that the POX/POY lock yields a transmission of 1. CARM UGF is only ~3 kHz, no boosts were turned on yet. 

Attachment #2 and Attachment #3 are phone photos of the camera images of the various ports. After some alignment work, the transmitted arm powers were ~200, i.e. PRG ~10. fwiw, this is the darkest i've ever seen the 40m dark port. c.f. 2016. Of course, the exposure time / ND filter / light levels could all have changed.

This work was possible during the daytime (~6pm PDT), but probably only because it was Sunday. The other rate limiting factor here is the franky terrible IMC duty cycle. TBH, I didn't honestly expect to get so far and ran out of time, but I think the next steps are:

1. Turn on some sensing lines and calibrate CARM/DARM.
2. Transition vertex control to 1f signals.
3. Whiten DARM.
4. Turn on some ASC for better power stabilization.
5. Scan the CARM offset and check that we are truly on resonance
6. Noise budget.

As usual, I would like to request that we don't change the IFO as far as possible until the BHD vent, i found it pretty difficult to get here.

Attachment #4 now shows the measured DARM OLTF when DARM is entirely on AS55_Q control. UGF is ~120 Hz and the phase margin is ~30 deg, seems okay for a first attempt. I'll now need to infer the OLTF over a wider range of frequencies by lining this measurement up with some model, so that I can undo the loop in plotting the DARM ASD.

[Jon, Hang]

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. 

OK so the QPD segments are in the "+" orientation when the 40m IMC WFS heads are mounted at 45 deg. I thought "+" was the natural PIT/YAW basis but I guess in the the LIGO parlance, the "X" orientation was considered more natural.

This is the doc from Keita Kawabe on why the WFS heads should be rotated.

Summary:

The apparent increase in the ALS noise (witnessed in-loop, e.g. Attachment #2 here) during the CARM offset reduction may have an optomechanical origin. 

Details:

• A simplified CARM plant was setup in Finesse - 3 mirror coupled cavity with PRM, ITM and ETM, 40m params for R/T/L used. 
• For a sanity check, DC power buildup and coincident resonance of the PRC and arm cavity were checked. PRG and CARM linewidth also checks out, and scales as expected with arm losses.
• To investigate possible optomechanical issues - I cut the input power to 300 mW (I estimate 600 mW incident on the PRM), set a PRG of ~20, to mimic what we have right now.
• I drive the ITM at various CARM offsets, and measure the m/m transfer function to itself and the ETM.
• Attachement #1 shows the results. 

Interpretation:

• ericq had similar plots in his thesis, but I don't think the full implications of this effect were investigated, the context there was different.
• The optomechanical resonance builds up at ~10 Hz and sweeps up to ~100 Hz as the CARM offset approaches zero, with amplification close to x100 at the resonance.
• What this means is that the arm cavity is moving by up to 100x the ambient seismically driven dispalcements. 
• The EX/EY uPDH servos have considerable gain at these frequencies, and so the AUX laser frequency can keep up with this increased motion (to be quantified exactly what the increase in residual is).
• However, the ALS loop that maintains the frequency offset b/w the PSL and the AUX lasers is digitial, and only has ~20 dB gain at 30 Hz. - so the error signal for CARM control becomes noisier as we see.
• I speculate that the multiple peaky features in the in-loop error signal are a result of some dynamical effects which Finesse presumably does not simulate.
• The other puzzler is: this simulation would suggest that approaching the zero CARM offset from the other side (anti-spring) wouldn't have such instabilities building up. However, I am reasonably sure I've seen this effect approaching zero from both sides, though I haven't checked in the last month.
• Anyways, if this hypothesis is correct, we can't really take advantage of the ~8pm RMS residual noise performance of the IR ALS system sadly, because of our 250g mirrors and 800mW input power. 
• Possible workarounds:
  • High BW ALS - this would give us more gain at ~30 Hz and this wouldn't be a problem anymore really. But in my trials, I think I found that the IN2 gain on the CM board has to be inverted for this to work (the IN1 path and the IN2 path share a common AO path polarity, and we need the two paths to have the opposite polarity).
  • Cut the input power - this would reduce the optomechanical action, but presumably the vertex locking becomes noisier. In any case, this isn't really practical without some kind of motorized/remote-controlled waveplate for power adjustment. 

Update 415pm 5/6: Per the discussion at the meeting, I have now uploaded as Attachment #2 the force-->displacement (i.e. m/N) transfer functions. I now think these are appropriate units. For the ALS case, we could convert the m/N to Hz/N of extra frequency noise imprinted on the AUX laser due to the increased cavity motion. Is W/N really better here, since the mechanism is extra frequency noise on a beatnote, and there isn't really a PDH or DC error signal?

Summary:

I've been thinking about the IMC WFS. I want to repeat the sort of analysis done at LLO where a Finesse model was built and some inferences could be made about, for example, the Gouy phase separation b/w the sensors by comparing the Finesse sensing matrix to a measured sensing matrix. Taking the currently implemented output matrix as a "measurement" (since the IMC WFS stabilize the IMC transmission), I don't get any agreement between it and my Finesse model. Could be that the model needs tweaking, but there are several known issues with the WFS themselves (e.g. imbalanced segment gains).

Building the finesse model:

• I pulled the WFS telescopes from Andres elogs/SURF report, which I think was the last time the WFS telescopes were modified.
• The in-vacuum propagation distances were estimated from CAD diagrams.
• According to my model, the Gouy phase separation between the two WFS heads is ~70 degrees, whereas Andres' a la mode simulations suggest more like 90 degrees. Presumably, some lengths/lenses are different between what I assume and what he used, but I continue the analysis anyway...
• The appropriate power attenuations were placed in each path - one thing I noticed is that the BS that splits light between WFS1 and WFS2 is a 30/70 BS and not a 50/50, I don't see any reason why this should be (presumably it was to do with component availability). see below for Rana's comments.

Simulations:

• The way the WFS servos are set up currently, the input matrix is diagonal while the output matrix encodes the sensing information.
• In finesse, I measured the input matrix (i.e. response sensed in each sensor when an optic is dithered in angle). The length is kept resonant for the carrier (but not using a locking signal), which should be valid for small angular disturbances, which is the regime in which the error signals will be linear anyways.
• Then I inverted the simulated sensing matrix so as to be able to compare with the CDS output matrix. Note that there is a relative gain scaling of 100 between the WFS paths and the MC2T QPD paths which I added to the simulation. I also normalized the columns of the matrix by the largest element in the column, in an attempt to account for the various other gains that are between the optical sensing and the digitizaiton (e.g. WFS demod boards, QPD transimpedance etc etc).
• Attachment #1 shows the comparison between simulation and measurement. The two aren't even qualitatively similar, needs more thought...

Some notes about the WFS heads:

• The transimpedance resistor is 1.5 kohms. With the gain stages, the transimpedance gain is nominally 37.5 kohms, and 3.75 kohms when the attenuation setting is engaged (as it is for 2/4 quadrants on each head).
• Assuming a modulation depth of 0.1, the Johnson noise of the transimpedance resistor dominates (with the MAX4106 current noise a close second), and these heads cannot be shot noise limited when operating at 1 W input power (though of course the situation will change if we have 25 W input).
• The heads are mounted at a ~45 deg angle, mixing PIT/YAW, but I assume we can just use the input matrix to rotate back to the natural PIT/YAW basis.

Update 215 pm 5/6: adding in some comments from Rana raised during the meeting:

1. The transimpedance is actually done by the RLC network (L6 and C38 for CH 3), and not 1.5 kohms. It just coincidentally happens that the reactance is ~1.5 kohms at 29.5 MHz. Note that my LTspice simulation using ideal inductors and capacitors still predicts ~4pA/rtHz noise at 29.5 MHz, so the conclusion about shot noise remains valid I think... One option is to change the attenuation in this path and send more light onto the WFS heads.
   The transimpedance gain and noise are now in Attachment #2. I just tweaked the L values to get a peak at 29.5 MHz and a notch at twice that frequency. For this I assumed a photodiode capacitance of 225pF and the shown transimpedance gain has the voltage gain of the MAX4106 stages divided out. The current noise is input referred.
2. The imbalanced power on WFS heads may have some motivation - it may be that the W/rad TF for one of the two modes we are trying to sense (beam plane tilt vs beam plane translation) is not equal, so we want more light on the head with weaker response.
3. The 45 degree mounting of the heads is actually meant to decouple PIT and YAW.

Yes, we are supposed to have a few spare PI PZTs.

I went to EY and saw that the HV power supply was only putting out 50 V and had hit the current limit of 10 mA (nominally, it should be 100 V, drawing ~7mA). This is definitely a problem that has come up after the power shutdown event, as when I re-energized the HV power supply at EY, I had confirmed that it was putting out the nominal values (the supply was not labelled with these nominal numbers so I had to label it). Or maybe I broke it while running the dither alignment tests yesterday, even though I never drove the PZTs above 50 Hz with more than 1000cts (= 300 mV * gain 5 in the HV amplifier = 1.5 V ) amplitude.

The problem was confirmed to be with the M2 PZT (YAW channel) and not the electronics by driving the M2 PZT with the M1 channels. Separately, the M1 PZT could be driven by the M2 channels. I also measured the capacitance of the YAW channels and found it to be nearly twice (~7 uF) of the expected 3 uF - this particular PZT is different from the three others in use by the ASX and ASY system, it is an older vintage, so maybe it just failed? 😔 

I don't want to leave 100 V on in this state, so the HV supply at EY was turned off. Good GTRY was recovered by manual alignment of the mirror mounts. If someone has a spare PZT, we can replace it, but for now, we just have to live with manually aligning the green beam often.

Summary:

It appears that the EY green steering PZTs have somehow lost their bipolar actuation range. I will check on them the next time I go to the lab for an N2 switch.

Details:

• Yuki installed the EY green PZTs and did some initial setup of the RTCDS model. 
• But we don't have a functional dither alignment servo yet, which is mildly annoying. So I thought I'll finally finish my SURF project.
• There were several problems with the signal flow, MEDM screens etc.
• I rectified these, and set up some operational scripts, burt snapshots etc in $SCRIPTS/ASY. The c1asy and c1als models were also modified, recompiled and restarted, everything appears to have come back online smoothly.
• The LO frequencies/amplitudes, demod filter gains and demod phases were chosen to have a signal mostly in the _I quadrature of the demodulated signal when the alignment is slightly disturbed from optimal (monitored after the post-demod LPF).
• While trying to close the integrator loops, I found that I appear to only have monopolar actuation ability (positive DAC output changes the alignment, negative DAC output does nothing).

Could be that the power outage busted something in the drive electronics. 

Hi All,

The new nitrogen cylinders were delivered to the rack at the west entrance.  We only get one Airgas delivery per week during the stay-at-home order, but so far they've not let us down.

I had set up the 4395 to do this automatically a few years ago, but it looked at the FSS/IMC instead. When the PCDRIVE goes high there is this excess around ~500 kHz in a broad hump.

But the IMC loop gain changes sometimes with alignment, so I don't know if its a loop instability or if its laser noise. However, I think we have observed PCDRIVE to go up without IMC power dropping so my guess is that it was true laser noise.

This works since the IMC is much more sensitive than PMC. Perhaps one way to diagnose would be to lock IMC at a low UGF without any boosts. Then the UGF would be far away from that noise making frequency. However, the PCDRIVE also wouldn't have much activity.

Nice, and we should also permanently install the camera server (c1cam) which is still sitting on the electronics bench. It is running an adapted version of the Python 2/Debian 8 site code. Maybe if COVID continues long enough I'll get around to making the Python 3 version we've long discussed.

Summary:

On Monday, I hooked up an AG4395 to the PMC error point (using the active probe). The idea was to take a spectrum of the PMC error point every time the FSS PC drive RMS channel indicated an excursion from the nominal value. An initial look at the results don't suggest that this technique is particularly informative. I'll have to think more about a workaround, but please share your ideas/thoughts if you have some.

Also, the feature in the spectrum at ~110 kHz makes me suspect some kind of loop instability. I'll measure the IMC loop OLG at the next opportunity.

Details:

• The PMC servo bandwidth is ~2 kHz, so above this, the PMC error point should be a faithful monitor of the PSL frequency noise, provided the sensing noise is low enough.
• The PMC error point sensing noise is ~100nV/rtHz (I'm monitoring this straight after the Minicircuits mixer+bandpass filter that we are using as a demodulator). This corresponds to ~2 Hz/rtHz, using the ~10 MHz/V PDH discriminant calibration from January. Seems consistent with this elog.
• I was hoping to see if there was a particular frequency band in which the noise gets elevated, and if the crossover frequency is a few kHz and the IMC servo BW is ~110 kHz, I would have expected this to be in the 10-100 kHz region. Possibly my frequency resolution isn't good enough? But with the Agilent, doing a finer grid would mean a longer measurement time, in which case the IMC might lose lock before the measurement is done.
• But, as shown in Attachment #1, there isn't any clear evidence, from the ~20 excursions that were recorded last night. The color of the line is meant to be indicative of the average value of the PC drive RMS channel in the measurement time.
• A significant bottleneck in this whole process is that it takes ~1 minute to initiate the GPIB measurement, and download the data. The pseudo-code I used is:
  • While the IMC is locked, watch PCdrive RMS EPICS channel's "ALARM" state, which becomes non-zero when the PCdrive RMS exceeds 1 V (this is how it is defined in the EPICS db record right now).
  • Make sure this isn't a transient feature - I do this by waiting 5 seconds and checking that the ALARM flag is still flagged.
  • Initiate a AG4395 measurement over GPIB - I use the measurement span of 1 kHz - 1 MHz with a BW/span ratio of 0.1%, 5 averages.
  • Check that the IMC is still locked (if it got unlocked while the measurement was made, presumably the measurement is garbage).
• Is there a better monitor of the laser frequency noise? I can imagine using POX/POY which I think have a lower electronics noise floor but I'm not sure if that's true at 100 kHz and having the arms locked in addition to the IMC seems more complicated...
• Since we are planning a laser upgrade, is this worth spending more time on? I may leave the measurement running on pianosa in a tmux session while I'm not in the lab...

Covid 19 motivated me to revive the summary pages. With Alex Urban's help, the infrastructure was modernized, the wiki is now up to date. I ran a test job for 2020 March 17th, just for the IOO tab, and it works, see here. The LDAS rsync of our frames is still catching up, so once that is up, we can start the old condor jobs and have these updated on a more regular basis.

• Empty N2 replaced. 
• Logged back into zita and started the StripTool traces (even though we keep the TV off nowadays).
• c1susaux acro-crate power cycled to re-enable PRM suspension control (all other vertex optics also now respond to slow bias voltage sliders being moved).
• c1iscaux needed a hard reboot as it wasn’t seen on martian. I power cycled the crate for good measure.
• Marconi turned back on with correct frequency/amplitude.
• c0rga is now seen again on martian network. I re-enabled the RGA scanning so that it takes a scan every morning at 4am. 
• The forepumps for TP2/TP3 are noisier than I remember. The former has ~10,000 hrs on the clock. How often does the tip seal replacement need to happen?
• HV supplies for ASX/ASY PZTs re-energized.
• IFO re-aligned for locking.
• c1oaf and c1daf models restarted. c1oaf required the usual start/stop/start sequence to make the DAQ errors go away, and luckily the FE didn’t crash when the model was unloaded.
• POX/POY/PRMI 1f carrier/green locking all was smooth.
• For some reason, the PRC angular FF filters i trained no longer do anything good (but MCL is still good). collected 20mins of PRMI 1f locked data for investigations.

Ok, now I understand my foolishness. It should definitely be 1/sqrt(f^2+fp^2) .

There's this elog from Stephen about better 1064 sensitivity from Basler. We should consider getting one if he finds that its actual SNR is as good as we would expect from the QE improvement.

Might allow for better scatter measurements - not that we need more signal, but it could allow us to use shorter exposure times and reduce blurring due to the wobbly beams.

Summary

I've generated specifications for the new BHD optics. This includes the suspended relay mirrors as well as the breadboard optics (but not the OMCs).

To design the mode-matching telescopes, I updated the BHD mode-matching scripts to reflect Koji's draft layout (Dec. 2019) and used A La Mode to optimize ROCs and positions. Of the relay optics, only a few have an AOI small enough for curvature (astigmatism) and most of those do not have much room to move. This reduced the optimization considerably.

These ROCs should be viewed as a first approximation. Many of the distances I had to eyeball from Koji's drawings. I also used the Gaussian PRC/SRC modes from the current IFO, even though the recycling cavities will both slightly change. I set up a running list of items like these that we still need to resolve in the BHD README.

Optics Specifications

• 2" mirrors (E2000226-v1)
• 2" 50:50 beamsplitters (E2000227-v1)
• 2" lenses (E2000228-v1)
• PR2 replacement (E2000229-v1)

At a glance, all the specifications can be seen in the optics summary spreadsheet.

LO Telescope Design

The LO beam originates from the PR2 transmission (POP), near ITMX. It is relayed to the BHD beamsplitter (and mode-matched to the OMCs) via the following optical sequence:

• LM1 (ROC = +10 m, AOI ≈ 3°)
• LM2 (Flat, AOI ≈ 45°)
• MMT1 (Flat, AOI ≈ 5°)
• MMT2 (ROC = +3.5 m, AOI ≈ 5°)

The resulting beam profile is shown in Attachment 1.

AS Telescope Design

The AS beam is relayed from the SRM to the BHD beamsplitter (and mode-matched to the OMCs) via the following sequence:

• AS1 (ROC = +1.5 m, AOI ≈ 3°)
• AS2 (Flat, AOI ≈ 45°)
• Lens (FL = -125 mm)

A lens is used because there is not enough room on the BHD breadboard for a pair of (low-AOI) telescope mirrors, like there is in the LO path. The resulting beam profile is shown in Attachment 2.

Four nitrogen cylinders replaced the empties in the rack at the west entrance.  Additionally, Airgas will now deliver only once a week.  Let me know via email or text when the there are four empties in the rack and I'll order the next round.

[Koji / Gautam (Remote)]

Lab status

• Gray Panel: The lab AC was off. Turned on all three (N/S, CTRL RM, E/W)
• The control room AC was running.

Work stations

• Control Room: All the control machines were running. We knew that nodus/chiara/fb were running
• 1X6/7:
  • JETSTOR was making beeping sound. “Power #1 failed””power #2 failed”
  • Optimus & megatron were off -> turned on -> up and running now
• 1X1/2:
  • ​Power cycled the netgear at the top of the IOO rack (maybe not necessary)
  • Turned on c1ioo -> up and running now
• 1X4/5: ​Rebooted c1sus / c1lsc -> up and running now
• 1X9: Rebooted c1iscex -> up and running now
• 1Y4: Rebooted c1iscex -> up and running now

Vacuum status

• Looked like everything was running as if it did not see the power glitch
• TP1 normal: Set speed 33.6k rpm / Actual speed 33.6k rpm 
• TP2 normal: 66k rpm / PTP2 16.0 mtorr
• TP3 normal: 31k rpm / PTP3 45.4mtorr
• P1 LOW / P2 1.7mtorr / CC2 1.1e-6 / P3 7.6e-2 / P4 LO
• Annuli: 2.7~3torr
• CC1 9.6e-6 / SUPER BEE 0.9mtorr

C1VAC recovery

• c1vac was alive, but was isolated from the martian network
• Checked the network I/F status with /sbin/ifconfig -a
  • eth0 had no IP
  • eth1 had the vac subnet IP (192.168.114.9)
• Ran sudo /sbin/ifdown eth0 then  sudo /sbin/ifup eth0
• The I/F eth0 started running and c1vac became visible from martian
• Later checked the vacuum screen: The pressure values and valve statuses looked normal.
  The interlock state was “running”. The system state was “unrecognized”.

End RTS recovery 

• The end slow machines (auxex and auxey) were already running
• Restarting end RT models:
  • c1iscey -> rtcds start --all
  • c1iscex -> rtcds start --all
• Confirmed that the models can dump the SUSs

Vertex RTS recovery

• We wanted to use the reboot script. (/opt/rtcds/caltech/c1/scripts/cds/rebootC1LSC.sh)
• c1susaux​​
  • To be safe, we wanted to bring c1susaux first.
  • c1susaux does not make the network I/Fs up automatically upon reboot.
    -> Connect an LCD display / keyboard / mouse to c1susaux
    -> Ran sudo /sbin/ifup eth0 and sudo /sbin/ifup eth1
  • Now c1susaux is visible from martian.
  • Login c1susaux and ran:  
    sudo systemctl start modbusIOC.service 
    -> c1susaux epics is up and running now
  • ...Meanwhile c1susaux lost its eth1 somehow. This made the slow values of 8 vertex sus all zero
    -> Ran sudo /sbin/ifdown eth1 and sudo /sbin/ifup eth1 again on c1susaux ->  this resolved the issue
• c1psl
  • Login c1psl and ran:  
    sudo systemctl start modbusIOC.service 
    -> c1psl epics is up and running now
• Prepared for the rebooting script
  • Ran /opt/rtcds/caltech/c1/scripts/cds/rebootC1LSC.sh
  • Rebooting was done successfully. All the suspensions looked free and healthy.
  • Burtrestored c1susaux (used Apr 12 21:19 snapshot)

Hardware

• PSL laser / Xend AUX laser / Yend AUX laser were off -> turned on
• The PMC was immediately automatically locked.
• The main marconi was off -> forgot to turn on
• The end temp controllers for the SHG crystals were on but not enabled -> now enabled

RTS recovery ~ part 2

• FB: FB status of all the RTS models were still red
• Timing: c1x01/2/3/5 were 1 sec behind of FB and c1x04 was 2 sec behind
• -> Remedy:  https://nodus.ligo.caltech.edu:8081/40m/14349
  • Software rebooting of FB
  • Manually start the open-mx and mx services using
  • sudo systemctl start open-mx.service 
  • sudo systemctl start mx.service
  • Check that the system time returned by gpstime matches the gpstime reported by internet sources. e.g. http://leapsecond.com/java/gpsclock.htm
  • Manually start the daqd processes using
    sudo systemctl start daqd_*
• This made all the FB(FE) indicators green!
• Ran the reboot script again -> All green!

IMC recovery

• The IMC status was checked
• No autolocker, but it could be manually locked. i.e. MC1/2/3 were not so much misalignment
• Autolocker/Slow FSS recovery along with https://nodus.ligo.caltech.edu:8081/40m/15121
  • sudo systemctl start MCautolocker.service
  • sudo systemctl start FSSSlow.service
• Both of them failed to run
• Note by Gautam: The problem with the systemctl commands failing was that the NFS mount points weren’t mounted. Which in turn was because of the familiar /etc/resolv.conf problem. I added chiara to the namespace in this file, and then manually mounted the NFS mount points. This fixed the problem.
  Now the IMC is locked and the autolocker is left running.

Burt restore

• Used Apr 12 21:19 snapshot
• c1psl
• c1alsepics/c1assepics/c1asxepics/c1asyepics
• c1aux/c1auxex/c1auxey/
• c1iscaux/c1susaux
• This made REFL and AS beams back to the CCDs. As has small fringes.
• Y arm has small IR flashes as well as green flashes.

JETSTOR recovery

• JETSTOR was beeping. 
• Shutdown megatron
• Followed the instruction https://nodus.ligo.caltech.edu:8081/40m/13107
• This stopped beeping. Waiting for JETSTOR to come up -> In a minute, JETSTOR display became normal and all disks showed green.
• Bring megatron back up again

N2 bottle

• The left N2 bottle was empty. The right one had 1500PSI.
• Replaced the left bottle with the spare one in the room.
• Now the left one 2680PSI and the right one 1400PSI.

Closing

• Closed PSL/AUX laser shutters
• Turned off the lights in the lab, CTRL room, and the office.

​Remaining Issues

• [done] MCAutoLocker / FSSSlow scripts are not running
• The PRM alignment slider has no effect (although the PRM is aligned…) -> SLOW DAQ frozen???
• JETSTOR is not mounted on megatron [gautam mounted Jetstor on megatron on 4/18 at 2pm]

I just now modified the /etc/rsyncd.conf file as per Dan Kozak's instructions. The old conf file is still there with the file name appended with today's date.

I then enabled the rsync daemon to run on boot using 'enable'. I'll ask Dan to start the file transfers again and see if this works.

controls@nodus|etc> sudo systemctl start rsyncd.service
controls@nodus|etc> sudo systemctl enable rsyncd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/rsyncd.service to /usr/lib/systemd/system/rsyncd.service.
controls@nodus|etc> sudo systemctl status rsyncd.service
● rsyncd.service - fast remote file copy program daemon
   Loaded: loaded (/usr/lib/systemd/system/rsyncd.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2020-04-13 16:49:12 PDT; 1min 28s ago
 Main PID: 4950 (rsync)
   CGroup: /system.slice/rsyncd.service
           └─4950 /usr/bin/rsync --daemon --no-detach

Apr 13 16:49:12 nodus.martian.113.168.192.in-addr.arpa systemd[1]: Started fast remote file copy program daemon.
Apr 13 16:49:12 nodus.martian.113.168.192.in-addr.arpa systemd[1]: Starting fast remote file copy program daemon...

[Larry (on site), Koji & Gautam (remote)]

Network recovery (Larry/KA)

• Asked Larry to get into the lab. 

• 14:30 Larry went to the lab office area. He restarted (power cycled) the edge-switch (on the rack next to the printer). This recovered the ssh-access to nodus. 

• Also Larry turned on the CAD WS. Koji confirmed the remote access to the CAD WS.

Nodus recovery (KA)

• Apr 12, 22:43 nodus was restarted.

• Apache (dokuwiki, svn, etc) recovered along with the systemctl command on wiki

• ELOG recovered by running the script

Control Machines / RT FE / Acromag server Status

• Judging by uptime, basically only the machines that are on UPS (all control room workstations + chiara) survived the power outage. All RT FEs are down. Apart from c1susaux, the acromag servers are back up (but the modbus processes have NOT been restarted yet). Vacuum machine is not visible on the network (could just be a networking issue and the local subnet to valves/pumps is connected, but no way to tell remotely).

• KA imagines that FB took some finite time to come up. However, the RT machines required FB to download the OS. That made the RTs down. If so, what we need is to power cycle them.

• Acromag: unknown state

​The power was lost at Apr 12 22:39:42, according to the vacuum pressure log. The power loss was for a few min.

In the past year, pygwinc has expanded to support not just fundamental noise calculations (e.g., quantum, thermal) but also any number of user-defined noises. These custom noise definitions can do anything, from evaluating an empirical model (e.g., electronics, suspension) to loading real noise measurements (e.g., laser AM/PM noise). Here is an example of the framework applied to H1.

Starting with the BHD review-era noises, I have set up the 40m pygwinc fork with a working noise budget which we can easily expand. Specific actions:

• Updated the 40m fork to the latest pygwinc version (while preserving the commit history).
• Added a directory ./CIT40m containing the 40m-specific noise budget files (created by GV).
• Added an ipython notebook CIT40m.ipynb at the root level showing how to generate a noise budget.
• Integrated our DAC and seismic noise estimators into pygwinc.
• Marked the old 40m NB repo as obsolete (last commit > 2 yrs ago). Many of these noise estimates are probably stale, but I will work with GV to identify which ones can be migrated.

I set up our fork in this way to keep the 40m separate from the main pygwinc code (i.e., not added to as a built-in IFO type). With the 40m code all contained within one root-level directory (with a 40m-specific name), we should now always be able to upgrade to the latest pygwinc without creating intractable merge conflicts.

Answers from Dolphin:

1. No, and kernel 4.x (modern Linux) definitely will not work with the Gen1 cards.
2. No, cards using different PCIe chipsets cannot be mixed.

Since upgrading every front end is out of the question, our only option is to install an old OS (Linux kernel < 3.x) on the two new machines. Based on Keith's advice, I think we should go with Debian 8. (Link to Keith's Debian 8 instructions.)

I don't have a recent measurement of the optical gain of this config so I can't undo the loop, but in-loop performance doesn't suggest any excess in the 10-100 Hz band. Interestingly, there is considerable improvement below 10 Hz. Maybe some of this is reduced A2L noise because of the better angular stability, but there is also improvement at frequencies where the FF isn't doing anything, so could be some bilinear coupling. The two datasets were collected at approximately the same time in the evening, ~5pm, but on two different days.

that's pretty great performance. maybe you can also upload some code so that we can do it later too - or maybe in the 40m GIT

I wonder how much noise is getting injected into PRC length at 10-100 Hz due to this. Any change the PRC ERR?

Summary:
Using the data I collected yesterday, the POP angular FF filters have been trained. The offline time-domain performance looks (unbelievably) good, online performance will be verified at the next available opportunity(see update).

Details:

The sequence of steps followed is the same as that done for the MCL FF filters. The trace that is missing from Attachment #1 is the measured online subtraction. Some rough notes:

• The "target" channels for the subtraction are the POP QPD PIT/YAW signals, normalized by the QPD sum. For the time that the PRMI was locked yesterday, the QPD readouts suggested that the beam was well centered on the QPD, but the POP QPD (OT-301) doesn't give me access to individual quadrant signals so I couldn't actually verify this.
• I used 64s impulse time on the FIR filter for training. Maybe this is too long, but anyways, the calculation only takes a few seconds even with 64^2 taps.
• I found that the Levinson matrix algorithm sometimes failed for this particular dataset. I didn't bother looking too much into why this is happening, the brute force matrix inversion took ~4 times longer but still was only ~5 seconds to calculate the optimal filter for 20 mins of training data sampled at 64 Hz.
• The actuator TF was measured with >0.9 coherence between 0.3 Hz - 10 Hz and fitted, and the fit was used for subsequent analysis. Fit is shown in Attachment #2.
• FIR to IIR fitting took considerable tweaking, but I think I got good enough fits, see Attachments #3, #4. In fact, there may be some benifit to making the shape smoother outside the subtraction band but I couldn't get IIRrational to cooperate. Need to confirm that this isn't re-injecting noise.

Update Apr 5 1145pm:

• Attachment #1 has now been updated to show the online performance. The comparison between the "test" and "validation" datasets aren't really apple-to-apple because they were collected at different times, but I think there's enough evidence here to say that the feedforward is helping.
• Attachment #5 shows that the POP DC (= PRC intracavity buildup) RMS has been stabilized by more than x2. This signal wasn't part of the training process, and I guess it's good that the intracavity power is more stable with the feedforward on. Median averaging was used for the spectral densities, there were still some abrupt glitches during the time this dataset was collected.
• _{The next step is to do the PRFPMI locking with all of these recently retuned feedforward loops engaged and see if that helps things}.

I wanted to pass along a complication pointed out by K. Thorne re: our plan to use Gen1 (old) Dolphin IPC cards in the new real-time machines: c1bhd, c1sus2. The implication is that we may be forced to install a very old OS (e.g., Debian 8) for compatibility with the IPC card driver, which could lead to other complications like an incompatibility with the modern network interface.

I have a query out to Dolphin asking:

1. Have they done any testing of these old drivers on Linux kernel 4.x (e.g., Debian 9/10)?
2. Is there any way to buy modern IPC cards for the two new machines and interface them with our existing Gen1 network?

I'll add more info if I hear back from them.

Yehonathan's list does include C1:AUX-GREEN_Y_Shutter and I copied its definition from /cvs/cds/caltech/target/c1aux/ShutterInterlock.db into the new ETMYaux.db file.

I noticed ShutterInterlock.db still contains about a dozen channels. Some of them appear to be ghosts (like the C1:AUX-PSL_Shutter[...] set, which has since become C1:PSL-PSL_Shutter[...] hosted on c1psl) but others like C1:AUX-GREEN_X_Shutter appear to still be in active use.

We want to migrate the end shutter controls from c1aux to the end acromags. Could you include them to the list if not yet?

This will let us remove c1aux from the rack, I believe.

I used Yehonathan's wiring assignments to lay the rest of groundwork for the final slow controls machine upgrade, c1auxey. Actions completed:

• Created an internal wiring diagram for assembling the Acromag chassis (log in with LIGO.ORG credentials to view/edit)
• Created a new target directory on the network drive:

The "1" will be dropped after the new system is permanently installed.

• Populated the target directory with files:
  • modbusIOC.service - wraps the EPICS IOC as a systemd service
  • ETMYaux.env - defines the EPICS environment variables
  • ETMYaux.cmd - command file to set up the EPICS IOC
  • ETMYaux.sh - enables DAC outputs to the suspension (executed lastly)
• Created the EPICS channel databases:
  • ETMYaux.db - migration of the existing database
  • c1auxey_state.db - contains logic for loopback monitoring of the IOC "alive" state (visible from Sitemap > CDS > Slow Controls Status)

Hardware-wise, this system will require:

• 2 Acromag XT-1221 units (ADC)
• 1 Acromag XT-1541 unit (DAC)
• 1 Acromag XT-1111 unit (sinking BIO)

I know that we do have these quantities left on hand. The next steps are to set up the Supermicro host and begin assembling the Acromag chassis. Both of these activities require an in-person presence, so I think this is as far as we can advance this project for now.