kimauth / materialmodels.jl Goto Github PK

Should we introduce a custom MaterialConvergenceError that could store the newton trace of the unconverged iterations? Now, we're just throwing an ErrorException and the error message isn't particularily informative about what happened.

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.

Perhaps it would be nice to have some additional functionality for each material that allows recovering information e.g. for postprocessing. Here is an example for the material that's currently called Plastic:

function state_conjugates(
    ε::SymmetricTensor{2,3,T,6}, 
    material::Plastic,
    state::PlasticState{3},
)
    (; Eᵉ, r, H) = material

    σ = Eᵉ ⊡ (ε - state.εᵖ)
    k = - state.κ / (r * H)
    a = - 3/2 / ((1-r)*H) * state.α

    return σ, k, a
end

function strain_rates(
    material::Plastic,
    σ::SymmetricTensor{2,3},
    κ::Real,
    α::SymmetricTensor{2,3},
    λ::Real,
)
    (; κ_∞, α_∞) = material

    σʳᵉᵈ = σ - α
    σʳᵉᵈ_dev = dev(σʳᵉᵈ)
    σₑʳᵉᵈ = sqrt(3/2) * norm(σʳᵉᵈ_dev)
    α_dev = dev(α)

    # flow + hardening rules
    ν = 3/2 * σʳᵉᵈ_dev / σₑʳᵉᵈ
    ζ_κ = -1. + κ / κ_∞
    ζ_α = -ν + 3. / (2α_∞) * α_dev

    # evolution equations
    dεᵖdt = λ * ν
    dkdt = λ * ζ_κ
    dadt = λ * ζ_α

    return dεᵖdt, dkdt, dadt
end

function dissipation(
    ::Plastic, # could perhaps be more general
    σ::SymmetricTensor{2,3},
    κ::Real,
    α::SymmetricTensor{2,3},
    dεᵖdt::SymmetricTensor{2,3},
    dkdt::Real,
    dadt::SymmetricTensor{2,3},
)
    # dissipation
    𝔇 = σ ⊡ dεᵖdt + κ * dkdt + α ⊡ dadt

    return 𝔇
end

This design tries to avoid recomputations of variables where possible, thus the function signatures. For convenience, these functions can of course be glued together and then have simpler signatures:

## convenience wrappers if intermediate results are not needed
function strain_rates(
    ε::SymmetricTensor{2,3}, 
    material::Plastic,
    state::PlasticState{3},
    Δt::Float64,
)
    σ, _, _ = state_conjugates(ε, material, state)
    (; κ, α, μ) = state

    λ = μ / Δt
    return strain_rates(material, σ, κ, α, λ)
end

function dissipation(
    ε::SymmetricTensor{2,3}, 
    material::Plastic,
    state::PlasticState{3},
    Δt::Float64,
)
    σ, _, _ = state_conjugates(ε, material, state)
    (; κ, α, μ) = state

    λ = μ / Δt
    dεᵖdt, dkdt, dadt = strain_rates(material, σ, κ, α, λ)

    return dissipation(material, σ, κ, α, dεᵖdt, dkdt, dadt)
end

Happy to hear some feedback!

A few thoughts for the documentation that could be good to discuss to avoid major restructuring later?

Documentation of new materials

Currently, we seem to document both the creation of the AbstractMaterial type as well as the material_response function for that material. Would it be an idea to have a single documentation for the material_response function (similar to get_cache and initial_material_state), and only document each AbstractMaterial?

Documentation of internal functions

In my PR #28, I have a utility_functions.jl file with some general purpose functions. These are not exported, but perhaps it would be nice to document these functions in the docs - perhaps under "Internal utilities"? Here we could also document the nonlinear_solver.jl contents?

From #14 :

I think we should decide what the material should output, ie dSdE or dPdF etc...
If we should allow "delta-strains" (Δε) or force ε + state variable.

I agree that we should have decisions on both of these. My thoughts are:

1. dSdE / dPdF etc: Can we handle this via the strain trait, too? The stress and the strain measure are closely connected, are they? Which would be the output that is closest related to the small strain model (i.e. which one should it be so that in the simplest case the same material routine can be used for small and finite strains) ?
2. Δε vs. ε: I'm a little critical about the ε + state variable solution. It seems like a poor idea to me to store an additional (unneeded) state variable for every material point. On the other hand we could store the elastic or plastic part of the strain tensor instead of the stress (but I think this would mean additional operations for computing the trial stress).