Components of a GeMA simulation

A GeMA simulation is made of three main components (Figure 1): model data, solution method and results monitor. The first two define, respectively, what will be simulated and how the simulation will be done. The third, defines which and how the simulation results will be saved and also which model variables should be monitored.

Figure 1: Main GeMA simulation components

Running a GeMA simulation is a two steps process. On the first, the model data, the solution method and the list of monitored variables (from the results monitor) are loaded from a file. On the second step, the orchestration script is executed to calculate the simulation results (Figure 2).

The orchestration script is the central part of the solution method. Its main function is to allow for the user to describe the sequence of processes that should be applied to the model data for the calculation of the expected results, thus providing the main simulation loop. This script is written by the user in the Lua language, a fast interpreted language specially built to be embedded inside applications, allowing them to dynamically execute user created programs, such as the orchestration script.

Figure 2: Main steps of a GeMA simulation

Processes are the main unit used to describe the solution. In general, they are high-level primitives that describe a complete action, such as the execution of a step of a finite element analysis, the transfer of data from one mesh to another, an adaptive mesh refinement, saving a dataset, etc. In particular, analysis processes, such as the FEM analysis process, will often cooperate with physics objects to provide the mathematical model being simulated. These concepts will be further explained while this tutorial evolves.

By adopting for the orchestration script a full programming language, with support for flow control, functions, data structures, etc, instead of a simple homemade solution that would only allow for the user to describe the order of process executions, the GeMA environment gives its orchestrator the freedom to execute operations as complex as needed.

User types

Being a generic multiphysics framework means that, to solve different kinds of problems, the GeMA environment must be able to cope with different usage scenarios. To allow that, the support for creating simulation models can occur at several levels:

Configuring a pre-existing simulation for its execution over a new model data set;
Creating a new simulation where the solution method is based on pre-existing analysis methods, either created with built-in processes and physics or based in external simulators that will be integrated with the GeMA environment;
Creating new analysis methods that will be implemented by new processes and/or new physics;

When solving real life problems, usually all of the above roles can be present, possibly associated with different kinds of users, with multidisciplinary backgrounds, as seen in Figure 3.

Figure 3: User types

The first role, configuring an existing simulation, is usually associated with the user that will execute and interpret the simulation results. This user knows about the application domain, the needed input data, and their relationships, but does not need to have an in-depth knowledge of the mathematical model behind the simulation. Its responsibility consists in feeding the model with the correct input data (meshes, attributes, boundary conditions, etc) and interpreting the results.

For the second role, the user should understand the simulation's mathematical model. Its responsibility is to describe through the orchestration script how the existing processes should be combined to produce the simulation result. This kind of user does not need advanced computer programming skills. Basic abilities are enough for building the orchestration script.

Finally, the third role contemplates the need for creating new processes and physics to support new discretization methods and/or new equations for existing methods. This is the traditional framework user, with knowledge both of the desired mathematical model and numerical systems development, that uses the provided interfaces and support classes to extend the framework and create new kinds of simulators.

On this tutorial, our focus will be on the first two roles, which are roughly tied to the concepts of "model data" and "solution method".

Plugin based architecture

For a better comprehension of the format and contents of the simulation files, a brief understanding of the GeMA framework architecture and design goals is important.

Being extensible is one of the main design goals behind the GeMA framework. By adopting a software architecture based on abstract interfaces and plugins, the GeMA environment can be extended with new functionalities provided by its users, without the need to change or even recompile the existing code.

On this architecture, analysis methods, such as the finite element method, are implemented by process plugins with support from physics plugins that are responsible for providing the specific matrix formulations for each physics type (e.g.: temperature, stress, pressure, etc). Even meshes are implemented by plugins, enabling the GeMA environment to provide several kinds of meshes with different support levels. As an example, we can have a lightweight implementation that only stores the mesh geometry definition and its associated data. Another mesh plugin, on the other hand, can implement a mesh type with full support for topological queries. Figure 4 illustrates the adopted plugin architecture.

Figure 4: Plugins

Being flexible is another goal. In a multi-physics and multi-scale analysis context, that means that the user should be able to freely choose how the simulation will unfold, with liberty to decide about discretization methods and desired coupling strategies.

This liberty passes through the user being allowed to split the problem in several spatial domain discretizations (meshes), with or without overlap between them, using different scales, and being able to exchange information between those different discretizations. It also means that the user should be able to decide whether he wants to use built-in analysis processes or integrate his own calculations with external simulators, whose results will be combined according to his own schemes.

In the GeMA framework, this flexibility goal is achieved by the adoption of the Lua language, not only in the orchestration script - the heart and soul of a GeMA simulation, but also in the model description, where it can be used to create parameterized models.

Go to the next section or return to the index.