Error Handling in the BLACS

 

This section describes the BLACS error-handling features. The BLACS error-handling behavior may be changed at compile time by using the C preprocessor macro BlacsDebugLvl. a call to BLACS_GET (see  [54] for details) will help determine what debug level the BLACS are using.

If the BLACS are compiled with a BLACS debug level of 0, little error checking is performed. A few critical items will be checked (for instance, BLACS_GRIDINIT will still not allow the user to allocate a process grid with more processes than there are available), but for performance reasons, the BLACS will not check most of the parameters.

It is therefore highly recommended that users link their code to a BLACS library compiled with debug level 1 while debugging their code. BLACS debug level 1 mainly does parameter checking. A few other services are also provided. For instance, users will be warned if a process sends a message to itself. Having a process send to itself is legal, but it displays poor performance and requires enough buffer space that it can occasionally cause hangs for large messages. The BLACS therefore issue a warning when this behavior is detected.

Many times, the debug level 0 code will simply hang, leaving the developer without any clue as to what has gone wrong. This may be caused, for instance, by trying to receive from a process that is not in the current context. The debug level 1 BLACS can detect this type of user error, and issue a (we hope helpful) message.

The BLACS issue three types of messages:

1. BLACS warning: BLACS detect risky behavior, but attempt to correct or ignore. Warning message is printed, and execution proceeds.
2. BLACS error: BLACS detects an error, prints an error message, and kills the machine via a call to BLACS_ABORT.
3. System error: The BLACS receive an error message from the underlying system, which is then passed on to the user, and the BLACS kills the machine.

 
• BLACS Warning and Error Messages