"Easy wins" for crop calendars

[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:

1. Increasing maximum growing season lengths. (These are just global parameters in a netCDF file.)
2. Replacing harvest requirement algorithm with maps from the GGCMI-calendar-based analysis. Wouldn't really want to increase max growing season lengths without also doing this. (Would want to make sure I'm making surface files that can be properly interpolated to different resolutions.)
3. Centering sowing windows on GGCMI static sowing dates. (Mildly tricky to handle windows that span the new year.)
4. Preventing crops from "overwintering." (Technically simple but lots of work to determine an appropriate parameterization. Would need to talk to agronomists; likely would vary by crop type.)
5. Scaling harvest requirements based on recent climate. (Hard to empirically justify without a literature search, which might not end up yielding much.) (If there's not already a long-term climatic mean we can use: issues with restarts from old runs.)

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.

[wwieder]

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]

@danicalombardozzi, @wwieder, and I discussed ideas and formulated a plan of action for me this morning.

1. Center sowing windows on GGCMI values. Input dataset will be provided as a stream file.
2. Rework maturity requirement, starting with a simple lifting of the maximum to see how much sensitivity there is to that. If that looks promising, determine a realistic maximum value for each crop based on the literature. If it doesn't, consider just using the GGCMI-derived maps, scaled somehow with recent climate and limited based on realistic values.
3. Increase maximum growing season length, at least for crops where the existing values seem particularly unrealistic.
4. Reparameterize crops whose yield performance is worsened by all this, focusing first on phenology-related parameters.

That last step is important. Steps 1–3 will increase realism but, given existing parameters, may actually harm yield performance. It will be important to not get discouraged if things look worse before reparameterization!

In addition, at some point in/around 2 or 3, I should prevent crops from "overwintering." As a starting point, I will harvest crops if they haven't photosynthesized for some number of days (to be determined based on analysis of overwintering in outputs).

It'd be really nice to get rid of the behavior where a crop automatically enters the grain-filling phase upon reaching maximum LAI. That kludge may become less necessary as a result of the work described here. For that reason, I will add diagnostic outputs so we can know when this "boost" has happened.

CCing @dlawrenncar, who expressed interest in such improvements being made for CTSM6/CESM3.

[samsrabin]

Some updates on my plan here:

Step 1 (center sowing windows on GGCMI dates): Done, with capability added in #2193.

Step 2 (rework maturity requirement): Use the GGCMI-derived maturity requirement maps, but allow them to vary based on recent climate. This needs to happen before the June 30 capability freeze. I will break it up into a few substeps to keep the PRs at a size conducive to reviews:

1. Implement adaptation, with "recent climate" based on the same "warm period" currently used by default CLM. ([WIP] Allow prescribed gddmaturity to vary based on recent climate #2557)
2. Define "recent climate" based on the GGCMI growing seasons.
3. Restrict adapted gddmaturity values to a realistic range.

Since Steps 3 and 4 are calibration, these can take place after the June 30 capability freeze, but they need to be done before the answer-changing freeze. I've set the milestone for this issue accordingly.