The docstrings for the PsfFitterComponentControl are split: See http://lsst-web.ncsa.illinois.edu/~yusra/meas_multifit/classlsst_1_1meas_1_1multifit_1_1_psf_fitter_component_control.html
I don't see what's wrong here. If you just mean that all the members appear twice on the page, once at the top, and then again at the bottom, I think that's an unavoidable thing Doxygen does with all classes. It's just more obvious here because the "brief" documentation is all any of these have.
I couldn't find where PsfFitterPrior is used by the code anywhere. Is to possible to add a test that uses it?
Good catch! I'd intended to construct one and put it in PsfFitter::_prior when any of the priorSigma parameters on the control object were nonzero and finite, but it looks like I'd forgotten that fairly important step. I'll fix that, and make sure it all still works.
I'm assuming PsfFitterModel and PsfFitterPrior are defined in psf.cc because PsfFitter is the only class that will use ever them.
Yes. And the fact that their public interface is purely defined by their base class, so as long as there's a public way to construct them, the user doesn't ever need to see the class definition.
line 256: The comment is an old note from me to you. It could go.
line 260: modelImageF is not used. (Note for future: it'd be nice if PsfFitter.apply could run on images with double pixels. – The reason this test needed a double and a float version of the psf image is because lsst::shapelet::MultiShapeletFunctionEvaluator::addToImage() takes doubles and psfFitter.apply() takes lsst::multishapelet::Pixel = floats.
Agreed. The real limitation here is that the base Likelihood class only takes single precision floats, so the underlying work all has to be done in single precision until that's addressed. But I think a convenience method to do the conversion would probably be valuable here.