# 2.2. Model Implementation

The key feature in LAMÉ that allows constitutive models to be implemented easily and application codes to be able to use those models is the interface. The key concept to understand concerning the interface is that it defines what roles the constitutive models have, what roles the application codes have, and how the models and the codes transfer information.

From the application code perspective we would like all of the constitutive models to look the same. Of course this is not the case. This is why, if we were to look at our legacy finite element codes, we see information regarding specific constitutive models show up in the application codes. Even a piece of information as simple as a material model ID will show up in the application code in order that the code call the correct model. Modern programming languages/styles allow us to avoid this confusion.

From a constitutive modeling perspective we would like a simple interface for implementing constitutive models. Constitutive modelers are only part-time code developers. They can have strengths in many areas in addition to code development, including physics, chemistry, continuum mechanics, applied mathematics, numerical methods and experimental mechanics. Having a code development environment that is useful for a constitutive model developer is necessary in the design of the constitutive model library.

## 2.2.1. Code Standards

The need to supply not only robust constitutive models, but also a robust constitutive modeling environment, requires strict adherence to code standards. Some code standards are stylistic. These are necessary to support the code (promoting readability) and to simplify the effort needed by the constitutive modeler to implement a model. Other code standards are necessary to support the code on various platforms and to prevent unintended behavior like memory leaks.

## 2.2.2. Testing Standards

Ensuring robust and reliable constitutive models also requires testing. There are two main concerns in providing constitutive modeling to an application code: accuracy and speed. Both of these concerns can be addressed to a large degree through testing. Toward this end two testing systems are developed: a verification test suite and a performance test suite.

### 2.2.2.1. Verification Testing

Constitutive models for the large deformation of materials can be extremely complex. This complexity is added to by the issues associated with implementing the model in the code. There are two questions associated with assessing this complexity. First, what is the expected result of the model, independent of its implementation? Second, does the implementation model that response?

### 2.2.2.2. Performance Testing

In a nonlinear solid mechanics analysis, the constitutive models are called often. For an explicit transient dynamics problem, the model is called once for each time step for each integration point in the finite element model. On the other hand, implicit quasi-static analyses call the model every iteration of every time step for each integration point in the finite element model.

Given the amount of time that a nonlinear solid mechanics finite element analysis spends calculating the stresses in a constitutive model, the performance of the constitutive model can have a large effect on the performance of the host code.

In order to ensure some measure of performance, a procedure for testing the performance of the models is proposed. First, a baseline set of performance data must be generated. Given that the CPU time used by the model can depend on many things, including the current loads on the machine where the test is being run, developing an approach for modeling the performance is not straightforward. If we call the various states of the machine “configurations”, then the best approach appears to be to generate a large set of data for the performance of the constitutive model that reflects the performance on a single machine over a large variety of its configurations.

Specifically, since we want to test only the speed of the constitutive model, we run tests that are fully prescribed strain paths. This eliminates any need for the material driver to solve an equilibrium state. We also want to test as many of the features of the constitutive model as possible. This requires a prescribed strain path that pushes the model into regimes of interest. For example, for an elastic-plastic model the performance test has to trigger plasticity, otherwise it will not reflect accurately on how the model performs in an analysis. We also want the strain path to push the plasticity model deep enough into the plastic range.

Determination of an appropriate strain path is not clear cut for all materials. Recognizing this, the performance tests should be documented clearly so that we know exactly what we are testing and we can go back and modify a test if there is some feature of the model that doesn’t appear in the performance test.

## 2.2.3. Documentation Standards

In order to disseminate information about the models in LAMÉ, there must be a commitment to documentation. The theory behind the models and their implementation must be documented. Furthermore, much of the success of the verification and performance testing depends on documentation too. Finally, documentation must be generated for analysts that allows them to understand what materials and behavior the model can represent, along with the inputs necessary to use the model and the outputs that come from the model.