L11_Improvements to crop model Design Document
The Design Document page provides a description of the algorithms, implementation and planned testing including unit, verification, validation and performance testing. Please read Step 1.3 Performance Expectations that explains feature documentation requirements from the performance group point of view.
Design Document
In the table below 4.Equ means Equations and Algorithms, 5.Ver means Verification, 6.Perf - Performance, 7. Val - Validation, - competed, - in progress, - not done
Title: Improvements to crop model
Requirements and Design
ACME Land Group
Date:
Summary
The ALM crop model has a relatively simple representation of some key processes. For example, although crops are harvested at maturity, the grain component is handled as litter and placed in the corresponding litter pools. This alters the biogeochemistry cycle by depositing carbon and nitrogen in the soil that would otherwise be consumed. A crop harvest subroutine is added to put crop grain into an external product pool that is respired to the atmosphere rather than into a litter pool.
The current root distribution in CLM4.5 is an exponential profile with the root fraction in each soil layer based on Jackson et al (1996) and Zeng (2001). However, this neglects the rapid change in the root structure of crops over the growing season. In fact, this is the case with all vegetation in ALM. This representation does not allow for proper plant response to heterogeneity of water and nutrients in the soil column. In order to modify the root system, a dynamic root module is created that will allow roots to grow deeper over the growing season while the root fraction in each soil layer of all PFTs is allowed to respond to water and nutrient availability.
Finally, crop plant date is determined from soil temperature thresholds, thereby restricting crops to the mid-latitudes since additional factors determine planting date in tropical regions. A new subroutine to allow fixed planting dates using observational data is added.
Requirements
Requirement: Add harvest subroutine and product pool
Date last modified:
Contributors: Beth Drewniak
This subroutine requires three components: 1) yield calculator, 2) creation of a product pool with 1-yr turnover, treatment of grain carbon and nitrogen at harvest by diverting to the product pool. The yield is calculated in bu/acre and t/ha. The harvest also allows the optional harvest of residue (leaves and stems), which will go into the same product pool with grain. The product pool respires to the atmosphere over a 1-year period. In addition to the code modifications, three additional parameters are added to the parameter file including: proportion of residue harvested with grain, fraction of grain that is harvested, and a conversion factor from gC/m2 to bu/acre.
Requirements
Requirement: Add dynamic root subroutine
Date last modified:
Contributors: Beth Drewniak
There are two components: root depth and root distribution (i.e., fraction of roots in each soil layer). Crop root depth is initialized at the bottom of the second soil layer (~ 4 cm). Root depth increases linearly with growing degree days over the growing cycle and reaches maximum depth at the beginning of the grain fill stage. Maximum rooting depth for crops varies with crop type: 120 cm, 160 cm, and 90 cm for corn, soybean, and wheat respectively. Natural vegetation is assumed to be mature and therefore maintains the standard maximum depth located at the base of the soil layer (3.8 m). The work proposed here is designed to optimize root distribution for both water and nitrogen uptake, but with a priority given to plant water demands. This allows plasticity of roots under non-uniform profiles of water and nitrogen, influencing the plant extractable resources and therefore the above ground vegetation dynamics.
Requirements
Requirement: Add fixed planting date option
Date last modified:
Contributors: Beth Drewniak
In order to include crops outside of the mid-latitudes, options to allow fixed plant date will be added with data from Sacks et al. (2010). Other sources of plant date information may come from the GEOGLAM crop calenders or AGMIP community. This task requires additional user options for selecting which planting date source to use as well as adding surface datasets that include planting date information.
Algorithmic Formulations
Design solution: New subroutines, input and output data are required to implement improvements to crop model
Date last modified:
Contributors: Beth Drewniak
Crop harvest and yield calculator:
1) Calculate grain yield (bu/acre; adapted from Agro-IBIS):
Yield (bu/acre) = grainc fyield * convfact / cgrain *1000
Yield (dm/ha) = grainc * fyield * 0.01 / cgrain
grainc = grain carbon (g/m2)
fyield = adjustment factor for portion of grain that is actually harvested
convfact = conversion to get from g/m2 to bu/acre
cgrain = amount of carbon in grain (0.45)
2) harvested crop to product pool (similar with nitrogen)
hrv_to_prod1c = presharv * leafc + presharv * livestemc + grainc
presharv = proportion of residue harvested
leafc = leaf carbon
livestemc = stem carbon
3) product pool loss (smiler with nitrogen):
prod1c_loss_col(c) = prod1c_col(c) * kprod1
prod1c_col = column level crop carbon product pool
kprod1 = (1/s) rate constants result in ~90% loss of initial state over 1 year, using a discrete-time fractional decay algorithm
Dynamic Roots:
1) Root depth for crops is:
root_depth = max(zi(2), min(hui / huigrain * root_dmx), root_dmx)
zi(2) = depth at bottom of 2nd soil layer
hui = GDD required to reach maturity
huigrain = GDD required to reach grain fill stage
root_dmx = maximum rooting depth (m, to be defined per PFT in param file)
2) The new rooting profile is updated with new carbon inputs to the roots (Drewniak et al., (2013)). New fine root carbon, C in each soil layer i is calculated each time step as:
Ci = Ci,o + ri,t * Cnew - ri,t-1 * Closs
where ri,t is new root fraction in each soil layer at time t:
ri,t = (1 - f) * rw,i + frn,i
f = fraction of available water in the rooting zone
rw,i = relative available soil water in soil layer i
rn,i = relative available soil mineral nitrogen in layer i
Fixed planting date:
No new algorithms required, only changes to surface dataset.
Design and Implementation
Implementation: Integrate code mods into ALM
Date last modified:
Contributors: Beth Drewniak
The initial code development has been integrated and tested in previous versions of CLM; updates to the code from the addition of new model components are being integrated into ACME as described by above Algorithmic Formulations.
Planned Verification and Unit Testing
Verification and Unit Testing: short-desciption-of-testing-here
Date last modified:
Contributors: Beth Drewniak
Two of the three requirements will only affect the crop model, while the third will affect all vegetation. Comparison between model versions with and without the modifications will determine the impact on crop yield and productivity. An examination of the root fraction and depth will determine the behavior or roots. Long term runs will be performed for the root module to ensure the root behavior on long time scales is consistent with observations (see validation testing).
Planned Validation Testing
Validation Testing: model benchmarking
Date last modified:
Contributors: Beth Drewniak
The root model will be tested against observational datasets of Jackson et al., 1996 and Schenk and Jackson 2002. Long term runs will determine the root behavior to ensure results are still within observational ranges. The crop harvest and planting date should have minimum impact on the crop model. Comparisons with observations of yield will determine the impact of these improvements, particularly against the GEOGLAM crop monitoring network. Crop model can also be run in point mode for validation at sites with flux data. These sites can be used for parameter calibration purposes and validation.
Planned Performance Testing
Performance Testing: short-desciption-of-testing-here
Date last modified:
Contributors: (add your name to this list if it does not appear)
All code modifications should have minimum impact on model performance. Timing logs from above verification tests can monitor the the impact from additional input and output requirements which should be negligible.