Simulation of DEVS Models

1. Simulation of DEVS Models Dr. Xiaolin Hu

2. Outline • Review of Event Scheduling • DEVS atomic model simulator • DEVS coupled model simulator • A heap-based Simulator • oneDCoord • Real time simulator • Discrete time simulator • Performance analysis for Dynamic Structure DEVS models

3. Event Scheduling • Event scheduling is a basic approach in discrete event simulation. • The event scheduling utilizes a event list, which stores a lift of events that are ordered by increasing scheduling times. • The event with earliest scheduled time is removed from the list and the clock is advanced to the time of this imminent event. The routine associated with the imminent event is executed. • A tie-breaking procedure is employed if there is more than one such imminent events. • Execution of the event routine may cause new events to be added in the proper place on the list. Also, existing events may be rescheduled or even canceled. • The next cycle now begins with the clock advance to the earliest scheduled time.

4. Gen Queue Server Event Scheduling Example Event: Generate_Job nr-waiting = nr-waiting +1 schedule a Generate_Job in inter-gen-time if nr-waiting = 1 then schedule a Process_Job in service-time Event: Process_Job nr-waiting = nr-waiting -1 if nr-waiting >0 then schedule a Process_Job in service-time Break-Ties by: Process_Job then Generate_Job

5. DEVS Model and DEVS Simulator DEVS Model (atomic model or coupled model) DEVS Simulator (centralized simulator, distributed simulator, real time simulator) DEVS makes a distinct separation between its models and simulators.

6. Atomic Model Simulator

7. DEVS Simulator for Atomic Model • What is the main design idea? • The idea is that the simulator should call the deltext, deltint, deltcon, out functions in the right place at the right time. How to do it? • Assuming the next event time is tN • Who trigger the model to arrive at this point? • External or internal • What shall we check first? • t==tN, out() • What shall we do next? • State transition functions • Next? How to decide when will be the next t? • Update tL and tN • Initialization?

8. Atomic Model Simulator • Every atomic model has a simulator assigned to it which keeps track of the time of the last event, tL and the time of the next event, tN. • Initially, the state of the model is initialized as specified by the modeler to a desired initial state, sinit. The event times, tL and tN are set to 0 and ta(sinit), respectively. • If there are no external events, the clock time, t is advanced to tN, the output is generated and the internal transition function of the model is executed. The simulator then updates the event times as shown, and processing continues to the next cycle. • If an external event is injected to the model at some time, text (no earlier than the current clock and no later than tN), the clock is advanced to text. • If text == tN the output is generated. • Then the input is processed by the confluent or external event transition function, depending on whether text coincides with tN or not. m timeline (abstract or logica) tN tL inject at time t s =: s init tL =: 0 tN =: ta(sinit) If t == tN generate output  (s) When receive m if m!= null and t < tN, s := ext (s,t-tN,m) if m!= null and t == tN, s := con (s,t-tN,m) if m= null and t == tN, s =: int (s) Legend: m = message s = state t = clock time tL = time of last event tN = time of next event tL =: t tN =: t + ta(s) genDevs. simulation. atomicSimulator

9. Coupled Model Simulator

10. DEVS Simulator for Coupled Model • The design idea is that the simulator should call the deltext, deltint, deltcon, out functions of the right components at the right time. How to do it? • Assuming the next event time is tN • Who trigger the model to arrive at this point? • Which components • How to find these components? • The imminent, or ask a component itself to decide if it is imminent • What shall we do first? • Out() • What shall we do next? • Send messages to each other • Next? • State transition functions • Next? How to decide when will be next t? • Update tL and tN • Initialization?

11. Basic DEVS Simulation Protocol 3 getOut 5 applyDelt simulator simulator simulator tN tN tN 4 sendOut 2. outTN Component Component Component tN. tL tN. tL tN. tL For a coupled model with atomic model components, a coordinator is assigned to it and coupledSimulators are assigned to its components. In the basic DEVS Simulation Protocol, the coordinator is responsible for stepping simulators through the cycle of activities shown. • Coupled Model Coordinator: • Coordinator sends nextTN to request tN from each of the simulators. • All the simulators reply with their tNs in the outTN message to the coordinator • Coordinator sends to each simulator a getOut message containing the global tN (the minimum of the tNs) • Each simulator checks if it is imminent (its tN = global tN) and if so, returns the output of its model in a message to the coordinator in a sendOut message. • Coordinator uses the coupling specification to distribute the outputs as accumulated messages back to the simulators in an applyDelt message to the simulators – for those simulators not receiving any input, the messages sent are empty. 1 nextTN Coupled Model coordinator After each transition tN = t + ta(), tL = t • Each simulator reacts to the incoming message as follows: • If it is imminent and its input message is empty, then it invokes its model’s inernal transition function • If it is imminent and its input message is not empty, it invokes its model’s confluence transition function • If is not imminent and its input message is not empty, it invokes its model’s external transition function • If is not imminent and its input message is empty then nothing happens.

12. Illustrating The DEVS Simulation Protocol within DEVS itself The DEVS Simulation Protocol can be illustrated within DEVSJAVA itself as follows: The coupled model, simTrip, represents the simulation of coupled model gpt. We define simulator and sCoordinator subclasses of atomic. The components of simTrip are: 3 instances of the simulator class, one each for g, p, and t 1 instance of the sCoordinator class. SimpArc gpt SimpArc simTrip SimpArc sCoordinator gpt SimpArc simulator

13. DEVS Simulation Protocol as Implemented in DEVSJAVA simulators. simulators. tellAll tellAll ("initialize“) ("initialize“) --- at start of simulation genDevs. simulation. coordinator coordinator simulators. simulators. AskAll AskAll (“ (“ nextTN nextTN ”) ”) simulators. simulators. tellAll tellAll (" (" computeInputOutput computeInputOutput “) “) simulators. simulators. tellAll tellAll (" (" sendMessages sendMessages ") ") DEVS cycle simulators. simulators. tellAll tellAll (" (" DeltFunc DeltFunc “) “) message message coupledSimulator coupledSimulator coupledSimulator Atomic Model Atomic Model Atomic Model Atoimc3 genDevs. simulation. coupledSimulator coupling

14. DEVS Simulation Protocol Classes Stand alone atomic models are assigned to AtomicSimulators Atomic models as components within coupled models are assigned to coupledSimulators Atomic Simulator coordinator coupledSimulator 1:n Coupled models are assigned to coordinators 1:n coupledCoordinator Coupled models as components within coupled models are assigned to coupledCoordinators genDevs. simulation. coordinator genDevs. simulation. coupledSimulator

15. Compare with the typical “Event Scheduling” • The event scheduling utilizes a event list, which stores a lift of events that are ordered by increasing scheduling times. For example, use a heap data structure to store the events. • In this approach, all the events are stored and updated in a “central” place. • In the DEVS implementation, events are storied in simulators in a decentralized way. In every simulation cycle, all simulators reports its next event and then the coordinator chooses the event with the smallest next tN. • This approach matches closely with the hierarchical structure of the DEVS model. However, it is not efficient from the performance point of view.

16. The Basic DEVS Simulation Protocol simulators.AskAll(“nextTN”) tN = compareAndFindTN(); simulators.tellAll("computeOut“,tN) simulators.tellAll("sendOut") simulators.tellAll("ApplyDelt“,tN)

17. The Basic Simulation Protocol (cont.) • Follows closely with the semantic of DEVS models. • Easy to be understood. • In a direct implementation: • All simulators have to go through the simulation steps in every cycle. • Computation complexity O(N) • Tends to result in slow simulation speed for models that have a large number of components.

18. A Heap-based Implementation tN = Heap.getMin() imminents = Heap.getImms() imminents.tellAll("computeOut“,tN) imminents.tellAll("sendOut") imminents = imminents.addAll(influencees) imminents.tellAll("ApplyDelt“,tN) imminents.tellAll(“updateHeap”) simulators.AskAll(“nextTN”) tN = compareAndFindTN(); simulators.tellAll("computeOut“,tN) simulators.tellAll("sendOut") simulators.tellAll("ApplyDelt“,tN) • N simulators are stored in a log2N depth heap • Only the imminents (and the influencees) go through the simulation steps in each cycle. • Computation complexityfor heap update – O(n*log2N) • Computation complexity for executing the state transition functions – O(n) • When n is small, it has better performance

19. Demonstration of the heap-based coordinator using the forest fire example

20. The oneDCoord simulator • An example of an advanced simulator that taking advantage of the spatial behavior of the cellular space models. • X. Hu, and B. P. Zeigler: A High Performance Simulation Engine for Large-Scale Cellular DEVS Models, High Performance Computing Symposium (HPC'04), Advanced Simulation Technologies Conference, April 2004 http://www.cs.gsu.edu/xhu/papers/Hu_Zeigler_HPC04.pdf

21. Real-Time Simulator/Executor Execution in real time of an atomic model is similar to its simulation in logical or abstract time. The difference is that rather than being controlled by an events list within the coordinator, each simulator governs itself according to the host processor system clock. Thus passage of time in the model is identical to that of a wall clock. This difference is seen in the following alteration of the simulator: m timeline real tN tL inject at time t s =: s init tL =: 0 tN =: ta(sinit) If t == tN generate output  (s) sleep for ta(s) When receive m if m!= null and t < tN, s := ext (s,t-tN,m) if m!= null and t == tN, s := con (s,t-tN,m) if m= null and t == tN, s =: int (s) • When first entering the state, s, the simulator starts a thread to sleep for a time ta(s) • If an external event is injected to the model at some time, text (no earlier than the current clock and no later than tN), the sleeping thread is interrupted and • If text == tN the output is generated. • Then the input is processed by the confluent or external event transition function, depending on whether text coincides with tN or not. Legend: m = message s = state t = clock time tL = time of last event tN = time of next event tL =: t tN =: t + ta(s) Real time execution of DEVS models is facilitated by the separation of model from simulator which allows the simulator to be “changed out” by one that adheres to a real clock. The ease of migration from simulation to execution enables a designprocess called model-continuity discussed later. genDevs. simulation.realTime atomicRTSimulator

22. Discrete Time Simulation • The following algorithm is an example of a simulator for a discrete time model: Ti=0, Tf=9 the starting and ending times, here 0 and 9 X(0) = 1, …, x(9) = 0 the input trajectory q(0) = 0 the initial state t=Ti While (t<=Tf){ y(t) = λ(q(t), x(t)) q(t+1) = δ(q(t), x(t)) t = t+1 }

23. What can we change for a DTS model? tN = tN +1; simulators.tellAll("computeOut“,tN) simulators.tellAll("sendOut") simulators.tellAll("ApplyDelt“,tN) simulators.AskAll(“nextTN”) tN = compareAndFindTN(); simulators.tellAll("computeOut“,tN) simulators.tellAll("sendOut") simulators.tellAll("ApplyDelt“,tN) tN = tN+1; -- there is no need to ask tN from simulators

24. Performance Measurement of DEVS Dynamic Structure Models

25. Standard Simulation Protocol Models.construction(); Models.initialization(); While (stop condition is not met){ simulators.AskAll(“nextTN”) tN = compareAndFindTN(); simulators.tellAll("computeOut“,tN) simulators.tellAll("sendOut") simulators.tellAll("ApplyDelt“,tN) }

26. Performance Analysis • Simulation protocol applies to both dynamic structure (DS) and non-dynamic structure (non-DS). • The difference is that the number of simulators involved in the simulation cycle is different. • For non-DS, the number of simulators is fixed; for DS, the number of simulators dynamically changes, due to the fact that models are dynamically added and deleted.

27. Performance Analysis • General formula of total execution time: T = Tinitial + (1) where, T is the total execution time. Tinitial includes the model construction and initialization time and Ti is the execution time of one cycle; m_step is the total simulation cycles. This formula is based on cellular spaced forest fire spreading simulation.

28. Performance Analysis • For DS model, a cellspacemanager model is used to add/remove forest cells. formula (1) becomes Tinitial = tinitial-of-cellspacemanager (2) =(3) where, in formula (3), tij is cycle execution time of an active cell. n is the number of active cells. Toverhead_i consists of initialization of added cells and coupling/decoupling of added and deleted cells.

29. Performance Analysis • For non-DS model formula (1) becomes Tinitial = N * tinitial-of-cell (4) = + (5) where, tij is cycle execution time of an active cell; tij’ is cycle execution time of a non-active cell; N is the total number of cells in the cell space. Generally, tij’ < tij.

30. Performance Analysis • Based on formulas (2), (3), (4) and (5), we get execution time difference of non-DS and DS: Tnon-DS - TDS = N * tinitial-of-cell - tinitial-of-cellspacemanager + (6) A major part of the difference of two models lies in non-DS model’s non-active cells’ cycle execution time and DS model’s overhead for adding/deleting cells.

31. General Observation From Performance Analysis • On one hand, DS forest fire model decreases execution time. • Dynamic structure saves time in the beginning. • Dynamic structure saves time during simulation. • On the other hand, DS model reduces memory utilization.

32. Six Measurement Metrics • Initialization time for different cellular space size • Execution time for different cellular space size • Execution time at different simulation stages • Memory usage • Execution time for different model behaviors (different # of ignition points) • Execution time for oneDCoord, DS and non-DS models

33. Forest Fire Model and Dynamic Structure Implementation • In non-DS model, all forest cells are created at the beginning of the simulation. This adds a lot of computation time for a cell space with thousands of cells. • DS model creates active cells during simulation. Once a forest cell goes from an active state to a passive state, it is removed from the cell space. This approach only keeps the forest cells along the fire front. Fig. 1 non-DS and DS Implementation Comparison

34. Performance Measurement Result 1 --- Initialization Time Comparison • The initialization time of non-DS model increases with the increase of cellular space • For DS model, the initialization time is little and does not change with the increase of cellular space size. Table 1. Initialization time (sec.) for different cellular space size

35. Performance Measurement Result 2 --- Execution Time for Different Cellular Space Fig. 2 Different Cellular Space Comparison (a)Execution Time Comparison (b)Speedup Comparison

36. Performance Measurement Result 3 --- Execution time at Different Simulation Stages Fig. 3 Execution time Comparison at different simulation stages

37. Performance Measurement Result 4 --- Memory Usage • In non-DS model, the active cells are always equal to cell space cells, so the memory using keeps in top line and does not change. • In DS model, its active cells do not change much, so the memory using is in the bottom line and is less than non-DS model. • On the other hand, DS model does not change with the increase of cellular space size. But for non-DS model, the memory use increases with the increase of cellular space. Fig. 4 Memory Use between non-DS and DS Models

38. Performance Measurement Result 5 --- Execution Time for Different Model Behaviors Table 2. Added/Deleted Cells for DS Model (40*40) • In this metric, we implement 2-ignition and 4-ignition in 40*40 cellular space for DS and non-DS models for sparse and close behaviors. • In general, the execution time of non-DS model for sparse ignitions is less than close ignitions. The execution time of DS model for sparse ignitions is more than close ignitions. • Fig. 5 shows the speedup. When multiple ignitions are sparse, the speedup is decreased. The speedup is not only related with the added/deleted cells but also has relationship with the behavior of model. Fig. 5 Speedup of Multiple Ignitions

39. Performance Measurement Result 6 --- Comparison of oneDCoord, DS and non-DS Models • The increase of overhead for DS model reduces its performance when simulation goes to later stages. • oneDCoord uses the same idea as DS model to let only active cells execute simulation, but it has no overhead. • oneDCoord has much less simulation time compared with non-DS and DS models. Fig. 6 Execution Time for oneDCoord, non-DS, and DS Models