Extra outputs from material_response

[lijas]

Sometimes I want to calculate extra information in the material routine; the dissipation and the gradient of dissipation.
I dont how common it for users to want other types of additional measures calculated in the material routine, or if this is just a special case of mine...but maybe it would be nice to have a system for this (if it is common enough).

A possible way of doing this is to use the option-dict and pass a key that you want to calculate the dissipation aswell, and then store the dissipation (and gradient of the dissipaiton) in the outptut state.

struct MatState
    statvar::SymmetricTensor
    D::Float64
    dDdε::SymmetricTensor
end

...
function material response(...)
  ...
  if options["dissipation"]
     D = ...
  end

end

This will store extra data that might be unused in most simulation which is not nice...

An option is to have D and dDdε optional in the struct instead... ::Union{dDdε, Missing}, but I dont know how this will effect type stability.

[fredrikekre]

Perhaps is is easier to just compute this after the constitutive driver?

[lijas]

You often need to use all the gradients and values that constitutive driver uses for the stress/tangent, in order do compute D and dDdε. It can be a quite large time saver to do it at the same time (in the driver), especially if the material is computational heavy.

But yeah, this is what I am doing now basically.

[KnutAM]

It is a good idea and supported by e.g. Abaqus - so more users might want this feature.
But could it not be solved by having the material calculate it if it is in the state variables? And if 2 versions are required, could not the material dispatch on different material states with the one having such fields being a subtype of the general version?
(Excuse my ignorance if this is not possible/good practice in Julia)

[kimauth]

I actually have the same issue when I need to compute spatial gradients of the tractions. In that case I want the constitutive driver to return all partial derivatives not just e.g. ∂T∂Δ . These derivatives should definitely be computed inside the material response (it would just be writing another material response function to compute them outside), but I don't have an idea how to make it possible to compute or not compute them while preserving type stability yet.

[lijas]

Nice to see that it is not a too uncommon feature 😄

Different/multiple MaterialStates could be a good solution, yes.

/Elias

[asdasdqwdqwfsdf]

Hey @kimauth, is it possible to export von Mises stress, history variables to .vtk files?

Libo

[kimauth]

Hi Libo!
This package computes only the material responses, e.g. which stress state is caused by a certain strain tensor. As that is computed in a material point (an integration point in a FE analysis), we can't really export it to .vtk - there is simply no grid in this package that could carry e.g. the stress field.
However, this package is meant to be used together with a finite element package, for example Ferrite.jl. Ferrite.jl indeed has a .vtk export functionality. The workflow would be as follows:

1. Run a simulation where you use MaterialModels.jl for obtaining the stresses in the integration points.
2. Use the L2Projector for extrapolating the stresses and history variables from the integration points to the nodes (like in this example).
3. Export the (nodal) stresses and history variables to .vtk (also shown in the L2Projector example).

Long term we'll hopefully add some examples how MaterialModels.jl can interact with Ferrite.jl (or another finite element package), but this package is still in its beginning - we still have lots of work left to do.