[Users] GRHydro: NaN checks

[Christian Reisswig]

Hi,

On Monday, July 19, 2010 12:47:32 pm Erik Schnetter wrote:
> On Mon, Jul 19, 2010 at 9:04 AM, Christian D. Ott
> 
> <cott at tapir.caltech.edu> wrote:
> > Hi,
> > 
> > On Mon, Jul 19, 2010 at 08:43:00AM -0500, Frank Loeffler wrote:
> >> I agree with Erik that if they affect performance that much we should
> >> protect them with #defines, but leave them in the code - even if this
> >> clutters it. They are much easier to put back in by setting a #define
> >> than by putting them all in back by hand. They can help quite a bit when
> >> you know that there are NaNs produces somewhere in GRHydro and you want
> >> to know quickly where and why.
> > 
> > they don't do that.
> > 
> > (a) They are not general -- i.e., in Prim2Con, there is a check on
> > the lorentz factor and on dens, but that's it (it's even redunant!).
> > This test won't tell you if there is a nan in another var.
> > 
> > (b) They are only in some parts of the code (i.e., the parts that
> > the person who needed them was using).
> > 
> > (c) They don't tell you 'quickly where and why'. If you get an error
> >    message like:
> > 
> >   call CCTK_WARN(GRHydro_NaN_verbose,
> >     "c2p failed and being told not to reset the pressure")
> > 
> >    Do you have any clue what happened? You are not even being told
> >    where (what physical location; what reflevel).
> > 
> > Of course, one could spend one's life making these messages better.
> > But we are paid for doing science, not for writing foolproof code.
> > 
> > I maintain that there is no point in having such messages.  They don't
> > help -- if you catch yourself a NaN (like I did yesterday!), you still
> > have to go in and do old-fashioned debugging to see what is going on.
> > 
> > Since we are not reaching a conclusion via e-mail, I would like
> > to discuss this in today's call.
> 
> For the record I would like to mention some of the possibilities
> mentioned during todays' phone call:
> 
> (1) There could be a macro CCTK_NANCHECK that checks a scalar variable
> for nan, outputting a warning message.  This would be easy to disable,
> and would be much cleaner than the current multi-line code for each
> variable.
> 
> (2) The NaNChecker thorn could be used to generate a nanmask, either
> automatically after each scheduled function (e.g. via Carpet's
> CallFunction), or manually after each 3D loop.

just some maybe trivial comment from my side: please use double or int numbers
for the mask and not some fancy memory saving bitmask. This makes 
visualization much easier because readers won't have to distinguish between
weird number formats.

cheers,
Christian

> (3) The thorn NaNCatcher can enable floating point exceptions as soon
> as any nan is encountered, aborting the job (or starting a debugger).
> 
> These approaches do not work well at the moment, because there are
> coarse grid points which do not contribute to the overall solution,
> but it is not obvious which coarse grid points these are.  Carpet
> needs to provide a mask describing which grid points remain "unused"
> after restriction.
> 
> -erik

-- 
Dr. Christian Reisswig
Theoretical Astrophysics
Cahill Center for Astronomy and Astrophysics
California Institute of Technology