Currently, setting numpy.random.seed(random_seed) in the infinite phase screens does not do anything. I have managed to get the initial screens to be deterministic by passing random_seed to ft_phase_screen when computing the initial screen. However, when rows are added to the screen these are not deterministic.

It seems like using numpy.random.seed is a bad way of trying to get deterministic behaviour from the infinite phase screens, since the fixed seed seems to only apply within the scope of the function in which numpy.random.seed is used?

I did a 'pip install aotools', but after testing with 'import aotools', I received the error shown below. The solution was to do a 'pip install numba'. However, shouldn't this dependency be corrected with the pip package?

Python 3.7.5 (default, Nov 7 2019, 10:50:52)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

import aotools
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python3.7/dist-packages/aotools/init.py", line 1, in
from . import astronomy, functions, image_processing, wfs, turbulence, opticalpropagation
File "/usr/local/lib/python3.7/dist-packages/aotools/turbulence/init.py", line 2, in
from .infinitephasescreen import *
File "/usr/local/lib/python3.7/dist-packages/aotools/turbulence/infinitephasescreen.py", line 418, in
@numba.jit(nopython=True, parallel=True)
AttributeError: 'NoneType' object has no attribute 'jit'

The functions: def cn2_to_r0 and r0_to_cn2 indicate in the documentation that the units of r0 are in cm. The equations implemented appear to return r0 in meters.

Equations are found in reference: Tyson, Robert K., and Benjamin West Frazier. “Field Guide to Adaptive Optics”, Second Edition, SPIE Press, 2012. and Fried, David L. "Anisoplanatism in adaptive optics." JOSA 72.1 (1982): 52-61.

Hello,
I wanted to test temporal_ps and I got the result that is attached here. I see that fit doesn't match with the noise psd. What might be reason for this discrepancy? Thanks very much!

The aotools.turbulence.infinitephasescreen module has the following to handle the case of missing numba:

try:
    import numba
except:
    numba = None  
[...]
        if numba:
            calc_seperations_fast(positions, self.seperations)
        else:
[...]

However, it later has:

@numba.jit(nopython=True, parallel=True)
def calc_seperations_fast(positions, seperations):

Which defeats the whole point of handling the missing numba in the first place.

Either the handling of missing numba could be removed and keep things cleaner, or the numba.jit decorator needs to be done in some other way. I can propose a fix, no problem, but I'm not sure which way you'd rather go (I would guess remove the handling of missing numba since numba is now a "hard" requirement of aotools).

Hi, I am Muzammil Ahmad, currently I am working on my thesis project, and looking forward to use the AOTOOLS to generate results. However, I was trying to learn about the packages and functions of AOTOOLS. I looked up into the atmos_conversions.cn2_to_r0, in which I fed the function value of cn2 and it gave me the value of r0 in meters. So far so good. I wanted to cross check the calculation so I calculated manually, by the formula I have of Fried Parameter which is r0 = 0.184*((lamda^2)/(Cn2*L))^(3/5). The value I calculated on paper approximately matched with one that I calculated with the function. I peeked into the documentation and author uses an alternate formula. But thing concerns me the most is that in both formulae there is an extra parameter we have to put which is range like L. The defined function doesn't ask for any value of L. I am wondering from where do it gets the value of L ? is it predefined? To make myself more clear shouldn't the function be like (when called)
r0 = aotools.turbulence.atmos_conversions(cn2 = 1, lamda = 1, L = 1)
The numbers are arbitrary and in meters. Shouldn't we feed the value of L (range) in meters too?
Looking forward to hear.

Nose has been unmaintained for a while. We should think about moving our tests to something else. Any suggestions? I have been looking at pytest as a potential replacement.

In photonsPerMag function docstring states wvlBand in nanometres but code uses Angstroms.

Read the docs is deprecating the .readthedocs.yaml so we need to change the way we build docs. Could be a good time to migrate to github actions and host on github.io?

I would like to simulate the effects of atmospheric turbulence on 2D images, like galaxies or planets, in the focal plane. Have you added support for applying PSF to 2D images? If not, do you have a timeframe for doing so?

Your paper states:

Building on this we will develop methods for applying a PSF to extended images, to allow for the degradation of wide-field images by the effects of atmospheric turbulence.

It would be nice to have the docs building and hosted on GitHub instead of an external site.

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 :

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

Greetings,

I'm poking around with aotools some and I am having a little trouble understanding what the units are on the phasescreens put out by the aotools.turbulence.phasescreen.ft_sh_phase_screen function. In some places in the documentation, it seems to refer to the units are radians but then in other places it seems to refer to the units as nanometers of wave front deviation per unit length. Can anyone clear this up?

I've just noticed the existance of the library numba-scipy, which adds more an API for numba to use scipy functions, such as "special" functions. This would be great to speed up some functions, such as "phase_covariance", which can then be much faster in making covariance matrices, etc...

We should rename the master branch to main inline with the new defaults in GitHub.

Hi all (@andrewpaulreeves @james-m-osborn @GillesOrban @ojdf),

I'm not sure I have up to date email addresses for everyone, so adding an issue to hopefully catch my out of date email addresses. Also let me know if I have forgotten someone I should have included.

I am hoping to submit the AOtools paper by the end of next week, if no-one has any major changes to make to the paper. If you don't have access then let me know an up to date email address so I can add you to edit the doc. AOtools_paper.pdf

Thanks,
Matt

I think there is a bug in the centre of gravity code. From a few trial runs, I think the centroids the functions outputs is off by 0.5 in both x and y. This is easily fixed by removing two lines of source code which add 0.5 to the x and y centroids in centroiders.py. Can this be confirmed before I go ahead and create a patch?

Hi, my name is Fernando and I am from the University of Porto. My goal is to simulate the propagation of a gaussian beam through turbulent atmosphere, and maybe aoTools can do this, right? From what I can see, I must propagate using Fresnel Integral, for example for 2500m, then multiply by e^(j*kolmogorov phase screen), and then propagate 2500m again to complete 5000km. To add more turbulence I will need to rise the number of phase screens right?

I am having some troubles, even propagating a beam 1m...

1. First I created my gaussian:
   "Create gaussian profile" dim=0.3 #m hdim=dim/2 step=0.0001 lmbda0=1.550e-6 #m x = numpy.arange(-hdim,hdim, step) y = numpy.arange(-hdim,hdim, step) xx, yy = numpy.meshgrid(x, y, sparse=True) sigma=0.05 z = 1/(2*numpy.pi) * numpy.exp(-(xx**2+yy**2)/(2*sigma*sigma))

2. Then propagated 1 meter:
   hlinha=opticalpropagation.oneStepFresnel(z,lmbda0, step, 1)

and if I plot this I get something crazy like this

I don't know what I missed... must d1 value d1 be the step?
Other thing, why there are no cross terms in the Huygens-Fresnel-Kirchoff integral inside the oneStepFresnel function?
Why shouldn't be C = ft2(Uin *numpy.exp(-1j * k/(2*z) * (x1**2 + y1**2 - 2*x1*x2 - 2*y1*y2)), d1) instead?

Formula from Svelto :
$u(x, y, z)=\frac{j}{\lambda L} \iint_{s} u\left(x_{1}, y_{1}, z_{1}\right) \exp -j k\left[\frac{\left(x-x_{1}\right)^{2}+\left(y-y_{1}\right)^{2}}{2 L}\right] d x_{1} d y_{1}$

Thank you a lot ^_^

This would be great to have as an affiliated package!

I've been using some functions from atmos_conversions for converting r0 -> cn2 and back. Sometimes r0 is listed in the docs as being is cm, sometimes in m. Is it really in cm sometimes? From a quick look at the equations I would guess its mostly in m.

Travis CI is no longer running tests, so they need to be done manually to check unit tests are all working. Think its time to bite the bullet and move to GitHub actions