search

ESCOMP / CTSM

Community Terrestrial Systems Model (includes the Community Land Model of CESM)
http://www.cesm.ucar.edu/models/cesm2.0/land/
Other
308 stars 312 forks source link

AgSys crop model integration: Couple time-varying min, max and critical C:N ratios #1702

Open billsacks opened 2 years ago

billsacks commented 2 years ago

The AgSys crop model allows for time-varying min, max and critical C:N ratios of each crop pool. It is not immediately apparent how to hook these time-varying C:N ratios into the current CTSM code, particularly code related to FlexibleCN and FUN: currently those modules use time-constant parameters defined on the parameter file for each PFT. Although it wouldn't be hard to change the code to use a time-varying value (I started to do so in https://github.com/billsacks/ctsm/commit/51241e8c3e5236ba0c0cb6adde78398ae4cd8dd2 but then reverted that commit), there are some scientific questions about how to do this correctly. Specifically, it seems like some parts of the code want a target C:N ratio for new growth, whereas other parts of the code want (for example) a target C:N ratio for all leaf growth to date, for comparison against the current actual C:N ratios of the leaves – e.g., this code in the FUN module: delta_CN = (leafc(p)+leafc_storage(p))/(leafn(p)+leafn_storage(p)) - leafcn(ivt(p)):

https://github.com/ESCOMP/CTSM/blob/449345ee9a534316cba0d6b4fd696b8d57e60428/src/biogeochem/CNFUNMod.F90#L1226-L1270

I'm not sure how to handle uses like that if target C:N ratios can change in time.

Our plan (from discussions with @danicalombardozzi and @pengbinpeluo) is to not try to couple the time-varying C:N ratios for now, but we will revisit this later.

wwieder commented 2 years ago

This makes sense. We can wrestle with how to merge with potential options that allow more flexible leaf stoichiometry as introduced by #1654

billsacks commented 2 years ago

@wwieder - Thanks for pointing me to @slevisconsulting 's PR – I hadn't followed that development and am just looking at it now – and seeing that it has a lot of overlap with what I started to do on a branch for AgSys but then backed out.

At first I was concerned that some of the possible scientific issues I stumbled over for AgSys could be problematic in #1654 , too - such as the issue I noted above for FUN, where it seems like the code expects the target leafcn to be constant in time (if I'm understanding the intent of the code correctly). However, I see that the purpose of #1654 appears to be to allow very gradually evolving C:N ratios, where the changes within a growing season would presumably be very small. This is in contrast to the AgSys changes where, even though conceptually we have the same need, the target C:N ratios can vary hugely within a season.

That is to say: I can see how the issues I struggled with for AgSys may not be problems in practice for #1654 with its intended use case.