This is connected with #1555 (and I realized this issue while investigating the mksurfdata_map code related to #1555 ) but this is a somewhat separate issue.
Currently, my understanding is that the PCT_PFT raw datasets are constructed so that the total landunit area of natural veg plus crop adds up to 100%: in source grid cells where the original data specify less than 100% cover of vegetation, PCT_PFT values are increased so that the raw data coming in to mksurfdata_map will specify 100% cover of PCT_NATVEG + PCT_CROP.
But as far as I can tell from an initial read through of mksurfdata_map, there is no reason why this needs to be the case, and I realized that there is a problem with this: In this call:
|
call gridmap_areaave_scs(tgridmap, pct_nat_pft_i(:,m), & |
|
pct_nat_pft_o(:,m), nodata=0._r8, & |
|
src_wt=pctnatveg_i*0.01_r8*tdomain%mask, & |
|
dst_wt=pctnatveg_o*0.01_r8, frac_dst=frac_dst) |
I'm pretty sure that the source (and dest) weighting imply that PCT_NATVEG (i.e., the landunit area) is used as a weighting factor in remapping PCT_NAT_PFT from source to dest. That seems like the right thing to do, but the correction of the raw datasets to force vegetated areas to 100% makes this weighting factor not work the way it should.
Consider a destination grid cell that has two source grid cells, with equal coverage:
- Source 1: truly 100% natural veg, with 100% c3 grass
- Source 2: truly 1% natural veg, 99% lake, where the natural veg portion is 100% bare ground
The correct result would be a grid cell with 50.5% natural veg, 49.5% lake, where the natural veg is almost entirely c3 grass (with just a tiny bit of bare ground). However, because the PCT_PFT raw dataset is adjusted to give 100% area in Source 2, the current result in the code would be 50% c3 grass and 50% bare ground.
To get correct PCT_NAT_PFT mappings, I believe the raw datasets should be constructed without forcing the total veg area to add to 100%.
See the bold note at the bottom of #1555 (comment) for something to check in the course of doing this. I believe it's safe to make the changes in this issue before or after #1555, though if I had to choose an order, I would do #1555 before updating the raw datasets, because there are less likely to be issues with assuming that PCT_NATVEG + PCT_CROP = 100% once we do #1555.
Edit: here is the bold note that I was referring to, just so it's all in one place:
When making these changes, we should double-check that there isn't any code that assumes that PCT_NATVEG + PCT_CROP adds up to 100% (or forces that to be the case). I didn't see anything like this in my initial, quick read-through, but we should double-check that. One specific thing to look for is: will code work correctly if the input PCT_NATVEG = PCT_CROP = 0%? (Or would such grid cells incorrectly be considered ocean, for example?)
This is connected with #1555 (and I realized this issue while investigating the mksurfdata_map code related to #1555 ) but this is a somewhat separate issue.
Currently, my understanding is that the PCT_PFT raw datasets are constructed so that the total landunit area of natural veg plus crop adds up to 100%: in source grid cells where the original data specify less than 100% cover of vegetation, PCT_PFT values are increased so that the raw data coming in to mksurfdata_map will specify 100% cover of PCT_NATVEG + PCT_CROP.
But as far as I can tell from an initial read through of mksurfdata_map, there is no reason why this needs to be the case, and I realized that there is a problem with this: In this call:
CTSM/tools/mksurfdata_map/src/mkpftMod.F90
Lines 561 to 564 in 7a85024
I'm pretty sure that the source (and dest) weighting imply that PCT_NATVEG (i.e., the landunit area) is used as a weighting factor in remapping PCT_NAT_PFT from source to dest. That seems like the right thing to do, but the correction of the raw datasets to force vegetated areas to 100% makes this weighting factor not work the way it should.
Consider a destination grid cell that has two source grid cells, with equal coverage:
The correct result would be a grid cell with 50.5% natural veg, 49.5% lake, where the natural veg is almost entirely c3 grass (with just a tiny bit of bare ground). However, because the PCT_PFT raw dataset is adjusted to give 100% area in Source 2, the current result in the code would be 50% c3 grass and 50% bare ground.
To get correct PCT_NAT_PFT mappings, I believe the raw datasets should be constructed without forcing the total veg area to add to 100%.
See the bold note at the bottom of #1555 (comment) for something to check in the course of doing this. I believe it's safe to make the changes in this issue before or after #1555, though if I had to choose an order, I would do #1555 before updating the raw datasets, because there are less likely to be issues with assuming that PCT_NATVEG + PCT_CROP = 100% once we do #1555.
Edit: here is the bold note that I was referring to, just so it's all in one place:
When making these changes, we should double-check that there isn't any code that assumes that PCT_NATVEG + PCT_CROP adds up to 100% (or forces that to be the case). I didn't see anything like this in my initial, quick read-through, but we should double-check that. One specific thing to look for is: will code work correctly if the input PCT_NATVEG = PCT_CROP = 0%? (Or would such grid cells incorrectly be considered ocean, for example?)