An Approach to Modeling

In this text, an approach to the modelling of engineering problems, as practiced and refined at tortuetec GmbH during the last years, is described. In this approach, models of the engineering problem are assembled inside a container called “conceptual model”. This includes amongst others scientific models, mathematical models, a data model and one or more real/virtual models. A real/virtual model is an intimately matching experiment/simulation pair, which is suitable for model verification and model calibration. Multiple real/virtual models within the same conceptual model can be tied together. This helps reaching engineering objectives efficiently by the synergetic application of experiments and simulations. This modelling approach has been used for through process modelling, multiscale modelling and the development of solutions for product development.

Introduction of the Idea

Here, the term real/virtual model refers to an intimately matching experiment-simulation pair, where both are part of the same conceptual model of a real-world phenomenon. Real-world phenomena include observed events, that are to be better understood by engineers. This includes the creation of product through industrial production processes (example 1) or the fatigue of structures in operation (example 2). A conceptual model [1] is a collection of scientific models, operational definitions, data models and mathematical models. The conceptual model contains descriptions, schemata, lists, flow charts, technical drawings, experiments and simulations. The following summaries can illustrate the basic idea.

Example 1: The industrial production of a product and how product properties are influenced. The first step towards a conceptual model may look like this: Industrial production of final object(s) from initial object(s). The final object properties (strength, stiffness, …) are influenced by initial object properties (thermal conductivity, density, …) and process properties (temperature, velocity, …). Physical models (heat conduction, diffusion, …) control the evolution of object properties.

Example 2: The exposure of a structure to an environment, causing degradation. The first step towards a conceptual model may look like this: Application of object(s) to environment(s). The final object properties (strength, stiffness, fatigue state, …) are influenced by the objects initial properties (heat treatment state, initial damage, …) and the environment (temperature, loading, …). Physical models (Smith-Watson-Topper fatigue parameter, Miner rule, …) control the evolution of object properties.

Also, the term real/virtual model necessitates some explanation. Experiments are real models and simulations are virtual models of real-world phenomena. For the mentioned example 2, a real model may be a fatigue test. It is composed of a test setup, a component and test parameters. A virtual model may be a fatigue test finite element simulation. It is composed of a virtual test setup, a virtual component and test parameters. If both models are part of the same conceptual model, and if they have closely matching test setup and component models, and if the test parameters use the same operational definitions and data model, then they may be qualified as real/virtual model, and the model pair can be used together:

• Resultant quantities from both models can be directly compared. For example 2, a comparison of strain/stress between the models may be used for material model calibration.
• Both models can augment each other. For example 2, an experimental Youngs modulus of a particular material volume can only be measured in one direction. But it can be simulated in all directions using virtual specimens of the same material volume.

Real/virtual models, even if one part or even both parts are kept in a rudimentary state, are valuable for thought experiments.

Even if real-world phenomena are most often complex, models should be as simple as possible. For the creation of simple and useful models, the definition of model objectives is of paramount importance (see Figure). Objectives have an enormous impact on project risk, cost and timeline.

• If the modeling objectives are wrong, and models strictly comply to them, modeling results may not provide answers to the engineer’s questions.
• If the modeling objectives are too vague, models may respect the objectives. But unnecessary details may grossly increase the cost of model development and application.

Conceptional model development and application are projects in their own. They start from defined objectives and are explained below.

Model Development

Keeping the model objectives in mind, the modelling process is started by studying information about underlying real-world phenomena (see Figure). To this end, proprietary and public information about observations, pre-existing simulations and experiments are used.

The conceptual model is elaborated through a set of models, typically including:

1. scientific models: schemata representing physical/chemical/… relations
2. technical drawings and flow charts for objects and processes
3. mathematical and physical models
4. data model of how parameters relate to objects and processes
5. in case of ambiguity: operational definitions of parameters.

Then follows the model quantification. For each parameter in the data model, a range (min/max) is determined. For example, a simple fatigue test model may only have the parameters “maximum stress” and “minimum stress” as input parameters, which both need to be within the range +100 MPa and -100 MPa.
Then a test matrix is created. The test matrix is just a collection of tests. Each test is characterized by a set of input parameter values as found in the data model, and the parameters need to lie within their allowed range. Then a fully specified test matrix for our fatigue example with two tests may look like this: { [test1: 100MPa;-100MPa], [test2: -90MPa, -90MPa] }.

Next the real/virtual model is created. To ensure that results from real and virtual model can be compared, the real/virtual model pair should operate with the same scientific model, data model and operational definitions. Each virtual or real model is completed with individual additional documents. In our fatigue example, this includes working drawings for test setups and the specimen of the real model (experiment). And the virtual model (simulation) needs a virtual representation of test setup and specimen as suitable for FEA.

Then real and virtual model are erected by manufacturing and programming, respectively. A verification process should make sure, that the real and virtual model each comply to the full underlying conceptual model. This includes functionality checks, plausibility checks and comparison of model results to expected, well known results.

Then a comparison of results from real and virtual model, using the same input parameters in both models, can be made. This can be used for model verification. In our fatigue example, “maximum strain” may be a result in both models. A discrepancy between experiment and simulation with a fully known specimen would signal, that an error needs to be found and removed. After successful verification, the comparison may be used for model calibration. In our fatigue example, if a specimen with unknown material properties is used, a comparison of experimental results and simulation results can be used to find these material properties.

A final validation step needs to make sure, that the whole conceptional model fits its purpose as defined by objectives.

Model Application

A verified and validated real/virtual model, embedded in a conceptual model, is now available for application (see Figure). Now application objectives need to be defined. Again, these objectives are paramount to the time consumption, cost and quality of model application results. In our fatigue example, an objective may be the description of the stress-life curve of a material.

Next, some information is needed for model application planning. It needs to be clarified, if the model fits the objectives. Some cases can be imagined:

• an existing real/virtual model can directly be applied. In the fatigue example, this would be the case, when
  • the real model (experiment) is fully defined. The test machine can be used without adaption. A specimen type and its manufacturing route is available. And all test parameters are compatible with the equipment.
  • the virtual model (simulation) is fully defined. The virtual test setup and the virtual specimen is available, and all material properties are known.
• An existing real/virtual model needs an extension. In the fatigue example, this would be the case, when
  • the real model (experiment) needs a new specimen type (specimen size, shape)
  • the virtual model (simulation) needs a new virtual specimen. Or if no material model is available.
• An existing real/virtual model would need a modification within the same conceptual model. In this case, a new real/virtual model is added to the same conceptual model. In the fatigue example, this would be the case, when a different, much higher test frequency is needed and
  • the real model (experiment) would need a faster actuator and temperature measurement. A modification of the test setup is not possible and a new test setup is created.
  • the virtual model (simulation) needs to take specimen self-heating into account. It would be too cumbersome for usual simulations to be extended. So a new virtual model with thermo-mechanical simulation is created
• It turns out, that the conceptual model is inadequate for reaching the objectives. Then another/new conceptual model is needed. In the fatigue example, this would be the case, if resultant mean stresses are very high, amplitudes very low. Then the situation is more similar to a tensile test or a creep test, and another conceptual model should be used.

If the model is suitable, a concept for the application is worked out and translated into test matrices for real and virtual model. Test matrix and test have already been defined in the model development section. Each test in each test matrix is then applied to the real model (experiment) or virtual model (simulation). All real and virtual results can then be evaluated together. There are some useful kinds of evaluation:

• Both models can augment each other, as can be shown for the fatigue example. An experimental Youngs modulus of a particular material volume can only be measured in one direction. But it can be simulated in all directions using virtual specimens of the same material volume.
• If experiments are more expensive than simulations, a mix of both can optimize insight/cost and fidelity/cost.
• Sensitivity analysis can be made by the variation of parameters in the text matrix and a suitable evaluation process.

This shows, that model application is frequently an iterative process, whereby look conception-testing-evaluation loops are performed, until a final report can be compiled.

Conclusions

In this work, the concept of a real/virtual model, embedded in a conceptual model, is introduced. The conceptual model can be imagined to be a container, housing all modelling aspects for one real-world phenomenon. Within this container, one or more virtual/real models can be built. A virtual/real model is an intimately related experiment-simulation pair, which allows for better validation, calibration and evaluation of test campaigns.

In this work, an overview is given over how these models are developed and applied and the most important steps and relations are mentioned. It can be used as a guideline for planning and controlling of such modelling work and for decision taking.

Having the courage to leave gaps can pay off. Objectives are indispensable. Concepts and mind models are always helpful. But doing all the steps in all depth all the time is tedious. An iterating approach should be applied. Skipping a step or being content with vague models and concepts allows for agility and early decisions. And frequently, objectives are reached without the need to erect new test setups and program complex simulations.

Finally, conceptual models can tie many real/virtual models together. Then the real/virtual models can treat the same real-world phenomenon on different scales or with different mathematical models or in more/less detail. A consistent data model is desirable, as it helps using the models together. Examples include:

• Multiscale modelling, with real/virtual models on different scales and with scale transformation models for linking the scales.
• Through process modelling with real/virtual models of successive process steps
• For providing engineering methods, whereby more agile and simple models are used in the basic design, and more predictive models are used for detail design and virtual prototyping.

[1] Conceptual model. (2018, January 15).