Finite strain weirdness

125 views
Skip to first unread message

Topher Matthews

unread,
Oct 23, 2019, 7:11:10 PM10/23/19
to moose...@googlegroups.com
All -

I am running a 2D simulation with a block moved by FunctionPresetBC.

When running with small strain, everything looks great.
When running with finite strain with a 9x9 mesh or lower, everything looks great.
When I run with finite strain with 10x10 or greater, everything gets all screwy:

image.png

When I run with finite strain with 10x10 and cut the time-step, everything looks okay again.
With a second order mesh, I can get up to 5x5 before things look screwy.

Is this a consequence of too much strain in one time step? I would think first/second order meshes would act the same if that were the case.

-Topher

Input file:

[Mesh/block]
  type = GeneratedMeshGenerator
  dim = 2
  nx = 10
  ny = 10
  elem_type = QUAD4
[]

[GlobalParams]
  displacements = 'disp_x disp_y'
[]

[Modules/TensorMechanics/Master/action]
  add_variables = true
  strain = FINITE
[]


[BCs]
  [./right_x]
    type = FunctionPresetBC
    variable = disp_x
    boundary = right
    function = 't'
  [../]
  [./right_y]
    type = FunctionPresetBC
    variable = disp_y
    boundary = top
    function = 't'
  [../]
[]

[Materials]
  [./plank]
    type = ComputeIsotropicElasticityTensor
    poissons_ratio = 0.3
    youngs_modulus = 1
  [../]
  [./stress]
    type = ComputeFiniteStrainElasticStress
    # type = ComputeLinearElasticStress
  [../]
[]

[Executioner]
  type = Transient
  petsc_options = '-snes_converged_reason'
  l_max_its = 100
  end_time = 0.1
  dtmin = 0.1
[]


[Outputs]
  exodus = true
[]

Wilkins, Andy (Mineral Resources, Pullenvale)

unread,
Oct 23, 2019, 7:15:07 PM10/23/19
to moose...@googlegroups.com

Do you want to set disp_x=0 on the left, and disp_y=0 on the bottom?

 

a

 

Ph: +61 7 3327 4497.  Fax: +61 7 3327 4666
Queensland Centre for Advanced Technologies
PO Box 883, Kenmore, Qld, 4069 
 

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CABnPpTrnOnRkvteoHATa%3DJ7ggkjPWRLoz99-70o_YV6ttOXEuQ%40mail.gmail.com.

Topher Matthews

unread,
Oct 23, 2019, 7:24:12 PM10/23/19
to moose...@googlegroups.com
No, I want to pull it along. This is a much simplified example of the sliding block test I am using for contact verification (https://github.com/idaholab/moose/pull/14188), where a block is mashed against a plank. But, I'm getting stuck on the tensor mechanics side with these errors before even coming in contact.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/MEAPR01MB5176F2749FE74D2C13250F8DEC6B0%40MEAPR01MB5176.ausprd01.prod.outlook.com.

Stephanie Pitts

unread,
Oct 23, 2019, 8:07:30 PM10/23/19
to moose...@googlegroups.com
Would something like an EqualValueBoundaryConstraint help? I'm not sure what is causing the mesh/node dependency though....

Stephanie

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CABnPpTrsG814L6uRwY5SyZD1MZkd__fq5GiYhNF6cgDPpN_qNg%40mail.gmail.com.

Topher Matthews

unread,
Oct 23, 2019, 8:14:29 PM10/23/19
to moose...@googlegroups.com
Do you mean EqualValueBoundaryConstraint for contact Stephanie, or for the problem in this current input? For the tests I mentioned, I am doing a bunch of test using mortar method and tensor mechanics in that PR. I ran into this problem before contact occurs, so it is independent of interacting blocks.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CAK8UXWtKScuH8z%2BiSPUi5y3MSXZSgsFKt%2BEOn9uQEfNWBJmiCQ%40mail.gmail.com.

Stephanie Pitts

unread,
Oct 23, 2019, 8:19:44 PM10/23/19
to moose...@googlegroups.com
For the problem in this current input, on the boundaries that Andy suggested to use zero displacement boundary conditions on. If I understand the constraint correctly, it will keep the edges planar but will allow them to translate in space

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CABnPpTqz_wDCVrSM-Wruy-ia4oT8jwRQ8b37Fb06SOivm-o7Rg%40mail.gmail.com.

Topher Matthews

unread,
Oct 23, 2019, 9:24:56 PM10/23/19
to moose...@googlegroups.com
Hmm, yes that may help for this. But shouldn’t that be unnecessary? Certainly I can’t do that for my contact tests as the boundaries that aren’t defined will be smooshed on purpose.

Topher Matthews

unread,
Oct 24, 2019, 10:14:46 AM10/24/19
to moose...@googlegroups.com
Oh boy, I can really get some screwy results by changing meshes with finite strain. Using the attached input file with tensor_mechanics-opt

tensor_mechanics-opt -i asdf.i left_cube_refinement=2 right_cube_refinement=2

image.png

tensor_mechanics-opt -i asdf.i left_cube_refinement=5 right_cube_refinement=2

image.png

tensor_mechanics-opt -i asdf.i left_cube_refinement=5 right_cube_refinement=5

image.png

tensor_mechanics-opt -i asdf.i left_cube_refinement=5 cube2_refinement=8

image.png


Please tell me this is input error!!
asdf.i

Stephanie Pitts

unread,
Oct 24, 2019, 11:26:49 AM10/24/19
to moose...@googlegroups.com
Since these are linear elements (quad 4), adding volumetric_locking_correction = true in the GlobalParams got rid of the distorted elements in the upper left corners when I ran your input file. The top row of elements are still squished in the 5x5 meshes, so it's just a partial solution

Stephanie

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CABnPpTo%3DXeZsusvwpLF3okPmFi_voOrJZazeEUx604ZFuYrzWQ%40mail.gmail.com.

Topher Matthews

unread,
Oct 24, 2019, 11:48:13 AM10/24/19
to moose...@googlegroups.com
Thanks so much for checking on this Stephanie!

Yeah, volumetric locking correction helps, but still has weird elements. Also, changing the poisson's ratio helps, or makes it worse. Similar things happen with second order as well.

If you take a look at stresses, they are high in the distorted elements (not surprising) but it should be zero since there is really no forces there right?

Changing convergence parameters doesn't seem to help.

This really feels like a looping problem since it is element number specific?

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CAK8UXWtB%2BbjG%3DhPkDLZm6yFPrj-27CwWC2%3Dydx00LVU3wjtmag%40mail.gmail.com.

Gary Hu

unread,
Oct 24, 2019, 1:45:14 PM10/24/19
to moose-users
Does DirichletBC fix the issue? -Gary

To unsubscribe from this group and stop receiving emails from it, send an email to moose...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CABnPpTqz_wDCVrSM-Wruy-ia4oT8jwRQ8b37Fb06SOivm-o7Rg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose...@googlegroups.com.

Topher Matthews

unread,
Oct 24, 2019, 2:00:07 PM10/24/19
to moose...@googlegroups.com
Whoa! Yes it does!

What does that mean?

To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/6699c974-3f52-4103-9097-530af8bd05f9%40googlegroups.com.

Gary Hu

unread,
Oct 24, 2019, 2:30:42 PM10/24/19
to moose-users
It means that the initial guess set by PresetBC which is supposed to be a better guess is actually not.
But I don't have any good intuition as to why it converges to the wrong solution.

-Gary

Topher Matthews

unread,
Oct 24, 2019, 2:38:57 PM10/24/19
to moose...@googlegroups.com
That’s interesting, I thought preset was supposed to be better for mechanics problems like these. I wonder why and when to use each?

To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/bec3e3bb-d8b0-4c8b-b607-b4647b8b1895%40googlegroups.com.

Benjamin W. Spencer

unread,
Oct 24, 2019, 6:37:52 PM10/24/19
to moose...@googlegroups.com

Topher,

 

Would you quit breaking the code already?

 

If you set

  decomposition_method = EigenSolution

in the Master action block, you’ll get the result you expect.  That works with both types of BC. It also converges a lot faster.

 

Although the model looks simple, you’re actually imposing extremely large incremental displacements in those elements in a single step.  The default TaylorExpansion method is faster, but it doesn’t handle large increments well.

 

Gary is right – using FunctionDirichletBC also fixes the problem. Try adding the line “execute_on=nonlinear” to the Outputs block so that you’ll see the iteration history in the Exodus file and run it with both types of BC.  You’ll see that FunctionPresetBC stretches the elements on the boundary like crazy in the first iteration, but FunctionDirichletBC does not. I’m also stumped about why it converges to the wrong solution, though. Maybe the TaylorExpansion method is so far off with large incremental deformations that the crazy configuration it converged to also satisfies equilibrium.

 

-Ben

 

tensor_mechanics-opt -i asdf.i left_cube_refinement=5 right_cube_refinement=2

 

 

tensor_mechanics-opt -i asdf.i left_cube_refinement=5 right_cube_refinement=5

 

 

tensor_mechanics-opt -i asdf.i left_cube_refinement=5 cube2_refinement=8

 

Benjamin W. Spencer

unread,
Oct 24, 2019, 7:22:51 PM10/24/19
to moose...@googlegroups.com

A few more thoughts on this:

 

It’s interesting to note that the ‘crazy’ solution is completely symmetric. I output the stresses, and they are very low, but nonzero, and they have a symmetric pattern as well. It seems like by following the iteration history that results from the use of the preset BCs, you are finding a second equilibrium solution that is admitted because of the approximations made with the TaylorExpansion method. The true solution is also admitted.

 

In light of this, maybe we should re-think the recommendation that we always give to users to use the preset BCs. We’ll probably find that some problems work better than others with one flavor of the BCs.

 

Finally, if you’re not already doing this, I would recommend using the EigenDecomposition option for all of your large deformation problems.

 

-Ben

Topher Matthews

unread,
Oct 24, 2019, 7:40:06 PM10/24/19
to moose...@googlegroups.com
I thought you'd like those broken pictures Ben :)

That all makes some sense. I'm pretty surprised that the number of elements changes the final result though.

It's now nice to acknowledge PresetBC isn't the end all BC to use, though I'm not sure why.
Perhaps FunctionPresetBC is inappropriate since it can result in large strains, while PresetBC be advantageous.

EigenDecomposition will be another interesting one to explore, although it does significantly slow down some test simulations I did. It also seems to hurt AD linear convergence, but I need to dig why.

What is the maximum strain you'd expect would work? Perhaps a damper could help protect against these extreme solutions, however I think that would require a Dirichlet type BC.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/215C9F0A-6EC6-4D7D-A89F-8153FDC4EA27%40inl.gov.

Daniel Schwen

unread,
Oct 24, 2019, 7:48:58 PM10/24/19
to moose-users
We should talk about making eigendecomp the default for finite strain in the master action.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CABnPpTo0w3iBjhyLvhArHNv9KhC6%2B0%2BZLGuytg3J4x1k5A2fAQ%40mail.gmail.com.

Topher Matthews

unread,
Oct 24, 2019, 8:03:28 PM10/24/19
to moose...@googlegroups.com
In testing with the inputs from https://github.com/idaholab/moose/pull/14188, EigenSolution does well for non-AD, but has terrible linear convergence in AD...

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CAPxoKqcRrkzkDrurH6M8YYqMb_pka4gRTnzNRJB-Ao5CJVtgZA%40mail.gmail.com.

Daniel Schwen

unread,
Oct 24, 2019, 9:07:06 PM10/24/19
to moose-users
Weird, is the Jacobian broken? I think I'm using Gary Hu's implementation for the ADReal ranktwotensor eigen value computation.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CABnPpTqddKQDAsXp-RXaA2H%2B4r0g9i_hyoFh_L57nzdak%3Dnp%3Dg%40mail.gmail.com.

Topher Matthews

unread,
Oct 24, 2019, 9:50:39 PM10/24/19
to moose...@googlegroups.com
I couldn’t see any reason why. It’s a pretty small section that is different in ADComputeFiniteStrain,  and it is identical to the non-ad version. I tried replacing all the “auto”s, but that didn’t do anything.

Daniel Schwen

unread,
Oct 24, 2019, 10:15:58 PM10/24/19
to moose-users
symmetricEigenvaluesEigenvectors has a template specialization in RandTwoTensor (the Real version calls lapack, the ADReal version is a new implementation).
So there is considerable difference in the code paths.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CABnPpTq9%2BC2iPVAyWezNA4kr3MDi8BC9HhoYTqH9oeoGr6bnuQ%40mail.gmail.com.

Topher Matthews

unread,
Oct 24, 2019, 10:49:00 PM10/24/19
to moose...@googlegroups.com
This might make the case for more careful testing...I don't think EigenSolution is actually tested with AD, and the details with FunctionPresetBC were teased out...

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CAPxoKqd9UAVoWOC2h8%3DYpk3Yz9h2OEJwsEzhRwvQckK4G0OZ%2BQ%40mail.gmail.com.

Daniel Schwen

unread,
Oct 24, 2019, 11:01:17 PM10/24/19
to moose-users
Yep, I agree. The eigendecomp is unit tested, but a proper mechanics test would be nice.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CABnPpTqQba0iy%3DZre7MayRBn540hasCX9bOJkGXvgO2bpN97Dw%40mail.gmail.com.

Derek Gaston

unread,
Oct 24, 2019, 11:24:20 PM10/24/19
to moose...@googlegroups.com
What is your scaling?  Are you using automatic scaling?  Weird solutions like this can be because of scaling issues... especially if you’re using reference residual.

If PresetBC is overly stretching your elements then you’re probably taking too big of a time step / moving things too fast.  Like you have noticed... you’ve put the elements in such a non-physical situation that the system finds a (IMO) non-converged solution.

As you’ve seen: PresetBC is not always the thing to use.  Imagine that you were trying to move the block the other direction: you would probably be inverting elements!

Derek



--
Sent from my iPhone

Benjamin W. Spencer

unread,
Oct 25, 2019, 9:57:42 AM10/25/19
to moose...@googlegroups.com
My initial thought was also that the solution simply wasn’t converged (which is what I think you’re alluding to with your comment about scaling). However, it’s actually converged very tightly. The absolute tolerance is something like 1e-13. The fact that the solution is also completely symmetric also backs that up. 

I agree that this is largely caused by taking too large of a displacement increment in one step. You would never want to take a step this large in a real problem. The EigenDecomposition option does correctly handle crazy large incremental deformation, though.

Ben

Topher Matthews

unread,
Oct 25, 2019, 9:58:38 AM10/25/19
to moose...@googlegroups.com
No scaling, no reference residual, this is independent of young's modulus, which is set as unity here.

PresetBC seems good when your fixing something already in place, but probably not good to push/pull things. At a first level, PresetBC > DirichletBC, but FunctionPresetBC < FunctionPresetBC

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CAFfxPjpogifS7oWdpt3N1-02_k8SkddAhrES%3DHKEYjcHVFoFpw%40mail.gmail.com.

Topher Matthews

unread,
Oct 25, 2019, 10:01:02 AM10/25/19
to moose...@googlegroups.com
In principle, I agree that this is a large step, and it probably teases at the edge of applicability, but it's surprising that small strain gets it right, and different mesh sizes get it right.

It's still unclear to me why the weirdness on the left block is dependent on the mesh size on the right block. Convergence is similar for both cases.

Alexander Lindsay

unread,
Oct 25, 2019, 11:31:46 AM10/25/19
to moose...@googlegroups.com
On Thu, Oct 24, 2019 at 8:24 PM Derek Gaston <frie...@gmail.com> wrote:
What is your scaling?  Are you using automatic scaling?  Weird solutions like this can be because of scaling issues... especially if you’re using reference residual.

What do you mean by the comment about reference residual? If you're using the same `nl_rel_tol`, then reference residual will almost always depend tighter convergence than the default convergence check because it requires that each variable's residual norm by dropped by the specified tolerance. The only exception is when you're approaching steady-state or your initial guess is very close to the actual solution. Reference residual is actually a much better choice for ensuring each variable is converged if you do have differences in residual scales.

Alexander Lindsay

unread,
Oct 25, 2019, 11:42:15 AM10/25/19
to moose...@googlegroups.com
I suppose using PresetBCs would be a case where you have an initial guess close to your solution ;-)

Topher Matthews

unread,
Oct 25, 2019, 2:24:31 PM10/25/19
to moose...@googlegroups.com
Whoa... “execute_on=nonlinear” to see the iteration in exodus is my new favorite thing...really cool with contact. thanks for the top Ben!

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CANFcJrFKF1otSw1e8GUj_KV3SeeyjCsVQayfZNReR4Dj_8PqwA%40mail.gmail.com.

Benjamin W. Spencer

unread,
Oct 28, 2019, 2:00:42 PM10/28/19
to moose...@googlegroups.com

The fact that small strain gets it right makes sense to me (note that it would get it totally wrong if there were any rotation or deformation, it happens to work because it’s just a rigid body translation.  I’m convinced that the culprit here is the Taylor series approximation of the decomposition of the deformation gradient into rotation and stretch, which only appears in the finite deformation case.

 

I’ve heard people say that PresetBC works better than DirichletBC for cases when the value is set to 0.  If that’s really true, I’m confused about why that would be the case because the only difference between the two is that PresetBC would be initially setting the value to 0, but it’s already 0.

 

-Ben

 

From: <moose...@googlegroups.com> on behalf of Topher Matthews <tophma...@gmail.com>


Reply-To: "moose...@googlegroups.com" <moose...@googlegroups.com>
Date: Friday, October 25, 2019 at 8:02 AM
To: "moose...@googlegroups.com" <moose...@googlegroups.com>

Error! Filename not specified.

 

tensor_mechanics-opt -i asdf.i left_cube_refinement=5 right_cube_refinement=2

 

Error! Filename not specified.

 

tensor_mechanics-opt -i asdf.i left_cube_refinement=5 right_cube_refinement=5

 

Error! Filename not specified.

 

tensor_mechanics-opt -i asdf.i left_cube_refinement=5 cube2_refinement=8

 

Error! Filename not specified.

Error! Filename not specified.

Benjamin W. Spencer

unread,
Oct 28, 2019, 2:02:36 PM10/28/19
to moose...@googlegroups.com

Yeah, it’s way cool.   You can do it on the linear iterations too.  One thing to note is that you may need to change execute_on in your AuxKernels that output things like stresses as well if you want them updated in a consistent way, but for looking at things like contact, that’s not generally necessary.

Error! Filename not specified.

 

tensor_mechanics-opt -i asdf.i left_cube_refinement=5 right_cube_refinement=2

 

Error! Filename not specified.

 

tensor_mechanics-opt -i asdf.i left_cube_refinement=5 right_cube_refinement=5

 

Error! Filename not specified.

 

tensor_mechanics-opt -i asdf.i left_cube_refinement=5 cube2_refinement=8

 

Error! Filename not specified.

Error! Filename not specified.

Reply all
Reply to author
Forward
0 new messages