How should we represent agricultural management events in CCMMF?

[dlebauer]

Currently, SIPNET doesn't simulate agricultural managements, which will be core to the CCMMF workflow.
Here are two options for representing these processes that @infotroph and I brainstormed today:

1. Within model, treating these events the same as other environmental drivers: adjusting pools or (in the case of tillage) modifying parameters.
2. Let PEcAn use SIPNET restart functionality to handle these events by adjusting state + parameters.
3. Other, perhaps depends on type of event.

For reference, these are the management types that we plan to represent, with some ideas about how these could be represented:

• fertilization: add N
• manure addition: add C and N
• irrigation: add water, like precipitation
• planting: add a little leaf and a little root
• harvest: remove fraction of aboveground biomass; for annuals, move plant biomass to litter pools
• cover crops: no different from other crops
• tillage: transient increase in SOC turnover rate

It is worth noting that in some we may only be able to detect that an event happened but not the magnitude, though we will be able to put priors on magnitude.

[dlebauer]

I am not familiar enough with the advantages of option 2 (modifying states and parameters and restarting the model), and I had not previously considered this.

Advantages of option 1 include:

• Representing ag management events the same as other environmental drivers means the logic is more consistent: managements are additional drivers that change states and modify parameters. Is there anything special about ag managements that warrant a different approach?
• This approach is commonly used by other crop and biogeochemistry models. This would make the logic more directly compatible with other models.

Disadvantages and considerations:

• Requires increasing complexity of SIPNET (but avoids even greater complexity of workflow code?)

[infotroph]

One potentially useful way to frame this: Do we want the model to know humans exist? If sipnet is model that represents biogeochemical processes, then we simulate management by perturbing biogeochemistry. If it's a model of ecosystem dynamics that includes human interventions, then we simulate management by specifying how those events affect other processes.

On the complexity side, I'm taking it as a given that whatever approach we take we have to implement all the code to get from (e.g.) "Tillage on March 20th" to (e.g.) "Heterotrophic respiration rate increases from March 20th to April 20th", so differences in complexity will come from putting the logic where it's easiest to read/understand/reuse more than from being able to skip any steps of the conversion.

[dlebauer]

Could you help me better understand the distinction about whether humans exist and how this would affect the choice of approach?

A time series of irrigation will add water to the system in the same (or similar) way as precipitation. Does the fact that the model explicitly handles irrigation mean that it 'knows' that humans exist? What about the fact that we are simulating an ecosystem that is both directly (through management) and indirectly (e.g. through climate change, pollution) influenced by humans?

[infotroph]

planting: add a little leaf and a little root

Not by resetting phenology terms like leafOnDate?

[mdietze]

Phenology will work for perennials, but for annuals -- if 100% of the plant was harvested (or turned over into the litter or soil pools) then there's nothing to leaf out (i.e. zero biomass is a stable equilibrium).

That said, note that Cherry has added code recently that allows us to prescribe phenology based on the MODIS product (or potentially other data sources) which does what Chris suggests -- setting the initial (year 1) leafOnDate and leaf off dates and then updating them during restarts.

[dlebauer]

FWIW I drafted these as examples of how managements could be simulated in the model itself since defining that is a separate and perhaps more complex question.

For this discussion, we just need to figure out how all of the managements will be simulated to determine the approach to take, just enough to help identify pros and cons of each approach.

[infotroph]

am I right that approach 1 would move sipnet from having two inputs (drivers in a clim file, parameters in a param file) to three (adding events in a file whose format is to be defined)? Or are you proposing to have the management events somehow appear directly in the clim file?

[infotroph]

(This isn't an argument for or against the approach, just making sure I understand what you're picturing)

[dlebauer]

I think representing managements in a format similar to weather drivers is an interesting idea, especially if we are creating gridded time series of managements. And these layers will be part of our deliverables, specifically Tasks 3.4 that includes "Generate gridded maps of agronomic management events, including uncertainty, for use in modeling framework." and 3.5 that updates these maps with new management types.

For the record, the PEcAn standard is JSON, it uses the ICASA vocabulary - this was developed by @istfer and @HenriKajasilta at FMI as part of their FieldObservatory. Perhaps we could we have SIPNET read this directly (thoughts @Alomir)?

• example events.json
• JSON schema definition github.com/hamk-uas/fieldobservatory-data-schemas and management-event.schema.json

[dlebauer]

@Alomir and @infotroph and I discussed additional details of the tradeoffs this morning and ultimately concluded to go with option 1 - implement handling of events like managements inside the SIPNET code.

But PEcAn will handle conversion of the management event JSON to a format that provides the quantities that SIPNET already uses (e.g. converting a fertilizer type to fluxes with appropriate units).