wwieder
commented
1 year ago A few questions based on the SE discussion today:
- merged GGCMI planting dates with CLM planting windows would generate spatial resolved variability for each CFT.
- Would GGCMI input data come in as streams or on surface data? @ekluzek suggested we use streams.
@samsrabin will schedule a meeting in the new year to discuss this in the scope of SE priorities for potential CTSM-ag work (AgSys?, pasture, others) with @dlawrenncar @danicalombardozzi and others who are interested.
samsrabin
One thing that's emerging from my analysis and writeup of #1863—e.g., my AGU poster—is that there are a few crops where using the GGCMI prescribed calendars makes a really big difference in global yield, mainly due to changes in growing season length. This is especially evident for sugarcane, cotton, and rice, depending on how "maturity" is defined (see #1914). For sugarcane and cotton, we see a huge performance improvement. For rice, it appears to cause decreased performance—a pretty big overestimation—but I would argue it's "wrong for the right reasons."
This has got me thinking about how the existing crop calendar system can learn from the GGCMI prescribed calendars without fully relying on them.
Tagging @danicalombardozzi for eventual discussion.
Ideas
Sowing dates
CLM default sowing is implemented as a set of hemisphere- and crop-specific sowing windows, within which planting occurs if and when some historical and/or current-season temperature criteria are met. These windows allow for some interannual variation in sowing date, as well as some long-term adaptation to warming temperatures. The GGCMI sowing data are just individual static dates, which of course allow for neither.
What I'm thinking is that CLM could use the GGCMI sowing date maps as the center of new sowing windows, with the sowing window radius being the same as it was before. (This would require some testing to ensure correct handling of sowing windows that cross into the new year.)
Harvest requirements
The simplest implementation of this would be to use the harvest requirement files generated using the GGCMI calendars over some baseline period, as I'm already doing.
One could also imagine some scaling of harvest requirements up or down according to recent climate—e.g., with 20-year mean annual temperature.
Mitigating immature harvests
Cotton and rice yields are really strongly affected by slight changes in how "maturity" is defined—i.e., how one chooses to include or exclude certain harvests as successful nonzero yields. (See my poster linked above.) An apparently okay performance for global rice yield under a strict 100% maturity threshold is only possible because huge parts of China never have a successful yield! They end up being harvested due to reaching maximum growing season length. Because relaxing the maturity threshold to 90% results in many more successful harvests (again, see poster), this implies that allowing a slightly longer growing season might do the same.
I propose that maximum growing season length (a global parameter) be set according to the maximum seen in the GGCMI static calendars plus, say, 10%.
At the same time, we want to avoid the possibility of crops "overwintering." Very long growing seasons might enable the eventual harvest of crops in regions where, in real life, farmers would have harvested after an extended cool period. To avoid this, we could force harvest if no growing degree-days were accumulated in the past, say, 14 days. (I'd want to talk with agronomists to better parameterize this.)
Winter wheat makes this discussion more complicated—would we want to avoid the possibility of "oversummering" instead? Certainly I would turn off the mechanism proposed above during the vernalization period.
Notes
Summary of ideas, ranked from easiest to hardest:
So far, I've only played with the static calendars from GGCMI. Sara Minoli has come up with an algorithm in an R package to generate time-varying calendars based on both temperature and precipitation, which I'm planning to use for the sowing date and harvest requirement files in the next phase of my work with Rutgers. That algorithm (or another one) could theoretically also be incorporated into CLM, which would avoid the possibility of sowing windows possibly becoming out of date far away from the present. The downside is that this still just generates an exact sowing date; we could use window to account for this-season conditions, but planting within that window would still just rely on temperature—not also precipitation—without some extra work.
There's also the question of whether we want to spend time on this if the current crop model will be supplanted anytime soon.