<
From version < 5.1 >
edited by aas2
on 2017/08/03 14:38
To version < 2.1 >
edited by aas2
on 2017/08/03 13:23
>
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -4,8 +4,6 @@
4 4  
5 5  {{toc/}}
6 6  
7 -----
8 -
9 9  == Overview ==
10 10  
11 11  After a model has been created, it is reasonable to test if the model does what is expected. This can be achieved by simulating the model. The simulation must
... ... @@ -18,21 +18,11 @@
18 18  
19 19  Within KIELER a single state of a simulation is represented as a //Data Pool//. A data pool can have multiple models. Each model can have multiple variables. Thus a representation of a complete run of a simulation can be implemented as list of data pools.
20 20  
21 -Executables for simulation are created using the incremental project builder that is part of the project management. The typical steps to create an executable are:
19 +== Starting a Simulation ==
22 22  
23 -* Compiling a model using the KIELER compiler
24 -* Generating the simulation wrapper code for the model using template processing
25 -* Compiling the resulting code using, e.g., gcc.
26 -
27 -For more insight of the simulation generation, please take a look at the [[doc:V2 Project Management]].
28 -
29 -----
30 -
31 -== Using the Simulation ==
32 -
33 33  Besides the explicit configuration of a simulation using a kisim file, it is possible to start simulations directly on models, executables or trace files. This will start a pre-defined configuration depending on the selected files. The following table shows which files can be started as simulation and what simulation configuration is created for it.
34 34  
35 -(% class="relative-table wrapped" style="width: 99.9453%;" %)
23 +(% class="relative-table" style="width: 99.9453%;" %)
36 36  |=(((
37 37  Selection
38 38  )))|=(% colspan="1" %)(% colspan="1" %)
... ... @@ -104,39 +104,14 @@
104 104  The current pool of the simulation is written as JSON object to the simout file.
105 105  )))
106 106  
107 -=== Playing the Simulation ===
108 -
109 -Besided manually stepping through the simulation tick after tick, it is possible to let the simulation play automatically. In play mode, a macro tick is performed after a given time, which can be defined in the data pool view (e.g. to perform a tick every 200ms).
110 -
111 -=== Stepping Back in the Simulation ===
112 -
113 -When clicking the //Step Back// button, the values of a former tick are set in the data pool view as user values, which will be assigned to the model before the next tick is executed.
114 -
115 -This it is possible to revert a model to a previous state if all variables that define the current state of this model are recorded in the data pool.
116 -
117 -=== The Data Pool View ===
118 -
119 -The current data pool can be seen in the Data Pool View (Window > Show View > Other > KIELER Simulation > Data Pool View).
120 -
121 -In the view, the variable values can be modified by the user via clicking the column //User Value//. If a user value is specified for a variable, the corresponding row is highlighted and marked with an asterisk ( * ) . The value is applied to the variable and send to the model before the next tick is performed.
122 -
123 -When using traces in the simulation, a trace mismatch of a variable will be highlighted in the data pool view. A tooltip on the //Current Value// column shows details about the mismatch. The trace mismatch is kept between ticks. To clear a mismatch, use the menu of the view and select //Clear Trace Mismatches//.
124 -
125 -When the data pool view is selected, stepping through the simulation can be done using the right arrow on the keyboard, which is often more useful than clicking the corresponding button in the toolbar.
126 -
127 -----
128 -
129 129  == Data Handlers ==
130 130  
131 -A simulation consists of a list of //data handlers//, that can read or write the current data pool. A macro tick in the simulation then consists of the execution of the read or write actions on these data handlers. Performing a single action on a data handler is called a //sub tick// and typically not necessary but can be useful to see the effect of single data handlers on the data pool.
97 +A simulation consists of a list of //data handlers//, that can read or write the current data pool. Which handlers are available are explained in the following.
132 132  
133 -Which handlers are available are explained in the following.
134 -
135 135  === Executable ===
136 136  
137 137  For instance, there exists a data handler for the simulation of an executable. The write operation of this data handler will send the inputs of the model as JSON object on stdin of the process. Afterwards the tick is triggered, and finally the data pool is updated with the JSON object received from stdout of the running process.
138 138  
139 -(% class="wrapped" %)
140 140  |=(((
141 141  Attribute
142 142  )))|=(% colspan="1" %)(% colspan="1" %)
... ... @@ -166,7 +166,6 @@
166 166  
167 167  Multiple models may interact with each other as some can have inputs that are generated as outputs of other models. To implement this behaviour in the simulation, the redirect data handler has been created. It sets the inputs of a model to the outputs of some other model in the data pool. Thus the outputs of a some model A can be used as inputs of some model B.
168 168  
169 -(% class="wrapped" %)
170 170  |=(((
171 171  Attribute
172 172  )))|=(((
... ... @@ -207,7 +207,6 @@
207 207  * Perform the tick of the model A
208 208  * Compare the outputs of the trace and the model A
209 209  
210 -(% class="wrapped" %)
211 211  |=(((
212 212  Attribute
213 213  )))|=(((
... ... @@ -293,7 +293,7 @@
293 293  
294 294  Simulation input files can also be used to feed the simulation with data to be visualized via the simulation visualization.
295 295  
296 -(% class="relative-table wrapped" style="width: 81.5545%;" %)
257 +(% class="relative-table" style="width: 81.5545%;" %)
297 297  |=(((
298 298  Attribute
299 299  )))|=(((
... ... @@ -328,7 +328,7 @@
328 328  
329 329  This data handler writes the output of the model in the simulation to the specified file.
330 330  
331 -(% class="relative-table wrapped" style="width: 81.7734%;" %)
292 +(% class="relative-table" style="width: 81.7734%;" %)
332 332  |=(((
333 333  Attribute
334 334  )))|=(((
... ... @@ -357,11 +357,9 @@
357 357  Name of the model in the simulation that will be written as JSON object to the simout file
358 358  )))
359 359  
360 -----
361 -
362 362  == KiSim ==
363 363  
364 -Which data handlers are used and which actions are performed on them for each macro tick can be configured using a DSL, namely **KiSim**.
323 +Which data handlers are used and which actions are performed on them can be configured using a DSL, namely **KiSim**.
365 365  
366 366  A kisim file contains two main parts:
367 367  
Confluence.Code.ConfluencePageClass[0]
Id
... ... @@ -1,1 +1,1 @@
1 -33260015
1 +31162495
URL
... ... @@ -1,1 +1,1 @@
1 -https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/KIELER/pages/33260015/V2 Simulation
1 +https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/KIELER/pages/31162495/V2 Simulation