Running simulation - bad pictures

[forcaeluz]

The simulation should be running now inside the branch dm_controller, but I get strange figures when I try to update the data, and I was wondering if this is only happening here, or somewhere else too. @faitdivers: Can you run the main in that branch to check?

[amydeeb]

The images I get make it look like the wavefront is getting more deformed as we iterate. Is it possible the levels are normalized somewhere, so that although it looks like it is getting more extreme it is only going to the extremes of a smaller range?

[forcaeluz]

The range is fixed, but the problems I'm having with the images is that the look like:

But it should look like:

That the image is getting worse instead of improving are caused by bad controller parameters. (I still have to work on that)

[amydeeb]

Can you display the output of each section (WFS, the actuators etc)? To see if the diagonal split shows up along the way?

[forcaeluz]

It does only show up when I make the animation. I was only wondering if this was a local issue, or if you have it too. I will change the code do it without the animation, only storing the pictures in files.

[amydeeb]

Sorry for misunderstanding :). Yes, it happens for me as well.

In the pictures generated on my computer it almost looks like the left edge of the oval could match up with the right edge... I wonder if there's a mismatch between the x and y coordinates somehow...

[forcaeluz]

The split is gone (If you pull the newest version). It still animates, so this should be ok. The controller settings are bad, so that the picture actually changes at each iteration. The image does not get very better when using a good controller, or using no PID in the middle. This could be due to the fact we are not using dynamic wave-front aberration yet. So a bad PID controller causes the wave-front to be "dynamic"

[amydeeb]

Nice, what was the issue out of curiosity? :) Good luck with the tuning!

[forcaeluz]

They suggest that you should use set_array() if you want only to update the data inside a plot (it is faster than redrawing the whole thing). But If I redraw the whole thing it works. It's slower this way, but the results at least are correct. And thanks! I think I will continue tomorrow. I'm also not sure everything is correct, as I modified part of the DM to get things working.

[faitdivers]

(I guess you don't need my help anymore; the results are looking good!)

On 22 June 2014 22:22, forcaeluz notifications@github.com wrote:

They suggest that you should use set_array() if you want only to update the data inside a plot (it is faster than redrawing the whole thing). But If I redraw the whole thing it works. It's slower this way, but the results at least are correct.

— Reply to this email directly or view it on GitHub https://github.com/faitdivers/pyao/issues/89#issuecomment-46791701.

[amydeeb]

Could it be that it thought the array was one size, but it was actually one data point 'wider'? its almost like it plotted N-1 points on the line, then had to still plot one more point but put it at the start of the next line, continuing until the offset was the whole image width, making that diagonal divide... curious.... but there are more pressing things :) glad you found a work-around!

[forcaeluz]

@amydeeb: You have a good point. Will take a look tomorrow. @faitdivers: In the simulation I only see a step being made between the first and the second frame. After that it remains the same. (When the controller does not blow things up). Is this what you would expect from it?

[faitdivers]

With or without noise? With or without delay?

With noise you should see some oscillations in closed-loop, around the steady-state value. Without delay it should converge really fast and you may only need a P controller without the integral part. With delay I would say (purely from intuition) that it would take some samples to converge.

On 22 June 2014 22:48, forcaeluz notifications@github.com wrote:

@amydeeb https://github.com/amydeeb: You have a good point. Will take a look tomorrow. @faitdivers https://github.com/faitdivers: In the simulation I only see a step being made between the first and the second frame. After that it remains the same. (When the controller does not blow things up). Is this what you would expect from it?

— Reply to this email directly or view it on GitHub https://github.com/faitdivers/pyao/issues/89#issuecomment-46792472.

[JaccovdS]

The fact that @amydeeb is pointing out, is that maybe caused by the fact that Fried reconstructs (Nx+1)*(Ny+1)? Where Nx and Ny the number of lenslets in x and y direction. Or doesn't that have anything to do with this?

[forcaeluz]

I still have to investigate, but that shouldn't affect the results here, as I'm not plotting the reconstructed wave-front. I can look at it tonight again, and then tune the parameters.

On Mon, Jun 23, 2014 at 7:42 AM, Jacco van der Spek < notifications@github.com> wrote:

The fact that @amydeeb https://github.com/amydeeb is pointing out, is that maybe caused by the fact that Fried reconstructs (Nx+1)*(Ny+1)? Where Nx and Ny the number of lenslets in x and y direction. Or doesn't that have anything to do with this?

— Reply to this email directly or view it on GitHub https://github.com/faitdivers/pyao/issues/89#issuecomment-46807962.

[forcaeluz]

@amydeeb: Sizes are correct. (If I print the shapes of the matrix). For everyone interested: https://www.dropbox.com/s/4tx4k5oyueb5p90/out.mov I added measurement noise to the system. No delays yet, with a P controller (Kp = 1).

[forcaeluz]

I will consider this issue as closed, as a workaround has been found for the bad pictures.