Crack propagation SNES iterations divergence

[François EDF Energy]

Hi,

The SNES iteration of mycrack propagation calculation are not converging at the first step (see log file enclosed)

Nonlinear elastic_ solve did not converge due to DIVERGED_MAX_IT iterations 50

I increase the tolerance of the non-linear problem parameters without any effect.

-propagation_snes_atol 1e-6
-propagation_snes_rtol 1e-4

Which parameters can be modify to reach convergence ?

May be those controlling the mesh cutting, in order to have a finer mesh from the beginning ?

Kind regards,
Francois.

[Lukasz Kaczmraczyk]

Hello,

It looks that you have a problem with boundary conditions. 

1) Do you apply nonzero displacements at some nodes, edges or surface?

2) Do you have restrained rigid body motion?

This not looks like a problem with tolerances. Mesh is cut fine, and initial residual looks ok.

Regards,

Lukasz

[François EDF Energy]

I checked my .config file, everything looks fine to me.

1) forces are applied (block 2 & 6)

2) One face is fixed (block 5)

I also checked that the block numbers are correctly associated with the groups numbers.

[Lukasz Kaczmraczyk]

 Config file looks ok to me.

Can you sen me med file. I will look at it.

[François EDF Energy]

Here it is.

The edges and vertices groups look ok to me.

May be something else is wrong.

[Lukasz Kaczmraczyk]

After looking at your config file, I would check if you have rigid body motion restricted.

[Lukasz Kaczmraczyk]

Hello,

I apologise for the late response. Have not notice your response. 

You where right, it is problem with tolerances. Your model is ok.

Set tolernces for Newton solver:

-elastic_snes_atol 1e-5
-elastic_snes_rtol 1e-5
-propagation_snes_atol 1e-5
-propagation_snes_rtol 1e-4

Set tolerances for linear problem:

-propagation_ksp_atol 1e-8
-propagation_ksp_rtol 1e-6

That looks that is solves the problem.

That solves the problem. This is a relatively big problem, at least for the laptop, and conditioning of matrix start to be a problem. 

BTW:
Can you make coarser mesh for testing? That is better to kick start analysis with coarser mesh first, check if boundary conditions works, etc. After that run bigger problem.

It is good to test it for the fine mesh. However, for this problem, I would recommend to do slightly coarser mesh and increase

 -my_ref_order 2

If you need better quality, That is more efficient.

You can locally refine mesh at the crack tip on the flay, to do that use

-my_ref 1

Kind regards,

Lukasz

 

[François EDF Energy]

Hi Lukasz,

I finally find out that a mistake in the unity of my model was the origin of the divergence.
I'll follow your advise about running a first analysis with coarser mesh. That might be useful to detect and fixed the issues quicker.

I'm currently running an analysis of the Full_Brick with a quite fine mesh, I set -my_ref 1 -my_ref_order 2.
The crack reach the 2/3rd of the height of the brick in 170 steps (-arc_lenght 1e-4).
It's a quite heavy and long calculation due the capacity of my computer. Anyway everything is running perfectly and the results seem really satisfying so far.
I'll send you the complete results once I'll be finish, it might be interesting for you.

I'd like to know if there is a way to set up the memory allocated to MoFEM for the calculation (like we can allocated a number of processeur with -np) ?

Kind regards,
Francois

[Lukasz Kaczmraczyk]

Hello,

Unfortunately, you can not control memory allocation. You have to have enough memory to solve the problem.

However the biggest consumer of memory is a solver, in your particular case, it is mumps.  Mumps is direct solver and needs much more memory than iterative solvers. 

Instead, you can use the block-multi-grid solver, which has been developed for fracture model, which should reduce memory demands. However, this needs set-up of tolerances for linear solver. Let me know if you like to try how it works. 

Regards,

Lukasz