farrayPtr2DCpy (a.k.a. arrayDup) is not initialized in ESMF_ArrayCreateGetUTest.F90

[danrosen25]

esmf/src/Infrastructure/Array/tests/ESMF_ArrayCreateGetUTest.F90

Line 408 in 82ba326

if (abs(farrayPtr2D(i,j)-farrayPtr2DCpy(i,j)) < 1.d-10) dataCorrect=.false.

Test Failure

Verify Array vs Array Copy (ALLOC) no data copy, ESMF_ArrayCreateGetUTest.F90, line 411:  Unexpected data copy
if (abs(farrayPtr2D(i,j)-farrayPtr2DCpy(i,j)) < 1.d-10) dataCorrect=.false.

Initialization for farrayPtr2DCpy never happens because it is created with ESMF_DATACOPY_ALLOC
arrayDup = ESMF_ArrayCreate(array, datacopyflag=ESMF_DATACOPY_ALLOC, rc=rc)
Initialization for farrayPtr2D
farrayPtr2D = real(localPet+10, ESMF_KIND_R8)

This causes intermittent failures

[danrosen25]

@theurich @oehmke
How should we fix this test? It's only guaranteed to be successful if ifort: -init=keyword [, keyword ] or gfortran: -finit-real=<zero|inf|-inf|nan>, etc are used, which we don't set for any build configuration.

We could

• eliminate this test
• redo the infrastructure to include a macro for #ifdef ESMF_INIT_REAL and fence this test and add the above flags for BOPT=g
• initialize arrayDup, which defeats the purpose of the test
• change the values in farrayPtr2D to something more obscure but this won't guarantee that the test works
• change the test so that it checks if every array value is identical

[theurich]

I agree that this test is fundamentally problematic, and can only be guaranteed 100% when using compiler level initialization as you point out. However, that gets tricky and requires maintenance when supporting many different compilers, and their versions... which is why I would like to stay away from that.

I think we could make the test more robust (not 100% but better than now) by (1) more obscure init data (as you suggest), and (2) turning around the verification logic. Currently the logic sets dataCorrect=.false. when a single element matches between the two arrays. This can happen randomly due to the uninitialized data in arrayDup. However, if we change it to set dataCorrect=.true. as soon as a single element is different (which means it is NOT an array data copy), then false positives (or negatives which ever you think about it) become much less likely, especially for a large enough array size.