mksurfdata_esmf: Some surface dataset parameters should be mapped with weighting factors

[billsacks]

Brief summary of bug

Some surface dataset parameters only apply to certain landunits – or more finer-grained portions of the land surface. When these parameters are remapped from raw datasets in mksurfdata, a more accurate remapping would be to include a weighting fraction for each raw dataset grid cell that is the fraction of the grid cell over which that parameter applies.

This issue emerged from discussions about #1716 last week with @olyson @lawrencepj1 @slevisconsulting and others... I think one of them was the one to point this out, though I forget who initially raised this point. This issue pre-existed in the old mksurfdata_map and has been carried over to the new mksurfdata_esmf.

General bug information

CTSM version you are using: master

Does this bug cause significantly incorrect results in the model's science? Yes, potentially, for some parameters

Configurations affected: Potentially all

Details of bug

An example of a field where I think this weighting should be done is lake depth: Consider a destination (model) grid cell that is made up of two source (raw dataset) grid cells, each with equal area of overlap. One raw dataset grid cell has lake depth of 10 m and pctlake of 1%; the other has lake depth of 20 m and pctlake of 100%. The current remapping would result in a destination value of 15 m. But in reality, the second source cell should dominate the result, leading to a weighted average lake depth of almost 20 m.

@lawrencepj1 pointed out that some crop-related parameters have a similar issue; I think he mentioned fertilizer application as one example. In this case, the weighting should be done by the given crop's area.

I haven't looked through the list of surface dataset parameters to identify which ones should be changed and how. It's possible that this also impacts some data read from streams; I haven't looked into this.

[billsacks]

I see that PCT_NAT_PFT and PCT_CFT already accomplish this by multiplying these fields by PCT_NATVEG/100 or PCT_CROP/100 (respectively) before mapping them, then dividing by similar values after mapping.

[lawrencepj1]

Thanks Bill

The main fields that come to mind are those that deal with crop fertilizer and tree wood harvest. These may need to be thought of more logically to make them more conservative in remapping from the raw to the model grid.

Peter -- Dr Peter Lawrence Terrestrial Science Section National Center for Atmospheric Research 1850 Table Mesa Drive Boulder Colorado 80305

Work: 1-303-497-1727 Cell: 1-303-956-6932

On Fri, Nov 11, 2022 at 5:05 PM Bill Sacks @.***> wrote:

I see that PCT_NAT_PFT and PCT_CFT already accomplish this by multiplying these fields by PCT_NATVEG/100 or PCT_CROP/100 (respectively) before mapping them, then dividing by similar values after mapping.

— Reply to this email directly, view it on GitHub https://github.com/ESCOMP/CTSM/issues/1734#issuecomment-1312276301, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC3OJOPMUAYP3UDUYWZVSQTWH3NNRANCNFSM5U7URZVQ . You are receiving this because you were mentioned.Message ID: @.***>

[ekluzek]

I looked at this to confirm that this is a post ctsm5.2 activity and likely a post CESM3 activity as well. So I marked as low priority.

[ekluzek]

Not something we'll be able to do for ctsm5.3.0 so moving the milestone to post ctsm6.0.0