Machine parameters such as the relative machine precision, the underflow and overflow thresholds, and the smallest value which can be safely reciprocated (which in LAPACK is called sfmin), are frequently used in numerical linear algebra computations, as well as in many other numerical computations. Without due care, variations in these values between processors can cause problems, such as those mentioned above.
Many such problems can be eliminated by using the largest machine precision among all participating processors. In LAPACK routine DLAMCH returns the (double precision) machine precision (as well as other machine parameters). In ScaLAPACK this is replaced by PDLAMCH which returns the largest value over all the processors, replacing the uniprocessor value returned by DLAMCH. Similarly, one should use the smallest overflow threshold and largest underflow threshold over the processors being used. The ScaLAPACK routine PDLAMCH runs the LAPACK routine DLAMCH on each process in the context and communicates the relevant maximum or minimum value. We refer to these machine parameters as the multiprocessor machine parameters. DLAMCH can also return the base, b, which nowadays is invariably b = 2, but what we would do for PDLAMCH if we ever had a mixture of binary and decimal machines in a network we leave as an open question!
Note that since PDLAMCH requires communication to each process in the context, it suffers from the weakness that it cannot be called by a subset of the processes (as might for example happen when a conditional statement such as an IF statement is being executed), because processes will be waiting for a communication which will never take place. There are many examples in ScaLAPACK codes, however, where only a subset of nodes (for instance one column or one row of the process grid) is performing a given computation, such as pivot selection. ScaLAPACK has to avoid calling PDLAMCH from such computations. Section 8 contains a specific example of this case.
For this reason, it is expected that the next release of the BLACS will support caching based on the BLACS context. We will then be able to perform the communication just once for each context and cache the values on the context. Subsequent PDLAMCH calls within the context will then access strictly local data, so will be more efficient, and thus may be safely called from code performing computations on grid subsets.