As simulation models become ever more complex, simulation time increases as a result. Initially, this is not a huge issue (unless the simulation is to be run in real-time, but that is a separate case), until the time it takes to simulate a model is inconveniently long. Added model fidelity is often required to deliver as accurate a result as possible, so it is undesirable to sacrifice model fidelity for the sake of simulation speed gains. Therefore, another solution to speed up models is required. One method, known as parallelisation, is available to users of Dymola; decouple blocks, found in the Claytex library, can be introduced to assist the process. Inbuilt Dymola flags make model parallelisation simple and easy to achieve.
Why could parallelisation and decoupling be useful?
If a chain is only as strong as its weakest link, then a model is only as fast as its slowest part or component. Often, this would be the most complex part or component, but also can be a component which calls an excessive number of time events or has states which vary frequently. Sometimes, it is a part whose behaviour has ramifications on much of the rest of the model. It can also be the result of stiff systems. These can all be thought of as performance bottlenecks. Whilst Dymola’s symbolic manipulation does a good job of reducing the model size and eliminating some of these bottlenecks, some such as events or stiff systems can remain and slow the simulation speed down. Therefore, in some cases employing model parallelisation and/or deploying decouple blocks to assist parallelisation can be a method of improving simulation speed.
What are decouple blocks and what is parallelisation?
Parallelisation is a process whereby two processes can be run simultaneously ‘in parallel’, sometimes known as multi-threading. When parallelisation is enabled within Dymola, the model is split into multiple sections that are run as separate threads. These threads can be run on multiple CPU cores rather than run solely on a single core. With more CPU processing power to be harnessed, an improvement in simulation speed performance may be possibly found. Parallelisation when enabled takes place during the translation of the Modelica model, with Dymola detecting which sections of the model can be split up and run in parallel as part of the symbolic manipulation process.
Example: translation window of a model which has active decouple blocks during translation with parallelisation enabled. Note the Parallelisation tab, which details the model splitting undertaken.
Dymola automatically identifies how many cores are available for parallelisation and assigns the parallelized model parts accordingly. Processor hyper-threading is also supported, where for instance a dual-core processor appears as 4 cores, quad-core as 8 etc. More information on hyper-threading can be found in the Dymola User Manual. If a processor is not hyper-threaded, then Dymola takes the number of processor cores as is. Users can specify the number of cores they wish to use in a multi-threaded application by assigning a value to the flag in the Dymola Commands window and pressing enter:
Advanced.NumberofCores
Decouple blocks can be deployed to further assist in the parallelisation process, informing Dymola how and where to break up large sections of code which otherwise cannot be broken up during symbolic manipulation. The decouple blocks themselves use development features within Dymola, calling specific Dymola functions/sub-routines. Decouple blocks can be applied at model interfaces, i.e. their connections. Within the Claytex library package “Decouple”, there are Flange, Frame, Signal and Thermal decouple blocks available.
Example: VeSyMA vehicle suspension system, with decouple blocks highlighted between subsystem frame connections.
External functions can be included in a parallelized model, although there are some key points to consider. By default, Dymola assumes that any external function is not thread-safe; this is to ensure accuracy of the executed external functions in the unknown case. Optimal performance may not result, as they are considered ‘critical’ and the parallelisation process is impacted by their status. If the functions are part of a read-only library, or known to be thread-safe, then the following flag can be set to indicate their safety:
Advanced.ExternalFunctionCritical=false
Note that this flag deals with all external functions within a model. Other annotations are listed in the Dymola user manual (vol 1, pg 774) which allow the user to specify an external function’s thread-safety status on an individual basis. This is useful if you have a mixture of thread-safe and non thread-safe functions in your model.
How can parallelisation and decouple blocks be used?
To enable parallelisation to be triggered during model translation, a flag has to be enabled within Dymola. Prior to translation, set the following flag complete with the suffix “=true” into the Commands window and hit enter.
Advanced.ParallelizeCode=true
For decouple blocks to be used, at least one decouple block has to be present in a model, sitting on the connection between models you wish to decouple. The connection passes through them, if they are inactive then they have no effect. All VeSyMA vehicle model templates feature decouple blocks between component subsystems, which can be configured and activated at the user’s discretion. To activate the decouple blocks during the model translation, set the following flag prior to model translation.
Advanced.SupportDecouple=true
Each decouple block has various flags within it, which the user can adjust to specify how the decoupling is applied depending upon the type of decouple block deployed. These settings influence how the model is decoupled across the CPU cores, and thus how the model ultimately performs.
Typical decouple block dialog box, the example showing one which acts on frame connections.
As with any computational process, there are overheads involved in the action of running parallelized code, as variables and data have to be passed between the threads of the model. If the speed benefit of parallelisation does not exceed the overheads, then a parallelized model can run slower than a standard model; this is why it is only recommended for stiff/complex models. Finding the correct strategy for your model can take time, making changes and evaluating the effect. The same principle applies to deploying decouple blocks. As a process, parallelisation without activated decouple blocks should not affect model results; use of decouple blocks creates a different model structure than normal translation and parallelisation, so care should be taken to ensure the results produced by a decoupled model are within an acceptable range of the original model.
Within the VeSyMA.Suspensions library, there is an example experiment containing a vehicle with decouple blocks activated to parallelise the rear axle, which contains suspension bushes. It can be found within the Experiments.VehicleManouvres called “FigureEightTestDecoupledRearAxle”. The vehicle has the required decouple blocks settings loaded into it, and their effect can be observed by setting the Commands window flags enabling parallelisation and decoupling support as true or false.
Further Information
For further information on decouple blocks, their use and how model parallelisation is achieved in Dymola, please see the following resources:
- User guides with the VeSyMA and Claytex libraries
- Dymola user guide vol. 1 pages 771-774
- Parallel Model Execution on Many Cores by Hilding Elmqvist, Sven Erik Mattsson and Hans Olsson.
Written by: Theodor Ensbury – Project Engineer
Please get in touch if you have any questions or have got a topic in mind that you would like us to write about. You can submit your questions / topics via: Tech Blog Questions / Topic Suggestion