GalSim-developers/GalSim — pull request #173 by barnabytprowe (2012-05-31 06:24:38+00:00)
Title: #35 -  central obscuration (e.g. secondary mirror) in pupil plane now implemented and tested

Another (hopefully) straightforward pull request.

I've implemented central obscuration, following the input param syntax Gary uses in SBProfile. The central obscuration is a co-centric disk with the main pupil (or square if using the optional square pupil), of a size specifed by a radius ratio parameter `obs` (default=0.).

There's also a unit test that compares the unaberrated obscured pupil to the same thing implemented by `SBAiry`, which seems to pass OK on my machine.

The only other thing to add is, after some testing, I decided to change the default `pad_factor` in `OpticalPSF` to 1.5 from 2.0. This means that the `stepK` (and thus reciprocal image size) is by default only a factor 1.5 smaller (larger in image size) than that used by SBAiry... This was giving v. good results on aberrations (specified via the peak-to-valley wavefront error, see the docstring for, e.g., `optics.wavefront`) I tested, for values up to and slightly larger than unity in units of the incident light wavelength.

This is what we should be expecting for most telescopes that aren't really horribly aligned. Larger values of `pad_factor` can be specified for larger aberrations if we want to simulate those, but it is a waste of CPU time to make this too large by default. The NR vs new spline code regression tests still use the previous default value of `pad_factor=2`.

I think, in time, it will be nice to add struts to the pupil plane too. This will be relatively straightforward. But in terms of the physical effects of primary importance to the telescope optical PSF, we are now nearly there.

Comments / suggestions for improvement welcome. As mentioned in the previous `OpticalPSF`-related pull request #166, we may wish to look into speeding up the FFTs by using the default scaling adopted by Gary in SBProfile (i.e. 2^n or 3 * 2^n as the array size). This can be put to a later Issue I think, if we find that making the lookup tables for `OpticalPSF` objects becomes a rate-determining step... Hopefully at some point it will :)