so I have an update on this.  on 94d2558 I made a first pass at adding caching and `draw`-ing the profile with a `galsim.Pixel(image.scale)` included.  unfortunately, the immediate impact of this was to cause the FFT that was now required to be drawn within `FourierDraw` to be huge.  before the convolution, `draw` could be done in pure real space without FFTing, and this was an inadertant, but large, efficiency saving.

even making the `GSParams.maximum_fft_size` huge (512^2) I was unable to get these SBErrors to go away.  for the tests that did run, the code slowed down to a crawl and took *lots* of memory.

so then I turned to the `calculate_stepk=False` and `calculate_maxk=False` that were the default choices within the `CorrelatedNoise` and `getCOSMOSNoise` instantiaiton of an `InterpolatedImage`.  turning `calculate_stepK=False` helped in some cases but in others led to the same `assert` orpoblems as before (the radial profile of these images is so peaky that the automatic routine fails).  the code in this state is here: 8b5b2c2 .  the memory allocation issues still got so large on the few tests that did meet the `maximum_fft_size` criteria that nose just crashed out a couple of the processes.

returning to `calculate_stepk=False` and instead putting `calculate_maxk=True` helped again in some (different cases), but didn't help in all. (see 831105e). agan, noise crashed out on a couple of the processes. it also led to some other failures, but I realised that these were because of the use of raw `draw()` commands in the tests that needed to be updated, and so I should have expected to encounter these failures in any case.

summary: I was not encouraged.

I think there are three options:

* we make the `maximum_fft_size` just *huge* for correlated noise profiles, and only run on machines with massive memory (in which case I will unrevert the three commits above and make the remaining tests pass)
* we focus attention on making the `calculate_maxk`/`calculate_stepk` work better for these gnarly profiles; this is a non-linear problem though, and we will never guarantee stability in all cases, so I worry a little about this.
* we live with the rather crummy approximation of the `Linear` interpolant to what we really want, and make a note of the efficiency reasons vs problems associated with doing this.

For GREAT3 I think that the third option is made more valid by the fact that the final output pixels, for either the space or ground-based data branches, are larger than the 0.03 arcsec pixels of the COSMOS correlated noise that we are seeking to whiten.  this means that the details of how we are treating the space between pixels becomes less important quite quickly.  this, and the fact we included the output-scale `galsim.Pixel` in the `correlated_noise.convolveWith([..., ...])` kernel, is why we saw good results in the whitening tests, despite the innaccuracies in the underlying treatment that have come to light.

keeping the linear interpolant and not convolving with the image.scale-sized `Pixel` when drawing would mean that the following cases would be compromised in accuracy, to various degrees:
* representing correlated noise in an image where the scale between pixels in the correlated noise is larger than the desired final output pixel scale (not many immediate use cases, but important to flag up)
* representing correlated noise fields that have been rotated relative to the final output pixel grid, where the correlated noise comes from a larger or comparably sized pixel scale image compared to the final output pixel scale.

the reason this last matters can be illustrated by a thought experiment.  imagine a CF from noise at a certain pixel scale `dx`.  we then rotate this CF by some general angle and redraw at the same scale `dx.  Now, because a boxcar convolved with another boxcar rotated by anything other than 90, 180 or 270 degrees is not precisely a triangular pyramid function of full width `dx`, the bilinear interpolant no longer precisely corresponds to the case we wish to describe.  it's not massively far away, which is why the tests pass, but we know it is a little wrong.

ugh. talk about fiddly!

my recommendation, given i) the timescale; ii) the empirical success of the current, imperfect scheme; and iii) the large manpower and/or CPU overheads that may be necessary to get the exact treatment working, is to stick with what we have.  I think the slight degree to which the noise is therefore imperfectly whitened is, by my reckoning, still appropriate given the other, large uncertainties we have in e.g. the galaxy selection given the finite size of the galaxy sample, colours, and other simplifications in the modelling.  but it's a bit unsatisfactory, and makes the justification that bit more complex.  we may need to run more tests to be sure.

[this possibly goes some way to explain the small (but detectable at ~0.1%) off pixel anti-/correlations I previously saw in my treated, whitened noise fields. at this level we probably have plenty more to worry about in detector effects -- such as interpixel capacitance for IR detectors -- anyway!]

fiddly.