Massive Simulations with Hierarchical Computation Graphs

Effectively targeting cloud resources using Hierarchical Computation Graphs for large-scale, high-fidelity simulation.

Hierarchical Computation Graphs

Sedaro presents scenario developers with a highly flexible interface for defining simulations and their agents, components, and variables, as well as the relationships and constraints between them. While this declarative information is formalized in the user-facing Sedaro Modeling Language (SedaroML), we translate it to an Intermediate Representation (IR) in order to capture the operational information required to simulate these models. This post will cover the layers of information that our IR represents and the ways it enables us to fully utilize cloud resources during simulation.

Sedaro's simulation platform aims to support a wide variety of engineering domains and enable interactions between multiple simulation engines, which is called co-simulation. Our runtime system must simulate both the low-level interactions of components within an agent as well as the high-level communications among the many agents in a scenario. To this end, our Intermediate Representation is based on computation graphs with explicit hierarchy and multiplexing, which we call Hierarchical Computation Graphs or HCGs.

HCGs are composed of three key elements: wires holding pieces of simulation state, children (which may represent either "primitive" functions for computing state or whole other HCGs), and links between them. I won't be getting into representation details here, but the interesting information is in the metadata attached to these elements throughout the hierarchy. Some of this information has an effect on the abstract simulation itself and will affect the data persisted to the Data Service and presented in the front end web interface. Other information is purely operational and used to control the concrete execution of the simulation. HCGs can be composed and combined algebraically, which lets us split up this metadata into various layers. By varying the purely operational layers, we can transparently experiment with different ways of running simulations to optimally target cloud computation resources without affecting the outputs of our simulations.