GalSim-developers/GalSim — pull request #171 by barnabytprowe (2012-05-27 06:27:31+00:00)
Title: #166 - updated OpticalPSF & functions in optics.py to use lam_over_D and dx throughout to be consistent with rest of code

This is a reasonably straightforward pull request... I have made changes to the functions and docstrings in the `OpticalPSF` class and in `galsim/base.py` described in Issue #166, to make the conventions more consistent and to make things clearer for other developers (e.g. Joerg in #105).

A couple of things came up:

1. I caught a minor bug in the setting of the size of the lookup table array in `OpticalPSF`; in the past the degree of oversampling requested by the user was not being taken into account, and it should be. This is fixed.

2. The inclusion of oversampling in consideration for the lookup table array size meant that the arrays got bigger for `oversampling` > 1. I thus reduced the default oversampling ratio from 2.0 to 1.5 in the `__init__` function for `OpticalPSF`. Really, anything > 1 should be sufficient in the ideal case. For practically realistc interpolants it makes sense to give a little overhead, hence 1.5.

3. This bug fix in `OpticalPSF` meant that the spline regression tests (which tested the kValues given by the spline-approximated k space interpolants of the `SBInterpolatedImage` used by `OpticalPSF` instances) had to be updated. I therefore went back to the commit in the repo which still contained the old NR routines, created a new branch (#166a_spline_fix) and added the newer `OpticalPSF` python functions to regenerate the tables for the regression tests. This is all documented in the commits themselves (plenty of cross-referencing), and in the comments header of `devutils/external/test_splines/make_spline_testarrays.py`. I was then able to merge #166a_spline_fix into #166 cleanly, re-updating back to the new spline code, so that all of this is preserved on the repo for posterity but we don't have a dangling branch.

I'm not sure if Item (3) above means that #166a_spine_test will still be visible as an unmerged branch on Github after #166 is pulled into master. If so, I will simply remove the branch label. All of the relevant info is stored indelibly in the commits themselves, so this won't harm any of the book-keeping, but I wanted to explain here what I'd done.

Would welcome comments on the new code, as ever. Particularly from @joergdietrich to see whether the newer conventions make more sense.