-
Notifications
You must be signed in to change notification settings - Fork 317
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
Conversation
…e as default. These datasets are documented in Oleson and Feddema, 2018, submitted to JAMES on 12/6/18.
There was a problem hiding this 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.
Is there an example I can follow? |
@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. |
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.... |
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. |
@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. |
Ok, I've initialized nlevurb to ispval and checked for invalid value before first use, which turns out to be in initVertical. |
@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
Given the planned discussion on CTSM5.2 datasets, I'm noting here that this particular PR was never completed. For CTSM5.2, the building temperature stream file described here should still be used. /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 |
Thanks for this update, @olyson. It looks like this issue is also on the CTSM5.2 project board, which is helpful! |
Thanks @slevisconsulting ! This is already showing up as closed. |
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.