Prepare Makefile to make CTSM5.4 fsurdat/landuse datasets

[slevis-lmwg]

Description of changes

Updating

• tools/mksurfdata_esmf/Makefile to accommodate new fsurdat/landuse list
• python/ctsm/toolchain/gen_mksurfdata_jobscript_multi.py to accommodate new fsurdat/landuse list
• input_pftdata_filename as per Logistical improvements to fsurdat/landuse files #2337

Removing checkboxes from rest of list because need to make this tag before generating new datasets:

• 5.4 branch tag to make all 5.4 datasets
• fsurdat/landuse files using make all
• default_data_1850.cfg which is used by the Makefile
• fsurdat/landuse files using make all-subset
• default_data_2000.cfg which is used for making NEON/PLUMBER fsurdat files
• NEON/PLUMBER fsurdat files
• namelist_defaults with the new (CTSM5.4) fsurdat/landuse files
• WhatsNewInCTSM5.4.md in For ctsm5.4: WhatsNewInCTSM5.4.md #3364
• files in /python/ctsm/test/testinputs if necessary

Specific notes

Contributors other than yourself, if any:
@ekluzek

CTSM Issues Fixed (include github issue #):
Fixes #1775
Fixes #2337
Fixes #2785
Fixes #3304
Fixes #3452
Addresses parts of #2851
Any other ctsm5.4-related or other issues?

Are answers expected to change (and if so in what way)?
Yes, because replacing fsurdat/landuse files.

Any User Interface Changes (namelist or namelist defaults changes)?
Update namelist_defaults with new fsurdat/landuse files.

Does this create a need to change or add documentation? Did you do so?
Update #3364 as needed.

Testing performed, if any:
None so far.

[slevis-lmwg]

Blocked by #3529 to be unblocked when @lawrencepj1 provides new ctsm54 lai raw dataset that includes pft 15 (as our codes expect).

UPDATE FROM MEETING WITH @ekluzek
We decided that this and #3501 can be merged. We will then put Peter's raw dataset updates (lai and noanthro) in a new PR. So far the lai is ready:
/glade/campaign/cesm/development/lmwg/clm6landusedatatoolsproduction/clm6timeseriesdata/clm6timeseriescmip7surfdata/CLM6_LUH3_HIST_CMIP7

[ekluzek]

@slevis-lmwg and I went over this and this is all great. One suggestion is to add a comment somewhere about the need to break up the ne3 historical into three separate jobs, because the low number of processors makes it take a long time.

And also we realized that the 1x1_brazil grids needed some changes. This wasn't quite right in the Grids document, so we corrected it there.

The bottom line with this is that want the datasets created to match the document.

[slevis-lmwg]

Ooops I got ahead of myself and put Peter's new lai and soilcolor files in this PR.
@ekluzek do you really feel I should bring them in with a separate PR?

[ekluzek]

I recommend separating the part that changes results for the surface datasets into a different PR. Otherwise it gets lost in the part that doesn't change answers, which is most of what this PR is about.

[ekluzek]

I suggest bringing this into the alpha branch and make a tag for it. You could rerun the testing, but as it doesn't touch model code, I'd just make sure the makefile works, and create a softlink to the previous baselines.

[slevis-lmwg]

@ekluzek I updated this PR to the latest tag in the alpha branch but ALSO to the latest tag in master (LMK if this does not make sense to you).

I started testing to confirm that I didn't mess anything up. This PR's tag will still be "12" since it only changes answers due to the changes in master. Again LMK if you disagree:

OK ./build-namelist_test.pl
PASS make black, make lint
PASS ./run_ctsm_py_tests
./run_sys_tests -s aux_clm -c alpha-ctsm5.4.CMIP7.12.ctsm5.3.075 -g alpha-ctsm5.4.CMIP7.12.ctsm5.3.079

[slevis-lmwg]

@ekluzek
I see the flaw in my logic to git merge ctsm5.3.079 to this branch:

• Now this PR is ahead of the alpha branch...
• Would you have me resolve this by opening another PR where I merge 079 to the alpha branch? Or would you not worry about it at this point?

[ekluzek]

@ekluzek I updated this PR to the latest tag in the alpha branch but ALSO to the latest tag in master (LMK if this does not make sense to you).

Yeah, this is something good to be on the same page about. Although since it's a branch it's not as important as on main branches. But, the ctsm5.4 branch is an important one, so probably good to sync up on.

I prefer having the "11" updated whenever there are changes along the branch even if they don't change answers. And I prefer doing a separate PR for a merge update, and not mixing it with other changes. Basically that means a few more tags, so the steps are more clearly defined and separable.

For a PR that is solely just a merge to a later ctsm tag, I'd leave the "11" alone, because it represents a change in the ctsm base version, and NOT on the branch. It's helpful to think of the "11" as the number of tags along the branch that don't change the base version, and the final ctsm tag part to be the ctsm tag it's based off of. So "11" shows there were 11 tagged sets of changes that diverge from master, and the difference in ctsm version from the last tag (ctsm5.3.075) from the first ctsm5.4 tag (ctsm5.3.40) shows the span of ctsm versions that the ctsm5.4 has gone through.

We do want to be on the same page about the naming convention for alpha tags. But, I don't want to dictate too much about how people handle their PR's. So we can do things slightly differently there, IMHO.