Add consistency checks for mesh_nx mesh_ny relative to mesh_file in gen_mksurfdata_namelist.py

[slevis-lmwg]

Description of changes

If mesh_file contains mesh_nx mesh_ny info, read it from the file.
Else abort and require user to enter it at the command line.
Confirm that the product of mesh_nx x mesh_ny (user-entered or from mesh_file) = elementCount (from mesh_file).

Address #1791 here, so as to name fsurdat files by their site/grid name rather than by their NX x NY.

Also address #1776 here, so as to stop hardwiring the mpirun command according to --machine in gen_mksurfdata_jobscript_single.py. Now get the mpirun command from env_mach_specific.xml.

Specific notes

Contributors other than yourself, if any: @ekluzek

CTSM Issues Fixed (include github issue #): #1790 #1791 #1776

Are answers expected to change (and if so in what way)? No.

Any User Interface Changes (namelist or namelist defaults changes)? No.

Testing performed, if any:
Running gen_mksurfdata_namelist.py for cases with and without --model_mesh in the user-entered arguments and confirming expected behavior.

[slevis-lmwg]

@ekluzek this PR could be ready for review and merging UNLESS you think I should fold #1776 here, too. I wouldn't mind doing that rather than opening a separate PR for that. Whatever you think makes more sense.

Update: I decided to keep working in the same PR.

[slevis-lmwg]

I see a git behavior that I don't understand.
Izumi gives the response that I expected:

> git branch
nx_ny_consist_checks
> git log
commit fb87525e7c6e1ae8092afbe6d643239e22f000a9
> git describe
alpha-ctsm5.2.mksrf.05_ctsm5.1.dev090-5-gfb87525e7

On cheyenne, the first two agree, but the third gives a different response:

> git describe
alpha-ctsm5.2.mksrf.04_ctsm5.1.dev090-53-gfb87525e7

[ekluzek]

@slevisconsulting this likely means you haven't pulled all the tags in both of your clones. If you fetch everything in both clones they will likely be consistent. The tags it's pointing to are the ESCOMP tags, so fetch from ESCOMP, and you might need to use the "-t" option to make sure you pull all the tags.

[slevis-lmwg]

@slevisconsulting this likely means you haven't pulled all the tags in both of your clones. If you fetch everything in both clones they will likely be consistent. The tags it's pointing to are the ESCOMP tags, so fetch from ESCOMP, and you might need to use the "-t" option to make sure you pull all the tags.

Interesting. The -t option returned this:

> git fetch -t escomp
From https://github.com/ESCOMP/ctsm
 ! [rejected]            alpha-ctsm5.2.mksrf.04_ctsm5.1.dev090 -> alpha-ctsm5.2.mksrf.04_ctsm5.1.dev090  (would clobber existing tag)
 ! [rejected]            alpha-ctsm5.2.mksrf.05_ctsm5.1.dev090 -> alpha-ctsm5.2.mksrf.05_ctsm5.1.dev090  (would clobber existing tag)

If it's not concerning, I can leave as is and make the next tag (after we go over my mods) from izumi in case it makes a difference.

[ekluzek]

That sounds like your local tag in your clone is in disagreement with the tag on ESCOMP. I would trust the tag on ESCOMP and be suspicious of the tag on your local clone. You could look into it in more detail to see which is right, and if the ESCOMP ones are actually correct. But, even if the tags are wrong we are unlikely to do anything about it for these branch tags. But, you probably don't want to have a tag on your local clone that disagrees with ESCOMP.

[slevis-lmwg]

@ekluzek request:
add comments to explain these lines, esp the last one

[slevis-lmwg]

@ekluzek request:
if orig_grid_dims disagrees with user-entered values, then abort with error message
if agrees, go on

[slevis-lmwg]

@ekluzek comment:
add TODO that this workflow should be included in the User's Guide.
add similar comment in the issue (#1773 ).