Starting in Hassayampa (Version 3.0), GridLAB-D supports several types of parallelism. Throughout this document a distinction is made between simple and complex GridLAB-D models, the definitions of which are as follows:
- Simple model
- A simple GridLAB-D model is a model that describes the agents of a system without reference to the behavior of other agents described in other GLM files. Simple models are standalone models in which all the agents' behavior is considered strongly coupled. They can be simulated without the need for parallelism (as in single-threaded mode. Although simple models can often be parallelized (and GridLAB-D can do that automatically in multithreaded mode) there is no requirement that they be run in parallel to successfully complete the simulation.
- Complex model
- A complex GridLAB-D model is a model that describes the agents of a system using references to the behavior of agents described in other GLM files. Complex models use multiple simultaneous simulations in which a few agents are considered weakly coupled. They cannot be simulation without recourse to parallelism of some kind (see multirun/single host and multirun/multihost modes).
Single-threaded simple model
This type of operation is the classical operational mode in which each model runs independent and uses only one CPU. If a machine has multiple processors, each processor is dedicated to a single run and GridLAB-D manages the CPU affinity of processes using a process map.
- See also
- High_Performance_Computing; Command options: (--pstatus, --clearmap, --pkill).
Multithreaded simple model
Simple models are often implicitly parallel in the sense that one or more agents' behavior may be solved simultaneously without altering the outcome of the simulation.
- Note
- Multithreaded operation was originally designed into GridLAB-D by virtue of the rank/pass structure of the core solver. However, the locking/synchronization mechanisms needed to make it work efficiently originally deployed in Version 1 was inefficient. A second attempt to deploy an efficient method in Version 2.0 was also deemed inadequate. As of Version 2.2, a more efficient parallelism method was introduced. It was originally planned to support multithreading for simple models, but this was never fully deployed because it could not be validated in Four Corners (Version 2.2) when it was ready.
The degree to which multithreading enhances performance is highly dependent on the structure of the model itself, so there is absolutely no guarantee that operating in multithreaded mode will actually improve performance. As a generally rule the following factor affect the degree to which multithreading will result in a speed-up of the simulation:
- Rank occupancy
- Models that have few densely populated ranks will typically parallelize much better than models that have many sparsely populated ranks.
- Inter-agent links
- Models in which the agents within a rank are more decoupled will typically parallelize much better than models that have a lot of inter-agent data exchange.
- Global solvers
- Models that use distributed or decoupled solvers (such as Gauss-Seidel) will typically parallelize much better than models that have monolithic or global solvers (such as Newton-Raphson).
Multithreading mode is intrinsic to the structure of the core solver and it is automatically used whenever the threadcount is not 1.
- See also
- Multithreading; Command options: (threadcount).
Multirun complex model (Single host)
Approval item: --Dchassin 14:37, 8 October 2011 (UTC)
Multirun mode is used to simulate multiple weakly coupled models. In such cases one model is designated the master model and all the other models are designed slave models. The master model is the model that is started by the user, and the master model starts and coordinates its mainloop_state with all the slave models. More than one instance may be defined in a single model. Slaves may define instances and therefore be both slave and master simultaneously.
The distinguishing characteristic of a single-host complex model is that all the slave instances of the GridLAB-D used in the simulation run on the same machine as the master instance.
- Note
- Complex models do not technically require multiple processor but they are designed to operate under the assumption that multiple processor are available on a single machine.
- See also
- Multirun mode: (instance, linkage, master, slave).
Multirun complex model (Multihost)
Approval item: --Dchassin 14:37, 8 October 2011 (UTC)
PROPOSED FOR 3.0
Multiple machines may be used to simulate weakly coupled models. This mode is operation is identical to single host mode in every way except that the slave instances may be run on different hosts than the master instance runs on.
- See also
- Multirun mode: (instance, linkage, master, slave).
Server mode
New in 2.2!
Server mode is a special mode of operation in which the main loop of GridLAB-D is controlled from an external process such as a graphical user interface or another simulator. See realtime server for details. This mode of operation is a decoupled mode in the sense that the minimum exchange of data required is the passing of the clock information through the pauseat message.
Server mode imposes no restrictions or assumptions on the type of parallelism required or used by the model.
- See also
- Realtime server; Global variables (clock; mainloop_state; server, (control, pauseat, resume).
Synchronous mode
Approval item: --Dchassin 14:37, 8 October 2011 (UTC)
Synchronous mode is a special mode that supports strongly coupled integration of GridLAB-D with external simulations. This can only be implemented using modules at the current time.
TODO: Description the requirements for synchronous simulation operation.
See also
- Multirun mode
- Technical documents