Repeated simulation
When simulating a CIF model, the simulator reads the CIF file, checks it for validity, generates Java code, compiles the code, and uses the compiled code using the actual simulation. All of this takes a bit of time, or even quite some time, depending on the size of the model. This situation is not ideal for repeated simulations, for instance when trying different scenarios or use cases, when simulating with different options, or when repeating simulations with various different initializations or due to stochastic behavior. The startup time for the first simulation is also present for the second simulation, etc.
It would be much better to generate and compile the code just once, and then simulate multiple times using the already compiled code, significantly reducing the startup time of the simulations. This is especially useful for automated repeated simulations, where the same simulation model, either with different options (for instance different initializations) or with the same options for a model with stochastics, is simulated multiple times and the results of simulation are for instance compared or aggregated in some way.
Compiling just once
The simulator can be used to generate code and compile it only once. By enabling the Compile only option (Compiler category), the simulator will perform all steps needed to generate and compile the code, and will then save the compiled code to a file. After saving the file, the simulator will terminate, not simulating the model.
By default, the input file name (e.g. some_file.cif) is used to construct the name of the simulator compiled Java code file, by removing the .cif file extension if present, and adding a .cifcode file extension to it (e.g. resulting in some_file.cifcode). It is possible to change this file name by using the Compiled code file option (Compiler category). If used, it specifies the absolute or relative local file system path to the compiled Java code file.
The compiled code file can be put in any directory. It does not have to be in the same directory as the original CIF model. However, make sure that any additional files, such as SVG images for visualization, remain in their original locations. They will be resolved relative to the original location of the CIF model that was compiled.
Simulating using a compiled code file
There are several ways to start simulation with a compiled code file. In fact, all the ways to start simulation for normal CIF models (e.g. .cif files), apply to compiled code files (e.g. .cifcode file) as well. The simulator checks whether the input file name ends with .cifcode and then loads the compiled code file, instead of treating the input model as CIF model.
Alternatively, a .cifcode file can be double clicked in the Eclipse Project Explorer tab or Package Explorer tab, to immediately start simulation. An option dialog is shown to configure any simulator options.
A warning is printed to the console if the compiled code file was generated by a different version of the simulator than the one used to simulate it. Ignoring the warning may lead to unexpected simulation results, or even simulator crashes.
Option effects and priorities
Most simulator options have no effect when the Compile only option (Compiler category) is enabled, as after code is generated, compiled, and saved to a file, the simulator terminates, and no actual simulation is performed.
The Compile only option (Compiler category) has no effect when debugging generated code, by enabling the Load debug code option (Simulator category).
Example
As an example, consider the following CIF model in file machine.cif:
event enter;
event processed;
event exit;
automaton machine:
disc int count = 0;
disc real process_time;
disc dist real d = normal(10, 7);
cont t der 1.0;
location waiting:
initial;
edge enter do (process_time, d) := sample d, t := 0 goto processing;
location processing:
edge processed when t >= process_time goto done;
location done:
edge exit do count := count + 1 goto waiting;
end
print machine.count for final;The model consists of a machine that processes products. Initially, the machine is waiting. Once a product enters the system, the machine will start processing. Once the product is processed, the machine is done and will be waiting for the next product to enter. The time it takes to process a product varies with each product. A normal distribution with a mean of 10 and a variance of 7 is used to model the varying processing times.
The print declaration at the end of the model is used to print the number of processed products at the end of the simulation.
Consider the following ToolDef script:
from "lib:cif" import *;
cifsim("machine.cif --compile-only=on");
rmfile("out.txt", force=true);
for x in range(1000):
string args = "machine.cifcode -i auto -a first -t 100 -o print";
cifsim(args, stdout="out.txt", appendOut=true);
end
double minimum = 9999;
double maximum = -9999;
for line in readlines("out.txt"):
double value = <double>line;
minimum = min(minimum, value);
maximum = max(maximum, value);
end
outln("Minimum: %.2f", minimum);
outln("Maximum: %.2f", maximum);The import statement makes the CIF tools available. The first cifsim command generates code for the machine.cif model, compiles it, and saves it to machine.cifcode. The rmfile command removes the out.txt file, in case it was left over from a previous run of the script.
The body of the for statement is executed 1000 times. Each time, the cifsim command is used to simulate the model, using the already compiled code in machine.cifcode. The simulation uses automatic mode due to -i auto, always chooses the first available transition due to -a first, ends at time 100 due to -t 100, and only outputs text for print declarations due to -o print. The output of the simulation is not written to the console, but to out.txt due to the use of the stdout parameter of the cifsim tool. The appendOut parameter is enabled to ensure that the output of each simulation is appended (added) to the out.txt file instead of overwriting the file for each simulation. After the simulations, the out.txt file will contain the number of processed products for each of the simulation experiments.
The remainder of the script computes the minimum and maximum number of products (minimum and maximum throughput) of the machine, as observed from the experiments. Both the minimum and maximum are initialized. Then each line of the out.txt file is processed. The numeric value is obtained by casting the text of the line to a double number. Then the minimum and maximum are updated as needed. After the minimum and maximum are calculated, they are printed to the console as floating point numbers with two digits after the decimal mark.
The output of the execution of the script could look like this, but may vary given that stochastics are used:
Minimum: 7.00
Maximum: 12.00Applications view
The Applications view shows the current status of each running application. For repeated simulation, lots of applications may be started in a short period of time. Also, a lot of status updates need to be processed by the view in a short amount of time. This may lead to many updates of the GUI of the Applications view, which could potentially reduce the responsiveness of Eclipse, and decrease the performance of the simulation. If you experience such problems, simply close the Applications view while running a repeated simulation.