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.
composite_function2	One model receives inputs from one source and sends outputs to one destination. One component of the input and the output each are composite types. The model is automatically wrapped by yggdrasil with the appropriate interface call.
composite_function	One model receives input from 3 different source, 2 being value constants and one being a file. The model is automatically wrapped by yggdrasil with the appropriate interface call.
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.
pytorch1	A single pytorch model based on the FastionMNIST example given in the PyTorch documentation runs with input from a files and output to a file.
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.
split_and_merge	Four models, A, B, C, & D, pass messages between them, splitting and joining variables in the messages between them. Model A receives input from a tab delimited table and sends two output variables which are split between models B & C according to the output_pattern: ‘scatter’ YAML parameter. The outputs from Models B & C are then merged and sent to model D according to the input_pattern: ‘gather’ YAML parameter. The output from model D is then sent to a table.
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.
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.