The coil balancing attempt failed. The off-diagonal values in the measured sensing matrices either remained the same or increased.

The attempt in the morning was too slow. By the time we reached, it had reached to iteration 7 only and still nowhere near optimum sensing matrix had reached. We still needed to see if the optimum would eventually reach if more iterations happened.

<Radhika came for shadowing us and learning about 40m>

So we worked a bit on speeding up the data loading process and then ran the code again which now was running much faster. Still within 1 hr or so, we saw it had reached to iteration 7 with no sign of sensing matrix getting any better.

<Paco left for vaccination>

To determine if the method would work in principle, I decided to stop the current run and start with a 0.5 Hz bandwidth run (so about 7 averages with 8s duration data and welch method). This completed 20 iterations before Gautum came. But it was clear now that the method is not converging to a better solution. Need to find a bug in the implementation of the algorithm mentioned in last post or find a better algoritm.

Attachment 1 is the plot of how the sensing matrix's distance from the identity matrix increased over iterations in the last run.

Attachment 2 is the plot for different off-diagonal terms in the sensing matrix. It is clear that POS->PIT,YAW coupling is not being measured properly as it remains constant.

Attachment 3 Gautum told us that there is some naming error in nds and MC_TRANS_PIT/YAW can be read through C1:IOO-MC_TRANS_PIT_ERR and C1:IOO-MC_TRANS_YAW_ERR channels instead. To test if they indeed point to same values, we did a test of exciting YAW degree through LOCKIN1 and seeing if the peaks are visible in the channels. This was also done to give Radhika an opportunity to do something I could confidently mentor about. and to experience using diaggui.

After fixing a few things we felt were wrong in our implementation of the algorithm, we ran the coil balancing for 12 iterations with just 11s per excitation and still taking CSD with 0.1 Hz bandwidth. This time we saw the distance of sensing matrix from identity going down.

Performance Analysis

• Attachment 1 shows the trend of distance of Sensing matrix from identity matrix over iterations.
• Attachment 2 shows the trend of off-diagonal terms in sensing matrix over iterations.
• Attachment 3 shows the ASD for the different sensed DOF when excited in different DOFs with the new output matrix. This is the better truth of what happened by the end. The true sensing matrix is proportional to the peak heights in this plot. Rows are different sensed DOFs (POS, PIT, YAW) and columns are excited DOFs (POS, PIT, YAW). The black dotted curves are ASD when no excitation was present.

Next step

• We want to run it for longer, more iterations and more duration to get better averaging. Hopefully, this will do a better job. We'll try running this new code tomorrow at 5:00am.
• We'll work on using uncertainties of measured data.
• Use awg to excite all DOF together at different frequencies and make the code faster.

All small components are packed in the boxes. They are ready to ship.

In these results, can you also include the new matrix and what the relative imbalances were?

A longer measurement is set to trigger at 5:00 tomorrow on April 2nd, 2021. This measurement will run for 35 iterations with an excitation duration of 120s and bandwidth for CSD measurement set to 0.1 Hz. The script is set to trigger in a tmux session named 'cB' on pianosa.

[koji, gautam]

Summary:

We could not find problems with any individual piece of the REFL55 electronics chain, from photodiode to ADC.  Nevertheless, the PRMI fringes witnessed by REFL55 is ~x10 higher than ~two weeks ago, when the PRMI could be repeatably and reliably locked using REFL55 signals (ETMs misaligned).

Details:

1. Koji prepared a spare whitening board. However, before he swapped it in, he checked the existing board and found no problems with it.
   • 20mV input signal, 100 Hz was injected into the two REFL55 channels on the whitening board.
   • The flat whitening gain was set to +45 dB.
   • The signal levels seen in CDS was consistent with what is expected given an ADC conversion factor of 3276.8 cts/V.
2. Tried putting the REFL55 demodulated outputs into the next two channels, 5&6, (currently unused) on the same whitening board.
   • After setting the whitening gains of these two channels also to +18dB, the saturation of the ADCs when the PRMI was fringing persisted.
3. With the dark noise of the whitening filter, we enabled/disabled the on board frequency dependent whitening, and reasoned that the time domain increase in RMS seemed reasonable. So we decided to investigate parts of the electronics chain upstream of the whitening board, since we couldn't find anything obviously wrong with the whitening board.
4. Injected -10dBm RF signal (=0.2 Vpp) into the RF input on the REFL55 demod board, and saw ~3500 cts-pp signal in CDS. This is totally consistent with my recent characterization of 16,000 cts/V for this demod board at the "nominal" + 18dB whitening gain setting. So the demodulator seems to function as advertised.
5. Decided to repeat my test of using the Jenne laser to test the whole chain end-to-end.
   • In summary, we recovered the results (RF transimpedance of the PD, and signal levels in CDS for a known AM determined by the reference NF1611 PD) I reported there.
   • So it would seem that the entire REFL55 electronics chain performs as expected.
   • The only remaining explanation is that the optical gain of the PRMI has increased - but how?? 
   • Similar jumps in the REFL55 signal levels have occurred multiple times in the past, and each time, I was able to recover the "nominal" performance by this procedure (though I have no idea why that should work at all).
   • So I am highly skeptical that this has anything to do with the IFO optical gain, but that is the only difference between our AM laser based test and the "live" operating conditions when the signals are saturated.

Discussion and next steps:

Q: Koji asked me what is the problem with this apparent increased optical gain - can't we just compensate by decreasing the whitening gain?
A: I am unable to transition control of the PRMI (no ETMs) from 3f to 1f, even after reducing the whitening gain on the REFL55 channels to prevent the saturation. So I think we need to get to the bottom of whatever the problem is here.

Q: Why do we need to transfer the control of the vertex to the 1f signals at all?
A: I haven't got a plot in the elog, but from when I had the PRFPMI locked last year, the DARM noise between 100-1kHz had high coherence with the MICH control signal. I tried some feedforward to try and cancel it but never got anywhere. It isn't a quantitative statement but the 1f signals are expected to be cleaner?

Koji pointed out that the MICH signal is visible in the REFL55 channels even when the PRM is misaligned, so I'm gonna look back at the trend data to see if I can identify when this apparent increase in the signal levels occurred and if I can identify some event in the lab that caused it. We also discussed using the ratio of MICH signals in REFL and AS to better estimate the losses in the REFL path - the Faraday losses in particular are a total unknown, but in the AS path, there is less uncertainty since we know the SRM transmission quite precisely, and I guess the 6 output steering mirrors can be assumed to be R=99%. 

Last run gave similar results as the quick run we did earlier. The code has been unable to strike out couplings with POS. We found the bug which is causing this. This was because the sampling rate of MC_F channel is different from the test-point channels used for PIT and YAW. Even though we were aware of it, we made an error in handling it while calculating CSD. Due to this, CSD calculation with POS data was performed by the code with zero padding which made it think that no PIT/YAW <-> POS coupling exist. Hence our code was only able to fix PIT <-> YAW couplings.

We'll need to do another run with this bug fixed. I'll update this post with details of the new measurement.

How should I try to understand why PIT and YAW are so different? 

Summary:

I wanted to put my optomechanical instability hypothesis to the test. So I decided to cut the input power to the IMC by ~half and try locking the PRFPMI. However, this did not improve the stability of the buildup in the arm cavities, while the control was solely on the ALS error signal. 

Details:

1. The waveplate I installed for this purpose was rotated until the MC RFPD DCMON channel reported ~half it's nominal value.
2. I adjusted the IMC servo gains appropriately to compensate. IMC lock was readily realized.
3. I increased the whitening gains on the POX, POY and REFL165 photodiodes by 6dB, to compensate for the reduced light levels.
   • One day soon, we will have remote power control, and it'd be nice to have this process be automated.
   • Really, we should have de-whitening filters that undo these flat gains in addition to undoing the frequency dependent whitening.
   • I'm not sure the quality of the electronics is good enough though, for the changing electronics offsets to not be a problem.
   • One possibility is that we can normalize some signals by the DC light level at that port, but I still think compensating the changing optical gain as far upstream as possible is best, and the whitening gain is the convenient stage to do this.
4. Recovered single arm POX/POY locking. 
5. Then I decided to try and lock the PRFPMI with the reduced input power.

Basically, with some tweaks to loop gains, it worked, see Attachment #1. Note that the lower right axis shows the IMC transmission and is ~7500 cts, vs the nominal ~15,000 cts.

Discussion:

Cutting the input power did not have the effect I hoped it would. Basically, I was hoping to zero the optical CARM offset while the IFO was entirely under ALS control, and have the arm transmission be stable (or at least, stay in the linear regime of REFL11). However, the observation was that the IFO did the usual "buzzing" in and out of the linear regime. Right now, this is not at all a problem - once the IR error signal is blended in, and DC control authority is transferred to that signal, the lock acquisition can proceed just fine. And I guess it is cool that we can lock the IFO at ~half the input power, something to keep in mind when we have the remote controlled waveplate, maybe we always want to lock at the lowest power possible such that optomechanical transients are not a problem. 

I also don't think this test directly disputes my claim that the residual CARM noise when the arm cavities are under purely ALS control is smaller than the CARM linewidth.

What does this mean for my hypothesis? I still think it is valid, maybe the power has to be cut even further for the optomechanics to not be a problem. In Finesse (see Attachment #2), with 0.3 W input power to the back of the PRM, and with best guesses for the 40m optical losses in the PRC and arms, I still see that considerable phase can be eaten up due to the optomechanical resonance around ~100 Hz, which is where the digital CARM loop UGF is. So I guess it isn't entirely unreasonable that the instability didn't go away?

After this work, I undid all the changes I made for the low power lock test. I confirmed that IMC locking, POX/POY locking, and the dither alignment systems all function as expected after I reverted the system.

[Paco, Anchal]

Came in a little bit after 8 and found the MC unlocked and struggling to lock for the past 3 hours. Looking at the SUS overview, both MC1 and ITMX Watchdogs had tripped so we damped the suspensions and brought them back to a good state. The autolocker was still not able to catch lock, so we cleared the WFS filter history to remove large angular offsets in MC1 and after this the MC caught its lock again.

Looks like two EQs came in at around 4:45 AM (Pacific) suggested by a couple of spikes in the seismic rainbow, and this.

Since it seems like the entire electronics chain has no obvious failure, I decided to compensate for the apparent increased optical gain by turning the flat whitening gain down from +18dB to 0dB. Then, after some fiddling around with alignment, settings etc, I was able to lock the PRMI once again, with the ETMs misaligned, using REFL55_I to sense PRCL, and REFL55_Q to sense MICH. Some sensing matrices attached. Some notes:

1. I made some changes to the presentation so that the units of the sensing matrix are now in [W/m] sensed on a photodiode. 
   • The info printed on the plot is also more verbose, I now indicate explicitly the actuator driven to make the measurement, and also the drive frequency. The various gains used to convert counts to Watts on a photodiode are also indicated.
   • I thought about printing the actual matrix too but haven't arrived at a clean prez style yet.
   • This is to facilitate easier comparison to Finesse models / analytic calcs.
   • I take into account all the gains from the photodetector to the servo error point where the measurement is made. However, the splitting fractions between various photodiodes is not included, so you will have to do that yourself when comparing to a Finesse model.
   • For example, in pg2 of Attachment #1, the measured gain of PRCL sensed in REFL55_I is ~2e6 W/m. But only ~4% of IFO REFL ends up on the REFL55 photodiode. So, this measurement would be consistent with a Finesse simulated optical gain of ~50MW/m, which is in the ballpark of what I do actually see.
2. There seems to be reasonable agreement between Finesse and these measurements. But why should the old settings / locking have worked at all then?
3. I tried two schemes for MICH actuation today.
   • The first was the usual BS + PRM combo, and I got the sensing matrix on pg 1 of Attachment #1. With this scheme, the MICH/PRCL orthogonality is a joke.
   • Then I changed the MICH actuator to the ITMs, and got the sensing matrix on pg 2 of Attachment #1. With this scheme, the orthogonality looks much better. I think the slight non-orthogonality in the 11/33 MHz photodiodes may even be reasonable, since the 11 MHz field isn't a good sensor of the anti-symmetric modes, but have to confirm by calculation/simulation. But certainly the separation of signals is much cleaner when the ITMs are used to control MICH.

So there is clearly something funky with the nominal MICH actuation scheme (MICH suspension, PRM suspension or both), which we should get to the bottom of before trying any low noise locking. I think using the ITMs as the MICH actuator in the full lock will not be a good low nosie strategy, as we would then be "polluting" all our suspended optics with our control loops, which seems highly suboptimal for technical noise sources like coil driver noise etc.

Yesterday Chris and I completed setup of the Supermicro machine that will serve as a dedicated host for developing and testing RTCDS sim models. It is currently sitting in the stack of machines in the FE test stand, though it should eventually be moved into a permanent rack.

It turns out the machine cannot run 10 user models, only 4. Hyperthreading was enabled in the BIOS settings, which created the illusion of there being 12 rather than 6 physical cores. Between Chris and Ian's sim models, we already have a fully-loaded machine. There are several more of these spare 6-core machines that could be set up to run additional models. But in the long term, and especially in Ian's case where the IFO sim models will all need to communicate with one another (this is a self-contained cymac, not a distributed FE system), we may need to buy a larger machine with 16 or 32 cores.

IPMI was set up for the c1sim cymac. I assigned the IPMI interface a static IP address on the Martian network (192.168.113.45) and registered it in the usual way with the domain name server on chiara. After updating the BIOS settings and rebooting, I was able to remotely power off and back on the machine following these instructions.

I/O chassis assembly

Yesterday I installed all the available ADC/DAC/BIO modules and adapter boards into the new I/O chassis (c1bhd, c1sus2). We are still missing three ADC adapter boards and six 18-bit DACs. A thorough search of the FE cabinet turned up several 16-bit DACs, but only one adapter board. Since one 16-bit DAC is required anyway for c1sus2, I installed the one complete set in that chassis.

Below is the current state of each chassis. Missing components are highlighted in yellow. We cannot proceed to loopback testing until at least some of the missing hardware is in hand.

C1BHD

C1SUS2

Gateway for remote access

To enable remote access to the machines on the test stand subnet, one machine must function as a gateway server. Initially, I tried to set this up using the second network interface of the chiara clone. However, having two active interfaces caused problems for the DHCP and FTS servers and broke the diskless FE booting. Debugging this would have required making changes to the network configuration that would have to be remembered and reverted, were the chiara disk to ever to be used in the original machine.

So instead, I simply grabbed another of the (unused) 1U Supermicro servers from the 1Y1 rack and set it up on the subnet as a standalone gateway server. The machine is named c1teststand. Its first network interface is connected to the general computing network (ligo.caltech.edu) and the second to the test-stand subnet. It has no connection to the Martian subnet. I installed Debian 10.9 anticipating that, when the machine is no longer needed in the test stand, it can be converted into another docker-cymac for to run additional sim models.

Currently, the outside-facing IP address is assigned via DHCP and so periodically changes. I've asked Larry to assign it a static IP on the ligo.caltech.edu domain, so that it can be accessed analogously to nodus.

We got some dumbells from Re-Source Manufacturing (see attached). I picked 3 in random and measured their dimensions:

1. 0.0760" in diameter, 0.0860" in length

2. 0.0760" in diameter, 0.0860" in length

3. 0.0760" in diameter, 0.0865" in length

In accordance with the Schematics.

As mentioned in last post, we earlier made an error in making sure that all time series arrays go in with same sampling rate in CSD calculation. When we fixed that, our recursive method just blew out in all the efforts since then.

We suspect a major issue is how our measured sensing matrix (the cross-coupling matrix between different degrees of freedom on excitation) has significant imaginary parts in it. We discard the imaginary vaues and only use real parts for iterative method, but we think this is not the solution.

Here we present cross-spectral density of different channels representing the three sensed DOFs (normalized by ASD of no excitation data for each involved component) and the sensing matrix (TF estimate) calculated by normalizing the first cross spectral density plots column wise by the diagonal values. These are measured with existing ideal output matrix but with the new input matrix. This is to get an idea of how these elements look when we use them.

Note, that we used only 10 seconds of data in this run and used binwidth of 0.25Hz. When we used binwidth of 0.1 Hz, we found that the peaks were broad and highest at 13.1 Hz instead of 13 Hz which is the excitation frequency used in these measurements.

How should we proceed?

• We feel that we should figure out a way to use the imaginary value of the sensing matrix, either directly or as weights representing noise in that particular data point.
• Should we increase the excitation amplitude? We are currently using 500 counts of excitation on coil output.
• Are there any other iterative methods for finding the inverse of the matrix that we should be aware of? Our current method is rudimentary and converges linearly.
• Should we use the absolute value of the sensing matrix instead? In our experience, that is equivalent to simply taking ratios of the PSD of each channel and does not work as well as the TF estimate method.

Basically I went around all the chambers and all the DB25 flanges to check the invac cable configurations. Also took more time to check the coil Rs and Ls.

Exceptions are the TTs. To avoid unexpected misalignment of the TTs, I didn't try to disconnect the TT cables from the flanges.

Upon the disconnection of the SOS cables, the following steps are taken to avoid large impact to the SOSs

• The alignment biases were saved or recorded.
• Gradually moved the biases to 0
• Turned off the watchdogs (thus damping)

After the measurement, IMC was lock and aligned. The two arms were locked and aligned with ASS. And the PRM alignment (when "misalign" was disengaged) was checked with the REFL CCD.
So I believe the SOSs are functioning as before, but if you find anything, please let me know.
 

Adding the chamfer around the edge of the optic ring did not change the center of mass relative to the plane from the suspension wires.

The CoM was .0003" away from the plane. Adding the chamfer moved it closer by .0001". See the attached photo.

I've also attached the list of the Moments of Inertia of the SOS Assembly.

To test if our method is working at all, we went for the simpler case of just uncoupling PIT and YAW. This is also because the sensor used for these two degrees of freedom is similar (the MC Trans WFS).

We saw a successful decrease in cross-coupling between PIT and YAW over the first 50 iterations that we tried. Here are some results:

Final output matrix:

Plots:

• Attachment 1 shows distance of sensing matrix from identity as iterations go.
• Attachment 2 shows the off-diagonal elements of sensing matrix as the iterations increase.
  • It is worth noting that PIT -> YAW coupling was the main element that was reduced successfully while the YAW -> PIT was reducing but much more slowly.
  • Most of the remaining cross coupling in the end was from YAW -> PIT.
• Attachment 3 shows first 10 oscillations in the time series data during excitation of some of the iterations.
• Attachment 4 shows the cross spectral density of the sensed data during excitation with each other. This has been normalized by reference PSD data (taken with no excitation) of the sensed DOFs involved in the CSD calculation.
• Attachment 5 shows the TF estimate made by normalizing CSD data column wise by the diagonal elements. The excitation frequency point in these plots become the Sensing matrix in the calculation.
  • One can notice how the PIT -> YAW element is going down in these plots.
  • Even though we are using only the real value of the sensing matrix, the imaginary values are also going down.

Next, tried uncoupling POS and PIT:

• Next, we tried to uncouple POS and PIT. We expect them to be more coupled than with YAW.
• At the time of writing this post, 15 iterations of this attempt have been completed and it is not looking good .
• The distance of the sensing matrix from identity is growing at an accelerated rate.
• The POS output matrix column seems to be trying to go towards the negative of PIT output matrix column! Why? We don't know.
• We have seen in the past that once POS transforms into PIT or YAW, it just makes the output matrix worse as no feedback actually goes into the POS column. Eventually, the IMC will cease to remain locked.
• So, I'm cancelling this attempt for now. Will consider more alternatives later.

Summary:

I spent an hour today evening checking out the remote waveplate operation. Basic remote operation was established 👍 . To run a test on the main beam (or any beam for that matter), we need to lay out some long cabling, and install the controller in a rack. I will work with Jordan in the coming days to do these things. Apart from the hardware, some EPICS channel will need to be added to the c1ioo.db file and a python script will need to be set up as a service to allow remote operation.

Part numbers:

• The controller is a NewFocus ESP300.
• The waveplate stage is a PR50CC. The waveplate itself that is mounted has a 1" diameter (clear aperture is more like 21mm), which I think is ~twice the size of the waveplates we have in the lab, good thing Livingston shipped us the waveplate itself too. It is labelled QWPO-1064-10-2, so should be a half wave plate as we want, but I didn't explicitly check with a linearly polarized beam today. Before any serious high power tests, we can first contact clean the waveplate to avoid any burning of dirt. The damage threshold is rated as 1 MW/cm^2, and I estimate that we will be well below this threshold for any power levels (<30W) we are planning to put through this waveplate. For a 100um radius beam with 30W, the peak intensity is ~0.2 MW/cm^2. This is 20% of the rated damage threshold, so may be better to enforce that the beam be >200um going through this waveplate.
• The dimensions of the mount look compatible with the space we have on the PSL table (though of course once the amplifier comes into the picture, we will have to change the layout. Maybe it's better to keep everything downstream of the PMC fixed - then we just re-position the seed beam (i.e. NPRO) and amplifier, and then mode-match the output of the amplifier to the PMC.

Electrical tests:

1. First, I connected a power cord to the ESP300 and powered it on - the front display lit up and displayed a bunch of diagnostics, and said something to the effect of "No stage connected".
2. Next, I connected the rotary mount to "Axis #1": Male DB25 on the stage to female DB25 on the rear of the ESP300. The stage was recognized.
3. Used the buttons on the front panel to rotate the waveplate, and confirmed visually that rotation was happening 👍 . I didn't calibrate the actual degrees of rotation against the readback on the front panel, but 45 degrees on the panel looked like 45 degrees rotation of the physical stage so seems fine.

RS232 tests:

• This unit only has a 9-pin Dsub connector to interface remotely to it, via RS232 protocol. c1psl Supermicro host was designated the computer with which I would attempt remote control.
• To test, I decided to use a serial-USB adapter. Since this is only a single unit, no need to get an RS232-ethernet interface like the one used in the vacuum rack, but if there are strong opinions otherwise we can adopt some other wiring/control philosophy.
• No drivers needed to be installed, the host recognized the adapter immediately. I then shifted the waveplate and controller assembly to inside the VEA - they are sitting on a cart behind 1X2. Once the controller was connected to the USB-serial adapter cable, it was registered at /dev/ttyUSB0 immediately. I had to chown this port to the controls user for accessing it using python serial. 
• Initially, I was pleasantly surprised when I found not one but TWO projects on PyPi that already claimed to do what I want! Sadly, neither NewportESP1.1 nor PyMeasure0.9.0 actually worked - the former is for python2 (and the string typesetting has changed for PySerial compatible with python3), while the latter seems to be optimized for Labview interfacing and didn't play so nice with the serial-USB adapter. I didn't want to spend >10mins on this and I know enough python serial to do the interfacing myself, so I pushed ahead. Good thing we have several pySerial experts in the group now, if any of you want to figure out how we can make either of these two utilities actually work for us - there is also this repo which claims to work for python 3 but I didn't try it because it isn't a managed package.
• The command list is rather intimidating, it runs for some 100 (!) pages. Nevertheless, I used some basic commands to readback the serial number of the controller, and also succeeded in moving the stage around  by issuing the "PR" command appropriately 👍. BTW, I forgot that I didn't test the motor enable/disable which is an essential channel I think.
• I think we actually only need a very minimal set of commands, so we don't need to read all 100 pages of instructions:
  • motor enable/disable
  • absolute and relative rotations
  • readback of the current position
  • readback of the moving status
  • a stop command
  • an interlock
• Note that as a part of this work, in addition to chowning /dev/ttyUSB0, I installed the two aforementioned python packages on c1psl. I saw no reason to manually restart the modbus and latch services running on it, and I don't believe this work would have impacted the correct functioning of either of those two services, but be aware that I was poking around on c1psl. I was also reminded that the system python on this machine is 2.7 - basically, only the latch service that takes care of the gains for the IMC servo board are dependent on python (and my proposed waveplate control script will be too), but we should really upgrade the default python to 3.7/3.8.

Next steps:

Satisfied that the unit works basically as expected, I decided to stop for today. My thinking was that we can have the ESP300 installed in 1X1 or 1X2 (depending on where space is more readily available). I will upload have uploaded a cartoon here so people can comment if they like/dislike my plan. 

• We need to use a long-ish cable to run from 1X1/1X2, where the controller will be housed, to the PSL enclosure. Livingston did ship one such long cable (still on Rana's table), but I didn't check if the length is sufficient / the functionality of this long cable. 
• We need to set up some EPICS channels for the rotation stage angle, motor ENABLE/DISABLE, a "move stage" button, motion status, and maybe a channel to control the rotation speed? 
• We need a python script that is reading from / writing to these EPICS channel in a while loop. Should be straightforward to setup something to run like the latch.py service that has worked decently reliably for ~a year now. afaik, there isn't a good way to run this synchronously, and the delay in sending/completing the execution of some of the serial commands might be ~1 second, but for the purpose of slowly ramping up the power, this shouldn't be a problem.
• One question I do have is, what is the strategy to protect the IFO from the high power when the lock is lost? Surely we are not gonna rely on this waveplate for any fast actuation? With the current input power of 1W, the MCREFL photodiode sees ~100mW when the IMC loses lock. So if the final input power is 35W, do we wanna change the T=10% beamsplitter in the MCREFL path to keep this ratio?

Once everything is installed, we can run some tests to see if the rotary motion disturbs the PSL in any meaningful way. I will upload some photos to the picasa later. Photos here.

Today, we finally crossed the last hurdle and got a successful converging coil balancing run.

What was the issue with POS?

• Position of the MC2 mirror is being sensed using C1:IOO-MC_F_DQ channel which is proportional to the resonant frequency of the locked IMC.
• However, this sensor is always 180 degrees out of phase of our actuator, the coils.
• When the coils push the mirror forward, the length of the cavity actually decreases.
• We added an extra option of providing a sign to the sensors such that -1 will be multiplied to sensed values for sensors which measure in opposite direction to the actuation.
• This is important, because the feedback is applied to the coil output matrix assuming a particular direction of acctuation.
• When we gave negative sign for the position sensor, it all started making sense and the algorithm started converging.

First run parameters:

• We used binwidth of 0.25 Hz and duration of excitation as 41s. This would give welch and csd averaging of 19. We used median averaging to ignore outliers.
• This iteration was run after PIT and YAW were separetly uncoupled before. We'll post a clean start to end run results in near future.
• The iteration works in following manner:
  • Define a constant coil matrix C = [[1, 1, 1], [1, 1, -1], [1, -1, 1], [1, -1, -1]] which is ideal coil output matrix.
  • In each iteration, the output matrix O_k is defined as (note @ is the matmul operator):
    O_k = C @ A_k
    where A_k is a 3x3 matrix. A_-1 is identity matrix.
  • At the end of each iteration, a sensing matrix is calculated in dimensions sensedDOF x excitedDOF, S_k
  • For next iteration, A_k+1 is calcualted by:
    A_k+1 = A_k - b * (S_k - I)
    where I is the identity matrix.
  • At convergence, the sensing matrix would become same as identity and matrix A will stop updating.
• For this run, we kept the parameter b to be 0.05. This is similar to the K_P parameter in PID loops. It should be between 0 and 1.
• Since b value was small enough to allow for convergence from the inital point, but later it slowed down the process a lot.
• Ideally, we should figure out a way to increase this paramter when the coil has been balanced somewhat, to increase the speed of the algorithm.
• Secondly, we have a code which excites all DOFs at different frequencies directly using excitation channels in coil output matrix using awg.py. But for some reason, the excitation channel for 4th row in the output matrix column only connects intermittantly. Because of this, we can't use this method reliably yet. We can investigate more into it if suggested.

Balancing characteristics:

• Attachment 1 shows how the distance of sensing matrix falls as iterations increase. We only ran for 50 iterations.
• Attachment 2 shows how different off-diagonal terms of sensing matrix decreased.
  • Note that POS -> PIT, POS -> YAW and PIT-YAW have settled down to the noise floor.
  • The noise floor can be improved by increasing the excitation amplitude and/or increasing the duration of measurement.
• Attachment 3 shows the evolution of sensing matrix as iterations move.

Final balanced output matrix:

Code features and next:

• Majority of the code is in two files: scripts/SUS/OutMatCalc/MC2crossCoupleTest.py and scripts/SUS/OutMatCalc/crossCoupleTest.py .
• The code runs from start to end without human involevement and restores the state of channels in any case (error, kyboard interrupt, end of code) using finally statement.
• Currently, each excitation is done one at a time through LockIn1. As mentioned above, this can be sped up 3 times if we get the awg.py to work reliably.
• The complete code is in python3 and currently is run through native python3 on allegra (a new debian10 workstation with latest cds-workstation installed).
• The code can be easily generalized for balancing any optic. Please let us know if we should work on making the generalized optic.
• We're also working on thinking about increasing b as iterations move forward and the error signal becomes smaller.
• We can also include the uncertainty in the Sensing matrix measurement to provide a weighted feedback. That way, we can probably increase b more.

5x 16bit ADC adapter boards (D0902006) assembled.

We ran again this method but with the 'b' parameter as a matrix instead. This provides more gain on some off-diagonal terms than others. This gave us a better convergence with the code reaching to the tolerance level provided (0.01 distance of S matrix from identity) within 16 iterations (~17 mins).

Attachment 1 again shows how the off-diagonal terms go down and how the overall distance of sensing matrix from identity goes down. This is 'Cross coupling budget' of the coils as iterations move forward.

Jumping to near zero-crossing:

• Rana mentioned a ezlockin code which first makes 5 step changes in output matrix without using feedback and calculates the changes required to reach zero-crossing in the behavior of the off-diagonal terms during these steps.
• This is similar to what we did above by hand where we increased the value of b for slowly converging off-diagonal elements.
• We plan to implement this 'jump' to near zero-crossing method next. Aim is to get a coil balancing code that does the job in ~5 min.
• We have been throwing away imaginary part of sensing matrix so far. We wanted to get to some owrking solution before we try more complex stuff. We have to figure out global phases in each transfer function estimate to rotate the measured transfer function appropriately.

convergence is great.

Next we wanna get the F2A filters made since most of the IMC control happens at f < 3 Hz. Once you have the SUS state space model, you should be able to see how this can be done using only the free'swinging eigenfrequencies. Then you should get the closed loop model including the F2A filters and the damping filters to see what the closed loop behavior is like.

Today I assembled the skeleton of 6 towers, without clamps and sensor assembly (attachment 1).

Some of the side plates have this weird hole that doesn't fit any of the suspension blocks (attachment 2). I didn't notice when I counted the parts and now there are exactly enough side plates to assemble 7 towers.

Also found that one of the stiffener plates has a broken threading.

We will need more parts to go beyond the necessary 7 SOSs. I will do the recounting later.

Things to do next:

1. Find the capped spring plungers and send them to C&B.

2. Assemble the clamps onto the suspension blocks.

3. Push some Viton tips into the vented screws we got to make safety stops.

4. more C&B: Magnets, dumbells, dowel pins, OSEMs.

5. Push clean dowel pins into the last suspension block.

6. Assemble 7th Tower.

7. Assemble safety stops and clamps.

8. Glue magnets to dumbells.

I installed three of the 16-bit ADC adapter boards assembled by Koji. Now, the only missing hardware is the 18-bit DACs (quantities below). As I mentioned this week, there are 2-3 16-bit DACs available in the FE cabinet. They could be used if more 16-bit adapter boards could be procured.

I think I mis-spoke about the balancing channels before. The ~20 Hz balancing could go into either the COIL banks or the SUS output matrix.

I believe its more conceptually clean to do this as gains in the outputmatrix, and leave the coil gains as +/- 1. i.e. we would only use the coil gains to compensate for coil/magnet actuation strength.

Then the high frequency balance goes into the outputmatrix. The F2A and A2L decoupling filters would then be generated having a high frequency gain = 1.

Summary

Yesterday I resurrected the 40m's LSC simPlant model, c1lsp. It is running on c1sim, a virtual, self-contained cymac that Chris and I set up for developing sim models (see 15997). I think the next step towards an integrated IFO model is incorporating the suspension plants. I am going to hand development largely over to Ian at this point, with continued support from me and Chris.

LSC Plant

This model dates back to around 2012 and appears to have last been used in ~2015. According to the old CDS documentation:

Here XEP, YEP, and VSP are respectively the x-end, y-end, and vertex suspension plant models. I haven't found any evidence that these were ever fully implemented for the entire IFO. However, it looks like SUS plants were later implemented for a single arm cavity, at least, using two models named c1sup and c1spx (appear in more recent CDS documentation). These suspension plants could likely be updated and then copied for the other suspended optics.

To represent the optical transfer functions, the model loads a set of SOS filter coefficients generated by an Optickle model of the interferometer. The filter-generating code and instructions on how to use it are located here. In particular, it contains a Matlab script named opt40m.m which defines the interferferometer. It should be updated to match the parameters in the latest 40m Finesse model, C1_w_BHD.kat. The calibrations from Watts to sensor voltages will also need to be checked and likely updated.

Model-Porting Procedure

For future reference, below are the steps followed to port this model to the virtual cymac.

1. Copy over model files.
    
   • The c1lsp model, chiara:/opt/rtcds/userapps/release/isc/c1/models/c1lsp.mdl, was copied to the userapps directory on the virtual cymac, c1sim:/home/controls/docker-cymac/userapps/x1lsp.mdl. In the filename, note the change in IFO prefix "c1" --> "x1," since this cymac is not part of the C1 CDS network.
      
   • This model also depends on a custom library file, chiara:/opt/rtcds/userapps/release/isc/c1/models/SIMPLANT.mdl, which was copied to c1sim:/home/controls/docker-cymac/userapps/lib/SIMPLANT.mdl.
      
2. Update model parameters in Simulink. To edit models in Simulink, see the instructions here and also here.
    
   • The main changes are to the cdsParameters block, which was updated as shown below. Note the values of dcuid and specific_cpu are specifically assigned to x1lsp and will vary for other models. The other parameters will be the same.
      
   • 
      
   • I also had to change the name of one of the user-defined objects from "ADC0" --> "ADC" and then re-copy the cdsAdc object (shown above) from the CDS_PARTS.mdl library. At least in newer RCG code, the cdsAdc object must also be named "ADC0." This namespace collision was causing the compiler to fail.
      
   • Note: Since Matlab is not yet set up on c1sim, I actually made these edits on one of the 40m machines (chiara) prior to copying the model.
      
3. Compile and launch the models. Execute the following commands on c1sim:
   • $ cd ~/docker-cymac
$ ./kill_cymac
$ ./start_cymac debug

   • The optional debug flag will print the full set of compilation messages to the terminal. If compilation fails, search the traceback for lines containing "ERROR" to determine what is causing the failure.
      

4. Accessing MEDM screens. Once the model is running, a button should be added to the sitemap screen (located at c1sim:/home/controls/docker-cymac/userapps/medm/sitemap.adl) to access one or more screens specific to the newly added model.

   • Custom-made screens should be added to c1sim:/home/controls/docker-cymac/userapps/medm/x1lsp (where the final subdirectory is the name of the particular model).

   • The set of available auto-generated screens for the model can be viewed by entering the virtual environment:

   • $ cd ~/docker-cymac
$ ./login_cymac                    #drops into virtual shell
# cd /opt/rtcds/tst/x1/medm/x1lsp  #last subdirectory is model name
# ls -l *.adl
# exit                             #return to host shell

   • The sitemap screen and any subscreens can link to the auto-generated screens in the usual way (by pointing to their virtual /opt/rtcds path). Currently, for the virtual path resolution to work, an environment script has to be run prior to launching sitemap, which sets the location of a virtual MEDM server (this will be auto-scripted in the future):

   • $ cd ~/docker-cymac
$ eval $(./env_cymac)
$ sitemap

   • One important auto-generated screen that should be linked for every model is the CDS runtime diagnostics screen, which indicates the success/fail state of the model and all its dependencies. T1100625 details the meaning of all the various indicator lights.

   • 

I'm not sure I understand what F2A is? I couldn't find a description of this filter anywhere and don't remember if you have already explained it. Can you describe what is needed to be done again, please? We would keep SUS state space model and seismic transfer functions calculation ready meanwhile.

Today, I screwed the plungers on the sensor plates and installed them on the Towers. I also installed the wire clamps on the suspension blocks (attachment).

I ran into problems in 2 separate suspension blocks: one had a dowel pin that was slightly too fat for the wire clamp. In another, the tapped holes were too short so that the 4-40 screws couldn't be screwed all the way.

Force to Angle. It just means the filters that are in the POS OUTPUT matrix. I think in the past sometimes they are called F2P or F2A.

These filters account for the frequency dependent coupling of the DOFs around the suspension resonance. Take a look at what Bhavini is doing for the plots.

Added Matlab to the Docker machine. This should help immensely with workflow as well as keeping installed libraries consistent. Next step is outlining the project so coding is easier

Command to launch is:     $ matlab &

From Jon just for bookkeeping: 

Then in the Matlab command window, open the CDS parts library via:

addpath /home/controls/simLink/lib/

open /home/controls/simLink/CDS_PARTS.mdl

Then open an RTCDS model (for example, here the LSC plant) via:

open /home/controls/docker-cymac/userapps/x1lsp.mdl

I spent some time today setting up a workable user interface to control the waveplate.

1. Created some EPICS database records at /cvs/cds/caltech/target/ESP300.db. These are all soft channels. This required a couple of restarts of the modbus service on c1psl - as far as I can tell, everything has come back up without problems.
2. Hacked newportESP to make it work, mainly some string encoding BS in the python2-->python3 paradigm shift.
3. Made a python script at /cvs/cds/caltech/target/ESP300.py that is based on similar services I've set up for the CM servo and IMC servo boards. I have not yet set this up to run as a service on c1psl, but that is pretty trivial.
4. Made a minimal MEDM screen, see Attachment #1. It is saved at  /opt/rtcds/caltech/c1/medm/c1psl/C1PSL_POW_CTRL.adl and can be accessed from the "PSL" tab on sitemap. We can eventually "calibrate" the angular position to power units.
5. Confirmed that I can move the waveplate using this MEDM screen.

So this system is ready to be installed once Jordan and I find some time to lay out cabling + install the ESP300 controller in a rack.

At the moment, there is no high power and there is minimal risk of damaging anything, but someone should double check my logic to make sure that we aren't gonna burn the precious IFO optics. We should also probably hook up a hardware interlock to this controller.

I went through some aLIGO documentation and believe that they are using a custom made potentiometer based angle sensor rather than the integrated Newport (or similar) sensor+motor. My reading of the situation was that there were several problems to do with hysterisis, the "find home" routine etc. I guess for our purposes, none of these are real problems, as long as we are careful not to randomly rotate the waveplate through a full 180 degrees and go through the full fringe in the process. Need to think of a clever way to guard against careless / accidental MEDM button presses / slider drags.

Unrelated to this work: I haven't been in the lab for ~a week so I took the opportunity today to go through the various configs (POX/POY/PRMI resonant carrier etc). I didn't make a noise budget for each config but at least they can be locked 👍 . I also re-aligned the badly misaligned PMC and offloaded the somewhat large DC WFS offsets (~100 cts, which I estimate to be ~150 nNm of torque, corresponding to ~50 urad of misalignment) to the IMC suspensions' slow bias voltages. 

We (rana, yehonathan and i) briefly talked about having high power going into the IFO. I worked on some calcs a couple of years ago, that are summarized here. There is some discussion in the linked page about how much power we even need. In summary, if we can have

• T_PMC ~85% which is what I measured it to be back in 2019
• T_IMC * T_inputFaraday ~60% which is what I estimate it to be now
• 98% mode matching into the IMC
• power recycling gain of 40-45 once we improve the folding mirror situation in the recycling cavities
• and a gain of 270-280 in the arm cavities (20-30ppm round trip loss)

then we can have an overall gain of ~2400 from laser to each arm cavity (since the BS divides the power equally between the two arms). The easiest place to get some improvement is to improve T_IMC * T_inputFaraday. If we can get that up to ~90%, then we can have an overall gain of ~4000, which is I think the limit of what is possible with what we have.

We also talked about the EOM. At the same time, I had also looked into the damage threshold as well as clipping losses associated with the finite aperture of our EOM, which is a NewFocus 4064 (KTP is the Pockel medium). The results are summarized in Attachments #1 and #2 respectively. Rana thinks the EOM can handle factor of ~3 greater power than the rated damage threshold of 20W/mm^2.

{Yehonathan, Rana}

We unpacked the content of the amplifier crate in front of the water fountain (see attachments). Inside we found:

1. Amplifier head. (attachment 1)
2. Amplifier electronics and pump diodes (attachment 2).
3. Optical fiber (attachment 3).
4. 2 Long water hoses (~2m) and 2 short ones.
5. Network cable.
6. A wooden plate.
7. Cable sleeve (attachment 2)?
8. Some manuals will be uploaded to the wiki soon.

Please don't move/touch any of that stuff

Things that we need to consider/obtain:
1. A suitable power cable (attachment 4) with suitable power ratings (800W according to the amplifier specs). The connector head is C19 I believe.
2. A chiller. Rana says Aidan knows where to find one. Should we chill the amplifier head as well?
3. A mounting plate for the amplifier head with good thermal conductivity.
4. The pump wavelength is 808nm, we need to get suitable safety goggles.
5. Where to put the big electronics box. Preferably on 1X1 or 1X2.
6. How do we arrange the different components on the table? We also need to mode match the beam into the amplifier.

Once again, I found the door to the outside in the control room open when I came in ~1215pm. I closed it.

Sorry about that. It must be me. I'll make sure it doesn't happen again. I was careless to not check back, no further explanation.

The C1:IFO-STATE variable is actually a bunch (16 to be precise) of bits, and the byte they form (2 bytes) converted to decimal is what is written to the EPICS channel. It was reported on the call today that the nominal value of the variable when the IMC is locked was "8", while it has become "10" today. In fact, this has nothing to do with the IMC. You can see that the "PMC locked" bit is set in Attachment #1. This is done in the AutoLock.sh PMC autolocker script, which was run a few days ago. Nominally, I just lock the PMC by moving some sliders, and I neglect to set/unset this bit.

Basically, there is no anomalous behavior. This is not to say that the situation cannot be improved. Indeed, we should get rid of the obsolete states (e.g. FSS Locked, MZ locked), and add some other states like "PRMI locked". While there is nothing wrong with setting these bits at the end of execution of some script, a better way would be to configure the EPICS record to automatically set / unset itself based on some diagnostic channels. For example, the "PMC locked" bit should be set if (i) the PMC REFL is < 0.1 AND (ii) PMC TRANS is >0.65 (the exact thresholds are up for debate). Then we are truly recording the state of the IFO and not relying on some script to write to the bit (I haven't thoguht through if there are some edge cases where we need an unreasonable number of diagnostic channels to determine if we are in a certain state or not).

Maybe tighten the tensioner on the door closer so that it closes by itself even in the low velocity case. Or maybe just use the front door like everyone else?

That makes sense. I assumed that IFO-STATE is configured as you have proposed it to be configured. This could be implemented in later.

Plan of action

• Get the transfer functions of the suspension plant from actuated DOF to sensed DOF. We'll verify Bhavini's state-space model and get these transfer functions. Use the model TFs, not measured.
• For each of POS->POS, PIT->PIT, and YAW->YAW, we'll get the resonant frequency and Q of the resonance from these models. No, forget about the Q.
• We can correct the resonant frequencies from the measured ones in our free swinging data.
• Now, we'll repeat the following for each column of output matrix filters (inspired from scripts/SUS/F2Pcalc.py, but not fully understood how/why):
  • Select col (eg. POS)
  • Set f₀ to the resonant frequency.
  • Calculate where G_UL is the corrected DC gain we got after output matrix optimization earlier. (Not sure how, why?). No, use the SS model.
  • Calculate f_UR, f_LL, and f_LR like above.
  • Set   (This just seems like a way of keeping some approximately low Q, ideally we should keep this same to what we got above but that might cause saturation issues like Rana mentioned in the meeting)
  • Then, set the following filter in the output matrix element for UL:
                         
    which is in zpk form equivalent to:
                         
  • Repeat the above for UR, LL, LR.
  • Note that this filter function takes values G_UL at DC and at high frequencies while it would dip at the resonant frequency for POS with depth and narrowness directly proportional to Q_UL. No, the DC gain is different from the AC gain.
• However, the F2P filter plots we found in several places on elog look a bit different. Like here: 40m/4719. One important difference is that the filter magnitude always become 1 after the resonance at higher frequencies. Yes, this is  what we want, since you already did the balancing at high frequencies.
• A preliminary plot of the above calculation for the 1,1 output matrix filter bank (POS -> UL) is attached in Attachment 1.

Discussion:

• We can make 12 such filters for the 12 numbers we got for the optimized output matrix. Is that the aim or should we do it only for the POS column as has been done in past?
• We are not sure how the choice of Q is made in setting the above filter function. We'll think more about it to understand this.
• We are also not sure how the choice of f_UL is made above. It looks like depending on the correction gain, we want to slide the zero positions with respect to the pole positions which are fixed at the resonant frequency as expected. This seems to have some complex explanation.
• Please let us know if we are planning this right before we dive into these calculations/script writing. Thanks.

Edit Thu Apr 15 08:32:58 2021 :

Comments are from Rana.

Corrected the plot in the attachment. It shows the correct behavior at high frequencies now.

A couple of years ago, I got some info about the amplifier setup at the sites from Terra - sharing here in case there is some useful info in there (our setup will be rather different, but it looked to me like our Amp is a 2017 vintage and it may be that the performance is not the same as reported in the 2019 paper).

collection of docs (table layout in 'Proposed....setup') : https://dcc.ligo.org/LIGO-T1700046

LVC 70W presentation: https://dcc.ligo.org/LIGO-G1800538 

I guess we should double check that the beam size everywhere (in vacuum and on the PSL table) is such that we don't exceed any damage thresholds for the mirrors used. 

I've occcupied the southernmost electronics bench for assembling the 4 production version HV coil driver chassis. I estimate it will take me 3 days, and have left a sign indicating as much. Once the chassis assembly is done, I will need to occupy the northernmost bench where bench supplies are to run some functionality tests / noise measurements, and so unless there are objections, I will move the Acromag box which has been sitting there.

Some more relevant documents provided by Matt:

Phase III:70W amplifier integration at LIGO

70W amplifier External Shutter

aLIGO PSL high power attenuator

Here' s aquick update before we leave for lunch. We have managed to calculate some filter that would go on the POS column in MC2 output matrix filter banks aka F2A aka F2P filters. In the afternoon if we can come and work on the IMC, we'll try to load them on the output matrix. We have never done that so it might take some time for us to understand on how to do that. Attached is the bode plot for these proposed filters. Let us know if you have any comments.

[jordan, gautam]

We did the following this afternoon.

1. Disconnected the cable from the unused (and possibly not working) RefCav heater power supply, and removed said PS from 1X1. There was insufficient space to install the ESP300 controller elsewhere. I have stored the power supply along the east arm under the beamtube, approximately directly opposite the RFPD cabinet.
2. Installed the ESP 300 - conveniently, the HP DCPS was already sitting on some rails and so we didn't need to add any.
3. Ran a long D25-D25 cable from the ESP300 to the NE corner area of the PSL enclosure. The ends of the cable are labelled as "ESP end" and "Waveplate end". The HEPA was turned on for the duration we had the enclosure open, and I have now turned it off.
4. Connected the waveplate to this cable. Also re-connected the ESP300 to the c1psl supermicro host via the USB-RS232 adapter cable.

The IMC stayed locked throughout our work, and judging by the CDS overview screen, we don't seem to have done any lasting damage, but I will run more tests. Note that the waveplate isn't yet installed in the beam path - I may do this later today evening depending on lab activity, but for now, it is just sitting on the lower shelf inside the PSL enclosure. I will post some photos later.

Update: The waveplate was installed. I gave it a couple of rounds of cleaning by first contact, and visually, it looked good to me. More photos uploaded. I also made some minor improvements to the MEDM screen, and setup the communication script with the ESP300 to run as a systemd service on c1psl. Let's see how stable things are... I think the philosophy at the sites is to calibrate the waveplate rotation angle in terms of power units, but i'm not sure how the unit we have performs in terms of backlash error. We can do a trial by requesting ~100 "random" angles, monitoring the power in s- and p-polatizations, and then quanitfying the error between requested and realized angles, but I haven't done this yet. I also haven't added these channels to the set recorded to frames / to the burt snapshot - do we want to record these channels long term?

I've updated the c1auxey wiring plan for compatibility with the new suspension electronics. Specifically it is based on wiring schematics for the new HAM-A coil driver (D1100117), satellite amplifier (D1002818), and HV bias driver (D1900163).

Changes:

• The PDMon, VMon, CoilEnable, and BiasAdj channels all move from DB37 to various DB9 breakout boards.
• The DB9 cables (x2) connecting the CoilEnable channels to the coil drivers must be spliced with the dewhitening switching signals from the RTS.
• As suggested, I added five new BI channels to monitor the state of the CoilEnable switches. For lack of a better name, they follow the naming convention C1:SUS-ETMY_xx_ENABLEMon.

@Yehonathan can proceed with wiring the chassis.

We received 10x 16bit ADC adapter boards from Todd. S2100687~S2100696

The number of soldered resistors seems to be less than that on the schematics. They are related to duotone, so check if it's OK upon use.

I was looking at the laser head/amp and somehow decided to open the glue freezer. And it was stuck. I've managed to open it but the upper room was completely frozen.
Some of the batteries were embedded in a block of ice. I think we should throw them out.

Can the person who comes in the morning work on defrosting?

- Coordinate with Yehonathan and move the amps and the wooden crate so that you can move the freezer.

- Remove the contents to somewhere (it's OK to be room temp for a while)

- Unplug the freezer

- Leave the freezer outside with the door open. After a while, the ice will fall without care.

- At the end of the day, move it back to the lab. Continue defrosting the other day if the ice remains.

{Paco, Anchal, Yehonathan}

We emptied the fridge and moved the amplifier equipment on top of the amplifier crate. We unplugged the freezer and moved it out of the lab to defrost (attachment).

found it unresponsive. Restarted fine using procedure documented in wiki