About Multicore Execution

You can use multicore processing to speed up the execution of models suitable for parallelization.

Note: For many kinds of models the internal dependencies don´t allow efficient parallelization for getting any substantial speed-up.

This page discusses:

Multicore Support
Handling of External Functions in Parallel Code

Multicore Support

The evaluation of model equations for calculations of derivatives for continuos-time integration can be parallelized for using multicore processing. This feature is activated by setting the option Advanced.ParallelizeCode=true;.

The number of cores is automatically figured out.

Notes:

Hyperthreading is included in the number, i.e. a dualcore processor is seen as 4 cores, and a quadcore as 8 cores.
The calculated number of cores is seen in the command log.

If a certain number of cores are to be used (including hyperthreading), the option Advanced.NumberOfCores can be set to any (positive) number of cores. This value overrides the automatically calculated value. An example of using this option is when you want to create code for a computer with a higher number of cores than the computer you work on. To use the automatically calculated number of cores, set this option to 0. (This is also the default value of the option.)

Notes:

You must use a compiler that supports OpenMP, that is, you must use any of:
- Visual Studio Professional Edition version 2010 or later
- Visual Studio Express Edition version 2012 or later
- MinGW GCC version 4.9.2 or later
- Intel Parallel Studio XE 2016 or later
Multicore execution is currently only supported for the integrators DASSL, LSODAR, Euler, and Rkfix, when neither using DLL nor embedded server (DDE).
When using external functions in parallel code, it is assumed that the functions are not thread-safe, see next section.
For source code generation the generated C-code contains standard OpenMP-pragmas that are supported by many compilers (see their documentation).

The equations are analyzed at translation to find out which equations that can be executed in parallel. The result is a sequence of layers, where the layers have sections that can be executed in parallel. This result is presented in the command log. See Applying Multicore Simulation for an example, including information about the log messages.

Note: The method for parallelization is described in "Parallel Model Execution On Many Cores". This paper includes successful uses from the thermodynamic and electrical domains giving speed-ups for 2.9-3.4 on a quadcore computer.

Handling of External Functions in Parallel Code

When using external functions in parallel code it is by default not assumed that the functions are threadsafe. This means that all external function calls are seen as a critical region, and only one external function executes at the same time.

This avoids unpredictable results, at the cost of efficiency. If you are certain that a specific external function is thread-safe, you can override the above for this function, with the following annotation in the external function:annotation(__Dymola_ThreadSafe=true);.

If the external functions are in a read-only library, you can set the option Advanced.ExternalFunctionCritical=false; to indicate that the external functions are by default threadsafe. You then also get the same behavior as in previous versions of Dymola Behavior Modeling. The default value of this option is true.

In addition, you can use the annotation annotation(__Dymola_CriticalRegion="CLanguageIdentifier");. This indicates that the function is not threadsafe, and creates a named critical region. This ensures that only one external function with the same identifier executes at the same time (but other functions may execute in parallel) - regardless of the setting of Advanced.ExternalFunctionCritical.