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.