To get to the bottom of the RFAM mystery, we've got to resurrect the StochMon to trend the RFAM after the IMC.

We will put an 1811 on the MC_TRANS or IP_POS beam (the 1811 has an input noise of 2.5 pW/rHz).

Then the Stochmon has an input pre-amp, some crappy filters, and then Wenzel RMS->DC converters. We will replace the hand-made filters with the following ones from Mini-Circuits which happen to match our modulation frequencies perfectly:

11 MHz     SBP-10.7+

55 MHz     SBP-60+

29.5 MHz   SBP-30+

The Stochmon had a four-way splitter, four hand-made filters and four mini-circuits ZX47-60-S+ Power Detectors.

Using the filters from our stock I have replaced the hand-made filters with the ones mentioned in Rana's elog.   The power supply solders to the ZX47-60-S+ Power Detectors were weak and came off during reassembly. And some of the handmade short SMA cables broke off at the neck.  So I changed the power supply cables and replaced all the short SMA cables with elbows.  I also removed one of the Power Detectors since there were four in the box and we need only three now.

The power supply connector on the box is illegal.  The current lab standard for  {+15, 0 , -15}  uses that connector.  So we are going to change it as soon as possible.  We need to identify a good {0, 5} lab standard and stock them.

The following were removed from the box:

The box now looks like this:

Steps remaining in installation of Stochmon:

1) Install the Newfocus 1811 PD at the IPPOS by diverting some of the power in that path

2) Connect the outputs of the Stochmon to ADC inputs in 1X2 rack.

I added the StochMon calibrated channels to the data trend by including the following channel names in the C0EDCU.ini file:

[C1:IOO-RFAMPD_33MHZ_CAL]
[C1:IOO-RFAMPD_133MHZ_CAL]
[C1:IOO-RFAMPD_166MHZ_CAL]
[C1:IOO-RFAMPD_199MHZ_CAL]

Before saving the changes I committed C0EDCU.ini to the svn.

Then I restarted the frame builder so now the new channels can be monitored and trended.

I also removed two of the AM stabilizers from the 1Y2 rack. The other one, which is currently running th MC modulations, is still in the rack, and there it is going to remain together with its distribution box.

I stored both AM stabilizers and the Stochmon box inside the RF cabinet down the East arm.

Now stochmon for 11MHz and 55MHz is running. The calibration / noise measurement are going to be post later...

Here is a 48 hours trend of the RFAM monitor (a.k.a StochMon):

The upper plot is the DC output from the StochMon PD and the lower plot shows the calibrated RIN (Relative Intensity) at each modulation frequency.

I have downloaded minutes trends of StochMon for 48 hours staring from 6:00AM of Nov/24.

I followed Koji's calibration formula (#6009) to get the actual peak value (half of the peak-peak value) of the RF outputs and then divided them by the DC output to make them RIN.

It looks the RINs are hovering at ~ 4 x 10^-4 and fluctuate from 1x10^-4 to 1x10^-3. Those numbers agree with what we saw before (#5616)

So it seems the StochMon is working fine.

Update of the stochmon status

[Attachment 1: Circuit diagram]

- The new stochmon has a low noise amplifier (MAR-6SM) inside.
The RFAM signal from the PD has the power of -60~-50dBm, which is almost at the bottom of the sensitivity for the power detector.

- The band pass filters were doubled.

- I've suffered from some RF coupling from the power line as the power detector is quite sensitive to it.
The situation has been largely improved by the EMI filters in the power supply path, although the problem is still present.
The worst remaining problem is that we can not close the aluminum lid as it cause a huge sprious coupling.

[Attachment 2: Calibration result]

- The outputs were calibarted with Marconi. They showed the signals linear to dBm for the input powers between -70dBm and -10dBm.

- The calibration result was fitted with the empirical fit function. The function and the results are shown in the attachment.

[Attachment 3: Detection limit]

- The attached figure shows the power spectrum of the PD output. This measurement gives us the amount of the RF power given from the PD noise when there is no RF signal.

11MHz out passband noise: −72.7dBm ===> V11 = 2.0483
30MHz out passband noise: −64.6dBm ===> V30 = 1.9333
55MHz out passband noise: −71.2dBm ===> V55 = 2.0272

- Now 11MHz and 55MHz outputs seem indicating the power correctly, but the 29.5MHz output never provides useful information.
It is a constant value independent from the state of the incident beam. Strangely this problem disappears if the marconi is used
for the RF source. Thus this issue is not seen in the calibration measurement.

- So far, 11MHz, 29.5MHz, 55MHz, and DC outputs appear in the channels C1:IOO-RFAMPD_33MHZ, C1:IOO-RFAMPD_133MHZ, C1:IOO-RFAMPD_166MHZ, and C1:IOO-RFAMPD_199MHZ.
They will be renamed.

 New RFAM mon calibration

Is there an update on Stochmon?  Are the signals acquired somewhere already?  What's the current deal-io?  The new EOM mount should be here later today, and I'm jazzed to start checking how my EOM box helps (hopefully) the amount of RFAM we see. 

I'll start making the adapter plate while I wait...

The  Stochmon channels for 11&55MHz have been reasonably working since last night.

The output is not yet calibrated as the RF power detector has a strange scaling.
I am analyzing the calibration data.

It turns out that we don't have all the parts I would need to do a full prototype of the precision temperature controller. I am guessing that we won't want to sit around and wait for the parts given the upcoming TAC meeting, so I'll do the next best thing:

• Standard DC temperature readout using an AD590.
• More-or-less complete heater driver

Does anyone have a suggestion for how this thing will be packaged? I.e., should it be in a box or should it be mounted in a rack, etc. In the end, a real board will be printed and stuffed, so this need not be a really professional job in the short term.

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%

LO Path

The LO relay path is shown in Attachment 2:

• LO1-LO2 Gouy phase separation: 67°
• Mode-matching to OMC: 98.6%

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.

I closed the shutter of the NPRO for the night.

@Yuta

The ITMX table has been left open since yesterday. I am disconnecting your oscilloscope and closing the table.

To whomsoever it may concern...

I found about half a dozen new cvi optics (beam splitters, waveplates and lenses) lying around on the SP table.

Please store optics back in their respective cabinets if you are not using them immediately. Somebody might be looking around to use them. 

I'm not the one who opened the ITMX table yesterday, but thanks for reminding me.
I put POP DC oscilloscope and its cables back.

Also, I relocked PMC and MC. It was unlocked since last night.

Lacking a better place, I've chosen the cabinet down the Y arm which had ethernet cables and various VME cards as a location to store some spare CDS computer equipment, such as harddrives.  I've added (or will add in 5 minutes) a label "FE COMPUTER HARD DRIVES" to this cabinet.

[JC, paco]

This morning we noted most optics were tripped, probably as a result of a recent M>5 earthquake in the area (on Sun 08/20). Most optics were restored and damped nicely, except for ITMY.

PMC locked to HOM --> realigned and locked

We aligned PMC to maximize its transmission to ~ 0.670, after this IMC was locked and we engaged the WFS to recover the alignment.

ETMY oplev laser --> replaced aligned and locked

Most suspended optics were restored, but we noticed the OpLev sum on ETMY and ITMY were too low so we checked the lasers on both optics. The ITMY HeNe laser is on, but the one on ETMY is off. JC tested with a new laser head and the controller was determined to be good. Then, we tried resetting the previous one (labeled Oct 25 2020) but didn't have luck, so yet another HeNe laser died. We removed the old one and luckily our spare had the same form factor so it wasn't hard to recover the nominal alignment. After this we verified that the OPLEV loops on ETMY were working.

ITMY local damping --> still "stuck" or worse

The local damping on ITMY is not working properly. This puts it in a weird alignment state which is why we also don't see a large Oplev sum count on the QPD. The shadow sensor (OSEM) signals are all small, the available rms monitors are ~ 0.0, 0.1 mV, and kicking the optic around doesn't produce a corresponding OSEM signal, even when undamped. Therefore, we believe ITMY is either stuck (UR/LR) or worse. We tried the usual "shake" technique but didn't see any sensors being restored.

[JC, Koji-remote, paco]

ITMY stuck --> Shaken remotely and restored, ARMS aligned

With Koji's assistance we restored ITMY (it was stuck) and finished aligning both arms. Then JC centered the OpLevs for ETMs, ITMs and BS

ITMY camera blinking --> Replaced camera

JC checked the situation with our ITMYF (face) camera as the image seemed faulty and blinking. The issue this time was not in the power supply as has been before, but rather the CCD itself. After replacing the unit and aligning the ARM cavity, we redrew the marker "guides" on the control room screen for quick reference.

In order to fix ELOG search, I have started running ELOG v2.9.2 on Nodus.

Sadly, due to changes in the software, we can no longer use one global write password. Instead, we must now operate with registered users.

Based on recent elog users, I'll be creating user accounts with the following names, using the same old ELOG write password. (These will be valid across all logbooks)

• ericq
• rana
• koji
• diego
• jenne
• manasa
• Steve
• Kate
• Zach
• Evan
• Aidan
• Chris
• Dmass
• nicolas
• Gabriele
• xiaoyue

All of these users will be "Admins" as well, meaning they can add new users and change settings, using the "Config" link.

Let me know if I neglected to add someone, and sorry for the inconvenience.

RXA: What Eric means to say, is that "upgrading" from Solaris to Linux broke the search and made us get a new elog software that;s worse than what we had.

 So, despite having registered users, it turns out that the "Author" field is still open for editing when making posts. I.e. we don't really need to make new accounts for everyone. 

Thus, I've made a user named "elog" with the old write password that can write to all ELOGs. 

(Also, I've added a user called "jamie")

I tried to find my own entry and faced with a strange behavior of the elog.

The search button invoked the following link and no real search has been done:

http://nodus.ligo.caltech.edu:8080/40m/?mode=summvry&reverse=0&reverse=1&npp=50&m&y&Authorthor=Koji

Summvry? Authorthor?

If I ran the following link, it returned correct search. So something must be wrong.

http://nodus.ligo.caltech.edu:8080/40m/?mode=summary&npp=50&Author=Koji

I did the same test we did in 40m/17616 to see if DACs are working fine for ITMX and ITMY.
I used awggui to excite all the coil outputs of the optic with 0.1 Hz with an amplitude of 3000 counts, and checked VMons.
Found that ITMX, ITMY, PRM and BS face coil DAC outputs cannot drive positive voltages. In contrast, SRM is fine (see attached).
This is consistent with what we have found in June (40m/17616).
We need to investigate what is causing this DAC failure...

For some reason ETMY has changed a lot.  Not only does it now have the worst "badness" (B matrix condition number) at ~10, but the frequency of all the modes have shifted, some considerably.  I did accidentally bump the optic when Jenne and I were adjusting the OSEMs last week, but I didn't think it was that much.  The only thing I can think of that would cause the modes to move so much is that the optic has been somehow reseated in it's suspension.  I really don't know how that would have happened, though.

Jenne and I went in to investigate ETMY, to see if we could see anything obviously wrong.  Everything looks to be ok.  The magnets are all well centered in the OSEMs, and the PDMon levels look ok.

We rechecked the balance of the table, and tweaked it a bit to make it more level.  We then tweaked the OSEMs again to put them back in the center of their range.  We also checked the response by using the lockin method to check the response to POS and SIDE drive in each of the OSEMs (we want large POS response and minimal SIDE response).  Everything looked ok.

We're going to take another freeswing measurement and see how things look now.  If there are any suggestions what should be done (if anything), about the shifted modes, please let us know.

 We have placed some sweet giant strawberries in the fridge; free for eating for anyone working in the lab today or tomorrow:

Steve, Kiwamu, and Koji

We went through the PSL table to make sure any strong beam did not hit the wall.

We found that the reflection of Stephanie's OSA returned its path down to the beamsplitter.
This BS reflect that beam to the wall. That was fixed.

The surprising was that the relatively strong beam (~1mW?) went through the steering mirror
just before the PMC. We put thorlabs razor blades. I am still thinking what this indicates...
because the beam had been blocked if it was such from long time before.

During the work we found some stray optics such as a cube BS, a flipper mirror, and so on.
We can see them in the photo as those enclosed with yellow circles.
One of the beams was obtained from the reflection of the ND filter (...almost illeagal), and 
was even hittting a metal fixture for the BS cube.

If someone uses these components for useful purposes,
please let me(Koji) know. Otherwise, they are removed next week.

The other thing we found was the bright scatter from the EOM for the PMC.
As this scatter is so blight, I am going to align it.

 These components are from when Rana and I used the StochMon PD to do the RFAM tuning, documented in elog 1926.  This was a very handy measurement, but I'm not sure if whether or not we need it often enough to keep the optics there.

OK! I saw the optics are redundant and some of the components are not in a right place.
I will talk with you when you are back such that we can keep the usefulness of the setup.

You can remove the RFAM measuring setup. Once we upgrade, we will no longer have a MZ or the related problems.

I inserted several beam blocks and iris on the Y arm Green table. There was/is lots of stray light because a lot of the mirrors are not under an angle of incident of 45°. Some stray light is left since couldn't find an appropriate beam block/dump due to lack of space on the table.

The Streckeisen is currently plugged into ADC channels 13, 14, and 15 (corresponding to STS-3 in the channels). The X, Y, and Z components are correct. The signals is zeroed (it's been so for at least the past 10 hours), the coherence with GUR1 looks decent, and the signal looks similar to the GUR1 signal.

Also deleted the ~50GB error files from ldas to prevent rsync from copying them to nodus again. With the new update to GWsumm, there are new error messages that initially didn't seem to affect the summary pages functionality, but in the extreme case can populated the error files the repeated warnings on the form "Loading: FrSerData", "Loading: FrSerData::n4294967295", "Loading: FrSummary","Loading: FrSerDataLoading: FrSerData" and many more combinations until we get file sizes of the order of ~50GB. So I have updated the checkstatus script to parse the error files and strip out the majority of these error messages. Work is ongoing to get them all.

In light of these large files generation, I decided to look in the summary pages folder to see if there are other large files that we need to keep track of and it turns there are indeed a collection of files in the archive folder that bloats the summary pages on ldas to ~1TB. Luckily these are not synced to nodus so no problem here. However, since the beginning of the year, the archive folders that hold data used for each day's computation have not been cleared. We have a script for doing this but it has not been run for a while now and it only delete archive files for a specific month which is hardcoded to two months from the date the file is run. I have modified the code to allow archive deletion for a range of months so we can clear data from Jan to July. 

As a test, I have replaced the PSL StripTool on the north wall of the control room with a nearly equivalent NDScope display. It is plotting the real time second trend along with min/max values. Let's try this out for awhile, and if its bad we can just close the window.

FYI, the striptool machine, zita, has a mis-configured network setup so that its not getting a useful nameserver. So for now, its running on allegra through ssh -Y. We should put the zita network thing on some sort of issue tracker. Maybe we can have tickets and issues like various companies use for tech support? This could cover all of our main lab work and help us keep track of little problems like this.

When I run StripTool on Pianosa, I get the following message

==== StripTool Xt Warning Handler ====
warning:         Axis: minVal is greater than or equal to maxVal

And the y-axis scale reverts to 0 -100 regardless of what ever I set in the controls panel

I ssh'ed into rosalba and ran striptool from there and did not face this problem.  So I think pianosa has a problem with Striptool.

ssh -X pianosa

On pianosa

StripTool PSL.strip&
StripTool IOO.strip&
StripTool seismic.strip&

The RMS signals generated by the updated filtering process are now on the wall. The NaN issue is gone it seems, and the template has been changed. Thanks for your help, Jenne. 

I've uploaded some more photos here. I believe the problem is a worn out thread where the main rotary handle attaches to the shaft that operates the valve.

This morning, I changed the valve config such that TP2 backs TP1 and that combo continues to pump on the main volume through the partially open RV2. TP3 was reconfigured to pump the annuli - initially, I backed it with the AUX drypump but since the load has decreased now, I am turning the AUX drypump off. At some point, if we want to try it, we can try pumping the main volume via the RGA line using TP2/TP3 and see if that allows us to get to a lower pressure, but for now, I think this is a suitable configuration to continue the IFO work.

There was a suggestion at the meeting that the saturation of the main volume pressure at 1mtorr could be due to a leak - to test, I closed V1 for ~5 hours and saw the pressure increased by 1.5 mtorr, which is in line with our estimates from the past. So I think we can discount that possibility.

I locked the arms using ALS error signals and the LSC filter modules. But when I try to acquire CARM and DARM using ALS, the arms lose lock when the matrix elements ALSX to Yarm and ALSY to X arm reach -/+0.9

What I did:

1. ALS locking of arms
(i) Found arm beat notes
(ii) Input matrix POX and POY elements set to '0'
(iii) Aux matrix elements ALSX to Xarm and ALSY to Y arm set to '1'
(iv) Power normalization matrix elements for TRX and TRY set to '0'
(v) Triggers for arm lock over ridden and the FM triggers were set to 'manual'
(vi) Arm servo gains set to '0'
(vii) All but FM5 were disabled
(viii) Phase tracker history reset and servo actuation set to ETMs
(ix) Servo gain increased in steps (+/-10 for the arms)
(x) FM1, FM6, FM7 enabled (see note 1 below)
(xi) FM9 enabled

Arms were locked with ~2000Hz rms

2. CARM and DARM locking
(i) Scanned the arms for IR resonance
(ii) Moved off-resonance (Stepped arm servo offsets by 30 counts)
(iiI) Stepped matrix elements ALSY to X arm and ALSX to Y arm ezcastep C1:LSC-PD_DOF_MTRX_6_29 +-0.1 C1:LSC-PD_DOF_MTRX_7_28 +0.1

Whenever the matrix elements reached -/+0.9, the arms were kicked out of lock. I don't see anything obvious as to why this is happening even after nearly 10+times of redoing.

Notes:
1. I found the filters for the arm servos different for X and Y. FM1 and FM8 were missing in one of the filter modules. Jenne remembered Rana modifying and removing the unnecessary filters in one arm. We put back FM1 (low pass filter) which might not be necessary for PDH lock but is necessary for ALS. FM8 is now added to FM7.
2. To self : Check ALS Y arm power outlets (60Hz frequency comb seen in the error signal)

You don't need to make transition from ALS X/Y to ALS C/D. Just stabilize the arms with ALS C/D from the beginning.

I made some simulation to study the change that the heater setup can induce on the Radius of Curvature of the ETM.

Heat pattern

First, I used a non-sequential ray tracing software (Zemax) to calculate the heat pattern. I made a CAD of the elliptical reflector and I put a radiative element inside it (similar to the rod-heater 30mm long, 3.8mm diameter that we ordered), placing it in such a way that the heater tip is as close as possible to the ellipse first focus. (figure 1)

Then, by putting a screen at the second focus of the ellipse (where we suppose to place the mirror HR surface), I could find the projected heat pattern, as shown in figure 2 and 3 (section). Notice that the scale is in INCH, even if the label says mm. As you can see, the heat pattern is pretty broad, but still enough to induce a RoC change. 

Mirror deformation

In order to compute the mirror deformation induced by this kind of pattern, I used this map produced with Zemax as absorption map in COMSOL. I considered ~1W total power absorbed by the mirror (just to have a unitary number).

The mirror temperature and deformation maps induced by this heat pattern are shown in figures 4 and 5. 

RoC change evaluation

Then I had to evaluate the RoC change. In particular, I did it by fitting the Radius of Curvature over a circle of radius:

where  is the waist of tha Gaussian mode on the ETMY (5mm) and n is the mode order. This is a way to approximately know which is the Radius of Curvature as "seen" by each HOM, and is shown in figure 6 (the RoC of the cold mirror is set to be 57.37m). Of course, besides being very tiny, the difference in RoC strongly depends on the heat pattern.

Gouy phase variation

Considering this absorbed power, the cavity Gouy phase variation between hot and cold state is roughly 15kHz (I leave to the SURFs the details of the calculation).

Unanswered points

So the still unaswered questions are:

- which is the minimum variation we are able to resolve with our measurement

- how much heating power do we expect to be projected onto the mirror surface (I'll make another entry on that)

 I studied the eigenfrequencies of a mirror mount designed with COMSOL.

I imposed fixed constraints for the base screws and for the screw connecting the base with the pedestal. Note that the central screw is connected to the base only for a small thickness, and the pedestal touches the base only with a thin annulus. This is in way to make a better model of the actual stress.

Shown in fig. 2 is the lowest eigenfrequency of the mount.

I' going to change the base and study the way the eigenfrequency vary, in way to find the configuration which minimizes the lowest eigenfrequency.

Here is a partial list of stuff which is being packed at LLO to be shipped to CIT.  The electronics ckt boards are yet to be added to this list.  Will do that tomorrow.

I think the only part missing for assembly now are 4 2U chassis. The PA95s need to be soldered on as well (they didn't arrive in time to send to SC). The stuffed boards are stored under my desk. I inspected one board, looks fine, but of course we will need to run some actual bench tests to be sure.

I put Jenne's cooler over the seismometers. Kiwamu put the copper foil wrapped lead brick on top of the cooler to hold it down. I also put another (unwrapped) lead brick on top of the Guralp cables outside of the cooler. Frank gave me a knife with which I cut a little escape hole in the bottom of the cooler lip for the Guralp cables to sneak out of.