New soiltex for ctsm5.2.mksurfdata #1732
Conversation
…/new_mksurfdata_soiltex
Resolved conflicts: tools/mksurfdata_esmf/README
|
@mvertens I'm adding the --hires_soitex option to the .py and .xml files, but I don't know this: |
@mvertens from this commit @ekluzek and everyone:
I decided to keep the prefix "mksrf_" because it's the only identifier that indicates a CTSM raw dataset. Without the prefix, the file could be anything, while with the prefix the file is clearly intended for use with the mksurfdata tool. |
|
I think these are good names, I only have a couple tweaks to suggest. You can take or leave as you see fit. I'm happy with above, I just wonder about a few things. Suggest capitalizing WISE since it's an org abbreviation |
@ekluzek thank you. Here are the file names that I ended up with based on your suggestions: One final tweak: |
|
./rimport complete on these three files. |
I followed the sand/clay template for organic and values look reasonable when written to stdout, but values are wrong in the .nc file. I have no explanation at this time.
| end do | ||
|
|
||
| ! TODO Rm organic before merging PR #1732 UNLESS we opt for OPTION 2 | ||
| ! organic_o OPTION 1: as we plan to calculate organic in the CTSM |
There was a problem hiding this comment.
As a test I calculated organic_o in two different ways...
- Option 1 as we discussed this morning: calculate organic in the CTSM from orgc_o, cfrag_o, and bulk_o (i.e. after the terms have been regridded).
- Option 2 (a few lines up where orgc_o is also calculated): In this case I regrid organic_i (calculated from orgc_i, cfrag_i, and bulk_i) to organic_o. This may be the more accurate approach. It goes against this morning's idea to keep ORGC the same in fsurdat as in the raw data, but it may be more accurate because it first calculates organic_i and then regrids to organic_o rather than regridding all the terms first and then calculating organic_o.
The fsurdat files from this test are in /glade/work/slevis/git/mksurfdata_toolchain/tools/mksurfdata_esmf:
surfdata_1.9x2.5_hist_78pfts_CMIP6_1850_c220527_OPT1.nc
surfdata_1.9x2.5_hist_78pfts_CMIP6_1850_c220527_OPT2.nc
surfdata_1.9x2.5_hist_78pfts_CMIP6_1850_c220527_OPT2-1.nc (the difference file)
Also, the old fsurdat that I'm comparing against:
/glade/p/cesmdata/inputdata/lnd/clm2/surfdata_map/release-clm5.0.18/surfdata_1.9x2.5_hist_78pfts_CMIP6_simyr1850_c190304.nc
I'm happy to follow up next week. Have a nice holiday weekend!
There was a problem hiding this comment.
Posting the difference in ORGANIC calculated by method 2 vs. 1.
Very little difference, I think because we regrid by most dominant rather than by averaging.
There was a problem hiding this comment.
When I get a chance, I'm curious to understand this small difference. Meanwhile though I've confirmed what should go without saying, i.e. that ORGC, CFRAG, BULK, PHAQ (and all other fields) are identical between these two fsurdats.
There was a problem hiding this comment.
Oh and old fsurdat shows max organic = 130 as we discussed:
|
This looks encouraging. In terms of trying to understand what the differences look like between the old fsurdat and the new data, perhaps you could plot with maximum value of 130, so we can see how the two datasets are similar/distinct. There are big difference, for example in the Canadian Archipelago and around Hudson Bay that I can see. No reason for me to think that the new data is wrong, though. I'd also be interested to see how this looks going down into the soil. That is, what do these datasets look like at 20cm, 50cm depth? |
New versus old layer 1, which goes to 1.75 cm:
Comparing at 16.6 cm Comparing at 28.9 cm Comparing at 49.3 cm To be precise
|
|
There are clear differences between datasets. Maybe the best way to understand the impacts would be to run simulations that compare permafrost extent, soil temperatures, and hydrology / runoff. |
…ltex_slevis Resolved conflicts: tools/mksurfdata_esmf/README tools/mksurfdata_esmf/gen_mksurfdata_namelist.py tools/mksurfdata_esmf/gen_mksurfdata_namelist.xml
|
At our 2022/9/8 meeting we agreed on a year-2000 1-degree SP simulation with all the new raw datasets. To generate the fsurdat file for this simulation with the new mksurfdata_esmf:
I have to |
Discussion pending regarding the consistency between PCT_LAKE in the new 2017 lakedepth file used for year-2000 simulations versus in the new transient lake files.
This string should have gone in with ESCOMP#1853, but I missed it, so the latest ctsm5.2.mksurfdata branch tag will not work as is right now. The correction will come in with the next tag.
rimport pending for mksrf_landuse files. Of those, there are: - "final" ones for 1850-2015 that I don't have permission to link to - older ones for other periods that I will check with @lawrencepj1 whether we expect to replace
|
As I have now run simulations with fsurdat files coming out of this branch, and we will likely run more, Once I do that, @ekluzek will merge the latest ctsm tag to the ctsm5.2.mksurfdata branch and make a tag. |
|
But first... |
Keeping the second option commented out for now, rather than deleting
| @@ -1,7 +1,7 @@ | |||
| do_transient_lakes = .true. | |||
|
|
|||
| ! This file was created with the following command: | |||
| ! ncap2 -s 'PCT_LAKE=array(0.0,0.0,PCT_CROP); PCT_LAKE={0.,50.,25.,25.,25.,25.}; HASLAKE=array(1.,1.,AREA); PCT_CROP=array(0.0,0.0,PCT_LAKE); PCT_CROP={0.,25.,12.,12.,12.,12.}' landuse.timeseries_1x1_smallvilleIA_hist_78pfts_simyr1850-1855_c160127.nc landuse.timeseries_1x1_smallvilleIA_hist_78pfts_simyr1850-1855_dynLakes_c200928.nc | |||
| ! ncap2 -s 'PCT_LAKE=array(0.0,0.0,PCT_CROP); PCT_LAKE={0.,50.,25.,25.,25.,25.}; PCT_LAKE_MAX=array(1.,1.,AREA); PCT_CROP=array(0.0,0.0,PCT_LAKE); PCT_CROP={0.,25.,12.,12.,12.,12.}' landuse.timeseries_1x1_smallvilleIA_hist_78pfts_simyr1850-1855_c160127.nc landuse.timeseries_1x1_smallvilleIA_hist_78pfts_simyr1850-1855_dynLakes_c200928.nc | |||
There was a problem hiding this comment.
@billsacks this is the only change in this commit where I didn't feel confident. Could you confirm? Other than the variable name, would you have also changed the array values for the purposes of this test?
There was a problem hiding this comment.
Technically this should be changed so that the value is 50 (the max value of the PCT_LAKE array) rather than 1. I think that could be done by changing array(1.,1.,AREA) to array(50.,0.,AREA) (I think the second value is irrelevant here). However, it shouldn't matter in practice, because a value of 1 will do the same thing as a value of 50 where this is read... it may just cause a bit of confusion. Thanks for taking care of this!
There was a problem hiding this comment.
Thanks, @billsacks
I will take care of this later since I merged this branch earlier today.
Probably in a PR that will address #1703
Do not expect answers to change as stated here: ESCOMP#1732 (comment)
Description of changes
Started from @mvertens branch feature/new_mksurfdata_soiltex
Pushed a few updates directly to that branch:
From there I started my branch new_soiltex_slevis and opened this PR.
This PR continues @mvertens and @wwieder 's work to replace the old soil texture and organic raw datasets with new.
Specific notes
Contributors other than yourself, if any:
@mvertens @wwieder @dlawrenncar @ekluzek
CTSM Issues Fixed (include github issue #):
Resolves #1303
Are answers expected to change (and if so in what way)?
Yes because new rawdata.
Any User Interface Changes (namelist or namelist defaults changes)?
New soil raw dataset consists of two files: a mapunits file and a lookup file.
Testing performed, if any:
@olyson posted diagnostics from running with the new and the old here and no red flags were raised.