Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve mechanism for determining where to allocate memory for urban when running with dynamic urban #1661

Merged
merged 9 commits into from
Mar 8, 2022

Conversation

fang-bowen
Copy link
Contributor

@fang-bowen fang-bowen commented Feb 25, 2022

Description of changes

Implement a 'pct_urban_max' mechanism that reads 'PCT_URBAN_MAX' (maximum urban percentage throughout timeseries) from landuse.timeseries and initialize urban landunits only where urban ever exists in the transient run.

Specific notes

As discussed in #1572, in the previous dynamic urban settings, the mechanism for allocating memory for urban is to set run_zero_weight_urban to .true., which causes performance and memory issues.

This PR includes the following changes to address the issue:

  1. Add a subroutine surfrd_urbanmask to read 'PCT_URBAN_MAX' from landuse.timeseries, which indicates the maximum percentage of urban in the timeseries.

  2. Add a 'pct_urban_max' variable and a function 'urban_landunit_exists'. If urban exists or will grow in a grid cell, memory is allocated.

  3. Modify the urban logic in is_active_l. If memory is allocated for an urban column, then make it active.

Contributors other than yourself, if any:

@olyson. Also referenced #1109 ('haslake').

CTSM Issues Fixed (include github issue #): #1572

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

Any User Interface Changes (namelist or namelist defaults changes)?
No. For dynamic urban runs, user can leave 'run_zero_weight_urban' as .false. and supply landuse.timeseries file which includes PCT_URBAN_MAX (3 urban density types) and the model will only initialize urban landunits where urban exists or will grow.

Testing performed, if any:
Please see #1661 (comment) (Modified dynamic urban test; aux_clm testing).

fang-bowen and others added 4 commits December 14, 2021 05:55
Also updated variable name from HASURBAN to PCT_URBAN_MAX (ESCOMP#1572 (comment)).
1. Fixed urban density type index for conditional initialization.
2. Change internal variable name from hasurban to pct_urban_max for consistency.
@olyson
Copy link
Contributor

olyson commented Feb 25, 2022

Thanks Bowen!
A couple of other things;

  1. the dynamic urban test (ERS_Lm25.1x1_smallvilleIA.IHistClm50BgcCropQianRs.cheyenne_gnu.clm-smallville_dynurban_monthly) has been modified so that it uses PCT_URBAN_MAX (instead of HASURBAN). It also now sets one of the urban landunits to zero percent throughout the timeseries in order to test that the landunit is indeed not active throughout the simulation. The landuse timeseries file (/glade/p/cesm/cseg/inputdata/lnd/clm2/surfdata_map/landuse.timeseries_1x1_smallvilleIA_hist_78pfts_simyr1850-1855_dynUrban_c211206.nc) has been updated (/glade/p/cgd/tss/people/oleson/modify_surfdata/landuse.timeseries_1x1_smallvilleIA_hist_78pfts_simyr1850-1855_dynUrban_c220223.nc) and needs to be moved to inputdata.
  2. ran aux_clm testing, all pass and all bfb (expected as do_transient_urban is .false. by default).

@fang-bowen fang-bowen marked this pull request as ready for review February 26, 2022 16:50
@billsacks billsacks self-requested a review March 3, 2022 17:06
I also committed it to the inputdata repository
Copy link
Member

@billsacks billsacks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great - thanks a lot @fang-bowen and @olyson !

I pushed a small commit where I point to a new location for the landuse timeseries file in the smallville test: I have moved this to the inputdata repository.

See my one inline comment below, but I'll leave it up to you whether you want to change it or if you prefer to keep this more explicit code in subgridWeightsMod even if it means a bit of duplication.

Other than that, this is ready for final testing and integration.

Comment on lines 346 to 349
dens_index = lun%itype(l) - isturb_MIN + 1
if (run_zero_weight_urban .or. pct_urban_max(g,dens_index) > 0._r8) then
is_active_l = .true.
end if
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not positive, but I think this could safely be changed to just return .true. for all urban landunits, similarly to what is done for lakes: this would say, if we have bothered to allocate memory for an urban landunit for any reason, then we want to make it active. I'm pretty sure that's what is intended here. However, the current code seems fine, too, so I'll leave it up to you whether you want to change it. The main advantages of changing it would be (1) consistency with lake, and (2) future-proofing in case the logic in subgridMod for when to allocate urban changes (currently the logic here needs to be kept consistent with the logic there).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, originally we had it set to just return .true. for all urban landunits , but that didn't seem to work in terms of not running an urban landunit that had a zero-weight throughout the transient time series. I checked this with the test I created in which one of the urban landunits was set to zero throughout the timeseries. If we simply returned .true. for all urban landunits here then the landunit would still show up in the history files as active with zero-weight. Using the statement we have now, the landunit no longer shows up.
I'll test this again to make sure this operates as I say.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given the current logic, I'm wondering why such an urban landunit would be allocated in the first place: if it has zero-weight throughout the time series, shouldn't the logic in urban_landunit_exists lead it to not getting allocated?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, no, I think you are right. In both cases an ncdump of the h1 file gives:

data:
land1d_wtgcell = 1, 0, 0, 0 ;
land1d_ityplunit = 1, 2, 7, 8 ;
land1d_active = 1, _, 1, 1 ;

which is correct since the landuse.timeseries has zero percent urban for MD (land1d_ityplunit=9).

I agree that it would be good to be consistent, so I'll make the change you suggested.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, thanks for checking.

olyson added 3 commits March 3, 2022 12:47
 Allow user to replace vegetation in fsurdat files with any pft/cft using the
 fsurdat_modifier tool option dom_plant. This option replaces now obsolete
 option dom_nat_pft which handled pfts only and not cfts.
@olyson
Copy link
Contributor

olyson commented Mar 8, 2022

Testing on cheyenne and izumi have passed as expected.
Two expected failures on izumi:

FAIL SMS_D.f10_f10_mg37.I2000Clm51BgcCrop.izumi_pgi.clm-crop MODEL_BUILD time=1 (EXPECTED FAILURE)
FAIL SMS.f10_f10_mg37.I2000Clm50BgcCrop.izumi_pgi.clm-crop MODEL_BUILD time=1 (EXPECTED FAILURE)

Two expected failures on cheyenne due to changing the dynamic urban test:

FAIL ERS_Lm25.1x1_smallvilleIA.IHistClm50BgcCropQianRs.cheyenne_gnu.clm-smallville_dynurban_monthly NLCOMP
FAIL ERS_Lm25.1x1_smallvilleIA.IHistClm50BgcCropQianRs.cheyenne_gnu.clm-smallville_dynurban_monthly BASELINE ctsm5.1.dev082: DIFF

I've updated and committed the ChangeLog (please review).

@billsacks
Copy link
Member

Looks great, thanks a lot! I'm about to merge this. (I just made a couple minor tweaks to the ChangeLog and ChangeSum; one is that I have started putting "multiple" in the ChangeSum when I'm bringing in a tag that had substantial contributions from multiple people, as this one seems to.)

@billsacks billsacks merged commit bf958ac into ESCOMP:master Mar 8, 2022
@olyson
Copy link
Contributor

olyson commented Mar 8, 2022

Thanks for the tweaks, good catches.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done (non release/external)
Development

Successfully merging this pull request may close these issues.

3 participants