Warped2: Open-Source Optimistic PDES Kernel

• Warped2 is an open-source PDES engine that uses Time Warp optimistic synchronization and Pending Event Set optimization to manage rollback and distributed event processing.
• Its baseline runtime architecture features modular components like the Event Dispatcher and Global Manager, ensuring effective state saving and MPI-based communication.
• Recent extensions include asynchronous listener threads, METIS-based load rebalancing with LP migration, and optimized nearest-neighbor search yielding significant performance gains.

Searching arXiv for papers specifically about Warped2 and closely related PDES/Time Warp work. Warped2 is an open-source Parallel Discrete Event Simulation (PDES) engine implementing Time Warp optimistic synchronization with Pending Event Set optimization. In the recent wargaming-oriented study centered on it, Warped2 is treated not as a simulator written from scratch for combat models, but as a reusable optimistic kernel whose rollback, event scheduling, MPI-based distributed execution, and configurable runtime architecture can be extended toward large-scale entity-centric simulation (Jia et al., 24 Jul 2025).

1. Identity, scope, and positioning

Warped2 is described as a PDES engine for simulations in which work is decomposed into logical processes (LPs) that exchange timestamped events and may execute speculatively in parallel. The engine is explicitly characterized as optimistic rather than conservative: LPs are allowed to process events before global causal certainty, and correctness is recovered by rollback when a causality violation is detected. In the study devoted to large-scale wargaming simulation, Warped2 is presented as a strong baseline because it already provides optimistic synchronization, pending event management, rollback support, MPI-based distributed execution, and a configurable kernel architecture (Jia et al., 24 Jul 2025).

Within that treatment, Warped2 is also positioned as an engine with both internal and external limitations. Internally, the baseline runtime is said to have inadequate mechanisms for handling events in large-scale throughput, insufficient support for dynamic event injection after initialization, and no satisfactory autonomous rebalancing of LP workloads once event patterns evolve. Externally, the baseline engine is said not to provide suitable interfaces for complex entity interaction patterns of the sort needed in wargaming, where reconnaissance, missile motion, attack, destruction, and shared-world state access must coexist with optimistic execution. The paper’s central claim is therefore not that Warped2 is inadequate as a PDES kernel, but that its default operating assumptions are too rigid for large-scale combat-style simulation unless the runtime and model interfaces are substantially reworked (Jia et al., 24 Jul 2025).

2. Baseline runtime architecture

The baseline Warped2 design is described through five major components: Event Dispatcher, Global Manager, Communication Manager, Statistics Manager, and Termination Manager. These are split into local and global functionality. On the local side, the Event Dispatcher manages the event set, simulation unit state, garbage collection, and rollback support. Its associated data structures include scheduling queues, LP input queues, management locks, processed and pending event structures, output queues, and LP state queues. The state manager stores saved LP states for rollback. On the global side, the Global Virtual Time (GVT) Manager monitors global progress, the Termination Manager decides when simulation can end, and the Statistics Manager collects local and global metrics (Jia et al., 24 Jul 2025).

The baseline execution model is node-centric. Each computing node is said to have a main thread, responsible for node-wide communication and message handling, and a worker thread, responsible for event processing. The same paper also discusses multiple worker threads and multiple scheduling queues in the optimized framework, so the baseline two-role structure should be read as the minimal kernel arrangement rather than the only possible deployment. Inter-node communication is performed through MPI messages, which carry event transfers, anti-messages, synchronization notifications, and related control traffic (Jia et al., 24 Jul 2025).

The architecture therefore places Warped2 squarely in the family of distributed optimistic kernels in which event management, state saving, rollback, and GVT-based reclamation are first-class concerns. This suggests that Warped2 is best understood as an execution substrate for speculative timestamp-ordered models rather than as a domain-specific simulation package.

3. Event processing, Time Warp synchronization, and Pending Event Set behavior

The event-processing loop reproduced in the paper follows the standard optimistic PDES pattern. The runtime fetches the next scheduled event, determines the destination LP, checks whether the event timestamp is earlier than the LP’s last processed event time, and if so invokes rollback. Anti-messages are handled by canceling matching events when possible and rescheduling as needed. Otherwise the engine processes the event, saves LP state, sends newly generated events, moves the processed event into history, and replaces the scheduled event for the LP (Jia et al., 24 Jul 2025).

This is the paper’s concrete statement of Time Warp behavior. LPs process events independently and speculatively; if a straggler arrives with an earlier timestamp than the LP’s current local virtual time or last processed event, the LP restores a prior state from the state queue and may emit anti-messages to cancel downstream effects of invalid speculative execution. Events and states earlier than GVT can be reclaimed because no legal rollback may pass before GVT. The paper does not recast these mechanisms into a new mathematical synchronization theory; it presents them as Warped2’s baseline operating model (Jia et al., 24 Jul 2025).

The Pending Event Set optimization is repeatedly identified as one of the reasons Warped2 is a useful starting point. The paper does not restate its full internal theory, but it describes Warped2 as using a two-level event management structure that improves local event handling and helps avoid unnecessary local rollbacks. In the optimized framework, this matters again because multiple scheduling queues become relevant for thread-level load balancing. The intended picture is that Pending Event Set behavior is already a strong local optimization, but does not by itself solve load imbalance, runtime control rigidity, or interaction-heavy model semantics.

4. Wargaming-oriented extensions

The paper’s main engineering contribution is a framework layered on top of Warped2 with four explicit improvements: asynchronous listener threads, METIS-based load rebalancing plus LP migration, an entity interaction solver with constraint satisfaction mechanisms, and a spatial hashing algorithm for nearest-neighbor search (Jia et al., 24 Jul 2025).

The first extension adds a listener thread on each node. The baseline engine is described as assuming autonomous execution after initialization, which is inconvenient when new events must be injected after a simulation phase, when user input must pause and modify the scenario, or when runtime control must be decoupled from synchronous polling. The optimized architecture therefore uses a main thread, worker threads, and a listener thread. A flag on the main node coordinates execution state; when user input arrives, the Termination Manager prevents premature termination, an MPI messaging interface informs other nodes that new events will be added, and idle workers wait for either new input or final termination. To support this mode, garbage collection is also altered: instead of reclaiming all events older than GVT at each update, the framework collects after a fixed number of GVT iterations, preserving more rollback history for delayed event injection (Jia et al., 24 Jul 2025).

The second extension targets load imbalance. Warped2 already supports pre-simulation graph partitioning, and the paper states that it builds a weighted communication graph and applies METIS multi-level k-way partitioning with graph coarsening, minimum-cut partitioning, and refinement. The optimized framework adds a dual-layer adaptive mechanism. At thread level, dynamic scheduling remaps thread IDs to queues by

$Q_{(i+k)\bmod N},$

where $T_i$ accesses $Q_{(i+k)\bmod N}$ at cycle $k$. At global level, a threshold-triggered incremental repartitioning mechanism is activated when cross-partition events exceed 10\%; the runtime then suspends simulation, updates the communication graph, performs METIS boundary adjustment, and migrates LP state. The stated purpose is to reduce remote communication, queue imbalance, and synchronization latency (Jia et al., 24 Jul 2025).

The third extension changes the modeling interface from grid-centric to entity-centric. In the optimized framework, entities are LPs and actions are events. Each entity inherits from LogicalProcess, implements initializeLP() and receiveEvent(const warped::Event &event), and stores mutable state through a WARPED_DEFINE_LP_STATE_STRUCT macro. LP attributes include faction, speed, weapon type, detection range, attack range, and dynamic state. The custom WarEvent extends the Warped2 event abstraction with three event types: reconnaissance, attack, and missile movement. The event flow is reconnaissance $\rightarrow$ missile movement $\rightarrow$ attack, subject to validation checks. To support shared-world interaction, the framework introduces mutex-protected singleton managers such as EntityManager and GlobalDataSingleton. The abstract describes this as an entity interaction solver with constraint satisfaction mechanisms, but the paper does not formulate a CSP, SAT, or SMT problem. Instead it describes a practical consistency layer: shared real-time state, target validation, existence checks, and ordered interaction semantics (Jia et al., 24 Jul 2025).

The fourth extension addresses geometric interaction search. The simulation space is a hexagonal GridWorld using a cubic coordinate system constrained by

$x+y+z=0.$

Global hash-table structures map grid coordinates to hash indices and grid cells to entity lists. The paper gives a printed hash formula,

$$HashValue = (coord.x * P1 + coord.y * P2 + coord.z * P3 ) \% (HashValue) + 1,$$

while also noting that the modulus base is intended to be the hash table size; as printed, the formula is internally inconsistent. Collision resolution uses linear probing. The neighborhood algorithm expands ring by ring to detection radius $N$, scans only entities stored in relevant local cells, validates targets, and returns early when appropriate. The paper characterizes the naive search as $O(n^2)$ and the hashed local lookup as constant-time on average, with the overall neighborhood search effectively reduced to linear-scale behavior under bounded occupancy assumptions (Jia et al., 24 Jul 2025).

5. Experimental evaluation and reported performance

The experimental platform is specified as an AS-4124GS-TNR server with 2 × AMD EPYC 7713 @ 1.70 GHz, 128 total cores, 1.5 TB memory, and 14.6 TB storage, running Ubuntu 20.04.6 LTS with Docker, GCC 9.4.0, Python 3.8.10, OpenMPI 4.0.3, MPICH 4.1.2, and related dependencies. The application scenario is a hexagonal GridWorld with entity types including ground structures, aircraft, ground forces, and vessels, with simplified grid-based movement, detection, and attack ranges. Both MPI-based inter-process and Pthreads-based intra-node executions are evaluated (Jia et al., 24 Jul 2025).

For LP migration alone, using 4 MPI nodes and 2 worker threads each, with 200,000 entities each initialized with one event, 25,000 additional entities each initialized with three events, ten generated events per event, and 10 time steps, the paper reports 12.1238 s without migration versus 10.6864 s with migration. In a more imbalanced load-balancing test, the reported runtimes are 34.938 s for baseline, 26.527 s for migration only, 15.016 s for load balancing only, and 14.609 s for load balancing plus migration. The paper explicitly states that the combined optimization yields a 58.18\% reduction relative to baseline, and that load balancing alone contributes 57\% of the total reduction. It also notes that partitioning completed in under one second (Jia et al., 24 Jul 2025).

For the nearest-neighbor optimization, the paper reports very large gains over brute force. In MPI single-core dual-thread tests, the improvement is 576\% and 861.2\% at 20,000 and 30,000 entities, rising to 1336.5\% and 1694.1\% at 50,000 and 100,000 entities. In Pthreads single-core dual-thread tests, the corresponding gains are 629.4\%, 855.28\%, 1315.1\%, and 1618.75\%. For one 100,000-entity run, nearest-neighbor search takes 326.53 microseconds versus 11,382.33 microseconds for brute force, for a reported 3,485.81\% improvement. The introduction and conclusion summarize this as roughly 34× average acceleration over brute-force search (Jia et al., 24 Jul 2025).

At the whole-framework level, the headline claims are that the optimized system achieves 16× acceleration over baseline implementations and maintains roughly 8× speedup over the 1-thread or 1-process configuration across both MPI and Pthreads. In the GridWorld scaling results, the Pthreads configuration falls from 21.85 s at 1 thread to 2.57 s at 16 threads, corresponding to 8.50× speedup and 88.2\% reduction in execution time; the MPI configuration falls from 26.21 s at 1 process to 3.02 s at 16 tasks, corresponding to 8.67× speedup and 88.5\% reduction (Jia et al., 24 Jul 2025).

The correctness tests across nine cases report 100\% success rate and 0\% error rate, with average search times below approximately 0.035 ms and coefficient of variation below 10\%. Within the paper’s own framing, these results are meant to show simultaneous gains in temporal fidelity and computational efficiency rather than raw throughput alone (Jia et al., 24 Jul 2025).

6. Significance, generality, and stated limitations

The study presents Warped2 as a practical PDES substrate whose optimistic synchronization, rollback model, and event infrastructure make it suitable for substantial extension. Some of the resulting changes are engine-level and broadly generalizable: asynchronous runtime control, dynamic queue remapping, METIS-based repartitioning, LP migration, and deferred GVT-based garbage collection are all described as useful beyond wargaming. Other changes are more application-specific: hex-grid cubic coordinates, the reconnaissance–missile–attack event chain, and the particular target-validation semantics are clearly tied to the GridWorld combat model (Jia et al., 24 Jul 2025).

The paper also states several limitations. The constraint satisfaction language in the abstract is not matched by a formal optimization or satisfiability model in the body; the mechanism remains a practical shared-state and validation scheme rather than a fully specified CSP. The use of mutex-protected singleton managers may itself introduce contention at larger scale. The repartitioning trigger—cross-partition events exceeding 10\%—is heuristic and application-tuned. Migration overhead is shown empirically to be beneficial in the reported cases, but is not given a separate analytic cost model. The paper additionally notes that some printed equations are malformed, especially in the hash formula and several performance expressions, which limits purely formulaic reconstruction of the implementation (Jia et al., 24 Jul 2025).

Taken together, these features indicate that Warped2 should be understood as both an optimistic PDES kernel and an extensible research platform. The recent wargaming study does not redefine its core semantics; rather, it shows that Warped2’s baseline combination of Time Warp synchronization, Pending Event Set optimization, rollback support, MPI messaging, and configurable runtime structure can sustain substantial architectural augmentation. A plausible implication is that Warped2’s main research value lies less in a fixed canonical engine configuration than in the way its optimistic core can absorb runtime-control, repartitioning, and model-interface changes without abandoning the speculative LP paradigm.