Framework for damage mechanics models coupled with other models

[bwspenc]

Rationale

We are working with a few material models that are based on concepts of damage mechanics, and would like them to be interoperable with other inelastic models (creep, plasticity, etc.)

Description

The smeared cracking model (ComputeSmearedCrackingStress) is a good example of a damage model, and it is currently implemented by deriving from ComputeMultipleInelasticStress. We are now working on a couple of other damage mechanics models, and they all have the same issue -- they need to modify the stress after the other models compute the inelastic strain.

This is important for allowing these models to be used in conjunction with creep and plasticity models.

Impact

We would like to be able to use ComputeMultipleInelasticStress as a platform for including damage as well as inelastic strains. This should require pretty minimal changes to that class.

[bwspenc]

@agiorla Look at the commit on my branch that is referenced here. This is a first stab at it, and I haven't even tried running it yet, but I think it looks like it will work. It actually looks pretty easy to drop the smeared cracking model into this framework.

[agiorla]

@bwspenc it seems a good first shot. What is not clear from the DamageBase interface is where the damage variable(s) would be computed. I assume this would be as part of DamageBase::updateJacobianMultForDamage, in which case I would rename it as DamageBase::updateDamageAndJacobianMult just so that it is clear where the damage needs to be incremented.

Then, ScalarMaterialDamage could be written like this:

void ScalarMaterialDamage::updateDamageAndJacobianMult(RankFourTensor & jacobian_mult) { this->updateScalarDamage(); jacobian_mult *= _damage_index[_qp]; }

With ScalarMaterialDamage::updateScalarDamage() a pure virtual function to be inherited by actual implementations of scalar damage models (such as Mazars model).

I would imagine that DamageBase needs to store a const ref to the elastic strain field (because most damage models would need that to compute the current damage state?

Finally (it is a minor detail), I think that most damage models in the literature use the convention of damage_index = 0 for undamaged materials and damage_index = 1 for the fully damaged material. While this is just a question of convention (and numerical efficiency) [and I don't mind which one you choose], I would just add a comment in the header on what the convention is (mostly make sure that there is no mistakes in future developments)

[bwspenc]

@agiorla Thanks for looking through this! To address your questions:

I like your suggestion about renaming the function that computes the JacobianMult to have it also update that damage at that point. Not every model will have to update the damage at that point (for example, the Lee-Fenves model will have already updated it), but that will give them the opportunity.

That ScalarMaterialDamage model was actually not really intended to be a base class for all scalar damage models. It was just intended to grab a material property computed by something else and use that as a damage parameter. I was going to use that with GenericFunctionMaterial to prescribe damage using a Function for testing purposes. I may just include that in the test area or something.

Yes, it was my intent that the individual damage models just get const refs to whatever properties they need to compute their damage. I figured it makes the most sense to have that all handled by the individual derived classes, rather than the base class.

I think I would also have the management of the damage index handled in the derived classes. We would definitely want to make it clear what the conventions are in comments/documentation. It might make sense for us to have a scalar damage intermediate class that all scalar damage classes derive from just to enforce some consistency.

My biggest hang-up here is that I'm still not convinced we're managing the interaction with the inelastic models correctly. The way I have this, the inelastic models are going to operate as if they're dealing with undamaged material. That's what the Lee-Fenves model needs, but I don't think that's the case for other models like creep models. As the code is now, a J2 creep model would compute creep strains based on undamaged stresses, which would be far higher than the damaged stresses, so it would overstate the creep strain. I'm not sure whether that's how your viscoelastic models would behave. I'd like to talk with you some more about this when you have a chance.

[tophmatthews]

@bwspenc Just FYI, this is something I am interested in as well, but perhaps peripherally. I am developing an inelastic strain model similar to creep, but using the hydrostatic stress instead of the deviatoric. I am coupling all of these via ComputeMultipleInelasticStress as well.

[agiorla]

@bwspenc Going back to your last comment about interaction between damage and other inelastic models, and more specifically with the linear viscoelastic framework I have implemented (the spring-dashpots Kelvin-Voigt or Maxwell models). I looked twice at the equations, and that framework works only if we are consistent between the tensors of each spring and the stress used for the update. We have two choices:

• a) we use the undamaged stress and the undamaged stiffness tensors everywhere
• b) we use the real stress (damaged) and the damaged stiffness tensors everywhere.

The current implementation uses the real stress (damaged) and the undamaged stiffness tensor, which is inconsistent, but the user can specify which stress field to use in the calculation to make that consistent again. I personally don't like to trust the user with that responsibility, but I'm not sure whether it would make more sense to use undamaged properties (very little modification in the code) or damaged properties (in which case we might need to store a pointer to the damage model itself, and provide a distinction between the previous values for the spring stiffness tensors [used for the update of the internal strains] and their current values [used during the step]). And now that I think about it, we might need to provide that distinction anyway for viscoelastic aging models... (that is a separate issue that I'm going to open/address very soon). We store the old properties of the material so that should be pretty straightforward.