Open gdicker1 opened 2 months ago
From what I found in this thread, it seems like Intel compilers on x86_64 systems don't check for overflow like I'd expect: https://community.intel.com/t5/Intel-Fortran-Compiler/How-best-to-handle-integer-overflow-situations/m-p/1088876#M123659
The ./cube_to_target ...
command I supplied in the Issue body will run successfully if you add --jmax_segments 26500
.
What I expected: Since the User's Guide indicates that Intel compilers are an option, I would expect the
cube_to_target
executable to work with minimal intervention.What I saw: Runs to generate bnd_topo files for MPAS-A grids fail unless I use GNU compiler.
What I did on Derecho:
cd
into cube_to_targetmodule purge && module load intel-classic cray-mpich netcdf-mpi
cube_to_target
executable:make
./cube_to_target --grid_descriptor_file "/glade/campaign/cesm/cesmdata/inputdata/share/meshes/mpasa120z32_ESMFmesh_cdf5_c20210120.nc" --intermediate_cs_name "${PATH_TO}/gmted2010_modis_bedmachine-ncube3000-220518.nc" --output_grid mpasa120 --smoothing_scale "100.0" --name_email_of_creator "${YOUR_VALUE_HERE}"
Error text:
This seems to be due to the logic around line 597 of cube_to_target.F90. GNU builds this seems to be handled appropriately, but my runs with Intel suggest (due to negative jall_anticipated) that the integer overflow check isn't sufficient.