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

Add new raw urban surface dataset and building temperature stream files #591

Merged
merged 4 commits into from
Sep 23, 2020

Conversation

olyson
Copy link
Contributor

@olyson olyson commented Dec 7, 2018

Add new raw urban surface dataset and building temperature stream files as default in CLM5.
These datasets are documented in Oleson and Feddema, 2018, submitted to JAMES on 12/6/18.
These changes can be moved from master to the release branch when allowable (when answer changing mods are approved for the release branch)

Description of changes

A new raw urban surface dataset is made available that should become the default for generating surface datasets at some point. This should be accompanied by the new building temperature streams file. The two files have been placed in the inputdata repository by Erik.
The raw urban dataset now has 10 layers for roofs/walls (currently 5 layers), this required changing the value of the nlevurb parameter in the mksurfdata source code and in the CLM5 code. Erik has suggested that this parameter could be read in directly from the dataset in the future.

Contributors other than yourself, if any: Johannes Feddema

CTSM Issues Fixed (include github issue #): None

Are answers expected to change (and if so in what way)? Yes, urban climate will change due to changes in building thermal, morphological, and radiative properties. This will affect gridcell average quantities for gridcells containing urban landunits (although urban fraction is small in most gridcells).

Any User Interface Changes (namelist or namelist defaults changes)? Yes, a new raw 0.05x0.05 urban dataset is provided for mksurfdata and a new building temperature streams file is provided.

Testing performed, if any:
The effects of these datasets are documented in Oleson and Feddema, 2018, submitted to JAMES on 12/6/18. Additionally, a 2 year 1deg CLM5 historical simulation using this branch was completed successfully.

…e as default.

These datasets are documented in Oleson and Feddema, 2018, submitted to JAMES on 12/6/18.
@olyson olyson added the PR status: ready PR: this is ready to merge in, with all tests satisfactory and reviews complete label Dec 7, 2018
@olyson olyson requested a review from ekluzek December 7, 2018 23:48
Copy link
Collaborator

@ekluzek ekluzek left a comment

Choose a reason for hiding this comment

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

@olyson this is of course simple, and mostly adding a new dataset, so there's not a lot to review. But, thinking about it, I think it is important to read the dimension size of nlevurb from the surface dataset. Doing this will allow us to use both old and new datasets, and is by nature a better practice than having hardcoded numbers.

So if you can take a stab, that would be great. Otherwise, I can help you, or do it when we bring this to master.

@ekluzek ekluzek added enhancement new capability or improved behavior of existing capability type: enhance - science and removed PR status: ready PR: this is ready to merge in, with all tests satisfactory and reviews complete labels Dec 11, 2018
@olyson
Copy link
Contributor Author

olyson commented Dec 11, 2018

Is there an example I can follow?

@ekluzek
Copy link
Collaborator

ekluzek commented Dec 11, 2018

@olyson. A good example is

surfrd_get_num_patches

which gets the number of PFT's, so pretty similar, although it looks like it might do more than you need for your purpose. But adding a surfrd_get_nlevurb to get it is mostly what you need. You then need to make sure it's set before it's used. So you probably want to initialize it to something you can recognize as unset, so it'll know to abort if it's used before being set.

@ekluzek
Copy link
Collaborator

ekluzek commented Dec 11, 2018

By the way, I think an important reason to do this, is so that we'll be able to use surface datasets used for CMIP6 simulations in CESM2.2 development, otherwise you wouldn't be able to do that out of the box. That's part of why I think this should be done, because I know people are going to want to use the same surface dataset used in CMIP6 for the latest CTSM. It's easier to just have it work, than have to explain to them what they have to do to have it work IMHO....

@olyson
Copy link
Contributor Author

olyson commented Dec 11, 2018

Following the surfrd_get_num_patches example, I've added a surfrd_get_nlevurb subroutine to surfrdMod.F90 and remove the hardcoded nlevurb in clm_varpar.F90.

I've done something similar in mksurfdata following the "density_class" example and am reading nlevurb in from the raw urban dataset, and removed the hardcoded nlevurb in mkvarpar.F90.

I'm not sure what is meant by setting and unsetting this. surfrd_get_nlevurb is called from clm_initialize immediately after surfrd_get_num_patches, which is called right after the land namelist is read in, and before even the land mask and grid is read in and decomposition is set. nlevurb is initialized using the values read in from the dataset using clm_varpar_init. I don't see any example of set/unset for surfrd_get_num_patches. But if you have a specific suggestion to do something different with surfrd_get_nlevurb, let me know.

@ekluzek
Copy link
Collaborator

ekluzek commented Dec 12, 2018

@olyson what I was thinking of was to set nlevurb to some value that would trigger a problem. For example, in mkurbpar...

public :: nlevurb = Inf

Then if it's used before being set it will cause problems and likely die. You can also check if it isn't set the first time you might encounter it (for example when data types are allocated. So in UrbanParamsType%Init you could

if ( nlevurb == Inf ) -- abort gracefully with an error...

This is all to make it easier to find problems later if things get moved around. There's often need to do that, but sometimes it's hard to figure out problems if you don't put these kind of things into place.

@olyson
Copy link
Contributor Author

olyson commented Dec 12, 2018

Ok, I've initialized nlevurb to ispval and checked for invalid value before first use, which turns out to be in initVertical.

@ekluzek
Copy link
Collaborator

ekluzek commented Jun 24, 2020

@olyson and I are going over this. I'm divide this into three things. One part is to update the urbantv stream file as a CTSM5_1 update. Another part we'll update the mksurfdata_map part of this (and the raw urban file). We also want to bring in @lawrencepj1 dataset updates for shifting-cultivation. The third part is to create new surface datasets and update all of them for CTSM5_1. So CTSM5_1 will have updated surface datasets that include the urban update as well as shifting cultivation.

Some bit-for-bit changes needed for the Perturbed Parameter Ensemble work

 Conflicts:
	bld/namelist_files/namelist_defaults_clm4_5_tools.xml
	bld/namelist_files/namelist_defaults_ctsm.xml
	src/main/clm_varpar.F90
	tools/mksurfdata_map/src/mkfileMod.F90
@olyson
Copy link
Contributor Author

olyson commented Sep 6, 2022

Given the planned discussion on CTSM5.2 datasets, I'm noting here that this particular PR was never completed.
The raw urban dataset and the building temperature stream file were never incorporated into the namelist files for use by mksurfdata_map and CLM (they were placed in inputdata however).
Similarly, the code that determined the dimension size of nlevurb from the surface dataset was never implemented. The lack of that code is what triggered #1252.

For CTSM5.2, the building temperature stream file described here should still be used.
However, a newer raw urban surface dataset has been developed from Gao and O'Neill (2021) and Gao and Pesaresi (2022).
If we are still using year 2000 for our raw "present-day" datasets, then the raw urban dataset that should be used is:

/glade/p/cgd/tss/people/oleson/Dynamic_Urban_Data/GaoOneil/Historical/GaoOneil_05deg_ThreeClass_2000_c20220416.nc

The full historical and SSP raw urban datasets can be found here:

/glade/p/cgd/tss/people/oleson/Dynamic_Urban_Data/GaoOneil/Historical
/glade/p/cgd/tss/people/oleson/Dynamic_Urban_Data/GaoOneil/SSP1
/glade/p/cgd/tss/people/oleson/Dynamic_Urban_Data/GaoOneil/SSP2
/glade/p/cgd/tss/people/oleson/Dynamic_Urban_Data/GaoOneil/SSP3
/glade/p/cgd/tss/people/oleson/Dynamic_Urban_Data/GaoOneil/SSP4
/glade/p/cgd/tss/people/oleson/Dynamic_Urban_Data/GaoOneil/SSP5

@wwieder
Copy link
Contributor

wwieder commented Sep 6, 2022

Thanks for this update, @olyson. It looks like this issue is also on the CTSM5.2 project board, which is helpful!

@slevis-lmwg
Copy link
Contributor

@olyson #1853 is now merged (in the ctsm5.2.mksurfdata branch).
Feel free to close this issue if appropriate.

@olyson
Copy link
Contributor Author

olyson commented Sep 28, 2022

Thanks @slevisconsulting ! This is already showing up as closed.

@samsrabin samsrabin added the science Enhancement to or bug impacting science label Aug 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement new capability or improved behavior of existing capability science Enhancement to or bug impacting science
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

6 participants