Model splitting

When building a simulation in ERS, you can organize your model as a single submodel or split it into multiple submodels that run in parallel. Deciding when to split a model into multiple submodels is a design decision that depends on your simulation's characteristics and requirements. This page explains when and why you might want to split a model into multiple submodels.

How submodels work together

When you split a model into multiple submodels:

Each submodel is paired with its own simulator and can run in parallel.
Submodels communicate through sync-events to transfer entities or data.
You define dependencies and promises between simulators to coordinate their execution.
Each submodel maintains its own set of entities and components.

For technical details on working with submodels, see the submodel page.

For a practical example of splitting a model into submodels, see the scaling up tutorial.

When to split a model into submodels

Performance and parallelization

If your simulation is computationally intensive and you need better performance, splitting into submodels allows ERS to execute them in parallel on multiple CPU cores. This is beneficial when:

You have independent or loosely-coupled subsystems that can run concurrently.
The computation time of your simulation is a bottleneck.
You have access to multi-core hardware to take advantage of parallelization.

Natural boundaries in your system

Split into submodels when your system has clear logical or physical boundaries:

Geographic separation: Different locations, facilities, or regions (e.g., multiple warehouses, factory floors, or service centers).
Functional separation: Distinct processes or departments (e.g., production vs. distribution, manufacturing vs. quality control).
Temporal separation: Systems that interact at specific intervals rather than continuously.

Different simulation paradigms

When different parts of your model require different simulator types, they should be in separate submodels:

One part uses discrete-event simulation while another uses agent-based or continuous simulation.
Different subsystems have significantly different time scales or precision requirements.

Modularity and reusability

Consider splitting when:

Reusing a subsystem in multiple different models.
Different parts of the model are developed or maintained by different teams.
Needing to test or validate subsystems independently.
The model structure would benefit from clearer organization and encapsulation.

Complexity management

If the model is becoming difficult to understand or maintain, splitting into submodels can help:

A single submodel has become too large with too many entities.
Different subsystems have minimal interaction and can be understood separately.
Clearer interfaces between different parts of the system are required.

When NOT to split

Avoid splitting into submodels when:

The model is small and manageable as a single submodel.
Entities need to interact very frequently between subsystems (high communication overhead).
The added complexity of managing multiple submodels and sync-events outweighs the benefits.
You don't need parallelization and the logical boundaries aren't clear.

Start simple, refactor when needed

It's often better to start with a single submodel and split it later when you identify clear benefits. Unless you know the layout of what the simulation should look like beforehand. Premature optimization can add unnecessary complexity. The decision to split should be driven by actual needs such as performance requirements, natural system boundaries, or maintainability concerns rather than speculation about future benefits.