Open samsrabin opened 2 years ago
Here is an example of how this works for SDATES and HDATES. Ignore the first timestep in the file, as that's from the year before my run started.
This seems great – thanks for the writeup and for the discussion at today's CLM science meeting. Just recording a few thoughts from there:
Before you get too far into implementation, it might be good for a few of us to get together and talk about a good way to do this in a general way. What I'm picturing ideally is that there would be infrastructure in histFileMod (maybe delegating out to some other module) to implement the logic in a general-purpose way, so that adding a new variable that is averaged over the growing season is as easy as making a hist_addfld call with appropriate arguments. (There would probably still need to be special purpose logic for the variables that handle the timings of different phenological triggers, but ideally there would be general-purpose logic for all of the variables that you want averaged over the growing season.)
@dlawrenncar suggested that it could be helpful to do something similar for natural vegetation if it isn't too difficult. If (1) is done in a general way, I wondered if we could have a patch-level variable that marks the beginning and end of the growing season which is leveraged by (1). Then there could be logic in CNPhenology to populate that variable appropriately for crops vs. natural vegetation, and the infrastructure for (1) would then work effectively the same for crops and natural vegetation. As @samsrabin pointed out, though, one piece of complexity with trying to be too general about this is the max number of growing seasons for a given vegetation type.
Over email, @danicalombardozzi, @billsacks, and I talked about how it might be a good idea to use the "annual" (technically, per growing season) crop output infrastructure I'm developing for #1537 (PR #1616) for additional crop output variables. This would reduce the data storage/transfer requirements and postprocessing overhead needed (as well as probability of postprocessing mistakes) for people working with crop outputs.
For example, currently, the only way to get crop yield is to sum up the daily grain C addition over the course of a growing season. It would be much easier and less storage-intensive to simply output yield once per harvest, on my new
mxharvests
dimension.I thought we could use this issue to discuss the various variables that should have such output enabled, as well as implementation details such as in what data structure(s) the values should be stored.
As a starting point, I took the list of output variables requested for GGCMI phase 3. I've included the units specified by the GGCMI protocol, but these could be changed for consistency with standard CLM output units as desired.
SDATES
(taken fromcrop_inst%sdates_thisyr
).HDATES
(taken fromcrop_inst%hdates_thisyr
), which has units "day of year" likeSDATES
.[^1]Soil moisture of upper 1m (monthly)kg m-3monthly average actual absolute available soil water content of the upper 1m soil column (above wilting point);[^1]: Instead, we could think about a "growing season length" variable for this, with
HDATES
remaining as the actual "harvest date."All of these could be output on the
mxharvests
dimension. Currently, sowing date (SDATES
) is output on themxsowings
dimension, but because by definitionmxharvests
>mxsowings
, it could go onmxharvests
too.As far as implementation goes, right now I have
SDATES
andHDATES
being set up in theCropType
module:(Note the
avgflag='I'
, as these are instantaneous variables.) I could see an argument being made either way: to put all the new variables intoCropType
, or to put them into more thematically related structures (water, C, etc.).