Examples

Name

Description

SaM

One model that receives input from two files and sends output to one file in the temporary directory. The YAML uses the deprecated driver-based method to represent connections.

ascii_io

A single model that receives data from three input files and sends received messages to three output files. The first file is an unstructure ASCII text file, the second file is a table delimited ASCII table that is read row by row, and the third file is a table identical to the second that is read all at once.

backwards

A single model using the deprecated “Cis” versions of the interface.

conditional_io

Three models, A, B1, & B2, that conditionally pass messages. Model A receives input from a tab delimited table and sends output to both models B1 & B2. The outputs to models B1 & B2 only succeed if the data satisfies conditions described in the YAML. Output from both models B1 & B2 are sent to a tab delimited table.

fakeplant

Four models that can be run in isolation or as an integration. Each model approximates a simplified model of a process governing plant growth. When run in isolation each model receives input from a file and sends output to a file. In the larger integration, the canopy model receives input from three files (initial structure, time steps, and some growth parameters. For each time step received, the canopy model also receives a growth rate from the growth model, computes the new structure. and send the structure to the light model. The light model receives the ambient light level from a file, calculates the intensity for each element of the structure, and sends the output to the photosynthesis model. The photosynthesis model receives temperature and CO2 from files, calculates the photosynthesis rate, and sends the result to the growth model. The growth model calculates the growth rate and sends the output to the canopy model.

formatted_io1

Two models, A & B, that send/receive ASCII data (strings). Model A receives input from a file and then sends it’s output to model B. Model B receives input from model A and sends it’s output to a file.

formatted_io2

Two models, A & B, that send/receive rows of table data. Model A receives input from a file and then sends it’s output to model B. Model B receives input from model A and sends it’s output to a file.

formatted_io3

Two models, A & B, that send/receive table data as arrays. Model A receives input from a file and then sends it’s output to model B. Model B receives input from model A and sends it’s output to a file.

formatted_io4

Two models, A & B, that send/receive table data as Pandas data frames (or the closest equivalent for non-Python languages). Model A receives input from a file and then sends it’s output to model B. Model B receives input from model A and sends it’s output to a file.

formatted_io5

Two models, A & B, that send/receive 3D mesh data as Ply meshes. Model A receives input from a file and then sends it’s output to model B. Model B receives input from model A and sends it’s output to a file.

formatted_io6

Two models, A & B, that send/receive 3D mesh data as Wavefront Obj meshes. Model A receives input from a file and then sends it’s output to model B. Model B receives input from model A and sends it’s output to a file.

formatted_io7

Two models, A & B, that send/receive key/value maps. Model A receives input from a file and then sends it’s output to model B. Model B receives input from model A and sends it’s output to a file.

formatted_io8

Two models, A & B, that send/receive JSON data. Model A receives input from a file and then sends it’s output to model B. Model B receives input from model A and sends it’s output to a file.

formatted_io9

Two models, A & B, that send/receive YAML data. Model A receives input from a file and then sends it’s output to model B. Model B receives input from model A and sends it’s output to a file.

gs_lesson1

A single model without any inputs or outputs.

gs_lesson2

Two models without any inputs or outputs.

gs_lesson3

A single model with input from a file and output to a file.

gs_lesson4

Two models, A & B, that send/receive strings. Model A receives input from a file and then sends it’s output to model B. Model B receives input from model A and sends it’s output to a file.

gs_lesson4b

Two models, A & B, that send/receive strings. Model A receives input from a file and then sends it’s output to model B. Model B receives input from model A and sends it’s output to a file. Connections are made using the deprecated method of matching the args parameter in input/output drivers.

hello

A single model receives input from a file, sends the input as output to a file and back to itself, receives its own output, and sends that as output to a file in the temporary directory. The input & output files are specified via the default_file parameter in the model inputs/outputs and the connection demonstrates the use of the onexit parameter.

maxMsg

Two models run in a client-server, remote procedure call (RPC) communication pattern. The client model maxMsgCli sends requests and receives response to/from the server model maxMsgSrv via the deprecated rpcCall method (use call instead). The server model receives requests and send responses. This example demostrates the RPC pattern through the use of the client_of and is_server model parameters and the RPC interface classes/functions.

model_error

A single model that raises/returns an error.

model_error_with_io

Two models, A & B, that should send/receive strings, but Model A raises and error instead.

model_function2

Two models, A & B, that send/receive scalars and arrays. Model A iterates over received array input from a table, calling the indicated model function for each array element, and then sends all of outputs from the iteration as an array to model B. Model B receives input arrays from model A and sends it’s output to a file. Both models are functions that are automatically wrapped by yggdrasil with the appropriate interface calls. This example demonstrates the use of the function model YAML parameter and auto-wrapping as well as iteration over input/output arrays via the iter_function_over model YAML paramter.

model_function

Two models, A & B, that send/receive strings. Model A receives input from a file and then sends it’s output to model B. Model B receives input from model A and sends it’s output to a file. Both models are functions that are automatically wrapped by yggdrasil with the appropriate interface calls. This example demonstrates the use of the function model YAML parameter and auto-wrapping.

osr

Two models run in a time step synchonization pattern where one of the models is the OpenSimRoot simulation code and the other is a dummy stand in. This example demonstrates how to run OSR simulations as part of yggdrasil integrations and the use of the timesync model parameter and communication pattern.

root_to_shoot

Two models, a root model and a shoot model, that are both run via wrappers around functions. The root model receives the initial root mass, growth rate, and time steps from files. For each time step, the root model computes the new root mass and sends it to the shoot model. The shoot model receives the initial shoot mass, growth rate, and time steps from files. For each time step, the shoot model receives the new root mass from the root model, calculates the next shoot mass and outputs it to a file.

rpcFib

Three models (two clients, one server) run in a client-server, remote procedure call (RPC) communication pattern. The client models (rpcFibCli and rpcFibCliPar) send requests and receive response to/from the server model rpcFibSrv. The rpcFibCli model sends & receives requests/responses via the deprecated rpcCall method (use call instead), while rpcFibCliPar uses the separate send/recv methods rpcSend and rpcRecv (use send & recv instead). The server model receives requests and send responses. The rpcFibCli model also reads text data from and input file and sends each request/response pair to an output file. This example demostrates the RPC pattern through the use of the client_of and is_server model parameters and the RPC interface classes/functions, including splitting calls into their send/recv components. The models also receive parameters via the command line as specified in the YAML args model parameter.

rpc_lesson1

Two models run in a client-server, remote procedure call (RPC) communication pattern. The client model client sends requests and receives response to/from the server model server via the deprecated call method. The server model receives requests and send responses. This example demostrates the RPC pattern through the use of the client_of and is_server model parameters and the RPC interface classes/functions. The client model also sends request/response pairs to a file.

rpc_lesson2

Three models run in a client-server, remote procedure call (RPC) communication pattern. The two client models (client1 & client2) send requests and receive response to/from the server model server via the deprecated call method. The server model receives requests and send responses. This example demostrates the RPC pattern through the use of the client_of and is_server model parameters and the RPC interface classes/functions. The client1 & client2 models also send request/response pairs to files in the temporary directory and receive parameters via the command line as specified in the YAML (both model call the same source code). The server model receives parameters as input from a file.

rpc_lesson2b

This example is identical to the rpc_lesson2 example except that 2 copies of the server are run instead of 1 via the copies model parameter.

rpc_lesson3

Two models run in a client-server, remote procedure call (RPC) communication pattern. The client model client sends requests and receives response to/from the server model server via the deprecated call method. The server model receives requests and send responses. The client model receives request data from a file and send responses to a file. In the case of both models, yggdrasil auto-wraps functions with interface calls at runtime. This example demostrates the RPC pattern through the use of the client_of and is_server model parameters and the RPC interface classes/functions in conjunction with automated wrapping of model functions, including the use of the global_scope interface parameter when autowrapping functions that contain interface calls themselves.

rpc_lesson3b

This example is identical to the rpc_lesson3 example except that 10 copies of the server model are run via the copies model parameter and the client model makes calls the server from inside an OpenMP threaded loop. This example demonstrates the use of the RPC communication pattern in conjunction with automated model wrapping, OpenMP threading, and model duplication.

sbml1

A single SBML model runs with input from a files and output to a file.

sbml2

A single SBML model runs with input from a files and output to a series of files. This example demonstrates how to control the SBML integration via model parameters in the YAML (e.g. tolerance, time steps, initial conditions).

sbml3

A single SBML model runs with input from a files and output to a file. This example demonstrates the use of the only_output_final_step model parameter to only get the final output of the simulation.

timed_pipe

This example is used for gathering performance information about communication between model in yggdrasil integrations and should only be run as part of the timing module.

timesync1

Two models, A & B, run simulations over time and exchange data via a timestep synchronization communication pattern. Both models compute the same variables (x and y) via the same source code and output data at each time step to a file, but they have different time steps.

timesync2

Two models, A & B, run simulations over time and exchange data via a timestep synchronization communication pattern. The timesync model statesync is explicit in the YAML and allows for specific control of the synchronization (e.g. relationship between variables, interpolation, aggregation). The models compute different variables, have different timesteps, and output data at each time step to a file. This example demonstrates more advanced use of the timesync communication pattern and YAML parameters.

Transformed I/O

Three models, A, B, & C, pass messages which are transformed based on YAML parameters. Model A receives input from a tab delimited table and sends output to both models B & C. The output to each model is transformed in different ways controlled by the transform comm model parameter. Models B & C both send output to tables.

transforms

This example is used by yggdrasil to test the support transformations in each of the supported languages and should not be used outside of the tests.

types

This example is used by yggdrasil to test the serialization/deserialization of the supported types between the supported languages and should not be used outside of the types test suite (run via yggtest –test-suite=types).

wofost

A single model receives input from a WOFOST-style parameter file and sends output to a file. This example demonstrates how to interact with generic data structures containing maps in the compiled languages.