We have uploaded the new damping gains on all the suspensions of IMC. This completes changing all the configuration to as mentioned in 16066 and 16072. The old setting can be restored by running python3 /users/anchal/20210505_IMC_Tuned_SUS_with_Gains/restoreOldConfigIMC.py from allegra or donatella.

GPSTIME: 1304265872

I put the box containing the untested OSEMs from KAGRA near the south flow bench on the floor.

After a helpful meeting with Jon, we realized that I have somehow corrupted the sitemap file. So I am going to use the code Chris wrote to regenerate it. 

Also, I am going to connect the controller using the IPC parts. The error that I was having before had to do with the IPC parts not being connected properly. 

We redid the WFS noise injection test and have compiled some results on noise contribution in arm cavity noise and IMC frequency noise due to angular noise of IMC.

Attachment 1: Shows the calibrated noise contribution from MC1 ASCPIT OUT to ARM cavity length noise and IMC frequency noise.

• For calibrating the cavity length noise signals, we sent 100 cts 100Hz sine excitation to ITMX/Y_LSC_EXC, used actuator calibration for them as 2.44 nm/cts from 13984, and measured the peak at 100 hz in time series data. We got calibration factors: ETMX-LSC_OUT: 60.93 pm/cts , and ETMY-LSC_OUT: 205.0 pm/cts.
• For converting IMC frequency noise to length noise, we used conversion factor given by where L is 37.79m and lambda is wavelength of light.
• For converting MC1 ASCPIT OUT cts data to frequency noise contributed to IMC, we sent 100,000 amplitude bandlimited noise (see attachment 3 for awggui config) from 25 Hz to 30 Hz at C1:IOO-MC1_PIT_EXC. This noise was seen at both MC_F and ETMX/Y_LSC_OUT channels. We used the noise level at 29 Hz to get a calibration for MC1_ASCPIT_OUT to IMC Frequency in Hz/cts. See Attachment 2 for the diaggui plots.
• Once we got the calibration above, we measured MC1_ASCPIT_OUT power spectrum without any excitaiton and multiplied it with the calibration factor.
• However, something must be wrong because the MC_F noise in length units is coming to be higher than cavity length noise in most of the frequency band.
  • It can be due to the fact that control signal power spectrum is not exactly cavity length noise at all frequencies.  That should be only above the UGF of the control loop (we plan to measure that in afternoon).
  • Our calibration for ETMX/Y_LSC_OUT might be wrong.

IOP models created

With all the PCIe issues now resolved, yesterday I proceeded to build an IOP model for each of new FEs. I assigned them names and DCUIDs consist with the 40m convention, listed below. These models currently exist on only the cloned copy of /opt/rtcds running on the test stand. They will be copied to the main network disk later, once the new systems are fully tested.

The models compile and install successfully. The RCG runtime diagnostics indicate that all is working except for the timing synchronization and DAQD data transmission. This is as expected because neither of these have been set up yet.

Timing system set-up

The next step is to provide the 65 kHz clock signals from the timing fanout via LC optical fiber. I overlooked the fact that an SPX optical transceiver is required to interface the fiber to the timing slave board. These were not provided with the timing slaves we received. The timing slaves require a particular type of transceiver, 100base-FX/OC-3, which we did not have on hand. (For future reference, there is a handy list of compatible transceivers in E080541, p. 14.) I placed a Digikey order for two Finisar FTLF1217P2BTL, which should arrive within two days.

I also noticed some sound in the control room. (didn't open the MP3 yet)

I'm afraid that the hard disk in the control room iMac is dying.

It seemed like the BIO channels were not working, both the inputs and the outputs. The inputs were working on the windows machine though. That is, when we shorted the BIO channel to the return, or put 0V on it, we could see the LED turn on on the I/O testing screen and when we ramped up the voltage above 3 the LED turned off. This is the expected behavior from a sinking digital input. However, the EPICs caget didn't show any change. All the channels were stuck on Disabled.

We checked the digital outputs by connecting the channels to a fluke. Initially, the fluke showed 13V. We tried to toggle the digital output channels with caput and that didn't work. We checked the outputs with the windows software. For that, we needed to stop the Modbus. To our surprise, the windows software was not able to flip the channels either. We realized that this BIO Acromag unit is probably defective. We replaced it with a different unit and put a warning sticker on the defective unit. Now, the digital outputs were working as expected. When we turned them on the voltage output dropped to 0V. We checked the channels with the EPICs software. We realized that these channels were locked with the closed loop definition. We turned on the channels tied to these output channels (watchdog and toggles) and it worked. The output channels can be flipped with the EPICs software. We checked all the digital output channels and fixed some wiring issues along the way.

The digital input channels were still not working. This is a software issue that we will have to deal with later.

(Yehonathan) Rana noticed that the BNC leads on the chassis front panel didn't have isolation on them so I redid them with shrinking tubes.

For past few days, a weird sound of decaying gas leakage comes in the 40m control room from the south west corner of ceiling. Attached is an audio capture. This comes about every 10 min or so. 

Rana came and helped us figure us where to inject the noise. Following are the characteristics of the test we did:

• Inject normal noise at C1:IOO-MC1_PIT_EXC using AWGGUI.
• Excitation amplitude of 54321 in band 12-37Hz with Cheby1 8th order bandpass filter with same limits.
• Look at power spectrum of C1:IOO-MC_F_DQ, C1:IOO-WFS1-PIT_OUT_DQ and the C1:IOO-MC1_PIT_EXC itself.
• Increased the gain of the noise excitation until we see some effect in MC_F.
• Diaggui also showed coherence plot in the bottom, which let's us have an estimate of how much we need to go further.

Attachment 1 shows a screenshot with awggui and diaggui screens displaying the signal in both angular and longitudinal channels.

Attachment 2 shows the analogous screenshot for MC2.

I found a "vice" in the cleanroom (attachment 1). I used it to push dowel pins into the last suspension block using some alcohol as a lubricant.

I then assembled the 7th and last suspension tower (attachment 2).

Things that need to be done:

1. Push Viton tips into vented screws and assemble the earthquake stops.

2. Glue magnets to dumbells.

We repeated the same test with IMC unlocked. We had found these gains when IMC was unlocked and their characterization needs to be done with no light in the cavity. attached are the results. Everything else is same as before.

Edit Tue May 4 14:43:48 2021 :

• Adding zoomed in plots to show first 25s after the step.
• MC1:
  • Our improvements by new gains are only modest.
  • This optic needs a more careful coil balancing first.
  • Still the ring time is reduced to about 5s for all step responses as opposed to 10s at old gains.
• MC2:
  • The first page of MC2 might be bit misleading. We have not changed the damping gain for SUSPOS channel, so the longer ringing is probably just an artifact of somthing else. We didn't retake data.
  • In PIT and YAW where we increased the gain by a factor of 3, we see a reduction in ringing lifetime by about half.
• MC3:
  • We saw the most optimistic improvement on this optic.
  • The gains were unusually low in this optic, not sure why.
  • By increasing SUSPOS gain from 200 to 500, we saw a reduction of ringing halftime from 7-8s to about 2s. Improvements are seen in other DOFs as well.
  • You can notice rightaway that YAW of MC3 keeps oscillating near resonance (about 1 Hz). Maybe more careful feedback shaping is required here.
  • In SUSPIT, we increased gain from 12 to 35 and saw a good reduction in both ringing time and initial amplitude of ringing.
  • In SUSYAW, we only increased the gain to 12 from 8, which still helped a lot in reducing big ringing step response to below 5s from about 12s.

Overall, I would recommend setting the new gains in the suspension loops as well to observe long term effects too.

When the cymac is started it gives me a list of channels shown below. 

But when I enter it into the Diaggui I get an error:

My guess is that need to connect to the Diaggui to something that can access those channels. I also need to figure out what those channels are.

Lock ARMs

• Try IFO Configure ! Restore Y Arm (POY) and saw XARM lock, not YARM. Looks like YARM biases on ITMY and ETMY are not optimal, so we slide C1:SUS-ETMY_OFF from 3.0 --> -14.0 and watch Y catch its lock.
• Run ASS scripts for both arms and get TRY/TRX ~ 0.95
  • We ran X, then Y and noted that TRX dropped to ~0.8 so we ran it again and it was well after that. From now on, we will do Y, then X.

WFS1 noise injection

• Turn WFS limits off by running switchOffWFSlims.sh
• Inject broadband noise (80-90 Hz band) of varying amplitudes from 100 - 100000 counts on C1:IOO-WFS1_PIT_EXC
• After this we try to track its propagation through various channels, starting with
  • C1:LSC-XARM_IN1_DQ / C1:LSC-YARM_IN1_DQ
  • C1:SUS-ETMX_LSC_OUT_DQ / C1:SUS-ETMY_LSC_OUT_DQ
  • C1:IOO-MC_F_DQ
  • C1:SUS-MC1_**COIL_OUT / C1:SUS-MC2_**COIL_OUT / C1:SUS-MC3_**COIL_OUT
  • C1:IOO-WFS1_PIT_ERR / C1:IOO-WFS1_YAW_ERR
  • C1:IOO-WFS1_PIT_IN2

** denotes [UL, UR, LL, LR]; the output coils.

• Attachment 1 shows the power spectra with IMC unlocked
• Attachment 2 shows the power spectra with the ARMs (and IMC) locked

We finished the installation procedure on the c1auxey1 host machine. There were some adjustments that had to be made for Debian 10. The slow machine wiki page has been updated.

A test database file was made were all the channel names were changed from C1 to C2 in order to not interfere with the existing channels.

We starting testing the channels one by one to check the wiring and the EPICs software. We found some misswirings and fixed them.

Its getting late. I'll continue with the rest of the channels on Monday.

Notice that for all the AI channels the RTN was disconnected while testing.

Now that the model is finally compiled I need to make an medm screen for it and put it in the c1sim:/home/controls/docker-cymac/userapps/medm/ directory. 

But before doing that I really want to test it using the autogenerated medm screens which are in the virtual cymac in the folder /opt/rtcds/tst/x1/medm/x1sup. In Jon's post he said that I can use the virtual path for sitemap after running $ eval $(./env_cymac)

The SDF system is supposed to help with restoring the correct settings, complementary to burt. My personal opinion is that there is no need to commit these filters to SDF until we're convinced that they help with the locking / noise performance.

This is the actuator calibration. For the error point calibration, you have to look at the filter in the calibration model. I think it's something like 8e-13m/ct for POX and similar for POY.

We received a stock of DB9 male feed-through connectors. That allowed me to complete the remaining wiring on the c1auxey Acromag chassis. The only thing left to be done is the splicing to the RTS.

With the input matrix, coil ouput gains and F2A filters loaded as in 16091, I tested the suspension loops' step response to offsets in LSC, ASCPIT and ASCYAW channels, before and after applying the "new damping gains" mentioned in 16066 and 16072. If these look better, we should upload the new (higher) damping gains as well. This was not done in 16091.

Note that in the plots, I have added offsets in the different channels to plot them together, hence the units are "au".

t Both arms were locked simply by using IFO > Configure > ! (YARM) > Restore YARM. I had to use ASS to improve the TRX/TRY to ~0.95.

I measured C1:LSC-XARM_IN1_DQ and C1:LSC-YARM_IN1_DQ while injecting band limited noise in C1:IOO-WFS1_PIT_EXC using uniform noise with amplitude 1000 along with filter defined by string: cheby1("BandPass",4,1,80,100). I calibrated the control arms signals by 2.44 nm/cts calibration factor directly picked up from 13984.

For the duration of this test, all LIMIT switches in the WFS loops were switched OFF.

I do not see any affect on the arm control signal power spectrums with or without the noise injection. Attachement 1 shows the PSD along with PSD of the injection site IN2 signal. I must be doing something wrong, so would like feedback before I go further.

I double checked today and the F2A filters in the output matrices of MC1, MC2 and MC3 in the POS column are ON. I do not get what SDF means? Did we need to add these filters elsewhere?

The other day I felt hot at the X end. I wondered if the Xend A/C was off, but the switch right next to the SP table was ON (green light).
I could not confirm if the A/C was actually blowing or not.

I installed the EPICs base, asyn and modbus modules according to Jon's instructions.

Since the modbus configurations files were already writtten for c1auxey1 (see elog 15292) the only thing I did was to change the IP addresses in ETMYaux.cmd to match the actual assigned IPs.

I followed the rest of the instructions as written.

The modbus service was activated succesfully.

The only thing left to do is to change ETMYaux.db to reflect to new channels that were added. I believe these are BI channels named C1:SUS-ETMY_xx_ENABLEMon.

The problem here was that the RFM errors cropped up again - seems like it started ~4am today morning judging by TRX trends. Of course without the triggering signal the arm cavity couldn't lock. I rebooted everything (since just restarting the rfm senders/receivers did not do the trick), now arm locking works fine again. It's a bit disappointing that the Rogue Master setting did not eliminate this problem completely, but oh well...

It's kind of cool that in this trend view of the TRX signal, you can see the drift of the ETMX suspension. The days are getting hot again and the temp at EX can fluctuate by >12C between day and night (so the "air-conditioning" doesn't condition that much I guess 😂 ), and I think that's what drives the drift (idk what the transfer function to the inside of the vacuum chamber is but such a large swing isn't great in any case). Not plotted here but i hypothesize TRY levels will be more constant over the day (modulo TT drift which affects both arms).

The IMC suspension team should double check their filters are on again. I am not familiar with the settings and I don't think they've been added to the SDF.

To add the required library: put the .mdl file that contains the library into the userapps/lib folder. That will allow it to compile correctly

I got these errors:

I removed all IPC parts (as seen in Attachment 1) and that did the trick. IPC parts (Inter-Process Communication) were how this model was linked to the controller so I don't know how exactly how I can link them now. 

I also went through the model and grounded all un-attached inputs and outputs. Now the model compiles

Also, The computer seems to be running very slowly in the past 24 hours. I know Jon was working on it so I'm wondering if that had any impact. I think it has to do with the connection speed because I am connected through X2goclient. And one thing that has probably been said before but I want to note again is that you don't need a campus VPN to access the docker.

Tried locking the arms

• Ran IFO > Configure > ! (YARM) > Restore YARM. Nothing happened.
• Trying to align through tip-tilt:
  • Previous values: TT1: PIT: -1.7845, YAW: -0.2775; TT2: PIT: -1.3376, YAW: -0.0436
  • Couldn't get flashing of light in the arms at all.
  • Restored values to previous values.
• Noticed that ITMY OPLEV YAWW Error has gone very high overnight while other oplevs remained the same.
• Trying to change the C1:SUS-ITMY_YAW_OFFSET to bring this oplev yaw error back to near zero.
• Changed C1:SUS-ITMY_YAW_OFFSET from -34 to 50. OPLEV_YEROR reduced to around -23 from -70.
• Same thing with BS PIT. OPLEV_PERROR is highlighted in red at -52.
• Changing C1:SUS-BS_PIT_OFFSET from 55 to 30. This brought OPLEV_PERROR to -15 from -52.
• Trying to align PRM by changing C1:SUS-PRM_PIT_OFFSET and C1:SUS-PRM_YAW_OFFSET.
• Inital values: C1:SUS-PRM_PIT_OFFSET: -20 , C1:SUS-PRM_YAW_OFFSET: 39.

Did the WFS step response test on IMC in between while waiting for help. See 16094.

Back to trying arm locking

• Tried IFO > Configure > ! (XARM) > Restore YARM. Nothing happened.
• Tried IFO > Configure > ! (YARM) > Restore YARM. Nothing happened again.
• Tried Movie Capture of AS screen from VIDEO > Movie Capture > AS. But the script failed due to module not present error.

PMC got unlocked

• Infront of me, PMC got unlocked. I did not go to PMC locking the screen at all since morning.
• I opened the C1PSL_PMC screen. The PSL Autolocker blinker is not blinking but the switch is set to Enable. 
• I do not see any automatic effort happening for regaining lock at PMC.
• I'll try it manually. I was able to get the PMC locked again. C1:PSL-PMC_PMCTRANSPD is showing 0.761 V and C1:PSL-PMC_RFPDDC is showing 0.053 V.
• Now IMC auto locker seems to be trying to get the lock acquired.
• It acquired a lock a few times but struggled to keep it on. I reduced C1:IOO-WFS_GAIN to 0 and then the lock could stay on. Seemed like the accumulated offsets were not good.
• So I cleared the history on WFS1, TRANS and WFS2 filter banks and then ramped the WFS overall gain (C1:IOO-WFS_GAIN) back to 1 and now IMC seems to stay locked in a stable configuration.
• However, I still don't know what caused the PMC to get unlocked in the first place. Did my repeated arm locking attempts did something to the main laser frequency?

Back to trying arm locking

• Tried IFO > Configure > ! (YARM) > Restore YARM again. Nothing happened again.

In 16087 we mentioned that we were unable to do a step response test for WFS loop to get an estimate of their UGF. The primary issue there was that we were not putting the step at the right place. It should go into the actuator directly, in this case, on C1:SUS-MC2_PIT_COMM and C1:SUS-MC2_YAW_COMM. These channels directly set an offset in the control loop and we can see how the error signals first jump up and then decay back to zero. The 'half-time' of this decay would be the inverse of the estimated UGF of the loop. For this test, the overall WFS loops gain,  C1:IOO-WFS_GAIN was set to full value 1. This test is performed in the changed settings uploaded in 16091.

I did this test twice, once giving a step in PIT and once in YAW.

Attachment 1 is the striptool screenshot for when PIT was given a step up and then step down by 0.01.

• Here we can see that the half-time is roughly 10s for TRANS_PIT and WFS1_PIT corresponding to roughly 0.1 Hz UGF.
• Note that WFS2 channels were not disturbed significantly.
• You can also notice that third most significant disturbance was to TRANS_YAW actually followed by WF1 YAW.

Attachment 2 is the striptool screenshot when YAW was given a step up and down by 0.01. Note the difference in x-scale in this plot.

• Here, TRANS YAW got there greatest hit and it took it around 2 minutes to decay to half value. This gives UGF estimate of about 10 mHz!
• Then, weirdly, TRANS PIT first went slowly up for about a minutes and then slowly came dome in a half time of 2 minutes again. Why was PIT signal so much disturbed by the YAW offset in the first place?
• Next, WFS1 YAW can be seen decaying relatively fast with half-life of about 20s or so.
• Nothing else was disturbed much.

• So maybe we never needed to reduce WFS gain in our measurement in 16089 as the UGF everywhere were already very low.
• What other interesting things can we infer from this?
• Should I sometime repeat this test with steps given to MC1 or MC3 optics?

Summary

Yesterday I unpacked and installed the three 18-bit DAC cards received from Hanford. I then repeated the low-level PCIe testing outlined in T1900700, which is expanded upon below. I did not make it to DAC-ADC loopback testing because these tests in fact revealed a problem with the new hardware. After a combinatorial investigation that involved swapping cards around between known-to-be-working PCIe slots, I determined that one of the three 18-bit DAC cards is bad. Although its "voltage present" LED illuminates, the card is not detected by the host in either I/O chassis.

I installed one of the two working DACs in the c1bhd chassis. This now 100% completes this system. I installed the other DAC in the c1sus2 chassis, which still requires four more 18-bit DACs. Lastly, I reran the PCIe tests for the final configurations of both chassis.

PCIe Card Detection Tests

For future reference, below is the set of command line tests to verify proper detection and initialization of ADC/DAC/BIO cards in I/O chassis. This summarizes the procedure described in T1900700 and also adds the tests for 18-bit DAC and 32-channel BO cards, which are not included in the original document.

Each command should be executed on the host machine with the I/O chassis powered on:

where xxxx is a four-digit device code given in the following table.

The command will return a two-line entry for each PCIe device of the specified type that is detected. For example, on a system with a single ADC this command should return:

We took a Supermicro from the lab (along with a keyboard, a mouse, and a screen taken from a table on the Y arm) and placed it near the Acromag chassis.

We installed Debian 10 on the machine. I followed the steps on the slow machine wiki for setting up the host machine. Some steps had to be updated. Most importantly, in the new Debian, the network interfaces are given random names like enp3s0 and enp4s0 instead of eth0 and eth1. I updated the wiki accordingly.

To operate the chassis using one 15V source I disconnected the +24V cable from the Acromag units and jumpered the +15V wire into the power input instead. I started up the Acromags. They draw 0.7A. I connected an Ethernet cable to the front interface. I checked that all the Acromags are connected to the local network of the host machine by pinging them one by one.

I have uploaded all the new settings mentioned in 16066 and 16072. The settings were uploaded through a single script present at anchal/20210428_IMC_Tuned_Suspension/uploadNewConfigIMC.py. The settings can be reverted back to old settings through anchal/20210428_IMC_Tuned_Suspension/restoreOldConfigIMC.py. Both these scripts can be run only through python3 in donatella or allegra.

GPSTIME of new settings: 1303690144

New settings include:

• New input matrices for MC1 and MC2.
• New Output coil gains for AC balancing on all three optics.
• Switching ON the FM8 filter modulae (Q=3 F2A filter) in POS column on output matrix of all optics.

We'll wait and watch the performance through summary pages and check back the performance on Monday.

I checked out what happened on c1vac. There are actually two independent monitoring codes running:

1. The interlock service, which monitors the line directly connected to the valves.
2. A seaparate convenience mailer, running as a cronjob, that monitors the tanks.

The interlocks did not trip because the low-pressure delivery line, downstream of the dual-tank regulator, never fell below the minimum pressure to operate the valves (65 PSI). This would have eventually occurred, had Jordan been slower to replace the tanks. So I see no problem with the interlocks.

On the other hand, the N2 mailer should have sent an email at 2021-04-18 15:00, which was the first time C1:Vac-N2T1_pressure dropped below the 600 PSI threshold. N2check.log shows these pressures were recorded at this time, but does not log that an email was sent. Why did this fail? Not sure, but I found two problems which I did fix:

• One was that the code was checking the sensor on the low-pressure side (C1:Vac-N2_pressure; nominally 75 PSI) against the same 600 PSI threshold as the tanks. This channel should either be removed or a separate threshold (65 PSI) defined just for it. I just removed it from the list because monitoring of this channel is redundant with the interlock service. This does not explain the failure to send an email.
• The second issue was that the pyN2check.sh script appeared to be calling Python 3 to run a Python 2 script. At least that was the situation when I tested it, and this was causing it to fail partway through. This might well explain the problem with no email. I explicitly set python --> python2 in the shell script.

The code then ran fine for me when I retested it. I don't see any further issues.

Good morning!

We ran the f2a filter test for MC1, MC2, and MC3.

Filters

The new filters differ from previous versions by a adding non-unity Q factor for the pole pairs as well.

This in terms of zpk is: [ [z_r + i z_i, z_r - i z_i], [p_r + i p_i, p_r - i p_i], 1] where

• Attachment #1 shows the filters for MC1 evaluated for Q=3, 7,and 10.
• Attachment #2 shows the filters for MC2 evaluated for Q=3, 7, and 10.
• Attachment #3 shows the filters for MC3 evaluated for Q=3, 7, and 10.
• Attachment #4 shows the bode plots generated by foton after uploading for Q=3 case.

We uploaded all these filters using foton, into the three last FM slots on the POS output gain coil.

Tests

We ran tests on all suspended optics using the following (nominal) procedure:

1. Upload new input matrix
2. Lower the C1:IOO-WFS_GAIN to 0.05.
3. Upload AC coil balancing gains.
4. Take ASD for the following channels:
   • C1:IOO-MC_TRANS_PIT_IN1
   • C1:IOO-MC_TRANS_YAW_IN1
   • C1:IOO-MC_WFS1_PIT_IN1
   • C1:IOO-MC_WFS1_YAW_IN1
   • C1:IOO-MC_WFS2_PIT_IN1
   • C1:IOO-MC_WFS2_YAW_IN1
5. For the following combinations:
   • No excitation** + no filter
   • No excitation + filter
   • Excitation + no filter
   • Excitation + filter

** Excitation = 0.05 - 3.5 Hz uniform noise, 100 amplitude, 100 gain

Plots

• Attachment 5-7 give the test results for MC1, MC2 and MC3.
• In each pdf, the three pages show ASD of TRANS QPD, WFS1 and WFS2 channels' PIT and YAW, respectively.
• Red/blue correspond to data taken while F2A filters were on. Pink/Cyan correspond to data taken with filters off.
• Solid curves were taken with excitation ON and dashed curves were taken with excitation off.
• We see good suppression of POS-> PIT coupling in MC2 and MC3. POS->YAw is minimally affected in all cases.
• MC1 is clearly not doing good with the filters and probably needs readjustement. Something to do later in the future.

The first version of the single filter plant is below. Jon and I went through compiling a model and running it on the docker (see this post)

We activated an early version of the plant model (from about 10 years ago) but this model was not designed to run on its own so we had to ground lots of unconnected pieces. the model compiled and ran so we moved on to the x1sus_single_plant model that I prepared.

This model is shown in the first attachment wasn't made to be run alone because it is technically a locked library (see the lock in the bottom left). It is supposed to be referenced by another file: x1sup.mdl (see the second attachment). This works great in the Simulink framework. I add the x1sus_single_plant model to the path and Matlab automatically attaches the two. but the docker does not seem to be able to combine the two. Starting the cymac it gives these errors:

I have tried putting the x1sus_single_plant.mdl file everywhere as well as physically dragging the blocks that I need into the x1sup.mdl file but it always seems to throw an error. Basically, I want to combine them into one file that is not referencing anything other than the CDS library but I cant figure out how to combine them.

Okay but the next problem is the medm screen generation. When we had the original 2010 model running the sitemap did not include it. It included models that weren't even running before but not the model Jon and I had added. I think this is because the other models that were not running had medm screens made for them. I need to figure out how to generate those screens. I need to figure out how to use the tool Chris made to auto-generate medm screens from Simulink but I can't seem to figure it out. And honestly, it won't be much use to me until I can actually connect the plant block to its framework. One option is to just copy each piece over one by one. this will take forever but at this point, I am frustrated enough to try it. I'll try to give another update later tonight.

We extended the f2a filter implementation and diagnostics as summarized in 16086 to MC1 and MC3.

MC1

Attachment 1 shows the filters with Q=3, 7, 10. We diagnosed using Q=3.

Attachment 2 shows the test summary, exciting with broadband noise on the LSC_EXC and measuring the CSD to estimate the transfer functions.

MC3

Attachment 3 shows the filters with Q=3, 7, 10. We diagnosed using Q=3.

Attachment 4 shows the test summary, exciting with broadband noise on the LSC_EXC and measuring the CSD to estimate the transfer functions.

Our main observation (and difference) with respect to MC2 is the filters have relative success for the PIT cross-coupling and not so much for YAW. We already observed this when we tuned the DC output gains to compute the filters.

Today we tested the F2A filters created from the DC gain values listed in 16066.

Filters:

• For a DC gain  required for balancing the coil at DC and being the resonance frequency of the mode (POS in this case), we calculate the filter using:
  where .
• Attachment 1 shows the motivation for choosing the resonant frequency in the formula above. It makes gain at DC as while keeping AC gain as 1.
• Attachment 2 shows the transfer functions of the filters uploaded.
• Filters are named Eg2CtQ3, Eg2CtQ7 and Eg2CtQ10 for Q=3,7,10 filters respectively. (Named for Eigenmode Basis to Cartesian Basis conversion filters, aka F2A filters).

Testing procedure:

• We uploaded the new input matrix listed in 16066.
• We then uploaded the coil output gains (AC gains) that are also listed in 16066.
• Then we reduced the C1:IOO-WFS_GAIN to 0.05 (by a factor of 20).
  • Rana asked us to test the WFS sensors' impulse response to observe a minimum 10s decay to ensure that the UGF of WFS control loops is at or below 0.1 Hz.
  • We were unable to have any effect on this decay actually. We tried setting offsets without tramps in multiple places but whenever we were able to excite this loop, it will always damp down in about 5-6s regardless of the value of C1:IOO-WFS_GAIN.
  • So we moved on.
• Then, with MC locked we took reference data with no excitation or filters uploaded. (dotted curves)
• We took cross spectral density from C1:IOO-MC_F to C1:IOO-MC_TRANS_PIT_IN1, C1:IOO-MC_TRANS_YAW_IN1, C1:IOO-WFS1_PIT_IN1, C1:IOO-WFS1_PIT_IN1, C1:IOO-WFS2_PIT_IN1, and C1:IOO-WFS2_PIT_IN1.
• We were also looking at the power spectral density of these channels.
• Then using awggui (after the fix we did as in 16085), we added noise in C1:SUS-MC2_LSC_EXC as uniform noise between 0.05 Hz to 3.5 Hz with amplitude of 100 and gain of 100.
• We took a set of data without switching on the filters to have a comparison later. (Dash-dort curves)
• We then took data after switching on the filters. (Solid curves)

Next:

• Tomorrow we'll repeat this for MC1 and MC3 if we get a favourable grade in our work here.
• Even if not, we'll jsut conclude the suspension optimization work tomorrow morning and get into main interferometer.

Today we had some trouble launching an excitation on C1:IOO-MC_LSC_EXC from awggui. The error read:

awgSetChannel: failed getIndexAWG C1:SUS-MC2_LSC_EXC ret=-3

What solved this was the following :

1. launch the dtt command line interface
2. Anchal remembers a slot number 37008
3. We issue >> awg free 37008
4. Slot freed, launch a new instance of awggui

1. I suggest not naming this the LSC model, since it has no LSC stuff.
2. Also remove all the diagnostic stuff in the plant model. We need nothing except a generic filter Module, like in the SUS controller.
3. Also, the TF looks kind of weird to me. I would like to see how you derive that eq.
4. Connect the models and show us some plots of the behavior in physical units using FOTON to make the filters and diaggui/DTT (at first) to make the plots.

I believe that there is an internal setting for the minimum flow, so the flow is not linear ("0%" is not zero), but we should mark this flow speed once you find this is sufficiently low for the locking too.

I will upload some plots later - but in summary, I set the HEPA speed to ~40%. I used (i)IMC transmission RIN, (ii) Arm cavity transmission RIN and (iii) ALS beat noise as 3 diagnostics, to see how noise in various frequency bands for these signals change as a function of the HEPA speed. The MC2T RIN shows elevated noise between 1-10Hz at even the lowest speed I tried, ~20% of the max on each blower. The elevated noise extended to ~50-70 Hz for HEPA speeds >40% of the maximum, and the arm cavity RIN and ALS signals also start to become noisy for speeds >60% of the maximum. So I think 40% is a fine speed to run at - for squeezing measurement we may have to turn off the HEPA for 10mins but for the usual single arm / PRMI / DRMI locking, this should be just fine. For the elevated ALS noise - I'm not sure if the coupling is happening over the top of the enclosure where the fiber bringing light from EX comes close to the HEPA filters, or if it is happening inside the PSL enclosure itself, near the beat mouth - but anyways, at the 40% speed, I don't see any effect on the ALS noise.

I checked with a particle counter at the SW corner of the PSL table (which is the furthest away we can be on the table from the HEPA blowers) after leaving the blowers on for ~30mins and it registered 0 for both 0.3um and 0.5um sized particles (if the blowers are off, the respective numbers are 43 and 9 but I forgot what the units were, and I believe they have to be multiplied by 10). 

I have not yet marked the speed control units yet in case there is some other HEPA science that needs to be done before deciding what is the correct setting. But I think I can get the PRFPMI lock without much issue with this lower speed, which is what I will try later today evening.

I have attached the framework that I am using for the full system. Plantframework.pdf has the important aspects that I will be changed. Right now I am trying to keep it mostly as is, but I have disconnected the Optic Force Noise and hope to disconnect the Suspension Position Noise. The Optic Force Noise Block is additive to the signal so eliminating it from the system should make it less realistic but simpler. It can be added back easily by reconnecting it.

The next step is adding my plant response, which is simply the transfer function and measurement from the last post. These should be inserted in the place of the red TM_RESP in the model.

The TM_RESP block takes in a vector of dimension 12 and returns a vector of dimension 6. The confusing part is that the block does not seem to do anything. it simply passes the vector through with no changes. I'm not sure why this is the case and I am looking for documentation to explain it but haven't found anything. As to how a 12 vector turns into a 6 vector I am also lost. I will probably just disconnect everything but the x position.

I tried to just throw in my model (see Simple_Plant.pdf) and see what happened but the model would not let me add built-in blocks to the model. This is weird because all the blocks that I am adding are part of the basic library. My guess is that this mode will only accept blocks from the CDL library. I will either need to change my blocks to be made from blocks in the CDL library or maybe I can pass the signal out of the plant framework model then into my model then back to the plant framework model. I think this is just a Matlab thing that I don't know about yet. (Jon probably knows)

I have also attached an image of the controls model for reference. It looks like a mess but I'm sure there is a method. I won't get lost in going through it just assume it works... for now.

The next question I have been asking is how do I show that the system works. When anchal and I made a python simulation of the system, we tested it by seeing the evolution of the degrees of freedom over time given some initial conditions. We could see the pendulum propagating and some of the coupling between the DOFs. This is a fast and dirty way to check if everything is working and should be easy to add. I simply recorded the POS signal and graph it over time. Once we get to a state-space model we can test it by taking the transfer function, but since our plant is literally already just a transfer function there isn't much of a point yet.

Also, I need to add color to my Simple_Plant.pdf model because it looks really boring :(

According to the aLIGO 70W amplifier interlock concept the flow rate of the chiller should be between 5 and 40 l/min. The chillers I found in the TCS lab both have around 15 l/min flow rate so we should be fine in that regard.

Assuming that the power consumption of the diode box is ~800W and that the optical output power of the diode is ~ 300W of optical power, the chillers need to be able to remove the remaining power. At room temperature, they both have enough cooling capacity according to their specs.

As for the idea to put the chiller and diode box in the drill room: There are not a lot of options here. The only viable place is the SW corner (attachment 1). I was told this place is used sometimes for liquid nitrogen dewar. Alternatively, if possible, we can move the fire extinguishers to the SW corner and use the NW corner. In that way, we don't have to clear all the junk from the SW corner, as long as the extinguishers are still accessible.

I made a sketch (attachment 2) showing a possible setup for a diode box + chiller rack. The fiber and network cable can go through the hole in the wall that already exists for the N2. It will have to get bigger though (attachment 3). The rack would also need to host some Acromag unit to convert the communication channel of the chiller/flow meter to Ethernet. The Acromag on 1X7 has no spare channels.

The only power socket in the room, to which the drill is connected, is circuit #36 which is connected to panel L in the lab. The breaker's ampacity seems to be 20A if I'm reading the number on the breaker correctly.

Indeed, you can make your own snapshot by specifying the channels to snap in a .req file. But what I meant was, we should confirm that all the channels that we modify are already in the existing snapshot files in the autoburt dir. If it isn't, we should consider adding it. I think the whole burt system needs some cleaning up - a single day of burt snapshots occupies ~400MB (!) of disk space, but I think we're recording a ton of channels which don't exist anymore. One day...

The mix up was my fault I think. I restored the channels manually instead of using burt restore. Your message suggests that we can set burt to start noticing channel changes at home point and create a .req file that can be used to restore later. We'll try to learn how to do that. Right now, we only know how to burt restore using the existing snapshots from the autoburt directory, but they touch more things than we work on, I think. Or can we just always burt restore it to morning time? If yes, what snapshot files should we use?

Koji mentioned that the mode of the laser is different for lower diode currents. So that might be the reason why we got less transmission at the low input power but more afterward.

I was a bit surprised by these numbers suggesting the PMC transmission is only 50-60%. I went to the table today and confirmed that it is more like 85% (1.3 W in, 1.1 W transmitted, both numbers from with the FieldMate power meter), as I claimed in 2019. Even being conservative with the power meter errors, I think we can be confident T_PMC will be >80% (modulo any thermal effects with higher power degrading the MM). There isn't any reliable record of what the specs of the PMC mirrors are, but assuming the IO couplers have T=4000ppm and the end mirror has T=500ppm as per Alan's plot, this is consistent with a loss of something like 300ppm loss per mirror - seems very high given the small beam spots, but maybe these mirrors just aren't as high quality as the test masses?

It's kind of unfortunate that we will lose ~20% of the amplifier output through the first filter, but I don't see an easy way to clean these mirrors. It's also not clear to me if there is anything to be gained by attempting a cleaning - isn't the inside of the cavity supposed to be completely isolated from the outside? Maybe some epoxy vaporization events degraded the loss?

This is to facilitate running of scripts like the CDS reboot script, mx_stream restart, etc, from rossa, without being pwd prompted every time, whereas previously it was only possible from pianosa. I added the public key of rossa to FB and the RT FE servers. I suppose I could add it to the Acromag servers too, but I haven't yet.

When adjusting the blower speed, give the blower at least 30 seconds to speed up or slow down to the set speed.  The flywheel effect of the big motor armature and blower mass requires time to follow the control current.  Note the taller Flanders HEPA filters.  These and the new intake filters should keep the PSL air clean for a long time!

The MC / WFS stability seemed off to me. Trending some channels at random, I saw that the MC3 PIT/YAW gains were restored mixed up (PIT was restored to YAW and vice versa) in the last day sometime - I wasn't sure what other settings are off so I did a global burtrestore from the last time I had the interferometer locked since those were settings that at least allow locking (I am not claiming they are optimal).

How are these settings being restored after the suspension optimization? If the burtrestore is randomly mixing up channels, seems like something we should be worried about and look into. I guess it'd also be helpful to make sure we are recording snapshots of all the channels we are changing - I'm not sure if the .req file gets updated automatically / if it really records every EPICS record. It'd be painful to lose some setting because it isn't recorded.

Unconnected to this work - the lights in the BS/PRM chamber were ON, so I turned them OFF. Also unconnected to this work, the summary pages job that updates the "live" plots every half hour seem to be dead again. There is a separate job whose real purpose is to wait for the data from EOD to be transferred to LDAS before filling in the last couple of hours of timeseries data, but seems to me like that is what is covering the entire day now.

Note: The AC gains were measured by keeping output matrix to ideal values of 1s. When optimizing DC gains, the AC gains were uploaded in coil ouput gains.

Note: The AC gains were measured by keeping output matrix to ideal values of 1s. When optimizing DC gains, the AC gains were uploaded in coil ouput gains.

Yes, during the AC balancing, POS column was set to all 1. This table shows the final values after all the steps. The first 3 columns are DC balancing results when output matrix was changed. While the last column is for AC balancing. During AC balancing, the output matrix was kept to ideal position as you suggested.