In the previous post, we saw that for the heater element design with straight edges in replacement of the current eight-element ring-like design, it provides the similar Gaussian-like irradiance profiles, but with smaller power delivery efficiencies, as shown in the plot. This turned out to result in similar but less prominent thermal effects.

They only differ from the original baseline design by a source power rescaling, however, as shown in the plot, where we see the power-rescaled irradiance profiles for the straight edge designs are close to that for the ring design. The resulting temperature profiles and thermal distortions are shown in plot and plot. The thermal effects for the 16 straight-edge design with renormalized source power for instance are strikingly similar to that for the original ring design.

An alternative straightened heater element design has also been investigated with COMSOL FEA simulation. As shown in the attached, in this new design each heater element component is cut with multiple straight edges but remains connected, shown in the same colors (green and red). In the example, four straight edges are cut from each of the four heater components (4x4=16 edges in total). There is no spacing between the neighboring edges from the same element component, but the edges from different components are separated by 2mm, as can be seen in the attached. This new N-in-one straight edge design offers similar irradiance compared to that for the evenly-spaced N-sided regular polygon straight edge design with the same number of edges, as shown in the plot. It however has fewer heater components, four in this case, which makes it easier to implement in assembly and wiring, and less vulnerable to electrical and thermal shorts with their fewer heater element pins.

Upon further inspection, one adjustment was made to the FROSTI profile analysis: changing the transmission value of the ZnSe viewport. It was initially assumed that the viewport possessed an AR coating, which would bring the transmission into the 90% range. Without the coating, it drops to roughly 70%. Assuming no coating, the estimated delivered power was calculated to be 11.7 W. This is consistent with the estimated power given from the Hartmann sensor analysis, thus it is believed that the viewport indeed had no coating.

For a quick projection for the resonant frequencies going from aLIGO to CE, the height and width of the BS are increased assuming the mass is increased from 14 kg to 70 kg, while keeping the aspect ratio fixed. The resonant frequencies for the two mechanical modes as a result becomes smaller, to 1.43 kHz and 2.11 kHz respectively, risking getting in the detection band.

Next step is to implement a mechanical ring with high stiffness outside the BS barrel to combat the decrement of the resonant frequencies of the relevant mechanical modes.

There are three major issues with the lab's CDS system that should be addressed. They are ordered from the highest priority to the lowest.

• CyMAC has stopped serving the fast channels (65k Hz)
  The channels are still there, and the data from the slow (16 Hz) channels is served correctly, but the fast data is not served. As a result, diagggui can not retrieve any information at the moment.
  Probably the issue is the same as the version conflict between daqd and nds2-server. After installing nds2-server on CyMAC and realizing that the conflict can not be resolved, I reverted the changes so that the CyMAC could be compatible with daqd, but there is a chance that there are still version conflicts that block the fast channels.
  I suspect that we have broken the MSC model when adding the new button. This could explain both the fasr-channels fault and the unexpected crashes.
  
  UPDATE 6/5
  Fixes this by rebuilding the models.
  Note for the future: The c1iop and c1msc models should be rebuilt together, even if no change has been made to c1iop.
• The fast channels were not saved to the frames
  Reviewing the frame files showed that the daqd was only saving the 16 Hz data in the .gwf frame files. I had missed this because I only checked the existence and the integrity of the raw frame files, but never retrieved the high-frequency data itself to check it.
• NDS2-server is installed, but does not distribute the data
  I managed to install the nds2-server and its satellite programs on the Chimay, and NFS mount the frame files on it. The server successfully chaches the channel names, frame files, and the data, but fails to list the channels for distribution.

Note: CyMAC machine was strangely disconnected from the network, and required manual reboot. I couldn't find any abnormal logs that could explain what happened.

• The MEDM models issue was fixed. The issue was that building the c1msc model alone was not enough and we had to re-build the c1iop as well, although no changes has been made to the c1iop. Added a note in the wiki on this for future reference.
• For writing the fast channels to the frame files, our CDS system should have a GDS broadcaster. I followed this wiki page to set one, but it breaks the current daqd system. Asked about it earlier today on the CDS Mattermost channel and waiting for a response. 
• Maybe I should continue the distributed scheme we have been trying for the nds2-server and let another machine on the network do this. 
• Question: daqd has a feature to zero-out the bad data (NaNs), and it is currently on for our system. I don't think that it's a good idea to have this. Should I turn it off? 

• Fast channels recorded to .gwf frame files
  • Had to add a DAQ Channels block to the c1msc model for those channel to be recorded in the .gwf frame files. The block is in the CDS_PARTS, and I just had to copy it to our model. Here is the example text for the channels:
    
    

    #DAQ Channels

    ONE_DAQ_CHANNEL 2048
ANOTHER_DAQ_CHANNEL 1024
SCIENCE_FRAME_CHAN* 1024
UINT32_CHAN uint32 2048
DAQ_CHANNEL_AT_DEFAULT_RATE

    I added two channels to the list (V0 and V1). Remember that the channel name should not be the full name, but just the part's name. In this case, I added these two channel names:
    
    V0_OUT
V1_OUT
    
    with the default sample rate. 
• The fast channels are recorded with an extra _DQ in their names. So, in ndscope and diaggui these two channels should be addressed as
  • C1:MSC-V0_OUT_DQ
  • C1:MSC-V1_OUT_DQ

• Update 6/13: enabled recording of all the ADC voltage channels so that Tyler can use all the data for the noise floor calculation. attached is an example of diagggui with almost 30 hrs of data.

• TODO: Enable daqd_wiper

[Luis, Ma]

Feb/10/25 4:00pm

Bake was stopped.

I ended the bake of the UHV system (that began on Monday) at 6:23 pm today by switching OFF both PID controllers. The heaters elements were run at max power (24 V DC / 200 mA per element) during this bake, and I left them powered at the same level.

At the time, the instrument readings were as follows:

• Left high-limit controller: 138 C
• Right high-limit controller: 128 C
• Left PID controller: 100 C
• Right PID controller: 100 C
• Main volume pressure: 8.17e-7 Torr
• RGA volume pressure: 4.63e-7 Torr

I reproduced Cao's CE beamsplitter code (see below for example plots). I received the current info on the beamsplitter parameters for A+ and A# from GariLynn also. The next steps are to perform a similar power loss analysis on the anticipated A# beamsplitter.

After taking data for each of the individual heater elements, I imported them into python and overlayed them to produce an average temperature profile. I rotated the 7 of the elements to align with element 1's profile and averaged them out. By setting the range to 28C - 33C (this gave the best visibility of the heating pattern) it gave the profile attached.

In response to reports that ants have been observed in the lab, I placed five ant bait traps around the room today. Each is sitting on the floor on top of a piece of aluminum foil, in areas unlikely to be inadvertently stepped on. They contain liquid which will spill out if picked up, so please take care not to disturb them.

Update: After seeing the strong response to the first set, I redistributed them to the hottest spots and added one more trap.

To access and control the Red Pitaya using Python locally on a machine within the local network, one should follow these steps:

1. Start the SCPI server. This is achieved by first log onto the Red Piatay page

   rp-xxxxxx.local/ 

2. Go to Development >> SCPI server and turn the server on. (Note : The server is currently running)
3. Communication with Red Piataya is done through PyVista, install PyVista with:

    sudo pip3 install pyvisa pyvisa-py 

   This has been installed on Chimay. Ensure that you have pip3 install, if not, you can install it using:

    sudo apt-install python3 pip 

4. To start talking to the RedPitaya, ensure you have the scipt

    redpitaya_scpi.py 

   in your local folder. This is the standard class that you will import to your code to establish connection with the Red Pitaya. This code can be found in directory

    ~/RedPiatya 
    or this link
   

Finished ADC-DAC loopback testing today (see attached xlsx file or access directly here). All looks well with the first 8 channels, with the gain hovering just under 2. Also edited c1msc model in simulink to add channels 7-15 (the last 8 channels), and changed the rate back to 64K. See image 1 for the updated c1msc model. The last 8 channels are also looking good and show no problems, with slightly more scattering for the gain, but all values very close to 2.

We also installed the new eight-channel Perle IOLAN SDS8 terminal server today. Image attached.

NOTE: When we were installing it, we noticed an energized wire dangling from the 24V power supply. Has since been fixed and put back into place.

Slides

[Ma, Christina, Tyler]

ADC CyMAC 260 hr, 8192Hz sampling rate channels V3 and Vref6