AOtools / aotools

A useful set of tools for Adaptive Optics in Python
GNU Lesser General Public License v3.0
109 stars 42 forks source link

KL modes #91

Open AurelieMagniez opened 1 year ago

AurelieMagniez commented 1 year ago

There is a problem in the reconstruction using AOtools KL modes. I have generated 1000 atmospheric phase screens and reconstructed them using a 'perfect' wavefront sensor that just flattens the phase. I looked at the variances of the reconstruction modes and compared them with KL modes generated by the OOMAO simulation :

KLModes_issue

The variances should be both smooth. The peaks in the AOtools plot correspond to radial modes.

GillesOrban commented 1 year ago

Thanks for raising the issue. Just to be sure I get it correctly: the reconstruction is done with the same code and consist simply in projecting the 500 modes (KL from OOMAO or from Aotools) on the same phase screens ? And can you confirm that the K-L are generated on an annular aperture ?

I'll try to reproduce your result and better understand the issue.

ojdf commented 1 year ago

Hi @GillesOrban I can confirm that I can reproduce this, or at least something similar. These modes were generated for a VLT aperture (8m with 1.1m central obscuration). The peaks are radial modes, but the modes numbers are different between OOMAO and AOtools, I don't know if that is important or not

image
GillesOrban commented 1 year ago

Hi, I finally took a look at it. I can also reproduce it and indeed the peaks only appear on radial modes. I played with a couple of parameters and haven't found the culprit yet.

I noticed at least two things, however: 1/ if we do the same with Zernike modes (not orthogonalized on the annular aperture), we also see some peaks (again only on radial modes), 2/ if one increases the number of pixels of the grid, the peaks decrease. This is illustrated in the two figures below. So I am wondering if the problem concerns only the K-L modes. That being said, the K-L routine needs a detailed check (e.g. does not work correctly for purely circular aperture). I'll try to spend some time on it, but may take some time.

When comparing with oomao, do you use only the K-L basis from oomao and perform all the rest with aotools?

image image

matthewtownson commented 1 year ago

Just to add I have had similar issues with Zernike modes before, and Like @GillesOrban says the issues is resolved by using more pixels. This makes me think its to do with aliasing and the edge of the aperture. Anecdotally I know some people see this in "real" data as well if they don't consider aliasing properly. I don't know if there is some kind of normalisation we can do to remove this artefact, or if it is just something we need to make people aware of - potentially be including caveats in the docstrings of the functions?

GillesOrban commented 1 year ago

Thanks for your input. I just quickly tried to perform the projection (not the modal generation) using a grey scale aperture - in an attempt to reduce aliasing effect from the edges. I don't really see any difference. But maybe I didn't get correctly your comment. Otherwise, I am don't think we want to change the normalization of the modes. Currently the std is exactly 1, and I think we want to keep that.

matthewtownson commented 8 months ago

Sorry its been a while... That is exactly the kind of thing I meant, either use more pixels across the aperture to get a better circle, or use a "grey" aperture to get the same thing. Interesting that it didn't make a noticable difference.

Also, it has been a long time since any of us worked on this. Is this something we're going to be able to figure out and fix, or is it a "feature" of the KL modes?

GillesOrban commented 7 months ago

Short inputs: 1/ for the Zernike projection (see above), using a Tikhonov regularization to invert the Zernike matrices and then do the projection seems to resolve the issue. 2/ For the K-L, increasing the radial sampling definitively help. Below a short test, with a 64x64 pupil, 200 modes, and make_kl(..., nr=201). We could change the default radial sampling value nr=40 to this nr=201, the extra computation time is probably acceptable. I am not sure however that this is a real fix, and I think there is some numerical aspect to be checked (maybe comparing to the OOMAO code, e.g., would help), which requires some substantial time...

image