GalSim-developers
galsim.Aperture specified with a pupil_plane_im is 4 times slower than using galsim.Aperture parameters
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.
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.
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 GitHubhttps://github.com/GalSim-developers/GalSim/issues/1182#issuecomment-1243993965, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABARV46EG7NS2KJWSXFJH4DV55LLLANCNFSM6AAAAAAQAZDEOM. You are receiving this because you authored the thread.Message ID: @.***>