ctsm5.3.064: Add time dimension to *1d_wt* fields that change in transient simulations

[slevis-lmwg]

Description of changes

So far the title says it all.

Specific notes

Contributors other than yourself, if any:
@ekluzek @samsrabin

CTSM Issues Fixed (include github issue #):
Resolves #3307

Are answers expected to change (and if so in what way)?
pfts1d_* fields with time dimension will display different answers in transient simulations

Does this create a need to change or add documentation? Did you do so?
I did not

Testing performed, if any:
As a first test I ran this to confirm that the time dimension had been added to pfts1d_wtgcell:
PASS RXCROPMATURITYSKIPGEN_Ld1097.f10_f10_mg37.IHistClm60BgcCrop.derecho_intel.clm-cropMonthOutput

[slevis-lmwg]

So far I have changed only one variable (pfts1d_wtgcell) to see what people think. As mentioned above, this test passed /glade/derecho/scratch/slevis/RXCROPMATURITYSKIPGEN_Ld1097.f10_f10_mg37.IHistClm60BgcCrop.derecho_intel.clm-cropMonthOutput.20250710_171417_wskoks and it shows time as a second dimension in the changed variable.

@samsrabin @lawrencepj1 do you want to check whether the test's output indicates that the problem is resolved based on what you were seeing? Or is there a different test/simulation that you would rather I ran?

[samsrabin]

Yes, excellent! Here's how I tested:

cd /glade/derecho/scratch/slevis/RXCROPMATURITYSKIPGEN_Ld1097.f10_f10_mg37.IHistClm60BgcCrop.derecho_intel.clm-cropMonthOutput.20250710_171417_wskoks/run

# Concatenate the h2i files for 1851
ncrcat *clm2.h2i.1851-*.nc /glade/derecho/scratch/samrabin/test.nc

# Check that pfts1d_wtgcell has time axis
ncdump -h /glade/derecho/scratch/samrabin/test.nc | grep pfts1d_wtgcell

And the result:

	double pfts1d_wtgcell(time, pft) ;
		pfts1d_wtgcell:long_name = "pft weight relative to corresponding gridcell" ;
		pfts1d_wtgcell:_FillValue = 1.e+36 ;

greping for pfts1d_wtcol instead shows that it has no time axis after concatenation:

	double pfts1d_wtcol(pft) ;
		pfts1d_wtcol:long_name = "pft weight relative to corresponding column" ;
		pfts1d_wtcol:_FillValue = 1.e+36 ;

I did the same in Python (xarray) using the script at ~samrabin/pr_3328/test.py:

pfts1d_wtgcell dims: ('time', 'pft')
pfts1d_wtcol dims: ('pft',)

[samsrabin]

Note, though, that it's not just pfts1d fields.

• This fix should be applied to land1d and cols1d fields as well.

[slevis-lmwg]

@samsrabin thank you for confirming! I will proceed with the rest of the fields now. Same test as above IN PROGRESS.

[slevis-lmwg]

@samsrabin I have added "time" to all the fields that seem relevant, and RXCROPMATURITYSKIPGEN_Ld1097 generates history the way that I hoped, but then fails with
TypeError: is_this_vegtype(): this_vegtype must be a single string or integer, not a list of them. Did you mean to call is_each_vegtype() instead?
Are you able to look into it? Test located in /glade/derecho/scratch/slevis/tests_0711-191852de

[slevis-lmwg]

Though we have the RXCROP test failure to resolve, I'm submitting
./run_sys_tests -s aux_clm -c ctsm5.3.063 -g ctsm5.3.064_pr3328

• izumi IN PROGRESS
• derecho FAIL tests_0711-191852de
  RXCROPMATURITYSKIPGEN_Ld1097 as documented in previous post.

[slevis-lmwg]

Are you able to look into it? Test located here: /glade/derecho/scratch/slevis/RXCROPMATURITYSKIPGEN_Ld1097.f10_f10_mg37.IHistClm60BgcCrop.derecho_intel.clm-cropMonthOutput.20250711_125617_couqfj

@samsrabin I see major problems in other tests so far, so I will troubleshoot them first. I will let you know later if we still need to look at this one.

[slevis-lmwg]

@samsrabin I have now resolved aux_clm on derecho but I still get the RXCROP failure that I reported above...

[samsrabin]

Ok, will look into it.

[slevis-lmwg]

At standup today we decided to revert ityp variables as currently unchanging, even if in the future we may allow them to change.

[slevis-lmwg]

@ekluzek suggested three things:

• Compare file sizes before and after to see the effect of this PR's change:
• before 6.9M tests_0708-124045de/RXCROPMATURITYSKIPGEN_Ld1097.f10_f10_mg37.IHistClm60BgcCrop.derecho_intel.clm-cropMonthOutput.GC.0708-124045de_int/run/RXCROPMATURITYSKIPGEN_Ld1097.f10_f10_mg37.IHistClm60BgcCrop.derecho_intel.clm-cropMonthOutput.GC.0708-124045de_int.clm2.h1i.1851-01-01-00000.nc
• after 7.7M RXCROPMATURITYSKIPGEN_Ld1097.f10_f10_mg37.IHistClm60BgcCrop.derecho_intel.clm-cropMonthOutput.20250721_124302_toq03z/run/RXCROPMATURITYSKIPGEN_Ld1097.f10_f10_mg37.IHistClm60BgcCrop.derecho_intel.clm-cropMonthOutput.20250721_124302_toq03z.clm2.h1i.1851-01-01-00000.nc
• before 4.5M tests_0708-124045de/RXCROPMATURITYSKIPGEN_Ld1097.f10_f10_mg37.IHistClm60BgcCrop.derecho_intel.clm-cropMonthOutput.GC.0708-124045de_int/run/RXCROPMATURITYSKIPGEN_Ld1097.f10_f10_mg37.IHistClm60BgcCrop.derecho_intel.clm-cropMonthOutput.GC.0708-124045de_int.clm2.h2i.1851-12.nc
• after 4.5M tests_0711-191852de/RXCROPMATURITYSKIPGEN_Ld1097.f10_f10_mg37.IHistClm60BgcCrop.derecho_intel.clm-cropMonthOutput.GC.0711-191852de_int/run/RXCROPMATURITYSKIPGEN_Ld1097.f10_f10_mg37.IHistClm60BgcCrop.derecho_intel.clm-cropMonthOutput.GC.0711-191852de_int.clm2.h2i.1851-12.nc
• Add if-statements making the old default for non-transient and the new default for transient cases.
  Sam R. agreed at this morning's Stand-up with this and the next suggestion.
• Add a namelist control of this.

[samsrabin]

@slevis-lmwg The RXCROPMATURITYSKIPGEN_Ld1097.f10_f10_mg37.IHistClm60BgcCrop.derecho_intel.clm-cropMonthOutput*.clm2.h1i.1851-01-01-00000.nc files have annual timesteps, so they're a good test of how much the time axis affects things when compressibility is minimal. However, it would also be good to test the effects on files with sub-annual timesteps that are all within one calendar year.

[slevis-lmwg]

@samsrabin in the same test the sub-annual h2i files contain the variables of interest and, yet, they come back identical in size. Is this the effect of compression, as you brought up?

• before -rw-r--r-- 1 slevis cseg 4697736 Jul 8 14:44 RXCROPMATURITYSKIPGEN_Ld1097.f10_f10_mg37.IHistClm60BgcCrop.derecho_intel.clm-cropMonthOutput.GC.0708-124045de_int.clm2.h2i.1851-12.nc
• after -rw-r--r-- 1 slevis cseg 4697736 Jul 11 21:20 RXCROPMATURITYSKIPGEN_Ld1097.f10_f10_mg37.IHistClm60BgcCrop.derecho_intel.clm-cropMonthOutput.GC.0711-191852de_int.clm2.h2i.1851-12.nc

Makes me now wonder whether the increased size in annual files warrants the added code complexity of new if statements and a new namelist variable.

[samsrabin]

@slevis-lmwg I meant individual files that contain multiple sub-annual timesteps within them, not sub-annual files with single timesteps per file. I.e., files with hist_mfilt > 1 that have timesteps smaller than 1 year.

[slevis-lmwg]

Ok, trying those next.

./create_newcase --case ~slevis/cases_sp/i2000sp_f10 --res f10_g37 --compset I2000Clm60Sp --run-unsupported
Update user_nl_clm:

hist_dov2xy = .false.
hist_nhtfrq = 1
hist_mfilt = 48

We're looking at files for day 3 containing timestep-level output:
before

229M Jul 21 13:58 i2000sp_f10_ctsm53063.clm2.h0a.2000-01-03-01800.nc
774K Jul 21 13:58 i2000sp_f10_ctsm53063.clm2.h0i.2000-01-03-01800.nc

after

234M Jul 21 14:01 i2000sp_f10.clm2.h0a.2000-01-03-01800.nc
5.8M Jul 21 14:01 i2000sp_f10.clm2.h0i.2000-01-03-01800.nc

I think this shows that both the h0a and the h0i increased by about 5.0M per day (48 time-slices), so 0.1M/slice.
The h1i files that I compared earlier had 3 time-slices per file and differed by about 0.8M, so 0.267M/slice.

Repeating with the new if-statements in place, the I2000 now looks like "before" in the numbers, while a new IHist case looks similar to "after" except that IHist ends up with more landunits, columns, and pfts, so the IHist files are bigger regardless.

[slevis-lmwg]

./run_sys_tests -s aux_clm -c ctsm5.3.063 -g ctsm5.3.064_pr3328 on

• derecho IN PROG tests_0722-195117de
• izumi OK: tests_0722-125205iz but rerunning with latest commits tests_0722-163416iz IN PROG

---

• Update ChangeLog/Sum

[slevis-lmwg]

This PR is ready to merge to master if reviewers will approve
@ekluzek @samsrabin
I'm also open to comments/concerns of course.

[samsrabin]

Looks great! I just have one minor request on the ChangeLog. Approving preemptively.