Issue by josePhoenix Tuesday Oct 04, 2016 at 20:55 GMT Originally opened as https://github.com/mperrin/poppy/issues/194

User @maciekgroch reports unusual behavior when propagating a 10nm wave a short distance past a circular aperture using the following code:

import poppy
import astropy.units as u

npix = 1024
wf = poppy.FresnelWavefront(
    5 * u.um,
    wavelength=10 * u.nm,
    npix=npix,
    oversample=4
)
wf *= poppy.CircularAperture(radius=800 * u.nm)
plt.figure()
wf.display()

z = 12. * u.um
plt.figure()
wf.propagate_fresnel(z, display_intermed=True)

POPPY produces this intensity pattern after propagating 12 um:

The user's other propagation software produces this pattern:

@douglase, any ideas?

Issue by douglase Wednesday Oct 05, 2016 at 19:45 GMT Originally opened as https://github.com/mperrin/poppy/pull/196

douglase included the following code: https://github.com/mperrin/poppy/pull/196/commits

Issue by douglase Tuesday May 19, 2015 at 23:30 GMT Originally opened as https://github.com/mperrin/poppy/issues/95

I've made a first attempt at extending POPPY to support Fresnel propagation in a branch in my fork:

https://github.com/douglase/poppy/tree/fresnel

The new module inherits the Wavefront class and added the necessary functions, methods and properties for Fresnel diffraction calculations. I chose a separate submodule because don't want to break any existing POPPY routines.

This new class has passed my initial tests. Demos of a telescope, diffraction from a circular aperture and the necessary Gaussian waist calculations are in this notebook: http://nbviewer.ipython.org/gist/douglase/600d6e4d88336f4ed0c4 (I left debug enabled, so there's lots of details in the notebook).

Some future work:

• Formal testing
• Make docstrings Astropy Guideline complaint
• Streamlined logging

Is this a feature others would find useful?

I'm going to keep working and testing this, but I wanted to open it up for outside input while things are still fresh.

This PR adds the FITSFPMElement class to poppy_core.py along with the method of applying the FPM called apply_fits_fpm_fftmft to fresnel.py. The method is in the FresnelWavefront class such that the wavefront has the FPM applied to it. There is an additional if statement in the propagate() method of FresnelOpticalSystem to check if the optic type is a FITSFPMElement and if it should be applied using standard multiplication or via the new method.

While working on the SPC modes of the Roman CGI models for POPPY, I still noticed some inconsistencies in the PSFs generated when compared to the results from the PROPER models. The PROPER models would use an FFT/MFT sequence to apply the focal plane masks for the SPC modes, so that sequence is what I have implemented here using POPPY's built in FFT and MFT functionality.

The sequence does a forward FFT to a virtual pupil plane, it the does an inverse MFT back to the focal plane but with the correct sampling required to apply the FPM, so the FPM amplitude transmission is then applied to the wavefront. A forward MFT is the done to go back to the virtual pupil and an inverse FFT is done to be back at the focal plane with the original wavefront sampling.

Results from the SPC modes show more accuracy than with my previous models I had implemented via the inwave parameter which I had a made a PR for before. These new results are shown below along with the total flux values in the array extents from both POPPY and PROPER.

SPC730 mode at 730nm (central wavelength):

SPC730 mode at 700nm:

SPC825 mode at 825nm (central wavelength):

SPC825 mode at 800nm:

I have also verified the display functionality for this type of optic:

By making the planetype for the FITSFPMElement be an intermediate planetype, the wavefront at the FPM can also be displayed with extents, meaning the display_intermediates functionality also works:

Others involved in this process are @Jashcraf and @douglase .

Let us know what changes should be made or what should be added for this to become a feature in POPPY.

Issue by mperrin Friday Jun 10, 2016 at 16:45 GMT Originally opened as https://github.com/mperrin/poppy/issues/170

splitting off this topic from https://github.com/mperrin/poppy/issues/160#issuecomment-225229716

Hi @eteq, @josePhoenix can give more of the details, but I think it's a bit of both.

For literally years, every so often I've encountered some random and hard-to-debug failures which eventually traced back to "the astropy helpers are doing something unexpected behind the scenes":

• https://github.com/astropy/package-template/issues/106
• https://github.com/astropy/astropy/issues/2502
• https://github.com/astropy/astropy/pull/3713
• and now here this new "the astropy helpers are using version 2.7 of py.test even though I've installed 2.8"
• which is possibly related to why we're getting consistent failures on Travis on python 3.5, even though all tests pass on 3.5 locally. https://github.com/mperrin/poppy/issues/159

Each of the above has led to time-consuming debugging to track down what's going on, which has been a time sink and distraction from the main tasks we're actually trying to get done. I readily admit that software is hard, and we can't expect a bug-free existence or anything close to it. But overall given the limited functionality we're actually gaining from the astropy helpers (mostly some setup.py tweaks and the sphinx extensions), it seems like the overall return on time invested is negative.

The changes made are such that a user can input their own custom wavefront data into a FresnelOpticalSystem() when using calc_psf().

The methods calc_psf() and propagate_mono() have been added directly into the FresnelOpticalSystem() class, so they are not just inherited and they contain an additional kwarg that is inwave. This kwarg is initialized to be None, but the user can define their own FrenselWavefront() and input it into calc_psf() using the inwave kwarg. This inwave object is then passed to propagate_mono(), which subsequently passes inwave to the input_wavefront() method in FresnelOpticalSystem(), which has also been edited to initialize a wavefront if the value of inwave is None, or to raise a value error if something other than a FresnelWavefront() object was supplied.

The changes made have been in an effort to create the Roman CGI modes with POPPY, however, the SPC modes and their data files required a unique sequence of MFTs and FFTs to apply the Focal Plane Masks (FPMs). So two separate optical systems were created, the first going up to the FPM and the second going through the rest of the optics of the CGI. This way, the FPM could be applied to the final wavefront of the first optical system, and then input into the second system to continue propagation. The results of this system have been tested and show agreement with the results of the PROPER model.

Future efforts will include implementing the technique used to apply the FPMs directly into POPPY such that two separate optical systems do not need to be created, but having the flexibility for a user to input their own wavefront data still seemed useful.

Please let me know if there issues with the PR or anything else I should change. Others who have contributed are @douglase and @Jashcraf.

Issue by corcoted Saturday Jul 01, 2017 at 18:22 GMT Originally opened as https://github.com/mperrin/poppy/pull/227

Patch for enhancement request #226 Added an optional parameter "mergemode" to CompoundAnalyticOptic which provides two ways to combine AnalyticOptics:

• mergemode="and" is the previous behavior (and new default)
• mergemode="or" adds the transmissions of the optics, correcting for any overlap

corcoted included the following code: https://github.com/mperrin/poppy/pull/227/commits

Issue by kmdouglass Tuesday Mar 10, 2015 at 16:18 GMT Originally opened as https://github.com/mperrin/poppy/issues/80

Hi all, I've just setup a clean virtualenv named myEnv in which I attempted to install poppy from pip3. Here are the current versions of packages I setup in the virtualenv using the Python 3.4.1 interpreter. I'm using Debian Wheezy.

(myEnv)douglass:~$ pip freeze
astropy==1.0.1
certifi==14.5.14
d2to1==0.2.11
docutils==0.12
ipython==3.0.0
Jinja2==2.7.3
jsonschema==2.4.0
MarkupSafe==0.23
matplotlib==1.4.3
mistune==0.5.1
nose==1.3.4
numpy==1.9.2
numpydoc==0.5
psutil==2.2.1
ptyprocess==0.4
pyfits==3.3
Pygments==2.0.2
pyparsing==2.0.3
pysynphot==0.9.6
python-dateutil==2.4.1
pytz==2014.10
pyzmq==14.5.0
requests==2.5.3
scipy==0.15.1
six==1.9.0
Sphinx==1.2.3
stsci.distutils==0.3.7
terminado==0.5
tornado==4.1

And the output from the install attempt:

(myEnv)douglass:~$ pip3 install poppy
Collecting poppy
  Using cached poppy-0.3.4.tar.gz
    /home/douglass/.virtualenvs/myEnv/lib/python3.4/site-packages/pkg_resources/__init__.py:190: RuntimeWarning: You have iterated over the result of pkg_resources.parse_version. This is a legacy behav
ior which is inconsistent with the new version class introduced in setuptools 8.0. In most cases, conversion to a tuple is unnecessary. For comparison of versions, sort the Version instances directly. If you h
ave another use case requiring the tuple, please file a bug with the setuptools project describing that need.                                                                                                   
      stacklevel=1,
    Traceback (most recent call last):
      File "<string>", line 20, in <module>
      File "/tmp/pip-build-8io8bu2m/poppy/setup.py", line 71, in <module>
        cmdclassd = register_commands(PACKAGENAME, VERSION, RELEASE)
      File "/tmp/pip-build-8io8bu2m/poppy/.eggs/astropy_helpers-0.4.8-py3.4.egg/astropy_helpers/setup_helpers.py", line 409, in register_commands
        'build_ext': generate_build_ext_command(package, release),
      File "/tmp/pip-build-8io8bu2m/poppy/.eggs/astropy_helpers-0.4.8-py3.4.egg/astropy_helpers/setup_helpers.py", line 470, in generate_build_ext_command
        uses_cython = should_build_with_cython(packagename, release)
      File "/tmp/pip-build-8io8bu2m/poppy/.eggs/astropy_helpers-0.4.8-py3.4.egg/astropy_helpers/setup_helpers.py", line 1205, in should_build_with_cython
        fromlist=['release', 'cython_version'])
      File "/tmp/pip-build-8io8bu2m/poppy/poppy/__init__.py", line 78, in <module>
        from . import poppy_core
    Complete output from command python setup.py egg_info:
    /home/douglass/.virtualenvs/myEnv/lib/python3.4/site-packages/pkg_resources/__init__.py:190: RuntimeWarning: You have iterated over the result of pkg_resources.parse_version. This is a legacy behav
ior which is inconsistent with the new version class introduced in setuptools 8.0. In most cases, conversion to a tuple is unnecessary. For comparison of versions, sort the Version instances directly. If you h
ave another use case requiring the tuple, please file a bug with the setuptools project describing that need.                                                                                                   

      stacklevel=1,

    Traceback (most recent call last):

      File "<string>", line 20, in <module>

      File "/tmp/pip-build-8io8bu2m/poppy/setup.py", line 71, in <module>

        cmdclassd = register_commands(PACKAGENAME, VERSION, RELEASE)

      File "/tmp/pip-build-8io8bu2m/poppy/.eggs/astropy_helpers-0.4.8-py3.4.egg/astropy_helpers/setup_helpers.py", line 409, in register_commands

        'build_ext': generate_build_ext_command(package, release),

      File "/tmp/pip-build-8io8bu2m/poppy/.eggs/astropy_helpers-0.4.8-py3.4.egg/astropy_helpers/setup_helpers.py", line 470, in generate_build_ext_command

        uses_cython = should_build_with_cython(packagename, release)

      File "/tmp/pip-build-8io8bu2m/poppy/.eggs/astropy_helpers-0.4.8-py3.4.egg/astropy_helpers/setup_helpers.py", line 1205, in should_build_with_cython

        fromlist=['release', 'cython_version'])

      File "/tmp/pip-build-8io8bu2m/poppy/poppy/__init__.py", line 78, in <module>

        from . import poppy_core

    ----------------------------------------
    Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-8io8bu2m/poppy

Any idea how I can install poppy using Python3, or am I stuck with Python2? I also ran into a similar error when trying to install PyFFTW, but this is probably a secondary issue.

Thanks!

Issue by josePhoenix Friday Dec 12, 2014 at 16:17 GMT Originally opened as https://github.com/mperrin/poppy/issues/23

For some reason, this sample code (using WebbPSF) causes a hang on my Mac Pro but not the science5 server or my personal machine (MacBook Air). Needs a better test case that uses only POPPY.

(To avoid the sometimes unusual behavior of multiprocessing + the interactive interpreter, I saved this as a separate script and ran it from the command line.)

import webbpsf
import poppy
nc = webbpsf.NIRCam()
nc.filter = 'F150W2'
poppy.conf.use_fftw = False
poppy.conf.use_multiprocessing = True
poppy.conf.n_processes = 8
nc.calcPSF()

Running this prints out logging output through "Propagating wavelength..." lines for the first 20 of 40 wavelengths, and then nothing happens.

If I interrupt the script with Ctrl-C, I get tracebacks from all the running workers interleaved (to be expected, but hard to interpret) and it looks like they're all waiting on "task = get()" which in turn is waiting on "racquire()" which seems to acquire a lock on a pipe.

This PR improves the ContinuousDeformableMirror class (for e.g. Boston MEMS DMs) by modeling the actuator positions at sub pixel resolution in the "get DM surface via convolution" implementation.

• The prior code in master rounds each actuator to the nearest integer pixel, pokes those pixels, then convolves by the DM actuator influence function. This results in uneven spacing of the modeled DM actuators unless the pupil pixel scale is an exact divisor of the DM actuator spacing (which we can't rely on).
• The new code distributes the pokes for each DM across a 2x2 square of pixels, linearly weighting between them according to the sub pixel position of the actuator. Then it convolves that by the DM actuator influence function. This results in much more uniform spacing of the modeled actuators, independent of pixel scales in the DM array.

Example image before:

With this PR:

This PR also slightly refactors the handling of DM flips, to reduce duplicated code between the convolution and Gaussian pathways, and to include the DM actuator mask (if provided) in the flipping. This is independent from the main improvements discussed above; a separate small improvement to the DM class.

See astropy/astropy-APEs#52 ("A roadmap for package infrastructure without astropy-helpers") which describes how the functionality in astropy-helpers can be achieved via more standardized tools in the Python ecosystem.

This is clearly good and we should do it.

See for instance https://github.com/spacetelescope/mosviz/pull/179 and https://github.com/spacetelescope/cubeviz/pull/492 for examples of PRs that remove astropy-helpers. We should do similarly here.

Bumps astropy from 5.1 to 5.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps numpy from 1.23.3 to 1.24.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps matplotlib from 3.5.3 to 3.6.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Astropy will drop python 3.8 support in March 2023; we should follow along then, and drop that from the supported version and the CI.

Conversely we should add python 3.11 to the CI now that it's out.

I would like to know if there is any source code for this wave [1].display. Or is there any way I can change the colorbar value scale, like changing the left colorbar the same as the right? waves[1].display(what='phase', colorbar=True,title = "Wavefront center")