walkup@us_ibm_com
New Member
I recently downloaded and built CESM 2.1 on the Oak Ridge Summit system using IBM XL Fortran, and encounterd a few issues. XL Fortran will complain when intrinsic functions max(a,b), min(a,b), mod(a,b) have different types, while many other compilers (for example gfortran) will not. A diff file is attached with the changes that I made to ensure proper type matches. You may prefer somewhat different solutions, but I believe that the source files flagged by XL Fortran should get fixed. There was another issue that arose at runtime and was fatal when using the XL Fortran build of CESM 2.1 with parallel netcdf. The job failed with segmentation violation and the call-stack pointed to the rand(r) routine defined in cism/source_cism/libglimmer-solve/SLAP/xersla.f . The fundamental issue was a name conflict with the rand() routine in the standard C library ... the C rand() routine is used inside MPI-IO functions. By default the XL Fortran compiler does not add an underscore to entry point names, and so the MPI-IO code was picking up the wrong version of the "rand" function, resulting in job failure. This issue would not arise with compilers that add an undersocre to Fortran function names, but I think it is a good idea to use a more specific name in the CESM source tree, for example slrand(r) for the Slatec xersla.f function. Using grep, it appears that the Slatec rand(r) function is used only in Slatec source file dlapqc.f, so a name-change would be contained to those two source files (dlapqc.f and xersla.f), and would prevent name conflicts with the C rand() routine. After fixing the issues mentioned above, CESM 2.1 built with both XL Fortran and GNU Fortran, and both builds passed the ECT verification test.