replace generic exceptions with galsim exceptions

[esheldon]

There are many errors that should be recoverable but galsim throws a generic
error. This is a problem because it may not be clear from where this error
originates. One cannot distinguish the recoverable from non-recoverable
errors.

For example, a pipeline may run many calls to galsim methods; tens is not
unusual. Each of these may throw a RuntimeError or ValueError. The
pipeline, and galsim itself, will intersperse other python function calls with
galsim calls, many of which may throw the same errors.

The difference is that most RuntimeError or ValueError thrown by the python
standard library are not recoverable, they signify a bug in the program, and
the program should crash and the user should fix the code.

But many times when galsim throws such an error it is not a bug, galsim simply
does not know what to do with the inputs or has some internal numerical
restrictions that are not met. Often one can just re-call the method with
modified parameters, or otherwise deal with this an move on. If I knew the
exception was a galsim exception I could write some robust code to deal with
the situation.

An example came up today when the fft code threw a RuntimeError because the
sheared image would require too large an FFT. This is not a bug, I can deal
with this quite cleanly at run time, but I can't tell if this RuntimeError
is coming from galsim or not.

I propose replacing some uses of RuntimeError or ValueError with something
like GalsimValueError, GalsimRangeError or whatever, inheriting from a base
GalsimError class. These can then be caught and dealt with robustly.

[rmjarvis]

I don't have a problem with this. It would take some time to go through and figure out which exceptions ought to have new GalSim-specific names and which ones are bugs that should keep the current names.

As a first pass, I'd wager that all the RuntimeErrors could get a GalSim-specific name. But the rest would require some thought to determine if they are pointing to coding errors or just a problem with the input.

[esheldon]

I'll spend some time on this

[esheldon]

Here are two I ran into recently

This error I think comes from include/galsim/FFT.h

RuntimeError: FFT error: KTable size <=0

I'm not sure where the next one originates, but most likely from
src/SBSersic.cpp or src/SBMoffat.cpp

RuntimeError: Error in function boost::math::tgamma<d>(d): numeric overflow

[esheldon]

The above occurred in a recent run of my metacalibration code. Here are some that I have seen in the past

This occurred processing real DES data, from interpolatedimage.py

    raise RuntimeError("This input image has zero total flux. "
                       "It does not define a valid surface brightness profile.")

The following happens when an algorithm determines to use too large
an fft; the error is set at the C++ level in SBProfile.cpp and
appears as a RuntimeError

    "fourierDraw() requires an FFT that is too large, "

I didn't have an example on hand, so not sure where this gets called
in python

[rmjarvis]

The last one here is relatively common. When we started on GalSim, it was still relatively common for people to have computers with only 2GB of RAM, so we didn't want people accidentally thrashing their swap space from large FFTs.

However, now it would probably make sense to up the default maximum_fft_size to 8192 at least (or maybe even larger). The current default is only 4096, which isn't large enough for some kinds of PSFs (particularly with a complicated optics component).

[rmandelb]

I would be comfortable with increasing the default at this point.

[esheldon]

Returning to the issue of raising RuntimeError and ValueError in various places: I think this is an excellent candidate for adopting a new galsim error type. This sort of thing falls into a general category where the algorithm finds (or user chooses) a numerical value for a parameter that is outside of the allowed range. We could call this a GalsimRangeError that inherits from a base GalsimError

[esheldon]

Another example is in the Spergel profile, where an invalid nu raises a RuntimeError which could be a GalsimRangeError

[esheldon]

Also, for the shear method, this raises a ValueError if the shear exceeds 1. This could also be a GalsimRangeError