## Keyboard shortcuts

Press `←` or `→` to navigate between chapters

Press `S` or `/` to search in the book

Press `?` to show this help

Press `Esc` to hide this help

# MatUser class

To create your own custom material model using our framework, derive a new class from the `MatUser` base class, which serves as a foundation for defining user-defined materials. The `MatUser` class provides a basic structure through its virtual functions, enabling you to override and customize the behavior of your material model.

To get started, create a new C++ class that inherits from `MatUser`. For example:

    #include "mat_user.h"

    class MatMyModel : public MatUser {
        // Your implementation goes here...
    };

### Configuration

Each material must define its material configuration. This is done by setting the class member variables in the constructor of your material model class. See Material configuration section for more information on how to configure a material model.

### Virtual functions to override

    void runInit(UserMatInitCPU data) const

This function is invoked during the initialization phase of the simulation. You can use it to set up any necessary data structures or perform other initialization tasks, such as set the inital state of the material and, if required, calculate material parameters.

    void runMat(UserMatCPU data) const

This function is executed each time step of the simulation if GPU acceleration in not available /enabled. It is effectively defining the behavior of the material. The constitutive response, failure criteria, and post-failure behavior are all critical components that can be tailored to capture the unique characteristics of various materials.

    void runInitGPU(UserMatHost host, UserMatDevice device, cudaStream_t stream) const

Currently not used, reserved for future implementation

    void runMatGPU(UserMatHost host, UserMatDevice device, cudaStream_t stream) const

This is similar to `runMat` but for GPU accelerated computation. Unlike the CPU-based executions, where member functions can be directly defined within the class structure, CUDA kernel implementations must reside in separate files due to the language’s inherent limitations. As a result, this function acts as an interface, invoking the relevant GPU-accelerated implementation from the external file.