[Jeff, Daniel]

We cleaned the top and inside of a 10 in vacuum cube that is slated to hold the power recycling optics for the power recycling cavity. We used the TWTX8410 (Pre-wetted Vectra Wipes (Alpha Red Wet)) for the knife edge and inside of the vacuum chamber. While opening this bag, we seemed to break the resealing mechanism, so we wrapped the bag in UHV foil and put it in an anti-static bag. We put in a new copper gasket since the old one was very dirty. We inspected the bottom of the top 10" flange, and it was clean enough to put back on the cube. The next step is the tip over the cube and replace the bottom 10" flange with the one I machined (with tapped holes).

Some notes on preferred networking setup now that I see machines going up with posts:

https://mccullerlab.com/logs/lab/index.php?callRep=11985

and https://mccullerlab.com/logs/lab/index.php?callRep=11998

The lab LAN uses a specially configured subnet and DHCP. You should not need static IP addresses, since the DCHP server remembers and maintains the assigned addresses.

The subnet settings are:

192.168.248.1/21 (equivalent \21 mask is 255.255.248.0)

The gateway is 192.168.248.1

broadcast address is: 192.168.255.255 (can be calculated from the above with the tool https://jodies.de/ipcalc?host=192.168.248.1&mask1=21&mask2=21)

the following addresses are supported:

HostMin:   192.168.248.1    
HostMax:   192.168.255.254  
Hosts/Net: 2046

The synology is running the internal DNS server a internal LAN address 192.168.248.15 so it should be included in your resolve.conf or equivalent. DHCP currently assigns it as the secondary DNS server. The primary is a preferred CIT server. We could make the internal DNS the primary, but may have bigger issues if/when it goes down.

if you assign static IP's, please only assign them to addresses already registered by the DHCP to the particular MAC address of the interface.

I am following this DCC document to configure the BIOS settings of Turing, one of our front-end machines. 

Machine info

sudo dmidecode -s baseboard-product-name

X11SRL-F

sudo dmidecode -s processor-version

Intel (R) Xeon(R) W-2245 CPU @ 3.90GHz

The BIOS version is 2.8.

BIOS settings

First, I reset all BIOS settings to default using 'Restore Defaults' in the 'Save & Exit' menu.

Advanced > CPU Configuration: Hyper-Threading [ALL] - Disabled

Advanced > CPU Configuration > Advanced Power Management Configuration > CPU P State Control: SpeedStep (Pstates) - Disabled

Advanced > CPU Configuration > Advanced Power Management Configuration > CPU C State Control: Enhanced Halt State (C1E) - Disabled

Advanced > CPU Configuration > Advanced Power Management Configuration > Package C State Control: Package C State - C0/C1 state

Advanced > PCIe/PCI/PnP Configuration: Above 4G Decoding - Enabled

IPMI > BMC Network Configuration: Update IPMI LAN Configuration - Yes

IPMI > BMC Network Configuration: Configuration Address Source - Static

IPMI > BMC Network Configuration: IPv6 Support - Disabled

I will need to follow up about the Station IP address. What is the local CDS admin LAN? Will we be doing this? For now I have set the static IP address to be the same address that was DHCP assigned.

The LIGO outreach interferometer got upgraded to a real breadboard and ThorLabs parts. They needed a way to mount their laser pointer. I used the plastic mount from the old mount as well as some of the half-inch hardware to mount it.

This equipment includes:

• 1/2 inch post. Four inches long (1)
• 1/2 inch post. One inch long (1)
• 90 degree 1/2 inch post connector (1)
• 1/2 post base. One inch tall (1)
• post holder base (1)
• Associated screws

[Sander, Daniel, Jeff]

We have powered on the seeder laser and amplifier in B111B and confirmed a beam on the optical table. The initial Faraday isolator is not aligned, and we powered off the amplifier and laser until tomorrow morning. Both the seeder and amplifier are plugged into the Furman power conditioner as described here. Here was our procedure:

First, power on only the seeder and verify that it is producing light by placing a power meter at the output of the power beamsplitter where the beam dump usually is. We saw 15mW on the power meter and then replaced the beam dump.

Next, we powered on the amplifier by first plugging it into a delay 2 slot on the Furman and then flipping the switch on the back of the laser amplifier. We adjusted the fiber polarizing beam splitter paddles (between the seeder laser and amplifier) until the input power to the laser amplifier read 24mW. We then turned the key on the amplifier and hit enable. There is a beam coming onto the table! Seen with a high power beam viewer card.

The beam is not making it through the Faraday isolator, and this does not change even when rotating the half wave plate, so we conclude it is not aligned.

We proceeded with a shutdown procedure, confirming the current was minimized on the amplifier, hitting disable, then turning the key in the laser amplifier. Next we turned off the seeder using the switch on the front, and finally we powered everything off using the Furman. The Furman shutdown sequence is quite long (2 minutes) as it is currently configured, we will shorten it to 30s total before turning on the system again.

[Lee, Sander, Daniel]

I got two copies of a key for a fire cabinet in B102B that holds chemicals. All 3 keys turn the lock. However, Sander and I couldn't figure out how to use the key to actually lock the cabinet. It seems like you would want to remove the key after turning it 90°, but this wasn't (easily) possible.

[Jeff, Daniel, Sander]

The Furman CN-2400S power conditioner has been placed under the laser amplifier on the electronics rack and is powered by a blue NEMA L5-20 socket above the optical table.

The delay setting is set to one minute between each stage (the 2 minute switch is "on" and the pot is set to 50%), we plan to put the seeder on delay 1 and the amplifier on delay 2. Delay 1 turns on immediately after turning the key. Delay 2 switches on one minute after, and delay 3 an additional minute after that, we confirmed the timing with iPad chargers. To change the delay settings one must unscrew the plastic cover on the front center and use the switches/potentiometer (see manual).

The power cable runs alongside the patch panel cables before routing under the table.

This post is going to cover how to build the ASC DHARD Yaw model (abbreviated ADY) in Buzz. The first step is to make sure that you are on the dev branch the main branch hasn't been updated in a long time (I should do that). the folder for the most up to date ADY model is in the test/ASC_SOLVER folder (not the test/ADY folder). there are a number of model type folders inside of this folder. Basically there is a few ways to attach different FOMs to different outputs of the model. the one we are interested in is the ExampleModels_newFOM. In the folder for this configuration you will find all of the different fits to environmental noise and measurement noise as well as the BNS FOM fit that comes from the test/FOMs folder. None of this should be touched. As it is all been put in this folder to make a specific configuration for this model. The configuration for this model is the basic both FOMs come out of the plant output. To run the code to build this model run the command:

This should run the code in the file T_ADY_make_sys.py that builds the system. It also generates plots to assess if everything was put together correctly. I will now go through these plots and explain what all the important ones say about the model.

FOM_bode.pdf: This plot shows what the two FOMs. Note the scale of these two FOMs is set so that the max of the BNS FOM is 1. It will be rescaled when it gets solved.  

Noise_bode.pdf: This is the most basic plot showing the inner workings of the model. Much like the next plot it is showing the individual components that are going into the function makeSPOFF(). All of the labels are rather self explanatory where "S*P" is the product of the plant and the environmental noise.

SPOFF_diagnostic_bode.pdf: This plot is showing the internal workings of the model. It is showing transfer functions for a number of the components. "P alone" is the plant that was put into the makeSPOFF() function. All the other traces are from the final connected model and are as follows

• "P to P in SPOFF" in the code SPOFF['P.out', 'P.in']: this is what the plant looks like in the model after it has been altered with the makeSPOFF() function

• "S to P" in the code SPOFF['P.out', 'S.in']: this is the path from the environmental noise in (S.in) to the output of the plant. This should be independent of how much of the plant was moved out of P since it is the product of SP.

• "S to S" in the code SPOFF['S.out', 'S.in']: this is the original environmental noise and the as well as the part of the plant that was moved over (P complement)

• "P Recombined" in the code SPOFF['P.out', 'SA.in']: this is the parts of the plant that were separated and should be the same as "P to P in SPOFF". It is the same in the plot attached it is really hard to see because the blue is behind the brown

• "P that moved to S" in the code SPOFF['S.out', 'SA.in']: this is the part of the plant that was moved to the environmental noise section (S). It also should line up with "P to P in SPOFF" because all of the plant's shape should have been moved to the environmental noise.

• "Orig. S" in the code SPOFF['G.out', 'S.in']: this is the original S and should be alone because we don't plot the non SPOFF S in this plot.

With all of the plots produced the configuration folder ExampleModels_newFOM should be automatically updated with the newest version with whatever changes you made. After that run the tests T_calc_H2, T_plot_H2, T_calc_HiB, and T_plot_HiB with the [ExampleModels_newFOM] option to run the solver with your model.

I got the switch that we loaned to Paco back on Friday (see [11983]). It originally came from B102 but since we are moving everything to B111 I decided to put it in the new rack. I placed it on the back of the new rack because that is where most of the networking will go. There was already a small switch there that I unplugged and replaced with this larger switch. This should allow for more expansion in this rack. This work took place on Friday but the log was delayed by the drill press falling. See attached photo for position in rack.

When securing the WEN Drill Press to the table in the mech. shop the base of the press broke in two. The drill press then fell forward off the table. I was under the table and only got hit lightly. The crack happened along the weak point on the cast iron where the most pressure was exerted from the tightening of the bolts. I was tightening the bolts that fasten the drill press to the tabel when the base broke. I had not over tightened the bolts, or at least I thought. The base of the press is poorly designed cast iron that did not have solid support for the bolts. My guess is that there was a defect in the cast iron that gave way when any amount of pressure was put on it. Cast iron snaps really quickly and does not bend at all so it was poorly designed when they did not have a solid connection from where the bolt would pull on the base to the table. We will need to either buy a new drill press, replace the base of this drill press, or attach the drill press by the support rod. The last one is not recomended. Daniel and I put the drill press on its side back on the table and tested it breifly to make sure the head still spun. It does. the light and lasers also still work. The chuck of the drill press got unseated and came out when I pulled on it. The press hit the shop vac when it fell but the shop vac seems okay. we tested it.

I successfully attached the bench vice to the table. The table is made out of a very hard material and I had to use the masionary bits to drill the holes in it. I attached it with locking nuts, locking washers, and loctite blue.

[Ian, Daniel]

We lightly re-tapped (with what looks to be a plug tap) the problematic tapped hole in the 10" Vacuum Cube and discovered a bit of debris 1.6" deep in the problematic hole. The threads are not good before this debris, but this debris would interfere with a 1.75" screw. The holometer used 1.5" long screws for this flange. The debris looks like the end of a drill bit or tap; maybe the bad threads and this drill bit are related (someone broke this tip trying to fix the threads, or this tip was broken and therefore the tapping did not go deep enough.)

We tried to remove the debris with some tweezers and a pick, but it seemed to be stuck.

We then inserted a 1.5" screw with an external hex head and tightened it to 30 Nm. I will label this hole on the cube.

[Jeff, Daniel]

I took an existing 24" tall 19" Electronics Rack and drilled holes in the two side panels for #10 screws using a #3 bit (the height of the width of the existing slots). These holes were both 1.125" from the top. One hole was 0.54" from the inside of the "jut out" that holds the shelves, the other was 1.25" further back (so 1.79" from the inside of the jut out). Note that these holes are further from the jut out than the existing slots so that the cross bar can fit behind the jut out instead of above it.

I then cut ~0.7" off the panels using a band saw in the MCE shop. These panels are made of steel, so I used the band saw meant for steel. I did this after drilling the holes so that I could clamp the panels more easily.

We then assembled the electornics rack, attached the shelf, and placed the SHG Temperature Controller on it. The new rack fits nicely under the optics table.

See the attached picture.

I've assigned the Moku Pros static IP addresses on the device, and added entries to the Pi-hole DNS on the NAS. I have also labeled the mokus with this information.

I tried names of the format "moku.pro.1" and this does not work, my guess is that each substring should be a valid name, and "1" is not. So, when naming things use alphanumeric chunks longer than 1 character

Loaned the 24-port gigabit ethernet switch (see attached photo) to Paco at the 40m. This switch was from B102. Apparently they are testing to see if the power outage affected anything. They are replacing it with one overnighted so we will have it back soon. There will be an associated elog post once they have their system back up and running. i.e. the elog is down because the switch does not work.