Set min_radius_pix for GalSim unit tests

[gostevehoward]

This gets the GalSim unit tests passing again, per #537.

This is the simplest implementation but I think adding all these keyword args is ugly and not sustainable. First, it's just ugly to have a web of kw args spreading through the code. Second, because you want to make it optional, but don't want to duplicate the default value so many times, you end up doing all this Nullable business, which isn't particularly pretty in Julia. (You could alternatively make a global const holding the default value but I find that ugly too for all the global references.)

I don't know of a good clean alternative (setting global flags is a bad idea in my opinion) other than trying to solve the problem more holistically. There's just no easy way to pass options deep down into the call tree from the top level, that I know of. One possibility would be to make a big Configuration type, which holds options like this for the entire Celeste engine. I think it'd be best structured as a nested set of types, with a structure roughly mirroring the high-level modules of the Celeste code. (I'm using "modules" informally, not implying it has to match the Julia module structure of Celeste exactly.)

For example, maybe three modules of the Celeste code are 1) image preparation (choosing patches, active pixels, etc), 2) multiple source handling (single/joint inference & threading), 3) the inference method (MOG, FFT). (This is probably not a good/accurate separation but bear with me for the sake of example.) You might have something like

type ImagePreparationConfig
  radius_override_px::Nullable{Float64}
  min_radius_px::Float64
  noise_fraction::Float64
end
ImagePreparationConfig() = ImagePreparationConfig(Nullable{Float64}(), 8.0, 0.5)

abstract InferenceConfig
type MixtureOfGaussiansConfig <: InferenceConfig ...(options)... end
type ImageFFTConfig <: InferenceConfig ...(options)... end

abstract MultipleSourceConfig
type SingleInferConfig <: MultipleSourceConfig
  inference_config::InferenceConfig
  ...
end
type JoinInferConfig <: MultipleSourceConfig
  inference_config::InferenceConfig
  ...
end

type CelesteConfig
  image_preparation_config::ImagePreparationConfig
  multiple_source_config::MultipleSourceConfig
end
CelesteConfig() = ...(defaults)...

function run_celeste(config::CelesteConfig, catalog, images, target_sources, ...etc...)
  patches = prepare_images(config.image_preparation_config, images, catalog)
  results = run_inference(config.multiple_source_config, patches, catalog, target_sources)
  ...etc...
end

function run_inference(config::SingleInferConfig, ...)
  ...
  results = infer_source(config.inference_config, ...)
  ...
end
function run_inference(config::JointInferConfig, ...)
  ...
  results = infer_source(config.inference_config, ...)
  ...
end

# in DeterministicVI.jl
function infer_source(config::MixtureOfGaussiansConfig, images, neighbors, entry) ...
# in DeterministicVIImagePSF
function infer_source(config::ImageFFTConfig, images, neighbors, entry) ...

# top-level caller
config = CelesteConfig()
config.image_preparation_config.min_radius_px = 40.0
config.inference_config = ImageFFTConfig()
run_celeste(config, catalog, ...)

Some notable things:

• Top-level caller code is clean, and only does as much work as it wants to to customize the defaults.
• Defaults are encoded in one place, the config constructor.
• Each submodule only receives the config relevant to its operation, which should make the code a bit easier to understand (than if a single giant config object were passed everywhere).
• Instead of having different entry points for different versions of a module (e.g., infer_source() and infer_source_fft()) and explicitly dispatching with conditionals or callback params (e.g., infer_source_callback), we dispatch a single entry point method call on the type of the config object, for each module.

This is benefits but it's not simple, which is why I coded the "simple" approach in this PR so you can see it. Of course we don't need a mass conversion, this could be implemented somewhat piecemeal.

I also admit this is inspired by how I'd structure such a thing in an OO paradigm, so I hope there's a simpler, equally beneficial and more idiomatic solution in the Julia paradigm which I'm not thinking of, if so let me know!

[gostevehoward]

I should mention for reference that the min_radius_px change is also fixing (or working around) #482.

[jeff-regier]

Let's bring up some of these issues with Keno tomorrow. I bet he has away do it that won't leave you missing OOP.

[gostevehoward]

OK. I added some abstract types in my sample code where they ought to be used. For what it's worth I don't think the above solution is necessarily bad, I can just see how some might find it overly complex, and I'm open to simpler alternatives. It's a matter of taste.