Replies: 4 comments 6 replies
-
|
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:
Disadvantages and considerations:
|
Beta Was this translation helpful? Give feedback.
-
Not by resetting phenology terms like leafOnDate? |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
@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). |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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:
For reference, these are the management types that we plan to represent, with some ideas about how these could be represented:
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.
Beta Was this translation helpful? Give feedback.
All reactions