Generalized Indices: MPP_REDISTRIBUTE#1886
Conversation
abrooks1085
requested review from
bensonr,
rem1776,
uramirez8707 and
vithikashah001
as code owners
uramirez8707
left a comment
uramirez8707
left a comment
There was a problem hiding this comment.
Just minor comments regarding the new argument name. Looks good to me otherwise.
| logical, intent(in), optional :: complete, free | ||
| integer, intent(in), optional :: list_size | ||
| integer, intent(in), optional :: position | ||
| integer, intent(in), optional :: axis_to_dim_in(3) |
There was a problem hiding this comment.
Please document this new arguments.
Can we make it consistent with the other subroutines? I think we used dim_order.
There was a problem hiding this comment.
Good point. I’ll add documentation for the new argument.
I also agree that this should be consistent across the MPP interfaces. While reviewing this, I found that dim_order is ambiguous because it has been used in different senses. In mpp_redistribute, the mapping is from logical axis to storage dimension:
axis_to_storage(logical_axis) = storage_dimension
For example, axis_to_storage = (/3,1,2/) means logical x, y, and z are stored in dimensions 3, 1, and 2.
The current pelist gather/scatter implementation uses dim_order in the opposite direction internally, mapping storage dimension to logical axis. To avoid exposing two conventions, I’m renaming the public argument to axis_to_storage for redistribute and will update pelist gather/scatter to use the same public convention, converting internally to the reverse map where needed. This should also make the interface consistent with @J-Lentz’s group update PR.
Pass field addresses, chunk counts, and shape metadata through the generalized redistribute register path instead of constructing rank-specific array aliases in the wrappers. Higher-rank fields are handled as contiguous 3D chunks in the shared do_redistribute implementation.
…torage_to_axis in test_mpp_domains.F90
3 participants
Description
This PR adds generalized storage-layout support to MPP_REDISTRIBUTE for 2D–5D fields. Callers may pass an optional axis_to_storage mapping, defined as:
axis_to_storage(logical_axis) = storage_dimension
For example, axis_to_storage = (/3,1,2/) means logical x, y, and z are stored in dimensions 3, 1, and 2, respectively.
The redistribute wrappers now pass this mapping through to the low-level pack/unpack logic, which maps logical domain bounds onto the correct storage dimensions before accessing field data. For 4D and 5D fields, extra dimensions are handled as repeated contiguous 3D chunks instead of being collapsed onto the third dimension, avoiding the previous assumption that storage dimension 3 is always logical z.
How Has This Been Tested?
amdbox + intel
Checklist:
make distcheckpasses