galsim.Aperture specified with a pupil_plane_im is 4 times slower than using galsim.Aperture parameters

[aaronroodman]

I'm making a PSF from a galsim.PhaseScreenPSF and a galsim.VonKarman and find that drawing the PSF is 4 times slower using a pupil_plane_im than using Aperture parameters. I was hoping that using a pupil image would be just as fast as the parametrization.

A sample script is attached, along with two files used to define a phase screen and the pupil aperture. The scripts makes 500 stars with either Aperture specification.

test_galsim_opticspsf.zip

[rmjarvis]

The issue here is just that the pupil plane image you are providing is quite a lot larger than the image that gets made automatically from struts and obscuration. More than 2x larger in each dimension. The tall pole numerical computation in phase_screen scales with the number of pixels in the illumination image (based on this image), so that's the 4x you're seeing.

I think the solution (i.e. to make it faster at the expense of some precision) is probably to rebin the input image before passing it to Aperture. If I add the line:

pupil_plane_uv = pupil_plane_uv.bin(2,2)

in getAperture, then the speed comes out much closer to the same:

Parametrized Aperture, 500 stars
time for make_images = 4.01
Image File Aperture, 500 stars
time for make_images = 4.87

If you're willing to cut the resolution even more at the expense of still more precision, you can use bin(4,4). Then GalSim will complain, but it will run nonetheless:

Parametrized Aperture, 500 stars
time for make_images = 3.93
Image File Aperture, 500 stars
/Users/Mike/mambaforge/envs/py3.8/lib/python3.8/site-packages/galsim/errors.py:416: GalSimWarning: The calculated stepk (1.04824) for PhaseScreenPSF is smaller than what was used to build the wavefront (1.48892). This could lead to aliasing problems. Increasing pad_factor is recommended.
  warnings.warn(message, GalSimWarning)
time for make_images = 2.15

The rendered stars still look visually identical to me with the 4,4 binning, so this might be acceptable. But I didn't try too hard to find where there might be aliasing issues with that.

[aaronroodman]

Mike, Ok! Thanks for looking into this Regards, Aaron

…

_________________________________________________________________________ Prof. Aaron Roodman Deputy Director Vera C. Rubin Observatory Dept. of Particle Physics & Astrophysics Kavli Institute for Particle Astrophysics & Cosmology SLAC National Accelerator Laboratory Stanford University SLAC National Accelerator Laboratory E-mail: ***@***.******@***.***> 2575 Sand Hill Rd. Phone: 650-926-2705 MS 29 Menlo Park, CA 94025 URL: http://www.slac.stanford.edu/~roodman

_________________________________________________________________________ From: Mike Jarvis ***@***.***> Date: Monday, September 12, 2022 at 9:33 AM To: GalSim-developers/GalSim ***@***.***> Cc: Roodman, Aaron ***@***.***>, Author ***@***.***> Subject: Re: [GalSim-developers/GalSim] galsim.Aperture specified with a pupil_plane_im is 4 times slower than using galsim.Aperture parameters (Issue #1182) The issue here is just that the pupil plane image you are providing is quite a lot larger than the image that gets made automatically from struts and obscuration. More than 2x larger. I think the solution (i.e. to make it faster at the expense of some precision) is probably to rebin the input image before passing it to Aperture. If I add the line: pupil_plane_uv = pupil_plane_uv.bin(2,2) in getAperture, then the speed comes out much closer to the same: Parametrized Aperture, 500 stars time for make_images = 4.01 Image File Aperture, 500 stars time for make_images = 4.87 If you're willing to cut the resolution even more at the expense of still more precision, you can use bin(4,4). Then GalSim will complain, but it will run nonetheless: Parametrized Aperture, 500 stars time for make_images = 3.93 Image File Aperture, 500 stars /Users/Mike/mambaforge/envs/py3.8/lib/python3.8/site-packages/galsim/errors.py:416: GalSimWarning: The calculated stepk (1.04824) for PhaseScreenPSF is smaller than what was used to build the wavefront (1.48892). This could lead to aliasing problems. Increasing pad_factor is recommended. warnings.warn(message, GalSimWarning) time for make_images = 2.15 The rendered stars still look visually identical to me with the 4,4 binning, so this might be acceptable. But I didn't try too hard to find where there might be aliasing issues with that. — Reply to this email directly, view it on GitHub<#1182 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABARV46EG7NS2KJWSXFJH4DV55LLLANCNFSM6AAAAAAQAZDEOM>. You are receiving this because you authored the thread.Message ID: ***@***.***>