[mpas-developers] dmpar_abort

[Michael Duda]

Hi, Xylar.

One approach might be to return a status code from routines that
might encounter errors, and allow a routine higher up in the call
stack to handle the error with a dmpar_abort if it were deemed
appropriate. Depending on the nature of the subroutine, this might
be the preferable approach -- allow higher-level code to determine
whether the error can be recovered from or whether it is fatal.
However, this would either entail adding an error code argument to
the subroutine, which is one thing we'd like to avoid, or
converting the subroutine into a function, which wouldn't be an
option if the subroutine was in fact already a function.

Another approach, and one that would be very simple to implement,
would be to add a dmpar_global_abort(mesg) routine that is
callable from any code that uses the dmpar module, and that prints
the message mesg before calling MPI_Abort with MPI_COMM_WORLD. The
current dmpar_abort only needs the dminfo argument to get the
communicator to abort on, and I'd be hard-pressed to find a case
where it would be desirable to abort on a communicator other than
the global one. Adding a dmpar_global_abort routine would obviate
the need to pass dminfo into any subroutine that might need to
abort, and adding it as a new subroutine would allow us to migrate
from existing calls to dmpar_abort on an as-needed basis.

I'd support adding a dmpar_global_abort routine in the dmpar
module, but I'd also suggest considering whether the error being
checked for is one that can be recovered from, in which case a
return error code might be the cleanest approach in that
particular case.

Cheers,
Michael


On Mon, Apr 26, 2010 at 02:10:10PM -0600, Xylar Asay-Davis wrote:
> I'm trying to use dmpar_abort as a way to stop the code with an error 
> message when things go wrong with the code I'm testing.  I could just 
> use stop, but I figured dmpar_abort was the "proper" way.  The problem 
> is that dminfo, the argument needed by dmpar_abort, is a member of the 
> domain, which is not available in many subroutines.  And it's 
> inconvenient to have to pass around any extra arguments to my 
> subroutines just in case I might want to abort.
> 
> Any suggestions?
> 
> -Xylar
> 
> -- 
> 
> ***********************
> Xylar S. Asay-Davis
> E-mail: xylar at lanl.gov
> Phone: (505) 606-0025
> Fax: (505) 665-2659
> CNLS, MS B258
> Los Alamos National Laboratory
> Los Alamos, NM 87545
> ***********************
> 
> 
> _______________________________________________
> mpas-developers mailing list
> mpas-developers at mailman.ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/mpas-developers