The ModelSolution is where all the linkages and rules for data exchange and processing are explicitly made between I/O interfaces, resources and SimComponents. As such, it offers the highest level of flexibility for designing and testing whole model structures in SIMPLACE.
Multiple SimComponents can be combined in a predefined execution order to address a specific problem or test a scientific hypothesis. The complexity of ModelSolutions differs according to the user needs and input data availability. One ModelSolution may, for example, need a detailed description of soil water, nitrogen, and phosphorus dynamics, while another may need to be more general with respect to the description of soil processes but must have a detailed description of carbon assimilation, respiration, and biomass partitioning. A flexible modelling system can accommodate both cases.
An entire model solution is specified in a special grammar of an XML file format where five sections must be declared including the (i) constant variables (<variables>); (ii) interfaces (<interfaces>); (iii) resources and data transformers (<resources>); (iv) the SimComponents structure and linkage (<simmodel>); and (v) the outputs (<outputs>). A model description (<description>) section is also available for documentation and quality-check purposes.
For each section of the ModelSolution file, users must assign unique names (ID) for every object and underlying variable. The common IDs are available to explicitly link information across the data resources and SimComponents.
For example, if a resource object is declared with an ID name “weather”, and contains two variables named “temp” and “rain”, this information can be passed to a SimComponent as “weather.temp” and “weather.rain” respectively. Similarly, if a SimComponent named “Phenology” has an accessible variable named “AnthesisDate”, it can be passed to either another SimComponent or output via “Phenology.AnthesisDate”. This syntax logic is employed throughout the whole ModelSolution file, provided the declaration order for each variable and object is given sequentially in a downward direction:
Fig 1. 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)
Automated checks on the XML syntax and SimVariables values during the simulation runtime are also possible and controlled by the ModelSolution attributes “version” and “check”. The check level “LAZY” (Fig. 1) is generally selected and will provide warnings during the simulations when the value of a SimVariable is out of limits (min/max). Other check-level options are also available and described at CheckHelper / CheckLevel.
As each ModelSolution can be understood as a stand-alone simulation model composed of a distinct set and order of SimComponents, a naming convention has been created which lists the names of the key model components as an array. For example, the ModelSolution named SIMPLACE <LINTUL5, Hillflow1D> is a model which combines the physically based soil water balance model component Hillflow1D with the generic crop growth and phenology-related SimComponents of LINTUL5.