Pitfall using mksurdata_esmf options --model-mesh-nx NX --model-mesh-ny NY when using unstructured meshes #2847
Labels
bfb
bit-for-bit
next
this should get some attention in the next week or two. Normally each Thursday SE meeting.
size: small
usability
Improve or clarify user-facing options
This command creates a bad fsurdat file:
./gen_mksurfdata_namelist --start-year 1850 --end-year 1850 --res ne3np4 --model-mesh /glade/campaign/cesm/cesmdata/inputdata/share/meshes/ne3np4_ESMFmesh_c230714_cdf5.nc --model-mesh-nx 1 --model-mesh-ny 488
This command, where the mesh file's elementCount (here, 488) and the value 1 have been switched, creates a good fsurdat file:
./gen_mksurfdata_namelist --start-year 1850 --end-year 1850 --res ne3np4 --model-mesh /glade/campaign/cesm/cesmdata/inputdata/share/meshes/ne3np4_ESMFmesh_c230714_cdf5.nc --model-mesh-nx 488 --model-mesh-ny 1
The explanation is in this if-statement in
subroutine check_namelist_input
of the mksurfdata_esmf toolWe could come up with a series of checks to try to prevent users from experiencing this pitfall.
The text was updated successfully, but these errors were encountered: