The Jacobian for Finite Strain in tensor_mechanics is incorrect

[tonkmr]

Description of the enhancement or error report

In the tensor_mechanics module, the Jacobian for all finite strain problems is only an approximation. Even if the Jacobian_mult passed in by the ComputeStress material is right, the Jacobian is still an approximation because the derivative of the finite strain with respect to the gradient of the displacements is not considered. So, problems using the ComputeFiniteStrain materials should NEVER be run with solve = newton right now. The ComputeIncrementalStrain materials does not have this problem.

Rationale for the enhancement or information for reproducing the error

If we can improve the Jacobian or even make it exact, the solves will be greatly improved

Identified impact

I think we might need to consider a change to how the Jacobian is calculated in all the StressDivergence kernels. Currently, we pass a fourth order tensor to the kernels, which is used to determine the Jacobian. However, we might need an additional piece. For example

dstress/du_i = dstress/dstrain x dstrain/dgrad_u x dgrad_u/du_i.

So, we currently we get the 4th order tensor dstress/dstrain from Jacobian_mult in the ComputeStress material. But, we to do this right we also need the 2nd order tensor dstrain/dgrad_u that would be calculated by the ComputeStrain material.

Does this make sense? It also may be that this is too hard and we should just make sure that every user knows that you can't do a Newton solve with ComputeFiniteStrain materials.

[tonkmr]

@dschwen @cpritam @jasondhales @bwspenc @sapitts @amjokisaari I would love to hear your thoughts on this.

[amjokisaari]

If I'm following correctly, you're essentially doing a chain rule to incorporate the gradients of the displacements, right?

Generally speaking I think it's a good idea to make code work as well as possible with the various combinations of MOOSE solve types/solid mechanics models/etc. You don't want users to be caught in "gotcha" situations.

Making this switch would require some pretty solid documentation, both on the mailing list to tell people of the changes, and on the wiki page to make sure people know how they need to update their code (if they've made their own materials for stresses and strains, like yours truly ;) )

[cpritam]

@tonkmr If I am right you are mentioning about models that use deformation gradient (F). For such models we can obtain dstress/dF (4th order) from computestress. The trick part will be to get dF=d(grad_u) (grad_u in current config). More straight forward will be dF=d(Grad_u). But we can break symmetries, which anyways is not assumed in the FE assembly. The second part can be obtained from computestrain.

[tonkmr]

@cpritam you are correct, the dstress/dstrain piece should be 4th order, which is our Jacobian_mult that we use now. I have fixed that above.

If we take the simplest finite strain case, ComputeFiniteStrainElasticStress, the

stress = C x strain_increment, where the strain increment is calculated using

strain_increment = -Cinv_I * 0.5 + Cinv_I * Cinv_I * 0.25;

So, here we have Jacobian_mult = C, but we don't currently include dstrain_increment/d_grad_u. I'm just wondering if it is worth trying to get some estimate of this piece.

[cpritam]

I think it would improve the behavior. I more thing we may consider is the effect of F_bar. Right now thats neglected as well.

Pritam

On Thu, May 19, 2016 at 11:16 AM, Michael Tonks notifications@github.com wrote:

@cpritam https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_cpritam&d=BQMCaQ&c=54IZrppPQZKX9mLzcGdPfFD1hxrcB__aEkJFOKJFd00&r=fxcsSUDsjb-y0IYm_GEpRjJvqGZLNaPVg0XoHQqvTIc&m=BECFkN_URpwyabGOH9PnE_1Q3S-92-QDnaBW0iE8jU8&s=NNQu00W5XQxCK2l8tKuwPhV59_qF2kl1IMR0R_A6wag&e= you are correct, the dstress/dstrain piece should be 4th order, which is our Jacobian_mult that we use now. I have fixed that above.

If we take the simplest finite strain case, ComputeFiniteStrainElasticStress, the

stress = C x strain_increment, where the strain increment is calculated using

strain_increment = -Cinv_I * 0.5 + Cinv_I * Cinv_I * 0.25;

So, here we have Jacobian_mult = C, but we don't currently include dstrain_increment/d_grad_u part. I'm just wondering if it is worth trying to get some estimate of this piece.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_idaholab_moose_issues_7028-23issuecomment-2D220391873&d=BQMCaQ&c=54IZrppPQZKX9mLzcGdPfFD1hxrcB__aEkJFOKJFd00&r=fxcsSUDsjb-y0IYm_GEpRjJvqGZLNaPVg0XoHQqvTIc&m=BECFkN_URpwyabGOH9PnE_1Q3S-92-QDnaBW0iE8jU8&s=fvZiGpBGWFxudhi1k3iCqy6CPz7w62bgtOIcTMaMoKM&e=

[WilkAndy]

Heheheh, i think we all must be getting old because we (or most of us!) discussed this sometime back when doing the consistent tangent operator in plasticity. To get the correct jacobian we needed that, but also the finite-strain stuff. I'd be very appreciative if someone did this, as for me it will DEFINITELY make a difference.

[tonkmr]

I am definitely getting old. Plus, I have been running some plasticity simulations and the poor convergence is getting on my nerves. Its much better when I use a better Jacobian from the FDP preconditioner,

[WilkAndy]

Yea, basically i only run in small-strain mode because of the jacobian. So @tonkmr , are you volunteering to code this up?

[tonkmr]

@cpritam we should work together to try to improve the Jacobian.

[cpritam]

@tonkmr That sounds good to me. If you want we can discuss offline.

[WilkAndy]

Thanks guys - it'll be very valuable to me.