Figure out how to divide winter and spring wheat

[billsacks]

We need a way to figure out how to divide winter and spring wheat in our surface datasets. The datasets label all wheat the same, so we've just called it spring wheat. But, since the two act very differently we need a way to distinguish locations with winter wheat as opposed to spring.

[wwieder]

How is this different than #264?

[billsacks]

I'm not sure I remember all the details, but I think #264 is about getting new code / parameters in to be able to model winter wheat assuming we know where it is grown (which has been done by Yaqoing), and this issue #269 is about figuring out how to separate winter from spring wheat on the surface dataset (which I think is still an outstanding project).

[ekluzek]

Yes, that's correct. This one is more centered on datasets especially the surface dataset. The other one is about the updated code.

[ekluzek]

@samsrabin has been doing some work with Jyoti Singh from Rutgers on this. Jyoti has results in CLM50 that look promising.

[samsrabin]

Tagging @jyoti1singh, @lawrencepj1, @danicalombardozzi

Generally, the IAMs making the SSP scenarios generate area maps over time of 5 different broad crop types (C3/C4 * annual/perennial, C3 N-fixing). Peter then does some magic with other databases to decompose those into our crop functional types. I don’t know exactly what’s involved there, but winter crops probably can’t follow similar rules—their phenology is just too different from spring crops.

There’s always the option of brute-forcing it, a la Qiao et al. (2023). Before doing an actual run with some climate input, we do a dummy run with that same input and slightly modified crop distribution. The modification is to include at least a tiny bit of spring and winter wheat in every gridcell, ensuring they get the same fertilizer. After the dummy run, we choose spring vs. winter for each year based on which would result in the highest yield. The result of this dummy runs would be put into a new file that's like the surface dataset but separate, which would avoid the need to make a different surface dataset for every climate input. Although I guess the results from the dummy run would depend on the surface / land-use timeseries datasets... This is probably not a good idea, because it'd make it too hard for winter wheat to be enabled in default runs.

Some insights might be derived from Iizumi et al. (2018)—at the very least, it can provide an idea of how to exclude gridcells from consideration of winter wheat because they’re too warm.

LPJ-GUESS does endogenously choose between winter and spring wheat, so a deep dive into that could be useful too. However, I’ve started on such a deep dive and it’s really complicated. I can look more into it if we want.

There may be other papers or gray literature describing how other models do this, but I'm not sure they do: LPJ-GUESS may well be the only one that endogenously chooses between winter and spring wheat. If that's the case (or it's really rare), I wonder if it would be acceptable to just use a present-day winter/spring mask for all time steps. Is that better than our current situation, where we assume everywhere is always spring wheat? I think so, but definitely worse than some system that allows evolution over time.

If we are able to come up a time-evolving algorithm for CTSM6.0, I'd prefer that. If not, I think it'd be okay to use a static mask and target 5.3. Jyoti, what sort of time would you have over the next few months to work on an algorithm? I unfortunately can't spare any.

With any method (except "use today's winter/spring mask forever"), we will have to think about how we want to handle the situation where (a) a northern-hemisphere gridcell wants winter wheat in year Y and (b) spring wheat in year Y+1, but (c) the winter wheat is still unharvested by the end of the spring wheat’s planting window. Do we go ahead and harvest the winter wheat to allow planting the spring wheat? Or do we let the winter wheat finish its season and miss our chance to plant spring wheat?

[jyoti1singh]

Thanks @samsrabin for the detailed overview of potential methods to differentiate between winter and spring wheat in the CTSM model. The first approach of conducting dummy runs using Qiao et al. (2023) seems quite complex for broader implementation.

The method described by Iizumi et al. (2018) for excluding specific grid cells from winter wheat consideration due to threshold temperature and the inherent decision-making process in LPJ-GUESS for choosing between wheat types based on climatic conditions provides a good foundation for us to build upon. I want to explore these methodologies and will share my findings here.

What is the deadline for producing the new surface dataset if we include winter wheat in the CTSM3.0 release? Knowing this timeline will help plan the necessary work.

Also, @lawrencepj1 please guide where I might find the climate and time-invariant rules used in CLM to separate tropical from temperate corn and soybean. Understanding CLM's existing algorithm for crop differentiation could serve as a helpful reference point for this task.

Looking forward to your insights and further guidance.

[samsrabin]

@jyoti1singh I think the tropical/temperate rules are implemented in Peter's scripts for making the surface datasets: For gridcells between 30°N and 30°S, they get the tropical version. (Not sure if those limits are inclusive or exclusive.) But I don't think that'll be much use to you here.

[KNR8070]

To add to this discussion, when I investigated the production maps for winter wheat and spring wheat over regions where winter wheat is prominent (Europe, the USA, and China), I found some interesting patterns (Figures attached in a doc). How to separate winter and spring wheat.docx

The main takeaways from the production figures are:

1. 94-95% of the wheat production in Europe and China is from winter wheat. Only 5-6% is from spring wheat. Therefore, it makes sense to prioritize winter wheat in these regions.
2. It is tricky in the USA as the production share between winter and spring wheat is 68% and 32%, respectively. However, upon inspection of wheat maps, winter and spring wheat do not overlap much. The overlap is seen only in the states of Montana and Idaho.

We can generate a rule from these insights depending on the geographical location, which wheat type takes precedence.

Hope this makes sense and might be useful. Thanks

[samsrabin]

Thanks, Narender! We also have the winter/spring wheat mask from GGCMI, which is global at 0.5° resolution, so it'd probably be a better starting point.

[jyoti1singh]

The modified surface dataset for CLM used to simulate winter wheat in our run is created using the GGCMI wheat mask. A critical aspect of wheat representation within the CLM surface dataset is its categorization into rainfed and irrigated types. As far as I understand, rainfed and irrigated wheat can be present within the same grid cell. However, each grid cell is restricted to either winter or spring wheat—not both. Further clarification would be beneficial if there are any exceptions or modifications to this approach within CLM.

@samsrabin, please confirm if this representation accurately reflects the current surface data framework in CTSM3.0 or if there are any updates or exceptions to this rule.

[samsrabin]

So winter and spring wheat aren't allowed to coexist in a grid cell at the same time? Or is it that a gridcell planted with spring wheat can NEVER get winter wheat?

You're probably more familiar with how winter wheat works than I am, but I don't see any such restriction—could you point me to where it is?

If there is one, and we decide we want to allow winter and spring wheat in the same cell, we can change the code as needed.

[jyoti1singh]

@samsrabin, you are correct that no specific rule prevents a grid cell from having spring and winter wheat. However, as I understand based on Peter's work, how the tropical and temperate corn and soybean are differentiated in CLM5, based on specific rules, where a grid can only have one type (tropical or temperate).

The criteria for distinguishing between winter and spring wheat, as outlined in GGCMI phase II and supported by Franke et al. (2020), are as follows: A growing season is assigned to winter wheat if all of the following hold, and to spring wheat otherwise:

• The monthly mean temperature is below freezing point (< 0°C) at most for 5 months per year (i.e., winter is not too long).

• The coldest 3 months of the year are below 10°C (i.e., there is a winter).

• The season start date fits the criteria that:

  • if in the Northern Hemisphere, it is after the warmest or before the coldest month of the year (as winter is around the end/beginning of the calendar year);
  • if in the Southern Hemisphere, it is after the warmest and before the coldest month of the year (as winter is in the middle of the calendar year).

Therefore, while using the GGCMI surface dataset to include winter wheat in the CLM dataset, I applied the same principle to wheat using the GGCMI wheat mask. Consequently, in the dataset I created, each grid cell contains either winter or spring wheat, not both.

Assuming these, I propose adopting similar rules for separating winter from spring wheat in the CLM5 dataset in a given grid cell, which would be easier. Please correct me if I am not right about interpreting winter and spring wheat representation in GGCMI.

[samsrabin]

Good find! Those first two conditions make a lot of sense—probably we would specify "over the past 20 years" or something.

The third one, though, is trickier. It depends on the GGCMI protocol's use of single, set sowing dates for every crop. We of course allow sowing to occur at any point in a sowing window. With my upcoming crop calendar work, the sowing windows will be static over time, centered on GGCMI dates.

So maybe we can use the GGCMI sowing dates as "the season start date" only in these conditionals, and let "the coldest month of the year" and "the warmest month of the year" vary over time. I think that will work.

Note, @lawrencepj1, that this will be code that needs to be written into CTSM, and shouldn't require any updates to the surface datasets.

@jyoti1singh, will you be able to work on this?

[jyoti1singh]

The conditions outlined make sense for distinguishing between winter and spring wheat using GGCMI sowing dates as a reference for the start of the season. Howeve, before moving forward, I'd like to review additional literature to understand the research on separating winter from spring wheat. This could provide us with a broader perspective and refine our methodology.

@lawrencepj1 @samsrabin Regarding the implementation, I have a couple of points to discuss. Would it be more effective to integrate this logic directly into the phenology code, or should we apply it to creating the surface dataset? Considering which approach might provide a more stable representation of land use and cover in the model in the long run. Which option would be more efficient and sustainable for future updates and for participating in crop model intercomparison projects?

[samsrabin]

It would definitely be better to put it in the phenology code. That way the surface dataset and land-use time series files can just stay "wheat," and we can partition it in a time-evolving way inside the model. This is also better for future updates, because changing the surface dataset is a much bigger task than updating code.

That does definitely make sense about wanting to do more research; feel free to put updates in this issue as your thinking evolves. Given the deadlines we're looking at for CTSM6.0 (CESM3.0), that'll probably mean we can't bring in winter wheat with that release, but that's okay.

When you are ready to start the coding, let me know and we can discuss what version of the code you should start with.

Thanks for taking this on!

[jyoti1singh]

Tagging @samsrabin @lawrencepj1 @danicalombardozzi

Building on the GGCMI Phase II criteria to separate winter wheat from spring wheat (Franke et al.,2020)

A growing season is assigned to winter wheat if all of the following hold, and to spring wheat otherwise:

1. The monthly mean temperature is below freezing point (< 0°C) at most for 5 months per year (i.e., winter is not too long).
2. The coldest 3 months of the year are below 10°C (i.e., there is a winter).
3. The season start date fits the criteria that:

• if in the Northern Hemisphere, it is after the warmest or before the coldest month of the year (as winter is around the end/beginning of the calendar year);
• if in the Southern Hemisphere, it is after the warmest and before the coldest month of the year (as winter is in the middle of the calendar year).

Fig. 1. Global distribution of seasonality type for characterizing wheat (Qiao et al., 2023)

applying the third criterion becomes important because of the nature of wheat seasonality and its distribution globally. In Figure 1, seasonality types are based on the annual pattern of temperature and precipitation. Cold regions are characterized by the mean monthly temperature of the coldest month (MTCO) <− 10 ◦C; temperate regions are characterized by MTCO >− 10 ◦C but <5 ◦C; warm regions are characterized by MTCO >5 ◦C; monsoon regions are characterized by MTCO >5 ◦C with significant monsoon cycles. The regions shown in white are areas where wheat is not grown. The key points to note are:

1. Cold regions are entirely dominated by spring wheat,
2. Temperate regions are characterized mainly by winter wheat,
3. Generally, spring wheat is grown in warm regions (e.g., India) but is sown in winter.

If we do not apply the third criterion from GGCMI, the spring wheat grown in cold regions might be characterized as winter wheat.

Another challenge would be the possibility of a mismatch between wheat-type and static-prescribed crop calendars, e.g., a grid has sowing information for spring wheat in the prescribed crop calendar, but given the climate constraints, the grid will be characterized as winter wheat; how would that work? Should we include some conditions to tackle these situations as well?

[samsrabin]

You're right, the third criterion definitely needs to be applied. As far as this:

Another challenge would be the possibility of a mismatch between wheat-type and static-prescribed crop calendars, e.g., a grid has sowing information for spring wheat in the prescribed crop calendar, but given the climate constraints, the grid will be characterized as winter wheat; how would that work?

To some extent, I think that should be fine. I can imagine a couple of different issues related to what you're saying:

• The present-day prescribed calendars are incorrect, leading to spring wheat where it should be winter (and vice versa.) The algorithm won't be perfect, but hopefully such errors are minimal enough that it's worth using.
• Climate in the future changes such that real farmers would shift planting dates rather than switch from spring wheat to winter (and vice versa), but our static planting date dataset doesn't allow for that. Same deal. In the future, there may be a time-evolving planting date dataset we can use, but for now I think it'd be better to include winter wheat even with this limitation.

Was there something else you were concerned about?

[jyoti1singh]

I think this is it for now, if anything comes up in the future I will post it here. I can start working on implementing this climate constraint. Which version of code should I start with?

[samsrabin]

Excellent! I think the latest tag, ctsm5.2.004, should be best.

[ekluzek]

I removed the ctsm6.1.0 milestone from this this is active research so we may not be able to have a timeline for it. I'm repurposing the ctsm6.1.0 milestone to be the CMIP7 updated dataset milestone which will be called ctsm5.4 since the CMIP7 dataset update is now planned to come before the CESM3.0 release.

If this can happen in the next 6 months or so it might fit into ctsm5.4 -- and if not would be post cesm3.0.