Material models

Material models#

The material model is responsible for describing the various coefficients in the equations that ASPECT solves. To implement a new material model, you need to overload the aspect::MaterialModel::Interface class and use the ASPECT_REGISTER_MATERIAL_MODEL macro to register your new class. The implementation of the new class should be in namespace aspect::MaterialModel. An example of a material model implemented this way is given in Case 2.3: BA_Ra103_vv_FS..

The main properties of the material are computed in the member function evaluate() that takes a struct of type MaterialModelInputs and is supposed to fill a MaterialModelOutputs object. For performance reasons this function is handling lookups at an arbitrary number of positions, so for each variable (for example viscosity), a std::vector is returned.

Implementations of evaluate() may of course choose to ignore dependencies on any of these material model inputs; for example, the MaterialModels::Simpler class describes a constant viscosity and a density that only depends linearly on the temperature. In writing a new material model, you should consider coefficient self-consistency (Coefficient self-consistency).

The function is_compressible() returns whether we should consider the material as compressible or not, see The Boussinesq approximation (BA) on the Boussinesq model. As discussed there, incompressibility as described by this function does not necessarily imply that the density is constant; rather, it may still depend on temperature or pressure. In the current context, compressibility simply means whether we should solve the continuity equation as \(\nabla \cdot (\rho \mathbf u)=0\) (compressible Stokes) or as \(\nabla \cdot \mathbf{u}=0\) (incompressible Stokes).

The other functions derived classes can overload are used in postprocessing as well as handling run-time parameters. The exact meaning of these member functions is documented in the aspect::MaterialModel::Interface class documentation. Note that some of these functions have a default implementation, as discussed on the documentation page just mentioned.

Additionally, every material model has a member variable “model_dependence,” declared in the Interface class, which can be accessed from the plugin as this->model_dependence. This object describes the nonlinear dependence of the various coefficients on pressure, temperature, composition, or strain rate. This information is used to implement fully nonlinear solution schemes based on, for example, a Newton iteration. The initialization of this variable is optional, but only plugins that declare correct dependencies can benefit from these solver types. All packaged material models declare their dependencies in the parse_parameters() function and can be used as a starting point for implementations of new material models.