We took the free-swinging spectra of the OpLev in the X and Y direction.
To make the motion of the optic quiet we turned off the airflow on the optical bench and moved the QPD close to the SOS so that the laser beam stays more or less within the QPD sensitive area.
In the process, we realized that the cleanroom HeNe went bad. It turned off after a few minutes after turning it on. The behavior repeated with another power supply. We replaced the HeNe and realigned it coarsely.
The data was taken using an oscilloscope while the optic was swinging freely. The PSD was calculated afterward (attachment 1).
Surprisingly, the pitch has a resonance frequency of ~ 2.5 Hz. And this is after we removed the back counterweight.
Additionally, we aligned the tilt of the optical table. Using a spirit bubble we adjusted the tilt by using a wrench on the table legs. As we suspected, the table was slightly tilted in the north-south direction.
After the new 1Y0 rack was placed near the 1Y1 rack by Chub and Anchal, today we worked on the 1Y1 rack. We removed some rails from spaces ~ 25 - 30. We then drilled a pair of ~ 10-32 thru-holes on some L-shaped bars to help support the c1sus2 machine weight. The hole spacing was set to 60 cm; this number is not a constant across all racks. Then, we mounted c1sus2. While doing this, Paco's knee clicked some of the video MUX box buttons (29 and 8 at least). We then opened the rack's side door to investigate the DC power strips on it before removing stuff. We did power off the DC33 supplies on there. No connections were made to allow us to keep building this rack.
When coming back to the control room, we noticed 3/4 video feed (analog) for the Test masses had gone down... why?
Update Tue Nov 2 18:52:39 2021
We successfully laid down all required optical fibre fiber cables from 1X4-1X7 region to 1Y1-1Y3 region today. This includes following cables:
2.5Hz is surprising. Can you move it down to sub 1Hz by adding a socket cap screw at the top instead of the set screw for the Teflon piece? How much mass do you need to add?
[Ian, Tega, Raj]
This is the rough plan for the testing of the new suspension models with the created plant model. We will test the suspensions on the plant model before we implement them into the full
MEDM file location
For ITMX display, use:
hsss_tega_gautam>medm -x -macro "site=caltech,ifo=c1,IFO=C1,OPTIC=ITMX,SUSTYPE=IM,DCU_ID=21,FEC=45" SUS_CUST_HSSS_OVERVIEW.adl
For ITMX display, use:
hsss_tega_gautam>medm -x -macro "site=caltech,ifo=c1,IFO=C1,OPTIC=ITMX,SUSTYPE=IM,DCU_ID=21,FEC=45" SUS_CUST_HSSS_OVERVIEW.adl
I have visited the binder file for the 40m wiring file in the control room.
The 12V power supply on 1Y1 is for the CCD cameras. So we still want to keep the 12V 0.8A power and the side connections for these. It is not necessary to be Sorensen. Can we replace it with an AC-DC adapter with +12V/1A for example? BTW, the video matrix and quads are AC-powered.
The mysterious thick cables and cross-connects (green wires) on the side panel (labeled AP1/AP2/SP/IMCREFL) are for "EO shutters". It was meant for the protection of the PDs from bright beams.
I don't think they have been used. And we don't need them.
Today we continued working on setting up the 6 degrees of freedom model for testing the suspension which we copied over from "/cvs/cds/rtcds/userapps/release/sus/c1/models/c1sup.mdl" to c1sp2.mdl in the same folder. We then changed the host from c1lsc to c1sus2, changed cpu # from 7 to 3 bcos c1sus2 has 6 cores. Then ran the following commands to build and install the model on c1sus2:
$ ssh c1sus2
$ rtcds make c1sp2
$ rtcds install c1sp2
where we encountered the following installation error:
ERROR: This node 62 is already installed as:
The new entry you are trying to write is as follows:
This script will not overwrite existing entries in testpoint.par
If this is an attempt to move an existing system from one host to another,
please remove conflicting entry from testpoint.par file
It seems that changing the model name and host did not change the node allocation, so will remove the previous entries in testpoint.par to see if that helps. After deleting the following lines
from the file "/opt/rtcds/caltech/c1/target/gds/param/testpoint.par", the installation went fine and the above entries were replaced by
BTW, I now believe the reason we had the node conflict earlier was bcos both models still had the same value of
Today I opened the ITMY chamber and removed the following optics and placed them in Xend flow bench (See attachment 1-3 for updated photograph):
I also unscrewed SRM and parked it near the Western end of the table where no optical paths would intersect it. Later we will move it in place once the alignment of the rest of the optics has been done.
While doing this work, I found two unnoted things on the table:
Please don't put it on c1sus2. Put it on the completely independent test stand as we discussed Wednesday. You must test the controller on the simplant and verify that they thing is stable and works, before putting it in the 40m network.
- New feedthrus [4xDB25 Qty 4 / 8xDB25 Qty 1] are placed on the wire shelf at the entrance -> Jordan, please clean them.
- There are plenty of 2" DLC mounts. There are also many 1.5" mounts but they are less useful.
We need at least 3 1" moounts and 1 1" or 2" lens mount (and the lens). Let's purchase them on Thorlabs. I'll work on the order.
Removed all sorensen power supplies from this rack except for 12 VDC one; that one got pushed to the top of the rack and is still powering the cameras.
Updated the rack layout. Now there is an issue.
We were supposed to have 1U space at the top, but it was occupied by the 12V.
We need to either lower the c1sus2 and IO chassis 1U or move the Sorensen at the bottom.
In reference to Koji's concern (see previous elog), we have completely removed sorensen power supplies from 1Y1. We added a 12 Volts / 2 Amps AC-to-DC power supply for the cameras and verified it works. We stripped off all unused hardware from shutters and other power lines in the strips, and saved the relays and fuses.
We then mounted SR2, PR3, PR2 Sat Amps, 1Y1 Sat amp adapter, and C1SUS2 AA (2) and AI (3) boards. We made all connections we could make with the cables from the test stand, as well as power connections to an 18 VDC power strip.
Big Gluing Day
Today I glued the magnet+dumbell assemblies on the optics adapters.
Unlike magnet gluing on a 3" optic where one can use a magnet gluing fixture, here I had to position the magnets manually. There is a complication though: the magnet is much heavier than the dumbell making it almost impossible gluing the dumbell side down onto the adapter since it is very unstable in this position. A workaround is to put the magnets on some paramagnetic sheet so that the magnets stick to it and then flip it over and glue it on the adapter dumbell sides down.
The problem here is that I need to position the magnets relatively accurately on the metal sheet. To make things slightly easier I printed some drawings of the positions of the magnet, laminated them, and cleaned them to have a decent starting point (attachment 1).
For each adapter:
1. I applied glue to the 4 circular grooves at the back of the adapter.
2. I picked 4 magnets (2 north, 2 south). Trying to match their strength.
3. Made a note of which magnets I picked for which adapter in the magnet+dumbell spreadsheet.
4. Clean the dumbells' surfaces when necessary.
5. Put the magnets on a laminated magnet-positions-drawing on a metal sheet that was precleaned in the right order.
6. Flip the metal sheet and position it on the adapter such that the dumbells go as precisely as possible into the circular grooves on the adapater.
7. Adjust the magnets' positions by pushing them slightly with a non-magnetic tip.
Attachment 2 shows the numbering on the adapters for future tracking.
I also glued some magnets and aluminum rods to side blocks. Next gluing session I will glue magnets to the aluminum rods. Probably some dumbells will not stick well to the adapters. These will have to be cleaned and reglued as well.
We combined a controler and a plant model into a single modle (See first attachment) called x1sus_cp.mdl in the userapps folder of the cymac in c1sim. This model combines 2 blocks: the controler block which is used to control the current optics and is found in cvs/cds/rtcds/userapps/release/sus/c1/models/c1sus.mdl further the control block we are using comes from the same path but from the c1sup.mdl model. This plant model is the bases for all of my custom plant models and thus is a good starting point for the testing. It is also ideal because I know it can beeasily altered into a my state-space plant model. However, we had to make a few adjustments to get the model up to date for the cds system. So it is now a unique block.
These two library blocks are set in the userapps/lib folder on the cymac. This is the lib file that the docker system looks to when it is compiling models. For a quick overview see this. All other models have been removed from the MatLab path so that when we open x1sus_cp.mdl in MatLab it is using the same models it will compile with.
We could not find the rtbitget library part, but chris pointed us to userapps, and we copied it over using: scp /opt/rtcds/userapps/trunk/cds/common/models/rtbitget.mdl controls@c1sim:/home/controls/simLink/lib.
scp /opt/rtcds/userapps/trunk/cds/common/models/rtbitget.mdl controls@c1sim:/home/controls/simLink/lib
NOTE TO FUTURE IAN: don't forget that unit delays exist.
Next step: now that we have a model that is compiling and familiar we need to make medm screens. We will use the auto mdl2adl for this so that it is quick. Then we can start adding our custom pieces one by one so that we know that they are working. We will also work with Raj to get an independent python model working. Which will allow us to compare the cds and python models.
The gluing was mostly successful. Only two magnets didn't stick (see attachment).
After talking with Rana we have an updated plan. We will be working on this plan step by step in this order.
We have moved c1sim computer from the test stand to the server rack in the office area. (see picture)
It is connected to the general campus network. Through the network switch at the top of the rack. This switch seeds the entire Martian network.
Test to show that I am not lying:
c1sim is now as connected to the 40m network as my mom's 10-year-old laptop.
unfortunately, I have not been able to get the x2go client to connect to it. I will have to investigate further. It is nice to have access to the GUI of c1sim occasionally.
Now that the computer is in its new rack I have copied over the filter two files that I will use in the plant and the controller from pianosa:/opt/rtcds/caltech/c1/chans to the docker system in c1sim:/home/controls/docker-cymac/chans. That is to say, C1SUP.txt -> X1SUP.txt and C1SUS.txt -> X1SUS_CP.txt, where we have updated the names of the plant and controller inside the txt files to match our testing system, e.g. ITMX -> OPT_PLANT in plant model and ITMX -> OPT_CTRL in the controller and the remaining optics (BS, ITMY, PRM, SRM) are stripped out of C1SUS.txt in order to make X1SUS_CP.txt.
Once the filter files were copied over need to add them to the filters that are in my models to do this I run the commands:
$ cd docker-cymac
$ eval $(./env_cymac)
# cd /opt/rtcds/tst/x1/medm/x1sus_cp
# medm -x X1SUS_OPT_PLANT_TM_RESP.adl
see this post for more detail
Unfortunately, the graphics forwarding from the docker is not working and is giving the errors:
canAccess('X1SUS_OPT_PLANT_TM_RESP.adl', 4) = 0
can directly access 'X1SUS_OPT_PLANT_TM_RESP.adl'
locateResource(X1SUS_OPT_PLANT_TM_RESP.adl...) returning 1
Error: Can't open display:
This means that the easiest way to add the filters to the model is through the GUI that can be opened through X2go client. It is probably easiest to get that working. graphics forwarding from inside the docker is most likely very hard.
unfortunately again x2go client won't connect even with updated IP and routing. It gives me the error: unable to execute: startkde. Going into the files on c1sim:/usr/bin and trying to start startkde by myself also did not work, telling me that there was no such thing even though it was right in front of me.
unable to execute: startkde.
Today we populated 4 Sat Amp boxes for LO1, Lo2, AS1, and AS4, 2 BO boxes for C1SU2, and 1 Sat Amp Adaptor box, at 1Y0 according the latest rack plan. We also added 2 Sorenson power supplies in 1Y0 at the top slots to power +/- 18V DC strips on both 1Y1 and 1Y0. All wiring has been done for these power connections.
Yehonathan and Tega found that the new PR3 and SR3 delivered in 2020 is in fact 3/4" in thickness (!). Digging the past email threads, it seems that the spec was 10mm but the thickness was increased for better relieving the residual stress by the coatings.
There are a few issues.
1. Simply the mirror is too thick for the ring. It sticks out from the hole. And the mirror retainers (four plastic plates) are too far from the designed surface, which will make the plates tilted.
2. The front side of the mirror assembly is too heavy and the pitch adjustment is not possible with the balance mass.
Some possible solutions:
- How about making the recess deeper?
In principle this is possible, but the machining is tricky because the recess is not a simple round hole but has "pads" where the mirror sits. And the distance of the retainer to the thread is still far.
And the lead time might become long.
- How about making new holes on the ring to shift the clamp?
Yes it is possible. This will shift the mirror assembly by a few mm. Let's consider this.
- How about modifying the wire blocks?
Yes it is equivalent to shift the holes on the ring. Let's consider this too.
1. How to hold the mirror with the retainer plates
[Attachment 1] The expected distance between the retainer plate and the threaded hole is 13.4mm. We can insert a #4-40 x L0.5" stand off (McMaster-Carr 91197A150, SUS316) there. This will make the gap down to 0.7mm. With a washer, we can handle this gap with the plate. Note that we need to use vented & silver plated #4-40 screws to hold the plates.
[Attachment 2] How does this look like when the CoM is aligned with the wire plane? Oh, no... the lower two plates will interfere with the EQ stops and the EQ stop holders. We have to remove them. [Attachment 3]
We need to check with the suspension if the EQ stop screws may hit the protruded optics and can cause chipping/cracking.
2. Modifying the wire block
[Attachment 4] The 4x thru holes of the wire block were extended to be +/-0.1" slots. The slots are too long to form ovals and produce thin areas. With the nominal position of the balance mass, the clamp coordinates are y=1.016 (vertical) and z=-2.54mm (longitudinal).
==> The CoM is 0.19mm backside (magnet side) and 0.9134 mm lower from the wire clamping points. This looks mathematically doable, but the feasibility of the manufacturing is questionable.
[Attachment 5] Because the 0.1" shift of the CoM is large, we are able to make new #2-56 thread holes right next to the original ones. The clamp coordinates are y=1.016 (vertical) and z=-2.54mm (longitudinal).
==> The CoM is 0.188mm backside (magnet side) and 0.9136 mm lower from the wire clamping points. With the given parameters, the expected pitch resonant frequency is 0.756Hz
- Modify the metal ring to shift the #2-56 threads by 0.1"
- The upper two retainer plates will have #4-40 x 0.5" stand off. Use vented Ag-coated #4-40 screws.
- The lower two are to be removed.
- Take care of the EQ stops.
- Of course, the best solution is to redesign the holder for 3/4" optics. Can we ask Protolab for rapid manufacturing???
Why did we need to place the mass forward to align the 1/4" thick optic?
We were supposed to adjust the CoM not to have too much adjustment. But we had to move the balance mass way too front for the proper alignment with a 1/4" thick optic. Why...?
This is because the ring was designed for a 3/8" thick optic... It does not make sense because the depth of the thread holes for the retainer plate was designed for 1/4" optics...
When the balance mass is located at the neutral position, the CoM coordinate is
x 0.0351mm (x+: left side at the front view)
y 0.0254mm (y+: vertical up)
z 0.4493mm (z+: towards back)
So, the CoM is way too behind. When the balance mass was stacked and the moved forward (center of the axis was moved forward by 0.27"), the CoM coordinate is (Attachment 6)
This makes sens why we had to move the balance mass a lot for the adjustment.
First attempt at the suspension of a Lambda Optic mirror
We found the box with the 2" Lambda Optic mirrors in the cleanroom. We choose to suspend a mirror with a ROC = 5m, probably LO1.
The mirror was put inside an adapter that was prepared beforehand, put the mirror in place by tightening the Teflon rod, and then clamp it using the clamping pads.
We decided to cut two wires and clamp them to the side blocks of the adapter, while it sits on the EQ stops. The wires were threaded through the winches' clamps, through the wire clamp on the suspension block, and through the side blocks' wire clamps. We adjusted the wire position while pulling on it. The wire was made to sit inside the wire grooves on the side blocks. While tightening the clamp on the side block with the magnet, the LN key fell knocking off two magnets from the back of the adapter.
Next time we think it might be a better idea to do all the adapter wire clamping on the table instead of on the SOS tower.
In the meanwhile, here are some pictures from today.
We are working on three fronts for the suspension plant model:
Here are the State-space matrices:
A few notes: If you want the values for these parameters see the .yml file or the State-space model file. I also haven't been able to find what exactly this s is in the matrices.
UPDATE [11/16/21 4:26pm]: I updated the matrices to make them more general and eliminate the "s" that I couldn't identify.
The input vector will take the form:
where x is the position, theta is the pitch, phi is the yaw, and y is the y-direction displacement
One goal of our sysID study is to improve the aLIGO L2A feedforward. Our algorithm currently improves only the statistical uncertainty and assumes the systematic errors are negligible. However, I am currently baffled by how to fit a (nearly) realistic suspension model...
My test study uses the damped aLIGO QUAD suspension model. From the Matlab model I extract the L2 drive in [N] to L3 pitch in [rad] transfer function (given by a SS model with the A matrix having a shape of 103x103). I then tried to use VectFIT to fit the noiseless TF. After removing nearby z-p pairs (defined by less than 0.2 times the lowest pole frequency) and high-frequency zeros, I got a model with 6 complex pole pairs and 4 complex zero pairs (21 free parameters in total). I also tried to fit the TF (again, noiseless) with an MCMC algorithm assuming the underlying model has the same number of parameters as the VectFIT results.
Please see the first attached plots for a comparison between the fitted models and the true one. In the second plot, we show the fractional residual
| TF_true - TF_fit | / | TF_true |,
and the inverse of this number gives the saturating SNR at each frequency. I.e., when the statistical SNR is more than the saturating value, we are then limited by systematic errors in the fitting. And so far, disappointingly I can only get an SNR of 10ish for the main resonances...
I wonder if people know better ways to reduce this fitting systematic... Help is greatly appreciated!
Updated A, B, C, D matrices for the state-space model to remove bugs in the previous estimate of the system dynamics. Updated the last post to represent the current matrixes.
We used MatLab to get the correct time-series filter coefficients in ZPK format and added them to the filters running in the TM_RESP filter matrix.
Get the pos-pos transfer function from the CDS model. Strangely, this seems to take a lot longer than anticipated to generate the transfer function, even though we are mainly probing the low-frequency behavior of the system.
For example, a test that should be taking approximately 6 minutes is taking well over an hour to complete. This swept sine (results below) was on the low settings to get a fast answer and it looks bad. This is a VERY basic system it shouldn't be taking this long to complete a Swept sine TF.
Noticed that we need to run eval $(./env_cymac) every time we open a new terminal otherwise CDS doesn't work as expected. Since this has been the source of quite a few errors already, we have decided to put it in the startup .bashrc script.
Another attempt at the suspension of a Lambda Optic mirror
The lambda mirror was removed from the adapter whose magnets were knocked off. We tried to mount the mirror on a different adapter but we knocked off magnets from two adapters . We succeeded in mounting the mirror at the third attempt (Adapter number 6). In the meanwhile, Tega threaded wires through side blocks separated from the adapter. He positioned the wires inside the grooves of the side block under a microscope (attachment 1). This procedure is much more accurate and pain-free than doing it on the suspended mirror.
We took the adapter and put it on the EQ stops. The wires were threaded through the wire clamp on the suspension block and clamped at the winches.
The adapter was rotated until the side magnet was roughly at the center of the side OSEM port. We then, as before, put coils in OSEM ports and try to adjust the height of the side magnet and the magnet groove on the other side block such that they are roughly at the center of the coil. We used the winches for fine adjustment.
I used the Canon camera to make sure the side blocks are leveled (attachment 2). I used the macro lens for that purpose. I set up a live stream from the Canon camera using these instructions only that I use OBS instead of CamTwist. I painted a semi-transparent green rectangle to annotate the position of the side magnet socket (attachment 3). I did this several times to confirm the repeatability of the results. Again using the winches for fine adjustments.
Once the height of the side magnets was confirmed to be leveled. I clamped the wires to the suspension block and cut them above it.
I tried to balance the optic but again I see that the suspensions are hysteretic. I check to see whether the wire is touching anything and indeed it touches the corner of the side block (attachments 4, 5).
Yehonathan told me that the wires are touching between the clamps! I went back to the CAD and confirmed it is really happening. Sad.
The distance of the wires at the upper clamp is 17.018mm.
The distance of the lower clamps is 74.168mm
The vertical drop of the wire is 251mm
--> The wire angle from the vertical line is 0.114 rad
The lower wire block has a step of 1.016mm with the vertical extension of the piece by 11.684mm
--> The angle clearance of the lower clamp is 0.087 rad
So the clearance was not enough.
If we cut the top center of the wire block more than 2.77mm, we can make the wires free.
For safety, we can cut 0.25" = 6.35mm. This will give 0.4mm clearance between the block and the wire at the closest point.
I did this modification on the 3D model and modified the 2D drawing too, so that we can find the machine shop to do it quickly.
This will be difficult to modify with the magnets and dumbells in place. Even if someone CAN clamp this piece into an endmill machine with the magnets/dumbells in place, the vibration of the cutting operation may be enough to break them off.
Of course, we remove the magnet-dumbbell for machining. After that the part will be cleaned/baked again. And Yehonathan is going to glue the magnet-dumbbell again.
Today I placed nodus and fb1 on UPS battery backed supply. Now power glitches should not hurt our cds system.
I went through the optics list (in the BHD procurement google spreadsheet) and summarized how to build them.
The red ones are what we need to purchase. Because of the strange height of the LMR mounts, the post needs to have none half-integer inch heights.
They need to be designed as the usual SS posts are not designed to be vac compatible (not because of the material but the design like screw hole venting).
We also need to check how many clean forks we have.
-> The components were ordered except for the custom posts.
We moved chiara to 1X7 above nodus and powered with same UPS from a battery backed port. The UPS is at 40% load capacity. The nameserver and nfs came back online automatically on boot up.
[Ian, Raj, Tega]
Here is the comparison between the results of Raj's python model and the transfer function measurement done on the plant model by Tega and me.
As You can see in the graphs there are a few small spots of disagreement but it doesn't look too serious. Next we will measure the signals flowing through the entire plant and controller.
For a nicer (and printable) version of these plots look in the zipped folder under Plots/Plant_TF_Individuals.pdf
1. Investigate cross-coupling btw the various degrees of freedom (dof) - turn on noise for each dof in the plant model and measure the transfer function of the other dofs.
2. Get a closed-loop transfer function using noise injection and give a detailed outline of the procedure in elog - IN1/IN2 for each TM_RESP filter while the others are turned off.
3. Derive analytic model of the closed-loop transfer functions for comparison.
4. Adapt control filters to fit optimized analytical solutions.
I used the UPS that was providing battery backup for chiara earlier (a APS Back-UPS Pro 1000), to provide battery backup to Megatron. This completes UPS backup to all important computers in the lab. Note that this UPS nominally consumes 36% of UPS capacity in power delivery but at start-up, Megatron was many fans that use up to 90% of the capacity. So we should not use this UPS for any other computer or equipment.
While doing so, we found that PS3 on Megatron was malfunctioning. It's green LED was not lighting up on connecting to power, so we replaced it from the PS3 of old FB computer from the same rack. This solved this issue.
Another thing we found was that Megatron on restart does not get configured to correct nameserver resolution settings and loses the ability to resolve names chiara and fb1. This results in the nfs mounts to fail which in turn results in the script services to fail. We fixed this by identifying that the NetworkManager of ubuntu was not disabled and would mess up the nameserver settings which we want to be run by systemd-resolved instead. We corrected the symbolic link: /etc/resolv.conf -> /run/systemd/resolve/resolv.conf. the we stopped and diabled the NetworkManager service to keep this persistent on reboot. Following are the steps that did this:
I finished copying over the current autolocker bash script functionality into a python script which runs using a simple configuration yaml file. To run this script, one needs to ssh into optimus and :
That's it. To check out running docker processes, one can:
And to shut down this particular script, in the same directory, one can
If the docker image requires to be rebuild in future, go to the directory where Dockerfile is present and run:
I had to add PyYAML package in the pyepics docker image already present on docker hub, thanks to Andrew.
For now, I have disabled the MCautolocker service on Megatron. To start it back again, one would need to ssh into megatron and do following:
Let's see for a day how this new script does. I've left PSL shutter open and autolocker engaged.
To do: Fix the C1:IFO-STATE epics channel definition so that it takes its bits from separate lock status channels instead of scripts writign the whole word arbitrarily.
I added mpmath to the quantization noise code. mpmath allows me to specify the precision that I am using in calculations. I added this to both the IIR filters and the State-space models although I am only looking at the IIR filters here. I hope to look at the state-space model soon.
I also added a new notebook which you can find HERE. This notebook creates a signal by summing two sine waves and windowing them.
Then that signal is passed through our filter that has been limited to a specific precision. In our case, we pass the same signal through a number of filters at different precisions.
Next, we take the output from the filter with the highest precision, because this one should have the lowest quantization noise by a significant margin, and we subtract the outputs of the lower precision filters from it. In summary, we are subtracting a clean signal from a noisy signal; because the underlying signal is the same, when we subtract them the only thing that should be left is noise. and since this system is purely digital and theoretical the limiting noise should be quantization noise.
Now we have a time series of the noise for each precision level (except for our highest precision level but that is because we are defining it as noiseless). From here we take a power spectrum of the result and plot it.
After this, we can calculate a frequency-dependent SNR and plot it. I also calculated values for the SNR at the frequencies of our two inputs.
This is the procedure taken in the notebook and the results are shown below.
Analysis of Results:
The first thing we can see is that the precision levels 256 and 128 bits are not shown on our graph. the 256-bit signal was our clean signal so it was defined to have no noise so it cant be plotted. The 128-bit signal should have some quantization noise but I checked the output array and it contained all zeros. after further investigation, I found that the quantization noise was so small that when the result was being handed over from mpmath to the general python code it was rounding those numbers to zero. To overcome this issue I would have to keep the array as a mpmath object the entire time. I don't think this is useful because matplotlib probably couldn't handle it and it would be easier to just rewrite the code in C.
The next thing to notice is sort of a sanity check thing. In general, low precision filters yield higher noise than high precision. This is a good quick sanity check. However, this does not hold true at the low end. we can see that 16-bit actually has the highest noise for most of the range. Chris pointed out that at low precisions that quantization noise can become so large that it is no longer a linearly coupled noise source. He also noted that this is prone to happen for low precision coefficients with features far below the Nyquist frequency like I have here. This is one explanation that seems to explain the data especially because this ambiguity is happening at 16-bit and lower as he points out.
Another thing that I must mention, even if it is just a note to future readers, is that quantization noise is input dependent. by changing the input signal I see different degrees of quantization noise.
Analysis of SNR:
One of the things we hoped to accomplish in the original plan was to play around with the input and see how the results changed. I mainly looked at how the amplitude of the input signal scaled the SNR of the output. Below I include a table of the results. These results were taken from the SNR calculated at the first peak (see the last code block in the notebook) with the amplitude of the given sine wave given at the top of each column. this amplitude was given to both of the two sine waves even though only the first one was reported. To see an example, currently, the notebook is set up for measurement of input amplitude 10.
As we can see from the table above the SNR does not seem to relate to the amplitude of the input. in multiple instances, the SNR dips or peaks in the middle of our amplitude range.
This looks great. I think what we want to see mainly is just the noise in the 32 bit IIR filtering subtracted from the 64 bit one.
It would be good if Tega can look through your code to make sure there's NO sneaky places where python is doing some funny casting of the numbers. I didn't see anything obvious, but as Chris points out, these things can be really sneaky so you have to be next level paranoid to really be sure. Fox Mulder level paranoia.
And, we want to see a comparison between what you get and what Denis Martynov put in an appendix of his thesis when comparing the Direct Form II, with the low-noise form (also some slides from Matt Evans on thsi from a ~decade agoo). You should be able to reproduce his results. He used matlab + C, so I am curious to see if it can be done all in python, or if we really need to do it in C.
And then...we can make this a part of the IFOtest suite, so that we point it at any filter module anywhere in LIGO, and it downloads the data and gives us an estimate of the digital noise being generated.
Late update. We got 2 modified side blocks from Jordan a few days ago. Yesterday, I glued a side magnet to one of the modified side blocks.
I took the opportunity to reglue some magnets that were knocked off from the adapters. I did this for 2 adapters only since w need 4 shallow adapters and we already had 2 complete ones.
Today, Jordan gave us the rest of the modified side blocks clean and baked. We are ready to suspend a mirror today.
Koji found out that the stock for BIO Acromag modules is very low and that the lead time for ordering new ones is ~ 1-year X-o.
We figure we might need to minimize the number of modules but still keep the Acromag chassis functional.
Looking at the new C1AUXEY feed-throughs spreadsheet one can see that we actually normally need only 1 BIO (not 2) module since there are 16 suspensions related bios + 1 green shutter which is unrelated to SUSAUX so there is no room to cut back here.
There are 16 analog input channels, 5 for PDMONs and 5 VMONs, and 6 spares which require 2 ADCs. Removing the spares and 2 monitoring channels will be enough to get us to 1 ADC.
The toilet tank in the big bathroom stopped refilling. I contacted PPService@caltech.edu and put up an "Out of Order sign".
We have been discussing how does the parameter estimation depends on the length per FFT segment. In other words, after we collected a series of data, would it be better for us to divide it into many segments so that we have many averages, or should we use long FFT segments so that we have more frequency bins?
My conclusions are that:
1). We need to make sure that the segment length is long enough with T_seg > min[ Q_i / f_i ], where f_i is the resonant frequency of the i'th resonant peak and the Q_i its quality factor.
2). Once 1) is satisfied, the result depends weakly on the FFT length. There might be a weak hint preferring a longer segment length (i.e., want more freq bins than more averages) though.
To reach the conclusion, I performed the following numerical experiment.
I considered a simple pendulum with resonant frequency f_1 = 0.993 Hz and Q_1 = 6.23. The value of f_1 is chosen such that it is not too special to fall into a single freq bin. Additionally, I set an overall gain of k=20. I generated T_tot = 512 s of data in the time domain and then did the standard frequency domain TF estimation. I.e., I computed the CSD between excitation and response (with noise) over the PSD of the excitation. The spectra of excitation and noise in the readout channel are shown in the first plot.
In the second plot, I showed the 1-sigma errors from the Fisher matrix calculation of the three parameters in this problem, as well as the determinant of the error matrix \Sigma = inv(Fisher matrix). All quantities are plotted as functions of the duration per FFT segment T_seg. The red dotted line is [Q_1/f_1], i.e., the time required to resolve the resonant peak. As one would expect, if T_seg <~ (Q_1/f_1), we cannot resolve the dynamics of the system and therefore we get nonsense PE results. However, once T_seg > (Q_1/f_1), the PE results seem to be just fluctuating (as f_1 does not fall exactly into a single bin). Maybe there is a small hint that longer T_seg is better. Potentially, this might be due to that we lose less information due to windowing? To be investigated further...
I also showed the Fisher estimation vs. MCMC results in the last two plots. Here each dot is an MCMC posterior. The red crosses are the true values, and the purple contours are the results of the Fisher calculations (3-sigma contours). The MCMC results showed similar trends as the Fisher predictions and the results for T_seg = (32, 64, 128) s all have similar amounts of scattering << the scattering of the T_seg=8 s results. Though somehow it showed a biased result. In the third plot, I manually corrected the mean so that we could just compare the scattering. The fourth plot showed the original posterior distribution.
a plumber came in yesterday and fixed the issue.