Users can explicitly define the output format and perform data post-processing within the <outputs> section of a ModelSolution. Custom arithmetical expressions or aggregation functions can be incorporated directly for each output variable using the placeholder “${}” within the “rule” attribute (e.g. the output “HI'' variable declared in Fig. 2). The level of aggregation can also be specified with the “frequence” attribute, which has three cases: (i) DAILY: will not aggregate the data outputting the selected variables for every simulation timestep (e.g. Fig. 4); COMPLEX: will aggregate data using the given “mode” for each variable (FIRST, LAST, SUM, MIN, MAX, AVG, STD). The aggregation can occur for given rules, which can represent, for example, variable crop season lengths (e.g. between sowing to harvest); and YEARLY, MONTHLY, WEEKLY: will output the results for the last day of the predefined time period. All output objects will have by default the project and simulation IDs (“projectid” and “simulationid”), and the date (“CURRENT.DATE”) for each output record.
Outputs specify the variables (and where they come from) to write to each output file.
Fig 1. Example of output object definition in a ModelSolution XML file
Fig. 2. Simplified version of a model solution XML file summarizing the information flow and linkage (dashed red arrows) across the five main sections of a model solution (<variables>; <interfaces>; <resources>; <simmodel>; <outputs>) and its objects. The “...” represents parts of the solution that were omitted for simplicity. Solid red arrows indicate where rule-based expressions are used. The variable CropFile is not directly specified as a rule or source, in the case of <interface>, it can be passed by enclosing it in the placeholder “${}” (e.g. “${CropFile}”) (source: https://doi.org/10.1093/insilicoplants/diad006)