alpha-ctsm5.4.CMIP7.13.ctsm5.3.079: Prepare Makefile to make CTSM5.4 fsurdat/landuse datasets #3482

slevis-lmwg · 2025-09-10T22:16:51Z

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 alpha-ctsm5.4.CMIP7.20.ctsm5.3.085: 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.

Update the ctsm5.4 alpha branch to ctsm5.3.071 PR ESCOMP#3464

Fire update (PR ESCOMP#3204)

slevis-lmwg · 2025-09-10T23:47:47Z

Notes about resolving #2337

I'm working in this directory:
/glade/derecho/scratch/slevis/temp_work/ctsm5.4/mk_ctsm54_datasets/tools/mksurfdata_esmf

I uncommented preexisting code but got this compile-time error

There is no matching specific function for this generic function reference.   [PIO_PUT_VAR]
        rcode = pio_put_var(pioid, pio_varid, (/1,ntim/), (/len_trim(string),1/), trim(string))

Test FAILs (see below): I replaced the failing line with rcode = pio_put_var(pioid, pio_varid, trim(string))
If (2) fails, look at line 4772 in src/main/histFileMod.F90 for an alternative: Doesn't work currently because I need to know how to allow adding use ncdio_pio

ekluzek · 2025-09-11T15:38:48Z

Hmmm, @slevis-lmwg I'm concerned about that doing something different. I think the first line probably needs to use keyword syntax to be clear on what it's doing. That would improve the code readability anyway.

rcode = pio_put_var(ncid=pioid, varid=pio_varid, start=(/1,ntim/), count=(/len_trim(string),1/), ival=trim(string))

Although the above doesn't change the order that it is in PIO, so I don't see why it isn't finding the interface for it?

"string" is just a character of some length and NOT an array right?

The only thing happening with the top version is that it's outputting the string with the time dimension, for time slice ntim. And I'm not certain that the version you are trying will do that. There would need to be some other way to specify the time dimension.

slevis-lmwg · 2025-09-11T18:34:30Z

Hmmm, @slevis-lmwg I'm concerned about that doing something different.

You're correct, my modification in (2) above did this in my 1850-1855 test:

 time = 1850, 1851, 1852, 1853, 1854, 1855 ;

 input_pftdata_filename =
  "/glade/campaign/cesm/cesmdata/inputdata/lnd/clm2/rawdata/CTSM54RawData/globalctsm53histCMIP7Deg025_250417/mksrf_landuse_ctsm53_histCMIP7_1855.c250417.nc\000\020\000\000\f\020\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\030~\211dp\024\000\000\200\311M\215p\024\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\300o\206dp\024\000\000\000q\206dp\024",
  "\200|\211dp\024\000\000@\020\b\207p\024\000\000\000\000\000\000\320\017\000\000\b\000@\001",
  "",
  "",
  "",
  "" ;

I think the first line probably needs to use keyword syntax to be clear on what it's doing. That would improve the code readability anyway.

rcode = pio_put_var(ncid=pioid, varid=pio_varid, start=(/1,ntim/), count=(/len_trim(string),1/), ival=trim(string))

This gives the same compile-time error as (1) above.

Although the above doesn't change the order that it is in PIO, so I don't see why it isn't finding the interface for it?

"string" is just a character of some length and NOT an array right?

Correct.

The only thing happening with the top version is that it's outputting the string with the time dimension, for time slice ntim. And I'm not certain that the version you are trying will do that. There would need to be some other way to specify the time dimension.

If I'm interpreting correctly, maybe you mean replacing "string" with an array of all the string values?
Though as written, I think the code remains agnostic of the total number of years, so I'm trying something else for now.

slevis-lmwg · 2025-09-11T21:48:45Z

@ekluzek could this be the problem?
mksurfdata_esmf has its own copy of pio called mkpioMod.F90 and it may not include all the options available in /libraries/parallelio
I will need to familiarize myself with these to answer...

ekluzek · 2025-09-12T23:04:53Z

@ekluzek could this be the problem? mksurfdata_esmf has its own copy of pio called mkpioMod.F90 and it may not include all the options available in /libraries/parallelio I will need to familiarize myself with these to answer...

@slevis-lmwg the mkpioMod code are just some wrappers around PIO code. But, they all start with mkpio_ so it can't be that. So the problem here seems to be a more fundamental problem, it might be another argument that doesn't match the expected type correctly...

ekluzek · 2025-09-12T23:15:16Z

Ahhh, I have the interface that it should match here. Above I was using the C version and the variable names are different:

https://ncar.github.io/ParallelIO/group___p_i_o__put__var.html#ga1f74a108488e4d9c411fa411b3a805ad

So try it this way, without specifying the keyword for the first two arguments:

rcode = pio_put_var(pioid, pio_varid, start=(/1,ntim/), count=(/len_trim(string),1/), ival=trim(string))

Or for keyword syntax, use "File=pioid" and "varid=pio_varid". But, also we might need to have pio_varid as an integer instead of as a "var_desc_t" type.

Are you still struggling with this?

slevis-lmwg

@ekluzek

I'm reviewing my own PR to explain my changes so far.
make all finished successfully and the submitted jobs are pending in the queue. We will see how many work. We already know that ne3np4.pg2 will not find a mesh file.
Speaking of ne3np4.pg2, I had to make the following changes to ccs_config:

diff --git a/component_grids_nuopc.xml b/component_grids_nuopc.xml
index 879d073..5c25fa2 100644
--- a/component_grids_nuopc.xml
+++ b/component_grids_nuopc.xml
@@ -17,6 +17,11 @@
   <!-- ATM/LND meshes regional and global -->
   <!-- ======================================================== -->
 
+  <domain name="400pt_sparse">
+    <nx>13824</nx> <ny>1</ny>
+    <mesh>$DIN_LOC_ROOT/share/meshes/400pt_sparse_13824x1_mesh.nc</mesh>
+    <desc>400-point sparse grid mesh</desc>
+  </domain>
   <domain name="360x720cru">
     <nx>720</nx> <ny>360</ny>
     <mesh>$DIN_LOC_ROOT/share/meshes/360x720_120830_ESMFmesh_c20210507.nc</mesh>
@@ -98,6 +103,11 @@
     <mesh>$DIN_LOC_ROOT/share/meshes/ne3np4_ESMFmesh_c230714_cdf5.nc</mesh>
     <desc>ne3np4 is Spectral Elem 10-deg grid:</desc>
   </domain>
+  <domain name="ne3np4.pg2">
+    <nx>486</nx> <ny>1</ny>
+    <mesh>$DIN_LOC_ROOT/share/meshes/ne3pg2_ESMFmesh_c25xxxx_cdf5.nc</mesh>
+    <desc>ne3np4 is Spectral Elem 10-deg grid:</desc>
+  </domain>
   <domain name="ne3np4.pg3">
     <nx>486</nx> <ny>1</ny>
     <mesh>$DIN_LOC_ROOT/share/meshes/ne3pg3_ESMFmesh_c221214_cdf5.nc</mesh>
diff --git a/modelgrid_aliases_nuopc.xml b/modelgrid_aliases_nuopc.xml
index 6b380b6..eb211a2 100644
--- a/modelgrid_aliases_nuopc.xml
+++ b/modelgrid_aliases_nuopc.xml
@@ -154,6 +154,13 @@
     <mask>0.125nldas2</mask>
   </model_grid>
 
+  <model_grid alias="400pt_sparse" not_compset="_MOM" compset="DATM.+CLM">
+    <grid name="atm">400pt_sparse</grid>
+    <grid name="lnd">400pt_sparse</grid>
+    <grid name="ocnice">400pt_sparse</grid>
+    <mask>400pt_sparse</mask>
+  </model_grid>
+
   <model_grid alias="hcru_hcru_mt13" not_compset="_MOM" compset="DATM.+CLM">
     <grid name="atm">360x720cru</grid>
     <grid name="lnd">360x720cru</grid>

python/ctsm/toolchain/gen_mksurfdata_jobscript_multi.py

tools/mksurfdata_esmf/Makefile

400pt_sparse simulations just point to the f19_400pt_sparse mesh file and do not need their own unique fsurdat file

python/ctsm/toolchain/gen_mksurfdata_jobscript_multi.py

tools/mksurfdata_esmf/Makefile

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 · 2025-10-14T00:41:38Z

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 · 2025-10-14T01:25:25Z

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 · 2025-10-14T16:50:04Z

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.

…tsm54_datasets

Update submodules to match versions in cesm3_0_alpha07e (+ CMEPS)

slevis-lmwg · 2025-10-14T22:01:53Z

@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
OK ./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 · 2025-10-14T22:17:43Z

@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 · 2025-10-14T22:34:02Z

@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.

slevis-lmwg · 2025-10-14T23:03:47Z

Thanks @ekluzek. Based on your post (which makes sense to me), I will add a few steps:

Open PR alpha-ctsm5.4.CMIP7.12.ctsm5.3.079: Updating the alpha54 branch from ctsm5.3.075 to .079 #3554 to generate aux_clm baselines:
./run_sys_tests -s aux_clm -c alpha-ctsm5.4.CMIP7.13.ctsm5.3.079 -g alpha-ctsm5.4.CMIP7.12.ctsm5.3.079
OK derecho
OK izumi
Then I merge that to this PR (tag: alpha-ctsm5.4.CMIP7.13.ctsm5.3.079) which should not change code, since I prematurely merged 079 to this one.

Notes:

NOT DONE in this PR (no response, yet): If Adam confirms, change 1979-2030 to 1979-2023 to agree with the spreadsheet.
I also started branch new_raw_lai_and_soilcolor based on this PR's branch, to which I have reintroduced the corrected raw lai and corresponding soil color file. With that I submitted make all to generate replacement fsurdat/landuse files needed by Will, Cecile, and possibly others. BUT UPDATE: Peter L. provided new pft timeseries from 1700 as well, so rerunning make all. Peter L. also provided the NOANTHRO raw data, so update cmip_era accordingly and any relevant documentation in the code. See alpha-ctsm5.4.CMIP7.14.ctsm5.3.079: New raw lai, soilcolor, 1700-2023 landuse files, and NOANTHRO landuse file #3555.
Now ready to merge this PR.

The test seemed fixed in a short range of tags: ctsm5.3.063 to .072 and alpha-ctsm5.4.CMIP7.09.ctsm5.3.068 to .075

slevis-lmwg · 2025-10-17T20:59:17Z

This PR spanned more than one Sprint, and the time estimate in weeks represents my time spent in the current Sprint only.

slevis-lmwg added 3 commits September 9, 2025 16:50

Merge tag 'alpha-ctsm5.4.CMIP7.09.ctsm5.3.071' into make_ctsm54_datasets

1b214aa

Update the ctsm5.4 alpha branch to ctsm5.3.071 PR ESCOMP#3464

Update Makefile/_multi.py to accommodate new fsurdat/landuse needs

e69570a

Merge tag 'alpha-ctsm5.4.CMIP7.10.ctsm5.3.071' into make_ctsm54_datasets

4faa434

Fire update (PR ESCOMP#3204)

slevis-lmwg self-assigned this Sep 10, 2025

slevis-lmwg added this to CTSM: realease-ctsm5.4 minor version update (CMIP7 datasets) and LMWG: Sprint Planning Board Sep 10, 2025

github-project-automation bot moved this to Status not assigned in CTSM: realease-ctsm5.4 minor version update (CMIP7 datasets) Sep 10, 2025

github-project-automation bot moved this to Todo in LMWG: Sprint Planning Board Sep 10, 2025

slevis-lmwg moved this from Todo to In Progress in LMWG: Sprint Planning Board Sep 10, 2025

slevis-lmwg moved this from Status not assigned to Prioritized in CTSM: realease-ctsm5.4 minor version update (CMIP7 datasets) Sep 10, 2025

slevis-lmwg moved this from Prioritized to In progress in CTSM: realease-ctsm5.4 minor version update (CMIP7 datasets) Sep 10, 2025

slevis-lmwg linked an issue Sep 10, 2025 that may be closed by this pull request

ctsm5.4.000: Update to CMIP7 LULCC forcings #2851

Closed

62 tasks

slevis-lmwg mentioned this pull request Sep 4, 2025

ctsm5.4.000: Update to CMIP7 LULCC forcings #2851

Closed

62 tasks

slevis-lmwg added this to the ctsm5.4.0: CMIP7 Datasets milestone Sep 10, 2025

Update Makefile/_multi.py for fsurdat/landuse updates in ctsm54 (part 2)

0247d55

slevis-lmwg commented Sep 12, 2025

View reviewed changes

Rm unnecessary 400pt_sparse grid from gen_mksurfdata_jobscript_multi.py

ffede38

400pt_sparse simulations just point to the f19_400pt_sparse mesh file and do not need their own unique fsurdat file

slevis-lmwg changed the title ~~Make CTSM5.4 fsurdat/landuse datasets~~ Prepare Makefile to make CTSM5.4 fsurdat/landuse datasets Oct 10, 2025

slevis-lmwg commented Oct 10, 2025

View reviewed changes

python/ctsm/toolchain/gen_mksurfdata_jobscript_multi.py Show resolved Hide resolved

slevis-lmwg commented Oct 10, 2025

View reviewed changes

tools/mksurfdata_esmf/Makefile Show resolved Hide resolved

ekluzek approved these changes Oct 10, 2025

View reviewed changes

slevis-lmwg removed the blocked: answer changing Can't be resolved until we're ready for answer changes on master label Oct 10, 2025

slevis-lmwg moved this from Stalled to In Progress in LMWG: Sprint Planning Board Oct 10, 2025

slevis-lmwg added 3 commits October 13, 2025 18:01

Add comment explaining why I split hist-ne3 into three separate jobs

92dd6d5

Point to corrected raw lai file and correspondng soil color file

c3e1ca1

Added back 1x1_brazil_transient to the mksurfdata_esmf Makefile

5a09596

Revert c3e1ca1 "Point to corrected raw lai file and corresp. soil color"

2ea100a

slevis-lmwg added 2 commits October 14, 2025 15:43

Merge remote-tracking branch 'escomp/alpha-ctsm5.4.CMIP7' into make_c…

11235f4

…tsm54_datasets

Merge tag 'ctsm5.3.079' into make_ctsm54_datasets

21c9a87

Update submodules to match versions in cesm3_0_alpha07e (+ CMEPS)

Add test back to expected failures (issue ESCOMP#1733)

bbc9e40

The test seemed fixed in a short range of tags: ctsm5.3.063 to .072 and alpha-ctsm5.4.CMIP7.09.ctsm5.3.068 to .075

slevis-lmwg changed the title ~~Prepare Makefile to make CTSM5.4 fsurdat/landuse datasets~~ alpha-ctsm5.4.CMIP7.13.ctsm5.3.079: Prepare Makefile to make CTSM5.4 fsurdat/landuse datasets Oct 17, 2025

Merge branch 'alpha-ctsm5.4.CMIP7' into make_ctsm54_datasets

157d3ae

slevis-lmwg merged commit b9b9c73 into ESCOMP:alpha-ctsm5.4.CMIP7 Oct 17, 2025
6 checks passed

github-project-automation bot moved this from In Progress to Done in LMWG: Sprint Planning Board Oct 17, 2025

github-project-automation bot moved this from In progress to Done in CTSM: realease-ctsm5.4 minor version update (CMIP7 datasets) Oct 17, 2025

slevis-lmwg deleted the make_ctsm54_datasets branch October 17, 2025 20:56

slevis-lmwg added this to CTSM: Upcoming tags Oct 17, 2025

github-project-automation bot moved this to Ready to start (or start again) in CTSM: Upcoming tags Oct 17, 2025

slevis-lmwg moved this from Ready to start (or start again) to release/externals tags done in CTSM: Upcoming tags Oct 17, 2025

alpha-ctsm5.4.CMIP7.13.ctsm5.3.079: Prepare Makefile to make CTSM5.4 fsurdat/landuse datasets #3482

alpha-ctsm5.4.CMIP7.13.ctsm5.3.079: Prepare Makefile to make CTSM5.4 fsurdat/landuse datasets #3482

Uh oh!

Conversation

slevis-lmwg commented Sep 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description of changes

Specific notes

Uh oh!

slevis-lmwg commented Sep 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ekluzek commented Sep 11, 2025

Uh oh!

slevis-lmwg commented Sep 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

slevis-lmwg commented Sep 11, 2025

Uh oh!

ekluzek commented Sep 12, 2025

Uh oh!

ekluzek commented Sep 12, 2025

Uh oh!

slevis-lmwg left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ekluzek left a comment

Choose a reason for hiding this comment

Uh oh!

slevis-lmwg commented Oct 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ekluzek commented Oct 14, 2025

Uh oh!

ekluzek commented Oct 14, 2025

Uh oh!

slevis-lmwg commented Oct 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

slevis-lmwg commented Oct 14, 2025

Uh oh!

ekluzek commented Oct 14, 2025

Uh oh!

slevis-lmwg commented Oct 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

slevis-lmwg commented Oct 17, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

slevis-lmwg commented Sep 10, 2025 •

edited

Loading

slevis-lmwg commented Sep 10, 2025 •

edited

Loading

slevis-lmwg commented Sep 11, 2025 •

edited

Loading

slevis-lmwg commented Oct 14, 2025 •

edited

Loading

slevis-lmwg commented Oct 14, 2025 •

edited

Loading

slevis-lmwg commented Oct 14, 2025 •

edited

Loading