You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In PIO1, we can define an IO decomposition with extra
outermost dimensions (their lengths are all set to 1) to
write/read a variable with reduced dimensions. For
example, we can use a decomposition of [1 x 10 x 20]
for a variable of [10 x 20], or use a decomposition of
[1 x 1 x 10 x 20] for a variable of [1 x 10 x 20] (or [10 x 20]).
In PIO2, the above case is not correctly handled. With
buggy code like below, PIO2 can get mismatched
start/count values from the decomposition, and access
an array out of its bounds.
for (int i = 0; i < ndims; i++)
{
start[i] = region->start[i];
count[i] = region->count[i];
}
One E3SM developer test (ERP_Ln9.ne4_ne4.FC5AV1C-L)
fails (passes with PIO1) due to this confirmed issue.
We should add some FORTRAN unit tests to reproduce this
issue, and enhance PIO2 to support decompositions with
extra outermost dimensions.
The text was updated successfully, but these errors were encountered:
In PIO1, a decomposition can have extra outermost dimensions
with their lengths all set to 1. For example, we can define a
3D decomposition of [1 x 10 x 20] to read/write a 2D variable
of [10 x 20], or a 3D record variable of [time x 10 x 20].
This feature is not supported by PIO2 so far. PIO2 might get
mismatched start/count values from the decomposition, and
access an array out of its bounds.
New Fortran unit tests are added for this enhancement, and
PIO2 code is updated to get correct start/count values from
the decomposition.
This feature branch has been extensively tested. All PIO2 unit
tests, e3sm_developer tests and cime_developer tests passed.
A High-resolution F case run on Cori also passed.
Fixes#106
In PIO1, we can define an IO decomposition with extra
outermost dimensions (their lengths are all set to 1) to
write/read a variable with reduced dimensions. For
example, we can use a decomposition of [1 x 10 x 20]
for a variable of [10 x 20], or use a decomposition of
[1 x 1 x 10 x 20] for a variable of [1 x 10 x 20] (or [10 x 20]).
In PIO2, the above case is not correctly handled. With
buggy code like below, PIO2 can get mismatched
start/count values from the decomposition, and access
an array out of its bounds.
One E3SM developer test (ERP_Ln9.ne4_ne4.FC5AV1C-L)
fails (passes with PIO1) due to this confirmed issue.
We should add some FORTRAN unit tests to reproduce this
issue, and enhance PIO2 to support decompositions with
extra outermost dimensions.
The text was updated successfully, but these errors were encountered: