Store data on integration points

[mrp089]

Use Case

All constrained-mixture-based (CMM) growth and remodeling (G&R) solid material models need to store internal data on each integration (Gauss) point. Different CMM materials store different sets of information:

• full CMM (Add constrained mixture material model #2): every past time step
• homogenized CMM (Add homogenized constrained mixture model #33): previous time step
• equilibrated CMM (Add equilibrated constrained mixture model #49): pre-loading time step

Problem

We currently store all global data on a node/dof-basis, which doesn't fit the G&R models.

Solution

There are two ways to implement this:

1. Store a n-sized vector on each integration point, where n is the number if internal variables
2. Store an n x elem-sized matrix globally, where elem is the total number of elements

I think approach 1 might be easier to implement with parallelization in mind. The elements are already distributed to processors and the data is only needed within each element. An example of this would be the FEMaterialPoint in FEBio, see usage here.

Alternatives considered

We discussed with @MatteoSalvador storing all data in a node-based format using back-and-forth projection using the elements' shape functions. The advantage of this would be that we get a regularization of G&R variables by the shape functions. Also, it would fit the FEM way of storing all data on a nodal basis.

After thinking about it more, I think we can't do this easily. These internal variables don't appear (directly) in the weak form and are not part of the unknowns. The projection would make everything we compute non-local to the elements and complicate the linearization. Furthermore, we would need a way of spatially interpolating tensors. Happy to discuss more!

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct and Contributing Guidelines

[ktbolt]

This G&R internal data is a state variable yes? State variables (velocity, displacement, etc.) are stored as global arrays in the ComMod class so if we want to follow how things are currently implemented then G&R internal data should be stored as an n x elem-sized matrix in ComMod.

On the other hand, we may want to break with tradition and create some classes and some sort of interface for this, just need to get it to work with the parallel distribution code and also with the post processing code (averaging element data to shared nodes).