## 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 with the SVG visualizer, 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.00

### Applications 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.