Elastic solver convergence with force boundary conditions

[pascals]

Dear Elmer community,

I want to impose static uniform boundary conditions (stress imposed) to a cubic sample composed of two different elastic materials (see attached mesh of a small example). The final objective is to homogenize the elastic properties of the sample. I was already able to run a simulation with kinematic uniform boundary conditions (displacement imposed boundary conditions) but I encounter convergence problems with the static uniform BC.

One example of these static uniform boundary conditions is uniaxial tension in X direction with free lateral boundaries (Y, Z). To apply that, I set two opposite forces in X direction on the top and bottom of the sample. In addition, to make the problem well-posed (that's what I imagine ?), I fix all the displacements of one node to 0.

Code: Select all

Boundary Condition 1
	Name = "x-"
	Target Boundaries(1) = 1
	Force 1 = -0.01
	Force 2 = 0.0
	Force 3 = 0.0
End

Boundary Condition 2
	Name = "x+"
	Target Boundaries(1) = 2
	Force 1 = 0.01
	Force 2 = 0.0
	Force 3 = 0.0
End

Boundary Condition 3
	Name = "Fixed node"
	Target Coordinates(3) = 0., 0., 0.
	Displacement 1 = 0.
	Displacement 2 = 0.
	Displacement 3 = 0.
End

My problem is that the iterative solver (BiCGStab with ILU0 pre-conditionner) does not converge or diverges. On the example attached to this post (sif and mesh), I have the following convergence:
100 0.2348E-02
200 0.1791E-02
300 0.1364E-02
400 0.4827E+00
500 0.8043E+03
600 0.3446E+10
700 0.5393E+16
800 0.2217E+19
817 0.3133E+21

Why does the solver not converge ? Is the problem ill-posed ? I am also not sure of what is set with Force 1 = 0.01, is that total force 0.01 distributed smartly on all nodes of the target boundary ?

I have tried with finer meshes, the convergence is very very very slow, 1e-2 after 1500 iterations, but no divergence observed.

Thanks for your help !

PS: I run Elmer on a virtual machine (linux Mint) on a MacBook pro.

[raback]

Try better preconditioner, like ILU2. -P

[pascals]

Thanks for the advice.

I have tried different ILUX

With ILU1, ILU2, ILU4 and the itersolver value diverged.

With ILU3, I obtained the following:

...
IterSolver: Calling real valued iterative solver
10 0.4576E-02
20 0.2303E-02
...
346 0.2700E+00
ComputeChange: NS (ITER=1) (NRM,RELC): ( 0.42631756E+11 2.0000000 ) :: linear elasticity
StressSolver: ------------------------------------------
StressSolver: Starting Stress Computation
OptimizeBandwidth: ---------------------------------------------------------
OptimizeBandwidth: Computing matrix structure for: linear elasticity...done.
OptimizeBandwidth: Half bandwidth without optimization: 10615
OptimizeBandwidth:
OptimizeBandwidth: Bandwidth Optimization ...done.
OptimizeBandwidth: Half bandwidth after optimization: 1430
OptimizeBandwidth: ---------------------------------------------------------
StressSolver: Solving for Stress(1,1)
CRS_IncompleteLU: ILU(3) (Real), Starting Factorization:
CRS_IncompleLU: Recursive round: 1
CRS_IncompleLU: Recursive round: 2
CRS_IncompleteLU: ILU(3) (Real), NOF nonzeros: 1163409
CRS_IncompleteLU: ILU(3) (Real), filling (%) : 845
CRS_IncompleteLU: ILU(3) (Real), Factorization ready at (s): 0.25
IterSolver: Calling real valued iterative solver
2 0.2518E-15
StressSolver: Solving for Strain(1,1)
...

I don't get the difference between the different "real valued iterative solver" ? On one hand, it seems there is no convergence, on the other hand, there is convergence.

For ILU5, I obtained "floating point exception".

[raback]

Hi pascals,

Looked at your sif file more thorougly. Unfortunately still didn't run the case. In 3D you have 6 rigid body motions - 3 translations and 3 rotations. If you just fix one node the three rotations will still be ambigious. Currently the fixed single node only defines 3 translations. You should provide at least 3 additional conditions.

Alternatively, you could use some small spring constants to ensure uniqueness.

ILU does not really like the null space and this is why increasing the order does not really help. Sorry for initially overlooking the uniquesness problem.

ILU5 probably runs out of memory.

The unit of "Force i" is Pascal if you use SI units.

-Peter

[pascals]

Hi,

Thanks. The numerical trick with the spring (k) seems to do the job and ensures the convergence. I checked that the spring does not affect the results (no observed variation on the result when k -> 0, if k is sufficiently small).

So,I added, for instance on a certain boundary :

Code: Select all

Boundary Condition 6
	Name = "z+"
	Target Boundaries(2) = 6 12
	Spring 1 = Real 0.001
	Spring 2 = Real 0.001
	Spring 3 = Real 0.001
End

Best regards,