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.

New HV power supply from Company 'M' has been delivered. So I decided to compare the noise levels of some HV supplies in the lab. There are three models from companies 'H', 'K', and 'M'.

The noise level was measured with SR785 via Gautam's HP filter with protection diodes.

'H' is a fully analog HV supply and the indicator is analog meters.
'K' is a model with a LCD digital display and numerical keypad.
'M' is a model with a knob and digital displays.

All the models showed that the noise levels increased with increased output voltage.

Among these three, H showed the lowest noise. (<~1uV/rtHz@10Hz and <50nV/rtHz@100Hz) (Attachment 1)

K is quite noisy all over the measured freq range and the level was <50uV/rtHz. Also the PSD has lots of 5Hz harmonics. (Attachment 2)

M has a modest noise level (<~30uV/rtHz@10Hz and <1uV/rtHz@100Hz)except for the noticeable line noise (ripple). (Attachment 3)

The comparison of the three models at 300V is Attachment 4. The other day Gautam and I checked the power spectrum of the HV coil driver with KEPCO and the output noise level of the coil driver was acceptable. So I expect that we will be able to use the HV supply from Company M. Next step is to check the HV driver noise with the model by M used as the supply.

The new HEPA speed controllers are attached at the middle of the HEPA unit (not at the edge of the unit)... (Attachment 1)
You still need a step./stool to touch the knob and need a ladder for a more precise setting.

We still don't know the optimal speed of the nominal IFO operation. For now, the HEPAs are running at the max speed (Attachment 2).
Once we know the optimal setting, we mark the knobs so that we can see them only with the step.

[Anchal, Koji]

Removed the top sheet

• Opened first from the door side so that any dust would spill outside.
• Then rolled the sheet inward to meet in the middle.
• Repeated this twice for the 2 HEPA filters.

Removed the sheets on the table

• Lifted sheet up making sure the top side face outside always.
• Rolled it sideways halfway through.
• Cut down the sheet vertically.
• Slided the doors to the other side and rolled the remaining half.
• On the door side, the sheets above the ALS optics were simply lifted off.

Restarting PSL

• Turned on the HEPAs at the max speed
• Switched on laser to jsut above the threshold
  • Before the 1st eom, power was 20mW 
  • After the EOM/AOM, 18mW. So about 90% transmission through all polarizing optics.
  • We saw the resonances of the PMC but could not lock it even with highest gain available (30 dB).
• Increased the input power to PMC to 100mW
  • Locked the PMC at 30dB gain
  • The transmitted power was ~50-60 mW. (Had to use power meter suspended by hand only.
  • The right before the IMC (after the 2nd EOM) 48mW. So none of the alignment was lost.
• Opened the PSL shutter.
• We were able to see IMC reflection signal.
• We were also able to see IMC catching lock as the servo was left ON earlier.
• Switched off the servo.
• Decided to increase the power while watching PMC Trans/Refl and IMC REFL
• Injection diode current to innolight was increased slowly to 2.10A. Saw a mod hopping region aroun 1.8A.
• We recovered the PMC Trans >0.7 V.
• PZT was near the edge, so moved by one FSR.
• The PMC refelction signal is still shown in red at around 48 mV.

Back to control room

• IMC was locked almost immediately by manually finding the lock while keeping IMC WFS off to preserve the offsets from yesterday.
• Then switch on IMC WFS. Working good.
• Then unlocked the servo and switched on IMC Autolocker. Lock was caught immediately.

Decided to start locking the arms

• The arm transmissions were flashing but at 0.2~0.3 level.
• Decided to adjust TT1 and TT2 Pitch and Yaw to align the light going into the arms.
• This made TRY ~0.6 / TRX ~0.8 at the peak of the flashing
• Locked the arms. (By switching on C1:LSC-MODE_SELECT which engages all servos).
• Used ASS to align Yarm then align Xarm. Procedure:
  • Sitemap > ASC > c1ass
  • Open striptool to look at progress. ! Scripts YARM > striptool.
  • Switch on ASS. ! More Scripts > ON
  • Wait for the TRY to reach to around 0.97.
  • Freeze the outputs. ! Scripts > Freeze Outputs.
  • Offload the offsets to preserve the output. ! More Scripts > OFFLOAD OFFSETS.
  • Switch off ASS. ! More Scripts > OFF
  • Repeted this for XARM.
• At the end, both XARM and YARM were locked with TRX ~ 0.97 and TRY ~ 0.96.

the POS column should be all 1 for the AC balancing. Where did those non-1 numbers come from?

It's probably too late to say but there are/were two boxes. (just for record)

Installed T2 today, and leaked checked the entire line. No issues found. It could have been a bad valve on the tank itself. Monitored T2 pressure for ~2 hours to see if there was any change. All seems ok.

We did a step response test with MC2 Suspensoin Damping Gains and optimized them to get <5 oscillations in ringdown.

Procedure:

• We uploaded the diagonalized input matrix.
• We uploaded the coil balancing gains at high frequencies found in 16054.
• We applied Eg2CtQ1 filter module for DC gain balancing foun inf 16055.
• We set TRAMP to 0 in C1:SUS-MC2_SUSPOS_TRAMP, C1:SUS-MC2_SUSPIT_TRAMP, and C1:SUS-MC2_SUSYAW_TRAMP.
• We played with offsets to get a good step height. Finally we used:
  • C1:SUS-MC2_SUSPOS_OFFSET: 3000
  • C1:SUS-MC2_SUSPIT_OFFSET: 100
  • C1:SUS-MC2_SUSYAW_OFFSET: 100
• We looked at channels C1:SUS-MC2_SUSPOS_INMON, C1:SUS-MC2_SUSPIT_INMON, and C1:SUS-MC2_SUSYAW_INMON on a striptool screen to see the step response of the switching on/off of the offsets.
• We tried to decrease/increase gain to get <5 oscillations during ringdown due to the step inputs.
• Restored everything back to old values at the end.

Results:

• Gain in POS was found to be already good. In PIT and YAW we changed the gains from 10 -> 30.
• Attachment 1 shows the striptool screen when offset was switched ON/Off in POS, PIT and YAW respectively after appling the optimized gains.
• Attachment 2 shows the same test with old gains for comparison.

In the afternoon, we'll complete doing the above steps for MC1 and MC3. Their coil balancing has not been done on DC so, it is bit non-ideal right now. We'll look into scripting this process as well.

I went to the TCS lab to take a look at the chillers lying around. I spotted two chillers:

1. Thermoflex1400 (attachment 1,2). Spec sheet.

2. Polyscience Recirculator 6000 series (attachment 3,4). Manual.

The Thermoflex has various communication ports. The Recirculator doesn't have any communication ports, but it is connected to a flow meter with what seems to be an electronic readout (attachment 5). Manual.

Both chillers have similar capacity ~ 4 gallons/minute. Thermoflex has 2 times more reservoir capacity than the Recirculator.

None of them seem to be Bechkoff-ready.

I guess we can have interlock code handling mixed signals Beckhoff+Non beckhoffs?

The controller would be in the c1sus model, and connects to the c1sup plant model. So the controller doesn't go in the plant model.

Both the controller and the plant can be modeled using a single filter module in each separate model as you've drawn, but they go in separate models.

Note from Stephen on more sensitive Baslers.

So I am stuck on how to add the control block to my model. I am trying to make it as simple as possible with just a simple transfer function for a damped harmonic oscillator and then the control block (see overview.png). 

The transfer function I am using is:

For future generations: To measure the transfer function (to verify that it is doing what it says it is) I am using the discrete transfer function estimator block. To get a quick transfer function estimator Simulink program run ex_discrete_transfer_function_estimator in the Matlab command line. This works well for filters but it was hit or miss using the discrete transfer function. 

The roadblock I am running into right now is that I can't figure out how to add the controller to the model. Not on an interpretation level but in a very straightforward "can I drag it into my model and will it just work" kind of way.

I am also a little confused as to exactly which block would do the controlling. Because I want to just use the x of the pendulum (its position) I think I want to use the suspension controls which come are connected to in the suspension plant model. But where exactly is it and how can I get the model? I can't seem to find it. 

Yikes!  That's ONE filter.  I'll get another from storage.

I also located the (possible) HEPA filters in the lab. (Attachments 1~3)

Oh! This is NO-NO! We can't place anything in front of the mains breakers. (Attachment 2)
I relocated the objects (Attachment 3)

Shutdown Procedure:
PSL Shutter closed / MC Autolocker disabled / PSL mechanical shutter closed / Laser injection current turned to zero / Laser turn off (red button) / Laser key turned off

The laser stat before the shutdown:
- LD Temp A: Set 22.07 (Untouched)
- LD Temp B: Set 21.03(Untouched)
- Laser Injection Current: Dial 9.53, Actual 2.100 -> Dial was moved to zero upon shutting down
- Laser Crystal Temp: Dial 3.34 (untouched)  Set 30.57 Actual 30.60 (Untouched)

PSL Table covering

- Because of the so many cables going up and down, sealing the PSL table with the metalized sheet was not easy. Therefore, the sheets have been just softly laid above the optics. (Attachment 1)
- The largest sheet which covers the east half of the table was taped to the table at the bottom, so that the air from the chimneys (see below) does not come up to the table

- The large dust could come from the opening of the enclosure during the filter replacement. So it was considered to be easier to seal the openings. (Attachment 2)
- Of course, the HEPAs are going to be tested after the maintenance work. It means that vent paths were needed so that the seals do not explode with the pressure (together with dust).
- Thus, the tubes of the sheets are attached to the seals to form "chimneys" for guiding the airflow beneath the table. (Attachment 2/3/4)
- This configuration was not meant to be sufficiently strong for a continuous run of the fans. Long running of the HEPAs may cause the failure of the seal tapes.
  Therefore the HEPA test should be done with a low flow rate and/or a short period of high flow.

- Once the work has been done, all the sheets should be carefully removed without scattering the fallouts onto the optics.

Following up from morning's work, I balanced the coils at DC as well. Attachment 1 is screenshot of striptool in which blue and red traces show ASCYAW and ASCPIT outputs when C1:SUS-MC2_LSC_OFFSET was switched by 500 counts. We see very slight disturbance but no real DC offset shown on PIT and YAW due to position step. This data was taken while nominal F2A filter calculated to balance coils at DC was uploaded

I have uploaded the filters on filter banks 7-10 where FM7 is the nominal filter with Q close to 1 and 8-10 are filters with Q 3, 7 and 10 respectively. The transfer function of these filters can be seen in Attachment 2. Note, that the high frequency gain drops a lot when higher Q filters are used.

These filters are designed such that the total DC gain after the application of coil outputs gains for high frequency balancing (as done in morning 16054) balances the coils at DC.

Since I had access to the complete output matrix that balances the coils to less than 1% cross coupling at high frequencies from 16009, I also did a quick test of DC coil balancing with this kind of high frequency balancing. In this case, I uploaded another set of filters which were made at Q close to 1 and gain such that effective DC gain matrix becomes what I got by balancing in the above case. This set of filter also worked as good as the above filters. This completes the proof that we can also use complete matrix for high frequency coil balancing which can be calculated by a script in 20min and works with DC coil balancing as well. In my opinion, this method is more clear and much faster than toggling values in coil output gains where we have only 4 values to optimize 6 cross-coupling parameters. But don't worry, I'm not wasting time on this and will abandon this effort for now, to be taken up in future.

Next up:

• Tomorrow, we'll finish DC balancing for MC1 and MC3 with the method I practiced today. This should not take much time and should be completed before the meeting.
• I'll also, calculate and upload the F2A filters for MC1 and MC3.
• Next, we'll optimize gains in the suspension damping loops by doing step response test (with TRAMP = 0s). We'll look for decaying response (at MC_F, and WFS sensors) with a few oscillations for each step in POS, PIT, and YAW.

Edit Tue Apr 20 21:25:46 2021 :

Corrected the calculation of filters in case of Q different than . There was a bug in the code which I overlooked. I'll correct the filter bank modules tomorrow.

Edit Wed Apr 21 11:06:42 2021 :

I have uploaded the corrected foton filters. Please see attachment 3 for the transfer functions calculated by foton. They match the filters we intended to upload. Only after uploading and closing the foton filter, I realized that the X=7 filter plot (bottom left in attachment 3) does not have dB units on y-axis. It is plotted in linear y-scale (this plot in foton is for phase by default to I guess I forgot to change the scaling when repurposing it for my plot).

[Paco, Anchal]

• We adopted the following procedure to balance the coil output gains using a high-frequency (> 10 Hz) excitation on "C1:SUS-MCX_ASCPIT_EXC", "C1:SUS-MCX_ASCYAW_EXC", and "C1:SUS-MCX_LSC_EXC", where X is one of {1, 2, 3} for the three IMC optics, and the cavity sensors (MC_F, and MC_TRANS);
  1. We load the new input matrix found on March-23rd.
  2. Using awggui, we launch a single 23.17 Hz sine with 500 - 1000 counts amplitude on the aforementioned channels.
     • We are still unable to launch multiple excitations simultaneously through either API (python-awg or dtt-awggui) 
  3. Using our built-in hominid neural networks, we look at the "C1:IOO-MC_F", "C1:IOO-MC_TRANS_PIT_IN", and "C1:IOO-MC_TRANS_YAW_IN" exponentially averaging power spectra, on and about the excitation frequency, and identify the amount of cross-coupling going into angular or longitudinal motion depending on the excited degree of freedom.
  4. We step the "C1:SUS-MCX_URCOIL_GAIN", "C1:SUS-MCX_ULCOIL_GAIN", "C1:SUS-MCX_LRCOIL_GAIN", "C1:SUS-MCX_LLCOIL_GAIN" coil output gains by hand in the presence of an excitation (e.g. "LSC") along a given degree of freedom (e.g. along "PIT") to try and minimize the coupling.
  5. We iterate step (4) until we find an optimum gain set, and move on to another optic.

Results

• For MC2 the optimal gains changed from: [1.0, -1.0, 1.0, -1.0] → [1.05, -1.05, 0.995, -1.03] **
  • Here we were able to first decouple PIT and YAW from a POS excitation almost entirely (see Attachment #1), but weren't as successful in decoupling YAW and POS from PIT, or PIT and POS from YAW excitations (Attachment #2).
• For MC1 the optimal gains changed from: [1.0, 1.0, 1.0, 1.0] → [0.282, 0.035, 0.302, 2.46] **
  • Here we mostly succeeded in decoupling POS from YAW and PIT excitations (see Attachments #3 - 4).
• For MC3 the optimal gains changed from: [1.0, -1.0, 1.0, -1.0] → [0.126, -0.123, 0.298, -0.306] **
  • Here the LSC_EXC didn't show up on MC_F (??), and the PIT/YAW excitations decouple by virtue of seemingly low gains, so maybe the optimum is an artifact of the lower coil gains...
  • Plots are to follow up for this one.

** The notation here is [UL, UR, LR, LL]

Except for the feed-throughs that require a DB9-M connector I finished wiring and labeling the Acromag, following Jon's updated wiring plan.

We can start testing the differential inputs until the missing connectors arrive.

{Paco, Yehonathan}

We broke the last chunk of ice and cleaned the fridge. We move the fridge back inside and plugged it into the wall. The glues were moved back from the main fridge.

The batteries that were found soaking wet are now somewhat dry and were left on the cabinet drawers for future recycling.

The x1SUSsim model on the docker was made in a more recent version of Simulink so I updated Matlab (see this)

I updated Matlab to 2021a so now the docker has 2020b and 2021a installed. This should also install Simulink 10.3 for the sus model to open. I used my account to activate it but I can change it over if I get a dedicated license for this. I am not sure what Jon did for the 2020b that he installed.

it is giving me "License error: -9,57" so I guess it didn't work... I will try to just make the model on the 2020b just so I have something.

-----------------------------------------------------------------------------------------------------------------------------

I was able to fix the problem with the activation (using this).

I can now open the x1sussim.mdl file. It is trying to access a BSFM_MASTER Library that it doesn't seem to have. the other files don't seem to have any warnings though. 

the simple suspension model can be found in home/controls/docker-cymac/userapps/c1simpsus.mdl on the docker system. This is where I will put my model. (right now it is just a copied file)

Also using Simulink on the docker is very slow. I think this is either a limit of the x2goclient software or the hardware that the docker is running on.

The filters were somewhat successful, how much we can see in attachment 1. The tip about difference between eigenmode basis and cartesian basis was the main thing that helped us take data properly. We still used OSEM data but rotated the output from POS, PIT, YAW to x, theta, phi (cartesian basis where x is also measured as angle projected by suspension length).

Eigenmode basis and Cartesian basis:

• It is important to understand the difference between these two and what channels/sensors read what.
• Eigenmode basis as the name suggests is the natural basis for the suspended pendulum.
  • It signifies the motion along three independent and orthogonal modes of motion: POS (longitudinal pendulum oscillation), PIT, and YAW.
  • The position of optic can be written in eigenmode basis as three numbers:
    • POS: Angle made by the center of mass of optic with verticle line from suspension point.
    • PIT: Angle made by the optic face with the suspension wires (this is important to note).
    • YAW: Angle made by optic surface with the nominal plane of suspension wires. (the yaw angle basically).
• Cartesian basis is the lab reference frame.
  • Here we define three variables that can also represent an optic positioned and orientation:
    • x: Angle made by the center of mass of optic with verticle line from suspension point. (Same as POS)
    • : Angle made by the optic surface with absolute verticle (z-axis) in lab frame.
    • : Twist of the optic around the z-axis. Same as YAW angle above.
• We want to apply the feedback gains and filters in eigenmode basis because they are a set of known independent modes. (RXA: NOOO!!!!!! read me elog entry on this topic)
• Hence, the output from input matrix of suspensions comes out at POS, PIT and YAW in the eigenmode basis.
• However, the sensors of optic positional, and orientation such at MC_F, wave front sensors and optical levers measure it in lab frame and thus in cartesian basis.
• Essentially, the measured by these sensors is different from the PIT calculated using the OSEM sensor data and is related by:
  • , where PIT and POS both are in radians as defined above.
• When we optimized the cross-coupling in output matrix at high frequencies using the MC_F and WFS data, we actually optimized it In cartesian basis.
• The three feedback filters from POS, PIT and YAW which carry data in the eigenmode basis need to be rotated into the cartesian basis in the output matrix before application to the coils.
• The so-called F2A and A2L filters are essentially doing this rotation.
• Above the resonant frequencies, the PIT and become identical. Hence we want our filters to go to unity

The two filter sets:

• The filters are named Eg2Ctv1 and Eg2Ctv2 on the POS column of MC2 output matrix.
• This is to signify that these filters convert the POS, PIT, and YAW basis data (eigenmode basis data) into the cartesian basis (x, theta, phi) in which the output matrix is already optimized at higher frequencies.
• v1 filter used an ideal output matrix during the calculation of filter as described in 16042 (script at scripts/SUS/OutMatCalc/coilBalanceDC.py).
• Attachment 2 shows these filter transfer functions.
• v2 filter use the output matrix optimized to reduce cross-coupling amount cartesian basis modes (MC_F, WFS_PIT and WFS_YAW) in 16009.
• Attachment 3 shows these filter transfer funcitons.
• Because of this, the v2 filter is different among right and left coils as well. We do see in Attachment 1 that this version of filter helps in reducing POS->YAW coupling too.

Test procedure:

• We uploaded both the diagonalized input matrix and the diagonalized output matrix as calculated earlier.
• We measured channels C1:SUS-MC2_SUSPOS_IN1_DQ, C1:SUS-MC2_SUSPIT_IN1_DQ, and C1:SUS-MC2_SUSYAW_IN1_DQ throughout this test.
• These channels give output in an eigenmode basis (POS, PIT, and YAW) and the rows of the input matrix have some arbitrary normalization.
• We normalize these channels to have same input matrix normalization as would be for ideal matrix (2 in each row).
• Then, assuming the UL_SENS, UR_SENS, LR_SENS, and LL_SENS channels that come at input of the input matrix are calibrated in units of um, we calculate the cartesian angles x, theta, phi. for this calculation, we used the distance between coils as 49.4 mm (got it from Koji) and length of suspension as 0.2489 m and offset of suspension points from COM, b = 0.9 mm.
• Now that we have true measures of angles in cartesian basis, we can use them to understand the effect on cross coupling from the filters we used.
• PSL shutter is closed and autolocker is disabled. During all data measurements, we switched of suspension damping loops. This would ensure that our low frequency excitation survives for measurement at the measurement channels.
• We first took reference data with no excitation and no filters for getting a baseline on each channel (dotted curves in Attachment 1).
• We then send excitation of 0.03 Hz with 500 counts amplitude at C1:SUS-MC2_LSC_EXC and switched on LSC output.
• One set of data is taken with no filters active (dashed curve in attachment 1).
• Then two sets of data are taken with the two filters. Each data set was of 500s in length.
• Welch function is used to take the PSD of data with bin widht of  0.01Hz and 9 averages.

Results:

• Filter v1 was the most successful in reducing  coupling by factor of 17.5.
  • The reduction in  coupling was less. By a factor of 1.4.
• Filter v2 was worse but still did a reduction of coupling by factor of 7.8.
  • The reduction in  coupling was better. By a factor of 3.3.

Next, filters in PIT columns too

• We do have filters calculated for PIT as well.
• Now that we know how to test these properly, we can test them tomorrow fairly quickly.
• For the YAW column though, the filters would probably just undo the output matrix optimization as they are derived from ideal transfer function models and ideally there is no coupling between YAW and other DOFs. So maybe, we should skip putting these on.

{Anchal, Paco, Yehonathan}

We took the glue fridge outside.

When I came into the lab this morning, I noticed that both N2 tanks were empty. I had swapped one on Friday (4-16-21) before I left the lab. Looking at the logs, the right tank (T2) sprung a leak shortly shortly after install. I leak checked the tank coupling after install but did not see a leak. There could a leak further down the line, possibly at the pressure transducer.

The left tank (T1) emptied normally over the weekend, and I quickly swapped the left tank for a full one, and is curently at ~2700 psi. It was my understanding that if both tanks emptied, V1 would close automatically and a mailer would be sent out to the 40m group. I did not receive an email over the weekend, and I checked the Vac status just now and V1 was still open.

I will keep an eye on the tank pressure throughout the day, and will try to leak check the T2 line this afternoon, but someone should check the vacuum interlocks and verify.

• Ideally, we put the chiller outside of the interferometer area. The PSL chiller used to be in the control room near the door by IMC REFL. We could also put it in the drill press room.
• Once we figure out a couple of places where the Diode Box can go, we can ask facilities to make the appropriate power connections. They will have to eval the situation to figure out if the main power to the lab needs to be shut down.
• Can we put the laser diode box in the drill press room too? Then the hoses can be short. Perhaps less EMI getting into our sensitive places.

There is still a huge chunk of unmelted ice in the fridge. I moved the content of that fridge in the main fridge and put "do not eat" warning signs.

I returned the fridge to the lab and plugged it back in to prevent flooding.

Defrosting will have to continue on Monday.