Determine MPI Data Types in col_on_comm() & dst_on_comm() to prevent displacements overflow. (Fix for #2156)

[benkirk]

Determine MPI Data Types in col_on_comm() & dst_on_comm() to prevent displacements overflow.

TYPE: bug fix

KEYWORDS: prevent displacements overflow in MPI_Gatherv() and MPI_Scatterv() operations

SOURCE: Benjamin Kirk & Negin Sobhani (NSF NCAR / CISL)

DESCRIPTION OF CHANGES:
Problem:
The MPI_Gatherv() and MPI_Scatterv() operations require integer displacements into the communications buffers. Historically everything is passed as an MPI_CHAR, causing these displacements to be larger than otherwise necessary. For large domain sizes this can cause the displace[] offsets to exceed the maximum int, wrapping to negative values.

Solution:
This change introduces additional error checking and then uses the function MPI_Type_match_size() (available since MPI-2.0) to determine a suitable MPI_Datatype given the input *typesize. The result then is that the displace[] offsets are in terms of data type extents, rather than bytes, and less likely to overflow.

ISSUE: Fixes #2156

LIST OF MODIFIED FILES:
M frame/collect_on_comm.c

TESTS CONDUCTED:
Failed cases run now.

RELEASE NOTE:
Determine MPI Data Types in col_on_comm() & dst_on_comm() to prevent displacements overflow.

[benkirk]

Just for awareness, I can't see the output of the failed WRF-BUILD-2690; I get a timeout accessing
https://ncar_jenkins.scalacomputing.com/job/WRF-Feature-Regression-Test/2690/console

[dudhia]

Common problem - it will be provided by message later

…

On Fri, Jan 17, 2025 at 3:21 PM Benjamin S. Kirk ***@***.***> wrote: Just for awareness, I can't see the output of the failed WRF-BUILD-2690; I get a timeout accessing https://ncar_jenkins.scalacomputing.com/job/WRF-Feature-Regression-Test/2690/console — Reply to this email directly, view it on GitHub <#2157 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIZ77CVDAXTOXJBOYNIOZ32LF67RAVCNFSM6AAAAABVMWK7MSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOJZGMYDONRXGA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[weiwangncar]

The regression test results:

Test Type              | Expected  | Received |  Failed
= = = = = = = = = = = = = = = = = = = = = = = =  = = = =
Number of Tests        : 23           24
Number of Builds       : 60           57
Number of Simulations  : 158           150        0
Number of Comparisons  : 95           86        0

Failed Simulations are: 
None
Which comparisons are not bit-for-bit: 
None

[weiwangncar]

@benkirk Thanks for the fix! I tested it for a few cases we could run before and it is working now.

[benkirk]

Thanks for the success report @weiwangncar, happy to help!

[dudhia]

I will tag @mgduda and @islas to review this.

[islas]

@benkirk Thanks for the fix! This has been a heck of a problem to hunt down.

If my understanding is correct the overflow can still manifest, just with a domain approximately 4x in size than what triggered it before, right? Though the error will now be caught and aborted at the appropriate location.

[benkirk]

That's right, the displace[] buffer is now in terms of array elements, not bytes. So for REAL*4 or integer arrays the overflows can occur still occur, but at ~4x larger problem sizes than before. And in these cases the overflow error will be caught in the routine so at least the source of the issue is identified.

(There's some potential fallbacks even in that case I can think of but haven't implemented. Those fallbacks would require some conditions on the buffers to be sent, like evenly divisible by some integer factor. Such tricks are necessary when trying to send buffers >2GB with MPI.)