Iss32

[JaccovdS]

This implements the Fried geometry, returns the phi's and their corresponding physical locations. Resolves #55 And is a completely working WFR.

Not much need to look at the updated doc.

[faitdivers]

@JaccovdS and @ntielen please analyse the reconstructed results for a simple Zernike aberration (when running from main.py) and see if they make sense.

[ntielen]

@larsvl , it would be nice for us to see how our geometries cope with a waffle mode wavefront. (this is a wavefront shaped as a checkerboard). Do you now the Noll index/Zernike modes for this aberated wavefront? Or can you find a way to generate such a wavefront?

[larsvl]

@ntielen, for this specific shape, I will need to take a look into the theory. But I'm thinking about time domain square waves and a classical decomposition in sine and cosine (Fourier). Maybe this idea can be mirrored to the trigonometric functions in the zernike modes? I will take a look into that in the upcoming days.

----- Reply message ----- From: "ntielen" notifications@github.com To: "faitdivers/pyao" pyao@noreply.github.com Cc: "larsvl" larsvl@live.nl Subject: [pyao] Iss32 (#82) Date: Sat, Jun 21, 2014 01:01

@larsvl , it would be nice for us to see how our geometries cope with a waffle mode wavefront. (this is a wavefront shaped as a checkerboard). Do you now the Noll index/Zernike modes for this aberated wavefront? Or can you find a way to generate such a wavefront?

---

Reply to this email directly or view it on GitHub: https://github.com/faitdivers/pyao/pull/82#issuecomment-46735256

[forcaeluz]

@faitdivers, is the analysis from @JaccovdS and @ntielen necessary before the branch can be merged? From code point of view this is ok I think.

[faitdivers]

The analysis is needed. We can merge it and raise issues for the upcoming bugs.

[forcaeluz]

I would do that. By merging it now, we have all things working until the WFR.

[JaccovdS]

Has anyone got suggestions for creating the simple aberration because I can't find the documentation of WFG. And I don't know anything about the Zernike for creating wavefronts to be honest. It would be nice to make a comparison.

[forcaeluz]

You can create Zernike wave-fronts by choosing the modes and the weight of each mode. (Take a look into the paramsWavefront in the setup_params().) Or is this not your question?

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

Has anyone got suggestions for creating the simple aberration because I can't find the documentation of WFG. And I don't know anything about the Zernike for creating wavefronts to be honest. It would be nice to make a comparison.

— Reply to this email directly or view it on GitHub https://github.com/faitdivers/pyao/pull/82#issuecomment-46809613.

[JaccovdS]

@forcaeluz yes I understand that. But my question is more what would be useful values for that?

[ntielen]

If i understand the code correctly, the value for the mode is the Noll index, and you only have to add 1 of them each time. The weight of that mode will be 1. So for a tilt:

zernikeModes = [2] zernikeWeights = [1]

[larsvl]

Correct adding a mode is easy when you an instance of the ZernikeWave class.

So first, create an instance: zw = ZernikeWave() Then add the modes+weights: zw.addMode([2,4,21],[0.5,0.24,-0.6]) And create the wavefront, with the resolution: zw.createWavefront(50,50)

So here we've created a 50 by 50 wavefront consisting of the mode 2,4,21 and respective weights 0.5,0.24,-0.6.

Now the documentation should be in WFGdoc branch, also a example on how to implement kolmogorov and zernike is in the presentation on dropbox.

----- Reply message ----- From: "ntielen" notifications@github.com To: "faitdivers/pyao" pyao@noreply.github.com Cc: "larsvl" larsvl@live.nl Subject: [pyao] Iss32 (#82) Date: Mon, Jun 23, 2014 09:55

If i understand the code correctly, the value for the mode is the Noll index, and you only have to add 1 of them each time. The weight of that mode will be 1. So for a tilt:

zernikeModes = [2] zernikeWeights = [1]

---

Reply to this email directly or view it on GitHub: https://github.com/faitdivers/pyao/pull/82#issuecomment-46815325

[larsvl]

Is the waffle thing still an issue for you? I've looked around a bit and I haven't found a ready-to-use solution. Still, every article reminds zernike's 'completeness', so a solution should be there somewhere.

Currently, I don't have a clever idea on how to algebraicly decompose a checkerboard/waffle in zernike modes and weights.

The best solution now, if wish to go ahead is to create a wavefront grid manually, create a ZernikeWave class, add a large enough range of modes and hit decomposeWavefront(...) from the class instance. Then check the weights and hopefully they represent it well enough. To check that, create a new ZernikeWave with the weights and plot it, or check the variance of Wf{real}-Wf{reconstructed}.

----- Reply message ----- From: "ntielen" notifications@github.com To: "faitdivers/pyao" pyao@noreply.github.com Cc: "larsvl" larsvl@live.nl Subject: [pyao] Iss32 (#82) Date: Mon, Jun 23, 2014 09:55

If i understand the code correctly, the value for the mode is the Noll index, and you only have to add 1 of them each time. The weight of that mode will be 1. So for a tilt:

zernikeModes = [2] zernikeWeights = [1]

---

Reply to this email directly or view it on GitHub: https://github.com/faitdivers/pyao/pull/82#issuecomment-46815325

[ntielen]

It is not really an issue, as we don`t need the waffle pattern to verify the WFR.

It is quite interesting because the waffle should live in the nullspace of geometry matrix of Fried, but not for Southwell. I would be nice to see this and check how (modified) Hudgin deals with this.

[JaccovdS]

@larsvl which branch should I use for using WFG? Then I can merge that one with my code.

[faitdivers]

atm you can use the master.

On 23 June 2014 14:19, Jacco van der Spek notifications@github.com wrote:

@larsvl https://github.com/larsvl which branch should I use for using WFG? Then I can merge that one with my code.

— Reply to this email directly or view it on GitHub https://github.com/faitdivers/pyao/pull/82#issuecomment-46837052.

[larsvl]

You can use WFGbranch, should include the right files. Also consider pull request #77

----- Reply message ----- From: "João Lopes e Silva" notifications@github.com To: "faitdivers/pyao" pyao@noreply.github.com Cc: "larsvl" larsvl@live.nl Subject: [pyao] Iss32 (#82) Date: Mon, Jun 23, 2014 14:22

atm you can use the master.

On 23 June 2014 14:19, Jacco van der Spek notifications@github.com wrote:

@larsvl https://github.com/larsvl which branch should I use for using WFG? Then I can merge that one with my code.

— Reply to this email directly or view it on GitHub https://github.com/faitdivers/pyao/pull/82#issuecomment-46837052.

---

Reply to this email directly or view it on GitHub: https://github.com/faitdivers/pyao/pull/82#issuecomment-46837340

[forcaeluz]

@faitdivers and @JaccovdS : Can I merge this? It's missing the analysis, but I think that can be done in a separate issue. The more working things I have on the master the better.

[JaccovdS]

Here is the analysis. I don't know if it is right it doesn't seem very good to me: https://www.dropbox.com/sh/yrzvqy5xz1vlrvo/AAB20bfDd2-d3ypDuv6N8J3ba I didn't have time to figure out where it was going wrong.

@forcaeluz You can merge this I think.

[JaccovdS]

Maybe you should consider merging #86 instead.

[faitdivers]

@forcaeluz you can merge it at your own risk. If the results from the reconstruction aren't what they are supposed to be you won't be able to draw good conclusions.

On 23 June 2014 21:58, Jacco van der Spek notifications@github.com wrote:

Maybe you should consider merging #86 https://github.com/faitdivers/pyao/pull/86 instead.

— Reply to this email directly or view it on GitHub https://github.com/faitdivers/pyao/pull/82#issuecomment-46893615.

[forcaeluz]

@faitdivers: That's a no then?

[JaccovdS]

@ Everyone did you test your code and see if it gives the right results. Because everyone in the loop is depending on each other. Because I don't think I made an error in at least Fried. But there are at least 4 modules before me and if someone gives a wrong output this also affects my reconstruction.

[faitdivers]

Try with smaller aberrations. Like really small with an rms of the order of lambda.

Check the magnitude of the incoming wavefront and of the reconstruction.

Also just look at the centroids and see if their order of magnitude makes sense.

Did you end up using Svd to perform the pseudo inverse of G? did you check the singular values of GtG to see whether it is invertible? No dia 24 de Jun de 2014 07:49, "Jacco van der Spek" < notifications@github.com> escreveu:

@Everyone https://github.com/Everyone did you test your code and see if it gives the right results. Because everyone in the loop is depending on each other. Because I don't think I made an error in at least Fried. But there are at least 4 modules before me and if someone gives a wrong output this also affects my reconstruction.

— Reply to this email directly or view it on GitHub https://github.com/faitdivers/pyao/pull/82#issuecomment-46934425.

[forcaeluz]

From the plots I have the WFG and WFS seem to be working ok. The centroids I don't know. I cannot plot them directly, as the centroids function returns the slopes.

[JaccovdS]

@faitdivers I'm just using the pinv function as was discussed before in another issue. And no I don't check the singular values of GtG.

@forcaeluz Yes from my plots I can also confirm WFG is correct.

[larsvl]

To come back to the waffle wavefront pattern. I know it isn't all that interesting anymore, but I just wanted to try it.

So first I created a waffle grid:

Then constructed all the modes 1 up to 200 and did pseudo inverse A = (Z^T Z)Z W to get the weights. The decomposition gave the following weights, which larger then the preset tolerance 1e-10:

• 5 13 23 27 39 43 57 61 65 81 85 89 107 111 115 119 139 143 147 151 173 177 181 185 189

And the respective weights:

• -0.001227842091821 -0.011188311747858 -0.020748874111828 0.025427405466265 -0.002566825874007 0.009590905375538 0.036374862361545 -0.029745599589667 0.033398484786549 -0.024540493719920 0.025873735478329 -0.024151440222725 0.007631856157559 -0.014062146274776 0.012367826628250 -0.002973660043147 -0.004371752935085 -0.002869319622124 0.001040706176328 0.009174859475978 0.002710514779971 0.001714145678480 0.002374251183788 -0.002374716389112 -0.000032505098189

These weights resulted in the following reconstructed wavefront:

I suppose it is clear that you will need a large amount of modes if you wish to represent the original waffle wavefront (likely to be a infinite amount). Much like a Fourier decomposition of a square wave in sines and cosines.

[JaccovdS]

Very nice job! I don't know if we have time to use it. But at least we have it documented in this way on Github!

[faitdivers]

Thanks for the input Lars. It will certainly be useful.

I just fixed the problems in this branch, which were basically due to a faulty implementation of the G matrix and in solving the LS problem. There seem to be some problems in understanding what a pseudo-inverse actually is.

The test file was basically useless as the results did not make any sense. So I basically redid the testing procedures to reconstruct a simple tip/tilt and an astigmatism aberration.

In my computer both the main.py in CL and OL ran smoothly as well as the test file for the WFR.

Nothing was changed in the fundamental structure so I will just merge this and then if sth comes up I'll raise an issue.

[JaccovdS]

@faitdivers as mentioned in #86 that pull request outdated this one so that is why I only fixed the problem of pseudo inverse in #86. Sorry for the incovenience.

[faitdivers]

No problrm at all. No dia 30 de Jun de 2014 07:57, "Jacco van der Spek" < notifications@github.com> escreveu:

@faitdivers https://github.com/faitdivers as mentioned in #86 https://github.com/faitdivers/pyao/pull/86 that pull request outdated this one so that is why I only fixed the problem of pseudo inverse in #86 https://github.com/faitdivers/pyao/pull/86. Sorry for the incovenience.

— Reply to this email directly or view it on GitHub https://github.com/faitdivers/pyao/pull/82#issuecomment-47497081.