Intel-Classic Compiler jall_anticipated overflow

[gdicker1]

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:

1. Clone NCAR/Topo repo and cd into cube_to_target
2. Load the correct modules: module purge && module load intel-classic cray-mpich netcdf-mpi
3. Build cube_to_target executable: make
4. Attempting the command below eventually gives the error text

./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:

# other output...
 Writing topo file to
 /glade/derecho/scratch/gdicker/2024Apr26_NCARTopoTest/Topo/cube_to_target/mpasa
 120_gmted2010_modis_bedmachine_nc3000_Laplace0100_noleak_20240429.nc

# ... multiple blank lines here ...

 anticipated number of overlaps jall_anticipated=  -198767296
 Compute overlap weights:
 more weights than anticipated
 increase jall

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.

[gdicker1]

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

[gdicker1]

The ./cube_to_target ... command I supplied in the Issue body will run successfully if you add --jmax_segments 26500.