Scaling prescribed crop maturity requirements based on recent climate

[samsrabin]

Posting here to get some feedback before I start working on this. @billsacks @slevis-lmwg @danicalombardozzi especially, if any of y'all have any thoughts on this they'd be much appreciated!

I'm currently leaning toward the "Using the mean GDD accumulation during the GGCMI growing season" method, but I'm interested to hear if there are any downsides/dangers I may not be considering.

---

We're hoping to incorporate some "easy wins" for crop calendars in CLM6; see #1928. One aspect: We want to use more realistic maturity requirements as the basis for CLM6 crop maturity requirements. The idea is to base them on the maps generated in the prescribed crop calendars paper, which were derived from sowing and harvest date maps used in the Global Gridded Crop Model Intercomparison (GGCMI). However, we want to scale them based on "recent" climate.

There are two ways this could be accomplished.

Using the "GDD20" running mean variables that CLM is already generating

Namely:

• GDD020
• GDD820
• GDD1020

In the middle of hemispherical winter (say, Jan. 1 in NH and July 1 in SH), each gridcell will calculate the maturity requirement to be used in the following warm season ($GDD_{mat}$) like so:

$$ GDD_{mat} = \frac{GDD20_{T}}{GDD20_{T, baseline}} \times GDD_{mat, GGCMI} $$

where:

• $GDD20_{T}$ is the current value of the relevant GDD20 running mean ($T \in {0, 8, 10 }$ based on CFT; see below),
• $GDD20_{T, baseline}$ is the 1980-2009 (GGCMI period) baseline, and
• $GDD_{mat, GGCMI}$ is the maturity requirement generated over 1980-2009 using the GGCMI sowing and harvesting dates.

My plan is to run CLM at half-degree resolution (to match the resolution of the GGCMI crop calendars), outputting the GDD20 variables on an annual basis for each year in 1980-2009. I will then take the average of those 30 years for each GDD20 variable. These will serve as maps in three new input variables gdd*20_baseline. Each CFT will use the gdd*20_baseline variable (0, 8, or 10) based on which matters for the crop in the CLM5 GDD calculation.

Misc. notes:

• The GDD20 values are accumulated during some annual "warm period" (April through September in NH, October through March in SH) (search code for ( month > 3 .and. month < 10 .and. grc%latdeg(g) >= 0._r8)
• The GDD20 output variables are saved as averages at the end of each calendar year, not instantaneously in midwinter. There will thus be some mismatch between what each gridcell-CFT sees in the midwinter GDDmat calculation vs. what I'm using to generate the baselines. I don't think it will matter much, though, since I'm taking an average over 30 years of outputs.
• Doing the GDDmat calculation in the middle of hemispherical winter ensures that active crops won't get their GDDmats changed. No it doesn't. I'll need to make sure that the newly-calculated GDDmat value is only applied during new calls of PlantCrop(), and that existing crops in the ground aren't affected.
• I guess that means I could do the calculation on Jan. 1 even in the southern hemisphere. There, it would mean the update includes the end of the previous warm season and the beginning of the current one—but again, it's going into a 20-year average, so it probably doesn't matter much.

Using the mean GDD accumulation during the GGCMI growing season

GGCMI provides maps of mean sowing and harvest dates, so I could have CLM read those in, then accumulate the GDD20 variables between those dates (rather than during the "warm period"). This is the more directly relevant option, since the trend in temperature during the "warm period" isn't guaranteed to match the trend in temperature in the actual growing season.

Other than that, it would work more or less the same as outlined in the section above. Some wrinkles specific to this method:

• Would these fully replace the existing GDD20 variables for all uses? In addition to their use in calculating maturity requirement, GDD020 is used to test whether winter cereals can be sown, and GDD820 is used similarly for other crops. I think it makes sense to use the GGCMI-period-derived values for those uses as well.
• For the short term, at least, I'd want to enable users to choose whether they want the "warm period" or "GGCMI period" method for both "can this be sown" and maturity requirement calculations. This will enable backward compatibility.
• If replacing the existing GDD20 variables, I would probably want to "flush" the existing values with an extra 20+ years of "spinup" before 1850. This is because, in some gridcells, the GGCMI growing season will be very different from the "warm period." (This won't be necessary once spinup uses the GGCMI growing season.)
• I would probably just update the 20-year means on Jan. 1, rather than sticking with the "midwinter" timing or doing something more complicated like "the day after the end of the GGCMI growing season."

Misc. notes

How to handle restarts from different years? Unfortunately, since I'll be using a new GDD20 running mean calculation relative to the calculation used in all the existing restarts, the year I choose to start my runs will affect the baseline value I calculate. Similarly, if someone starts their run at a different year than what I used to generate my baselines, they'll get different GDDmat values. This is "only" a problem (to the extent that anyone cares) until all restarts use my new running mean.

• Relatedly, if someone uses a different climate than what I used to generate my baselines, they'll get different GDDmat values. But that's true with the existing system as well.
• I could get around this in a brute-force way by setting initializing the accumulator values based on read-in files that reflect the "correct" value for each possible restart year. But that's ridiculous. And what, assume people are only restarting at midnight on Jan. 1? You're not gonna do every timestep.

Warmth isn't everything. Ideally, CLM would dynamically simulate how crops in some places are planted based on seasonal warmth and in other places they're planted based on seasonal water availability. We're not there yet at this point; the goal of the "easy wins" is to implement changes within the existing setup, which only considers warmth.

[billsacks]

Sorry, @samsrabin - I started trying to read through this but it felt hard to get my head into it enough that I'd be able to give you any meaningful feedback. I do want to be able to support you with this, but I think it would be easier for me if we sat down and talked through anything that you want feedback on.

[slevis-lmwg]

I feel similarly. I'm happy to meet with both of you or separately.