>> Speaking of things we don't do or don't want to do during development...
>>
>> Because we only handle error() ourselves, I found it useful while
>> debugging to change a few assert() statements to use a
>> libmesh_assert() macro instead, one which (when NDEBUG isn't defined)
>> basically does a
>> This might be a good place to start? It describes the
>> MPI_Errhandler_create and MPI_Errhandler_set interfaces.
>
> Thanks, but according to this, MPI's default behavior should already
> be what I want: to do an MPI_Abort on any errors.
>
> Of course, even when I do an MPI_Abort(COMM_WORLD
On Sat, 12 Apr 2008, John Peterson wrote:
> This might be a good place to start? It describes the
> MPI_Errhandler_create and MPI_Errhandler_set interfaces.
Thanks, but according to this, MPI's default behavior should already
be what I want: to do an MPI_Abort on any errors.
Of course, even wh
This might be a good place to start? It describes the
MPI_Errhandler_create and MPI_Errhandler_set interfaces.
-J
http://www.mpi-forum.org/docs/mpi-11-html/node148.html
On Sat, Apr 12, 2008 at 11:39 AM, Roy Stogner <[EMAIL PROTECTED]> wrote:
>
> I'm taking another look at making our assert()/e
I'm taking another look at making our assert()/error()/abort()/throw()
behavior more consistent and more useful, but with the levels of code
below us it's not easy. If one process fails an assert(), for
instance, it eventually dies with an abort() and returns an error code
to the OS, but for some
